로그, 메트릭, 추적 및 구조화된 이벤트

옵저버빌리티 신호는 중복되지만 서로 바꿔 사용할 수는 없습니다. 질문에 답하는 가장 작은 신호를 선택하면 계측을 이해하기 쉽게 유지하고 비용을 통제할 수 있습니다.

각 신호의 장점

텍스트 로그는 특정 프로세스 및 시간에 대한 자세한 진단 컨텍스트를 보존합니다. 예외, 비정상적인 분기 및 사람이 읽을 수 있는 수명 주기 메시지에 유용합니다.

메트릭은 시간 경과에 따른 수치 측정을 요약합니다. 카운터, 게이지 및 히스토그램은 서비스 전체 속도, 포화도 및 대기 시간 추세에 효율적이지만 의도적으로 행 수준 컨텍스트를 삭제합니다.

추적 연결은 요청 경로 전체에 걸쳐 있습니다. 이는 어떤 서비스 또는 종속성이 시간을 소비했는지 보여주며 하나의 작업이 여러 시스템에 걸쳐 있을 때 유용합니다.

구조화된 이벤트는 완료된 비즈니스 또는 애플리케이션 사실을 쿼리 가능한 행으로 설명합니다. SQL이 계정, 기능, 모델, 경로 또는 릴리스별로 그룹화되어야 하는 작업 결과, 웹훅 전달, LLM 요청, 활성화 이정표 및 고객에게 영향을 미치는 오류에 적합합니다.

수사부터 시작하라

"서비스가 비정상인가요?"에 대해서는 메트릭과 알림만으로 충분할 수 있습니다. "이 요청은 어디에서 시간을 보냈습니까?"에 대해서는 추적을 사용하십시오. "이 프로세스에서 정확히 무엇이 실패했나요?"에 대해서는 로그를 검사하세요. “출시 후 동기화에 실패한 계정은 무엇입니까?”에 대해 구조화된 이벤트를 쿼리합니다.

모든 속성을 모든 곳에 복사하지 않고도 신호를 연결할 수 있습니다. 구조화된 이벤트 및 진단 로그에 안전한 request_id 또는 trace_id를 넣으세요. 메트릭에서 카디널리티가 낮은 서비스 상태를 유지하세요. 추적에 범위별 타이밍을 저장합니다. 이는 각 시스템의 목적을 유지하면서 시스템 간에 경로를 생성합니다.

Telemetry가 적합한 곳

Telemetry는 구조화된 이벤트 테이블과 SQL을 중심으로 설계되었습니다. 인프라 메트릭이나 분산 추적을 대체하는 것이 아니라 보완합니다. 워크플로에 유용한 결과가 있는 경계에서 이벤트를 내보낸 다음 해당 테이블에서 비율, 백분위수, 집단 및 최근 사례를 쿼리합니다.

예를 들어 추적을 통해 한 번의 결제에 4초가 소요된 이유를 설명할 수 있습니다. checkout_completed 이벤트는 v2 버전으로 인해 모든 고객의 p95 대기 시간이 증가했는지 또는 결제 실패가 발생했는지 여부를 표시할 수 있습니다.

식별자를 추가하기 전에 카디널리티가 높은 필드 및 상관 ID를 검토하세요. 구현 패턴은 구조화된 로깅 가이드부터 시작하세요.