こんにちは!今日は、OpenTelemetryの強力な機能の一つであるメトリックビューについて深く掘り下げていきたいと思います。収集されたメトリックデータをバックエンドに送信する前に、好みに合わせて変更したいと思ったことはありませんか?まさにそんな時に使う秘密兵器が「メトリックビュー」です!🚀

###
OpenTelemetry メトリックビューとは?
最も簡単に説明すると、メトリックビューは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に1つ以上のビューを登録して、メトリックストリームを制御します。
概念的な手順:
- 測定選択器(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を使用している場合は、メトリックビューを積極的に活用して、可観測性データを次のレベルにアップグレードしてみてください!
コメントを残す