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

Solución de problemas de observabilidad

En este documento, se describe cómo identificar las fallas de implementación y los incidentes operativos que puedes encontrar en el dispositivo aislado de Google Distributed Cloud (GDC), y se incluyen descripciones de todas las alertas que se muestran en el sistema para ayudarte a resolver problemas comunes con los componentes de registro y supervisión.

Identifica los componentes de Observability

La plataforma de 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 las métricas a nivel de la organización para supervisar los componentes de la infraestructura, como el uso de la CPU y el consumo de almacenamiento. También proporciona acceso a los registros operativos y de auditoría. Además, brinda acceso a las alertas, los registros y las métricas de los componentes operables del 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 físicas, los conmutadores 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 nodos de Kubernetes, Pods, máquinas de metal desnudo, conmutadores de red y 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 alertas de Prometheus.
`Loki`	Loki es una base de datos de series temporales que almacena y agrega registros de diversas 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 operativos y de auditoría 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 en la implementación

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

Sigue estos pasos para identificar las fallas en la implementación:

Confirma el estado actual de un componente:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Reemplaza lo siguiente:
- 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, la columna READY del resultado muestra N/N como valor. Si la columna READY no muestra un valor, no necesariamente indica una falla. Es posible que el servicio necesite más tiempo para procesar la solicitud.
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 valor, que la columna STATUS muestre un valor de 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 falla, 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 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 de Secret que requiere el Pod.
- Tu clúster de Kubernetes se quedó sin recursos para programar el pod, lo que ocurre si muchas aplicaciones se ejecutan en el clúster.
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.

El resultado muestra más detalles sobre el Pod.

Navega a la sección Events del resultado para ver una tabla con los eventos recientes del Pod y un resumen sobre 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 tiempo prolongado, recibirás el siguiente resultado:

  Events:         <none>

Verifica que la pila de registro de Observabilidad esté en ejecución

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

Verifica que todas las instancias o pods de Loki tengan el sidecar de Istio incorporado. Verifica que todos los pods de Fluent Bit llamados anthos-audit-logs-forwarder-SUFFIX y anthos-log-forwarder-SUFFIX tengan el sidecar de Istio incorporado.
Verifica que todas las instancias de Loki se ejecuten sin errores en el clúster de infraestructura de la organización.
Verifica el estado de los objetos anthos-audit-logs-forwarder y anthos-log-forwarder DaemonSet para comprobar que todas las instancias se ejecutan en todos los nodos sin errores.
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 Observabilidad esté en ejecución

Sigue estos pasos para verificar que la pila de supervisión se esté ejecutando:

Verifica 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 supervisión estén en la malla de servicio de Istio. Sigue los pasos de la sección Identifica fallas en la 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`

Asegúrate de que Cortex se ejecute 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.

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 anterior con errores 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 instancias de Loki.

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

Consulta 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 registros:
```
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 del componente logmon-operator es la definición de recurso personalizado logmon. La definición de recurso personalizado logmon le indica a logmon-operator cómo configurar la Observabilidad para tu implementación. Esta definición de recurso personalizado 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 recurso personalizado logmon:

Para ver la configuración actual de tu implementación de Observabilidad, haz lo siguiente:
```
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
```

El resultado de la ejecución de cualquiera de los comandos puede hacer referencia a varios objetos ConfigMap de Kubernetes para una mayor configuración. Por ejemplo, puedes configurar reglas de Alertmanager en un objeto ConfigMap independiente, al que se hace referencia en la definición de recurso personalizado logmon por nombre. Puedes cambiar y ver la configuración de Alertmanager a través de la definición de recurso personalizado 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 los problemas comunes que puedes enfrentar cuando implementas la plataforma de Observabilidad.

No puedes acceder a Grafana

De forma predeterminada, Grafana no se expone a las 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 redireccionar el puerto de Service, ejecuta el siguiente comando:

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

En tu navegador web, navega 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, esto 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 los problemas de velocidad en Grafana, revisa 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:

En la interfaz de usuario de Grafana, haz clic en Configuración del panel.
Selecciona Fuentes de datos.
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`

Si faltan estas fuentes de datos, significa que la pila de Observabilidad no pudo configurar Grafana correctamente.

Si configuraste las fuentes de datos correctamente, pero no se muestran datos, es posible que haya un problema con los objetos Service que recopilan métricas o registros para alimentar 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 deben cumplir las siguientes condiciones:

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

Nota: Si tu servicio es una implementación o un objeto StatefulSet, agrega la anotación al servicio para que Kubernetes la propague a tus Pods.
El formato de métricas 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 a través de 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, consulta los registros en Fluent Bit para asegurarte de que el servicio funcione según lo esperado. Para revisar cómo extraer registros, consulta Cómo recuperar registros de Observabilidad.

Alertmanager no abre alertas

Si Alertmanager no puede abrir alertas, sigue estos pasos:

En tu objeto configMap dentro del espacio de nombres gpc-system, asegúrate de que exista la etiqueta logmon: system_metrics.
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.
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 del 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 en el 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:

Verifica que los valores de tu 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 debas generar una clave de API para acceder a la API del servicio externo, o bien que tu clave de API actual haya vencido y debas actualizarla.
Si el servicio externo está fuera de la implementación del dispositivo aislado de GDC, 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 del 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 extraer datos de tu carga de trabajo, debes declarar toda la información del 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 ignorará la carga de trabajo.
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 es parte del fragmento 0. Verifica el Pod del que deseas extraer 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 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 Status > Targets.
  2. Asegúrate de que el pod que deseas extraer esté en la lista. De lo contrario, revisa el siguiente fragmento. Si no hay más fragmentos para verificar, vuelve a validar que Prometheus tenga 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 los errores en los registros del pod 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 creó un panel:

Revisa el estado del recurso personalizado Dashboard para buscar errores. El recurso personalizado debe tener un estado Ready.
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.
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, significa que el archivo JSON de tu objeto configMap tiene un formato incorrecto y debes corregirlo.
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 en funcionamiento 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:

Asegúrate de que Cortex y Loki estén en modo de almacenamiento en bucket. Las reglas no funcionan a menos que el backend esté respaldado por el almacenamiento de bucket.
Verifica que el estado de los recursos personalizados MonitoringRule y LoggingRule sea Ready.
Verifica las siguientes condiciones de alerta:
- Expresiones de PromQL y LogQL: Compara todas las funciones que usas con la documentación de Crear reglas de alertas 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 con qué frecuencia se debe evaluar la condición. Compara los valores de estos campos entre sí y asegúrate de que tus condiciones sean lógicas.
Verifica la IU de Grafana para ver si la alerta está abierta en la página Alerts.
Si Grafana muestra que la alerta está abierta, verifica tus canales de notificación y asegúrate de que Alertmanager pueda comunicarse con ellos para generar la alerta.

Los registros esperados no están disponibles

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

Verifica si tu componente se está ejecutando y produciendo registros.
Verifica si los registros de tus componentes se deben recopilar como una funcionalidad integrada. De lo contrario, asegúrate de que el recurso personalizado LoggingTarget esté 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:

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

Identifica 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.

Reglas de alertas predefinidas en Loki

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

Reglas de alertas preinstaladas en Loki para errores de Cloud Audit Logging
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, significa que el sistema perdió al menos un registro de auditoría.

Reglas de alertas 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 objetivos 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ítico	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 estado de bucle de fallas durante más de 15 minutos.
`KubePodNotReady`	Advertencia	El Pod ha estado en estado no listo durante más de 15 minutos.
`KubePersistentVolumeFillingUp`	Crítico	Los bytes disponibles de un objeto `PersistentVolume` reclamado son inferiores a 0.03.
`KubePersistentVolumeFillingUp`	Advertencia	Los bytes disponibles 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 ha estado listo durante 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	Una Deployment en el clúster de infraestructura de la organización se encuentra en un estado de no listo desde hace más de 15 minutos.
`StatefulSetNotReady`	Crítico	Un objeto `StatefulSet` en el clúster de infraestructura de la organización se encuentra en un estado de no listo desde hace más de 15 minutos.
`AuditLogsForwarderDown`	Crítico	El DaemonSet `anthos-audit-logs-forwarder` ha estado inactivo durante más de 15 minutos.
`AuditLogsLokiDown`	Crítico	El objeto `audit-logs-loki` StatefulSet ha estado en un estado no listo durante más de 15 minutos.