Solucionar problemas con registros que faltan en GKE

Los problemas con la canalización de registros en Google Kubernetes Engine (GKE) pueden impedir que los registros de tu clúster aparezcan en Cloud Logging, lo que dificulta tus esfuerzos de monitorización y depuración.

Consulta este documento para saber cómo verificar configuraciones y permisos, solucionar problemas de recursos y rendimiento, investigar filtros y el comportamiento de las aplicaciones, y abordar problemas de la plataforma o del servicio que afecten a tus registros.

Esta información es importante para los administradores y operadores de la plataforma que mantienen la observabilidad del clúster, así como para cualquier persona que use Cloud Logging para solucionar problemas de operaciones de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de usuario de GKE.

Para obtener más información sobre cómo usar los registros para solucionar problemas de tus cargas de trabajo y clústeres, consulta Realizar análisis históricos con Cloud Logging.

Encontrar la solución por síntoma

Si has identificado un síntoma específico relacionado con los registros que faltan, consulta la siguiente tabla para obtener consejos sobre cómo solucionar el problema:

Categoría Síntoma u observación Posible causa Pasos para solucionar el problema
Configuración No se ven los registros de ningún clúster del proyecto. La API Cloud Logging está inhabilitada en el proyecto. Verificar el estado de la API Cloud Logging
Faltan registros de un clúster específico o solo faltan determinados tipos de registros. El registro a nivel de clúster está inhabilitado para los tipos de registro obligatorios. Verificar la configuración de registro del clúster
Faltan registros de los nodos de un grupo de nodos específico. Los nodos del grupo de nodos no tienen el ámbito de acceso necesario. Verificar los ámbitos de acceso del pool de nodos
Aparecen errores de permisos (401 o 403) en los registros del agente de registro. La cuenta de servicio del nodo no tiene el permiso necesario. Verificar los permisos de la cuenta de servicio del nodo
Recursos y rendimiento Faltan registros de forma intermitente o se muestran errores RESOURCE_EXHAUSTED. El proyecto está superando la cuota de escritura de la API de Cloud Logging. Investigar el uso de la cuota de la API de Cloud Logging
Faltan algunos registros de un nodo específico, a menudo durante periodos de tráfico o carga elevados. El nodo supera los límites de rendimiento del agente de registro o no tiene recursos (CPU o memoria) para procesar los registros. Investigar el rendimiento de los nodos y el uso de recursos
Filtrado y comportamiento de las aplicaciones Faltan constantemente registros específicos que coinciden con un patrón determinado. Un filtro de exclusión de registros de Cloud Logging está descartando los registros sin querer. Investigar filtros de exclusión de registros
Los registros de un contenedor se retrasan significativamente o solo aparecen después de que el contenedor se cierre. La salida de la aplicación está totalmente almacenada en búfer, a menudo debido a la canalización stdout. Investigar el almacenamiento en búfer y los retrasos de los registros de contenedores
Los registros esperados no aparecen en los resultados de búsqueda. Los filtros de consulta de Explorador de registros pueden ser demasiado restrictivos. Investigar consultas del Explorador de registros
No se ven registros de un pod de aplicación específico, pero sí otros registros del clúster. La aplicación del contenedor no escribe en stdout ni en stderr. Investigar el comportamiento de registro específico de una aplicación
Plataforma y servicio No aparecen los registros anteriores a una fecha determinada. Los registros han superado el periodo de conservación y Cloud Logging los ha eliminado. Investigar los periodos de conservación de registros
Pérdida o retrasos generalizados de registros en proyectos o clústeres. Problema con el servicio Cloud Logging o retraso en la ingestión. Investigar problemas y retrasos del servicio Cloud Logging
Los problemas de registro coinciden con las limitaciones de la versión del clúster. Versión de GKE no compatible. Investigar la versión del clúster

Usar herramientas de diagnóstico automatizadas

En las siguientes secciones se describen las herramientas que pueden inspeccionar automáticamente tu clúster para detectar errores de configuración habituales y ayudarte a investigar problemas complejos.

Depurar problemas de registro de GKE con gcpdiag

Si faltan registros o están incompletos en tu clúster de GKE, usa la herramienta gcpdiag para solucionar los problemas.

gcpdiag es una herramienta de código abierto. No es un producto Google Cloud con asistencia oficial. Puedes usar la herramienta gcpdiag para identificar y solucionar problemas de proyectos. Google CloudPara obtener más información, consulta el proyecto gcpdiag en GitHub.

Si faltan registros del clúster de GKE o están incompletos, investiga las posibles causas centrándote en los siguientes ajustes de configuración principales:

  • Registro a nivel de proyecto: asegura que el proyecto que aloja el clúster de GKE tenga habilitada la API Cloud Logging. Google Cloud
  • Registro a nivel de clúster: verifica que el registro esté habilitado explícitamente en la configuración del clúster de GKE.
  • Permisos del grupo de nodos: confirma que los nodos de los grupos de nodos del clúster tienen habilitado el ámbito Cloud Logging Write, lo que les permite enviar datos de registro.
  • Permisos de la cuenta de servicio: valida que la cuenta de servicio utilizada por los grupos de nodos tenga los permisos de gestión de identidades y accesos necesarios para interactuar con Cloud Logging. En concreto, suele ser necesario el rol roles/logging.logWriter.
  • Cuotas de escritura de la API Cloud Logging: verifica que no se hayan superado las cuotas de escritura de la API Cloud Logging en el periodo especificado.

Google Cloud console

  1. Completa y copia el siguiente comando. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Abre la Google Cloud consola y activa Cloud Shell.
    3. Abrir la consola de Cloud
  3. Pega el comando copiado.
  4. Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, a continuación, realiza comprobaciones de diagnóstico. Si procede, sigue las instrucciones de salida para corregir las comprobaciones fallidas.

Docker

Puedes ejecutar gcpdiag mediante un envoltorio que inicie gcpdiag en un contenedor Docker. Docker o Podman deben estar instalados.

  1. Copia y ejecuta el siguiente comando en tu estación de trabajo local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Ejecuta el comando gcpdiag. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Consulta los parámetros disponibles de este runbook.

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto que contiene el recurso.
  • CLUSTER_NAME: el nombre del clúster de GKE.
  • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.

Marcas útiles:

Para ver una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las gcpdiaginstrucciones de uso.

Usar las investigaciones de Gemini Cloud Assist

Puedes usar las investigaciones de Gemini Cloud Assist para obtener más información sobre tus registros y resolver problemas. Para obtener más información sobre las diferentes formas de iniciar una investigación con el Explorador de registros, consulta el artículo Solucionar problemas con las investigaciones de Gemini Cloud Assist en la documentación de Gemini.

Verificar la configuración y los permisos de registro

Una configuración incorrecta es un motivo habitual por el que faltan registros de GKE. Consulta las siguientes secciones para verificar tu configuración de Cloud Logging.

Verificar el estado de la API Cloud Logging

Para que se recojan registros de cualquier clúster de tu proyecto, la API Cloud Logging debe estar activa.

Síntomas:

No se muestran registros de ningún recurso de GKE de tu proyecto en Cloud Logging.

Causa:

La API Cloud Logging está inhabilitada en el proyecto Google Cloud , lo que impide que el agente de registro de los nodos envíe registros.

Resolución:

Para comprobar que la API Cloud Logging está habilitada y habilitarla si es necesario, selecciona una de las siguientes opciones:

Consola

  1. En la Google Cloud consola, ve a la página APIs y servicios habilitados.

    Ir a APIs y servicios habilitados

  2. En el campo Filtrar, escribe Cloud Logging API y pulsa Intro.

  3. Si la API está habilitada, aparecerá en la lista. Si la API no aparece en la lista, habilítala:

    1. Haz clic en Habilitar APIs y servicios.
    2. En el campo Buscar, escribe Cloud Logging API y pulsa Intro.
    3. Haz clic en el resultado API Cloud Logging.
    4. Haz clic en Enable (Habilitar).

gcloud

  1. Comprueba si la API está habilitada:

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    La salida debería ser la siguiente:

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Si la API no aparece en la lista de servicios habilitados, habilítala:

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud

Verificar la configuración de registro del clúster

GKE te permite configurar qué tipos de registros (como SYSTEM o WORKLOAD) se recogen de un clúster.

Síntomas:

No aparecen registros en Cloud Logging de un clúster de GKE específico o solo faltan determinados tipos de registros (como SYSTEM).

Causa:

El registro a nivel de clúster está inhabilitado para los tipos de registro obligatorios. Si utilizas un clúster de Autopilot, este no es el motivo de tus problemas de registro. Este ajuste se puede configurar en los clústeres estándar, pero siempre está habilitado de forma predeterminada en los clústeres de Autopilot y no se puede inhabilitar.

Resolución:

Para comprobar y actualizar la configuración de registro del clúster, selecciona una de las siguientes opciones:

Consola

  1. En la Google Cloud consola, ve a la página Clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

  2. Haga clic en el nombre del clúster que quiera investigar.

  3. Haz clic en la pestaña Detalles y ve a la sección Funciones.

  4. En la fila Registro, comprueba qué tipos de registro están habilitados, como Sistema o Cargas de trabajo.

  5. Si los tipos de registro que quieres recoger están inhabilitados o son incorrectos, haz clic en Editar registro.

  6. En la lista Components (Componentes), marca las casillas de los tipos de registro que quieras recoger y haz clic en OK (Aceptar). Para obtener más información sobre los tipos de registros disponibles, consulta el artículo Acerca de los registros de GKE.

  7. Haz clic en Guardar cambios.

gcloud

  1. Para comprobar la configuración de registro, describe el clúster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
    • PROJECT_ID: tu ID de proyecto Google Cloud .

    Si el registro está habilitado, el resultado será similar al siguiente:

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Si el resultado es NONE, significa que el registro está inhabilitado.

  2. Si los tipos de registros que quieres están inhabilitados o son incorrectos, actualiza la configuración de registro:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Sustituye LOGGING_TYPE por SYSTEM, WORKLOAD o ambas. Para recoger los registros, SYSTEM debe estar habilitado. Los registros de WORKLOAD no se pueden recoger por sí solos. Para obtener más información sobre los tipos de registros disponibles, consulta el artículo Acerca de los registros de GKE.

Verificar los permisos de acceso del grupo de nodos

Los nodos de un clúster de GKE usan permisos de acceso de OAuth para obtener permiso para interactuar con APIs, incluida Cloud Logging. Google Cloud

Síntomas:

Faltan registros de los nodos de un grupo de nodos específico.

Causa:

Los nodos del grupo de nodos no tienen el permiso de acceso de OAuth necesario. Los nodos deben tener uno de los siguientes permisos para escribir registros en Cloud Logging:

  • https://www.googleapis.com/auth/logging.write: concede permiso para escribir registros. Este es el ámbito mínimo necesario.
  • https://www.googleapis.com/auth/logging.admin: otorga acceso completo a la API Cloud Logging, que incluye los permisos de logging.write.
  • https://www.googleapis.com/auth/cloud-platform: concede acceso completo a todas las APIs habilitadas, incluidas las de Google Cloud .logging.write

Resolución:

Para verificar los permisos y conceder los roles necesarios si faltan, selecciona una de las siguientes opciones:

Consola

  1. Verifica los ámbitos de acceso del grupo de nodos:

    1. En la Google Cloud consola, ve a la página Clústeres de Kubernetes.

      Ir a clústeres de Kubernetes

    2. Para abrir la página de detalles del clúster, haz clic en el nombre del clúster que quieras investigar.

    3. Haz clic en la pestaña Nodos.

    4. En la sección Grupos de nodos, haz clic en el nombre del grupo de nodos que quieras investigar.

    5. Ve a la sección Seguridad.

    6. Revisa los permisos que se indican en el campo Permisos de acceso. Asegúrate de que se incluya al menos uno de los ámbitos obligatorios:

      • API de Stackdriver Logging (solo escritura)
      • API de Stackdriver Logging - Completa
      • Cloud Platform - Habilitado

      Si faltan los ámbitos obligatorios, vuelve a crear el grupo de nodos. No puedes cambiar los ámbitos de acceso de un grupo de nodos que ya tengas.

  2. Si es necesario, crea un grupo de nodos con el ámbito requerido:

    1. Vuelve a la página de detalles del clúster que quieras modificar.
    2. Haz clic en la pestaña Nodos.
    3. Haz clic en Crear grupo de nodos gestionado por el usuario.
    4. Rellena la sección Detalles del grupo de nodos.
    5. En el panel de navegación de la izquierda, haz clic en Seguridad.
    6. En la sección Ámbitos de acceso, selecciona los roles que quieras añadir:
      • Para añadir ámbitos específicos, selecciona Definir acceso para cada API.
      • Para permitir el acceso completo, selecciona Permitir el acceso completo a todas las APIs de Cloud.
    7. Configure las demás secciones según sea necesario.
    8. Haz clic en Crear.

  3. Migra tus cargas de trabajo al nuevo grupo de nodos. Después de migrar las cargas de trabajo al nuevo grupo de nodos, las aplicaciones se ejecutan en nodos que tienen los ámbitos necesarios para enviar registros a Cloud Logging.

  4. Elimina el grupo de nodos antiguo:

    1. Vuelve a la página de detalles del clúster y selecciona la pestaña Nodos.
    2. En la sección Grupos de nodos, busca el grupo de nodos antiguo.
    3. Junto al grupo de nodos, haz clic en Eliminar .
    4. Cuando se te pida, confirma la eliminación escribiendo el nombre del grupo de nodos y haz clic en Eliminar.

gcloud

  1. Verifica los ámbitos de acceso del grupo de nodos:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
    • PROJECT_ID: tu ID de proyecto Google Cloud .

    Revisa el resultado de cada grupo de nodos. Asegúrate de que se incluya al menos uno de los permisos obligatorios (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform o https://www.googleapis.com/auth/logging.admin). Si faltan los ámbitos obligatorios, vuelve a crear el grupo de nodos. No puedes cambiar los ámbitos de acceso de un grupo de nodos que ya tengas.

  2. Si es necesario, crea un grupo de nodos con el ámbito requerido:

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Haz los cambios siguientes:

    • NEW_NODE_POOL_NAME: nombre del nuevo pool de nodos.
    • OTHER_SCOPES: lista separada por comas de otros permisos que necesiten tus nodos. Si no necesitas otros ámbitos, omite este marcador de posición y la coma anterior.

  3. Migra tus cargas de trabajo al nuevo grupo de nodos. Después de migrar las cargas de trabajo al nuevo grupo de nodos, tus aplicaciones se ejecutan en nodos que tienen los ámbitos necesarios para enviar registros a Cloud Logging.

  4. Elimina el grupo de nodos antiguo:

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Verificar los permisos de la cuenta de servicio del nodo

Los nodos usan una cuenta de servicio para autenticarse en los servicios de Google Cloud , y esta cuenta necesita permisos de gestión de identidades y accesos específicos para escribir registros.

Síntomas:

  • Faltan registros de los nodos.
  • Al inspeccionar los registros del agente de registro (por ejemplo, Fluent Bit), es posible que se muestren errores relacionados con los permisos, como los códigos 401 o 403, al intentar escribir en Cloud Logging.
  • Puede que veas una Grant Critical Permissions to Node Service Account notificación del clúster en la Google Cloud consola.

Causa:

La cuenta de servicio que usan los nodos del grupo de nodos no tiene los permisos de IAM necesarios para escribir registros en Cloud Logging. Los nodos requieren una cuenta de servicio con el rol logging.logWriter, que incluye el permiso logging.logEntries.create.

Además, en las versiones 1.33 y posteriores de GKE, el agente de servicio de nodo predeterminado (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) de GKE debe tener como mínimo el rol de agente de servicio de nodo predeterminado de Kubernetes (roles/container.defaultNodeServiceAgent). Este rol permite a GKE gestionar los recursos y las operaciones de los nodos, incluidos los componentes de registro.

Resolución:

Para verificar los permisos y conceder los roles necesarios si faltan, haz lo siguiente:

  • Verifica el permiso de la cuenta de servicio del nodo.
  • Verifica que el agente de servicio de GKE tenga el rol necesario.

Verificar el permiso de la cuenta de servicio del nodo

La cuenta de servicio del nodo es la que usa el nodo para autenticarse y enviar registros. Para identificar esta cuenta de servicio y verificar que tiene el permiso roles/logging.logWriternecesario, haz lo siguiente:

  1. Para identificar la cuenta de servicio que usa el grupo de nodos, selecciona una de las siguientes opciones:

    Consola

    1. En la Google Cloud consola, ve a la página Clústeres de Kubernetes.

      Ir a clústeres de Kubernetes

    2. En la lista de clústeres, haga clic en el nombre del clúster que quiera inspeccionar.

    3. En función del modo de funcionamiento del clúster, haz una de las siguientes acciones:

      • En los clústeres estándar, haz lo siguiente:

        1. Haz clic en la pestaña Nodos.
        2. En la tabla Grupos de nodos, haz clic en el nombre de un grupo de nodos. Se abrirá la página de detalles del grupo de nodos.
        3. En la sección Seguridad, busca el campo Cuenta de servicio.

      • En los clústeres de Autopilot, haz lo siguiente:

        1. Ve a la pestaña Detalles.
        2. En la sección Seguridad, busca el campo Cuenta de servicio.

      Si el valor del campo Cuenta de servicio es default, tus nodos usan la cuenta de servicio predeterminada de Compute Engine. Si el valor de este campo no es default, tus nodos usan una cuenta de servicio personalizada. Para asignar el rol necesario a una cuenta de servicio personalizada, consulta Usar cuentas de servicio de IAM con el mínimo de privilegios.

    gcloud

    Ejecuta el siguiente comando en función del tipo de clúster que utilices:

    Clústeres estándar 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Haz los cambios siguientes:

    • NODE_POOL_NAME: el nombre del grupo de nodos.
    • CLUSTER_NAME: el nombre de tu clúster Standard.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
    • PROJECT_ID: tu ID de proyecto Google Cloud.

    Si el resultado es default, el grupo de nodos usa la cuenta de servicio predeterminada de Compute Engine. Si el valor no es default, tus nodos usan una cuenta de servicio personalizada. Para asignar el rol necesario a una cuenta de servicio personalizada, consulta Usar cuentas de servicio de IAM con el mínimo de privilegios.

    Clústeres de Autopilot 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster de Autopilot.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
    • PROJECT_ID: tu Google Cloud ID de proyecto.

    Si el resultado es default, el grupo de nodos usa la cuenta de servicio predeterminada de Compute Engine. Si el valor no es default, tus nodos usan una cuenta de servicio personalizada. Para asignar el rol necesario a una cuenta de servicio personalizada, consulta Usar cuentas de servicio de IAM con el mínimo de privilegios.

    Para ver secuencias de comandos más detalladas que te ayuden a identificar los permisos que faltan, consulta Identificar todas las cuentas de servicio de nodos a las que les faltan permisos.

  2. GKE busca automáticamente los permisos que faltan y proporciona recomendaciones. Para usar las recomendaciones y comprobar si faltan permisos, selecciona una de las siguientes opciones:

    Consola

    1. En la página Clústeres de Kubernetes, busca la columna Notificaciones.
    2. Consulta la columna Notificaciones para ver la recomendación Conceder permisos críticos. Esta recomendación significa que la comprobación NODE_SA_MISSING_PERMISSIONS no se ha superado.
    3. Si aparece la recomendación, haz clic en ella. Se abrirá un panel de detalles en el que se explican los permisos que faltan y se indican los pasos para solucionarlo.

    gcloud

    1. Mostrar recomendaciones sobre permisos de cuentas de servicio que faltan:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analiza el resultado del comando:

      • Si el comando devuelve una lista vacía, significa que el recomendador no ha encontrado ninguna recomendación NODE_SA_MISSING_PERMISSIONS activa. Parece que las cuentas de servicio que ha comprobado tienen los permisos necesarios.

      • Si el comando devuelve uno o varios bloques YAML, significa que el recomendador ha identificado un problema de permisos. Revisa los resultados de los siguientes campos clave:

        • description: proporciona un resumen del problema, como especificar que a tu cuenta de servicio de nodo le falta el rol roles/logging.logWriter o que al agente de servicio de GKE le falta el rol roles/container.defaultNodeServiceAgent.
        • resource: especifica el clúster afectado.
        • content.operations: contiene la resolución recomendada. En esta sección se proporciona el comando gcloud projects add-iam-policy-binding exacto necesario para conceder el rol que falta.

    El recomendador puede tardar hasta 24 horas en reflejar los cambios recientes.

  3. Si quieres verificar los permisos inmediatamente, para comprobar los permisos y asignar el rol, selecciona una de las siguientes opciones:

    Consola

    1. En la consola de Google Cloud , ve a la página Gestión de identidades y accesos.

      Ir a IAM

    2. Busca la cuenta de servicio que usa el grupo de nodos.

    3. En la columna Rol, comprueba si la cuenta de servicio tiene el rol Escritor de registros (roles/logging.logWriter).

    4. Si falta el permiso, añádelo:

      1. Haz clic en Editar principal.
      2. Haz clic en Añadir otro rol.
      3. En el campo de búsqueda, introduce Logs Writer.
      4. Seleccione la casilla Escritor de registros y haga clic en Aplicar.
      5. Haz clic en Guardar.

    gcloud

    1. Comprueba los roles actuales de la cuenta de servicio del nodo:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Si falta, concede el rol logging.logWriter:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Verificar los permisos del agente de servicio de GKE

Si siguen faltando registros y usas la versión 1.33 o una posterior, comprueba que el agente gestionado por Google que usa GKE para gestionar los componentes de tu nodo tenga el permiso necesario:

  1. Para identificar la dirección de correo del agente de servicio, obtén el número de tu proyecto:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    Sustituye PROJECT_ID por el ID de tu proyecto. Anota el resultado.

    El correo del agente de servicio de GKE es: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Para usar las recomendaciones y comprobar si faltan permisos, selecciona una de las siguientes opciones:

    Consola

    1. En la página Clústeres de Kubernetes, busca la columna Notificaciones.
    2. Consulta la columna de la recomendación Conceder permisos críticos.
    3. Si aparece la recomendación, haz clic en ella. Se abrirá un panel de detalles en el que se explican los permisos que faltan y se indican los pasos para solucionarlo.

    gcloud

    1. Mostrar recomendaciones sobre permisos de cuentas de servicio que faltan:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analiza el resultado del comando. Revisa el resultado para ver una descripción que especifique que falta el rol roles/container.defaultNodeServiceAgent del agente de servicio de GKE (gcp-sa-gkenode).

  3. Para comprobar los permisos inmediatamente y asignar el rol, selecciona una de las siguientes opciones:

    Consola

    1. En la consola de Google Cloud , ve a la página Gestión de identidades y accesos.

      Ir a IAM

    2. En el campo Filtro, escribe la dirección de correo del agente de servicio de GKE y pulsa Intro.

    3. En la lista filtrada, comprueba si el agente de servicio tiene al menos el rol Agente de servicio de nodo predeterminado de Kubernetes (roles/container.defaultNodeServiceAgent).

    4. Si falta el rol, concédele el permiso:

      1. Haz clic en Editar principal junto al agente de servicio.
      2. Haz clic en Añadir roles.
      3. En el campo de búsqueda, introduce Kubernetes Default Node Service Agent y selecciona el rol.
      4. Haz clic en Guardar.

    gcloud

    1. Comprueba si el rol roles/container.defaultNodeServiceAgent está vinculado al agente de servicio:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      En el resultado, busca roles/container.defaultNodeServiceAgent.

    2. Si falta el rol, concede el rol Agente de servicio de nodo predeterminado de Kubernetes:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Solucionar problemas de recursos y rendimiento

Si faltan registros de forma intermitente o se eliminan de nodos con mucho tráfico, puede que la causa no sea un error de configuración, sino un problema de rendimiento. Consulta las secciones siguientes para investigar si tu proyecto supera las cuotas de API o si el gran volumen de registros está sobrecargando los agentes de nodos específicos.

Investigar el uso de la cuota de la API de Cloud Logging

Para proteger el servicio, Cloud Logging aplica una cuota de escritura a todos los proyectos, lo que limita el volumen total de registros que Cloud Logging puede ingerir por minuto.

Síntomas:

  • Faltan registros de forma intermitente o por completo.
  • Aparecen errores RESOURCE_EXHAUSTED relacionados con logging.googleapis.com en los registros de nodos o agentes de registro.

Causa:

El proyecto está superando la cuota de solicitudes de escritura de la API de Cloud Logging. Este problema impide que el agente de registro envíe registros.

Resolución:

Para comprobar el uso de la cuota y solicitar un aumento, haz lo siguiente:

  1. En la Google Cloud consola, ve a la página Cuotas.

    Ir a Cuotas

  2. En el campo Filtrar, escribe Cloud Logging API y pulsa Intro.

  3. En la lista filtrada, busca la cuota de Bytes de escritura de registros por minuto y región de la región en la que se encuentra tu clúster.

  4. Revisa los valores de la columna Porcentaje de uso actual. Si el uso está cerca del límite o lo ha alcanzado, es probable que hayas superado la cuota.

  5. Para solicitar un aumento, haz clic en Editar cuota y sigue las instrucciones. Para obtener más información, consulta Ver y gestionar cuotas.

Para reducir el uso, puedes excluir registros o reducir la verbosidad de los registros de las aplicaciones. También puedes configurar políticas de alertas para recibir notificaciones antes de alcanzar el límite.

Investigar el rendimiento de los nodos y el uso de recursos

El agente de registro de GKE de cada nodo tiene su propio límite de capacidad, que se puede superar.

Síntomas:

Los registros de nodos específicos faltan o se retrasan de forma intermitente, sobre todo durante periodos de alta actividad del clúster o de uso intensivo de los recursos de los nodos.

Causa:

El agente de registro de GKE tiene un límite de rendimiento predeterminado (aproximadamente 100 KB/s por nodo). Si las aplicaciones de un nodo generan registros más rápido que este límite, es posible que el agente elimine registros, aunque no se haya superado la cuota general de la API del proyecto. Puedes monitorizar el rendimiento del registro de nodos mediante la métrica kubernetes.io/node/logs/input_bytes en el explorador de métricas.

También es posible que falten registros si el nodo está sometido a una gran presión de CPU o de memoria, lo que deja recursos insuficientes para que el agente procese los registros.

Resolución:

Para reducir el rendimiento, selecciona una de las siguientes opciones:

Clústeres estándar

Prueba las siguientes soluciones:

  • Habilita el registro de alto rendimiento: esta función aumenta la capacidad por nodo. Para obtener más información, consulta Ajustar el rendimiento del agente de Cloud Logging.

  • Reduce el volumen de registros: analiza los patrones de registro de aplicaciones. Reduce el registro innecesario o excesivamente detallado.

  • Desplegar un agente de registro personalizado: puedes desplegar y gestionar tu propio DaemonSet de Fluent Bit personalizado, pero serás responsable de su configuración y mantenimiento.

  • Comprueba el uso de recursos de los nodos: aunque el volumen de registros esté dentro de los límites, asegúrate de que los nodos no estén sometidos a una presión excesiva de la CPU o la memoria. Si los recursos de los nodos son insuficientes, se puede dificultar la capacidad del agente de registro para procesar y enviar registros. Puedes consultar métricas como kubernetes.io/node/cpu/core_usage_time y kubernetes.io/node/memory/used_bytes en Explorador de métricas.

Clústeres de Autopilot

Prueba las siguientes soluciones:

  • Reduce el volumen de registros: analiza los patrones de registro de tu aplicación. Reduce el registro innecesario o excesivamente detallado. Asegúrate de que los registros estén estructurados siempre que sea posible, ya que estos tipos de registros pueden ayudar a que el procesamiento sea eficiente. Excluye los registros que no sean esenciales.

  • Optimizar el rendimiento de las aplicaciones: como los recursos de los nodos se gestionan en los clústeres de Autopilot, asegúrate de que tus aplicaciones no consuman demasiada CPU o memoria, ya que esto podría afectar indirectamente al rendimiento de los componentes de los nodos, como el agente de registro. Aunque no gestionas los nodos directamente, la eficiencia de las aplicaciones afecta al estado general de los nodos.

Solucionar problemas de filtrado y de aplicaciones

Si tu aplicación genera registros correctamente, pero estos no aparecen en Cloud Logging, el problema suele deberse al filtrado o al comportamiento de registro de la aplicación. En las siguientes secciones se analizan problemas como los filtros de exclusión de registros, el almacenamiento en búfer a nivel de contenedor, las consultas de búsqueda restrictivas y las aplicaciones que no escriben en stdout ni en stderr.

Investigar los filtros de exclusión de registros

Explorador de registros solo muestra los registros que coinciden con todos los filtros de tu consulta y con el periodo seleccionado.

Síntomas:

Faltan registros específicos que cumplen determinados criterios en Cloud Logging, pero sí están presentes otros registros de las mismas fuentes.

Causa:

Los filtros de exclusión de registros se definen en los sumideros de Cloud Logging (a menudo, el sumidero _Default). Estas reglas eliminan de forma silenciosa los registros que cumplen criterios específicos, aunque el nodo los haya enviado correctamente.

Resolución:

Para revisar y modificar los filtros de exclusión, selecciona una de las siguientes opciones:

Consola

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

    Ir al enrutador de registros

  2. Identifica el filtro que da problemas:

    1. En cada receptor (excepto en el receptor _Required, que no puede tener filtros de exclusión), haz clic en Más acciones y selecciona Ver detalles del receptor.
    2. Revisa las consultas de la sección Filtros de exclusión. Compara la lógica del filtro con los atributos de los registros que faltan (por ejemplo, el tipo de recurso, las etiquetas o las palabras clave).
    3. Copia la consulta del filtro de exclusión.

    4. Ve a la página Explorador de registros.

      Ir a Explorador de registros

    5. Pegue la consulta del filtro de exclusión en el panel de consultas y haga clic en Ejecutar consulta.

    6. Revisa los resultados. Los registros que se muestran son los que el filtro excluiría. Si los registros que faltan aparecen en estos resultados, es probable que el filtro sea la causa.

  3. Inhabilita o edita el filtro:

    1. Vuelve a la página Enrutador de registros.
    2. Haz clic en Más acciones en el receptor con el filtro sospechoso y selecciona Editar receptor.
    3. Busca la sección Seleccionar los registros que se excluirán del sumidero y el filtro de exclusión.
    4. Puedes hacer clic en Inhabilitar para inhabilitar el filtro o modificar su consulta para que sea más específica.
    5. Haz clic en Actualizar receptor. Los cambios se aplican a los registros nuevos.

gcloud

  1. Mostrar todos los sumideros del proyecto:

    gcloud logging sinks list --project=PROJECT_ID

  2. Para ver los filtros de exclusión de cada receptor, sigue estos pasos:

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    En la salida, revisa la sección exclusions. Compara la lógica del filtro con los atributos de los registros que faltan (por ejemplo, el tipo de recurso, las etiquetas o las palabras clave).

  3. Para modificar las exclusiones, actualiza la configuración del receptor:

    1. Exporta la configuración del receptor a un archivo local (por ejemplo, sink-config.yaml):

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Abre el archivo sink-config.yaml en un editor de texto.

    3. Busca la sección exclusions: y elimina o modifica el filtro que da problemas.

    4. Actualiza el sumidero modificado:

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Para obtener más información sobre este comando, consulta la documentación de gcloud logging sinks update.

Investigar el almacenamiento en búfer y los retrasos de los registros de contenedores

Las aplicaciones y los sistemas operativos suelen usar el almacenamiento en búfer para escribir datos en fragmentos en lugar de línea por línea, lo que puede mejorar el rendimiento.

Síntomas:

  • Los registros de contenedores específicos aparecen en Cloud Logging solo después de que el contenedor se cierre o si hay un retraso significativo en la aparición de los registros.
  • A veces, los registros están incompletos.

Causa:

Este problema suele deberse al almacenamiento en búfer de los registros. Aunque la salida estándar (stdout) suele almacenarse en búfer de línea cuando se conecta a una terminal, este comportamiento cambia cuando la salida se canaliza. Si los registros o las secuencias de comandos de inicio de una aplicación en un contenedor dirigen stdout a otros comandos (por ejemplo, my-app | grep ...), es posible que la salida se almacene en búfer por completo. Por lo tanto, los registros se conservan hasta que el búfer se llena o se cierra la tubería. Este comportamiento puede provocar retrasos o pérdida de datos si el contenedor finaliza de forma inesperada. El almacenamiento en búfer interno de la aplicación también puede provocar retrasos.

Resolución:

Para solucionar el problema, prueba las siguientes soluciones:

  • Evita usar tuberías stdout: si es posible, modifica los puntos de entrada del contenedor o los comandos de la aplicación para escribir los registros directamente en stdout o stderr sin usar tuberías a través de otros comandos, como grep o sed, en el contenedor.
  • Asegúrate de que el búfer de línea esté activado:
    • Si no puedes evitar el uso de tuberías, utiliza herramientas que admitan el almacenamiento en búfer de líneas. Por ejemplo, usa grep --line-buffered.
    • En el caso de las aplicaciones personalizadas, asegúrate de que vacíen los registros con frecuencia, idealmente después de cada línea, cuando escriban en stdout. Muchas bibliotecas de registro tienen ajustes para controlar el almacenamiento en búfer.

  • Prueba el comportamiento de almacenamiento en búfer: implementa el siguiente manifiesto de Pod y observa los efectos en los registros mediante el comando kubectl logs -f buffered-pod. Experimenta comentando y descomentando las diferentes command matrices del manifiesto buffered-container:

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Investigar consultas del explorador de registros

Si estás seguro de que se están recogiendo los registros, pero no los encuentras, puede que el problema esté en la consulta de búsqueda o en el periodo.

Síntomas:

Los registros esperados no aparecen en los resultados de búsqueda, aunque sepas que la aplicación los está generando.

Causa:

Es posible que tu consulta en Explorador de registros tenga filtros (por ejemplo, en espacios de nombres, etiquetas, tipos de recursos o texto) que excluyan por error los registros que buscas.

Resolución:

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

    Ir a Explorador de registros

  2. Haz clic en Seleccionar periodo. Aunque creas que sabes cuándo se produjeron los registros, prueba con un intervalo mucho más amplio para descartar problemas de sincronización.

  3. Simplifica la consulta:

    1. Borrar todos los filtros.

    2. Prueba a filtrar solo por tu clúster:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Haz los cambios siguientes:

      • CLUSTER_NAME: el nombre de tu clúster.
      • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.

    3. Haz clic en Realizar una consulta.

  4. Si la consulta general funciona, vuelve a introducir los filtros originales uno a uno:

    • Tipo de recurso: asegúrese de usar el tipo de recurso correcto. Por ejemplo, ¿estás filtrando por k8s_container cuando deberías filtrar por k8s_node?
    • Etiquetas: comprueba que las etiquetas resource.labels, como namespace_name, container_name o las etiquetas personalizadas, estén bien escritas.
    • Gravedad: asegúrate de que el nivel de gravedad (por ejemplo,severity=ERROR) no sea demasiado restrictivo.
    • Carga útil de texto: comprueba si hay errores ortográficos y cadenas demasiado restrictivas en los términos de búsqueda. Por ejemplo, usa : para "contiene" en lugar de = para una concordancia exacta (jsonPayload.message:"error" en lugar de jsonPayload.message="error").

  5. Compruebe que los filtros tengan en cuenta las mayúsculas y minúsculas (el texto no suele distinguir entre ellas, pero las etiquetas sí), asegúrese de que los valores no tengan caracteres ocultos ni espacios adicionales y compruebe si los términos con caracteres especiales deben ir entre comillas.

  6. Consulta la cronología. Las bajadas repentinas al añadir un filtro pueden ayudarte a identificar la parte problemática de la consulta.

Para obtener más consejos sobre consultas de registro eficaces, consulta el artículo Buscar entradas de registro rápidamente de la documentación de Cloud Logging.

Si sigues sin encontrar los registros después de acotar la consulta, puede que el problema no sea la consulta, sino otro problema descrito en otras secciones de este documento.

Investigar el comportamiento de registro específico de una aplicación

El agente de registro de GKE solo recoge los registros escritos en los flujos stdout y stderr.

Síntomas:

No se ven los registros de un pod o un contenedor específicos en Cloud Logging, aunque haya otros registros del clúster.

Causa:

La aplicación no escribe en stdout ni en stderr. Puede que esté mal configurado para escribir registros en un archivo dentro del contenedor, donde el agente de registro no puede recogerlos.

Es posible que la aplicación también combine texto JSON y no JSON en su salida. El analizador del agente de registro espera un formato coherente (JSON o texto) de un solo flujo. Si una aplicación configurada para el registro JSON genera una línea de texto sin formato, puede interrumpir el analizador, lo que provoca que los registros se descarten o se ingieran incorrectamente.

Resolución:

  1. Determina el nombre del pod y el espacio de nombres de la aplicación cuyos registros faltan:

    kubectl get pods -n NAMESPACE_NAME

  2. Consulta los registros de contenedores:

    • Si el pod tiene un solo contenedor, ejecuta el siguiente comando:

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Haz los cambios siguientes:

      • POD_NAME: el nombre de tu Pod.
      • NAMESPACE_NAME: el espacio de nombres de tu pod.

    • Si el pod tiene varios contenedores, especifica el nombre del contenedor:

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Sustituye CONTAINER_NAME por el nombre del contenedor del pod.

    • Para monitorizar los registros en tiempo real, ejecuta el siguiente comando:

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Haz los cambios siguientes:

      • POD_NAME: el nombre de tu Pod.
      • CONTAINER_NAME: el nombre del contenedor del pod.
      • NAMESPACE_NAME: el espacio de nombres de tu pod.

  3. Analiza el resultado:

    • Si el comando kubectl logs no devuelve ningún resultado o si el resultado del comando no contiene los registros esperados, significa que el problema está en la propia aplicación. El comando kubectl logs lee directamente de los flujos stdout y stderr capturados por el tiempo de ejecución del contenedor. Si los registros no están aquí, el agente de registro de GKE no podrá verlos.

      Cambia el código o la configuración de tu aplicación para que deje de escribir en un archivo y, en su lugar, registre todos los mensajes directamente en stdout (para los registros normales) y stderr (para los registros de errores).

    • Si ves una combinación de cadenas JSON y líneas de texto sin formato, significa que hay un problema con el formato mixto. Configura tu aplicación para que solo escriba objetos JSON válidos de una sola línea en stdout y stderr.

    • Si el comando kubectl logs sí muestra los registros esperados, es probable que el problema se encuentre más abajo en la canalización de registro (por ejemplo, en el agente, los permisos o el servicio Cloud Logging).

Solucionar problemas de la plataforma y del servicio

En las siguientes secciones se explica cómo investigar problemas externos a tu configuración inmediata, como las políticas de conservación de registros, el estado de Cloud Logging o las versiones de GKE no compatibles.

Investigar los periodos de conservación de los registros

Los registros se almacenan en segmentos y cada segmento tiene un periodo de conservación que define cuánto tiempo se conservan sus registros antes de que se eliminen automáticamente.

Síntomas:

Faltan registros anteriores a una fecha determinada.

Causa:

Los registros que estás buscando son anteriores al periodo de conservación del cubo de registro al que se han enviado.

Resolución:

Para identificar y actualizar el periodo de conservación, selecciona una de las siguientes opciones:

Consola

  1. Identifica el bucket al que se envían tus registros de GKE:

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

      Ir al enrutador de registros

    2. Revisa la columna Destino, que muestra a dónde se dirigen los registros.

      El destino tiene un aspecto similar al siguiente:

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Consulta PROJECT_ID, LOCATION y BUCKET_ID.

      Los registros suelen dirigirse al contenedor _Default, pero también pueden dirigirse a otros contenedores si has configurado receptores personalizados.

  2. Comprueba el periodo de retención del segmento de registro:

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

      Ir a Almacenamiento de registros

    2. Busca los contenedores que coincidan con BUCKET_ID, LOCATION y PROJECT_ID en el destino del receptor.

    3. En cada uno de los segmentos pertinentes, consulta la columna Periodo de conservación.

    4. Si los registros que quieres ver son anteriores al periodo de conservación, Cloud Logging los habrá eliminado. Si necesitas un periodo de conservación más largo, haz lo siguiente:

      1. En el contenedor cuyo periodo de conservación quieras ampliar, haz clic en Más acciones.
      2. Selecciona Editar contenedor y actualiza el periodo de conservación. Ten en cuenta las posibles implicaciones económicas.

gcloud

  1. Identifica el bucket al que se envían tus registros de GKE:

    gcloud logging sinks list --project=PROJECT_ID

    Revisa el resultado. El campo destination de cada receptor muestra a dónde se dirigen los registros. El formato de destino de un contenedor de registro es el siguiente:

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Ten en cuenta PROJECT_ID, LOCATION y BUCKET_ID.

    Los registros suelen enrutarse al segmento _Default.

  2. Comprueba el periodo de retención del segmento de registro:

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    En el resultado, busca el campo retentionDays. Si los registros que necesitas son anteriores al valor indicado en retentionDays, Cloud Logging los habrá eliminado.

  3. Si necesitas un periodo de conservación más largo, actualízalo:

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Haz los cambios siguientes:

    • BUCKET_ID: el ID del segmento de registro.
    • LOCATION: la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del contenedor.
    • RETENTION_DAYS: número de días que se conservarán los registros. Ten en cuenta las posibles implicaciones económicas de aumentar el periodo de conservación.
    • PROJECT_ID: tu ID de proyecto Google Cloud .

Investigar problemas del servicio Cloud Logging y retrasos en la ingestión

En ocasiones, es posible que la propia canalización de registro tenga problemas, ya sea por una interrupción en todo el servicio o por un retraso temporal a gran escala en la ingesta.

Síntomas:

  • Pérdida de registros generalizada o intermitente en varios proyectos o clústeres.
  • Los registros tardan mucho en aparecer en el explorador de registros.

Causa:

  • Interrupción del servicio Cloud Logging: una interrupción poco frecuente en todo el servicio puede impedir la ingestión de registros, lo que provoca retrasos generalizados o la pérdida total de registros.
  • Volumen de registros alto: incluso sin que se produzca una interrupción oficial, un volumen de registros alto de tu proyecto o región puede sobrecargar temporalmente el servicio de ingesta, lo que provoca que los registros tarden en aparecer.

Resolución:

  • Comprueba el estado de los Google Cloud servicios en el Google Cloud panel de control Estado del servicio. Busca incidentes abiertos relacionados con Cloud Logging o GKE.

  • Ten en cuenta posibles retrasos en la ingesta. Si los registros no se ven inmediatamente y no hay incidentes activos, espera un tiempo para que se ingieran, sobre todo si el volumen de registros es alto. Vuelve a comprobarlo dentro de unos minutos.

Investigar la versión del clúster

GKE lanza periódicamente nuevas versiones que incluyen correcciones de errores y mejoras de rendimiento para los componentes, incluido el agente de registro.

Síntomas:

Los problemas de registro coinciden con las limitaciones de la versión del clúster.

Causa:

Es posible que el clúster esté ejecutando una versión de GKE antigua o no compatible que tenga problemas conocidos con el agente de registro o que carezca de determinadas funciones de registro.

Resolución:

Para solucionar este problema, sigue estos pasos:

  1. Comprueba la versión de tu clúster:

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • LOCATION: la región o la zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.

  2. Para comprobar si es una versión compatible, compárala con la programación de lanzamientos de GKE.

  3. Si el clúster usa una versión no compatible, actualízalo.

Siguientes pasos