OpenTelemetry Sum 메트릭 완벽 정복: 두 가지 핵심 축 📈

안녕하세요! 오늘은 OpenTelemetry(OTel)의 핵심 메트릭 유형 중 하나인 Sum에 대해 깊이 파헤쳐보는 시간을 갖겠습니다. 🕵️‍♂️ 많은 분들이 Sum을 단순히 '합계를 내는 메트릭'이라고 생각하지만, 그 동작 방식을 결정하는 두 가지 중요한 속성이 있다는 사실을 알고 계셨나요?

 

바로 단조성(Monotonicity)과 집계 임시성(Aggregation Temporality)입니다. 이 두 가지 축을 이해해야만 Sum 메트릭을 정확하게 해석하고 활용할 수 있습니다. 자, 그럼 지금부터 이 두 가지 개념을 자세히 알아보겠습니다!

 

 

---

🗺️ 전체 맥락 보기: Sum 메트릭의 두 가지 축

Sum 메트릭의 동작 방식을 결정하는 두 가지 핵심 요소를 먼저 이해하는 것이 중요합니다. 이 둘은 독립적인 개념이 아니라, 서로 조합되어 Sum 메트릭의 최종적인 성격을 정의합니다.

1. 단조성 (Monotonicity): 이 값은 오직 증가만 할 수 있는가, 아니면 증가와 감소 모두 가능한가?
2. 집계 임시성 (Aggregation Temporality): 메트릭을 보고(export)할 때, 전체 누적값을 보낼 것인가, 아니면 최근 변화량만 보낼 것인가?

이 두 가지 질문에 대한 답의 조합이 바로 여러분이 보게 될 Sum 메트릭의 모습입니다.

The image you are requesting does not exist or is no longer available

---

1️⃣ 첫 번째 축: 단조성 (Monotonicity)

단조성은 값의 변화 방향에 대한 규칙입니다.

✅ Monotonic: true (단조 증가)

값이 오직 증가하거나 동일하게 유지되며, 절대 감소하지 않는다는 의미입니다. 마치 자동차의 총주행거리 계기판처럼요. odometer는 뒤로 가지 않죠! 🚗

• 특징: 0 또는 양수 값만 더해집니다.
• 사용 예시:
  • 누적 API 요청 수
  • 서비스가 시작된 후 발생한 총 에러 수
  • 전송된 총 데이터 바이트(bytes)
• 관련 OTel Instrument: Counter

↕️ Monotonic: false (비단조, 증가/감소 가능)

값이 증가할 수도 있고, 감소할 수도 있다는 의미입니다. 마치 방 안에 있는 사람 수처럼, 들어오면 증가하고 나가면 감소하죠. 👨‍👩‍👧‍👦

• 특징: 양수 또는 음수 값이 더해질 수 있습니다.
• 사용 예시:
  • 현재 활성 커넥션 수 (+1 on connect, -1 on disconnect)
  • 메시지 큐에 쌓여있는 항목 수 (+1 on publish, -1 on consume)
  • 사용 중인 메모리 양의 변화
• 관련 OTel Instrument: UpDownCounter

---

2️⃣ 두 번째 축: 집계 임시성 (Aggregation Temporality)

집계 임시성은 수집된 메트릭 값을 어떤 시점 기준으로 보고할지를 결정하는 매우 중요한 속성입니다. 보통 이 설정은 최종 데이터를 내보내는 Exporter 레벨에서 결정됩니다.

🧱 Cumulative (누적)

Cumulative는 이름 그대로 프로세스(애플리케이션)가 시작된 시점부터 현재까지의 전체 누적 합계를 보고하는 방식입니다.

• 특징: 보고 시점마다 값이 초기화되지 않고 계속 쌓입니다. (단, Monotonic: false인 경우 값은 감소할 수도 있습니다.)
• 왜 사용할까?: Prometheus와 같은 모니터링 시스템은 이 방식을 선호합니다. 특정 시간 동안의 변화율(rate)을 계산할 때, 전체 누적값을 기반으로 계산하는 것이 데이터 유실(예: 수집 실패)에 더 강건하기 때문입니다. 만약 변화량만 받았는데 중간에 수집을 한번 놓치면, 그 기간의 데이터는 영원히 알 수 없게 되죠.
• 보고 방식 예시 (누적 요청 수):

// 1분 간격으로 메트릭을 보고한다고 가정
// T=0: 서비스 시작

// T=1분: 100개 요청 발생
export({"http.server.requests": 100})

// T=2분: 추가로 150개 요청 발생
export({"http.server.requests": 250}) // 이전 100 + 새로운 150

// T=3분: 추가로 60개 요청 발생
export({"http.server.requests": 310}) // 이전 250 + 새로운 60

보시다시피, 값은 항상 전체 누적 합계를 나타냅니다.

 

💧 Delta (델타, 변화량)

Delta는 마지막으로 보고한 시점 이후의 변화량(증가분 또는 감소분)만을 보고하는 방식입니다.

• 특징: 한번 보고가 끝나면 내부 집계 값은 다음 보고를 위해 초기화됩니다.
• 왜 사용할까?: StatsD와 같이 "매 순간의 변화"를 중시하는 시스템과 잘 맞습니다. 또한 OTLP(OpenTelemetry Protocol)의 기본값으로, 수집 에이전트나 백엔드에서 데이터를 유연하게 처리할 수 있는 여지를 줍니다.
• 보고 방식 예시 (누적 요청 수):

// 1분 간격으로 메트릭을 보고한다고 가정
// T=0: 서비스 시작

// T=1분: 100개 요청 발생
export({"http.server.requests": 100})

// T=2분: 추가로 150개 요청 발생
export({"http.server.requests": 150}) // 지난 1분 동안의 변화량

// T=3분: 추가로 60개 요청 발생
export({"http.server.requests": 60}) // 그 다음 1분 동안의 변화량

Cumulative와 달리, 각 보고는 독립적인 기간의 값만을 나타냅니다.

---

📊 한눈에 보는 요약

특징	설명	관련 Instrument	주요 사용 예시
Monotonicity	값이 증가만 하는지(true), 혹은 증감 모두 가능한지(false)를 결정합니다.	Counter (true)	http.server.request.count (누적 요청 수)
		UpDownCounter (false)	system.processes.active (활성 프로세스 수)
Aggregation Temporality	프로세스 시작 후 전체 누적값(Cumulative)을 보고할지, 마지막 보고 이후의 변화량(Delta)만 보고할지를 결정합니다.	(Exporter 설정)	Cumulative: Prometheus 선호 Delta: OTLP Exporter 기본값

---

🚀 결론

이제 OpenTelemetry의 Sum 메트릭이 단순한 '합계'가 아니라는 것을 확실히 아셨을 겁니다. Monotonicity를 통해 데이터의 증감 특성을 정의하고, Aggregation Temporality를 통해 그 데이터를 어떻게 보고할지를 결정합니다.

 

이 두 가지 핵심 축을 이해하면, 여러분은 어떤 모니터링 환경에서도 메트릭을 정확하게 설정하고, 대시보드에서 보이는 그래프를 명확하게 해석할 수 있는 강력한 무기를 갖게 된 것입니다. 이제 여러분의 시스템을 더 깊이 있게 관찰해보세요!