KR101837109B1 - 트랜잭션을 논리적 서브시스템들의 맵을 통하는 흐름들로서 시각화하는 방법 - Google Patents

Abstract

컴퓨터 시스템의 서브시스템들을 통하는 흐름들을 시각화함으로써 컴퓨터 시스템에서의 문제들을 진단하는 방법에 개시된다. 진단 툴들은 애플리케이션들과 같은 서브시스템들(이 서브시스템들을 통해 비즈니스 트랜잭션이 흐름), 및 상기 서브시스템들 사이의 콜 관계(calling relationship)를 그래픽적으로 표시하는 분류 맵을 포함하는 사용자 인터페이스를 포함한다. 서브시스템들은 경보들 및 성능 정보를 포함하는 노드들에 의해 표시될 수 있다. 사용자는 특정 비즈니스 트랜잭션의 트랜잭션들 및/또는 응답 시간 및 사용자 식별자와 같은 필터 기준에 부합하는 프론트 엔드 서브시스템을 검색하기 위한 커맨드를 실행(run)할 수 있다. 각각의 캡쳐된 트랜잭션은 응답 시간 및 보고 에이전트와 같은 정보로 열거될 수 있다. 특정 트랜잭션 인스턴스의 상세들, 예컨대 트랜잭션 인스턴스의 호출된 컴포넌트들, 이 또한 트랜잭션 트레이스에서 보여질 수 있다.

Description

트랜잭션을 논리적 서브시스템들의 맵을 통하는 흐름들로서 시각화하는 방법{VISUALIZING TRANSACTION TRACES AS FLOWS THROUGH A MAP OF LOGICAL SUBSYSTEMS}

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

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

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

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

본 발명은 컴퓨터 시스템의 서브시스템들을 통하는 흐름들을 시각화(visualizing)함으로써 컴퓨터 시스템 내부의 문제점들을 진단하는 방법을 제공한다.

일 실시예에서, 하나 이상의 애플리케이션들을 통하는 흐름들의 시각화 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하기 위하여, 컴퓨터 판독 가능한 소프트웨어가 내장되어 있는, 일시적이지 않으며 실재하는(non-transitory, tangible) 컴퓨터 판독 가능 저장매체가 제공된다. 수행되는 상기 방법은; (a) 하나 이상의 애플리케이션들과 관련된(associated) 하나 이상의 에이전트(agent)들로부터 획득되는 데이터에 액세스하기 위하여 데이터 저장매체에 액세스하는 단계와, 여기서 상기 에이전트들은 상기 하나 이상의 애플리케이션들에 인스톨된(installed) 인스트루먼테이션을 이용하여 상기 데이터를 제공하고, (b) 사용자 인터페이스 상에 분류(triage) 맵 영역(map region)을 디스플레이하는 단계와, 여기서 상기 분류 맵 영역은 상기 하나 이상의 애플리케이션들의 서브시스템들 및 그 서브시스템들 간의 종속 관계(dependency relationship)들을 그래픽적으로(graphically) 표시(depiction)하고, 상기 서브시스템들은 노드(node)들로, 그리고 상기 종속 관계들은 상기 노드들을 연결하는 화살표들로 표시되며, 그리고 (c) 상기 액세스된 데이터에 근거하여, 적어도 하나의 트랜잭션 인스턴스(transaction instance)와 관련된 정보를 제공하는, 사용자 인터페이스의 보조 영역(auxiliary region)을 디스플레이하는 단계를 포함한다.

또 다른 실시예에서는, 하나 이상의 애플리케이션들을 통하는 흐름들을 시각화하기 위한 컴퓨터 구현 방법이 제공된다. 이 방법은 컴퓨터 구현 단계들: 즉, (a) 하나 이상의 애플리케이션들과 관련된 하나 이상의 에이전트들로부터 획득된 데이터에 액세스하기 위하여 데이터 저장매체(data store)에 액세스하는 단계와, 여기서 상기 에이전트들은 상기 하나 이상의 애플리케이션들에 인스톨된 인스트루먼테이션을 이용하여 데이터를 제공하며, (b) 사용자 인터페이스 상에 분류 맵 영역을 디스플레이하는 단계와, 여기서 상기 분류 맵 영역은 상기 하나 이상 애플리케이션들의 서브시스템들 및 그 서브시스템들 간의 종속 관계들을 그래픽적으로 표시하고, 상기 서브시스템들은 노드들로, 그리고 상기 종속 관계들은 상기 노드들을 연결하는 화살표들로 표시되며, 상기 분리 맵 영역은 비즈니스 트랜잭션(business transaction) 및 상기 비즈니스 트랜잭션에서 호출되는 복수의 서브시스템들을 식별하고, 그리고 (c) 상기 액세스된 데이터에 근거하여, 사용자 인터페이스의 보조 영역을 디스플레이하는 단계를 포함한다.

또 다른 실시예에서는, 하나 이상의 애플리케이션들을 통하는 흐름들의 시각화 방법을 수행하도록 적어도 하나의 프로세서를 프로그래밍하기 위하여, 컴퓨터 판독가능 소프트웨어가 내장되어 있는, 유형의, 비일시적 컴퓨터 판독 가능 저장매체가 제공된다. 수행되는 상기 방법은; (a) 하나 이상의 애플리케이션들과 관련된 하나 이상의 에이전트들로부터 획득된 데이터에 액세스하기 위하여 데이터 저장매체에 액세스하는 단계와, 여기서 상기 에이전트들은 상기 하나 이상의 애플리케이션들에 인스톨된 인스트루먼테이션을 이용하여 데이터를 제공하며, (b) 사용자 인터페이스 상에 분류 맵 영역을 디스플레이하는 단계와, 여기서 상기 분류 맵 영역은 상기 하나 이상의 애플리케이션들의 서브시스템들 및 그 서브시스템들 간의 종속 관계들을 그래픽적으로 표시하고, 상기 서브시스템들은 상기 서브시스템의 이름들을 지닌 서브시스템 노드들로, 그리고 상기 종속 관계들은 상기 서브시스템 노드들을 연결하는 화살표들로 표시되며, (c) 상기 서브시스템 노드들 중 하나는 적어도 제1 및 제2 비즈니스 트랜잭션들에 의하여 호출되고 상기 서브시스템 노드들 중 하나에 의하여 표시되며, (d) 상기 분류 맵 영역은 제1 비즈니스 트랜잭션의 이름을 지닌 상기 제1 비즈니스 트랜잭션 및 제2 비즈니스 트랜잭션의 이름을 지닌 제2 비즈니스 트랜잭션을 디스플레이하고, (e) 사용자가 상기 서브시스템 노드들 중 하나를 선택하는 것에 응답하여, 상기 사용자 인터페이스는 상기 서브시스템들 중 하나를 위한 콘텍스트 메뉴(context menu)를 디스플레이하며, 여기서 상기 콘텍스트 메뉴는, 적어도 제1 비즈니스 트랜잭션의 부분으로서 상기 서브시스템들 중 하나를 호출하는, 미래의 시간 기간 내의 트랜잭션 인스턴스들을 검색하고, 그리고 (e) 검색된 트랜잭션 인스턴스들과 관련된 정보를 제공하기 위하여 상기 사용자 인터페이스를 갱신하는 단계를 포함한다.

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

도 1은 관리되는(managed) 애플리케이션을 포함하는 시스템을 보여주는 도면이다.
도 2a는 트랜잭션에 대한 트레이싱을 시작하는 프로세스의 한 가지 실시예를 표시하는 흐름도이다.
도 2b는 트랜잭션의 실행시간을 완성하기 위한 프로세스의 한 가지 실시예를 표시하는 흐름도이다.
도 2c는 도 1의 네트워크의 컴퓨팅 장치를 보여주는 도면이다.
도 3은 하나 이상의 애플리케이션들의 동작을 기술하는 데 사용되는 계층구조를 보여주는 도면이다.
도 4a는 트랜잭션에서 호출된 컴포넌트들의 한 가지 예시적인 시퀀스(sequence)에서의 종속 관계들을 보여주는 도면이다.
도 4ba은 도 4a의 가능한 컴포넌트들의 시퀀스에 근거하여, 트랜잭션에서 호출된 컴포넌트들의 시퀀스들을 위한 예시적인 트랜잭션 트레이스들을 보여주는 도면이다.
도 4bb는 도 4ba의 예시적인 트랜잭션 트레이스들에서 대기 기간(waiting period)들을 보여주는 도면이다.
도 4bc은 종속적인 인스트루먼트된(instrumented) 서브시스템들의 시퀀스에 대하여, 총 지속시간(total duration), 네트 지속시간(net durations), 대기 시간, 및 서브시스템 간 통신 시간들을 결정하기 위한 방법을 보여주는 도면이다.
도 5a는 서브시스템들 및 비즈니스 트랜잭션들의 사용자 인터페이스(UI)로서, 비즈니스 서비스가 사용자에 의하여 선택된 것을 보여주는 도면이다.
도 5ba은 도 5a의 사용자 인터페이스를, 로그인 비즈니스 트랜잭션(304)을 위한 메트릭(metric)들을 보여주는 호버 박스(hover box)를 추가한 상태로 보여주는 도면이다.
도 5bb는 도 5a의 사용자 인터페이스를, 인증서비스 서브시스템(322)을 위한 메트릭들을 보여주는 호버 박스를 추가한 상태로 보여주는 도면이다.
도 5c는 도 5a의 사용자 인터페이스를, 로그인 비즈니스 트랜잭션(304)를 위한 옵션(option)들을 보여주는 호버 박스를 추가한 상태로 보여주는 도면이다.
도 5d는, 도 5c의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인 비즈니스 트랜잭션의 맵(map)에 대한 사용자 인터페이스를 보여주는 도면이다.
도 5ea은, 도 5c의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인 비즈니스 트랜잭션을 위하여 대응 트랜잭션들의 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5eb는 선택된 비즈니스 트랜잭션의 콘텍스트(context) 내에서 인증서비스 서브시스템을 위하여 매칭 트랜잭션들을 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5ec은 다수의 비즈니스 트랜잭션들의 콘텍스트 내에서 인증서비스 서브시스템을 위하여 매칭 트랜잭션들을 검색하기 위한 사용자 인터페이스를 보여주는 도면이다.
도 5f는 로그인의 서브시스템들 중 일부만이 선택된 비즈니스 트랜잭션 인스턴스에 의하여 호출되는 경우의 사용자 인터페이스를 보여주는 도면이다.
도 5g는, 도 5c의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인의 위치들에 대한 사용자 인터페이스를 보여주는 도면이다.
도 5h는, 도 5c의 사용자 인터페이스의 콘텍스트 메뉴(532)로부터 론치된, 로그인 비즈니스 트랜잭션의 건강도 메트릭(health metric)의 사용자 인터페이스를 보여주는 도면이다.
도 5i는, 사용자가 노드(322)와 보조 영역(562)의 "상세"(details) 탭을 선택한 후에, 도 5g의 사용자 인터페이스를 보여주는 도면이다.
도 5j는, 사용자가 노드(328)와 보조 영역(562)의 "상세"(details) 탭을 선택한 후에, 도 5g의 사용자 인터페이스를 보여주는 도면이다.
도 5k는, 도 5ea의 사용자 인터페이스로부터 론치될 수 있는, 선택된 트랜잭션 인스턴스를 위한 트랜잭션 트레이스들을 보여주는 도면이다.
도 5l은, 사용자가 서브시스템 노드를 선택한 경우에, 도 5k의 사용자 인터페이스를 보여주는 도면이다.
도 5ma은, 사용자가 트랜잭션 트레이스를 선택한 경우에, 도 5k의 사용자 인터페이스를 보여주는 도면이다.
도 5mb은, 사용자가 트랜잭션 트레이스 내의 컴포넌트를 선택한 경우에, 도 5k의 사용자 인터페이스를 보여주는 도면이다.
도 5n은 도 5k의 사용자 인터페이스가 플레이백(playback) 모드로 된 것을 보여주는 도면으로서, 시간 마커(time marker)의 위치에 따라 서브시스템 노드(322)가 하이라이트된(highlighted) 것을 보여주는 도면이다.
도 5o는 도 5k의 사용자 인터페이스에서 경로(513)이 하이라이트된 것을 보여주는 도면이다.
도 5p는 도 5k의 사용자 인터페이스가 플레이백(playback) 모드로 된 것을 보여주는 도면으로서, 서브시스템 노드(328)이 하이라이트된 것을 보여주는 도면이다.
도 5q는 도 5k의 사용자 인터페이스가 플레이백(playback) 모드로 된 것을 보여주는 도면으로서, 경로(613)이 하이라이트된 것을 보여주는 도면이다.
도 5r은, SQL 문장(statement)들을 추가한, 도 5q의 트랜잭션 트레이스(651)를 보여주는 도면이다.
도 5s는 예시적인 사용자 인터페이스(680)로서, 사용자가 화살표(613)를 선택하고, 그 결과 도 5ma의 보조 영역(562) 내에서 그래프 부분들, CM8(647), CM9(648) 및 CM10(640)이 시각적으로 구분된 것을 보여주는 도면이다.
도 6은 사용자 인터페이스를 제공하기 위한 방법을 보여주는 도면이다.

본 발명은 컴퓨터 시스템의 서브시스템들을 통하는 흐름들을 시각화함으로써 컴퓨터 시스템 내의 문제점들을 진단하는 방법을 제공한다.

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

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

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

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

더 나아가, 상기 맵 아래쪽의 탭 창(tabbed pane)과 같은 보조 영역은 추가적인 옵션들 및 정보를 제공할 수 있다. 제1 탭은 결과값으로 반환된(returned) 트랜잭션들(트랜잭션 리스트)를 포함하여, 사용자가 어떤 항목들이 선택되었는지(그리고 상기 맵에 겹쳐져 표시되는지)를 확인하고 수정할 수 있도록 할 수 있다. "더 보기" 버튼은 사용자로 하여금 동일한 파라미터들을 사용하여 더 많은 트랜잭션들을 기록할 수 있도록 한다. 제2 탭(상세)은 상기 맵에서 현재 선택되어 있는 항목에 대한 정보를 제공한다. 예를 들어, 만약 프론트엔드(front-end) 노드가 선택되었다면, 해당 프론트엔드에 대응하는 겹쳐진 트랜잭션들의 모든 컴포넌트들이, 클래스 및 메소드에 의거하여, 그 컴포넌트들의 에이전트 식별자(identifier)들 및 지속시간들과 함께 나열된다. 사용자는 상기 노드들로부터 조사자 에이전트 트리(investigator agent tree)에 있는 대응되는 메트릭 경로들(metric paths)로 이동(navigate)할 수 있게 된다.

마지막으로, 상기 맵에 표시된 각각의 트랜잭션에 대하여, 탭이 해당 트랜잭션의 "트레이스 보기"(trace view)를 트랜잭션 트레이서에서 보여지는 것처럼, 그 위쪽에 보여지는 되감기(rewind), 재생, 정지, 일시정지 및 빨리 감기(fast forward)와 같은 VCR 타입의 제어버튼들과 함께, 화면에 보여준다. 사용자는 상기 트리 안에서 개별적인 컴포넌트들을 선택함으로써 상기 컴포넌트를 호출하는 대응하는 서브시스템이 맴에서 선택되게 할 수 있고; 사용자는 또한 전체 트랜잭션에 대하여 "재생"을 선택할 수도 있다. 상기 재생 중에, 트레이스 내의 각각의 컴포넌트가 차례로 선택되고, 상기 맵 내의 대응되는 서브시스템도 역시 선택된다. 상기 맵에서는 선택된 항목들 옆에 관련된 지속시간이 표시된다. 또 다시, 사용자는 트레이스 보기에 있는 컴포넌트로부터 조사자 에이전트 트리(Investigator agent tree) 내의 대응 메트릭 경로로 이동(navigation)할 수 있다.

상기한 바와 동일한 기능이 트랜잭션 트레이스들을 제공하는 기존의 인터페이스들에서도 사용 가능하도록 될 수 있다. 만약 해당 트레이스가 분류 맵에 있는 애플리케이션들 또는 비즈니스 트랜잭션들과 매칭되는(matched) 경우에는, "해당 트랜잭션 맵핑하기"의 옵션이 제공될 수 있다. 이는, 위에서 설명한 바와 같이, 대응되는 오버레이(overlay)와 함께 적절한 맵을 보여준다.

추가로, 상기 기능은 트랜잭션 트레이스로부터 인스트루먼테이션을 동적으로 추가하는 옵션을 포함하도록 확장될 수 있다. 일시적 인스트루먼테이션은, 더욱 상세한 정보를 위하여 저속의 트랜잭션들을 조사하기(drill into) 위하여, 사용자에 의하여 추가될 수 있고; 또한 현재의 인스트루먼테이션이 특정 비즈니스 트랜잭션들의 성능을 트랙킹하는 데 적절한지 또는 최적인지를 평가하기 위하여 사용될 수도 있다. 만약 그렇지 않다면, 일시적으로 추가된 인스트루먼테이션은 영구적인 것으로 만들어질 수 있다. 다음 단계에 있어서는, 상기 기능이 사용자들로 하여금 그들의 비즈니스 서비스들을 모니터링하도록 그들의 시스템들을 구성할 수 있게 하는 간단한 방법을 제공할 수 있다.

아래에서는 서로 다른 디자인 화면들 또는 사용자 인터페이스들이 더욱 상세하게 제공된다.

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

도 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)는 일시적이지 않으며 실재하는(non-transitory, tangible) 프로세서 또는 컴퓨터 판독 가능 저장 장치로서, 상기 프로세서(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)을 포함한다. 인스트루먼트되지 않은 서브시스템들은, 오더레코드SQL(OrderRecordsSQL)(332), 보고레코드SQL(ReportRecords SQL)(338), 시스템 caDBHost(334)(이는 그것의 포트번호 6543를 통하여 액세스됨), 시스템 caSAPHost(321)(이는 그것의 포트번호 3456 및 고객레코드SQL (CustRecordsSQL)(336)를 통하여 액세스됨)을 포함한다. 그 이름에 SQL을 포함하는 서브시스템은 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)에 있는 것으로 간주될 수 있는 반면에 실행중인 컴포넌트는 액티브, 실행 모드에 있는 것으로 간주될 수 있다. 컴포넌트는 트랜잭션 동안 두번 이상 호출될 수도 있다.

도4ba은 도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를 콜한다.

도4bb는 도4ba의 예시적인 트랜잭션 트레이스들에서 대기 기간들(waiting periods)을 나타낸다. 동기(synchronous) 트랜잭션은 하나의 컴포넌트, 예컨대 CM1을 포함하는바, CM1은 다른 하나의 컴포넌트 예컨대, CM2를 콜하고 그리고 실행을 지속/재개하기 전에 답신하기 위하여 CM2를 기다린다. 콜된(called) 메소드에 의해서 요구되는 시간은, 콜하는(calling) 메소드에 대한 "대기 시간(wait time)" 이라는 점을 가정할 수 있다. 또한, 비동기 트랜잭션을 트레이스하는 것도 가능하며, 그리고 이것을 도4ba과 유사한 트랜잭션 트레이스 도면에 도시하는 것도 가능하다. 상기 대기 시간 이외의(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 각각은 데이터베이스(CustRecordsSQL)를 콜한다. 하지만, 상기 데이터베이스가 인스트루먼트되지 않았기 때문에, 데이터베이스에 의해서 소모되는 시간의 양은, 트랜잭션 트레이스(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 이다. 백 엔드 콜 시간들은 콜되는 하나 이상의 인스트루먼트된 혹은 인스트루먼트되지 않은 서브시스템들에 할당될 수 있다. 상기 일례에서, 하나의 인스트루먼트되지 않은 서브시스템이 콜되며(CustRecordsSQL), 따라서 300 ms 가 이에 할당된다.

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

이와 유사하게, 우리는 인증서비스 서브시스템의 루트 컴포넌트 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) 등으로 나타낼 수 있다. 이러한 예시적인 절차는 다음에 설명될 것이다.

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

이러한 개념들을 고려하면, 도4bc의 단계 422는 인스트루먼트된 서브시스템을 선택하는 것을 포함하며, 서브시스템에 의해서 호출된 컴포넌트들에 기초하여 트레이스가 획득된다. 예를 들어, 도4bb에서, 인증서비스 서브시스템 및 그것의 트레이스(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에서 도4bb의 인증엔진 서브시스템 및 그것의 트레이스(403)가 선택된다. 단계 424는 그 루트 컴포넌트 CM7의 지속시간으로부터 서브시스템의 전체 지속시간 T1 = 600 ms를 판별한다. 단계 426은 CM8, CM9, 및 CM10을 식별하는바, 이들은 서브시스템 외부로 나가는 콜들에 대응하며, 상기 일례에서는 인스트루먼트되지 않은 백 엔드 CustRecordsSQL 에 해당한다. 단계 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에서는, 인스트루먼트된 목적지 서브시스템이 선택된다. 도4bb의 일례에서, 인증엔진 서브시스템이 재방문된다. 단계 438에서는, 목적지 서브시스템으로의 콜들의 완전(full) 지속시간(TF = 700 ms)으로부터 전체 지속시간(T1 = 600 ms)을 감산하여, 목적지 서브시스템으로의 콜들에 대한 순수 지속시간 TN = 100 ms를 얻는다.

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

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

이러한 선택에 응답하여, 다수의(하나 이상의) 연관된 비즈니스 트랜잭션들, 비즈니스 트랜잭션들의 서브시스템들 그리고 서브시스템들 간의 종속 관련성을 나타내는 화살표들이 사용자 인터페이스의 메인 영역(502)(분류 맵 영역이라 지칭됨)에 디스플레이된다. 좌측의 타원형 노드들(304, 306, 308, 310, 312)은 비즈니스 트랜잭션들을 나타내며 그 이름들을 포함하고 있다. 화살표(에지 라고 지칭되기도 함)는 비즈니스 트랜잭션에 대해서 어떤 서브시스템이 제일 먼저 호출되는지 그리고 어떤 서브시스템들이 후속으로 호출되는지를 나타낸다. 몇몇 경우에 있어서는, 서로 다른 비즈니스 트랜잭션 인스턴스들에 대해서 공통적인 서브시스템이 호출된다. 예를 들면, 옵션 트레이딩 및 로그인 비즈니스 트랜잭션들에 의해서 인증서비스가 공통으로 호출될 수 있다.

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

또한, 동일한 비즈니스 트랜잭션의 개별 인스턴스들이 동일한 서브시스템을 호출할 필요는 없다는 점을 유의해야 한다. 예를 들어, 에러 혹은 네트워크 장애로 인하여, 비즈니스 트랜잭션 인스턴스은 에러가 없는 경우라면 호출될 수 있었던 특정 서브시스템을 호출하지 못할 수도 있다. 또는, 시각(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)을 통해 액세스되며 그리고 요청된 서비스들을 호스트하는 원격 시스템 상에서 실행된다. 이러한 콜들, 및 다른 것들(예를 들어, 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)은 본질적으로 맵 내의 더미 노드(dummy node)들인데, 왜냐하면 이들은 인스트루먼트되지 않은 목적지를 나타내고, 따라서 이들에 대해 목적지에 의해 보고되는 정보를 가질 수 없기 때문이다. 프론트 엔드들로부터의 콜들을 나타내는 화살표의 끝에서, 이러한 노드들에 인접한 원형 아이콘은 백 엔드 콜 메트릭들 및 연관된 경보(alert)들을 위한 플레이스홀더(placeholder)들로서의 역할을 한다.

하나의 엔드로부터 또 다른 엔드로의 콜을 위해, 전체 인스트루멘테이션(instrumentation)이 이용가능하다. 콜은 예를 들어, 웹 서비스 혹은 EJB 클라이언트를 통해 행해질 수 있다. 단일 프론트 엔드로부터 발신되는 모든 웹 서비스 콜들이 취합(aggregate)되어, 단일의 "웹 서비스" 백 엔드 콜로서 나타내지며, 따라서 다른 타입의 콜들과 달리, 웹 서비스 콜은 하나보다 많은 목적지를 가질 수 있다. 이러한 경우에, 백 엔드 콜은 맵 내에서 포크형(forking) 혹은 분기형(branching) 화살표로서 나타난다. 데이터의 단지 하나의 세트만이 이러한 콜과 연관되기 때문에, 일 방법에 있어서, 원형의 "W" 아이콘은 목적지 박스와 나란히 나타나는 대신 포크(fork)의 베이스(base)에서 맵 내에 나타난다. 도 5a에서, 웹 서비스(510 및 512)는 두 개의 이러한 포크형 웹 서비스 콜들을 나타내는바, 이들은 인증서비스(AuthenticationService)(322)와 인증엔진(AuthenticationEngine)(328) 간의 콜(이것도 또한 웹 서비스 콜이지만 단일의 목적지를 가짐)과 대비된다. 구체적으로, 웹 서비스 아이콘(510)은 목적지 노드들(326 및 328)과 나란히 있지 않고 포크의 베이스에 있으며, 이에 따라 웹 서비스(510)에 대한 콜과 연관된 데이터의 일 세트가 존재한다. 웹 서비스 아이콘(515)은 목적지 노드(329)와 나란히 혹은 이것에 인접하여 있는데, 왜냐하면 콜에 대해 단지 하나의 목적지만 존재하기 때문이다. 선택에 따라서는, 웹 서비스 아이콘(515)은 노드(322)와 노드(328) 사이에 있을 수 있고, 이에 따라 화살표(513)가 또한 노드(322)와 웹 서비스 아이콘(515) 사이에서 연장되지만, 추가적인 화살표(미도시)는 웹 서비스 아이콘(515)과 노드(328) 사이에서 연장된다. 웹 서비스 노드(512)는 목적지 노드들(328 및 330)과 나란히 있지 않고 포크의 베이스에 있으며, 이에 따라 웹 서비스(512)에 대한 콜과 연관된 데이터의 일 세트가 존재한다.

트레이드서비스 노드(TradeService node)(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)을 개시시킨다. 어떤 경우에서건, 트레이드서비스가 사용된다. 트레이드서비스는 예를 들어, 추가 정보를 획득하여 주문/트레이드를 프로세싱하기 위해 시스템 caSAPHost(321)를 콜한다. 시스템 caSAPHost(321)에 대해서는 거의 알려져 있지않은데, 왜냐하면 이것은 인스트루먼트되지 않기 때문이고, 따라서 이에 대한 노드는 단지 플레이스홀더이다. 트레이드서비스의 인스턴스에 의해 콜되는 컴퓨팅 디바이스(321)의 포트는 알려져 있고(예를 들어, 포트 3456), 그리고 이 정보는 노드(321)를 장식(decorate)하는 데 사용된다. 시스템 caSAPHost(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)을 콜한다. 맵은, 트레이드서비스가 거의 동일한 시간에 혹은 상이한 시간에(예를 들어 이것은 아마도 오더레코드SQL 데이터베이스(OrderRecordsSQL database)에 대한 콜이 행해진 이후일 것임) 이러한 다른 서브시스템들 양쪽 모두를 콜함을 반드시 표시할 필요가 없으며, 또는 동일한 비즈니스 트랜잭션의 일부로서 혹은 상이한 비즈니스 트랜잭션의 일부로서(결국, 트레이드서비스와 연관된 두 개의 비즈니스 트랜잭션들이 존재함) 이러한 다른 서브시스템들 양쪽 모두를 콜함을 반드시 표시할 필요도 없고, 기타의 경우도 마찬가지이다. 이들 양쪽 모두가 동일한 비즈니스 트랜잭션의 일부로서 하지만 상이한 인스턴스들 동안 콜되는 것도 또한 가능하다. 특정 시기 내의 어떤 시점에서 트레이드서비스가 이러한 프론트 엔드들 양쪽 모두를 웹 서비스(510)를 사용하여 콜했음을 맵이 보여준다.

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

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

화살표(513)로 묘사된 바와 같이, CM4a는, 인증서비스 서브시스템(322)과 동일한 서버 혹은 상이한 서버 상에 있을 수 있는 인증엔진 서브시스템(328)에서 CM7을 콜한다. CM7이 CM8을 콜하는 바, CM8은 고객 레코드에 액세스하여 사용자 로그인이 패스워드와 매칭됨을 확인하기 위해 고객레코드SQL 데이터베이스(336)를 콜한다. 이것이 성공이라고 가정하면, 제어 흐름은 CM7로 리턴(return)하고 CM7은 CM9를 콜한다. CM9는 고객 레코드들에 다시 액세스하여 사용자의 어카운트(account)가 양호한 상태(good standing)에 있음(예를 들어, 어카운트를 유지하기 위해 사용자가 수수료를 지불했음 혹은 최소 개수의 트레이드를 했음)을 확인하기 위해 고객레코드SQL 데이터베이스(336)(혹은 또 다른 데이터베이스)를 콜한다. 이것이 성공이라고 가정하면, 제어 흐름은 CM7로 리턴하고 CM7은 CM10을 콜한다. CM10은 고객 레코드들에 다시 액세스하여 (사용자가 현재 로그인되었음을 표시하도록) 레코드들을 업데이트하기 위해 고객레코드SQL 데이터베이스(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)은 고객 레코드들에 액세스하여 보고서의 획득에 대해 사용자/고객이 인증되었음을 확인하기 위해 고객레코드SQL 데이터베이스(336)를 콜할 수 있다.

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

도 4ba 내지 도 4bc과 연계되어 설명된 바와 같이 계산된 시간 메트릭들이 UI(500) 상에, 예를 들어 대응하는 노드 위에, 디스플레이될 수 있다. 즉, UI 및 그 노드들 그리고 화살표들이 메트릭들로 장식된다. 총 지속시간(total duration), 순 지속시간(net duration) 및/또는 대기 시간(wait time)이 디스플레이될 수 있다. 여기서, 로그인 노드(304) 위에는 로그인의 총 지속시간(1300 ms)이 디스플레이되고, 인증서비스 노드(322) 위에는 600 ms의 순 지속시간이 디스플레이되고, 화살표(513) 위에는 인증엔진(328)에 대한 콜을 위한 서브시스템간 통신 시간(100 ms)이 디스플레이되고, 인증엔진 노드(328) 위에는 지속시간 300 ms가 디스플레이되고, 그리고 화살표(613) 위에는 고객레코드SQL에 할당된 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)된 메트릭들과 함께 디스플레이될 수 있다.

도 5ba은 도 5a의 사용자 인터페이스를 묘사하는바, 여기에는 로그인 비즈니스 트랜잭션(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개의 스톨)를 표시한다. 호버 박스는 선택된 비즈니스 트랜잭션을 보고하는 모든 컴퓨팅 디바이스/에이전트에 걸쳐 요약 성능 데이터를 제공할 수 있다.

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

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

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

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

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

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

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

도 5d는 도 5c의 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) 경계를 가질 수 있다. 이러한 강조는 일 노드 혹은 화살표를 또 다른 노드 혹은 화살표와 시각적으로 구분하기 위한 하나의 방법이다.

도 5ea은 도 5c의 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)의 다른 부분으로서 디스플레이될 수 있거나, 또는 개별 디스플레이 스크린 상에 디스플레이될 수 있다. 보조 영역이 분류 맵 영역(triage map region)(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)에서의 다른 서브시스템들은 강조하지 않음으로써 반영될 수 있다. 예를 들어, 도 5f에 묘사된 바와 같이, 트랜잭션 인스턴스들 중 하나는 인증서비스를 호출할 수 있지만 인증엔진 또는 고객레코드SQL은 호출할 수 없는 바, 이러한 경우에 노드들(304 및 322)은 강조되지만, 노드들(328 및 336) 또는 화살표들(513 및 613)은 강조되지 않는다.

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

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

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

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

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

도 5g는 도 5c의 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를 제공하는 중앙 관리자에게 에이전트에 의해 제공될 수 있다.

도 5h는 도 5c의 UI의 콘텍스트 메뉴(532)로부터 개시된 로그인의 건강도 메트릭들의 사용자 인터페이스(580)를 묘사한다. 영역(504)에서, 트리는 건강도 메트릭들이 이용가능한 컴포넌트들을 식별하기 위해 확장된다. 여기서 비즈니스 트랜잭션들 및 다른 서브시스템들에 대해 도시된 메트릭 그래프들은 모든 에이전트들 상에서의 모든 트랜잭션 인스턴스들에 걸쳐 요약된 것이다. 일 방법에서, 트리는 각각의 비즈니스 트랜잭션에 대해 단일의 차일드 노드(child node)를 가질 수 있다. 각각의 이러한 차일드 노드는, 그 연관된 비즈니스 트랜잭션 컴포넌트(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) 내의 요소 "비즈니스 서비스별"은, 사용자가 데이터를, 예를 들어, 비즈니스 서비스 및 비즈니스 트랜잭션의 계층적 정렬(hierarchical arrangement) 관점에서 볼 수 있게 한다.

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

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

도 5i는, 사용자가 노드(322)를 선택하고 보조 영역(562)으로부터 "세부사항(Details)" 탭을 선택한 이후, 도 5g의 사용자 인터페이스를 묘사한다. 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 node)만이 사용자에 의해 선택되는 경우, 종 서브시스템(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)를 사용하는 대신 사용자 인터페이스에서 동시에 제공될 수 있다.

도 5j는 사용자가 노드(328)를 선택하고 보조 영역(562)으로부터 "세부사항" 탭을 선택한 이후, 도 5g의 사용자 인터페이스를 묘사한다. UI(600)에서, 그 선택된 서브시스템(328)(인증엔진)에 관한 추가적 세부사항들이 제공된다. 앞에서와 같이, 서브시스템 노드가 사용자에 의해 선택되는 경우 다른 타입의 강조(이중 실선 경계)가 사용된다. 보조 영역(562)은 선택된 서브시스템에서 로그인의 일부로서 호출되는 컴포넌트의 각각의 인스턴스를 식별할 수 있다. 간단한 예로서, 각각의 컴포넌트의 단지 하나의 인스턴스만이 묘사된다. 실제로는, 각각의 컴포넌트의 복수의 인스턴스들이 묘사될 수 있다. 예를 들어, CM7의 응답 시간은 600 ms이고, CM8, CM9 및 CM10 각각의 응답 시간은 100 ms이다. 호스트B 상의 에이전트B는 각각의 컴포넌트와 연관되고, 그리고 각각의 컴포넌트의 실행 시작 시간이 표시된다.

선택에 따라서는, 앞서 언급된 바와 같이, 주 서브시스템 노드만이 사용자에 의해 선택되는 경우, 종 서브시스템을 콜하는 주 서브시스템의 컴포넌트들은 보조 영역(562)에 제공되지 않는다. 예를 들어, 서브시스템 노드(328)만이 선택된 경우, CM7은 보조 영역(562)에 나열될 수 있지만 CM8, CM9 및 CM10은 그렇지 않은바, 그 이유는 CM8, CM9 및 CM10이 서브시스템(336)을 콜하기 때문이다. 이러한 방법에서, 사용자가 단지 화살표(613) 및/또는 노드(336)만을 선택한 경우, 종 서브시스템(예를 들어, CM8, CM9 및 CM10)에 대한 콜 컴포넌트들은 보조 영역 내에 저절로 나열될 수 있다. 그 다음에 만약 사용자가 또한 노드(328)를 선택한다면, 추가 컴포넌트(CM7)가 나열될 수 있다.

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

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

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)이 다른 노드들 및 화살표들과 시각적으로 구분된다.

도 5l은 사용자가 서브시스템 노드를 선택할 때, 도 5k의 사용자 인터페이스를 묘사한다. 이 경우, UI(620)에서, 사용자는 커서 위치 및 이중 실선 경계에 의해 표시된 바와 같이, 노드(322)를 선택한다. 이러한 선택으로 인해, 그 대응하는 트랜잭션 트레이스(641)가 강조되며, 혹은 만약 그렇지 않다면 보조 영역(562) 내에서 더 굵은 실선으로 트랜잭션 트레이스(651)와 시각적으로 구분된다. 따라서, 사용자는 보조 영역(562) 내의 복수의 트레이스들 중에서, 서브시스템과 연관된, 트랜잭션 트레이스를 빠르게 식별할 수 있다. 대안적으로, 사용자는 노드(328)를 선택할 수 있고, 이것은 그 대응하는 트랜잭션 트레이스(651)가 강조되게 하며, 혹은 만약 그렇지 않다면 트랜잭션 트레이스(641)와 시각적으로 구분되게 한다.

선택에 따라서는, 만약 사용자가 단지 노드(322)만을 선택한다면, 또 다른 서브시스템을 콜하지 않는 트랜잭션 트레이스(641) 내의 컴포넌트들(예를 들어, CM1, CM2, CM4b 및 CM5, 그러나 CM4a는 아님)만이 시각적으로 구분된다. 만약 사용자가 단지 화살표(513)만을 선택한다면, 또 다른 서브시스템을 콜하는 트랜잭션 트레이스(641) 내의 컴포넌트(예를 들어, CM4a)만이 시각적으로 구분된다. 만약 사용자가 노드(322)와 화살표(513) 양쪽 모두를 선택한다면, 컴포넌트들 모두가 시각적으로 구분된다. 마찬가지로, 만약 사용자가 단지 노드(328)만을 선택한다면, 트랜잭션 트레이스(651) 내의 CM7만이 시각적으로 구분된다. 만약 사용자가 화살표(613) 및/또는 노드(336)를 선택한다면, 트레이스(651) 내의 CM8, CM9 및 CM10만이 (그러나 CM7은 아님) 시각적으로 구분된다.

도 5ma은 사용자가 트랜잭션 트레이스를 선택할 때, 도 5k의 사용자 인터페이스를 묘사한다. 이 경우, UI(630)에서, 사용자는 커서 위치에 의해 표시된 바와 같이, 트랜잭션 트레이스(641)를 선택하는 바(즉, 사용자는 그래프의 대응하는 부분을 선택함), 이것은 트랜잭션 트레이스(641)가, 굵은 선에 의해 표시된 바와 같이, 트랜잭션 트레이스(651)와 시각적으로 구분되게 한다. 이것은 대응하는 서브시스템 노드(322)가 더 굵은 대쉬선으로 강조되게 하고, 이에 따라 노드(328)와 시각적으로 구분되게 한다. 따라서, 사용자는 분류 맵 영역(502) 내의 복수의 서브시스템들 중에서, 임의의 선택된 트랜잭션 트레이스와 연관된, 서브시스템를 빠르게 식별할 수 있다. 대안적으로, 사용자는 트랜잭션 트레이스(651)를 선택할 수 있고, 이것은 트랜잭션 트레이스(651)가 트랜잭션 트레이스(641)와 시각적으로 구분되게 한다. 이것은 결과적으로, 그 대응하는 서브시스템 노드(328)가 강조되게 하며, 이에 따라 노드(322)와 시각적으로 구분되게 한다.

또 다른 예에서, 사용자는, 서브시스템과 백 엔드 간의 콜 관계(calling relationship)를 묘사하는 화살표(예를 들어, 서브시스템(328)과 백 엔드(336) 간의 화살표(613))를 선택한다. 이에 응답하여, 보조 영역(562) 내의 트레이스의 하나 또는 그 이상의 그래프 부분들(예를 들어, 도 5ma의 보조 영역(562) 내의 그래프 부분들(M8(647), CM9(648) 및 CM10(649)) 또는 아래에서 더 설명되는, 도 5r의 보조 영역(562) 내의 그래프 부분들(691-693))이 시각적으로 구분된다. 이러한 그래프 부분들은 백 엔드(336)를 콜하기 위해 서브시스템(328)에서 호출되는 컴포넌트들을 나타낸다. 서브시스템(328) 및/또는 백 엔드(336)는 또한 이러한 사용자 선택엔 근거하여 강조될 수 있다. 또는, 사용자는 백 엔드(예를 들어, 백 엔드(336))를 묘사한 노드를 선택할 수 있고, 이에 응답하여 보조 영역(562) 내의 트레이스의 하나 또는 그 이상의 그래프 부분들이 시각적으로 구분된다. 이러한 그래프 부분들은 백 엔드(336)를 콜하기 위해 서브시스템(328)에서 호출되는 컴포넌트들을 나타낸다. 서브시스템(328) 및/또는 화살표(613)는 또한 이러한 사용자 선택에 근거하여 강조될 수 있다. 더 상세한 것에 대해서는 도 5s를 참조하기 바란다.

도 5mb는 사용자가 트랜잭션 트레이스 내의 컴포넌트를 선택할 때, 도 5k의 사용자 인터페이스를 묘사한다. 사용자 인터페이스(631)의 보조 영역(562) 내에서, 사용자는 단일 컴포넌트(CM2)를 선택하고, 이에 응답하여 그 연관된 서브시스템 노드(322)가 시각적으로 구분된다. 사용자는 또한, 트레이스의 복수의 컴포넌트들(그러나 트레이스의 모든 컴포넌트들 보다는 적은 수)을 선택할 수 있고, 이에 응답하여 그 연관된 서브시스템 노드 혹은 노드들이 시각적으로 구분된다. 이것은 사용자로 하여금 더 큰 입상도로 시스템을 이해할 수 있게 한다.

도 5n은 재생 모드(playback mode)에서 도 5k의 사용자 인터페이스를 묘사한 것으로, 여기서 서브시스템 노드(322)는 시간 표시자(time marker)의 위치에 근거하여 강조된다. 이러한 경우에, 시간 표시자(657)(예를 들어, 원을 구비한 수직의 굵은 선)는, 사용자에 의해 원하는 시점에, 드래그(drag)될 수 있거나 혹은 만약 그렇지 않다면 배치될 수 있다. 원은, 예를 들어, 시간 표시자와 중첩되는 트레이스의 최저 레벨에서, 트랜잭션 트레이스와 시간 표시자의 교차점(658)을 표시한다. 이러한 동작을 통해, 교차점에서 트랜잭션 트레이스 내의 컴포넌트가 선택된다.

시간 표시자는, 예를 들어 드래그를 통해 사용자에 의해 수동으로 이동될 수 있거나, 또는 재생 모드에서 자동으로 이동될 수 있다. 재생 모드에서, 보조 영역(562)은 VCR형 재생 제어 버튼 영역(656)을 포함하는바, 여기서 VCR형 재생 제어 버튼 영역(656)은, 처음으로 점프(jump to start)(js), 스텝 후진(step back)(sb), 플레이/일시정지(play/pause)(pp), 중지(stop)(sp), 스텝 전진(step forward)(sf), 및 뒤로 점프(jump to end)(je)를 위한 버튼들을 포함한다. 스텝 후진 및 스텝 전진 버튼들을 사용하는 대신, 사용자는 재생이 일시정지된 동안 다음(next)(nx) 혹은 이전 요소(previous element)(pe)를 클릭할 수 있다. 대안적인 것으로 "스텝 후진, 플레이/중지, 스텝 전진"이 있는데, 여기서 가정된 것은 "플레이"가 언제나 현재 선택된 세그먼트(segment)들"의 처음부터 시작한다는 것이다(또는 만약 선택된 것이 없다면 첫 번째 세그먼트부터 시작). 따라서, 중지는 일시정지와 동일하고, 사용자는 되감기를 위해 첫 번째 요소를 클릭할 수 있거나 앞으로 점프하기 위해서 뒤에 있는 요소를 클릭할 수 있다.

이러한 제어들을 활성화시킴으로써, 시간 표시자 및 교차점이 이동되고, 그리고 맵의 대응하는 부분들이 강조된다. 일 방법에서, 비즈니스 트랜잭션에서의 각각의 연속하는 노드는, 교차점(658)의 현재 위치에 근거하여, 강조되며, 이전의 강조된 노드들은 강조된 채로 있게 된다. 또 다른 방법에서, 시간 표시자의 현재 위치와 연관된 노드들만이 강조된다. 비즈니스 트랜잭션(로그인)을 식별하는 노드(304)는 선택에 따라서는 재생을 통해 강조된 채로 있을 수 있다.

예를 들어, "플레이"를 선택함으로써, 시간 표시자는 t0에서 시작하여 점진적으로 좌측에서 우측으로 고정된 속도로, 시간이 흐름에 따라 혹은 스텝별로, 이동할 수 있다. 사용자는 재생 속도를 조정하는 능력을 가질 수 있다. 더욱이, 사용자는 더 작은 세그먼트들에 대한 더 큰 가시성을 위해 트랜잭션 트레이스들의 시간 스케일(time scale)을 조정할 수 있다. 재생 속도는 전형적으로, 데이터가 레코딩되었던 실제 속도보다 더 느리다.

한가지 옵션에서, "앞으로 스킵(skip ahead)" 혹은 "뒤로 스킵(skip back)" 버튼을 통해 재생이 이산적 증분치(discrete increments)(예를 들어, 스텝(steps)) 단위로만 진행될 수 있게 할 수 있는바, 결과적으로 이것은 강조된 노드들 및/또는 노드들 간의 화살표들에서의 변화가 일어나게 하고, 이에 따라 사용자는 분류 맵의 강조된 노드들에서의 변화를 거치며 빠르게 나아갈 수 있다. 예를 들어, 사용자가 "앞으로 스킵" 버튼을 클릭할 때마다, 시간 표시자(657)는 다음 시점으로 점프할 수 있는바, 결과적으로 이것은 노드들의 강조에서의 변화가 일어나게 한다. 이러한 경우에, 시간 표시자는 각각의 증분치에 대한 사용자 커맨드에 응답하여 증분치 단위로 스킵한다. 마찬가지로, 사용자가 "뒤로 스킵" 버튼을 클릭할 때마다, 시간 표시자(657)는 이전 시점으로 점프할 수 있는바, 결과적으로 이것은 노드들의 강조에서의 변화가 일어나게 한다. 또 다른 옵션에서, "앞으로 스킵" 버튼은 사용자에 의해 이전에 선택된 토글 버튼(toggle button)이고, 이에 응답하여, 재생은 동일한 이산적 증분치 단위로 진행한다(이 경우 사용자로 하여금 각각의 증분치에 대한 커맨드를 다시 선택할 것을 요구하지는 않음). 시간 표시자는 증분치 단위로 이동하여 서브시스템들의 노드들 및/또는 화살표들의 강조에서의 변화를 일으키는 선택된 시점에서 중지된다(이 경우 노드들 및/또는 화살표들의 강조에서의 변화를 일으키지 않는 시점들에서는 중지되지 않음). 이러한 선택된 시점들은, 예를 들어, 그래프에서의 각각의 변이(transition)에 근거하여 그래프를 여러 구간으로 분할함으로써, 그리고 각각의 구간과 연관된 하나 또는 그 이상의 서브시스템들 및/또는 화살표들을 식별함으로써, 그리고 동일한 하나 또는 그 이상의 서브시스템들 및/또는 화살표들과 연관된 인접한 구간들을 결합함으로써, 식별될 수 있다. 남아 있는 시점들은 강조에서의 변화가 일어나는 시점들이다. 다시 한번 버튼을 클릭함으로써 해당 버튼은 정상 상태(상승 상태)로 리턴하게 되고, 그리고 재생은 정규의 세그먼트별 업데이트를 재개하게 된다.

강조된 노드들 및/또는 화살표들에서의 변화를 일으키는 이산적 증분치의 예로서, 그 강조된 서브시스템 노드들 및/또는 화살표들, 그리고 대응하는 시간들은, t0 (노드(322)), t2 (화살표(513)), t3.5 (노드(328)), t4 (화살표(613)), t5 (노드(328)), t6 (화살표(613)), t7 (노드(328)), t8 (화살표(613)), t9 (노드(328)), t9.5 (화살표(513)), t10 (노드(322)), 및 선택에 따라서는 종점으로서 t13(노드(322))이다.

또 다른 옵션에서, 시간 표시자는 균등하게 트랜잭션 트레이스를 거쳐 이동하기보다는 트랜잭션 트레이스에서 컴포넌트 단위로 스킵한다. 각각의 스킵은 분류 맵에서의 변화를 일으킬 수 있거나 혹은 일으키지 않을 수 있지만, 이것은 사용자로 하여금 서로 다른 컴포넌트들이 트레이스에서 어디에 있는지 그리고 얼마나 많은 컴포넌트들이 동일한 서브시스템과 연관되었는지를 알 수 있게 하는데 도움을 준다. 또한, 맵은, 예를 들어, 서브시스템에 대한 총 시간이 아닌, 현재 선택된 컴포넌트의 지속시간을 보여주기 위해 업데이트될 수 있다. 예를 들어, td는, 아래에서 더 설명되는, 도 5q에서의 컴포넌트(CM8)에 대한 시간이다. 컴포넌트에서 컴포넌트로 스킵하기 위한 이산적 증분치의 예로서, 그 강조된 서브시스템 노드들 및/또는 화살표들, 그리고 대응하는 시간들은 앞서의 예와 동일하고, 추가된 것은, t1 (노드(322)), t11 (노드(322)), t11.5 (노드(322)), t12 (노드(322)) 및 t12.5 (노드(322))이다.

이러한 스킵 방법에서, 시간 표시자는, 각각의 이산적 시간 증분치의 맨 좌측 부분, 또는 중앙, 또는 맨 우측 부분에 배치될 수 있다.

도 5o는 도 5n의 사용자 인터페이스를 묘사하는바, 여기서 경로(513)는 UI(650)에서 강조되어 있다. 이때, t2 내지 t3으로부터, CM4는 이미 t2에서 CM7에게 콜을 행했을 수 있고, CM7은 t3까지는 실행을 시작하지 않았으며, 이에 따라 경로(513)를 통해 통신이 일어나고 있다. 결과적으로, 경로(513)가 강조된다.

도 5p는 재생 모드에서 도 5n의 사용자 인터페이스를 묘사하고, 여기서 서브시스템 노드(328)는 UI(660)에서 강조되어 있다. 이때, t3 내지 t4로부터, CM7이 실행되고 있지만, 백 엔드(336)에 대한 콜은 아직 행해지지 않았고, 이에 따라 경로(613)는 강조되지 않는다.

도 5q는 재생 모드에서 도 5n의 사용자 인터페이스를 묘사하고, 여기서 경로(613)는 UI(670)에서 강조되어 있다. 이때, t4 내지 t5로부터, CM8이 백 엔드(336)에 대한 콜을 행하고 있으며, 이에 따라 경로(613)(화살표와 원 아이콘)는 강조된다. 일 방법에서, 노드(328)는 강조되지 않는데, 왜냐하면 데이터베이스(336)로부터의 응답을 기다리고 있기 때문이다. 일 방법에서, 노드(336)는 강조되지 않는데, 왜냐하면 노드(336)는 인스트루멘테이션을 갖지 않아 트랜잭션 트레이스에서 보여질 수 없는 더미 노드(dummy node)이기 때문이다. 대안적으로, 화살표(613)와 노드(336)는 결합될 수 있고, 이에 따라 이들은 함께 강조된다(혹은 강조되지 않는다). 상기할 것은, 백 엔드에 대한 콜이, 예를 들어, 웹 서비스 콜을 나타내거나, 혹은 하나 또는 그 이상의 차일드 SQL 문(child SQL statements)과 결합된 JDBC 드라이버 콜을 나타낼 수 있다는 것이다. 따라서, CM8, CM9 및 CM10은 각각, 트랜잭션 트레이스에서의 개별 깊이 레벨에서 나타나는 하나 또는 그 이상의 차일드 SQL 문과 결합된 JDBC 드라이버 콜을 나타낼 수 있다(JDBC 드라이버 콜이 일 레벨에 있고 SQL 문이 그 다음 하위 레벨에 있음). 간단하게 말하면, 이러한 것들은 트랜잭션 트레이스들(641 및 642)에서 하나의 레벨로 결합된다.

도 5r은 SQL 문이 추가된 도 5q의 트랜잭션 트레이스(651)를 묘사한다. 설명된 바와 같이, 하나의 가능한 실시예에서, CM8, CM9 및 CM10은 각각 JDBC 드라이버 콜일 수 있고, 차일드 SQL 문(691, 692 및 693) 각각이 또한 묘사된다.

도 5s는 예시적 사용자 인터페이스(680)를 묘사하는바, 여기서 사용자는 화살표(613)를 선택하고, 이것은 결과적으로 도 5ma의 보조 영역(562) 내의 그래프 부분들(CM8(647), CM9(648) 및 CM10(649))이 시각적으로 구분되게 한다. 화살표 형상의 커서, 및 결과적으로 더 굵은 화살표(613)는 사용자 선택을 나타낸다. 도 5r의 보조 영역에서, 추가적으로 혹은 대안적으로, 그래프 부분들(691-193)은 시각적으로 구분될 수 있다.

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

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

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

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

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

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

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

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

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

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

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

Claims (21)

1. 방법에 있어서,
   사용자 인터페이스(122, 500, 520, 525, 530, 540, 550, 555, 556, 560, 570, 580, 590, 600, 610, 620, 630, 640, 650, 660, 670, 680) 상에 분류 맵 영역(triage map region)(502)을 디스플레이하는 단계와, 상기 분류 맵 영역은 애플리케이션의 서브시스템들 및 상기 서브시스템들 사이의 종속 관계들(dependency relationships)을 그래픽적으로 표시하고, 상기 서브시스템들은 노드들(320, 321, 322, 324, 326, 328, 330, 336)로서 표시되고 상기 종속 관계들은 상기 노드들을 연결하는 화살표들(513)을 사용하여 표시되고, 상기 화살표들은 상기 서브 시스템들이 서로 콜(call)하는 순서를 나타내며;
   상기 애플리케이션과 관련된 에이전트로부터 얻어진 데이터 및 상기 노드들중 하나를 선택하는 사용자 커맨드에 근거하여, 상기 사용자 인터페이스의 보조 영역(auxiliary region)(562)을 디스플레이하는 단계를 포함하며, 상기 보조 영역은 상기 노드들 중 상기 하나에 의해 표시된 서브시스템들 중 하나를 호출(invoking)하는 하나의 트랜잭션 인스턴스와 관련된 정보를 제공하며;
   상기 서브시스템들 중 하나의 노드들 중 하나의 사용자 선택에 응답하여, 상기 사용자 인터페이스에 상기 서브시스템들 중 상기 하나에 대한 콘텍스트 메뉴(532)를 디스플레이하는 단계와, 상기 콘텍스트 메뉴는 미래의 시간에 상기 서브시스템들 중 하나를 호출하는 트랜잭션 인스턴스들을 찾는 옵션을 포함하며;
   그리고 상기 찾아진 트랜잭션 인스턴스들과 관련된 정보를 제공하기 위하여 상기 사용자 인터페이스를 갱신하는 단계를 포함하는 것을 특징으로 하는 방법.
2. 제1 항에 있어서,
   상기 서브시스템들은 상기 하나의 트랜잭션 인스턴스에서 호출되는 서브시스템들을 포함하며,
   상기 보조 영역을 통하여 상기 하나의 트랜잭션 인스턴스의 사용자 선택에 응답하여 상기 하나의 트랜잭션 인스턴스에 의해 호출된 서브시스템들의 노드들을 상기 하나의 트랜잭션 인스턴스에 의해 호출되지 않는 상기 분류 맵 영역에 있는 다른 서브시스템들의 노드들로부터 시각적으로 구분하는 단계를 더 포함하는 것을 특징으로 하는 방법.
3. 제2 항에 있어서,
   상기 하나의 트랜잭션 인스턴스의 사용자 선택에 응답하여, 상기 보조 영역을 통하여 상기 하나의 트랜잭션 인스턴스의 트랜잭션 트레이스(401) - 상기 트랜잭션 트레이스는 상기 하나의 트랜잭션 인스턴스의 호출된 콤포넌트들을 식별하는 그래프임 - 및 상기 호출된 컴포넌트들 간의 콜 관계들(calling relationships)을 디스플레이하는 단계를 더 포함하는 것을 특징으로 하는 방법.
4. 제1 항 내지 3항 중 어느 한 항에 있어서,
   상기 서브시스템들 중 상기 하나의 서브시스템의 대기 시간(wait time)보다 짧은 총 실행 지속시간(total execution duration)을 나타내는 네트 지속시간(net duration)으로 상기 노드들 중 하나를 장식(decoration)하는 단계를 더 포함하는 것을 특징으로 하는 방법.
5. 제1 항에 있어서,
   상기 서브시스템들 중 다른(another) 서브시스템은 상기 서브시스템들 중 하나의 서브시스템에 의해 콜되는 언인스트루먼트 백 엔드(uninstrumented back end)를 포함하며,
   상기 언인스트루먼트 백 엔드에 대한 백 엔드 콜 시간보다 짧은 총 지속시간에 근거하여 상기 서브시스템들 중 상기 하나에서 소비된 시간으로 상기 노드들중 하나의 노드를 장식하는 단계를 더 포함하는 것을 특징으로 하는 방법.
6. 제1 항에 있어서,
   인터-서브시스템 통신 시간을 나타내는 지속시간으로 상기 화살표들 중 하나를 장식하는 단계를 더 포함하는 것을 특징으로 하는 방법.
7. 제1 항에 있어서,
   상기 서브시스템들 중 하나를 경보 아이콘(alert icon)으로 장식하는 단계를 더 포함하고,
   상기 경보 아이콘은 복수의 트랜잭션 인스턴스들에 걸친 상기 서브시스템들 중 상기 하나의 서브시스템의 수행(performance)에 근거하여 경보 레벨을 표시하는 것을 특징으로 하는 방법.
8. 제1 항에 있어서,
   상기 서브시스템들 중 하나를 경보 아이콘으로 장식하는 단계를 더 포함하고,
   상기 경보 아이콘은 상기 화살표들 중 상기 하나로 나타내지는 메소드 콜(method call)의 수행에 근거하여 경보 레벨을 표시하는 것을 특징으로 하는 방법.
9. 제1 항에 있어서,
   상기 서브시스템들 중 상기 하나의 서브시스템은 상기 서브시스템들 중 다른(another) 서브시스템을 콜하는 인스트루먼트 서브시스템(instrumented subsystem)을 포함하며, 상기 서브시스템들 중 상기 다른 서브시스템은 언인스트루먼트 서브시스템(118)을 포함하고 상기 노드들 중 다른 노드에 의해 표시되며,
   상기 화살표들 중 하나는 상기 노드들 중 상기 하나의 노드를 상기 노드들 중 상기 다른 노드(321, 332, 334, 336, 338)에 연결하고; 그리고
   상기 분류 맵 영역은 상기 화살표들 중 상기 하나를, 상기 언인스트루먼트 서브시스템을 콜하는데 있어서 상기 인스트루먼트 서브시스템에 의해 사용되는 지속시간을 표시하도록 장식하는 것을 특징으로 하는 방법.
10. 제1 항에 있어서,
    상기 분류 맵 영역은 비즈니스 트랜잭션의 이름을 지닌 노드(304, 306, 308, 310, 312)를 디스플레이하고; 그리고
    상기 사용자 인터페이스는 사용자가 상기 비즈니스 트랜잭션의 이름을 지닌 노드(304)에 대해 포인팅 디바이스를 포인팅할 때 상기 비즈니스 트랜잭션을 지닌 상기 노드에 대한 호버 박스(522)를 디스플레이하며, 상기 호버 박스는 상기 비즈니스 트랜잭션의 복수의 트랜잭션 인스턴스들에 대한 수행 매트릭을 디스플레이 하는 것을 특징으로 하는 방법.
11. 제1 항에 있어서,
    상기 분류 맵 영역은 비즈니스 트랜잭션의 이름을 지닌 노드(304, 306, 308, 310, 312)를 디스플레이하고; 그리고
    사용자가 상기 비즈니스 트랜잭션의 이름을 지닌 노드(304)에 대해 포인팅 디바이스를 포인팅함에 응답하여, 상기 사용자 인터페이스는 상기 비즈니스 트랜잭션에 대한 콘텍스트 메뉴(532)를 디스플레이하며, 상기 콘텍스트 메뉴는 상기 비즈니스 트랜잭션 내의 상기 하나의 트랜잭션 인스턴스에서 호출되는 상기 복수의 서브시스템들의 노드들을, 상기 비즈니스 트랜잭션 내의 상기 하나의 트랜잭션 인스턴스에서 호출되지 않는 상기 분류 맵 영역 내의 다른 서브시스템들의 노트들로부터 시각적으로 구분함으로써 상기 비즈니스 트랜잭션의 맵을 디스플레이하는 옵션을 포함하는 것을 특징으로 하는 방법.
12. 제1 항에 있어서,
    상기 분류 맵 영역은 비즈니스 트랜잭션의 이름을 지닌 노드(304, 306, 308, 310, 312)를 디스플레이하고;
    사용자가 상기 비즈니스 트랜잭션의 이름을 지닌 노드에 대해 포인팅 디바이스를 포인팅함에 응답하여, 상기 사용자 인터페이스는 상기 비즈니스 트랜잭션에 대한 콘텍스트 메뉴를 디스플레이하며, 상기 콘텍스트 메뉴(532)는 필터 기준을 만족하는 미래의 시간 기간 내에 상기 비즈니스 트랜잭션의 트랜잭션 인스턴스들을 찾는 옵션을 포함하고; 그리고
    상기 보조 영역은 상기 필터 기준을 만족하는 상기 찾아진 트랜잭션 인스턴스들과 관련된 수행 매트릭들을 제공하도록 업데이트되는 것을 특징으로 하는 방법.
13. 프로세서로 하여금 방법을 수행하도록 프로그램된 컴퓨터 판독가능 소프트웨어가 수록된 유형의, 비-일시적인 컴퓨터 판독가능 스토리지로서,
    상기 방법은:
    사용자 인터페이스 상에 분류 맵 영역을 디스플레이하는 단계와, 상기 분류 맵 영역은 애플리케이션의 서브시스템들 및 상기 서브시스템들 사이의 종속 관계들(dependency relationships)을 그래픽적으로 표시하고, 상기 서브시스템들은 상기 서브시스템들의 이름을 갖는 서브시스템 노드들로서 표시되고, 상기 종속 관계들은 상기 노드들을 연결하는 화살표들로 표시되고, 상기 화살표들은 상기 서브 시스템들이 서로 콜하는 순서를 나타내고, 상기 서브시스템들 중 하나는 제1 및 제2 비즈니스 트랜잭션에 의해 호출되고 상기 서브시스템 노드들 중 하나로 표시되며, 상기 분류 맵 영역은 상기 제1 비즈니스 트랜잭션의 이름을 갖는 제1 비즈니스 트랜잭션 노드와 상기 제2 비즈니스 트랜잭션의 이름을 갖는 제2 비즈니스 트랜잭션 노드를 디스플레이하며;
    사용자가 상기 서브시스템 노드들 중 하나를 선택함에 응답하여, 상기 사용자 인터페이스는 상기 서브시스템들 중 상기 하나에 대한 콘텍스트 메뉴를 디스플레이하는 단계와, 상기 콘텍스트 메뉴는 상기 제1 비즈니스 트랜잭션의 일부로서 상기 서브시스템들 중 하나를 호출하는 트랜잭션 인스턴스들을 찾는 옵션을 포함하며; 그리고
    상기 애플리케이션과 관련된 에이전트로부터 얻어지는 데이터에 근거하여, 상기 트랜잭션 인스턴스들과 관련된 정보를 제공하도록 하기 사용자 인터페이스를 어데이트하는 단계를 포함하는 것을 특징으로 하는 유형의, 비-일시적인 컴퓨터 판독가능 스토리지.
14. 제13 항에 있어서,
    만일 상기 사용자가 상기 제1 비즈니스 트랜잭션 노드만을 선택하고, 상기 제2 비즈니스 트랜잭션 노드는 선택하지 않는 경우, 상기 콘텍스트 메뉴의 상기 옵션은 상기 제2 비즈니스 트랜잭션의 일부로서 상기 서브시스템들 중 상기 하나를 호출하는 트랜잭션 인스턴스들을 찾지 않는 것을 특징으로 하는 유형의, 비-일시적인 컴퓨터 판독가능 스토리지.
15. 제13 또는 14항에 있어서,
    상기 콘텍스트 메뉴의 상기 옵션은 상기 제2 비즈니스 트랜잭션의 일부로서 상기 서브시스템들 중 상기 하나를 호출하는 트랜잭션 인스턴스들을 찾는 것을 특징으로 하는 유형의, 비-일시적인 컴퓨터 판독가능 스토리지.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제

Images