En este documento, se describe una configuración para la evaluación de reglas y alertas en un servicio administrado para la implementación de Prometheus que usa la recopilación administrada.
En el siguiente diagrama, se ilustra una implementación que usa varios clústeres en dos proyectos de Google Cloud y usa la evaluación de reglas y alertas, así como el recurso opcional de GlobalRules:
Para configurar y usar una implementación como la del diagrama, ten en cuenta lo siguiente:
El evaluador de reglas administradas se implementa de forma automática en cualquier clúster en el que se ejecute la recopilación administrada. Estos evaluadores se configuran de la siguiente manera:
Usa recursos de Rules para ejecutar reglas en los datos dentro de un espacio de nombres. Los recursos Rules se deben aplicar en cada espacio de nombres en el que desees ejecutar la regla.
Usa recursos ClusterRules para ejecutar reglas en los datos de todo un clúster. Los recursos ClusterRules se deben aplicar una vez por clúster.
Toda la evaluación de reglas se ejecuta en el almacén de datos global, Monarch.
- Los recursos Rules filtran las reglas de forma automática para el proyecto, la ubicación, el clúster y el espacio de nombres en el que se instalan.
- Los recursos ClusterRules filtran las reglas de forma automática para el proyecto, la ubicación y el clúster en el que están instalados.
- Todos los resultados de reglas se escriben en Monarch después de la evaluación.
Una instancia de Prometheus AlertManager se implementa de forma manual en cada clúster. Los evaluadores de reglas administradas se configuran mediante la edición del recurso OperatorConfig para enviar reglas de alertas activadas a su instancia de AlertManager local. Los silencios, las confirmaciones y los flujos de trabajo de administración de incidentes suelen manejarse en una herramienta de terceros como PagerDuty.
Puedes centralizar la administración de alertas de varios clústeres en un solo AlertManager mediante un recurso Endpoints de Kubernetes.
En el diagrama anterior, también se muestra el recurso opcional GlobalRules. Usa GlobalRules con moderación para realizar tareas como calcular SLO globales en proyectos o evaluar reglas entre clústeres dentro de un solo proyecto de Google Cloud. Recomendamos enfáticamente usar Rules y ClusterRules siempre que sea posible; estos recursos proporcionan mayor confiabilidad y se adaptan mejor a los modelos de usuario y los mecanismos de implementación comunes de Kubernetes.
Si usas el recurso GlobalRules, ten en cuenta lo siguiente del diagrama anterior:
Un solo clúster que se ejecuta dentro de Google Cloud se designa como el clúster de evaluación de reglas global para un alcance de métricas. Este evaluador de reglas administradas está configurado para usar scoping_project_A, que contiene los proyectos 1 y 2. Las reglas ejecutadas en scoping_project_A se distribuyen de forma automática a los proyectos 1 y 2.
La cuenta de servicio subyacente debe tener los permisos de Monitoring Viewer para scoping_project_A. Para obtener información adicional sobre cómo configurar estos campos, consulta Evaluación de reglas globales y de varios proyectos.
Al igual que en todos los demás clústeres, este evaluador de reglas se configura con recursos Rules y ClusterRules que evalúan reglas con alcance de un espacio de nombres o clúster. Estas reglas se filtran automáticamente para el proyecto local, en este caso, el proyecto 1. Debido a que scoping_project_A contiene el proyecto 1, las reglas configuradas con Rules y ClusterRules se ejecutan solo en datos del proyecto local como se esperaba.
Este clúster también tiene recursos GlobalRules que ejecutan reglas en scoping_project_A. Los recursos GlobalRules no se filtran automáticamente y, por lo tanto, GlobalRules se ejecuta exactamente como se escribe en todos los proyectos, ubicaciones, clústeres y espacios de nombres en scoping_project_A.
Las reglas de alertas activadas se enviarán al AlertManager autoalojado como se esperaba.
El uso de GlobalRules puede tener efectos inesperados, según si conservas o agregas las etiquetas project_id, location, cluster y namespace en tus reglas:
Si tu regla de GlobalRules conserva la etiqueta
project_id(mediante una cláusulaby(project_id)), los resultados de la regla se vuelven a escribir en Monarch con el valor original deproject_idde la serie temporal subyacente.En este caso, debes asegurarte de que la cuenta de servicio subyacente tenga los permisos de Monitoring Metric Writer para cada proyecto supervisado en scoping_project_A. Si agregas un proyecto supervisado nuevo a scoping_project_A, también debes agregar manualmente un permiso nuevo a la cuenta de servicio.
Si tu regla de GlobalRules no conserva la etiqueta
project_id(porque no se usa una cláusulaby(project_id)), los resultados de la regla se vuelven a escribir en Monarch mediante el valorproject_iddel clúster en el que se ejecuta el evaluador de reglas global.En esta situación, no necesitas modificar aún más la cuenta de servicio subyacente.
Si tu recurso GlobalRules conserva la etiqueta
location(porque se usa una cláusulaby(location)), los resultados de la regla se vuelven a escribir en Monarch con cada región original de Google Cloud desde la que se originó la serie temporal subyacente.Si GlobalGlobal no conserva la etiqueta
location, los datos se vuelven a escribir en la ubicación del clúster en el que se ejecuta el evaluador de reglas globales.
Recomendamos encarecidamente conservar las etiquetas cluster y namespace en los resultados de la evaluación de reglas, a menos que el propósito de la regla sea agregar esas etiquetas. De lo contrario, el rendimiento de las consultas podría disminuir y podrías encontrarte con límites de cardinalidad. No se recomienda quitar ambas etiquetas.