こんにちは。オブザーバビリティの世界へようこそ。
「監視」というと、多くの人が「CPU使用率が80%を超えたらアラートを飛ばす」といった静的な設定を想像します。しかし、現代の分散システムにおいて、それは「暗闇で懐中電灯を振り回している」のと同義です。
今日は、OpenTelemetry (OTel) という現代の標準規格と、Prometheus という堅牢なデータストアを融合させ、あなたのシステムに「真の可視性」をもたらすアーキテクチャについて語ります。これをマスターすれば、障害の「予兆」を事前に察知し、トラブルシュートに費やす無駄な時間を激減させることができます。
—
1. なぜ「OpenTelemetry Collector」を挟むのか？
多くの初心者や中級者は、アプリケーションから直接Prometheus形式でメトリクスを出力しようとします。しかし、それは「密結合」の罠です。
- Prometheusの役割: データの「貯蔵庫」であり、「時系列解析のエンジン」。
- OTel Collectorの役割: データの「変換・転送・集約のハブ」。
Collectorを介することで、アプリケーションは「どの監視ツールを使うか」を意識する必要がなくなります。将来、PrometheusからManaged Service（AWS Managed Service for PrometheusやGrafana Cloudなど）へ移行したくなっても、設定ファイルを一行書き換えるだけで済みます。これが「アーキテクチャの疎結合化」という極意です。
—
2. 構築のステップ：OTel CollectorからPrometheusへの流し込み
まずは、最小構成で「Collectorを介してメトリクスを受け取り、Prometheusに渡す」ルートを作りましょう。
ステップA: Collectorの設定 (`otel-config.yaml`)
Collectorには「受信（Receiver）」「処理（Processor）」「送信（Exporter）」の3つのフェーズがあります。
receivers:
otlp:
protocols:
grpc: # アプリからのデータ受信
http:
processors:
batch: # データをまとめて効率的に送信する
exporters:
prometheus:
endpoint: “0.0.0.0:8889” # Prometheusがここをスクレイピングする
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]
ステップB: Prometheusの設定 (`prometheus.yml`)
Prometheusには、Collectorを「単なるターゲットの一つ」として認識させます。
scrape_configs:
- job_name: ‘otel-collector’
scrape_interval: 10s
static_configs:
- targets: [‘localhost:8889’] # Collectorのエクスポート先を指定
—
3. 「HelloWorld」的動作確認：メトリクスを流してみる
複雑なインフラを組む前に、まずは手元のCLIでデータが流れることを確認しましょう。PythonのSDKを使うのが最も直感的です。
pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp
app.py（送信側のコード）:
from opentelemetry.metrics import set_meter_provider
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
Collectorへデータを送る設定
exporter = OTLPMetricExporter(endpoint=”localhost:4317″, insecure=True)
provider = MeterProvider(metric_readers=[PeriodicExportingMetricReader(exporter)])
set_meter_provider(provider)
meter = provider.get_meter(“my-app”)
counter = meter.create_counter(“request_count”, description=”リクエスト回数”)
動作確認：カウンターを回す
counter.add(1, {“endpoint”: “/api/v1/hello”})
このコードを実行し、PrometheusのUI (`http://localhost:9090`) で `request_count` を検索してみてください。データが見えた瞬間が、あなたの監視システムが「次世代」へ進化した瞬間です。
—
4. 現場で震えるほど役立つ「運用の極意」
ただ動かすだけでは、いずれアラート疲れで倒れることになります。以下の3つを心に留めておいてください。
1. カーディナリティ（Cardinality）の爆発を避けろ:
メトリクスのラベル（タグ）に「ユーザーID」や「ユニークなリクエストID」を入れないでください。Prometheusのメモリが瞬時に枯渇します。ラベルは「有限なカテゴリ」に限定しましょう。
2. Collectorでの集約（Aggregation）:
高頻度のメトリクスはCollector側で `sum` や `avg` を計算してからPrometheusに渡しましょう。Prometheusの負荷が劇的に下がります。
3. 「症状」ではなく「兆候」を監視せよ:
CPU使用率よりも「エラー率（Error Rate）」や「レイテンシ（Latency）」を監視すること。ユーザーが不利益を被る前に気づけるかどうかが、プロとアマの境界線です。
—
最後に：次へのステップ
今回の構成が理解できれば、次は「ログ」と「トレース」を統合する「信号の相関（Signal Correlation）」の世界へ踏み出せます。
Prometheusで「エラー率が上がった」と検知し、同じトレースIDを持つログを即座に特定して原因を突き止める。この体験を一度味わうと、二度とログファイルをSSHで覗くような古いやり方には戻れなくなりますよ。
何か詰まったら、いつでも聞いてください。設計の細部からチューニングの極意まで、あなたの監視が「退屈な監視」から「攻めのオブザーバビリティ」に変わるまで伴走します。頑張りましょう！