Soluciona problemas de paneles de supervisión

Autopilot Estándar

En esta página, se muestra cómo resolver problemas relacionados con los paneles de supervisión para Google Kubernetes Engine (GKE).

De forma predeterminada, Monitoring se habilita cuando creas un clúster. Si no ves los paneles de GKE cuando ves los paneles de Google Cloud proporcionados en Monitoring, Monitoring no está habilitado para los clústeres en el proyecto de Google Cloud seleccionado. Habilita la supervisión para ver estos paneles.

No hay recursos de Kubernetes en mi panel

Si no ves ningún recurso de Kubernetes en tu panel de GKE, verifica lo siguiente:

Proyecto de Google Cloud seleccionado

Verifica que seleccionaste el proyecto de Google Cloud correcto de la lista desplegable en la barra de menú de la consola de Google Cloud para seleccionar un proyecto. Debes seleccionar el proyecto cuyos datos deseas ver.

Actividad de los clústeres

Si acabas de crear tu clúster, espera unos minutos para que se propague con los datos. Consulta Configura el registro y la supervisión para GKE a fin de obtener más detalles.

Intervalo de tiempo

El intervalo de tiempo seleccionado puede ser demasiado reducido. Puedes usar el menú Tiempo en la barra de herramientas del panel para seleccionar otros intervalos de tiempo o definir un intervalo Personalizado.

Permisos para ver el panel

Si ves alguno de los siguientes mensajes de error de permiso denegado cuando revisas los detalles de implementación de un servicio o las métricas de un proyecto de Google Cloud, debes actualizar tu Identity and Access Management para incluir roles/monitoring.viewer o roles/viewer:

You do not have sufficient permissions to view this page
You don't have permissions to perform the action on the selected resources

Para obtener más información, ve a Funciones predefinidas.

Permisos de la cuenta de servicio del nodo y del clúster para escribir datos en Monitoring y Logging

Si ves tasas de errores altas en la página API y servicios habilitados en la consola de Google Cloud, es posible que tu cuenta de servicio no tenga los siguientes roles:

roles/logging.logWriter: En la consola de Google Cloud, este rol se denomina Escritor de registros. Para obtener más información sobre las funciones de Logging, consulta la Guía de control de acceso de Logging.
roles/monitoring.metricWriter: En la consola de Google Cloud, este rol se denomina Escritor de métricas de Monitoring. Para obtener más información sobre las funciones de Monitoring, consulta la Guía de control de acceso de Monitoring.
roles/stackdriver.resourceMetadata.writer: En la consola de Google Cloud, este rol se denomina Escritor de metadatos de recursos de Stackdriver. Con esta función, se permite el acceso de solo escritura a los metadatos de recursos y se proporcionan los permisos necesarios para que los agentes envíen los metadatos. Para obtener más información sobre las funciones de Monitoring, consulta la Guía de control de acceso de Monitoring.

Para mostrar tus cuentas de servicio, en la consola de Google Cloud, ve a IAM y administración y, luego, selecciona Cuentas de servicio.

No se pueden ver los registros

Si no ves los registros en los paneles, verifica lo siguiente:

El agente está en ejecución y en buen estado

La versión de GKE 1.17 y versiones posteriores usan Fluent Bit para capturar registros. Fluent Bit es el agente de Logging que se ejecuta en los nodos de Kubernetes. Para verificar si el agente se ejecuta de forma correcta, sigue estos pasos:

Ejecuta el siguiente comando para verificar si el agente se reinicia:

kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

Si no hay reinicios, el resultado es similar al siguiente:

NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

Ejecuta el siguiente comando para verificar las condiciones de estado del Pod:

JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

Si la implementación está en buen estado, el resultado es similar al siguiente:

fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

Verifica el estado del Pod, que puede ayudarte a determinar si la implementación está en buen estado. Para ello, ejecuta el siguiente comando:
```
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system
```
Si la implementación está en buen estado, el resultado es similar al siguiente:
```
NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h
```
En este resultado de ejemplo, el estado deseado coincide con el estado actual.

Si el agente está en ejecución y en buen estado en estas situaciones y aún no ves todos tus registros, es posible que el agente esté sobrecargado y quitando registros.

El agente está sobrecargado y quita registros

Una posible causa por la que no ves todos los registros es que el volumen de registros del nodo sobrecarga al agente. La configuración predeterminada del agente de Logging en GKE se ajusta a la tasa de 100 kiB por segundo para cada nodo. El agente puede comenzar a descartar registros si el volumen supera ese límite.

Para detectar si alcanzas este límite, busca cualquiera de los siguientes indicadores:

Consulta la métrica kubernetes.io/container/cpu/core_usage_time con el filtro container_name=fluentbit-gke para ver si el uso de CPU del agente de Logging está cerca del 100% o lo alcanzó.
Observa la métrica logging.googleapis.com/byte_count que agrupa metadata.system_labels.node_name para verificar si algún nodo alcanza los 100 kiB por segundo.

Si ves alguna de estas condiciones, puedes agregar más nodos al clúster a fin de reducir el volumen de registros de los nodos. Si todo el volumen de registro proviene de un solo Pod, deberás reducir su volumen.

Si deseas cambiar los parámetros de ajuste del agente de Logging, consulta el instructivo de la comunidad para implementar una configuración de agente de Logging personalizada.

Para obtener más información sobre la investigación y la resolución de problemas relacionados con el registro en GKE, consulta Soluciona problemas de registro en GKE.

El incidente no coincide con un recurso de GKE

Si tienes una condición de política de alertas que agrega métricas a diferentes recursos de GKE, es posible que debas editar la condición de la política para incluir más etiquetas de jerarquía de GKE a fin de asociar incidentes con entidades específicas.

Por ejemplo, puedes tener dos clústeres de GKE, uno para la producción y otro para la etapa de pruebas, cada uno con su propia copia de servicio lilbuddy-2. Cuando la condición de la política de alertas agrega una métrica a los contenedores en ambos clústeres, el panel de Monitoring de GKE no puede asociar este incidente de forma única con el servicio de producción o el servicio de etapa de pruebas.

Para resolver esta situación, orienta la política de alertas a un servicio específico mediante la adición de namespace, cluster y location al campo Agrupar por de la política. En la tarjeta del evento de la alerta, haz clic en el vínculo Update alert policy para abrir la página Editar política de alertas de la política de alertas pertinente. Desde aquí, puedes actualizar la política de alertas con información adicional para que el panel pueda encontrar el recurso asociado.

Después de actualizar la política de alertas, el panel de Monitoring de GKE puede asociar todos los incidentes futuros con un servicio único en un clúster específico, lo que te brinda información adicional para diagnosticar el problema.

Según el caso de uso, recomendamos filtrar algunas de estas etiquetas además de agregarlas al campo Agrupar por. Por ejemplo, si solo deseas recibir alertas para tu clúster de producción, puedes filtrar por cluster_name.