Esta página se ha traducido con Cloud Translation API.

Solución de problemas de observabilidad

En este documento se describe cómo identificar los fallos de implementación y los incidentes operativos que pueden producirse en el dispositivo aislado de Google Distributed Cloud (GDC). También se incluyen descripciones de todas las alertas que se muestran en el sistema para ayudarle a resolver problemas habituales con los componentes de registro y monitorización.

Identificar componentes de observabilidad

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

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

Las pilas de monitorización y registro de GDC usan soluciones de código abierto como parte de la plataforma Observabilidad. Estos componentes recogen registros y métricas de pods de Kubernetes, máquinas físicas, conmutadores de red, almacenamiento y servicios gestionados.

En la siguiente tabla se describen todos los componentes que integran la plataforma Observabilidad:

Componente	Descripción
`Prometheus`	Prometheus es una base de datos de series temporales que se usa para recoger y almacenar métricas, así como para 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 añade etiquetas como pares clave-valor y recoge métricas de nodos, pods, máquinas físicas, conmutadores de red y dispositivos de almacenamiento de Kubernetes.
`Alertmanager`	Alertmanager es un sistema de gestió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. Gestiona el enrutamiento, el silenciamiento y la agregación de 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 que las consultas sean eficientes.
`Grafana`	Grafana proporciona una interfaz de usuario para ver las métricas que recoge Prometheus y consultar los registros de auditoría y operativos de las instancias de Loki correspondientes. La interfaz de usuario te permite visualizar paneles de control 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 todos los nodos de todos los clústeres.

Identificar fallos de implementación

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

Sigue estos pasos para identificar los fallos de implementación:

Confirma el estado actual de un componente:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Haz los cambios siguientes:
- TYPE: el tipo de componente
- COMPONENT: 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, en la columna READY del resultado se muestra el valor N/N. Si la columna READY no muestra ningún valor, no significa necesariamente que se haya producido un error. Es posible que el servicio necesite más tiempo para procesar la solicitud.
Comprueba los pods de cada componente:
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
Sustituye 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 el valor N/N, que la columna STATUS muestre el valor Running y que el número de RESTARTS no supere el valor 2.

Un número elevado de reinicios indica los siguientes síntomas:
- Los pods fallan y Kubernetes los reinicia.
- La columna STATUS muestra el valor CrashLoopBackoff.
Para resolver el problema, consulta los registros de los pods.

Si un pod está en estado PENDING, significa que presenta uno o varios de los siguientes síntomas:
- El pod está esperando a tener 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 necesita el pod.
- Tu clúster de Kubernetes se ha quedado sin recursos para programar el pod, lo que ocurre si hay muchas aplicaciones ejecutándose en el clúster.
Determinar la causa de un estado PENDING:
```
kubectl describe -n obs-system pod/POD_NAME
```
Sustituye POD_NAME por el nombre del pod que muestra el estado PENDING.

El resultado muestra más detalles sobre el pod.

Ve 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 de 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 periodo prolongado, verás el siguiente resultado:

  Events:         <none>

Comprobar que la pila de registro de observabilidad se está ejecutando

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

Verifica que todas las instancias o pods de Loki tengan el sidecar de Istio insertado. 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.
Comprueba que todas las instancias de Loki se estén ejecutando sin errores en el clúster de infraestructura de la organización.
Comprueba el estado de los objetos anthos-audit-logs-forwarder y anthos-log-forwarder DaemonSet para verificar que todas las instancias se ejecutan en todos los nodos sin errores.
Verifica que obtienes los registros operativos de los contenedores 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 del clúster de infraestructura de la organización.

Comprobar que la pila de monitorización de Observabilidad se está ejecutando

Sigue estos pasos para verificar que la pila de monitorización se está ejecutando:

Comprueba que las instancias de Grafana se estén ejecutando en el clúster de infraestructura de la organización. Los pods 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.

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

Nombre del pod	Número 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`

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

Obtener registros de Observabilidad

En la siguiente tabla se incluyen los comandos que debe ejecutar para obtener los registros de cada uno de los componentes que implementa la plataforma Observability.

Componente	Comando de obtenció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, añade la marca -p al final de cada comando. Si añades la marca -p, podrás revisar los registros de una instancia anterior que haya fallado en lugar de la instancia en ejecución actual.

Ver la configuración

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

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

Los siguientes comandos muestran las acciones disponibles que puedes realizar en la canalización de registro:

Consulta la configuración actual de la implementación de tu canalización de registro:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Cambia la configuración de la implementación de tu flujo de registro:
```
kubectl edit loggingpipeline -n obs-system default
```

GDC usa un operador de registro y monitorización llamado logmon-operator para gestionar el despliegue de componentes de observabilidad, como Prometheus y Fluent Bit. La API del 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 de tu implementación. Esta definición de recurso personalizado incluye las propiedades de los volúmenes para almacenar tus métricas, las reglas de alerta de Alertmanager, las configuraciones de Prometheus para recoger métricas y las configuraciones de Grafana para los paneles de control.

Los siguientes comandos muestran las acciones disponibles que puedes realizar en la definición de recurso personalizado logmon:

Consulta la configuración actual de tu implementación de Observabilidad:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Cambia la configuración de tu implementación de Observabilidad:
```
kubectl edit logmon -n obs-system logmon-default
```

La salida de la ejecución de cualquiera de los comandos puede hacer referencia a varios objetos de Kubernetes ConfigMap para realizar más configuraciones. Por ejemplo, puede configurar reglas de Alertmanager en un objeto ConfigMap independiente, al que se hace referencia en la definición de recurso personalizado logmon por su nombre. Puedes cambiar y ver la configuración de Alertmanager a través de la logmon definición de recurso personalizado 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 más comunes

En esta sección se describen los problemas habituales que pueden surgir al implementar 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 temporalmente a la interfaz de Grafana desde fuera del clúster de infraestructura de la organización, puedes reenviar el puerto Service a localhost. Para reenviar el puerto de la Service, ejecuta el siguiente comando:

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, pulsa las teclas Control + C.

Grafana funciona lentamente

Si Grafana funciona con lentitud, puede deberse a lo siguiente:

Las consultas a Prometheus o Loki devuelven una cantidad excesiva de datos.
Las consultas devuelven más datos de los que se pueden mostrar en un solo gráfico.

Para solucionar los problemas de velocidad en Grafana, comprueba las consultas de tus paneles de control personalizados de Grafana. Si las consultas devuelven más datos de los que es razonable mostrar en un solo gráfico, considera la posibilidad de reducir la cantidad de datos mostrados para mejorar el rendimiento del panel de control.

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 monitorización o de registro.
El sistema no está recogiendo métricas ni registros.

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

En la interfaz de usuario de Grafana, haz clic en Configuración del panel de control.
Seleccione Fuentes de datos.
En la página Fuentes de datos, comprueba que aparecen 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`

Si faltan estas fuentes de datos, significa que la pila de observabilidad no ha podido configurar Grafana correctamente.

Si has configurado las fuentes de datos correctamente, pero no se muestran datos, puede que haya un problema con los objetos Service que recogen métricas o registros para introducirlos en Prometheus o Loki.

A medida que Prometheus recoge 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 y pueda recopilar métricas, deben cumplirse las siguientes condiciones:

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

Nota: Si tu servicio es un objeto de implementación o StatefulSet, añade la anotación al servicio para que Kubernetes la propague a tus pods.
El formato de métrica de Prometheus expone las métricas de los pods a través de HTTP. De forma predeterminada, Prometheus busca estas métricas en el endpoint http://POD_NAME:80/metrics. Si es necesario, puede anular el puerto, el endpoint y el esquema mediante anotaciones.

Fluent Bit recoge registros y está diseñado para ejecutarse en todos los nodos de tus clústeres de Kubernetes. Fluent Bit envía los registros a Loki para almacenarlos a largo plazo.

Si no hay registros en Grafana, prueba estas soluciones alternativas:

Consulta los registros de las instancias de Loki para asegurarte de que se ejecutan sin errores.
Si las instancias de Loki se están ejecutando correctamente, pero los registros no aparecen, consulta los registros de Fluent Bit para asegurarte de que el servicio funciona según lo esperado. Para consultar cómo extraer registros, consulta Recuperar registros de observabilidad.

Alertmanager no abre alertas

Si Alertmanager no puede abrir alertas, sigue estos pasos:

En el objeto configMap del espacio de nombres gpc-system, comprueba que existe la etiqueta logmon: system_metrics.
Comprueba que la sección de datos configMap incluya una clave llamada alertmanager.yml. El valor de la clave alertmanager.yml debe ser el de las reglas de alerta que se incluyan en tu archivo de configuración de Alertmanager válido.
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, tal 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 notificación configurados

Es posible que un error de configuración te impida recibir notificaciones en el software externo que hayas configurado como canal de notificaciones (por ejemplo, Slack), aunque Alertmanager genere alertas en la instancia de Grafana.

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

Comprueba 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.
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 tengas que generar una clave de API para acceder a la API del servicio externo o que tu clave de API actual haya caducado y tengas que actualizarla.
Si el servicio externo está fuera de tu implementación del dispositivo aislado por aire de GDC, asegúrate de que el clúster de infraestructura de tu organización tenga configuradas las 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 ámbito de proyecto

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

Asegúrate de que el recurso personalizado MonitoringTarget tenga el estado Ready.
Para raspar tu carga de trabajo, debes declarar toda la información de destino especificada en 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.
Prometheus ejecuta varios fragmentos, lo que significa que no se espera que todos los pods de Prometheus raspen tu pod. Puede identificar el número de fragmento en el nombre de cada pod de Prometheus. Por ejemplo, primary-prometheus-shard0-replica0-0 forma parte del fragmento 0. Comprueba el pod del que quieras obtener datos de cada fragmento de Prometheus:
1. Redirige el puerto del pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus en el espacio de nombres obs-system para acceder a la interfaz de usuario de Prometheus. Sustituye SHARD_NUMBER en el nombre del pod por números crecientes cada vez que compruebes un nuevo fragmento.
2. Ve a la interfaz de usuario de Prometheus en tu navegador web y sigue estos pasos:
  1. Haz clic en Estado > Objetivos.
  2. Asegúrate de que el pod que quieres raspar esté en la lista. Si no es así, comprueba el siguiente fragmento. Si no hay más fragmentos que comprobar, vuelve a validar que Prometheus tiene suficiente información para detectarlo.
3. Verifica que el pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus registre errores en el espacio de nombres obs-system.
Verifica que los registros del pod cortex-tenant muestren errores en el espacio de nombres obs-system.

No se ha creado ningún panel de control

Sigue estos pasos para aplicar una solución alternativa y averiguar por qué no se ha creado un panel de control:

Revisa el estado del recurso personalizado Dashboard para ver si hay errores. El recurso personalizado debe tener el estado Ready.
Asegúrate de que estás consultando la instancia de Grafana correcta. Por ejemplo, si has desplegado el panel de control en el espacio de nombres de tu proyecto llamado my-namespace, el panel de control debe estar en la instancia de Grafana en el endpoint https://GDCH_URL/my-namespace/grafana.
Consulta los registros de fleet-admin-controller en el espacio de nombres gpc-system. Busca errores relacionados con el panel de control buscando su nombre en los registros. Si se detectan errores, significa que el archivo JSON del objeto configMap tiene un formato incorrecto y debes corregirlo.
Consulta los registros de Grafana en el espacio de nombres PROJECT_NAME-obs-system para ver si hay errores. Los paneles de control consultan la API REST de Grafana, por lo que Grafana debe funcionar para que se pueda crear un panel de control.

Tu alerta no se abre

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

Asegúrate de que Cortex y Loki estén en modo de almacenamiento en contenedores. Las reglas no funcionan a menos que el backend esté respaldado por un almacenamiento de segmentos.
Verifica que el estado de los recursos personalizados MonitoringRule y LoggingRule sea Ready.
Comprueba las siguientes condiciones de alerta:
- Expresiones de PromQL y LogQL: compara todas las funciones que estés usando con la documentación sobre creación de reglas de alerta para asegurarte de que las reglas estén configuradas como quieras. 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 debe evaluar la condición. Compruebe los valores de estos campos entre sí y asegúrese de que las condiciones sean lógicas.
Comprueba la interfaz de usuario de Grafana para ver si la alerta está abierta en la página Alerts (Alertas).
Si Grafana muestra que la alerta está abierta, comprueba tus canales de notificación y asegúrate de que Alertmanager pueda ponerse en contacto con ellos para generar la alerta.

Los registros esperados no están disponibles

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

Comprueba si tu componente se está ejecutando y genera registros.
Comprueba si los registros de tus componentes se deben recoger como una función integrada. Si no es así, asegúrese de que el recurso personalizado LoggingTarget se ha implementado con una especificación válida y con el estado Ready.

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

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 /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
Verifica que el pod anthos-audit-logs-forwarder-SUFFIX del mismo nodo no tenga errores.
Si tu componente usa un endpoint de syslog para recibir registros, asegúrate de que has implementado el recurso personalizado AuditLoggingTarget con una especificación válida y con el estado Ready.

Identificar reglas de alertas predefinidas

Esta sección contiene información sobre las reglas de alertas predefinidas que existen en los componentes de Observabilidad para informarle sobre los fallos del sistema.

Reglas de alerta predefinidas en Loki

En la siguiente tabla se muestran las reglas de alertas preinstaladas en Loki para los errores de registro de auditoría:

Reglas de alertas preinstaladas en Loki para errores de registro de auditoría
Nombre	Tipo	Descripción
`FluentBitAuditLoggingWriteFailure`	Crítica	Fluent Bit no ha podido reenviar los registros de auditoría en los últimos cinco minutos.
`LokiAuditLoggingWriteFailure`	Crítica	Loki no ha podido escribir registros de auditoría en el almacenamiento backend.

Cuando se muestra una o varias de estas alertas, significa que el sistema ha perdido al menos un registro de auditoría.

Reglas de alertas predefinidas en Prometheus

En la siguiente tabla se muestran las reglas de alerta preinstaladas en Prometheus para los componentes de Kubernetes:

Reglas de alertas preinstaladas en Prometheus
Nombre	Tipo	Descripción
`KubeAPIDown`	Crítica	La API de Kube ha desaparecido del descubrimiento de destinos de Prometheus durante 15 minutos.
`KubeClientErrors`	Advertencia	La proporción de errores del cliente del servidor de la API de Kubernetes ha sido superior a 0,01 durante 15 minutos.
`KubeClientErrors`	Crítica	La proporción de errores del cliente del servidor de la API de Kubernetes ha sido superior a 0,1 durante 15 minutos.
`KubePodCrashLooping`	Advertencia	El pod ha estado en un bucle de fallos durante más de 15 minutos.
`KubePodNotReady`	Advertencia	El pod lleva más de 15 minutos en un estado no preparado.
`KubePersistentVolumeFillingUp`	Crítica	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ítica	El volumen persistente ha estado en la fase `Failed` o `Pending` durante cinco minutos.
`KubeNodeNotReady`	Advertencia	El nodo no está listo desde hace más de 15 minutos.
`KubeNodeCPUUsageHigh`	Crítica	El uso de CPU del nodo es superior al 80%.
`KubeNodeMemoryUsageHigh`	Crítica	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ítica	El uso del sistema de archivos del nodo es superior al 85%.
`CertManagerCertExpirySoon`	Advertencia	Un certificado caduca en 21 días.
`CertManagerCertNotReady`	Crítica	Un certificado no está listo para servir tráfico después de 10 minutos.
`CertManagerHittingRateLimits`	Crítica	Has alcanzado un límite de frecuencia al crear o renovar certificados durante cinco minutos.
`DeploymentNotReady`	Crítica	Una implementación en el clúster de infraestructura de la organización lleva más de 15 minutos en un estado no preparado.
`StatefulSetNotReady`	Crítica	Un objeto `StatefulSet` del clúster de infraestructura de la organización lleva más de 15 minutos en un estado no preparado.
`AuditLogsForwarderDown`	Crítica	El `anthos-audit-logs-forwarder` DaemonSet ha estado inactivo durante más de 15 minutos.
`AuditLogsLokiDown`	Crítica	El `audit-logs-loki` StatefulSet ha estado en un estado no preparado durante más de 15 minutos.