Azure MonitorのOTLP取り込みが一般提供されたことで、OpenTelemetryで計装済みのアプリケーションや既存のOpenTelemetry Collectorパイプラインから、ログ・メトリック・トレースをAzure Monitorへ直接送信しやすくなりました。結論として、すでにOpenTelemetryを使っている組織は、Azure固有のSDKや独自パイプラインに寄せすぎず、標準的なOTLPベースの監視構成を本番利用の選択肢にできます。
一方で、何も考えずに切り替えると、DCR/DCEの設定漏れ、Microsoft Entra IDの権限不足、メトリックのtemporality不一致、重複取り込みによるコスト増が起きやすい更新です。この記事では、2026年6月5日に公開・更新されたAzure Updatesの「Generally Available: Ingest OTLP signals into Azure Monitor with the OpenTelemetry Collector」をもとに、Azure Monitorの変更点、影響範囲、管理者・開発者が確認すべき設定と移行時の注意点を整理します。Azure Updatesではこの更新が「Launched」として掲載されており、Azureの「Launched」は本番利用可能な一般提供状態を意味します。(マイクロソフト Azure)
Azure MonitorのOTLP取り込みで何が変わるのか
今回のポイントは、Azure MonitorがOpenTelemetry Protocol、つまりOTLPのネイティブ取り込みを一般提供したことです。OTLPは、OpenTelemetryで収集したログ、メトリック、トレースを監視基盤へ送るための標準プロトコルです。Microsoft Learnでも、Azure MonitorはOpenTelemetry Collector、Azure Monitor Agent、AKSアドオンという複数の経路でOTLP信号を受け取れると説明されています。(Microsoft Learn)
特に今回の主役は、OpenTelemetry Collector経由の取り込みです。アプリケーション側はOpenTelemetry SDKで計装し、CollectorがOTLPを受け取り、Azure Monitorのクラウド取り込みエンドポイントへ送信します。これにより、アプリケーションごとにAzure専用の実装へ寄せるのではなく、監視データの送信部分をCollector側で集約・制御しやすくなります。
この変更は、AIアプリやCopilot拡張のように複数サービスをまたいで処理が流れるシステムにも効果があります。ただし、「AI/Copilot専用の新機能」というより、分散アプリケーション全般の可観測性をOpenTelemetry標準で整えやすくする更新と理解すると実務上は正確です。
一般提供された範囲と、まだ注意が必要な範囲
Azure MonitorのOpenTelemetry対応には複数の選択肢があります。すべてが同じリリース状態ではないため、採用前にどの経路を使うのかを分けて考える必要があります。
| 方式 | 主な用途 | リリース状態の考え方 | 向いているケース |
|---|---|---|---|
| OpenTelemetry Collector経由のOTLP取り込み | 任意の環境からAzure Monitorへ送信 | 一般提供 | 既存のOpenTelemetry Collectorを使っている、マルチクラウド・ハイブリッド環境がある |
| Microsoft OpenTelemetry Distro | Azure Monitor向けに最適化されたOpenTelemetry導入 | 一般提供 | .NET、Java、Node.js、PythonなどでAzure Monitor統合を手早く始めたい |
| Azure Monitor Agent経由 | VM、VM Scale Sets、Azure Arc対応サーバーからの取り込み | プレビュー扱いに注意 | ホスト単位でエージェント管理したい |
| AKSアドオン経由 | AKS上のコンテナーアプリ監視 | プレビュー扱いに注意 | AKS統合の管理体験を使いたい |
Microsoft Learnでは、OpenTelemetry CollectorとMicrosoft OpenTelemetry Distroは一般提供、AMAとAKSの経路はプレビューであり、プレビュー機能はSLAなし・本番ワークロード推奨ではないと明記されています。(Microsoft Learn)
つまり、本番環境で今回の更新を活用するなら、まずはOpenTelemetry Collector経由、またはMicrosoft OpenTelemetry Distroを中心に検討するのが現実的です。AMAやAKSアドオンの経路は便利ですが、本番適用時はプレビュー条件、サポート範囲、将来の仕様変更リスクを確認してから判断すべきです。
既存環境への影響
今回の一般提供は、既存のApplication Insights SDKやAzure Monitor OpenTelemetry Distroを強制的に置き換えるものではありません。すでにApplication Insights SDKで安定運用しており、移植性やCollector集約に課題がない場合は、急いで変更する必要はありません。
影響が大きいのは、次のような環境です。
- すでにOpenTelemetry SDKでアプリケーションを計装している
- OpenTelemetry Collectorを社内標準のテレメトリゲートウェイとして使っている
- Azure以外のクラウド、オンプレミス、Kubernetes環境からAzure Monitorへ集約したい
- ログ、メトリック、トレースを標準スキーマで扱い、将来的な監視基盤の移行余地を残したい
- Azure Monitor、Log Analytics、Application Insights、Grafanaを組み合わせて可視化したい
Azure MonitorのネイティブOTLP取り込みでは、メトリックはAzure Monitor Workspaceに保存され、PromQLやGrafanaで扱える構成になります。ログとトレースはLog Analyticsに保存され、OpenTelemetryのセマンティック規約に基づくスキーマで分析できます。さらにApplication InsightsやGrafanaの可視化にもつなげられます。(Microsoft Learn)
実務上のメリットは、単に「Azure Monitorに送れるようになった」ことではありません。アプリケーション側の計装をOpenTelemetry標準に寄せたまま、Azure Monitor側の分析・可視化・アラート運用へ接続しやすくなる点が重要です。
管理者が最初に確認すべき設定
Azure管理者やプラットフォーム担当者は、アプリケーションコードより先に、受け皿となるAzureリソースと権限設計を確認する必要があります。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| Application InsightsのOTLPサポート | 新規作成時にOTLP supportを有効化するか | 必要なDCR/DCEや接続情報の準備漏れ |
| DCR/DCE | Data Collection Rule、Data Collection Endpoint、送信先ワークスペースの関係 | 送信先不一致、エンドポイント誤り |
| Microsoft Entra ID | CollectorがAzure Monitorへ送信するための認証方式 | 401、403、データ未到達 |
| ロール割り当て | DCRに対するMonitoring Metrics Publisher権限 | Collectorは起動しているのに送信できない |
| ワークスペース設計 | Log Analytics WorkspaceとAzure Monitor Workspaceのリージョン、保持期間、RBAC | コスト増、権限管理の複雑化 |
| ネットワーク | CollectorからAzure Monitor取り込みエンドポイントへのアウトバウンド通信 | ファイアウォールやプロキシで送信失敗 |
| コスト管理 | サンプリング、フィルタリング、高カーディナリティ属性 | ログ・メトリック量の急増 |
Microsoft Learnでは、OTLP取り込み設定として、Application InsightsリソースでOTLPサポートを有効にする方法が多くのシナリオで推奨されています。この方法では、必要なAzureリソースと関係が自動的に構成され、Application Insightsのトラブルシューティング体験も利用しやすくなります。(Microsoft Learn)
一方、既存のLog Analytics WorkspaceやAzure Monitor Workspaceを再利用したい場合、またはDCR/DCEを細かく制御したい場合は、手動オーケストレーションを選びます。この場合は、Log Analytics Workspaceがログとトレース、Azure Monitor Workspaceがメトリックの保存先になる点を踏まえて設計します。(Microsoft Learn)
OpenTelemetry Collector側で必要な準備
OpenTelemetry Collectorを使う場合、前提としてOpenTelemetry SDKで計装されたアプリケーションと、Azure Authentication Extensionを含むCollector構成が必要です。Microsoft Learnでは、OpenTelemetry Collectorのバージョン0.132.0以上とAzure Authentication Extensionが前提として示されています。(Microsoft Learn)
Collectorは、一般的にはアプリケーションからOTLPを受け取るreceiver、バッチ処理などを行うprocessor、Azure Monitorへ送るexporterで構成します。典型的には、アプリケーションはCollectorの4317、または4318へOTLPを送信します。
receivers:
otlp:
protocols:
grpc:
endpoint: localhost:4317
http:
endpoint: localhost:4318
processors:
batch:
extensions:
azure_auth:
use_default: true
scopes:
- https://monitor.azure.com/.default
exporters:
otlphttp/azuremonitor:
traces_endpoint: "https://<logs-dce-domain>/datacollectionRules/<dcr-immutable-id>/streams/Microsoft-OTLP-Traces/otlp/v1/traces"
logs_endpoint: "https://<logs-dce-domain>/datacollectionRules/<dcr-immutable-id>/streams/Microsoft-OTLP-Logs/otlp/v1/logs"
metrics_endpoint: "https://<metrics-dce-domain>/datacollectionRules/<dcr-immutable-id>/streams/<metrics-stream>/otlp/v1/metrics"
auth:
authenticator: azure_auth
service:
extensions:
- azure_auth
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/azuremonitor]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/azuremonitor]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/azuremonitor]実運用では、上記に加えてmemory_limiter、リトライ、キュー、不要属性の削除、サンプリングなどを検討します。特に高トラフィックなAPIやバッチ処理基盤では、Collectorが単一障害点にならないよう、スケールアウトと監視も設計に含めるべきです。
Microsoft Entra IDとDCR権限の確認
CollectorからAzure Monitorへ送信するには、Microsoft Entra IDによる認証が必要です。Azure VMやVirtual Machine Scale Sets上でCollectorを動かす場合は、システム割り当てマネージドIDを有効化し、そのIDにMonitoring Metrics Publisherロールを割り当てる流れが示されています。(Microsoft Learn)
Azure外の環境、たとえばオンプレミス、他クラウド、セルフマネージドKubernetesでCollectorを動かす場合は、サービスプリンシパルやワークロードIDなど、環境に合ったEntra ID認証を構成します。重要なのは、Collectorが使うIDに対して、送信先のData Collection Ruleへ書き込む権限を付与することです。Microsoft Learnでも、DCRのIAMからMonitoring Metrics Publisherを割り当てる手順が説明されています。(Microsoft Learn)
権限トラブルは、OTLP移行で非常に起きやすい失敗です。アプリケーションはCollectorへ送れている、Collectorも起動している、それでもAzure Monitorにデータが出ない場合は、まずDCRに対するロール割り当て、トークン取得、エンドポイントURLの3点を確認してください。
エンドポイントURLで間違えやすいポイント
手動でDCE/DCRを構成する場合、ログ、メトリック、トレースのエンドポイントURLを正しく組み立てる必要があります。Microsoft Learnでは、メトリック、ログ、トレースで異なるURLパターンが示されており、トレースエンドポイントはログDCEドメインを使用すると説明されています。(Microsoft Learn)
特に注意したいのはメトリックのstream名です。DCR側のstream名とDCE URL側のstream名は一致している必要があり、大文字・小文字も区別されます。stream名を変更した場合は、DCRテンプレート内の参照とCollector設定の両方を更新しなければなりません。(Microsoft Learn)
現場では、次のようなミスがよく起きます。
| 症状 | よくある原因 | 確認する場所 |
|---|---|---|
| トレースだけ届かない | traces_endpointにmetrics側DCEドメインを使っている | Collector exporter設定 |
| メトリックだけ表示されない | metricsのstream名がDCRと一致していない | DCR、DCE URL、Collector設定 |
| すべて届かない | DCR Immutable IDではなくResource IDをURLに使っている | DCR Overview |
| 403になる | CollectorのIDにMonitoring Metrics Publisherがない | DCRのIAM |
| Collector起動時に認証エラー | azure_auth構文とCollectorバージョンが合っていない | Collectorバージョン、拡張機能 |
なお、Microsoft Learnの例では、azure_auth構文に関してOpenTelemetry Collector 0.148.0以降が必要で、古いバージョンとは後方互換性がない旨も説明されています。バージョン固定で運用している環境では、構成ファイルだけを新しくしても動かない可能性があります。(Microsoft Learn)
開発者が確認すべき実装ポイント
開発者側では、Azure Monitorに直接依存するコードを書くかどうかよりも、OpenTelemetryの信号がきれいに出ているかを確認することが重要です。
まず、service.name、service.version、deployment.environmentなどのresource属性を必ず整備します。これが不足していると、Application InsightsやGrafanaで見たときに、どのサービスのテレメトリなのか判別しづらくなります。
次に、トレースのコンテキスト伝播を確認します。HTTP、gRPC、メッセージキュー、非同期ジョブをまたぐ構成では、trace IDが途中で切れると、分散トレースとしての価値が大きく下がります。障害調査で「API Gatewayまでは見えるが、バックエンド処理がつながらない」という状態になりがちです。
メトリックについては、delta temporalityとexponential histogram aggregationに注意が必要です。Application Insightsの事前構築済みダッシュボードやクエリは、OTLPメトリックにdelta temporalityとexponential histogram aggregationを期待すると説明されています。SDK側がcumulative temporalityで送っている場合は、Collector側でcumulativetodelta processorを使って変換する必要があります。(Microsoft Learn)
ログについては、構造化ログにtrace IDやspan IDを含め、トレースとログを突き合わせられるようにします。単なる文字列ログを大量に送るだけでは、Azure Monitorへ集約しても根本原因分析にはつながりにくく、コストだけが増えます。
移行・展開の進め方
本番環境では、既存監視から一気に切り替えるより、サービス単位で段階的に検証するのが安全です。
| 手順 | 作業内容 | 判断基準 |
| -: | ———————————————– | ———————————— |
| 1 | 現在の計装方式、SDK、Exporter、Collector構成を棚卸しする | Azure専用実装とOpenTelemetry標準実装が混在していないか |
| 2 | 影響の小さい1サービスを選び、OTLP送信を試す | ログ・メトリック・トレースがすべて到達するか |
| 3 | Application InsightsのOTLPサポート、または手動DCR/DCEを構成する | DCR、DCE、Workspaceの関係が説明できるか |
| 4 | CollectorへAzure認証とexporter設定を追加する | 401、403、URLミスがないか |
| 5 | 既存監視と並行稼働して差分を見る | 件数、レイテンシ、エラー率、トレースのつながりが妥当か |
| 6 | ダッシュボード、アラート、KQL、PromQLを更新する | 運用チームが障害調査に使えるか |
| 7 | 重複送信を止め、旧Exporterや旧設定を整理する | 二重課金やノイズが発生していないか |
並行稼働の期間は、障害調査に必要な主要シナリオを実際に試すことが大切です。たとえば、APIエラーを意図的に発生させ、トレース、関連ログ、メトリックの変化を1つの調査フローで追えるかを確認します。
採用すべきケース、慎重に進めるべきケース
今回のAzure Monitor OTLP取り込みは、多くの環境で前向きに検討できる更新です。ただし、すべての環境で即時移行が最適とは限りません。
採用を優先したいのは、次のケースです。
- OpenTelemetryをすでに標準計装として採用している
- Azure、オンプレミス、他クラウドの監視データをAzure Monitorへ集約したい
- アプリケーションコードを特定ベンダーの監視SDKに強く依存させたくない
- Collectorでフィルタリング、属性加工、サンプリングを集中管理したい
- Grafana、PromQL、Log Analytics、Application Insightsを組み合わせて使いたい
慎重に進めたいのは、次のケースです。
- 既存のApplication Insights SDKで十分に運用できており、移植性の課題がない
- Collector運用の経験がなく、可用性やスケール設計をまだ持っていない
- AMAやAKSアドオンの経路を本番前提で使おうとしている
- テレメトリ量の見積もりがなく、コスト上限や保持期間のルールも未整備
- 監視データのスキーマ変更により、既存のKQL、アラート、ダッシュボードが壊れる可能性がある
特にコストは見落としがちです。OTLPで送信しやすくなるほど、不要なdebugログ、高カーディナリティなラベル、過剰なメトリック、重複トレースも入りやすくなります。Collectorを導入するなら、送信前に削る設計も同時に行うべきです。
サポート範囲の線引きも確認しておく
OpenTelemetry Collectorを使う場合、Azure Monitorに送るための構成にはOpenTelemetry Collector ContribやAzure Authentication Extensionなどのオープンソースコンポーネントが関係します。Microsoft Learnでは、これらオープンソースコンポーネントのサポートはコミュニティチャネルで提供され、AzureサービスやApplication Insights、Log Analytics、DCR、DCEなどのAzureリソースについてはAzureサポートが利用できると説明されています。(Microsoft Learn)
この線引きは、運用設計で重要です。たとえば、DCRの権限やAzure Monitor側の取り込み問題はAzureサポートの対象になり得ますが、Collectorの特定processorの不具合やcontribコンポーネントの挙動は、コミュニティIssueを追う必要が出る場合があります。
本番展開前に、社内の問い合わせ先を次のように分けておくと混乱を減らせます。
| 問題の種類 | 主な確認先 |
|---|---|
| Azure Monitorにデータが表示されない | DCR、DCE、Workspace、RBAC、Azureサポート |
| Collectorが起動しない | Collector設定、バージョン、コンテナログ |
| 特定processor/exporterの挙動がおかしい | OpenTelemetry Collectorのドキュメント、GitHub Issue |
| ダッシュボードやアラートが期待通り動かない | KQL、PromQL、Application Insights、Grafana設定 |
| テレメトリ量が急増した | Collectorのフィルタ、サンプリング、ログレベル、属性設計 |
次にやるべきこと
Azure MonitorのOTLP取り込み一般提供は、OpenTelemetryを本番監視の標準にしたい組織にとって大きな前進です。特にOpenTelemetry Collectorをすでに使っている場合、既存の計装やパイプラインを活かしながら、Azure Monitor、Application Insights、Log Analytics、Grafanaへ接続しやすくなります。
まずは、いきなり全サービスを切り替えるのではなく、1つの代表的なサービスでPoCを行いましょう。確認すべき項目は、Collectorのバージョン、Azure Authentication Extension、DCR/DCE、Monitoring Metrics Publisherの権限、メトリックのdelta temporality、既存監視との重複、コスト見積もりです。
そのうえで、ログ・メトリック・トレースがAzure Monitor上で相関して見えるか、障害調査に使えるか、アラート運用を置き換えられるかを判断します。OTLP対応は「送れるようになった」で終わらせず、監視データを標準化し、調査時間と運用負荷を下げるための基盤変更として扱うのが成功のポイントです。
コメント