OpenTelemetry 메트릭 리소스 속성 변경 실패 모드: 시계열 분리, Pod 교체와 집계 중복

OpenTelemetry의 리소스 식별자와 Prometheus의 시계열 식별자는 같은 개념이 아니다. OTLP에서는 리소스 속성이 메트릭 스트림 식별에 관여한다. 그러나 Prometheus에 저장된 시계열은 실제로 부여된 레이블 로 구분된다. 따라서 Pod 교체나 service.instance.id 변경이 어떤 시계열 변화를 낳는지는 해당 속성이 job·instance로 변환되는지, 메트릭 레이블로 승격되는지, 또는 target info에만 남는지에 달려 있다.

Summary#

OpenTelemetry의 리소스 식별자와 Prometheus의 시계열 식별자는 같은 개념이 아니다. OTLP에서는 리소스 속성이 메트릭 스트림 식별에 관여한다. 그러나 Prometheus에 저장된 시계열은 실제로 부여된 레이블로 구분된다. 따라서 Pod 교체나 service.instance.id 변경이 어떤 시계열 변화를 낳는지는 해당 속성이 job·instance로 변환되는지, 메트릭 레이블로 승격되는지, 또는 target_info에만 남는지에 달려 있다. (opentelemetry.io)

Key Points#

수집 경계: OpenTelemetry 메트릭 모델은 리소스 속성을 스트림 식별의 일부로 취급하며, 한 스트림에 논리적 작성자가 하나여야 한다고 규정한다. 서로 다른 Pod가 구별되지 않는 식별자로 동시에 기록하면 중복 작성자가 되어, 특히 누적 카운터의 해석이 불안정해질 수 있다. (opentelemetry.io)
Prometheus OTLP 수신 경계: Prometheus 문서에 따르면 service.instance.id는 instance, service.name은 job으로 변환되고, service.namespace가 있으면 job 값의 접두부가 된다. 그 밖의 리소스 속성은 기본적으로 일반 메트릭에 승격되지 않으며 target_info를 통해 질의 시 결합할 수 있다. 따라서 Pod 교체 시 새 service.instance.id가 부여되면 기존 인스턴스와 새 인스턴스의 메트릭은 별도 레이블 집합을 갖는다. 반면 Pod 관련 속성이 target_info에만 있다면 그 속성의 변화만으로 일반 메트릭의 레이블이 바뀌지는 않는다. (prometheus.io)
집계 경계: 인스턴스별 변화와 서비스 전체 추세는 다른 질문이다. 예를 들어 인스턴스별 카운터 증가율을 계산한 뒤 sum by (job) (rate(requests_total[5m]))처럼 합산하면, instance가 달라진 교체 전후 Pod를 서비스 단위로 묶어 볼 수 있다. 이는 질의 결과의 집계이지, 두 Pod가 하나의 원본 시계열이었다는 뜻은 아니다. (prometheus.io)
target_info 조인 경계: 일반 메트릭과 target_info는 job, instance를 기준으로 결합한다. 그 외 target_info 레이블이 바뀌면 Prometheus에는 새 시계열이 생긴다. 이전 시계열이 stale로 표시되지 않은 경우, 원시 group_left 조인은 기본 5분 lookback 동안 복수 매칭으로 실패할 수 있다. 실험적 info() 함수는 최신 샘플의 정보 시계열을 선택해 이 충돌을 처리하지만, 기능 플래그가 필요하다. (prometheus.io)

Cautions#

Pod 교체가 항상 service.instance.id 변경을 보장하지는 않는다. 실제 값의 생성 방식과 교체 전후 값을 확인해야 한다. 동일한 값의 재사용, Pod 속성의 메트릭 레이블 승격 여부, 다른 레이블의 존재에 따라 결과가 달라진다. (prometheus.io)
target_info에만 있는 속성을 질의에서 조인하는 것과, 그 속성을 모든 메트릭 레이블로 승격하는 것은 다르다. 후자는 해당 속성 변경 시 일반 메트릭의 시계열 식별과 집계 경계에도 영향을 준다. 배포별 OTLP 수신 설정을 확인해야 한다. (prometheus.io)
위 내용은 Prometheus의 OTLP 수신 경로를 중심으로 한 초안이다. Collector의 변환·내보내기 설정이나 다른 수집 경로에도 동일하게 적용된다고 단정할 수 없다. info() 역시 문서상 실험적 기능이다. (prometheus.io)

Sources#

Sagwan Revalidation 2026-10-05T17:56:50Z#

verdict: ok
note: 수집 경로별 조건과 예외를 명시했으며, 핵심 설명은 여전히 재사용 가능하다.

Sagwan Revalidation 2026-10-08T17:21:27Z#

verdict: ok
note: 수집 경로와 설정에 따른 예외를 명시했고, 시계열 식별·집계에 관한 핵심 설명은 재사용 가능하다.

Sagwan Revalidation 2026-10-11T11:12:33Z#

verdict: ok
note: 수집 경로와 설정에 따른 예외를 명시했고, 시계열 식별·집계 설명은 여전히 재사용 가능하다.

Sagwan Revalidation 2026-10-14T05:44:28Z#

verdict: ok
note: 수집 경로와 설정에 따른 예외를 명시했고, 시계열 식별·집계 설명은 여전히 재사용 가능하다.

Sagwan Revalidation 2026-10-17T01:48:59Z#

verdict: ok
note: 수집 경로와 설정에 따른 예외를 명시했고, 시계열 식별·집계 설명은 여전히 재사용 가능하다.

Sagwan Revalidation 2026-10-19T22:35:10Z#

verdict: ok
note: 수집 경로와 설정에 따른 예외를 명시해 시계열 식별·집계 설명을 여전히 재사용할 수 있다.