Realizar análisis históricos con Cloud Logging

Cuando un pod falla o un servicio no funciona como se espera en Google Kubernetes Engine (GKE), es fundamental comprender la secuencia de eventos que han llevado al problema. Inspeccionar el estado actual no siempre es suficiente para encontrar la causa raíz, por lo que los datos de registro históricos son muy valiosos.

En esta página se explica cómo usar Cloud Logging para investigar errores anteriores (por ejemplo, por qué no se ha podido iniciar un pod o quién ha eliminado una implementación crítica) consultando y analizando los registros de GKE.

Esta información es importante para los administradores y operadores de la plataforma que necesiten realizar análisis de la causa raíz de problemas en todo el clúster, auditar cambios y comprender las tendencias de comportamiento del sistema. También es esencial para los desarrolladores de aplicaciones, ya que les permite depurar errores específicos de las aplicaciones, monitorizar las rutas de las solicitudes y comprender cómo se comporta su código en el entorno de GKE a lo largo del tiempo. Para obtener más información sobre los roles habituales y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Información sobre los tipos de registros clave para solucionar problemas

Para ayudarte a solucionar problemas, Cloud Logging recoge y agrega automáticamente varios tipos de registros clave de tus clústeres de GKE, aplicaciones contenerizadas y otrosGoogle Cloud servicios:

  • Registros de nodos y de tiempo de ejecución (kubelet y containerd): los registros de los servicios de nodos subyacentes. Como kubelet gestiona el ciclo de vida de todos los pods del nodo, sus registros son esenciales para solucionar problemas como el inicio de contenedores, los eventos de falta de memoria (OOM), los fallos de sondeo y los errores de montaje de volúmenes. Estos registros también son fundamentales para diagnosticar problemas a nivel de nodo, como un nodo con el estado NotReady.

    Como containerd gestiona el ciclo de vida de tus contenedores, incluida la descarga de imágenes, sus registros son cruciales para solucionar los problemas que se producen antes de que kubelet pueda iniciar el contenedor. Los registros de containerd te ayudan a diagnosticar problemas a nivel de nodo en GKE, ya que documentan las actividades específicas y los posibles errores del tiempo de ejecución del contenedor.

  • Registros de la aplicación (stdout, stderr): los flujos de salida y de errores estándar de los procesos en contenedores. Estos registros son esenciales para depurar problemas específicos de la aplicación, como fallos, errores o comportamientos inesperados.

  • Registros de auditoría: estos registros responden a las preguntas "¿Quién hizo qué, dónde y cuándo?" en tu clúster. Registran las acciones administrativas y las llamadas a la API realizadas en el servidor de la API de Kubernetes, lo que resulta útil para diagnosticar problemas causados por cambios en la configuración o por accesos no autorizados.

Situaciones habituales de solución de problemas

Una vez que haya identificado un problema, puede consultar estos registros para averiguar qué ha ocurrido. Para ayudarte a empezar, revisar los registros puede ayudarte con estos problemas:

  • Si un nodo tiene el estado NotReady, revisa sus registros. Los registros kubelet y containerd suelen revelar la causa subyacente, como problemas de red o restricciones de recursos.
  • Si un nuevo nodo no se aprovisiona y no se une al clúster, consulta los registros del puerto serie del nodo. Estos registros capturan la actividad de arranque inicial y de inicio de kubelet antes de que los agentes de registro del nodo estén completamente activos.
  • Si un pod no se ha podido iniciar en el pasado, revisa los registros de la aplicación de ese pod para comprobar si hay fallos. Si los registros están vacíos o no se puede programar el pod, consulta los registros de auditoría para ver si hay eventos relevantes o los registros de nodos en el nodo de destino para obtener información sobre la presión de los recursos o los errores de extracción de imágenes.
  • Si se ha eliminado una implementación crítica y nadie sabe por qué, consulta los registros de auditoría de actividad de administración. Estos registros pueden ayudarte a identificar qué usuario o cuenta de servicio ha emitido la llamada a la API de eliminación, lo que te proporciona un punto de partida claro para tu investigación.

Cómo acceder a los registros

Usa Explorador de registros para consultar, ver y analizar los registros de GKE en la Google Cloud consola. Explorador de registros ofrece potentes opciones de filtrado que te ayudan a aislar el problema.

Para acceder al Explorador de registros y usarlo, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Explorador de registros.

    Ir a Explorador de registros

  2. En el panel de consultas, escribe una consulta. Usa el lenguaje de las consultas de Logging para escribir consultas específicas. Aquí tienes algunos filtros habituales para empezar:

    Tipo de filtro Descripción Valor de ejemplo
    resource.type El tipo de recurso de Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id El flujo de registro del recurso. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtrar recursos por un nombre específico.
    Sustituye RESOURCE_TYPE por el nombre del recurso que quieras consultar. Por ejemplo, namespace o pod.    		 example-namespace-name, example-pod-name
    severity El nivel de gravedad del registro. DEFAULT, INFO, WARNING, ERROR y CRITICAL
    jsonPayload.message=~ Una búsqueda de texto con expresiones regulares en el mensaje de registro. scale.down.error.failed.to.delete.node.min.size.reached

    Por ejemplo, para solucionar un problema de un Pod concreto, puede que quieras aislar sus registros de errores. Para ver solo los registros con una gravedad ERROR de ese pod, usa la siguiente consulta:

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Haz los cambios siguientes:

    • POD_NAME: nombre del pod que tiene problemas.
    • NAMESPACE_NAME: el espacio de nombres en el que se encuentra el pod. Si no sabes cuál es el espacio de nombres, consulta la columna Namespace del resultado del comando kubectl get pods.

    Para ver más ejemplos, consulta las consultas relacionadas con Kubernetes en la documentación de Google Cloud Observability.

  3. Haz clic en Realizar una consulta.

  4. Para ver el mensaje de registro completo, incluida la carga útil JSON, los metadatos y la marca de tiempo, haz clic en la entrada de registro.

Para obtener más información sobre los registros de GKE, consulta Acerca de los registros de GKE.

Siguientes pasos