Evaluación de reglas y alertas con colecciones gestionadas

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

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, así como el recurso GlobalRules opcional:

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

• El evaluador de reglas gestionadas se despliega automáticamente en cualquier clúster en el que se esté ejecutando la recogida gestionada. Estos evaluadores se configuran de la siguiente manera:

  • Usa recursos de reglas para ejecutar reglas en los datos de un espacio de nombres. Los recursos de reglas deben aplicarse en todos los espacios de nombres en los que quieras ejecutar la regla.

  • Usa recursos ClusterRules para ejecutar reglas en los datos de un clúster. Los recursos ClusterRules deben aplicarse una vez por clúster.

• Todas las evaluaciones de reglas se ejecutan en el almacén de datos global, Monarch.

  • Los recursos de reglas filtran automáticamente las reglas al proyecto, la ubicación, el clúster y el espacio de nombres en los que están instalados.
  • Los recursos ClusterRules filtran automáticamente las reglas del proyecto, la ubicación y el clúster en los que están instalados.
  • Todos 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 evaluadores de reglas gestionadas se configuran editando el recurso OperatorConfig 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 incidencias suelen gestionarse en una herramienta de terceros, como PagerDuty.

  Puedes centralizar la gestión de alertas en 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 tareas como calcular SLOs globales en varios proyectos o evaluar reglas en clústeres de un solo Google Cloud proyecto. Te recomendamos que uses Rules y ClusterRules siempre que sea posible, ya que estos recursos ofrecen una fiabilidad superior y se adaptan mejor a los mecanismos de implementación y los modelos de tenencia comunes de Kubernetes.

Si usa el recurso GlobalRules, tenga en cuenta lo siguiente del diagrama anterior:

• Un único clúster que se ejecuta en Google Cloud se designa como clúster de evaluación de reglas global para un ámbito de métricas. Este evaluador de reglas gestionadas se ha configurado para usar scoping_project_A, que contiene los proyectos 1 y 2. Las reglas que se ejecutan 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. Para obtener más información sobre cómo definir estos campos, consulte Evaluación de reglas globales y de varios proyectos.

• Al igual que en el resto de los clústeres, este evaluador de reglas se configura con recursos Rules y ClusterRules que evalúan reglas cuyo ámbito es un espacio de nombres o un clúster. Estas reglas se filtran automáticamente al proyecto local (en este caso, Proyecto 1). Como scoping_project_A contiene el proyecto 1, las reglas y las reglas configuradas de ClusterRules se ejecutan solo en los datos del proyecto local, tal como se espera.

• Este clúster también tiene recursos GlobalRules que ejecutan reglas en scoping_project_A. Las GlobalRules no se filtran automáticamente y, por lo tanto, se ejecutan exactamente como se escriben en todos los proyectos, ubicaciones, clústeres y espacios de nombres de scoping_project_A.

• Las reglas de alertas activadas se enviarán al AlertManager autohospedado como se espera.

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

• Si tu regla GlobalRules conserva la etiqueta project_id (mediante una cláusula by(project_id)), los resultados de la regla 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 tu regla GlobalRules no conserva la etiqueta project_id (porque no usa una cláusula by(project_id)), los resultados de la regla se vuelven a escribir en Monarch con el valor project_id del clúster en el que se ejecuta el evaluador de reglas globales.

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

• Si GlobalRules conserva 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 GlobalRules 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 que conserves las etiquetas cluster y namespace en los resultados de la evaluación de reglas, a menos que el objetivo de la regla sea agregar esas etiquetas. 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.