Azure Monitor の監視基盤を OpenTelemetry に寄せたい開発者にとって、2026年4月20日に公開された Azure Monitor native OTLP ingestion via Azure Monitor Agent のパブリックプレビューは重要な更新です。結論から言うと、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバー上のアプリケーションは、OpenTelemetry の OTLP データをローカルの Azure Monitor Agent に送れるようになり、アプリ側の実装、認証、ルーティング、DCR 管理を分離しやすくなります。(マイクロソフト)
ただし、この機能はプレビュー段階であり、Microsoft はプレビュー機能を SLA なしで提供し、本番ワークロードには推奨しないと明記しています。すぐに全面移行するというより、まずは開発環境、検証環境、一部の VM ワークロードで試し、既存の Application Insights や OpenTelemetry Collector 構成と比較しながら移行判断を進めるのが現実的です。(Microsoft Learn)
Azure Monitor native OTLP ingestion via Azure Monitor Agentとは
Azure Monitor native OTLP ingestion via Azure Monitor Agent は、OpenTelemetry Protocol、つまり OTLP 形式のメトリック、ログ、トレースを Azure Monitor に取り込むための新しい経路です。
これまで Azure Monitor で OpenTelemetry を使う場合、多くの開発チームは次のような構成を選んでいました。
- アプリに Azure Monitor OpenTelemetry Distro を組み込む
- OpenTelemetry Collector を立てて Azure Monitor に送る
- AKS の場合は Azure Monitor の Kubernetes 向けアドオンを使う
- 既存の Application Insights SDK から段階的に移行する
今回の AMA 経由の OTLP 取り込みでは、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバーで動くアプリケーションが、ローカルホスト上の Azure Monitor Agent に OTLP を送信します。Azure Monitor Agent は認証と Azure Monitor エンドポイントへのルーティングを担います。(Microsoft Learn)
つまり、アプリケーション開発者は「Azure Monitor 専用の送信処理をアプリに深く埋め込む」のではなく、「OpenTelemetry SDK で標準的に計装し、OTLP エクスポート先をローカルの AMA に向ける」という考え方に近づきます。
今回の更新で実装・移行・自動化が楽になるポイント
アプリ側は「Azure Monitor固有実装」から「標準OTLP送信」に寄せやすい
開発者にとって一番分かりやすいメリットは、アプリケーション側の責務を小さくできる点です。
従来は、アプリごとに Azure Monitor Exporter や接続文字列、認証情報、送信先エンドポイントを意識する構成になりがちでした。AMA 経由の構成では、アプリは OpenTelemetry SDK でメトリック、ログ、トレースを生成し、OTLP gRPC の送信先をローカルホストに向けます。
公式ドキュメントでは、メトリックは localhost:4317、ログとトレースは 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既に service.name や deployment.environment などの属性を設定している場合は、OTEL_RESOURCE_ATTRIBUTES を上書きせず、カンマ区切りで追記する形にします。
export OTEL_RESOURCE_ATTRIBUTES="service.name=orders-api,deployment.environment=staging,microsoft.applicationId=<your-application-id>"この構成にすると、アプリケーションコードの変更を最小限に抑えながら、監視基盤側の変更を Azure Monitor Agent、DCR、IAM、Azure Policy で扱いやすくなります。
プラットフォームチームはDCR中心に収集設定を管理しやすくなる
Azure Monitor の DCR、つまり Data Collection Rule は、収集対象、変換、送信先を定義する Azure リソースです。Microsoft は DCR ベースのデータ収集について、構成方法の一貫性、取り込み前の変換、Infrastructure as Code や DevOps プロセスに対応しやすいスケーラブルな管理を利点として説明しています。(Microsoft Learn)
このため、Platform Engineering や DevOps チームは、アプリごとの個別設定ではなく、次のような単位で監視設定を管理しやすくなります。
| 管理対象 | 従来起きやすかった課題 | AMA経由OTLPで楽になる点 |
|---|---|---|
| アプリの送信先 | アプリごとに接続文字列や送信先が散らばる | OTLP送信先をローカルAMAに寄せやすい |
| 認証 | アプリ側に秘密情報を持たせがち | マネージドIDとDCRへの権限付与で整理しやすい |
| 収集ルール | 言語・サービスごとに設定が分散する | DCR/DCRAでAzureリソースとして管理できる |
| 大規模展開 | VM追加時に監視設定漏れが起きる | Azure PolicyやIaCで関連付けを自動化しやすい |
| 移行 | 一気にSDKを置き換える必要がある | ワークロード単位で段階的に検証しやすい |
特に VM や Arc 対応サーバーを多く運用している組織では、「アプリチームは OpenTelemetry に集中し、プラットフォームチームは Azure Monitor Agent と DCR を管理する」という分担がしやすくなります。
認証とルーティングをアプリから切り離せる
AMA 経由の構成では、コンピューティングリソースでシステム割り当てマネージド ID を有効化し、その ID に DCR へ書き込むための Monitoring Metrics Publisher ロールを割り当てます。公式ドキュメントでは、AMA が使うマネージド ID には DCR へデータを書き込む権限が必要とされています。(Microsoft Learn)
これは実務上かなり大きい変更です。アプリケーションの環境変数やシークレットストアに Azure Monitor の資格情報を持たせる範囲を減らし、VM や Arc サーバーの ID を起点に監視データ送信を管理できます。
ただし、これは「認証設定が不要になる」という意味ではありません。マネージド ID の有効化、DCR への RBAC、DCR と対象リソースの関連付けが必要です。ここを飛ばすと、アプリが OTLP を送っていても Azure Monitor 側にデータが出ません。
対応ワークロードと採用判断
Azure Monitor は OTLP 信号の取り込み経路として、OpenTelemetry Collector、Azure Monitor Agent、AKS アドオンの3つを示しています。AMA 経由は、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバー上のアプリケーション向けの経路です。(Microsoft Learn)
| ワークロード | AMA経由OTLPの適性 | 判断ポイント |
|---|---|---|
| Azure VM上のWeb/APIアプリ | 高い | AMAを既に使っている、またはVM監視をDCRで統一したい場合に向く |
| Virtual Machine Scale Sets | 高い | スケールアウト時のDCR関連付けをPolicyやIaCで自動化できるかが重要 |
| Azure Arc対応サーバー | 高い | オンプレ・他クラウドのサーバーをAzure Monitorに集約したい場合に有効 |
| AKS上のアプリ | 中 | AKSアドオンやCollectorとの比較が必要。AMA経由だけで考えない |
| 非Azure・非Arcのサーバー | 低 | OpenTelemetry Collector経由の方が現実的 |
| SLAが必要な本番システム | 低 | プレビュー段階のため、まず検証環境や限定的な本番外ワークロードで確認する |
OpenTelemetry Collector 経由の取り込みも引き続き選択肢です。Collector 経由では、Azure Monitor のクラウド取り込みエンドポイントへ送信し、Collector 0.132.0 以上と Azure Authentication extension が前提として示されています。非Azure環境、複数バックエンドへの同時送信、Collectorでの加工が必要な場合は、Collector構成の方が向くケースがあります。(Microsoft Learn)
実装手順の全体像
AMA 経由の OTLP 取り込みは、アプリだけで完結しません。Azure リソース、エージェント、DCR、ID、アプリ環境変数を順番にそろえる必要があります。
事前に確認すること
| 確認項目 | 見るべきポイント |
|---|---|
| アプリの計装 | OpenTelemetry SDKでメトリック、ログ、トレースを出せるか |
| ホスト環境 | Azure VM、VMSS、Azure Arc対応サーバーか |
| AMAバージョン | Windowsは1.38.1以上、Linuxは1.37.0以上か |
| DCR | Application Insightsベースで自動作成するか、手動で作るか |
| ID | システム割り当てマネージドIDを有効化できるか |
| RBAC | DCRに対してMonitoring Metrics Publisherを割り当てられるか |
| メトリック形式 | delta temporality と exponential histogram aggregation を使えるか |
AMA の最低バージョンは、VM と Virtual Machine Scale Sets のデプロイで Windows 1.38.1 以上、Linux 1.37.0 以上とされています。(Microsoft Learn)
推奨ルートはApplication InsightsのOTLPサポートを使う構成
Microsoft のドキュメントでは、ほとんどのシナリオで Application Insights ベースの方法が推奨されています。この方法では必要な Azure リソースと関係性の作成が自動化され、Application Insights のアプリケーション性能監視、分散トレース、障害分析を利用できます。(Microsoft Learn)
まず、Application Insights OTLP プレビュー機能とプロバイダーを登録します。
az feature register --name OtlpApplicationInsights --namespace Microsoft.Insights
az feature list -o table \
--query "[?contains(name, 'Microsoft.Insights/OtlpApplicationInsights')].{Name:name,State:properties.state}"
az provider register -n Microsoft.Insightsその後、Azure ポータルで Application Insights リソースを作成し、Basics タブで OTLP サポートを有効にします。作成後は Application Insights の Overview にある OTLP Connection Info から DCR リソース ID を確認します。Collectorを使う場合はトレース、ログ、メトリックのエンドポイントURLも使いますが、AMA経由ではアプリ側の送信先はローカルホストです。(Microsoft Learn)
Azure Monitor Agentを導入または更新する
Azure Monitor Agent は Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバーにインストールできます。Microsoft のドキュメントでは、Azure CLI、PowerShell、ARMテンプレート、Azure Policy など複数の導入方法が示されています。また、Azure Monitor Agent のインストール、更新、アンインストールではマシン再起動は不要とされています。(Microsoft Learn)
Azure VM に CLI で入れる場合の例は次のとおりです。
# Windows VM
az vm extension set \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.Monitor \
--ids <vm-resource-id> \
--enable-auto-upgrade true
# Linux VM
az vm extension set \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor \
--ids <vm-resource-id> \
--enable-auto-upgrade trueAzure Arc 対応サーバーの場合は、az connectedmachine extension create を使います。
# Windows Arc-enabled server
az connectedmachine extension create \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.Monitor \
--type AzureMonitorWindowsAgent \
--machine-name <arc-server-name> \
--resource-group <resource-group-name> \
--location <arc-server-location> \
--enable-auto-upgrade true
# Linux Arc-enabled server
az connectedmachine extension create \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor \
--type AzureMonitorLinuxAgent \
--machine-name <arc-server-name> \
--resource-group <resource-group-name> \
--location <arc-server-location> \
--enable-auto-upgrade true既に AMA を使っている環境では、最低バージョンを満たしているかを先に確認します。古いエージェントが混在していると、アプリ側の OTLP 設定が正しくても取り込みに失敗する可能性があります。
DCRを対象リソースに関連付ける
DCR は作成しただけでは対象 VM に適用されません。Data Collection Rule Association、つまり DCRA によって、DCR と対象リソースを関連付ける必要があります。Microsoft は DCRA を作成する方法として Azure portal、CLI、PowerShell、ARMテンプレートなどを示しています。(Microsoft Learn)
CLI で関連付ける例は次のとおりです。
az monitor data-collection rule association create \
--name "my-vm-dcr-association" \
--rule-id "<dcr-resource-id>" \
--resource "<vm-or-arc-resource-id>"大規模運用では、手作業で関連付けると漏れが起きます。新規 VM やスケールアウトしたインスタンスにも適用したい場合は、Azure Policy や IaC を使って、AMA の導入と DCR 関連付けをセットで自動化するのが現実的です。DCR関連付けは Azure Policy により複数リソースへスケールして適用でき、新しく作成された対象リソースにも関連付けを作れると説明されています。(Microsoft Learn)
手動リソースオーケストレーションを選ぶべきケース
Application Insights ベースの作成は便利ですが、すべての組織に最適とは限りません。既存の Log Analytics ワークスペースや Azure Monitor ワークスペースを使いたい、DCE/DCR の構成を細かく制御したい、複数環境でテンプレート化したい場合は、手動リソースオーケストレーションを選びます。
手動構成では、ログとトレース用の Log Analytics ワークスペース、メトリック用の Azure Monitor ワークスペースを同じ Azure リージョンに用意し、DCE と DCR を作成します。Application Insights のトラブルシューティング体験を使いたい場合は、同じリージョンに Application Insights リソースも用意します。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Application Insightsベース | 早く検証したい、APM体験を使いたい、DCR作成を自動化したい | 既存リソースの再利用や細かい構成には制約が出る可能性がある |
| 手動リソースオーケストレーション | 既存LAW/AMWを使いたい、IaCで統制したい、DCE/DCRを細かく管理したい | DCE、DCR、ワークスペース、App Insights参照の設計が必要 |
| OpenTelemetry Collector経由 | 非Azure環境、複数送信先、Collectorでの加工が必要 | Collector運用、認証拡張、バージョン管理が必要 |
| Azure Monitor OpenTelemetry Distro | 言語別のAzure Monitor統合や自動計装を使いたい | アプリ側にAzure Monitor向け設定が残りやすい |
Azure Monitor OpenTelemetry Distro は不要になるわけではありません。Microsoft は Distro について、Azure Monitor 向け機能を含む OpenTelemetry distribution であり、自動テレメトリ、カスタムテレメトリ、Live Metrics をサポートすると説明しています。コードベースのサーバーサイドアプリでは、引き続き Distro が分かりやすい選択肢になる場面があります。(Microsoft Learn)
移行判断の実務チェックリスト
AMA 経由の OTLP 取り込みは魅力的ですが、既存の監視基盤から急に切り替えると、データ欠損、二重取り込み、アラート誤発報が起きやすくなります。移行は次の順番で進めると安全です。
| ステップ | 作業 | 判断基準 |
|---|---|---|
| 現状棚卸し | Classic Application Insights SDK、Azure Monitor Distro、Collector、独自ログ送信を洗い出す | どのアプリが何を送っているか分かる |
| 対象選定 | VM/VMSS/Arc上の低リスクアプリを選ぶ | プレビュー検証に適したワークロードである |
| 並行検証 | 既存経路とAMA経由を短期間比較する | トレース、ログ、メトリックが期待通り見える |
| 重複排除 | 二重送信しているExporterや設定を整理する | 取り込みコストとノイズが増えていない |
| 自動化 | AMA、DCR、DCRA、RBACをIaC化する | 手作業なしで再現できる |
| 運用確認 | アラート、ダッシュボード、トラブルシュート手順を更新する | 障害時に誰が何を見るか明確である |
移行時に重要なのは、「OpenTelemetry になったから終わり」ではなく、「Azure Monitor 上でどの体験を使うか」まで確認することです。Application Insights では、Application dashboard、Application map、Live metrics、Search view、Failures view、Performance view、Logs、Workbooks、Grafana ダッシュボードなどの体験が用意されています。(Microsoft Learn)
つまずきやすいポイント
メトリックの形式が合わずダッシュボードに出ない
Application Insights の事前構築済みダッシュボードやクエリでは、OTLP メトリックに delta temporality と exponential histogram aggregation が必要です。受信メトリックが cumulative temporality の場合は、メトリック構成で cumulativetodelta プロセッサを使う必要があると説明されています。(Microsoft Learn)
AMA 経由の検証で「トレースは見えるがメトリックが期待通り出ない」という場合は、まずメトリックの temporality と histogram aggregation を確認します。
メトリックとログ・トレースのポートを混同する
AMA 経由の例では、メトリックは 4317、ログとトレースは 4319 です。一般的な OTLP のデフォルトポートだけを前提にしていると、ログやトレースが届かない原因になります。(Microsoft Learn)
アプリの OTLP exporter が「全シグナルを同じエンドポイントに送る」設定になっている場合は、メトリックとログ・トレースを分けられるか確認してください。
microsoft.applicationId を設定していない
Application Insights が作成した DCR を使う場合、microsoft.applicationId リソース属性が必要です。手動作成した DCR に Application Insights ID を含める場合も、取り込んだデータを Application Insights リソースごとに分離するために必要です。(Microsoft Learn)
この属性が抜けると、データは送れているように見えても、Application Insights の期待する表示や分類に乗らない可能性があります。
DCRを作っただけで満足してしまう
DCR は収集ルールであり、対象リソースへの関連付けが必要です。DCRA がない、または対象 VM と異なる DCR に関連付いている場合、AMA は期待したルールで動きません。
検証時は次の3点をセットで確認します。
- 対象 VM または Arc サーバーに AMA が入っている
- 対象 VM または Arc サーバーに DCR が関連付いている
- その DCR に対してマネージド ID が書き込み権限を持っている
プレビュー機能を本番標準にしてしまう
今回の機能はパブリックプレビューです。検証価値は高いものの、SLA が必要な本番システムで、既存の安定した監視経路をすぐに置き換える判断は慎重にすべきです。まずは本番外、または影響範囲の小さい本番周辺ワークロードで、可観測性、コスト、運用手順、障害時の切り戻しを確認します。(Microsoft Learn)
開発者・Platform Engineer・DevOpsで見るべき観点
開発者が見るべきこと
開発者は、アプリが正しく OpenTelemetry シグナルを出しているかに集中します。
特に確認すべき点は次の通りです。
service.nameが明確に設定されているか- 環境名やバージョンがリソース属性に入っているか
- トレースIDがサービス間でつながっているか
- 例外、HTTPステータス、DB呼び出しなどの重要なスパンが欠けていないか
- メトリックの temporality が Azure Monitor 側の期待に合っているか
AMA 経由になると、送信先のクラウドエンドポイントや認証処理をアプリに抱え込みにくくなります。その分、開発者は「良いテレメトリを出す」ことに注力しやすくなります。
Platform Engineerが見るべきこと
Platform Engineer は、Azure Monitor Agent、DCR、DCRA、RBAC、Azure Policy、IaC の設計を見るべきです。
特に VM や Arc 対応サーバーが多い環境では、次の設計が重要になります。
- DCRを環境別に分けるか、アプリ種別別に分けるか
- DCR名やDCRA名の命名規則をどうするか
- 新規VM作成時にAMAとDCR関連付けを自動化できるか
- 監視データの送信先ワークスペースをどのリージョンに置くか
- 権限付与を最小権限で運用できるか
DCRはAzureリソースとして管理できるため、Bicep、ARMテンプレート、Terraformなどによる再現性のある構成管理と相性が良い領域です。
DevOpsチームが見るべきこと
DevOps チームは、監視の切り替えがデプロイパイプラインや障害対応に与える影響を見ます。
具体的には、次の確認が必要です。
- アプリのデプロイ時にOTLP環境変数が正しく入るか
- 既存のアラートが新しいデータ経路でも動くか
- ダッシュボードの参照先が変わらないか
- 二重取り込みによってコストやアラート件数が増えないか
- 切り戻し時に旧Exporterや旧Collector構成へ戻せるか
監視基盤の移行は、アプリの機能リリースとは別のリスクを持ちます。CI/CD に組み込む場合も、まずは監視設定を独立した変更として扱い、データ到達とアラート挙動を確認してから本格展開するのが安全です。
まず何から試すべきか
最初の検証対象としておすすめなのは、Azure VM または Arc 対応サーバー上で動く、トラフィック量が中程度の API アプリです。トレース、ログ、メトリックが一通り出るため、AMA 経由 OTLP のメリットと課題を確認しやすいからです。
検証では、次の最小ゴールを設定します。
| ゴール | 確認内容 |
|---|---|
| トレース確認 | リクエスト単位で処理の流れを追える |
| ログ確認 | アプリログが期待した属性付きで見える |
| メトリック確認 | レイテンシ、リクエスト数、エラー率などが見える |
| 権限確認 | アプリ側に不要なAzure Monitor資格情報を持たせていない |
| 自動化確認 | AMA、DCR、DCRA、RBACを再現可能な手順で作れる |
| 切り戻し確認 | 旧経路へ戻す手順が明確である |
この検証で問題がなければ、次に同じアプリ種別の複数 VM、VMSS、Arc 対応サーバーへ展開します。いきなり全アプリへ広げるのではなく、DCR とロール割り当てのテンプレートを固めてから横展開する方が失敗しにくくなります。
Azure Monitor運用は「アプリ実装」から「収集基盤設計」へ寄っていく
Azure Monitor native OTLP ingestion via Azure Monitor Agent の価値は、単に OTLP を受け取れるようになったことではありません。より重要なのは、アプリケーション側の送信実装、Azure Monitor への認証、DCR ベースの収集ルール、VM/Arc 単位の関連付けを分離しやすくなる点です。
開発者は OpenTelemetry による計装品質を高め、Platform Engineer は AMA と DCR を標準化し、DevOps チームは移行と運用を自動化する。この分担ができると、Azure Monitor の監視基盤は個別アプリ依存から、再利用しやすいプラットフォーム設計へ近づきます。
現時点ではパブリックプレビューのため、本番標準として即採用するよりも、VM/VMSS/Arc の検証ワークロードで試し、既存の Azure Monitor OpenTelemetry Distro や OpenTelemetry Collector 構成と比較するのが現実的です。次に取るべき行動は、対象アプリを1つ選び、Application Insights の OTLP サポート、AMA の最低バージョン、DCR 関連付け、マネージド ID 権限、OTLP 環境変数の5点をそろえて、小さく検証を始めることです。
コメント