このエントリは2026/06/24現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。
今回は特に誰からの問い合わせというわけでもなく、個人的な実験結果をまとめたもの。
【おことわり】
1. この記述はあくまでも実験であり、本番運用環境で使うことを意図していません。
2. サポートの有無についても考慮していません。
やりたいこと
OpenTelemetry (OTel) のエンドポイントをAPIMのManaged Gatewayで公開したい
通常は、Application Insightsやその他のサービスが公開するOpenTelemetry (OTel) のエンドポイントに向けて送信する。APIMのSelf-hosted gatewayでApplication InsightsのOTelエンドポイントを公開するドキュメントが存在するのだが、Managed Gatewayでもできるだろう、ということで、Gatewayを置き換えて構成してみた、というもの。
OpenTelemetry 統合を使用して Kubernetes にセルフホステッド ゲートウェイをデプロイする / Deploy a self-hosted gateway to Kubernetes with OpenTelemetry integration
https://learn.microsoft.com/azure/api-management/how-to-deploy-self-hosted-gateway-kubernetes-opentelemetry
APIMの設定
Azure PortalにはPreviewという記述はありつつも、Application Insights OpenTelemetryというメニューが存在する。
設定自体は、ドキュメントに従って構成すれば問題ない。ただし2026/06/24時点で、Application InsightsでのOTelサポート有効化には注意が必要。具体的には、Application InsightsでのOTelサポート有効化は、任意のタイミングで可能。
OTelサポートを無効化していても、プロビジョニング後のOTelサポート有効化は可能。
ただし、OTelのサポートを有効化したApplication Insightsは、プロビジョニング後、OTelサポートを無効化できない。これはPortalからプロビジョニングした場合にはInformationで確認できる。
AMA を使用して OTLP データをAzure Monitorに取り込む (プレビュー) / Ingest OTLP data into Azure Monitor by using AMA (Preview)
https://learn.microsoft.com/azure/azure-monitor/containers/opentelemetry-ingest-agent#set-up-otlp-data-ingestion
構成が終わると、APIMではAPIが3個作成されていて、Backendsも3個構成されているはず。
各Backendの設定を見ると、「DCR (data collection rule) を構成しているんだなー」というのがわかるはず。これで設定はおしまい。
送信元の設定
アプリケーション側から送信するための設定は以下のあたり。
- エンドポイント
- プロトコル
エンドポイントは、APIMのAPI settingsページのBase URLを使う。
プロトコルはgRPCもしくはhttp/protobufが主流だが、送信元とバックエンドの制約に従う。
これでおしまい。
実際にOTel tracingやmetricsの確認は次のエントリで。
Logico Inside 