Azure Monitor for AKS で OpenTelemetry を標準化したいチームにとって、2026年4月14日の更新は「OpenTelemetry を使いながら、Application Insights、Container Insights、Azure Monitor の調査導線を使い続けやすくなる」プレビューです。ポイントは、AKS 上のアプリケーション監視で OTLP を扱えるようになり、プラットフォームチームがテレメトリの取り込み経路を管理しつつ、開発チームは OpenTelemetry ベースの計測に寄せられることです。Microsoft の Azure Updates では、Azure ID 560119 として「Public Preview: Monitor AKS applications with OpenTelemetry and Azure Monitor」が掲載されています。(Microsoft Azure)
ただし、これはまだプレビューです。すぐに全本番環境へ横展開する機能というより、まずは一部の名前空間や重要度の低いワークロードで検証し、既存の Application Insights、Container Insights、Grafana、アラート運用にどう組み込むかを確認する段階と見るべきです。Microsoft Learn でも、プレビュー機能は SLA なしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
Azure Monitor for AKS のプレビューで何が変わったのか
今回のプレビューの本質は、AKS 上のアプリケーション監視で OpenTelemetry Protocol、つまり OTLP を Azure Monitor のファーストパーティ体験に取り込めるようになったことです。Microsoft Learn では、Azure Monitor が AKS 上で動くアプリケーションに対し、OpenTelemetry Protocol を使ったインストルメンテーションとデータ収集のプレビューサポートを追加したと説明しています。(Microsoft Learn)
従来、AKS の監視は大きく分けると、ノード・Pod・コンテナなどのインフラ監視と、アプリケーションのリクエスト・依存関係・例外・トレースを見る APM の領域に分かれがちでした。Container Insights や Managed Prometheus はクラスターの状態を見るには強力ですが、マイクロサービス単位のリクエスト失敗や外部依存の遅延まで一気通貫で追うには、Application Insights や OpenTelemetry の設計も必要になります。
このプレビューでは、その分断を小さくできます。AKS の監視設定からアプリケーション監視を有効化し、Application Insights にテレメトリを流し、Container Insights の文脈でアプリケーションの失敗や遅延を確認する流れを作れます。Microsoft の公式ブログでも、AKS クラスターブレードからのオンボーディング、OpenTelemetry サポート、自動インストルメンテーション、自動構成によって、コード変更やカスタムエージェント運用の負担を減らせると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上の変化は、次のように整理できます。
| 従来の悩み | プレビューで期待できる変化 |
|---|---|
| OpenTelemetry を採用したいが、Azure Monitor との接続設計がチームごとにバラつく | AKS 統合のオンボーディングで、名前空間またはデプロイスコープの取り込み経路を標準化しやすい |
| Collector、認証、接続文字列、環境変数の管理が属人化する | Azure Monitor 側の管理体験に寄せ、プラットフォームチームが共通設定を持ちやすい |
| アプリのトレースと AKS インフラのメトリックが別々に見える | Application Insights と Container Insights の間を行き来しながら調査しやすい |
| OSS 標準を使うか、Azure の運用体験を使うかで迷う | 計測標準は OpenTelemetry、調査・可視化・アラートは Azure Monitor という分担を取りやすい |
OpenTelemetry 標準化チームにとっての意味
OpenTelemetry を標準化する目的は、単に新しい SDK を入れることではありません。重要なのは、言語や実行基盤が増えても、トレース、メトリック、ログの考え方を共通化し、バックエンドを変更しても運用設計を破綻させにくくすることです。
今回の Azure Monitor for AKS のプレビューは、この方針と相性があります。Microsoft Learn では、AKS 向けの OTLP アプリケーション監視について、クラスター統合の監視、自動インストルメンテーションまたは自動構成、名前空間・デプロイスコープでのオンボーディング、エージェント配置・ID 管理・テレメトリルーティングを扱うマネージド体験として説明しています。(Microsoft Learn)
つまり、OpenTelemetry を「アプリケーション計測の共通語」として使い、Azure Monitor を「Azure 上での運用ワークフロー」として使う構成が取りやすくなります。これは、次のような組織に特に向いています。
| チームの状況 | このプレビューの価値 |
|---|---|
| AKS を標準基盤として運用している | クラスター単位で監視設定と取り込み経路を統制しやすい |
| Java、Node.js、.NET、Python など複数言語が混在している | OpenTelemetry を共通方針にし、言語ごとの差分を吸収しやすい |
| Application Insights を既に使っている | 既存の Azure Portal、Application Map、ログ分析、アラート設計を活かしやすい |
| ベンダーロックインを避けたいが、Azure ネイティブの運用体験も捨てたくない | テレメトリ形式は OTLP、運用画面は Azure Monitor という分離がしやすい |
| Platform Engineering チームが監視基盤を標準化している | 名前空間・デプロイ単位でオンボーディング基準を決めやすい |
ここで注意したいのは、「OpenTelemetry を使うなら Azure 固有の機能を避けるべき」と考えすぎないことです。現実の運用では、障害対応、権限管理、アラート通知、ダッシュボード、コスト管理まで含めて監視基盤を設計します。Azure を主要クラウドとして使っているなら、計測はオープン標準に寄せつつ、運用の入口は Azure Monitor に集約するほうが、オンコール対応や監査の面で扱いやすいケースがあります。
自動インストルメンテーションと自動構成の違い
このプレビューで混同しやすいのが、自動インストルメンテーションと自動構成です。どちらも「OpenTelemetry を使った AKS アプリ監視」に関係しますが、役割は違います。
| 方式 | 何をするか | 向いているケース | 注意点 |
|---|---|---|---|
| 自動インストルメンテーション | Azure Monitor OpenTelemetry Distro をアプリケーション Pod に注入し、テレメトリを生成する | Java や Node.js アプリで、コード変更を抑えてまず可視化したい場合 | 対応言語、ノード、既存計測との重複を確認する |
| 自動構成 | 既に OpenTelemetry SDK で計測済みのアプリに対し、環境変数などをプラットフォーム側で設定して Application Insights へ送る | すでに OSS OpenTelemetry SDK を導入済みで、Azure Monitor へルーティングしたい場合 | 計測そのものはアプリ側の責任。SDK、属性、サンプリング設計が必要 |
| 手動インストルメンテーション | アプリ側で SDK、Exporter、属性、フィルターなどを明示的に設定する | 高度な制御、独自属性、細かいサンプリング、マルチバックエンド送信が必要な場合 | 開発チームの実装負荷が高く、標準化ルールが必要 |
Microsoft Learn では、自動構成は既に OpenTelemetry で計測済みのアプリケーションに適用され、Azure Monitor がアプリへ計測コードを追加するのではなく、既存 SDK が Application Insights へエクスポートするための環境変数を設定すると説明されています。(Microsoft Learn)
一方、自動インストルメンテーションは、Azure Monitor OpenTelemetry Distro をアプリケーション Pod に挿入する方式です。公式ドキュメントでは、Java と Node.js の AKS ワークロードに対し、ソースコードを変更せず Application Insights を有効化する手順が案内されています。(Microsoft Learn)
判断基準はシンプルです。すでに OpenTelemetry SDK をアプリに入れているなら、まず自動構成を検討します。まだ計測していない Java または Node.js アプリを素早く可視化したいなら、自動インストルメンテーションを試す価値があります。すでに高度な Collector パイプラインやマルチクラウド監視を設計している場合は、このプレビューを無理に全面採用せず、既存の OpenTelemetry Collector 構成との役割分担を決めるほうが安全です。
Azure Monitor のファーストパーティワークフローをどう活かせるか
OpenTelemetry の採用でよくある失敗は、テレメトリの送信まではできたものの、運用者がどの画面を見ればよいか分からなくなることです。標準化のゴールは、データを送ることではなく、障害時にすばやく原因に近づける状態を作ることです。
Azure Monitor for AKS のプレビューでは、Application Insights に流れたリクエスト、依存関係、例外、トレースを、AKS インフラの文脈と結び付けやすくなります。Microsoft の公式ブログでは、Container Insights と Application Insights の間を移動しながら、アプリケーション性能とノード、Pod、コンテナの状態を関連付けて調査できることが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
障害対応の流れは、たとえば次のようになります。
- Azure Monitor または Application Insights のアラートで、特定サービスの失敗率上昇を検知する
- Application Insights で失敗したリクエスト名、依存先、例外タイプを確認する
- Application Map や依存関係の情報から、遅延している外部 API、DB、内部サービスを切り分ける
- Container Insights 側で該当 Pod、Deployment、Node の CPU、メモリ、再起動、イベントを確認する
- デプロイ直後の問題であれば、ロールバック、スケール調整、設定変更のどれを優先するか判断する
この流れを作れると、アプリチームとプラットフォームチームの会話が変わります。「アプリが悪い」「基盤が悪い」という切り分けではなく、「このリクエストの p95 が上がったタイミングで、この Deployment の Pod 再起動が増え、この依存先の失敗が増えている」という形で、同じ事実を見ながら対応できます。
既存の AKS 監視との関係
このプレビューは、Container Insights、Managed Prometheus、Azure Managed Grafana を置き換えるものではありません。むしろ、それらと組み合わせて使う位置付けです。
AKS の監視では、プラットフォームメトリック、Prometheus メトリック、アクティビティログ、リソースログ、Container Insights など複数レイヤーの可観測性が必要です。Microsoft Learn でも、AKS は Azure Monitor、Container Insights、Prometheus のマネージドサービス、Azure Managed Grafana と統合されると説明されています。(Microsoft Learn)
役割を分けると、次のようになります。
| 領域 | 主に見るもの | 代表的な Azure の体験 |
|---|---|---|
| クラスター基盤 | Node、Pod、コンテナ、Kubernetes イベント、リソース使用率 | Container Insights |
| メトリック監視 | Prometheus メトリック、SLO 指標、ダッシュボード | Azure Monitor managed service for Prometheus、Azure Managed Grafana |
| アプリケーション性能 | リクエスト、依存関係、例外、分散トレース | Application Insights |
| ログ分析 | アプリログ、例外、Kubernetes 関連ログ、横断クエリ | Log Analytics |
| 標準化された計測 | トレース、メトリック、ログの共通仕様 | OpenTelemetry、OTLP |
Azure Monitor for AKS の OpenTelemetry プレビューは、主に「アプリケーション性能」と「標準化された計測」を AKS の運用体験へつなぐ役割を持ちます。Container Insights でクラスターを見て、Application Insights でアプリの挙動を見て、必要に応じて Grafana でフルスタックのダッシュボードを作る、という設計が現実的です。
Microsoft の公式ブログでも、Azure Monitor の Grafana ダッシュボードと組み合わせることで、Application Insights と OpenTelemetry のデータを使ったアプリ中心のトラブルシューティング、AKS インフラメトリックとの相関、標準ベースの可視化が可能になると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
採用すべきケース、慎重にすべきケース
プレビューだからといって無視する必要はありません。一方で、標準基盤としてすぐ本番全面展開するのも早計です。判断は、ワークロードの重要度、既存の OpenTelemetry 実装状況、Azure Monitor への依存度で分けるとよいでしょう。
| ケース | 判断 |
|---|---|
| AKS 上の Java または Node.js アプリを、少ないコード変更で可視化したい | 検証候補。自動インストルメンテーションを試す価値がある |
| 既に OSS OpenTelemetry SDK で計測済みの AKS アプリがある | 検証候補。自動構成で Application Insights へ流す設計を確認する |
| Application Insights を全社標準の APM として使っている | 検証優先度は高い。既存のアラートやダッシュボードと接続しやすい |
| マルチクラウドで同じ Collector パイプラインを使っている | 慎重に比較。OpenTelemetry Collector の柔軟性を残す設計が必要 |
| 本番の最重要システムで SLA 前提の監視が必要 | すぐ全面採用しない。プレビュー制約を踏まえ、並行検証に留める |
| Windows ノードプールや特殊なネットワーク制約がある | 事前確認が必須。未対応シナリオに該当しないか確認する |
特に Observability engineer や Kubernetes platform team は、「使えるか」だけでなく「誰が責任を持つか」を先に決めるべきです。OpenTelemetry はアプリケーション側の実装品質に大きく左右されます。service.name がバラバラ、ログに個人情報が混じる、カーディナリティの高いメトリックを大量送信する、といった状態では、どのバックエンドを使っても運用は苦しくなります。
導入前に決めておくべき責任分界
このプレビューは、プラットフォームチームと開発チームの協業を前提に考えると成功しやすくなります。Microsoft Learn でも、クラスター管理者と開発者の責任分担として、クラスター統合、共有 Azure リソース、ID と権限、ガバナンス、テレメトリの属性やサンプリング、アラート所有などを分けて説明しています。(Microsoft Learn)
実務では、次のように分けると運用しやすくなります。
| 項目 | プラットフォームチーム | 開発チーム |
|---|---|---|
| AKS 監視アドオン | 有効化、更新、ロールバック方針の管理 | 直接変更しない |
| Application Insights / Azure Monitor workspace | 作成、命名、権限、接続先の標準化 | 利用要件を伝える |
| OpenTelemetry SDK | 標準バージョンや推奨設定を提示 | アプリへ導入、属性設定、テスト |
| 自動インストルメンテーション | 対象名前空間・対象言語・除外ルールを管理 | アプリへの影響確認、リリース調整 |
| サンプリング | 全社または環境別の方針を決める | サービス特性に合わせて調整を提案 |
| アラート | 共通アラートテンプレートを用意 | SLO、閾値、通知先を所有 |
| コスト管理 | 取り込み量、保持期間、ワークスペース設計を管理 | 不要ログ、過剰メトリック、属性爆発を抑える |
責任分界を曖昧にしたまま導入すると、「データは来ているが、誰もアラートを見ない」「開発チームが属性を変えたらダッシュボードが壊れた」「プラットフォームチームが設定を変えたらトレースが消えた」といった問題が起きます。
実際の導入手順
検証を始めるなら、いきなり全クラスターへ展開せず、1クラスター、1名前空間、1〜2サービスから始めます。Microsoft Learn では、AKS アプリケーション監視の前提として、AKS クラスター、Azure CLI、aks-preview 拡張機能、プレビュー機能の登録、Application Insights の OTLP サポートなどが案内されています。(Microsoft Learn)
対象サービスを棚卸しする
まず、AKS 上のサービスを次の観点で分類します。
| 観点 | 確認すること |
|---|---|
| 言語 | Java、Node.js、.NET、Python、Go など |
| 現在の計測 | 未計測、Application Insights SDK、OpenTelemetry SDK、独自ログのみ |
| 重要度 | 本番重要、社内向け、検証環境、バッチ系 |
| トラフィック | 高トラフィック、低トラフィック、ピークが大きい |
| 依存関係 | DB、メッセージキュー、外部 API、他マイクロサービス |
| セキュリティ | 個人情報、認証情報、規制対象データがログに混ざる可能性 |
最初の検証対象は、低〜中トラフィックで、障害時の調査価値が高く、開発チームと連携しやすいサービスが向いています。最重要システムや高トラフィックサービスは、コストと性能影響を把握してから段階的に進めます。
取り込み方式を選ぶ
方式選定は、次の基準で決めます。
| 状況 | 推奨される進め方 |
|---|---|
| 既に OpenTelemetry SDK を入れている | 自動構成を検証する |
| Java / Node.js で未計測 | 自動インストルメンテーションを検証する |
| 高度な加工、複数バックエンド送信、独自 Processor が必要 | OpenTelemetry Collector との併用を検討する |
| AKS 以外の VM、VMSS、Arc 対応サーバーもある | Azure Monitor Agent による OTLP 取り込みも比較する |
| Azure 外やマルチクラウドも同じ設計にしたい | OpenTelemetry Collector を中心に設計する |
Microsoft Learn では、AKS の場合はクラスター統合の自動インストルメンテーションまたは自動構成、VM や Arc 対応サーバーでは Azure Monitor Agent、最大限の柔軟性や Azure 外の環境では OpenTelemetry Collector という使い分けが示されています。(Microsoft Learn)
プレビュー機能を登録する
検証用サブスクリプションで、必要なプレビュー機能を登録します。コマンド名や前提条件は更新される可能性があるため、実行前に公式ドキュメントの最新版を確認してください。
az extension add --name aks-preview
az extension update --name aks-preview
az feature register \
--namespace "Microsoft.ContainerService" \
--name "AzureMonitorAppMonitoringPreview"
az feature register \
--namespace "Microsoft.Insights" \
--name "OtlpApplicationInsights"
az provider register --namespace "Microsoft.ContainerService"
az provider register --namespace "Microsoft.Insights"公式ドキュメントでは、AKS 側の AzureMonitorAppMonitoringPreview と、Application Insights 側の OtlpApplicationInsights の登録手順が案内されています。(Microsoft Learn)
AKS クラスターを準備する
AKS クラスター側では、Azure Monitor のメトリックとログにオンボードし、アプリケーション監視を有効化します。既存クラスターの場合、公式ドキュメントでは次のようなコマンドでアプリケーション監視を有効化する手順が案内されています。(Microsoft Learn)
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--enable-azure-monitor-app-monitoringポータルから進める場合は、AKS リソースの Monitor Settings で、Container Logs、Managed Prometheus、Application Monitoring などの設定を確認します。すでに Container Insights や Managed Prometheus を使っているクラスターでは、既存のワークスペース設計と競合しないように注意します。
OTLP 対応の Application Insights を用意する
今回のプレビューでは、Application Insights 側で OTLP サポートを有効化することが重要です。Microsoft Learn では、Application Insights リソースを作成または選択する際に OTLP Support を有効にし、Managed workspaces を使う手順が説明されています。また、インフラメトリック用の Azure Monitor workspace とは別のワークスペースを使う注意点も示されています。(Microsoft Learn)
ここを間違えると、後続の画面で期待する Instrumentation Type が表示されなかったり、テレメトリの保存先が想定とずれたりします。特に複数リージョン、複数サブスクリプション、複数環境を運用している組織では、命名規則を先に決めておくべきです。
例:
| 環境 | Application Insights 名 | 用途 |
|---|---|---|
| dev | appi-aks-dev-otel | 検証、SDK 設定確認 |
| stg | appi-aks-stg-otel | リリース前の負荷・アラート確認 |
| prod | appi-aks-prod-otel | 本番候補。ただしプレビュー中は慎重に扱う |
名前空間またはデプロイ単位でオンボードする
オンボーディングは、名前空間全体またはデプロイ単位で設計します。名前空間全体に適用すると運用は楽ですが、対象外にしたいサービスがある場合は影響範囲が広くなります。デプロイ単位にすると制御しやすい反面、設定のばらつきが出やすくなります。
最初の検証では、名前空間を1つ用意し、その中に検証対象サービスだけを置く構成が扱いやすいです。
kubectl create namespace otel-preview設定後は、対象 Deployment の再起動が必要です。Microsoft Learn でも、監視設定を反映するためにデプロイの rollout restart が必要であることが説明されています。(Microsoft Learn)
kubectl rollout restart deployment -n otel-previewここは失敗しやすいポイントです。設定を入れたのにテレメトリが出ない場合、まず「対象 Pod が再作成されたか」「新しい環境変数や注入設定が入ったか」を確認します。
検証時に見るべきチェックポイント
導入後は、単にデータが届いたかだけでは不十分です。トレース、メトリック、ログが、運用で使える品質になっているかを確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| サービス名 | service.name がチーム内で一貫しているか |
| 環境名 | dev、stg、prod が属性やリソースで区別できるか |
| リクエスト | 主要 API の成功率、失敗率、p95/p99 が見えるか |
| 依存関係 | DB、外部 API、キューなどの依存先が分かるか |
| 例外 | 例外タイプ、発生数、影響リクエストが追えるか |
| Pod との関連 | 該当 Deployment、Pod、Namespace へたどれるか |
| ログ | 必要なログが出ており、機密情報が混ざっていないか |
| コスト | 取り込み量、カーディナリティ、ログ量が想定内か |
| アラート | 失敗率、遅延、例外急増などの通知が実用的か |
Log Analytics で調査する場合、Application Insights 関連のテーブルとして AppRequests、AppDependencies、AppExceptions、AppTraces などが使われます。Microsoft Learn のログテーブルリファレンスでも、Application Insights の依存関係、例外、メトリックなどのテーブルが示されています。(Microsoft Learn)
たとえば、リクエスト失敗と遅延を見る最初のクエリは次のような形です。
AppRequests
| where TimeGenerated > ago(30m)
| summarize
requests = count(),
failures = countif(Success == false),
p95_ms = percentile(DurationMs, 95)
by Name, bin(TimeGenerated, 5m)
| order by TimeGenerated desc依存先の失敗や遅延を確認する場合は、次のように見ます。
AppDependencies
| where TimeGenerated > ago(30m)
| summarize
calls = count(),
failures = countif(Success == false),
p95_ms = percentile(DurationMs, 95)
by Type, Target, bin(TimeGenerated, 5m)
| order by failures desc例外の多い順に見る場合は、次のようなクエリが入口になります。
AppExceptions
| where TimeGenerated > ago(1h)
| summarize count() by Type, ProblemId
| order by count_ descクエリはそのまま本番アラートにするのではなく、まずはサービスごとの通常値を把握するために使います。p95 が常に高い API、失敗率が一時的に上がるバッチ、デプロイ直後だけ例外が出る処理など、サービスごとの特性を理解してからアラート化することが重要です。
失敗しやすいポイントと対策
Azure Monitor for AKS と OpenTelemetry の組み合わせでは、設定そのものよりも、運用設計の抜けでつまずくことが多くなります。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| テレメトリが出ない | Deployment を再起動していない、対象名前空間が違う、Application Insights が OTLP 対応ではない | Pod 再作成、環境変数、接続先、Instrumentation 設定を順に確認する |
| Instrumentation Type が表示されない | OTLP 対応の Application Insights を選んでいない | OTLP Support を有効化した Application Insights を使う |
| データが重複する | 手動計測と自動インストルメンテーションが重なっている | 言語ごとの優先順位と既存 SDK を確認し、どちらを正とするか決める |
| メトリックが見づらい | 属性名が不統一、カーディナリティが高い | service.name、環境名、バージョン、名前空間の命名規則を標準化する |
| 取り込みコストが増える | DEBUG ログ、ヘルスチェック、ユーザー単位属性などを大量送信している | サンプリング、ログレベル、フィルター、保持期間を調整する |
| 障害時に使われない | ダッシュボードやアラートの所有者が決まっていない | SLO、アラート閾値、オンコール手順をサービス単位で決める |
| セキュリティレビューで止まる | ログや属性に個人情報、トークン、認証情報が混ざる | 収集前のフィルタリングとレビューを標準プロセスに入れる |
特にログと属性の設計は重要です。Microsoft Learn でも、Application Insights の OpenTelemetry データのフィルター処理は、不要なテレメトリの除外、機密データの収集防止、パフォーマンス最適化、コンプライアンスに役立つと説明されています。(Microsoft Learn)
OpenTelemetry を標準化すると、各チームが自由に属性を追加できる一方で、無秩序な属性追加がコストと可読性を悪化させます。たとえば、ユーザーID、リクエストID、注文IDのような高カーディナリティ値をメトリックラベルに入れると、ダッシュボードやアラートが重くなり、コストも増えます。こうした値は、必要に応じてトレースやログで扱うべきです。
プレビュー制約として確認すべきこと
この機能はプレビューであり、制約を理解して使う必要があります。Microsoft Learn では、OTLP/HTTP の binary Protobuf のみを受け付け、JSON ペイロードや OTLP/gRPC はサポートしないこと、DCR 関連付け数、スケール、追加リソース使用量、圧縮非対応などの制約が示されています。(Microsoft Learn)
主な確認ポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| サポート状態 | プレビューであり、本番前提の SLA は期待しない |
| 対応リージョン | 一部リージョンは対象外。グローバル展開前に対象リージョンを確認する |
| ノード制約 | Windows ノードプールなど未対応シナリオに該当しないか確認する |
| OTLP プロトコル | OTLP/HTTP binary Protobuf に合わせる。OTLP/gRPC 前提の設定は見直す |
| 圧縮 | OpenTelemetry SDK exporter の圧縮が未対応の場合があるため設定を確認する |
| DCR | クラスターあたりの Data Collection Rule 関連付け数に注意する |
| スケール | 大量トラフィックでは EPS、CPU、メモリ影響を検証する |
| SDK 設定 | 自動構成では既存 OpenTelemetry SDK の計測品質が前提になる |
本番導入を急ぐ場合でも、最低限、検証環境で次の3つは確認してください。
| 検証 | 目的 |
|---|---|
| 通常負荷テスト | テレメトリ量、CPU、メモリ、取り込み遅延を確認する |
| 障害注入テスト | 例外、依存先失敗、タイムアウトが Application Insights で追えるか確認する |
| デプロイテスト | rollout restart、ロールバック、Pod 再作成時に計測が維持されるか確認する |
OpenTelemetry Collector とどう使い分けるか
OpenTelemetry を標準化しているチームほど、「Azure Monitor の AKS 統合」と「OpenTelemetry Collector」のどちらを使うべきか迷います。結論として、AKS 上で Azure Monitor を主な観測バックエンドにするなら、今回のプレビューは検証価値があります。一方、マルチクラウドや複数バックエンド送信、複雑な加工処理が必要なら、Collector を中心にした設計も残すべきです。
| 要件 | AKS 統合の Azure Monitor プレビュー | OpenTelemetry Collector |
|---|---|---|
| Azure ネイティブなオンボーディング | 強い | 自前設計が必要 |
| Application Insights との接続 | 強い | Exporter 設定が必要 |
| Container Insights との調査導線 | 強い | 自前で関連付けを設計 |
| マルチクラウド | 弱い | 強い |
| 複数バックエンド送信 | 限定的 | 強い |
| Processor による加工 | 限定的 | 強い |
| 運用負荷 | 低くしやすい | Collector の運用が必要 |
| プレビューリスク | あり | 構成によるが成熟した選択肢も多い |
Microsoft Learn でも、Azure Monitor Agent が使えない環境や最大限の柔軟性が必要な場合は OpenTelemetry Collector を使う選択肢が示されています。(Microsoft Learn)
現実的には、次のようなハイブリッド方針が取りやすいです。
| 環境 | 推奨方針 |
|---|---|
| Azure AKS の標準アプリ | Azure Monitor for AKS の OTLP 監視を検証 |
| Azure 外の Kubernetes | OpenTelemetry Collector を中心に設計 |
| 高度な加工が必要なサービス | Collector を残し、Azure Monitor 送信も設計 |
| 新規の Java / Node.js アプリ | 自動インストルメンテーションで初期可視化を検証 |
| 既存の OTel SDK 導入済みアプリ | 自動構成で Azure Monitor へ接続 |
標準化で決めるべき命名・属性・アラート
OpenTelemetry と Azure Monitor をうまく組み合わせるには、技術設定よりも標準ルールが重要です。最低限、次の項目はプラットフォーム標準として決めておきます。
| 標準化項目 | 例 | 決める理由 |
|---|---|---|
| サービス名 | checkout-api、payment-worker | ダッシュボード、アラート、検索の軸になる |
| 名前空間 | prod-checkout、stg-payment | AKS リソースとアプリの対応を取りやすくする |
| 環境名 | dev、stg、prod | 本番と検証データを混ぜない |
| バージョン | Git SHA、イメージタグ、リリース番号 | デプロイ後の劣化を追いやすくする |
| サンプリング | 本番は head sampling、重要処理は例外時保持など | コストと調査性のバランスを取る |
| ログレベル | 本番は INFO 以上、DEBUG は期間限定 | 取り込み量とノイズを抑える |
| 機密情報 | Authorization、Cookie、個人情報は収集禁止 | セキュリティとコンプライアンスを守る |
| アラート所有者 | サービスチーム、SRE、Platform など | 通知の放置を防ぐ |
独自性を出すなら、ダッシュボードより先に「調査ストーリー」を標準化するのがおすすめです。たとえば、全サービスで次の5つの問いに答えられる状態を合格基準にします。
| 問い | 必要なデータ |
|---|---|
| どの API が遅いのか | AppRequests、リクエスト名、Duration |
| どの依存先が失敗しているのか | AppDependencies、Target、Success |
| どの例外が増えているのか | AppExceptions、Type、ProblemId |
| どの Pod / Deployment に偏っているのか | Kubernetes 属性、Container Insights |
| いつのデプロイから悪化したのか | service.version、リリース時刻、Deployment 履歴 |
この5つに答えられない場合、テレメトリは届いていても、運用品質としてはまだ不足しています。
まず取るべきアクション
Azure Monitor for AKS の OpenTelemetry プレビューは、AKS observability と OpenTelemetry を両立したいチームにとって、かなり実務的な選択肢です。特に、OpenTelemetry を全社標準にしながら、Azure Monitor、Application Insights、Container Insights、Grafana のファーストパーティワークフローを使い続けたい組織には価値があります。
一方で、プレビューである以上、最初から本番標準にしないことが重要です。次の順番で進めると失敗しにくくなります。
| 順番 | やること |
|---|---|
| 1 | 検証用 AKS クラスターまたは検証用名前空間を選ぶ |
| 2 | 対象アプリを1〜2個に絞り、既存の OpenTelemetry 導入状況を確認する |
| 3 | 自動インストルメンテーションか自動構成かを決める |
| 4 | OTLP 対応の Application Insights とワークスペース設計を確認する |
| 5 | テレメトリが届くだけでなく、障害調査に使えるかを検証する |
| 6 | 命名、属性、サンプリング、ログ、アラート所有者の標準を作る |
| 7 | 本番候補サービスへ段階的に広げる |
このプレビューの価値は、「OpenTelemetry を採用するか、Azure Monitor を使うか」という二択を減らせる点にあります。計測は OpenTelemetry に寄せ、運用は Azure Monitor の既存ワークフローに載せる。AKS を中核にしたプラットフォームチームにとって、これが今回の更新で最も注目すべき意味です。
コメント