Evaluación de reglas y alertas con recopilación autoimplementada
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
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 autoimplementada.
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:
Para configurar y usar una implementación como la del diagrama, ten en cuenta lo siguiente:
Las reglas se instalan dentro de cada servidor de recopilación de Managed Service para Prometheus, tal como lo hacen cuando se usa Prometheus estándar. La evaluación de las reglas se ejecuta en los datos almacenados de forma local en cada servidor. Los servidores están configurados para retener los datos durante el tiempo suficiente a fin de cubrir el período de visualización de todas las reglas, que generalmente no supera 1 hora. Los resultados de las 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 servidores de Prometheus se configuran mediante la edición del campo alertmanager_config del archivo de configuración para enviar reglas de alerta 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.
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. El evaluador de reglas independiente se implementa en ese clúster y las reglas se instalan con el formato de archivo de regla 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 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.
El uso de un evaluador de reglas global autoimplementado puede tener efectos inesperados, según si conservas o agregas las etiquetas project_id, location, cluster y namespace en tu reglas:
Si tus reglas conservan 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 original de project_id de 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 tus reglas no conservan la etiqueta project_id (porque no se usa una cláusula by(project_id)), los resultados de la regla se vuelven a escribir en Monarch mediante el valor project_id del 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 tus reglas conservan la etiqueta location (porque se usa una cláusula by(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 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 global.
Recomendamos encarecidamente conservar 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 encontrarte con límites de cardinalidad. No se recomienda quitar ambas etiquetas.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Evaluation of rules and alerts with self-deployed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[self-deployed collection](/stackdriver/docs/managed-prometheus/setup-unmanaged).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- Rules are installed within each Managed Service for Prometheus collection\n server, just as they are when using standard Prometheus. Rule evaluation\n executes against the data stored locally on each server. Servers are\n configured to retain data long enough to cover the lookback period of all\n rules, which is typically no more than 1 hour. Rule results are written\n to Monarch after evaluation.\n\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Prometheus servers are configured by [editing the\n `alertmanager_config` field of the configuration file](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged) to send\n fired alerting rules to their local AlertManager instance. Silences,\n acknowledgements, and incident management workflows are typically\n handled in a third-party tool such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged).\n- One single cluster running inside Google Cloud is designated as the\n global rule evaluation cluster for a metrics scope. The [standalone\n rule evaluator](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged) is deployed in that cluster and rules are\n installed using the standard Prometheus rule-file format.\n\n The standalone rule evaluator is configured to use scoping_project_A,\n which contains Projects 1 and 2. Rules executed against scoping_project_A\n automatically fan out to Projects 1 and 2. The underlying service account\n must be given the [Monitoring Viewer](/monitoring/access-control#mon_roles_desc) permissions\n for scoping_project_A.\n\n The rule evaluator is configured to send alerts to the local Prometheus\n Alertmanager by using the [`alertmanager_config` field of the configuration\n file](/stackdriver/docs/managed-prometheus/rules-unmanaged#eval-rules-unmanaged).\n\nUsing a self-deployed global rule evaluator may have unexpected\neffects, depending on whether you preserve or aggregate the `project_id`,\n`location`, `cluster`, and `namespace` labels in your rules:\n\n- If your rules preserve the `project_id` label (by using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the original `project_id` value of the underlying\n time series.\n\n In this scenario, you need to ensure the underlying service account\n has the [Monitoring Metric Writer](/monitoring/access-control#mon_roles_desc) permissions for each\n monitored project in scoping_project_A. If you add a new\n monitored project to scoping_project_A, then you must also manually\n add a new permission to the service account.\n- If your rules do not preserve the `project_id` label (by not using\n a `by(project_id)` clause), then rule results are written back to\n Monarch using the `project_id` value of the cluster where the\n global rule evaluator is running.\n\n In this scenario, you do not need to further modify the underlying\n service account.\n- If your rules preserve the `location` label (by using a `by(location)`\n clause), then rule results are written back to Monarch\n using each original Google Cloud region from which the underlying\n time series originated.\n\n If your rules do not preserve the `location` label, then data is written\n back to the location of the cluster where the global rule evaluator\n is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels\nin rule evaluation results whenever possible. Otherwise, query performance\nmight decline and you might encounter cardinality limits. Removing both\nlabels is strongly discouraged."]]
