KR20120030320A - 의존도 데이터로부터 의존도 맵들의 발생 - Google Patents

의존도 데이터로부터 의존도 맵들의 발생 Download PDF

Info

Publication number
KR20120030320A
KR20120030320A KR1020110093671A KR20110093671A KR20120030320A KR 20120030320 A KR20120030320 A KR 20120030320A KR 1020110093671 A KR1020110093671 A KR 1020110093671A KR 20110093671 A KR20110093671 A KR 20110093671A KR 20120030320 A KR20120030320 A KR 20120030320A
Authority
KR
South Korea
Prior art keywords
data
dependency
software components
vertex
transactions
Prior art date
Application number
KR1020110093671A
Other languages
English (en)
Other versions
KR101678131B1 (ko
Inventor
인드라닐 베이색
Original Assignee
컴퓨터 어소시에이츠 싱크, 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 컴퓨터 어소시에이츠 싱크, 인코포레이티드 filed Critical 컴퓨터 어소시에이츠 싱크, 인코포레이티드
Publication of KR20120030320A publication Critical patent/KR20120030320A/ko
Application granted granted Critical
Publication of KR101678131B1 publication Critical patent/KR101678131B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/323—Visualisation of programs or trace data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/87—Monitoring of transactions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

본 명세서에서는 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 발생시킬 뿐만 아니라, 상기 데이터에 의거하여 의존도 맵들을 디스플레이하기 위한 기법들이 개시된다. 상기 데이터는 상기 소프트웨어 컴포넌트들에 의해 처리되는 트랜잭션들을 모니터링 또는 트레이스하는 에이전트들에 의해 수집될 수 있다. 상기 수집된 데이터는 상기 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 방향 그래프를 형성하기 위해 종합될 수 있다. 상기 방향 그래프에 의거하여 의존도 맵이 디스플레이될 수 있다. 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들 사이의 의존도를 보여줄 수 있다. 상기 의존도 맵은 또한 상기 소프트웨어 컴포넌트들을 포함하는 애플리케이션들 사이의 의존도를 보여줄 수 있다. 상기 의존도 맵(들)은 사용자로 하여금 어디서 문제가 발생하는지를 쉽고도 신속하게 확인할 수 있게 해준다. 예를 들면, 사용자는 문제가 프런트엔드에 있는 애플리케이션 서버에 있는 것이 아니라 백엔드 데이터베이스에 있는지를 신속히 판별할 수 있다.

Description

의존도 데이터로부터 의존도 맵들의 발생{GENERATING DEPENDENCY MAPS FROM DEPENDENCY DATA}
본 개시는 컴퓨팅 환경에서 소프트웨어를 모니터링하기 위한 기술에 관한 것이다.
인터넷 뿐만 아니라 인트라넷 및 엑스트라넷과 같은 다른 컴퓨터 네트워크들의 성장은 전자상거래, 교육 및 다른 분야들에서 많은 새로운 애플리케이션들을 가져왔다. 기관들은 그들의 사업 또는 다른 목적들을 수행하기 위해서 이러한 애플리케이션들에 점점 더 의존하며, 그들이 예상된 바와 같이 수행하는 것을 보장하기 위해 상당한 자원들을 바친다. 이를 위해, 다양한 애플리케이션 관리 기법들이 개발되었다.
하나의 접근법은 애플리케이션에서 실행되는 개별 소프트웨어 컴포넌트들에 관한 애플리케이션 런타임 데이터를 수집함으로써 애플리케이션의 인프라스트럭처를 모니터링하는 것을 포함한다. 이 접근법은 본질적으로 모니터링되는 시스템에 존재하는 에이전트들을 사용할 수 있다. 예를 들면, 소프트웨어의 인프라스트럭처를 사용하여, 쓰레드(thread)나 프로세스는 실행되는 각각의 컴포넌트를 식별하기 위해서 뿐만 아니라 각각의 컴포넌트의 실행 시간과 같은 런타임 데이터를 얻기 위해서 트레이스(trace)될 수 있다. 트레이스하는 것은 컴퓨터 프로그램이 실행하는 단계들의 상세한 기록, 즉 트레이스를 얻는 것을 가리킨다. 트레이스들은 디버깅의 보조 수단으로서 사용될 수 있다.
전형적으로, 트레이스한 결과들에 의거하여 어떤 유형의 리포트가 사용자에게 제시된다. 이 정보는 쉽게 이해되는 방식으로 사용자에게 제시되어야 한다. 만일 정보가 너무 상세하게 설명되면, 사용자는 어디에 문제점이 있는지를 정확히 판별하기 어려울 수 있다. 비록 너무 상세하게 설명되지 않더라도, 정보는 문제점의 빠른 시각화를 제공하지 않을 수도 있다. 예를 들면, 트레이스 정보는 서로 다른 컴퓨팅 장치들 상에서 실행되는 소프트웨어 애플리케이션들로부터 데이터를 수집할 수도 있다. 일부 경우들에서, 서로 다른 엔티티들이 서로 다른 소프트웨어 애플리케이션들을 유지보수하는 것을 책임진다. 예를 들면, 하나의 엔티티는 사용자 요청들을 수신하는 웹 서버 애플리케이션을 유지보수할 수도 있는 반면, 다른 엔티티는 백엔드 데이터베이스(backend database)를 유지보수할 수도 있다. 웹 서버나 백엔드 데이터베이스에서 문제(예컨대, 느린 실행)가 발생하고 있는지 여부를 사용자가 빠르게 알아낼 수 있어서 적절한 엔티티가 접속될 수 있도록 하는 것이 유용할 수 있다.
본 명세서에서 개시된 하나의 실시예는 디스플레이 스크린 상에 의존도 맵을 디스플레이하기 위한 기계로 구현되는(machine-implemented) 방법을 포함한다. 상기 방법은 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도(dependencies)를 기술하는 데이터를 수집하는 것과, 상기 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프(directed graph)를 형성하기 위해 상기 데이터를 종합(aggregate)하는 것과, 그리고 상기 방향 그래프에 의거하여 디스플레이 스크린상에 의존도 맵(dependency map)을 디스플레이하는 것을 포함하며, 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 의존도를 보여준다.
본 명세서에서 개시된 하나의 실시예는 하나 이상의 프로세서들과, 상기 하나 이상의 프로세서들에 연결되는 컴퓨터 판독가능한 저장 장치를 가지는 시스템을 포함한다. 상기 컴퓨터 판독가능한 저장 장치는 그 상에 컴퓨터 판독가능한 명령어들을 가질 수 있으며, 이들은 상기 하나 이상의 프로세서들 상에서 실행될 때 상기 하나 이상의 프로세서들로 하여금 상기 시스템의 소프트웨어 컴포넌트들에 의해 처리되는 트랜잭션들의 트레이스(trace)를 시작하고, 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 수집하고, 상기 트랜잭션들이 처리될 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프를 형성하기 위해 상기 의존도를 기술하는 데이터를 종합하며, 그리고 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들 또는 상기 소프트웨어 컴포넌트들이 존재하는 애플리케이션들 중 어느 하나의 의존도를 기술하는 상기 방향 그래프에 의거하여 의존도 맵을 디스플레이하게 한다.
본 명세서에서 개시된 하나의 실시예는 방법을 수행하도록 적어도 하나의 프로세서를 프로그램하기 위해 그 상에 컴퓨터 판독가능한 명령어들이 저장된 컴퓨터 판독가능한 저장 장치를 포함하며, 상기 방법은 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 수집하는 것과, 상기 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프를 형성하기 위해 상기 데이터를 종합하는 것과, 그리고 상기 방향 그래프에 의거하여 디스플레이 스크린상에 의존도 맵을 디스플레이하는 것을 포함하며, 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들의 세트 또는 상기 소프트웨어 컴포넌트들이 존재하는 애플리케이션들의 세트 중 어느 하나의 의존도를 보여준다.
도 1은 관리되는 애플리케이션을 포함하는 시스템을 도시한 것이다.
도 2, 도 3, 및 도 4는 디스플레이 스크린 상에 제시될 수 있는 의존도 맵(dependency map)들의 예들을 도시한 것이다.
도 5a는 도 1의 네트워크에서 사용될 수 있는 컴퓨터 시스템의 한 실시예를 도시한 것이다.
도 5b는 애플리케이션들을 모니터링하는 절차의 실시예의 순서도를 예시한 것이다.
도 6은 다이그래프(digraph)를 기반으로 의존도 맵을 디스플레이하기 위한 절차의 한 실시예를 나타내는 순서도이다.
도 7은 의존도 데이터(dependency data)를 수집하는 절차의 한 실시예를 도시하는 순서도이다.
도 8은 다이그래프 데이터 구조의 한 실시예의 블록도이다.
도 9는 다이그래프를 생성할 때 에지(edge)들을 처리하는 한 실시예를 도시하는 순서도이다.
도 10a 및 10b는 다이그래프를 생성할 때 정점들(vertices)을 처리하는 한 실시예의 순서도를 도시한 것이다.
도 11은 의존도 데이터의 나이(age)에 의거하여 디스플레이할 다이그래프를 수정하기 위한 절차의 한 실시예를 나타내는 순서도이다.
본 명세서에서는 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 발생시킬 뿐만 아니라, 상기 데이터에 의거하여 의존도 맵들을 디스플레이하기 위한 기법들이 개시된다. 상기 데이터는 상기 소프트웨어 컴포넌트들에 의해 처리되는 트랜잭션들을 모니터링 또는 트레이스하는 에이전트들에 의해 수집될 수 있다. 상기 수집된 데이터는 상기 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 방향 그래프를 형성하기 위해 종합될 수 있다. 상기 방향 그래프에 의거하여 의존도 맵이 디스플레이될 수 있다. 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들 사이의 의존도를 보여줄 수 있다. 상기 의존도 맵은 또한 상기 소프트웨어 컴포넌트들을 포함하는 애플리케이션들 사이의 의존도를 보여줄 수 있다. 상기 의존도 맵(들)은 사용자로 하여금 어디서 문제가 발생하는지를 쉽고도 신속하게 확인할 수 있게 해준다. 예를 들면, 사용자는 문제가 프런트엔드에 있는 애플리케이션 서버에 있는 것이 아니라 백엔드 데이터베이스에 있는지를 신속히 판별할 수 있다.
도 1은 서로 다른 컴퓨터 시스템들이 데이터를 관리자(manager)로 제공하는 네트워크(100)를 도시한 것이다. 예시적인 컴퓨터 시스템들은 원하는 기능들을 달성하기 위해 코드를 실행하기 위한 프로세서를 가지는 애플리케이션 서버들(110a, 110b) 또는 임의의 다른 유형의 컴퓨터 시스템을 포함할 수 있다. 애플리케이션 서버들(110)은 서로 다른 애플리케이션들을 실행할 수 있거나, 동일한 애플리케이션의 별개의 인스턴스(instance)들을 실행할 수 있다. 애플리케이션 서버들(110)은 서로로부터 원격으로 위치되거나 또는 같은 위치에 위치될 수 있다. 이 예에서, 애플리케이션 서버들(110)은 관리자 컴퓨터(120)와 통신한다. 관리자(Manager)(120)는 애플리케이션 서버들(110)로부터 로컬(local)이거나 원격(remote)일 수 있다.
예를 들면, 웹 기반의 전자상거래 애플리케이션과 같은 기업용 애플리케이션을 운영하는 기업은 부하 균형(load balancing)을 위해 하나의 위치에서 다수의 애플리케이션 서버들을 채용할 수 있다. 사용자들로부터의 요청들, 예컨대 사용자의 예시적인 웹 브라우저(102)로부터의 요청들이 인터넷과 같은 네트워크(104)를 통해서 수신되며, 애플리케이션 서버들(110) 중 임의의 것으로 라우트(route)될 수 있다. 웹 브라우저(102)는 전형적으로 인터넷 서비스 제공자(Internet Service Provider) (미도시됨)를 통해서 네트워크 클라우드(network cloud)(104)를 액세스한다.
애플리케이션 서버들(110a, 110b)은 관리되는 애플리케이션(managed application) A(151A) 및 관리되는 애플리케이션 B(151B)를 포함하며, 이들은 에이전트들(112A, 112B)과 예시적인 프로브들(probes)(153A, 153B)을 포함한다. 임의의 개수의 프로브들이 존재할 수 있다. 논의를 위해 참조 번호(예컨대, 애플리케이션 서버들(110a, 110b))에서 문자를 가지는 요소들 사이의 구별이 이루어진다. 본 명세서에서, "a" 또는 "b"가 없이 참조 번호들을 사용하는 것은 어떠한 특정 서버나 다른 요소들도 참조되고 있지 않는 것을 표시한다. 애플리케이션(151)은 자바(Java？) 애플리케이션 또는 다른 유형의 애플리케이션일 수 있다. 따라서, 하나의 가능한 접근법으로, 에이전트(Agent)(112)로 표시되는 애플리케이션 서버들(110) 상에서 실행되는 에이전트 소프트웨어는 애플리케이션 서버들(110) 상에서 실행되는 관리되는 애플리케이션(151), 미들웨어(middleware) 또는 다른 소프트웨어로부터 정보를 모은다. 예를 들면, 애플리케이션(151)으로부터의 정보는 또한 프로브들(153)을 이용하여 얻어질 수 있다. 실제로, 많은 그러한 프로브들이 애플리케이션(151)의 서로 다른 컴포넌트들에 관한 정보를 얻는 데 이용될 수 있다. 일부 실시예들에서, 프로브들이 인스트루멘테이션을 이용하여 애플리케이션(151)에 추가될 수 있으며, 인스트루멘테이션의 하나의 예는 바이트 코드 인스트루멘테이션(byte code instrumentation)이다. 하지만, 모인 데이터는 다른 방식들로도 역시 얻어질 수 있다. 에이전트들(112)은 본질적으로 모니터링되는 컴퓨터 시스템에 존재하며, 데이터 획득 포인트(data acquisition point)를 제공한다. 에이전트들은 관리자(120)로 전달되는 데이터를 조직화하고 최적화한다.
트랜잭션 흐름을 기술하는 목적에서, 트랜잭션들을 처리하는 소프트웨어 컴포넌트들이 관리되는 애플리케이션들(151)에 도시되어 있다. 소프트웨어 컴포넌트들은 관리되는 애플리케이션(151) 내의 임의의 코드 일부(예컨대, 모듈) 또는 관리되는 애플리케이션 외부의 임의의 코드 일부를 포함할 수 있다. 예를 들면, 관리되는 애플리케이션(151) 내의 소프트웨어 컴포넌트들은 서블릿(Servlet), POJO(plain old java object), EJB？(Enterprise JavaBeans？), 소켓 등을 포함할 수 있지만, 이에 한정되는 것은 아니다. 관리되는 애플리케이션(151) 외부의 소프트웨어 컴포넌트들은 관리되는 애플리케이션(151)과 상호 작용하는 것들을 포함할 수 있지만, 직접적인 상호 작용은 필수적이지 않다. 관리되는 애플리케이션(151) 외부의 소프트웨어 컴포넌트들은 데이터베이스, 웹 서비스, 웹 브라우저 등을 포함할 수 있지만, 이에 한정되는 것은 아니다.
3개의 트랜잭션이 도 1에 도시되어 있다. 하나의 예로서, 트랜잭션 BTA1은 웹 브라우저(102)로부터의 HTTP 요청에 응답하여 시작될 수 있다. 트랜잭션 BTA1에 대하여, 흐름은 모듈 A1으로부터 모듈 A2, 데이터베이스X(113)까지이다. 유의할 점은 실제로는 트랜잭션 BTA1에 수반되는 소프트웨어 컴포넌트들이 더욱 많이 있을 수 있다는 것이다. 하지만, 소프트웨어 컴포넌트들 모두가 사용자에게 관심의 대상인 것은 아닐 수 있다. 예를 들면, 모듈 A1과 모듈 A2 사이에 트랜잭션을 따라 하나 이상의 소프트웨어 컴포넌트들이 있을 수도 있다. 또한, 모듈 A2와 데이터베이스X(113) 사이에 트랜잭션을 따라 하나 이상의 소프트웨어 컴포넌트들이 있을 수도 있다. 예를 들면, 모듈 A2와 데이터베이스X(113) 사이에 소켓이 있을 수도 있다. 하지만, 소켓은 사용자에게 관심의 대상이 아닐 수도 있다. 트랜잭션 BTA2에 대하여, 흐름은 모듈 A3로부터 웹 서비스(109), 모듈 B1까지이다. 예를 들면, 만일 모듈 B1으로부터 데이터베이스Y(114)까지의 흐름이 모듈 A3로부터 모듈 B1까지의 호출에 의해 야기되면, 그 흐름은 또한 트랜잭션 BTA2의 일부인 것으로 고려될 수 있다. 트랜잭션 BTA2는 애플리케이션 B에 대하여 트랜잭션 BTB1을 발생시킨다. 구체적으로, 트랜잭션 BTB1에 대한 흐름은 모듈 B1으로부터 데이터베이스Y(114)까지이다.
논의를 위해, 트랜잭션 BTA1은 "구매 트랜잭션(Buy Transaction)"일 수도 있으며, 이는 (웹 브라우저(102)에서) 사용자로 하여금 책이나 일부 다른 아이템을 살 수 있게 한다. 논의를 위해, 트랜잭션 BTA2는 "신용 조회 트랜잭션(Check Credit Transaction)"일 수도 있으며, 이는 책 구입을 위한 신용 카드의 사용을 인가한다. 유의할 점은 시간이 지나면서 서로 다른 사용자들이 웹 사이트를 방문함에 따라 트랜잭션 BTA의 서로 다른 인스턴스들이 많이 있을 수 있다는 것이다. 따라서, 트랜잭션 BTA1은 한 "유형의 트랜잭션(type of transaction)"으로 지칭될 수 있으며, 이에 대해 많은 인스턴스들이 있을 수 있다.
일부 실시예들에서, 에이전트들(112)은 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들 사이에 의존도를 기술하는 데이터를 수집하고 그 데이터를 관리자(120)로 공급한다. 관리자(120)는 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 소프트웨어 컴포넌트들 사이에 의존도를 나타내는 방향 그래프(directed graph, "다이그래프(digraph)")를 형성하기 위해서 그 데이터를 종합(aggregate)할 수 있다. 예를 들면, 다이그래프는 컴포넌트들을 나타내는 정점(vertex)들과 컴포넌트들 사이에 의존도를 나타내는 에지(edge)들을 가질 수 있다. 그런 다음, 의존도 맵(dependency map)이 다이그래프에 의거하여 사용자 인터페이스(122)와 같은 디스플레이 스크린 상에 디스플레이될 수 있다. 의존도 맵은 트랜잭션들이 처리될 때 의존도를 보여준다. 의존도 맵은 다양한 레벨의 세부사항을 가질 수 있다. 예를 들면, 의존도 맵은 소프트웨어 컴포넌트들 사이에 의존도를 보여줄 수 있다. 하지만, 의존도 맵은 더욱 일반적일 수 있고 애플리케이션들(151) 사이의 의존도를 보여줄 수 있다(아마도 소프트웨어 컴포넌트들은 전혀 보여주지 않을 수 있다). 예시적인 목적으로 몇몇의 예시적인 의존도 맵들은 다음과 같다. 이들 맵은 도 1의 시스템(100)에 의해 처리되는 예시적인 트랜잭션들에 해당한다.
도 2는 (사용자 인터페이스(122)와 같은) 디스플레이 스크린 상에 제시될 수 있는 의존도 맵(200a)의 한 예를 도시한 것이다. 예시적인 의존도 맵(200a)은 트랜잭션들을 처리할 때 시스템(100)의 소프트웨어 컴포넌트들 사이의 의존도를 보여줄 수 있다. 이 예에서, 의존도 맵(200a)은 애플리케이션 A에 의해 처리되는 트랜잭션들에 관한 것이다. 이 의존도 맵(200a)은 관리되는 애플리케이션 A(151A)에 대한 상세한 의존도 맵을 위한 사용자 요청에 응답하여 디스플레이될 수 있다. 트랜잭션들 BTA1과 BTA2는 관리되는 애플리케이션 A의 의존도 맵의 일부인 것으로 여겨질 수 있다. 양 트랜잭션들이 애플리케이션 A에 대한 하나의 의존도 맵을 형성하도록 함께 조합될 수 있다. 예를 들면, 모듈 A1, 모듈 A2, 및 데이터베이스X(113) 사이의 종속성은 이 컴포넌트들을 연결하는 화살표들에 의해 제시된다. 유의할 점은 이것이 트랜잭션 BTA1에 해당한다는 것이다. 모듈 A3, 웹 서비스(109), 모듈 B1, 및 데이터베이스Y(114) 사이의 의존도는 이 요소들을 연결하는 화살표들에 의해 제시된다. 유의할 점은 이것이 트랜잭션 BTA2에 해당한다는 것이다. 또 다른 가능성은 사용자가 애플리케이션 A에 대한 세부사항들만을 요청했기 때문에 관리되는 애플리케이션 B(151b)에 대해서는 세부사항들을 더 적게 보여주는 것이다. 예를 들면, 모듈 B1 및/또는 데이터베이스Y(114)는 도시되지 않을 수도 있다. 그 대신에, 단지 웹 서비스(109)로부터 관리되는 애플리케이션 B(151b)로의 화살표만이 있을 수 있다.
의존도 맵(200)은 정점들과 에지들을 포함할 수 있다. 정점은 소프트웨어 컴포넌트에 해당할 수 있다. 예를 들면, 도 2에서, 정점들은 "외부 정점(external vertex)", 모듈 A1, 모듈 A2, 모듈 A3, 데이터베이스X, 웹 서비스, 모듈 B1, 및 데이터베이스Y일 수 있다. 유의할 점은 일부 경우에 관리되는 애플리케이션 A와 관리되는 애플리케이션 B가 정점일 수 있다는 것이다. 또한 유의할 점은 "외부 정점"이라는 용어는 애플리케이션 서버 외부에 있는 한 유형의 정점을 지칭하는 데 사용되고 있다는 것이다. 이 경우에, 외부 정점은 HTTP 요청을 관리되는 애플리케이션 A(151A)로 송신하는 일부 소프트웨어 컴포넌트를 나타낸다. 유의할 점은 사용자는 정확히 어느 소프트웨어 컴포넌트가 HTTP 요청을 송신했는지에 대해서는 관심이 없을 수도 있다는 것이다. 그러므로, "외부 정점"라는 일반 용어를 사용하는 것은 충분한 설명을 제공할 수 있다.
몇 개의 에지들(251a-251f)이 도 2에 표시되어 있다. 에지는 한 쌍의 소프트웨어 컴포넌트들 사이의 의존도를 나타낸다. 일반적으로, 에지는 2개의 소프트웨어 컴포넌트들의 순서쌍(ordered pair)으로서 기술될 수 있다. 에지들은 도 2에서 화살표들로서 나타내어 진다. 화살표의 머리(head)와 꼬리(tail)는 상기 순서쌍에서 소프트웨어 컴포넌트들의 순서를 정의하는 데 사용될 수 있다. 예를 들면, 에지(251a)는 (모듈 A1, 모듈 A2)로서 기술될 수 있다. 에지(251b)는 (모듈 A2, 데이터베이스X)로서 기술될 수 있다.
한 실시예에서, 의존도 맵(200)은 도 2에서 보여주는 것보다 상위 레벨의 요약(summary)을 포함할 수 있다. 만일 많은 수의 애플리케이션들 및/또는 소프트웨어 컴포넌트들이 있다면 애플리케이션의 보다 상세한 뷰(view)는 복잡해질 수 있다. 도 3은 디스플레이 스크린 상에 제시될 수 있는 요약 의존도 맵(200b)을 도시한 것이다. 이 예는 도 2의 예보다 상위 레벨의 요약이며 애플리케이션 A에 대한 요약이다. 이 예에서, 관리되는 애플리케이션 A(151a), 관리되는 애플리케이션 B(151b), 데이터베이스X(113), 및 데이터베이스Y(114) 사이의 의존도가 트랜잭션들 BTA1과 BTA2에 대하여 도시되어 있다. 유의할 점은 관리되는 애플리케이션들(151) 내의 소프트웨어 컴포넌트들은 도시되어 있지 않다는 것이다. 하지만, 의존도 맵(200b)은 에이전트들(112)에 의해 수집된 데이터로서 도 2의 의존도 맵(200a)에 사용된 것과 동일한 데이터로부터 발생되었을 수 있다.
의존도 맵(200)은 또한 앞의 예에서와 같은 관리되는 애플리케이션 대신에, 일정한 트랜잭션에 관한 것일 수 있다. 도 4는 트랜잭션 BTA1에 대한 요약을 보여주는 한 예를 도시한 것이다. 이러한 의존도 맵(200c)은 트랜잭션 BTA1에 대한 의존도 맵을 위한 사용자 요청에 응답하여 제시될 수 있다. 비즈니스 트랜잭션들의 요약 뷰가 트랜잭션들의 흐름을 디스플레이한다. 이 예에서, 트랜잭션 BTA1의 일부인 에지들만이 강조하여 표시되어 있다(굵은 실선 화살표). 다른 에지들은 트랜잭션 BTA1의 일부가 아님을 표시하도록 점선으로 되어 있다. 예를 들면, 에지들 (애플리케이션 A, 웹서비스)와 (웹서비스, 애플리케이션 B)는 BTA1의 일부가 아니지만, 그것들은 그래도 디스플레이되어 있으며 하지만 강조하여 표시되어 있지는 않다. 에지들 (BTA1, 애플리케이션 A)와 (애플리케이션 A, 데이터베이스X)는 BTA1의 일부이므로 강조하여 표시되어 있다. 애플리케이션 B는 BTA1의 일부가 아니기 때문에, 에지 (애플리케이션 B, 데이터베이스X)는 디스플레이되지 않는다.
BTA2와 같은 다른 트랜잭션들의 요약 뷰도 또한 디스플레이될 수 있다. 또 다른 가능성은 비즈니스 서비스(Business Service)에 대한 의존도 맵(200)을 디스플레이하는 것이며, 이는 공통의 공유된 목적을 달성하기 위하여 서로 상호작용하는 몇 개의 트랜잭션들로 구성될 수 있다. 하나의 예로서, BTA1과 BTA2는 동일한 비즈니스 서비스의 일부일 수 있다. 비즈니스 서비스의 요약은 BTA1과 BTA2에 포함되는 모든 정점들과 에지들의 유니온(union)일 수 있다.
도 1에 대한 논의로 다시 돌아가서, 한 실시예에서, 프로브들(153) 및 추가적인 코드를 추가하기 위해 프로브 빌더(도 1에 미도시됨)는 관리되는 애플리케이션들(151)에 대한 바이트코드를 인스트루멘트(instrumnet)(예컨대, 수정(modify))한다. 프로브들(153)은 애플리케이션들의 비즈니스 로직을 변경함이 없이 관리되는 애플리케이션들(151)에 관한 정보의 특정 일부를 측정할 수 있다. 한 유형의 프로브는 컴포넌트가 실행에 소비한 시간의 양을 측정한다. 시간의 양은 프로브를 가지는 컴포넌트에 의해 호출되는 컴포넌트들에 의한 실행에 소비된 시간을 포함할 수 있지만, 그것이 필수적인 것은 아니다. 프로브(153)는 컴포넌트의 엔트리 포인트(entry point)에서 시작 포인트(begin point)를 가지고 컴포넌트의 각각의 출구(exit)에서 종료 포인트(end point)를 가질 수 있다. 한 실시예에서, 시작 포인트는 타이머를 시작하고 종료 포인트는 타이머를 중지한다. 프로브(153)는 타이밍 정보 외의 다른 정보를 수집할 수 있다.
프로브 빌더는 또한 애플리케이션들(151)과 동일한 기계 또는 별개의 기계 상에 인스톨(install)될 수 있는 에이전트(112)를 부가할 수 있다. 일단 프로브들(153)이 애플리케이션(151)에 인스톨되었다면, 또는 그렇지 않고 모니터링 능력이 제공되었다면, 애플리케이션은 관리되는 애플리케이션으로 지칭된다. 바이트코드를 계측하는 것에 대한 추가적인 정보는 명칭을 "System For Modifying Object Oriented Code"로 하는 Lewis K. Cirne에 의한 미국 특허 제6,260,187호와, 2001년 2월 28일에 출원된 명칭을 "Adding Functionality To Existing Code At Exits"로 하는 미국 특허 출원 제09/795,901호 찾을 수 있으며, 상기 특허 문헌 각각은 본 명세서에서 그 전체가 참조로서 포함된다.
관리되는 애플리케이션(151)이 실행됨에 따라, 프로브들(153)은 데이터를 에이젠트(112)로 송신한다. 예를 들면, 프로브들로부터의 정보는 트랜잭션이나 다른 실행 흐름의 시작 및 중지 시간, 또는 트랜잭션/실행 흐름 내의 개별 컴포넌트들의 시작 및 중지 시간과 같은 성능 데이터를 표시할 수 있다. 한 실시예에서, 프로브들(153)은 데이터를 기록하거나, 데이터를 변경하거나, 또는 그렇지 않고 애플리케이션 서버의 상태가 변하게 하는 객체들(objects) 및 다른 코드로 구현될 수 있다. 이 데이터는 애플리케이션 런타임 데이터(application runtime data)라고 지칭될 수 있다. 에이전트(122)는 또한 트랜잭션들이 처리됨에 따라 컴포넌트들 사이의 의존도를 기술하는 의존도 데이터를 수집할 수 있다. 그런 다음, 에이전트(112)는 애플리케이션 런타임 데이터 및 의존도 데이터를 수집, 요약하고 관리자(120)로 송신한다. 그에 응답하여, 관리자(120)는 요청된 계산들을 실행하고, 애플리케이션 런타임 데이터를 사용자 인터페이스(112)에게 이용가능하도록 만들고, 그리고 선택에 따라서는 애플리케이션 런타임 데이터를 나중의 분석을 위해 데이터베이스(118)로 송신한다. 관리자(120)는 또한 다이그래프를 형성하고 그 다이그래프에 의거하여 하나 이상의 의존도 맵들을 디스플레이하기 위해 의존도 데이터를 종합한다. 프로브들을 사용하여 애플리케이션을 모니터링하는 것에 관한 추가 정보는 2004년 4월 22일에 공개된 명칭을 "User Interface For Viewing Performance Information About Transactions"로 하는 Lewis K. Cirne에 의한 미국 특허 출원 공개 제2004/0075690호에서 찾을 수 있으며, 상기 문헌은 본 명세서에서 그 전체가 참조로서 포함된다.
에이전트들로부터 수신된 데이터에 의거하여 정보를 디스플레이하기 위해, 관리자(120)는 모니터와 같은 사용자 인터페이스(122)와 통신하는 워크스테이션과 같은 별도의 컴퓨터 시스템 상에 제공될 수 있다. 관리자(120)는 또한 상기 에이전트들로부터 수신된 데이터를 저장하기 위해 데이터베이스(118)를 액세스할 수 있다. 제공된 예에서, 애플리케이션 서버들은 네트워크(104)를 액세스하지 않고 관리자(120)와 통신할 수 있다. 예를 들면, 통신은 로컬 영역 네트워크(local area network)를 통해 일어날 수 있다. 다른 설계에서, 관리자(120)는 네트워크(104)를 통해 다수의 애플리케이션 서버들의 에이전트들로부터 데이터를 수신할 수 있다. 예를 들면, 일부 큰 기관들은 중앙 네트워크 운영 센터(central network operations center)를 채용하는데, 이 경우에 하나 이상의 관리자들이 서로 다른 지리적 위치들에 있는 다수의 분산된 에이전트들로부터 데이터를 얻는다. 예시를 위해, 웹-기반 전자상거래(e-commerce) 기업은 소비자 주문들을 수신하는 서로 다른 지리적 위치들에 있는 서버들로부터, 결제를 처리하는 서버들로부터, 재고를 조사하고 주문들을 나르기 위한 웨어하우스들에 있는 서버들로부터, 및 기타 서버들로부터 에이전트 데이터를 얻을 수 있다. 관리자(120)와 사용자 인터페이스 디스플레이(122)는 기업 본사의 위치에 제공될 수 있다. 다른 애플리케이션들이 마찬가지로 그들의 시스템들을 관리하기 위해 에이전트들과 관리자들을 채용할 수 있으며, 이들은 반드시 웹-기반인 것은 아니며 또는 소매나 다른 판매를 수반한다. 예를 들면, 은행은 수표와 신용 계좌를 처리하기 위한 애플리케이션을 사용할 수 있다. 게다가, 언급된 멀티-컴퓨터(multi-computer) 시스템 배치 이외에도, 단일의 컴퓨터 시스템이 또한 하나 이상의 에이전트들을 사용하여 모니터링될 수 있다.
도 5a는 도 1의 네트워크에서 사용될 수 있는 컴퓨터 시스템의 한 실시예를 도시한 것이다. 컴퓨터 시스템(500)은 도 1과 관련하여 논의된 바와 같이 웹 브라우저(102), (애플리케이션 서버들(110)과 같은) 호스트, 관리자(120) 및/또는 사용자 인터페이스(122)로서 사용될 수 있는 시스템의 간략화된 표현이다. 컴퓨터 시스템(500)은 하드 디스크나 휴대용 매체와 같은 저장 장치(510), 다른 컴퓨터 시스템들과 통신을 위한 네트워크 인터페이스(520), 소프트웨어 명령어들을 실행하기 위한 프로세서(530), 소프트웨어 명령어들이 예를 들어 저장 장치(510)로부터 로드된 후 소프트웨어 명령어들을 저장하기 위한 RAM과 같은 작업 메모리(510), 그리고 사용자 인터페이스 디스플레이(550)를 포함한다. 저장 장치(510)는 본 명세서에서 논의되는 기능들을 제공하기 위한 방법들을 수행하도록 프로세서(530)를 프로그래밍하기 위해 프로세서 판독가능한 코드가 수록된 프로세서 판독가능한 저장 장치로 여겨질 수 있다. 사용자 인터페이스 디스플레이(550)는 하나 이상의 에이전트들로부터 수신되는 데이터에 의거하여 사람인 운용자에게 정보를 제공할 수 있다. 사용자 인터페이스 디스플레이(550)는 그래픽 방식, 테이블 방식 등이건 임의의 알려진 디스플레이 방식을 사용할 수 있다. 온-스크린(on-screen) 디스플레이 이외에도, 프린터로부터의 하드 카피(hard copy)와 같은 출력이 제공될 수 있다.
또한, 본 명세서에서 서술된 기능들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어 모두의 조합을 사용하여 구현될 수 있다. 소프트웨어에 대해서는, 하나 이상의 프로세서들을 프로그래밍하기 위해 프로세서 판독가능한 코드가 저장된 하나 이상의 프로세서 판독가능한 저장 장치들이 사용될 수 있다. 프로세서 판독가능한 저장 장치들은 휘발성 및 비휘발성 매체, 착탈형(removable) 및 비-착탈형(non-removable) 매체와 같은 컴퓨터 판독가능한 저장 장치를 포함할 수 있다. 예를 들면, 컴퓨터 판독가능한 저장 장치는 컴퓨터 판독가능한 명령어들, 데이터 구조들, 프로그램 모듈들, 또는 다른 데이터와 같은 정보의 저장을 위해 임의의 방법이나 기술로 구현되는 휘발성 및 비휘발성 매체, 착탈형 및 비-착탈형 매체를 포함할 수 있다. 컴퓨터 판독가능한 저장 장치의 예들은 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 저장 장치, 자기 카세트(magnetic cassetts), 자기 테이프, 자기 디스크 저장 장치 또는 다른 자기 저장 장치들, 또는 원하는 정보를 저장하는 데 사용될 수 있으며 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함한다. 대체가능한 실시예들에서, 소프트웨어의 일부 또는 전부는 커스텀(custom) 집적 회로, 게이트 어레이들, FPGA, PLD 및 특수 용도 프로세서들을 포함하여 전용 하드웨어로 대체될 수 있다. 한 실시예에서, 하나 이상의 실시예들을 구현하는 소프트웨어(저장 장치 상에 저장된)가 하나 이상의 프로세서들을 프로그램하는 데 사용된다. 하나 이상의 프로세서들은 하나 이상의 컴퓨터 판독가능한 저장 장치들, 주변 장치들, 및/또는 통신 인터페이스들과 통신할 수 있다.
일부 실시예들에서, 에이전트(112)는 애플리케이션들(151)을 모니터링하고 애플리케이션 런타임 데이터를 관리자(120)로 전송하며, 이 경우에 데이터가 분석되어 사용자에게 리포트된다. 도 5b는 애플리케이션들(151)을 모니터링하는 절차의 한 실시예의 순서도를 예시한 것이다. 절차는 도 1의 예시적인 시스템(100)에서 수행될 수도 있다. 단계(502)에서, 애플리케이션(151)이 에이전트들(152)에 의해 모니터링된다. 모니터링하는 것은 애플리케이션 서버(110)의 어느 트랜잭션들이 처리되는지와 애플리케이션이 클라이언트 요청을 처리할 때에 그들이 호출되는 기간을 에이전트들(112) 결정하는 것을 수반할 수 있다. 또한, 모니터링하는 것은 컴포넌트들이 트랜잭션들을 처리할 때 에이전트들(112)이 의존도 데이터를 판별하는 것을 수반할 수 있다. 의존도 데이터의 일부 예들이 아래에서 논의된다. 단계(502)는 애플리케이션(151)에서 데이터를 수집하기 위해 실행되는 프로브들을 포함할 수 있다.
단계(504)에서, 애플리케이션의 모니터링에 의거하여 애플리케이션 런타임 데이터가 발생된다. 발생된 애플리케이션 런타임 데이터는 요청을 처리하는 데 수반되는 애플리케이션 컴포넌트들, 요청을 처리함에 있어 각각의 컴포넌트가 소비한 기간, 그리고 다른 정보를 가리킬 수 있다. 애플리케이션 런타임 데이터는 프로브들의 실행으로부터 발생하는 데이터에 의거하여 에이전트(112)에 의해 발생될 수 있으며, 그 후에 에이전트(112)는 발생된 애플리케이션 런타임 데이터를 관리자(120)로 전달할 수 있다. 일반적으로, 애플리케이션 런타임 데이터는 평균 컴포넌트(예컨대, 메쏘드(method)) 실행 시간, 초당 또는 구간당 컴포넌트 호출 비율, 컴포넌트 호출의 총수, 구간당 시작하였지만 종료하지 않은 컴포넌트 호출들의 개수를 표시하는 컨커런시 메트릭(concurrency metric), 그리고 구간당 시작하였으며 그 컴포넌트 호출 횟수가 특정 임계값을 초과한 컴포넌트 호출 횟수를 표시하는 스톨 메트릭(stalled metric)과 같은 정보를 포함할 수 있다. 또한, 애플리케이션 런타임 데이터는 가비지 콜렉션 히프 크기(garbage collection heap size), 파일 및 소켓의 활동을 표시하는 대역폭 메트릭(bandwidth metric), 쓰레드들의 개수, 시스템 로그들, 예외들(exceptions), 메모리 누설(memory leaks), 컴포넌트 상호작용(component interactions)을 식별할 수 있다. 유의할 점은 애플리케이션 런타임 데이터는 관리되는 애플리케이션(151)에 의해 처리되고 있는 특정한 트랜잭션에 링크(link)될 수 있다는 것이다.
단계(506)에서 애플리케이션 런타임 데이터는 예컨대 데이터를 종합하고(aggregate), 데이터를 저장하고, 소정의 인터페이스나 다른 사용자 인터페이스(112)를 통하여 데이터를 운용자에게 제공함으로써 관리자(120)에 의해 처리되고 리포트될 수 있다.
도 6은 다이그래프(digraph)에 의거하여 의존도 맵(200)을 디스플레이하기 위한 절차(600)의 한 실시예를 도시한 순서도이다. 절차(600)는 시스템(100)과 같은 시스템에서 이용될 수 있다. 도 2 내지 도 4는 절차(600)를 이용하여 디스플레이될 수 있는 몇몇 예시적인 의존도 맵들(200)을 보여준다. 단계(602)에서, 의존도 데이터가 수집된다. 의존도 데이터는 에이전트들(112)에 의해 수집될 수 있다. 한 실시예에서, 의존도 데이터는 소프트웨어 컴포넌트들을 기술하는 정점 데이터와 소프트웨어 컴포넌트들 간의 의존도를 기술하는 에지 데이터를 포함한다.
유의할 점은 의존도 데이터는 관리되는 애플리케이션(151)(예컨대, 관리되는 애플리케이션 A(151A))의 많은 서로 다른 인스턴스들에 대한 데이터를 포함할 수 있다는 것이다. 예를 들면, 시스템(100)은 관리되는 애플리케이션 A(151A)의 서로 다른 인스턴스를 각각 실행하는 다수의 서버들을 가질 수 있다. 일부 경우들에서, 단일의 서버가 관리되는 애플리케이션 A(151A)의 서로 다른 인스턴스들을 실행할 수도 있다. 유사한 방안들이 관리되는 애플리케이션 B(151B)에 적용될 수 있다. 또한, 유의할 점은 특정한 유형의 트랜잭션에 대해 서로 다른 인스턴스들이 많이 존재할 수 있다는 것이다. 전술된 바와 같이, 트랜잭션 BTA1의 서로 다른 인스턴스들이 많이 있을 수 있으며, 이는 구입을 하는 서로 다른 사용자들에 해당할 수 있다. 따라서, 의존도 데이터는 각각의 유형의 트랜잭션의 많은 서로 다른 인스턴스들에 대한 데이터를 포함할 수 있다. 단계(602)의 한 실시예의 보다 세부사항들이 아래에서 논의된다.
단계(604)에서, 트랜잭션들을 처리하는 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프를 형성하기 위해 의존도 데이터가 종합(aggregate)된다. 일부 실시예들에서, 방향 그래프는 다양한 소프트웨어 컴포넌트들(예컨대, 서블릿, EJB, 장치 드라이버들, DBMS, 소켓들 등)에 해당하는 정점들 뿐만 아니라 소프트웨어 컴포넌트들의 쌍들 사이의 에지들을 포함한다. 의존도 데이터를 종합하는 것은 의존도 데이터에서 중복 정점들(duplicate vertices)을 찾는 것과 소프트웨어 컴포넌트들에 대하여 중복 데이터를 나타내는 단일의 "논리적 정점(logical vertex)"을 발생시키는 것을 포함할 수 있다. 마찬가지로, 의존도 데이터를 종합하는 것은 의존도 데이터에서 중복 에지들을 찾는 것과 소프트웨어 컴포넌트들 사이의 의존도에 대하여 중복 데이터를 나타내는 단일의 "논리적 에지(logical vertex)"를 발생시키는 것을 포함할 수 있다. 단계(604)의 한 실시예의 보다 세부사항들이 아래에서 논의될 것이다.
단계(606)에서, 방향 그래프에 의거하여 의존도 맵(200)이 디스플레이된다. 다수의 예들이 도 2 내지 도 4에 도시되어 있다. 유의할 점은 의존도 맵(200)은 방향 그래프의 복잡도를 어느 정도 감소시킬 수 있다는 것이다. 예를 들면, 방향 그래프의 모든 정점들이 의존도 맵(200)에 디스플레이될 필요는 없다. 마찬가지로, 방향 그래프의 모든 에지들이 의존도 맵(200)에 디스플레이될 필요는 없다. 특정한 예로서, 관리되는 애플리케이션(151)의 요약은 관리되는 애플리케이션들(151)의 내부에 있는 컴포넌트들을 보여주지 않고 디스플레이될 수 있다.
도 7은 의존도 데이터를 수집하는 절차(700)의 한 실시예를 도시한 순서도이다. 절차(700)는 절차(600)의 단계(602)의 한 실시예이다. 단계(702)에서, 트랜잭션 트레이스가 시작된다. 한 실시예에서, 일정한 소프트웨어 컴포넌트들이 트랜잭션 호출 스택(transaction call stack)의 첫번째 요소로 식별될 때 트랜잭션 트레이스가 시작한다. 이들 소프트웨어 컴포넌트들은 일정한 시점에서 관심의 대상으로서 식별된 것들일 수 있다. 일부 실시예들에서, 트랜잭션 트레이스는 트랜잭션의 경계선들을 캡처(capture)한다. 경계선의 하부 한계(lower limit)는 호출 스택의 첫번째 관심 요소에 의해 정의될 수 있다. 하나의 예로서, 관심 요소는 관심의 대상으로 여겨지는 유형의 컴포넌트, 예컨대 서블릿을 특정함으로써 미리 정의될 수 있다. 한 실시예에서, 상부 경계선은 JVM(Java Virtual Machine) 외부에 있는 트랜잭션 호출들에 의해 제어될 수 있다. 스택의 하부 경계선은 프론트엔드(Frontend)라는 용어로 지칭될 수 있는 반면, 상부 경계선은 백엔드(Backend)라는 용어로 지칭될 수 있다. 하나의 예로서 도 1를 참조하면, 모듈 A1이 프론트엔드일 수도 있고 모듈 A2가 백엔드일 수도 있다.
단계(704)에서, 하나 이상의 에이전트들(112)이 트랜잭션을 처리하는 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 의존도 데이터를 수집한다. 예를 들면, 의존도 데이터는 프론트엔드와 백엔드 사이의 에지를 포함할 수 있다. 도 1의 트랜잭션 BTA1을 참조하면, 모듈 A1과 모듈 A2 사이의 화살표가 이러한 에지가 될 수 있다. 또한, 외부 엔티티(external entity)와 프론트엔드 정점(Frontend vertex) 사이에서 시작 에지(starting edge)가 생성될 수 있다. 도 1을 참조하면, 네트워크(104)(또는 웹 브라우저(102))가 외부 정점으로 고려될 수 있다. 네트워크(104)를 "외부 정점"으로 지칭하는 이유들 중 하나는 이것이 애플리케이션 서버(110a) 상의 가상 머신(예컨대, JVM)의 외부에 있을 수 있기 때문이다. 따라서, 시작 에지는 네트워크(104)와 모듈 A1 사이에 있을 것이다. 또한, 모듈 A2와 데이터베이스X(113) 사이에 에지가 있을 수 있다. 유의할 점은 하나 이상의 에이전트가 단일의 트랜잭션에 대한 의존도 데이터를 수집할 수 있다는 것이다. 예를 들면, 에이전트들(112a, 112b)은 모두 트랜잭션 BTA2에 대한 데이터를 수집할 수 있다.
단계(706)에서, 에이전트(112)는 의존도 데이터가 관리자(120)로 제공되어야 하는지 여부를 판별한다. 의존도 데이터는 언제든지 그리고 임의의 빈도로 제공될 수 있다. 의존도 데이터는 관리자(120)로부터의 요청에 응답하여 또는 요청 없이도 제공될 수 있다. 만일 의존도 데이터가 관리자(120)로 제공되지 않는다면, 절차(700)는 또 다른 트랜잭션의 트레이스를 시작하기 위해 단계(702)로 되돌아간다. 또 다른 트랜잭션을 트레이스하는 것은 트랜잭션 BTA1의 서로 다른 인스턴스를 트레이스하는 것일 수 있으며, 또는 서로 다른 유형의 트랜잭션(예컨대, BTA2)을 트레이스하는 것일 수 있다.
일정한 지점에서, 의존도 데이터는 에이전트(112)로부터 관리자(120)로 송신된다(단계(708)). 언급된 바와 같이, 의존도 데이터는 에지들과 정점들을 기술할 수 있다. 단계(710)에서, 관리자(120)는 의존도 데이터를 저장한다. 한 실시예에서, 관리자(120)는 도착 타임스탬프(arrival timestamp)를 의존도 데이터에 추가한다. 한 실시예에서, 에이전트(112)는 관리자(120)에게 송신하기에 앞서 수집 타임스탬프(collection timestamp)(예컨대, 의존도 데이터가 수집된 시간)를 데이터에 추가한다. 유의할 점은 관리자(120)가 많은 에이전트(112)들로부터 의존도 데이터를 수신할 수 있다는 것이다. 서로 다른 에이전트들(112)로부터의 이러한 데이터는 조합될 수 있다.
전술된 바와 같이, 에이전트들(112)은 의존도 데이터를 수집하고 이를 관리자(120)에게 송신할 수 있다. 표 1은 정점들을 위해 수집될 수 있는 의존도 데이터의 한 예를 도시한 것이다. 전술된 바와 같이, 정점들은 소프트웨어 컴포넌트들에 해당할 수 있다. 이 예에서, 각각의 정점은 "정점 속성들(vertex properties)"의 세트를 가진다.

정점 속성(Vertex Property)
설명

유형(type)
소프트웨어 컴포넌트의 유형. 예들에는 시작 노드(Starting Node), 서블릿, EJB 등이 포함되지만 이에 한정되는 것은 아니다. 사용자는 커스텀(custom) 유형을 생성할 수도 있다.

이름(Name)
소프트웨어 컴포넌트의 이름. 예들에는 클래스 이름, 인터페이스 이름, 클래스-메쏘드 이름, 데이터베이스, URL 등이 포함되지만 이에 한정되는 것은 아니다.

에이전트 이름(Agent Name)
소프트웨어 컴포넌트가 존재하는 에이전트의 이름(예컨대, 데이터를 수집하는 에이전트)

계층화 레벨(Hierarchy Level)
계층화는 클래스, 클래스-메쏘드 등일 수 있다. 이 속성은 정점들 사이의 부모자식 관계(parent child relationship)를 생성할 수 있다.

추상화 레벨(Abstraction Level)
일부 정점들은 외부(external)라고 표시될 수 있다.

업데이트 시간(Update Time)
정점이 마지막으로 업데이트된 시간.
유형 속성의 경우, 시작 노드는 트랜잭션의 시작에서의 컴포넌트일 수 있다. 시작 노드는 애플리케이션 서버(110)의 내부에 있을 수 있거나 서버(110)의 외부에 있을 수 있다. 애플리케이션 서버(110)의 외부에 있는 적어도 일부 컴포넌트들에게는 "외부 정점"이라는 추상화 레벨이 주어질 수 있다. 한 실시예에서, 외부로부터 관리되는 애플리케이션(151)을 호출하는 컴포넌트들은 "외부 정점들"이다. 하지만, 데이터베이스와 같이 백엔드에서의 외부 컴포넌트들은 외부 정점들로 고려될 필요가 없다.
표 2는 에지들에 대하여 수집될 수 있는 의존도 데이터의 유형들의 한 예를 도시한 것이다. 전술된 바와 같이, 에지 데이터는 트랜잭션들이 처리될 때 소프트웨어 컴포넌트들(또는 정점들) 사이의 의존도에 관한 것일 수 있다. 이 예에서, 각각의 에지는 "에지 속성들"의 세트를 가진다.

에지 속성(Vertex Property)
설명

머리 정점(Head Vertex)
끝부분에서의 정점(화살표의 머리가 가리키는).

꼬리 정점(Tail Vertex)
시작부분에서의 정점(화살표의 꼬리에 닿아있는).

소유자(Owner)
에지를 소유하는 애플리케이션이나 비즈니스 트랜잭션의 이름.

머리 소유자(Head Owner)
머리 정점/소프트웨어 컴포넌트를 소유하는 애플리케이션.

꼬리 소유자(Tail Owner)
꼬리 정점/소프트웨어 컴포넌트를 소유하는 애플리케이션.

업데이트 시간(Update Time)
에지를 마지막으로 마주쳤던 시간.
예시적인 에지 속성들에 관해 다음에서 상술한다. 도 1을 참조하면, 모듈 A1과 모듈 A2 사이의 에지는 다음과 같이 기술될 수 있다. 머리 정점은 모듈 A2일 수 있다. 꼬리 정점은 모듈 A1일 수 있다. 에지 소유자는 관리되는 애플리케이션 A (151A)일 수 있다. 머리 정점 소유자는 관리되는 애플리케이션 A(151A)일 수 있다. 꼬리 정점 소유자는 관리되는 애플리케이션 A(151A)일 수 있다.
또 다른 예로서, 모듈 A3와 웹 서버(109) 사이의 에지는 다음과 같이 기술될 수 있다. 머리 정점은 웹 서버(109)일 수 있다. 꼬리 정점은 모듈 A3일 수 있다. 에지 소유자, 머리 정점 소유자, 및 꼬리 정점 소유자는 모두 관리되는 애플리케이션 A(151A)일 수 있다.
또 다른 예로서, 웹 서비스(109)와 모듈 B1 사이의 에지는 다음과 같이 기술될 수 있다. 머리 정점은 모듈 B1일 수 있다. 꼬리 정점은 웹 서버(109)일 수 있다. 에지 소유자, 머리 정점 소유자, 및 꼬리 정점 소유자는 모두 관리되는 애플리케이션 B(151B)일 수 있다. 일부 실시예들에서, 이 에지에 대하여 제2 세트의 데이터가 형성될 수 있다. 제2 세트는 관리되는 애플리케이션 A(151A)를 에지 소유자 및 꼬리 정점 소유자로서 열거할 수 있으며, 관리되는 애플리케이션 A(151A)는 머리 정점 소유자일 수 있다. 이 에지에 대하여 이러한 제2 세트의 데이터를 두는 한가지 이유는 서로 다른 애플리케이션들(151)의 관점에서 의존도 맵(200)이 디스플레이될 수 있게 하는 것이다. 이 예에서, 관리되는 애플리케이션 A(151A)가 에지 소유자이었을 때의 에지 정보는 애플리케이션 A(151A)의 관점에서 의존도 맵(200)을 디스플레이할 때에 이용될 수도 있다. 유사한 추론이 관리되는 애플리케이션 B(151B)에 대해 의존도 맵(200)을 디스플레이하는 데 적용될 수 있다.
유의할 점은 에이전트(112)가 "외부 정점(external vertex)"과 같이 일부 컴포넌트들에 대하여 특별한 이름을 할당할 수 있다는 것이다. 예를 들면, 마지막 예에서, 웹 서비스(109) 소프트웨어 컴포넌트가 "외부 정점"으로 지칭될 수도 있다. 모듈 A1으로 요청을 송신하는 네트워크(104)(또는 웹 브라우저(102))도 또한 "외부 정점"이라고 불릴 수도 있다. 이런 명명 규칙(naming convention)을 사용하는 하나의 이유는 사용자에게는 애플리케이션(151)을 호출하는 실제 소프트웨어 컴포넌트가 관심의 대상이 아닐 수 있기 때문이다. 그러므로, "외부 정점"과 같은 보다 일반적인 용어는 충분한 세부사항들을 제공할 수 있다.
도 8은 다이그래프 데이터 구조(digraph data structure)(800)의 한 실시예의 블록도이다. 다이그래프 데이터 구조(800)는 에이전트들(112)에 의해 수집되는 의존도 데이터에 의거하여 관리자(120)에 의해 형성될 수 있다. 다이그래프(800)는 정점들(또한 노드(node)들이라고도 함)의 세트와, 에지들의 세트를 포함할 수 있다. 각각의 에지는 한 쌍의 구별되는 정점들을 나타낼 수 있다. 방향 그래프에서의 에지들은 순서쌍들일 수 있다.
다이그래프 데이터 구조(800)의 바닥에서 시작하면, 물리적 정점들의 모음(collection)과 물리적 에지들의 모음이 존재한다. 이들은 에이전트들(112)에 의해 수집된 실제 의존도 데이터일 수 있다. 표시된 바와 같이, 물리적 정점들과 물리적 에지들 사이에 2:1의 관계(에지에 대한 컴포넌트들의 순서쌍에 해당함)가 존재할 수 있다. 그 다음 상위 레벨에서, 논리적 정점들의 모음과 논리적 에지들의 모음이 존재한다. 일반적으로, 특정한 물리적 정점의 모든 인스턴스들에 대하여 하나의 논리적 정점이 존재할 수 있다. 일반적으로, 특정한 물리적 에지의 모든 인스턴스들에 대하여 하나의 논리적 에지가 존재할 수 있다. 논리적 정점들과 논리적 에지들 사이에 2:1의 관계가 존재할 수 있으며, 이는 에지에 대한 컴포넌트들의 순서쌍들에 해당한다. 아래에서 논의되는 바와 같이, 물리적 정점들(원시 의존도 데이터(raw dependency data))로부터 논리적 정점들을 형성하기 위하여 의존도 데이터가 종합될 수 있다. 마찬가지로, 물리적 에지들로부터 논리적 에지들을 형성하기 위해 의존도 데이터가 종합될 수 있다. 유의할 점은 논리적 정점들과 물리적 정점들 사이에 1:N의 관계가 존재한다는 것이다(논리적 에지들과 물리적 에지들에 대해서도 유사함).
표 1에서 언급된 바와 같이, 정점들은 "유형(type)", "추상화 레벨(abstraction level)", "계층화 레벨(hierarchy level)"과 같은 다양한 속성들을 가질 수 있다. 논리적 정점 위의 다이그래프(800)의 다음 상위 레벨들은 이들 속성들을 위한 컨테이너(container)들이다. 예를 들면, "서블릿(servlet)", "EJB", 및/또는 "데이터베이스"에 대하여 별개의 유형 컨테이너들이 있을 수 있다. 또 다른 예로서, "클래스(Class)" 및 "클래스-메쏘드(Class-Method)"에 대하여 별개의 계층화 레벨 컨테이너들이 존재할 수 있다. 또 다른 예로서, 정점들은 "추상화 레벨"에 의거하여 분류될 수 있다. 한 실시예에서, "외부 정점들"에 대한 컨테이너가 있으며, 이는 애플리케이션 서버(110)의 외부에 있는 적어도 일부 컴포넌트들에 대한 것일 수 있다. 한 실시예에서, 외부로부터 관리되는 애플리케이션(151)을 호출하는 컴포넌트들은 "외부 정점들"이다. 하지만, 데이터베이스들과 같은 백엔드에서의 외부 정점들은 반드시 외부 정점들로 고려될 필요는 없다. 유의할 점은 이들 속성들은 예들이고, 다른 속성들이 이용될 수도 있다는 것이다. 또한 유의할 점은 속성들이 서로 다른 순서로(예컨대, 서로 다른 레벨들) 위치될 수 있다는 것이다.
최상위 레벨에서 다이그래프 데이터 구조(800)는 의존도 맵 정점들(Dependency Map Vertices)과 의존도 맵 에지들(Dependency Map Edges)의 세트를 포함한다. 의존도 맵은 의존도 맵 정점들과 의존도 맵 에지들에 의거하여 그려질 수 있다. 예를 들면, 도 2 내지 도 4에서 도시된 다양한 요소들이 의존도 맵 정점들과 의존도 맵 에지들에 의거할 수 있다.
의존도 맵 정점은 유사한 물리적 정점들의 모음을 나타낼 수 있다. 물리적 정점들은 정점 소유권(ownership)과 속성들(예컨대, 카테고리, 계층화 레벨, 추상화 레벨, 유형 및 이름)에 기초하여 함께 그룹화될 수 있다. 의존도 맵 에지는 의존도 맵 정점들의 순서쌍일 수 있다. 각각의 의존도 맵 에지는 논리적 에지들의 모음을 유지함으로써 원래의 물리적 에지 관계를 유지할 수 있다.
도 9는 다이그래프를 생성할 때 에지들을 처리하기 위한 절차(900)의 한 실시예를 도시한 순서도이다. 절차(900)는 관리자(120)에 의해 수행될 수 있지만, 다른 계산 노드(compute node)가 절차(900)를 수행할 수 있다. 일반적으로, 절차(900)는 다이그래프를 형성하기 위해 의존도 데이터를 종합하는 것을 포함한다. 절차(900)에서, "물리적(physical)"이라는 용어와 "논리적(logical)"이라는 용어가 이용된다. 절차(900)에서, "물리적"이라는 용어는 수집되는 데이터를 가리킨다. 예를 들면, "물리적 정점"과 "물리적 에지"라는 용어들은 에이전트들(112)에 의해 수집되는 데이터를 가리키는 데 사용된다. 유의할 점은 의존도 데이터에서 특정한 물리적 정점의 인스턴스들이 많이 있을 수 있다는 것이다. 예를 들면, 의존도 데이터에서 모듈 A1의 인스턴스들이 많이 있을 수 있다. 마찬가지로, 의존도 데이터에서 특정한 물리적 에지의 인스턴스들이 많이 존재할 수 있다. 절차(900)에서, "논리적"이라는 용어는 물리적 정점들과 에지들을 나타내기 위해 다이그래프에서 생성되는 노드를 가리킨다. 유의할 점은 특정한 물리적 정점의 모든 인스턴스들에 대해 단일의 논리적 정점이 존재할 수 있다는 것이다. 예를 들면, 모듈 A1에 대해 단일의 논리적 정점이 존재할 수 있다. 마찬가지로, 특정한 물리적 에지의 모든 인스턴스들에 대해 단일의 논리적 에지가 존재할 수 있다. 절차(900)는 사용자 요청에 응답하여 수행될 수 있다. 사용자는 의존도 데이터가 일정한 애플리케이션이나 트랜잭션의 관점에서 보여질 것을 요청할 수 있다. 도 2 내지 도 4는 몇몇 이러한 예들을 도시한 것이다.
절차(900)는 사용자가 의존도 맵(200)을 디스플레이하라는 요청에서 특정하였던 애플리케이션(들)이나 트랜잭션(들)에 의해 소유되는 에지들을 처리할 수 있다. 단계(902)에서, 의존도 데이터에서 처리할 물리적 에지들이 더 존재하는지 여부에 대해 판별된다. 만일 그렇다면, 단계(904)에서 그 다음 물리적 에지가 의존도 데이터로부터 액세스된다. 본 명세서에서 언급된 바와 같이, 에지는 머리 정점(head vertex)과 꼬리 정점(tail vertex)에 의해 기술될 수 있다. 단계(906)에서, 관리자(120)는 머리 정점을 이미 마주쳤는지 여부를 판별한다. 다시 말해, 관리자(120)는 다이그래프가 그 머리 정점에 대하여 논리적 정점을 가지는지 여부를 판별할 수 있다. 만일 그렇지 않다면, 단계(908)에서 머리 정점에 대하여 새로운 논리적 정점이 다이그래프에서 생성된다. 한 실시예에서, 관리자(120)는 의존도 데이터에서 머리 정점의 하나 이상의 속성들을 조사한다. 예를 들면, 표 1을 참조하면, 유형, 이름, 소유자, 계층화 레벨, 및 추상화 레벨과 같은 하나 이상의 속성들이 이미 다이그래프에 있는 논리적 정점들과 비교될 수 있다. 유의할 점은 이 속성들은 예로서 제공되는 것이라는 점이다.
만일 머리 정점을 이미 마주쳤다면, 다이그래프에서 새로운 논리적 정점을 생성할 필요는 없다. 하지만, 단계(910)에서 머리 정점의 이 인스턴스에 관한 정보는 다이그래프에 추가될 수 있다. 예를 들면, 머리 정점의 이 인스턴스는 에이전트(112)가 데이터를 수집한 시간이나 관리자(120)가 이 인스턴스를 포함하는 데이터를 수신한 시간과 같이 그것과 관련된 일정한 시간 정보를 가질 수 있다. 이 시간 정보는 다이그래프에 추가될 수 있다. 시간 정보를 포함하는 한 이유는 일부 실시예들에서 의존도 맵이 의존도 데이터의 나이(age)에 의거하여 디스플레이되기 때문이다. 예를 들면, 사용자는 특정한 시편(time slice) 동안에 발생한 트랜잭션들에 관심이 있을 수 있다. 한 실시예에서, 논리적 정점은 마주쳤던 머리 정점의 각각의 인스턴스를 포함하는 버킷(bucket)을 가진다. 서로 다른 인스턴스들이 시간 정보에 의거하여 정렬될 수 있다.
머리 정점을 처리한 후에, 꼬리 정점이 처리된다. 꼬리 정점의 처리는 머리 정점과 유사할 수 있다. 단계(912)에서, 관리자(120)가 꼬리 정점을 이미 마주쳤는지 여부를 판별한다. 다시 말해, 관리자(120)는 다이그래프가 이미 꼬리 정점에 대하여 논리적 정점을 가지는지 여부를 판별할 수 있다. 만일 그렇지 않다면, 단계(914)에서 꼬리 정점에 대하여 새로운 논리적 정점이 다이그래프에 생성된다. 한 실시예에서, 관리자(120)는 의존도 데이터에서 꼬리 정점의 하나 이상의 속성들을 조사한다. 만일 꼬리 정점을 이미 마주쳤다면, 다이그래프에 새로운 논리적 정점을 생성할 필요는 없다. 하지만, 단계(916)에서 꼬리 정점의 이 인스턴스에 관한 정보는 다이그래프에 추가될 수 있다. 한 실시예에서, 논리적 정점은 마주쳤던 꼬리 정점의 각각의 인스턴스를 포함하는 버킷을 가진다. 서로 다른 인스턴스들이 시간 정보에 의거하여 정렬될 수 있다.
꼬리 정점을 처리한 후에, 에지가 처리된다. 단계(918)에서, 관리자(120)는 에지를 이미 마주쳤는지 여부를 판별한다. 다시 말해, 관리자(120)는 다이그래프가 이미 그 에지에 대한 논리적 에지를 가지는지 여부를 판별할 수 있다. 본 명세서에서 언급된 바와 같이, 에지는 꼬리 정점과 머리 정점의 순서쌍에 의해 기술될 수 있다. 한 실시예에서, 관리자(120)는 머리 및 꼬리 정점의 속성들을 갖는 에지를 마주쳤는지 여부를 판별하기 위하여 에지의 속성들을 조사한다. 하지만, 에지 동일성을 찾기 위해 다른 기법이 이용될 수 있다.
만일 에지를 마주치지 않았다면, 단계(920)에서 에지에 대하여 새로운 논리적 에지가 다이그래프에 생성된다. 이 논리적 에지는 논리적 머리와 논리적 꼬리 사이에 생성된다. 만일 에지를 이미 마주쳤다면, 다이그래프에 새로운 논리적 에지를 생성할 필요는 없다. 하지만, 단계(922)에서 에지의 이 인스턴스에 관한 정보는 다이그래프에 추가될 수 있다. 예를 들면, 에지와 관련된 시간 정보가 추가될 수 있다. 한 실시예에서, 논리적 에지는 마주쳤던 에지의 각각의 인스턴스를 포함하는 버킷을 가진다. 서로 다른 인스턴스들이 시간 정보에 의거하여 정렬될 수 있다. 한 실시예에서, 저장되는 에지들은 소유 에이전트에 의거하여 정렬된다.
도 10a 및 10b는 다이그래프를 형성할 때 정점들을 처리하는 절차(1000)의 한 실시예의 순서도를 도시한 것이다. 일부 실시예들에서 논리적 정점은 유형, 추상화 레벨, 계층화 등과 같은 속성들을 가질 수 있다는 것을 기억하자. 절차(1000)는 다이그래프 데이터 구조(800)에 이들 속성들을 추가하는 세부사항들을 기술한 것이다. 일반적으로, 절차(1000)는 단일의 정점을 처리하는 것을 기술한다. 따라서, 절차(1000)는 각각의 정점(꼬리 및 머리 모두)에 대하여 반복될 수 있다. 절차(1000)는 관리자(120)에 의해 수행될 수 있지만, 또 다른 노드가 절차(1000)를 수행할 수 있다.
단계(1002)에서, 관리자(120)는 의존도 데이터로부터 물리적 정점을 액세스한다. 단계(1004)에서, 물리적 정점이 논리적 다이그래프(800)에 추가된다.
절차(1000)에서, 정점들은 "프런트엔드(frontend)", "백엔드(backend)", 및 "백엔드 패밀리 카테고리(backend family category)"로서 카테고리화 될 수 있다. 물리적 정점이 어느 카테고리들에 있는지에 의거하여 처리가 계속될 수 있다. 프런트엔드는 일반적으로 트랜잭션의 시작(또는 앞)이나 시작 가까이에 있는 컴포넌트를 가리킬 수 있다. 예를 들면, 모듈 A1은 트랜잭션 BTA1에 대해 프런트엔드일 수 있다(도 1 참조). 백엔드는 일반적으로 트랜잭션의 뒤나 뒤 가까이에 있는 컴포넌트를 가리킬 수 있다. 한 실시예에서, 백엔드는 성능 메트릭(performance metric)들의 이용가능성에 따라 2개의 카테고리들로 나뉜다. 예를 들면, 모듈 A2가 데이터베이스X(113)를 호출할 때, 그 호출에 대한 성능 메트릭들이 존재할 수 있다. 그러므로, 데이터베이스X(133)는 "백엔드 카테고리"로 불릴 수 있다. 반면에, 모듈 A3가 모듈 B1을 호출하는 웹 서비스(109)를 호출할 때, 모듈 B1의 호출에 대해서가 아니라 웹 서비스(109)의 호출에 대하여 성능 메트릭들이 존재할 수 있다. 그러므로, 웹 서비스(109)는 "백엔드 패밀리 카테고리"로 불릴 수 있다.
단계(1006)는 물리적 정점이 프런트엔드 카테고리에 있는지를 판별하는 테스트이다. 컴포넌트가 어느 카테고리에 속하는지를 판별하는 데 이용될 수 있는 하나의 방안은 리스트(list)를 찾아보는 것이다. 예를 들면, 리스트는 일정한 유형의 소프트웨어 컴포넌트들이 "프런트엔드"로 고려될 수 있다는 것을 특정할 수 있다. 예를 들면, 서블릿은 프런트엔드로 고려될 수 있다. 데이터베이스는 백엔드로 고려될 수 있다. 다른 속성들도 또한 카테고리를 결정하는 데 이용될 수 있다. 한 실시예에서, 사용자는 다양한 컴포넌트들에 대해 카테고리를 정의할 수 있다. 물리적 정점이 프런트엔드 카테고리에 있다고 가정하면, 관리자(120)는 그 물리적 정점 소유자에 대하여 의존도 맵 정점이 존재하는지 여부를 판별한다. 만일 그렇지 않다면, 단계(1010)에서 의존도 맵 정점이 생성된다. 그런 다음, 단계(1012)에서 물리적 정점이 의존도 맵 정점에 추가된다. 만일 의존도 맵 정점이 그 물리적 정점 소유자에 대해 이미 존재한다면, 단계(1010)는 건너뛸 수 있다.
단계(1014)에서, 관리자(120)는 물리적 정점에 대하여 부모(parent)가 존재하는지 여부를 판별한다. 정점의 하나의 속성은 계층화 레벨(예컨대, 클래스, 클래스-메쏘드)일 수 있다는 것을 기억하자. 방향 그래프에서 이미 존재하는 부모가 있는지 여부를 판별하기 위해 계층화 레벨이 조사될 수 있다. 만일 부모가 있다면, 단계(1016)에서 관리자(120)는 부모 물리적 정점(parent physical vertex)에 대하여 임의의 논리적 정점이 존재하는지 여부를 판별한다. 만일 그 부모 물리적 정점에 대하여 논리적 정점이 존재하지 않는다면(단계(1016)가 아니오임), 단계(1017)에서 부모 정점이 의존도 맵 정점에 추가된다. 만일 단계(1016)가 예라면, 절차는 아래에서 논의될 단계(1018)로 속행한다.
만일 물리적 정점에 대하여 부모가 존재하지 않는다면(단계(1014)가 아니오임), 단계(1018)에서 관리자는 그 물리적 정점의 계층화 레벨에 대해 임의의 컨테이너가 존재하는지 여부를 판별한다. 만일 존재하지 않는다면, 관리자(120)는 계층화 컨테이너를 생성하고(단계(1020)), 물리적 정점을 계층화 컨테이너에 추가한다(단계(1022)). 반면에, 만일 물리적 정점의 계층화 레벨에 대해 컨테이너가 이미 존재한다면, 새로운 컨테이너가 생성될 필요가 없고(단계(1020)를 건너뜀), 단계(1022)에서 물리적 정점은 이미 존재하는 계층화 컨테이너에 추가된다.
다음으로 추상화 레벨의 처리가 수행된다. 단계(1024)에서, 관리자(120)는 물리적 정점의 추상화 레벨에 대해 임의의 컨테이너가 존재하는지 여부를 판별한다. 만일 존재하지 않는다면, 관리자(120)는 추상화 레벨 컨테이너를 생성하고(단계(1026)), 물리적 정점을 추상화 레벨에 추가한다(단계(1028)). 반면에, 만일 물리적 정점의 추상화 레벨에 대해 컨테이너가 이미 존재한다면, 새로운 컨테이너가 생성될 필요가 없고(단계(1026)를 건너뜀), 단계(1028)에서 물리적 정점은 이미 존재하는 추상화 레벨 컨테이너에 추가된다.
다음으로 유형의 처리가 수행된다. 단계(1030)에서, 관리자(120)는 물리적 정점의 유형에 대해 임의의 컨테이너가 존재하는지 여부를 판별한다. 만일 존재하지 않는다면, 관리자(120)는 유형 컨테이너를 생성하고(단계(1032)), 물리적 정점을 유형 컨테이너에 추가한다(단계(1034)). 반면에, 만일 물리적 정점의 유형에 대해 컨테이너가 이미 존재한다면, 새로운 컨테이너가 생성될 필요가 없고(단계(1032)를 건너뜀), 단계(1034)에서 물리적 정점은 이미 존재하는 유형 컨테이너에 추가된다.
다음으로 논리적 정점의 처리가 수행된다. 단계(1036)에서, 관리자(120)는 물리적 정점 이름을 갖는 임의의 논리적 정점이 존재하는지 여부를 판별한다. 만일 존재하지 않는다면, 관리자(120)는 논리적 정점을 생성하고(단계(1038)), 물리적 정점을 논리적 정점에 추가한다(단계(1040)). 반면에, 만일 물리적 정점에 대해 논리적 정점이 이미 존재한다면, 새로운 논리적 정점이 생성될 필요가 없고(단계(1038)를 건너뜀), 단계(1040)에서 물리적 정점은 이미 존재하는 논리적 정점에 추가된다. 이는 물리적 정점이 프런트엔드 카테고리에 있는 경우에 대한 처리를 끝맺는다.
만일 물리적 정점이 백엔드 패밀리 카테고리에 있다면(단계(1050)가 예임), 처리는 다음과 같다. 관리자(120)는 정점 소유자와 백엔드 패밀리 이름에 대해 이미 의존도 맵 정점이 존재하는지 여부를 판별한다(단계(1052)). 만일 그렇지 않다면, 단계(1054)에서 관리자(120)는 이러한 의존도 맵 정점을 생성한다. 그런 다음, 단계(1012)에서 절차(1000)는 물리적 정점을 의존도 맵 정점에 추가한다. 만일 의존도 맵 정점이 이미 존재한다면, 절차(1000)는 물리적 정점을 의존도 맵 정점에 추가하기 위해 단계(1012)로 간다. 그런 다음, 절차(1000)는 프런트엔드 카테고리에 대해 이미 서술된 바와 같이 계속된다.
만일 물리적 정점이 백엔드 패밀리 카테고리에 있지 않다면(단계(1050)가 아니오임), 관리자(120)는 물리적 정점이 백엔드 카테고리에 있는지 여부를 판별한다(단계(1060)). 만일 그렇다면, 관리자(120)는 정점 유형과 이름에 대해 이미 의존도 맵 정점이 존재하는지 여부를 판별한다(단계(1062)). 만일 그렇지 않다면, 단계(1064)에서 관리자(120)는 이러한 의존도 맵 정점을 생성한다. 그런 다음, 단계(1012)에서 절차(1000)는 물리적 정점을 의존도 맵 정점에 추가한다. 만일 의존도 맵 정점이 이미 존재한다면, 절차(1000)는 물리적 정점을 의존도 맵 정점에 추가하기 위해 단계(1012)로 간다. 그런 다음, 절차(1000)는 프런트엔드 카테고리에 대해 이미 서술된 바와 같이 계속된다. 만일 물리적 정점이 백엔드 카테고리에 있지 않으면(단계(1060)가 아니오임), 절차는 종료한다.
한 실시예에서, 의존도 맵(200)은 의존도 데이터의 나이에 의거하여 디스플레이된다. 예를 들면, 만일 컴포넌트 및/또는 에지에 대한 데이터가 사용자가 특정한 시간 범위 밖에 있다면 의존도 맵에서 컴포넌트들 및/또는 에지들 일부가 회색으로 비활성화될(grayed out) 수 있다. 도 11은 의존도 데이터의 나이에 의거하여 의존도 맵을 디스플레이하는 절차(1100)의 한 실시예의 순서도이다. 절차(1100)의 한 실시예에서, 방향 그래프가 입력이고, 오래된 것으로 표시된 일정한 정점들 및/또는 에지들을 가지는 방향 그래프가 출력이다.
단계(1102)에서, 시간 범위가 수신된다. 한 실시예에서, 사용자는 사용자 인터페이스(122)와 같은 사용자 인터페이스로 시간 범위를 입력한다. 사용자는 또한 의존도 데이터가 형성되어야 할 하나 이상의 관리되는 애플리케이션들(151) 및/또는 하나 이상의 트랜잭션들을 특정할 수도 있다.
일반적으로, 절차(1100)는 입력 방향 그래프로부터의 에지들과 정점들을 처리한다. 단계(1104)에서, 처리해야할 에지들이 더 존재하는지에 대한 판별이 이루어진다. 만일 그렇다면, 단계(1106)에서 다음의 에지가 방향 그래프로부터 액세스된다. 예를 들면, 방향 그래프에 저장된 시간 정보가 액세스된다. 시간 정보는 에이전트(112)가 물리적 에지에 대하여 데이터를 수집한 시간 및/또는 관리자(120)가 의존도 데이터를 저장한 시간을 포함할 수도 있다는 것을 기억하자. 하지만, 유의할 점은 시간 정보는 이들 예로만 한정되는 것은 아니라는 것이다.
단계(1108)에서, 에지의 나이가 단계(1102)에서 수신된 시간 범위 밖에 있는지 여부에 대한 판별이 이루어진다. 예를 들면, 만일 사용자가 단지 지난 24시간 동안의 데이터를 보기를 원한다고 할 때, 만일 에지에 대한 데이터가 24시간보다도 전에 수집되었다면, 단계(1110)에서 그것은 회색으로 표시된다. 회색으로 표시한다는 것은 의존도 맵이 디스플레이될 때 그 에지가 회색으로 비활성화된 것으로 디스플레이되도록 에지를 만드는 것을 가리킨다. 유의할 점은 회색으로 표시하는 것은 에지를 오래된 것으로 표시하는 하나의 예이고, 다른 기법들이 사용될 수 있다는 것이다. 만일 그렇지 않으면, 단계(1112)에서 에지는 회색이 아닌 것으로 표시된다. 절차(1110)는 모든 에지들이 처리되었을 때까지 에지들을 더 처리하는 것을 계속한다. 그런 다음, 단계(1114)에서 시작하여 정점들이 처리된다.
단계(1114)에서, 방향 그래프에서 더 이상의 에지들이 있는지 여부에 대한 판별이 이루어진다. 만일 그렇다면, 그 다음 정점이 방향 그래프로부터 액세스된다. 예를 들면, 정점을 회색으로 만들지 여부에 대한 판별이 이루어질 수 있도록 정점에 대한 정보가 방향 그래프로부터 액세스된다. 한 실시예에서, 그 판별은 정점에 연결된 에지들이 회색으로 된 것인지 여부에 의거한다.
단계(1118)에서, 정점에 연결된 모든 에지들이 회색으로 표시된 것인지 여부에 대한 판별이 이루어진다. 만일 그렇다면, 단계(1120)에서 정점은 회색으로 표시된다. 만일 그렇지 않으면, 단계(1122)에서 정점은 회색이 아닌 것으로 표시된다. 유의할 점은 정점을 회색으로 표시할지 여부를 판별하기 위해 서로 다른 테스트가 이루어질 수 있다는 것이다. 모든 정점들이 처리된 후에, 절차(1100)는 끝맺는다. 절차(1110)의 결과는 회색이나 회색이 아닌 것 중 어느 하나로 표시된 에지들과 정점들을 가지는 방향 그래프일 수 있다. 그러므로, 의존도가 적절히 디스플레이될 수 있다. 언급된 바와 같이, 회색으로 비활성화하는 것은 의존도 데이터의 오래된 정도를 보여주는 방식으로 표시하는 하나의 예이다.
본 발명의 전술된 상세한 설명은 예시 및 설명의 목적으로 제시되었다. 상기 상세한 설명은 본 발명을 빠짐없이 완전히 제시한 것이라거나 본 발명을 개시된 바로 그 형태로 한정하고자 의도된 것이 아니다. 상기 교시 내용에 비추어 많은 수정 및 변경들이 가능하다. 상기 서술된 실시예들은 본 발명의 원리 및 그 실제적인 응용을 가장 잘 설명함으로써 당해 기술분야의 숙련된 기술자들이 다양한 실시예들에서 그리고 예기된 특정 용도에 적합하게 다양한 수정들을 가하여 본 발명을 가장 잘 이용할 수 있게 하기 위하여 선택되었다. 본 발명의 범위는 본 명세서에 첨부된 특허청구범위에 의해 정의되도록 의도하는 바이다.

Claims (15)

  1. 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도(dependencies)를 기술하는 데이터를 수집하는 단계(602)와;
    상기 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프(directed graph)를 형성하기 위해 상기 데이터를 종합(aggregate)하는 단계(604)와; 그리고
    상기 방향 그래프에 의거하여 디스플레이 스크린상에 의존도 맵(dependency map)을 디스플레이하는 단계(606)를 포함하며, 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 의존도를 보여주는
    기계로 구현되는 방법.
  2. 제1항에 있어서,
    상기 수집된 데이터는 상기 복수의 소프트웨어 컴포넌트들을 기술하는 정점 데이터(vertex data) 및 복수의 에지들에 대한 에지 데이터(edge data)를 포함하며, 상기 복수의 에지들 각각은 상기 복수의 소프트웨어 컴포넌트들의 쌍(pair)과 관련되는
    기계로 구현되는 방법.
  3. 제2항에 있어서,
    상기 데이터를 수집하는 단계는 상기 복수의 소프트웨어 컴포넌트들의 컴포넌트들에 대한 상기 소프트웨어 컴포넌트를 기술하는 정보를 수집하는 것을 포함하는
    기계로 구현되는 방법.
  4. 제2항 또는 제3항에 있어서,
    상기 데이터를 수집하는 단계는 상기 에지들 각각의 소유자(owner)를 기술하는 정보를 수집하는 것을 포함하는
    기계로 구현되는 방법.
  5. 제4항에 있어서,
    상기 에지들 각각의 상기 소유자는 소프트웨어 애플리케이션 또는 한 유형의 비즈니스 트랜잭션(a type of business transaction) 중 하나인
    기계로 구현되는 방법.
  6. 제2항 내지 제5항 중 어느 한 항에 있어서,
    방향 그래프를 형성하기 위해 상기 데이터를 종합하는 단계는
    상기 의존도 데이터에서 동일한 에지의 서로 다른 인스턴스(instance)들에 대하여 단일의 논리적 에지(logical edge)를 생성하는 것과,
    상기 의존도 데이터에서 상기 에지들 중 제1 에지의 제1 인스턴스에 대하여 제1 논리적 에지를 생성하는 것과, 그리고
    상기 의존도 데이터에서 상기 제1 에지의 추가적인 인스턴스들에 대한 정보를 상기 제1 논리적 에지에 추가하는 것
    을 포함하는 기계로 구현되는 방법.
  7. 제2항 내지 제6항 중 어느 한 항에 있어서,
    방향 그래프를 형성하기 위해 상기 데이터를 종합하는 단계는
    상기 의존도 데이터에서 동일한 소프트웨어 컴포넌트의 서로 다른 인스턴스들에 대하여 단일의 논리적 정점(logical vertex)을 생성하는 것과,
    상기 의존도 데이터에서 상기 소프트웨어 컴포넌트들 중 제1 소프트웨어 컴포넌트의 제1 인스턴스에 대하여 제1 논리적 정점을 생성하는 것과; 그리고
    상기 의존도 데이터에서 상기 제1 소프트웨어 컴포넌트의 추가적인 인스턴스들에 대한 정보를 상기 제1 논리적 정점에 추가하는 것
    을 포함하는 기계로 구현되는 방법.
  8. 제7항에 있어서,
    상기 방향 그래프에 의거하여 디스플레이 스크린 상에 의존도 맵을 디스플레이하는 단계는 상기 소프트웨어 애플리케이션들 중 제1 소프트웨어 애플리케이션이 오래된 것임을 표시하는 방식으로 상기 제1 소프트웨어 애플리케이션을 디스플레이하는 것을 포함하는
    기계로 구현되는 방법.
  9. 제1항 내지 제8항 중 어느 한 항에 있어서,
    상기 소프트웨어 컴포넌트들에 의해 처리되는 상기 트랜잭션들을 트레이스(trace)하는 단계를 더 포함하는
    기계로 구현되는 방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서,
    상기 의존도 맵은 상기 복수의 소프트웨어 컴포넌트들을 포함하는 애플리케이션들 사이의 의존도를 보여주는
    기계로 구현되는 방법.
  11. 하나 이상의 컴퓨팅 장치들(110A, 110B) 상에서 실행되는 소프트웨어 컴포넌트들(모듈 A1, A2, A3, B1)에 의해 처리되는 트랜잭션들의 트레이스를 시작하는 적어도 하나의 프로세서(530)를 포함하며, 상기 적어도 하나의 프로세서는 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 수집하고, 상기 적어도 하나의 프로세서는 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프를 형성하기 위해 상기 의존도를 기술하는 데이터를 종합하고, 상기 적어도 하나의 프로세서는 상기 트랜잭션들이 처리될 때 상기 소프트웨어 컴포넌트들 또는 상기 소프트웨어 컴포넌트들이 존재하는 애플리케이션들 중 어느 하나의 의존도를 기술하는 상기 방향 그래프에 의거하여 의존도 맵을 디스플레이하는
    시스템.
  12. 제11항에 있어서,
    상기 적어도 하나의 프로세서에 연결되는 디스플레이(550)를 더 포함하며, 상기 적어도 하나의 프로세서는 상기 디스플레이 상에 상기 의존도 맵을 디스플레이하며, 상기 의존도 맵은 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 보여주는
    시스템.
  13. 제11항 또는 제12항에 있어서,
    상기 수집된 데이터는 상기 복수의 소프트웨어 컴포넌트들을 기술하는 정점 데이터와 복수의 에지들에 대한 에지 데이터를 포함하며, 상기 복수의 에지들 각각은 상기 복수의 소프트웨어 컴포넌트들의 쌍과 관련되는
    시스템.
  14. 제11항 내지 제13항 중 어느 한 항에 있어서,
    상기 수집된 데이터는 상기 복수의 소프트웨어 컴포넌트들의 컴포넌트들에 대한 상기 소프트웨어 컴포넌트를 기술하는 정보를 포함하는
    시스템.
  15. 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 기술하는 데이터를 수집하는 수단(530)과;
    상기 복수의 소프트웨어 컴포넌트들이 트랜잭션들을 처리할 때 상기 복수의 소프트웨어 컴포넌트들 사이의 의존도를 나타내는 방향 그래프를 형성하기 위해 상기 데이터를 종합하는 수단(530)과; 그리고
    상기 방향 그래프에 의거하여 디스플레이 스크린상에 의존도 맵을 디스플레이하는 수단(550, 530)을 포함하며, 상기 의존도 맵은 상기 트랜잭션들이 처리될 때 의존도를 보여주는
    시스템.
KR1020110093671A 2010-09-17 2011-09-16 의존도 데이터로부터 의존도 맵들의 발생 KR101678131B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/885,135 2010-09-17
US12/885,135 US8490055B2 (en) 2010-09-17 2010-09-17 Generating dependency maps from dependency data

Publications (2)

Publication Number Publication Date
KR20120030320A true KR20120030320A (ko) 2012-03-28
KR101678131B1 KR101678131B1 (ko) 2016-12-06

Family

ID=45002179

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020110093671A KR101678131B1 (ko) 2010-09-17 2011-09-16 의존도 데이터로부터 의존도 맵들의 발생

Country Status (4)

Country Link
US (1) US8490055B2 (ko)
EP (1) EP2431879A1 (ko)
JP (1) JP5431430B2 (ko)
KR (1) KR101678131B1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015057188A1 (en) * 2013-10-14 2015-04-23 Hewlett-Packard Development Company, L.P. Package dependency maps for distributed computing
KR20180073520A (ko) * 2015-10-23 2018-07-02 오라클 인터내셔날 코포레이션 병렬로 애플리케이션 서버를 부팅하기 위한 시스템 및 방법
CN109254909A (zh) * 2018-08-06 2019-01-22 四川蜀天梦图数据科技有限公司 一种测试用大图生成方法和系统

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8175863B1 (en) 2008-02-13 2012-05-08 Quest Software, Inc. Systems and methods for analyzing performance of virtual environments
US8490055B2 (en) * 2010-09-17 2013-07-16 Ca, Inc. Generating dependency maps from dependency data
US8688606B2 (en) * 2011-01-24 2014-04-01 International Business Machines Corporation Smarter business intelligence systems
US8516301B2 (en) 2011-04-08 2013-08-20 Ca, Inc. Visualizing transaction traces as flows through a map of logical subsystems
US9202185B2 (en) * 2011-04-08 2015-12-01 Ca, Inc. Transaction model with structural and behavioral description of complex transactions
US8438427B2 (en) 2011-04-08 2013-05-07 Ca, Inc. Visualizing relationships between a transaction trace graph and a map of logical subsystems
US8782614B2 (en) * 2011-04-08 2014-07-15 Ca, Inc. Visualization of JVM and cross-JVM call stacks
US8997084B2 (en) * 2011-04-20 2015-03-31 Hewlett-Packard Development Company, L.P. Method and apparatus for determining compatible versions of dependent entities in a computer system
US10157049B2 (en) * 2011-10-26 2018-12-18 International Business Machines Corporation Static analysis with input reduction
US9038033B1 (en) * 2011-12-09 2015-05-19 Sencha, Inc. Techniques and mechanisms for web application minification
US8938518B2 (en) * 2012-01-16 2015-01-20 International Business Machines Corporation Transferring applications and session state to a secondary device
US9665233B2 (en) * 2012-02-16 2017-05-30 The University Utah Research Foundation Visualization of software memory usage
EP2842026A4 (en) * 2012-04-27 2016-01-13 Hewlett Packard Development Co MAPPING OF APPLICATION DEPENDENCIES AT TIME OF EXECUTION
US10230603B2 (en) * 2012-05-21 2019-03-12 Thousandeyes, Inc. Cross-layer troubleshooting of application delivery
US9729414B1 (en) 2012-05-21 2017-08-08 Thousandeyes, Inc. Monitoring service availability using distributed BGP routing feeds
US10333820B1 (en) * 2012-10-23 2019-06-25 Quest Software Inc. System for inferring dependencies among computing systems
US9557879B1 (en) 2012-10-23 2017-01-31 Dell Software Inc. System for inferring dependencies among computing systems
US9411787B1 (en) 2013-03-15 2016-08-09 Thousandeyes, Inc. Cross-layer troubleshooting of application delivery
US10924365B2 (en) * 2013-05-03 2021-02-16 Inetco Systems Limited Method and system for generating directed graphs
US9734040B2 (en) 2013-05-21 2017-08-15 Microsoft Technology Licensing, Llc Animated highlights in a graph representing an application
US8990777B2 (en) * 2013-05-21 2015-03-24 Concurix Corporation Interactive graph for navigating and monitoring execution of application code
US9280841B2 (en) 2013-07-24 2016-03-08 Microsoft Technology Licensing, Llc Event chain visualization of performance data
US9292415B2 (en) 2013-09-04 2016-03-22 Microsoft Technology Licensing, Llc Module specific tracing in a shared module environment
WO2015071777A1 (en) 2013-11-13 2015-05-21 Concurix Corporation Software component recommendation based on multiple trace runs
US11005738B1 (en) 2014-04-09 2021-05-11 Quest Software Inc. System and method for end-to-end response-time analysis
US9479414B1 (en) 2014-05-30 2016-10-25 Dell Software Inc. System and method for analyzing computing performance
US9535726B2 (en) 2014-09-26 2017-01-03 Oracle International Corporation Reverse dependency injection in a system with dynamic code loading
US10291493B1 (en) 2014-12-05 2019-05-14 Quest Software Inc. System and method for determining relevant computer performance events
JP2017539031A (ja) * 2014-12-09 2017-12-28 エントイット ソフトウェア エルエルシーＥｎｔｉｔ Ｓｏｆｔｗａｒｅ Ｌｌｃ テスト実行からのテスト検証の分離
US9274758B1 (en) 2015-01-28 2016-03-01 Dell Software Inc. System and method for creating customized performance-monitoring applications
US9996577B1 (en) 2015-02-11 2018-06-12 Quest Software Inc. Systems and methods for graphically filtering code call trees
US10187260B1 (en) 2015-05-29 2019-01-22 Quest Software Inc. Systems and methods for multilayer monitoring of network function virtualization architectures
US10200252B1 (en) 2015-09-18 2019-02-05 Quest Software Inc. Systems and methods for integrated modeling of monitored virtual desktop infrastructure systems
US9892029B2 (en) * 2015-09-29 2018-02-13 International Business Machines Corporation Apparatus and method for expanding the scope of systems management applications by runtime independence
US9547478B1 (en) * 2015-09-30 2017-01-17 Semmle Limited Hierarchical dependency analysis enhancements using disjoint-or trees
US10432471B2 (en) * 2015-12-31 2019-10-01 Microsoft Technology Licensing, Llc Distributed computing dependency management system
US10671520B1 (en) 2016-06-15 2020-06-02 Thousandeyes, Inc. Scheduled tests for endpoint agents
US10659325B2 (en) 2016-06-15 2020-05-19 Thousandeyes, Inc. Monitoring enterprise networks with endpoint agents
US10230601B1 (en) 2016-07-05 2019-03-12 Quest Software Inc. Systems and methods for integrated modeling and performance measurements of monitored virtual desktop infrastructure systems
US11979422B1 (en) 2017-11-27 2024-05-07 Lacework, Inc. Elastic privileges in a secure access service edge
US11973784B1 (en) 2017-11-27 2024-04-30 Lacework, Inc. Natural language interface for an anomaly detection framework
US12021888B1 (en) 2017-11-27 2024-06-25 Lacework, Inc. Cloud infrastructure entitlement management by a data platform
US20190325078A1 (en) 2018-04-24 2019-10-24 Trovares, Inc. Graph search optimization system based on sorted property techniques
US10885116B2 (en) 2018-04-24 2021-01-05 Trovares, Inc. Graph search optimization system based on an edge-count directed techniques
WO2019209661A1 (en) * 2018-04-24 2019-10-31 Trovares, Inc. Graph search optimization system based on derived constraint techniques
US10885117B2 (en) 2018-04-24 2021-01-05 Trovares, Inc. Graph search optimization system based on derived constraint techniques
KR102108342B1 (ko) * 2018-08-21 2020-05-13 재단법인대구경북과학기술원 그래프 특성을 보존하는 대규모 그래프 증폭 시스템
CN110908741A (zh) * 2018-09-14 2020-03-24 阿里巴巴集团控股有限公司 应用性能管理的展示方法及装置
US11032124B1 (en) 2018-10-24 2021-06-08 Thousandeyes Llc Application aware device monitoring
US10848402B1 (en) 2018-10-24 2020-11-24 Thousandeyes, Inc. Application aware device monitoring correlation and visualization
US11159386B2 (en) * 2019-03-14 2021-10-26 Cisco Technology, Inc. Enriched flow data for network analytics
US10567249B1 (en) 2019-03-18 2020-02-18 Thousandeyes, Inc. Network path visualization using node grouping and pagination
US11323463B2 (en) * 2019-06-14 2022-05-03 Datadog, Inc. Generating data structures representing relationships among entities of a high-scale network infrastructure
US10747544B1 (en) * 2019-06-27 2020-08-18 Capital One Services, Llc Dependency analyzer in application dependency discovery, reporting, and management tool
US11347569B2 (en) 2020-10-07 2022-05-31 Microsoft Technology Licensing, Llc Event-based framework for distributed applications
US11762749B2 (en) 2021-10-28 2023-09-19 Bionic Stork Ltd. Software application intelligence platform, and method thereof
US20230252133A1 (en) * 2022-02-10 2023-08-10 Cisco Technology, Inc. Application Security Context from Traces and Snapshots
US20240103853A1 (en) * 2022-09-26 2024-03-28 Sap Se Code maintenance system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040064543A1 (en) * 2002-09-16 2004-04-01 Ashutosh Ashutosh Software application domain and storage domain management process and method
US20090144305A1 (en) * 2007-11-29 2009-06-04 Mark Cameron Little Dependency management with atomic decay

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5485616A (en) 1993-10-12 1996-01-16 International Business Machines Corporation Using program call graphs to determine the maximum fixed point solution of interprocedural bidirectional data flow problems in a compiler
US5592600A (en) 1994-09-27 1997-01-07 International Business Machines Corporation Animated display showing execution of object-oriented programs
US6186677B1 (en) 1996-08-27 2001-02-13 Compuware Corporation Byte code instrumentation
JPH1124901A (ja) 1997-06-27 1999-01-29 Internatl Business Mach Corp <Ibm> プログラム情報の解析・表示方法およびシステム
US6282701B1 (en) 1997-07-31 2001-08-28 Mutek Solutions, Ltd. System and method for monitoring and analyzing the execution of computer programs
US6338159B1 (en) 1997-12-12 2002-01-08 International Business Machines Corporation System and method for providing trace information
US6260187B1 (en) 1998-08-20 2001-07-10 Wily Technology, Inc. System for modifying object oriented code
US6584501B1 (en) 1999-02-03 2003-06-24 Compuware Corporation Method to display information representing network traffic on a computer display monitor
WO2001086775A1 (en) 2000-05-05 2001-11-15 Aprisma Management Technologies, Inc. Help desk systems and methods for use with communications networks
US7003781B1 (en) 2000-05-05 2006-02-21 Bristol Technology Inc. Method and apparatus for correlation of events in a distributed multi-system computing environment
AU2001279151A1 (en) 2000-08-04 2002-03-04 Xtremesoft, Inc. System and method for analysing a transactional monitoring system
US6857120B1 (en) 2000-11-01 2005-02-15 International Business Machines Corporation Method for characterizing program execution by periodic call stack inspection
US7065566B2 (en) 2001-03-30 2006-06-20 Tonic Software, Inc. System and method for business systems transactions and infrastructure management
US8473922B2 (en) 2001-09-19 2013-06-25 Hewlett-Packard Development Company, L.P. Runtime monitoring in component-based systems
US6996806B2 (en) 2001-09-21 2006-02-07 International Business Machines Corporation Graphical view of program structure during debugging session
US7216160B2 (en) 2001-10-31 2007-05-08 Sun Microsystems, Inc. Server-based application monitoring through collection of application component and environmental statistics
US7290048B1 (en) 2002-03-29 2007-10-30 Hyperformix, Inc. Method of semi-automatic data collection, data analysis, and model generation for the performance analysis of enterprise applications
US20040039728A1 (en) 2002-08-23 2004-02-26 Diring Software Method and system for monitoring distributed systems
US7558847B2 (en) 2002-09-13 2009-07-07 Intelliden, Inc. System and method for mapping between and controlling different device abstractions
US6792460B2 (en) 2002-10-02 2004-09-14 Mercury Interactive Corporation System and methods for monitoring application server performance
US7870431B2 (en) * 2002-10-18 2011-01-11 Computer Associates Think, Inc. Transaction tracer
US7310777B2 (en) 2002-10-18 2007-12-18 Computer Associates Think, Inc. User interface for viewing performance information about transactions
US7607169B1 (en) 2002-12-02 2009-10-20 Arcsight, Inc. User interface for network security console
US8244853B1 (en) 2003-03-03 2012-08-14 Vmware, Inc. Method and system for non intrusive application interaction and dependency mapping
US7505953B2 (en) 2003-07-11 2009-03-17 Computer Associates Think, Inc. Performance monitoring of method calls and database statements in an application server
US7310780B2 (en) 2003-08-14 2007-12-18 International Business Machines Corporation Methods, systems and computer program products for visually tethering related graphical objects
US7668953B1 (en) 2003-11-13 2010-02-23 Cisco Technology, Inc. Rule-based network management approaches
US7191364B2 (en) 2003-11-14 2007-03-13 Microsoft Corporation Automatic root cause analysis and diagnostics engine
US7590614B2 (en) 2003-12-11 2009-09-15 Sap Ag Method, apparatus, and computer program product for implementing techniques for visualizing data dependencies
US7987453B2 (en) 2004-03-18 2011-07-26 International Business Machines Corporation Method and apparatus for determining computer program flows autonomically using hardware assisted thread stack tracking and cataloged symbolic data
US8352423B2 (en) 2004-05-07 2013-01-08 Inceptia Llc Apparatus and method for providing streaming data
US20060036726A1 (en) 2004-07-12 2006-02-16 Vieo, Inc. User interface for a distributed computing environment and method of using the same
US7203624B2 (en) 2004-11-23 2007-04-10 Dba Infopower, Inc. Real-time database performance and availability change root cause analysis method and system
US7509632B2 (en) 2005-03-24 2009-03-24 International Business Machines Corporation Method and apparatus for analyzing call history data derived from execution of a computer program
US7743128B2 (en) 2005-04-20 2010-06-22 Netqos, Inc. Method and system for visualizing network performance characteristics
US7350107B2 (en) 2005-04-29 2008-03-25 Microsoft Corporation Method and apparatus for performing network diagnostics
US8694621B2 (en) 2005-08-19 2014-04-08 Riverbed Technology, Inc. Capture, analysis, and visualization of concurrent system and network behavior of an application
US7904892B2 (en) * 2006-01-06 2011-03-08 Northrop Grumman Corporation Systems and methods for identifying and displaying dependencies
JP2007249373A (ja) * 2006-03-14 2007-09-27 Osaka Prefecture Univ 分散型プログラムの監視システム
US8578017B2 (en) 2006-05-11 2013-11-05 Ca, Inc. Automatic correlation of service level agreement and operating level agreement
US8656006B2 (en) 2006-05-11 2014-02-18 Ca, Inc. Integrating traffic monitoring data and application runtime data
US9519571B2 (en) 2007-07-13 2016-12-13 International Business Machines Corporation Method for analyzing transaction traces to enable process testing
US8208381B2 (en) 2007-07-27 2012-06-26 Eg Innovations Pte. Ltd. Root-cause approach to problem diagnosis in data networks
US20090112667A1 (en) * 2007-10-31 2009-04-30 Ken Blackwell Automated Business Process Model Discovery
US20090177509A1 (en) 2008-01-09 2009-07-09 Joshua David Business Service Management Dashboard
US8499284B2 (en) * 2008-09-11 2013-07-30 Microsoft Corporation Visualizing relationships among components using grouping information
US7681182B1 (en) 2008-11-06 2010-03-16 International Business Machines Corporation Including function call graphs (FCG) generated from trace analysis data within a searchable problem determination knowledge base
US8027981B2 (en) 2008-12-10 2011-09-27 International Business Machines Corporation System, method and program product for classifying data elements into different levels of a business hierarchy
US8135739B2 (en) 2008-12-29 2012-03-13 Microsoft Corporation Online relevance engine
US8589196B2 (en) 2009-04-22 2013-11-19 Bank Of America Corporation Knowledge management system
JP5440164B2 (ja) * 2009-12-28 2014-03-12 富士通株式会社 分析プログラム、及び制御プログラム
US8490055B2 (en) * 2010-09-17 2013-07-16 Ca, Inc. Generating dependency maps from dependency data
US8438427B2 (en) 2011-04-08 2013-05-07 Ca, Inc. Visualizing relationships between a transaction trace graph and a map of logical subsystems
US9202185B2 (en) 2011-04-08 2015-12-01 Ca, Inc. Transaction model with structural and behavioral description of complex transactions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040064543A1 (en) * 2002-09-16 2004-04-01 Ashutosh Ashutosh Software application domain and storage domain management process and method
US20090144305A1 (en) * 2007-11-29 2009-06-04 Mark Cameron Little Dependency management with atomic decay

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015057188A1 (en) * 2013-10-14 2015-04-23 Hewlett-Packard Development Company, L.P. Package dependency maps for distributed computing
KR20180073520A (ko) * 2015-10-23 2018-07-02 오라클 인터내셔날 코포레이션 병렬로 애플리케이션 서버를 부팅하기 위한 시스템 및 방법
CN109254909A (zh) * 2018-08-06 2019-01-22 四川蜀天梦图数据科技有限公司 一种测试用大图生成方法和系统
CN109254909B (zh) * 2018-08-06 2021-11-23 四川蜀天梦图数据科技有限公司 一种测试用大图生成方法和系统

Also Published As

Publication number Publication date
US20120072887A1 (en) 2012-03-22
JP5431430B2 (ja) 2014-03-05
KR101678131B1 (ko) 2016-12-06
EP2431879A1 (en) 2012-03-21
US8490055B2 (en) 2013-07-16
JP2012074028A (ja) 2012-04-12

Similar Documents

Publication Publication Date Title
KR101678131B1 (ko) 의존도 데이터로부터 의존도 맵들의 발생
WO2018228285A1 (zh) 一种数据采集、查询方法、装置、存储介质及处理器
US8341605B2 (en) Use of execution flow shape to allow aggregate data reporting with full context in an application manager
JP5886712B2 (ja) 分散環境におけるトランザクション別に区別されたメトリックの効率的収集
US7949673B2 (en) Correlating cross process and cross thread execution flows in an application manager
US8316354B2 (en) Execution flow shape compression for aggregate data reporting in an application manager
CN107251024B (zh) 用于诊断执行问题的数据库查询执行跟踪和数据生成
US8423973B2 (en) Instrumenting an application with flexible tracers to provide correlation data and metrics
US9009680B2 (en) Selecting instrumentation points for an application
US10540053B2 (en) Methods and systems for managing community information
US20100058113A1 (en) Multi-layer context parsing and incident model construction for software support
US20220188283A1 (en) Automatic discovery of executed processes
US20240152444A1 (en) Online query execution using a big data framework
US8589207B1 (en) System and method for determining and visually predicting at-risk integrated processes based on age and activity
US20170285923A1 (en) Multi-perspective application components dependencies
CA2684106A1 (en) Performing enterprise planning and economics analysis for reservoir-related services
US20130219044A1 (en) Correlating Execution Characteristics Across Components Of An Enterprise Application Hosted On Multiple Stacks
US20160013989A1 (en) Service discovery and/or effort estimation in networked computing environments
de Albuquerque Filho et al. OBAS: an OLAP benchmark for analysis services
Schwanke Faculty Informatics Bachelor of Science–Business Information Systems
Bruni et al. Subsystem and Transaction Monitoring and Tuning with DB2 11 for z/OS
Özcan Analysis and Design of Scalable Software as a Service Architecture
Parziale et al. Problem Determination for Linux on System z

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant