All Products
Search
Document Center

Alibaba Cloud Service Mesh:Customize access logs on the data plane

Last Updated:Apr 03, 2024

After you add a Kubernetes cluster to a Service Mesh (ASM) instance, Envoy proxies that are deployed on the data plane of the ASM instance can print all access logs of the cluster. ASM allows you to customize the fields of access logs printed by Envoy proxies. This topic describes how to customize the fields of access logs.

Prerequisites

Step 1: Enable access logging

For ASM instances of versions earlier than 1.17.2.35

  1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Instance > Base Information.

  3. In the upper-right corner of the page that appears, click Settings.

  4. In the Settings Update panel, select Enable access logging and print it to container stdout and click OK.

    By default, the istio-proxy container prints logs that contain the following fields. If access logging is disabled, the istio-proxy container does not print access logs in the JSON format.

    Show details of a log

    
        "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)%"

For ASM instances of version 1.17.2.35 or later

  1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Observability Management Center > Observability Settings.

  3. On the Observability Settings page, click the Global, Namespace, or Custom tab.

    • If you select the Namespace tab, click Create and select a namespace from the Namespace drop-down list.

    • If you select the Custom tab, click Create, select a namespace from the Namespace drop-down list, and then set Name and Matching Label.

  4. In the Log Settings section, turn on the Enable Log Output switch and click submit.

    After you turn on the switch, the sidecar proxies or gateways on the data plane of the ASM instance print access logs to the standard output of the containers. ASM also supports the log filter feature. For more information, see Filter logs in the "Configure Observability Settings" topic.

  5. View logs in the standard output streams of sidecar containers on the data plane.

    The following example shows how to use kubectl to view access logs.

    1. Run the following command to view the logs of a sidecar proxy:

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

      Show the sample output

      {
          "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"
      }

    2. Run the following command to view the logs of an ingress gateway:

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

      Show the sample output

      {
          "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. (Optional) View access logs in the ACK console.

    If you use a Container Service for Kubernetes (ACK) cluster of Alibaba Cloud, you can also view access logs in the ACK console.

    1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

    2. On the Clusters page, click the name of the cluster that you want to manage and choose Workloads > Pods in the left-side navigation pane.

    3. On the Pods page, click the name of the desired pod and click the Logs tab to view access logs.

For more information about logs, see Configure Observability Settings and Enable control-plane log collection and log-based alerting in an ASM instance of version 1.17.2.35 or later.

Step 2: Customize the fields of access logs

For ASM instances of versions earlier than 1.17.2.35

  1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Instance > Base Information.

  3. In the Config Info section of the page that appears, click Update Access Log Format next to Enable access logging and print it to container stdout.

  4. In the Update Access Log Format dialog box, add a field by setting the accessLogFormat key parameter to my_custom_key and the accessLogFormat value parameter to %REQ(end-user)%. Then, click OK.

    In this example, my_custom_key is used to extract the value of the end-user header field in HTTP requests for the Bookinfo sample application and then insert the value into access logs. You can select optional fields provided by ASM or add custom fields. The following figure shows the optional fields and a sample custom field. Then, access logs will be printed in the custom format.可选字段

For ASM instances of version 1.17.2.35 or later

  1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Observability Management Center > Observability Settings.

  3. On the Observability Settings page, click the Global, Namespace, or Custom tab.

    • If you select the Namespace tab, click Create and select a namespace from the Namespace drop-down list.

    • If you select the Custom tab, click Create, select a namespace from the Namespace drop-down list, and then set Name and Matching Label.

  4. In the Log Settings section, select the desired fields or modify the information of custom fields. You can also click the 增加.png icon to the right of log metrics in the lower part to add log fields. Then, click submit.

    You can customize the fields of access logs only if you turn on Enable Log Output. In the Log Format section, the log fields that are selected by default are mandatory and cannot be modified. You can choose to obtain the value of a log field from the request header, response header, or Envoy built-in value.

    The following example sets accessLogFormat key to accept-encoding, Type to Request Properties, and accessLogFormat value to Accept-Encoding to print the accept-encoding header in requests.日志格式.png

  5. Run the following command to view the logs of the components on the data plane of an ASM instance:

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

    Show the sample output

    {
        "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"
    }

    The value of the accept-encoding header that is added in substep 4 is printed in the access log. For more information about logs, see Configure Observability Settings and Enable control-plane log collection and log-based alerting in an ASM instance of version 1.17.2.35 or later.

Step 3: View access logs

After you enable access logging and customize the fields of access logs, the sidecar container that initiates a request prints access logs in the custom format.

  1. Enter IP address of the ingress gateway:productpage in the address bar of your browser to access the Productpage application.

  2. Log on to the ACK console. In the left-side navigation pane, click Clusters.

  3. On the Clusters page, click the name of the cluster that you want to manage and choose Workloads > Deployments in the left-side navigation pane.

  4. In the upper part of the Deployments page, select default from the Namespace drop-down list and click Details in the Actions column of the productpage-v1 application.

  5. On the details page of the application, click the Logs tab and set the Container parameter to istio-proxy.

    The following log is displayed in the log output box. The log contains a field that specifies an end user named jason. This indicates that the custom configuration takes effect.日志

Duration fields

In Service Mesh, "upstream" indicates the receiver of a request, and "downstream" indicates the initiator of the request. For example, when service A initiates a request to service B, service A is the downstream service, and service B is the upstream service.

Field

Value

Description

duration

$DURATION%

  • For an HTTP request, this field indicates the span from the time when the sidecar proxy or gateway starts to read the request to the time when the sidecar proxy or gateway sends the last byte of the response to the downstream service. This represents the duration taken by the sidecar proxy or gateway to process the request.

  • For a TCP request, this field indicates the period of time during which the sidecar proxy or gateway is connected to the downstream service.

request_duration

%REQUEST_DURATION%

  • For an HTTP request, this field indicates the time consumed to read the entire request from the downstream service. An entire request contains the request header and the request body. If the value of this field is larger than expected, check the following items:

    • Whether the network quality is good and the bandwidth is sufficient

    • Whether the upstream or downstream service has an I/O bottleneck

  • For a TCP request, this field is unavailable, and the value of this field is a hyphen (-).

request_tx_duration

%REQUEST_TX_DURATION%

  • For an HTTP request, this field indicates the span from the time when the request is initiated to the time when the last byte of the request is sent to the upstream service. If the value of this field is larger than expected, check the following items:

    • Whether the network quality is good and the bandwidth is sufficient

    • Whether the upstream or downstream service has an I/O bottleneck

  • For a TCP request, this field is unavailable, and the value of this field is a hyphen (-).

response_duration

%RESPONSE_DURATION%

  • For an HTTP request, this field indicates the span from the time when the request is initiated to the time when the first byte of the response is read from the upstream service. If the value of this field is larger than expected and the value of request_tx_duration meets the expectation, check whether the upstream service has a performance bottleneck.

  • For a TCP request, this field is unavailable, and the value of this field is a hyphen (-).

response_tx_duration

%RESPONSE_TX_DURATION%

  • For an HTTP request, this field indicates the span from the time when the first byte of the response is read from the upstream service to the time when the last byte of the response is sent to the downstream service. If the value of this field is larger than expected, check the following items:

    • Whether the network quality is good and the bandwidth is sufficient

    • Whether the upstream or downstream service has an I/O bottleneck

  • For a TCP request, this field is unavailable, and the value of this field is a hyphen (-).

upstream_service_time (for a sidecar proxy)

%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%

In the access logs of sidecar proxies or gateways, this field indicates the processing time of the upstream service and the time consumed in communication with the upstream service. If the value of this field is larger than expected, check the following items:

  • Whether the processing performance of the upstream application meets expectations.

  • Whether the network latency and bandwidth for communication with the upstream service meet expectations.

upstream_response_time (for a gateway)

Note

For an HTTP request with a body whose Content-Length is larger than 0, the request is simultaneously read and sent to the upstream service instead of being sent after it is read. In this case, if the current node reads the request slowly from the downstream service, the upstream service of the current node takes more time to read the request.

Related operations

You can also use Simple Log Service to collect access logs on the data plane. For more information, see Configure the features of generating and collecting the access logs of an ASM gateway.