All Products
Search
Document Center

Microservices Engine:Enable log shipping for a cloud-native gateway

Last Updated:Dec 28, 2023

The log shipping feature is implemented by using cloud-native gateways and Alibaba Cloud Simple Log Service. After log shipping is enabled for a cloud-native gateway, you can analyze the access logs of the cloud-native gateway to understand the behavior and geographical locations of client users for troubleshooting. This topic describes how to enable the log shipping feature for a cloud-native gateway of Microservices Engine (MSE).

Prerequisites

Note

If you use the log shipping feature in MSE, no log shipping fees are generated in the MSE console. Instead, you are charged the fees in Simple Log Service based on the amount of resources that you used. For more information about billing of Simple Log Service, see Pay-by-feature.

Enable log shipping

  1. Log on to the MSE console. In the top navigation bar, select a region.

  2. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.

  3. In the left-side navigation pane, click Parameter Settings. In the Observability Parameters section, click 2 next to Log Shipping. In the Log Shipping Settings dialog box, turn on Enable Log Shipping (Ship Gateway Access Logs to Log Service).

    日志投递.png

    Note

    After log shipping is enabled, click the link on the right side of Project in the Observability Parameters section. You are redirected to the Logstore that corresponds to the gateway. For more information, see Query and analyze logs.

Fields

The following table describes the fields that are related to log shipping.

Field name

Data type

Description

__time__

long

The time when the log entry was generated.

cluster_id

string

The ID of the gateway that you purchased.

authority

string

The Host header in the request.

bytes_received

long

The size of the request body. The size of the request header is not included.

bytes_sent

long

The size of the response body. The size of the response header is not included.

downstream_local_address

string

The address of the gateway pod.

downstream_remote_address

string

The address of the client that is connected to the gateway.

duration

long

The amount of time that is consumed to process the request. Unit: milliseconds.

method

string

The HTTP method.

path

string

The requested path.

protocol

string

The HTTP protocol version.

request_id

string

The ID of the request. The gateway generates an ID for each request and adds the ID to the x-request-id header field. Backend servers can parse the ID from the header field and use the ID for troubleshooting.

requested_server_name

string

The server name that is used to establish a Secure Sockets Layer (SSL) connection.

response_code

long

The returned HTTP status code.

response_flags

string

The reason for the failure of the request.

route_name

string

The name of the route.

start_time

string

The start time of the request. Specify this parameter in the Universal Time Coordinated (UTC) format.

trace_id

string

The trace ID.

upstream_cluster

string

The name of the cluster where the upstream service resides.

upstream_host

string

The IP address of the upstream service.

upstream_local_address

string

The address that is used to connect to the upstream service.

upstream_service_time

long

The amount of time (in milliseconds) that is taken for the gateway to access the network of the upstream service and for the upstream service to process requests.

upstream_transport_failure_reason

string

The reason for the failure of the connection request to the upstream service.

user_agent

string

The User-Agent HTTP request header.

x_forwarded_for

string

The x-forwarded-for field in the HTTP request header. In most cases, this field specifies real IP addresses of the HTTP client.

Causes of request failures

The cause of a request failure is identified by Response_Flag in the log. This section describes the values of Response_Flag.

Note

The downstream service refers to the client, and the upstream service refers to the backend service.

  • UH: No healthy upstream host is available in the cluster where the upstream service resides.

  • UF: The connection to the upstream service fails.

  • NR: No route is configured for the given request.

  • URX: The request is rejected because the retry condition for upstream HTTP requests is not met or the maximum number of TCP connection attempts is reached.

  • NC: The cluster where the upstream service resides cannot be found.

  • DT: The request or connection duration exceeds the duration specified by max_connection_duration or max_downstream_connection_duration.

  • DC: The connection to the downstream service is terminated.

  • LH: The local service does not pass the health check.

  • UT: The request of the upstream service times out.

  • LR: The connection is locally reset.

  • UR: The upstream service is remotely reset.

  • UC: The connection to the upstream service is terminated.

  • DI: Request processing is delayed. The delay period is specified in the fault injection rule.

  • FI: The request is terminated due to the status code specified in the fault injection rule.

  • RL: The request is locally limited by the HTTP rate limiting filter, except for the 429 status code.

  • UAEX: The request is rejected by the external authorization service.

  • RLSE: The request is rejected because of an error in the rate limiting service.

  • IH: The request is rejected because an invalid value is included in a strictly checked header.

  • SI: Idle timeout occurs on a stream.

  • DPE: An HTTP protocol error is reported for the downstream service request.

  • UPE: An HTTP protocol error is reported for the upstream service response.

  • UMSDR: The processing duration of the upstream service request exceeds the maximum processing duration.

  • OM: The request is terminated by the overloaded manager.

  • DF: The request is terminated due to a DNS resolution failure.