Azure Monitor の preview で注目すべき点は、OpenTelemetry で計装したアプリケーションの OTLP データを、Azure Monitor Agent（AMA）経由で Azure Monitor に取り込めるようになったことです。2026年4月20日時点の更新では、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応プラットフォームで、AMA がアプリから OTLP を受け取り、Azure Monitor へ転送する public preview として案内されています。(Microsoft)
結論から言うと、この Azure Monitor preview は「監視ツールの新機能」というより、VM やハイブリッド環境での監視ワークフローを整理するための選択肢です。特に、OpenTelemetry Collector を各所に立てるほどではないが、標準化された OTLP でトレース・メトリック・ログを集めたい Power users、admins、solution owners に向いています。ただし preview 機能は SLA なしで提供され、Microsoft Learn でも本番ワークロードには推奨されていないため、まずは非本番環境や限定的なサービスで検証するのが現実的です。(Microsoft Learn)
Azure Monitor の preview で何が変わるのか
今回の更新の本質は、OpenTelemetry のデータ取り込み経路に「AMA 経由」という現場になじみやすいルートが加わったことです。
従来、OpenTelemetry のテレメトリを Azure Monitor に送る場合、アプリケーション側の Azure Monitor OpenTelemetry Distro、OpenTelemetry Collector、AKS 向けの統合機能など、ワークロードごとに経路を選ぶ必要がありました。今回の preview では、Azure VM、VM Scale Sets、Azure Arc 対応サーバー上のアプリケーションについて、ホスト上の Azure Monitor Agent が OTLP の受け口になります。(Microsoft Learn)
これにより、運用上の考え方が次のように変わります。
| 従来の悩み | AMA 経由の OTLP ingestion で変わる点 |
|---|---|
| 各アプリや各サーバーで Collector の配置・更新・認証設定を管理する必要がある | AMA をホスト側の共通受け口として扱いやすくなる |
| アプリチームとインフラチームの責任分界が曖昧になりやすい | アプリ側は OpenTelemetry SDK と OTLP 送信、運用側は AMA・DCR・ID・Azure Monitor 側を管理しやすい |
| VM と Arc 対応サーバーで監視設計がばらつく | Azure VM、VMSS、Arc 対応環境で近い考え方を使える |
| 独自 SDK やベンダー依存の監視設計から抜けにくい | OTLP を前提にし、将来の監視基盤変更にも備えやすい |
重要なのは、「Collector が不要になる」と単純化しすぎないことです。Collector には変換、フィルタリング、複数送信先への分岐、複雑なプロセッサ構成といった強みがあります。AMA 経由は、VM や Arc 対応サーバーでシンプルなホストレベルの取り込み経路を作りたい場合に有力な選択肢です。
現場のワークフローはどう変わるか
アプリチームは「Azure Monitor 専用」ではなく OTLP を意識すればよくなる
アプリケーション開発者にとっての大きな変化は、監視先の実装を Azure 固有のコードだけで考える必要が薄れることです。
OpenTelemetry SDK でトレース、メトリック、ログを出し、OTLP exporter の送信先をローカルの AMA に向ける構成が取りやすくなります。Microsoft Learn では、メトリックは localhost:4317、ログとトレースは localhost:4319 の gRPC エンドポイントに送る例が示されています。(Microsoft Learn)
たとえば、API サーバーを運用しているチームなら、次のような分担が可能です。
| 担当 | 作業内容 |
|---|---|
| アプリチーム | OpenTelemetry SDK の導入、service.name や環境名などの属性設計、OTLP exporter の設定 |
| インフラ・運用チーム | AMA の導入・更新、Data Collection Rule（DCR）の関連付け、Managed Identity と権限設定 |
| SRE・監視担当 | Application Insights、Log Analytics、Grafana での可視化、アラート条件、障害時の調査手順整備 |
| solution owner | 本番適用可否、コスト、データ保持、監査要件、preview 利用リスクの判断 |
この分担にすると、アプリチームは「どの監視基盤へ送るか」よりも、「どのテレメトリを、どの名前と属性で出すか」に集中できます。運用側は、送信先や認証、DCR の適用範囲を中央管理しやすくなります。
管理者は DCR と Managed Identity を中心に運用できる
admins にとっては、DCR と Managed Identity がワークフローの中心になります。
AMA 経由で OTLP を取り込む場合、Application Insights の OTLP support を有効にしてリソースを作成する方法と、Data Collection Endpoint（DCE）、DCR、Log Analytics workspace、Azure Monitor workspace などを手動で構成する方法があります。Microsoft Learn では、多くのシナリオで Application Insights ベースの方法が推奨されています。(Microsoft Learn)
手動構成が向いているのは、既存のワークスペースを使い回したい場合、監視データの保存先を細かく分けたい場合、組織の命名規則やリージョン設計に合わせたい場合です。一方で、初回検証や標準的なアプリ監視では、Application Insights から始めた方が作業ミスを減らせます。
また、AMA が Azure Monitor endpoint への認証とルーティングを担うため、コンピュートリソースには system-assigned managed identity を有効化し、その ID に DCR への書き込み権限として Monitoring Metrics Publisher ロールを割り当てる必要があります。(Microsoft Learn)
障害対応は「画面を切り替える」より「同じ文脈で掘る」流れになる
今回の preview が実務で効くのは、障害対応の流れです。
Azure Monitor に取り込まれた OTLP データは、Application Insights でアプリケーションのパフォーマンス監視、トリアージ、トラブルシューティングに使えます。メトリックは Grafana ダッシュボードや Prometheus query language、ログとトレースは Log Analytics で確認できると案内されています。(Microsoft)
たとえば、EC サイトの注文 API で応答遅延が発生した場合、現場の動きは次のように変わります。
| 調査ステップ | 使う画面・データ | 見るポイント |
|---|---|---|
| 影響範囲の確認 | Application Insights の Performance、Failures | どの API、どの依存先、どの時間帯で悪化したか |
| 系統的な遅延確認 | Grafana / メトリック | CPU、リクエスト数、レイテンシ、キュー長などの変化 |
| 1リクエストの深掘り | トレース | フロントエンド、API、DB、外部サービスのどこで時間を使ったか |
| 原因候補の確認 | Log Analytics | 同じ trace id や service name に紐づくエラー、警告、例外 |
| 再発防止 | アラート・Workbook・ダッシュボード | しきい値、SLO、失敗率、依存先別の監視を整備 |
ポイントは、単に「ログが見える」ことではありません。トレース、メトリック、ログを同じ OpenTelemetry の文脈で扱いやすくなるため、アプリ・インフラ・運用の調査会話がそろいやすくなります。
具体的な利用シナリオ
シナリオ1: VM 上の業務アプリを OpenTelemetry 化する
最も分かりやすいシナリオは、Azure VM 上で動いている社内向け Web アプリや API の監視です。
これまで、Application Insights SDK を直接入れていたり、OS ログとアプリログを別々に見ていたりする環境では、障害調査時に「アプリの処理時間」「DB 呼び出し」「ログ上の例外」「VM の状態」を別々に追うことが多くなります。
AMA 経由の OTLP ingestion を使う検証では、次の流れが現実的です。
| 手順 | 実施内容 | 判断ポイント |
|---|---|---|
| 対象を選ぶ | 低リスクな API、バッチ、社内アプリを選定 | 本番直結ではなく、非本番または限定サービスから始める |
| 計装する | OpenTelemetry SDK を導入 | service.name、環境名、バージョンなどを決める |
| 送信先を設定する | OTLP exporter を localhost の AMA エンドポイントへ向ける | メトリック、ログ、トレースのポートを混同しない |
| AMA を準備する | 必要バージョン以上の AMA を導入 | VM / VMSS では Windows 1.38.1 以上、Linux 1.37.0 以上が前提 |
| DCR を関連付ける | 対象 VM に DCR を関連付ける | 検証対象だけに絞り、影響範囲を限定する |
| 可視化する | Application Insights、Log Analytics、Grafana で確認 | データ欠損、属性名、コストを確認する |
Microsoft Learn では、VM と Virtual Machine Scale Sets で Windows 版 AMA 1.38.1 以上、Linux 版 AMA 1.37.0 以上が前提条件として示されています。(Microsoft Learn)
このシナリオでの成功条件は、最初から全アプリを対象にしないことです。1つの API、1つのバッチ、1つのサービス単位で「期待したトレースが出るか」「ログと関連付けられるか」「メトリックが使える粒度か」を確認してから広げます。
シナリオ2: VM Scale Sets のマイクロサービス監視を標準化する
VM Scale Sets 上で複数の API やワーカーを動かしている場合、監視設定がインスタンスごとにばらつくと、スケールアウト時に抜け漏れが起きます。
AMA 経由の preview を使う場合は、VMSS に対して DCR を関連付け、アプリケーション側は OpenTelemetry の設定をイメージや起動スクリプトに組み込む形が考えられます。
このとき重要なのは、サービス名とロール名の設計です。
悪い例は、すべてのサービスが app や web のような名前で送信される状態です。これでは Application Map やログ検索で区別しづらくなります。
良い例は、次のような命名です。
| 属性 | 例 | 目的 |
|---|---|---|
service.name | order-api、payment-worker | サービス単位でトレースとメトリックを分ける |
deployment.environment | dev、staging、prod | 環境別に調査・集計する |
service.version | 2026.04.20、v3.1.0 | リリース後の不具合切り分けに使う |
cloud.role 相当の情報 | API 名、ワーカー名 | Application Insights 側の見え方を整理する |
VMSS では「どのインスタンスが悪いか」だけでなく、「どのサービスのどのバージョンが悪いか」が重要です。OpenTelemetry の属性設計を先に決めておくと、スケール後も調査しやすい監視になります。
シナリオ3: Azure Arc 対応サーバーでハイブリッド監視を寄せる
オンプレミスや他クラウドのサーバーを Azure Arc 対応にしている組織では、監視の分断が課題になりがちです。アプリはオンプレミス、監視は Azure、運用チームはグローバルに分散、という構成では、障害発生時に「どこを見ればよいか」が決まっていないだけで復旧が遅れます。
今回の preview は Azure Arc 対応プラットフォームも対象としているため、Arc 対応サーバー上のアプリケーションから OTLP データを AMA 経由で Azure Monitor に送る検証ができます。(Microsoft)
グローバル運用で特に役立つのは、次のような場面です。
| 場面 | 期待できる効果 |
|---|---|
| 国や拠点ごとに異なる監視ツールを使っている | Azure Monitor 側に調査入口を寄せやすい |
| オンプレミス API と Azure 上の API が連携している | 分散トレースで依存関係を追いやすくなる |
| 運用担当が時差のある複数拠点にいる | Application Insights や Log Analytics の共通ビューで引き継ぎやすい |
| 監視設定の属人化が進んでいる | AMA、DCR、Managed Identity を軸に運用ルールを作りやすい |
ただし、Arc 対応サーバーではネットワーク経路、プロキシ、ファイアウォール、ID 管理の設計がボトルネックになりやすいです。preview 検証では、テレメトリが届くかだけでなく、再起動後、ネットワーク断後、エージェント更新後の挙動も確認しておくべきです。
AMA、Collector、AKS アドオンはどう使い分けるか
Azure Monitor の OTLP ingestion では、どの経路を使うかの判断が重要です。間違えると、余計な運用コンポーネントが増えたり、必要なテレメトリが欠けたりします。
| 選択肢 | 向いている環境 | 向いているケース |
|---|---|---|
| Azure Monitor Agent 経由 | Azure VM、VMSS、Azure Arc 対応サーバー | ホストレベルのエージェントで認証とルーティングを簡素化したい |
| OpenTelemetry Collector 経由 | Azure 外を含む幅広い環境 | データ加工、フィルタリング、複数送信先、柔軟な構成が必要 |
| AKS アドオン | Azure Kubernetes Service | クラスター統合の監視、namespace や deployment 単位の管理を重視する |
| Azure Monitor OpenTelemetry Distro | 対応言語のアプリ | アプリコード側から Application Insights へ分かりやすく送信したい |
Microsoft Learn でも、AMA 経由は VM、VMSS、Arc 対応サーバーでホストレベルのエージェントに認証とルーティングを任せたい場合、Collector 経由は最大限の柔軟性や Azure Monitor Agent が使えない環境で使う場合、AKS アドオンは AKS 上のコンテナー化アプリで使う場合に整理されています。(Microsoft Learn)
現場判断では、次のように考えると迷いにくくなります。
まず、対象が AKS なら AKS 向けの経路を優先します。対象が Azure VM、VMSS、Arc 対応サーバーで、複雑な加工が不要なら AMA 経由を検証します。複数の監視先へ同時送信したい、属性変換を細かく制御したい、Azure 外の環境を広く含めたい場合は Collector を検討します。
preview 検証で失敗しやすいポイント
本番適用を急ぎすぎる
public preview は、利用者が試せる段階であって、全面的に本番標準へ採用する段階とは限りません。特に監視基盤は障害時に使う最後の拠り所です。preview 機能だけに本番監視を依存させると、データ欠損や仕様変更が起きたときにリスクが大きくなります。
おすすめは、既存の監視を残したまま、限定サービスで並行検証する方法です。
| 検証項目 | 確認すること |
|---|---|
| データ到達性 | トレース、メトリック、ログが期待通り届くか |
| 相関性 | trace id でログとトレースを追えるか |
| 可視化 | Application Insights や Grafana で運用に使える形になるか |
| アラート | 既存のアラートと同等以上の検知ができるか |
| コスト | 取り込み量、ログ量、高カーディナリティ属性が増えすぎないか |
| 復旧手順 | AMA 停止、DCR 設定ミス、ID 権限不足時に切り戻せるか |
OTLP のポート設定を一般的なサンプルのまま流用する
OpenTelemetry のサンプルでは、OTLP gRPC の 4317 や HTTP の 4318 を見る機会が多いです。しかし AMA 経由の preview では、Microsoft Learn の例でメトリックが localhost:4317、ログとトレースが localhost:4319 と示されています。(Microsoft Learn)
そのため、既存の Collector 向け設定をそのまま移植すると、トレースだけ届かない、ログだけ見えない、といった切り分けに時間がかかる可能性があります。検証時は、シグナルごとの endpoint を明示的に分けて確認しましょう。
メトリックの temporality と histogram を見落とす
Application Insights の事前構築済みダッシュボードやクエリでは、OTLP メトリックに delta temporality と exponential histogram aggregation が求められると説明されています。累積メトリックを送っている場合は、変換設定が必要になる可能性があります。(Microsoft Learn)
ここを見落とすと、「データは届いているのに、期待したグラフにならない」「レイテンシ分布が扱いにくい」という状態になります。メトリックは届けばよいのではなく、運用画面で読める形になっているかまで確認しましょう。
属性を増やしすぎてコストと検索性を悪化させる
OpenTelemetry は属性を柔軟に付けられますが、何でも入れると失敗します。ユーザーID、注文ID、セッションID、URL の可変パスなどを無制限にメトリック属性へ入れると、カーディナリティが急増し、コストや可視化の扱いやすさに影響します。
実務では、属性を次の3種類に分けると設計しやすくなります。
| 属性の種類 | 例 | 方針 |
|---|---|---|
| 必ず入れる属性 | サービス名、環境名、リージョン、バージョン | 全サービスで標準化する |
| 調査に使う属性 | HTTP method、依存先名、エラー種別 | 必要な粒度で付ける |
| 慎重に扱う属性 | ユーザーID、注文ID、全文 URL、プロンプト本文 | ログやトレースで扱う場合もマスキングと保持期間を検討する |
特にグローバル読者向けのサービスでは、プライバシー、データ所在地、監査要件も確認が必要です。監視データは「技術ログ」ではありますが、業務上の識別子や個人情報に近い情報が混ざることがあります。
導入前に決めておくべき運用ルール
Azure Monitor の preview を試す前に、技術設定より先に決めておくべきことがあります。
| 決めること | 具体例 |
|---|---|
| 対象範囲 | まずは staging の order-api のみ、など |
| 成功条件 | p95 レイテンシ、失敗率、依存先呼び出し、主要ログが確認できる |
| 命名規則 | service.name、環境名、DCR 名、Application Insights 名 |
| 権限設計 | Managed Identity、DCR へのロール割り当て、閲覧権限 |
| 切り戻し | 既存監視を残す期間、AMA 設定変更時のロールバック手順 |
| コスト確認 | 1日あたりの取り込み量、保持期間、不要ログの削減 |
| 本番判断 | preview の制約を受け入れる範囲、正式リリース後の移行計画 |
ここを曖昧にしたまま始めると、「データは出たが運用で使えない」という状態になりがちです。特に solution owner は、機能の有無だけでなく、責任分界、コスト、リスク、既存運用との整合性を見て判断する必要があります。
まず何から始めるべきか
最初の一歩は、全社標準化ではなく、小さな業務フローの検証です。
おすすめは、次の順番です。
- Azure VM または Arc 対応サーバー上の低リスクなアプリを1つ選ぶ
- 既存の監視で見ている障害パターンを3つ洗い出す
- OpenTelemetry SDK を入れ、サービス名と環境名を標準化する
- AMA、DCR、Managed Identity を準備する
- OTLP のトレース、メトリック、ログを送る
- Application Insights、Log Analytics、Grafana で障害調査が再現できるか確認する
- コスト、データ欠損、アラート、切り戻しを評価する
Azure Monitor の native OTLP ingestion via Azure Monitor Agent は、監視の入口を増やすだけの preview ではありません。VM、VMSS、Arc 対応サーバーを中心に、アプリチームと運用チームの分担を整理し、OpenTelemetry を軸にした監視へ移行するきっかけになります。
ただし、preview である以上、いきなり本番監視の中核に置くのは避けるべきです。まずは非本番または限定サービスで、既存監視と並行しながら「障害時に本当に使えるか」を検証してください。導入判断は、データが届いたかではなく、現場のトリアージ、原因調査、再発防止までのワークフローが短くなるかで見るのが最も実践的です。
コメント