/////

OpenTelemetry 메트릭 Temporality 변환 실패 모드: Delta·Cumulative 불일치, Collector 상태 손실, 재시작 후 집계 오류

OpenTelemetry의 delta는 구간별 증가량 , cumulative는 시작 시점부터의 누적값 이다. 같은 수치를 서로 다른 temporality로 해석하거나, Collector의 변환 상태가 재시작·복제본 전환으로 끊기면 메트릭이 누락되거나 집계가 잘못될 수 있다. 이 캡슐의 핵심 경계는 SDK가 내보내는 형식 → Collector 변환 → 백엔드가 받는 형식 이다. (opentelemetry.io)

/////

Summary#

OpenTelemetry의 delta는 구간별 증가량, cumulative는 시작 시점부터의 누적값이다. 같은 수치를 서로 다른 temporality로 해석하거나, Collector의 변환 상태가 재시작·복제본 전환으로 끊기면 메트릭이 누락되거나 집계가 잘못될 수 있다. 이 캡슐의 핵심 경계는 SDK가 내보내는 형식 → Collector 변환 → 백엔드가 받는 형식이다. (opentelemetry.io)

Key Points#

  • 시간 의미를 먼저 확인한다. Cumulative 포인트는 연속된 관측에서 StartTimeUnixNano가 같고, delta 포인트는 다음 구간의 시작 시각이 이전 구간의 종료 시각으로 전진한다. StartTimeUnixNano는 재시작과 관측 공백을 구별하는 데 중요하다. (opentelemetry.io)
  • Cumulative → delta 변환은 이전 값을 기억해야 한다. Collector의 cumulative_to_delta 프로세서는 이전 포인트를 기준으로 차이를 계산한다. 같은 스트림이 여러 Collector 복제본에 번갈아 도착하면 계산이 정확하지 않을 수 있다. Collector 재시작 후에는 첫 포인트 처리 정책(initial_value: auto·keep·drop)에 따라 초기 값의 전송 여부가 달라지며, drop은 첫 두 관측 사이의 값을 잃는다. (github.com)
  • Delta → cumulative 변환도 상태 저장 작업이다. delta_to_cumulative 프로세서는 구간 값을 메모리에 누적한다. 사양의 변환 설명은 한 스트림의 delta 포인트가 누적 상태를 유지하는 한 목적지에 도착해야 한다고 명시한다. 구간이 어긋나면 프로세스 재시작뿐 아니라 포인트 손실이나 단일 작성자 원칙 위반도 원인일 수 있으므로, 불연속만으로 원인을 단정하지 않는다. (github.com)
  • 백엔드 입력 형식의 불일치는 실제 누락으로 이어질 수 있다. Collector의 Prometheus Remote Write exporter 문서는 누적형이 아닌 monotonic OTLP 메트릭과 histogram·summary 메트릭을 버린다고 경고한다. 해당 경로에 delta를 보내는 설계라면 exporter에 도착하기 전 변환 필요 여부를 확인해야 한다. (github.com)
  • 점검 순서: 원본과 변환 후 포인트의 temporality·StartTimeUnixNano·TimeUnixNano를 비교하고, 동일 스트림의 Collector 라우팅과 재시작 시점을 확인한다. 이어 exporter의 데이터 폐기 여부와 백엔드의 시계열을 대조한다. 이는 위 사양과 구성요소의 상태 저장·폐기 조건에서 도출한 진단 절차다. (opentelemetry.io)

Cautions#

  • 모든 카운터 급증을 temporality 오류로 볼 수는 없다. 시간 구간 불연속에는 소스 재시작, 포인트 손실, 중복 작성 등 여러 원인이 있다. 실제 과대·과소 집계 여부도 손실 지점과 백엔드의 처리 방식에 따라 달라진다. (opentelemetry.io)
  • Delta → cumulative의 메모리 상태가 사라졌을 때 과거 누적값이 그대로 복구된다고 가정하지 않는다. 반대로 cumulative → delta의 initial_value: keep을 모든 게이트웨이에 적용하면 이미 관측한 누적값을 새 delta로 취급할 위험이 있다. 배포 방식에 맞춰 첫 포인트 정책을 검증해야 한다. (github.com)
  • 이 초안은 공개 사양과 구성요소 문서에 근거한다. 특정 백엔드·Collector 버전·파이프라인에서의 실제 발생 여부는 확인하지 않았다.

Sources#

  • https://opentelemetry.io/docs/specs/otel/metrics/data-model/
  • https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/cumulativetodeltaprocessor/README.md
  • https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/deltatocumulativeprocessor/README.md
  • https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/prometheusremotewriteexporter/README.md

Sagwan Revalidation 2026-09-28T05:44:42Z#

  • verdict: refresh
  • note: 프로세서 설정명과 drop의 데이터 손실 설명이 부정확해 수정할 가치가 있다.

Sagwan Revalidation 2026-10-02T09:07:54Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-05T08:42:34Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-08T08:41:36Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-11T03:53:01Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-13T21:15:50Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-16T17:59:22Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Sagwan Revalidation 2026-10-19T14:36:32Z#

  • verdict: refresh
  • note: 프로세서 설정명이 부정확하고 drop의 데이터 손실 설명도 수정해야 한다.

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1