트레이싱

3. 소프트웨어 트레이싱

소프트웨어 트레이싱은 개발자에게 디버깅을 위한 유용한 정보를 제공하며, 개발 기간뿐만 아니라 배포 후에도 사용된다.^[5] 이벤트 로깅과 다르게, 소프트웨어 트레이싱은 이벤트의 "클래스"와 "이벤트 코드"라는 개념을 갖지 않는다. 이벤트 로깅 방식이 소프트웨어 트레이싱에 적절하지 않은 이유는 다음과 같다.

• 소프트웨어 트레이싱은 저수준이기 때문에 많은 종류의 메시지 형식들이 있으며, 이것들은 코드의 한 부분에만 사용될 수 있다. 이벤트 로깅 파라다임은 이런 "한번만 사용되는" 메시지들로 인한 개발 오버헤드가 발생케 한다.
• 개발 기간 동안 기록된 메시지들의 종류는 종종 이벤트 로깅보다 불안정한 편이다.
• 트레이싱의 결과는 개발자들이 사용하는 것이기 때문에 메시지는 지역화될 필요가 없다. 그러므로 트레이싱 메시지를 다른 지역화가 필요한 자원들과 분리하는 것은 중요하다.
• 한번도 보지 못한 메시지들도 있다.
• 트레이싱 메시지들은 코드 안에 있어야 한다. 왜냐하면 이것들은 코드의 신뢰도를 높일 수 있기 때문이다. 이것은 이벤트 로깅 해결책에서는 가능하지 않을 수 있다.

• 사유 소프트웨어에서, 트레이싱 데이터는 소스 코드에 대한 민감한 정보를 가질 수 있다.
• 만약 트레이싱이 실행 중에 활성화 되거나 비활성화 된다면, 트레이싱의 많은 방식들이 많은 양의 추가적인 데이터를 바이너리에 포함될 것을 필요로 하며, 이것은 성능을 감소시킨다.
• 만약 트레이싱이 컴파일 타임에 활성화되거나 비활성화 된다면, 고객 머신의 문제에 대한 트레이스 데이터를 얻는 것은 고객이 특별한 버전의 소프트웨어를 설치할 수 있는가에 달려있으며, 이후에 문제를 복사할 수 있다.

4. 이벤트 로깅 대 트레이싱

이벤트 로깅과 소프트웨어 트레이싱은 동일한 기술을 사용하기 때문에 명확하게 구분하기 어렵다. 다음 표는 중요하지만 절대적이지 않은 구분을 보여준다.

이벤트 로깅은 시스템 관리자에게 진단 및 감사에 유용한 정보를 제공한다. 서로 다른 이벤트 클래스와 이벤트 메시지에 나타날 세부 사항은 종종 개발 주기 초기에 고려된다. 많은 이벤트 로깅 기술은 각 이벤트 클래스에 고유한 "코드"를 할당하도록 허용하거나 요구한다. 이 코드는 이벤트 로깅 소프트웨어 또는 별도의 뷰어(예: 이벤트 뷰어)에서 사람이 읽을 수 있는 메시지를 형식화하고 출력하는 데 사용된다. 이는 지역화를 용이하게 하고 시스템 관리자가 발생하는 문제에 대한 정보를 더 쉽게 얻을 수 있도록 한다.

이벤트 로깅은 높은 수준의 정보(종종 실패 정보)를 기록하는 데 사용되므로 로깅 구현의 성능은 종종 덜 중요하다.

이벤트가 "너무 자주" 기록되는 것을 방지하는 특별한 문제는 이벤트 스로틀링을 통해 처리된다.

이벤트 로깅과 소프트웨어 추적을 명확하게 구분하는 데 어려움이 있는 이유는 동일한 기술이 두 가지 모두에 사용된다는 사실과, 두 가지를 구분하는 많은 기준이 이산적이라기보다는 연속적이기 때문이다.

5. 기술 및 기법

소프트웨어 트레이싱에는 트레이싱 매크로나 디버거에 출력하는 방법, 관점 지향 프로그래밍과 관련된 계측 기법을 사용하는 방법 등이 있다.^[7] Windows software trace preprocessor (WPP)를 이용하거나, ftrace를 통해 리눅스 커널 트레이싱을 할 수도 있다. Kernel Markers와 LTTng을 통해 리눅스 시스템 레벨 및 사용자 레벨 트레이싱도 가능하다.

이벤트 로깅에는 syslog, 마이크로소프트 윈도우를 위한 [http://msdn2.microsoft.com/en-us/library/aa363652.aspx Event Logging APIs], [http://msdn2.microsoft.com/en-us/library/aa385780.aspx Windows Event Log] (윈도우 비스타) 등이 있다.

[http://logging.apache.org/ Apache logging], [http://msdn.microsoft.com/en-us/library/bb968803(VS.85).aspx Event Tracing for Windows], [http://www.codeproject.com/Tips/1026577/Code-Tracing .][http://www.codeproject.com/Tips/1026577/Code-Tracing Net Tracing API], [http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/package-summary.html Java logging APIs], [http://msdn2.microsoft.com/en-us/library/microsoft.visualbasic.logging.aspx Visual Basic logging] (Visual Basic .NET) 등은 소프트웨어 트레이싱과 이벤트 로깅 모두에 사용 가능하다. Logcheck는 로그 관리를 위한 자유 오픈 소스 유틸리티이다. [http://www.x-trace.net X-Trace] 는 연구 프로젝트이다. Instruction set simulation, [https://web.archive.org/web/20140815063124/http://easylogging.org/ C++ Logging] (크로스 플랫폼 C++ 애플리케이션용) 등도 있다.

소스 코드에서 사용되는 라이브러리는 데이터를 에이전트 또는 수집 구성 요소로 직접 전송한다.^[4] 메서드 호출의 추적은 소스 코드 계측, 런타임 정보 수집 또는 디버거 제어 하에서 수행할 수 있다.^[7]

6. 한계 및 과제

런타임 중에 추적을 활성화하거나 비활성화하려면 바이너리에 추가 데이터가 포함되어야 하는 경우가 많다. 이는 추적이 활성화되지 않은 경우에도 성능 저하로 이어질 수 있다.

컴파일 시간에 추적을 활성화 또는 비활성화하는 경우, 클라이언트 시스템에서 추적 데이터를 수집하려면 클라이언트가 추적이 특별히 활성화된 소프트웨어 버전을 설치하고 그 문제를 재현할 의지와 능력이 있어야 한다.

소프트웨어 추적은 일반적으로 추적 출력의 정확성과 신뢰성뿐만 아니라 추적되는 프로세스가 중단되지 않도록 보장하는 데 있어서 높은 수준의 강건성을 요구한다.

낮은 수준의 특성으로 인해 추적은 많은 양의 메시지를 생성할 수 있다. 성능 문제를 완화하기 위해 컴파일 시점이나 런타임 중에 소프트웨어 추적을 비활성화하는 옵션이 있어야 하는 경우가 많다. 독점 소프트웨어에서 트레이싱 데이터는 제품의 소스 코드에 대한 민감한 정보를 포함할 수 있다.

7. 도구

OpenTelemetry는 분산 추적을 포괄적으로 지원하는 CNCF 오픈 소스 프로젝트이다.^[3] Datadog, New Relic, Splunk를 포함한 일부 벤더는 추적 SaaS 서비스도 제공한다.^[4]

구글(Google)과 메타(Meta Platforms)는 자체 추적 프레임워크인 Dapper와 Canopy를 개발했다.^[2]

• GNU 디버거(GNU Debugger)의 trace 명령어를 사용한 트레이싱^[5]
• cwrap을 사용한 리눅스 C/C++ 애플리케이션 트레이싱
• UST를 사용한 리눅스 애플리케이션 트레이싱 - LTTng과 동일한 프로젝트의 일부
• 윈도우 소프트웨어 트레이스 전처리(WPP)
• 명령어 집합 시뮬레이션

8. 트레이스 분석

ISVis는 실행 트리를 모델링하기 위해 루트 트리를 유향 비순환 그래프로 변환하며, Jinsight는 호출 프레임 원리를 활용하여 추적에 대한 누적 정보를 수집하고 표현한다.^[7]

주요 시각화 방법은 재거(Jaeger)와 같은 도구에서 사용되는 스윔레인(swimlane) 뷰이며, 주석과 키-값 속성을 포함하는 경우가 많다. 널리 사용됨에도 불구하고 이 설계는 엄격한 정당성이 부족하며, 사용자는 기능 누락 및 혼란스러운 탐색과 같은 문제에 자주 직면한다. 스윔레인 뷰의 대안으로는 재거의 서비스 종속성 뷰 또는 스카이워킹(SkyWalking)의 목록, 트리 및 테이블 뷰가 있다. 집계 시각화는 대량의 추적을 분석하는 데에도 사용되며, 카노피(Canopy)와 같은 시스템은 쿼리 가능한 메트릭을 제공하고 재거는 추적 비교 기능을 제공한다.^[8]

참조

_[1] 웹사이트 The Tracing Book http://ltt.polymtl.c[...]
_[2] 논문 Enjoy your observability: an industrial survey of microservice tracing and analysis 2022
_[3] 웹사이트 Council Post: Distributed Tracing: The Key To Microservices Observability https://www.forbes.c[...] 2024-01-12
_[4] 논문 Open tracing tools: Overview and critical comparison https://www.scienced[...] Elsevier BV
_[5] 웹사이트 Tracepoints (Debugging with GDB) https://sourceware.o[...] 2022-06-24
_[6] 서적 Trace Recording for Embedded Systems: Lessons Learned from Five Industrial Projects https://link.springe[...] Springer Berlin Heidelberg 2010
_[7] 간행물 On the Practical Feasibility of Software Monitoring: a Framework for Low-Impact Execution Tracing https://dl.acm.org/d[...] IEEE 2019
_[8] 웹사이트 A Qualitative Interview Study of Distributed Tracing Visualisation: A Characterisation of Challenges and Opportunities https://ieeexplore.i[...] 2024-01-12