안녕하세요! 오늘은 OpenTelemetry의 강력한 기능 중 하나인 메트릭 뷰(Metric View)에 대해 깊이 알아보려고 합니다. 혹시 수집된 메트릭 데이터를 백엔드로 보내기 전에 입맛에 맞게 바꾸고 싶다는 생각, 해보신 적 없나요? 바로 그럴 때 사용하는 비밀 무기가 '메트릭 뷰'입니다! 🚀

오픈텔레메트리 메트릭 뷰(Metric Views)란?
가장 간단하게 설명하자면, 메트릭 뷰는 OpenTelemetry SDK의 심장부에서 작동하는 '데이터 맞춤 제작소'라고 할 수 있습니다. 🏭
우리가 애플리케이션에서 열심히 수집한 메트릭 데이터가 최종 목적지(예: Prometheus, Datadog 등)로 떠나기 바로 직전, 이 '메트릭 뷰'라는 관문을 거치게 됩니다. 이 관문에서 우리는 데이터의 형태를 마음대로 바꾸거나, 필터링하거나, 새롭게 재구성할 수 있는 강력한 힘을 얻게 되죠.
즉, 데이터가 익스포터(Exporter)를 통해 외부로 전송되기 전에 메트릭 스트림을 커스터마이징하고 변환하는 핵심 메커니즘입니다.
메트릭 뷰는 메트릭 데이터가 백엔드로 전송되기 전에 가공하고 제어할 수 있는 강력한 기능입니다. 특정 메트릭을 선택하여 다음과 같은 작업을 수행할 수 있습니다.
- 집계(Aggregation) 변경: 기본 집계 방식(예: 합계, 마지막 값)을 히스토그램이나 다른 방식으로 변경할 수 있습니다. 예를 들어, HTTP 요청 지속 시간을 기본 집계 대신 히스토그램으로 수집하여 분포를 파악할 수 있습니다.
- 속성(Attribute) 필터링: 특정 속성 키를 추가하거나 제외하여 저장 공간을 절약하고 분석에 필요한 데이터만 남길 수 있습니다. 예를 들어, http.client_ip와 같이 카디널리티가 높은 속성을 제외하여 비용을 절감할 수 있습니다.
- 이름 변경 및 설명 추가: 메트릭의 이름을 더 명확하게 바꾸거나 설명을 추가하여 가독성을 높일 수 있습니다.
- 측정(Instrument) 선택: 특정 이름, 유형, 단위 등을 가진 측정(Instrument)에만 뷰를 적용할 수 있습니다.
✨ 메트릭 뷰로 할 수 있는 놀라운 작업들
메트릭 뷰를 사용하면 다음과 같이 다채로운 작업들을 수행할 수 있습니다. 하나씩 살펴볼까요?
1. 특정 메트릭의 집계 방식 변경 📊 ➡️ 📈
가장 강력한 기능 중 하나입니다! 예를 들어, 기본적으로 '합계(Sum)'로 집계되던 요청 카운트 메트릭이 있다고 가정해봅시다. 하지만 우리는 단순히 총합이 아니라, 요청들이 얼마나 다양한 시간대에 분포되어 있는지 알고 싶을 수 있습니다. 이때 메트릭 뷰를 사용하면 이 메트릭의 집계 방식을 '히스토그램(Histogram)'으로 손쉽게 변경할 수 있습니다.
- Before: request_count (단순 합계)
- After (with View): request_count (시간대별 분포를 보여주는 히스토그램)
2. 메트릭 이름 변경 🏷️
조직 내에서 사용하는 메트릭 명명 규칙이 있거나, 기존 시스템과의 호환성을 위해 메트릭 이름을 바꿔야 할 때가 있습니다. 메트릭 뷰를 사용하면 코드 레벨에서 생성된 원래의 메트릭 이름을 원하는 이름으로 깔끔하게 변경하여 내보낼 수 있습니다.
- Before: http.server.duration
- After (with View): my_app.request_latency_seconds
3. 불필요한 속성(Attribute) 필터링 🧹
메트릭 데이터에는 다양한 컨텍스트 정보를 담은 '속성(Attribute)'이 함께 수집됩니다. (예: http.method, http.status_code, user.id 등) 하지만 때로는 너무 많은 속성 때문에 데이터의 카디널리티(cardinality)가 폭발적으로 증가하여 비용 문제나 성능 저하를 유발할 수 있습니다. 메트릭 뷰는 이럴 때 구원투수 역할을 합니다! 불필요하다고 판단되는 속성을 선별적으로 제거하여 꼭 필요한 데이터만 남길 수 있습니다.
- Before: metric{user_id="123", client_ip="...", ...}
- After (with View): metric{...} (민감하거나 불필요한 속성 제거)
4. 히스토그램의 버킷(Bucket) 경계 설정 📏
히스토그램은 데이터의 분포를 보여주는 강력한 도구지만, 어떤 기준으로 구간을 나눌지(버킷)가 매우 중요합니다. 우리 서비스의 응답 시간(latency)은 대부분 100ms 미만인데, 히스토그램 버킷이 [1s, 2s, 5s, ...] 와 같이 너무 넓게 설정되어 있다면 유의미한 분석이 어렵겠죠? 메트릭 뷰를 사용하면 히스토그램의 버킷 경계를 우리 서비스에 최적화된 값으로 세밀하게 조정할 수 있습니다.
- Default Buckets: [0, 5, 10, 25, 50, ...]
- Custom Buckets (with View): [0.01, 0.05, 0.1, 0.25, 0.5, 1] (더 세분화된 분석 가능)
💡 왜 메트릭 뷰가 중요한가요?
결론적으로, 메트릭 뷰는 데이터가 우리의 관측 가능성 백엔드로 전송되기 전에 데이터의 형태(Shape), 세분성(Granularity), 그리고 카디널리티(Cardinality)를 완벽하게 제어할 수 있는 힘을 부여합니다.
이를 통해 우리는 다음과 같은 이점을 얻을 수 있습니다.
- 비용 절감 💰: 불필요한 데이터를 필터링하여 전송량과 저장 비용을 줄입니다.
- 성능 향상 ⚡️: 백엔드 시스템의 부하를 줄여 더 빠르고 효율적인 데이터 처리가 가능합니다.
- 분석 효율 증대 🎯: 데이터를 분석 목적에 맞게 가공하여 더 의미 있고 정확한 인사이트를 얻을 수 있습니다.
메트릭 뷰 구성 방법
메트릭 뷰는 일반적으로 MeterProvider를 설정할 때 구성합니다. 대부분의 언어 SDK에서 비슷한 개념을 제공하며, 여기서는 개념적인 흐름과 함께 코드 예시를 통해 설명하겠습니다.
1. 뷰(View) 등록하기
MeterProvider에 하나 이상의 뷰를 등록하여 메트릭 스트림을 제어합니다.
개념적인 절차:
- 측정 선택기(Instrument Selector): 어떤 측정(Instrument)에 뷰를 적용할지 선택합니다. 이름, 유형, 미터 이름 등으로 특정할 수 있습니다.
- 스트림 설정(Stream Configuration): 선택된 측정 데이터 스트림을 어떻게 처리할지 정의합니다. 이름 변경, 설명 추가, 속성 필터링, 집계 방식 변경 등을 설정합니다.
- MeterProvider에 뷰 추가: 생성한 뷰를 MeterProvider에 등록합니다.
2. 주요 구성 요소
측정 선택기 (Instrument Selector)
뷰를 적용할 대상을 선택하는 규칙입니다. 다양한 기준으로 선택할 수 있습니다.
- instrument_name: 측정의 이름 (예: http.server.duration)
- instrument_type: 측정의 유형 (예: Histogram, Counter, Gauge)
- meter_name: 이 측정을 생성한 미터(Meter)의 이름
- meter_version: 미터의 버전
와일드카드(*)를 사용하여 여러 측정에 규칙을 적용할 수도 있습니다. (예: http.*.duration)
스트림 설정 (Stream Configuration)
선택된 메트릭 데이터를 어떻게 가공할지 정의합니다.
- name: 새로운 메트릭 이름
- description: 메트릭에 대한 설명
- aggregation: 집계 방식 정의 (아래 '집계 방식' 참조)
- attribute_keys: 수집할 속성 키의 목록. 이 목록에 없는 키는 제거됩니다.
3. 집계 방식 (Aggregation)
뷰에서 사용할 수 있는 대표적인 집계 방식은 다음과 같습니다.
- SumAggregation: 모든 측정값의 합계를 계산합니다. (Counter의 기본값)
- LastValueAggregation: 가장 마지막으로 측정된 값을 사용합니다. (Gauge의 기본값)
- DropAggregation: 해당 메트릭을 완전히 제거합니다.
- ExplicitBucketHistogramAggregation: 사용자가 직접 정의한 경계값(boundary)을 기준으로 히스토그램을 생성합니다. 이를 통해 값의 분포를 시각화할 수 있습니다.
- 예: [0, 5, 10, 25, 50, 100] 밀리초(ms) 단위로 응답 시간 분포 파악
코드 예시 (Python)
다음은 Python OpenTelemetry SDK에서 http.server.duration 메트릭을 히스토그램으로 집계하고, 불필요한 속성을 제거하는 예시입니다.
from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.view import View, InstrumentSelector
from opentelemetry.sdk.metrics.aggregation import ExplicitBucketHistogramAggregation
from opentelemetry.sdk.resources import Resource
# 1. 뷰(View) 생성
# http.server.duration 메트릭을 선택하여 히스토그램으로 집계 방식을 변경
histogram_view = View(
# 'http.server.duration' 이라는 이름의 측정(Instrument)을 선택
selector=InstrumentSelector(
instrument_name="http.server.duration",
instrument_type=metrics.Histogram
),
# 새로운 이름과 설명 설정
name="http.server.duration.histogram",
description="Duration of inbound HTTP requests in milliseconds",
# 집계 방식을 명시적 버킷 히스토그램으로 변경
# 응답 시간을 0, 10, 50, 100, 500ms 경계로 나누어 집계
aggregation=ExplicitBucketHistogramAggregation(
boundaries=(0, 10, 50, 100, 500)
)
)
# 2. MeterProvider에 뷰 등록
resource = Resource.create({"service.name": "my-service"})
meter_provider = MeterProvider(
resource=resource,
views=[histogram_view] # 생성한 뷰를 등록
)
# 3. MeterProvider를 전역으로 설정
metrics.set_meter_provider(meter_provider)
# 이후 애플리케이션 코드에서 메트릭을 기록하면
# http.server.duration 메트릭은 위에서 정의한 뷰의 규칙에 따라 처리됩니다.
meter = metrics.get_meter("my-app.meter")
histogram = meter.create_histogram(
"http.server.duration",
unit="ms",
description="HTTP server request duration"
)
# ... 애플리케이션 로직 ...
# histogram.record(request_duration_in_ms)
이처럼 메트릭 뷰를 활용하면 애플리케이션 코드 변경 없이도 수집되는 메트릭 데이터의 형식과 내용을 유연하게 제어할 수 있어, 모니터링 시스템의 효율성과 비용을 최적화하는 데 매우 유용합니다.
OpenTelemetry를 사용하고 계신다면, 메트릭 뷰를 적극적으로 활용하여 여러분의 관측 가능성 데이터를 한 단계 업그레이드해 보세요!
'클라우드 > opentelemetry' 카테고리의 다른 글
| 🚀 OpenTelemetry의 숨겨진 호환성 비밀: B3와 Jaeger 전파자 파헤치기 (0) | 2025.10.14 |
|---|---|
| 🚀 내 애플리케이션의 숨은 병목 현상, OpenTelemetry Profiles로 찾아내기! (0) | 2025.10.14 |
| OpenTelemetry Collector의 숨겨진 비밀 🤫: service::telemetry::metrics 완전 정복 (0) | 2025.10.14 |
| 🧭 OpenTelemetry SDK의 심장을 파헤치다: 4가지 핵심 컴포넌트 완벽 가이드 (0) | 2025.10.14 |
| OpenTelemetry Collector, 여러 백엔드로 데이터를 똑똑하게 분산하는 방법 ⚖️ (0) | 2025.10.14 |