Azure Monitor の管理者がまず確認すべき結論は、「Azure Monitor native OTLP ingestion via Azure Monitor Agent」は、OpenTelemetry で計装済みのアプリケーションから OTLP データを Azure Monitor Agent 経由で取り込むためのパブリックプレビュー機能だという点です。2026年4月20日の Azure Updates では、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応プラットフォーム上のワークロードを対象に、AMA が OTLP を受け取り Azure Monitor へ送信できるようになったと発表されています。(Microsoft)
ただし、これは発表直後に本番へ一斉展開する機能ではありません。Microsoft Learn でも、この機能はプレビューであり、SLA なしで提供され、本番ワークロードには推奨されないと明記されています。(Microsoft Learn) そのため管理者は、既存の監視設計を置き換える前に、対象範囲、Azure Monitor Agent のバージョン、DCR、マネージド ID、アプリケーション側の OTLP 設定、運用部門への周知内容を順番に確認する必要があります。
この記事では、Azure Monitor の管理者、運用責任者、展開計画担当者向けに、Azure Monitor native OTLP ingestion via Azure Monitor Agent の導入判断、設定差分、展開順序、社内周知に使えるチェックリストをまとめます。
Azure Monitor native OTLP ingestion via Azure Monitor Agent で何が変わるのか
今回の更新で重要なのは、OpenTelemetry の OTLP 信号を Azure Monitor Agent がローカルで受け取り、Azure Monitor へ送れるようになった点です。これにより、OpenTelemetry SDK で計装したアプリケーションは、Azure Monitor Agent を経由して Application Insights、Log Analytics、Azure Monitor workspace などの Azure Monitor 側の監視体験につなげやすくなります。(Microsoft)
Microsoft Learn では、Azure Monitor が OTLP 信号を受け取る方法として、OpenTelemetry Collector、Azure Monitor Agent、AKS アドオンの3種類が整理されています。そのうち AMA 経由の方式は、Azure VM、Virtual Machine Scale Sets、Azure Arc 対応サーバー上で動くアプリケーションから OTLP データを取り込む方法です。(Microsoft Learn)
管理者視点では、次のように理解すると判断しやすくなります。
| 観点 | これまでの典型例 | AMA 経由の native OTLP ingestion |
|---|---|---|
| アプリ側 | OpenTelemetry Collector や各種 SDK から送信先を個別設定 | OTLP exporter の送信先を localhost の AMA 受信ポートへ向ける |
| 認証・ルーティング | アプリや Collector 側で設計することが多い | VM 上の AMA が Azure Monitor への認証とルーティングを処理する |
| 管理単位 | Collector 構成、アプリ構成、Azure 側設定が分散しやすい | AMA、DCR、DCR association、マネージド ID を中心に管理する |
| 主な対象 | 任意の Collector 配置やクラウド直接送信 | Azure VM、VMSS、Azure Arc 対応サーバー |
| 展開時の注意 | Collector の設計・運用が必要 | AMA バージョン、DCR、権限、ポート分離の確認が必要 |
ポイントは、「OpenTelemetry Collector が不要になる」と単純化しないことです。Collector には加工、フィルタリング、ルーティング、複数宛先送信などの役割があります。AMA 経由が合うのは、Azure VM や Arc 対応サーバー上のアプリケーションを、Azure Monitor 中心に監視したいケースです。複雑なテレメトリ処理やマルチクラウド横断の収集基盤が必要な場合は、引き続き Collector 方式の方が適することがあります。
導入前に決めるべき判断基準
Azure Monitor native OTLP ingestion via Azure Monitor Agent は、運用標準化に向いた更新です。ただし、プレビュー段階であることを踏まえると、導入可否は「技術的に使えるか」だけでなく、「どの範囲ならリスクを管理できるか」で判断する必要があります。
導入候補にしやすい環境
次の条件に当てはまる環境は、検証対象として優先しやすいです。
| 条件 | 理由 |
|---|---|
| Azure VM、VMSS、Azure Arc 対応サーバー上で稼働している | AMA 経由方式の主な対象に合っている |
| すでに OpenTelemetry SDK で計装している | アプリ側の送信先変更で検証しやすい |
| Azure Monitor Agent を標準エージェントとして採用している | 既存の運用・更新・監視ポリシーに組み込みやすい |
| Application Insights でアプリ性能監視を行いたい | 推奨構成では Application Insights リソース作成時に OTLP サポートを有効化できる |
| 本番ではなく検証、ステージング、低リスクな業務アプリから始められる | プレビュー機能のリスクを抑えられる |
すぐに本番適用しない方がよい環境
次の環境では、まず検証環境での確認に留めるべきです。
| 条件 | 注意点 |
|---|---|
| 監視停止が重大インシデントにつながる本番システム | プレビュー機能は SLA なしで、本番ワークロードには推奨されていない |
| AKS ワークロードが中心 | AKS には AKS アドオン経由の選択肢があるため、AMA on VM 前提で設計しない |
| App Service、Functions、Container Apps など PaaS 中心 | AMA 経由方式の主対象とは異なるため、別の OpenTelemetry 取り込み方式を検討する |
| Collector で高度な加工や複数宛先送信をしている | AMA 経由に置き換えると既存の処理を失う可能性がある |
| アプリケーションを OpenTelemetry で計装していない | AMA を入れるだけではアプリの OTLP テレメトリは発生しない |
特に見落としやすいのは、「Azure Monitor Agent を入れれば自動的にアプリのトレースやメトリックが出る」と誤解することです。アプリケーション側には OpenTelemetry SDK による計装と OTLP exporter の設定が必要です。
まず確認する全体構成
AMA 経由の OTLP ingestion は、ざっくり次の流れで動きます。
OpenTelemetry 計装済みアプリ
↓ OTLP exporter
localhost:4317 メトリック
localhost:4319 ログ・トレース
↓
Azure Monitor Agent
↓ DCR / DCE / Managed Identity
Azure Monitor
├ Application Insights
├ Log Analytics workspace
└ Azure Monitor workspaceMicrosoft Learn では、アプリケーション環境で OTLP exporter を localhost に向け、メトリックは gRPC の 4317、ログとトレースは gRPC の 4319 に送る構成例が示されています。また、Application Insights の体験では、デルタテンポラルと指数ヒストグラム集計を使った OTLP メトリックが必要とされています。(Microsoft Learn)
この構成を見れば、管理者が確認すべき領域は明確です。アプリ、OS、AMA、DCR、ID、Azure Monitor 側のリソース、ネットワーク、運用手順のすべてに関係します。
導入前チェックリスト
発表直後の確認では、いきなり設定作業に入るよりも、まず以下のチェックリストで対象範囲を固めるのが安全です。
| チェック項目 | 確認内容 | 担当の目安 |
|---|---|---|
| 機能ステータス | パブリックプレビューであること、SLA や本番利用方針を確認したか | Azure 管理者、運用責任者 |
| 対象ワークロード | VM、VMSS、Arc 対応サーバー上のアプリか | インフラ担当 |
| アプリ計装 | OpenTelemetry SDK でメトリック、ログ、トレースを出せるか | アプリ開発担当 |
| AMA バージョン | Windows は 1.38.1 以降、Linux は 1.37.0 以降か | サーバー運用担当 |
| DCR | OTLP ingestion 用の DCR を作成・把握しているか | 監視基盤担当 |
| DCR association | 対象 VM、VMSS、Arc 対応サーバーに DCR を関連付けたか | インフラ担当 |
| マネージド ID | 対象コンピューティングにシステム割り当てマネージド ID を有効化したか | ID 管理担当 |
| IAM | マネージド ID に Monitoring Metrics Publisher ロールを付与したか | Azure 管理者 |
| アプリ環境変数 | OTLP endpoint、microsoft.applicationId、メトリック設定を反映したか | アプリ担当 |
| ポート | アプリから localhost:4317 / 4319 に接続できるか | アプリ・OS 担当 |
| 検証方法 | Application Insights、Log Analytics、Azure Monitor workspace で確認する観点を決めたか | SRE、運用担当 |
| ロールバック | 旧送信先へ戻す手順、DCR 関連付け解除、アプリ設定戻しを用意したか | 展開計画担当 |
| 周知 | 監視画面、アラート、問い合わせ先、既知制限を関係者へ通知したか | 運用責任者 |
最低限、AMA バージョン、DCR association、マネージド ID の権限、アプリ側 endpoint の4点は、検証前に必ず確認してください。ここが抜けると、アプリはデータを送っているのに Azure Monitor 側で何も見えない、という切り分けに時間がかかります。
設定差分チェックリスト
既存の Azure Monitor 運用に AMA 経由の OTLP ingestion を追加する場合、差分は主に「アプリ側」「Azure Monitor 側」「ID・権限」「運用管理」の4領域に出ます。
アプリケーション側の差分
| 項目 | 変更前 | 変更後の確認ポイント |
|---|---|---|
| 計装 | 未計装、または独自 SDK | OpenTelemetry SDK で必要な信号を出せるか |
| OTLP 送信先 | Collector、外部エンドポイント、未設定 | AMA の localhost 受信ポートへ送る |
| メトリック endpoint | アプリや Collector により異なる | http://localhost:4317 を使用する構成を確認 |
| ログ・トレース endpoint | アプリや Collector により異なる | http://localhost:4319 を使用する構成を確認 |
| Application Insights 関連付け | 接続文字列中心の運用 | 必要に応じて microsoft.applicationId を resource attribute に設定 |
| メトリック形式 | 累積型や既定設定のまま | delta temporality と指数ヒストグラム集計の要件を確認 |
設定例としては、次のような環境変数をアプリケーション実行環境に設定します。実際の値は、利用している言語、SDK、デプロイ方式に合わせて調整してください。
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 が全信号を同じ endpoint に送る前提になっている場合、信号種別ごとに endpoint を分けられるか確認してください。
Azure Monitor 側の差分
Microsoft Learn では、OTLP ingestion の設定方法として、Application Insights ベースの推奨アプローチと、DCE、DCR、宛先ワークスペースを手動で構成する方法が示されています。多くのシナリオでは、必要な Azure リソース作成と関係設定を自動化できる Application Insights ベースのアプローチが推奨されています。(Microsoft Learn)
| 項目 | 推奨確認 |
|---|---|
| Application Insights | 新規作成時に OTLP support を有効化するか |
| Feature registration | OtlpApplicationInsights の登録状態を確認するか |
| Resource provider | Microsoft.Insights を登録済みか |
| DCR | 自動作成された DCR または手動作成した DCR の resource ID を記録したか |
| DCE | 手動構成の場合、同一リージョンで DCE を作成したか |
| Log Analytics workspace | ログとトレースの保存先として設計したか |
| Azure Monitor workspace | メトリック保存先として設計したか |
| リージョン | App Insights、LAW、AMW、DCR、DCE のリージョン整合性を確認したか |
| 命名規則 | 検証用、本番候補、部門別などの識別子を入れたか |
| タグ | owner、environment、costCenter、preview などを付与したか |
推奨アプローチで開始する場合、Azure CLI では次の登録確認が必要になります。
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プレビュー機能の検証では、あとから「誰が何の目的で作ったリソースか」が分からなくなりがちです。検証用リソースには preview=true、owner=<team>、reviewDate=<date> のようなタグを付け、削除判断やコスト確認をしやすくしておくと運用が安定します。
DCR と関連付けの差分
DCR は Azure Monitor のデータ収集設定を集中管理する重要なリソースです。Microsoft Learn では、DCR は収集するデータ、受信データのスキーマ、変換、送信先などを定義し、Azure Monitor のデータ収集をより管理しやすく、スケーラブルにする仕組みとして説明されています。(Microsoft Learn)
AMA 経由の OTLP ingestion では、DCR を作るだけでなく、対象の VM、VMSS、Arc 対応サーバーに関連付ける必要があります。DCR の Resources タブから対象リソースを追加できるため、検証時は「DCR があるか」ではなく「DCR が対象リソースに関連付いているか」を確認してください。(Microsoft Learn)
| 確認対象 | よくあるミス | 対策 |
|---|---|---|
| DCR resource ID | アプリ担当へ古い ID を共有する | 作成後に Overview からコピーし、変更履歴に残す |
| DCR association | DCR 作成だけで満足する | 対象 VM / VMSS / Arc server の関連付け一覧を確認する |
| 複数 DCR | 既存 DCR と役割が重複する | OTLP 用、OS ログ用、VM insights 用の責任範囲を分ける |
| 手動テンプレート | Stream 名や DCE 名の整合性を崩す | テンプレート変更時は命名ルールをレビューする |
| 既存監視 | 旧アラートが同じデータを前提にしている | 並行稼働期間を設け、アラート差分を比較する |
DCR は監視設定の中核になるため、ポータルで手作業するだけでなく、検証後は Bicep、ARM テンプレート、Terraform などの IaC 管理へ移すことを検討してください。プレビュー検証段階でも、少なくとも設定値と作成者、変更日を記録しておくべきです。
ID と権限の差分
AMA が Azure Monitor へデータを送るには、対象コンピューティングのマネージド ID と、DCR への書き込み権限が必要です。Microsoft Learn では、コンピューティングリソースでシステム割り当てマネージド ID を有効にし、そのマネージド ID に Monitoring Metrics Publisher ロールを割り当てる必要があると説明されています。(Microsoft Learn)
| 項目 | 確認内容 |
|---|---|
| Managed Identity | 対象 VM、VMSS、Arc 対応サーバーで有効か |
| Role assignment | DCR に対して Monitoring Metrics Publisher が付与されているか |
| 権限スコープ | サブスクリプション全体ではなく、必要な DCR など最小範囲で付与しているか |
| 変更承認 | IAM 変更が社内の権限申請フローに沿っているか |
| 監査 | 誰がいつロールを付与したか追跡できるか |
失敗しやすいのは、Log Analytics workspace 側の権限だけを確認し、DCR に対する権限を忘れるケースです。今回の構成では、DCR がデータ収集制御の重要なポイントになるため、IAM の確認対象に必ず DCR を含めてください。
展開順序チェックリスト
発表直後の展開では、全台展開ではなく、検証、限定展開、段階展開の順に進めます。特にプレビュー機能は、社内の標準監視基盤へ組み込む前に、監視データの欠落、コスト、アラート品質、運用手順への影響を確認する必要があります。
推奨する展開順序
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 情報確認 | Azure Updates と Microsoft Learn の更新内容を確認 | 対象範囲、プレビュー制約、前提条件を説明できる |
| 対象選定 | VM、VMSS、Arc 対応サーバー上の低リスクアプリを選ぶ | 1〜3個程度のパイロット対象が決まる |
| 既存監視確認 | 現在のメトリック、ログ、トレース、アラートを棚卸し | 置き換えるもの、並行稼働するものが明確になる |
| リソース準備 | App Insights、DCR、必要に応じて DCE、LAW、AMW を準備 | DCR resource ID と関連リソースが記録される |
| AMA 確認 | Azure Monitor Agent をインストールまたは更新 | Windows 1.38.1 以降、Linux 1.37.0 以降を満たす |
| DCR 関連付け | 対象リソースに DCR を関連付け | DCR の Resources で対象が確認できる |
| ID 設定 | Managed Identity と Monitoring Metrics Publisher を設定 | DCR に対する権限が確認できる |
| アプリ設定 | OTLP endpoint と resource attributes を設定 | アプリ再起動後に OTLP 送信が始まる |
| データ確認 | Application Insights、Log Analytics、Azure Monitor workspace で確認 | メトリック、ログ、トレースのいずれを取り込めたか記録する |
| アラート確認 | 既存アラート・新規アラートの動作を確認 | 誤検知、欠落、重複通知を把握する |
| 周知 | 運用、開発、SRE、セキュリティ、ヘルプデスクへ共有 | 問い合わせ先と既知制限が明確になる |
| 次段階判断 | 継続、拡大、保留、撤回を判断 | 判定理由と次回レビュー日を残す |
パイロット対象の選び方
最初の検証対象は、次の条件を満たすものが適しています。
| 条件 | 理由 |
|---|---|
| 既に OpenTelemetry 計装済み | アプリ改修よりも取り込み経路の検証に集中できる |
| 障害影響が限定的 | プレビュー検証のリスクを抑えられる |
| VM または Arc 対応サーバーで動いている | AMA 経由の対象範囲に合う |
| 開発チームと運用チームが協力しやすい | アプリ設定と Azure 側設定の両方を素早く切り分けられる |
| 既存の監視データがある | 旧方式との比較がしやすい |
逆に、最初から全社共通の基幹業務アプリ、24時間停止できない本番システム、規制対応が厳しいログを扱うシステムを選ぶのは避けた方が安全です。
周知項目チェックリスト
Azure Monitor native OTLP ingestion via Azure Monitor Agent の導入では、設定変更だけでなく、関係者への周知が重要です。監視経路が変わると、アラートの見え方、ログの検索方法、障害時の切り分け手順、コスト管理の見方が変わる可能性があります。
| 周知先 | 伝える内容 | 具体例 |
|---|---|---|
| アプリ開発チーム | OTLP exporter の endpoint、resource attributes、再起動タイミング | メトリックは 4317、ログ・トレースは 4319 へ送る |
| インフラ運用チーム | AMA バージョン、DCR association、Managed Identity | 対象 VM の AMA が要件バージョンを満たすか確認 |
| SRE / NOC | 監視画面、アラート、ダッシュボードの変更 | 旧ダッシュボードと新ダッシュボードの並行確認期間を設ける |
| セキュリティチーム | IAM 変更、データ送信経路、保持先 | DCR への Monitoring Metrics Publisher 付与を説明する |
| FinOps / コスト管理 | 取り込みデータ量、ログ保持、メトリック増加の可能性 | パイロット期間中は日次で取り込み量を確認する |
| ヘルプデスク | 問い合わせ時の一次切り分け | 「Azure Monitor に出ない」時の確認項目を共有する |
| 変更管理者 | プレビュー利用の扱い、ロールバック基準 | 本番適用ではなく検証扱いであることを明記する |
周知文には、次の4点を必ず入れてください。
1. 何が変わるか
OpenTelemetry の OTLP データを Azure Monitor Agent 経由で Azure Monitor に取り込む検証を開始します。
2. 影響範囲
対象は指定した VM / VMSS / Azure Arc 対応サーバー上の検証アプリです。全社展開ではありません。
3. 作業内容
AMA バージョン確認、DCR 関連付け、マネージド ID 権限設定、アプリの OTLP endpoint 変更を行います。
4. 注意点
本機能はパブリックプレビューです。監視の本番切り替えではなく、並行検証として扱います。検証時の確認ポイント
導入後は、「データが来ているか」だけでなく、「期待した形で使えるか」を確認します。特に OpenTelemetry はメトリック、ログ、トレースの3種類を扱うため、1つの信号だけを見て成功と判断しないようにしてください。
データ到達確認
| 信号 | 確認先 | 見るポイント |
|---|---|---|
| メトリック | Azure Monitor workspace、Grafana、Azure Monitor 側のメトリック体験 | 値が時系列で出るか、単位やラベルが想定通りか |
| ログ | Log Analytics | ログが保存されるか、検索できるか、不要な高頻度ログがないか |
| トレース | Application Insights、Log Analytics | サービス名、依存関係、失敗、遅延が追えるか |
| ダッシュボード | Application Insights、Grafana | 既存運用で使える粒度か |
| アラート | Azure Monitor alerts | 旧経路と比較して欠落や重複がないか |
Microsoft の発表では、Application Insights でアプリ性能の監視、トリアージ、トラブルシューティングを行い、OTLP メトリックは Grafana ダッシュボードや Azure 上の Prometheus query language で可視化し、ログとトレースは OpenTelemetry semantics で Log Analytics からクエリできると説明されています。(Microsoft)
よくあるトラブルと切り分け
| 症状 | 確認すべきこと | 対処の方向性 |
|---|---|---|
| データがまったく出ない | AMA のバージョン、DCR association、Managed Identity、ロール付与 | まず Azure 側の関連付けと権限を確認 |
| メトリックだけ出ない | 4317 に送っているか、delta temporality か | OTLP exporter の metrics endpoint と temporality を確認 |
| ログ・トレースだけ出ない | 4319 に送っているか | traces/logs endpoint を分けて設定する |
| Application Insights で期待通り見えない | microsoft.applicationId が設定されているか | resource attributes を確認 |
| 一部の VM だけ失敗する | AMA 自動更新のばらつき、DCR 関連付け漏れ | 対象 VM ごとの拡張機能と DCR を確認 |
| 取り込み量が急増する | 高頻度メトリック、詳細ログ、不要な属性 | サンプリング、フィルタ、DCR 変換、Collector 利用を検討 |
| アラートが重複する | 旧監視経路と新監視経路が並行稼働している | 並行期間中の通知ルールを分ける |
切り分けでは、アプリ、AMA、Azure Monitor のどこで止まっているかを分けて考えることが重要です。アプリが localhost に送れていない場合、Azure 側をいくら確認しても解決しません。逆に、アプリが送れていても、DCR association や IAM が不足していれば Azure Monitor には届きません。
Azure Policy と IaC で管理する場合の注意点
検証が進み、対象台数が増える場合は、手作業で AMA をインストールしたり DCR を関連付けたりする運用は避けるべきです。Microsoft Learn では、Azure Policy を使って既存および新規の仮想マシンに Azure Monitor Agent を自動インストールし、関連する DCR を自動関連付けできると説明されています。(Microsoft Learn)
ただし、プレビュー機能を Azure Policy で広範囲に割り当てる場合は慎重に進めてください。ポリシーのスコープをサブスクリプション全体に広げると、意図しない VM や Arc 対応サーバーまで検証対象になる可能性があります。
| 管理方法 | 向いている場面 | 注意点 |
|---|---|---|
| ポータル手動 | 初回検証、少数台の確認 | 設定漏れや履歴不明が起きやすい |
| Azure CLI / PowerShell | 手順化された検証、再現性の確保 | 実行ログとパラメーター管理が必要 |
| Bicep / ARM / Terraform | 標準展開、複数環境への反映 | プレビュー仕様変更への追従が必要 |
| Azure Policy | 新規 VM や既存 VM への大規模適用 | スコープを限定し、除外条件を明確にする |
おすすめは、最初のパイロットだけポータルで確認し、2回目以降は CLI または IaC へ落とし込む進め方です。これにより、検証結果をそのまま標準手順へ変換しやすくなります。
ロールバック計画で決めておくこと
プレビュー機能の検証では、ロールバック計画がないまま始めるのは危険です。ロールバックとは、単に Azure 側リソースを削除することではありません。監視データの送信先、アラート、ダッシュボード、問い合わせ対応を元に戻せる状態にしておくことです。
| 項目 | ロールバック方針 |
|---|---|
| アプリ設定 | OTLP endpoint を旧 Collector または旧送信先へ戻す |
| AMA | 既存の OS 監視で使っている場合は安易に削除しない |
| DCR association | OTLP 用 DCR の関連付けだけを解除する |
| Application Insights | 検証データの保持期間を確認してから削除判断する |
| アラート | 新経路用アラートを無効化し、旧経路の通知を戻す |
| ダッシュボード | 旧ダッシュボードを並行保持する |
| 周知 | 検証中止、保留、再開予定を関係者へ伝える |
特に AMA は、他の Azure Monitor 監視や VM insights で使っている可能性があります。OTLP 検証だけを理由に AMA を削除すると、OS ログやパフォーマンス監視まで止まる恐れがあります。ロールバックでは「どの DCR とアプリ設定を戻すのか」を明確にしてください。
管理者が作るべき社内メモのテンプレート
展開前に、次のような社内メモを作っておくと、運用部門や変更管理会議で説明しやすくなります。
件名:
Azure Monitor Agent 経由の OTLP ingestion パブリックプレビュー検証について
目的:
OpenTelemetry 計装済みアプリケーションのメトリック、ログ、トレースを Azure Monitor Agent 経由で Azure Monitor に取り込めるか検証する。
対象:
- サブスクリプション:
- リソースグループ:
- VM / VMSS / Arc 対応サーバー:
- アプリケーション:
- 環境: 検証 / ステージング / 本番以外
実施内容:
- Application Insights OTLP support の有効化
- DCR / DCE / workspace の確認
- Azure Monitor Agent バージョン確認
- DCR association の作成
- Managed Identity と Monitoring Metrics Publisher の設定
- アプリケーションの OTLP endpoint 変更
注意事項:
- 本機能はパブリックプレビュー
- 本番監視への正式切り替えではない
- 旧監視経路は並行保持する
- 取り込み量とアラート挙動を検証期間中に確認する
ロールバック:
- アプリケーションの OTLP endpoint を旧設定へ戻す
- OTLP 用 DCR association を解除する
- 新規アラートを無効化する
- 旧ダッシュボードを継続利用する
問い合わせ先:
- Azure 管理:
- アプリ担当:
- SRE / 運用:このメモは、単なる議事録ではなく、後から「なぜこの構成にしたのか」を説明するための証跡になります。プレビュー機能の検証では、技術検証だけでなく、判断理由の記録も重要です。
本番展開を判断する前の最終チェック
本番環境へ広げるかどうかは、プレビュー段階では慎重に判断します。少なくとも、次の項目が確認できるまでは、正式な監視経路として扱わない方が安全です。
| 判断項目 | 確認基準 |
|---|---|
| 機能ステータス | プレビューの制約を理解し、社内の利用基準に合っている |
| データ品質 | メトリック、ログ、トレースが期待した粒度で取得できている |
| 可観測性 | 障害時に原因調査へ使えるダッシュボードとクエリがある |
| アラート品質 | 旧経路と比較して検知漏れや過剰通知がない |
| コスト | 取り込み量、保持期間、メトリック増加の影響を把握している |
| 運用手順 | 一次切り分け、エスカレーション、ロールバックが文書化されている |
| 権限管理 | Managed Identity とロール付与が最小権限で管理されている |
| 自動化 | 手作業ではなく、IaC や Azure Policy で再現可能になっている |
| 関係者合意 | 開発、運用、セキュリティ、コスト管理が変更内容を理解している |
まず取るべき次の行動
Azure Monitor native OTLP ingestion via Azure Monitor Agent は、Azure Monitor と OpenTelemetry の接続をシンプルにし、VM や Arc 対応サーバー上のアプリケーション監視を標準化しやすくする更新です。一方で、2026年4月時点ではパブリックプレビューであり、本番監視の即時置き換えではなく、限定的な検証から始めるべき機能です。
管理者が最初に行うべきことは、次の3つです。
1つ目は、対象ワークロードを VM、VMSS、Arc 対応サーバーの中から絞り込み、OpenTelemetry 計装済みか確認することです。2つ目は、AMA バージョン、DCR、Managed Identity、Monitoring Metrics Publisher、OTLP endpoint の設定差分をチェックリスト化することです。3つ目は、旧監視経路を残したまま、パイロット環境でメトリック、ログ、トレース、アラート、コストの差分を確認することです。
この順序で進めれば、発表直後の新機能を無理なく評価でき、正式採用すべきか、Collector 方式を併用すべきか、当面は保留すべきかを判断しやすくなります。
コメント