Alibaba Cloud Service Mesh (ASM) allows you to customize log headers for the ingress gateway service based on your business requirements. This topic describes how to use Envoy filters to customize log headers for the ingress gateway service of an ASM instance.

Create an Envoy filter

In the following example, the user ID of the request is added to the logs of the ingress gateway service of an ASM instance as a header.

Create an Envoy filter by using the following content. For more information, see Manage Envoy filters.
Note If the version of your ASM instance is 1.8 or higher, we recommend that you use Envoy v3 API in the typed_config parameter of the Envoy filter.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: gateway-accesslog-userdefine
  namespace: istio-system
spec:
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: ANY
        listener:
          filterChain:
            filter:
              name: envoy.http_connection_manager
      patch:
        operation: MERGE
        value:
          typed_config:
            '@type': >-
              type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
            access_log:
              - name: envoy.access_loggers.file
                typed_config:
                  '@type': >-
                    type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                  log_format:
                    json_format:
                      authority: '%REQ(:AUTHORITY)%'
                      bytes_received: '%BYTES_RECEIVED%'
                      bytes_sent: '%BYTES_SENT%'
                      downstream_local_address: '%DOWNSTREAM_LOCAL_ADDRESS%'
                      downstream_remote_address: '%DOWNSTREAM_REMOTE_ADDRESS%'
                      duration: '%DURATION%'
                      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%'
                      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)%'
                      user_id: '%REQ(USER_ID)%'
                      x_forwarded_for: '%REQ(X-FORWARDED-FOR)%'
                  path: /dev/stdout
  workloadSelector:
    labels:
      app: istio-ingressgateway
Set the access_log format parameter in access.log based on your business requirements. <input tabindex="-1" class="dnt" readonly="readonly" value="Do Not Translate">
Note If you do not set the log_format parameter, the default log format of Envoy is used.
  • namespace: the namespace where the Envoy filter takes effect.
  • workloadSelector: the ingress gateway for which the Envoy filter takes effect. Specify your ingress gateway in the format of app: istio-{Ingress gateway name}. In this example, the ingress gateway named ingressgateway is used.
You can also specify a custom log header in the following format in the Envoy filter:
my_custom_header:'%REQ(MY_CUSTOM_HEADER)%'
After you add a custom log header, the logs of the ingress gateway contain the following content:
{"protocol": "HTTP/1.1", "duration": "123", "my_custom_header": "value_of_MY_CUSTOM_HEADER"}

Verify whether the header configuration of the Envoy filter takes effect

  1. Connect to a serverless Kubernetes cluster by using kubectl. For more information, see Step 2: Select a type of cluster credentials.
  2. Run the following command to check whether the user_id header is added to logs:
    kubectl  exec $gateway_pod -n istio-system -- curl localhost:15000/config_dump |grep -5 user_id
    user

    The return result indicates that the user_id header is added to the log_format parameter in access.log.

  3. Run the following command to send a request to the ingress gateway. In this example, the user ID of the request is 8888.
    curl -H 'user_id: 8888'  <Gateway IP> /some_path
  4. Run the following command to view the logs of the ingress gateway:
    kubectl -n istio-system  logs -f <name of the ingress gateway pod>  --tail=10
    Logs

    The return result indicates that the user_id header is contained in the logs of the ingress gateway.

Version requirements

If the version of your ASM instance is earlier than 1.8, we recommend that you use Envoy v2 API in the typed_config parameter of your Envoy filter. The following code provides an example of an Envoy filter:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: enable-accesslog
  namespace: gateway-accesslog-userdefine
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.http_connection_manager
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager"
          access_log:
          - name: envoy.file_access_log
            config:
              path: /dev/stdout
              log_format:
                 ....
  workloadSelector:
    labels:
      app: istio-ingressgateway