Anthos Service Mesh 1.6 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

Interpreta los registros de Anthos Service Mesh

En las secciones siguientes, se explica cómo verificar el estado de tu malla y revisar los distintos registros que contienen detalles útiles para solucionar problemas.

Interpreta las métricas del plano de control

Cuando se instala Anthos Service Mesh con el perfil asm-gcp, Istio exporta las métricas a la observabilidad de Google Cloud para la supervisión, de forma predeterminada. Istiod aplica el prefijo a estas métricas con istio.io/control y brinda estadísticas sobre el estado del plano de control, como la cantidad de proxies conectados a cada instancia del plano de control, los eventos de configuración, los envíos y las validaciones.

Sigue los pasos a continuación para observar o solucionar problemas del plano de control.

Carga un panel de muestra:

git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples && git checkout asm

Instala el panel de Anthos Service Mesh:

gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

Busca un panel llamado Istio Control Plane Dashboard en la lista. Para obtener más información, consulta Visualiza el panel instalado.

Si no usas el perfil asm-gcp, puedes agregar las variables de entorno a la implementación de Istiod para habilitar las métricas del plano de control:
```
- name: ENABLE_STACKDRIVER_MONITORING
value: "true"
```
Además, puedes agregar esta variable de entorno mediante la opción de instalación, components.pilot.k8s.env.

Para ver la lista completa de métricas disponibles, consulta Métricas exportadas.

Diagnostica demoras en la configuración

En los siguientes pasos, se explica cómo usar la métrica pilot_proxy_convergence_time para diagnosticar una demora entre un cambio de configuración y todos los proxies que convergen.

Ejecuta un comando de shell en un Pod:

kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s

Accede a localhost:15014 y grep para convergence en métricas:
```
curl http://localhost:15014/metrics | grep convergence
```

Interpreta los registros de acceso de observabilidad de Google Cloud

En la siguiente información, se explica cómo usar los registros de acceso de observabilidad de Google Cloud para solucionar problemas de conexión.

Anthos Service Mesh exporta datos a los registros de acceso de observabilidad de Google Cloud que pueden ayudarte a depurar los siguientes tipos de problemas:

Fallas y flujo de tráfico
Enrutamiento de solicitudes de extremo a extremo

Los registros de acceso y tráfico de observabilidad de Google Cloud están habilitados de forma predeterminada en el perfil asm-gcp de toda la malla. Sin embargo, si aún no están habilitados, puedes usar el siguiente comando:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true

Existen dos tipos de registros de acceso:

Los registros de acceso al servidor proporcionan una vista de las solicitudes del servidor. Se encuentran en server-accesslog-stackdriver, adjuntos al recurso supervisado k8s_container. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del servidor:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
Los registros de acceso del cliente proporcionan una vista de las solicitudes del cliente. Se encuentran en client-accesslog-stackdriver, adjuntos al recurso supervisado k8s_pod. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del cliente:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```
.

Solo los registros de errores del cliente están habilitados de forma predeterminada para reducir los costos de registro. Sin embargo, puedes habilitar todos los registros del cliente (correctos y con errores) mediante el siguiente comando:

istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION 

    --set values.telemetry.v2.stackdriver.enabled=true 

    --set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL

Los registros de acceso contienen la siguiente información:

Propiedades de la solicitud HTTP, como el ID, la URL, el tamaño, la latencia y los encabezados comunes
Información de la carga de trabajo de origen y de destino, como el nombre, el espacio de nombres, la identidad y las etiquetas comunes
Información de revisión y del servicio canónico de origen y destino
Información de seguimiento de los registros, como ID de seguimiento, ID de intervalo y muestreo, si está habilitado el seguimiento

La información que se muestra en los registros de acceso de observabilidad de Google Cloud se origina en los registros de acceso de Envoy, cuando los habilitas en la configuración de Istio. Contienen los siguientes encabezados:

route_name
upstream_cluster
X-Envoy-Original-Path
X-Envoy-Original-Host

Este es un ejemplo de una entrada de registro:

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

Puedes usar este registro de varias maneras:

Integra a Cloud Trace, que es una función opcional de Anthos Service Mesh.
Exporta los registros de tráfico a BigQuery, ya que allí puedes ejecutar consultas, como seleccionar todas las solicitudes que toman más de 5 segundos.
Crea métricas basadas en registros.
Soluciona errores 404 y 503

Soluciona errores `404` y `503`

En el siguiente ejemplo, se explica cómo usar este registro para solucionar problemas cuando una solicitud falla con un código de respuesta 404 o 503.

En el registro de acceso del cliente, busca una entrada como la siguiente:

httpRequest: {
requestMethod: "GET"
requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
requestSize: "2088"
status: 404
responseSize: "75"
remoteIp: "10.168.0.26:34165"
serverIp: "10.36.3.149:8080"
latency: "0.000371440s"
protocol: "http"
}

Navega a las etiquetas en la entrada de registro de acceso. Busca el campo response_flag, que tiene el siguiente aspecto:
```
response_flag: "NR"
```
El valor NR es una sigla que significa NoRoute, lo que indica que no se encontró ninguna ruta para el destino o que no había una cadena de filtro que coincida con una conexión descendente. Del mismo modo, también puedes usar la etiqueta response_flag para solucionar los errores 503.
Si ves errores 503 en los registros de acceso del cliente y del servidor, comprueba que los nombres de puertos configurados para cada servicio coincidan con el nombre del protocolo que se usa entre ellos. Por ejemplo, si un cliente del objeto binario de Golang se conecta a un servidor de Golang mediante HTTP, pero el puerto se llama http2, el protocolo no negociará automáticamente de forma adecuada.

Para obtener más información, consulta Marcas de respuesta.

Interpreta los registros de Envoy

En los siguientes pasos, se explica cómo usar los registros de acceso del proxy de Envoy para mostrar el tráfico entre ambos extremos de una conexión a fin de solucionar los problemas.

Los registros de acceso de Envoy son útiles para diagnosticar problemas como los siguientes:

Fallas y flujo de tráfico
Enrutamiento de solicitudes de extremo a extremo

Los registros de acceso no están habilitados de forma predeterminada en Anthos Service Mesh y solo se pueden habilitar a nivel global en toda la malla.

Para solucionar problemas de errores de conexión o solicitud, genera actividad en tu aplicación que active una solicitud HTTP y, luego, inspecciona la solicitud asociada en los registros de origen o de destino.

Si activas una solicitud y aparece en los registros del proxy de origen, indica que el redireccionamiento de tráfico de iptables funciona de forma correcta y que el proxy de Envoy está controlando el tráfico. Si ves errores en los registros, genera un volcado de configuración de Envoy y verifica la configuración del clúster de Envoy para asegurarte de que sea correcta. Si ves la solicitud, pero el registro no tiene errores, verifica los registros del proxy de destino en su lugar.

Si la solicitud aparece en los registros del proxy de destino, indica que la malla funciona correctamente. Si, en cambio, ves un error, ejecuta un volcado de la configuración de Envoy y verifica los valores correctos del puerto de tráfico establecido en la configuración del objeto de escucha.

Si el problema persiste después de seguir los pasos anteriores, puede que Envoy no sea capaz de negociar de forma automática el protocolo entre el archivo adicional y el pod de su aplicación. Asegúrate de que el nombre del puerto del servicio de Kubernetes, por ejemplo, http-80, coincida con el protocolo que usa la aplicación.

Usa el Explorador de registros para consultar registros

Puedes usar la interfaz del explorador de registros para consultar registros de acceso específicos. Por ejemplo, para consultar todas las solicitudes que tienen habilitado MULTUAL_TLS y usan el protocolo grpc, agrega lo siguiente a la consulta de registros de acceso al servidor:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Establece una política de registro de acceso

Puedes establecer una política de registro del proxy que determine qué tipo de información recopilas. Esto es útil para controlar el permiso de tus registros a fin de solucionar problemas. Por ejemplo, el registro captura los errores de forma automática, pero puedes configurar logWindowDuration para también capturar eventos exitosos durante un período específico o establecer la duración del período en cero a fin de registrar todos los accesos. La política se establece a nivel de la malla o del clúster.

Para habilitar una política de registro de acceso, usa el siguiente comando:

istioctl install --set profile=PROFILE_NAME \
    --set values.telemetry.v2.stackdriver.enabled=true \
    --set values.telemetry.v2.stackdriver.logging=true \
    --set values.telemetry.accessLogPolicy.enabled=true

Para obtener más información sobre las opciones de configuración del registro de acceso, como logWindowDuration, consulta AccessLogPolicy Config.

Obtén información específica del servicio o de la carga de trabajo

Si tienes un problema con un servicio o carga de trabajo en específico, en lugar de un problema en toda la malla, inspecciona los proxies de Envoy individuales y recopila información relevante sobre ellos. Para recopilar información sobre una carga de trabajo en particular y sus proxies, puedes usar pilot-agent:

kubectl exec POD_NAME -c istio-proxy -- pilot-agent request GET SCOPE

En el ejemplo, SCOPE es uno de los siguientes:

certs: Certificados dentro de la instancia de Envoy
clusters: Clústeres con Envoy configurado
config_dump: Vuelca la configuración de Envoy
listeners: Objetos de escucha con Envoy configurado
logging: Visualiza y cambia la configuración del registro de cambios
stats: Estadísticas de Envoy
stats/prometheus: Estadísticas de Envoy como registros de Prometheus

Visualiza los estados de los sockets del proxy

Puedes examinar directamente el estado de los sockets del proxy de Envoy mediante el siguiente proceso.

Muestra una lista de sockets establecidos, incluidos sockets en el estado TIME_WAIT, que pueden afectar la escalabilidad de forma negativa si su recuento es alto:
```
kubectl exec POD_NAME -c istio-proxy -- ss -anopim
```
Muestra un resumen de las estadísticas de los sockets:
```
kubectl exec POD_NAME -c istio-proxy -- ss -s
```

Para obtener más información, consulta Introducción al comando ss.

Registros `istio-proxy` y `istio-init`

Además, recupera los registros istio-proxy y revisa el contenido para detectar si hay errores que podrían sugerir la causa del problema:

kubectl logs POD_NAME -c istio-proxy

Puedes hacer lo mismo para el contenedor init:

kubectl logs POD_NAME -c istio-init