Microsoft Azureの今回の更新で押さえるべき点は、Azure Container AppsのマネージドOpenTelemetry機能が拡張され、New Relic、Dynatrace、Elasticといった外部のオブザーバビリティ基盤へログ・メトリック・トレースを送りやすくなったことです。これにより、Azure Container Apps上のアプリケーションを監視するために、独自にOpenTelemetry Collectorや各社エージェントを運用する負担を減らせる可能性があります。
ただし、送信先を設定するだけで自動的に可観測性データが生成されるわけではありません。アプリケーション側でOpenTelemetry SDKを使った計装、送信先ごとの認証情報、環境変数、ネットワーク到達性、コスト管理まで確認する必要があります。本記事では、2026年6月に公開・更新されたMicrosoft Azureの公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定と展開時の注意点を整理します。(Microsoft Azure)
Azure Container AppsのOpenTelemetry宛先サポート拡張とは
今回の更新は、Azure Container AppsのマネージドOpenTelemetryエージェントで、外部の監視・分析サービスへテレメトリーデータを送る選択肢が広がったというものです。
Microsoftの公式更新では「Additional support for OpenTelemetry destinations」として、New Relic、Dynatrace、Elasticへの追加サポートが一般提供として示されています。Azure Updatesにおける「Launched」は、一般に本番利用可能なリリース済み機能を意味します。(Microsoft Azure)
Azure Container AppsのマネージドOpenTelemetryエージェントを使うと、アプリケーションが出力したOpenTelemetry形式のログ、メトリック、トレースを、Azure Container Apps環境側で指定した宛先へルーティングできます。Microsoft Learnでは、Azure Monitor Application Insights、Datadog、OTLP互換エンドポイントなどへの送信が説明されており、New Relic、Dynatrace、Elasticについても送信ガイドが用意されています。(Microsoft Learn)
何が便利になるのか
従来、外部のオブザーバビリティ基盤にテレメトリーを送るには、アプリケーションごとにエージェントやOpenTelemetry Collectorを配置したり、サイドカー構成や別コンテナを管理したりするケースがありました。今回のようにAzure Container Apps環境側のマネージドエージェントを利用できると、送信経路の管理をAzure側に寄せられます。
実務上のメリットは次の通りです。
| 観点 | 期待できる効果 | 注意点 |
|---|---|---|
| 運用負荷 | Collectorや専用エージェントの自前運用を減らせる | 複雑な加工・フィルタリングが必要な場合は自前Collectorが必要になることがある |
| 監視基盤の選択 | New Relic、Dynatrace、Elasticなど既存の監視基盤を活用しやすい | 各サービス側の契約、取り込み量、権限設計は別途必要 |
| アプリ改修 | 宛先変更時にアプリ側の送信先設定を大きく変えずに済む可能性がある | アプリ側のOpenTelemetry計装は引き続き必要 |
| 標準化 | 環境単位でログ・メトリック・トレースの送信先を統制しやすい | アプリ単位で細かく送信先を分ける用途には制約がある |
対象になるサービスと影響範囲
今回の主な対象は、Azure Container AppsでOpenTelemetryを利用している、または利用予定の環境です。
影響を受けやすいのは、次のようなチームです。
- Azure Container Appsでマイクロサービスを運用している
- New Relic、Dynatrace、Elasticのいずれかを標準監視基盤として使っている
- これまでOpenTelemetry Collectorを自前で動かしていた
- アプリケーションのログ、メトリック、分散トレースを統合的に管理したい
- Azure Monitorだけでなく、既存のSRE・運用監視基盤へデータを集約したい
一方で、すべてのAzure利用者がすぐに対応を迫られる変更ではありません。Azure Container Appsを使っていない環境、OpenTelemetryを利用していないアプリケーション、Application Insightsだけで十分な監視を行っている構成では、直ちに設定変更が必要になるとは限りません。
送信できるデータ種別を確認する
Azure Container AppsのマネージドOpenTelemetryエージェントでは、宛先によって送信できるデータ種別が異なります。Microsoft Learnでは、New Relic、Dynatrace、Elasticはいずれもログ、メトリック、トレースに対応すると説明されています。一方、Azure Monitor Application Insightsについては、ログとトレースは対応していますが、メトリックは対象外とされています。(Microsoft Learn)
| 宛先 | ログ | メトリック | トレース | 実務上の見方 |
| ———————————- | -: | —-: | —: | ——————————————— |
| New Relic | 対応 | 対応 | 対応 | APM、ログ分析、メトリック監視をNew Relicに集約したい場合に有力 |
| Dynatrace | 対応 | 対応 | 対応 | サービス依存関係や自動分析をDynatrace中心に見る組織向け |
| Elastic | 対応 | 対応 | 対応 | Elastic Observabilityや既存のElastic基盤へ統合したい場合に有効 |
| Azure Monitor Application Insights | 対応 | 非対応 | 対応 | Azureネイティブ監視を中心にする場合の基本選択肢 |
| OTLP互換エンドポイント | 対応 | 対応 | 対応 | 独自Collectorや他のOTLP対応基盤へ送る場合に利用 |
ここで重要なのは、「どこに送れるか」だけでなく「どの信号を送るか」を決めることです。たとえば、トレースはApplication InsightsとNew Relicの両方に送り、ログはElasticに集約し、メトリックはDynatraceに送る、といった設計も考えられます。ただし、送信先が増えるほど取り込みコスト、データ重複、アラート重複の管理が難しくなります。
管理者が最初に確認すべきポイント
管理者は、いきなり本番環境で送信先を追加するのではなく、現在の監視設計とデータフローを確認することが重要です。
Container Apps環境単位の設定であることを理解する
マネージドOpenTelemetryエージェントの設定は、基本的にAzure Container Appsの環境レベルで扱います。Microsoft Learnでは、データ種別ごとに異なる宛先へ送ることはできる一方、同一環境内でアプリごとにデータを分割して送信することはできない制約が説明されています。(Microsoft Learn)
これは設計上かなり重要です。たとえば、同じContainer Apps環境に「本番アプリ」と「検証アプリ」が混在している場合、送信先やデータ取り扱い方針を分けにくくなります。
実務では、次の判断が必要です。
| 確認項目 | 判断基準 |
|---|---|
| 本番・検証が同一Container Apps環境に混在していないか | 混在している場合、送信先や保持ポリシーの分離が難しくなる |
| チームごとに監視基盤が異ならないか | 環境を分ける、または送信先を統一する方針が必要 |
| 個人情報や機密情報を含むログがないか | 外部SaaSへ送る前にマスキング・出力制御を確認する |
| 監査上、国外サービスへの送信に制約がないか | 送信先リージョン、契約、社内規程を確認する |
APIキーやトークンの管理方法を決める
New Relic、Dynatrace、Elasticへ送信する場合、各サービス側のAPIキーや取り込みトークンが必要です。
New Relicの公式ガイドではIngest License Keyを使い、Azure Container Apps側ではOTLPエンドポイントとヘッダーを設定します。Dynatraceではlogs.ingest、metrics.ingest、openTelemetryTrace.ingestなどのスコープを持つトークンが必要とされています。Elasticでは、OpenTelemetryデータを書き込めるAPIキーを使い、Authorization: ApiKey <TOKEN>形式のヘッダーを設定します。(Microsoft Learn)
本番展開では、次のようなミスに注意してください。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 権限が強すぎるAPIキーを使う | 漏えい時の影響範囲が広がる | 取り込み専用・必要最小権限のキーを使う |
| トークンをテンプレートに直書きする | GitやCIログから漏えいする | secure parameterや組織のシークレット管理を使う |
| キーのローテーション手順がない | 期限切れや漏えい時に復旧が遅れる | 更新手順と影響範囲を事前に文書化する |
| 本番と検証で同じキーを使う | データ混在や調査困難につながる | 環境ごとにキーと宛先を分ける |
なお、Microsoft Learnでは、マネージドエージェント関連の制約として、シークレットをテンプレートに指定する必要があり、エージェント構成におけるAzure Key Vault統合は現時点で未対応とされています。運用では、BicepやCI/CD側の安全なパラメーター受け渡しを前提に設計しましょう。(Microsoft Learn)
開発者が確認すべきOpenTelemetry計装
今回の更新で誤解しやすいのが、「Azure側で宛先を設定すれば、アプリケーションのログ・メトリック・トレースが自動的に出る」と考えてしまうことです。
実際には、マネージドOpenTelemetryエージェントは主に送信・ルーティングを担います。Microsoft Learnでも、エージェントを有効にしただけではデータ収集は始まらず、アプリケーション側でOpenTelemetry SDKを使ってメトリック、ログ、トレースを出力する必要があると説明されています。(Microsoft Learn)
最低限設定したい環境変数
送信先ガイドでは、Container Appsのアプリ側に次のような環境変数を設定する例が示されています。
| 環境変数 | 目的 |
|---|---|
OTEL_SERVICE_NAME | 監視基盤上で表示されるサービス名を指定する |
OTEL_TRACES_EXPORTER=otlp | トレースをOTLPで出力する |
OTEL_METRICS_EXPORTER=otlp | メトリックをOTLPで出力する |
OTEL_LOGS_EXPORTER=otlp | ログをOTLPで出力する |
New Relicのガイドでは、これらの環境変数を設定し、新しいリビジョンをデプロイする流れが説明されています。(Microsoft Learn)
OTEL_SERVICE_NAMEは特に重要です。ここが曖昧だと、監視画面上でどのアプリのデータか分かりにくくなります。たとえば、apiやwebのような汎用名ではなく、order-api-prod、payment-worker-stgのように、サービス名と環境が分かる命名にすると運用しやすくなります。
DynatraceとElasticではメトリック設定に注意する
Dynatraceのガイドでは、メトリック取り込みのためにOTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=DELTAが必要とされています。また、Elasticのガイドでは、必要に応じてOTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=cumulativeを設定する例が示されています。(Microsoft Learn)
メトリックのtemporalityは、監視基盤上の値の見え方に関わります。設定が合っていないと、メトリックが表示されない、値が想定と違う、アラートしきい値が機能しないといった問題につながります。
送信先別の設定ポイント
ここでは、管理者・開発者が迷いやすい送信先別の要点を整理します。
New Relicに送る場合
New Relicでは、OTLPエンドポイントとしてhttps://otlp.nr-data.net:4318を使う例が示されています。HTTPでは4318、gRPCでは4317を使うため、プロトコルとポートの組み合わせを間違えないようにします。認証ヘッダーにはapi-keyを指定し、値としてNew RelicのIngest License Keyを設定します。(Microsoft Learn)
実務での確認ポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| エンドポイント | リージョンやアカウント種別に応じて正しいNew Relic OTLPエンドポイントを使っているか |
| ヘッダー | api-keyにIngest License Keyを設定しているか |
| データ種別 | Logs、Traces、Metricsの必要なチェックを有効化しているか |
| サービス名 | New Relic上で識別しやすいOTEL_SERVICE_NAMEになっているか |
New RelicをすでにAPMの標準基盤として使っている組織では、Azure Container Appsだけ別の監視画面を見る必要が減り、障害対応時の調査導線を統一しやすくなります。
Dynatraceに送る場合
Dynatraceでは、OTLPのベースエンドポイントとしてhttps://<TENANT>.live.dynatrace.com/api/v2/otlpを使い、/v1/traces、/v1/metrics、/v1/logsのような信号別パスは追加しないよう説明されています。マネージドエージェント側が信号パスを自動的に付加するためです。 (Microsoft Learn)
また、Dynatraceではトークンにlogs.ingest、metrics.ingest、openTelemetryTrace.ingestのスコープが必要です。メトリックを送る場合は、OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=DELTAも忘れずに確認します。(Microsoft Learn)
| 項目 | 確認内容 |
|---|---|
| エンドポイント | /api/v2/otlpまでを指定し、信号別パスを追加していないか |
| 認証 | AuthorizationヘッダーにApi-Token <TOKEN>形式で設定しているか |
| トークンスコープ | ログ、メトリック、トレースの取り込み権限があるか |
| メトリック | DELTA設定が必要な構成になっていないか |
Dynatraceではサービス依存関係や自動分析の文脈でテレメトリーを見ることが多いため、サービス名、環境名、リソース属性の整備が重要です。単にデータが届くだけでなく、Dynatrace上で「どのサービスの、どの環境の、どのリビジョンか」が追える状態を目標にしましょう。
Elasticに送る場合
Elasticでは、OTLPベースエンドポイントとしてhttps://<YOUR_ELASTIC_ENDPOINT>:443を指定する例が示されています。認証ヘッダーはAuthorization、値はApiKey <TOKEN>形式です。(Microsoft Learn)
| 項目 | 確認内容 |
|---|---|
| エンドポイント | Elastic側のOTLP取り込みに対応したエンドポイントか |
| 認証 | Authorization: ApiKey <TOKEN>形式になっているか |
| 権限 | ログ、トレース、メトリックを書き込めるAPIキーか |
| メトリック | 必要に応じてcumulative設定を確認しているか |
Elasticをログ分析基盤として使っている組織では、ログだけでなくトレースやメトリックも同じObservability画面で確認できるようになります。ただし、ログ量が多いアプリでは取り込みコストやインデックス設計への影響が出やすいため、送信前にログレベルや除外方針を決めておくべきです。
移行・展開時のおすすめ手順
既存環境にいきなり適用するのではなく、次の順序で進めると失敗を減らせます。
| 手順 | 作業内容 | 完了条件 |
| -: | ———————— | —————————————————————– |
| 1 | 現在の監視構成を棚卸しする | Application Insights、Log Analytics、自前Collector、外部SaaSの送信経路が分かっている |
| 2 | 送信先を決める | ログ、メトリック、トレースをどこに送るか決まっている |
| 3 | アプリのOpenTelemetry計装を確認する | SDK導入、サービス名、エクスポーター設定が確認済み |
| 4 | 検証環境でOTel宛先を追加する | 外部基盤にデータが届く |
| 5 | データ量とコストを確認する | 取り込み量、保持期間、アラート数が想定範囲内 |
| 6 | 本番環境へ段階展開する | 一部サービスまたは一部環境から順に有効化する |
| 7 | 旧構成を整理する | 不要なCollector、重複送信、古いアラートを削除する |
特に重要なのは、移行期間中の二重送信です。旧CollectorとマネージドOpenTelemetryエージェントの両方から同じ監視基盤へ送ると、メトリックが二重計上されたり、ログ量が急増したりします。検証時は便利でも、本番ではコストとノイズの原因になります。
ネットワークとセキュリティで確認すべきこと
外部SaaSへテレメトリーデータを送る場合、アプリ本体の通信とは別に、監視データの送信経路もセキュリティ設計の対象になります。
外部エンドポイントへ到達できるか
Container Apps環境でVNet統合、カスタムDNS、Firewall、NAT Gatewayなどを使っている場合、New Relic、Dynatrace、Elasticのエンドポイントへ到達できるかを確認します。Microsoft Learnでは、マネージドOpenTelemetry CollectorがContainer Apps環境のカスタムDNS構成を尊重することも説明されています。(Microsoft Learn)
確認すべき項目は次の通りです。
- 名前解決ができるか
- HTTPS通信が許可されているか
- プロキシやFirewallでブロックされていないか
- 送信元IP制限がある場合、外部SaaS側で許可されているか
- プライベート環境から外部SaaSへ送る方針が社内規程に合っているか
ログに機密情報を出していないか
OpenTelemetryの送信先を増やすと、意図せず機密情報を外部基盤へ送ってしまうリスクも増えます。
特に注意すべきデータは次の通りです。
| データ例 | リスク | 対策 |
|---|---|---|
| Authorizationヘッダー | 認証情報の漏えい | アプリログに出力しない、マスキングする |
| 個人情報 | プライバシー・法務リスク | ログ設計段階で除外・匿名化する |
| リクエスト本文 | パスワードや決済情報が含まれる可能性 | 原則として全文ログ化しない |
| SQLや外部APIの詳細 | 内部構造の露出 | 必要最小限の情報に絞る |
| 例外スタックトレース | 秘密値が混入する可能性 | 本番ログの出力内容をレビューする |
監視基盤を強化するほど、データの集約範囲も広がります。可観測性とセキュリティはセットで設計する必要があります。
コスト面の注意点
マネージドOpenTelemetryエージェント自体について、Microsoft Learnでは追加のコンピュートコストは発生しないと説明されています。ただし、送信先サービスで発生する料金は利用者側の責任です。複数の宛先へ同じテレメトリーを送る場合、それぞれのサービスで取り込み・保存・分析コストが発生する可能性があります。(Microsoft Learn)
コストを抑えるには、次の設計が有効です。
- すべてのログを送るのではなく、ログレベルを見直す
- 開発・検証環境では送信データ種別を絞る
- トレースのサンプリング率を設定する
- 低価値なヘルスチェックや定期実行ログを除外する
- 同じデータを複数基盤へ送る期間を短くする
- 送信先ごとの保持期間を見直す
特にコンテナ環境では、スケールアウト時にログやメトリックの量が一気に増えます。障害時だけでなく、負荷試験やキャンペーン時のデータ量も見積もっておきましょう。
既知の制約と運用上の落とし穴
Azure Container AppsのマネージドOpenTelemetryエージェントには、便利な反面、いくつかの制約があります。Microsoft Learnでは、システムログやContainer Apps標準メトリックはOpenTelemetryエージェントへ送信できないこと、Application Insightsエンドポイントはメトリックを受け付けないこと、設定は環境レベルであること、マネージドエージェントは単一レプリカで高可用性構成を変更できないことなどが説明されています。(Microsoft Learn)
実務で特に注意したい落とし穴を整理します。
| 落とし穴 | 具体例 | 対応策 |
|---|---|---|
| 宛先設定だけでデータが出ると思い込む | 監視画面に何も表示されない | アプリ側のSDK計装と環境変数を確認する |
| アプリ単位で送信先を分けられると思う | 同一環境内の複数アプリが同じ宛先設計になる | Container Apps環境の分離を検討する |
| Application Insightsにメトリックも送れると思う | メトリックが見つからない | メトリックは別宛先を検討する |
| 外部SaaS側の権限不足 | ログだけ届き、メトリックやトレースが届かない | トークンのスコープを確認する |
| 旧Collectorを残したまま本番化する | データ重複、コスト増、アラート重複 | 移行後に旧経路を停止する |
| エージェントの状態監視を前提にする | ポータルでエージェントヘルスを確認できない | 宛先側で受信状況を監視する |
マネージド機能は運用を楽にしますが、完全に監視設計を不要にするものではありません。むしろ、環境単位で標準化される分、最初の設計を誤ると影響範囲が広くなります。
管理者・開発者向けチェックリスト
本番展開前には、次のチェックリストを使って確認すると抜け漏れを防ぎやすくなります。
| 分類 | チェック項目 |
|---|---|
| 対象範囲 | Azure Container Apps環境、対象アプリ、対象リビジョンを把握している |
| 送信先 | New Relic、Dynatrace、Elasticのどれに何を送るか決まっている |
| データ種別 | ログ、メトリック、トレースの送信要否を決めている |
| 計装 | アプリにOpenTelemetry SDKが導入されている |
| 環境変数 | OTEL_SERVICE_NAMEと各Exporter設定を確認している |
| 認証 | APIキーやトークンの権限が必要最小限になっている |
| セキュリティ | ログに個人情報・秘密情報が含まれないことを確認している |
| ネットワーク | Container Apps環境から外部OTLPエンドポイントへ到達できる |
| コスト | 外部監視基盤の取り込み量と保持期間を見積もっている |
| 移行 | 旧Collectorや旧エージェントとの二重送信期間を管理している |
| 検証 | 外部基盤でサービス名、環境名、ログ、メトリック、トレースを確認している |
| ロールバック | 宛先設定を戻す手順、旧経路に戻す手順を用意している |
どのような組織にとってメリットが大きいか
今回の更新は、特に次のような組織に向いています。
すでに外部オブザーバビリティ基盤を標準化している組織
New Relic、Dynatrace、Elasticを全社標準として使っている場合、Azure Container AppsだけAzure Monitor中心で別管理するよりも、既存の監視ワークフローへ統合したほうが運用しやすくなります。
障害対応では、開発者、SRE、インフラ管理者が同じ画面でログ・メトリック・トレースを見ることが重要です。監視基盤が分散していると、原因調査のたびに画面を切り替え、用語やサービス名を突き合わせる作業が発生します。
マイクロサービス構成で分散トレースを重視する組織
Azure Container Appsは、API、バックエンドワーカー、イベント処理などを小さなコンテナ単位で動かす構成と相性が良いサービスです。一方で、サービスが増えるほど「どこで遅くなっているのか」「どのリクエストがどのサービスを通ったのか」を追うのが難しくなります。
OpenTelemetryのトレースを外部基盤へ送れるようにしておくと、障害時にログだけを検索するよりも、サービス間の流れを把握しやすくなります。
Collector運用を減らしたい組織
自前のOpenTelemetry Collectorは柔軟ですが、設定ファイル、コンテナイメージ、スケール、可用性、セキュリティパッチ、デプロイ手順を管理する必要があります。Azure Container AppsのマネージドOpenTelemetryエージェントで要件を満たせるなら、運用対象を減らせます。
ただし、複雑なprocessor設定、細かなサンプリング、独自の属性加工、複数段のルーティングなどが必要な場合は、引き続き自前Collectorのほうが適していることもあります。
まず取るべき行動
今回のAzure Container Apps OpenTelemetry宛先サポート拡張は、New Relic、Dynatrace、Elasticを使うAzure利用者にとって、監視設計を見直す良いタイミングです。
まずは、次の順番で進めるのがおすすめです。
- Azure Container Appsで動いているアプリとContainer Apps環境を棚卸しする
- 現在のログ、メトリック、トレースの送信先を整理する
- New Relic、Dynatrace、Elasticのどれを標準の受け皿にするか決める
- 検証環境でマネージドOpenTelemetryエージェントの宛先設定を試す
- データが届くことだけでなく、サービス名、属性、コスト、アラートまで確認する
- 本番では段階的に有効化し、旧Collectorや重複送信を整理する
今回の更新は「監視ツールが増えた」というだけではありません。Azure Container Appsの可観測性を、アプリ単位の個別設定から、環境単位の標準化へ近づける変更です。管理者は送信先とセキュリティを、開発者はOpenTelemetry計装とサービス名設計を確認し、運用チームが実際に使える監視データとして整備していきましょう。
コメント