シグナルを伝達する道: OpenTelemetryとGrafana Alloy

前回の記事では、セキュリティインシデントの範囲と原因を同時に把握するためには、ログ・トレース・メトリックを連携させる必要があると説明しました。では、アプリケーションが生成するこれら3つのシグナルは、どのような経路をたどって観測バックエンドまで移動するのでしょうか？このとき、よく一緒に登場するのがOpenTelemetryとGrafana Alloyです。

OpenTelemetry、略してOTelは、観測シグナルを作成し、表現し、伝達するためのベンダーニュートラルな仕様とツールエコシステムです。Grafana Alloyは、そのエコシステムにおけるCollectorディストリビューションであり、様々な場所から入ってくるシグナルを受け取り、処理した後に目的地へ送る実行プログラムです。一言で言えば、OpenTelemetryが共通の輸送ルールであるならば、Alloyはそのルールを理解する乗り換えセンターです。

この記事では、アプリケーションからOTLPでシグナルを送信し、Podmanで実行したAlloyがそれを受信・加工・伝達する最小限の実習を行います。実習ではローカルのデバッグ出力のみを確認し、最後には運用環境で必ず補完すべきセキュリティと障害対応のポイントも指摘します。製品の動作と例は、2026年9月3日時点の公式ドキュメントを基準に確認しました。

アプリケーションの3つの観測シグナルが中央収集パイプラインを経由して複数の分析ストレージに転送される様子

OpenTelemetryとAlloyは同じものではない

OpenTelemetryは単一のサーバー製品ではありません。APIとSDK、自動計測、データモデル、Semantic Conventions、OTLP（OpenTelemetry Protocol）、Collectorといった複数の要素をまとめたプロジェクトです。アプリケーションSDKはSpan・Metric・Log Recordを作成し、Resource属性でどのサービスと環境から発生したかを説明し、Trace Contextでサービス間のリクエスト関係を繋ぎます。

OpenTelemetry Collectorは、これらのシグナルを受け取るReceiver、変換・フィルタリングするProcessor、外部へ送信するExporterをパイプラインで接続するベンダーニュートラルなプロキシです。保存と検索はCollectorの主な任務ではありません。実際の保管と検索は、Tempo・Mimir・Loki、Jaeger・Prometheus、またはOTLPを受け入れる商用サービスのようなBackendが担当します。

Grafana Alloyは、公式説明によるとOpenTelemetry Collectorのディストリビューションであり、PrometheusパイプラインやLoki・PyroscopeなどGrafanaエコシステムとの連携機能も提供するオープンソースのテレメトリーCollectorです。Grafana製品の名前がついていますが、互換性のある他のBackendにも送信できます。逆に、OTelを使用するからといってAlloyが必須というわけでもありません。upstream Collectorや他のディストリビューションを選択することも可能です。


区分	OpenTelemetry	Grafana Alloy	観測Backend

—	—	—	—
正体	仕様・API・SDK・プロトコル・Collectorエコシステム	OTel Collectorベースの実行可能なディストリビューション	保存・検索・可視化システム
主要な役割	シグナル生成方法とデータ表現・転送を標準化	受信、変換、フィルタ、バッチ、ルーティング、エクスポート	長期保存、クエリ、ダッシュボード、アラート
必ず一緒に使うべきか	Alloy以外のCollectorも選択可能	OTel以外のPrometheus・Loki系コンポーネントもサポート	要件に応じて交換可能
記憶すべき境界	OTelは単一のストレージではない	Alloyは分析画面や権限台帳ではない	Backendが計測コードを代替するわけではない

シグナル1つが移動する全体の経路

例えば、決済APIが1つのリクエストを処理するとします。OTel SDKは「checkout-api」というResourceとTraceIdを含むSpanを作成します。ExporterはこれをOTLP/gRPCまたはOTLP/HTTPでAlloyに送信します。AlloyのOTLP Receiverがそれを受け取り、Memory Limiterが過度なメモリ使用を制御し、Batch Processorが複数のレコードをまとめて送信回数を減らします。最後に、Exporterが選択されたBackendに転送します。

애플리케이션 계측
  → OTLP/gRPC 또는 OTLP/HTTP
  → Alloy OTLP Receiver
  → Memory Limiter
  → Batch Processor
  → Exporter
  → Tempo·Mimir·Loki 또는 다른 호환 Backend

ここで重要なのは、「3つのシグナルを1箇所に入れる」ことよりも、同じサービス名、環境、TraceIdのような相関関係のコンテキストを維持することです。Collectorを経由したからといって、互いに無関係なログとトレースが自動的に接続されるわけではありません。計測段階でコンテキストを適切に生成し、伝播させる必要があります。

OTLPにはgRPCとHTTPの転送方式があります。一般的にgRPC受信ポートは4317、HTTP受信ポートは4318を使用します。ただし、ポートが開いているという事実が認証と暗号化を意味するわけではありません。ネットワーク境界外で受信する場合は、TLS、認証、アクセス制御を別途設計する必要があります。

なぜアプリケーションがBackendに直接送信しないのか

小規模な開発環境では、SDKがBackendに直接エクスポートしても構いません。公式のOpenTelemetryドキュメントも、開始段階での直接送信を可能な選択肢として説明しています。しかし、サービスごとにBackendのアドレスと認証方式を設定すると、変更範囲が大きくなり、再試行・バッチ・フィルタポリシーもアプリケーションごとに分散してしまいます。

Collector層を設けることで、アプリケーションは近いOTLP Endpointにシグナルを素早く渡し、本来の業務に戻ることができます。再試行、バッチ処理、機密情報フィルタリング、複数の宛先への分岐はCollectorで管理されます。ただし、Collectorが新たなボトルネックや障害点となるため、キューの滞留、拒否・破棄数、メモリ、Exporterの失敗を必ず観測する必要があります。

バッチ処理の位置も重要です。Grafanaのドキュメントでは、OTelコンポーネントを使用するすべてのAlloyに対してBatch Processorの構成を強く推奨しており、Memory Limiterやサンプリングのようにデータを破棄する可能性のあるProcessorの後ろに配置するよう案内しています。これにより、最終的に残ったデータを効率的にまとめることができます。

実習: PodmanでAlloy乗り換えセンターを開く

今回の実習では、外部のBackendやクラウドの資格情報は使用しません。OTLPで受信したデータをAlloyのDebug Exporterがコンテナログに出力する閉鎖型の検証です。機密性の高い運用データを送信せず、サンプルシグナルのみを使用してください。

ステップ1: 作業ディレクトリと設定ファイルの準備

新しいディレクトリでconfig.alloyを作成します。

mkdir -p alloy-lab
cd alloy-lab

logging {
  level  = "info"
  format = "logfmt"
}

otelcol.receiver.otlp "lab" {
  grpc {
    endpoint = "0.0.0.0:4317"
  }

  http {
    endpoint = "0.0.0.0:4318"
  }

  output {
    metrics = [otelcol.processor.memory_limiter.lab.input]
    logs    = [otelcol.processor.memory_limiter.lab.input]
    traces  = [otelcol.processor.memory_limiter.lab.input]
  }
}

otelcol.processor.memory_limiter "lab" {
  check_interval = "1s"
  limit          = "256MiB"

  output {
    metrics = [otelcol.processor.batch.lab.input]
    logs    = [otelcol.processor.batch.lab.input]
    traces  = [otelcol.processor.batch.lab.input]
  }
}

otelcol.processor.batch "lab" {
  timeout         = "1s"
  send_batch_size = 512

  output {
    metrics = [otelcol.exporter.debug.lab.input]
    logs    = [otelcol.exporter.debug.lab.input]
    traces  = [otelcol.exporter.debug.lab.input]
  }
}

otelcol.exporter.debug "lab" {
  verbosity = "detailed"
}

この設定は、Receiver → Memory Limiter → Batch → Debug Exporterという方向グラフです。AlloyのネイティブエンジンはYAMLではなくAlloy構文でコンポーネントの出力を次のコンポーネントの入力に接続します。2026年9月現在、upstream Collector YAMLを直接実行するalloy otelエンジンもありますが、公式ドキュメントではExperimentalとされているため、この実習では安定したネイティブエンジンを使用します。

ステップ2: 設定をまず検証する

実行前に、コンテナのvalidateコマンドで構文とコンポーネントの接続を検査します。は公式リリースで検証済みの固定バージョンに置き換えてください。`latest`は実習の再現性を低下させるため、本文のコマンドでは使用しません。

podman run --rm 
  -v "$PWD/config.alloy:/etc/alloy/config.alloy:Z,ro" 
  docker.io/grafana/alloy:v1.19.0 
  validate /etc/alloy/config.alloy

成功すれば、設定エラーなしで終了します。失敗した場合は、行番号とコンポーネント名を確認し、次のステップに進まないでください。

ステップ3: Alloyを実行する

podman run --rm -d --name alloy-lab 
  -p 127.0.0.1:12345:12345 
  -p 127.0.0.1:4317:4317 
  -p 127.0.0.1:4318:4318 
  -v "$PWD/config.alloy:/etc/alloy/config.alloy:Z,ro" 
  docker.io/grafana/alloy:v1.19.0 
  run --server.http.listen-addr=0.0.0.0:12345 
  --storage.path=/var/lib/alloy/data 
  /etc/alloy/config.alloy

ホストバインディングを127.0.0.1に制限した理由は、実習用の無認証OTLP ReceiverとデバッグUIを外部に公開しないためです。ブラウザでhttp://127.0.0.1:12345を開くと、コンポーネントの状態と接続グラフを確認できます。

ステップ4: プロンプトだけでサンプルアプリを計測する

使用するLLMコーディングツールに以下のプロンプトを入力します。生成されたコードは実行前にファイルリストと依存関係を確認し、秘密の値や外部転送アドレスがないことを確認してください。

Pythonで最小限のHTTPサーバーを作成してください。OpenTelemetry公式SDKとOTLP Exporterを使用し、サービス名を`alloy-lab-app`に設定してください。`/work`リクエストを受け取ったら、親Spanを1つ、子Spanを1つ、Counter Metricを1つ、TraceIdを含む構造化Logを1つ作成し、それらをOTLP/HTTPで`http://127.0.0.1:4318`に送信してください。必要な`requirements.txt`、実行コマンド、リクエストコマンドも一緒に作成してください。ただし、外部サービスや資格情報は使用しないでください。

生成結果が言語ごとの公式パッケージ名と現在のAPIに合致していることを確認した後、隔離された仮想環境で実行します。`/work`を数回呼び出し、次のコマンドでAlloyの出力を確認します。

podman logs -f alloy-lab

期待される結果は、`alloy-lab-app` Resourceと生成されたSpan・Metric・Log RecordがDebug Exporterの出力に表示されることです。TraceIdを比較して、1つのリクエストから発生したシグナルが接続されていることを確認します。デバッグ出力は学習用であり、大量の運用トラフィックには適していません。

ステップ5: 終了とクリーンアップ

実習が終了したら、次のように終了します。`–rm`オプションにより、停止したコンテナも一緒に削除されます。

podman stop alloy-lab

Backendに変更する際の変更点

実習のDebug ExporterをOTLP Exporterに置き換えることで、Alloyの背後に実際のBackendを接続できます。OTLPをサポートする単一のEndpointに3つのシグナルを送信することも、LogはLoki、TraceはTempo、MetricはPrometheus互換ストレージにそれぞれ異なるルーティングをすることも可能です。

この際、Endpoint、プロトコル、認証方式はBackendのドキュメントに従う必要があります。例えば、HTTP/HTTPS Endpointには`otelcol.exporter.otlphttp`が、gRPC Endpointには`otelcol.exporter.otlp`が対応します。APIトークンを設定ファイルに平文で記述せず、環境変数や組織のシークレット管理システムを使用してください。複数のテナントが共有する環境では、受信認証とテナント識別を信頼できるGatewayで強制し、クライアントが送信したテナント属性をそのまま信用しないでください。


デプロイ方式	利点	注意点	適した環境

—	—	—	—
アプリケーションからBackendへ直接送信	構成要素が少なく、開始が早い	認証・再試行・宛先設定がサービスごとに分散	個人開発、短期検証
ホスト別Agent	アプリケーションに近く、素早く引き渡せる	ノード数分のデプロイ・アップデートが必要	VM、Kubernetes DaemonSet
中央Gateway	ポリシーとExporterを一箇所で管理	ボトルネック・単一障害点・テナント分離が必要	複数のチームが共有するプラットフォーム
Agent + Gateway	ローカル収集と中央ポリシーを分離	2層の容量・障害対応が必要	大規模な運用環境

運用投入前のセキュリティ・信頼性チェックリスト

OTLP ReceiverとAlloy管理UIを必要なインターフェースとネットワークにのみバインドする。
Collector間またはリモートクライアント接続にはTLSと認証を適用する。
ログ本文、Span属性、Resource属性にトークン・セッション・個人情報を入れない。
フィルタとマスキングは、エクスポート直前だけでなく、可能な限り計測元から適用する。
Memory Limiter、Batch、送信キュー、再試行をトラフィック特性に合わせて調整する。
受信量、拒否・破棄量、キュー滞留、エクスポート失敗、再起動回数、メモリを監視する。
サービス名や環境名などのResource属性の組織標準を定め、高カーディナリティ値をMetric Labelとして乱用しない。
コンテナバージョンまたはDigestを固定し、設定は読み取り専用でマウントし、最小権限で実行する。
Debug Exporterの詳細出力には生データが表示される可能性があるため、運用では無効にする。
障害実験でBackendの遅延・中断を発生させ、データ損失とアプリケーションへの影響範囲を確認する。

テレメトリーには、ユーザー識別子、URL、クエリ、エラー内容、内部ネットワーク構造が混在する可能性があります。OpenTelemetryの公式セキュリティドキュメントも、PIIの露出、データ改ざん、規制遵守、DoSをCollectorセキュリティの主な理由として挙げています。観測パイプラインも保護すべきデータパイプラインです。

結論: 標準と転送プログラムを分離して理解しよう

OpenTelemetryは、ログ・トレース・メトリックを共通の方法で作成し、接続し、伝達できるようにする標準とエコシステムです。Grafana Alloyは、そのシグナルを実際に受け取り、加工し、ルーティングするCollectorディストリビューションです。OTelはBackendではなく、AlloyはGrafana専用の通路ではなく、Collectorを置いたからといって相関関係とセキュリティが自動的に完成するわけではありません。

最も小さな出発点は、ローカルのOTLP ReceiverとDebug Exporterです。ここでResource、TraceId、および3つのシグナルの到着を確認した後、Memory LimiterとBatchを維持したまま実際のBackend Exporterに置き換えます。次のステップでは、Tempo・Loki・Prometheus系のストレージに到着したシグナルをGrafanaで相互に移動しながら照会する方法を検討できます。

公式参考資料

カテゴリ: クラウド/opentelemetry

タグ: OpenTelemetry, Grafana Alloy, OTLP, Observability, Collector, Log, Trace, Metric