Alibaba Cloud Service Mesh:ASM observability settings

Salida del registro de acceso

1. En la sección Log Settings, active o desactive el interruptor Enable Log Output según sus necesidades.

   • Si habilita esta opción, los sidecars o gateways del plano de datos envían los registros de acceso a la salida estándar (stdout) del contenedor.

   • Si deshabilita esta opción, los sidecars o gateways del plano de datos dejan de enviar registros al stdout del contenedor.

2. Consulte los registros en el stdout del contenedor sidecar del plano de datos.

   A continuación se muestra cómo consultar los registros de acceso mediante kubectl.

   1. Ejecute el siguiente comando para consultar los registros del sidecar:

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

      Ejemplo de salida

      {
          "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. Ejecute el siguiente comando para consultar los registros del gateway de entrada:

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

      Ejemplo de salida

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

3. (Opcional) Consulte los registros de acceso en la consola de Container Service for Kubernetes.

   Si utiliza un clúster de Alibaba Cloud Container Service for Kubernetes (ACK), también puede consultar los registros de acceso en la consola de ACK.

   1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

   2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Workloads > Pods.

   3. En la página Pods, haga clic en el nombre del pod de destino y, a continuación, haga clic en la pestaña Logs en la parte inferior de la página para consultar los registros de acceso.

Formato de salida de los registros

En la sección Log Settings, establezca Log Output Format en JSON o TEXT según sus necesidades.

• Si selecciona JSON, los registros de acceso se envían al stdout del contenedor como cadenas JSON.

• Si selecciona TEXT, los registros de acceso se envían al stdout del contenedor como cadenas de texto sin formato.

Formato de registro personalizado

1. En la sección Log Settings, seleccione campos, modifique la información de los campos personalizados o haga clic en el icono en la parte inferior de la lista de campos de registro para agregar un nuevo campo.

   El formato de registro solo se puede personalizar cuando el interruptor Enable Log Output está activado. En la sección Log Format, los campos de registro seleccionados de forma predeterminada son obligatorios y no se pueden deseleccionar. Los valores de los campos de registro se pueden obtener de los encabezados de solicitud, de los encabezados de respuesta o de los valores integrados de Envoy.

   Por ejemplo, para registrar el encabezado de solicitud accept-encoding, establezca accessLogFormat key en accept-encoding, Type en Request Properties y accessLogFormat value en Accept-Encoding. La plantilla de formato para un encabezado de solicitud es %REQ(HEADER_NAME)% (por ejemplo, %REQ(:AUTHORITY)%), para un encabezado de respuesta es %RESP(HEADER_NAME)% (por ejemplo, %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%) y para un atributo integrado de Envoy es %ATTRIBUTE_NAME% (por ejemplo, %REQUEST_DURATION%).

2. Ejecute el siguiente comando para consultar los registros de los componentes del plano de datos en la service mesh.

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

   Ejemplo de salida

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

   Ahora el registro de acceso muestra el valor del encabezado Accept-Encoding que agregó en step 1.

Filtrado de registros

En la sección Log Settings, seleccione Enable Log Filter para activar el filtrado de registros y, a continuación, introduzca una expresión de filtrado en el cuadro de texto. Los registros de acceso solo se generan para las solicitudes que coinciden con la expresión.

Por ejemplo, para registrar únicamente las solicitudes que cumplen la condición Response Http Status >= 400, utilice la expresión response.code >= 400. Para obtener más información, consulte CEL expressions and common fields.

Generación de métricas

Las métricas se clasifican en métricas del lado del cliente y métricas del lado del servidor.

• Métricas del lado del cliente: métricas generadas cuando un sidecar actúa como cliente para iniciar solicitudes. Las métricas de gateway también se clasifican como métricas del lado del cliente.

• Métricas del lado del servidor: métricas generadas cuando un sidecar actúa como servidor para recibir solicitudes.

1. En la sección Metric Settings, dentro de la columna Client-Side Metrics o Server-Side Metrics, seleccione o desmarque la casilla Enabled de una métrica según sus necesidades.

   • Si una métrica está habilitada, el sidecar o gateway del plano de datos expone dicha métrica a través de la ruta /stats/prometheus en el puerto 15020.

   • Si una métrica está deshabilitada, no se expone en el puerto ni en la ruta especificados.

2. Ejecute el siguiente comando para consultar las métricas que expone un sidecar o gateway.

   Con kubectl puede ejecutar un comando curl dentro del contenedor del sidecar o gateway para acceder a la ruta /stats/prometheus en el puerto local 15020 y consultar las métricas exportadas.

   kubectl exec httpbin-5c5944c58c-w**** -c istio-proxy -- curl 127.0.0.1:15020/stats/prometheus|head -n 10

   Ejemplo de salida:

   # TYPE istio_agent_cert_expiry_seconds gauge
   istio_agent_cert_expiry_seconds{resource_name="default"} 46725.287654548
   # HELP istio_agent_endpoint_no_pod Endpoints without an associated pod.
   # TYPE istio_agent_endpoint_no_pod gauge
   istio_agent_endpoint_no_pod 0
   # HELP istio_agent_go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
   # TYPE istio_agent_go_gc_duration_seconds summary
   istio_agent_go_gc_duration_seconds{quantile="0"} 5.0149e-05
   istio_agent_go_gc_duration_seconds{quantile="0.25"} 9.8807e-05
   ......

Dimensiones de métricas

Las dimensiones de métricas proporcionan información contextual detallada. Estas dimensiones permiten filtrar las métricas de destino en Prometheus. Por ejemplo, la dimensión source_app sirve para filtrar las métricas de las solicitudes provenientes de una aplicación cliente específica.

kubectl exec httpbin-5c5944c58c-w**** -c istio-proxy -- curl 127.0.0.1:15020/stats/prometheus

istio_request_bytes_sum{reporter="destination",source_workload="istio-ingressgateway",source_canonical_service="unknown",source_canonical_revision="latest",source_workload_namespace="istio-system",source_principal="spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway",source_app="istio-ingressgateway",source_version="unknown",source_cluster="c479fc4abd2734bfaaa54e9e36fb26c01",destination_workload="httpbin",destination_workload_namespace="default",destination_principal="spiffe://cluster.local/ns/default/sa/httpbin",destination_app="httpbin",destination_version="v1",destination_service="httpbin.default.svc.cluster.local",destination_canonical_service="httpbin",destination_canonical_revision="v1",destination_service_name="httpbin",destination_service_namespace="default",destination_cluster="c479fc4abd2734bfaaa54e9e36fb26c01",request_protocol="http",response_code="200",grpc_response_status="",response_flags="-",connection_security_policy="mutual_tls"} 18000

istio_request_bytes_sum{response_code="200"} 16550

istio_request_bytes_sum{response_code="200",request_path="/spec.json"} 5800

Porcentaje de muestreo

Es posible personalizar el porcentaje de muestreo de la trazabilidad, el cual determina el porcentaje de solicitudes para las que se generan trazas. Un valor de 0 deshabilita la trazabilidad.

Etiquetas personalizadas

Las etiquetas adjuntas a los spans de trazabilidad reportados se pueden personalizar. En la sección Tracing Analysis Settings, haga clic en Add Custom Tags y, a continuación, configure Name, Type y Value.

Los tipos válidos incluyen Fixed Value, Request Header y Environment Variable. En la siguiente tabla se describe cada tipo y se proporcionan ejemplos.