소개

Solaris (OpenSolaris 포함), FreeBSD 및 Mac OS X에 빌드된 DTrace(Dynamic Tracing) 기능에는 애플리케이션을 동적으로 추적할 수 있는 간단한 환경이 있다. 디버깅과 달리, DTrace는 원하는 대로 기능을 끄거나 켤 수 있으며 추적 기능을 이용하기 위해 애플리케이션을 특별히 빌드할 필요가 없다.

위에 있는 모든 플랫폼에서는 표준 DTrace 프로브를 사용할 수 있다. 코드 내에 있는 다양한 함수의 경계에서 운영 체제에 의해 노출되는 프로브를 다룬다. 이러한 프로브를 FBT(Function Boundary Tracing)라고 하며 이 프로브를 이용하면 특정 함수가 시작하거나 중지하는 시점을 식별할 수 있다.

이 기능의 한계는 단편적인 기능보다는 애플리케이션의 기능을 프로브하는 데만 사용될 수 있다는 점이다. 단일한 조작을 구성하는 다수의 기능 전체에서 실행 과정을 시험하고자 하거나 단편적인 하나의 기능을 조사하고자 할 경우에는 FBT가 유용하지 않다.

자체 애플리케이션인 경우에는 USDT(User-land Statically Defined Tracing)를 사용하여 이러한 문제를 해결할 수 있다. USDT를 이용하면 개발자가 애플리케이션 코드에서 중요하다고 생각되는 위치에 특정 프로브를 추가할 수 있다. 또한, USDT 시스템을 이용하면 실행 중인 애플리케이션에서 데이터를 노출할 수 있으며 애플리케이션을 추적하는 과정에서 프로브의 인수로서 이 데이터를 액세스할 수 있다.

시스템에 USDT 프로브를 추가하려면, 먼저 프로브에서 보고할 내용과 제공할 정보 및 잠재적인 성능 문제를 고려해야 한다.

위로

프로브 디자인

표준 FBT 프로브가 요구사항에 적합하지 않다고 결정되면 애플리케이션에 정적 프로브를 추가하는 것을 고려해야 한다.

DTrace를 사용하여 애플리케이션에 프로브를 추가할 때 먼저 고려해야 할 사항은 첫째, 실제로 프로브를 사용하는 이유를 결정하는 것이다. 프로브를 이용하면 다양한 문제점과 정보를 확인할 수 있지만, 먼저 프로브할 대상을 선택해야 한다. 모든 함수의 경계에 표준 entry/exit 프로브(제공된)를 사용하여 찾기에는 어려운 측정 가능한 정보나 기능 또는 성능과 같은 특정 영역을 선택해야 한다.

그러므로 간단히 말해서 다음과 같은 두 가지 주요 프로브 유형을 고려해야 한다.

1. 정보 프로브: 이 프로브는 프로그램을 실행하는 과정에서 달리 판별하기 어려운 일부 정보를 표시하거나 요약한다. 여기에 있는 예제에는 내부 구조의 크기나 내용 또는 함수에 의해 직접 처리되지 않는 이벤트의 조작이나 트리거링이 포함되어 있다. 기존 운영 체제의 프로브에는 이러한 예제가 다수 있다. 예를 들면, 가상 메모리 시스템의 결함이나 디스크 I/O 통계에 관한 정보를 얻을 수 있다.
2. 조작 프로브: 이 프로브는 사용자가 프로브를 사용하여 시퀀스의 처음과 마지막에서 내부 구조에 관한 특정 정보를 얻거나 특정 명령 세트의 실행 시간을 모니터할 수 있도록 특정 이벤트나 일련의 명령문을 일괄하여 처리한다. 이러한 프로브를 어느 곳이든지 추가하여 조작의 시작과 마지막을 표시할 수 있기 때문에 이러한 프로브의 적용 범위를 다수의 함수로 확대하거나 특정 함수의 일부로 한정할 수 있다. 이렇게 하는 것이 범위가 너무 넓거나 적은 함수 경계를 사용하는 것보다 더욱 실용적이다. 관례에 따라 이러한 프로브에서는 일반적으로 start와 done 접미부를 사용한다.

프로브 유형을 결정한 후에는 프로브에서 추가 정보를 표시할 것인지, 표시한다면 어떤 정보를 어떤 형식으로 표시할 것인지 고려해야 한다. DTrace에서는 적합한 DTrace 스크립트나 One-liner를 작성할 때 처리할 수 있는 인수를 통해 프로브에서 정보를 노출할 수 있다. 예를 들어, 파일 I/O 함수를 도구화하면 작성된 파일의 이름을 프로브에 추가하여 이 함수를 추적할 수 있다.

프로브를 정의할 때 이러한 인수에 다음과 같은 이름과 유형을 지정한다. probe write__file__start(int id, char *filename);.

모니터하는 과정에서 DTrace 스크립트 내에서 인수를 사용하는 경우, 각 인수는 arg0, arg1 등과 같은 변수에서 사용할 수 있다. 따라서, printf("%s\n", copyinstr(arg1)); 명령을 사용하여 파일 이름과 두 번째 인수를 인쇄할 수 있다.

표시할 올바른 데이터를 선택하려면 애플리케이션을 모니터하는 과정에서 프로브에서 확인할 사항을 알아야 한다. 예를 들어, 위에서 살펴본 I/O 함수 예제에서는 함수를 사용하여 다수의 파일에 쓰려면 파일 이름을 알아야 한다. 그러나 함수가 같은 파일에만 쓰는 경우에는 프로브에서 이 정보를 표시할 필요가 없다.

그러므로 사용자는 정보를 표시할 방법을 고려해야 한다. 조작 유형이나 파일 또는 네트워크 포트에 따라 데이터를 요약할 수 있기를 원하는가? 데이터 크기나 작성된 실제 데이터를 알고 싶은가? 이러한 모든 사항은 프로그램과 환경에 따라 매우 달라진다.

또한, 이러한 방식으로 정보를 제공하면 오버헤드가 발생하므로 특히 대용량 구조와 같은 정보를 공유하지 말아야 한다. DTrace 프로브를 추가하기 위해 복사하고, 단축하거나 재형식화하는 것이 훨씬 더 영향을 많이 줄 것이라는 점을 감안하더라도 제한된 정보만을 제공하거나 요약된 정보를 제공해야 한다.

이러한 방식으로 프로브를 사용하는 것이 유용하며 이러한 방식에는 두 가지가 있다. 다수의 프로브를 사용하는 방법과 특별히 '프로브의 활성화 여부'를 확인하여 코드 블록을 둘러싸는 방법이다. dtrace 명령을 사용하여 프로브를 작성하고 헤더 파일을 생성하는 경우에는 두 번째 방법을 매우 간단한 형태로 지원할 수 있다. 프로브가 활성화되었는지 판별하여(즉, 프로브를 능동적으로 모니터) 코드 블록을 둘러싸고 추가로 조작을 수행한다. 이러한 조작은 데이터를 요약하거나 메시지로 전송해야 하는 경우에 유용하다(Listing 1 참조).

if (WRITE_FILE_START_ENABLED())
{
    ...
}

별도의 프로브를 사용하는 첫 번째 방법에서는 특정 프로브를 사용하여 필요한 정보를 얻을 수 있다. 예를 들면, 원하는 정보를 판별할 수 있도록 개념적으로 중첩된 프로브를 사용하여 다양한 레벨에서 여러 가지 정보를 제공하는 프로브 구조를 여기에 있는 I/O 예제를 사용하여 구현할 수 있다.

• write-file-start(ID)
• write-file-data(파일 이름, 버퍼)
• write-file-done(ID)

애플리케이션을 모니터할 때, write-file 조작의 속도를 모니터하면 되는 경우에는 write-file-start와 write-file-done 프로브를 사용할 수 있으며 이러한 프로브는 참조용 ID를 제공한다. 파일 이름 데이터를 원하는 경우에는 write-file-data 프로브를 선택적으로 모니터하여 처리 과정에서 이러한 정보를 출력할 수 있다.

마지막으로 모든 프로브에서는 DTrace 프로브를 모니터할 권한이 있는 사용자가 노출된 정보를 액세스할 수 있다는 점을 기억해야 한다. 예를 들어, 프로브에서 이메일 주소나 메시지 내용이 노출되면 DTrace 프로브를 모니터할 권한이 있는 모든 사용자가 이러한 내용을 읽을 수 있다. 이런 식으로 잠재적으로 민감한 정보가 노출되지 않도록 주의해야 한다. 가능한 통계 데이터만을 제공하거나 민감할 수 있는 실제 정보를 노출해야 하는 경우에는 정확한 정보를 판별할 수 없도록 데이터를 감추어야 한다.

위로

프로브 정의하기

Solaris/OpenSolaris에서는 /usr/include/sys/sdt.h에 있는 매크로를 사용하여 프로브를 정의할 수 있다. 이 매크로를 이용하면 삽입할 인수에 적합한 매크로를 호출하여 코드 내에 프로브를 삽입할 수 있다. 예를 들면, 인수를 사용하지 않고 프로브를 삽입하려면 DTRACE_PROBE("prime","calc-start")를 사용해야 한다.

인수를 공유할 경우에는 프로브를 트리거할 때, 해당 인수 번호를 공유할 수 있도록 1에서 5까지 번호가 지정된 다른 매크로를 사용한다. 예를 들어, 하나의 인수를 공유하려면 DTRACE_PROBE("prime","calc-start",prime)를 사용한다.

이 방법은 Solaris/OpenSolaris에서만 지원된다. Solaris/OpenSolaris, FreeBSD 및 Mac OS X에서 지원되는 휴대용 버전과 코드에 프로브를 삽입할 수 있는 훨씬 쉬운 방법을 제공하는 버전의 경우에는 각 프로브를 통해 공유하고자 하는 인수의 정의와 코드에 삽입할 각 프로브가 포함된 프로브 정의 파일을 작성할 수 있다.

이 정의 파일의 형식은 C와 비슷하다. 하나 이상의 제공자를 지정해야 하며 코드에서 지원할 각 프로브를 각 제공자에서 지정해야 한다. Listing 2에 있는 코드에서 프로브 정의 샘플을 확인할 수 있다.

provider primes {

/* Start of the prime calculation */

   probe primecalc__start(long prime);

/* End of the prime calculation */

   probe primecalc__done(long prime, int isprime);

/* Exposes the size of the table of existing primes */

   probe primecalc__tablesize(long tablesize);

};

프로브가 애플리케이션 내에 설치되면 provider에 제공자의 이름을 사용한다. DTrace 내에서는 다음과 같이 제공자, 모듈, 함수, 프로브 이름으로 프로브를 식별한다. provider:module:function:name. USDT 프로브의 경우에는 이 스펙 중에서 제공자와 이름 부분만을 지정할 수 있다.

프로브 이름은 프로브 키워드 바로 다음에 있는 문자열에서 가져올 수 있다. 이중 밑줄을 사용하여 프로브 이름의 문자를 분리할 수 있다. 추적 과정에서 프로브를 사용할 경우에는 이중 밑줄이 하나의 하이픈으로 변환된다. 예를 들면, 이 파일에 있는 primecalc__start() 프로브 이름은 primes::primecalc-start 이름(제공자와 프로브 이름의 결합)을 사용하여 식별할 수 있다.

정의에 있는 각 프로브의 인수는 C 코드에 있는 인수의 데이터 유형을 식별할 수 있게 도움을 준다. 각 인수는 arg0, arg1, argN 등으로 추적하는 과정에서 사용할 수 있다는 점을 기억해야 한다. 따라서, primecalc__done 프로브의 경우, 소수가 arg0가 되며 숫자가 소수인지 여부는 arg1에서 결정된다.

프로브 정의 파일이 있는 경우에는 다음과 같이 dtrace 명령을 사용하여 프로브 정의를 헤더 파일로 변환한다. $ dtrace -o probes.h -h -s probes.d.

위에 있는 명령은 출력 파일의 이름(-o)을 지정하여 헤더(-h)와 소스 프로브 정의 파일의 이름(-s)을 생성한다.

이렇게 해서 생긴 헤더 파일에는 프로브를 삽입할 코드에 배치할 수 있는 매크로가 포함되어 있다. 코드 내에서 필요한 위치에 원하는 만큼 이 매크로를 사용하여 프로브를 트리거할 수 있다.

프로브 매크로의 형식은 사용자가 정의한 프로브 이름을 따른다. 예를 들면, primecalc__done 매크로는 PRIMES_PRIMECALC_DONE이 된다. 이제까지 프로브 정의 파일(애플리케이션을 빌드하는 과정에서도 사용하게 됨)과 헤더 파일을 살펴보았으므로 이제 C 소스에 프로브를 삽입하도록 하자.

위로

프로브를 삽입할 위치 식별하기

프로브를 삽입할 위치를 설명하기 위해 소수를 판별하는 간단한 프로그램을 살펴본다. 이 코드가 가장 효과적인 방법은 아니지만 DTrace 프로브를 이용하여 문제점을 식별할 수 있다.

원본 소스 코드는 Listing 3에서 확인할 수 있다.

#include <stdio.h>

long primes[1000000] = { 3 };
long primecount = 1;

int main(int argc, char **argv)
{
  long divisor = 0;
  long currentprime = 5;
  long isprime = 1;

  while (currentprime < 1000000)
    {
      isprime = 1;
       for(divisor=0;divisor<primecount;divisor++)
        {
          if (currentprime % primes[divisor] == 0)
            {
              isprime = 0;
            }
        }
      if (isprime)
        {
          primes[primecount++] = currentprime;
          printf("%d is a prime\n",currentprime);
        }
      currentprime = currentprime + 2;
    }
}

DTrace 프로브가 추가된 수정된 코드는 Listing 4에 있다.

#include <stdio.h>
#include "probes.h"

long primes[1000000] = { 3 };
long primecount = 1;

int main(int argc, char **argv)
{
  long divisor = 0;
  long currentprime = 5;
  long isprime = 1;

  while (currentprime < 1000000)
    {
      isprime = 1;
      PRIMES_PRIMECALC_START(currentprime);
      for(divisor=0;divisor<primecount;divisor++)
        {
          if (currentprime % primes[divisor] == 0)
            {
              isprime = 0;
            }
        }
      PRIMES_PRIMECALC_DONE(currentprime,isprime);
      if (isprime)
        {
          primes[primecount++] = currentprime;
          PRIMES_PRIMECALC_TABLESIZE(primecount);
          printf("%d is a prime\n",currentprime);
        }
      currentprime = currentprime + 2;
    }

}

프로브의 위치는 다음과 같이 다양한 요인을 고려하여 결정한다.

• dtrace로 생성한 헤더 파일은 소스 코드에 삽입된다.
• primecalc-start와 primecalc-done 프로브는 계산을 수행하는 기본 루프 바로 바깥쪽에 프로브가 배치된다. 루프의 시작과 끝은 프로브를 삽입할 논리적인 위치로 여겨지기 때문에 이 위치에 프로브를 삽입하고 싶을 것이다. 그러나 앞서 살펴본 바와 같이 특정 기능 영역을 모니터할 이러한 프로브는 모니터할 실제 조작에 근접한 위치에 배치해야 한다. 프로브를 while 루프의 시작과 끝에 배치하면 실제 소수의 계산과는 관련이 없는 조작이 다수 포함되게 된다. 이 애플리케이션에서는 이와 같은 문제로 인해 크게 차이가 생기지 않지만 다른 애플리케이션에서는 이러한 추가적인 단계로 인해 실제로 모니터하고자 하는 조작을 수행하는 데 상당한 시간이 걸릴 수 있다.
• primecalc-tablesize 프로브는 프로브하는 데 걸리는 시간을 모니터할 수 있게 디자인되지 않았지만 사용자는 테이블의 크기를 효과적으로 모니터하기를 원한다. 프로브를 삽입할 가장 좋은 위치는 값이 변경되는 위치와 가장 근접한 곳이다. 값이 시간에 따라 변화하는 상황을 모니터하고 있지 않은 경우에도 사용자는 값이 변경되는 위치를 정확히 추적하여 알고자 한다는 점에서 이 위치가 중요하다고 할 수 있다.
• done 프로브에서 숫자가 소수인지 여부가 판별된다. if문에 이르기까지 판별된 값을 사용하지 않는 경우에도 for 루프가 끝난 바로 다음에야 사용자는 숫자가 소수인지 여부를 실제로 알게 된다. 또한, isprime 변수값을 인수로 사용하면 다른 프로브를 사용하는 대신 이 값을 제공하여 done 프로브를 코드에 삽입할 수 있다. 스크립트 작성과 관련해서는 이 값을 사용하여 소수와 비소수를 찾는데 소요된 시간을 조건부를 사용하여 계산할 수 있다.
• 기타 애플리케이션의 경우에도 동일한 규칙이 적용된다. 사용자는 통계 데이터(반드시 시점이 맞아야 하는 것은 아님)를 제공하는 프로브가 가능한 해당 정보가 변경되는 위치와 근접해 있는지 확인한다. 동일한 프로브를 여러 번 코드에 삽입할 수 있다. 이 경우에는 초기값이 강조될 수 있도록 변수를 초기화하는 부분 바로 다음, 기본 코드 블록의 앞에 PRIMES_PRIMECALC_TABLESIZE 매크로를 삽입할 수 있다.

위로

애플리케이션 컴파일

다른 애플리케이션을 컴파일할 때와 같이 직접 선택한 C 컴파일러를 사용하여 DTrace 애플리케이션을 컴파일할 수 있다. 일반적으로 Mac OS X/FreeBSD에서는 애플리케이션을 간단히 컴파일할 수 있다. 그러나 Solaris/OpenSolaris에서는 오브젝트 파일을 수정하여 DTrace 프로브가 포함된 새로운 오브젝트 파일을 생성해야 한다.

Solaris/OpenSolaris에서는 최종 링크 작업을 하기 전에 오브젝트 파일을 수정해야 하며 애플리케이션에서 사용하려고 하는 프로브를 포함하고 있는 별도로 생성된 오브젝트 파일에서 링크를 해야 한다. 오브젝트 파일을 수정하는 프로세스는 적절한 시점에서 수행된다. 다시 말해서, 사용자가 오브젝트 파일을 지정하면 해당 프로세스에서 파일을 수정하면서 변경사항을 다시 소스 파일에 저장한다. 오브젝트 파일은 이 프로세스가 진행되는 과정에서 생성된다. 일반적인 시퀀스는 다음과 같다.

1. 각 소스 파일을 컴파일하여 오브젝트 파일을 생성한다. 예: $ gcc -c primes.c.
2. 모든 소스 파일을 컴파일한 다음에는 기본 프로그램에 링크할 프로브가 포함된 DTrace 프로브 오브젝트 파일을 작성한다. 예를 들어, 파일이 하나인 경우에는 $ dtrace -G -s probes.d -o probes.o primes.o 명령을 사용하여 이 작업을 수행할 수 있다.
3. 위에 있는 명령은 오브젝트 파일 primes.o와 프로브 정의 probes.d를 읽은 후, 프로브 파일 probes.o를 생성한다. DTrace 프로브가 있는 오브젝트 파일이 다수인 경우에는 명령행에서 추가로 오브젝트 파일을 지정할 수 있다. 예: $ dtrace -G -s probes.d -o probes.o file1.o file2.o file3.o.
4. 모든 오브젝트 파일과 생성된 프로브 오브젝트 파일을 포함하여 애플리케이션을 링크한다. 예: $ gcc -o primes primes.o probes.o.
5. 마지막에 생성된 실행 파일인 primes가 프로브되고 활성화되어 사용할 수 있게 된다.

FreeBSD/Mac OS X에서는 링크를 하기 위해 별도로 프로브 오브젝트 파일을 생성할 필요가 없다. 따라서, 다음과 같이 컴파일 과정이 더 단순해 진다.

1. 각 소스 파일을 컴파일하여 오브젝트 파일을 생성한다. 예: $ gcc -c primes.c.
2. 모든 오브젝트 파일을 포함하여 애플리케이션을 링크한다. 예: $ gcc -o primes primes.o.
3. 이로써 DTrace 프로브를 추가한 애플리케이션을 사용할 수 있게 된다.

이제, 이 프로브를 사용해 보도록 하자.

위로

프로브를 사용할 수 있게 스크립트 작성하기

여기에서는 몇 가지 매우 기본적인 프로브를 매우 간단한 프로그램에 추가했지만 그래도 프로그램을 실행하면 몇 가지 유용한 정보를 얻을 수 있다. 예를 들면, start와 done 프로브를 사용하여 모든 소수와 비소수를 찾는 데 얼마나 오랜 시간이 걸리는지 확인할 수 있다. 비소수에 비하여 소수는 훨씬 더 작게 분포되어 있기 때문에 이러한 두 요소를 찾는데 걸리는 시간에는 중요한 차이가 있다는 것을 알 수 있다. Listing 5에 있는 샘플 스크립트에서 이점을 확인할 수 있다.

#!/usr/sbin/dtrace -s

#pragma D option quiet

primes*:::primecalc-start
{
  self->start = timestamp;
}

primes*:::primecalc-done
/arg1 == 1/
{
        @times["prime"] = sum(timestamp - self->start);
}

primes*:::primecalc-done
/arg1 == 0/
{
        @times["nonprime"] = sum(timestamp - self->start);
}

END
{
        normalize(@times,1000000);
        printa(@times);
}

이 스크립트는 최종 계산값이 소수 또는 비소수인지 여부를 식별하는 조건부를 사용하여 start 프로브에서 done 프로브까지 소요된 시간 데이터를 집계한다. 이 정보는 sum() 총계 함수를 사용하여 집계되어 관련된 배열에 삽입된다.

END 블록에 있는 normalize() 함수는 결과값을 100으로 나누어 소요된 시간을 밀리초로 변환한다. primes 프로그램을 실행하면서 동시에 이 스크립트를 실행하면 Listing 6에 있는 것과 같은 결과를 얻게 된다.

$ dtrace -s timing.d            
^C

  prime                                             10784
  nonprime                                       16340221

이러한 결과를 통해 소수를 찾는 데 걸리는 시간보다 비소수를 찾는 데 걸리는 시간이 더 오래 걸린다는 것을 알 수 있다. 이는 비교적 소수보다는 비소수가 더 많기 때문이다.

위로

고려사항

DTrace 프로브를 삽입할 때는 다양한 문제를 고려해야 하지만 여기에서는 독자가 알고 싶어하는 다음과 같은 몇 가지 알려진 문제를 살펴본다.

• 프로브를 함수의 시작점과 종료점에 배치하지 않는다. FBT 프로브를 사용하면 자동으로 이러한 위치를 액세스할 수 있으므로 DTrace 프로브를 삽입해서 얻을 수 있는 혜택은 함수 이름 대신 프로브 이름을 사용할 수 있다는 점뿐이다. USDT 프로브를 추가하는 경우에는 함수의 경계 대신, 프로브할 조작점에 따라서 프로브를 작성해야 한다.
• DTrace 프로브를 함수의 마지막 명령문에 삽입하지 않는다. 일부 플랫폼에서 컴파일러를 실행하면 코드를 최적화하는 과정에서 최적화된 프로브가 없어지거나(전체적으로 프로브를 효과적으로 제거) 프로브가 호출 함수에 첨부될 수 있으며 이로 인해 인수 데이터가 제거되거나 심각한 타이밍 문제를 일으킬 수 있다.
• 라이브러리를 컴파일하여 링크를 하고 프로브를 사용 가능하게 하고자 하는 경우에는 라이브러리를 작성하기 전에 오브젝트 파일에서 DTrace 프로세스를 실행해야 한다. 또한, Solaris/OpenSolaris에서는 생성된 오브젝트 파일과 원본 오브젝트 파일을 라이브러리에 삽입해야 한다. 그리고 aotomake에서 적용되는 프로세스와 같은 복잡한 빌드 프로세스를 사용하는 경우에는 추가로 주의를 기울여야 한다. automake를 이용하면 오브젝트 파일을 임시 디렉토리에 삽입하여 라이브러리를 생성하는 과정에서 명시적으로 사용할 수 있게 할 수 있다. 라이브러리에 추가되는 오브젝트 파일에서 dtrace 명령이 실행 중인지 확인해야 한다.
• 생성한 프로브 오브젝트 파일과 이 프로브 오브젝트 파일이 기초로 하고 있는 오브젝트 파일은 일치해야 한다. 오브젝트 파일이 변경되면 프로브 오브젝트 파일을 다시 생성해야 한다. 그렇지 않으면 링크 작업이 실패하게 된다.
• autoconf 및 cmake와 같은 명령을 사용하고 크로스 플랫폼 호환성을 유지하기를 원하는 경우에는 dtrace에서 -G 옵션을 사용하여 프로브 오브젝트 파일을 생성하면 된다. 구성 과정에서 이러한 과정을 쉽게 테스트할 수 있다.

위로

요약

DTrace의 함수 기반 추적 기능을 사용해도 다양한 정보를 얻을 수 있지만 유연성을 최대한 확보하려면 자체적으로 정적 프로브를 추가해야 한다. 정적 프로브를 사용하면 프로브의 위치와 이름 및 노출할 정보를 선택할 수 있으며 추출할 데이터와 일치하도록 노출할 정보를 세밀하게 조정할 수 있다.

정적 프로브를 추가하려면 적합한 정의 파일을 작성한 다음, 이 파일에서 생성된 매크로를 C 소스 코드에서 사용해야 한다. 플랫폼에 따라 완료해야 할 하부 단계가 몇 가지 더 있지만 컴파일 과정은 비교적 간단하다. 프로브를 삽입할 위치와 사용할 프로브를 선택하는 방법과 관련된 조언을 기억하면 애플리케이션에 실제로 프로브를 삽입하는 과정으로 인한 작은 오버헤드는 프로브를 통해 얻을 수 있는 혜택에 비하면 일반적으로 아무것도 아니다.

참고자료

교육

• 다수의 시스템 전체에서 동일한 명령을 사용하는 방법을 배우려면 System Administration Toolkit: Standardizing your UNIX command-line tools(Martin Brown, developerWorks, 2006년 5월)를 읽어보도록 하자.
  
  
• bash에서 프로그램하는 방법을 배울 수 있는 시리즈 기사인 Bash by example, Part 1: Fundamental programming in the Bourne again shell(bash)(Daniel Robbins, developerWorks, 2000년 3월), Bash by example, Part 2: More bash programming fundamentals(Daniel Robbins, developerWorks, 2000년 4월) 및 Bash by example, Part 3: Exploring the ebuild system(Daniel Robbins, developerWorks, 2000년 5월)을 확인하자.
  
  
• 시스템 관리 툴킷: 이 시리즈의 다른 파트를 확인하자.
  
  
• Making UNIX and Linux work together(Martin Brown, developerWorks, 2006년 4월): 이 기사에서 기존의 UNIX® 배포판과 Linux를 함께 사용하는 방법을 확인할 수 있다.
  
  
• 시스템마다 다양한 도구를 사용한다. IBM Redbook인 Solaris to Linux Migration: A Guide for System Administrators에서 몇 가지 핵심 도구를 확인할 수 있다.
  
  
• AIX와 UNIX 입문: AIX와 UNIX 입문 페이지에서 자세한 정보를 볼 수 있다.
  
  
• developerWorks AIX 및 UNIX 영역에는 수백 건의 유익한 기사와 초급, 중간급, 고급 사용자를 대상으로 하는 튜토리얼이 있다.
  
  
• developerWorks 팟캐스트에서 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술 얻기

• DVD로 제공되거나 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 차기 오픈 소스 개발 프로젝트를 구현해 보자.
  
  

토론

• Twitter의 developerWorks 페이지를 살펴보자.
  
  
• My developerWorks 커뮤니티에 참여하자.
  
  
• AIX 및 UNIX 포럼에 참여하자.
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • IBM Support Assistant Forum
  • Performance Tools Forum
  • Virtualization Forum
  • 기타 AIX and UNIX Forums
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 프로브 디자인
• 프로브 정의하기
• 프로브를 삽입할 위치 식별하기
• 애플리케이션 컴파일
• 프로브를 사용할 수 있게 스크립트 작성하기
• 고려사항
• 요약
• 참고자료
• 필자소개
• 의견