Se usó la API de Cloud Translation para traducir esta página.

Soluciona problemas relacionados con la falta de registros en GKE

Autopilot estándar

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 supervisión y depuración.

Usa este documento para aprender a verificar configuraciones y permisos, resolver problemas de recursos y rendimiento, investigar filtros y el comportamiento de las aplicaciones, y abordar problemas de la plataforma o el servicio que afectan tus registros.

Esta información es importante para los administradores y operadores de la plataforma que mantienen la observabilidad del clúster, y para cualquier persona que use Cloud Logging para solucionar problemas de las 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 los usuarios de GKE.

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

Encuentra la solución según el síntoma

Si identificaste un síntoma específico relacionado con la falta de registros, usa la siguiente tabla para encontrar sugerencias para solucionar problemas:

Categoría	Síntoma o observación	Posible causa	Pasos para solucionar problemas
Configuration	No se ven los registros de ningún clúster del proyecto.	La API de Cloud Logging está inhabilitada para el proyecto.	Verifica el estado de la API de Cloud Logging
	Faltan registros de un clúster específico, o solo faltan ciertos tipos de registros.	El registro a nivel del clúster está inhabilitado para los tipos de registros requeridos.	Verifica la configuración del registro del clúster
	Faltan registros en los nodos de un grupo de nodos específico.	Los nodos del grupo de nodos no tienen el permiso de acceso requerido.	Verifica los permisos de acceso del grupo de nodos
	Aparecen errores de permiso (`401` o `403`) en los registros del agente de Logging.	A la cuenta de servicio del nodo le falta el permiso requerido.	Verifica los permisos de la cuenta de servicio del nodo
Recursos y rendimiento	Los registros faltan de forma intermitente o ves errores de `RESOURCE_EXHAUSTED`.	El proyecto está superando la cuota de escritura de la API de Cloud Logging.	Investiga el uso de la cuota de la API de Cloud Logging
Recursos y rendimiento	Faltan algunos registros de un nodo específico, a menudo durante períodos de carga o tráfico altos.	El nodo supera los límites de capacidad de procesamiento del agente de Logging o no tiene recursos (CPU o memoria) para procesar registros.	Investiga el rendimiento del nodo y el uso de recursos
Comportamiento de filtrado y aplicación	Faltan de forma constante registros específicos que coinciden con un patrón determinado.	Un filtro de exclusión de registros en Cloud Logging descarta los registros de forma involuntaria.	Investiga los filtros de exclusión de registros
	Los registros de un contenedor se retrasan significativamente o aparecen solo después de que el contenedor sale.	La salida de la aplicación se almacena en búfer por completo, a menudo debido a la canalización de `stdout`.	Investiga el almacenamiento en búfer y las demoras en los registros de contenedores
	Los registros esperados no aparecen en los resultados de la búsqueda.	Es posible que los filtros de consultas en el Explorador de registros sean demasiado restrictivos.	Investiga las consultas del Explorador de registros
	No se ven registros de un Pod de aplicación específico, pero sí hay otros registros del clúster.	La aplicación dentro del contenedor no escribe en `stdout` ni en `stderr`.	Investiga el comportamiento de registro específico de la aplicación
Plataforma y servicio	No aparecen los registros anteriores a una fecha determinada.	Los registros superaron su período de retención y Cloud Logging los borró.	Investiga los períodos de retención de registros
	Pérdida de registros o retrasos generalizados en proyectos o clústeres	Problema del servicio de Cloud Logging o retraso en la transferencia	Investiga los problemas y las demoras del servicio de Cloud Logging
	Los problemas de registro coinciden con las limitaciones de la versión del clúster.	La versión de GKE no es compatible.	Investiga la versión del clúster

Usa herramientas de diagnóstico automatizadas

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

Depura problemas de registro de GKE con `gcpdiag`

Si faltan registros o recibes registros incompletos de tu clúster de GKE, usa la herramienta gcpdiag para solucionar problemas.

gcpdiag es una herramienta de código abierto. No es un producto Google Cloud compatible oficialmente. Puedes usar la herramienta gcpdiag para identificar y corregir Google Cloudproblemas del proyecto. Para obtener más información, consulta el proyecto de gcpdiag en GitHub.

Cuando faltan registros del clúster de GKE o están incompletos, investiga las posibles causas enfocándote en los siguientes parámetros de configuración principales:

Registro a nivel del proyecto: Garantiza que el proyecto Google Cloud que aloja el clúster de GKE tenga habilitada la API de Cloud Logging.
Registro a nivel del clúster: Verifica que el registro esté habilitado de forma explícita 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 alcance Cloud Logging Write, lo que les permite enviar datos de registro.
Permisos de la cuenta de servicio: Valida que la cuenta de servicio que usan los grupos de nodos posea los permisos de IAM necesarios para interactuar con Cloud Logging. Específicamente, suele ser necesario el rol de roles/logging.logWriter.
Cuotas de escritura de la API de Cloud Logging: Verifica que no se hayan superado las cuotas de escritura de la API de Cloud Logging dentro del período especificado.

Consola deGoogle Cloud

Completa y, luego, copia el siguiente comando.

gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Abre la Google Cloud consola y activa Cloud Shell.

Abre la consola de Cloud

Pega el comando copiado.
Ejecuta el comando gcpdiag, que descarga la imagen de Docker gcpdiag y, luego, realiza verificaciones de diagnóstico. Si corresponde, sigue las instrucciones de salida para corregir las verificaciones que fallaron.

Docker

Puedes ejecutar gcpdiag con un wrapper que inicie gcpdiag en un contenedor de Docker. Se debe instalar Docker o Podman.

Copia y ejecuta el siguiente comando en tu estación de trabajo local.
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

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 para este runbook.

Reemplaza lo siguiente:

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

Marcas útiles:

--universe-domain: Si corresponde, el dominio de Trusted Partner Sovereign Cloud que aloja el recurso
--parameter o -p: Parámetros del runbook

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

Usa las investigaciones de Gemini Cloud Assist

Considera usar las investigaciones de Gemini Cloud Assist para obtener estadísticas adicionales 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 Soluciona problemas con las investigaciones de Gemini Cloud Assist en la documentación de Gemini.

Verifica la configuración y los permisos de registro

Los parámetros de configuración incorrectos son un motivo común por el que faltan registros de GKE. Usa las siguientes secciones para verificar tu configuración de Cloud Logging.

Verifica el estado de la API de Cloud Logging

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

Síntomas:

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

Causa:

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

Solución:

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

Console

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

Ir a APIs y servicios habilitados
En el campo Filter, escribe Cloud Logging API y presiona Intro.
Si la API está habilitada, la verás 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 Search, escribe Cloud Logging API y presiona Intro.
3. Haz clic en el resultado API de Cloud Logging.
4. Haz clic en Habilitar.

gcloud

Verifica si la API está habilitada:

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

El resultado debería ser el siguiente:

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

Si la API no aparece en la lista de servicios habilitados, habilítala:
```
gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID
```
Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud.

Verifica la configuración del registro del clúster

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

Síntomas:

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

Causa:

El registro a nivel del clúster está inhabilitado para los tipos de registros requeridos. Si usas un clúster de Autopilot, este no es el motivo de tus problemas de registro. Este parámetro de configuración se puede establecer para los clústeres de Standard, pero siempre está habilitado de forma predeterminada en los clústeres de Autopilot y no se puede inhabilitar.

Solución:

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

Console

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

Ir a clústeres de Kubernetes
Haz clic en el nombre del clúster que deseas investigar.
Haz clic en la pestaña Detalles y navega a la sección Funciones.
En la fila Logging, revisa qué tipos de registros, como System o Workloads, están habilitados.
Si los tipos de registros que deseas recopilar están inhabilitados o son incorrectos, haz clic en Editar registro.
En la lista Components, selecciona las casillas de verificación de los tipos de registros que deseas recopilar y haz clic en OK. Para obtener más información sobre los tipos de registros disponibles, consulta Acerca de los registros de GKE.
Haz clic en Guardar cambios.

gcloud

Para verificar 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)"
```
Reemplaza lo siguiente:
- CLUSTER_NAME: El nombre de tu clúster.
- LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.
- PROJECT_ID: El ID de tu proyecto Google Cloud .
Si el registro está habilitado, el resultado es similar al siguiente:
```
example-cluster    SYSTEM_COMPONENTS;WORKLOADS
```
Si el resultado es NONE, significa que el registro está inhabilitado.
Si los tipos de registro que deseas 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
```
Reemplaza LOGGING_TYPE por SYSTEM, WORKLOAD o ambos. Para recopilar registros, se debe habilitar SYSTEM. Los registros de WORKLOAD no se pueden recopilar por sí solos. Para obtener más información sobre los tipos de registros disponibles, consulta Acerca de los registros de GKE.

Verifica 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 las APIs de Google Cloud , incluida la de Cloud Logging.

Síntomas:

Faltan registros en 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. Se requiere uno de los siguientes permisos para que los nodos escriban registros en Cloud Logging:

https://www.googleapis.com/auth/logging.write: Otorga permiso para escribir registros. Este es el alcance mínimo requerido.
https://www.googleapis.com/auth/logging.admin: Otorga acceso completo a la API de Cloud Logging, que incluye los permisos de logging.write.
https://www.googleapis.com/auth/cloud-platform: Otorga acceso completo a todas las APIs de Google Cloud habilitadas, lo que incluye los permisos de logging.write.

Solución:

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

Console

Verifica los permisos de acceso del grupo de nodos:
1. En la consola de Google Cloud , ve a la página de 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 deseas 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 deseas investigar.
5. Navega a la sección Seguridad.
6. Revisa los permisos que se indican en el campo Permisos de acceso. Asegúrate de que esté presente al menos uno de los permisos obligatorios:
  - API de Stackdriver Logging (solo escritura)
  - API de Stackdriver Logging - Full
  - Cloud Platform - Habilitado
  Si faltan los permisos requeridos, vuelve a crear el grupo de nodos. No puedes cambiar los permisos de acceso en un grupo de nodos existente.
Si es necesario, crea un grupo de nodos nuevo con el permiso requerido:
1. Vuelve a la página de detalles del clúster que deseas modificar.
2. Haz clic en la pestaña Nodos.
3. Haz clic en Crear grupo de nodos administrado por el usuario.
4. Completa la sección Detalles del grupo de nodos.
5. En la barra de navegación de la izquierda, haz clic en Seguridad.
6. En la sección Alcances de acceso, selecciona los roles que deseas agregar:
  - Para agregar permisos específicos, selecciona Configurar acceso para cada API.
  - Para permitir el acceso total, selecciona Permitir el acceso total a todas las APIs de Cloud.
7. Configura cualquier otra sección según sea necesario.
8. Haz clic en Crear.
Migra tus cargas de trabajo al grupo de nodos nuevo. Después de migrar las cargas de trabajo al nuevo grupo de nodos, tus aplicaciones se ejecutarán en nodos que tienen los permisos necesarios para enviar registros a Cloud Logging.
Borra el grupo de nodos anterior:
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 anterior.
3. Junto al grupo de nodos, haz clic en Borrar .
4. Cuando se te solicite, confirma la eliminación escribiendo el nombre del grupo de nodos y haz clic en Borrar.

gcloud

Verifica los permisos de acceso del grupo de nodos:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"
```
Reemplaza lo siguiente:
- CLUSTER_NAME: El nombre de tu clúster.
- LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.
- PROJECT_ID: El ID de tu proyecto Google Cloud .
Revisa el resultado de cada grupo de nodos. Asegúrate de que se muestre al menos uno de los alcances 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 alcances requeridos, vuelve a crear el grupo de nodos. No puedes cambiar los permisos de acceso en un grupo de nodos existente.
Si es necesario, crea un grupo de nodos nuevo con el permiso 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
```
Reemplaza lo siguiente:
- NEW_NODE_POOL_NAME: Es el nombre del grupo de nodos nuevo.
- OTHER_SCOPES: Es una lista separada por comas de cualquier otro alcance que requieran tus nodos. Si no necesitas otros permisos, omite este marcador de posición y la coma anterior.
Migra tus cargas de trabajo al grupo de nodos nuevo. Después de migrar las cargas de trabajo al nuevo grupo de nodos, tus aplicaciones se ejecutarán en nodos que tienen los permisos necesarios para enviar registros a Cloud Logging.

Borra el grupo de nodos anterior:

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

Verifica los permisos de la cuenta de servicio del nodo

Los nodos usan una cuenta de servicio para autenticarse con los servicios de Google Cloud , y esta cuenta necesita permisos específicos de IAM para escribir registros.

Síntomas:

Faltan registros en los nodos.
La inspección de los registros del agente de registro (por ejemplo, Fluent Bit) puede mostrar errores relacionados con los permisos, como los códigos 401 o 403 cuando se intenta escribir en Cloud Logging.
Es posible que veas una notificación de Grant Critical Permissions to Node Service Account para el clúster en la consola de Google Cloud .

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, para 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 que GKE administre los recursos y las operaciones de los nodos, incluidos los componentes de registro.

Solución:

Para verificar los permisos y otorgar 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 requerido.

Verifica el permiso de la cuenta de servicio del nodo

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

Para identificar la cuenta de servicio que usa el grupo de nodos, selecciona una de las siguientes opciones:
Console
1. En la consola de Google Cloud , ve a la página de clústeres de Kubernetes.
  
  Ir a clústeres de Kubernetes
2. En la lista de clústeres, haz clic en el nombre del clúster que deseas inspeccionar.
3. Según el modo de operación del clúster, realiza una de las siguientes acciones:
  - Para los clústeres de Standard, haz lo siguiente:
    
    Haz clic en la pestaña Nodos.
    
    En la tabla Grupos de nodos, haz clic en el nombre de un grupo de nodos. Se abrirá la página Detalles del grupo de nodos.
    
    En la sección Seguridad, busca el campo Cuenta de servicio.
  - Para los clústeres de Autopilot, haz lo siguiente:
    
    Ve a la pestaña Detalles.
    
    En la sección Seguridad, busca el campo Cuenta de servicio.
  Si el valor en el 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 otorgar el rol requerido a una cuenta de servicio personalizada, consulta Usa cuentas de servicio de IAM privilegio mínimo mínimos.
gcloud
Ejecuta el siguiente comando según el tipo de clúster que uses:
Clústeres estándar
gcloud container node-pools describe NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --project=PROJECT_ID \ --format="value(config.serviceAccount)"

Reemplaza lo siguiente:

NODE_POOL_NAME: Es el nombre del grupo de nodos.

CLUSTER_NAME: Es el nombre de tu clúster estándar.

LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.

PROJECT_ID: Es el ID del proyecto 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 otorgar el rol requerido a una cuenta de servicio personalizada, consulta Usa cuentas de servicio de IAM privilegio mínimo mínimos.
Clústeres de Autopilot
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --project=PROJECT_ID \ --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre de tu clúster de Autopilot.

LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.

PROJECT_ID: El ID de tu 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 otorgar el rol requerido a una cuenta de servicio personalizada, consulta Usa cuentas de servicio de IAM privilegio mínimo mínimos.
Para obtener secuencias de comandos más detalladas para identificar los permisos faltantes, consulta Cómo identificar todas las cuentas de servicio de nodos con permisos faltantes.
GKE analiza automáticamente los permisos faltantes y proporciona recomendaciones. Para usar las recomendaciones y verificar si faltan permisos, selecciona una de las siguientes opciones:
Console
1. En la página Clústeres de Kubernetes, busca la columna Notificaciones.
2. Revisa la columna Notificaciones para ver la recomendación Otorga permisos críticos. Esta recomendación significa que falló la verificación de NODE_SA_MISSING_PERMISSIONS.
3. Si aparece la recomendación, haz clic en ella. Se abrirá un panel de detalles en el que se explican los permisos faltantes y se indican los pasos para corregir el problema.
gcloud
1. Sigue estos pasos para ver las recomendaciones sobre los permisos faltantes de la cuenta de servicio:
  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 encontró ninguna recomendación NODE_SA_MISSING_PERMISSIONS activa. Las cuentas de servicio que verificó parecen tener los permisos necesarios.
  - Si el comando devuelve uno o más bloques YAML, significa que el recomendador identificó un problema de permisos. Revisa el resultado para ver los siguientes campos clave:
    
    description: Proporciona un resumen del problema, como especificar que a la cuenta de servicio del 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 otorgar el rol específico faltante.
El recomendador puede tardar hasta 24 horas en reflejar los cambios recientes.
Si deseas verificar los permisos de inmediato, para comprobar los permisos y otorgar el rol, selecciona una de las siguientes opciones:
Console
1. En la consola de Google Cloud , dirígete a la página IAM.
  
  Ir a IAM
2. Busca la cuenta de servicio que usa el grupo de nodos.
3. En la columna Rol, verifica si la cuenta de servicio tiene el rol de escritor de registros (roles/logging.logWriter).
4. Si falta el permiso, agrégalo:
  1. Haz clic en Editar principal.
  2. Haz clic en Agregar otra función.
  3. En el campo de búsqueda, ingresa Logs Writer.
  4. Selecciona la casilla de verificación Escritor de registros y haz clic en Aplicar.
  5. Haz clic en Guardar.
gcloud
1. Verifica 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, otorga el rol logging.logWriter:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role="roles/logging.logWriter"

Verifica los permisos del agente de servicio de GKE

Si los registros siguen faltando y usas la versión 1.33 o una posterior, verifica que el agente administrado por Google que GKE usa para administrar los componentes de tu nodo tenga el permiso requerido:

Para identificar la dirección de correo electrónico del agente de servicio, obtén el número de tu proyecto:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
Reemplaza PROJECT_ID por el ID del proyecto. Observa el resultado.

El correo electrónico del agente de servicio de GKE es el siguiente: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com
Para usar las recomendaciones y verificar si faltan permisos, selecciona una de las siguientes opciones:
Console
1. En la página Clústeres de Kubernetes, busca la columna Notificaciones.
2. Consulta la columna para ver la recomendación Otorga permisos esenciales.
3. Si aparece la recomendación, haz clic en ella. Se abrirá un panel de detalles en el que se explican los permisos faltantes y se indican los pasos para corregir el problema.
gcloud
1. Sigue estos pasos para ver las recomendaciones sobre los permisos faltantes de la cuenta de servicio:
  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 al agente de servicio de GKE (gcp-sa-gkenode) le falta el rol roles/container.defaultNodeServiceAgent.
Para verificar los permisos de inmediato y otorgar el rol, selecciona una de las siguientes opciones:
Console
1. En la consola de Google Cloud , dirígete a la página IAM.
  
  Ir a IAM
2. En el campo Filtro, escribe la dirección de correo electrónico del agente de servicio de GKE y presiona Intro.
3. En la lista filtrada, verifica si el agente de servicio tiene al menos el rol de agente de servicio de nodo predeterminado de Kubernetes (roles/container.defaultNodeServiceAgent).
4. Si falta el rol, otórgale acceso:
  1. Haz clic en Editar principal junto al agente de servicio.
  2. Haz clic en Agregar roles.
  3. En el campo de búsqueda, ingresa Kubernetes Default Node Service Agent y selecciona el rol.
  4. Haz clic en Guardar.
gcloud
1. Verifica 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, otorga el rol de 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"

Soluciona problemas de rendimiento y recursos

Si los registros faltan de forma intermitente o se descartan de los nodos de tráfico alto, es posible que la causa no sea un error de configuración, sino un problema de rendimiento. Usa las siguientes secciones para investigar si tu proyecto supera las cuotas de la API o si el gran volumen de registros sobrecarga los agentes en nodos específicos.

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

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

Síntomas:

Los registros faltan de forma intermitente o por completo.
Ves errores de RESOURCE_EXHAUSTED relacionados con logging.googleapis.com en los registros del agente de nodos o de registro.

Causa:

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

Solución:

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

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

Ir a Cuotas
En el campo Filter, escribe Cloud Logging API y presiona Intro.
En la lista filtrada, busca la cuota de Bytes de escritura de registros por minuto y por región para la región en la que se encuentra tu clúster.
Revisa los valores de la columna Porcentaje de uso actual. Si el uso está cerca del límite o lo alcanzó, es probable que hayas excedido la cuota.
Para solicitar un aumento, haz clic en Editar cuota y sigue las indicaciones. Para obtener más información, consulta Visualiza y administra las cuotas.

Para reducir el uso, considera 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.

Investiga el uso de recursos y la capacidad de procesamiento de los nodos

El agente de Logging de GKE en cada nodo tiene su propio límite de procesamiento, que se puede superar.

Síntomas:

Los registros de nodos específicos faltan o se retrasan de forma intermitente, en especial durante períodos de alta actividad del clúster o uso intensivo de los recursos del nodo.

Causa:

El agente de Logging de GKE tiene un límite de capacidad de procesamiento 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 descarte registros, incluso si no se supera la cuota general de la API del proyecto. Puedes supervisar el rendimiento del registro de nodos con la métrica kubernetes.io/node/logs/input_bytes en el Explorador de métricas.

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

Solució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 Cómo ajustar la agente de Logging de Cloud Logging.
Reduce el volumen de registros: Analiza los patrones de registro de la aplicación. Reduce el registro innecesario o demasiado detallado.
Implementa un agente de registro personalizado: Puedes implementar y administrar tu propio DaemonSet de Fluent Bit personalizado, pero serás responsable de su configuración y mantenimiento.
Verifica el uso de recursos del nodo: Incluso si el volumen de registros está dentro de los límites, asegúrate de que los nodos no estén bajo una gran presión de CPU o memoria. Los recursos de nodos insuficientes pueden obstaculizar 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 el 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 demasiado detallado. Asegúrate de que los registros estén estructurados siempre que sea posible, ya que este tipo de registros pueden ayudar con el procesamiento eficiente. Excluye los registros que no sean esenciales.
Optimiza el rendimiento de las aplicaciones: Dado que los recursos de los nodos se administran en los clústeres de Autopilot, asegúrate de que tus aplicaciones no consuman CPU o memoria en exceso, lo que podría afectar indirectamente el rendimiento de los componentes del nodo, como el agente de registro. Si bien no administras los nodos directamente, la eficiencia de la aplicación afecta el estado general de los nodos.

Soluciona problemas de filtrado y de la aplicación

Cuando 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 exploran problemas como los filtros de exclusión de registros, el almacenamiento en búfer a nivel del contenedor, las búsquedas restrictivas y las aplicaciones que no escriben en stdout ni en stderr.

Investiga los filtros de exclusión de registros

El Explorador de registros solo muestra los registros que coinciden con todos los filtros de tu consulta y el período seleccionado.

Síntomas:

Faltan registros específicos que coinciden con ciertos criterios en Cloud Logging, pero hay otros registros de las mismas fuentes.

Causa:

Los filtros de exclusión de registros se definen en tus receptores de Cloud Logging (a menudo, el receptor _Default). Estas reglas descartan de forma silenciosa los registros que coinciden con criterios específicos, incluso si el nodo los envió correctamente.

Solución:

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

Console

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

Ir a Enrutador de registros
Identifica el filtro problemático:
1. En cada receptor (excepto 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 búsquedas en la sección Filtros de exclusión. Compara la lógica del filtro con los atributos de los registros faltantes (por ejemplo, tipo de recurso, etiquetas o palabras clave).
3. Copia la consulta del filtro de exclusión.
4. Ir a la página Explorador de registros.
  
  Ir al Explorador de registros
5. Pega la consulta del filtro de exclusión en el panel de consultas y haz 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 este filtro sea la causa.
Inhabilita o edita el filtro:
1. Regresa a la página Enrutador de registros.
2. Haz clic en Más acciones para el receptor con el filtro sospechoso y selecciona Editar receptor.
3. Busca la sección Elige registros para filtrar fuera del receptor y encuentra 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

Enumera todos los receptores del proyecto:

gcloud logging sinks list --project=PROJECT_ID

Sigue estos pasos para ver los filtros de exclusión de cada receptor:
```
gcloud logging sinks describe SINK_NAME --project=PROJECT_ID
```
En el resultado, revisa la sección exclusions. Compara la lógica del filtro con los atributos de los registros faltantes (por ejemplo, tipo de recurso, etiquetas o palabras clave).
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 quita o modifica el filtro problemático.
4. Actualiza el receptor 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.

Investiga el almacenamiento en búfer y las demoras 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 sale o hay una demora significativa 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 registros. Si bien la salida estándar (stdout) suele almacenarse en búfer de líneas 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 dentro de una canalización de contenedores stdout a otros comandos (por ejemplo, my-app | grep ...), es posible que la salida se almacene en búfer por completo. Como resultado, los registros se retienen hasta que el búfer se llena o se cierra la canalización. Este comportamiento puede causar 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 causar demoras.

Solución:

Para resolver el problema, prueba las siguientes soluciones:

Evita canalizar stdout: Si es posible, modifica los puntos de entrada del contenedor o los comandos de la aplicación para escribir registros directamente en stdout o stderr sin canalizar a través de otros comandos como grep o sed dentro del contenedor.
Asegúrate de que el búfer de líneas sea suficiente:
- Si no se puede evitar la canalización, usa 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 parámetros de configuración para controlar el almacenamiento en búfer.

Comportamiento del búfer de prueba: Implementa el siguiente manifiesto del Pod y observa los efectos en los registros con el comando kubectl logs -f buffered-pod. Experimenta comentando y quitando los comentarios de los diferentes arrays de command en el manifiesto de 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

Investiga las consultas del Explorador de registros

Si tienes la certeza de que se recopilan tus registros, pero no los encuentras, es posible que el problema se deba a tu búsqueda o al período.

Síntomas:

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

Causa:

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

Solución:

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

Ir al Explorador de registros
Haz clic en Seleccionar período. Incluso si crees que sabes cuándo se produjeron los registros, prueba con un rango mucho más amplio para descartar problemas de sincronización.
Simplifica la búsqueda:
1. Borra todos los filtros.
2. Intenta filtrar solo por tu clúster:
```
resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
```
  Reemplaza lo siguiente:
  - CLUSTER_NAME: El nombre de tu clúster.
  - LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del clúster.
3. Haz clic en Ejecutar consulta.
Si la búsqueda amplia funciona, vuelve a introducir los filtros originales de a uno:
- Tipo de recurso: Asegúrate de usar el tipo de recurso correcto. Por ejemplo, ¿filtras por k8s_container cuando deberías filtrar por k8s_node?
- Etiquetas: Verifica la ortografía de resource.labels, como namespace_name, container_name o etiquetas personalizadas.
- Gravedad: Asegúrate de que el nivel de gravedad (por ejemplo, severity=ERROR) no sea demasiado restrictivo.
- Carga útil de texto: Verifica 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 coincidencia exacta (jsonPayload.message:"error" en lugar de jsonPayload.message="error").
Verifica que tus filtros tengan en cuenta la distinción entre mayúsculas y minúsculas (el texto suele no distinguir entre mayúsculas y minúsculas, pero las etiquetas podrían hacerlo), asegúrate de que los valores no tengan caracteres ocultos ni espacios adicionales, y comprueba si los términos con caracteres especiales deben estar entre comillas.
Revisa la Línea de tiempo. Las disminuciones repentinas cuando se agrega un filtro pueden ayudarte a identificar la parte problemática de la consulta.

Para obtener más sugerencias sobre consultas de registros eficaces, consulta Cómo encontrar entradas de registro rápidamente en la documentación de Cloud Logging.

Si aún no encuentras los registros después de definir mejor tu búsqueda, es posible que el problema no sea la búsqueda, sino uno de los problemas que se describen en otras secciones de este documento.

Investiga el comportamiento de registro específico de la aplicación

El agente de Logging de GKE solo recopila los registros escritos en los flujos stdout y stderr.

Síntomas:

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

Causa:

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

Es posible que la aplicación también combine texto en formato JSON y texto que no esté en formato 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 se descarten los registros o se ingieran de forma incorrecta.

Solución:

Determina el nombre del Pod y el espacio de nombres de la aplicación cuyos registros faltan:
```
kubectl get pods -n NAMESPACE_NAME
```
Verifica los registros del contenedor:
- Si el Pod tiene un solo contenedor, ejecuta el siguiente comando:
```
kubectl logs POD_NAME \
    -n NAMESPACE_NAME
```
  Reemplaza lo siguiente:
  - POD_NAME: es el nombre del Pod.
  - NAMESPACE_NAME: es el espacio de nombres del Pod.
- Si el Pod tiene varios contenedores, especifica el nombre del contenedor:
```
kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME
```
  Reemplaza CONTAINER_NAME por el nombre del contenedor dentro del Pod.
- Para seguir los registros en tiempo real, ejecuta el siguiente comando:
```
kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME
```
  Reemplaza lo siguiente:
  - POD_NAME: es el nombre del Pod.
  - CONTAINER_NAME: Es el nombre del contenedor dentro del Pod.
  - NAMESPACE_NAME: es el espacio de nombres del Pod.
Analiza el resultado:
- Si el comando kubectl logs no tiene salida o si la salida del comando no contiene los registros esperados, el problema está en la aplicación en sí. El comando kubectl logs lee directamente de los flujos stdout y stderr capturados por el tiempo de ejecución del contenedor. Si no hay registros aquí, el agente de registro de GKE no puede verlos.
  
  Cambia el código o la configuración de tu aplicación para dejar de escribir en un archivo y, en su lugar, registra 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, este resultado indica un problema de 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 muestra los registros esperados, es probable que el problema se encuentre más abajo en la canalización de registros (por ejemplo, en el agente, los permisos o el servicio de Cloud Logging).

Soluciona problemas de plataformas y servicios

En las siguientes secciones, se te ayudará a investigar problemas externos a tu configuración inmediata, como las políticas de retención de registros, el estado de Cloud Logging o las versiones de GKE no compatibles.

Investiga los períodos de retención de registros

Los registros se almacenan en buckets, y cada bucket tiene un período de retención que define cuánto tiempo se conservan sus registros antes de que se borren automáticamente.

Síntomas:

Faltan registros anteriores a una fecha determinada.

Causa:

Los registros que buscas son anteriores al período de retención del bucket de registros al que se redireccionaron.

Solución:

Para identificar y actualizar el período de retención, selecciona una de las siguientes opciones:

Console

Identifica el bucket al que se enrutan tus registros de GKE:
1. En la consola de Google Cloud , ve a la página Enrutador de registros.
  
  Ir a Enrutador de registros
2. Revisa la columna Destino, que muestra a dónde se enrutan los registros.
  
  El destino es similar al siguiente:
```
logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
```
  Observa PROJECT_ID, LOCATION y BUCKET_ID.
  
  Los registros suelen enrutarse al bucket _Default, pero también pueden enrutarse a otros buckets si tienes registros personalizados configurados.
Verifica el período de retención del bucket de registros:
1. En la consola de Google Cloud , ve a la página Almacenamiento de registros.
  
  Ir a Almacenamiento de registros
2. Busca los buckets que coincidan con BUCKET_ID, LOCATION y PROJECT_ID del destino del receptor.
3. Para cada bucket pertinente, consulta la columna Período de retención.
4. Si los registros que deseas ver son anteriores al período de retención, Cloud Logging los borró. Si necesitas un período de retención más largo, haz lo siguiente:
  1. En el bucket cuyo período de retención deseas extender, haz clic en Más acciones.
  2. Selecciona Editar bucket y actualiza el período de retención. Ten en cuenta las posibles implicaciones de costos.

gcloud

Identifica el bucket al que se enrutan tus registros de GKE:
```
gcloud logging sinks list --project=PROJECT_ID
```
Revise el resultado. El campo destination de cada receptor muestra dónde se enrutan los registros. El formato de destino para un bucket de registros es el siguiente:
```
logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
```
Observa PROJECT_ID, LOCATION y BUCKET_ID.

Los registros suelen enrutarse al bucket _Default.
Verifica el período de retención del bucket de registros:
```
gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID
```
En el resultado, busca el campo retentionDays. Si los registros que necesitas son más antiguos que el valor que se indica para retentionDays, Cloud Logging los borró.
Si necesitas un período de retención más largo, actualízalo:
```
gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID
```
Reemplaza lo siguiente:
- BUCKET_ID: Es el ID del bucket de registros.
- LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) del bucket.
- RETENTION_DAYS: Es la cantidad de días que se retendrán los registros. Ten en cuenta las posibles implicaciones de costos de aumentar el período de retención.
- PROJECT_ID: El ID de tu proyecto Google Cloud .

Investiga problemas del servicio de Cloud Logging y retrasos en la transferencia

A veces, la propia canalización de registro puede experimentar problemas, ya sea por una interrupción en todo el servicio o por una demora temporal a gran escala en la transferencia de datos.

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 de Cloud Logging: Una interrupción poco frecuente en todo el servicio puede impedir la transferencia de registros, lo que provoca demoras generalizadas o la pérdida total de registros.
Volumen de registros alto: Incluso sin una interrupción oficial, el volumen de registros alto de tu proyecto o región puede sobrecargar temporalmente el servicio de transferencia, lo que provoca que los registros tarden en aparecer.

Solución:

Visita el Google Cloudpanel de estado del servicio para verificar el Service Health de Google Cloud . Busca incidentes abiertos relacionados con Cloud Logging o GKE.
Ten en cuenta las posibles demoras en la transferencia. Si los registros no se ven de inmediato y no hay incidentes activos, espera un tiempo para que se ingieran, en especial si el volumen de registros es alto. Vuelve a intentarlo en unos minutos.

Investiga la versión del clúster

GKE lanza nuevas versiones periódicamente 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 ejecute una versión anterior o no compatible de GKE que tenga problemas conocidos con el agente de Logging o que carezca de ciertas funciones de Logging.

Solución:

Para solucionar este problema, haz lo siguiente:

Verifica la versión de tu clúster:
```
gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"
```
Reemplaza lo siguiente:
- CLUSTER_NAME: El nombre de tu clúster.
- LOCATION: Es la región o zona de Compute Engine (por ejemplo, us-central1 o us-central1-a) para el clúster.
Para asegurarte de que sea una versión compatible, compárala con el Programa de lanzamientos de GKE.
Si el clúster usa una versión no compatible, actualízalo.

¿Qué sigue?

Si no encuentras una solución a tu problema en la documentación, consulta Obtener asistencia para obtener más ayuda, como asesoramiento en los siguientes temas:
- Comunicarse con Atención al cliente de Cloud para abrir un caso de asistencia.
- Hacer preguntas en StackOverflow para obtener asistencia de la comunidad y usar la etiqueta google-kubernetes-engine para buscar problemas similares. También puedes unirte al canal de Slack #kubernetes-engine para obtener más Asistencia de la comunidad.
- Abrir errores o solicitudes de funciones con la herramienta de seguimiento de errores pública.

Soluciona problemas relacionados con la falta de registros en GKE Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Encuentra la solución según el síntoma

Usa herramientas de diagnóstico automatizadas

Depura problemas de registro de GKE con gcpdiag

Consola deGoogle Cloud

Docker

Usa las investigaciones de Gemini Cloud Assist

Verifica la configuración y los permisos de registro

Verifica el estado de la API de Cloud Logging

Console

gcloud

Verifica la configuración del registro del clúster

Console

gcloud

Verifica los permisos de acceso del grupo de nodos

Console

gcloud

Verifica los permisos de la cuenta de servicio del nodo

Verifica el permiso de la cuenta de servicio del nodo

Console

gcloud

Clústeres estándar

Clústeres de Autopilot

Console

gcloud

Console

gcloud

Verifica los permisos del agente de servicio de GKE

Console

gcloud

Console

gcloud

Soluciona problemas de rendimiento y recursos

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

Investiga el uso de recursos y la capacidad de procesamiento de los nodos

Clústeres estándar

Clústeres de Autopilot

Soluciona problemas de filtrado y de la aplicación

Investiga los filtros de exclusión de registros

Console

gcloud

Investiga el almacenamiento en búfer y las demoras de los registros de contenedores

Investiga las consultas del Explorador de registros

Investiga el comportamiento de registro específico de la aplicación

Soluciona problemas de plataformas y servicios

Investiga los períodos de retención de registros

Console

gcloud

Investiga problemas del servicio de Cloud Logging y retrasos en la transferencia

Investiga la versión del clúster

¿Qué sigue?

Soluciona problemas relacionados con la falta de registros en GKE

Depura problemas de registro de GKE con `gcpdiag`