Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

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

En esta sección se explican los problemas habituales de Cloud Service Mesh y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.

En la telemetría de Cloud Service Mesh, los proxies de Envoy llaman periódicamente a las APIs de observabilidad de Google Cloud para enviar datos de telemetría. El tipo de llamada a la API determina su frecuencia:

Registro: cada 10 segundos aproximadamente
Métricas: cada minuto aproximadamente
Bordes (API Context/vista de topología): informes incrementales cada minuto aproximadamente e informes completos cada 10 minutos aproximadamente.
Traces: se determina en función de la frecuencia de muestreo que configure (normalmente, una de cada 100 solicitudes).

Los paneles de control de telemetría recogen datos de Confluence y de Google Cloud Observability para mostrar los distintos paneles de control centrados en los 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 gestionado de Cloud Service Mesh.

Para enumerar las configuraciones de la API Telemetry, ejecuta el siguiente comando. Verifica que haya 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 control de servicios

El panel de control solo muestra servicios HTTP(S) o gRPC. Si tu servicio debería estar en la lista, comprueba que la telemetría de Cloud Service Mesh lo identifica como un servicio HTTP.

Si el servicio sigue sin aparecer, comprueba que haya una configuración de 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 de servicios o son incorrectas

Si faltan métricas o son incorrectas en los servicios del panel de control Servicios, consulta las siguientes secciones para ver posibles soluciones.

Verificar que los proxies de Sidecar existen y se han inyectado correctamente

Es posible que el espacio de nombres no tenga una etiqueta para la inyección automática o que la inyección manual haya fallado. Confirma que los pods del espacio de nombres tienen al menos dos contenedores y que uno de ellos es el contenedor istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

Verificar que existe la configuración de telemetría

Para confirmar que el filtro de observabilidad de Google Cloud está configurado, obtén un volcado de configuración de cada proxy y busca el 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 la salida del comando anterior, busca el filtro de Google Cloud Observability, que tiene un aspecto similar al siguiente:

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

Verificar que Cloud Service Mesh identifica un servicio HTTP

Las métricas no se mostrarán en la interfaz de usuario si el puerto de servicio del servicio de Kubernetes no se llama http o cualquier nombre con el prefijo http-. Confirma que el servicio tiene los nombres adecuados para sus puertos.

Verificar que la API Cloud Monitoring esté habilitada en el proyecto

Confirma que la API Cloud Monitoring está habilitada en el panel de control APIs & Services (APIs y servicios) de laGoogle Cloud consola, que es el valor predeterminado.

Verificar que no se informan errores a la API de Cloud Monitoring

En el panel de control de APIs y servicios de la consola, abre la URL del gráfico Tráfico por código de respuesta: Google Cloud

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

Si ves mensajes de error, puede que haya un problema que requiera una investigación más a fondo. En concreto, busca un gran número de mensajes de error 429, ya que esto indica que puede haber un problema con la cuota. Consulta la siguiente sección para ver los pasos de solución de problemas.

Verificar la cuota correcta de la API de Cloud Monitoring

En la consola, abre el menú IAM & Admin y comprueba que haya una opción Cuotas. Google Cloud Puedes acceder a esta página directamente con la URL:

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

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

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

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

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Sin embargo, ignora los mensajes de advertencia como el siguiente, 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

Verificar 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 estén registrando métricas y que su metric.mesh_uid tenga el formato proj-<Cloud Service Mesh fleet project number>.

Si metric.mesh_uid tiene cualquier otro valor, el panel de control de Cloud Service Mesh no mostrará métricas. metric.mesh_uid se define cuando Cloud Service Mesh se instala en el clúster, así que investiga tu método de instalación para ver si hay alguna forma de asignarle el valor esperado.

Faltan datos de telemetría de servicios o son incorrectos

De forma predeterminada, Cloud Monitoring y Cloud Logging están habilitados en tuGoogle Cloud proyecto cuando instalas Cloud Service Mesh. Para enviar datos de telemetría, cada proxy adicional que se inserta en los pods de tu servicio llama a la API de Cloud Monitoring y a la API de Cloud Logging. Después de desplegar las cargas de trabajo, los datos de telemetría tardan entre uno y dos minutos en mostrarse en laGoogle Cloud consola. Cloud Service Mesh mantiene actualizados automáticamente los paneles de control de servicios:

En el caso de las métricas, los proxies sidecar llaman a la API de Cloud Monitoring aproximadamente cada minuto.
Para actualizar el gráfico de topología, los proxies sidecar envían informes incrementales aproximadamente cada minuto e informes completos cada diez minutos.
En cuanto al registro, los proxies sidecar llaman a la API de Cloud Logging aproximadamente cada diez segundos.
Para el rastreo, debes habilitar Cloud Trace. Las trazas se registran según la frecuencia de muestreo que hayas configurado (normalmente, una de cada 100 solicitudes).

Las métricas solo se muestran en los servicios HTTP de la página Métricas de Cloud Service Mesh. Si no ve ninguna métrica, compruebe que todos los pods del espacio de nombres de los servicios de su aplicación tienen proxies adicionales insertados:

kubectl get pod -n YOUR_NAMESPACE --all

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

Además, el panel de control de Servicios solo muestra métricas del servidor, por lo que es posible que los datos de telemetría no aparezcan si el cliente no está en la malla o si está configurado para registrar solo métricas del cliente (como las de las pasarelas de entrada).