Valutazione di regole e avvisi con la raccolta gestita
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento descrive una configurazione per la valutazione delle regole e degli avvisi
in un deployment di Managed Service per Prometheus che utilizza
la raccolta gestita.
Il seguente diagramma illustra un deployment che utilizza più cluster
in due Google Cloud progetti e utilizza sia la valutazione delle regole sia quella degli avvisi, nonché
la risorsa facoltativa GlobalRules:
Per configurare e utilizzare un'implementazione come quella nel diagramma, tieni presente quanto segue:
L'valutatore delle regole gestite viene eseguito automaticamente in qualsiasi cluster in cui è in esecuzione la raccolta gestita. Questi valutatori sono configurati come segue:
Utilizza le risorse Regole per eseguire regole sui dati
all'interno di uno spazio dei nomi. Le risorse delle regole devono essere applicate in ogni spazio dei nomi
in cui vuoi eseguire la regola.
Utilizza le risorse ClusterRules per eseguire
regole sui dati di un cluster. Le risorse ClusterRules devono essere applicate
una volta per cluster.
Tutta la valutazione delle regole viene eseguita nel data store globale Monarch.
Le risorse di regole filtrano automaticamente le regole in base al progetto, alla località, al cluster e allo spazio dei nomi in cui sono installate.
Le risorse ClusterRules filtrano automaticamente le regole in base al progetto, alla località e al cluster in cui sono installate.
Tutti i risultati delle regole vengono scritti in Monarch dopo la valutazione.
Un'istanza Prometheus AlertManager viene dispiegamento manualmente in ogni singolo
cluster. I valutatori delle regole gestite vengono configurati modificando la risorsa OperatorConfig per inviare le regole di avviso attivate all'istanza AlertManager locale. I silenzi, i riconoscimenti e i flussi di lavoro per la gestione degli incidenti vengono in genere gestiti in uno strumento di terze parti come PagerDuty.
Puoi centralizzare la gestione degli avvisi su più cluster in un singolo AlertManager utilizzando una risorsa Endpoints di Kubernetes.
Il diagramma precedente mostra anche la risorsa facoltativa GlobalRules.
Utilizza GlobalRules con parsimonia, ad esempio per calcolare SLO globali in più progetti o per valutare le regole in più cluster all'interno di un singolo progetto. Google Cloud
Consigliamo vivamente di utilizzare Rules e ClusterRules, se possibile; queste risorse offrono un'affidabilità superiore e sono più adatte ai meccanismi di deployment e ai modelli di tenancy comuni di Kubernetes.
Se utilizzi la risorsa GlobalRules, tieni presente quanto segue dal diagramma precedente:
Un singolo cluster in esecuzione all'interno di Google Cloud è designato come
cluster di valutazione delle regole globale per un ambito delle metriche. Questo valutatore di regole gestite è configurato per utilizzare scoping_project_A, che contiene i progetti 1 e 2. Le regole eseguite in base a scoping_project_A vengono distribuite automaticamente ai progetti 1 e 2.
Come in tutti gli altri cluster, questo valutatore delle regole è configurato con le risorse Rules
e ClusterRules che valutano le regole con ambito a uno spazio dei nomi
o a un cluster. Queste regole vengono filtrate automaticamente in base al progetto locale, in questo caso il progetto 1. Poiché scoping_project_A contiene il progetto 1, le regole e le regole configurate con ClusterRules vengono eseguite solo sui dati del progetto locale, come previsto.
Questo cluster contiene anche risorse GlobalRules che eseguono regole per
scoping_project_A. Le regole GlobalRules non vengono filtrate automaticamente e quindi vengono eseguite esattamente come scritte in tutti i progetti, le località, i cluster e gli spazi dei nomi in scoping_project_A.
Le regole di avviso attivate verranno inviate ad AlertManager autonomo come previsto.
L'utilizzo di GlobalRules può avere effetti imprevisti, a seconda che tu scelga di conservare o aggregare le etichette project_id, location, cluster e namespace nelle tue regole:
Se la regola GlobalRules conserva l'etichetta project_id (utilizzando
una clausola by(project_id)), i risultati della regola vengono scritti nuovamente in
Monarch utilizzando il valore project_id originale della serie temporale sottostante.
In questo scenario, devi assicurarti che l'account di servizio di base abbia le autorizzazioni Monitoring Metric Writer per ogni progetto monitorato in scoping_project_A. Se aggiungi un nuovo progetto monitorato a scoping_project_A, devi anche aggiungere manualmente una nuova autorizzazione all'account di servizio.
Se la regola GlobalRules non conserva l'etichetta project_id (non utilizzando una clausola project_id), i risultati della regola vengono scritti nuovamente in Monarch utilizzando il valore project_id del cluster in cui è in esecuzione il valutatore delle regole globali.by(project_id)
In questo caso, non è necessario modificare ulteriormente l'account di servizio di base.
Se GlobalRules conserva l'etichetta location (utilizzando una clausola by(location)), i risultati delle regole vengono riscritti in Monarch utilizzando ogni regione Google Cloud originale da cui ha avuto origine la serie temporale sottostante.
Se GlobalRules non conserva l'etichetta location, i dati vengono riscritti nella posizione del cluster in cui viene eseguito il valutatore delle regole globali.
Ti consigliamo vivamente di conservare le etichette cluster e namespace nei risultati di valutazione delle regole, a meno che lo scopo della regola non sia eliminare queste etichette. In caso contrario, il rendimento delle query potrebbe diminuire e potresti riscontrare limiti di cardinalità. La rimozione di entrambe le etichette è vivamente sconsigliata.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
