Grafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合まで

OpenTelemetryで計装したアプリケーションをGrafanaで見るには、OTLPで受け取ったテレメトリをログ・メトリクス・トレースの3系統に振り分け、それぞれLoki・Mimir・Tempoへ書き込む経路を組みます。受け口はGrafana Alloyでも素のOpenTelemetry Collectorでも成立しますが、どちらを選ぶかで設定量と運用の手数が変わる設計です。この記事では、受信層の選び分け、各バックエンドへのexporter設定とラベル変換の癖、Tempoデータソースのtrace to logs設定による相関、セルフホストとGrafana Cloudの費用の分岐点までを、実装する側の判断材料として整理します。数値と版番号は2026年8月時点の公式ドキュメントで確認したものです。

まとめ：受信層の選び方と3バックエンドへの振り分け方針

結論から示します。PrometheusのスクレイプやPromtail相当のログ収集をすでに持っている環境ならGrafana Alloy、OTelの構成ファイルを他バックエンドと共通化したいなら素のOpenTelemetry Collectorを受信層に置く。この基準で決めれば選定は数分で終わります。Alloyは1.18系（2026年8月時点、v1.18.1が2026年8月6日公開）で、OpenTelemetry Collectorのベンダーニュートラルなディストリビューションとして提供されており、OTLP受信とPrometheus系パイプラインを1プロセスに同居させられます。

書き込み先はシグナルごとに固定です。ログはLokiのOTLPエンドポイント、メトリクスはMimirのOTLPエンドポイント、トレースはTempoのOTLP受信ポートへ送ります。事故が起きるのはexporterの選定ではなく、その先のラベル変換のほうでした。Mimirはメトリクス名のドットとハイフンをアンダースコアへ変換し、リソース属性をtarget_infoという別系列へ退避します。Lokiは既定の17個のリソース属性だけをインデックスラベルにし、残りを構造化メタデータへ落とします。ダッシュボードのクエリを書き始める前に、この2点の挙動を手元の環境で確認しておくと手戻りが出ません。

OTLPで送ったテレメトリがLoki・Tempo・Mimirへ振り分けられる経路

Grafanaスタックは1つの製品ではなく、シグナルごとに別のデータベースが立つ構成です。アプリ側が知るべきエンドポイントは1つに保ち、振り分けは受信層に閉じ込めます。

アプリからCollector経由で3系統へ分かれる送信経路の全体像

アプリケーションはOTLPで受信層へ送るだけで、宛先を3つ知る必要はありません。受信層のotelcol.receiver.otlpが4317番のgRPCと4318番のHTTPで待ち受け、otelcol.processor.batchでまとめたうえで、シグナル別のexporterへ渡します。この一段を挟むかどうかが、後からバックエンドを差し替えられるかどうかを決めます。

アプリから直接バックエンドへ送る構成も動きはします。ただしGrafana Cloudの公式ドキュメントは、直接送信の制約として転送障害時の信頼性の低さ、メタデータの付加ができない点、サンプリングやマスキング、複数バックエンドへの振り分けができない点を挙げ、本番ではAlloyを挟む構成を推奨しています。検証環境で直接送信を試したなら、本番移行のタイミングで受信層を入れてください。OTLPやシグナルの前提そのものはOpenTelemetry（OTel）の3つのシグナルとCollectorの役割で整理しています。

Loki・Tempo・Mimirが受け持つシグナルと検索言語の違い

3つのバックエンドは保存する対象もクエリ言語も別物です。1つのダッシュボードに並べて見えるため同じ仕組みに見えますが、書き込み経路の設定は個別に行います。

Grafanaスタックにはプロファイル用のPyroscopeもありますが、OTLPで受けられる3シグナルとは取り込み経路が別系統のため、本記事の対象からは外しています。TraceQLでのトレース検索やTempoの保存構造はGrafana Tempoの仕組みとTraceQLによるトレース検索で、LogQLとラベル設計はGrafana LokiのLogQLとPrometheus連携で詳しく扱っています。

Grafana Alloyと素のOpenTelemetry Collectorの選択基準

受信層の選択は好みの問題ではなく、既存の収集資産をどれだけ引き継ぐかで決まります。両者とも同じOTLPを受け、同じバックエンドへ書けます。

Alloy v1.18系がOTel Collector配布版として担う範囲

Alloyは公式ドキュメント上「OpenTelemetry Collectorのベンダーニュートラルなディストリビューション」と位置づけられ、OTLP受信に加えてPrometheus・Loki・Pyroscopeのネイティブパイプラインを同一プロセスで持ちます。設定はHCLに似た独自の構文で、コンポーネント名がotelcol.receiver.otlp、otelcol.exporter.otlphttp、prometheus.remote_writeのように名前空間で分かれます。

この構造が効くのは、OTelに寄せきれない収集が残っている環境です。Prometheusのスクレイプ設定、ノードのメトリクス、既存のログ収集が動いているなら、それらをAlloyのコンポーネントとしてそのまま持ち込み、OTLP受信と1つのプロセスに統合できます。稼働プロセスが1つ減る効果は、Kubernetes上のDaemonSet運用でそのまま管理コストの差になりました。

素のCollectorを選ぶ条件とAlloyを選ぶ条件の分かれ目

素のOpenTelemetry Collectorを選ぶ理由は3つあります。第一に、GrafanaとDatadogなど複数バックエンドへ同時送信する予定があり、設定資産をベンダー非依存のYAMLで持ちたい場合。第二に、テールベースサンプリングやカスタムプロセッサなど、Contribディストリビューションのコンポーネントに依存する場合。第三に、社内の標準がすでにOTel Collectorで統一されている場合です。

逆にAlloyを選ぶべきなのは、Grafanaスタックを主バックエンドに決めていて、Prometheus由来の収集が残っている環境です。ここで「中立性のために素のCollectorを使う」という判断は見送ってよい。バックエンドを乗り換える具体的な計画がないのに設定を二重に持つと、コンポーネントの版差を追う工数だけが残ります。他社SaaSへ切り替える可能性を本気で残すなら、DatadogへのOpenTelemetry連携で選べる4方式のように、バックエンド側が用意する受け口の制約を先に確認しておくと判断が早まります。

Loki・Mimir・Tempoへのexporter設定とラベル変換の落とし穴

ここからが実装で詰まる箇所です。exporterを繋ぐだけなら30分で終わりますが、ラベルの変換規則を知らないままダッシュボードを作ると、クエリが空を返します。

Lokiへの2経路｜ネイティブOTLPとloki.writeの選び分け

Lokiへログを送る経路は2つあります。1つはotelcol.exporter.otlphttpでネイティブOTLPエンドポイントへ送る方法で、endpointにはotlpまでを指定し、実際の書き込み先はotlp配下のv1/logsになります。もう1つはotelcol.exporter.loki経由でloki.writeへ渡し、loki/api/v1/pushへ書く方法です。

新規に組むならネイティブOTLP側を選んでください。OTelのリソース属性がLokiのインデックスラベルへ直接対応し、変換を挟まずに済みます。既定ではcloud.region、k8s.pod.name、service.nameなど17個のリソース属性がインデックスラベルになり、残りは構造化メタデータへ格納されます。ここで注意すべきなのは、Lokiのラベル数上限が15である点です。公式ドキュメントは「既定の設定は15を超えるリソース属性を選ぶが、いくつかは排他的なので問題ない」と説明していますが、独自のリソース属性を足していくと上限に触れます。なお構造化メタデータはLoki 3.0以降で既定有効ですが、設定ファイル側でallow_structured_metadataがtrueになっていることは確認が必要です。

Mimirの/otlpで起きる文字変換とtarget_infoの扱い

Mimirへのメトリクス送信も、otlphttp exporterでotlp配下のv1/metricsへ送る形が公式の推奨です。ただしMimirはPrometheus互換のデータモデルを持つため、OTelの命名規則がそのままは通りません。メトリクス名やラベル名のドットとハイフンはアンダースコアへ変換され、requests.durationはrequests_durationになります。

もう1つの癖がリソース属性の扱いです。service.namespaceとservice.nameはjobラベル、service.instance.idはinstanceラベルとして全メトリクスに付きますが、それ以外のリソース属性はtarget_infoという別系列へ退避されます。参照するにはジョイントクエリを書くか、Prometheusのinfo関数を使います。「Collectorで付けたリソース属性でフィルタできない」という相談は、この仕様を知らないまま起きることがほとんどでした。加えて、OTelのExponential Histogramは既定では受け付けられず、ネイティブヒストグラムの取り込みを先に有効化する必要があります。計器の型とカーディナリティの設計はOpenTelemetryのメトリクス実装側の論点と合わせて詰めてください。

Tempoへのトレース送信と4317・4318の受信ポート設定

3系統のうち、設定がもっとも素直なのがトレースです。TempoはOTLPをネイティブに受けるため、受信層のexporterからgRPCなら4317番、HTTPなら4318番へ素通しするだけで届きます。属性名の変換もリソース属性の退避も起きません。

Grafana Cloudへ送る場合は、otlp-gatewayから始まるリージョン別のホスト名に対し、otlp配下のv1/traces・v1/metrics・v1/logsへHTTPで送ります。認証はインスタンスIDとトークンによるBasic認証で、環境変数OTEL_EXPORTER_OTLP_ENDPOINTとOTEL_EXPORTER_OTLP_HEADERSに入れる値は管理コンソールから取得する値です。Python環境ではヘッダ値のBasicの後の空白を%20へ置き換える注意書きが公式に出ているため、認証エラーが出たらまずここを疑うと切り分けが早くなります。

trace to logsとexemplarでスパンからログ・指標へ辿る相関設定

3つのバックエンドへ書き込めても、それだけでは画面が3つに分かれたままです。Grafana側でデータソース間のリンクを設定して、はじめて1画面の調査になります。

Tempoデータソースのtrace to logs設定と時刻シフト調整

Tempoデータソースの設定画面には、スパンから他シグナルへリンクする3つのセクションがあります。Trace to logsはLokiなどのログデータソースへ、Trace to metricsはPrometheus系の指標クエリへ、Trace to profilesはPyroscopeのフレームグラフへ飛ばす設定です。

設定で効くのは対応させるタグの指定と時刻シフトです。スパンのservice.nameとLoki側のservice_nameラベルのように、変換後の名前で突き合わせないとリンクが空振りします。前述のとおりMimirとLokiでは変換規則が違うため、Tempo側のタグ指定は実際に書き込まれたラベル名を確認してから入れてください。カスタムクエリでは${__span.name}、${__span.tags}、${__trace.traceId}といった変数が使えるので、トレースIDでの絞り込みが効かない環境ではログ側のクエリを直接書いて回避できます。

trace to metricsとexemplarで指標へ辿る導線の作り方

逆方向、つまり指標のグラフから該当スパンへ飛ぶ導線を作るのがexemplarです。レイテンシのグラフに点が打たれ、そこからTempoのトレースが開きます。障害調査の初動が「グラフの異常を見つけてからトレースを探す」順序である以上、この方向のリンクを先に作ったほうが実務での効き目は大きい。

実装としては、Collector側でexemplarを含むメトリクスを出し、Mimirがそれを受け取り、Grafanaのデータソース設定でトレースIDのラベル名を指定します。ここで詰まるのはたいていラベル名の不一致です。trace_idとtraceIDのどちらで書き込まれているかを、実データを1件見て確認してから設定してください。Trace to metrics側にはスパンの開始・終了時刻をずらすシフト設定があり、非同期処理で指標の粒度が粗い環境では数十秒のシフトを入れないと該当区間が拾えません。

セルフホストとGrafana Cloudの費用と運用工数の分岐点

ここは判断を言い切ります。3シグナル分のデータベースを自前で持つ負荷は、ダッシュボードの見た目からは想像しにくいところにあります。

Grafana Cloud無料枠10kシリーズ・50GBで収まる規模の目安

Grafana Cloudの無料枠は、2026年8月時点でメトリクスが月間10kアクティブシリーズ・保持14日、ログ・トレース・プロファイルが各月間50GB・保持14日、可視化ユーザーが3名です。有料のProは月額19ドルのプラットフォーム料金に加え、メトリクスが1kシリーズあたり6.50ドルから、ログなどは書き込み1GBあたり0.400ドル・保持1GBあたり0.100ドルからという単価で、保持はメトリクス13か月・ログとトレースは30日に伸びます。

目安として、サービス数が10前後、Kubernetesのポッドが数十、ユーザーが3名以内であれば無料枠に収まる可能性が高いといえます。逆に、OTelの既定計装をそのまま入れてHTTPルートごとにラベルを持たせると、10kシリーズは数サービスで超えます。無料枠の判断は「規模が小さいか」ではなく「カーディナリティを制御できているか」で行ってください。

セルフホストが割に合わない条件と、それでも自前で持つべき場面

セルフホストを見送るべき条件は明確です。オブザーバビリティ基盤の専任者を置けない、オブジェクトストレージのライフサイクル設計や圧縮処理の運用経験がない、テレメトリの総量が月間数百GB以下、この3つが揃うならGrafana Cloudを選んだほうが総額で安く済みます。Loki・Mimir・Tempoはいずれもオブジェクトストレージ前提の分散構成で、書き込み系と読み込み系のコンポーネントを別々にスケールさせる必要があり、監視対象より監視基盤のほうが手のかかる状態になりがちです。

それでも自前で持つべきなのは、データを国内やVPC内から出せない要件がある場合、テレメトリ量が大きく従量課金の総額が人件費を上回る場合、そして保持期間を1年以上にしたい場合です。この線引きを曖昧にしたまま「まず自前で」と始めた基盤は、半年後にダッシュボードだけが残ってアラートが機能していない状態になりやすい。運用の担い手を先に決めてから構成を選ぶ順序が現実的です。基盤の運用体制まで含めて外部と分担する選択肢を検討するなら、システムの保守運用・内製化支援で相談範囲を確認してください。

よくある質問

Grafana OpenTelemetry連携の実装で相談の多い論点を5つ挙げます。

Grafana AlloyとOpenTelemetry Collectorはどちらを選ぶべきですか？

Grafanaスタックを主バックエンドに決めていて、Prometheusのスクレイプなど既存の収集設定が残っているならAlloyです。Alloyは1.18系（2026年8月時点）でOTel Collectorのベンダーニュートラルなディストリビューションとして提供され、OTLP受信とPrometheus系パイプラインを1プロセスに同居させられます。複数バックエンドへ同時送信する予定がある、あるいはContribのプロセッサに依存する構成なら素のCollectorを選んでください。両者ともOTLPの受け口と送信先は同じで、後から入れ替えることもできます。

Lokiへログを送るとき、ネイティブOTLPとloki.writeのどちらが良いですか？

新規構築ならネイティブOTLPエンドポイントを選びます。otelcol.exporter.otlphttpのendpointにotlpまでを指定すると、OTelのリソース属性が既定で17個までLokiのインデックスラベルへ対応し、残りは構造化メタデータへ入ります。otelcol.exporter.lokiからloki.writeへ渡す旧来の経路は、既存のLokiラベル設計を維持したい場合に限って残す形が扱いやすいでしょう。なお構造化メタデータを使うには、Loki側の設定でallow_structured_metadataが有効になっている必要があります。

Mimirへ送るとメトリクス名やラベルが変わってしまうのはなぜですか？

MimirがPrometheus互換のデータモデルを採るためです。メトリクス名やラベル名のドットとハイフンはアンダースコアへ変換され、requests.durationはrequests_durationとして保存されます。リソース属性のうちservice.namespaceとservice.nameはjobラベル、service.instance.idはinstanceラベルになり、それ以外はtarget_infoという別系列へ退避されます。ダッシュボードで参照するには、ジョイントクエリかPrometheusのinfo関数で結合してください。

Grafana Cloudの無料枠だけで本番運用できますか？

カーディナリティを制御できていれば可能です。2026年8月時点の無料枠はメトリクス月間10kアクティブシリーズ、ログ・トレース各月間50GB、保持14日、可視化ユーザー3名という範囲で、サービス数10前後・ユーザー3名以内の構成なら収まる余地があります。ただしOTelの既定計装をそのまま入れてHTTPルートやユーザーIDをラベルに持たせると、数サービスで10kシリーズを超えます。まず属性の絞り込み方針を決めてから枠の判断をしてください。

トレースからログへ飛べない場合、どこを疑えばよいですか？

最初に疑うのはタグ名の不一致です。Tempoデータソースのtrace to logsで指定したタグが、Loki側に書き込まれた実際のラベル名と一致していないと空振りします。バックエンドごとに変換規則が違うため、設定画面の値ではなく実データのラベル名を1件確認してください。次に疑うのが時刻範囲で、非同期処理やバッチではスパンの時刻とログの時刻がずれるため、開始・終了のシフト設定を数十秒入れると拾える場合があります。

関連記事

• Amazon Managed Grafanaとは？機能・料金・データソースと始め方：AWSのマネージド版でGrafana本体を運用する場合の料金とデータソース設定を扱っています。
• Grafana 12とは？最新版13との違い・v11からの変更点：可視化側の版差とバージョン確認方法をまとめています。
• OpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計：Mimirへ送る前段の、計器の型と属性の絞り込みを解説しています。
• OpenTelemetryのKubernetes構成｜Operator導入とCollector二層設計：Kubernetes上で受信層を配置する場合の構成パターンを扱っています。
• AWSオブザーバビリティの実装｜ADOT・CloudWatchで計装する構成：AWSマネージドサービス側で3シグナルを受ける場合の比較材料になります。