Evaluación de reglas y alertas con la recogida desplegada automáticamente

En este documento se describe una configuración para la evaluación de reglas y alertas en una implementación de Managed Service para Prometheus que usa la recogida autodesplegada.

En el siguiente diagrama se muestra una implementación que usa varios clústeres en dos proyectos Google Cloud y que utiliza tanto la evaluación de reglas como la de alertas:

Una implementación para la evaluación de reglas y alertas que usa la recogida desplegada automáticamente.

Para configurar y usar una implementación como la del diagrama, ten en cuenta lo siguiente:

  • Las reglas se instalan en cada servidor de recogida de Managed Service para Prometheus, al igual que cuando se usa Prometheus estándar. La evaluación de reglas se ejecuta con los datos almacenados localmente en cada servidor. Los servidores están configurados para conservar los datos el tiempo suficiente para cubrir el periodo retrospectivo de todas las reglas, que suele ser de una hora como máximo. Los resultados de las reglas se escriben en Monarch después de la evaluación.

  • Se implementa manualmente una instancia de AlertManager de Prometheus en cada clúster. Los servidores de Prometheus se configuran editando el campo alertmanager_configdel archivo de configuración para enviar las reglas de alerta activadas a su instancia local de Alertmanager. Los silencios, las confirmaciones y los flujos de trabajo de gestión de incidentes suelen gestionarse en una herramienta de terceros, como PagerDuty.

    Puedes centralizar la gestión de alertas en varios clústeres en un único AlertManager mediante un recurso Endpoints de Kubernetes.

  • Un único clúster que se ejecuta en Google Cloud se designa como clúster de evaluación de reglas global de un ámbito de métricas. El evaluador de reglas independiente se implementa en ese clúster y las reglas se instalan con el formato de archivo de reglas estándar de Prometheus.

    El evaluador de reglas independiente está configurado para usar scoping_project_A, que contiene los proyectos 1 y 2. Las reglas ejecutadas en scoping_project_A se propagan automáticamente a los proyectos 1 y 2. Se deben conceder los permisos de lector de Monitoring a la cuenta de servicio subyacente de scoping_project_A.

    El evaluador de reglas está configurado para enviar alertas al Alertmanager de Prometheus local mediante el campo alertmanager_config del archivo de configuración.

El uso de un evaluador de reglas global autodesplegado puede tener efectos inesperados, en función de si conservas o agregas las etiquetas project_id, location, cluster y namespace en tus reglas:

  • Si tus reglas conservan la etiqueta project_id (mediante una cláusula by(project_id)), los resultados de las reglas se vuelven a escribir en Monarch con el valor project_id original de la serie temporal subyacente.

    En este caso, debes asegurarte de que la cuenta de servicio subyacente tenga los permisos Escritor de métricas de Monitoring para cada proyecto monitorizado en scoping_project_A. Si añades un nuevo proyecto monitorizado a scoping_project_A, también debes añadir manualmente un nuevo permiso a la cuenta de servicio.

  • Si tus reglas no conservan la etiqueta project_id (porque no usan una cláusula by(project_id)), los resultados de las reglas se vuelven a escribir en Monarch con el valor project_id del clúster en el que se ejecuta el evaluador de reglas global.

    En este caso, no es necesario que modifiques más la cuenta de servicio subyacente.

  • Si sus reglas conservan la etiqueta location (mediante una cláusula by(location) ), los resultados de las reglas se vuelven a escribir en Monarch usando cada región Google Cloud original de la que proceden las series temporales subyacentes.

    Si tus reglas no conservan 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.

Te recomendamos que conserves las etiquetas cluster y namespace en los resultados de la evaluación de reglas siempre que sea posible. De lo contrario, el rendimiento de las consultas podría disminuir y podrías alcanzar los límites de cardinalidad. No se recomienda quitar ambas etiquetas.