Solución de problemas de observabilidad

En este documento, se proporcionan procedimientos de solución de problemas y descripciones de referencia de las alertas del sistema predefinidas para ayudarte a identificar fallas de implementación y resolver incidentes operativos con componentes de registro y supervisión en el dispositivo de Google Distributed Cloud (GDC) aislado. Puedes usar estos procedimientos y definiciones de alertas para verificar que las pilas de registro y supervisión se estén ejecutando, inspeccionar las configuraciones de canalización y solucionar problemas de componentes.

Identificar los componentes de Observability

La plataforma de observabilidad implementa sus componentes en el espacio de nombres obs-system en el clúster de infraestructura de la organización.

La instancia de Grafana del operador de infraestructura (IO) proporciona acceso a las métricas a nivel de la organización para supervisar los componentes de la infraestructura, como el uso de CPU y el consumo de almacenamiento. También proporciona acceso a los registros operativos y de auditoría. Además, brinda acceso a alertas, registros y métricas de los componentes operables de GDC.

Las pilas de supervisión y registro de GDC usan soluciones de código abierto como parte de la plataforma de observabilidad. Estos componentes recopilan registros y métricas de los pods de Kubernetes, las máquinas de equipos físicos, los switches de red, el almacenamiento y los servicios administrados.

En la siguiente tabla, se incluye una descripción de todos los componentes que integran la plataforma de observabilidad:

Componente	Descripción
Prometheus	Prometheus es una base de datos de series temporales para recopilar y almacenar métricas, y evaluar alertas. Prometheus almacena las métricas en la instancia de Cortex del clúster de infraestructura de la organización para el almacenamiento a largo plazo. Prometheus agrega etiquetas como pares clave-valor y recopila métricas de los nodos de Kubernetes, los Pods, las máquinas de equipos físicos, los switches de red y los dispositivos de almacenamiento.
Alertmanager	Alertmanager es un sistema de administración definido por el usuario que envía alertas cuando los registros o las métricas indican que los componentes del sistema fallan o no funcionan con normalidad. Administra el enrutamiento, el silenciamiento y la agregación de las alertas de Prometheus.
Loki	Loki es una base de datos de series temporales que almacena y agrega registros de varias fuentes. Indexa los registros para realizar consultas eficientes.
Grafana	Grafana proporciona una interfaz de usuario (IU) para ver las métricas que recopila Prometheus y consultar los registros de auditoría y operativos de las instancias de Loki correspondientes. La IU te permite visualizar paneles de métricas y alertas.
Fluent Bit	Fluent Bit es un procesador que extrae registros de varios componentes o ubicaciones y los envía a Loki. Se ejecuta en cada nodo de todos los clústeres.

Identifica fallas de implementación

Si tu implementación se está ejecutando y está en buen estado, los componentes se ejecutan en el estado READY.

Sigue estos pasos para identificar las fallas de implementación:

1. Confirma el estado actual de un componente:

   kubectl get -n obs-system TYPE/COMPONENT
   

   Reemplaza lo siguiente:

   • TYPE: el tipo de componente
   • COMPONENT: Es el nombre del componente.

   Obtendrás un resultado similar al siguiente:

   NAME       READY  AGE
   COMPONENT  1/1    23h
   

   Si el componente está en buen estado, la columna READY del resultado muestra N/N como un valor. Si la columna READY no muestra un valor, no necesariamente indica un error. Es posible que el servicio necesite más tiempo para procesar la solicitud.

2. Verifica los Pods en cada componente:

   kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
   

   Reemplaza COMPONENT por el nombre del componente.

   Obtendrás un resultado similar al siguiente:

   NAME       READY  STATUS   RESTARTS  AGE
   COMPONENT  1/1    Running  0         23h
   

   Verifica que la columna READY muestre N/N como un valor, que la columna STATUS muestre un valor Running y que la cantidad de RESTARTS no supere un valor de 2.

   Una gran cantidad de reinicios indica los siguientes síntomas:

   • Los Pods fallan y Kubernetes los reinicia.
   • La columna STATUS muestra el valor CrashLoopBackoff.

   Para resolver el estado de error, consulta los registros de los Pods.

   Si un Pod está en estado PENDING, este estado indica uno o más de los siguientes síntomas:

   • El Pod está esperando el acceso a la red para descargar el contenedor necesario.
   • Un problema de configuración impide que se inicie el Pod. Por ejemplo, falta un valor Secret que requiere el Pod.
   • Tu clúster de Kubernetes se quedó sin recursos para programar el Pod, lo que ocurre si se ejecutan muchas aplicaciones en el clúster.

3. Determina la causa de un estado PENDING:

   kubectl describe -n obs-system pod/POD_NAME
   

   Reemplaza POD_NAME por el nombre del Pod que muestra el estado PENDING.

   En el resultado, se muestran más detalles sobre el Pod.

4. Navega a la sección Events del resultado para ver una tabla con los eventos recientes del Pod y un resumen de la causa del estado PENDING.

   En el siguiente resultado, se muestra una sección Events de ejemplo para un objeto StatefulSet de Grafana:

   Events:
     Type    Reason            Age                From                    Message
     ----    ------            ----               ----                    -------
     Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful
   

   Si no hay eventos en tu Pod ni en ningún otro recurso durante un período prolongado, recibirás el siguiente resultado:

     Events:         <none>
   

Verifica que la pila de registro de observabilidad se esté ejecutando

Sigue estos pasos para verificar que la pila de registro se esté ejecutando:

1. Verifica que todas las instancias o Pods de Loki tengan insertado el sidecar de Istio. Verifica que todos los Pods de Fluent Bit llamados anthos-audit-logs-forwarder-SUFFIX y anthos-log-forwarder-SUFFIX tengan el sidecar de Istio insertado.

2. Verifica que todas las instancias de Loki se estén ejecutando sin errores en el clúster de infraestructura de la organización.

3. Verifica el estado de los objetos anthos-audit-logs-forwarder y anthos-log-forwarder DaemonSet para asegurarte de que todas las instancias se estén ejecutando en todos los nodos sin errores.

4. Verifica que obtengas los registros operativos de los contenedores de kube-apiserver-SUFFIX y los registros de auditoría del servidor de la API de Kubernetes de los últimos cinco minutos en todos los clústeres. Para ello, ejecuta las siguientes consultas en la instancia de Grafana:

   • Registros operativos: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
   • Registros de auditoría: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

   Debes obtener valores distintos de cero para todos los nodos del plano de control en el clúster de infraestructura de la organización.

Verifica que la pila de supervisión de Observability esté en ejecución

Sigue estos pasos para verificar que la pila de supervisión esté en ejecución:

1. Verifica que las instancias de Grafana se estén ejecutando en el clúster de infraestructura de la organización. Los Pods de grafana-0 deben ejecutarse sin errores en los siguientes espacios de nombres:

   • obs-system
   • infra-obs-obs-system
   • platform-obs-obs-system
   Nota: Es posible que otros espacios de nombres de PROJECT_NAMESPACE-obs-system ejecuten instancias de Grafana. Las instancias varían según el clúster.

2. Asegúrate de que todos los componentes de supervisión estén en la malla de servicios de Istio. Sigue los pasos de la sección Identifica fallas de implementación. Cada uno de los siguientes Pods debe mostrar que todos los contenedores están listos en la columna READY. Por ejemplo, un valor de 3/3 significa que tres contenedores de tres están listos. Además, los Pods deben tener un contenedor istio-proxy. Si los Pods no cumplen con estas condiciones, reinícialos:

   Nombre del Pod	Cantidad de contenedores listos
   cortex-	2/2
   cortex-etcd-0	2/2
   cortex-proxy-server-	2/2
   cortex-tenant-	2/2
   meta-blackbox-exporter-	2/2
   meta-grafana-0	3/3
   meta-grafana-proxy-server-	2/2
   meta-prometheus-0	4/4
   cortex-alertmanager-	2/2
   cortex-compactor-	2/2
   cortex-distributor-	2/2
   cortex-etcd-0	2/2
   cortex-ingester-	2/2
   cortex-querier-	2/2
   cortex-query-frontend-	2/2
   cortex-query-scheduler-	2/2
   cortex-ruler-	2/2
   cortex-store-gateway-	2/2
   cortex-tenant-	2/2
   grafana-proxy-server-	2/2
   meta-blackbox-exporter-	2/2
   meta-grafana-0	3/3
   meta-grafana-proxy-server-*	2/2
   meta-prometheus-0	4/4

3. Asegúrate de que Cortex se esté ejecutando sin errores.

Recupera registros de observabilidad

En la siguiente tabla, se incluyen los comandos que debes ejecutar para recuperar los registros de cada uno de los componentes que implementa la plataforma de observabilidad.

Nota: Según el nombre del clúster o del componente, el comando puede ser un poco diferente.

Componente	Comando de recuperación de registros
grafana	kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s	kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager	kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io	kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read	kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all	kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read	kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io	kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read	kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa	kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read	kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all	kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read	kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder	kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder	kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder	kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator	kubectl logs -n obs-system deployment/logmon-operator

Para ver los registros de la instancia anterior de un componente, agrega la marca -p al final de cada comando. Agregar la marca -p te permite revisar los registros de una instancia con errores anterior en lugar de la instancia en ejecución actual.

Observa la configuración

La pila de observabilidad usa recursos personalizados de la API de Kubernetes para configurar las canalizaciones de supervisión y registro.

El recurso personalizado LoggingPipeline se implementa en el clúster de infraestructura de la organización y configura las instancias de Loki.

En los siguientes comandos, se muestran las acciones disponibles que puedes realizar en la canalización de registro:

• Visualiza la configuración actual de la implementación de tu canalización de registros:

  kubectl get loggingpipeline -n obs-system default -o yaml
  

• Cambia la configuración de la implementación de tu canalización de registro:

  kubectl edit loggingpipeline -n obs-system default
  

GDC usa un operador de registro y supervisión llamado logmon-operator para administrar la implementación de componentes de observabilidad, como Prometheus y Fluent Bit. La API para el componente logmon-operator es la definición de recurso personalizado logmon. La definición de recurso personalizado logmon indica a logmon-operator cómo configurar la observabilidad para tu implementación. Esta definición de recursos personalizados incluye las propiedades de los volúmenes para almacenar tus métricas, las reglas de alertas para Alertmanager, las configuraciones de Prometheus para recopilar métricas y las configuraciones de Grafana para los paneles.

En los siguientes comandos, se muestran las acciones disponibles que puedes realizar en la definición de recursos personalizados de logmon:

• Consulta la configuración actual de tu implementación de Observability:

  kubectl get logmon -n obs-system logmon-default -o yaml
  

• Cambia la configuración de tu implementación de Observability:

  kubectl edit logmon -n obs-system logmon-default
  

El resultado de ejecutar cualquiera de los comandos puede hacer referencia a varios objetos ConfigMap de Kubernetes para una configuración adicional. Por ejemplo, puedes configurar las reglas de Alertmanager en un objeto ConfigMap independiente, al que se hace referencia en la definición de recursos personalizados de logmon por nombre. Puedes cambiar y ver la configuración de Alertmanager a través de la definición de recursos personalizados de logmon llamada gpc-alertmanager-config.

Para ver la configuración de Alertmanager, ejecuta el siguiente comando:

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

Problemas comunes

En esta sección, se incluyen problemas comunes que puedes tener cuando implementas la plataforma de observabilidad.

No puedes acceder a Grafana

De forma predeterminada, Grafana no se expone a máquinas externas a tu clúster de Kubernetes. Para acceder de forma temporal a la interfaz de Grafana desde fuera del clúster de infraestructura de la organización, puedes redireccionar el puerto de Service a localhost. Para redireccionar el puerto de Service, ejecuta lo siguiente:

kubectl port-forward -n gpc-system service/grafana 33000\:3000

En tu navegador web, ve a http://localhost:33000 para ver el panel de Grafana de tu implementación. Para finalizar el proceso, presiona las teclas Control + C.

Grafana se ejecuta con lentitud

Si Grafana se ejecuta con lentitud, se indica lo siguiente:

• Las consultas a Prometheus o Loki devuelven datos excesivos.
• Las consultas devuelven más datos de los que es razonable mostrar en un solo gráfico.

Para resolver las velocidades lentas en Grafana, verifica las consultas en tus paneles personalizados de Grafana. Si las consultas devuelven más datos de los que es razonable mostrar en un solo gráfico, considera reducir la cantidad de datos que se muestran para mejorar el rendimiento del panel.

El panel de Grafana no muestra métricas ni registros

Si Grafana no muestra métricas ni registros, puede deberse a los siguientes motivos:

• Las fuentes de datos de Grafana no están configuradas correctamente.
• El sistema tiene problemas de conectividad con las fuentes de datos de supervisión o de registro.
• El sistema no recopila métricas ni registros.

Para ver los registros y las métricas, sigue estos pasos:

1. En la interfaz de usuario de Grafana, haz clic en Configuración del panel.
2. Selecciona Fuentes de datos.
3. En la página Fuentes de datos, asegúrate de ver las siguientes fuentes:

Nombre	Organización	URL
Audit Logs	All	http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs	Root	http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs	Org	http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus		http://anthos-prometheus-k8s.obs-system.svc:9090

La falta de estas fuentes de datos indica que la pila de observabilidad no pudo configurar Grafana correctamente.

Si configuraste las fuentes de datos de forma correcta, pero no se muestran datos, es posible que haya un problema con los objetos de Service que recopilan métricas o registros para ingresarlos en Prometheus o Loki.

A medida que Prometheus recopila métricas, sigue un modelo de extracción para consultar periódicamente tus objetos Service en busca de métricas y almacenar los valores encontrados. Para que Prometheus descubra tus objetos Service para la recopilación de métricas, se debe cumplir lo siguiente:

• Todos los Pods de los objetos Service se anotan con 'monitoring.gke.io/scrape: "true"'.

  Nota: Si tu servicio es un objeto Deployment o StatefulSet, agrega la anotación al servicio para que Kubernetes la propague a tus Pods.

• El formato de métrica de Prometheus expone las métricas del Pod a través de HTTP. De forma predeterminada, Prometheus busca estas métricas en el extremo http://POD_NAME:80/metrics. Si es necesario, puedes anular el puerto, el extremo y el esquema con anotaciones.

Fluent Bit recopila registros y está diseñado para ejecutarse en cada nodo de tus clústeres de Kubernetes. Fluent Bit envía los registros a Loki para su almacenamiento a largo plazo.

Si no hay registros en Grafana, prueba las siguientes soluciones alternativas:

• Verifica los registros de las instancias de Loki para asegurarte de que se ejecuten sin errores.

• Si las instancias de Loki se ejecutan correctamente, pero no aparecen los registros, verifica los registros en Fluent Bit para asegurarte de que el servicio funcione como se espera. Para revisar cómo extraer registros, consulta Recupera registros de observabilidad.

Alertmanager no abre alertas

Si Alertmanager no abre las alertas, sigue estos pasos:

1. En tu objeto configMap dentro del espacio de nombres gpc-system, asegúrate de que exista la etiqueta logmon: system_metrics.
2. Verifica que la sección de datos configMap incluya una clave llamada alertmanager.yml. El valor de la clave alertmanager.yml debe ser las reglas de alerta que se incluyen en tu archivo de configuración de Alertmanager válido.

3. Asegúrate de que la definición de recurso personalizado logmon llamada logmon-default en el espacio de nombres gpc-system contenga una referencia al objeto configMap. La definición de recurso personalizado logmon-default debe contener el nombre del objeto configMap, como se muestra en el siguiente ejemplo:

   apiVersion: addons.gke.io/v1
   kind: Logmon
   spec:
     system_metrics:
       outputs:
         default_prometheus:
           deployment:
             components:
               alertmanager:
                 alertmanagerConfigurationConfigmaps:
                   - alerts-config
   

   El valor alerts-config del ejemplo es el nombre de tu objeto configMap.

Alertmanager no envía alertas a los canales de notificaciones configurados

Un error de configuración puede impedir que recibas notificaciones en el software externo que configuraste como canal de notificaciones, como Slack, incluso si Alertmanager genera alertas en la instancia de Grafana.

Para recibir alertas en tu software externo, sigue estos pasos:

1. Verifica que los valores del archivo de configuración de Alertmanager tengan el formato correcto. Cuando Alertmanager activa una alerta, consulta un webhook en el software externo.

2. Asegúrate de que las URLs de webhook que se conectan al software externo sean correctas. Si las URLs son correctas, asegúrate de que el software esté configurado para aceptar webhooks. Es posible que debas generar una clave de API para acceder a la API del servicio externo o que tu clave de API actual haya vencido y debas actualizarla.

3. Si el servicio externo está fuera de la implementación del dispositivo de GDC aislado, asegúrate de que el clúster de infraestructura de tu organización tenga configuradas sus reglas de salida. Esta configuración permite que Alertmanager envíe solicitudes a un servicio fuera de la red interna de Kubernetes. Si no se verifican las reglas de salida, es posible que Alertmanager no pueda encontrar el software externo.

No puedes ver las métricas de tu carga de trabajo con alcance de proyecto

Sigue estos pasos para aplicar una solución alternativa y obtener métricas de tu carga de trabajo:

1. Asegúrate de que el recurso personalizado MonitoringTarget tenga el estado Ready.
2. Para extraer tu carga de trabajo, debes declarar toda la información de destino especificada en el MonitoringTarget en la especificación del Pod de cargas de trabajo. Por ejemplo, si declaras que las métricas están disponibles en el puerto 8080, el Pod de la carga de trabajo debe declarar a Kubernetes que el puerto 8080 está abierto. De lo contrario, Prometheus ignora la carga de trabajo.
3. Prometheus ejecuta varios fragmentos, lo que significa que no se espera que todos los Pods de Prometheus extraigan datos de tu Pod. Puedes identificar el número de fragmento en el nombre de cada Pod de Prometheus. Por ejemplo, primary-prometheus-shard0-replica0-0 forma parte de la fragmentación 0. Verifica el Pod del que deseas recopilar datos de cada fragmento de Prometheus:
   1. Redirecciona el puerto del Pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus en el espacio de nombres obs-system para obtener acceso a la IU de Prometheus. Reemplaza SHARD_NUMBER en el nombre del Pod por números crecientes cada vez que verifiques un fragmento nuevo.
   2. Ve a la IU de Prometheus en tu navegador web y sigue estos pasos:
      1. Haz clic en Estado > Destinos.
      2. Asegúrate de que el Pod que quieres extraer esté en la lista. De lo contrario, verifica el siguiente fragmento. Si no hay más fragmentos para verificar, vuelve a validar que Prometheus tenga suficiente información para descubrirlo.
   3. Verifica que el Pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus registre errores en el espacio de nombres obs-system.
4. Verifica los errores de los registros del Pod de cortex-tenant en el espacio de nombres obs-system.

No se creó un panel

Sigue estos pasos para aplicar una solución alternativa y descubrir por qué no se crea un panel:

1. Revisa el estado del recurso personalizado Dashboard para buscar errores. El recurso personalizado debe tener un estado Ready.
2. Asegúrate de verificar la instancia de Grafana correcta. Por ejemplo, si implementaste el panel en el espacio de nombres de tu proyecto llamado my-namespace, el panel debe estar en la instancia de Grafana en el extremo https://GDCH_URL/my-namespace/grafana.
3. Verifica los registros de fleet-admin-controller en el espacio de nombres gpc-system. Busca errores relacionados con el panel buscando su nombre en los registros. Si encuentras errores, el archivo JSON de tu objeto configMap tiene un formato incorrecto y debes corregirlo.
4. Revisa los registros de Grafana en el espacio de nombres PROJECT_NAME-obs-system para buscar errores. Los paneles consultan la API de REST de Grafana, por lo que Grafana debe estar funcionando para que se cree un panel.

No se abre la alerta

Sigue estos pasos para aplicar una solución alternativa y descubrir por qué no se abre una alerta:

1. Asegúrate de que Cortex y Loki estén en modo de almacenamiento de bucket. Las reglas no funcionan, a menos que el backend esté respaldado por el almacenamiento de bucket.
2. Verifica que el estado de los recursos personalizados MonitoringRule y LoggingRule sea Ready.
3. Verifica las siguientes condiciones de alerta:
   • Expresiones de PromQL y LogQL: Compara todas las funciones que usas con la documentación de Crea reglas de alerta para asegurarte de que tus reglas estén configuradas como deseas. Asegúrate de que las expresiones devuelvan un valor true o false.
   • Duración: El campo for del recurso personalizado define cuánto tiempo debe cumplirse una condición. El campo interval define la frecuencia con la que se evalúa la condición. Verifica los valores de estos campos entre sí y asegúrate de que tus condiciones sean lógicas.
4. Consulta la IU de Grafana para ver si la alerta está abierta con la página Alertas.
5. Si Grafana muestra que la alerta está abierta, verifica tus canales de notificaciones y asegúrate de que Alertmanager pueda comunicarse con ellos para producir la alerta.

Los registros esperados no están disponibles

Sigue estos pasos si no ves los registros operativos de tu componente:

1. Verifica si tu componente se está ejecutando y produciendo registros.
2. Verifica si los registros de tus componentes se deben recopilar como una funcionalidad integrada. De lo contrario, asegúrate de tener el recurso personalizado LoggingTarget implementado con una especificación válida y con un estado Ready.

Sigue estos pasos si no ves los registros de auditoría de tu componente:

1. Si tu componente escribe registros en un archivo, asegúrate de que el archivo exista en el sistema de archivos del nodo en la ruta de acceso /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
2. Verifica que el Pod anthos-audit-logs-forwarder-SUFFIX en el mismo nodo no tenga errores.
3. Si tu componente usa un extremo de syslog para recibir registros, asegúrate de tener implementado el recurso personalizado AuditLoggingTarget con una especificación válida y un estado Ready.

Identificar reglas de alertas predefinidas

En esta sección, se incluye información sobre las reglas de alertas predefinidas que existen en los componentes de Observabilidad para notificarte sobre las fallas del sistema.

Nota: Cada una de las alertas predefinidas en las siguientes tablas representa un incidente operativo.

Reglas de alerta predefinidas en Loki

En la siguiente tabla, se proporcionan las reglas de alerta preinstaladas en Loki para las fallas de registro de auditoría:

Reglas de alertas preinstaladas en Loki para fallas en el registro de auditoría

Nombre	Tipo	Descripción
FluentBitAuditLoggingWriteFailure	Crítico	Fluent Bit no pudo reenviar los registros de auditoría en los últimos cinco minutos.
LokiAuditLoggingWriteFailure	Crítico	Loki no pudo escribir registros de auditoría en el almacenamiento de backend.

Cuando se muestran una o más de estas alertas, el sistema perdió al menos un registro de auditoría.

Reglas de alerta predefinidas en Prometheus

En la siguiente tabla, se proporcionan las reglas de alertas preinstaladas en Prometheus para los componentes de Kubernetes:

Reglas de alertas preinstaladas en Prometheus

Nombre	Tipo	Descripción
KubeAPIDown	Crítico	La API de Kube desapareció del descubrimiento de destino de Prometheus durante 15 minutos.
KubeClientErrors	Advertencia	La proporción de errores del cliente del servidor de la API de Kubernetes fue superior a 0.01 durante 15 minutos.
KubeClientErrors	Crítico	La proporción de errores del cliente del servidor de la API de Kubernetes fue superior a 0.1 durante 15 minutos.
KubePodCrashLooping	Advertencia	El Pod estuvo en un estado de bucle de fallas durante más de 15 minutos.
KubePodNotReady	Advertencia	El Pod estuvo en un estado no listo durante más de 15 minutos.
KubePersistentVolumeFillingUp	Crítico	Los bytes libres de un objeto PersistentVolume reclamado son inferiores a 0.03.
KubePersistentVolumeFillingUp	Advertencia	Los bytes libres de un objeto PersistentVolume reclamado son inferiores a 0.15.
KubePersistentVolumeErrors	Crítico	El volumen persistente estuvo en una fase Failed o Pending durante cinco minutos.
KubeNodeNotReady	Advertencia	El nodo no está listo desde hace más de 15 minutos.
KubeNodeCPUUsageHigh	Crítico	El uso de CPU del nodo es superior al 80%.
KubeNodeMemoryUsageHigh	Crítico	El uso de memoria del nodo es superior al 80%.
NodeFilesystemSpaceFillingUp	Advertencia	El uso del sistema de archivos del nodo es superior al 60%.
NodeFilesystemSpaceFillingUp	Crítico	El uso del sistema de archivos del nodo es superior al 85%.
CertManagerCertExpirySoon	Advertencia	Un certificado vence en 21 días.
CertManagerCertNotReady	Crítico	Un certificado no está listo para entregar tráfico después de 10 minutos.
CertManagerHittingRateLimits	Crítico	Alcanzaste un límite de frecuencia cuando creaste o renovaste certificados durante cinco minutos.
DeploymentNotReady	Crítico	Un Deployment en el clúster de infraestructura de la organización estuvo en un estado no listo durante más de 15 minutos.
StatefulSetNotReady	Crítico	Un objeto StatefulSet en el clúster de infraestructura de la organización estuvo en un estado no listo durante más de 15 minutos.
AuditLogsForwarderDown	Crítico	El DaemonSet anthos-audit-logs-forwarder estuvo inactivo durante más de 15 minutos.
AuditLogsLokiDown	Crítico	El StatefulSet audit-logs-loki estuvo en un estado no listo durante más de 15 minutos.