OpenTelemetry와 함께 Telemetry 사용
Telemetry 및 OpenTelemetry는 옵저버빌리티 시스템의 서로 관련되어 있지만 서로 다른 부분을 해결합니다. OpenTelemetry는 공급업체 중립적인 API, SDK, 의미 체계 규칙 및 추적, 지표 및 로그를 위한 수집기를 제공합니다. Telemetry는 특별히 구축된 JSON 애플리케이션 결과, 유형이 지정된 테이블, DataFusion SQL, 대시보드 및 알림에 대한 관리 경로를 제공합니다.
Telemetry는 현재 OTLP 수집 엔드포인트를 제공하지 않으며 OpenTelemetry 수집기 백엔드로 설명되어서는 안 됩니다. 추적, 메트릭 및 로그를 위해 OTLP 호환 옵저버빌리티 백엔드와 함께 OpenTelemetry 수집기를 사용하세요. 애플리케이션이 SQL의 혜택을 받는 비즈니스 또는 운영 결과에 도달하면 별도의 Telemetry 이벤트를 발생시킵니다.
각 신호에 하나의 작업을 제공합니다.
| 신호 | 최고의 시작 질문 |
|---|---|
| 미터법 | 집계 서비스 또는 인프라 상태가 변경됩니까? |
| 추적 | 이 분산 요청에서 시간은 어디로 갔습니까? |
| 진단 로그 | 이 코드 경로를 설명하는 로컬 세부 정보는 무엇입니까? |
| Telemetry 이벤트 | 어떤 완료된 결과가 사용자, 계정, 워크플로 또는 비용 센터에 영향을 미쳤습니까? |
결제 추적은 데이터베이스 및 공급자 범위를 표시할 수 있습니다. checkout_completed 이벤트는 수익에 영향을 미치는 SQL에 필요한 터미널 상태, 안전 계정 ID, 계획, 금액 범주, 재시도 횟수, 릴리스 및 대기 시간을 보유할 수 있습니다. 어느 쪽도 다른 쪽을 복제할 필요가 없습니다.
승인된 식별자와 연관
애플리케이션 결과 경계에서 활성 OpenTelemetry 범위 컨텍스트를 읽습니다.
import { trace } from "@opentelemetry/api";
const spanContext = trace.getActiveSpan()?.spanContext();
await telemetry.log("checkout_completed", {
checkout_id: checkoutId,
status: "success",
latency_ms: 684,
trace_id: spanContext?.traceId,
span_id: spanContext?.spanId,
checkout_version: "v2",
release: process.env.APP_RELEASE,
});
추적 및 범위 ID를 차트 차원이 아닌 조회 필드로 처리합니다. 사고 워크플로우의 일부로 시스템 간 상관 관계를 만들기 전에 추적 시스템과 Telemetry에 호환 가능한 액세스 및 보존 경계가 있는지 확인하십시오.
범위 이벤트, 리소스 속성, 수하물, 프롬프트, 요청 본문 또는 스택 추적을 도매로 복사하지 마십시오. 허용 목록을 사용하세요. 특히 OpenTelemetry 수하물은 서비스 경계를 넘어 전파될 수 있으므로 분석에 안전하다고 가정해서는 안 됩니다.
파이프라인을 독립적으로 운영
OpenTelemetry 수집기는 지원되는 신호를 일괄 처리, 재시도, 필터링 및 내보낼 수 있습니다. Telemetry SDK 또는 Log API에는 자체 전달 동작이 있습니다. 두 파이프라인을 모두 모니터링하고 실패 모드 결합을 방지합니다.
- 실패한 결과 이벤트 전달은 성공적인 요청을 종료해서는 안 됩니다.
- 실패한 추적 내보내기는 재귀 이벤트 로깅을 트리거해서는 안 됩니다.
- 중요한 감사 또는 청구 결과는 명시적으로 지속 가능한 애플리케이션 경로를 사용해야 합니다.
- 샘플링 결정은 신호별로 이루어져야 합니다.
- 배포 검증에서는 상관관계와 독립적인 가용성을 모두 확인해야 합니다.
OpenTelemetry 로깅 사양은 추적 및 로그 컨텍스트 간의 상관 관계를 설명합니다. OpenTelemetry 통합 가이드, 로그, 지표, 추적 및 이벤트 및 표준 와이드 이벤트를 사용하여 신뢰할 수 있는 가장 작은 신호 세트를 선택하세요.