Estás viendo la documentación de Service Mesh v1.22.

Versiones disponibles

Cloud Service Mesh
Archivo 1.22
Archivo 1.21
Archivo 1.20
Archivo 1.19
Archivo 1.18

Se usó la API de Cloud Translation para traducir esta página.

Resuelve problemas de observabilidad y telemetría en Cloud Service Mesh

En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.

En la telemetría de la malla de servicios de Cloud, los proxies de Envoy llaman al Las APIs de Google Cloud Observability de forma periódica para informar datos de telemetría El tipo de llamada a la API determina su frecuencia:

Registro: cada 10 segundos aproximadamente
Métricas: cada 1 minuto aproximadamente
Perímetros (vista de topología/API de contexto): Informes incrementales cada aproximadamente 1 minuto con informes completos cada 10 minutos aproximadamente
Seguimientos: Se determinan según la frecuencia de muestreo que configures (por lo general, una de cada 100 solicitudes).

Los paneles de telemetría recopilan datos de Confluence y de la Observabilidad de Google Cloud para mostrar los distintos paneles centrados en servicios.

Verifica que haya, como máximo, una configuración de la API de telemetría de Istio

Esta sección solo se aplica al plano de control administrado de la malla de servicios de Cloud.

Para mostrar una lista de las configuraciones de la API de telemetría, ejecuta el siguiente comando. Verifica lo siguiente: hay, como máximo, una configuración de la API de telemetría de Istio.

kubectl -n istio-system get telemetry

Falta un servicio en el panel de servicios

El panel solo muestra servicios HTTP(S)/gRPC. Si tu servicio debería estar en por la lista, verifica que la telemetría de Cloud Service Mesh la identifique como un servicio.

Si el servicio sigue sin estar disponible, verifica que haya un Configuración del servicio de Kubernetes existe en tu clúster.

Revisa la lista de todos los servicios de Kubernetes:
```
kubectl get services --all-namespaces
```
Revisa la lista de servicios de Kubernetes en un espacio de nombres específico:
```
kubectl get services -n YOUR_NAMESPACE
```

Faltan métricas en los servicios o estas son incorrectas

Si faltan métricas o son incorrectas para los servicios en el panel Servicios, consulta las siguientes secciones a fin de conocer las posibles soluciones.

Verifica que los proxies de sidecar existan y se hayan insertado correctamente

El espacio de nombres quizás no tenga una etiqueta para la inserción automática, o la inyección manual haya fallado. Confirma que los Pods en el espacio de nombres tengan al menos dos contenedores y que uno de esos contenedores es el proxy istio-proxy container:

kubectl -n YOUR_NAMESPACE get pods

Verifica que la configuración de telemetría exista

Para confirmar que el filtro de Google Cloud Observability está configurado, recopilar un volcado de configuración de cada proxy y buscar la presencia de la Filtro de observabilidad de Google Cloud:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

En el resultado del comando anterior, busca el filtro de observabilidad de Google Cloud, que tiene el siguiente aspecto:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Verifica que Cloud Service Mesh identifique un servicio HTTP

Las métricas no se mostrarán en la interfaz de usuario si el puerto de servicio del El servicio de Kubernetes no se llama http ni ningún nombre con el prefijo http-. Confirma que el servicio tenga los nombres propios para sus puertos.

Verifica que la API de Cloud Monitoring esté habilitada para el proyecto

Confirma que la API de Cloud Monitoring esté habilitada en el panel de API y servicios en la consola de Google Cloud, que es la configuración predeterminada.

Verifica que no haya informes de errores en la API de Cloud Monitoring

En la API de la consola de Google Cloud y Panel de servicios, abre la URL del gráfico de tráfico por código de respuesta:

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

Si ves mensajes de error, es posible que sea un problema que requiera una mayor investigación. En particular, busca una gran cantidad de mensajes de error 429, que indican un posible problema de cuota. Consulta la siguiente sección a fin de conocer los pasos para la solución de problemas.

Verifica la cuota correcta para la API de Cloud Monitoring

En la consola de Google Cloud, abre el menú IAM & Admin y verifica que haya un Cuotas de 12 a 1 con la nueva opción de compresión. Puedes acceder a esta página directamente mediante la siguiente URL:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

En esta página, se muestra el conjunto completo de cuotas para el proyecto, en el que puedes buscar Cloud Monitoring API.

Verifica que no haya registros de errores en los proxies de Envoy

Revisa los registros del proxy en cuestión y busca las instancias de mensajes de error:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Sin embargo, ignora los mensajes de advertencia como los siguientes, que son normales:

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

Verifica que `metric.mesh_uid` esté configurado correctamente.

Abre el Explorador de métricas y ejecuta la siguiente consulta de MQL:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

Verifica que todos los servicios esperados sean métricas de informes y que su metric.mesh_uid esté en el formato proj-<Cloud Service Mesh fleet project number>.

Si metric.mesh_uid tiene cualquier otro valor, el panel de Cloud Service Mesh no mostrará métricas. metric.mesh_uid se configura cuando Cloud Service Mesh es instalada en el clúster, así que investiga tu método de instalación para ver si hay una manera de establecerlo en el valor esperado.

Faltan datos de telemetría de los servicios o los datos son incorrectos

De forma predeterminada, Cloud Monitoring y Cloud Logging están habilitados en tu proyecto de Google Cloud cuando instalas Cloud Service Mesh. Para informar datos de telemetría, cada proxy de sidecar que se incorpora en tus pods de servicio llama a la API de Cloud Monitoring y a la API de Cloud Logging. Después de implementar las cargas de trabajo, se necesitan alrededor de uno o dos minutos para que los datos de telemetría se muestren en la consola de Google Cloud. Cloud Service Mesh mantiene automáticamente los paneles de servicio actualizado:

Para las métricas, los proxies de sidecar llaman a la API de Cloud Monitoring cada alrededor de un minuto.
Para actualizar el gráfico de topología, los proxies de sidecar envían informes incrementales cada alrededor de un minuto e informes completos cada diez minutos.
Para el registro, los proxies de sidecar llaman a la API de Cloud Logging cada alrededor de diez segundos.
Para el seguimiento, debes habilitar Cloud Trace. Los seguimientos se informan según la frecuencia de muestreo configurada (en general, en una de cada 100 solicitudes).

Las métricas solo se muestran para los servicios HTTP en la malla de servicios de Cloud. página Métricas. Si no ves ninguna métrica, verifica que todos los Pods del espacio de nombres para los servicios de tu aplicación tienen proxies de sidecar insertados:

kubectl get pod -n YOUR_NAMESPACE --all

En el resultado, observa que la columna READY muestra dos contenedores para cada una de tus cargas de trabajo: el contenedor principal y el contenedor del proxy de sidecar.

Además, el panel de Servicios solo muestra las métricas del servidor, Es posible que los datos no aparezcan si el cliente no está en la malla o si está configurado para informar solo las métricas del cliente (como puertas de enlace de entrada).