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:
Per configurare e utilizzare un'implementazione come quella nel diagramma, tieni presente quanto segue:
Le regole vengono installate in ogni server di raccolta di Managed Service per Prometheus, come quando si utilizza Prometheus standard. La valutazione delle regole viene eseguita sui dati memorizzati localmente su ogni server. I server sono configurati per conservare i dati per un periodo di tempo sufficiente a coprire il periodo di riferimento di tutte le regole, che in genere non supera 1 ora. I risultati delle regole vengono scritti
in Monarch dopo la valutazione.
Un'istanza Prometheus AlertManager viene dispiegamento manualmente in ogni singolo
cluster. I server Prometheus vengono configurati modificando il campo alertmanager_config del file di configurazione per inviare le regole di avviso attivate all'istanza AlertManager locale. I silenzi,
gli acknowledgement 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.
Un singolo cluster in esecuzione in Google Cloud è designato come
cluster di valutazione delle regole globali per un ambito delle metriche. L'valutatore di regole autonomo viene dispiegato in questo cluster e le regole vengono installate utilizzando il formato del file di regole Prometheus standard.
Il valutatore delle regole autonomo è 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. All'account di servizio sottostante devono essere assegnate le autorizzazioni Visualizzatore Monitoring per scoping_project_A.
L'utilizzo di un valutatore delle regole globali di cui è stato eseguito il deployment autonomo può avere effetti inaspettati, a seconda che tu conservi o aggreghi le etichette project_id, location, cluster e namespace nelle regole:
Se le regole mantengono l'etichetta project_id (utilizzando
una clausola by(project_id)), i risultati delle regole 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 le regole non mantengono l'etichetta project_id (non utilizzando una clausola project_id), i risultati delle regole 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 le regole mantengono 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 le regole non mantengono l'etichetta location, i dati vengono scritti nuovamente 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, se possibile. 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 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."]]
