분산 트레이싱 개요
프로그램 로그는 코드 실행 프로세스의 탐색경로입니다. 이러한 이동 경로를 찾으면 코드에 숨겨진 버그를 찾을 수 있을 뿐만 아니라: Fontawesome-solid-bug: 더 중요한 것은 지속적인 프로그램 로그 추적이 관찰 가능한 프로그램 실행 프로세스를 구축하는 방법을 제공한다는 것입니다.
로그에서 시작하기¶
로그 파일만 있습니다.
추적 시스템이 등장하기 전에는 시스템 작동 상태를 확인할 수 있는 유일한 방법은 로컬 로그를 통해서였습니다. 실제로 추적 시스템 이전에는 로그 서비스가 다양한 제품 유형에 대해 여러 세대에 걸쳐 반복되었습니다.
표준 출력과 표준 오류 출력을 로컬 파일에 배치하고 마법의 운영 체제의 기능을 사용하면 이상적으로는 끝없는 프로그램 실행 로그를 얻을 수 있습니다. 시스템이 충돌하지 않고 단일 오류 지점이 없으며 프로세스가 파일 쓰기 흐름을 방해하지 않는 한 언제든지 프로세스 실행 파일의 복사본을 가져오고 매우 큰 파일에서 관심 있는 이벤트를 검색할 수 있습니다.
트레이싱이 등장하기 전¶
로그 서버
프로그램에 대한 프로그램 로그의 중요성으로 인해 독립적인 로그 서버가 등장했습니다. 예, SPoF에 대해 걱정할 필요가 없습니다. 로그 서버는 프로세스가 보낸 프로그램 로그를 지속적으로 기록하기 위해 고정 포트에서 기다립니다.
로그 서버의 초기 단계에서는 운영 인터페이스가 터미널에서 브라우저로 변경되고 검색할 수 있는 로그가 단일 프로그램에서 여러 프로그램으로 변경된다는 점을 제외하면 파일 서버처럼 작동했습니다. 그러나 기록된 로그는 여전히 프로세스 실행 순서 레코드 더미를 포함하는 동일한 로그입니다. 다음은 로그인 서버의 로그를 시뮬레이션합니다.
classDiagram
class LoginAPI {
name: login server
host: localhost
port: 8080
dscp: print some descriptive information
...
1978-03-12 xx:xx:xx file:api.js line:232 call checkToken()
1978-03-12 xx:xx:xx file:api.js line:178 call parseParameters()
1978-03-12 xx:xx:xx file:api.js line:348 call validate()
1978-03-12 xx:xx:xx file:api.js line:456 call callRedis()
1978-03-12 xx:xx:xx file:api.js line:79 call callMysql()
1978-03-12 xx:xx:xx file:api.js line:914 call writeBack()
}로그 텍스트에서는 격리된 프로그램 이벤트만 볼 수 있으며, 실행 문서에서는 프로그램 실행 상태를 파악하기가 어렵습니다. 파일서버 후반부에는 로그 보기 전용 UI와 일련의 프로그램 실행 환경 상태 매개변수가 등장했다. 이 단계의 로그 서비스는 로그 파일을 기반으로 하는 데이터베이스 서비스와 비슷합니다. 네, 관심 있는 프로그램 이벤트를 더욱 원활하게 검색하실 수 있습니다.
트레이싱 시스템¶
옵저버빌리티의 부상
프로그램 추적 시스템은 고급 로깅 서비스가 아닙니다. 로깅 카테고리에도 속하지 않지만 실제 탐색경로입니다. 추적 시스템은 프로세스 실행 중에 실행 상태 데이터 구조(Span)를 생성합니다. 처리 흐름이 단계별로 진행되면서 실행 순서에 따라 다수의 스팬이 연결되어 현재 프로세스의 트레이스(Tracing)를 형성하게 된다. 여러 프로세스가 호출 순서에 따라 연결되어 현재 시스템의 관찰 가능한 실행 상태를 형성합니다.
가상의 로그인 서비스를 예로 들어보겠습니다.
graph LR
A(UserInterface) -->|input| B{LoginAPI};
B -->|check token| C{RedisServer};
B -->|update database probably| D{MysqlServer};위 그림은 다중 프로세스에서 추적 시스템에 의해 생성된 트레이스 다이어그램만 보여줍니다. 실제로 추적 시스템에서는 각 실행 프로세스의 상태를 로그처럼 볼 수도 있습니다. 원하는 경우 보고된 상태 데이터 구조(span)의 각 필드를 사용자 정의하고 의미를 부여할 수 있습니다. 추적 시스템은 디버깅에 사용되지 않습니다. "물론 추적 시스템에서는 버그가 빠져나갈 수 없습니다." 추적 시스템은 시스템 실행 상태를 자세히 설명하여 시스템 문제를 발견함으로써 버전 반복을 촉진하고 시스템을 지속적으로 개선할 수 있는 긍정적인 피드백 메커니즘을 제공합니다.
추적 시스템은 주로 두 가지 수준의 문제를 해결합니다.
- 상태 데이터를 수집하는 방법
모니터링되는 시스템이 의존하는 기술 스택을 기반으로 시장에서 흔히 볼 수 있는 추적 시스템 솔루션는 완전 자동 데이터 수집 및 수동 데이터 수집 방법을 제공합니다. 시스템 추적은 NodeJS, JAVA, C# 등과 같은 프로그램의 런타임을 모니터링하여 완료됩니다. 이러한 유형의 기술 스택을 기반으로 하는 모든 시스템 구현은 완전 자동 시스템 추적을 수행할 수 있습니다. 동시에 추적 시스템은 모든 기술 스택에 대한 추적 라이브러리를 제공하므로 프로젝트에 종속성을 도입하고 간단한 코드 편집을 수행하여 완전 수동 시스템 추적을 수행할 수 있습니다.
- 상태 데이터를 구성하는 방법
프로그램 실행 중 자연스러운 호출 및 호출된 관계를 통해 시중의 모든 추적 시스템이 상태 데이터 구조 정의를 상위-하위 관계로 연결할 수 있습니다. ParentID 및 ID를 사용하여 호출자와 호출 수신자가 생성한 Span을 연결합니다. 동일한 프로세스(동시 환경의 스레드 포함)의 서로 다른 호출 프로세스는 호출자 ID가 포함된 컨텍스트를 전달하여 상위 프로세스와 하위 프로세스를 연결합니다. 서로 다른 프로세스 사이에서 호출자는 서로 다른 프로세스 간에(프로세스 간 통신할 수 있는 네트워크나 파이프 등을 통해) 자신의 ID가 포함된 컨텍스트를 전송하여 상위 프로세스를 하위 프로세스와 연결합니다.
트레이싱 시스템 솔루션¶
프로그램 성과 모니터링(APM) 시장에서 프로그램을 추적하는 능력은 필수라고 할 수 있다. 다음은 시장에 나와 있는 몇 가지 일반적인 솔루션에 대한 간략한 소개입니다.
: 현재 생산 환경의 프로그램에 대한 모니터링 및 심층적인 시각화 기능을 제공하는 가장 완벽한 APM 솔루션 제공업체입니다. 모든 프로그램 이벤트를 모니터링하기 위해 네트워크 서비스, 메시지 대기열 및 데이터베이스에 대한 기본 성능 모니터링 대시보드를 제공합니다. 추적 트레이스 데이터는 서비스 및 컨테이너 전체에서 세션, 로그, 시스템 프로필, 포괄적인 탐지, 네트워크, 프로세스 및 기본 시스템 메트릭 세트와 원활하게 상호 연관될 수 있습니다. DataDog에서는 시스템 병목 현상으로 인해 발생한 느린 트레이스를 조사할 때 문제를 일으키는 코드를 직접 찾을 수 있습니다.
: Jaeger는 Dapper 및 OpenZipkin에서 영감을 받아 Uber Technologies에서 출시한 오픈 소스 분산 프로그램 추적 시스템입니다. 특히 마이크로서비스 아키텍처 기반 모니터링 시스템에 적합하며 다음과 같은 기능을 제공합니다. : - 분산 컨텍스트 전파 : - 분산 트랜잭션 모니터링 : - 근본 원인을 추적하는 분석 능력 : - 서비스 종속성 분석 : - 성능 최적화 : Jaeger에 관심이 있으시면 Uber 기술팀의 내부 관행를 참고하시면 됩니다.
: OpenTelemetry(OTel)는 트레이스, 메트릭, 로그와 같은 원격 측정 데이터를 생성, 수집 및 내보내기 위한 API, SDK, 사양 및 도구를 제공하는 공급업체 중립적 관찰 프레임워크입니다. OpenTelemetry 자체는 관찰 백엔드가 아니며, 수집된 데이터는 처리 및 저장을 위해 DataKit과 같은 수신 측으로 전송되어야 합니다.
: SkyWalking은 분산 클라우드 시스템에 대한 모니터링, 추적, 진단 및 기타 기능을 제공하는 오픈 소스 APM 시스템입니다. 핵심 역량은 다음과 같습니다. : - 서버 측 메트릭 세트 분석 : - 근본 원인을 추적하는 분석 능력 : - 서비스 토폴로지 분석 : - 서비스 종속성 분석 : - 느린 서비스 검색 : - 성능 최적화 :- 캐시 모니터링, 읽기 및 쓰기 성능, 느린 액세스 검색 : - 데이터베이스 모니터링, 느린 쿼리 검색 : - 메시지 큐 성능 모니터링 : - 브라우저 성능 테스트, 루트 추적 기능 : - 인프라 모니터링은 주류 클라우드 제공업체에 대한 지원을 제공합니다. : - 시스템 알람
: Zipkin은 순차적 데이터를 수집하여 시스템 모니터링을 완료하고 서비스 수준 시스템 문제를 발견하는 데 사용되는 분산 추적 시스템입니다. 집킨은 데이터 수집과 데이터 조회가 포함된 통합 솔루션을 제공합니다. TraceID를 기반으로 Zipkin의 UI에서 로그에서 트레이스로 직접 이동할 수 있으며 다양한 데이터를 기반으로 검색 기능을 제공합니다.
: 위의 추적 시스템과 달리 DataKit에서 제공하는 솔루션은 프로그램 실행 상태 데이터(Span)를 생성하지 않으며 데이터 구성 형태를 변경하지 않습니다. DataKit은 주요 추적 시스템에서 보낸 트레이스 데이터를 수신하기 위해 네트워크 포트에서 수신 대기합니다. DataKit의 추적 모듈은 기본 기능을 제공할 뿐만 아니라 구성이 거의 필요하지 않습니다. 사용자는 다른 추적 시스템에서 원활하게 DataKit으로 전환할 수 있습니다.
: DataKit은 트레이스 데이터 처리 및 분석 네트워크 서비스입니다. 네트워크 애플리케이션으로서 DataKit은 다음과 같은 특징을 가지고 있습니다.
: - DataKit은 부하가 높은 트래픽 데이터를 지속적으로 처리할 수 있습니다. DataKit 내부에 사용된 다중 채널 로컬 캐싱 기술은 실제로 플러딩 수준의 트레이스 데이터에도 불구하고 낮은 CPU 부하에서 양호한 작동을 유지할 수 있습니다. : - DataKit은 동시 네트워크 요청 환경에서 계속 작동할 수 있습니다. DataKit은 내부적으로 액세스 정책과 스레드 풀을 사용하여 동시에 발생하는 네트워크 요청에 대처하고 CPU 부하를 낮은 범위로 제어합니다. : - DataKit은 시장의 다양한 주류 추적 시스템과 마찰 없이 연결할 수 있으며 계속 확장되고 있습니다.
: 분석 및 계산 도구로서 DataKit은 다음과 같은 특징을 가지고 있습니다.
: - 유연성과 구성 가능성이 뛰어나 별도의 구성 없이 DataKit의 트레이스 데이터 기능을 사용할 수 있으며, 샘플링, 희귀 트레이스 선택, 리소스 닫기 등 간단한 구성을 통해 DataKit에서 제공하는 다양한 트레이스 컴퓨팅 기능을 사용자 정의할 수도 있습니다. : - 효율적이고 분산된 일관된 샘플링 알고리즘. : - 데이터 처리 전단의 다양한 데이터 처리 필터는 일상적인 데이터 처리 요구 사항을 충족합니다. : - 데이터 처리 백엔드 Pipeline 지원, Guance에서 제공하는 강력한 Pipeline 스크립트를 사용하여 데이터가 센터로 전송되기 전에 사용자 정의할 수 있습니다.
요약¶
추적 시스템은 시스템 실행 상태에 대한 다차원적이고 심층적인 시각화 기능을 제공하여 시스템 유지 관리 및 개발의 형태를 변경할 뿐만 아니라 개발 및 운영 비용을 크게 절감합니다. 또한 시스템 병목 현상을 발견하고 후속 시스템 버전 반복에 대한 귀중한 단서를 제공하는 다양한 분석 도구를 제공할 수 있습니다.