Evaluación de reglas y alertas con recopilación administrada
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 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 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.
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á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 tu regla de GlobalRules no conserva 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 tu recurso GlobalRules conserva 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 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.
[[["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 managed collection\n\nThis document describes a configuration for rule and alert evaluation\nin a Managed Service for Prometheus deployment that uses\n[managed collection](/stackdriver/docs/managed-prometheus/setup-managed).\n\nThe following diagram illustrates a deployment that uses multiple clusters\nin two Google Cloud projects and uses both rule and alert evaluation, as well\nas the optional GlobalRules resource:\n\nTo set up and use a deployment like the one in the diagram, note the\nfollowing:\n\n- The [managed rule evaluator](/stackdriver/docs/managed-prometheus/rules-managed) is automatically\n deployed in any cluster where managed collection is running. These\n evaluators are configured as follows:\n\n - Use [Rules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#rules) resources to run rules on data\n within a namespace. Rules resources must be applied in every namespace\n in which you want to execute the rule.\n\n - Use [ClusterRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#clusterrules) resources to run\n rules on data across a cluster. ClusterRules resources should be applied\n once per cluster.\n\n- All rule evaluation executes against the global datastore,\n Monarch.\n\n - Rules resources automatically filter rules to the project, location, cluster, and namespace in which they are installed.\n - ClusterRules resources automatically filter rules to the project, location, and cluster in which they are installed.\n - All rule results are written to Monarch after evaluation.\n- A Prometheus AlertManager instance is manually deployed in every single\n cluster. Managed rule evaluators are configured by [editing the\n OperatorConfig resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed) to send fired alerting\n rules to their local AlertManager instance. Silences, acknowledgements, and\n incident management workflows are typically handled in a third-party tool\n such as PagerDuty.\n\n You can centralize alert management across multiple clusters into a\n single AlertManager by using a Kubernetes\n [Endpoints resource](/stackdriver/docs/managed-prometheus/rules-managed#am-config-managed).\n\nThe preceding diagram also shows the optional\n[GlobalRules](https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.15.3/doc/api.md#globalrules) resource.\nUse GlobalRules very sparingly, for tasks like\ncalculating global SLOs across projects or for evaluating rules across\nclusters within a single Google Cloud project.\n**We strongly recommend using Rules and ClusterRules whenever possible**;\nthese resources provide superior reliability and are better fits for\ncommon Kubernetes deployment mechanisms and tenancy models.\n\nIf you use the GlobalRules resource, note the following from the\npreceding diagram:\n\n- One single cluster running inside Google Cloud is designated as the\n global rule-evaluation cluster for a metrics scope. This managed rule\n evaluator is configured to use scoping_project_A, which contains\n Projects 1 and 2. Rules executed against scoping_project_A automatically\n fan out to Projects 1 and 2.\n\n The underlying service account must be given the [Monitoring\n Viewer](/monitoring/access-control#mon_roles_desc) permissions for scoping_project_A.\n For additional information on how to set these fields, see\n [Multi-project and global rule evaluation](/stackdriver/docs/managed-prometheus/rules-managed#multi-project_and_global_rule_evaluation).\n- As in all other clusters, this rule evaluator is set up with Rules\n and ClusterRules resources that evaluate rules scoped to a namespace\n or cluster. These rules are automatically filtered to the *local*\n project---Project 1, in this case. Because scoping_project_A\n contains Project 1, Rules and ClusterRules-configured rules execute\n only against data from the local project as expected.\n\n- This cluster also has GlobalRules resources that execute rules against\n scoping_project_A. GlobalRules are not automatically filtered, and\n therefore GlobalRules execute exactly as written across all projects,\n locations, clusters, and namespaces in scoping_project_A.\n\n- Fired alerting rules will be sent to the self-hosted AlertManager as\n expected.\n\nUsing GlobalRules may have unexpected effects, depending on whether you\npreserve or aggregate the `project_id`, `location`, `cluster`, and\n`namespace` labels in your rules:\n\n- If your GlobalRules rule preserves 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 GlobalRules rule does not preserve the `project_id` label (by\n not using a `by(project_id)` clause), then rule results are written back\n to Monarch using the `project_id` value of the cluster\n where the 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 GlobalRules preserves the `location` label (by using a\n `by(location)` clause), then rule results are written back to\n Monarch using each original Google Cloud region from which\n the underlying time series originated.\n\n If your GlobalRules does not preserve the `location` label, then data\n is written back to the location of the cluster where the global rule\n evaluator is running.\n\nWe strongly recommend preserving the `cluster` and `namespace` labels in\nrule evaluation results unless the purpose of the rule is to aggregate away\nthose labels. Otherwise, query performance might decline and you might\nencounter cardinality limits. Removing both labels is strongly discouraged."]]
