Azure Monitor で OpenTelemetry を使う場合、これまで悩みやすかったのが「アプリから直接送るのか、OpenTelemetry Collector を置くのか、Azure Monitor Agent を使うのか」という取り込み経路の設計でした。結論から言うと、2026年4月20日に発表された Azure Monitor Agent（AMA）による OTLP ネイティブインジェストのパブリックプレビューにより、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバーの監視設計では、AMA をローカルの OTLP 受け口として使う選択肢が現実的になりました。(Microsoft)
これは単なる新機能ではありません。OpenTelemetry の計装を保ちながら、認証・ルーティング・Azure Monitor への転送をホスト側のエージェントに寄せられるため、Observability engineers、SRE、platform teams、cloud architects にとって、監視基盤の標準化と運用負荷の下げ方が変わります。
Azure Monitor の OTLP ネイティブインジェストとは
Azure Monitor の OTLP ネイティブインジェストは、OpenTelemetry Protocol（OTLP）のシグナルを Azure Monitor 側で受け取り、Application Insights、Log Analytics、Azure Monitor Workspace、Grafana などの分析・可視化につなげるための仕組みです。
OpenTelemetry は、トレース、メトリック、ログなどのテレメトリを収集・処理・エクスポートするための標準的な枠組みです。OTLP はそのデータを送るためのプロトコルで、アプリケーションと監視バックエンドを疎結合にしやすい点が大きな価値です。(OpenTelemetry)
今回注目すべき点は、Azure Monitor Agent が OTLP の受け口になれることです。アプリケーションは OpenTelemetry SDK や OTLP exporter でローカルの AMA にデータを送り、AMA が Azure Monitor への転送を担います。Microsoft の発表では、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応プラットフォームでサポートされると説明されています。(Microsoft)
これまでの設計で起きやすかった課題
OpenTelemetry を Azure Monitor に送る設計では、よく次のような課題がありました。
| 課題 | 現場で起きること |
|---|---|
| Collector を誰が管理するか決まらない | アプリチーム、SRE、プラットフォームチームの責任分界が曖昧になる |
| アプリごとに exporter 設定がばらつく | 接続先、認証、サンプリング、属性付与が統一されない |
| VM と Kubernetes で設計が分断される | AKS はアドオン、VM は Collector、別環境は別方式になり運用が複雑化する |
| ベンダー固有 SDK への依存を避けたい | OpenTelemetry に寄せたいが、Azure Monitor 側の取り込み経路で迷う |
| 認証情報の扱いが難しい | アプリケーションに接続文字列や認証設定を持たせる範囲が増える |
AMA による OTLP ネイティブインジェストは、特に VM と Arc サーバーの領域で「アプリは標準の OTLP をローカルに送る」「Azure への転送はホスト側の AMA が担う」という分担を作りやすくします。
なぜ Azure Monitor の OpenTelemetry 採用で重要なのか
ベンダー中立の計装を維持しやすくなる
OpenTelemetry 採用の主な狙いは、アプリケーションの計装を特定ベンダーの SDK だけに閉じないことです。コード側は OpenTelemetry の API、SDK、semantic conventions に寄せ、バックエンドは Azure Monitor、他の APM、データレイクなどに切り替えやすくする。これが多くのプラットフォームチームにとって重要な設計思想です。
AMA が OTLP を受けられるようになると、Azure 上の VM ワークロードでは、アプリケーションを Azure Monitor 専用 exporter に強く結びつけずに済む場面が増えます。アプリ側は OTLP endpoint を localhost に向け、監視基盤側で DCR、DCE、ワークスペース、Application Insights との接続を管理する構成にできます。
Collector を置かない選択肢が増える
OpenTelemetry Collector は非常に強力です。テレメトリの変換、フィルタリング、サンプリング、複数バックエンドへの分岐などを行うには、今後も重要な選択肢です。
ただし、すべての VM ワークロードで Collector を運用したいとは限りません。Collector を入れると、構成ファイル、バージョン管理、セキュリティパッチ、プロセス監視、スケール設計が必要になります。Azure Monitor Agent で十分な要件であれば、Collector を追加せずに OTLP を Azure Monitor へ流せるため、監視パイプラインを軽くできます。
Microsoft Learn でも、AMA 方式は Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバー上のアプリケーションから OTLP シグナルを取り込む方式として位置付けられています。(Microsoft Learn)
認証とルーティングをホスト側に寄せられる
AMA 方式では、アプリケーションがローカルの AMA に OTLP を送信し、AMA が Azure Monitor エンドポイントへの認証とルーティングを処理します。ドキュメントでは、コンピューティングリソースでシステム割り当てマネージド ID を有効にし、その ID に DCR へ書き込むための Monitoring Metrics Publisher ロールを割り当てる手順が示されています。(Microsoft Learn)
これはセキュリティ設計上も意味があります。アプリケーションごとに認証情報を細かく持たせるより、ホスト単位のマネージド ID と DCR association で制御したほうが、標準化しやすいケースがあるためです。
Application Insights、Log Analytics、Grafana への接続が整理される
Azure Monitor の OTLP ネイティブインジェストは、単にデータを受け取るだけではありません。発表では、OTLP データを Application Insights で監視・トリアージ・トラブルシュートに使えること、OTLP メトリックを Azure 上の Grafana ダッシュボードや Prometheus query language で可視化できること、ログとトレースを OpenTelemetry semantics で Log Analytics からクエリできることが説明されています。(Microsoft)
つまり、OpenTelemetry の標準データを Azure Monitor の分析体験に接続する道が広がったということです。SRE にとっては、インシデント対応時に「どのパイプラインで取ったデータか」ではなく、「どのサービスで何が起きたか」に集中しやすくなります。
AMA によって変わる監視アーキテクチャの選び方
Azure Monitor の OpenTelemetry 取り込みには、主に複数の経路があります。重要なのは「新しいから AMA を使う」ではなく、ワークロードの場所、運用体制、必要な加工処理、プレビュー利用の許容度で選ぶことです。
| 取り込み方式 | 向いている環境 | 主なメリット | 注意点 |
|---|---|---|---|
| Azure Monitor Agent（AMA）による OTLP 取り込み | Azure VM、VMSS、Azure Arc 対応サーバー | ホスト単位で標準化しやすい。Collector を別途管理しない構成を作れる | パブリックプレビュー。対応バージョン、ポート、DCR、権限設定の確認が必要 |
| OpenTelemetry Collector から Azure Monitor へ送信 | マルチクラウド、オンプレ、複雑な加工が必要な環境 | 変換、フィルタ、サンプリング、複数バックエンド送信に強い | Collector の運用管理が必要 |
| Azure Monitor OpenTelemetry Distro | .NET、Java、Node.js、Python などのアプリケーション中心の監視 | アプリ側に組み込みやすく、Application Insights 体験に入りやすい | 言語・機能の対応状況確認が必要 |
| AKS アドオン | Azure Kubernetes Service | クラスター統合の監視設計に向く | VM/Arc とは設計単位が異なる |
Azure Monitor の公式ドキュメントでは、Azure Monitor が OTLP シグナルを受け取る方式として、OpenTelemetry Collector、Azure Monitor Agent、AKS アドオンの3つが整理されています。(Microsoft Learn)
AMA を選ぶべきケース
AMA 方式は、次の条件に当てはまる場合に有力です。
| 判断基準 | AMA が向いている理由 |
|---|---|
| アプリが Azure VM、VMSS、Arc 対応サーバーで動いている | AMA の対象環境と一致する |
| すでに AMA を標準エージェントとして使っている | 監視エージェントの運用を統一しやすい |
| アプリ側は OTLP 送信だけにしたい | 認証や Azure Monitor へのルーティングを AMA 側に寄せられる |
| Collector の高度な加工が不要 | 追加コンポーネントを減らせる |
| プレビュー機能を検証環境や限定範囲で試せる | 現時点では本番全面移行より段階導入が適している |
典型的な構成は次のようになります。
OpenTelemetry SDK を組み込んだアプリケーション
↓ OTLP gRPC
localhost の Azure Monitor Agent
↓
Data Collection Rule / Data Collection Endpoint
↓
Application Insights / Log Analytics / Azure Monitor Workspace
↓
Grafana / KQL / Application Insights の分析画面この構成では、アプリケーション開発者は OpenTelemetry の計装と OTLP exporter の設定に集中できます。一方で、プラットフォームチームは AMA、DCR、RBAC、ワークスペース設計を IaC や Azure Policy で標準化しやすくなります。
OpenTelemetry Collector を選ぶべきケース
AMA が登場しても、Collector が不要になるわけではありません。むしろ、次のような要件では Collector のほうが適しています。
| 要件 | Collector が向いている理由 |
|---|---|
| Azure 以外の環境からも同じパイプラインで送信したい | AMA が使えない環境でも動かせる |
| 複数の監視バックエンドへ同時送信したい | exporter の分岐がしやすい |
| tail sampling、属性変換、フィルタリングが必要 | processor による加工が強い |
| 既存の Prometheus、Jaeger、Zipkin などと統合したい | 多様な receiver を使える |
| 中央集約型の observability gateway を作りたい | チーム横断の制御点にしやすい |
Azure Monitor の Collector 方式では、Azure Monitor クラウド取り込みエンドポイントへ送信する構成が説明されており、Collector のデプロイでは Azure 認証拡張機能を使用する Collector バージョン 0.132.0 以降が前提として示されています。(Microsoft Learn)
Azure Monitor OpenTelemetry Distro を選ぶべきケース
Azure Monitor OpenTelemetry Distro は、アプリケーションに OpenTelemetry ベースの収集を組み込み、Application Insights へ送るための現実的な入口です。公式ドキュメントでは、Application Insights が OpenTelemetry を使ってテレメトリを収集・分析できること、サーバーサイドアプリでは Distro を使う流れが示されています。(Microsoft Learn)
Distro は、次のようなケースに向いています。
| ケース | 理由 |
|---|---|
| アプリケーション単位で素早く APM を始めたい | Application Insights の体験に入りやすい |
| .NET、Java、Node.js、Python など対応言語で構成している | 言語別ガイドを使いやすい |
| ホスト側エージェントよりアプリ側設定を優先したい | 接続文字列を使った構成がしやすい |
| VM 以外の App Service、Functions、アプリ中心の設計をしている | ワークロードの種類に合わせやすい |
ただし、Distro、AMA、Collector は競合するだけの関係ではありません。組織内では、AKS はアドオン、VM/Arc は AMA、特殊な加工が必要なチームは Collector、アプリ単位の簡易導入は Distro というように、複数の標準パターンを用意するほうが現実的です。
AMA で OTLP 取り込みを検証する実務ステップ
本番環境へ一気に展開する前に、まずは検証用の VM または Arc 対応サーバーで小さく試すのが安全です。現時点ではプレビュー機能であり、Microsoft Learn でもプレビュー機能は SLA なしで提供され、運用環境のワークロードには推奨されないと説明されています。(Microsoft Learn)
検証の進め方
| ステップ | 実施内容 | 確認ポイント |
|---|---|---|
| 1. 対象ワークロードを選ぶ | VM、VMSS、Arc 対応サーバー上の小さなサービスを選定 | 影響範囲が限定されているか |
| 2. OpenTelemetry 計装を確認する | SDK、auto-instrumentation、OTLP exporter を確認 | traces、metrics、logs のどれを送るか |
| 3. Application Insights または手動リソース構成を選ぶ | 推奨は Application Insights ベースの作成 | DCR、DCE、ワークスペースの関係が明確か |
| 4. AMA のバージョンを確認する | Windows は 1.38.1 以上、Linux は 1.37.0 以上が必要 | 古い AMA が残っていないか |
| 5. DCR と対象リソースを関連付ける | DCR association を構成 | 対象 VM/Arc に正しく適用されているか |
| 6. マネージド ID と権限を設定する | Monitoring Metrics Publisher を割り当て | DCR への書き込み権限があるか |
| 7. アプリの OTLP endpoint を localhost に向ける | metrics、traces、logs の送信先を設定 | ポートを間違えていないか |
| 8. Azure Monitor で確認する | Application Insights、Log Analytics、Grafana で確認 | 欠落、重複、属性不足がないか |
AMA 方式のドキュメントでは、VM と VMSS では Windows 版 AMA 1.38.1 以上、Linux 版 AMA 1.37.0 以上が前提として記載されています。(Microsoft Learn)
アプリケーション側の設定例
AMA 方式では、アプリケーションの OTLP exporter を localhost に向けます。Microsoft Learn の例では、メトリックは 4317、ログとトレースは 4319 の gRPC ポートを使う構成が示されています。(Microsoft Learn)
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT="http://localhost:4317"
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="http://localhost:4319"
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="http://localhost:4319"
export OTEL_RESOURCE_ATTRIBUTES="microsoft.applicationId=<your-application-id>"
export OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
export OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION=base2_exponential_bucket_histogramここで特に注意したいのは、microsoft.applicationId、メトリックの temporality、ヒストグラム集計です。Application Insights の事前構築済みダッシュボードやクエリでは、OTLP メトリックに delta temporality と exponential histogram aggregation が求められると説明されています。(Microsoft Learn)
失敗しやすいポイント
OTLP のデフォルトポートと AMA のポートを混同する
一般的な OTLP gRPC の既定ポートとして 4317 を使うケースは多いですが、AMA 方式ではメトリックが 4317、ログとトレースが 4319 として示されています。既存の Collector や別プロセスが 4317 を使っている場合、ポート競合や送信先ミスが起きやすくなります。
「OTLP endpoint を localhost にしたのにデータが来ない」という場合は、まずシグナルごとのポート、gRPC/HTTP の違い、エクスポーター設定を確認してください。
DCR への権限不足で取り込みに失敗する
AMA が Azure Monitor へ送るには、対象リソースのマネージド ID に適切な権限が必要です。DCR に対して Monitoring Metrics Publisher ロールが付与されていないと、アプリ側の設定が正しくても Azure Monitor 側でデータが見えません。
SRE チームは、DCR、DCE、ワークスペース、マネージド ID、RBAC をセットでレビューするチェックリストを作ると、導入時の切り分けが速くなります。
Application Insights の体験に必要な属性が足りない
OpenTelemetry では service.name、service.version、deployment.environment などの resource attributes が重要です。さらに AMA 方式で Application Insights ベースの DCR を使う場合、microsoft.applicationId が必要になるケースがあります。
属性設計を後回しにすると、Application Map でサービス名が分かりにくい、環境別に絞り込めない、チーム別のコスト分析ができないといった問題が起きます。最初に「必須属性」「推奨属性」「禁止属性」を決めておくべきです。
Classic SDK と OpenTelemetry の二重計装
既存の Application Insights SDK から OpenTelemetry へ移行する途中では、同じリクエストが二重に送信されることがあります。特に自動計装と手動計装を混ぜる場合、リクエスト数、依存関係、例外ログが重複して見えることがあります。
移行時は、旧 SDK、Distro、OTLP exporter、Collector、AMA のどこでデータが生成・転送されているかを図にして確認してください。監視データの重複は、ノイズだけでなくコストにも直結します。
プレビュー機能を本番標準にしすぎる
AMA による OTLP ネイティブインジェストは有望ですが、現時点ではパブリックプレビューです。運用環境の全面移行を急ぐより、まずは次のような範囲で評価するのが現実的です。
| 評価項目 | 見るべきポイント |
|---|---|
| 可用性 | エージェント停止時、再起動時、ネットワーク断時の挙動 |
| データ品質 | traces、metrics、logs の欠落や属性の整合性 |
| 遅延 | インシデント対応に使える鮮度で届くか |
| コスト | ログ量、メトリック数、カーディナリティが増えすぎないか |
| 運用性 | DCR、RBAC、AMA 更新をチームで管理できるか |
プラットフォームチームが作るべき標準パターン
OpenTelemetry-on-Azure の設計で重要なのは、各チームが自由に送信方式を選びすぎないことです。自由度が高いほど、障害時の切り分け、セキュリティレビュー、コスト管理が難しくなります。
プラットフォームチームは、少なくとも次の3つの標準パターンを用意すると運用しやすくなります。
| 標準パターン | 対象 | 方針 |
|---|---|---|
| VM/Arc 標準 | Azure VM、VMSS、Arc 対応サーバー | AMA による OTLP 取り込みを検証し、DCR と RBAC をテンプレート化 |
| Kubernetes 標準 | AKS | AKS アドオンまたは Collector ベースの構成を標準化 |
| 高度加工標準 | マルチクラウド、複数送信、tail sampling | OpenTelemetry Collector を gateway として設計 |
このように分けると、チームは「どの方式が好きか」ではなく、「自分のワークロードはどの標準パターンに当てはまるか」で判断できます。
移行ロードマップ
Azure Monitor の OTLP ネイティブインジェストを評価する場合、次の順序で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | 既存の Application Insights SDK、Collector、Prometheus、ログ基盤を棚卸し | 現行のテレメトリ経路図 |
| 方針決定 | VM/Arc、AKS、マルチクラウドで標準パターンを分ける | 取り込み方式の判断表 |
| 小規模検証 | 1つのサービスで AMA OTLP 取り込みを試す | 検証結果、既知の制約 |
| データ品質確認 | Application Insights、Log Analytics、Grafana で確認 | 属性、クエリ、ダッシュボード |
| セキュリティ確認 | マネージド ID、RBAC、DCR、データ保持を確認 | 権限設計レビュー |
| コスト確認 | ログ量、メトリック数、カーディナリティを確認 | コスト試算 |
| 段階展開 | 開発、検証、本番の順に展開 | IaC、運用手順、障害対応手順 |
特にグローバルチームでは、リージョン、データ保持、個人情報、プロンプト情報、顧客データの扱いが国や事業部ごとに異なります。OpenTelemetry の導入は「データを送れるようにする作業」ではなく、「どのデータを、どの粒度で、どこへ送るか」を決めるガバナンス設計でもあります。
まず何をすべきか
Azure Monitor を使っていて、OpenTelemetry の採用や移行を検討しているなら、最初にやるべきことは3つです。
まず、現在のテレメトリ経路を図にしてください。アプリ、SDK、Collector、エージェント、DCR、ワークスペース、Application Insights の関係を見える化しないと、AMA を入れるべき場所が判断できません。
次に、VM/Arc ワークロードを1つ選び、AMA による OTLP 取り込みを検証してください。ポート、DCR、マネージド ID、メトリック temporality、Application Insights での見え方を確認します。
最後に、組織としての標準パターンを決めてください。AMA は VM/Arc の標準候補、Collector は高度加工やマルチクラウドの標準候補、Distro はアプリ単位の素早い導入候補として整理すると、チームごとの判断がぶれにくくなります。
Azure Monitor の OTLP ネイティブインジェストは、OpenTelemetry を Azure 上で本格活用するための重要な一歩です。ただし、プレビュー段階であることを踏まえ、まずは限定範囲で検証し、データ品質・運用性・コストを確認してから段階的に広げるのが実務的な進め方です。
コメント