En esta sección, se explican los problemas comunes de Anthos Service Mesh y cómo solucionarlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
En la telemetría de Anthos Service Mesh, los proxies de Envoy llaman a las APIs de observabilidad de Google Cloud de forma periódica para informar los 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: determinados por la frecuencia de muestreo que configuras (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 el servicio.
Falta un servicio en el panel de servicios
El panel solo muestra servicios HTTP(S)/gRPC. Si tu servicio debería estar en la lista, verifica que la telemetría de Anthos Service Mesh lo identifique como un servicio HTTP.
Si tu servicio sigue sin aparecer, verifica que exista una configuración del servicio de Kubernetes 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 ellos sea el contenedor istio-proxy:
kubectl -n YOUR_NAMESPACE get pods
Verifica que la configuración de telemetría exista
Usa EnvoyFilters en el espacio de nombres istio-system para configurar la telemetría.
Sin esa configuración, Anthos Service Mesh no informará datos a la observabilidad de Google Cloud.
Verifica que exista la configuración de observabilidad de Google Cloud (y la configuración del intercambio de metadatos):
kubectl -n istio-system get envoyfilter
El resultado esperado es similar al siguiente:
NAME AGE metadata-exchange-1.4 13d metadata-exchange-1.5 13d stackdriver-filter-1.4 13d stackdriver-filter-1.5 13d ...
Para confirmar que el filtro de observabilidad de Google Cloud esté configurado correctamente, recopila un volcado de configuración de cada proxy y busca la presencia del filtro de observabilidad de Google Cloud:
kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump
En el resultado del comando anterior, busca el filtro de observabilidad de Google Cloud, que se ve de la siguiente manera:
"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 Anthos Service Mesh identifique un servicio HTTP
Las métricas no aparecerán en la interfaz de usuario si el puerto de servicio para el servicio de Kubernetes no tiene un nombre con un prefijo http. Confirma que el servicio tenga los nombres adecuados 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 el panel de API y servicios de la consola de Google Cloud, 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 una opción de Cuotas. 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
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 Anthos 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. Anthos Service Mesh mantiene los paneles del servicio actualizados de forma automática:
- 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 se muestran solo para los servicios HTTP en la página Métricas de Anthos Service Mesh. Si no ves ninguna métrica, verifica que todos los Pods en el espacio de nombres de los servicios de tu aplicación tengan 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, en el panel Servicios solo se muestran métricas del cliente, por lo que es posible que los datos de telemetría no aparezcan si el cliente no está en la malla.