すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:データプレーンのアクセスログのカスタマイズ

    ドキュメントセンター

    Alibaba Cloud Service Mesh:データプレーンのアクセスログのカスタマイズ

    最終更新日:Mar 12, 2026

    Service Mesh (ASM) インスタンスに Kubernetes クラスターを追加すると、データプレーン上の Envoy プロキシがすべてのインバウンドおよびアウトバウンドトラフィックをログ記録します。これらのアクセスログをカスタマイズすることで、トラブルシューティング、監査、またはモニタリングのために特定のリクエストおよび応答のメタデータを収集できます。

    アクセスログのカスタマイズは、以下のような場合に有効です。

    • リクエスト失敗のデバッグ：ヘッダーまたはタイミング関連のフィールドを追加して、リクエストが失敗または遅延する箇所を特定します。

    • コンプライアンス要件への対応：監査およびデータ保持ポリシーを満たすために、特定のフィールドを含めるか除外します。

    • ノイズの低減：デフォルトで出力される全フィールドではなく、ご利用の運用に必要なフィールドのみをログ記録します。

    前提条件

    アクセスログの有効化

    手順は ASM インスタンスのバージョンによって異なります。

    ASM インスタンスのバージョンが 1.17.2.35 より前の場合

    1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > Mesh Management を選択します。

    2. Mesh Management ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、ASM Instance > Base Information を選択します。

    3. 右上隅の 設定項目 をクリックします。

    4. 設定項目の更新 パネルで、アクセスログの有効化およびコンテナの標準出力への出力 を選択し、OK をクリックします。

    アクセスログが有効化されると、istio-proxy コンテナは以下のデフォルトフィールドを含む JSON 形式でログを出力します。

    デフォルトのログフィールド

    {
    "authority_for": "%REQ(:AUTHORITY)%",
    "bytes_received": "%BYTES_RECEIVED%",
    "bytes_sent": "%BYTES_SENT%",
    "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
    "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
    "duration": "%DURATION%",
    "istio_policy_status": "%DYNAMIC_METADATA(istio.mixer:status)%",
    "method": "%REQ(:METHOD)%",
    "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
    "protocol": "%PROTOCOL%",
    "request_id": "%REQ(X-REQUEST-ID)%",
    "requested_server_name": "%REQUESTED_SERVER_NAME%",
    "response_code": "%RESPONSE_CODE%",
    "response_flags": "%RESPONSE_FLAGS%",
    "route_name": "%ROUTE_NAME%",
    "start_time": "%START_TIME%",
    "trace_id": "%REQ(X-B3-TRACEID)%",
    "upstream_cluster": "%UPSTREAM_CLUSTER%",
    "upstream_host": "%UPSTREAM_HOST%",
    "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
    "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
    "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%",
    "user_agent": "%REQ(USER-AGENT)%",
    "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%"
}

    アクセスログが無効化されている場合、istio-proxy コンテナは JSON 形式でアクセスログを出力しません。

    ASM インスタンスのバージョンが 1.17.2.35 以降の場合

    1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > Mesh Management を選択します。

    2. Mesh Management ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、Observability Management Center > Observability Settings を選択します。

    3. Observability Settings ページで、グローバル、名前空間、または カスタム タブをクリックして、構成の適用範囲を設定します。

      • グローバル：メッシュ内のすべてのサイドカープロキシおよびゲートウェイに適用されます。

      • 名前空間：作成 をクリックし、名前空間 のドロップダウンリストから名前空間を選択して、特定の名前空間に設定を適用します。

      • カスタム：作成 をクリックし、名前空間 のドロップダウンリストから名前空間を選択した後、名前 および マッチングラベル を設定して、特定のワークロードを対象とします。

    4. ログ設定 セクションで、ログ出力の有効化 をオンにし、送信 をクリックします。スイッチをオンにすると、サイドカープロキシおよびゲートウェイがそのコンテナの標準出力（stdout）にアクセスログを出力します。ASM では、ログ量を削減するためのログフィルター機能もサポートされています。詳細については、「ログのフィルター処理」（「可観測性設定の構成」トピック内）をご参照ください。

    5. サイドカーコンテナの標準出力のログを表示することで、アクセスログが正常に動作していることを確認します。

      以下のコマンドを実行して、サイドカープロキシからの最新のアクセスログエントリを表示します。

      kubectl logs <pod-name> -c istio-proxy --tail 1

      <pod-name> は、ご利用のクラスター内の Pod の名前に置き換えてください。例：

      kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1

      サンプル出力

      {
       "authority_for": "47.110.XX.XXX",
       "bytes_received": "0",
       "bytes_sent": "22382",
       "downstream_local_address": "192.168.0.29:80",
       "downstream_remote_address": "221.220.XXX.XXX:0",
       "duration": "80",
       "istio_policy_status": "-",
       "method": "GET",
       "path": "/static/favicon.ico",
       "protocol": "HTTP/1.1",
       "request_id": "0f2cf829-3da5-4810-a618-08d9745d****",
       "requested_server_name": "outbound_.8000_._.httpbin.default.svc.cluster.local",
       "response_code": "200",
       "response_flags": "-",
       "route_name": "default",
       "start_time": "2023-06-30T04:00:36.841Z",
       "trace_id": "-",
       "upstream_cluster": "inbound|80||",
       "upstream_host": "192.168.0.29:80",
       "upstream_local_address": "127.0.X.X:55879",
       "upstream_response_time": "79",
       "upstream_service_time": "79",
       "upstream_transport_failure_reason": "-",
       "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
       "x_forwarded_for": "221.220.XXX.XXX"
   }

      代わりにイングレスゲートウェイのログを表示するには：

      kubectl -n istio-system logs <gateway-pod-name> --tail 1

      例：

      kubectl -n istio-system logs istio-ingressgateway-6cff9b6b58-r**** --tail 1

      サンプル出力

      {
       "authority_for": "47.110.XX.XXX",
       "bytes_received": "0",
       "bytes_sent": "22382",
       "downstream_local_address": "192.168.0.63:80",
       "downstream_remote_address": "221.220.XXX.XXX:64284",
       "duration": "81",
       "istio_policy_status": "-",
       "method": "GET",
       "path": "/static/favicon.ico",
       "protocol": "HTTP/1.1",
       "request_id": "0f2cf829-3da5-4810-a618-08d9745d****",
       "requested_server_name": "-",
       "response_code": "200",
       "response_flags": "-",
       "route_name": "httpbin",
       "start_time": "2023-06-30T04:00:36.841Z",
       "trace_id": "-",
       "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local",
       "upstream_host": "192.168.0.29:80",
       "upstream_local_address": "192.168.0.63:36140",
       "upstream_response_time": "81",
       "upstream_service_time": "81",
       "upstream_transport_failure_reason": "-",
       "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
       "x_forwarded_for": "221.220.XXX.XXX"
   }

    6. （任意）Container Service for Kubernetes (ACK) コンソールでアクセスログを表示します。クラスターが ACK 上で実行されている場合、コンソールから直接アクセスログを表示できます。

      1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスター をクリックします。

      2. クラスター ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、ワークロード > Pod を選択します。

      3. Pod ページで、Pod の名前をクリックし、ログ タブをクリックします。

    アクセスログフィールドのカスタマイズ

    アクセスログが有効化された後、カスタムフィールドを追加したり、ログフォーマットを変更したりして、追加のリクエストまたは応答のメタデータを収集できます。

    ASM インスタンスのバージョンが 1.17.2.35 より前の場合

    1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > Mesh Management を選択します。

    2. Mesh Management ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、ASM Instance > Base Information を選択します。

    3. 構成情報 セクションで、アクセスログフォーマットの更新 を、アクセスログの有効化およびコンテナの標準出力への出力 の横にあるリンクをクリックして起動します。

    4. アクセスログフォーマットの更新 ダイアログボックスで、カスタムフィールドを追加します。この例では、Bookinfo サンプルアプリケーションで使用される HTTP リクエストの end-user ヘッダーを抽出し、アクセスログに挿入します。ASM が提供するオプションフィールドから選択するか、独自に定義できます。その後、OK をクリックすると、更新されたフォーマットでアクセスログが出力されます。以下の図には、利用可能なオプションフィールドとサンプルのカスタムフィールドが示されています。

      • accessLogFormat key をログ出力におけるフィールド名（例：my_custom_key）に設定します。

      • accessLogFormat value を値を抽出する Envoy コマンド演算子（例：%REQ(end-user)%）に設定します。

      Optional fields and custom field configuration

    ASM インスタンスのバージョンが 1.17.2.35 以降の場合

    1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > Mesh Management を選択します。

    2. Mesh Management ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、Observability Management Center > Observability Settings を選択します。

    3. Observability Settings ページで、グローバル、名前空間、または カスタム タブをクリックします。

      • 名前空間 タブ： 作成 をクリックし、名前空間 のドロップダウンリストから名前空間を選択します。

      • カスタム タブ： 作成 をクリックし、名前空間 のドロップダウンリストから名前空間を選択した後、名前 および マッチングラベル を設定します。

    4. ログ設定 セクションで、ログフィールドをカスタマイズします。各カスタムフィールドについて、以下の項目を指定します。さらにフィールドを追加するには、ログメトリクスの右側にある add icon アイコンをクリックします。その後、送信 をクリックします。以下の図には、ログフォーマット設定の例が示されています。

      ログフィールドのカスタマイズには、ログ出力の有効化 がオンになっている必要があります。ログフォーマット セクションのデフォルトログフィールドは必須であり、削除できません。
      設定項目説明
      accessLogFormat keyログ出力におけるフィールド名（例：accept-encoding）。
      タイプ値のソース： リクエストプロパティ、レスポンスヘッダー、または Envoy 組み込み値。
      accessLogFormat value抽出するヘッダー名または Envoy 変数（例：Accept-Encoding）。

      Log format configuration

    5. カスタムフィールドがアクセスログに表示されることを確認します。

      kubectl logs <pod-name> -c istio-proxy --tail 1 | grep <custom-field-key> --color=auto

      例：

      kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1 | grep accept-encoding --color=auto

      サンプル出力

         {
       "bytes_received": "0",
       "bytes_sent": "9593",
       "downstream_local_address": "192.168.0.29:80",
       "downstream_remote_address": "69.164.XXX.XX:0",
       "duration": "2",
       "istio_policy_status": "-",
       "method": "GET",
       "path": "/",
       "protocol": "HTTP/1.1",
       "request_id": "29939dc9-62be-4ddf-acf6-32cb098d****",
       "requested_server_name": "outbound_.8000_._.httpbin.default.svc.cluster.local",
       "response_code": "200",
       "response_flags": "-",
       "route_name": "default",
       "start_time": "2023-06-30T04:18:19.734Z",
       "trace_id": "-",
       "upstream_cluster": "inbound|80||",
       "upstream_host": "192.168.0.29:80",
       "upstream_local_address": "127.0.X.X:34723",
       "upstream_service_time": "2",
       "upstream_transport_failure_reason": "-",
       "user_agent": "Mozilla/5.0 zgrab/0.x",
       "x_forwarded_for": "69.164.XXX.XX",
       "authority_for": "47.110.XX.XXX",
       "upstream_response_time": "2",
       "accept-encoding": "gzip"
   }

      末尾の accept-encoding フィールドにより、カスタムフィールドが正しく動作していることが確認できます。

    Bookinfo アプリケーションによるカスタムアクセスログの検証

    アクセスログの有効化およびフィールドのカスタマイズ後、リクエストを開始するサイドカーコンテナがカスタムフォーマットでアクセスログを出力します。以下の手順では、Bookinfo サンプルアプリケーションを使用して、カスタムフィールド（例： my_custom_key を %REQ(end-user)% にマップしたもの）が実際のトラフィックログに表示されることを検証します。

    1. ブラウザのアドレスバーに <ingress-gateway-IP>:productpage を入力して、Productpage アプリケーションにアクセスします。

    2. ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスター をクリックします。

    3. クラスター ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、ワークロード > デプロイメント を選択します。

    4. デプロイメント ページで、名前空間 のドロップダウンリストから default を選択し、productpage-v1 の 操作 列の 詳細 をクリックします。

    5. 詳細ページで、ログ タブをクリックし、コンテナ を istio-proxy に設定します。ログ出力にはカスタムフィールドが含まれます。たとえば、end-user ヘッダーが jason に設定されている場合、ログには値 jason を持つフィールドが含まれ、カスタム構成が有効であることが確認できます。

      Access log with custom end-user field

    期間関連フィールドのリファレンス

    サービスメッシュの用語では、upstream はリクエストを受信するサービスを指し、downstream はリクエストを開始するサービスを指します。たとえば、サービス A がサービス B を呼び出す場合、サービス A は downstream、サービス B は upstream となります。

    以下の表は、アクセスログで利用可能な期間関連フィールドについて説明しています。これらのフィールドを使用して、リクエストライフサイクル全体にわたるレイテンシー問題を診断できます。

    フィールドEnvoy 変数HTTP リクエストTCP リクエスト
    duration%DURATION%プロキシがリクエストの読み取りを開始してから、最後の応答バイトを downstream サービスに送信するまでの合計時間。downstream 接続の持続時間。
    request_duration%REQUEST_DURATION%downstream サービスからリクエスト全体（ヘッダー＋本文）を読み取るまでの時間。値が高い場合、ネットワーク品質が低い、帯域幅が不足している、または I/O ボトルネックが発生している可能性があります。利用不可（-）。
    request_tx_duration%REQUEST_TX_DURATION%リクエストの開始から、最後のリクエストバイトを upstream サービスに送信するまでの時間。値が高い場合、ネットワークまたは I/O の問題が発生している可能性があります。利用不可（-）。
    response_duration%RESPONSE_DURATION%リクエストの開始から、upstream サービスから最初の応答バイトを読み取るまでの時間。この値が高いが request_tx_duration が正常な場合、upstream サービスのパフォーマンスボトルネックを確認してください。利用不可（-）。
    response_tx_duration%RESPONSE_TX_DURATION%upstream から最初の応答バイトを読み取ってから、downstream に最後の応答バイトを送信するまでの時間。値が高い場合、ネットワークまたは I/O の問題が発生している可能性があります。利用不可（-）。
    upstream_service_time（サイドカープロキシ）／upstream_response_time（ゲートウェイ）%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%upstream サービスの処理時間および通信遅延。値が高い場合、upstream サービスの処理が遅い、またはネットワーク遅延が高い可能性があります。--
    本文がある HTTP リクエスト（Content-Length > 0）では、プロキシは完全なリクエストを待たずに、読み取りと転送を同時に行います。つまり、現在のノードが downstream サービスから読み取る速度が遅い場合、upstream サービスも完全なリクエストを受信するまでに時間がかかるということです。

    次のステップ