Solicitar registros de proxy

Las páginas de Cloud Service Mesh proporcionan enlaces a dos tipos de registros diferentes en Cloud Logging: registros de acceso (también conocidos como registros de Envoy) y registros de tráfico (también conocidos como registros de acceso de Observabilidad de Google Cloud).

Registros de acceso

Habilitar registros de acceso

Los pasos necesarios para habilitar los registros de acceso dependen del tipo de Cloud Service Mesh, ya sea gestionado o en el clúster:

gestionados

Sigue las instrucciones para habilitar los registros de acceso en Cloud Service Mesh gestionado.

En el clúster

Sigue las instrucciones para habilitar los registros de acceso en Cloud Service Mesh en clústeres.

Ver registros de acceso

Para ver los registros de acceso en el Explorador de registros, sigue estos pasos:

  1. Ve al explorador de registros:

    Ir al Explorador de registros

  2. Selecciona el Google Cloud proyecto adecuado.

  3. Ejecuta la siguiente consulta:

    resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

Registros de tráfico

Habilitar registros de tráfico

Los registros de tráfico están habilitados de forma predeterminada, a menos que Cloud Service Mesh esté instalado en Google Distributed Cloud con Istio CA (anteriormente conocido como Citadel).

Para habilitar los registros de tráfico en Google Distributed Cloud con Istio CA cuando instales Cloud Service Mesh en el clúster, usa la marca --option stackdriver. También puedes habilitar los registros de tráfico en Google Distributed Cloud con Istio CA después de instalar Cloud Service Mesh en el clúster.

Ver registros de tráfico

Ver registros de tráfico en el explorador de registros

Para ver los registros de tráfico en el Explorador de registros, sigue estos pasos:

  1. Ve al explorador de registros:

    Ir al Explorador de registros

  2. Selecciona el Google Cloud proyecto adecuado.

  3. Ejecuta la siguiente consulta en función de si estás viendo los registros de acceso del cliente o del servidor:

    Registros de servidor

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

    Registros de clientes

    resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

Ver los registros de tráfico en la página de Anthos Service Mesh

Para ver los registros de tráfico de un servicio en la página de Cloud Service Mesh durante un periodo específico, sigue estos pasos:

  1. En la consola, ve a la página Cloud Service Mesh. Google Cloud

    Ir a la página Cloud Service Mesh

  2. En Servicios, selecciona el nombre del servicio que quieras inspeccionar.

  3. Ve a la página Métricas.

  4. Especifica un periodo en el menú desplegable Periodo o define un periodo personalizado en la cronología.

  5. Haz clic en Ver registros de tráfico.

El registro de tráfico se llama server-accesslog-stackdriver y se adjunta al recurso monitorizado correspondiente (k8s_container o gce_instance) que utiliza tu servicio. El registro de tráfico contiene la siguiente información:

  • Propiedades de las solicitudes 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.

  • Si la monitorización está habilitada, se incluye información de la traza, como el muestreo, el ID de la traza y el ID del intervalo.

Una entrada de registro de ejemplo tiene el siguiente aspecto:

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

Interpretar la telemetría de Anthos Service Mesh

En las siguientes secciones se explica cómo comprobar el estado de tu malla y consultar las distintas telemetrías que contienen detalles útiles para ayudarte a solucionar problemas.

Interpretar las métricas del plano de control

Cuando se instala Cloud Service Mesh con el plano de control en el clúster, istiod exporta métricas a Google Cloud Observability para la monitorización de forma predeterminada. istiod prefija estas métricas con istio.io/control y proporciona información valiosa sobre el estado del plano de control, como el número de proxies conectados a cada instancia del plano de control, los eventos de configuración, los envíos y las validaciones.

Observa o soluciona problemas del plano de control siguiendo estos pasos.

  1. Carga un panel de control de ejemplo:

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

  2. Instala el panel de control de Cloud Service Mesh:

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

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

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

Diagnosticar retrasos en la configuración

En los pasos siguientes se explica cómo usar la métrica pilot_proxy_convergence_time para diagnosticar un retraso entre un cambio de configuración y la convergencia de todos los proxies.

  1. 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

  2. Acceso a localhost:15014 y grep para convergence en las métricas:

    curl http://localhost:15014/metrics | grep convergence

Interpretar los registros de acceso de Google Cloud Observability

En la siguiente información se explica cómo usar los registros de acceso de Google Cloud Observability para solucionar problemas de conexión. Los registros de acceso o tráfico de Google Cloud Observability están habilitados de forma predeterminada.

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

  • Flujo de tráfico y errores
  • Enrutamiento de solicitudes de extremo a extremo

Los registros de acceso de Google Cloud Observability están habilitados de forma predeterminada en las instalaciones de Cloud Service Mesh en Google Kubernetes Engine. Puedes habilitar los registros de acceso de Google Cloud Observability volviendo a ejecutar asmcli install. Usa las mismas opciones que instalaste originalmente, pero omite la superposición personalizada que inhabilitó Stackdriver.

Hay dos tipos de registros de acceso:

  • Los registros de acceso al servidor ofrecen una vista de las solicitudes del lado del servidor. Se encuentran en server-accesslog-stackdriver, adjuntos al recurso k8s_container monitorizado. Utilice la siguiente sintaxis de URL para mostrar los registros de acceso del lado 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 de clientes ofrecen una vista de las solicitudes del lado del cliente. Se encuentran en client-accesslog-stackdriver, adjuntos al recurso monitorizado k8s_pod. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del lado del cliente:

    https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID

Los registros de acceso contienen la siguiente información:

  • Propiedades de las solicitudes 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 canónica del servicio y la revisión de origen y destino.
  • Si el rastreo está habilitado, los registros contienen información de rastreo, como el muestreo, el ID de rastreo y el ID de intervalo.

La información que se muestra en los registros de acceso de Google Cloud Observability procede de los registros de acceso de Envoy, que se habilitan 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 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 formas:

  • Integración con Cloud Trace, una función opcional de Cloud Service Mesh.
  • Exporta los registros de tráfico a BigQuery, donde puedes ejecutar consultas como seleccionar todas las solicitudes que tardan más de 5 segundos.
  • Crea métricas basadas en registros.
  • Solucionar errores 404 y 503

Solucionar 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.

  1. 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"
}

  2. Desplázate hasta las etiquetas de la entrada del registro de acceso. Busca el campo response_flag que tenga este aspecto:

    response_flag: "NR"

    El valor NR es un acrónimo de NoRoute, que significa que no se ha encontrado ninguna ruta para el destino o que no había ninguna cadena de filtros coincidente para una conexión de nivel inferior. Del mismo modo, puede usar la etiqueta response_flag para solucionar problemas de 503.

  3. Si ves errores 503 en los registros de acceso del cliente y del servidor, comprueba que los nombres de los puertos definidos para cada servicio coincidan con el nombre del protocolo que se usa entre ellos. Por ejemplo, si un cliente binario de Go se conecta a un servidor de Go mediante HTTP, pero el puerto se llama http2, el protocolo no se negociará automáticamente correctamente.

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

Interpretar los registros de acceso

En los siguientes pasos se explica cómo usar los registros de acceso (también conocidos como registros de proxy de Envoy) para mostrar el tráfico entre los dos extremos de una conexión con fines de solución de problemas.

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

  • Flujo de tráfico y errores
  • Enrutamiento de solicitudes de extremo a extremo

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

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

Si se activa una solicitud y aparece en los registros del proxy de origen, significa que la redirección del tráfico de iptables funciona correctamente y que el proxy de Envoy gestiona el tráfico. Si ve errores en los registros, genere un volcado de configuración de Envoy y compruebe la configuración del clúster de Envoy para asegurarse de que es correcta. Si ves la solicitud, pero el registro no tiene errores, consulta los registros del proxy de destino.

Si la solicitud aparece en los registros del proxy de destino, significa que la malla funciona correctamente. Si aparece un error, ejecuta un volcado de configuración de Envoy y verifica los valores correctos del puerto de tráfico definido en la configuración del listener.

Si el problema persiste después de seguir los pasos anteriores, es posible que Envoy no pueda negociar automáticamente el protocolo entre el sidecar y su pod de 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.

Usar 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 MULTUAL_TLS habilitado y usan el protocolo grpc, añade lo siguiente a la consulta de los registros de acceso al servidor:

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

Definir una política de registro de acceso

Para configurar el registro de proxy en Cloud Service Mesh gestionado, consulta Registros de acceso de Envoy.

Para definir una política de registro de acceso para Cloud Service Mesh con el plano de control en el clúster, sigue estos pasos:

  1. Cree un archivo de superposición personalizada IstioOperator que incluya los valores AccessLogPolicyConfig aplicables a su caso.

  2. Pasa este archivo a asmcli con la opción --custom_overlay para actualizar la configuración del plano de control del clúster. Para obtener información sobre cómo ejecutar asmcli install con un archivo de superposición personalizado, consulta el artículo sobre cómo instalar con funciones opcionales.

Ver información específica de un servicio o una carga de trabajo

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

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

En el ejemplo, SCOPE es uno de los siguientes:

  • certs: certificados de la instancia de Envoy
  • clusters: clústeres con Envoy configurado
  • config_dump: muestra la configuración de Envoy.
  • listeners: listeners con Envoy configurado
  • logging: ver y cambiar los ajustes de registro
  • stats: estadísticas de Envoy
  • stats/prometheus: estadísticas de Envoy como registros de Prometheus

Ver estados de sockets proxy

Puedes examinar directamente el estado de los sockets proxy de Envoy siguiendo este proceso.

  1. Muestra una lista de los sockets establecidos, incluidos los sockets en el estado TIME_WAIT, que pueden afectar negativamente a la escalabilidad si su número es elevado:

    kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -anopim

  2. Muestra un resumen de las estadísticas de los sockets:

    kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -s

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

Registros de istio-proxy y istio-init

Además, obtenga los registros de istio-proxy y revise su contenido para detectar errores que puedan indicar la causa del problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Puedes hacer lo mismo con el contenedor init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Siguientes pasos