Azure Monitor を使っているチームが今回まず確認すべきことは、Azure Monitor Agent（AMA）が OTLP をネイティブに受け取り、Azure Monitor へ送信できるようになったという点です。これにより、OpenTelemetry SDK で計装したアプリケーションから、OTLP のメトリック・ログ・トレースを AMA 経由で Azure Monitor に取り込める選択肢が増えました。
ただし、2026年4月20日時点の更新では Public Preview です。すぐに本番の標準経路へ切り替えるというより、既存の監視設計・OpenTelemetry Collector の利用状況・AMA の展開範囲を確認し、検証環境で取り込み方式を評価するのが現実的な初動です。Microsoft の公式情報でも、この機能はプレビューとして案内されており、本番ワークロードには推奨されない扱いです。(マイクロソフト)
Azure Monitor native OTLP ingestion via Azure Monitor Agent の概要
今回の変更は、Azure Monitor が OpenTelemetry Protocol（OTLP）シグナルを AMA 経由で直接取り込めるようになるというものです。
従来、Azure Monitor で OpenTelemetry データを扱う場合は、OpenTelemetry Collector や AKS 向けの Azure Monitor OpenTelemetry 構成などを検討する場面が多くありました。今回の Public Preview により、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバー上で動作するアプリケーションについては、AMA を OTLP の受け口として使う構成が選べるようになります。(マイクロソフト)
実務上の意味は、単に「新しい取り込み方法が増えた」だけではありません。Azure Monitor Agent をすでに展開している組織では、OpenTelemetry の受信・認証・Azure Monitor へのルーティングを AMA 側に寄せられる可能性があります。
何が変わるのか
今回の Public Preview で特に重要なのは、アプリケーション側の OpenTelemetry 計装と、Azure Monitor 側の監視体験をつなぐ経路が増えたことです。
| 観点 | これまでの主な選択肢 | 今回追加された選択肢 |
|---|---|---|
| OTLP の受け口 | OpenTelemetry Collector など | Azure Monitor Agent |
| 主な対象 | Collector を配置できる環境、AKS など | Azure VM、VMSS、Azure Arc 対応サーバー |
| 取り込むデータ | メトリック、ログ、トレース | メトリック、ログ、トレース |
| 利用先 | Azure Monitor、Application Insights、Log Analytics など | Azure Monitor、Application Insights、Log Analytics、Azure Managed Grafana など |
| 実務での位置づけ | 柔軟だが Collector 設計が必要 | AMA 展開済み環境では構成を簡素化できる可能性 |
Microsoft Learn では、Azure Monitor の OTLP 取り込み方法として、OpenTelemetry Collector、Azure Monitor Agent、AKS add-on の3つが整理されています。今回の内容は、そのうち Azure Monitor Agent を使う OTLP 取り込み方式に関する更新です。(Microsoft Learn)
最初に確認すべき影響範囲
この更新で影響を受けやすいのは、Azure Monitor を中心に可観測性基盤を構築している Observability engineers、SRE、platform teams、cloud architects です。
特に、次のような環境では早めに確認する価値があります。
| 確認対象 | 見るべきポイント |
|---|---|
| OpenTelemetry SDK を導入済みのアプリ | OTLP の送信先を localhost の AMA に向けられるか |
| Azure VM / VMSS 上のワークロード | 必要な AMA バージョンを満たしているか |
| Azure Arc 対応サーバー | Arc 経由で AMA と DCR を管理できるか |
| Application Insights 利用環境 | OTLP データを Application Insights の分析体験に載せたいか |
| Log Analytics 利用環境 | ログ・トレースを OpenTelemetry セマンティクスでクエリしたいか |
| Grafana / Prometheus 利用環境 | OTLP メトリックを可視化・PromQL で扱う要件があるか |
逆に、AKS 中心の環境では、AKS add-on や既存の OpenTelemetry Collector 構成との比較が必要です。今回の AMA 経由方式は、主に VM、VMSS、Arc 対応プラットフォーム上のアプリケーションを対象に考えると整理しやすくなります。(Microsoft Learn)
Public Preview であることの実務上の注意点
この機能は Public Preview です。つまり、正式提供済みの GA 機能と同じ扱いで本番標準にするには慎重な判断が必要です。
Microsoft Learn では、プレビュー機能は SLA なしで提供され、本番ワークロードには推奨されない旨が明記されています。したがって、まずは検証環境や一部の非クリティカルなサービスで評価するのが安全です。(Microsoft Learn)
すぐに本番移行すべきではないケース
次の条件に当てはまる場合は、既存構成を維持しながら検証を進めるのが無難です。
| 状況 | 判断 |
|---|---|
| 本番監視の SLA が厳しい | GA まで本番標準化は見送る |
| Collector で複雑な加工・分岐をしている | AMA 方式で代替できるか慎重に検証する |
| メトリックの一時性やヒストグラム設定を細かく管理している | delta temporality など要件を確認する |
| 複数クラウド・オンプレ横断で Collector を統一している | Azure 固有構成とのバランスを見る |
| 監視データのコスト管理が未整備 | 取り込み量の増加を先に見積もる |
Public Preview は、新機能を早期に試せる一方で、仕様変更や制限が残る可能性があります。監視基盤は障害対応の土台になるため、「動いたから採用」ではなく、「障害時に運用できるか」で判断することが重要です。
AMA 経由 OTLP 取り込みの基本構成
AMA 経由で OTLP を取り込む場合、アプリケーション、AMA、Data Collection Rule（DCR）、送信先リソースの関係を理解しておく必要があります。
基本的な流れは次のとおりです。
| ステップ | 内容 |
|---|---|
| アプリを OpenTelemetry SDK で計装 | メトリック、ログ、トレースを OTLP で出力する |
| AMA を対象サーバーに展開 | VM、VMSS、Arc 対応サーバーに Azure Monitor Agent をインストールする |
| DCR を構成 | どのデータをどこへ送るかを定義する |
| DCR を対象リソースに関連付け | 計装済みアプリが動くサーバーに DCR を紐づける |
| マネージド ID と権限を設定 | AMA が DCR へデータを書き込めるようにする |
| Azure Monitor 側で確認 | Application Insights、Log Analytics、Grafana などで可視化・分析する |
重要なのは、アプリケーションが Azure Monitor のクラウドエンドポイントへ直接送るのではなく、ローカルの AMA に OTLP を送信し、AMA が認証とルーティングを担当する点です。Microsoft Learn でも、AMA が Azure Monitor エンドポイントへの認証とルーティングを処理すると説明されています。(Microsoft Learn)
利用前に確認すべき前提条件
検証を始める前に、次の前提条件を確認します。
| 項目 | 確認内容 |
|---|---|
| Azure サブスクリプション | 対象リソースを作成・変更できる権限があるか |
| アプリケーション | OpenTelemetry SDK で計装されているか |
| 対象環境 | Azure VM、VMSS、Azure Arc 対応サーバーか |
| AMA バージョン | Windows は 1.38.1 以上、Linux は 1.37.0 以上か |
| DCR | OTLP データの収集先・送信先を定義できているか |
| 認証 | システム割り当てマネージド ID と権限設定ができているか |
Microsoft Learn では、VM および VMSS 向けの前提として、Windows の AMA は 1.38.1 以上、Linux の AMA は 1.37.0 以上が必要とされています。(Microsoft Learn)
実務では、AMA のバージョン確認を後回しにすると検証が詰まりやすくなります。既存のエージェント展開ポリシーや自動更新設定を確認し、対象サーバーが必要バージョンを満たすか先に棚卸ししておくとスムーズです。
推奨される構成方法は Application Insights ベース
Microsoft Learn では、OTLP データ取り込みの構成方法として、主に2つのアプローチが示されています。
1つ目は、OTLP サポートを有効にした Application Insights リソースを作成する方法です。多くのシナリオではこちらが推奨されています。
2つ目は、Data Collection Endpoint（DCE）、Data Collection Rule（DCR）、送信先ワークスペースなどを手動で構成する方法です。こちらは、既存リソースを再利用したい場合や、より細かいカスタム構成が必要な場合に向いています。(Microsoft Learn)
| 構成方法 | 向いているケース | 注意点 |
|---|---|---|
| Application Insights ベース | 初回検証、標準的な APM、トラブルシューティング体験を使いたい場合 | 作成される関連リソースを把握しておく |
| 手動オーケストレーション | 既存の LAW / AMW / DCR を再利用したい場合、設計を細かく制御したい場合 | DCE、DCR、送信先、Application Insights 参照の整合性管理が必要 |
最初の検証では、Application Insights ベースで動作を確認し、その後に既存の監視アーキテクチャへどう組み込むかを検討すると失敗しにくくなります。
アプリケーション側で必要になる設定
AMA 経由で OTLP を送る場合、アプリケーション側では OpenTelemetry SDK の OTLP exporter 設定が重要です。
Microsoft Learn では、メトリックは gRPC の localhost:4317、ログとトレースは gRPC の localhost:4319 に送る構成が示されています。また、Application Insights ベースの DCR を使う場合などには、microsoft.applicationId リソース属性の設定が必要です。(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ここで注意したいのは、メトリックとログ・トレースでポートが分かれている点です。既存の OTLP exporter がすべてのシグナルを同じエンドポイントへ送る設定になっている場合、シグナルごとに送信先を分ける必要が出る可能性があります。
メトリック設定でつまずきやすいポイント
今回の変更で見落としやすいのが、OTLP メトリックの temporality と histogram aggregation です。
Microsoft Learn では、Application Insights の体験、事前構成済みダッシュボード、クエリでは、OTLP メトリックに delta temporality と exponential histogram aggregation が必要とされています。さらに、入力メトリックが cumulative temporality の場合は、metrics config に processors: [cumulativetodelta] を追加するよう案内されています。(Microsoft Learn)
実務では、次の観点で確認してください。
| 確認項目 | 失敗しやすい例 | 対応 |
|---|---|---|
| temporality | cumulative のまま送って期待した表示にならない | delta へ変換・設定する |
| histogram | 既存の集計方式が Application Insights の期待と合わない | exponential histogram aggregation を確認する |
| exporter 設定 | メトリック・ログ・トレースを同じポートへ送っている | シグナルごとに endpoint を分ける |
| resource attributes | Application Insights 側でデータ分離できない | microsoft.applicationId を設定する |
このあたりは、単に接続確認だけでは問題が見えにくい領域です。検証時は「データが届いたか」だけでなく、「Application Insights や Grafana で期待どおりに見えるか」まで確認する必要があります。
認証と権限で確認すべきこと
AMA が Azure Monitor へデータを送るには、対象コンピュートリソースのシステム割り当てマネージド ID を有効にし、必要な権限を付与する必要があります。
Microsoft Learn では、マネージド ID に対して Monitoring Metrics Publisher ロールを割り当て、AMA が DCR へデータを書き込めるようにする手順が示されています。(Microsoft Learn)
実務では、次の点を確認しておくとトラブルを減らせます。
| 確認項目 | 内容 |
|---|---|
| マネージド ID | 対象 VM / VMSS / Arc 対応サーバーで有効か |
| ロール割り当て | DCR に対して Monitoring Metrics Publisher が付与されているか |
| スコープ | サブスクリプション全体ではなく、必要最小限の範囲で付与できるか |
| 変更管理 | 誰がいつ権限を付与したか監査できるか |
| IaC 管理 | Bicep、ARM、Terraform などで再現可能か |
権限設定は、検証ではポータル操作で済ませがちです。しかし、SRE や platform team が本格導入を検討する場合は、DCR、DCE、ロール割り当て、AMA 展開を IaC で管理できる状態にすることが重要です。
OpenTelemetry Collector 構成との使い分け
AMA 経由の OTLP 取り込みが追加されたからといって、OpenTelemetry Collector が不要になるわけではありません。
Collector は、フィルタリング、サンプリング、属性加工、複数バックエンドへの分岐、ベンダー横断の可観測性基盤などに強みがあります。一方、AMA 経由の取り込みは、Azure VM や Arc 対応サーバー上で Azure Monitor を主な監視先にする場合、構成をシンプルにできる可能性があります。
| 判断軸 | AMA 経由が向いているケース | Collector が向いているケース |
|---|---|---|
| 主な監視先 | Azure Monitor 中心 | 複数バックエンドへ送信 |
| 実行環境 | Azure VM、VMSS、Arc 対応サーバー | Kubernetes、オンプレ、複数クラウドなど幅広い環境 |
| データ加工 | 最小限でよい | 属性加工、フィルタ、サンプリングが必要 |
| 運用体制 | AMA を標準エージェントとして管理済み | Collector の運用ノウハウがある |
| 設計思想 | Azure ネイティブに寄せたい | ベンダーニュートラル性を重視したい |
クラウドアーキテクトの視点では、「どちらが優れているか」ではなく、「どのレイヤーで標準化するか」が論点になります。Azure Monitor を中心にした VM 系ワークロードでは AMA 経由を検証し、マルチクラウドや高度なテレメトリ加工が必要な領域では Collector を残す、という併用設計も現実的です。
Azure Monitor 利用者が取るべき初動
今回の Public Preview に対して、Azure Monitor 利用者が最初に行うべきことは、いきなり設定変更することではありません。まずは対象範囲を切り分け、検証計画を作ることです。
既存環境を棚卸しする
最初に、どのワークロードが今回の対象になり得るかを確認します。
| 棚卸し項目 | 確認例 |
|---|---|
| 実行基盤 | Azure VM、VMSS、Arc 対応サーバー上のアプリはどれか |
| 計装状況 | OpenTelemetry SDK を導入済みか、今後導入予定か |
| 既存監視 | Application Insights、Log Analytics、Grafana の利用状況 |
| エージェント | AMA が導入済みか、バージョンは要件を満たすか |
| データ量 | メトリック、ログ、トレースの取り込み量がどの程度か |
| 運用要件 | 障害時の調査フローに組み込めるか |
この棚卸しにより、「検証すべきサービス」と「当面影響なしのサービス」を分けられます。
小さく検証する
次に、非本番環境で小さく検証します。
おすすめは、1つのアプリケーションを選び、メトリック・ログ・トレースの3種類を取り込めるか確認する方法です。単にデータ到達を確認するだけではなく、次の観点まで見ると実務に近い評価になります。
| 検証観点 | チェック内容 |
|---|---|
| 接続 | OTLP データが AMA 経由で Azure Monitor に届くか |
| 可視化 | Application Insights や Grafana で期待どおり表示されるか |
| クエリ | Log Analytics でログ・トレースを調査できるか |
| 遅延 | 障害調査に耐える取り込み遅延か |
| 欠損 | 再起動や負荷時にデータ欠損が起きないか |
| コスト | 取り込み量が想定より増えていないか |
| 運用 | SRE がアラートから原因調査まで辿れるか |
検証結果は、単なる作業メモではなく、監視設計の判断材料として残しておくとよいでしょう。
本番適用の判断基準を決める
Public Preview の段階では、本番適用するかどうかの判断基準を明確にしておく必要があります。
たとえば、次のような基準です。
| 判断基準 | 採用に進めやすい状態 |
|---|---|
| 機能面 | 必要なメトリック、ログ、トレースが欠損なく扱える |
| 運用面 | 障害時の調査手順が既存フローに組み込める |
| セキュリティ | マネージド ID と RBAC が最小権限で管理できる |
| コスト | 取り込み量と保存期間の見積もりができている |
| 標準化 | AMA、DCR、権限、アプリ設定を IaC 化できる |
| リスク | Preview の制約を受け入れられる対象に限定している |
特に本番導入では、「監視データが取れる」だけでは不十分です。障害時に誰が、どの画面で、どのクエリを使い、何分以内に原因を絞り込めるかまで確認してください。
変更対応でよくある失敗
今回のような監視基盤の更新では、技術的には接続できても、運用でつまずくことがあります。
既存の Collector 構成を置き換える前提で進めてしまう
AMA 経由の OTLP 取り込みは便利な選択肢ですが、既存の OpenTelemetry Collector 構成をすべて置き換える前提で考えると失敗しやすくなります。
Collector でサンプリング、属性付与、送信先分岐、データ削減を行っている場合、それらを AMA 経由構成でどう扱うかを確認する必要があります。まずは「Collector をなくせるか」ではなく、「Azure Monitor 向けの一部経路を AMA に寄せられるか」と考える方が現実的です。
Application Insights での見え方を確認しない
OTLP データが Azure Monitor に届いても、Application Insights の画面や事前構成済みダッシュボードで期待どおり見えるとは限りません。特にメトリックの temporality や histogram aggregation は、表示結果に影響します。(Microsoft Learn)
検証時は、データ到達確認に加えて、APM、分散トレーシング、失敗分析、ダッシュボード、クエリの見え方を必ず確認してください。
権限設定を手作業のままにする
検証ではポータルから権限を付与しても構いません。しかし、本番や複数環境へ展開する場合、手作業の RBAC 設定は再現性と監査性の問題になります。
AMA、DCR、DCR association、マネージド ID、Monitoring Metrics Publisher ロールの割り当ては、可能な限り IaC 化しておくべきです。
データ量とコストを後回しにする
OpenTelemetry を導入すると、可視性が上がる一方で、メトリック、ログ、トレースの取り込み量が増えることがあります。特にトレースや高カーディナリティなメトリックは、設計次第でデータ量が膨らみます。
検証段階で、取り込み量、保存期間、サンプリング方針、ログの粒度を確認しておくことが重要です。
チーム別の確認ポイント
今回の更新は、関係者ごとに見るべきポイントが異なります。
| 役割 | 最初に確認すべきこと |
|---|---|
| Observability engineer | 既存の OTel / Collector / Azure Monitor 設計に AMA 経由をどう位置づけるか |
| SRE | 障害調査フロー、アラート、ダッシュボードに組み込めるか |
| Platform team | AMA 展開、DCR association、RBAC を標準化できるか |
| Cloud architect | Azure ネイティブ構成とマルチクラウド標準化のバランス |
| Security / Governance | マネージド ID、最小権限、監査ログ、変更管理 |
| Application team | OTLP exporter 設定、resource attributes、計装コードへの影響 |
組織内で検討する場合は、Platform team だけで判断せず、SRE と Application team を巻き込むことが大切です。監視基盤の変更は、最終的には障害対応とアプリケーション改善の速度に影響するためです。
実務でのおすすめ検証シナリオ
最初の検証では、複雑な全社標準化を目指すより、次のような小さなシナリオから始めると評価しやすくなります。
| シナリオ | 目的 |
|---|---|
| VM 上の単一アプリを OTel SDK で計装 | AMA 経由の基本動作を確認する |
| Application Insights ベースで DCR を作成 | 推奨構成の動作とリソース関係を把握する |
| メトリック・ログ・トレースを同時に送信 | シグナルごとの表示・クエリを確認する |
| Grafana で OTLP メトリックを確認 | 可視化と PromQL 利用の実用性を見る |
| 障害を意図的に発生させる | トレース、ログ、メトリックから原因を追えるか確認する |
| 負荷をかけてデータ量を見る | コストと高カーディナリティの影響を確認する |
特に、障害を意図的に発生させる検証は有効です。正常系だけでは、監視基盤が本当に役立つか分かりません。HTTP エラー、依存サービスの遅延、CPU 負荷、アプリケーション例外などを発生させ、Azure Monitor 側でどこまで追跡できるか確認してください。
まとめ：まずは対象ワークロードの棚卸しと小規模検証から始める
Azure Monitor native OTLP ingestion via Azure Monitor Agent の Public Preview は、OpenTelemetry を Azure Monitor で活用するチームにとって重要な更新です。Azure VM、VMSS、Azure Arc 対応サーバー上のアプリケーションでは、AMA を OTLP の受け口として使い、Application Insights、Log Analytics、Grafana などにつなげる構成を検討できるようになりました。(マイクロソフト)
一方で、現時点では Public Preview です。本番の監視標準へ即時移行するのではなく、次の順番で進めるのが現実的です。
- Azure VM、VMSS、Arc 対応サーバー上の対象アプリを棚卸しする
- OpenTelemetry SDK の導入状況と OTLP exporter 設定を確認する
- AMA のバージョンと展開方法を確認する
- Application Insights ベースの推奨構成で小さく検証する
- メトリック、ログ、トレースの表示・クエリ・障害調査フローを確認する
- Collector 構成との使い分け、RBAC、IaC、コストを整理する
最初の一歩としては、非本番環境の1つのアプリを選び、AMA 経由で OTLP データを取り込めるか検証するのがよいでしょう。その結果をもとに、既存の Azure Monitor 設計に組み込むべきか、Collector と併用すべきか、GA まで待つべきかを判断できます。
コメント