KR20120115476A - 복합 트랜잭션들에 대한 구조적 및 행동적 디스크립션을 사용하는 트랜잭션 모델 - Google Patents

Abstract

컴퓨터 시스템의 적어도 하나의 애플리케이션을 통하는 흐름들(flows)을 추적하기 위한 사용자 인터페이스를 제공하기 위하여 모델이 사용된다. 모델은 적어도 하나의 애플리케이션의 구조적 양상들을 비즈니스 트랜잭션 계층과 같은 행동적 모델에 관련시킨다. 모델의 구조적 부분은 링크된 버텍스 및 에지 레코드들을 포함한다. 컴포넌트의 서로 다른 인스턴스들을 위한 버텍스 레코드들이 통합(aggregation)되어 사용자 인터페이스 내에 디스플레이하기 위한 단일 버텍스 또는 노드를 제공한다. 버텍스 레코드는 에이전트 레코드 및 메트릭 경로 레코드에 링크된다. 에지 레코드들은 콜의 테일 및 헤드 컴포넌트들을 식별한다. 에지 레코드들의 세트는 모델의 행동적 부분의 트랜잭션 레코드와 관련될 수 있다. 트랜잭션 레코드는 비즈니스 트랜잭션 레코드와 관련될 수 있고, 비즈니스 트랜잭션 레코드는 비즈니스 서비스 레코드와 관련될 수 있다.

Description

복합 트랜잭션들에 대한 구조적 및 행동적 디스크립션을 사용하는 트랜잭션 모델{TRANSACTION MODEL WITH STRUCTURAL AND BEHAVIORAL DESCRIPTION OF COMPLEX TRANSACTIONS}

본 발명은 컴퓨팅 환경에서 소프트웨어를 모니터링하기 위한 기술에 관한 것이다.

인터넷(internet)뿐만 아니라 인트라넷(intranet)들 및 엑스트라넷(extranet)들과 같은 다른 컴퓨터 네트워크들의 증가는 전자상거래(e-commerce), 교육 및 다른 분야들에서 많은 새로운 애플리케이션들(applications)을 가져왔다. 기관들은 그들의 비즈니스 또는 다른 목표들을 수행하기 위하여 더욱더 그러한 애플리케이션들에 의존하고, 그 애플리케이션들이 기대하는 바대로 수행되는 것을 보장하기 위하여 상당한 자원을 사용하고 있다. 이를 위하여, 다양한 애플리케이션 관리 기법들이 개발되어왔다.

일 기법은 애플리케이션 내에서 호출되는 개별적인 소프트웨어 컴포넌트들과 관련된 애플리케이션의 런타임(runtime) 데이터들을 수집함으로써 해당 애플리케이션의 인프라구조를 모니터링하는 것이다. 상기 기법은 모니터링되고 있는 시스템 내에 근본적으로 존재하는 에이전트들을 이용할 수 있다. 예를 들어, 해당 소프트웨어의 인스트루먼테이션(instrumentation)을 사용함으로써, 호출되는 각 컴포넌트들을 식별하고 또한 각 컴포넌트의 실행 시간과 같은 런타임 데이터(runtime data)를 획득할 수 있도록, 쓰레드 또는 프로세스가 트레이싱될 수 있다. 트레이싱은 컴퓨터 프로그램이 실행시키는 단계들의 상세한 기록, 즉 트레이스(trace)를 획득하는 것을 의미한다. 트레이스의 한 종류는 스택 트레이스이다. 트레이스들은 디버깅(debugging)에서의 보조 수단으로 사용될 수도 있다.

그러나, 문제점들의 진단은 여전히 어렵고 시간 소모적인 일로 남아있다. 예를 들어, 트랜잭션 또는 애플리케이션이 실패(fail)할 때, 그 제공자는 정확히 무엇이 잘못되었는지, 그리고 왜 잘못되었는지 알고자 한다. 따라서 향상된 진단 기법들이 필요하다.

본 발명은 컴퓨터 시스템의 적어도 일 애플리케이션을 통하는 흐름들을 추적함으로써 컴퓨터 시스템에서의 문제들을 진단하는 방법을 제공한다.

일 실시예에서, 적어도 하나의 애플리케이션들을 통하는 흐름들을 추적하는 모델을 제공하도록 적어도 하나의 프로세서를 프로그래밍하기 위하여, 프로세서-판독가능 소프트웨어가 수록된, 적어도 하나의, 유형의(tangible) 비일시적(non-transitory) 프로세서-판독가능 저장 장치가 제공된다. 상기 모델은, (a) 상기 적어도 하나의 애플리케이션과 관련된 트랜잭션들 동안에 호출되는 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들과, (b) 상기 소프트웨어 컴포넌트들 간의 콜들을 식별하는 에지 레코드들과, 상기 에지 레코드들은 상기 버텍스 레코드들에 링크되고, (c) 상기 트랜잭션들을 식별함과 아울러 상기 에지 레코드들에 링크되는 트랜잭션 레코드들과, 상기 트랜잭션 레코드들은 트랜잭션 계층으 fskxksoau, 상기 트랜잭션 계층은 상기 트랜잭션 계층의 일 레벨에서의 트랜잭션들 및 상기 트랜잭션 계층의 제1 상위 레벨(first higher level)에서의 트랜잭션들의 하나 이상의 그룹들을 포함하고, (d) 서로 다른 에이전트들에 의해 모니터링되는 복수의 인스턴스들을 구비한 소프트웨어 컴포넌트들 중 적어도 하나를 포함하며, 그리고 (e) 상기 서로 다른 에이전트들에 의해 모니터링되는 복수의 인스턴스들을 구비한 소프트웨어 컴포넌트들 중 적어도 하나에 대해, 상기 버텍스 레코드들은 상기 서로 다른 에이전트들에 대한 서로 다른 버텍스 레코드들, 및 상기 서로 다른 버텍스 레코드들의 어그리게이션을 나타내는 공통 버텍스 레코드를 포함한다.

또 다른 실시예에서, 적어도 하나의 애플리케이션들을 통하는 흐름들을 추적하는 모델을 제공하는 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하기 위하여, 프로세서-판독가능 소프트웨어가 수록된, 적어도 하나의, 유형의(tangible) 비일시적(non-transitory) 프로세서-판독가능 저장 장치가 제공된다. 이 방법은, (a) 적어도 하나의 애플리케이션과 관련된 트랜잭션들 동안 호출되는 소프트웨어 컴포넌트들을 모니터링하는 에이전트들로부터 데이터를 수신하는 단계와, 상기 데이터는 상기 소프트웨어 컴포넌트들 중 적어도 하나에 대한 정보의 필드들을 포함하고, (b) 상기 모델이 상기 정보의 필드들과 일치하는 버텍스 레코드를 포함하는지 결정하는 단계와, (c) 상기 모델이 상기 버텍스 레코드를 포함하지 않으면, 상기 모델 내에 상기 소프트웨어 컴포넌트들 중 상기 적어도 하나를 나타내는 버텍스 레코드를 제공하는 단계와, (d) 상기 정보의 필드들에 근거하여, 상기 소프트웨어 컴포넌트들 중 적어도 하나와 관련된 콜을 식별하는 에지 레코드를 제공하는 단계와, (e) 상기 에지 레코드를 상기 버텍스 레코드에 링크하는 단계와, (f) 상기 정보의 필드들에 근거하여, 상기 소프트웨어 컴포넌트들 중 적어도 하나와 관련(involve)되는 상기 트랜잭션들 중 하나를 식별하는트랜잭션 레코드를 제공하는 단계와, 그리고 (g) 상기 트랜잭션 레코드를 상기 에지 레코드에 링크하는 단계를 포함한다.

또 다른 실시예에서, 적어도 하나의 애플리케이션들을 통하는 흐름들을 추적하는 모델을 제공하는 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하기 위하여, 프로세서-판독가능 소프트웨어가 수록된, 적어도 하나의, 유형의(tangible) 비일시적(non-transitory) 프로세서-판독가능 저장 장치가 제공된다. 이 방법은, (a) 상기 적어도 하나의 애플리케이션과 관련된(involving) 트랜잭션들 동안에 호출되는 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들을 제공하는 단계와, (b) 상기 소프트웨어 컴포넌트들 사이의 콜들을 식별하는 에지 레코드들을 제공하는 단계와, 상기 에지 레코드들은 상기 버텍스 레코드들에 링크되고, (c) 상기 트랜잭션들을 식별함과 아울러 상기 에지 레코드들에 링크되는 트랜잭션 레코드들을 제공하는 단계와, 상기 트랜잭션 레코드들은 트랜잭션 계층을 나타내고, 상기 트랜잭션 계츠은 상기 트랜잭션 계층의 일 레벨에서의 트랜잭tus들 및 상기 트랜잭션 계층의 제1의 상위 레벨에서의 트랜잭션들의 하나 이상의 그룹들을 포함하고, 그리고 (d) 사용자 인터페이스 디스플레이 내에 유향 그래프(directed graph)를 제공하는 단계를 포함하며, 상기 유향 그래프는 상기 버텍스 레코드들에 근거한 버텍스들과 상기 에지 레코드들에 근거한 에지들을 포함하고, 상기 버텍스들은 상기 트랜잭션 계층에 따라 배열된다.

실행되는 경우에 본 명세서에서 제공된 상기 방법을 수행하는 명령들로 인코딩된 저장 매체를 포함하는 컴퓨터 판독 가능 또는 프로세서 판독 가능 저장 장치들 및 대응하는 방법들, 시스템들이 제공될 수 있다.

도 1은 관리되는(managed) 애플리케이션을 포함하는 시스템을 보여주는 도면이다.
도 2a는 트랜잭션에 대한 트레이싱을 시작하는 프로세스의 한 가지 실시예를 표시하는 흐름도이다.
도 2b는 트랜잭션의 실행시간을 완성하기 위한 프로세스의 한 가지 실시예를 표시하는 흐름도이다.
도 2c는 도 1의 네트워크의 컴퓨팅 장치를 보여주는 도면이다.
도 3은 하나 이상의 애플리케이션들의 동작을 기술하는 데 사용되는 계층구조를 보여주는 도면이다.
도 4a는 트랜잭션에서 호출된 컴포넌트들의 한 가지 예시적인 시퀀스(sequence)에서의 종속 관계들을 보여주는 도면이다.
도 4b1은 도 4a의 가능한 컴포넌트들의 시퀀스에 근거하여, 트랜잭션에서 호출된 컴포넌트들의 시퀀스들을 위한 예시적인 트랜잭션 트레이스들을 보여주는 도면이다.
도 4b2는 도 4b1의 예시적인 트랜잭션 트레이스들에서 대기 기간(waiting period)들을 보여주는 도면이다.
도 4b3은 종속적인 인스트루먼트된(instrumented) 서브시스템들의 시퀀스에 대하여, 총 지속시간(total duration), 네트 지속시간(net durations), 대기 시간, 및 서브시스템 간 통신 시간들을 결정하기 위한 방법을 보여주는 도면이다.
도 5a는 서브시스템들 및 비즈니스 트랜잭션들의 사용자 인터페이스(UI)로서, 비즈니스 서비스가 사용자에 의하여 선택된 것을 상세히 보여주는 도면이다.
도 5b은 서브시스템들 및 비즈니스 트랜잭션들의 사용자 인터페이스(UI)를 도시하며, 여기서 비즈니스 서비스는 상기 사용자에 의해, 도 5a의 UI에 대안적인 요약 보기로 선택되었다.
도 5c는 도 5b의 사용자 인터페이스를, 로그인 비즈니스 트랜잭션(304)를 위한 메트릭들을 보여주는 호버 박스를 추가한 상태로 도시한다.
도 5d는 도 5b의 사용자 인터페이스를, 인증서비스 서브시스템(322)을 위한 메트릭들을 보여주는 호버 박스를 추가한 상태로 보여주는 도면이다.
도 5e는 도 5b의 사용자 인터페이스를, 로그인 비즈니스 트랜잭션(304)를 위한 옵션(option)들을 보여주는 호버 박스를 추가한 상태로 보여주는 도면이다.
도 5f는, 도 5e의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 실행된, 로그인 비즈니스 트랜잭션의 맵(map)에 대한 사용자 인터페이스를 보여주는 도면이다.
도 5g는, 도 5e의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 실행된, 로그인 비즈니스 트랜잭션을 위하여 대응 트랜잭션들의 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5h는 선택된 비즈니스 트랜잭션의 콘텍스트(context) 내에서 인증서비스 서브시스템을 위하여 매칭 트랜잭션들을 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5i은 다수의 비즈니스 트랜잭션들의 콘텍스트 내에서 인증서비스 서브시스템을 위하여 매칭 트랜잭션들을 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5j는 로그인의 서브시스템들 중 일부만이 선택된 비즈니스 트랜잭션 인스턴스에 의하여 호출되는 경우의 사용자 인터페이스를 보여주는 도면이다.
도 5k는, 도 5e의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인의 위치들에 대한 사용자 인터페이스를 보여주는 도면이다.
도 5l는, 도 5e의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인 비즈니스 트랜잭션의 건강도 메트릭(health metric)의 사용자 인터페이스를 보여주는 도면이다.
도 5m는, 사용자가 버텍스(322)와 보조 영역(562)의 "상세"(details) 탭을 선택한 후에, 도 5k의 사용자 인터페이스를 보여주는 도면이다.
도 5n는, 도 5g의 사용자 인터페이스로부터 론치될 수 있는, 선택된 트랜잭션 인스턴스를 위한 트랜잭션 트레이스들을 보여주는 도면이다.
도 6a는 적어도 하나의 애플리케이션을 통하는 흐름들을 추적하기 위한 모델을 도시한다.
도 6b는 도 6a의 모델에 따른 예시적인 버텍스 레코드를 도시한다.
도 6c는 도 6a의 모델에 따른 예시적인 에지 레코드를 도시한다.
도 6d는 도 6a의 모델에 따른 예시적인 에이전트 레코드를 도시한다.
도 6e는 도 6a의 모델에 따른 예시적인 메트릭 경로 레코드를 도시한다.
도 6f는 도 6a의 모델에 따른 예시적인 에지 소유자 레코드를 도시한다.
도 6g는 도 6a의 모델에 따른 예시적인 트랜잭션 레코드를 도시한다.
도 6h는 도 6a의 모델에 따른 예시적인 비즈니스 트랜잭션 레코드를 도시한다.
도 6i는 도 6a의 모델에 따른 예시적인 비즈니스 서비스 레코드를 도시한다.
도 7aa는 도 5a의 유향 그래프의 상세 보기를 위한 예시적인 버텍스 표를 도시한다.
도 7ab는 도 7aa의 예시적인 버텍스 표가 계속된 것을 도시한다.
도 7b는 도 5b의 유향 그래프의 요약 보기를 위한 예시적인 버텍스 표를 도시한다.
도 7ca는 도 5a의 유향 그래프의 상세 보기를 위한 예시적인 에지 표를 도시한다.
도 7cb는 도 5b의 유향 그래프의 요약 보기를 위한 예시적인 에지 표를 도시한다.
도 7d는 도 5a의 유향 그래프를 위한 예시적인 에지 소유자 표를 도시한다.
도 7e는 도 5a의 유향 그래프를 위한 예시적인 트랜잭션 표를 도시한다.
도 7f는 도 5a의 유향 그래프를 위한 예시적인 비즈니스 트랜잭션을 도시한다.
도 7g는 도 5a의 유향 그래프를 위한 예시적인 비즈니스 서비스 표를 도시한다.
도 8a는 도 5a의 트레이드서비스의 복수의 인스턴스들을 위한 물리적 버텍스 레코드들의 예를 도시한다.
도 8b는 도 5a의 TradeOptions|Service 컴포넌트의 인스턴스를 위한 버텍스 레코드 및 도 8a로부터 의 부모 버텍스 레코드(802)의 예를 도시한다.
도 8c는 TradeOptions|Service 컴포넌트가 도 5a의 WebServices1 웹서비스를 콜할 때 에지 레코드 및 버텍스 레코드들의 예를 도시한다.
도 9는 사용자 인터페이스를 제공하기 위한 방법을 도시한다.
도 10은 도 9의 단계 907에서 모델을 갱신하는 예시적인 방법을 도시한다.

본 발명은 컴퓨터 시스템의 적어도 하나의 애플리케이션을 통하는 흐름들을 추적함으로써 컴퓨터 시스템 내의 문제점들을 진단하는 방법을 제공한다.

비즈니스 트랜잭션 또는 애플리케이션이 실패할 때, 그 제공자는 정확히 무엇이 잘못되었고 왜 잘못되었는지를 알기 원한다. 비즈니스 트랜잭션은, 웹사이트에서의 로그인, 물품의 주문 등과 같이, 고객 입장에서의 작업(task)을 의미할 수 있다. 어떤 경우에는 상기 문제가 일반적이고(트랜잭션이 매번 실패하는 경우), 어떤 경우들에서는 좀 더 구체적(specific)이다. 예를 들어, 트랜잭션은 오직 특정 사용자가 시도했을 경우에만 실패하거나, 특정 종류의 항목(item)이 요청되었을 경우에만 실패할 수 있다. 그러한 문제가 일반적인 것인지 구체적인 것인지 결정하는 것은 해결하기 어려운 문제일 수 있으며, 상기 문제의 원인을 찾아내는 것은 더더욱 그러하다.

일반적 및 구체적 경우들을 위하여 서로 다른 진단 툴(tool)들이 제공된다. 예를 들어, 일반적인 경우에 대처하기 위하여 유향 그래프(directed graph)(또한 분류 맵(triage map) 또는 애플리케이션 맵이라고도 칭해짐)이 사용될 수 있는데, 이는 상기 분류 맵이 트랜잭션들을 취합(aggregate)하고 연관된 논리적 서브시스템들이 상호작용할 수 있는 모든 가능한 방법들을 보여주기 때문이다. 상기 분류 맵은 또한 서브시스템 각각의 전체적인 건강도(health)를 보여준다. 가장 구체적인 경우(the most specific case)를 처리하기 위해서는 트랜잭션 트레이싱 툴이 사용될 수 있다. 상기 툴은, 트랜잭션들이 시스템을 통과함(pass through)에 따라, 개별적인 트랜잭션들을 시기록 하위 메소드 콜(timed low-level method call)들의 시퀀스로서 기록하고 보여준다. 문제는 상기 두 개의 툴들 사이에 큰 폭의 간극이 존재한다는 점이다. 유향 그래프가 지나치게 일반적이고 거시적(coarse-grained)이라면, 트랜잭션 트레이서는 너무 구체적이고 미시적(granular)일 수 있다. 유향 그래프로부터 시작하여 어떤 잘못된-일반적인 경향-도 발견하지 못한 사용자는 트랜잭션 트레이스들의 풀링(pulling)을 시작하고 패턴을 파악하기 위하여 그 트레이스들을 검토(browse through)하여야 한다. 문제점을 다시 서브시스템 수준으로 매핑(mapping)하는 것은 해당 소프트웨어 및 기반이 되는 인프라구조 모두에 대한 완전한 지식을 필요로 한다.

따라서 두가지 시각화들(visualizations)을 결합할 필요, 즉 개별적인 트랜잭션들을 논리적 서브시스템을 통하는 일련의 시기록 단계들(timed steps)로서 보여주어야 할 필요가 있다. 하나의 가능한 해결책은, 사용자로 하여금 개별적인 트랜잭션 트레이스(또는 관련된 트레이스들의 집합)을 관련된 유향 그래프 위에 겹쳐지도록(overlay) 하는 것이다. 따라서, 만약 특정 비즈니스 트랜잭션에 대하여 문제점이 보고된다면, 사용자는 먼저 해당 비즈니스 트랜잭션을 위한 유향 그래프를 확인한다. 만약 관련된 서브시스템들의 전체적인 건강도가 정상이라면, 사용자는 그 문제가 일반적인 문제점은 아니라고 인식하게 된다. 그 후 사용자는 상기 비즈니스 트랜잭션을 위한 트랜잭션 트레이스들을 요청한다. 상기 트랜잭션 트레이서는 상기 비즈니스 트랜잭션의 파라미터(parameter)들(예를 들어, 특정 URL 및 POST 파라미터)에 일치(match)하고 특정 지속시간을 초과하는 최근 트랜잭션들의 목록을 기록 및 제공하고, 사용자는 그 중 하나 이상을 "매핑"하도록 선택한다. 사용자는, 일정 패턴이 드러나는지, 예를 들어 일 특정 호스트(host)로부터 만들어진 데이터베이스 콜들이 지연에 대한 책임이 있는지를 확인하기 위하여, 가장 긴 트랜잭션들 모두(all the lengthiest transactions)를 한 번에 하나씩 매핑하도록 선택할 수도 있다.

매핑된 트랜잭션은 현재 맵의 하이라이트된 일부분으로 나타나게 되고, 각각의 버텍스 위 그리고 각각의 관련 에지(edge) 옆에 지속시간들도 함께 보여진다. 에지는 서브시스템들 사이의 전이(transition)이고, 맵에서 화살표로 표시된다. 즉, 해당 트랜잭션에서 활성화된 서브시스템들은, 일 서브시스템으로부터 다음 서브시스템으로의 콜을 표현하는 에지들과 함께, 맵에서 하이라이트되어 나타난다. 서브시스템에서 소비된 총 시간이 버텍스 상에 나타나되고, 서브시스템들 간 콜들의 길이는 에지 옆에 표시된다. 상기 맵에서 최장 총 지속시간을 갖는 컴포넌트는 시계 모양과 같은 특별한 아이콘(icon)으로 표시된다. 다수의 트랜잭션들을 겹쳐서 나타내는 경우에 있어서는, 평균 지속시간이 화면에 보여질 수 있다는 점을 유의할 필요가 있다. 개별적인 지속시간들은 툴팁(tooltip) 안, 호버(hover) 위에 제공될 수 있다.

더 나아가, 사용자 인터페이스의 보조 영역은 추가적인 옵션들 및 정보를 제공할 수 있다. 제1 탭은 결과값으로 반환된(returned) 트랜잭션들(트랜잭션 리스트)를 포함하여, 사용자가 어떤 항목들이 선택되었는지(그리고 상기 맵에 겹쳐져 표시되는지)를 확인하고 수정할 수 있도록 할 수 있다. "더 보기" 버튼은 사용자로 하여금 동일한 파라미터들을 사용하여 더 많은 트랜잭션들을 기록할 수 있도록 한다. 상세 탭은 부모 서브시스템과 관련되는 트랜잭션 트레이스로부터의 메소드 콜들을 열거할 수 있다. 트레이스 보기 탭은 트랜잭션 트레이스를 제공할 수 있다. 하기에서 더 설명되는 바와 같이, 서로 다른 타입의 디자인 스크린들, 사용자 인터페이스들이 제공될 수 있다.

사용자 인터페이스를 통하여, 사용자는 유향 그래프의 서브시스템들 및 트랜잭션들 간의 관계들, 그리고 트랜잭션 인스턴스 데이터를 쉽게 감지할 수 있다.

도 1은 서로 다른 컴퓨팅 장치들이 관리자(manager)에게 데이터를 제공하는 네트워크(100)를 보여주고 있다. 예시적인 컴퓨팅 장치들(106, 110, 114)은 애플리케이션 서버들 또는, 원하는 기능을 성취하기 위하여 코드를 실행시키기 위한 프로세서를 구비한 어떠한 다른 종류의 컴퓨팅 장치들을 포함할 수 있다. 컴퓨팅 장치들은 서로에게서 멀리 떨어져 위치할 수도 있고 같은 곳에 위치할 수도 있다. 본 실시예에서 상기 컴퓨팅 장치들(106, 110, 114)은 로컬 관리자 컴퓨터(120)와 통신한다. 대안적으로 상기 관리자 컴퓨터(120)는 상기 컴퓨팅 장치들(106, 110, 114)과 떨어져 있을 수도 있는데, 이 경우 통신은 네트워크 클라우드(104)를 통하여 이루어질 수 있다.

예를 들어, 웹 기반 전자상거래 애플리케이션과 같은 기업 애플리케이션을 운영하는 회사는, 작업량 균형 배분(load balancing)을 위하여 일 위치에서 여러 대의 애플리케이션 서버들을 활용할 수 있다. 예를 들어 사용자의 웹 브라우저(102)로부터의 요청과 같은, 사용자들로부터의 요청들은 인터넷과 같은 네트워크 클라우드(104)를 통하여 수신되고, 상기 컴퓨팅 장치들(106, 110, 114) 중 어느 하나로 전달된다. 웹 브라우저(102)는 통상적으로, 도면에는 보이지 않았지만 인터넷 서비스 제공자(internet service provider)를 통하여 상기 네트워크 클라우드(104)에 액세스한다. 한 가지 방식에서, 각각 에이전트 A1(108), 에이전트 A2(112), 및 에이전트 A3(116)로 표시된, 상기 컴퓨팅 장치들(106, 110, 114)에서 실행되는 에이전트 소프트웨어는 상기 컴퓨팅 장치들(106, 110, 114)에서 실행 중인 애플리케이션, 미들웨어(middleware), 또는 다른 소프트웨어로부터 정보를 수집한다. 예를 들어, 그러한 정보는 인스트루먼테이션을 이용하여 얻어질 수 있는데, 그러한 한 가지 예는 바이트 코드 인스트루먼테이션(byte code instrumentation)이다. 그러나, 다른 방식으로도 상기 수집 데이터가 얻어질 수 있다. 에이전트들은 근본적으로 모니터링되는 컴퓨팅 장치 안에 존재하며, 데이터 수집 지점(data acquisition point)을 제공한다. 상기 에이전트들은 상기 관리자(120)에 통신되는 데이터를 조직화(organize)하고 최적화(optimize)한다.

관리자(120)는 워크 스테이션과 같은 별도의 컴퓨팅 장치에 제공될 수 있는데, 이 컴퓨팅 장치는, 상기 에이전트들로부터 수신된 데이터에 근거하여 정보를 나타내도록, 모니터와 같은 사용자 인터페이스(122)와 통신한다. 상기 관리자는 또한 상기 에이전트들로부터 수신된 데이터를 저장하기 위하여 데이터베이스(118)에 액세스할 수도 있다. 본 실시예에서, 상기 컴퓨팅 장치들은 네트워크 클라우드(104)에 액세스하지 않은 채로 상기 관리자 컴퓨터(120)와 통신한다. 예를 들어, 상기 통신은 근거리 통신망(local area network)을 통하여 이루어질 수 있다. 다른 설계에서는, 상기 관리자(120)가 네트워크 클라우드(104)를 통하여 많은 컴퓨팅 장치들의 에이전트들로부터 데이터를 수신할 수 있다. 예를 들어, 일부 대형 조직들은 중앙 네트워크 처리 센터(central network operations center)를 활용하는데, 여기서는 하나 이상의 관리자들이 서로 다른 지리적 위치들에 있는 수 많은 분산된 에이전트들로부터 데이터를 획득한다. 설명을 위하여, 웹 기반 전자상거래 기업은, 고객 주문을 수령하는 서로 다른 지리적 위치의 서버들로부터, 지불(payment)을 처리하는 서버들로부터, 재고를 관리하고 주문들을 처리하는 물류창고(warehouse)의 서버들로부터, 그리고 기타 서버들로부터 에이전트 데이터를 획득할 수 있다. 상기 관리자(120) 및 사용자 인터페이스 디스플레이(122)가 기업 본사의 위치에 제공될 수 있다. 꼭 웹 기반이거나 소매 또는 기타 판매와 관련되지 않은 다른 애플리케이션들도, 그들의 시스템들을 관리하기 위하여 유사하게 에이전트들 및 관리자들을 활용할 수 있다. 예를 들어, 은행은 수표들 및 신용카드 계정들을 처리하기 위한 애플리케이션을 사용할 수 있다. 더 나아가, 상기 언급된 다수의 컴퓨팅 장치들의 구성에 더하여, 단일 컴퓨팅 장치도 또한 마찬 가지로 하나 이상의 에이전트들로 모니터링될 수 있다.

실행 상태를 모니터링하는 인스트루먼테이션 소프트웨어를 위한, 다양한 방법(approach)들이 알려져 있다. 예를 들어, 본 명세서의 도입부에서 언급한 바와 같이, 소프트웨어의 실행을 추적하기 위하여 트레이싱이 사용될 수 있다. 트레이싱의 한 예는 "트랜잭션 트레이서"(Transaction Tracer)라는 제목으로 2004년 4월 22일 발행된 미국 특허 2004/0078691에 설명되어 있는데, 본 명세서에 참조 인용되어 있다. 상기 특허에서 논의되는 일 방법에서는, 모니터링하고자 하는 애플리케이션의 오브젝트 코드(object code) 또는 바이트 코드(byte code)가 프로브(probe)들과 함께 인스트루먼테이션, 예를 들어, 수정된다. 상기 프로브들은, 해당 애플리케이션의 비즈니스 또는 기타 로직(business or other logic)을 바꾸지 않고, 해당 애플리케이션에 대한 구체적인 정보를 측정한다. 일단 상기 프로브들이 애플리케이션의 바이트 코드 안에 설치되면, 해당 프로그램은 관리되는 애플리케이션이라고 불린다. 상기 에이전트 소프트웨어는 상기 프로브들로부터 정보를 입수하고, 상기 정보를 다른 프로세스, 즉 관리자(120)에 있는 프로세스에게 전달하거나, 또는, 상기 정보가 비정상적인 상태를 보여주고 있는지 여부를 결정하기 위한 것처럼, 상기 정보를 국지적으로(locally) 처리할 수도 있다. 따라서 상기 에이전트들은 상기 프로브들로부터 수신된 정보들을 수집하고 요약한다. 상기 프로브들은 지시 파일(directive file)에 정의된 바대로 정보를 수집한다. 예를 들어, 상기 프로브들로부터의 정보는, 트랜잭션 또는 다른 실행 흐름의 시작 및 정지 시간, 또는 트랜잭션/실행 흐름 내의 개별적인 컴포넌트들의 시작 및 정지 시간들을 나타낼 수 있다. 상기 정보는, 그 정보가 주어진 한계 안에 있는지 결정하기 위하여 사전 설정된 기준치들(criteria)과 비교될 수 있다. 만약 상기 정보가 한계치들 안에 있지 않으면, 상기 에이전트는 이러한 사실을 상기 관리자에게 보고하여, 적절한 문제 해결 절차(troubleshooting)가 수행될 수 있도록 한다. 상기 에이전트들(108, 112, 116)은 통상적으로, 그들이 각각 연계되어 있는 국지적(local) 컴퓨팅 장치들(106, 110, 114) 위에서 실행되는 소프트웨어를 인식하고 있다.

상기 프로브들은 메트릭들의 표준 세트들을 보고할 수 있는데, 상기 메트릭들은, CORBA 메소드 타이머들(method timers), 원격 메소드 호출(RMI: romote method invocation), 쓰레드 카운터들(thread counters), 네트워크 대역폭(network bandwidth), JDBC 업데이트 및 쿼리 타이머들(query timers), 서블릿 타이머들(servelet timers), JSP 타이머들(Java Server Pages timers), 시스템 로그들(system logs), 파일 시스템 입력 및 출력 대역폭 메트릭들(bandwidth meters), 잔여 및 사용중인 메모리 및 EJB(Enterprise JavaBean) 타이머들을 포함한다. 메트릭은 특정 애플리케이션 활동에 대한 측정값(measurement)을 의미한다.

에이전트는 트랜잭션들에 관한 정보를 보고하는데, 애플리케이션에 의하여 액세스(access)되는 리소스(resource)들을 식별한다. 일 기법에서는, 트랜잭션들에 대하여 보고할 때, "Called"라는 용어가 상기 리소스를 가리킨다. 상기 리소스는, 소비자(consumer)인 부모 컴포넌트의 리소스(또는 서브리소스(sub-resource))이다. 예를 들어, 서블릿 A가 트랜잭션에서 호출되는 첫 번째 컴포넌트라고 가정하기로 한다. 상기 소비자 서블릿 A 아래에는, 서브리소스 Called EJB가 존재할 수 있다. 상기 에이전트에 의하여 소비자들 및 리소스들은 트리와 같은 형태로 보고될 수 있다. 트랜잭션을 위한 데이터는 또한 상기 트리에 의거하여 저장될 수 있다. 예를 들어, 만약 서블릿(예를 들어 서블릿 A)이 네트워크 소켓(network socket)의 소비자이고, 또한 순차적으로 BC(예를 들어 JDBC D)의 소비자인 EJB(예를 들어 EJB B)의 소비자라고 하면, 상기 트리는 다음과 같은 모양을 갖출 수 있다:

서블릿 A

서블릿 A를 위한 데이터

Called EJB B

EJB B를 위한 데이터

Called JDBC D

JDBC D를 위한 데이터

Called 소켓 C

소켓 C를 위한 데이터

일 실시예에서, 상기 트리는 상기 에이전트에 의하여, 블레임 스택(blame stack)이라고 하는 스택 안에 저장된다. 트랜잭션들이 시작될 때, 상기 트리는 스택 속으로 푸쉬(push)된다. 상기 트랜잭션들이 완료되면, 상기 트리는 스택으로부터 팝(pop)된다. 일 실시예에서, 스택 위의 각각의 트랜잭션은 다음과 같은 정보들: 즉, 트랜잭션의 종류, 해당 트랜잭션을 위한 시스템에 의해 사용되는 이름, 파라미터들의 해쉬 맵(hash map), 해당 트랜잭션이 언제 스택에 푸쉬되었는지에 대한 타임스탬프, 그리고 서브-요소(sub-element)들을 저장하게 된다. 서브-요소들이란, 해당 트랜잭션 내부로부터 실행되는, 다른 컴포넌트들을 위한 블레임 스택 엔트리(entry)들(예를 들어, 메소드들, 프로세스들, 프로시저들(procedures), 함수들(functions), 쓰레드들, 명령세트(set of instructions), 등)을 말한다. 트리를 상기 예시한 바와 같이 사용함으로써, 서블릿 A를 위한 블레임 스택 엔트리는 두 개의 서브-요소들을 구비하게 된다. 제1 서브-요소는 EJB B를 위한 엔트리이고, 제2 서브-요소는 소켓 스페이스(socket space) C를 위한 엔트리이다. 비록 서브-요소가 특정 트랜잭션을 위한 한 엔트리의 일부이지만, 상기 서브-요소는 또한 그 자신의 블레임 스택 엔트리를 갖는다. 상기 트리에 보인 바와 같이, EJB B는 서블릿 A의 서브-요소이고, 또한 그 자신의 엔트리를 가지고 있다. 트랜잭션을 위한 상기 최상위(또는 초기) 엔트리(예를 들어, 서블릿 A)는 루트 컴포넌트(root component)라고 불린다. 상기 스택 위의 엔트리들 각각은 오브젝트(object)이다.

도 2a는 트랜잭션의 트레이싱을 시작하기 위한 프로세스의 한 가지 실시예를 설명하는 흐름도이다. 각 단계들은 적절한 에이전트(들)에 의하여 수행된다. 단계 130에서, 트랜잭션이 시작된다. 실시예에서, 프로세스는 메소드의 시작(예를 들어, "loadTracer" 메소드의 콜)에 의하여 트리거(triggered)된다. 단계 132에서는, 에이전트가 원하는 파라미터 정보를 획득한다. 일 실시예에서, 사용자는 설정 파일(configuration file) 또는 사용자 인터페이스를 통하여 어느 파라미터 정보가 얻어져야 하는지를 설정할 수 있다. 획득된 파라미터들은 해쉬 맵에 저장되는데, 상기 해쉬 맵은 블레임 스택에 푸쉬되는 오브젝트의 일부이다. 다른 실시예에서는, 파라미터들의 식별이 사전에 설정된다. 저장될 수 있는 많은 서로 다른 파라미터들이 존재한다. 일 실시예에서, 실제 사용되는 파라미터들의 목록은 모니터링되는 애플리케이션에 의존적이다. 아래의 테이블은 획득될 수 있는 일부 파라미터들의 예들을 제공하고 있다.

파라미터	등장 위치	값
UserID	Servlet, JSP	http 서블릿 요청을 호출하는 엔드유저(end-user)의 사용자 ID
URL	Servlet, JSP	Query String을 포함하지 않는, 서블릿 또는 JSP에 전달되는 URL
URL Query	Servlet, JSP	http 요청 중 query 파라미터들을 지정하는 URL의 일부분 ("?" 분리자 뒤의 텍스트)
동적 SQL	동적 JDBC Statements	일반적인 형태이거나, 또는 해당 호출로부터의 모든 구체적 파라미터들을 갖춘, 동적 SQL 문장
Method	Blamed Method timers (Servlet, JSP, 및 JDBC를 제외한 모든 것)	트레이싱된 메소드의 이름 만약 트레이싱된 메소드가 동일한 컴포넌트 내에서 다른 메소드를 직접 콜하는 경우, 오직 최초의 최외곽 메소드만이 획득됨.
Callable SQL	Callable JDBC statements	일반적인 형태이거나, 또는 해당 호출로부터의 모든 구체적 파라미터들을 갖춘, Callable SQL 문장
Prepared SQL	Prepared JDBC statements	일반적인 형태이거나, 또는 해당 호출로부터의 모든 구체적 파라미터들을 갖춘, Prepared SQL 문장
Object	All non-static methods	트레이싱된 컴포넌트의 'this' 오브젝트의 'toString()'으로서, 일정 상한의 문자들로 잘려진 결과물
Class Name	All	트레이싱된 컴포넌트의 클래스의 정식이름
Param_n	WithParams custom tracer들을 갖춘 모든 오브젝트	컴포넌트의 트레이싱되는 메소드에 전달되는 n번째 파라미터의 toString()
Primary Key	Entity Beans	entity bean의 property key의 toString()으로서, 일정 상한의 문자들로 잘려진 결과물

파라미터들은 쿼리(query), 쿠키(cookie), 포스트(post), URL 및 세션 종류 이름/값 쌍(session type name/value pair)들을 포함할 수 있다.

단계 134에서, 상기 시스템은 현재 시간을 나타내는 타임스탬프를 획득한다. 단계 136에서, 스택 엔트리가 생성된다. 단계 138에서, 상기 스택 엔트리는 블레임 스택으로 푸쉬된다. 일 실시예에서, 타임스탬프가 단계 138의 일부로 추가된다. 상기 프로세스는 트랜잭션이 시작되는 경우에 수행된다. 트랜잭션의 서브-컴포넌트(sub-component)(예를 들어, EJB B는 서블릿 A의 서브-컴포넌트임 - 상기 설명 참조)가 시작되는 경우도 유사한 프로세스가 수행된다.

도 2b는 트랜잭션의 트레이싱을 완료하기 위한 프로세스의 한 가지 실시예를 설명하는 흐름도이다. 상기 프로세스는 트랜잭션이 종료되는 경우에 에이전트에 의하여 수행된다. 단계 140에서, 상기 프로세스는 트랜잭션(예를 들어, 메소드) 종료(예를 들어, "finishTrace" 메소드의 콜)에 의하여 트리거된다. 단계 142에서, 상기 시스템은 현재 시간을 획득한다. 단계 144에서는, 스택 엔트리가 제거된다. 단계 146에서는, 상기 단계 142로부터의 타임스탬프를 스택 엔트리에 저장된 타임스탬프와 비교함으로써 트랜잭션의 실행 시간이 계산된다. 단계 148에서는, 상기 트레이스를 위한 필터(filter)가 적용된다. 예를 들어, 상기 필터는 1초의 임계(threshold) 기간을 포함할 수 있다. 따라서, 단계 148은 상기 단계 146으로부터 계산된 지속기간이 1초보다 큰지를 결정하는 것을 포함한다. 만약 상기 임계이 초과되지 않는다면(단계 150), 상기 트랜잭션의 데이터는 제거된다. 일 실시예에서는, 전체 스택 엔트리가 제거된다. 다른 실시예에서는, 오직 파라미터들 및 타임스탬프들만이 제거된다. 또 다른 실시예들에서는, 데이터의 다양한 부분집합들이 제거될 수 있다. 일부 실시예들에서, 만약 임계 기간이 초과되지 않는다면, 해당 데이터는 상기 에이전트에 의하여 도 1의 다른 컴포넌트들에게 전송되지 않는다. 만약 상기 지속시간이 상기 임계 기간을 넘는다면(단계 (150), 상기 에이전트는 단계 160)에서 해당 컴포넌트 데이터(component data)를 형성(build)한다. 상기 컴포넌트 데이터는 보고될 트랜잭션에 관한 데이터이다. 일 실시예에서, 상기 컴포넌트 데이터는 트랜잭션 이름, 트랜잭션의 종류, 트랜잭션의 시작 시간, 트랜잭션의 지속시간, 파라미터들의 해쉬 맵, 및 모든 하부컴포넌트들(컴포넌트들의 재귀적(recursive)인 목록이 될 수 있음)을 포함한다. 또한 다른 정보들도 상기 컴포넌트 데이터의 일부가 될 수 있다. 단계 162에서, 상기 에이전트는 상기 컴포넌트 데이터를 TCP/IP 프로토콜을 통하여 상기 관리자(120)에 보냄으로써 상기 컴포넌트 데이터를 보고한다.

도 2b는 트랜잭션이 종료될 때 어떤 일이 발생하는지를 보여준다. 그러나 서브-컴포넌트가 종료될 때는, 수행되는 단계들은, 타임스탬프를 획득하는 단계, 해당 서브-컴포넌트를 위한 스텍 엔트리를 제거하는 단계, 그리고 완료된 서브-요소를 과거 스택 엔트리로 추가하는 단계를 포함한다. 일 실시예에서, 필터들 및 의사결정 로직(decision logic)은, 특정 서브-컴포넌트보다는, 해당 트랜잭션의 시작 및 종료에 적용된다.

일 실시예에서, 만약 트랜잭션 트레이서가 꺼져 있는 경우, 상기 시스템은 여전히 상기 블레임 스택을 사용한다; 하지만, 파라미터들은 저장되지 않고 어떠한 컴포넌트 데이터도 생성되지 않는다는 점을 유의해야 한다. 일부 실시예들에서, 상기 시스템은 트레이싱 기술이 꺼진 채로 시작하도록 초기 설정된다. 위에서 설명한 것처럼, 트레이싱은 사용자가 요청한 후에만 비로소 시작된다.

도 2c는 도 1의 네트워크의 컴퓨팅 장치를 보여준다. 컴퓨팅 장치(200)는, 도 1과 관련하여 설명된 것과 같은 웹 브라우저, 애플리케이션 서버, 관리자 및/또는 사용자 인터페이스들 중 하나로서 사용될 수 있는 시스템을 간략하게 표시한 것이다. 상기 컴퓨팅 장치(200)는 하드 디스크 또는 휴대용 매체와 같은 저장 장치(210), 다른 컴퓨팅 장치들과 통신하기 위한 네트워크 인터페이스(220), 소프트웨어 명령들을 실행하기 위한 프로세서(230), 예를 들어 상기 저장 장치(210)로부터 읽어들인 후에 소프트웨어 명령들을 저장하기 위한 RAM과 같은 작업 메모리(working memory)(240), 그리고 하나 이상의 비디오 모니터와 같은 사용자 인터페이스를 포함한다. 사용자 인터페이스에는 하나 또는 그 이상의 모니터들이 제공될 수 있다. 상기 저장 장치(210)는 유형의(tangible) 비일시적(non-transitory) 프로세서 또는 컴퓨터 판독 가능 저장 장치로서, 상기 프로세서(230)로 하여금 본 명세서에서 설명된 기능을 제공하기 위한 방법을 수행하도록 프로그래밍하기 위한, 프로세서 판독 가능한 코드들을 내장한 장치라고 할 수 있다. 상기 사용자 인터페이스 디스플레이(250)는 하나 이상의 에이전트들로부터 수신된 데이터에 근거하여 인간인 작업자에게 정보를 제공할 수 있다. 상기 사용자 인터페이스 디스플레이(250)는, 시각적이든, 표 형식이든, 또는 그와 유사한 다른 방식이든, 알려진 어떠한 디스플레이 방식도 사용할 수 있다. 화면 상의 디스플레이에 추가로, 프린터로 출력되는 것처럼 하드 카피(hard copy)와 같은 출력물이 제공될 수 있다.

저장 디바이스(210)가 가령, 어플리케이션 서버, 매니저 및/또는 사용자 인터페이스들과 같은 컴퓨팅 디바이스(200)의 일부인 경우, 데이터 베이스(118)는 저장 디바이스(210)에 포함될 수 있다. 저장 디바이스(210)는 하나 이상의 에이전트로부터 수신된 데이터를 저장하는 하나 이상의 저장 디바이스들을 나타낼 수 있으며 그리고 저장 디바이스는, 본 명세서에 서술된 바와 같이 데이터를 획득하여 사용자 인터페이스를 제공하도록 액세스될 수 있다. 저장 디바이스(210)는 데이터 저장매체(data store)를 나타낼 수 있다.

또한, 본 명세서에 서술된 기능들은 하드웨어, 소프트웨어, 혹은 하드웨어와 소프트웨어 둘다의 조합을 이용하여 구현될 수 있다. 소프트웨어의 경우, 하나 이상의 프로세서들을 프로그래밍하기 위한 프로세서 판독가능 코드가 내장되어 있는 하나 이상의, 일시적이지 않으며 실재하는(non-transitory, tangible) 프로세서 판독가능 저장 디바이스들이 이용될 수 있다. 일시적이지 않으며 실재하는(non-transitory, tangible) 프로세서 판독가능 저장 디바이스들은, 휘발성 및 비휘발성 매체, 착탈가능 및 비-착탈가능(non-removable) 매체와 같은 컴퓨터 판독가능 매체를 포함할 수 있다. 예를 들어, 일시적이지 않으며 실재하는 컴퓨터 판독가능 매체는, 컴퓨터 판독가능 명령들, 데이터 스트럭처들, 프로그램 모듈들 혹은 기타 데이터 등과 같은 정보의 저장을 위해 임의의 방법 혹은 기법으로 구현되는 휘발성, 비휘발성, 착탈가능, 및 착탈가능하지 않은 매체를 포함할 수 있다. 일시적이지 않으며 실재하는 컴퓨터 판독가능 매체의 일례들은, RAM, ROM, EEPROM, 플래시 메모리 혹은 다른 메모리 소자, CD-ROM, DVD(Digital Versatile Disk), 혹은 다른 광 디스크 스토지리, 마그네틱 카세트, 마그네틱 테이프, 마그네틱 디스크 스토리지 혹은 다른 마그네틱 저장 디바이스들, 혹은 원하는 정보를 저장하는데 이용될 수 있으며 그리고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 대안적인 실시예에서, 소프트웨어의 일부 혹은 전부는 커스텀 집적회로, 게이트 어레이들, FPGA, PLD, 그리고 특수 목적 프로세서들을 포함하는 전용 하드웨어로 대체될 수 있다. 일실시예에서는, 소프트웨어(저장 디바이스에 저장된)로 구현되는 하나 이상의 일례들이 이용되어 하나 이상의 프로세서들을 프로그래밍한다. 하나 이상의 프로세서는 하나 이상인 실재하는(tangible) 컴퓨터 판독가능 매체/저장 디바이스들, 주변회로들 및/또는 통신 인터페이스들과 통신할 수 있다.

도3은 하나 이상의 어플리케이션들의 동작을 설명하는데 이용되는 계층(hierarchy)을 도시한다. 서로 다른 레벨의 계층들이 임의의 바람직한 조직적인 구조(organizational structure)에 기초하여 정의될 수 있다. 예를 들어, 상기 계층은 인간을 상대하는 용어(human-facing terminology), 즉, 모니터링되는 어플리케이션과의 클라이언트의 상호작용에 대한 이해를 촉진시키는 용어를 포함할 수 있다. 상기 상호작용이 가령, 전자상거래(e-commerce transaction)와 같이 이득을 목적으로 하는 비즈니스, 교육 기관 혹은 정부 기관의 분야에 속하는지에 관계없이 상기 계층은 어플리케이션과의 임의 유형의 상호작용으로 확장될 수 있다. 또한, 하나 이상의 계층들은 상기 하나 이상의 계층들의 서로 다른 레벨들에서 노드들을 포함할 수 있는바, 여기서 각각의 노드는 서술적인 이름(descriptive name)을 갖는다. 상기 계층은, 인간 조작자에게 좀더 이해하기 쉬운 방식으로 어플리케이션이 어떻게 실행되는지에 관한 정보를 조직하는 방법을 제공하는 추상적인 개념(abstract construct)으로 간주될 수도 있다.

상기 계층의 탑 레벨은 "도메인(Domain)" 이라 명명되는 도메인 레벨(300)이다. 계층의 다음 레벨은 비즈니스 서비스(Business Service) 레벨(302)이다. 비즈니즈 서비스 레벨의 일례는, 웹 사이트를 이용한 주식 혹은 다름 금융 상품(financial instrument)에 관련된 트레이딩(trading)에 관한 것이다. 따라서, "트레이딩(Trading)"은 상기 계층의 비즈니스 서비스 레벨에서의 노드 이름이 될 수 있다. 예컨대, 특정 사용자가 트레이딩을 실행할 때에, 트레이딩 비즈니스 서비스(Trading Business Service)의 특별한 인스턴스(instance)가 발생한다. 비즈니스 서비스의 다른 일례는 책을 판매하는 웹 사이트(book-selling web site)에 대한 "책 구매(Buy Book)" 를 포함하며 그리고 복지 프로그램에 등록하는 종업원의 "공제 조합에 등록(Enroll in benefits)" 을 포함할 수 있다.

상기 계층의 다음 레벨은 비즈니스 트랜잭션(Business Transaction) 레벨이다. 전술한 바와 같이, 비즈니스 트랜잭션은 웹 사이트에 로그인하는 것, 물품을 주문하는 것, 등등과 같은 클라이언트 관점에서의 태스크를 나타낼 수 있다. 비즈니스 서비스(Business Service)는 다수개의 비즈니스 트랜잭션들(Business Transactions)로 구성될 수 있다. 예를 들어, 트레이딩의 경우, 비즈니스 트랜잭션은: 로그인(Login)(304)(예컨대, 웹 사이트에 로그인), 밸런스(Balance:잔액)(예컨대, 계좌의 잔액을 획득), 어카운트 요약(Account Summary)(308)(예컨대, 최근의 구매/판매 활동에 대한 보고를 획득), 주문(Place Order)(310)(예컨대, 옵션 이외의 주식 혹은 채권 등등과 같은 증권을 사고팔기 위해 주문하는 것), 그리고 옵션 트레이딩(Option Trading)(312)(리서칭 및 옵션 트레이드 등과 같은 행위를 수행함)을 포함할 수 있다. 로그인(Login)의 특별한 인스턴스는 사용자가 계좌(account)에 로그인하는 때에 발생한다.

또한, 비즈니스 트랜잭션은 하나 이상의 비즈니스 트랜잭션 컴포넌트들과 관련될 수 있다. 하나의 접근법에서, 비즈니스 트랜잭션은 오직 하나의 식별 컴포넌트(identifying component)를 갖는다. 비즈니스 트랜잭션 컴포넌트(Business Transaction Component)는, 가령, 서블릿(servlet) 혹은 EJB 등과 같은 서버에 의해서 인식 및 측정가능한 어플리케이션의 컴포넌트의 일 유형이 될 수 있다. 하나의 접근법에서, 어플리케이션의 컴포넌트들 중 하나는 비즈니스 트랜잭션 컴포넌트(Business Transaction Component)로서 설정되며, 이것은 비즈니스 트랜잭션에 대한 식별 트랜잭션 컴포넌트(identifying transaction component)이다. 비즈니스 트랜잭션 컴포넌트는 트랜잭션에 대한 식별 트랜잭션 컴포넌트이며, 이는 비즈니스 트랜잭션에 대한 식별 트랜잭션이다. 트랜잭션은 클라이언트로부터의 요청에 응답하여 호출되는(invoked) 소프트웨어 컴포넌트들의 시퀀스를 나타낼 수 있으며, 대응 응답을 클라이언트에 제공하기 위한 것이다. 예를 들어, 비즈니스 트랜잭션 컴포넌트는, 에이전트에 의해 보고되는 컴포넌트 데이터가 룰들의 세트에 언제 매칭되는지를 판별함에 의해서 식별될 수 있다. 이러한 정의(this definition)는 예를 들어, 특정 URL 호스트 네임, URL 파라미터들, HTTP 포스트 파라미터들, 쿠키 및/또는 세션 매니저 파라미터들을 포함할 수 있다. 부가적으로 혹은 대안적으로, 상기 정의는 특정 URL 호스트 네임으로 시작하기 위한 트랜잭션을 요구할 수도 있다. 예컨대, 에이전트 혹은 매니저는 룰들의 상기 세트에 대하여 컴포넌트 데이터를 비교할 수 있는바, 이는 비즈니스 트랜잭션 컴포넌트가 비즈니스 트랜잭션에 언제 존재하는지를 판별하기 위한 것이다. 만일, 비즈니스 트랜잭션 컴포넌트가 검출된다면, 관련된 비즈니스 트랜잭션은 특정 유형이다. 예를 들어, 비즈니스 트랜잭션 컴포넌트 305, 307, 309, 311 혹은 313 이 검출된다면, 관련된 비즈니스 트랜잭션은 각각 로그인(Login)(304), 밸런스(Balance)(306), 어카운트 요약(Account Summary)(308), 주문(Place Order)(310), 옵션 트레이딩(Option Trading)(312) 이다.

예를 들면, 서블릿(servlet)에 관련된 트랜잭션의 경우, 비즈니스 트랜잭션 컴포넌트는 보조 프레임 내에 로딩되는 자바서버 페이지(JavaServer Page : JSP)에 관련하여 호출될 수도 있다.

또한, 하나 이상의 어플리케이션들은 서로 다른 서브 시스템들을 포함하는바, 예컨대 특정 태스크를 수행하는 소프트웨어 컴포넌트들을 포함한다. 일반적으로, 비즈니스 트랜잭션의 각각의 인스턴스는 하나 이상의 서브시스템들의 시퀀스의 코드의 실행을 수반한다. 서브시스템들은 서로 의존하는바, 예컨대, 직렬 혹은 브랜치 체인에서 서로를 콜(call) 한다. 서로 다른 비즈니스 트랜잭션들은 때때로 공통의 서브시스템을 이용할 수 있다.

서브시스템들의 일례는, 인스트루먼트된(instrumented) 서브시스템들을 포함하는바, 이들은 파선 박스들(dashed line boxes)로 표시되며 그리고 전형적으로는 프론트 엔드 서브시스템들이다. 뿐만 아니라 서브시스템들의 일례는, 인스트루먼트되지 않은(un-instrumented) 서브시스템들을 포함하는바, 이들은 점선 박스들(dotted line boxes)로 표시되며 그리고 전형적으로는 백 엔드 서브시스템들이다. 본 명세서에서 사용되는 바와 같이, 프론트 엔드 서브시스템은 인스트루먼트되는 것이 일반적인 반면에, 백 엔드 서브시스템은 인스트루먼트되지 않는 것이 일반적이다. 또한, 하나의 프론트 엔드 서브시스템은 가령, 웹 서비스 콜(Web Service call)을 통해 다른 하나의 프론트 엔드 서브시스템을 호출할 수 있다. 또는, 하나의 프론트 엔드 서브시스템은 하나의 백 엔드 서브시스템을 호출할 수 있다. 퍼포먼스 메트릭스(performance metrics)의 전체 범위는, 인스트루먼트된 서브시스템으로부터 획득될 수 있다. 인스트루먼트되지 않은 서브시스템에 대한 제한된 정보는, 인스트루먼트된 서브시스템들로부터 이들을 콜 아웃하는데 이용되는 메소드들(methods)로부터 획득될 수도 있다. 인스트루먼트되지 않은 데이터베이스의 경우, 예를 들어, JDBC 드라이버(콜링(calling) 프론트 엔드와 동일한 자바 가상 머신 JVM 내에 위치됨)는 메트릭스(metrics)를 제공하는데, 이는 데이터베이스의 응답성(responsiveness)에 관한 아이디어를 우리에게 제공한다. 인스트루먼트되지 않은 메인프레임들의 경우, 메인프레임 상의 특정 포트 상에 메인프레임을 콜 아웃하는 메소드가 통상적으로 존재하며 그리고 우리는 상기 콜이 얼마나 오래 걸리는지 혹은 지연(stall)되는지 혹은 에러를 보고하는지를 측정할 수 있다.

많은 경우에 있어서, 인스트루먼트되지 않은 서브시스템은 가령, 메인프레임, 데이터베이스 혹은 몇몇 다른 인스트루먼트되지 않은 컴퓨팅 디바이스와 같은 백 엔드 서브시스템이다. 이들은 알려지지 않은(unknown) 컴포넌트들/목적지들(destinations)이다. 인스트루먼트된 서브시스템들은, 트레이드서비스(320), 오더엔진(OrderEngine)(326), 인증엔진(328), 보고서비스(ReportingService)(324), 인증서비스(322) 및 보고엔진(330)을 포함한다. 인스트루먼트되지 않은 서브시스템들은, 오더 레코드 DB(Order Records DB)(332), 보고 레코드 DB(Report Records DB)(338), 시스템 로컬 호스트(334)(이는 그것의 포트번호 6543를 통하여 액세스됨), 시스템 로컬 호스트(321)(이는 그것의 포트번호 3456 및 고객 레코드 DB (Customer Records DB)(336)을 통해 액세스됨)를 포함한다. 서브시스템은 Structured Query Language(SQL) 데이터베이스이다. "?"는 서브시스템들(334, 321)이 알려지지 않았음을 나타낸다.

도4a는 비즈니스 트랜잭션에서 호출된 컴포넌트들의 예시적인 시퀀스에서의 종속 관계를 나타낸다. 컴포넌트들로 지칭되는 빌딩 블록들로부터 프로그래머가 어플리케이션 혹은 다른 프로그램을 조립함에 있어서, 컴포넌트-지향 프로그래밍 모델들(component-oriented programming models)이 특히 유용하다. 각각의 컴포넌트는 소프트웨어의 전체 기능에 조화되는 특정 기능을 수행할 수 있다. 또한, 컴포넌트는 다른 컴포넌트들을 콜할 수 있을 뿐만 아니라 재귀 콜(recursive call)에서 자신을 콜할 수도 있는바, 따라서 프로그램에서 컴포넌트들의 시퀀스가 호출된다. 컴포넌트-지향 프로그래밍 모델의 일례 중 하나는 J2EE 이며, 이것은 자바 서버 페이지(Java Server Page), 엔터프라이즈 자바 빈(Enterprise Java Bean : EJB), 서블릿, 및 자바 데이터베이스 커넥티비티(JDBC) 컴포넌트 등과 같은 컴포넌트들을 채용할 수 있다. JDBC는 JAVA(™) 프로그래밍 언어에 대한 어플리케이션 프로그래밍 인터페이스(API)로서, 이는 클라이언트가 데이터베이스에 어떻게 액세스할 수 있는지를 정의한다. 이것은, 데이터베이스의 데이터를 질의(querying)하고 업데이트(updating) 하기 위한 방법을 제공한다. 하지만, 가령, .NET 등과 같은 다른 컴포넌트 지향 프로그래밍 모델들이 또한 이용될 수도 있다. 또한, 상기 프로그래밍 모델은 객체 지향이 될 필요는 없다.

상기 일례는 전술한 로그인 비즈니스 트랜잭션의 세부내용을 제공한다. 가능한 일 구현예에서, 로그인(Login)의 각각의 컴포넌트는 클래스-메소드 쌍(class-method(CM) pair)이다. 예를 들어, 서블릿은 JAVA 클래스이다. 요청(request)을 수신하고 그리고 대응 응답(response)을 생성하는 것은 객체(object)이다. 클래스-메소드 쌍은 class.method 표기법으로 표현될 수 있다. 로그인(Login)은 제 1 클래스-메소드 쌍 CM1을 포함할 수 있으며, 이는 로그인 네임 및 패스워드 등과 같은 사용자의 로그인 크리덴셜(login credentials)을 획득한다. CM1의 예시적인 형식은 ServletA1.ObtainLoginCredentials 이다.

일례로서, CM1은 로그인(Login)의 비즈니스 트랜잭션 컴포넌트가 될 수 있다. 따라서, CM1이 호출되었다는 것을 에이전트가 검출할 때마다, 에이전트는 현재의 트랜잭션이 로그인(Login)의 일부분이라고 결론내며, 그리고 그 컴포넌트 데이터를 로그인(Login)에 연관시킨다.

제 2 클래스-메소드 쌍 CM2(예컨대, ServletA2.CheckLoginCredentials)는 로그인 크리덴셜의 포맷을 체크한다.

만일, 로그인 크리덴셜이 적절한 포맷이 아니라면, CM2는 제 3 클래스-메소드 쌍 CM3(예컨대, ServletA3.DisplayErrorMessage)를 콜하는바, 이는 에러 메시지를 디스플레이하며, 적절한 입력을 제공하도록 사용자를 프롬프팅한다. 만일, 로그인 크리덴셜이 적절한 포맷이라면, CM2는 CM4a(예컨대, ServletA4.ValidateLoginCredentials)를 콜한다. CM4a는 CM7(예컨대, ServletB1.ReceiveLoginCredentials)을 콜하는바, 이는 상기 콜과 함께 로그인 크리덴셜을 통과시킨다.

CM7은 CM8(예를 들면, JDBC driver call/SQL statement to CheckCredentialRecord)을 콜하는바, CM8은 사용자의 로그인 크리덴셜이 고객 기록(customer records)과 매칭되는지를 판별하기 위하여 데이터베이스에 액세스한다. 매칭이 존재한다라고 CM8이 CM7에게 응답하면, CM7은 CM9(예를 들면, JDBC driver call/SQL statement to CheckAccountStanding)를 콜하는바, CM9는 사용자의 계좌가 우량 등급(good standing)인지를 판별하기 위하여 데이터베이스에 액세스한다. 사용자의 계좌가 우량 등급이라는 응답을 CM9이 CM7에게 제공하면, CM7은 CM10(예컨대, JDBC driver call/SQL statement to UpdateLoginRecords)을 콜하는바, CM10은 사용자가 로그인하였음을 나타내도록 데이터베이스를 업데이트하며 그리고 login status=true 를 CM7에게 리턴한다. 만일, CM8에서 상기 크리덴셜이 매칭되지 않는다면, 혹은 CM9에서 사용자의 계좌가 우량 상태(good standing)가 아니라면, CM7은 login status=false 를 설정하며 그리고 CM10은 콜되지 않는다. 따라서, 디폴트 login status=false 가 유지된다.

예시적인 구현예에서, CM8 내지 CM10 각각은 JDBC 드라이버 콜(JDBC driver call)을 포함할 수 있는바, JDBC 드라이버 콜은 가령, 데이터베이스에 테이블 엔트리를 생성하고, 상기 엔트리에 데이터를 부가하고 등등을 위해, 하나 이상의 SQL 스테이트먼트(SQL statements)를 호출할 수 있다. 대안적으로는, 각각의 SQL 스테이트먼트는, JDBC 드라이버 콜에 의해서 콜되는 별도의 컴포넌트로서 특정될 수도 있다(원한다면). 또한, 도5r을 참조하기로 한다.

CM7은 CM4a에게 답신(reply)을 리턴하며, 그리고 CM4a는 CM2에게 답신을 리턴한다(login status=false 혹은 login status=true 중 어느 하나). 만일, login status=true 라면, CM2는 CM4b를 콜하며, CM4b는 CM5(예컨대, ServletA5.DisplayMessageAccessGranted)를 콜하는바, CM5는 액세스가 허용되었음을 나타내는 메시지를 사용자에게 디스플레이한다. 만일, login status=false 라면, CM2는 CM4b를 콜하며, CM4b는 CM6(예컨대, ServletA6.DisplayMessageAccessDenied)를 콜하는바, CM6은 액세스가 거부되었음을 나타내는 메시지를 사용자에게 디스플레이한다.

CM4a에 의한 CM7로의 콜, 그리고 CM4b에 의한 CM5 혹은 CM6으로의 콜에 대한 개별 인스트루먼팅(separate instrumenting)을 허용하기 위해서, 개별 컴포넌트들인 CM4a 와 CM4b가 이용됨을 유의해야 한다. 대안적으로는, 하나의 컴포넌트, 즉 CM4가 CM4a 및 CM4b의 기능들을 담당할 수도 있다. 이러한 하나의 컴포넌트는 웹 서비스 콜(Web service call)(CM7로의) 그리고 동일한 app 서버 내의 다른 하나의 메소드(CM5 혹은 CM6) 둘다를 호출할 것이다.

일례로서, CM1 내지 CM6는 인증서비스 서브시스템(AuthenticationService subsystem) 내에서 실행되는 반면에, CM7 내지 CM10은 인증엔진 서브시스템(AuthenticationEngine subsystem) 내에서 실행된다. 따라서, 로그인(Login)은 이들 서브시스템들 둘다에서 실행되거나 혹은 이들을 호출할 수 있다.

컴포넌트는 다른 컴포넌트를 콜한 이후에 실행을 계속할 수 있는데, 이는 비동기(asynchronous), 다중-쓰레드(multi-thread) 혹은 다중-프로세스 모드에서 실행을 개시한다. 또는 컴포넌트는 콜된 컴포넌트가 실행을 마칠 때까지 동기(synchronous), 단일-쓰레드 혹은 단일-프로세스 모드에서 일시적으로 정지할 수 있다. 정지중인 있는 컴포넌트는 대기 간격(wait interval)에 있는 것으로 간주될 수 있는 반면에 실행중인 컴포넌트는 액티브, 실행 모드에 있는 것으로 간주될 수 있다. 컴포넌트는 트랜잭션 동안 두번 이상 호출될 수도 있다.

도4b1은 도4a의 컴포넌트들의 가능한 하나의 시퀀스에 기초하여, 트랜잭션에서 호출된 컴포넌트들의 시퀀스들에 대한 예시적인 트랜잭션 트레이스들(transaction traces)을 도시한다. 수평 방향은 시간을 나타내는 반면에, 수직 방향은 콜 스택 깊이 혹은 위치(call stack depth or position)를 나타낸다. 트랜잭션 트레이스(콜 스택이라고도 지칭됨)는, 하나 이상의 프로그램들, 프로세스들 혹은 쓰레드들의 실행 동안에 콜되었던 혹은 호출되었던 인스트루먼트된 컴포넌트들을 식별한다. 인스트루먼트된 컴포넌트들의 트레이스 데이터는, 어플리케이션을 이해하고 그리고 디버깅하기 위해서 종속 데이터(dependency data)와 함께 이용될 수 있다. 트랜잭션 트레이스는 하나의 트레이스가 될 수 있거나 혹은 트랜잭션의 전부 또는 일부가 될 수 있으며 그리고 각각의 에이전트를 갖는 하나 이상의 컴퓨팅 디바이스들에 대해서 확장될 수 있다.

특히, 서로 다른 쓰레드들이 서로 다른 트랜잭션 트레이스들로 분리되도록, 각각의 트랜잭션 트레이스는 각각의 에이전트에게 제공될 수 있다. 또한, 각각의 트랜잭션 트레이스는, 각각의 수평적으로-확장된 영역(horizontally-extending region), 혹은 다이어그램의 "스윔 레인(swim lane)"에 의해서 표현될 수 있다. 이러한 다이어그램에서, 인증서비스 서브시스템(AuthenticationService subsystem)에 대한 에이전트의 트랜잭션 트레이스(401)는, 가장 위쪽의 수평적으로-확장된 영역(top horizontally-extending region)에 있으며, 그리고 인증엔진 서브시스템(AuthenticationEngine subsystem)에 대한 에이전트의 트랜잭션 트레이스(403)는 바닥의 수평적으로-확장된 영역(bottom horizontally-extending region)에 존재한다. 2개의 트랜잭션 트레이스들은 이들의 상대적인 타이밍을 좀더 잘 이해하기 위해서 함께 제공된다. 만일, 서로 다른 에이전트들의 클럭들이 충분히 동기화되었다고 알려진 경우에는, 서로 다른 트랜잭션 트레이스들의 상대적인 타이밍에 대해 정확한 결론들이 만들어질 수 있다. 화살표(400 및 402)는 트랜잭션 트레이스들(401, 403)에 대한 각각의 콜 스택 깊이를 각각 나타낸다.

사용자 인터페이스 디스플레이 상에 제공될 수도 있는 이러한 그래픽적인 표현에서, 컴포넌트 CM1은, 트랜잭션 트레이스(401)의 첫번째 혹은 루트 컴포넌트(the first or root component)이다. 상기 트랜잭션 트레이스는 제 2 레이어에서 CM2를 포함하며, 제 3 레이어에서 CM4a와 CM4b를 포함하며, 그리고 제 4 레이어에서 CM5를 포함한다. 트랜잭션 트레이스(403)에서는, CM7이 제 1 레벨에 존재하며 그리고 CM8, CM9, 및 CM10은 제 2 레벨에 존재한다. 선택적으로는, 트랜잭션 트레이스(403)는 더 세부적인 내용을 보여줄 수도 있다. 예를 들어, CM8, CM9, 및 CM10이 각각 JDBC 드라이버 콜인 경우, 트랜잭션 트레이스(403)는 차일드(child) SQL 스테이트먼트들(691, 692, 693)을 각각 도시하도록 변형될 수도 있는바, 이에 대해서는 도5r을 참조하여 상세히 후술될 것이다.

시간 척도는 t0 - t13 이며, 이는 예컨대, 1300 밀리세컨드(ms.)를 나타낼 수 있다. 트랜잭션 트레이스는 컴포넌트가 실행하는 시간 간격(time interval)과 그리고 컴포넌트들 간의 콜 관계(calling relationship)를 나타낸다. 예를 들어, CM1은 t0 - t13 에서 실행하며, CM2는 t1 - t12.5 에서 실행하며, CM4a는 t2 - t10(대략) 에서 실행하며, CM4b는 t10(대략)에서 t12 까지 연장되며 그리고 CM5는 t11 - t11.5 에서 실행한다. 또한, CM1은 CM2를 콜하며, CM2는 CM4a 및 CM4b를 콜하며, 그리고 CM4b는 CM5를 콜한다.

도4b2는 도4b1의 예시적인 트랜잭션 트레이스들에서 대기 기간들(waiting periods)을 나타낸다. 동기(synchronous) 트랜잭션은 하나의 컴포넌트, 예컨대 CM1을 포함하는바, CM1은 다른 하나의 컴포넌트 예컨대, CM2를 콜하고 그리고 실행을 지속/재개하기 전에 답신하기 위하여 CM2를 기다린다. 콜된(called) 메소드에 의해서 요구되는 시간은, 콜하는(calling) 메소드에 대한 "대기 시간(wait time)" 이라는 점을 가정할 수 있다. 또한, 비동기 트랜잭션을 트레이스하는 것도 가능하며, 그리고 이것을 도4b1과 유사한 트랜잭션 트레이스 도면에 도시하는 것도 가능하다. 상기 대기 시간 이외의(outside the wait time), 컴포넌트에 의해서 소모되는 시간은, 실행 혹은 응답 시간의 순수 지속시간(net duration)이라고 간주될 수 있다. 따라서, 대기 시간과 순수 지속시간을 더한 값은, 실행 혹은 응답 시간의 전체 지속시간(total duration)과 같다. 컴포넌트의 전체 지속시간은, 상기 컴포넌트에 의해서 직접적으로 콜된 모든 메소드들에 대한 지속시간들을 합산하여 합계를 구하고 그리고 상기 컴포넌트에 대한 기록된 전체 지속시간(total recorded duration)에서 상기 합계를 차감함에 의해서 계산될 수 있다.

그래프에 있는 각각의 수평 바(horizontal bar)에서, 사선으로 패턴처리되지 않은 부분은, 콜된 컴포넌트로부터의 응답을 컴포넌트가 기다리고 있지 않음을 나타내며 반면에, 사선으로 패턴처리된 부분은 콜된 컴포넌트로부터의 응답을 컴포넌트가 기다리고 있음을 나타낸다. 비록, 컴포넌트의 인스트루먼테이션(instrumentation)이 컴포넌트가 실행 중인지 혹은 대기 중인지를 명시적으로 나타내고 있지는 않지만, 상기 동기형 케이스의 경우, 이전의 컴포넌트들(earlier components)은 대기 중인 반면에 이들이 콜한 메소드들은 실행중일 거라고 추론할 수 있다. 컴포넌트에 의해 소모되는 시간에서, 상기 시간 중 일부는 실행(executing), 응답하기 위해 콜된 컴포넌트를 기다림(waiting), 네트워크 혹은 CPU 지연에 의한 지연(delay), 기타등등 때문에 소모될 수 있다.

이러한 일례에서, CM1은 t0에서, 즉 로그인 비즈니스 트랜스잭션의 인스턴스의 시작시에 실행을 개시하며, 그리고 t1에서 CM2를 콜한다. CM2은 t1에서 실행을 개시하며, 그리고 t2에서 CM4a를 콜한다. CM4a는 t2에서 실행을 개시한다. 트랜잭션 트레이스(401)는 CM4a가 t3에서 CM7을 콜한 것을 명시하지 않을 수도 있는데, 왜냐하면 상기 일례에서 CM7은 다른 서브시스템 상에 있으며, 다른 에이전트에 관련되기 때문이다. 또한, 네트워크 전송 시간, 프로세싱 지연, 혹은 다른 인자들 등으로 인하여, CM7을 콜하는 CM4a와 실행을 개시하는 CM7 사이에는 지연이 있을 수도 있다. 하지만, 트랜잭션 트레이스(403)는, CM7이 t3.5에서 실행을 개시하고 있으며 그리고 예컨대, 크로스-프로세스 콜(cross-process call)에서 CM4a에 의해서 콜되었음을 나타낸다. 즉, CM4a의 호출(invocation)로 인하여, CM7은 실행을 개시한다. CM7은 t4에서 CM8을 콜하며 그리고 CM8은 t4 - t5에서 실행한다. CM7은 t6에서 CM9을 콜하며 그리고 CM9은 t6 - t7에서 실행한다. CM7은 t8에서 CM10을 콜하며 그리고 CM10은 t8 - t9에서 실행한다. t9에서, 콘트롤 플로우는 CM7로 반환되며 그리고 t9.5에서 CM7은 실행을 중지한다. 상기 콘트롤 플로우는 전술한 바와 같은 인자들 때문에 t10까지 CM4a로 반환되지 않는다. t10에서, 콘트롤 플로우는 CM4a로 짧게(briefly) 반환되며 그리고 t10 직후에 CM2가 CM4b를 콜하는 때 CM2로 짧게(briefly) 반환된다. 트랜잭션 트레이스(401)에서, CM4b는 t11에서 CM5를 콜하며 그리고 CM5는 t11 - t11.5에서 실행한다. t11.5에서, 콘트롤 플로우는 CM4b로 반환되고, t12에서 콘트롤 플로우는 CM2로 반환되며 그리고 t12.5에서 콘트롤 플로우는 CM1로 반환된다.

CM8, CM9, 및 CM10 각각은 데이터베이스(Customer Records DB)를 콜한다. 하지만, 상기 데이터베이스가 인스트루먼트되지 않았기 때문에, 데이터베이스에 의해서 소모되는 시간의 양은, 트랜잭션 트레이스(403)에서의 CM8, CM9, 혹은 CM10의 전체 실행 시간과 구별될 수 없다.

이러한 일례에서, CM1의 경우, 전체 지속시간은 t13 - t0 = 1300 ms 이며, 대기 시간은 t12.5 - t1 = 1150 ms 이며, 그리고 순수 지속시간은 1300 - 1150 = 150 ms 이다. CM2의 경우, 전체 지속시간은 1150 ms 이며, 대기 시간은 t12 - t2 = 1000 ms 이며, 그리고 순수 지속시간은 1150 - 1000 = 150 ms 이다. CM4a의 경우, 전체 지속시간은 t10 - t2 = 800 ms 이며, 대기 시간은 t10 - t3 = 700 ms 이며, 그리고 순수 지속시간은 800 - 700 = 100 ms 이다. CM4b의 경우, 전체 지속시간은 t12 - t10 = 200 ms 이며, 대기 시간은 t11.5 - t11 = 50 ms 이며, 그리고 순수 지속시간은 200 - 50 = 150 ms 이다. CM5의 경우, 전체 지속시간은 t11.5 - t11 = 50 ms 이며, 대기 시간은 0 ms 이며, 그리고 순수 지속시간은 50 - 0 = 50 ms 이다.

이와 유사하게, 트랜잭션 트레이스(403)에서, CM7의 경우, 전체 지속시간은 t9.5 - t3.5 = 600 ms 이며, 백 엔드 콜 시간은 t5 - t4 + t7 - t6 + t9 - t8 = 100 + 100 + 100 = 300 ms 이며, 그리고 인증엔진 서브시스템에서 시간 소모는 600 -300 = 300 ms 이다. 이러한 시간 소모는 순수 지속시간과 유사하다. CM8의 경우, 전체 지속시간은 t5 - t4 = 100 ms 이며, 대기 시간은 0 ms로 추정되며 그리고 순수 지속시간은 100 ms 이다. CM9의 경우, 전체 지속시간은 t7 - t6 = 100 ms 이며, 대기 시간은 0 ms로 추정되며 그리고 순수 지속시간은 100 ms 이다. CM10의 경우, 전체 지속시간은 t9 - t8 = 100 ms 이며, 대기 시간은 0 ms로 추정되며 그리고 순수 지속시간은 100 ms 이다.

인증엔진 서브시스템에 대한 전체 지속시간은 600 ms 이며 이는 인증엔진 서브시스템의 루트 컴포넌트, CM7의 전체 지속시간에 기초한다. 인증엔진 서브시스템의 백 엔드 콜 시간은 100 + 100 + 100 = 300 ms 인바, 이는 상기 서브시스템 외부에서 콜이 만들어졌을 때의 시간들(예컨대, 최하위 레벨 컴포넌트들인 CM8, CM9, 및 CM10에 의한 t4, t6, t8에서의 각각의 콜들) 그리고 상기 콜들에 대한 대응 응답이 수신되었을 때의 시간들(예컨대, t5, t7, t9 각각)에 기초한다. 다음으로, 인증엔진 서브시스템에서의 시간 소모는, 전체 지속시간 빼기 백 엔드 콜 시간들 즉, 600 - 300 = 300 ms 이다. 백 엔드 콜 시간들은 콜되는 하나 이상의 인스트루먼트된 혹은 인스트루먼트되지 않은 서브시스템들에 할당될 수 있다. 상기 일례에서, 하나의 인스트루먼트되지 않은 서브시스템이 콜되며(Customer Records DB), 따라서 300 ms 가 이에 할당된다.

대체로 인증엔진 서브시스템의 경우, 기능적으로, 일 구현예에서 식별된 "대기 시간" 은 없다. CM8, CM9 및 CM10은 "백 엔드 콜" 시간들에 대응한다. 상기 트레이스의 3개의 컴포넌트들은 하나 이상의 백 엔드들에 대한 콜들을 나타내지만, 구별할 수 없다. 우리는 상기 콜을 실행하는데 소비되는 시간과 응답을 위해 상기 백 엔드를 대기하는데 소비되는 시간을 구별할 수 없다. 인증엔진에 대한 전체 시간에서 백 엔드 시간을 감산하면, 인증엔진 "프론트 엔드"에 소비된 시간과 "백 엔드 콜들"에 소비된 시간을 구별할 수 있다. 이 경우, 모든 백 엔드 콜들이 동일한 백 엔드로 가기 때문에, 이들은 하나의 값으로 취합(aggregate)될 수 있다(Customer Records DBL를 콜하는 전체 시간). 다른 경우들에서는, 다수의 백 엔드들 각각에 대해서 개별적인 백 엔드 콜 타임이 취합될 수 있다.

이와 유사하게, 우리는 인증서비스 서브시스템의 루트 컴포넌트 CM1의 전체 지속시간으로부터, 인증서비스 서브시스템의 전체 지속시간이 1300 ms 라고 판별할 수 있다. 인증서비스 서브시스템의 대기 시간은 700 ms 인바, 이는 최하위 레벨 컴포넌트 콜이 서브시스템의 외부에서 만들어졌을 때의 시간(예컨대, 상기 콜은 최하위 레벨 컴포넌트인 CM4a에 의해서 t3에서 CM7로 행해짐)과 상기 콜에 대한 응답이 수신되었을 때의 시간(예컨대, t10)에 기초한다. 따라서, 인증서비스 서브시스템의 순수 지속시간은 전체 지속시간 빼기 대기 시간 즉, 1300 - 700 = 600 ms 이다.

또한, 인증서비스 서브시스템의 대기 시간인 700 ms는, 그것이 콜하는 하나 이상의 서브시스템들에 기인할 수 있다. 인증서비스 서브시스템에 의해서 콜되는 유일한 서브시스템이 바로 인증엔진 서브시스템이기 때문에, 우리는 700 ms가 인증엔진 서브시스템 덕분이라고 생각할 수 있다. 하지만, 인증엔진 서브시스템의 전체 지속시간은 오직 600 ms 라고 판별되었다. 따라서, 700 - 600 = 100 ms 는, 인증서비스 서브시스템으로부터 인증엔진 서브시스템으로 요청을 통신하는데 소모되고 그리고 인증엔진 서브시스템으로부터 인증서비스 서브시스템으로 대응 답신을 통신하는데 소모되는 시간이라고 간주될 수 있다. 다음을 유이해야 하는바, 서브시스템들 사이에서 요청과 답신을 통신하는 것은, 네트워크 및 CPU 지연들 뿐만 아니라, 웹 서비스 등과 같은 서비스에 액세스하는 것을 포함할 수 있다.

이와 같은 방법으로, 우리는 트랜잭션의 마지막으로 콜된 서브시스템으로부터 첫번째로 콜된 서브시스템으로 역행하여(backward) 작업할 수 있는바, 이는 전체 지속시간들, 순수 지속시간 혹은 서브시스템에서 소비된 시간, 대기 시간들, 백 엔드 콜 시간들(혹은 인스트루먼트되지 않은 서브시스템들로의 다른 콜들), 그리고 서브시스템들 간의 통신 시간들을 판별하기 위한 것이다. 백 엔드 콜 시간들을 표현함에 있어서, 순수 지속시간 대비 완전(full) 지속시간을 언제 및 어떻게 이용할지에 대한 의문이 존재한다. 순수 지속시간이 더 많은 입도(more granularity)를 제공하기 때문에 순수 지속시간이 바람직할 수도 있지만, 인스트루먼트되지 않은 백 엔드에 대해서 콜이 되고 있는 경우에 우리는 완전(full) 지속시간만을 갖는다. 우리는, 이용가능한 경우에는 순수 지속시간을 이용하도록 룰을 설정할 수 있지만, 인스트루먼트되지 않은 백 엔드의 그것을 상기 시간이 언제 포함하는지를 묶음 괄호(grouping bracket) 등으로 나타낼 수 있다. 이러한 예시적인 절차는 다음에 설명될 것이다.

도 4b3은 종속 인스트루먼트된 서브시스템들의 시퀀스에 대하여 전체 지속시간들, 순수 지속시간들, 대기시간들, 및 서브시스템들간 통신 시간들을 판별하기 위한 방법을 도시한다. 인스트루먼트된 서브시스템들의 시퀀스는 직렬이 될 수 있는바, 따라서 하나의 서브시스템은 첫번째 다음 서브시스템(first next subsystem)을 콜하며, 상기 첫번째 다음 서브시스템은 두번째 다음 서브시스템을 호출하는바(그리고 기타등등), 따라서 시퀀스 내에는 오직 하나의 브랜치 혹은 체인만이 존재한다. 혹은, 상기 시퀀스는 하나 이상의 병렬 브랜치들을 가질 수 있는바, 가령 하나의 서브시스템이 첫번째 다음 서브시스템과 두번째 다음 서브시스템을 콜하는 경우가 그러하다. 예를 들어, 후술되는 도5A에서, 인스트루먼트된 서브시스템들의 직렬 시퀀스가 로그인을 위해 제공되는바, 여기서, 인증서비스는 인증엔진을 콜한다. 또한, 인스트루먼트된 서브시스템들의 다중-브랜치가 주문(Place Order)를 위해 제공되는바, 여기서, 트레이드서비스는 개별 브랜치들에 있는 주문엔진과 인증엔진 둘다를 콜한다. 또한, 종속 서브시스템들의 시퀀스의 스테이지들이 정의될 수 있다. 예를 들어, 로그인의 경우, 인증서비스는 첫번째 스테이지에 있으며 그리고 인증엔진은 두번째(마지막) 스테이지에 있다. 주문의 경우, 트레이드서비스는 첫번째 스테이지에 있으며 그리고 주문엔진 및 인증엔진 둘다는 두번째(마지막) 스테이지에 있다.

이러한 개념들을 고려하면, 도4b3의 단계 422는 인스트루먼트된 서브시스템을 선택하는 것을 포함하며, 서브시스템에 의해서 호출된 컴포넌트들에 기초하여 트레이스가 획득된다. 예를 들어, 도4B2에서, 인증서비스 서브시스템 및 그것의 트레이스(401)를 선택한다. 단계 424에서는, 서브시스템의 루트 컴포넌트의 지속시간으로부터 서브시스템의 전체 지속시간 T1이 판별된다. 예를 들면, 트레이스(401)의 CM1에 기초하여 T1 = 1300 ms 이다. 단계 426은, 인스트루먼트된 혹은 인스트루먼트되지 않는에 관계없이, 서브시스템에서 나와서 목적지 서브시스템으로 가는 콜들(예컨대, 크로스-프로세스 콜)에 대응하는 트레이스 내의 모든 컴포넌트들을 식별한다. 예를 들어, 우리는 트레이스(401)에서 CM4a를 식별한다. 단계 428에서는, 식별된 컴포넌트들의 시간들을 합산하여, 서브시스템 외부의 모든 콜들의 전체 지속시간 T2를 획득한다. 여기서, 오직 하나의 이러한 식별된 컴포넌트 CM4a(Tc1 = 700 ms)가 존재하며 그리고 우리는 T2 = Tc1 = 700 ms를 얻는다. 단계 430에서는, 서브시스템의 전체 지속시간 T1으로부터 서브시스템 외부의 모든 콜들의 전체 지속시간 T2를 감산함에 의해서 서브시스템의 순수 지속시간 T3(또한 프론트 엔드 시간 이라고 지칭됨)이 획득된다. 트레이스(401)의 경우, T3 = T1 - T2 = 1300 - 700 = 600 ms 이다.

단계 432에서는 식별된 컴포넌트들을 그들의 목적지 서브시스템에 의해 그룹화하며, 이후 각 그룹의 시간들(가령, 단계 428의 Tc1, Tc2...등)을 합산한다. 이러한 합산값들은 목적지 서브시스템으로의 각각의 콜에 대한 완전(full) 지속시간들 TF 이다. 트레이스(401)의 경우, 오직 하나의 그룹만이 존재하는데, 이는 오직 하나의 목적지 서브시스템 즉, 인증엔진 서브시스템만이 존재하기 때문이다. 인증엔진 서브시스템에 대한 시간들의 합산값은 TF = 700 ms 이다. 결정 단계 434에서는, 분석할 다음 서브시스템이 있는지가 판별된다. 분석할 다음 서브시스템이 있다면, 상기 다음 서브시스템에 대해서 단계 422 내지 단계 432가 반복된다. 예를 들어, 분석할 다음 서브시스템은 단계 426에서 식별된 목적지 서브시스템을 포함할 것이다. 상기 프로세스는 서브시스템들의 시퀀스의 프론트에서 시작할 수 있으며 그리고 연속적으로 콜된 서브시스템들 쪽으로 하나 이상의 직렬 경로들에서 아래쪽으로 진행될 수 있다. 예를 들어, 인증엔진 서브시스템은 인증서비스 서브시스템의 목적지 서브시스템이다.

따라서, 단계 422에서 도4B2의 인증엔진 서브시스템 및 그것의 트레이스(403)가 선택된다. 단계 424는 그 루트 컴포넌트 CM7의 지속시간으로부터 서브시스템의 전체 지속시간 T1 = 600 ms를 판별한다. 단계 426은 CM8, CM9, 및 CM10을 식별하는바, 이들은 서브시스템 외부로 나가는 콜들에 대응하며, 상기 일례에서는 인스트루먼트되지 않은 백 엔드 Customer Records DB 에 해당한다. 단계 428에서는, 식별된 컴포넌트들의 시간들이 합산되는바, 이는 서브시스템 외부의 모든 콜들의 전체 지속시간 T2를 획득하기 위한 것이다. 여기서, CM8의 경우 Tc1 = 100 ms 이며, CM9의 경우 Tc2 = 100 ms 이며, 그리고 CM10의 경우 Tc3 = 100 ms 인바, 따라서 T2는 300 ms 이다. 단계 430에서, 트레이스(403)에 대해서, T3 = T1 - T2 = 600 - 300 = 300 ms 가 제공된다.

단계 432는 식별된 컴포넌트들을 그들의 목적지 서브시스템에 의해서 그룹화하며, 이후 각 그룹의 시간들을 합산한다(TF = Tc1 + Tc2 + Tc3 = 300 ms). 결정 단계 434에서, 분석할 다음 서브시스템이 있는지를 판별한다. 결정 단계 434에서 분석할 다음 서브시스템이 없는 경우, 상기 프로세스는 목적지 서브시스템으로의 각각의 콜을 재방문(revisit)하는바, 목적지 서브시스템은 인스트루먼트되며 그리고 각각의 에이전트에 관련된다. 특히, 단계 436에서는, 인스트루먼트된 목적지 서브시스템이 선택된다. 도4B2의 일례에서, 인증엔진 서브시스템이 재방문된다. 단계 438에서는, 목적지 서브시스템으로의 콜들의 완전(full) 지속시간(TF = 700 ms)으로부터 전체 지속시간(T1 = 600 ms)을 감산하여, 목적지 서브시스템으로의 콜들에 대한 순수 지속시간 TN = 100 ms를 얻는다.

도 5a는 서브시스템들의 사용자 인터페이스(UI)와 비즈니스 트랜잭션들을 상세하게 도시하며, 여기서 트레이딩(Trading)의 비즈니스 서비스가 사용자에 의해 선택되었다. UI(500)는 유향 그래프(directed graph)를 제공하는바, 상기 유향 그래프는 서브시스템들을 나타내는 버텍스들과 상기 버텍스들에 연결되는 에지들을 이용하여, 서브시스템들이 어떻게 서로 의존하는지(예컨대, 서브시스템들이 서로를 콜하는 순서)를 그래픽적으로 도시한다. 또한, 상기 맵은 특정 비즈니스 트랜잭션에 어떤 서브시스템들이 관련되는지를 나타낸다. 비즈니스 트랜잭션은 하나 이상의 컴퓨팅 디바이스에서 하나 이상의 서브시스템들에 관련되는 컴포넌트들을 호출할 수 있다. 상기 맵은, 어떤 서브시스템들이 서로를 잠재적으로 호출할 수 있는지를 판별하기 위한 하나 이상의 관리되는(managed) 어플리케이션들에 대한 분석에 기초하여, 개발될 수 있다. 이러한 분석은 관리되는 어플리케이션들의 특정 시간 간격(time interval)에서 컴포넌트 데이터가 획득되기 전에 수행될 수 있다. 상기 맵은 하나 이상의 비즈니스 트랜잭션들의 서브시스템들을 포함할 수 있다.

사용자 인터페이스의 영역(504)은, 이용가능한 비즈니스 서비스들에 대한 뷰(view)를 제공하도록 오픈될 수 있는 노드 및 이용가능한 프론트엔드들에 대한 뷰(view)를 제공하도록 오픈될 수 있는 노드를 포함하는 노드들의 트리(tree)를 제공한다. 바이 비즈니스 서비스(By Business Service) 노드는 비즈니스 서비스 콜된 트레이딩(Trading)을 위한 노드를 포함하며, 그리고 트레이딩은 트레이딩을 구성하는 비즈니스 트랜잭션들에 대한 노드들을 포함하는바, 이들은 전술한 바와 같은 밸런스, 로그인, 옵션 트레이딩, 주문 및 어카운트 요약이다. 트레이딩이 사용자에 의해 선택되었으며, 그리고 현재의 디스플레이는 이러한 선택에 기초한 것이다. 이러한 선택은 영역(504)의 트리에서 "트레이딩(Trading)" 이라는 글자 아래의 밑줄에 의해 표현된다.

이러한 선택에 응답하여, 다수의(하나 이상의) 연관된 비즈니스 트랜잭션들, 비즈니스 트랜잭션들의 서브시스템들 그리고 서브시스템들 간의 종속 관련성을 나타내는 에지들이 사용자 인터페이스의 메인 영역(502)(유향 그래프 영역이라 지칭됨)에 디스플레이된다. 좌측의 타원형 버텍스들(304, 306, 308, 310, 312)은 비즈니스 트랜잭션들을 나타내며 그 이름들을 포함하고 있다. 에지들은 비즈니스 트랜잭션에 대해서 어떤 서브시스템이 제일 먼저 호출되는지 그리고 어떤 서브시스템들이 후속으로 호출되는지를 나타낸다. 에지들은 식별자들 Ed1-Ed26으로 라벨링되어 있고, 여기서 표시 "d"는 UI의 상세 보기에서의 에지를 나타낸다. 이 식별자들은 UI 상에 디스플레이될 수 있으나, 반드시 디스플레이되어야 하는 것은 아니다. 몇몇 경우에 있어서는, 서로 다른 비즈니스 트랜잭션 인스턴스들에 대해서 공통적인 서브시스템이 호출된다. 예를 들면, 옵션 트레이딩 및 로그인 비즈니스 트랜잭션들에 의해서 인증서비스가 공통으로 호출될 수 있다.

주어진 비즈니스 트랜잭션 인스턴스에 대해서 호출되는 컴포넌트들은 고유한 식별자들을 이용하여 별도로 추적될 수 있는데, 이들 컴포넌트들이 동일한 서브시스템에 있는 경우에도 추적될 수 있다. 또한, 컴포넌트의 개별 인스턴스들이 서로 다른 비즈니스 트랜잭션 인스턴스들의 서브시스템에서 호출되는 것도 가능하다. 다시한번 설명하면, 이들 개별적인 인스턴스들은 개별적으로 추적될 수 있다.

또한, 동일한 비즈니스 트랜잭션의 개별 인스턴스들이 동일한 서브시스템을 호출할 필요는 없다는 점을 유의해야 한다. 예를 들어, 에러 혹은 네트워크 장애로 인하여, 비즈니스 트랜잭션 인스턴스은 에러가 없는 경우라면 호출될 수 있었던 특정 서브시스템을 호출하지 못할 수도 있다. 또는, 시각(time of day) 혹은 이용가능한 리소들로 인하여, 동일한 비즈니스 트랜잭션의 개별 인스턴스들은 서로 다른 서브시스템들을 호출할 수도 있다. 많은 변형예들이 가능한바, 이들 간략화된 일례들에는 이러한 많은 변형예들이 도시되지 않았음을 유의해야 한다.

버텍스들의 경계선(border)은 버텍스가 하이라이트되었는지의 여부, 그리고 다른 몇몇 경우에서는 하이라이트의 유형을 도시하는데 이용된다. 하이라이팅(highlighting)은 하나의 버텍스를 다른 버텍스들과 시각적으로 구별하는 방법들 중 하나이다. 또한, 서로 다른 색상들이 이용될 수도 있다. 일 접근법에서, 점선 경계선 혹은 파선 경계선(dotted or dashed line border)은 하이라이트가 없음을 나타내며, 반면에 실선(solid line)은 하이라이트를 나타낸다. 또한, 이중 경계선이 이용될 수도 있다. 일 접근법에서, 실선 외곽 경계선은 버텍스가 사용자에 의해 선택되었음을 나타내며, 그리고 파선 외곽 경계선은 사용자에 의한 다른 몇몇의 커맨드에 기초하여 그 버텍스가 시각적으로 구별되고 있음을 나타낸다. 영역(504)에서의 사용자의 선택과 그리고 사용자 인터페이스에서 버텍스 자체에 대한 사용자의 선택에 응답하여 버텍스가 하이라이트될 수 있다. 사용자에게 정보를 전달하기 위해서, 다양한 하이라이트 기법, 컬러 코딩, 및 다른 시각적 효과들이 제공될 수 있다. 서브시스템 버텍스들의 일부는 다음을 포함한다. (a) 프론트엔트 혹은 취합된 프론트엔드(예를 들면, 동일한 어플리케이션 콘텍스트를 공유하는 모든 서블릿들)를 나타내는 2개의 중첩 스크린들과 같은 심볼, (b) 데이터베이스를 나타내는 실린더 형상의 심볼, 혹은 (c) 서브시스템의 유형을 식별하기 위한, 소켓 콜(socket call)의 목적지인 미지의(unknown)(인스트루먼트되지 않은) 서브시스템을 나타내는 심볼.

다른 유형의 표현들은 메트릭스(metrics)와 경고(alert)를 포함한다. 비즈니스 트랜잭션들에 대해서(관련된 컴포넌트 데이터에 기초하여), 프론트엔드의 전체 성능(overall performance)("Healh")에 대해서, 그리고 프론트엔드에 의해서, 인스트루먼트되지 않은 백 엔드쪽으로 혹은 다른 프론트엔드쪽으로 행해진 백 엔드 콜들에 대해서 상기 경고들이 이용가능하다. 다른 프론트엔드쪽으로 행해진 콜들은 맵 상에서 이와 같이 보여지도록 웹 서비스 또는 EJB 클라이언트들을 통해 행해질 수 있다. 이들 경고들은 사용자에 의해서 생성 및 구성될 수 있다. 따라서, 임의의 비즈니스 트랜잭션, 프론트엔드 혹은 백 엔드 콜들은 그것을 위해 정의된 경고를 가질 수도 있으며 갖지 않을 수도 있다. 경고가 정의된다면, 경고는 여러 개의 상태들 중 하나를 나타낼 수 있다. 정상(녹색), 주의(노란색), 위험(적색), 데이터없음(회색), 그리고 스케줄된 다운타임(흑색 및 회색). 만일 경고가 정의되지 않는다면, 비즈니스 트랜잭션 또는 프론트엔드 내에 그 어떤 아이콘도 보이지 않을 것이다. 하지만, 작은 메트릭 아이콘(small "metric icon")이 백 엔드 콜의 말미에 나타날 수도 있는데, 이는 메트릭 데이터가 여기서 이용가능함을 나타내기 위한 것이다.

화살표의 말미에 나타나는 원(circle)(이는, 하나의 서브시스템으로부터 다른 하나의 서브시스템으로의 콜을 나타냄)은, 비록 경고가 정의되지 않았다 하더라도, 그 콜에 대해 이용가능한 최근 데이터가 존재함을 나타낸다. 백 엔드 콜에 대해서 경고가 정의된 경우, 경고 아이콘은 메트릭 아이콘 위에 중첩될 수 있으며 그리고 메트릭 아이콘을 실질적으로 대체할 수 있다. 임의의 원/경고 아이콘의 부재(lack)는, 상기 맵이 로딩된 이후로 그 콜에 대해서 메트릭들이 보여지지 않았음을 의미할 수 있다. 메소드 콜에 대한 경고 아이콘은 메소드 콜의 전체 지속시간에 기초하여 설정될 수 있다. 상기 원은 화살표의 끝에, 콜된 서브시스템 옆에 위치될 수 있다. 간략함을 위해서, 상기 일례에서는, 전부다 흑색인 원(fully solid dark colored circle)은 위험 경고 상태를 나타내며, 속이 하얀 원은 정상 경고 상태를 나타내며, 그리고 반만 흑색인 원은 메트릭들이 이용가능하며 그리고 경고가 정의되지 않았음을 나타낸다. 또한, 상기 영역(504)은 비즈니스 서비스와 비즈니스 트랜잭션의 이름 옆에 경고 표시를 제공하는데, 이는 관련 계층 레벨에 대해서 어떤 경고 레벨이 디스플레이되는지를 나타내기 위한 것이다. 비즈니스 트랜잭션들에 대한 상기 영역(504)에서의 원 표시(도시되지 않음)는 버텍스들(304, 306, 308, 310, 312)에 대한 원 표시와 일치할 수 있다. 서브젝트 서브시스템(subject subsystem)의 경고 레벨은, 서브젝트 서브시스템의 관련된 모든 목적지 서브시스템들에 기초할 뿐만 아니라 서브시스템의 건강도 메트릭들(health metrics)에 기초하는 최상위 경고 레벨을 나타낸다. 또한, 비즈니스 서비스의 경고 레벨은, 그 비즈니스 서비스의 비즈니스 트랜잭션들 중 임의의 것의 최상위 경고 레벨로 설정될 수 있다.

프론트 엔드 서브시스템들은 소켓을 통하여 어플리케이션 서버 밖으로 콜을 행할 수 있다. 이러한 콜들은 웹 서비스 콜들, JDBC 드라이버 콜들, 혹은 다른 유형의 콜들이 될 수 있다. 전형적으로, 웹 서비스들은 어플리케이션 프로그래밍 인터페이스(API) 혹은 웹 API 인데, 이들은 하이퍼텍스트 전송 프로토콜(HTTP)을 통해 액세스되며 그리고 요청된 서비스들을 호스트하는 원격 시스템 상에서 실행된다. 이러한 콜(call)들, 및 다른 것들(예를 들어, JDBC 드라이버 콜(driver call)들과 같은 것)은 여전히 애플리케이션 서버 내에 있고, 이에 따라 이들을 검출할 수 있으며, 이들에 관한 메트릭(metric)들이 획득될 수 있지만, 그러나 이들은 애플리케이션 서버로부터 콜을 행하기 때문에, 이들은 백 엔드 콜(back end call)로 지칭된다. 따라서, 도 5a에서와 같은 전체 맵(map)은 검출된 프론트 엔드(front end)들 및 이들이 백 엔드(back end)들에 행한 콜들을 나타낸다. 이러한 백 엔드 콜들의 목적지는 (웹 서비스들 및 어떤 EJB 콜들의 경우) 다른 프론트 엔드들이거나 혹은 인스트루먼트되지 않은(un-instrument) 백 엔드 컴포넌트들이다. 이러한 인스트루먼트되지 않은 컴포넌트들 대부분은 백 엔드 콜로부터 적어도 부분적으로 식별될 수 있는바, 예를 들어, JDBC 드라이버 콜들은 그들의 목적지 데이터베이스 명칭으로 라벨링(labelling)되고, 그리고 디폴트 소켓 콜(default socket call)들은 목적지 호스트 및 포트(port)로 라벨링된다. 다른 경우에 있어서, 사용자는 커스텀 콜(custom call)들을 정의할 수 있고, 이들을 이들의 목적지로 라벨링할 수 있다. 이러한 경우 모두에 있어, UI는 데이터베이스 혹은 다른 적절한 타입의 컴포넌트를 묘사하는 아이콘으로 그리고 적절하게 라벨링된, 백 엔드 목적지를 나타내는 박스(box)를 제공할 수 있다.

예를 들어, 만약 소켓을 통한 콜이 존재하고, 콜이 인스트루먼트되고, 그리고, 56 밀리초가 걸린다고 알고 있지만, 그 목적지(어떤 서브시스템을 콜하는지)를 모른다면, "미지의 컴포넌트(unknown component)" 아이콘을 보여주는 그리고 시스템 호스트명칭 및 포트로 라벨링된 백 엔드 버텍스와 나란히 UI 내에 그 시간 메트릭(time metric)이 디스플레이될 수 있다. 백 엔드들(321, 332, 334, 336 및 338)은 본질적으로 맵 내의 더미 버텍스들인데, 왜냐하면 이들은 인스트루먼트되지 않은 목적지를 나타내고, 따라서 이들에 대해 목적지에 의해 보고되는 정보를 가질 수 없기 때문이다. 프론트 엔드들로부터의 콜들을 나타내는 에지들의 끝에서, 이러한 버텍스들에 인접한 원형 아이콘은 백 엔드 콜 메트릭들 및 연관된 경보(alert)들을 위한 플레이스홀더(placeholder)들로서의 역할을 한다.

일 프론트 엔드로부터 또 다른 프론트엔드로의 콜(예를 들어, 320으로부터 326으로, 또는 322로부터 328로, 또는 324로부터 330으로의 콜)에서, 풀 인스트루먼테이션(full instrumentation)이 사용가능하다. 콜은, 예를 들어, 웹 서비스들 또는 EJB 클라이언트를 통해 만들어질 수 있다. 이 예에서, 버튼(336)을 통해 사용자에의해 상세보기가 선택되고, 그 결과 각각의 웹 서비스가 개별적으로, 즉, 웹서비스1(341), 웹서비스2(343), 웹서비스3a(345), 웹서비스3b(347), 웹서비스3c(349), 그리고 웹서비스4(351)로 표시된다. 웹서비스는 URL에 의해 표현될 수 있다. 예를 들어, 웹서비스1(341)은 http//127.0.0.1:7080/OrderEngine/services/OrderService|getService1 과 같은 URL에 의해 표현될 수 있다. 웹서비스2(343)는 http//127.0.0.1:7080/OrderEngine/services/OrderService|getService2와 같은 URL에 의해 표현될 수 있다. 웹서비스3a(345)는 http//127.0.0.1:7080/AuthenticateEngine/services/AuthenticationService|getService2.와 같은 URL에 의해 표현될 수 있다. 웹서비스3b(347) 및 웹서비스3c(349)는 웹서비스 3a(345)와 동일한 URL로 표현될 수 있다. 웹서비스4(351)는 http//127.0.0.1:7080/ReportingEngine/services/ReportingService|getService2와 같은 URL에 의해 표현될 수 있다. 이 상세보기에서, 동일한 웹서비스는 그것을 콜하는 각각의 서로 다른 서브시스템에 대해 개별 아이콘으로 표현될 수 있다. 예를 들어, 웹서비스(3a, 3b, 3c)는 동일한 웹 서비스의 서로 다른 인스턴스들일 수 있으나, 서브시스템(320)에 의해 콜될 때 아이콘(345)으로 표현되고, 서브시스템(328)에 의해 콜될 때 아이콘(347)로, 서브시스템(322)에 의해 콜될 때 아이콘(347)으로 표현된다. 또 다른 기법에서, 동일한 웹서비스의 복수의 인스턴스들을 표시하기 위하여 공통 아이콘이 사용된다. 도 5b를 참조하기로 한다.

또한, 상세보기에서, 자식(child) 및 부모(parent) 컴포넌트들을 식별하는 버텍스들이 제공된다. 예를 들어, 부모 트레이드서비스(320) 내에서, 버텍스(340)은 자식 서블릿(servlet) 주문|서비스(PlaceOrder|service)를 나타내고, 버텍스(342)는 자식 서블릿 뷰오더|서비스(ViewOrders|service)를, 그리고 버텍스(344)는 자식 서블릿 트레이드옵션|서비스(TradeOptions|service)를 나타낸다. 주문|서비스는 주문으로 명명된 클래스와 서비스로 명명된 메소드를 나타내고, 뷰오더|서비스는 뷰오더로 명명된 클래스와 서비스로 명명된 메소드를, 트레이드옵션|서비스는 트레이드옵션으로 명명된 클래스와 서비스로 명명된 메소드를 나타낸다. 이 클래스들 전부는 동일한 애플리케이션, 트레이드서비스의 부분이다. 이것들은 애플리케이션 서버에 배치되기 전에 동일한 압축 파일, WAR(web archive file) 또는 EAR(enterprise archive file)에 패키지될 수 있다. 버텍스들(340, 342, 344)은 이것들이 트레이드 서비스 버텍스(320)의 자식 버텍스들이므로 버텍스(320) 내에서 그룹화된다.

인증서비스(322) 내에서, 버텍스(350)는 자식 서블릿 서블릿A|서비스(ServletA|service)를 나타낸다. 보고서비스(342) 내에서, 버텍스(360)는 자식 서블릿 서블릿A|서비스(ServletA|service)를, 버텍스(362)는 자식 서블릿 서블릿B|서비스(ServletB|service)를 나타낸다. 오더엔진(326)에서, 버텍스(327)는 자식 서블릿 축서블릿|서비스(AxisServlet|service)를 나타낸다. 보고엔진(330)에서, 버텍스(331)는 자식 서블릿 축서블릿|서비스(AxisServlet|service)를 나타낸다.

서블릿A|서비스 및 축서블릿|서비스와 같은 서블릿 또는 다른 클래스는 서로 다른 애플리케이션들 또는 서브시스템들에 의해 공유될 수 있음에 주목하여야 한다. 예를 들어, 동일한 자바 압축(.JAR) 파일 또는 라이브러리에 속한 클래스가 서로 다른 애플리케이션들 또는 서브시스템들에 의해 공유될 수 있다. 이 예에서, 서블릿A로 명명된 클래스는 인증서비스와 보고서비스 둘 모두에 의해 공유되는 공통 라이브러리에 속할 수 있다. "서비스"는 트랜잭션에 참여하는 클래스의 메소드 이름을 지칭한다. 마찬가지로, 축서블릿은 오더엔진, 인증엔진 및 보고엔진에 의해 공유되는 공통 라이브러리에 속할 수 있다.

사용자가 버튼(361)을 선택함으로써 요약보기를 선택할 때, 자식 컴포넌트들은 표시되지 않는다. 더 자세한 사항은 도 5b를 참조하기로 한다.

도 5b는, 도 5a의 UI에 대한 대안적인 요약 보기에서, 사용자에 의해 비즈니스 서비스가 선택된 상태의 서브시스템들 및 비즈니스 트랜잭션들의 사용자 인터페이스(UI)(505)를 보여준다. 여기서, 단일 프론트 엔드로부터 기인되는 모든 웹서비스 콜들이 어그리게이션(aggregation)되고 단일 "웹 서비스" 백 엔드 콜로서 표현되며, 따라서, 다른 타입의 콜들과는 다르게, 웹 서비스 콜은 하나 보다 많은 목적지를 가질 수 있다. 이 경우에, 백 엔드 콜은 맵 내에서 포크(fork) 또는 분기(branch)되는 화살표로 나타날 것이다. 일 세트의 데이터만이 이 콜과 관련되고 하나 보다 많은 목적지 노드가 존재하므로, 일 기법에서, 맵 내에서 목적지 노드에 나란히 있는 곳이 아닌 포크의 베이스(base)에 원 "W" 아이콘이 나타난다.

구체적으로, 웹 서비스 버텍스(510)는 도 5a로부터의 버텍스들(341, 343, 345)을 나타낸다. 웹 서비스 버텍스(510)는 포크의 베이스에 있고 목적지 노드들(326, 328)에 나란히 있지 않으며, 따라서 웹 서비스 버텍스(510)에 대한 콜과 관련된 일 세트의 데이터가 존재한다. 웹서비스 버텍스(515)는 도 5a로부터의 버텍스(347)를 나타낸다. 웹서비스 버텍스(515)는 목적지 노드(328) 옆에 또는 인접해 있는바, 그 이유는 콜에 대해 단지 하나의 목적지만이 있기 때문이다. 선택적으로, 웹 서비스 버텍스(515)는 노드(322)와 노드(328) 사이에 있을 수 있으며, 이로 인해 Es11이 여전히 노드(322)와 웹서비스 버텍스(515) 사이에서 연장(extend)될수 있으나, 추가의 에지(도시되지 않음)가 웹 서비스 버텍스(515)와 노드(328) 사이에서 연장된다. 웹 서비스 버텍스(512)는 도 5a로부터의 버텍스들(349, 351)를 나타낸다. 웹 서비스 버텍스(512)는 포크의 베이스에 있고 목적지 노드들(328, 330)에 나란히 있지 않으며, 따라서, 웹 서비스 버텍스(512)에 대한 콜과 관련된 하나의 데이터 세트가 존재한다.

웹서비스들(510, 512)은 두개의 포크되는(forking) 웹서비스 콜들을 나타낸다. 이 웹서비스 콜들은 인증서비스(322)와 인증엔진(328) 사이의 콜과 대조적인데, 인증서비스(322)와 인증엔진(328) 사이의 콜 또한 웹서비스 콜이나, 단일 목적지를 지닌다. 추가적으로, 많은 경우 복수의 에지들이 하나의 에지로 콜랩스되어, 도 5a의 UI(500)에서 보다 더 적은 에지들이 존재한다. 또한, 에지 식별자들이 다시 번호매겨지거나 그렇지 않다면 요약보기를 위해 수정될 수 있다. 예를 들어, UI(500)의 Ed1과 Ed2는 UI(505) 의 Es1으로 콜랩스되고, UI(500)의 Ed3 및 Ed4는 UI(505)의 Es2로 콜랩스되고, UI(500)의 Ed5는 UI(505)의 Es4로, UI(500)의 Ed6은 UI(505)의 Es5로, UI(500)의 Ed7은 UI(505)의 Es6으로, UI(500)의 Ed8은 UI(505)의 Es7로, UI(500)의 Ed9-Ed13은 UI(505)의 Es8로 콜랩스되고, UI(500)의 Ed17과 Ed(18)은 UI(505)의 Es(9)로 콜랩스되고, UI(500)의 Ed23은 UI(505)의 Es15로, UI(500)의 Ed24는 UI(505)의 Es16으로, UI(500)의 Ed19는 UI(505)의 Es10으로, UI(500)의 Ed14 및 Ed20은 UI(505)의 Es11로 콜랩스되고, UI(500)의 Ed15 및 Ed16은 UI(505)의 Es12로, UI(500)의 Ed21은 UI(505)의 Es13으로, UI(500)의 Ed22는 UI(505)의 Es14로, UI(500)의 Ed17은 UI(505)의 Es27로, UI(500)의 Ed25는 UI(505)의 Es17로, 그리고 UI(500)의 Ed26은 UI(505)의 Es18로 콜랩스된다. 표기 "s"는 UI의 요약보기에서의 에지를 나타낸다. 상세보기의 에지 식별자들에 대해 요약보기의 에지 식별자들을 크로스-참조(cross-reference)하는 레코드 또는 매핑이 유지될 수 있다. 예를 들어, Ed1과 Ed2가 Es1에 매핑된다. 버텍스들( 340, 342, 344, 350, 360, 362, 327, 329 및 331)과 같은 상세 레벨 버텍스들이 제거될 수 있다.

또한, 버텍스가 서브시스템의 복수의 인스턴스들을 나타낼 수 있음을 상기하도록 한다. 예를 들어, 트레이드서비스 버텍스(320)는 복수의 머신(machine)들에 걸쳐 실행되는 트레이드서비스 서브시스템의 복수의 인스턴스(instance)들의 요약(summary)을 나타낼 수 있다. 웹 서비스(510)는 트레이드서비스(320) 서브시스템이 실행되는 하나 또는 그 이상의 컴퓨팅 디바이스/머신과 연관되며, 그리고 웹 서비스(512)는 보고서비스(ReportingService)(324)가 실행되는 하나 또는 그 이상의 컴퓨팅 디바이스/머신과 연관된다. 웹 서비스(510 및 512)에 대한 메트릭 및 경보 아이콘은 일 컴퓨팅 디바이스로부터 다음 컴퓨팅 디바이스로 행해진 메소드 콜(들)의 성능 혹은 건강도(health)를 나타낸다.

일 방법에 있어서, 경보는 응답 시간과 같은 시간 메트릭과 연관된다. 경보는, 제 1 레벨(L1)보다 작은 응답 시간에 대해서는 정상 상태(normal status)가 표시되고, 제 1 레벨(L1)과 제 2 레벨(L2) 사이의 응답 시간에 대해서는 경고 상태(caution status)가 표시되고, 그리고 제 2 레벨(L2)보다 큰 응답 시간에 대해서는 위험 상태(danger status)가 표시되도록 구성될 수 있다. 경보는 임의 타입의 성능 메트릭에 근거하여 구성될 수 있다. 예를 들어, 인스트루멘테이션은 많은 타입의 성능 메트릭들을 산출할 수 있는바, 이러한 성능 메트릭들에는, 컴포넌트의 평균 실행 혹은 응답 시간, 초당 혹은 구간별 호출율, 호출의 카운트(count), 구간 단위로 시작은 하지만 끝나지는 않는 호출의 수를 표시하는 동시실행 메트릭(concurrency metric), 및 그 메소드 호출 횟수가 구간별로 특정 임계치를 초과하는 개시된 호출의 수를 표시하는 스톨 메트릭(stalled metric)이 있다. 애플리케이션 런타임(application runtime)에서 획득되어 에이전트(agent)에 의해 보고되는 컴포넌트 데이터의 예들이 존재한다. 경보는 아이템들 중 임의의 아이템에 대해 제공될 수 있다.

또한, 서브시스템들을 지원하는 컴퓨팅 머신 상에서 사용되는 리소스들에 대해, 인스트루멘테이션은 예를 들어, 가비지 수집 힙 사이즈(garbage collection heap size), 파일 및 소켓 활동을 표시하는 대역폭 메트릭(bandwidth metric), 쓰레드(thread)들의 수, 시스템 로그(system log)들, 예외(exception)들, 메모리 리크(memory leak)들 및 컴포넌트 상호작용(component interaction)들을 식별할 수 있는 데이터를 산출할 수 있다. 경보는 또한, 이러한 아이템들 중 임의의 아이템에 대해 제공될 수 있다.

더욱이, 경보는, 특정 파라미터들을 갖는 URL과 같은 비즈니스 트랜잭션 컴포넌트(usiness Transaction Component)에 대한 하나 또는 그 이상의 성능 메트릭들에 근거하여 구성될 수 있다. 예를 들어, 경보는 특정 시기 동안의 비즈니스 트랜잭션 컴포넌트의 평균 응답 시간을 나타낼 수 있다.

아래에서 더 설명되는 바와 같이, 경보 및 메트릭 아이콘에 근거하여, 사용자는 UI에서 묘사된 비즈니스 트랜잭션들, 서브시스템들 및 콜들에 관한 후속 정보를 획득하기 위해 다양한 단계들을 취할 수 있다. 일 방법에 있어서, 사용자는 경보 및 메트릭 아이콘의 존재에 의해 인도되고, 그리고 예를 들어, 문제를 진단하기 위해, 그 연관된 비즈니스 트랜잭션들, 서브시스템들, 및 콜들에 관한 후속 정보를 획득하려고 한다. 더욱이, 아래에서 설명되는 바와 같이, 다른 타입의 정보가 진단시 도움을 주기 UI 상에 제공될 수 있다. 일반적으로, 본 명세서에서 제공되는 다양한 UI들은 하나 또는 그 이상의 윈도우(window)들 내에 제공될 수 있고, 그리고 정보에 액세스하기 위해, 공지된 UI 기술(예를 들어, 팝업 윈도우(popup window), 마우스 오버(mouse over) 혹은 호버 박스(hover box), 툴팁(tooltip), 및 우측 클릭(right-clicking)과 같은 것)을 사용할 수 있다.

특정 비즈니스 트랜잭션들 및 이들의 서브시스템들에 있어서, UI는 주문(Place Order)(310) 및 옵션 트레이딩(Options Trading)(312) 양쪽 모두가 프론트 엔드 서브시스템, 즉 트레이드서비스(TradeService)(320)를 호출하는 것을 표시한다. 예시적 시나리오에서, 사용자는 예를 들어, 주식(stock) 혹은 채권(bond)을 사거나 팔기 위해 수행돼야 하는 주문을 정의함으로써 주문(310)을 개시시킨다. 모든 사용자 입력들, 및 사용자에게 제공되는 정보 혹은 명령들은 웹 페이지 또는 다른 UI를 통해 제공될 수 있다. 또는, 사용자는 풋(put) 또는 콜(call)과 같은 옵션을 포함하는 트레이드를 정의함으로써 옵션 트레이딩(312)을 개시시킨다. 어떤 경우에서건, 트레이드서비스가 사용된다. 트레이드서비스는 예를 들어, 추가 정보를 획득하여 주문/트레이드를 프로세싱하기 위해 시스템 로컬 호스트(321)를 콜한다. 시스템 로컬 호스트(321)에 대해서는 거의 알려져 있지않은데, 왜냐하면 이것은 인스트루먼트되지 않기 때문이고, 따라서 이에 대한 버텍스는 단지 플레이스홀더이다. 트레이드서비스의 인스턴스에 의해 콜되는 컴퓨팅 디바이스(321)의 포트는 알려져 있고(예를 들어, 포트 3456), 그리고 이 정보는 버텍스(321)를 장식(decorate)하는 데 사용된다. 시스템 Local Host(321)는, 또 다른 호스트 혹은 리소스(미도시)를 또한 콜할 수 있지만 이것은 묘사되지 않았다.

컴퓨터 네트워킹(computer networking)에서, 포트는 통신 엔드포인트(communications endpoint)로서의 역할을 하는 애플리케이션-특정 혹은 프로세스-특정 소프트웨어 구성부이다. 이것은 예를 들어, 전송 제어 프로토콜(Transmission Control Protocol, TCP) 및 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)과 같은 인터넷 프로토콜 스위트(Internet Protocol Suite)의 전송 계층 프로토콜들에 의해 사용된다. 특정 포트는 그 번호(이것은 일반적으로 포트 번호로 불림), 연관된 IP 어드레스, 및 통신을 위해 사용되는 프로토콜에 의해 식별된다. TCP 및 UDP는 그들의 패킷 헤더(packet header)들 내에 소스 및 목적지 포트 번호를 특정한다. 네트워크를 통해 데이터를 전송 및 수신하기 위해, 입력 혹은 출력 채널 파일 설명자들(input or output channel file descriptors)(소켓들)을 포트 번호 및 IP 어드레스와 연관시키는 프로세스(바인딩(binding)으로서 알려진 프로세스)가 수행된다. 운영 체계의 네트워킹 소프트웨어는, 모든 애플리케이션 포트들로부터의 출력 데이터를 네트워크 상으로 전송하고 그리고 패킷 IP 어드레스와 포트 번호를 매칭시킴으로써 그 도달된 네트워크 패킷들을 임의의 프로세스에 전달하는 태스크를 갖는다.

프로세스들은 소켓들을 사용함으로써 전송 프로토콜 포트들과의 연관(association)들을 생성한다. 소켓은 전송 엔드-포인트로서 사용되는 소프트웨어 구조이다. 이것은 프로세스를 위해 운영 체계에 의해 생성되고, 그리고 포트 번호와 IP 어드레스의 결합으로 이루어진 소켓 어드레스에 결합된다. 소켓들은 한번에 단방향에서 데이터를 송신 혹은 수신하도록 설정될 수 있거나(반이중 방식(half duplex)), 혹은 양방향에서 동시에 데이터를 송신 혹은 수신하도록 설정될 수 있다(전이중 방식(full duplex)).

트레이드서비스(320)는 주문/트레이드를 요청하기 위해 (웹 서비스 버텍스들(510)로 어그리게이션되는) 하나 또는 그 이상의 웹 서비스들을 사용한다. 웹 서비스(510)는 또한, (a) 주문/트레이드를 프로세싱하는 오더엔진 서브시스템(326), 및/또는 (b) 예를 들어 사용자의 크리덴셜들(credentials)을 검증함으로써 주문/트레이드를 인증하는 인증엔진 서브시스템(328)을 콜한다. 맵은, 트레이드서비스가 거의 동일한 시간에 혹은 상이한 시간에(예를 들어 이것은 아마도 오더 레코드 데이터베이스(Order Records Database)에 대한 콜이 행해진 이후일 것임) 이러한 다른 서브시스템들 양쪽 모두를 콜함을 반드시 표시할 필요가 없으며, 또는 동일한 비즈니스 트랜잭션의 일부로서 혹은 상이한 비즈니스 트랜잭션의 일부로서(결국, 트레이드서비스와 연관된 두 개의 비즈니스 트랜잭션들이 존재함) 이러한 다른 서브시스템들 양쪽 모두를 콜함을 반드시 표시할 필요도 없고, 기타의 경우도 마찬가지이다. 이들 양쪽 모두가 동일한 비즈니스 트랜잭션의 일부로서 하지만 상이한 인스턴스들 동안 콜되는 것도 또한 가능하다. 특정 시기 내의 어떤 시점에서 트레이드서비스가 이러한 프론트 엔드들 양쪽 모두를 웹 서비스(510)를 사용하여 콜했음을 맵이 보여준다.

웹 서비스(510)로부터의 하나 또는 그 이상의 콜들을 서비스하기 위해, 오더엔진 서브시스템(326)은 두 개의 백 엔드들(SQL을 사용하여 오더 레코드들을 저장하는 오더 레코드 데이터베이스(332), 및 시스템 로컬 호스트(334))을 콜한다. 시스템 로컬 호스트(334)는, 예를 들어, 어떤 관리상의 핸드쉐이크(administrative handshake)를 위해 혹은 JDBC 드라이버의 일부인 것으로서 마크(mark)되지 않았던 다른 태스크를 위해 사용될 수 있다. 인증엔진 서브시스템(328)은 예를 들어, 주문/트레이드의 수행에 대해 사용자/고객이 인증되었음을 확인하기 위해, 고객 레코드들을 저장하는 고객 레코드 데이터베이스(336)를 콜한다.

로그인(login)(304)의 비즈니스 트랜잭션은 프론트 엔드 서브시스템, 즉 인증서비스(322)를 포함한다. 앞에서 설명된 예시적 시나리오에서, 로그인은 인증서비스 서브시스템(322)에서 컴포넌트들(CM1-CM4a)을 호출하고 인증엔진 서브시스템(328)에서 CM7-CM10을 호출한다.

에지(513)(Es11)로 묘사된 바와 같이, CM4a는, 인증서비스 서브시스템(322)과 동일한 서버 혹은 상이한 서버 상에 있을 수 있는 인증엔진 서브시스템(328)에서 CM7을 콜한다. CM7이 CM8을 콜하는 바, CM8은 고객 레코드에 액세스하여 사용자 로그인이 패스워드와 매칭됨을 확인하기 위해 고객 레코드 데이터베이스(336)를 콜한다. 이것이 성공이라고 가정하면, 제어 흐름은 CM7로 리턴(return)하고 CM7은 CM9를 콜한다. CM9는 고객 레코드들에 다시 액세스하여 사용자의 어카운트(account)가 양호한 상태(good standing)에 있음(예를 들어, 어카운트를 유지하기 위해 사용자가 수수료를 지불했음 혹은 최소 개수의 트레이딩을 했음)을 확인하기 위해 고객 레코드 데이터베이스(336)(혹은 또 다른 데이터베이스)를 콜한다. 이것이 성공이라고 가정하면, 제어 흐름은 CM7로 리턴하고 CM7은 CM10을 콜한다. CM10은 고객 레코드들에 다시 액세스하여 (사용자가 현재 로그인되었음을 표시하도록) 레코드들을 업데이트하기 위해 고객 레코드 데이터베이스(336)(혹은 또 다른 데이터베이스)를 콜하고, 그리고 CM7에게 로그인 상태=참(true)을 리턴한다. 그 다음에 제어 흐름은 CM2로 리턴하고, CM2는 CM4b를 콜하고, CM4b는 또한 CM5를 콜한다. 그 다음에, 제어 흐름은 CM4b로 리턴하고, 그 다음에 CM2로 리턴하고, 마지막으로 CM1로 리턴하는 바, 이 포인트에서 로그인 비즈니스 트랜잭션의 인스턴스가 끝난다.

밸런스(Balances)(306) 및 어카운트 요약(Account Summary)(308)은 공통 프론트 엔드 서브시스템, 즉 보고서비스(324)를 호출한다. 예시적 시나리오에서, 사용자는, 어카운트 밸런스(account balance)를 획득하여, 예를 들어 특정 어카운트 내의 자금(funds)의 양을 알기 위한 요청을 수행함으로써 밸런스(306)를 개시시킨다. 또는, 사용자는 최근 트랜잭션들(예를 들어, 주문/트레이드, 자금 이체, 등)의 보고서(예를 들어, 거래명세서(statement))를 획득기 위한 요청을 수행함으로써 어카운트 요약(308)을 개시시킨다. 어떤 경우에서건, 보고서비스(324)는 웹 서비스(512)를 콜함으로써 보고 요청을 프로세싱하고, 웹 서비스(512)는 또한 인증엔진 서브시스템(328)을 콜하고, 인증엔진 서브시스템(328)은 고객 레코드들에 액세스하여 보고서의 획득에 대해 사용자/고객이 인증되었음을 확인하기 위해 고객 레코드 데이터베이스(336)를 콜할 수 있다.

일 실시예에서, 제어 흐름은 보고서비스(324)로 리턴하고, 보고서비스(324)는 웹 서비스(512)를 통해 보고엔진 서브시스템(330)에 대한 또 다른 콜을 행하고, 보고엔진 서브시스템(330)은 보고서의 제공을 위해 사용되는 레코드들을 획득하기 위해 보고 레코드 데이터베이스(338)를 콜함으로써 보고 요청을 수행한다. 웹 서비스(512)에 대한 이러한 콜은, 원하는 보고서의 타입, 어카운트 식별자, 관련된 시간 프레임 등을 특정하는 정보를 포함할 수 있다.

도 4b1 내지 도 4b3과 연계되어 설명된 바와 같이 계산된 시간 메트릭들이 UI(505) 상에, 예를 들어 대응하는 버텍스 위에, 디스플레이될 수 있다. 즉, UI 및 그 버텍스들(자식 및 부모 버텍스들을 포함) 그리고 에지들이 메트릭들로 장식된다. 총 지속시간(total duration), 순 지속시간(net duration) 및/또는 대기 시간(wait time)이 디스플레이될 수 있다. 여기서, 로그인 버텍스(304) 위에는 로그인의 총 지속시간(1300 ms)이 디스플레이되고, 인증서비스 버텍스(322) 위에는 600 ms의 순 지속시간이 디스플레이되고, 에지(513) 위에는 인증엔진(328)에 대한 콜을 위한 서브시스템간 통신 시간(100 ms)이 디스플레이되고, 인증엔진 버텍스(328) 위에는 지속시간 300 ms가 디스플레이되고, 그리고 에지(613) 위에는 고객 레코드에 할당된 300 ms의 대기 시간이 디스플레이된다. 따라서 이러한 버텍스들 및 에지들이 메트릭들로 장식된다. 이러한 메트릭들은, 비즈니스 트랜잭션의 단일 인스턴스(예를 들어, 로그인)에 대한 것일 수 있거나, 혹은 더 일반적으로는, 비즈니스 트랜잭션의 복수의 인스턴스들에 걸친 평균(예를 들어, 특정 시간 구간에 걸친 평균)일 수 있다.

로그인 버텍스(304)를 위해 디스플레이되는 위험 레벨 경보는, 임계치 레벨(예를 들어, 1000 ms)을 넘는 1300 ms의 시간에 근거할 수 있다. 인증서비스 버텍스(322)에 대해 디스플레이되는 위험 레벨 경보는, 임계치 레벨(예를 들어, 300 ms)을 넘는 600 ms의 시간에 근거할 수 있다. 에지(513)에 대해 디스플레이되는 위험 레벨 경보는, 임계치 레벨(예를 들어, 50 ms)을 넘는 100 ms의 시간에 근거할 수 있다. 인증엔진 버텍스(328)에 대해 디스플레이되는 정상 레벨 경보는, 임계치 레벨(예를 들어, 500 ms)을 넘지 않는 300 ms의 시간에 근거할 수 있다. 에지(613)의 첨단부에 있는(예를 들어, 백 엔드 콜의 엔드포인트에 있는) 반만 어둡게 채색된 원은 관련 메트릭들이 이용가능하고 어떠한 경보도 정의되지 않았음을 표시한다.

일반적으로, UI(510)는 다양한 비즈니스 트랜잭션들, 서브시스템들, 및 콜들에 대한 시간 메트릭들로 채워질 수 있다. 시간 메트릭들이 단지 간략한 설명을 위해 로그인 비즈니스 트랜잭션(304)에 대해서만 묘사되지만, 실제로는, 모든 비즈니스 트랜잭션들에 대해 동시에 디스플레이될 수 있다. 복수의 시간 메트릭들이 서로 다른 비즈니스 트랜잭션들에 의해 호출된 서브시스템(예를 들어, 주문(310) 및 옵션 트레이딩(312)에 의해 호출된 트레이드서비스(320))과 연관될 때, 각각의 시간 메트릭은 컬러 코딩(color coding) 혹은 다른 시각적 기술에 의해 비즈니스 트랜잭션들 중 하나와 연관될 수 있다. 예를 들어, 주문과 연관된 시간 메트릭은 트레이드서비스 버텍스(320) 위에 하나의 컬러로 디스플레이될 수 있고, 옵션 트레이딩과 연관된 또 다른 시간 메트릭은 트레이드서비스 버텍스(320) 위에 또 다른 컬러로 디스플레이될 수 있다.

시계 아이콘(511)이, 로그인 비즈니스 트랜잭션의 모든 서브시스템들 가운데 가장 높은 순 지속시간(혹은 총 지속시간 혹은 대기 시간)을 갖는 서브시스템에 대해 제공될 수 있다. 만약 두 개의 순 지속시간들이 오차허용도(tolerance) 내에서 동일하다면, 상위 레벨 서브시스템이 이 아이콘을 수용할 수 있거나, 아이콘이 양쪽 서브시스템들과 함께 디스플레이될 수 있고, 또는 아이콘이 디스플레이될 필요가 없다.

이러한 방식으로, 사용자는 소정의 서브시스템이 문제가 있는지를 빠르게 알아 낼 수 있고, 그 서브시스템에 관한 진단에 집중할 수 있다. 문제가 있는 다수의 서브시스템들이 또한 식별될 수 있다. 경보의 심각도(severity)가 또한 사용자를 안내할 수 있다. 예를 들어, 만약 인증엔진 서브시스템에 대해서 정상 레벨 경보가 디스플레이되고 인증서비스 서브시스템에 대해 위험 레벨 경보가 디스플레이된다면, 사용자는 인증서비스 서브시스템을 먼저 조사하도록 인도될 수 있다. 사용자가 서브시스템 및 서브시스템이 호출한 컴포넌트들에 관한 추가적 세부사항들을 획득할 수 있도록 하는 다양한 기술들이 제공된다.

UI 상에 제공되는 메트릭들은 특정 시간 구간에서의 피관리 애플리케이션으로부터의 데이터에 근거한다. 일 방법에서, UI는 초기에 메트릭들 없이 디스플레이되고, 그리고 사용자는 예를 들어, 사용자 특정 필터 기준에 매칭되는 트랜잭션들을 찾음으로써, 메트릭들을 획득하기 위한 커맨드를 입력한다. 사용자는 이러한 기준을 수동으로 특정할 수 있거나, 혹은 하나 또는 그 이상의 기준의 디폴트 세트가 사용될 수 있다. 그 다음에 UI는 기준과 매칭되는 트랜잭션들로부터의 메트릭들로 채워진다. 또 다른 방법에서, UI는 초기에 필터 기준의 디폴트 세트에 근거하여 캡처(capture)된 메트릭들과 함께 디스플레이될 수 있다.

도 5c는 도 5b의 사용자 인터페이스를 묘사하는바, 여기에는 로그인 비즈니스 트랜잭션(304)에 대한 메트릭들을 보여주는 호버 박스가 추가되어 있다. UI(520)에서, 사용자는 비즈니스 트랜잭션의 버텍스, 서브시스템 혹은 웹 서비스 콜 위에 혹은 에지 위에 커서를 포인팅하여(이것은 경사진 화살표로 나타나 있음) 관련 성능 메트릭들이 디스플레이되도록 마우스와 같은 포인팅 디바이스(pointing device)를 사용할 수 있다. 일반적으로, 사용자는, 아래에서 더 설명되는, UI의 보조 영역에 관련 정보가 디스플레이되도록 하기 위한 선택을 입력하기 위해 버텍스를 포인팅하여 그 버텍스 상에서 클릭을 행할 수 있다. 요소를 포인팅함으로써, 일반적으로 호버링 툴팁(hovering tooltip)이 나타나게 되며, 그 요소 상에서 클릭을 행함으로써(즉, 선택함으로써), 일반적으로 UI의 또 다른 부분에 관련 정보가 디스플레이된다. 노드는 예를 들어, 비즈니스 트랜잭션 전체와 관련될 수 있거나 혹은 비즈니스 트랜잭션의 서브시스템과 연관될 수 있다. 특정 성능 메트릭들 및 이들의 포맷이 구성가능하다. 여기서, 커서가 로그인에 대한 버텍스에 포인팅되고 잠시 동안 그 위에서 유지되는 경우 호버 박스(522)가 나타나게 된다. 따라서, 사용자는 선택된 비즈니스 트랜잭션과 연관된 메트릭들을 디스플레이하기 위한 커맨드를 제공한다.

호버 박스는 비즈니스 트랜잭션(로그인)의 명칭을 식별할 뿐만 아니라 관련 시간 구간에 대한 경보 레벨 및 성능 메트릭들을 식별한다. 경보 레벨은 위험한 상태를 표시한다. 그 다음에, 1300 ms의 평균 응답 시간(총 지속시간)이 디스플레이된다. 이러한 시나리오에서, 예를 들어, 로그인의 응답 시간은 로그인의 4개의 인스턴스들에 걸친 평균이다. "카운트(Count)"는 최근의 시간 구간(이것은 분석 하에 있는 시간 구간임)에서 로그인의 호출 혹은 인스턴스의 수를 표시한다. 여기서, 카운트=4가 표시하는 것은 호출의 수가 4개임을 나타낸다. "최소치(Min)"는 최소 응답 시간, 예를 들어, 1100 ms를 표시하고, "최대치(Max)"는 최대 응답 시간, 예를 들어, 1500 ms를 표시한다. "구간별 에러(Errors per interval)"는 최근의 시간 구간에서 로그인 시 에러의 수를 식별한다. "구간별 응답(Responses per interval)"은 로그인과 연관된 응답의 수(예를 들어, 4개의 응답)를 식별한다. "스톨 카운트(Stall count)"는 최근 시간 구간에서 로그인 시 스톨의 수(예를 들어, 0개의 스톨)를 표시한다. 호버 박스는 선택된 비즈니스 트랜잭션을 보고하는 모든 컴퓨팅 디바이스/에이전트에 걸쳐 요약 성능 데이터를 제공할 수 있다.

도 5d는 도 5b의 사용자 인터페이스를 묘사하는바, 여기에는 인증서비스 서브시스템(322)에 대한 메트릭들을 보여주는 호버 박스가 추가되어 있다. UI(525)에서, 비즈니스 트랜잭션에 대한 호버 박스를, 예를 들어 버텍스(304)를 통해, 제공하는 것에 추가하여, 메트릭들을 갖는 호버 박스가 로그인의 서브시스템들 중 임의의 서브시스템에 대해 유사하게 제공될 수 있다. 예를 들어, 인증서비스 서브시스템(322)에 대한 호버 박스(523)는 그 서브시스템에 특정된 메트릭들(예를 들어, 경보 레벨, 평균 응답 시간, 동시실행 호출의 수, 구간별 에러, 구간별 응답, 및 스톨 카운트)을 표시할 수 있다.

따라서, 소정의 서브시스템에 대해, 사용자는 연관된 성능 메트릭들의 디스플레이를 트리거할 수 있다. 이것은 해당 서브시스템을 통과하는 모든 트랜잭션들에 걸쳐 존재하며, 이에 따라 일반적인 건강도 혹은 전체 성능이 나타나게 된다.

또 다른 예로서, 웹 서비스(342)에 대한 호버 박스는 트레이드서비스(320)에 의해 행해진 콜들에 특정된 유사한 메트릭들(예를 들어, 경보 레벨, 평균 응답 시간, 구간별 에러 및 스톨 카운트)을 표시할 수 있다.

사용자는 또한, 보고 에이전트들 및 에이전트별 데이터의 목록을 디스플레이하는 것을 트리거할 수 있다. 에이전트별 데이터와 함께, 종속 맵(dependency map)이, 특정 비즈니스 트랜잭션을 보고하는 컴퓨팅 디바이스/에이전트 모두에 걸친 요약 성능 데이터, 예를 들어 전체적인 건강도 데이터를 디스플레이할 수 있다. 현재 값들이 호버 상에 디스플레이되고, 그리고 시간 동향(time trends)이 또한, 예를 들어, 보조 영역에서, 트랜잭션 목록(Transaction List), 세부사항(Details) 및 트레이스 보기(Trace View)로 라벨링된 탭(tab)들 하에서 이용가능하다. 마지막으로, 동일한 종류의 요약 데이터가 또한, 식별된 서브시스템들(프론트 엔드들 및 이들의 백 엔드 콜들)에 대해 이용가능한바, 호버 상의 스냅샵(snapshot)과 시간 동향 양쪽 모두이다.

툴팁 데이터(tooltip data)(및 도 5l에 도시된 데이터 도표(data charts))는 "일반적인 건강도" 혹은 "전체 성능"에 대응하는바, 왜냐하면 이것은 모든 에이전트들에 관한 모든 관련 트랜잭션들에 걸쳐 요약된 것이기 때문이다. (도 5k에서와 같은) 기여 에이전트(contributing agent)들 및 에이전트별 성능 메트릭들을 나열하는 경우, 나열된 에이전트에 의해 보고된(즉, 특정 JVM 상에서 실행되는) 모든 관련 트랜잭션들에 걸쳐 요약이 수행된다. 이것은 서브시스템의 단일 "위치(Location)"로서 지칭되고, 그리고 위치 건강도 메트릭(Location health metric)들이 설명된다.

도 5e는 도 5b의 사용자 인터페이스를 묘사하는바, 여기에는 로그인에 대한 옵션들 보여주는 콘텍스트 메뉴(context menu)(532)가 추가되어 있다. 일반적으로, 버텍스(304)와 같은 비즈니스 트랜잭션의 버텍스는 해당 버텍스와 연관된 사용자 커맨드(예를 들어, 포인팅 디바이스를 통해 입력되는 커맨드)를 제공하기 위해 사용될 수 있다. 사용자는 버텍스를 포인팅하고 마우스의 우측 클릭을 행하여 UI(530)로 하여금 버텍스에 특정된 옵션들의 목록을 디스플레이하도록 할 수 있다. 그 다음에, 임의의 옵션이 선택될 수 있는바, 가능한 일 방법에서 이러한 선택은 커서로 해당 옵션을 포인팅하고 좌측 클릭을 행함으로써 이루어질 수 있다.

예를 들어, 콘텍스트 메뉴(532)는 사용자로 하여금 로그인(304)에 관한 추가 정보의 획득을 위해 4개의 옵션들 중에서 선택을 행할 수 있도록 한다. 첫 번째 옵션은 로그인의 맵을 디스플레이하는 것으로, 이것은 결과적으로 도 5f의 인터페이스를 생성한다. 두 번째 옵션은 매칭 트랜잭션들을 찾는 것으로, 이것은 결과적으로 도 5g의 인터페이스를 생성한다. 세 번째 옵션은 로그인을 위한 위치들(즉, 기여 에이전트들 및 이들의 연관된 건강도 메트릭 데이터)을 찾는 것으로, 이것은 결과적으로 도 5k의 인터페이스를 생성한다. 네 번째 옵션은 로그인에 대한 건강도 메트릭들을 보는 것으로, 이것은 결과적으로 도 5l의 인터페이스를 생성한다. 건강도 메트릭들, 성능 메트릭들의 세트는, 예를 들어, 로그인의 전체 건강도를 표시할 수 있다.

도 5f는 도 5e의 UI의 콘텍스트 메뉴(532)로부터 개시된 로그인 비즈니스 트랜잭션의 맵의 사용자 인터페이스를 묘사한다. "로그인의 맵을 디스플레이(Display map of Login)"가 선택되는 경우, 로그인이 선택되었음을 표시하기 위해 영역(504)에서의 트리(tree)가 (예를 들어, 밑줄긋기(underlining)을 행함으로써) 자동으로 업데이트되고, 그리고 UI(540)는 이렇게 선택된 비즈니스 트랜잭션에 대한 세부사항들을 제공한다. 대안적으로, 사용자는 콘텍스트 메뉴(532)를 사용하는 대신, 트리 내의 대응하는 버텍스를 선택함으로써 영역(504)으로부터 로그인을 선택할 수 있다. 또 다른 방법으로서, 사용자는 (도시된 바와 같은) 화살표 형상의 커서를 사용하여 로그인 버텍스(304) 상에서 더블 클릭(souble click)을 행할 수 있다. 버텍스(304) 상에서의 싱글 클릭(single-click)으로 그 버텍스를 선택할 수 있고, 그리고 보조 디스플레이 영역 혹은 하부 구획(lower pane)(562)이 나타나게 된다.

여기서, 사용자 선택은 UI로 하여금 로그인(304)를 나타내는 버텍스(304), 그리고 연관된 서브시스템 버텍스들(322, 328 및 336)을 굵은 실선 경계로 강조(highlight)하도록 한다. 다시 말하면, 버텍스들의 경계를 변경함으로써 강조하는 것은 하나의 옵션인바, 따라서 컬러(color), 쉐도우(shadow) 및/또는 다른 시각적 효과의 사용이 또한 가능하다. 로그인과 연관된 에지들은 또한, 예를 들어, 두께를 증가시키거나 혹은 다른 시각적 기술에 의해 강조될 수 있다. 이러한 강조를 통해, 사용자는 사용자 선택 비즈니스 트랜잭션에 관련된 서브시스템들(뿐만 아니라 이러한 서브시스템들 간의 콜 종속 관계(calling dependency relationships))을 용이하게 식별하여 여기에 집중할 수 있다. 사용자 선택 비즈니스 트랜잭션에 관련되지 않은 서브시스템들의 버텍스들은 강조되지 않고, 강조되지 않은 상태로 있을 수 있는바, 예를 들어, 파선(dashed) 혹은 점선(dotted) 경계를 가질 수 있다. 이러한 강조는 일 노드 혹은 화살표를 또 다른 버텍스 혹은 에지와 시각적으로 구분하기 위한 하나의 방법이다.

도 5g은 도 5e의 UI의 콘텍스트 메뉴(532)로부터 개시된 로그인 비즈니스 트랜잭션에 대한 매칭 트랜잭션들을 찾기 위한 사용자 인터페이스를 묘사한다. UI(550) 내에는, 사용자로 하여금 현재 선택된 비즈니스 트랜잭션(예를 들어, 로그인)에 대한 매칭 트랜잭션 인스턴스들을 찾을 수 있도록 하는 윈도우(564)가 디스플레이된다. 이 윈도우는 사용자로 하여금, 트랜잭션 맵핑 모드에서, 장래에 애플리케이션의 인스트루멘테이션으로부터의 데이터를 획득할 때 사용될 하나 또는 그 이상의 필터 기준을 갖는 커맨드를 입력할 수 있게 한다. 예를 들어, 클라이언트 컴퓨팅 디바이스의 사용자가 애플리케이션에 로그인하는데 문제를 갖는 시나리오(이 경우 로그인이 평소와 달리 오래 시간을 필요로 함)를 고려해 본다. 사용자는 도움 센터(help center)의 직원에게 전화하여 문제를 설명할 수 있다. 도움 센터 직원은 문제를 진단하기 위해 여러 단계를 수행할 수 있는데, 예를 들어 사용자에게 문제를 야기한 동일한 단계를 반복하도록 지시할 수 있으며, 트랜잭션으로부터의 메트릭들의 새로운 레코드를 개시할 수 있다. 이것은 도움 센터 직원이, 이러한 문제가 특정 사용자에게만 특정되어 해당 사용자에 대해 매번 일어나는 문제인지 아니면 로그인을 시도하는 모든 사용자 혹은 대부분의 사용자에게 일어나는 일반적인 문제인지를 결정하는데 도움을 줄 수 있다. 만약 문제가 사용자에게 특정된 문제라면, 단지 그 사용자에 대해서만, 추가적 매칭 트랜잭션들의 위치가 결정될 수 있다. 윈도우(564)는 클라이언트 컴퓨팅 디바이스의 사용자를 필터 기준으로 식별하기 위한 필드(사용자Id)를 포함할 수 있다. 문제가 일반적인 문제인지 아니면 특정적인 문제인지 여부를 결정하는 것은 문제의 원인을 격리시키는 경우 유용하다.

도움 센터 직원은, 장래 모니터링 시기(예를 들어, 그 다음 몇 초 혹은 몇 분)에 데이터의 레코드를 구성함으로써 추가적 데이터를 획득할 수 있다. 도움 센터 직원은 트랜잭션들에 대한 임계 지속시간(이것은 특정된 수의 밀리초 혹은 이보다 긴 시간임)을 입력할 수 있다. 이것이 의미하는 바는, 임계치를 초과하는 장래 로그인 비즈니스 트랜잭션들(예를 들어, CM1을 호출하는 트랜잭션들)에 대한 컴포넌트 데이터만이 UI를 통해 캡처 및 디스플레이됨을 의미한다. 일부 경우에 있어서, 비즈니스 트랜잭션은 복수의 쓰레드들을 포함하고, 이러한 경우, 일 방법에 있어서, 첫 번째 쓰레드가 캡처 및 디스플레이될 수 있다. 그 구성에 따라, 모든 쓰레드들이 또한 캡처될 수 있지만, 전형적으로는 그 첫 번째 쓰레드의 첫 번째 컴포넌트에 의해 트레이스(trace)들이 나열/라베링된다.

더욱이, 도움 센터 직원은, (a) 특정된 수의 초 이후와, 그리고 (b) 특정된 수의 매칭 트랜잭션들(예를 들어, 매칭 인스턴스들 혹은 트레이스들)이 검출된 이후 중 더 일찍 일어나는 것 이후에 종료가 일어나도록 시기를 설정할 수 있다. 예를 들어, 도움 센터 직원은 임계치를 1000 ms에 대해 설정하고, 180초(3분) 이후에 혹은 10개의 매칭 트랜잭션들 이후에, (이중 먼저 일어나는것 이후에) 중지가 일어나게 할 수 있다. 도움 센터 직원은 모니터링 시기를 개시시키기 위해 "오케이(OK)" 버튼을 선택할 수 있거나, 또는 새로운 모니터링 시기를 개시시킴 없이 윈도우를 닫기 위해 "닫기(close)" 버튼을 선택할 수 있다.

윈도우(564)는, 임의의 필터 기준(최소 및 최대 트랜잭션 지속시간을 포함할 뿐만 아니라 에이전트 혹은 호스트 식별자 또는 다른 인자들에 의한 필터링을 포함함)을 설정하는데 사용될 수 있다.

매칭 트랜잭션들에 대한 정보가 보조 영역(562)에 묘사된다. 보조 영역(562)은, 각각의 트랜잭션 인스턴스의 총 지속시간 혹은 다른 시간 메트릭, 보고 에이전트 식별자, 에이전트가 실행되는 호스트의 식별자, 트랜잭션의 시작 시간의 타임스탬프를 나열하는 테이블(table)을 제공한다. 시간은 시, 분, 초 단위로 나열된다. 1초의 분수 값이 또한 제공될 수도 있다. 보조 영역(562)은 트랜잭션 인스턴스들과 연관된 임의 타입의 성능 메트릭을 제공할 수 있다.

예를 들어, 매 15초 마다 수집된 메트릭들은 이러한 트랜잭션 트레이스 데이터(transaction trace data)와는 다르다. 트랜잭션 트레이스들은 매칭 트랜잭션들을 레코딩하는 것, 그리고 콜 시퀀스 및 각각의 콜의 지속시간들(및 시퀀스의 총 지속시간)을 식별하는 것을 포함한다. 특정 트랜잭션이 에러를 보고했는지에 관한 정보가 또한 획득된다.

보조 영역(562)은 예를 들어, 윈도우 혹은 UI(550)의 다른 부분으로서 디스플레이될 수 있거나, 또는 개별 디스플레이 스크린 상에 디스플레이될 수 있다. 보조 영역이 유향 그래프 영역(502)과 동시에 디스플레이되는 경우 유용하다. 보조 영역은 UI의 임의의 부분에 나타날 수 있다.

사용자는 보조 영역(562)에서의 표 엔트리(table entry)들을 분류하기 위해 컬럼 표제(column headings)를 클릭할 수 있다. 또 다른 방법에서, 보조 영역(562)은 둘 혹은 그 이상의 축(axis)들 상에 결과를 제공할 수 있는바, 여기서 일 축은 시간을 나타내고, 하나 또는 그 이상의 다른 축들은 다른 테이블 표제들(예를 들어, 지속시간, 트랜잭션 id, 에이전트 id, 및 호스트 id)을 나타낸다. 막대형 도표(bar charts), 파이형 도표(pie charts) 등과 같은 다른 시각적 디스플레이들이 가능하다. 가장 긴 지속시간의 트랜잭션들이 예를 들어, 진단을 위해 빠르게 식별될 수 있다.

여기서는, 4개의 트랜잭션들의 위치가 결정되어 있다(호스트A에서 에이전트A로부터 두 개, 그리고 호스트B에서 에이전트B로부터 두 개). 에이전트A에서의 트랜잭션들의 응답 시간(총 지속시간)은 1100 ms와 1200 ms인바, 그 평균은 1150 ms이다. 에이전트B에서의 트랜잭션들의 응답 시간(총 지속시간)은 1500 ms와 1400 ms인바, 그 평균은 1450 ms이다. 따라서, 4개의 트랜잭션들의 평균 응답 시간은 1300 ms이다. 사용자는 보조 영역(562)에 현재 디스플레이되는 동일한 타입의 트랜잭션 인스턴스들을 더 획득하기 위해 "더 찾기(find more)" 버튼을 선택할 수 있다. 일 방법에서, 이러한 검색은 윈도우(564)에 의해 설정된 동일한 필터 기준을 자동으로 사용하고, 이에 따라 사용자는 기준을 다시 입력할 필요가 없게 된다. 즉, "더 찾기" 커맨드는 이전과 동일한 기준으로 트랜잭션 트레이스 세션(transaction trace session)을 반복한다. 또는, 사용자는 새로운 기준으로 다시 검색할 수 있다. 어느 경우이건, 보조 영역(562)은, 이전 결과들 대신 혹은 이전 결과들에 추가하여, 새로운 결과들로 업데이트된다.

보조 영역(562)은, 추가적 매칭 트랜잭션들이 식별되는 대로, 실시간으로 업데이트될 수 있다. 더욱이, 영역(566)은 사용자에게 검색의 진행에 관한 정보를 그 완료 전에 제공할 수 있다. 여기서, 사용자가 제공받는 정보는, 지금까지, 지속시간에 있어서 1000 ms를 초과하는 4개의 트랜잭션들이 트레이스/위치결정되었고, 그리고 검색의 잔존 시간이 53초라는 것이다. 영역(566)에서의 버튼들은 사용자로 하여금 현재 검색을 중지시키거나 혹은 다시 개시킬 수 있게 한다. 보조 영역(562)의 상대적인 크기는, 추가 트랜잭션들의 위치가 결정됨에 따라, 특정 포인트까지 확장할 수 있다. 스크롤링 메커니즘(scrolling mechanism)은 모든 결과를 동시에 디스플레이하기에 스크린 상의 공간이 충분하지 않은 경우 사용자로 하여금 추가 트랜잭션들을 볼 수 있게 할 수 있다. 일 방법에서, 결과들은 테이블 내에 엔트리들로서 혹은 가로칸에 디스플레이될 수 있다. "소거(Clear)" 버튼은 사용자로 하여금 목록으로부터 오래된 트랜잭션 인스턴스들 모두(즉, 이전 레코딩 세션으로부터의 모든 트레이스들)를 제거할 수 있게 한다. 엔트리에 바로 옆에 있는 체크박스(checkbox)를 선택한 후 "삭제(Delete)" 버튼을 선택함으로써, 개별 엔트리들이 사용자에 의해 삭제될 수 있다.

레코딩 세션이 완료되고 어떠한 트랜잭션도 보조 영역(562)에서 선택되지 않는 경우, 로그인의 버텍스에 가깝게 위치된 타이밍 데이터(timing data)는 메트릭들의 현재 세트를 반영하도록 업데이트될 수 있다. 예를 들어, 로그인의 평균 지속시간(1300 ms)이 디스플레이될 수 있다. 연관된 서브시스템 버텍스들(322, 328 및 336)의 평균 총 지속시간들, 그리고 서브시스템간 통신 시간들이 또한 디스플레이될 수 있다. 만약 사용자가, 체크 박스들을 선택한 후 "맵에서 보기(View in map)" 버튼을 선택함으로써 유향 그래프 영역(562)에서 하나 또는 그 이상의 트랜잭션들을 선택한다면, 분류 맵 영역(502)이 그 대응하는 메트릭들로 업데이트될 수 있다. 예를 들어, 만약 첫 번째 두 개의 엔트리들이 선택된다면, 1150 ms의 지속시간이 로그인 버텍스(304)에 대해 제공되고, 그리고 대응하는 메트릭들이 선택에 따라서는 다른 버텍스들에 대해 제공된다.

일부 트랜잭션들에 있어서, 비즈니스 트랜잭션의 서브시스템들 모두보다 작은 수가 호출될 수 있음에 유의해야 한다. 이것은, 사용자가 보조 영역(562)으로부터 트랜잭션 인스턴스를 선택하고 이후 "맵에서 보기"를 선택하는 경우, 단지 호출된 서브시스템들만을 강조하고 유향 그래프 영역(502)에서의 다른 서브시스템들은 강조하지 않음으로써 반영될 수 있다. 예를 들어, 도 5j에 묘사된 바와 같이, 트랜잭션 인스턴스들 중 하나는 인증서비스를 호출할 수 있지만 인증엔진 또는 고객 레코드는 호출할 수 없는 바, 이러한 경우에 버텍스들(304 및 322)은 강조되지만, 버텍스들(328 및 336) 또는 에지들(513 및 613)은 강조되지 않는다.

도 5h는 선택된 비즈니스 트랜잭션의 콘텍스트에서, 인증서비스 서브시스템에 대한 매칭 트랜잭션들을 찾기 위한 사용자 인터페이스를 묘사한다. 비즈니스 트랜잭션과 연관된 트랜잭션 트레이스들을 찾기 위한 대안으로서, 임의의 선택된 비즈니스 트랜잭션의 콘텍스트에서 하나 또는 그 이상의 사용자 선택 서브시스템들과 연관된 트랜잭션 트레이스들을 찾는 것이 가능하다. 이러한 예에서, 사용자는 UI(555) 내의 인증서비스 서브시스템에 대해 영역(504)에서 프론트 엔드 뷰(front end view)를 선택한다. 프론트 엔드 뷰는 프론트 엔드 서브시스템에서 발신되는 트랜잭션들 모두를 나타낸다. 이러한 선택에 있어서, 선택된 서브시스템과 연관되지 않은 영역(502)에서의 버텍스들은 제거된다. 선택에 따라서는, 연관된 비즈니스 트랜잭션들(304 및 312)에 대한 버텍스들은 잔존할 수 있다. 더욱이, 인증서비스 서브시스템에 종속된 하나 또는 그 이상의 추가적 서브시스템들이 디스플레이될 수 있다. 예를 들어, 또 다른 미지의 컴포넌트(소켓)(323)가 묘사된다. 인증서비스는, 트레이딩 비즈니스 서비스(Trading Business Service)의 일부로서 정의된 비즈니스 트랜잭션들 중 임의의 비즈니스 트랜잭션에 관련되지 않은 어떤 백업 시스템(backup system)을 때때로 콜할 수 있다. 이러한 경우에, 그 백업 시스템은 프론트 엔드 뷰에는 나타나지만 트레이딩 비즈니스 서비스 맵에는 나타나지 않는다.

여기서, 사용자는 콘텍스트 메뉴(예를 들어, 도 5e에서의 콘텍스트 메뉴(532)와 같은 것)를 호출하기 위해 아이콘(322)을 포인팅함으로써 아이콘(322)을 선택하고, 그리고 매칭 트랜잭션들을 찾기 위해 "매칭 트랜잭션 찾기(Find matching transactions)"를 선택하는바, 이로 인해 결과적으로 디스플레이되는 것이 윈도우(565)이다. 이러한 예에서는, 로그인 비즈니스 트랜잭션이 선택되고, 이에 따라 단지 로그인 비즈니스 트랜잭션에서만 인증서비스를 호출하는 매칭 트랜잭션들이 고려된다. 임계치는 서브시스템의 총 지속시간과 비교되어 실행될 수 있다. 이러한 예에서는 다시 임계치가 1000 ms에 설정된다. 따라서, 프론트 엔드를 고려함이 없이 특정 비즈니스 트랜잭션에 대한 트랜잭션들을 찾는 이전의 예뿐만 아니라, 프론트 엔드들 및 비즈니스 트랜잭션들에 대한 필터를 충족시키는 트랜잭션 인스턴스들을 찾을 수 있다. 달리 말하면, 첫 번째 서브시스템이 인증서비스였던 로그인의 비즈니스 트랜잭션들 모두를 찾을 수 있다. 이러한 경우에, 로그인 인스턴스들이 리턴되지만, 인증서비스를 사용하여 인증을 요구하는 다른 비즈니스 트랜잭션들로부터의 독립 쓰레드(standalone thread)들은 리턴되지 않는다. 예를 들어, 인증서비스를 또한 콜할 수 있는 옵션 트레이딩의 트랜잭션들은 리턴되지 않는다. 보조 영역(562)은 지금까지 3개의 트랜잭션들이 매칭되었음을 표시하고, 그리고 이들이 1150 ms, 1250 ms, 및 1550 ms의 응답 시간을 가지며 에이전트A 및 에이전트B로부터 온 것임을 표시한다.

앞서의 예는 세 개 혹은 그 이상의 비즈니스 트랜잭션들이 서브시스템을 호출할 수 있는 경우에 확장될 수 있다. 예를 들어, 사용자는 필터 기준으로서 첫 번째와 두 번째 비즈니스 트랜잭션들을 선택할 수 있지만 세 번째는 선택하지 않을 수 있다.

도 5i은 복수의 비즈니스 트랜잭션들의 콘텍스트에서, 인증서비스 서브시스템에 대한 매칭 트랜잭션들을 찾기 위한 사용자 인터페이스를 묘사한다. 도 5h와 대비하여, 사용자 인터페이스(556)는 사용자로 하여금 모든 연관된 비즈니스 트랜잭션들에 걸쳐 인증서비스에 대한 매칭 트랜잭션들의 위치를 결정하도록 할 수 있다. 여기서, 로그인 및 옵션 트레이딩에 대한 아이콘들은 선택되지 않았고, 이에 따라 인증서비스 아이콘(322)이 선택되는 경우 윈도우(567)는 필터 기준이 특정 비즈니스 트랜잭션들을 특정하고 있지 않음을 표시한다. 선택에 따라서는, 도 5g에서와 같이, 비즈니스 트랜잭션 뷰(Business Transaction View)로부터, 사용자는 비즈니스 트랜잭션과 독립된 임의의 선택된 서브시스템에 대한 매칭 트랜잭션을 요청할 수 있다(이것은 만약 비즈니스 서비스가 트리 내에서 선택되었다면 디폴트일 수 있음). 그 다음에 사용자는 트레이스를 실행하기 이전에 도 5i에서와 같이 그 서브시스템에 대한 프론트 엔드 뷰로 점프(jump)될 수 있다.

도 5j는 선택된 비즈니스 트랜잭션 인스턴스에 대해 로그인의 모든 서브시스템들보다 더 적은 수의 서브시스템이 호출되는 사용자 인터페이스(560)를 묘사한다. 지속시간과 같은 메트릭들은 호출되지 않은 서브시스템들에 대해서는 제공되지 않을 수 있다. 비즈니스 트랜잭션의 특정 인스턴스가 단지 그 집결된 비즈니스 트랜잭션에서 호출된 서브시스템들의 서브세트만을 호출하는 시나리오는, 예를 들어, 발생된 에러에 의해 혹은 흐름에 영향을 미치는 트랜잭션의 어떤 파라미터로 인해 일어날 수 있다. 더욱이, 에러 시나리오에서, 보조 영역(562)에서의 트랜잭션 목록은, 예를 들어, 에러가 포함된 트랜잭션들을 서로 다른 폰트(font) 혹은 컬러로 식별할 수 있다. 흐름에 영향을 미치는 비즈니스 트랜잭션의 파라미터의 예는, 예를 들어, 사용자Id에서의 틀린 문자가 UI로 하여금 인증엔진이 호출되기 전에 에러를 리턴하도록 하는 경우에 발생한다.

도 5k는 도 5e의 UI의 콘텍스트 메뉴(532)로부터 개시된 로그인을 위한 위치들을 갖는 사용자 인터페이스(570)를 묘사한다. UI는 로그인 인스턴스들이 호출되는 위치들을 보여주는바, 즉 에이전트들 및 컴퓨팅 디바이스들(컴퓨팅 머신들)이 특정 시기에 로그인의 하나 또는 그 이상의 인스턴스들을 보고한 위치들을 보여준다. 콘텍스트 메뉴(532) 내의 "로그인을 위한 위치 보기(Show Locations for Login)"를 선택함으로써 행해진 이러한 선택에 응답하여, 보조 영역(562)이 제공된다. 콘텍스트 메뉴(532)는 사용자가 보조 영역(562)에 링크(link)될 수 있게 한다. 이러한 위치들은, 로그인의 소프트웨어가 실행되는 호스트 컴퓨팅 디바이스를 나열함으로써, 뿐만 아니라 소프트웨어의 인스트루멘테이션으로부터 메트릭들을 획득하는 연관된 에이전트를 나열함으로써, 식별될 수 있다. 현재 시간 구간에 대한 메트릭들(예를 들어, 응답 시간(Response Time, R/T)(총 시간), 로그인의 동시실행 호출의 수, 에러의 수, 응답의 수, 및 스톨의 수)이 또한 제공될 수 있다. 에이전트 및 호스트 위치들이 메트릭들에 인덱스(index)된다.

이러한 예에서, 두 개의 에이전트/컴퓨팅 디바이스가 로그인을 위한 위치를 보고했고, 각각은 로그인의 두 개의 인스턴스들을 보고한다. 구체적으로, 호스트A에서의 에이전트A가 두 개의 로그인 트랜잭션 인스턴스들을 검출하고, 평균 응답 시간 혹은 지속시간은 1150 ms이다(예를 들어, 1100 ms의 일 인스턴스와 1200 ms의 또 다른 인스턴스의 평균치). 호스트B에서의 에이전트B가 두 개의 다른 로그인 트랜잭션 인스턴스들을 검출하고, 평균 응답 시간 혹은 지속시간은 1450 ms이다(예를 들어, 일 인스턴스에 대한 1400 ms와 또 다른 인스턴스에 대한 1500 ms의 평균치). 선택에 따라서는, 보조 영역(562)은 각각의 에이전트/호스트에 대한 인스턴스들을 집결시키는 대신 로그인의 각각의 인스턴스에 대한 엔트리를 디스플레이할 수 있다. 호스트는 텍스트 명칭(text name)에 의해, 혹은 인터넷 프로토콜(Internet Protocol, IP) 어드레스 또는 다른 네트워크 어드레스에 의해 식별될 수 있다. 이러한 호스트들 양쪽 모두는 로그인 트랜잭션의 트리거 요청을 레코딩한 컴퓨팅 디바이스들을 나타내며, 따라서 양쪽 모두는 인증서비스와 연관된다. 그러나, 이러한 수들은 비즈니스 트랜잭션을 정의하는 특정 비즈니스 트랜잭션 컴포넌트에 대한 메트릭들을 나타내는바, 이는 인증서비스 프론트 엔드에 대해 측정된 전체 활동의 서브세트이다.

로그인을 구현하기 위한 소프트웨어가 단지 하나의 컴퓨팅 디바이스 상에만 설치될 수 있다. 또는, 로그인을 구현하기 위한 소프트웨어가 복수의 컴퓨팅 디바이스들 상에 설치될 수 있지만, 이들 중 단지 하나만이 정보가 보고되는 특정 시기에 로그인을 호출하게 된다. 이러한 정보는 보조 영역(562)에서 드러난다. 보고된 메트릭들은, 일 실시예에서, UI를 제공하는 중앙 관리자에게 에이전트에 의해 제공될 수 있다.

도 5l는 도 5e의 UI의 콘텍스트 메뉴(532)로부터 개시된 로그인의 건강도 메트릭들의 사용자 인터페이스(580)를 묘사한다. 영역(504)에서, 트리는 건강도 메트릭들이 이용가능한 컴포넌트들을 식별하기 위해 확장된다. 여기서 비즈니스 트랜잭션들 및 다른 서브시스템들에 대해 도시된 메트릭 그래프들은 모든 에이전트들 상에서의 모든 트랜잭션 인스턴스들에 걸쳐 요약된 것이다. 일 방법에서, 트리는 각각의 비즈니스 트랜잭션에 대해 단일의 자식 버텍스를 가질 수 있다. 각각의 이러한 자식 버텍스는, 그 연관된 비즈니스 트랜잭션 컴포넌트(Business Transaction Component, BTC)(이것은 일 실시예에서 인스트루멘테이션에 의해 실제로 측정된 유일한 컴포넌트임)에 대해 명명될 수 있다. 트리에서 BTC를 선택함으로써 그 묘사된 그래프들이 산출된다.

건강도 메트릭들은, 평균 응답 시간, 구간별 응답, 동시실행 호출들, 구간별 에러, 및 스톨 카운트와 같은 메트릭들을 제공하는, 그래프, 테이블, 혹은 다른 시각적 표현을 포함할 수 있다. UI(550)는, 예를 들어, 새로운 윈도우로서, 혹은 UI(530) 위의 팝업 윈도우로서, 혹은 별개의 디스플레이 스크린 상에 개시될 수 있다.

트리의 버텍스들은 각각의 옵션을 보기 위해 확장될 수 있거나 옵션들을 감추기 위해 접힐 수 있다. "비즈니스 서비스별(By Business Service)" 및 "프론트 엔드별(By Front end)"은 맵 트리의 서로 다른 부분들(서로 다른 서브트리들)이고, 애플리케이션들을 통해 트랜잭션들을 그룹화하고 맵핑하는데 사용되는 서로 다른 오브젝트(object)들(비즈니스 트랜잭션들 및 프론트 엔드들)을 나타낸다. 즉, 트랜잭션은, 특정 비즈니스 트랜잭션에 매칭되는 것으로서 분류될 수 있거나, 또는 그것의 프론트 엔드로서 특정 서브시스템을 갖는 것으로 분류될 수 있다(또는 양쪽 모두일 수 있음). 비즈니스 트랜잭션과 그 종속물(즉, 비즈니스 트랜잭션에 매칭되는 트랜잭션들에 의해 호출되는 모든 서브시스템들)이 맵핑될 수 있거나, 또는 프론트 엔드와 그 종속물(즉, 그 프론트 엔드에서 발신되는 트랜잭션들에 의해 호출되는 모든 서브시스템들)이 맵핑될 수 있다.

트리 영역(504)에서 "비즈니스 서비스별(By Business Service)" 혹은 "프론트 엔드별(By Front end)"을 선택함으로써, 첫 번째 경우에는 특정 비즈니스 서비스 또는 비즈니스 트랜잭션을 찾기 위한 검색 유틸리티(search utility)가 제공되고, 혹은 두 번째 경우에는 프론트 엔드 또는 백 엔드 콜을 찾기 위한 검색 유틸리티가 제공된다. 트리에서 비즈니스 서브시스템 혹은 비즈니스 트랜잭션을 선택함으로써, 애플리케이션 분류 맵(Application Triage Map)(즉, 비즈니스 서비스에서의 모든 비즈니스 트랜잭션들의 유향 그래프(이 경우, 만약 비즈니스 트랜잭션이 선택되는 경우 이들 중 하나는 강조됨))의 "비즈니스 뷰(Business View)"가 산출된다. 트리에서 프론트 엔드를 선택함으로써, 애플리케이션 유향 그래프(즉, 프론트 엔드 및 그 종속물의 유향 그래프)의 "프론트 엔드 뷰(Front end View)"가 산출된다. 비즈니스 트랜잭션 레벨 혹은 프론트 엔드 레벨 아래에 있는 어떤 것을 선택함으로써, 그 선택된 아이템 혹은 그 자식 버텍스들에 대한 메트릭 정보가 산출된다.

비즈니스 트랜잭션(실제로는, 비즈니스 트랜잭션 컴포넌트)에 대한 혹은 프론트 엔드의 전체 건강도 및 그 다양한 백 엔드 콜들에 대한 성능 메트릭들이 수집될 수 있다. 트리 내의 비즈니스 서비스 버텍스는 그 연관된 비즈니스 트랜잭션들을 그룹화(및 이들 모두를 함께 맵핑)하기 위한 폴더(folder)이고, 비즈니스 트랜잭션 버텍스들을 통해 비즈니스 트랜잭션 맵들을 볼 수 있으며, 프론트 엔드 버텍스들을 통해 프론트 엔드 맵들을 볼 수 있고, 다른 노드들 모두를 통해 관련 성능 데이터를 볼 수 있다.

따라서, 트리 영역(504) 내의 요소 "비즈니스 서비스별(By Business Service)"은, 사용자가 데이터를, 예를 들어, 비즈니스 서비스 및 비즈니스 트랜잭션의 계층적 정렬(hierarchical arrangement) 관점에서 볼 수 있게 한다.

트리 영역(504) 내의 요소 "프론트 엔드별(By Front End)"은, 사용자가 데이터를 프론트 엔드 서브시스템 관점에서 볼 수 있게 한다. 이것은 다른 방식으로 "비즈니스 서비스별" 뷰와 동일한 데이터를 보는 것이다. 예를 들어, 트리의 버텍스들은 서로 다른 앞서 설명된 서브시스템들을 포함할 수 있다. 보고 서비스에 대한 버텍스는 건강도 메트릭들이 액세스될 수 있음을 표시하기 위해 확장된다. 이 버텍스는 평균 응답 시간, 동시실행 호출들, 구간별 에러, 구간별 응답, 및 스톨 카운트와 같은 서브 버텍스들을 제공하기 위해 확장될 수 있다. "백 엔드 콜(Back end calls)" 버텍스는 웹 서비스 및 그 성능 메트릭들에 대한 서브-버텍스들들을 보여주기 위해 확장되었다. 언급된 바와 같이, 원들은 경보 레벨을 식별한다(정상 레벨에 대해서는 백색이고, 위험 레벨에 대해서는 흑색). 이것은 사용자로 하여금 문제를 빨리 진단할 수 있게 한다.

특히, 트리 내에서 경보 레벨이 "위험 레벨에 가까워(bubble up)"지는 경우, 부모 버텍스들은 그들의 자식 버텍스들 중 어느 하나의 최악의 경보 상태를 보여준다. 따라서, 만약 보고서비스의 웹 서비스 백 엔드 콜이 위험 레벨 경보를 갖는다면, 그 위에 있는 "백 엔드 콜" 버텍스도 또한 위험 레벨 경보를 가지며, 이에 따라 보고서비스 버텍스 자체도 그렇게 된다. ("건강도(Health)" 버텍스는 프론트 엔드 자체의 건강도 나타내고, 그 위에 있는 버텍스는 해당 애플리케이션에 대한 아이템들의 전체 세트(프론트 엔드들 및 백 엔드 콜들)를 나타낸다.) 실제 경보 임계치들은, 프론트 엔드 "건강도", 백 엔드 콜들, 및 비즈니스 트랜잭션 컴포넌트들과 연관된 개별 메트릭들에 대해 정의될 수 있다. 나머지는 이러한 것들에 근거하는 요약 경보(summary alerts)일 수 있다(최악의 경우, "위험 레벨에 가까워짐(bubble up)" 경보).

도 5m는, 사용자가 노드(322)를 선택하고 보조 영역(562)으로부터 "세부사항(Details)" 탭을 선택한 이후, 도 5k의 사용자 인터페이스를 묘사한다. UI(590)에서, 그 선택된 서브시스템(322)(인증서비스)에 관한 세부사항들이 제공된다. 비즈니스 트랜잭션의 경로를 묘사하기 위해 서브시스템이 강조되는 경우(예를 들어, 단일의 실선 경계)와는 반대로, 사용자가 서브시스템을 선택할 때 상이한 타입의 강조(예를 들어, 이중 실선 경계)가 사용됨에 유의해야 한다.

예를 들어, 영역(562)은 로그인의 일부로서 서브시스템에서 호출되는 컴포넌트의 각각의 인스턴스를 식별할 수 있다. 간단한 예로서, 각각의 컴포넌트의 단지 하나의 인스턴스만이 묘사된다. 실제로, 각각의 컴포넌트의 복수의 인스턴스들이 묘사될 수 있다. 예를 들어, CM1 CM2, CM4a, CM4b 및 CM5의 응답 시간(총 지속시간)은 각각, 1300 ms, 1150 ms, 800 ms, 200 ms 및 50 ms이다. CM이 클래스-메소드 쌍(Class-Method pair)을 표시함에 유의해야 한다. 더욱이, 호스트A 상의 에이전트A가 각각의 컴포넌트와 연관되고, 그리고 각각의 컴포넌트의 실행 시작 시간이 표시된다. 순 지속시간이 또한, 추가적으로 혹은 대안적으로 제공될 수 있다. 세부사항 탭이 이제 활성화 및 선택되고, 이것은 유향 그래프 내의 인증서비스 버텍스(322)와 연관된 트랜잭션 트레이스로부터의 메소드 콜들을 나열한다.

선택에 따라서는, 주 서브시스템 버텍스(subject subsystem vertex)만이 사용자에 의해 선택되는 경우, 종 서브시스템(dependent subsystem)을 콜하는 주 서브시스템의 컴포넌트들은 보조 영역(562)에 제공되지 않는다. 예를 들어, 서브시스템 버텍스(322)만이 선택된 경우, CM1 CM2, CM4a 및 CM5는 보조 영역(562)에 나열될 수 있지만 CM4a는 그렇지 않은바, 그 이유는 이것이 서브시스템(328) 내의 CM7을 콜하기 때문이다. 이러한 방법에서, 사용자가 단지 에지(513)만을 선택한 경우, 종 서브시스템(예를 들어, CM4a)에 대한 콜 컴포넌트(calling component)들은 보조 영역 내에 저절로 나열될 수 있다. 그 다음에 만약 사용자가 또한 버텍스(322)를 선택한다면, 추가적 컴포넌트들(CM1 CM2, CM4a 및 CM5)이 나열될 수 있다. 이것은 사용자로 하여금 더 큰 입도(granularity)로 유향 그래프를 탐색할 수 있게 한다.

서브시스템에 의해 호출되고 또 다른 서브시스템을 콜하는 컴포넌트들(콜 컴포넌트들)은 또한, 서브시스템에 의해 호출되지만 또 다른 서브시스템을 콜하지 않는 컴포넌트들과는, 보조 디스플레이 영역(562) 내에서 (예를 들어, 컬러(color), 폰트(font), 아이콘(icon), 노트(note), 등에 의해) 시각적으로 구분될 수 있다. 예를 들어, 콜 컴포넌트(CM4a)는 도 5i에서 이탤릭체로 구분된다.

사용자는 "트랜잭션-맵핑 모드(transaction-mapping mode)"를 빠져나와 맵을 표준 외관(standard appearance) 및 작동으로 리턴시키기 위해 탭들 중 어느 하나로부터 닫기 버튼을 선택할 수 있다.

또 다른 옵션에서, "트랜잭션 목록" 탭, "세부사항" 탭, 및 "트레이스 보기" 탭 중 하나 또는 그 이상의 탭들 하의 정보가, 탭 뷰(tabbed views)를 사용하는 대신 사용자 인터페이스에서 동시에 제공될 수 있다.

도 5n는 도 5g의 사용자 인터페이스로부터 개시될 수 있는 임의의 선택된 트랜잭션 인스턴스에 대한 트랜잭션 트레이스들을 묘사한다. 예를 들어, 사용자는 도 5g에서 보조 영역(562)의 "트랜잭션 목록" 탭으로부터 트랜잭션 인스턴스들 중 하나를 선택할 수 있고, 그 다음에 "트레이스 보기" 탭을 선택할 수 있다. 트레이스 보기는 선택된 트랜잭션 인스턴스에 대한 하나 또는 그 이상의 트랜잭션 트레이스들을 제공한다. 이러한 예에서는, 도 4b1 및 도 4b2의 트랜잭션 트레이스들이 반복되며, 이들은 상세히 설명되었고, 그리고 도 5g에서의 트랜잭션들을 나타낸다.

UI(610)의 보조 영역(562)에서, 트랜잭션 트레이스(641)는 인증서비스와 연관된 에이전트로부터의 컴포넌트 데이터에 근거하여 제공되며, 트랜잭션 트레이스(651)는 인증엔진과 연관된 에이전트로부터의 컴포넌트 데이터에 근거하여 제공된다. 트랜잭션 트레이스(641)는 CM1, CM2, CM4a, CM4b 및 CM5를 각각 나타내는 그래프 부분들(642, 643, 639, 644 및 645)을 포함한다. 트랜잭션 트레이스(651)는 CM7, CM8, CM9 및 CM10을 각각 나타내는 그래프 부분들(646, 647, 648 및 649)을 포함한다.

사용자는, 유향 그래프 영역(502)과 트랜잭션 트레이스들을, 하나 또는 그 이상의 스크린들 상의 동일 UI 내에서 동시에 볼 수 있고, 이 둘 간의 상관관계를 탐색할 수 있다. 사용자는 (예를 들어, 포인팅 디바이스를 사용하여) 트랜잭션 트레이스를 전체적으로 선택하거나 혹은 그 그래프 영역들(639 및 642-649)을 선택하여, 하나 또는 그 이상의 대응하는 버텍스들이 유향 그래프 영역(502) 내에서 시각적으로 구분될 수 있도록 할 수 있다.

사용자가 첫 번째 트랜잭션 트레이스(641)를 선택하는 경우, 버텍스(322)는 버텍스(328) 및 다른 버텍스들과 시각적으로 구분된다. 그리고, 사용자가 두 번째 트랜잭션 트레이스(651)를 선택하는 경우, 버텍스(328)는 버텍스(322) 및 다른 버텍스들과 시각적으로 구분된다. 또 다른 가능한 방법에서, 사용자가 첫 번째 트랜잭션 트레이스(641)를 선택하는 경우, 버텍스(322) 및 모든 종속 버텍스들(328, 336) 그리고 연관된 에지들(513, 613)이 다른 버텍스들 및 에지들과 시각적으로 구분된다. 그리고, 사용자가 두 번째 트랜잭션 트레이스(651)를 선택하는 경우, 버텍스(328) 및 모든 종속 버텍스들(336) 그리고 연관된 에지들(613)이 다른 버텍스들 및 에지들과 시각적으로 구분된다.

도 6a는 적어도 하나의 애플리케이션을 통하는 흐름을 추적(tracking)하는 모델을 도시한다. 여기에 표시된 사용자 인터페이스 디스플레이를 제공하기 위하여 모델 또는 스키마가 사용될 수 있다. 모델은 두개의 부분들, 즉 행동적 부분 및 구조적 부분을 포함할 수 있다. 행동적 부분은 사용자에 의해 수동적으로 정의되거나 비즈니스 프로세스 실행 언어(BPEL;Business Process Execution Language)와 같은 기존의 행동 설명자(behavioral descriptor)에 대한 이해를 통해 자동적으로 발생되는 방식의 트랜잭션들 또는 어그리게이션들(aggregations)의 세트를 나타낸다. BPEL(또한 웹 서비스 비즈니스 프로세스 실행 언어(WS-BPEL)라 알려져 있음)는 웹 서비스들과 비즈니스 프로세스들 내의 액션들을 규정하기 위한 실행가능한 언어의 OASIS 표준이다. 구조적 부분은 소프트웨어 컴포넌트들을 통한 트랜잭션들의 실제 흐름을 나타낸다.

모델은, 질문들, 예컨대 (a) 만약 특정 구조적 컴포넌트가 적절하게 수행되고 있지 않으면, 어떤 비즈니스 서비스들 또는 트랜잭션이 영향을 받는가? 그리고 (b) 만약 비즈니스 서비스가 실패헐 것으로 보인다면, 어떤 구조적 컴포넌트가 이 비즈니스 서비스 또는 트랜잭션에 영향을 주고 있는가? 와 같은 질문들에 대한 대답을 제공하기 위하여 행동적 부분 및 구조적 부분을 브리지(bridge)한다. 모델의 구조적 부분의 또 다른 중요한 임무는 소프트웨어 컴포넌트들과 하부에 놓인 물리적 인프라스트럭쳐가 추가적으로 상관될 수 있게 하는 것이다. 각각의 박스는 모델의 레코드를 나타내며, 여기서 각각의 레코드는 각각의 박스에 열거된 정보의 필드들을 가진다. 일부 경우들에 있어서, 레코드의 필드들이 또 다른 레코드에 중복적으로 존재(duplicate)할 수 있거나, 또는 필드들을 제공된 예와는 다른 레코드들에 분배함으로써 모델이 수정될 수 있다. 예를 들어, Vertex_type_name 및 Vertex_type_ID는 버텍스 레코드로부터 별도의 버텍스 타입 레코드로 이동될 수 있고(도시되지 않음), Vertex_owner_ID 및 Vertex_owner_name는 버텍스 레코드로부터 버텍스 소유자 레코드로 이동될 수 있다(도시되지 않음). 많은 다른 변형들이 가능하다.

모델의 구조적 부분은 파선의 우측 하부에 있고, 에지, 버텍스, 에이전트, 메트릭 경로 및 에지 소유지의 레코드들을 포함한다. 모델의 행동적 부분은 파선의 좌측 상부에 있고, 트랜잭션, 비즈니스 트랜잭션 및 비즈니스 서비스의 레코드들을 포함한다. 버텍스는 에이전트와 다-대-일(many-to-one) 관계를 가지며, 이는 복수의 버텍스 레코드들이 하나의 에이전트 레코드와 관련될 수 있음을 의미한다. 메트릭 경로는 버택스와 다-대-일 관계를 가지며, 이는 복수의 메트릭 경로 레코드들이 하나의 버텍스 레코드와 관련될 수 있음을 의미한다. 에지는 에지 소유자와 다-대-일 관계를 가지며, 이는 복수의 에지 레코드들이 하나의 에지 소유자 레코드와 관련될 수 있음을 의미한다. 에지는 버텍스와 일-대-일 관계를 가지며, 이는, 일 기법에서, 에지 레코드가 단지 하나의 버텍스 레코드와 관련됨을 의미한다.

"순서화됨(ordered)" 박스(600)는 에지들의 순서화된 세트(에지 레코드들)이 트랜잭션 레코드와 관련될 수 있음을 나타낸다. 이는 에지들의 세트가 트랜잭션을 나타내는 것으로 고려되도록 특정-순서(specified order)로 발생해야 함을 의미한다. "순서화됨"으로 표시된 다른 박스(602)는 트랜잭션 레코드 내의 필드들의 순서가 적절(relevant)할 수 있음을 나타낸다. 예를 들어, 비즈니스 트랜잭션이 트랜잭션들의 순서화된 세트에 의해 표시될 수 있고, 비즈니스 서비스가 비즈니스 트랜잭션들의 순서화된 세트에 의해 표시될 수 있다. 트랜잭션은 비즈니스 트랜잭션과 일-대-일 관계를 가지며, 일 기법에서, 이는 트랜잭션 레코드가 단지 하나의 비즈니스 트랜잭션 레코드와 관련될 수 있음을 의미한다. 비즈니스 트랜잭션은 비즈니스 서비스와 다-대-일 관계를 가지며, 이는 복수의 비즈니스 트랜잭션 레코드들이 일 비즈니스 서비스 레코드와 관련될 수 있음을 의미한다. 이것의 예는 트레이딩과 관련되어 있는 도 5b의 주문, 옵션 트레이딩, 로그인, 밸런스 및 어카운트 요약이다. 레코드들을 연결하는 다-대-일 표시에서, 원 아이콘은 순서배치(ordering)가 중요함을 나타낸다.

일반적으로, 트랜잭션은 애플리케이션/서비스의 하나 이상의 컴포넌트들을 호출하는 고유의 흐름을 표시할 수 있다. 이 컴포넌트들은 클래스, 클레스-메소드 쌍, 프로세스 및 JVM과 같은 인스트루먼트화된(instrumented) 소프트웨어 컴포넌트를 포함할 수 있다. 트랜잭션은 에지들의 순서화된 세트에 의해 정의될 수 있으며, 여기서 에지들은 일련의 컴포넌트들 내의 콜들을 나타낸다. 또한, 트랜잭션은 다른 트랜잭션들을 포함할 수 있다. 이 트랜잭션들의 리스트가 또한 순서화될 수 있다. 일 기법에서, 트랜잭션이 비즈니스 계층의 최하 레벨에 있고, 비즈니스 트랜잭션이 제1의 상위 레벨(first higher level)에, 비즈니스 서비스가 제2의 상위 레벨(second higher level)에 있다. 이 계층의 예는 3개의 레벨들을 포함하지만, 단지 두개 또는 그 이상의 레벨들이 제공될 필요가 있다. 비즈니스 트랜잭션은 잘-정의된 비즈니스 기능을 나타낼 수 있으며 하나 이상의 트랜잭션들을 포함할 수 있다. 비즈니스 서비스는 경제적으로 비즈니스에 의미있으며 분명하게 관리되는 잘-정의된 애플리케이션/서비스, 또는 애플리케이션들/서비스들의 세트를 나타낼 수 있다. 또한, 하나 이상의 비즈니스 서비스들의 순서화된(ordered) 또는 순서화되지 않은(unordered) 집합(collection)을 포함하는 비즈니스 프로세스가 정의될 수 있다.

모델은 UI를 제공하기 위하여 사용될 수 있다. 도 5a의 예시적인 UI에서, 예를 들어, 버텍스 레코드가 버텍스들 (310, 312, 304, 306, 308, 340, 342, 344, 320, 350, 322, 360, 362, 324, 321, 341, 343, 345, 347, 349, 351, 349, 351, 327, 326, 334, 332, 329, 328, 336, 331, 330 및 338) 각각에 대해 제공될 수 있다. 에지 레코드는 에지들(Ed1-Ed26) 각각에 대해 제공될 수 있다. 비즈니스 서비스 레코드는 트레이딩에 대해 제공될 수 있고, 비즈니스 트랜잭션 레코드는, 주문, 옵션 트레이딩, 로그인, 밸런스 및 어카운트 요약 각각에 대해 제공될 수 있다. 마찬가지로, 도 5b의 예시적인 UI에서, 버텍스 레코드가 버텍스들(10, 312, 304, 306, 308, 320, 322, 324, 321, 510, 515, 512, 326, 334, 332, 328, 336, 330 및 338) 각각에 대해 제공될 수 있다. 에지 레코드는 에지들 Es1-Es18 각각에 대해 제공될 수 있다. 언급된 바와 같이, 상세보기의 에지 레코드들은 요약보기의 에지 레코드들에 대해 크로스 참조될 수 있다.

또한, 유향 그래프 내의 버텍스는 동일한 버텍스 레코드의 복수의 인스턴스들을 나타낼 수 있다. 예를 들어, 도 5b에서, 트레이드서비스 버텍스(320)는 하나 이상의 호스트 머신들에서 구동되는 애플리케이션 트레이드서비스의 배치들(deployments) 또는 복수의 인스턴스들을 나타낼 수 있다. 마찬가지로, 유향 그래프의 에지는 동일한 에지 레코드의 복수의 인스턴스들을 나타낼 수 있다 . 예를 들어, 도 5b에서, 에지 Es7는 버텍스(321)에 의해 표현되는 백엔드를 콜하는 애플리케이션 트레이드서비스의 복수의 인스턴스들을 나타낼 수 있다. 이 레코드들의 어그리게이션을 달성하기 위하여, "논리적" 추상화 레벨을 가지는 버텍스 레코드가 "물리적" 추상화 레벨을 가지는 하나 이상의 버텍스 레코드들에 대해 제공될 수 있다. 논리적 버텍스 레코드는 복수의 인스턴스들을 위한 레코드들의 어그리게이션을 나타내는 공통 레코드이다. UI는 이 버텍스 레코드를 사용하여 생성될 수 있다.

예를 들어, 트레이드서비스의 제1 인스턴스가 첫번째로 호출(invoke)될 때(예를 들어, 제1 호스트 머신 상에서 구동되는 트레이드서비스의 애플리케이션의 인스턴스가 비즈니스 트랜잭션에서 첫번째로 콜될 때), 트레이드서비스에 대한 제1 버텍스가 "물리적" 추상화 레벨을 가지고 생성된다.

트레이드서비스의 제1 인스턴스가 두번째로 호출될 때(예를 들어, 제1 호스트 머신 상에서 구동되는 트레이드서비스의 애플리케이션의 제1 인스턴스가 비즈니스 트랜잭션에서 두번째로 콜될 때), 애플리케이션 인스턴스가 이미 알려져 있으므로(noted), 어떠한 새로운 버텍스 레코드도 생성되지 않는다. 트레이드서비스의 제2 인스턴스가 첫번째로 호출될 때(예를 들어, 제1 머신 상에서 또는 또 다른 호스트 머신 상에서 구동되는 트레이드서비스의 애플리케이션의 또다른 인스턴스 또는 배치가 비즈니스 트랜잭션에서 첫번째로 콜될 때), 트레이드서비스를 위한 제2 버텍스 레코드가 "물리적" 추상화 레벨을 가지고 생성되며 선택적으로(optionally) 기 존재하는(pre-existing) 트레이드서비스용 버텍스 레코드 에 링크된다. 레코드들은, 예를 들어, 데이터베이스들내에서 데이터를 조직화하는데 사용되는 기법들을 사용하여, 링크될 수 있다.

따라서, 일 기법에서, "물리적" 레코드가 애플리케이션의 각각의 인스턴스에 대해 또는 다른 컴포넌트에 대해 생성될 수 있으며, 한편, 하나의 공통 또는 "논리적" 레코드가 복수의 "물리적" 레코드들에 링크되어 컴포넌트의 복수의 인스턴스들의 어그리게이션을 나타낼 수 있다. 일 기법에서, 컴포넌트의 동일한 인스턴스의 복수의 호출들(invocations)은 추가적인 "물리적' 버텍스 레코드들을 야기하지 않으며- 단지 컴포넌트의 인스턴스의 제1 호출이 결과적으로 "물리적" 버텍스 레코드를 생성한다. 추가적인 세부사항에 대해서는 도 8a 및 8b를 참조하기로 한다. 일 기법에서, 컴포넌트의 서로 다른 인스턴스들은 이 컴포넌트의 서로 다른 배치들(예를 들어, 서로 다른 호스트 머신들 상에 있음)을 나타낼 수 있고, 각각은 각각의 에이전트와 관련된다.

모델의 각각의 레코드의 세부사항은 다음에 논의된다.

도 6b는 도 6a의 모델에 따른 예시적인 버텍스 레코드를 도시한다. 버텍스 레코드는 모델의 구조적 부분의 중앙 엔티티(central entity)이며 특정 오퍼레이션을 수행할 책임이 있는 소프트웨어 컴포넌트를 나타낼 수 있다. 클래스가 메소드의 부모인 클래스-메소드 쌍에서와 같이, 소프트웨어 컴포넌트는 또 다른 소프트웨어 컴포넌트와 부모-자식 관계(필드 Parent_ID로 표시됨) 를 가질 수 있다. 버텍스 레코드는 유향 그래프 내의 버텍스에 의해 나타낼 수 있다. 여기에서의 레코드 설명은 필드 이름, 필드 설명, 그리고 필드의 타입을 식별한다. Varchar 또는 Variable Character 필드는 규정되지 않은 길이의 캐릭터 데이터의 세트이다. 이것은 데이터베이스 관리 시스템 내의 열 또는 필드의 데이터 타입을 지칭한다. Char 는 고정 길이의 캐릭터 데이터의 세트이다. Integer는 정수이다. 버텍스의 필드들은, Vertex_Name, Vertex_ID, Parent_ID, Abstraction_Level, Hierarchy_Level, Agent_ID, Vertex_Properties, Context_URL, Vertex_Type_Name, Vertex_Type_ID, Vertex_Owner_ID, Creation_Date, Update_Date 및 User_Name을 포함할 수 있다. 각각의 버텍스 레코드는 고유 식별자(Vertex_ID)를 가질 수 있다.

Vertex_Properties와 관련하여, 예를 들어, 특정 버텍스의 특별한 디스플레이를 위하여, 이름-값 쌍들의 리스크가 사용될 수 있다. 이 특성들은 통합된 서비스 모델(USM)의 물리적 부분들과 상관하기 위하여 사용될 수 있다. 예를 들어, JDBC 연결 스트링의 컴포넌트들이 이름-값 쌍들의 리스트 내에 있을 수 있다. Vertex_Type_Name의 예는 EJB, Database, DatabaseSocket, Socket, WebService, 메시지 송신용 서버(예를 들어, JAVA(TM) MESSAGE SERVER 또는 JMS), External 및 EJB 클라이언트를 포함한다. 각각의 버텍스는 버텍스 타입을 가질 수 있다.

Hierarchy_Level과 관련하여, 버텍스 정보가 에이전트에 의해 수집된다. 일반적으로, 에이전트는 클래스의 메소드에 대한 정보를 수집할 수 있다. 예를 들어, 클래스 Class1의 메소드 method1이 트랜잭션 Tran1에 참여한다고 가정하기로 한다. 클래스 Class1의 또 다른 메소드 method2 또한 트랜잭션 Tran1에 참여한다. 에이전트에의해 송신된 정보는 하나 이상의 버텍스 레코드들을 위한 정보를 포함할 것이다. 예를 들어, Hierarchy_Level이 클래스-메소드로 설정되면, 에이전트는 Class1.method1와 Class1.method2로 명명된 두개의 버텍스들을 송신할 것이다. 두개의 메소드들이 모두 동일한 클래스에 속하므로, 이것들은 또한 동일한 버텍스 타입에 속할 것이다. 이는 이 버텍스들 둘 모두가 동일한 논리적 버텍스(버킷(bucket)에 놓일 것임을 의미한다. 이제, Hierarchy_Level이 클래스로 설정되면, 에이전트는 Class1으로 명명된 하나의 버텍스만을 송신할 것이다. 이는 여전히 동일한 논리적 버텍스 (버킷)로 갈것이나, 에이전트와 서버 사이의 네트워크 트래픽을 감소시킬 것이다. 모든 버텍스들이 클래스 또는 클래스-메소드와 관련되어야 하는 것은 아니다. 예를 들어, 버텍스 정보는 서버 컨테이너 또는 JVM과 관련될 수 있다. 버텍스 Class1.method1 또는 Class1이, Hierarchy_Level=process 상태에서, 애플리케이션 서버 Server1로부터 송신된다고 가정하기로 한다. 버텍스 Server1 은 버텍스 Class1.method1 또는 Class1의 부모일 수 있다. 따라서, Hierarchy_Level은 에이전트에 의해 관리자(manager)로 설정되는 정보의 타입 및 입도(granularity)를 식별한다.

도 6c는 도 6a의 모델에 따른 예시적인 에지 레코드를 도시한다. 트랜잭션 세그먼트(일 버텍스로부터 또 다른 버텍스로의 요청, 그리고 대응하는 응답)를 나타낼 수 있는 에지는 두 버텍스들 사이의 관계를 제공한다. 유향 그래프에서, 에지는 두 버텍스들 사이의 화살표로 표시된다. 각각의 에지는 Tail_Vertex_ID(에지의 테일에서의 버텍스를 식별함) 및 Head_Vertex_ID(에지의 헤드에서의 버텍스를 식별함)를 가진다. Edge_Properties 필드는 UI 디스플레이에서 사용하기 위한 에지의 특성들을 나타낼 수 있다. 예로서, Head_Owner_ID와 Tail_Owner_ID와 관련하여, 도 5a의 에지 Ed8은 트레이드서비스의 Head_Owner_ID 및 Tail_Owner_ID를 가질 수 있다. 추가의 세부사항들에 대해서는 도 7ca과 7cb를 참조하기로 한다.

도 6d는 도 6a의 모델에 따른 예시적인 에이전트 레코드를 도시한다. 일반적으로, 에이전트가 도 1에 도시된 것과 같은 호스트 머신을 위해 제공되어, 인스트루먼트화된 애플리케이션을 모니터링하고 그리고 관리자에게 보고한다. 에이전트는 컴포넌트의 인스턴스와 관련될 수 있다.

도 6e는 도 6a의 모델에 따른 예시적인 메트릭 경로 레코드를 도시한다. 메트릭 경로는 버텍스 레코드와 관련된 메트릭 이름을 링크하는 내부 레코드이다. 하나의 버텍스 레코드가 복수의 메트릭 경로들을 가질 수 있다. 일반적으로, 메트릭들은 Vertex_ID 또는 다른 식별자에 근거하여 검색된다. 메트릭 경로는 메트릭들이 정의되고 수집되는 방식을 나타내는 스트링일 수 있다. 이 레코드는 발견되는 강성 타입의 오브젝트들(strong types of objects)과 이 메트릭들 사이의 관계를 레코딩하여 모델의 일부로서 사용할 수 있게 한다. 메트릭 겨로의 예는 (a) |MyDomain|MyHost|MyAgent|MyProcess|EJB|MyMetric| 그리고 (b) |SuperDomain|app.company.com|Agent1|Process1|DataAccessEJB|ResponseTime| 이다.

도 6f는 도 6a의 모델에 따른 예시적인 에지 소유자 레코드를 도시한다. 이는 에지의 소유자를 나타낸다. 복수의 에지들이 동일한 Edge_Owner에 의해 소유될 수 있다. 또한, Edge_Owner는 그 소유의 부모 또는 자식 Edge_Owner를 가질 수 있다. 자식 Edge_Owner는 단 하나의 부모 Edge_Owner를 가질 수 있으나, 부모 Edge_Owner는 복수의 자식 Edge_Owner들을 가질 수 있다. Transaction_ID는 모델의 행동적 부분과 모델의 구조적 부분을 링크하는 식별자이며, 트랜잭션 레코드에서의 필드와 동일한 필드이다(도 6a). 이는 에지, 또는 에지들의 세트가 트랜잭션과 관련될 수 있게 하며, 그럼으로써 이 에지, 또는 에지들의 세트가, 트랜잭션이 관련된 비즈니스 트랜잭션과, 그리고 비즈니스 트랜잭션이 관련된 비즈니스 서비스와 관련될 수 있게 한다.

공통 에지 레코드는 동일 에지를 나타내는 서로 다른 에지 레코드들의 어그리게이션을 나타내도록 제공될 수 있다. 이 에지 레코드는 복수의 인스턴스들을 위한 레코드들의 어그리게이션을 나타내는 공통 레코드이다. UI는 이 에지 레코드를 사용하여 생성될 수 있다. 또한, 이 공통 에지 레코드는 공통 버텍스 레코드에 링크될 수 있다.

도 6g는 도 6a의 모델에 따른 예시적인 트랜잭션 레코드를 도시한다. 언급된 바와 같이, 트랜잭션 레코드는 계층의 제1의 상위 레벨(first higher level)에 있는 비즈니스 트랜잭션(트랜잭션은 이 비즈니스 트랜잭션의 일부임)의 이름, 및 상기 제1의 상위 레벨 위의, 계층의 제2의 상위 레벨(second higher level)에 있는 비즈니스 서비스(비즈니스 트랜잭션은 이 비즈니스 서비스의 일부임)의 이름을 포함할 수 있다. 하나 이상의 서로 다른 트랜잭션 레코드들이 동일한 비즈니스 트랜잭션 레코드와 관련될 수 있으며, 하나 이상의 서로 다른 비즈니스 트랜잭션 레코드들이 동일한 비즈니스 서비스 레코드와 관련될 수 있다.

도 6h는 도 6a의 모델에 따른 예시적인 비즈니스 트랜잭션 레코드를 도시한다. 비즈니스 트랜잭션 레코드는 계층의 제2 상위 레벨에 있는 비즈니스 서비스(비즈니스 트랜잭션은 이 비즈니스 서비스의 일부임)의 이름을 포함할 수 있다. 하나 이상의 서로 다른 비즈니스 트랜잭션 레코드들이 동일한 비즈니스 서비스 레코드와 관련될 수 있다.

도 6i는 도 6a의 모델에 따른 예시적인 비즈니스 서비스 레코드를 도시한다.

모델을 사용하여, 에이전트들에 의해 수집된 정보가 조직화되어 UI 상에 디스플레이될 수 있다. 레코드의 필드들의 일부가, 예를 들어, 레코드들의 링크(linking)를 허용하기 위하여 모델 내에서 내부적으로 사용될 수 있으며, 한편 이름 필드들과 같은 다른 필드들은, 예를 들어, 유향 그래프에서 또는 이 유향 그래프와는 분리된 디스플레이에서 에지들 및 버텍스들을 장식(decoration)하기 위하여, UI상에 디스플레이된다. UI는 사용자에게 요구되는 임의의 필드에 액세스하기 위한 커맨드를 제출(submittion)하는 옵션을 제공한다.

도 7aa은 도 5a의 유향 그래프의 상세보기를 위한 예시적인 버텍스 표를 도시한다. 이 표의 각 엔트리는 각각의 서로 다른 버텍스 레코드로부터의 것이다. 모델이 여기에 기술된 표들을 실제로 생성할 필요는 없으나, 레코드들에 의해 저장되는 것을 간결한 방식으로 전하기 위하여 이 표들이 제공된다. 개별 엔트리가 도 5a의 UI의 컴포넌트의 각 인스턴스에 대해 제공된다. Ref.#는 버텍스에 대한 도 5a의 참조 번호를 표시한다. 이 표 및 다른 표에서의 식별자들에 관하여, 실제로는 이 식별자들이 정수일 수 있으나 이 식별자들은 학습 보조기(learning aid)와 같은 서술적 텍스트를 사용한다. 예를 들어, 서술적 텍스트 PlaceOrderID 는 이것이 주문(PlaceOrder) 버텍스 레코드를 위한 식별자임을 의미한다.

엔트리들(1-5)은 External 타입의 비즈니스 트래잭션 버텍스들을 제공한다. 엔트리들(6-9)은 트레이드서비스 및 그것의 자식 컴포넌트들의 제1 인스턴스에 대한 버텍스들을 제공한다. 이 예에서, 트레이드서비스 및 그것의 자식 컴포넌트들의 3개의 인스턴스들 또는 배치들이 존재하며, 이것들은 각각 Agent1a, Agent1b 및 Agent1c와 관련된다. 엔트리들(10-13)은 트레이드서비스 및 그것의 자식 컴포넌트의 제1 추가적인(add.) 인스턴스에 대한 것이고, 엔트리들(14-17)은 트레이드서비스들 및 그것의 자식 컴포넌트들의 제2의 추가적(add.) 인스턴스에 대한 것이다. 추가의 인스턴스들을 위하여 개별 버텍스들은 UI에 전혀 도시되지 않는다. 엔트리들(18 및 19)은 인증 서비스 애플리케이션 및 그것의 자식 컴포넌트에 대한 것이다. 엔트리들(20-22)은 보고 서비스 애플리케이션 및 그것의 자식 컴포넌트들에 대한 것이다.

도 7ab는 도 7aa의 예시적인 버텍스 표가 계속된 것을 도시한다. 엔트리들(23-29)은 포트(3456) 상의 시스템 로컬 호스트에 대한 백엔드 콜 및 웹서비스들에 대한 것이다. 엔트리들(30, 31)은 오더엔진 애플리케이션 및 그것의 자식 컴포넌트에 대한 것이다. 엔트리들(32, 33)은 인증엔진 애플리케이션 및 그것의 자식 컴포넌트에 대한 것이다. 엔트리들(34, 35)은 보고엔진 애플리케이션 및 그것의 자식 컴포넌트에 대한 것이다. 엔트리들(36-39)은 포트(6543) 상의 시스템 로컬 호스트에 대한 백엔드 콜 및 데이터베이스들에 대한 것이다.

도 7aa 및 7ab의 표는 도 5a의 UI를 제공한는데 사용되는 상세 보기에서의 물리적 버텍스 레코드들을 나타내는것으로 고려될 수 있다. 논리적 버텍스 레코드들을 나타내는 대응하는 표는 그것이 도 7aa의 추가의(add.) 엔트리들(10-17) 또는 에이전트 식별자들을 포함하지 않을것이라는 것을 제외하고는 유사할 것이다. 논리적 버텍스 레코드는 에이전트 식별자에 독립적일 수 있다. 또한, 도 5b의 요약 뷰 UI를 제공하기 위하여 사용되는 대응하는 표는, 도 7b에 도시된 것과 같이, 상세 레벨 버텍스들을 생략(omitting) 또는 통합(consolidating)함(예를 들어, 자식 컴포넌트들(340, 342, 344, 350, 360, 362, 327, 329, 331)을 생략하고 웹 서비스 버텍스들을 통합함)으로써 제공될 수 있다. 도 7b는 도 5b의 유향 그래프의 요약 뷰에 대한 예시적인 버텍스 표를 도시한다.

도 7ca은 도 5a의 유향 그래프의 상세 보기를 위한 예시적인 에지 표를 도시한다. 표의 각 엔트리는 각각의 서로 다른 에지 레코드로부터의 것이다. Edge_ID들은 도 5a에 도시된 것과 같이 Ed1-Ed26이다.

Tail_vertex_ID는 에지의 테일이 기인된(originated) 컴포넌트의 식별자이다. 마찬가지로, Head_vertex_ID는 에지의 헤드가 종료되는 컴포넌트의 식별자이다. 이 컴포넌트들은 인스트루먼트화된(instrumented) 또는 인스트루먼트화되지 않은(uninstrumented) 컴포넌트들(예컨대, 인스트루먼트화되지 않은 로컬 호스트 또는 웹 서비스)일 수 있다. 그러나, 일 기법에서, 테일 소유자 또는 헤드 소유자가 인스트루먼트화된 컴포넌트의 소유자가 될 것이 요구된다. 이 기법은 유용한데, 그 이유는 인스트루먼트화되지 않은 컴포넌트의 소유자를 식별하기 위한 정보가 사용가능하지 않을 수 있기 때문이다.

따라서, 에지가 인스트루먼트화된 컴포넌트로부터 기인된 것이라면, Tail_owner_ID는 인스트루먼트화된 컴포넌트의 소유자의 식별자로 설정된다. 만약 에지가 인스트루먼트화되지 않은 컴포넌트(예를 들어, Ed17, Ed18, Ed19, Ed20, Ed21, Ed22)로부터 기인된 것이라면, Tail_owner_ID 는 에지의 헤드가 종료되는 인스트루먼트화된 컴포넌트의 소유자의 식별자로 설정된다 (헤드 및/또는 테일에서 컴포넌트가 인스트루먼트화(instrumented)되는 것으로 가정된다). 따라서, 테일 소유자는 헤드 소유자에 근거하여 설정된다. 마찬가지로, 에지가 인스트루먼트화된 컴포넌트에서 종료되면, Head_owner_ID는 인스트루먼트화된 컴포넌트의 소유자의 식별자로 설정된다. 에지가 인스트루먼트화되지 않은 컴포넌트에서 종료되면(예를 들어, Ed8-Ed16, Ed23-Ed26), Head_owner_ID는 에지의 테일이 기인된 인스트루먼트화된 컴포넌트의 소유자의 식별자로 설정된다. 따라서, 헤드 소유자는 테일 소유자에 근거하여 설정된다.

또한, 부모 컴포넌트가 없을 때, 인스트루먼트화된 컴포넌트의 소유자는, 일-대-일 베이시스에서, 컴포넌트와 관련되는 소유자로서 정의될 수 있다. 그렇지 않다면, 소유자는 컴포넌트의 최고 부모 소유자일 수 있다(예를 들어, 부모, 조부모, 등). 예를 들어, 도 5a의 에지들(Ed1-Ed7) 각각에 대해, 테일 버텍스들이 비즈니스 트랜잭션들(310, 312, 304, 306, 308)을 나타내고 External 타입일 수 있다. 헤드 버텍스들은 서브시스템들 내에서의 자식 컴포넌트들(즉, 서브시스템(320) 내의 자식 컴포넌트들(340, 342, 344), 서브시스템(322) 내의 자식 컴포넌트(350), 서브시스템(324) 내의 자식 컴포넌트들(360, 362))이다. 결과적으로, Ed1-Ed3에 대한 헤드 소유자는 (TradeServiceID의 식별자를 가지는) 트레이드서비스, 자식 컴포넌트들(340, 342, 344)의 부모이다. Ed4 및 Ed5에 대한 헤드 소유자는 (AuthenticationServiceID의 식별자를 가지는) 인증서비스, 자식 컴포넌트(350)의 부모이다. Ed6과 Ed7에 대한 헤드 소유자는 (ReportingServiceID의 식별자를 가지는) 보고서비스, 자식 컴포넌트들(360, 362)의 부모이다.

Ed8-Ed16은 부모 컴포넌트가 테일 소유자인 인스트루먼트화된 컴포넌트들로부터 기인되는 에지들의 예들이다. Ed8-Ed16은 또한 인스트루먼트화되지 않은 컴포넌트들에서 종료되는 에지들의 예들이며, 따라서 헤드 소유자가 테일 소유자와 동일하게 설정된다. Ed17-Ed22는 인스트루먼트화되지 않은 컴포넌트들로부터 기인되거 인스트루먼트화된 컴포넌트들에서 종료되는 에지들의 예들이고, 따라서 테일 소유자가 헤드 소유자와 동일하게 설정된다. Ed17-Ed22는 부모 컴포넌트가 헤드 소유자인 인스트루먼트화된 컴포넌트들에서 종료되는 에지들의 예들이다. Ed23-26은 부모 컴포넌트가 테일 소유자인 인스트루먼트된 컴포넌트들로부터 기인되는 에지들의 예들이다. Ed23-Ed26은 또한 인스트루먼트화되지 않은 컴포넌트들에서 종료되는 에지들의 예들이며, 따라서 헤드 소유자가 테일 소유자와 동일하게 설정된다. 도 5a의 상세 보기에, 자식 컴포넌트들 및 관련된 에지들이 도시되었다.

도 7cb는 도 5b의 유향 그래프의 요약보기를 위한 예시적인 에지 표를 도시한다. 여기서, 각각의 로컬 호스트 및 웹 서비스를 위한 개별 버텍스들 및 자식 컴포넌트들이 없음으로 인하여 에지들의 수가 감소되고 그것들의 정의가 간략화된다.

도 7d는 도 5a의 유향 그래프를 위한 예시적인 에지 소유자 표를 도시한다. 일 기법에서, 그래프는 영역(504)에서의 트레이딩의 비즈니스 서비스의 선택에 근거하므로, 트레이딩이 그래프에서 각 에지의 소유자이다. 트랜잭션들과 관련하여, 논의된 바와 같이, 트랜잭션은 일련의 컴포넌트들 및 이 컴포넌트들 간의 콜들을 나타내는 에지들의 세트(예를 들어, 에지 레코드들)의 호출을 수반할 수 있다. 트랜잭션들은 다양한 방식들로 정의될 수 있다. 예로서, 트랜잭션들은 다음과 같이 도 5b의 에지들과 관련될 수 있다: 트랜잭션1 - Es1, Es7; 트랜잭션2 - Es1, Es8, Es9, Es15; 트랜잭션3 - Es1, Es8, Es10, Es17; 트랜잭션4 - Es2, Es8, Es9, Es16; 트랜잭션5 - Es4, Es11, Es17; 트랜잭션6 - Es5, Es12, Es13, Es17; 트랜잭션7 - Es6, Es12, Es14, Es18.

도 7e는 도 5a의 유향 그래프를 위한 예시적인 트랜잭션 표를 도시한다. 도 7d의 예시적인 트랜잭션들이 제공된다. 추가적으로, 트랜잭션들1-3이 주문과 관련되고, 트랜잭션4가 옵션 트레이딩과, 트랜잭션5가 로그인과 관련되고, 트랜잭션6이 밸런스와, 그리고 트랜잭션7이 어카운트 요약과 관련된다. 추가적으로, URL1-URL7의 콘텍스트 URL들은 트랜잭션들1-7과 각각 관련될 수 있다.

도 7f는 도 5a의 유향 그래프를 위한 예시적인 비즈니스 트랜잭션 표를 도시한다. 도 7e의 비즈니스 트랜잭션들이 이 표에 포함된다.

도 7g는 도 5a의 유향 그래프를 위한 예시적인 비즈니스 서비스 표를 도시한다. 이 예에서, 트레이딩의 일 비즈니스 서비스가 제공된다. 그러나, 다른 비즈니스 서비스들을 제공하는 것 또한 가능하다.

도 8a는 도 5a의 트레이드서비스 애플리케이션의 복수의 인스턴스들을 위한 물리적 버텍스 레코드들의 예를 도시한다. 언급된 바와 같이, 인스트루먼트화된 컴포넌트의 인스턴스에 대한 제1 호출(invocation)이 검출될 때, 그 컴포넌트를 위한 물리적 버텍스 레코드가 생성된다. 이 컴포넌트의 동일한 인스턴스가 후속적으로 호출될 때, 새로운 버텍스 레코드는 생성되지 않는다. 인스트루먼트화된 컴포넌트의 또 다른 인스턴스의 제1 호출이 검출될 때, 이 인스트루먼트화된 컴포넌트의 그 또 다른 인스턴스를 위하여 또 다른 물리적 버텍스 레코드가 생성된다. 이 레코드는 기존에 존재하는 버텍스 레코드에 선택적으로 링크된다.

일 기법에서, 논리적 버텍스 레코드(동일 컴포넌트의 복수의 인스턴스들에 대한 물리적 버텍스 레코드들의 어그리게이션을 나타냄)가 신속하게(on the fly) 생성될 수 있고, 데이터베이스(예를 들어, 표)에는 영구적으로 저장되지 않는다. 어떤 경우든, 그러한 버텍스 레코드들은 모델의 부분이다. 이 경우에, 로컬 버텍스는 Vertex_ID, Creation_Date, Update_Data 및 User_Name 필드들을 가질 필요가 없다.

이 예에서, 컴포넌트는 트레이드서비스의 애플리케이션이다. 각각의 에이전트들, 즉, Agent1, Agent2, Agent3과 관련되는 3개의 컴포넌트 인스턴스들이 존재한다. 예를 들어, 이 에이전트들은 각각의 서버들(106, 110, 114)(도 1) 상에 있을 수 있다. 버텍스 레코드(800)는 Abstraction_Level=logical 로 표시된 것과 같이 논리적 버텍스 레코드이다. 관련된 에이전트는 존재하지 않는다. 예로서, 계층 레벨은 클래스이다. 버텍스 특성들은 각각의 레코드에서 동일할 수 있으며, 일반적으로 표시 "TrdSvcProp"로 표시된다. 예로서, 서블릿의 버텍스 타입은 서블릿ID의 관련된 식별자를 가진다. 버텍스 레코드들의 소유자는 이름 트레이딩 비즈니스 서비스(ID는 TradingBusServ임)를 가진다. 컴포넌트의 3개의 인스턴스들 각각의 제1 호출의 날짜/시간이 상이할 수 있으므로, 생성 날짜/시간이 물리적 버텍스 레코드들 각각에 대해 상이할 수 있음에 주목하여야 한다. 버텍스 레코드들(802, 804, 806)은, Abstraction_Level=physical로 표시된것과 같이, 서버들(108, 112, 116)에서의 트레이드서비스의 인스턴스들에 대한 물리적 레코드들이다. 각각의 물리적 버텍스 레코드는 상이한 식별자 Vertex_ID를 가진다. 각각의 에이전트는 Agent_ID에 의해 식별된다. 이 예에서 트레이드 서비스가 부모를 가지지 않으므로 Parent_ID=null이다. 물리적 버텍스 레코드들(802, 804, 806)은 공통의 논리적 버텍스 레코드(800)에 링크될 수 있다.

도 8b는 도 5a의 TradeOptions|Service 컴포넌트의 인스턴스를 위한 버텍스 레코드의 예, 및 도 8a로부터의 부모 버텍스 레코드(802)를 도시한다. TradeOptions|Service 의 인스턴스는 Agent1과 관련되고, TradeOptions|Service는 Hierarchy_Level에 의한 서블릿으로서 식별된다. 레코드(812)의 Parent_ID 필드는 TradeService를 TradeOptions|Service의 부모 컴포넌트로서 식별한다. 구체적으로, 버텍스 레코드(802)의 식별자 TradeService1ID는 버텍스 레코드(802)의 Parent_ID 필드에 있다. 이러한 모델 양상은 TradeOptions|Service 버텍스(344)가 도 5a의 트레이드서비스 버텍스(320)의 자식 컴포넌트로서 제공될 수 있게 한다. 즉, 자식 컴포넌트들의 버텍스들이, 네스팅된 방식으로, 부모 컴포넌트의 버텍스 내부에 디스플레이될 수 있다.

도 8c는 TradeOptions|Service 컴포넌트가 도 5a의 WebServices1 웹서비스를 콜할 때의 버텍스 레코드들 및 에지 레코드의 예를 도시한다. 이 콜은 도 5a의 버텍스(344), 에지 Ed11 및 버텍스(341)에 의해 표시된다. 또한, 버텍스(344)는 버텍스 레코드(820)에 의해 표시되고, 에지 Ed11는 에지 레코드(822)에 의해 표시되고, 버텍스(341)는 버텍스_레코드(824)에 의해 표시된다. 레코드(820)는 TradeOptions|Service의 버텍스를 식별하고, 한편, 레코드(824)는 WebServices1의 버텍스를 식별한다. 레코드(822)는 Ed11의 헤드 및 테일 버텍스들과 에지의 헤드 및 테일의 소유자(트레이드서비스)를 식별한다. 레코드(824)에서 Agent_ID=null인데, 그 이유는 WebServices1 이 인스트루먼트화된 컴포넌트가 아니며 따라서 에이전트를 가지지 않기 때문이다.

도 9은 사용자 인터페이스를 제공하기 위한 방법을 묘사한다. 언급된 바와 같이, 피관리 애플리케이션이 실행됨에 따라, 관련 컴포넌트 데이터가 애플리케이션의 인스트루멘테이션을 통해 획득된다. 이러한 정보는 에이전트들에 의해 중앙 관리자에게 보고될 수 있다. 관리자에서의 데이터는, 데이터베이스(118)(도 1) 내에 제공될 수 있는바, 예를 들어, 저장 디바이스(210)(도 2c)에서 제공될 수 있다. 데이터는 다양한 데이터 필드들을 포함할 수 있는바, 이러한 데이터 필드들은, 데이터가, 본 명세서에서 설명되는 기능을 달성하기 위해 상이한 방법으로 질의(query) 및 액세스(acess)될 수 있도록 한다.

단계 900에서, 데이터는, 분석하에 있는 특정 시간 구간 동안 액세스될 수 있는바, 이러한 특정 시간 구간은 디폴트 값(예를 들어, 15분)으로 설정될 수 있거나 혹은 사용자에 의해 특정된 대로 설정될 수 있다. 일 방법에서, 이 단계는 이전에 설명된 "더 찾기(Find more)" 커맨드를 포함할 수 있다. 예를 들어, 데이터는 데이터 저장소로부터 액세스될 수 있다. 비록 많은 양의 트랜잭션 트레이스 데이터를 모으고 저장하는 것이 프로세싱 시간 및 저장 공간 면에서 비용이 많이 들 수 있지만, 이력 데이터(과거의 날(days) 혹은 과거의 달(months))가 또한 사용될 수 있다. 또한, 계속 진행되는 트랜잭션 트레이스 샘플링(transaction trace sampling)에 의존하는 것이 가능하다(여기서, 샘플링은 더 높은 빈도로 설정됨).

일반적으로, 세 개의 개별 프로세싱 경로들을 따를 수 있다. 첫 번째 경로에서, 응답 시간 및 지속시간과 같은 성능 메트릭들이 단계 902에서 트랜잭션 트레이스/콜 스택(transaction traces/call stacks)으로부터 계산될 수 있다. 단계 904는, 예를 들어, 성능 메트릭들을 각각의 임계치들과 비교함으로써, 경보 레벨들을 결정한다. 경보들은 서브시스템들에 대한 전체 성능 메트릭들에 근거하여 계산될 수 있다. 트랜잭션 트레이스 지속시간에 대한 임계치에 관해서, 서브시스템의 "평균 응답 시간" 경보들에 대한 임계치들이 재사용될 수 있는바, 즉 이들을 트랜잭션 트레이스들에서 측정된 대응하는 지속시간에 적용할 수 있다. 이러한 임계치들은 단일 트랜잭션에 관해 사용하기에는 너무 민감하고, 결과적으로 많은 황색 경보 및 적색 경보를 일으킨다. 일 방법에서, 성능 메트릭들 및 경보들은 유향 그래프 구조에 직접적으로 의존하지 않고, 이로부터 독립적으로 계산될 수 있다. 성능 메트릭들은 비즈니스 트랜잭션 컴포넌트들의 성능, 프론트 엔드 및 백 엔드 콜들을 전체적으로(즉, 특정 시간 구간 동안, 전형적으로는 매 15초 마다, 관측된 모든 트랜잭션들에 대해) 설명한다. 이러한 데이터는 라이브 모드(live mode) 및 이력 모드(historical mode)로 유향 그래프에서 사용된다.

성능 메트릭들은 평균 응답 시간, 동시실행 호출들, 구간별 에러, 구간별 응답, 및 스톨 카운트를 포함할 수 있다. 더욱이, 특정 트랜잭션 인스턴스에 대해, 트랜잭션 트레이서(transaction tracer)는, 예를 들어, 도 4b1 및 연관된 설명에 근거하여, 각각의 비즈니스 트랜잭션, 트랜잭션 및 컴포넌트에 대한 실행 시간 및 호출 지속시간을 계산할 수 있다.

두 번째 프로세싱 경로에서, 두 개의 서로 다른 데이터 세트가 제공되는바, 하나는 유향 그래프의 구조를 특정하기 위한 것이고, 나머지 하나는 특정 트랜잭션 트레이스들을 그 맵 구조에 맵핑하기 위한 것이다. 이러한 것들은 유향 그래프 상에 트랜잭션 트레이스 정보의 오버레이(overlay)를 제공하기 위해 사용된다. 이러한 데이터 세트들을 제공하기 위해, 단계 906에서, 해당 시기에 호출된 프론트 엔드 서브시스템들 및 비즈니스 트랜잭션들이 식별된다. 유향 그래프 데이터는 모든 트랜잭션들에 걸쳐 제공될 수 있다. 유향 그래프를 구축하기 위해 사용되는 데이터는 캡처되어 (데이터 샘플링을 사용하여) 계속적으로 저장되고, 그리고 각각의 맵은, 예를 들어, 라이브 업데이트(live updates)를 통해 (디폴트 값으로서) 과거 3일 동안의 데이터를 나타낼 수 있다. 구성 설정은 이러한 디폴트 시간 윈도우(default time window)를 변경시킬 수 있고, 그리고 사용자는 또한 이력 시간 범위(historical time range)를 특정할 수 있다. 양쪽 경우에 있어서, 맵을 구축하기 위한 정보는 데이터 저장소로부터 검색된다.

서브시스템들을 비즈니스 트랜잭션에 연관시키는 것은, 발생하고 있는 트랜잭션들에 대한 정보를 보고하는 특별한 맵 트레이서(map tracer)들을 사용하여 달성될 수 있는바, 만약 트랜잭션이 비즈니스 트랜잭션 컴포넌트와 매칭된다면 그 트랜잭션은 해당 비즈니스 트랜잭션 컴포넌트 명칭으로 라벨링되고 그 트랜잭션 동안 호출된 하위 레벨 컴포넌트들 모두는 해당 비즈니스 트랜잭션 컴포넌트와 연관된다(이에 따라 그 비즈니스 트랜잭션과 연관됨). 이러한 하위 레벨 컴포넌트들은 이후, 어떤 규칙들에 근거하여 "서브시스템들"로 집결된다.

비즈니스 트랜잭션은, 쓰레드의 초기 세그먼트로서, 그 선택된 비즈니스 트랜잭션 컴포넌트 혹은 프론트 엔드 식별자를 찾음으로써 식별될 수 있다. 서브시스템 식별자가 트랜잭션 트레이스에서 발견되면, 서브시스템이 호출되었다고 결론을 내릴 수 있다. 그 다음에, 트랜잭션에서 그 포인트로부터 행해진 모든 콜들은, 그 다음 인식된 서브시스템(프론트 엔드 혹은 백 엔드 콜)이 호출될 때까지, 필연적으로 동일한 서브시스템의 일부이다.

더욱이, 개별 트랜잭션 트레이스 내에서, 맵 및 트리에 나타난 프론트 엔드 및 백 엔드 콜들은, 해당 컴포넌트가 임의의 트레이스된 트랜잭션의 일부로서 히트(hit)되는 경우, 세그먼트와 연관된 특정 메트릭 경로들(식별자들)과 연관된다.

세 번째 프로세싱 경로에서, 단계 912는 유향 그래프 상에서 서브시스템들에 대해 추가적인 데이터 세트에서 건강도 메트릭들을 계산한다. 도 5l를 또한 참조하기 바란다. 이러한 메트릭들은 트랜잭션 트레이스들로부터 획득된 응답 시간과 같은 성능 메트릭들과 대비된다.

단계 907는 여기에서 기술된 모델을 갱신한다. 더 자세한 사항들은 도 10에 제공된다.

단계 908는 사용자 커맨드를 수신하는 것을 포함한다. 사용자 커맨드들은, 본 명세서에서 설명된 바와 같이 트리 영역(tree region)(504), 메인 영역(main area)(502) 및 보조 영역(auxiliary region)(562)과 같은, 사용자 인터페이스의 다양한 부분들에서의 선택들 및/또는 엔트리들을 포함할 수 있다. 단계 910는 모델을 사용하여, 분석 하에 있는 시간 구간 동안 관련 정보로 사용자 인터페이스를 디스플레이(예를 들어, 업데이트)하는 것을 포함한다.

도 10은 도 9의 단계 907에서와 같은 모델을 갱신하는 예시적 방법을 도시한다. 단계 1000는 에이전트에 의해 수신되는 데이터로부터, 컴포넌트의 서브젝트 인스턴스에 대한 정보의 필드들을 획득하는 단계를 포함한다. 필드들은, 예를 들어, 이름, 타입, 계층 레벨 및 에이전트 식별자를 포함할 수 있다. 결정 단계 1002는, 예를 들어, 모델이 정보의 필드들(예를 들어, 동일한 이름, 타입, 계층 레벨 및 에이전트 식별자)과 일치하는 버텍스 레코드를 포함하는지 결정함으로써, 버텍스 레코드가 컴포넌트의 인스턴스들에 대해 존재하는지를 결정한다. 버텍스 레코드가 모델 내에 존재하면, 결정 단계 1014로 진행한다.

결정 단계 1014는 새 에지가 컴포넌트의 인스턴스와 관련되는지를 결정한다. 이는 에지 레코드들의 Tail_Owner_ID와 Head_Owner_ID를 정보 필드들 내의 컴포넌트의 인스턴스의 콜러(caller) 또는 콜리(callee) 컴포넌트의 식별자에 대해 비교하는 단계를 수반할 수 있다. 예를 들어, 컴포넌트의 인스턴스가 도 5a의 PlaceOrder|service이고, 필드가 그것이 포트(3456) 상의 시스템 로컬 호스트를 콜했음을 나타낸다고 가정하기로 한다. 이 콜에 대해 에지가 존재하지 않으면(Tail_Vertex_ID= PlaceOrderServiceID이고 Head_Vertex_ID= SystemLocalHost1ID인 에지 레코드, 그러한 에지 레코드가 생성된다. 에지가 새 에지라면, 단계 1016은 새 에지 레코드를 생성하고 그것을 버텍스 레코드들, 에지 소유자 레코드들, 및 트랜잭션 레코드에 링크한다. 결정 단계 1014가 거짓(false)이면, 단계 1000으로 다시 돌아간다.

결정 단계 1002가 거짓이면, 결정 단계 1004는 버텍스 레코드가 서브젝트 컴포넌트의 또 다른 인스턴스에 대해 존재하는지 결정한다. 예를 들어, 컴포넌트 인스턴스는, 컴포넌트 인스턴스들이 서로 다른 에이전트 식별자 필드들을 가질 때 이 컴포넌트 인스턴스들이 서로 다른 것으로 고려되게끔 에이전트 식별자에 결부(tie)될 수 있다. 결정 단계 1004는 모델이 에이전트 식별자가 아닌 다른 정보 필드들과 일치하는 버텍스 레코드(예를 들어, 동일한 이름, 타입, 계층 구조, 그러나 다른 에이전트 식별자)를 포함하는지 결정함으로써 컴포넌트의 또 다른 인스턴스에 대해 버텍스 레코드가 존재하는지 결정할 수 있다. 버텍스 레코드가 모델에 존재한다면, 단계 1018은 컴포넌트의 서브젝트 인스턴스에 대한 새로운 버텍스 레코드를 생성하여 그것을 기존에 존재하는 버텍스 레코드 또는 다른 인스턴스들의 레코드들에 선택적으로 링크할 수 있다. 결정 단계 1010로 진행한다.

결정 단계 1004가 거짓이라면, 이는 컴포넌트의 임의의 인스턴스에 대해 모델 내에 버텍스 레코드가 존재하지 않음을 의미한다. 따라서, 단계 1006는 컴포넌트에 대한 새로운 버텍스 레코드를 생성한다. 단계 1008는 메트릭 경로 레코드를 생성하여 그것을 새로 생성된 버텍스 레코드에 링크한다. 결정 단계 1010로 진행한다. 결정 단계 1010는 컴포넌트의 인스턴스의 에이전트가, 에이전트 레코드가 존재하지 않는 새로운 에이전트인지 결정한다. 이 단계는 에이전트 레코드들의 Agent_ID를 컴포넌트의 각각의 버텍스 레코드의 Agent_ID에 비교하는 단계를 수반한다. 컴포넌트들의 버텍스 레코드들 내에 매칭되는 Agent_ID가 존재하지 않으면, 에이전트는 새로운 에이전트이고, 단계 1012는 새 에이전트 레코드를 생성하여 그것을 컴포넌트 인스턴스를 위한 버텍스 레코드에 링크한다. 도 6a를 참조하기로 한다. 결정 단계 1010가 거짓이면, 위에서 논의된 결정 단계 1014로 진행한다.

본 발명의 앞서의 설명은 예시적 목적 및 설명 목적으로 제시된다. 이것은 본 발명을 이렇게 개시된 형태에 정확하게 한정시키려 하는 것이 아니며 또한, 본 발명의 실시예 모두를 말하는 것도 아니다. 앞서의 가르침의 관점에서 많은 수정 및 변형이 가능하다. 본 명세서에서 설명되는 실시예들은 본 발명의 원리 및 그 실용적 응용을 가장 잘 설명하기 위해 선택된 것으로, 이에 따라 본 발명의 기술분야에서 숙련된 자들이 다양한 구현으로 그리고 고려하는 특정 용도에 맞는 다양한 수정으로 본 발명을 최상으로 이용할 수 있도록 하기 위해 선택된 것이다. 본 발명의 범위는 본 명세서에 첨부되는 특허청구범위에 의해 정의되도록 의도되었다.

Claims (20)

1. 애플리케이션을 통하는 흐름들(flows through application)을 추적(tracking)하는 컴퓨터-구현(computer-implemented) 방법으로서,
   상기 애플리케이션에 관련된 트랜잭션들(304, 306, 308, 310, 312) 동안 호출되는 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들(버텍스, 800, 802, 804, 806, 812, 820, 824)을 제공하는 단계와;
   상기 소프트웨어 컴포넌트들 간의 콜(call)들을 식별하는 에지 레코드들(에지, 822)을 제공하는 단계와, 상기 에지 레코드들은 상기 버텍스 레코드들에 링크되며;
   상기 트랜잭션들을 식별함과 아울러 상기 에지 레코드들에 링크되는 트랜잭션 레코드들(트랜잭션)을 제공하는 단계와, 상기 트랜잭션 레코드들은 트랜잭션 계층(hierarchy)을 나타내며, 상기 트랜잭션 계층은 상기 트랜잭션 계층의 일 레벨에서의 트랜잭션들 및 상기 트랜잭션 계층의 제1의 상위 레벨(first higher level)에서의 트랜잭션들의 그룹(grouping)을 포함하고; 그리고
   사용자 인터페이스 디스플레이(122) 내에 유향 그래프(directed graph)(500, 505, 520, 525, 530, 540, 550, 555, 556, 560, 570, 590, 610)를 제공하는 단계를 포함하며, 상기 유향 그래프는 상기 버텍스 레코드들에 근거한 버텍스들(310, 312, 304, 306, 308, 340, 342, 344, 320, 350, 322, 360, 362, 324, 321, 341, 343, 345, 347, 349, 351, 349, 351, 327, 326, 334, 332, 329, 328, 336, 331, 330, 338) 및 상기 에지 레코드들에 근거한 에지들(Es1-Es18)을 포함하고, 상기 버텍스들은 상기 트랜잭션 계층에 따라 배열(arrange)되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
2. 제1 항에 있어서,
   상기 소프트웨어 컴포넌트들 중 하나는 서로 다른 에이전트들(108, 112, 116)에 의해 모니터링되는 복수의 인스턴스들을 포함하고; 그리고
   상기 서로 다른 에이전트들에 의해 모니터링되는 복수의 인스턴스들을 포함하는 상기 소프트웨어 컴포넌트넌트들 중 하나에 대해, 상기 버텍스 레코드들은 상기 서로 다른 에이전트들에 대한 서로 다른 버텍스 레코드들, 및 상기 서로 다른 버텍스 레코드들의 어그리게이션(aggregation)을 나타내는 공통 버텍스 레코드(common vertex record)를 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
3. 제2 항에 있어서,
   상기 유향 그래프 내의 상기 버텍스들은 상기 공통 버텍스 레코드에 근거한 것이며, 사용자로 하여금 상기 서로 다른 에이전트들에 걸친 어그리게이션에 근거하여 상기 애플리케이션을 통한 흐름을 볼 수 있게 하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
4. 제2 항 또는 3 항에 있어서,
   상기 유향 그래프 내의 상기 버텍스들은 상기 서로 다른 버텍스 레코드들 중 하나에 근거한 것이며, 사용자로 하여금 상기 애플리케이션을 통한 흐름을 볼 수 있게하고, 여기서 상기 흐름은 상기 서로 다른 에이전트들 중 하나에 특정(specific)된 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
5. 제1 항 내지 4 항 중 임의의 한 항에 있어서,
   상기 버텍스들 중 하나가 상기 유향 그래프에서 상기 트랜잭션 계층의 일 레벨과 관련된 것으로서 식별되고 상기 버텍스들 중 또 다른 하나가 상기 유향 그래프 내에서 상기 트랜잭션 계층의 제1의 상위 레벨과 관련된 것으로서 식별되게끔 상기 버텍스들이 상기 트랜잭션 계층에 따라 배열되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
6. 제1 항 내지 5 항 중 임의의 한 항에 있어서,
   상기 트랜잭션들의 그룹을 식별함과 아울러 상기 트랜잭션 레코드들 중 하나에 링크되는 비즈니스 트랜잭션 레코드(비즈니스 트랜잭션)를 제공하는 단계와; 그리고
   상기 트랜잭션 계층의 제1의 상위 레벨 위의, 상기 트랜잭션 계층의 제2의 상위 레벨을 나타냄과 아울러, 상기 트랜잭션 계층의 제1의 상위 레벨에 있는 트랜잭션들의 그룹을 식별하는 비즈니스 트랜잭션 레코드에 링크되는 비즈니스 서비스 레코드(비즈니스 서비스)를 제공하는 단계를 더 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
7. 제1 항 내지 6 항 중 임의의 한 항에 있어서,
   상기 소프트웨어 컴포넌트들을 모니터링하는 에이전트들(108, 112, 116)로부터 데이터를 수신하는 단계를 더 포함하며, 상기 데이터는 상기 소프트웨어 컴포넌트들 중 하나에 대한 정보의 필드들을 포함하고, 상기 버텍스 레코드들을 제공하는 단계는, 상기 모델이 정보의 필드들과 일치하는 버텍스 레코드를 포함하는지를 결정하는 단계와, 그리고 상기 모델이 상기 버텍스 레코드를 포함하지 않는 경우, 상기 소프트웨어 컴포넌트들 중 하나를 나타내기 위하여 상기 모델 내의 정보의 필드들과 일치하는 버텍스 레코드를 제공하는 단계를 포함하고, 상기 에지 레코드들 및 상기 트랜잭션 레코드들을 제공하는 단계는 상기 정보의 필드들에 근거한 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
8. 제7 항의 컴퓨터-구현 방법에 있어서, 상기 모델이 상기 버텍스 레코드를 포함하는지 결정하는 단계는 상기 모델이,
   상기 정보의 필드들과 일치하는 이름(Vertex_Name)과, 여기서 상기 이름은 소프트웨어 컴포넌트의 이름이고;
   상기 정보의 필드들과 일치하는 타입(Vertex_Type_Name)과, 여기서 상기 타입은 소프트웨어 컴포넌트의 타입이고;
   상기 정보의 필드들과 일치하는 계층 레벨(Hierarchy_level)과; 그리고
   상기 정보의 필드들과 일치하는 에이전트 식별자(Agent_ID)로 구성된 버텍스 레코드를 포함하는지를 결정하는 것을 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
9. 제1 항 내지 8 항 중 임의의 한 항에 있어서,
   상기 소프트웨어 컴포넌트들 중 하나는 자식 컴포넌트이고 상기 소프트웨어 컴포넌트들 중 또 다른 하나는 관련된 부모 컴포넌트이며;
   상기 버텍스 레코드들 중 하나는 상기 관련된 부모 컴포넌트에 대한 것이고, 상기 버텍스 레코드들 중 또 다른 하나는 상기 자식 컴포넌트에 대한 것이며 상기 과련된 부모 컴포넌트의 식별자를 포함하고;
   상기 유향 그래프 내의 상기 버텍스들은 상기 자식 컴포넌트 및 상기 관련된 부모 컴포넌트의 자식-부모 관계를 표시하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
10. 제1 항 내지 9 항 중 임의의 한 항에 있어서,
    상기 에지 레코드들 중 하나는, (a) 상기 소프트웨어 컴포넌트들 중 하나를 상기 콜들 중 하나의 콜러(caller)로서 식별하는 테일 식별자(Tail_Vertex_ID)와, (b) 상기 소프트웨어 컴포넌트들 중 또 다른 하나를 상기 콜들 중 하나의 콜리(callee)로서 식별하는 헤드 식별자(Head_vertex_ID)를 포함하여, 상기 유향 그래프로 하여금 콜러로부터 콜리로의 에지(Es1-Es18)를 표시할 수 있게 하며, 그리고 또한 (c) 상기 유향 그래프로 하여금 상기 콜러의 소유자의 이름 및 상기 콜리의 소유자의 이름을 표시할 수 있게 하기 위하여, 상기 콜러의 소유자의 이름(Tail_owner_ID), 및 상기 콜리의 소유자의 이름(Head_owner_ID)을 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
11. 제1 항 내지 10 항 중 임의의 한 항에 있어서,
    상기 에지 레코드들 중 하나는 이름-값 쌍을 표시하는 에지 특성 식별자(Edge_properties)를 포함하고;
    상기 버텍스 레코드들 중 하나는 이름-값 쌍을 표시하는 버텍스 특성 식별자(Vertex_properties)를 포함하고; 그리고
    상기 유향 그래프는 상기 에지 특성 식별자 및 상기 버텍스 특성 식별자에 의해 표시되는 상기 이름-값 쌍들을 사용하여 제공되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
12. 제1 항 내지 11항 중 임의의 한 항에 있어서,
    (a) 상기 에지 레코드들 및 (b) 상기 버텍스 레코드들 중 하나는, 상기 사용자 인터페이스로 하여금 관련된 URL(Uniform Resource Locator)를 표시할 수 있게 하기 위하여, 관련된 URL의 식별자(Context_URL)를 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
13. 제1 항 내지 12 항 중 임의의 한 항에 있어서,
    상기 버텍스 레코드들은 상기 소프트웨어 컴포넌트들의 타입을 식별하여, 상기 사용자 인터페이스로 하여금 상기 타입을 표시할 수 있게 하고, 상기 타입은 서블릿, EJB, 데이터베이스, 데이터베이스 소켓, 소켓, 웹 서비스, 메시징 서버, 및 EJB 클라이언트 중 적어도 하나를 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
14. 제1 항 내지 13 항 중 임의의 한 항에 있어서,
    상기 버텍스 레코드들 중 하나는 소프트웨어 컴포넌트들의 계층에서의 관련된 레벨을 표시하는 식별자(Hierarchy_level)를 포함하며, 상기 소프트웨어 컴포넌트들의 계층은, 클래스, 클래스-방법 쌍, 프로세스, 및 JVM 중 적어도 하나를 포함하고, 상기 식별자는 상기 버텍스 레코드들 중 하나 내에 정보의 입도(granularity)를 표시하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
15. 제1 항 내지 14 항 중 임의의 한 항에 있어서,
    상기 소프트웨어 컴포넌트들에 대한 성능 메트릭들에 대한 경로(path)를 식별하는 메트릭 경로 레코드(Metric_path)를 제공하는 단계를 더 포함하며, 상기 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들 각각은 상기 메트릭 경로 레코드들 중 하나에 링크되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
16. 제1 항 내지 15 항 중 임의의 한 항에 있어서,
    상기 사용자 인터페이스 디스플레이에서 사용하기 위하여, 상기 콜들의 소유자를 식별하는 소유자 레코드(Edge_owner_ID)를 제공하는 단계를 더 포함하고, 상기 소유자 레코드는 상기 에지 레코드들 중 하나에 링크되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
17. 제1 항 내지 16 항 중 임의의 한 항에 있어서,
    상기 트랜잭션 레코드들 중 하나는, 에지들의 세트가 상기 트랜잭션들 중 하나를 나타내는 것으로 고려되도록 특정된 순서로 발생하여야 함을 표시하는 상기 에지 레코드들의 레코드들의 순서화된 세트(ordered set)(600)에 링크되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
18. 제1 항 내지 17 항 중 임의의 한 항에 있어서,
    상기 소프트웨어 컴포넌트들 중 하나는 서로 다른 에이전트들에 의해 모니터링되는 복수의 인스턴스들을 포함하고,
    상기 에지 레코드들은 상기 서로 다른 버텍스 레코드들과 관련된 서로 다른 에지 레코드들, 및 상기 서로 다른 에지 레코드들의 어그리게이션을 나타냄과 아울러 상기 공통 버텍스 레코드에 링크되는 공통 에지 레코드를 포함하는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터-구현 방법.
19. 애플리케이션을 통하는 흐름들을 추적하는 시스템으로서,
    컴퓨터 판독가능 코드를 저장하는 저장 디바이스와; 그리고
    상기 저장 디바이스와 통신하는 프로세서와, 상기 프로세서는 상기 컴퓨터 판독가능 코드를 실행하여,
    상기 애플리케이션에 관련된 트랜잭션들 동안에 호출되는 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들(Vertex, 800, 802, 804, 806, 812, 820, 824)을 제공하고;
    상기 소프트웨어 컴포넌트들 간의 콜들을 식별하는 에지 레코드들(Edge, 822)을 제공하고, 상기 에지 레코드들은 상기 버텍스 레코드들에 링크되며;
    상기 에지 레코드들에 링크됨과 아울러 상기 트랜잭션들을 식별하는 트랜잭션 레코드들(Transaction)을 제공하고, 상기 트랜잭션 레코드들은 트랜잭션 계층을 나타내며, 상기 트랜잭션 계층은 상기 트랜잭션 계층의 일 레벨에서의 트랜잭션들 및 상기 트랜잭션 계층의 제1의 상위 레벨(first higher level)에서의 트랜잭션들의 그룹(grouping)을 포함하고; 그리고
    사용자 인터페이스 디스플레이(122) 내에 유향 그래프(directed graph)(500, 505, 520, 525, 530, 540, 550, 555, 556, 560, 570, 590, 610)를 제공하며, 상기 유향 그래프는 상기 버텍스 레코드들에 근거한 버텍스들(310, 312, 304, 306, 308, 340, 342, 344, 320, 350, 322, 360, 362, 324, 321, 341, 343, 345, 347, 349, 351, 349, 351, 327, 326, 334, 332, 329, 328, 336, 331, 330, 338) 및 상기 에지 레코드들에 근거한 에지들(Es1-Es18)을 포함하고, 상기 버텍스들은 상기 트랜잭션 계층에 따라 배열(arrange)되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 시스템.
20. 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터 프로그램 물(computer program product)로서,
    컴퓨터 판독가능 프로그램 코드가 수록된 컴퓨터 판독가능 저장 매체와, 상기 컴퓨터 판독가능 프로그램 코드는,
    상기 애플리케이션에 관련된(involving) 트랜잭션들 동안에 호출되는 소프트웨어 컴포넌트들을 식별하는 버텍스 레코드들(Vertex, 800, 802, 804, 806, 812, 820, 824)을 제공하도록 된 컴퓨터 판독가능 프로그램 코드와;
    상기 소프트웨어 컴포넌트들 간의 콜들을 식별하는 에지 레코드들(Edge, 822)을 제공하도록 된 컴퓨터 판독가능 프로그램 코드와, 상기 에지 레코드들은 상기 버텍스 레코드들에 링크되며;
    상기 에지 레코드들에 링크됨과 아울러 상기 트랜잭션들을 식별하는 트랜잭션 레코드들(Transaction)을 제공하도록 된 컴퓨터 판독가능 프로그램 코드와, 상기 트랜잭션 레코드들은 트랜잭션 계층을 나타내며, 상기 트랜잭션 계층은 상기 트랜잭션 계층의 일 레벨에서의 트랜잭션들 및 상기 트랜잭션 계층의 제1의 상위 레벨(first higher level)에서의 트랜잭션들의 그룹(grouping)을 포함하고; 그리고
    사용자 인터페이스 디스플레이(122) 내에 유향 그래프(directed graph)(500, 505, 520, 525, 530, 540, 550, 555, 556, 560, 570, 590, 610)를 제공하도록 된 컴퓨터 판독가능 프로그램 코드를 포함하며, 상기 유향 그래프는 상기 버텍스 레코드들에 근거한 버텍스들(310, 312, 304, 306, 308, 340, 342, 344, 320, 350, 322, 360, 362, 324, 321, 341, 343, 345, 347, 349, 351, 349, 351, 327, 326, 334, 332, 329, 328, 336, 331, 330, 338) 및 상기 에지 레코드들에 근거한 에지들(Es1-Es18)을 포함하고, 상기 버텍스들은 상기 트랜잭션 계층에 따라 배열(arrange)되는 것을 특징으로 하는 애플리케이션을 통하는 흐름들을 추적하는 컴퓨터 프로그램 물.

Images