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 progetti Google Cloud e utilizza sia la valutazione delle regole sia quella degli avvisi, nonché la risorsa facoltativa GlobalRules:
Per configurare e utilizzare un deployment come quello nel diagramma, tieni presente seguenti:
Lo strumento di valutazione delle regole gestite viene automaticamente con deployment in qualsiasi cluster in cui è in esecuzione la raccolta gestita. Questi i valutatori sono configurati nel seguente modo:
Utilizza le risorse Regole per eseguire regole sui dati all'interno di uno spazio dei nomi. Le risorse delle regole devono essere applicate a ogni spazio dei nomi in cui desideri eseguire la regola.
Utilizza le risorse ClusterRules per eseguire regole sui dati in un cluster. È necessario applicare le risorse ClusterRules una volta per cluster.
Tutta la valutazione delle regole viene eseguita nell'archivio dati 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 dispiattata manualmente in ogni singolo cluster. I valutatori delle regole gestite vengono configurati modificando il valore Risorsa OperatorConfig per inviare gli avvisi attivati alla propria 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 in più cluster in un un singolo AlertManager, utilizzando un cluster Kubernetes Risorsa endpoint.
Il diagramma precedente mostra anche Risorsa 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. Ti consigliamo vivamente di utilizzare regole e ClusterRules quando possibile; queste risorse offrono un'affidabilità superiore e sono più adatte i meccanismi di deployment e i modelli di tenancy più comuni di Kubernetes.
Se utilizzi la risorsa GlobalRules, tieni presente quanto segue dal diagramma precedente:
Un singolo cluster in esecuzione in 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.
All'account di servizio sottostante deve essere assegnata la classe Monitoring Autorizzazioni di visualizzatore per ambiting_project_A. Per ulteriori informazioni su come impostare questi campi, consulta Valutazione delle regole a livello di più progetti e globale.
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é progetto_ambito_A contiene il progetto 1, le regole e le regole configurate ClusterRules eseguite solo rispetto ai dati del progetto locale, come previsto.
Questo cluster include anche risorse GlobalRules che eseguono le regole scoping_project_A. Le regole globali non vengono filtrate automaticamente e pertanto GlobalRules vengono eseguite esattamente come sono state scritte in tutti i progetti, località, cluster e spazi dei nomi in ambiting_project_A.
Le regole di avviso attivate verranno inviate ad AlertManager autonomo come previsto.
L'utilizzo di GlobalRules potrebbe avere effetti imprevisti, a seconda che tu
conservare o aggregare project_id, location, cluster e
namespace etichette nelle regole:
Se la regola GlobalRules conserva l'etichetta
project_id(utilizzando una clausolaby(project_id)), i risultati della regola vengono scritti nuovamente in Monarch utilizzando il valoreproject_idoriginale della serie temporale sottostante.In questo scenario, devi assicurarti che l'account di servizio sottostante dispone delle autorizzazioni Writer metriche Monitoring per ciascuno progetto monitorato in ambiting_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 clausolaproject_id), i risultati della regola vengono scritti nuovamente in Monarch utilizzando il valoreproject_iddel cluster in cui è in esecuzione il valutatore delle regole globali.In questo scenario, non è necessario modificare ulteriormente l'account di servizio.
Se GlobalRules conserva l'etichetta
location(utilizzando un parametroby(location)), i risultati della regola vengono riscritti Monarca 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, le prestazioni delle query potrebbero diminuire
che incontri limiti di cardinalità. La rimozione di entrambe le etichette è vivamente sconsigliata.