MENU

Azure Container AppsのHTTPトラフィック監視がGA：ContainerAppHTTPLogsの変更点と設定確認ポイント

Azure

2026年6月3日に公開・更新情報として確認された「Generally Available: Monitor HTTP traffic in Azure Container Apps」は、Azure Container Apps の受信 HTTP トラフィックを Azure Monitor でより詳細に監視できるようにする更新です。結論から言うと、管理者や開発者は Container Apps 環境の診断設定に ContainerAppHTTPLogs を追加するか、既存の allLogs 設定で意図せず大量ログを取り込み始めていないか を確認すべきです。Microsoft の Azure Updates では Azure ID 562559 として掲載され、プラットフォームレベルのログに加えて、受信 HTTP アクセスログ向けの専用診断カテゴリ ContainerAppHTTPLogs が追加されたことが示されています。(Microsoft Azure)

この更新により、リクエストのメソッド、パス、ステータスコード、応答時間、リビジョン、レプリカなどを Log Analytics で分析しやすくなります。障害調査、リリース後のリビジョン比較、API の遅延分析、5xx エラーの検知に使える一方、HTTP ログは件数が多くなりやすいため、コスト、保持期間、個人情報・機密情報の扱いまで含めて設計する必要があります。

目次

Azure Container AppsのHTTPトラフィック監視で何が変わったのか

今回のポイントは、Azure Container Apps の HTTP アクセスログを、Azure Monitor の診断設定カテゴリとして扱えるようになったことです。Azure Container Apps では、従来からアプリケーションの標準出力・標準エラーに由来するコンソールログや、Container Apps サービスが生成するシステムログを利用できました。Microsoft Learn では、HTTP ログは診断設定で有効化された場合にイングレス層から出力されるログとして説明されています。(Microsoft Learn)

今回追加された ContainerAppHTTPLogs は、アプリケーション内で独自にアクセスログを実装しなくても、Azure Container Apps のイングレスで観測された HTTP リクエストを分析するためのログです。API や Web アプリの「どのパスで」「どのステータスコードが」「どのリビジョンで」「どれくらい遅いのか」を、運用側で横断的に見られるようになる点が大きな違いです。

観点これまで中心だったログContainerAppHTTPLogs で見やすくなる情報
アプリの出力stdout / stderr のコンソールログアプリ内部の処理ログとは別に、HTTP リクエスト単位のアクセス状況
プラットフォーム状態リビジョン、Dapr、Keda、Envoy などのシステムログルーティング結果、ステータスコード、レスポンス時間
障害調査アプリログからエラー文字列を探す4xx / 5xx、遅いリクエスト、失敗したエンドポイントを KQL で抽出
リリース確認メトリックやアプリログで確認リビジョン別のリクエスト数、エラー率、P95 レイテンシを比較
運用上の注意ログ量は比較的アプリ実装に依存HTTP リクエスト数に比例してログ量が増えやすい

Azure Updates のステータス「Launched」は、Microsoft Azure の更新ページ上では「production-ready product available to all Azure customers」と説明されており、本番利用を前提に検討しやすい段階です。(Microsoft Azure) ただし、一般提供だからといって自動で最適な監視設計になるわけではありません。診断設定、宛先、コスト管理、アラート設計は利用者側で確認が必要です。

ContainerAppHTTPLogsで確認できる主な項目

ContainerAppHTTPLogs では、HTTP リクエストの調査に必要な情報をかなり細かく確認できます。Microsoft Learn のスキーマでは、Method、Path、Protocol、UserAgent、XForwardedFor、StatusCode、RequestDuration、RequestId、ContainerAppName、RevisionName、ReplicaName、EnvironmentName、UpstreamRequestAttemptCount などが説明されています。(Microsoft Learn)

実務で特に使う項目は、次のとおりです。

項目使いどころ
Method / Pathどの API や画面でエラー・遅延が起きているかを確認する
StatusCode4xx、5xx、接続断などを集計する
ResponseCodeDetailsroute_not_found や upstream_per_try_timeout など、失敗理由の切り分けに使う
RequestDuration遅いリクエスト、P95 / P99 レイテンシの分析に使う
ContainerAppName同じ環境内の複数アプリを絞り込む
RevisionName新旧リビジョンのエラー率や遅延を比較する
ReplicaName特定レプリカに偏った障害を追跡する
RequestIdアプリログや顧客報告と突き合わせる
XForwardedForクライアント IP の傾向を見る。ただし個人情報として扱う

注意したいのは、Path にはクエリ文字列が含まれ、クライアントがトークンや API キーをクエリで渡している場合はログに出る可能性がある点です。また、XForwardedFor にはエンドユーザーの IP が含まれるため、Microsoft Learn でも PII として扱うよう説明されています。(Microsoft Learn)

影響を受ける環境と確認すべき対象

今回の更新で主に影響を受けるのは、Azure Container Apps で HTTP ingress を利用している環境です。特に、外部公開 API、社内 Web アプリ、BFF、Webhook 受信、マイクロサービス間通信の入口として Container Apps を使っている場合は、監視改善の効果が大きくなります。

一方で、HTTP トラフィックが少ないバックグラウンド処理、ジョブ中心の構成、外部から直接アクセスされないワークロードでは、すぐに有効化する必要性は相対的に低いかもしれません。とはいえ、障害発生時に「HTTP レイヤーで何が起きたか」を後から確認できるかどうかは運用品質に直結します。

対象影響・確認ポイント
Azure 管理者Container Apps 環境のログ宛先、診断設定、Log Analytics ワークスペース、保持期間、コストを確認する
開発者RequestId、ステータスコード、アプリログとの突き合わせ方法を整える
SRE / 運用担当5xx、P95 レイテンシ、リビジョン別エラー率のアラートを設計する
セキュリティ担当Path のクエリ文字列、XForwardedFor、保持期間、アクセス権限を確認する
FinOps担当HTTP ログの取り込み量、ワークスペース課金、アーカイブ先のコストを監視する

特に見落としやすいのが、既存の診断設定で categoryGroup: allLogs を使っている環境です。Azure Monitor のカテゴリグループは、カテゴリが更新されるとログ収集対象も自動的に変更される仕組みです。(Microsoft Learn) そのため、既存環境で allLogs を使っている場合は、ContainerAppHTTPLogs が含まれるか、ログ量が急増していないかを早めに確認してください。

管理者が確認すべき診断設定

Azure Monitor の診断設定では、リソースログやプラットフォームメトリックを Log Analytics、Storage、Event Hubs、パートナーソリューションなどに送信できます。リソースログは既定では収集されないため、必要なログカテゴリを選び、送信先を設定する必要があります。(Microsoft Learn)

Azure Container Apps のログオプションは、Container Apps 環境レベルで構成できます。ログ宛先として Azure Monitor を選ぶと、環境レベルとコンテナーアプリレベルで診断設定を構成できますが、HTTP ログの対象として確認すべき中心は Container Apps 環境です。Microsoft Learn の対応ログカテゴリ一覧では、Microsoft.App/managedEnvironments のログカテゴリとして ContainerAppHTTPLogs が掲載されています。(Microsoft Learn) (Microsoft Learn)

Azure Portalで確認する手順

Azure Portal で確認する場合は、まず Container Apps 環境を開き、ログ宛先と診断設定を確認します。

手順確認内容
Container Apps 環境を開く個別の Container App ではなく、まず環境側の監視設定を確認する
監視 > ログ オプションログ宛先が Azure Monitor になっているか確認する
監視 > 診断設定既存の診断設定に allLogs や ContainerAppHTTPLogs が含まれるか確認する
診断設定の追加または編集必要に応じて ContainerAppHTTPLogs を選択し、宛先を設定する
Log Analyticsで確認テストリクエスト後に ContainerAppHTTPLogs テーブルをクエリする

ログ宛先で Azure Monitor を選ぶ場合、保存後に診断設定を構成する必要があります。また、Log Analytics ワークスペース、Storage、Event Hubs、パートナーソリューションを宛先として選択できます。(Microsoft Learn) (Microsoft Learn)

Azure CLIで有効化する例

既存の Container Apps 環境で Azure Monitor にログを送る場合は、環境のログ宛先を Azure Monitor に更新したうえで、診断設定を作成します。ContainerAppHTTPLogs が利用可能かは、実行前にカテゴリ一覧で確認しておくと安全です。

# 環境IDを取得
ENV_ID=$(az containerapp env show \
  --name <ENVIRONMENT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --query id -o tsv)

# Log Analytics ワークスペースIDを取得
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --workspace-name <WORKSPACE_NAME> \
  --resource-group <WORKSPACE_RESOURCE_GROUP> \
  --query id -o tsv)

# Container Apps 環境のログ宛先を Azure Monitor に変更
az containerapp env update \
  --name <ENVIRONMENT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --logs-destination azure-monitor

# 利用可能な診断カテゴリを確認
az monitor diagnostic-settings categories list \
  --resource "$ENV_ID" \
  -o table

# HTTPログを Log Analytics に送信
az monitor diagnostic-settings create \
  --name aca-http-logs-to-law \
  --resource "$ENV_ID" \
  --logs '[{"category":"ContainerAppHTTPLogs","enabled":true}]' \
  --workspace "$WORKSPACE_ID" \
  --export-to-resource-specific true

az containerapp env update では --logs-destination azure-monitor を指定できます。診断設定の作成には az monitor diagnostic-settings create を使用し、--logs でログカテゴリを指定します。--export-to-resource-specific は、Log Analytics への出力をリソース固有テーブルにするためのオプションです。(Microsoft Learn) (Microsoft Learn)

Log Analyticsで使える実用KQL

ContainerAppHTTPLogs を有効にしたら、まずは「見えるかどうか」ではなく、「運用時に判断できる形で見えるか」を確認します。Microsoft Learn でも、最近の HTTP エラー、遅いリクエスト、リビジョン別のリクエスト数とエラー率、単一リクエストの追跡などのクエリ例が示されています。(Microsoft Learn)

最近のHTTPエラーを見る

障害発生時に最初に実行したいクエリです。4xx と 5xx をまとめて見たあと、必要に応じて 5xx のみに絞ります。

ContainerAppHTTPLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| project TimeGenerated, ContainerAppName, RevisionName, Method, Path,
          StatusCode, ResponseCodeDetails, RequestDuration, RequestId
| order by TimeGenerated desc
| take 100

ResponseCodeDetails を見ると、ルーティング設定の問題なのか、アプリ側が返したエラーなのかを切り分けやすくなります。たとえば route_not_found はルーティング設定の問題、via_upstream はコンテナー側が応答したことを示す例として説明されています。(Microsoft Learn)

遅いリクエストを確認する

ユーザーから「画面が遅い」「API の応答が遅い」と報告された場合は、RequestDuration を使って遅いリクエストを抽出します。

ContainerAppHTTPLogs
| where TimeGenerated > ago(1h)
| where ContainerAppName == "<app-name>"
| top 50 by RequestDuration desc
| project TimeGenerated, Method, Path, StatusCode, RequestDuration,
          ReplicaName, UpstreamRequestAttemptCount, RequestId

RequestDuration はミリ秒単位です。UpstreamRequestAttemptCount > 1 とあわせて高い値が出ている場合、再試行によって応答時間が伸びている可能性があります。(Microsoft Learn)

リビジョン別にエラー率とP95を比較する

Blue/Green デプロイやカナリアリリース後の確認に向いています。新しいリビジョンだけエラー率や P95 が悪化していないかを見ます。

ContainerAppHTTPLogs
| where TimeGenerated > ago(6h)
| where ContainerAppName == "<app-name>"
| summarize Requests = count(),
            Errors = countif(StatusCode >= 500),
            ErrorRatePct = round(100.0 * countif(StatusCode >= 500) / count(), 2),
            P95DurationMs = percentile(RequestDuration, 95)
  by RevisionName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc
| render timechart

新しいリビジョンが急にリクエスト 0 になっている場合は、トラフィック重み付けの問題を疑います。新リビジョンのエラー率や P95 が旧リビジョンより高い場合は、ロールバック判断の材料になります。(Microsoft Learn)

失敗が多いエンドポイントを優先順位付きで探す

エラーが多すぎて原因箇所が分からない場合は、パス単位で集計します。

ContainerAppHTTPLogs
| where TimeGenerated > ago(24h)
| where StatusCode >= 400
| summarize Errors = count(),
            DistinctClientIPs = dcount(XForwardedFor),
            SampleStatusCodes = make_set(StatusCode, 5),
            ExampleDetails = take_any(ResponseCodeDetails)
  by ContainerAppName, Method, Path
| order by Errors desc
| take 20

DistinctClientIPs が多いエラーは広範囲に影響している可能性が高く、少ない場合は特定クライアント、スキャナー、誤ったリトライなどが原因の可能性があります。(Microsoft Learn)

移行・展開時に失敗しやすいポイント

ContainerAppHTTPLogs は便利ですが、有効化すれば終わりではありません。特に本番環境では、ログ量、クエリ、権限、個人情報、既存の監視設計への影響を確認してから展開する必要があります。

allLogsで意図せず大量ログを取り込む可能性がある

診断設定で allLogs を使っている場合、新しいカテゴリが追加された際に収集対象が広がる可能性があります。HTTP ログはリクエスト数に比例して増えるため、アクセスの多い環境では Log Analytics の取り込み量や保持コストに影響します。

既存設定を確認するには、次の観点で棚卸しします。

確認項目判断基準
categoryGroup が allLogs か新カテゴリが含まれる可能性を前提に、取り込み量を確認する
宛先が Log Analytics かワークスペースの取り込み量、保持期間、アラートルールを確認する
宛先が Storage か長期保存コスト、ライフサイクル管理、監査要件を確認する
宛先が Event Hubs かdownstream の SIEM や分析基盤がログ増加に耐えられるか確認する
複数環境で同一設定か開発・検証・本番で同じ allLogs を使っていないか確認する

Azure Monitor の診断設定は、送信先やログ量に応じてコストが発生する可能性があります。Microsoft Learn でも、必要なカテゴリのみを収集し、不要なプラットフォームメトリックの収集を避けることがコスト管理のポイントとして説明されています。(Microsoft Learn)

テーブルがすぐに見えないことがある

HTTP ログを有効にしても、ContainerAppHTTPLogs テーブルが Log Analytics に表示されるまで数分かかることがあります。Microsoft Learn でも、HTTP ログを有効にした後にテーブルが表示されるまで数分かかる場合があると説明されています。(Microsoft Learn)

また、Azure Monitor の診断設定全般では、設定後に選択した宛先へデータが流れ始めるまで最大 90 分程度を見込むべきケースがあります。(Microsoft Learn) 検証時は、設定直後に「出ない」と判断せず、テストリクエストを流してから一定時間待つ運用にしてください。

Portalの「ログ」メニューの見え方が変わる

Container Apps 環境のログ宛先で Azure Monitor を選ぶと、Azure portal の Log Analytics クエリエディターを提供する「ログ」メニューが無効になる場合があります。これはログが見られなくなるという意味ではなく、診断設定の宛先として指定した Log Analytics ワークスペース側でクエリする運用に切り替えるということです。(Microsoft Learn)

運用チームには、次のように伝えておくと混乱を避けられます。

誤解しやすい点正しい見方
Container App の「ログ」が無効になったのでログが消えたAzure Monitor 宛先では、指定した Log Analytics ワークスペースでクエリする
ContainerAppConsoleLogs_CL と同じ書き方でよいContainerAppHTTPLogs は新しい HTTP ログ用のテーブルとして扱う
既存のアプリログだけ見れば十分HTTP レイヤーの失敗、ルーティング、応答時間は HTTP ログで見る
すぐ表示されないので設定ミス初回はテーブル作成・取り込みに時間がかかる場合がある

クエリ文字列とIPアドレスの扱いを見直す

HTTP ログには、リクエストパスやクライアント IP に関する情報が含まれます。クエリ文字列にトークン、メールアドレス、API キー、顧客 ID を含める設計になっている場合、ログに機密情報が残る可能性があります。

対応としては、次の順で見直すのが現実的です。

優先度対応
高API キーやトークンをクエリ文字列で渡していないか確認する
高Log Analytics ワークスペースへの閲覧権限を最小化する
高保持期間を業務要件に合わせて短く設定する
中顧客 ID などをパスやクエリに含める設計を見直す
中インシデント対応用の閲覧ロールと通常運用ロールを分ける
低長期分析が必要な場合は Storage アーカイブとライフサイクル管理を検討する

開発者が活用すべき場面

開発者にとっての価値は、アプリログだけでは見えにくかった「外から見た失敗」を確認できる点です。

たとえば、アプリ内では正常終了しているように見えても、イングレス側でタイムアウトやルーティング失敗が起きている場合があります。ResponseCodeDetails や ResponseFlags を見ることで、アプリ内部の例外なのか、ルーティングやアップストリーム接続の問題なのかを切り分けやすくなります。

また、RevisionName を使えば、デプロイ後に新リビジョンだけエラー率が上がっていないかを確認できます。CI/CD パイプラインやリリースチェックに、次のような確認を入れると実用的です。

タイミング確認するKQLの観点
リリース直後新リビジョンのリクエスト数が想定通り増えているか
カナリア配信中新旧リビジョンで 5xx 率、P95 レイテンシに差がないか
障害報告時RequestId、Path、StatusCode、ReplicaName を突き合わせる
パフォーマンス改善後対象パスの P95 / P99 が改善しているか
ルーティング変更後route_not_found や NR が増えていないか

顧客やフロントエンドから x-request-id を渡せる設計にしておくと、RequestId を起点に HTTP ログとアプリログを突き合わせやすくなります。Microsoft Learn では、RequestId はクライアントが x-request-id ヘッダーを指定した場合はそれを反映し、指定がない場合はイングレスが生成すると説明されています。(Microsoft Learn)

導入すべきかの判断基準

ContainerAppHTTPLogs は、すべての環境で無条件にフル収集すべきものではありません。導入判断は、障害時の可観測性とログコストのバランスで決めます。

状況判断
本番の外部公開 API を Container Apps で運用している早めに有効化する価値が高い
リビジョン分割、カナリア、Blue/Green を使っているリビジョン別比較に有効
5xx や遅延の原因調査に時間がかかっている優先度高く導入する
既に API Gateway や Front Door で十分なアクセスログを取っている重複範囲と保持期間を整理してから導入する
開発・検証環境でリクエストが少ない低コストで先行検証しやすい
高トラフィックでコスト管理が未整備いきなり全環境ではなく、対象環境を絞って段階導入する
HTTP ingress を使っていない優先度は低い

おすすめは、まず検証環境または本番に近い一部環境で有効化し、1日あたりのログ件数、取り込み量、よく使う KQL、アラート条件を確認することです。そのうえで、本番全体に展開するか、重要アプリを分離した Container Apps 環境に限定するかを決めると失敗しにくくなります。

展開前チェックリスト

本番環境に展開する前に、次の項目を確認してください。

チェック項目確認内容
対象環境HTTP ingress を使っている Container Apps 環境を洗い出したか
既存診断設定allLogs により意図せず収集対象が広がっていないか
ログ宛先Log Analytics、Storage、Event Hubs、パートナーソリューションのどれに送るか決めたか
テーブル確認ContainerAppHTTPLogs にテストリクエストが入るか確認したか
コスト1日あたりの取り込み量と保持期間を見積もったか
セキュリティPath、クエリ文字列、XForwardedFor の扱いをレビューしたか
権限Log Analytics ワークスペースの閲覧権限を最小化したか
アラート5xx 率、P95 レイテンシ、特定パスの異常を検知できるか
ダッシュボードリクエスト数、エラー率、遅延、リビジョン別比較を可視化したか
運用手順障害時に実行する KQL と一次切り分け手順を用意したか

まず実施すべき次のアクション

今回の一般提供は、Azure Container Apps を本番利用しているチームにとって、HTTP レイヤーの可観測性を高める良い機会です。まずは Container Apps 環境の診断設定を確認し、ContainerAppHTTPLogs が利用可能か、既存の allLogs 設定でログ量が変化していないかを確認してください。

次に、検証環境で ContainerAppHTTPLogs を Log Analytics に送信し、最近のエラー、遅いリクエスト、リビジョン別エラー率の KQL を保存します。最後に、コストと個人情報の扱いを確認したうえで、本番環境では重要な API から段階的に展開するのが安全です。

ContainerAppHTTPLogs は、単なるログカテゴリの追加ではなく、「障害時にどこから調べるか」を変える更新です。アプリログ、メトリック、HTTP アクセスログを組み合わせることで、Azure Container Apps の運用はより原因特定しやすく、リリース判断もしやすくなります。

Azure
Azure Monitor Azure Container Apps Log Analytics ContainerAppHTTPLogs

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次