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'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 in 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 dispiattata manualmente in ogni singolo cluster. I valutatori delle regole gestite vengono configurati modificando la risorsa OperatorConfig per inviare le regole di avviso attivate 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 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.
All'account di servizio sottostante devono essere assegnate le autorizzazioni Visualizzatore monitoraggio per scoping_project_A. Per ulteriori informazioni su come impostare questi campi, consulta Valutazione di regole globali e per più progetti.
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 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 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 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.by(project_id)In questo caso, non è necessario modificare ulteriormente l'account di servizio di base.
Se GlobalRules conserva l'etichetta
location(utilizzando una clausolaby(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, le prestazioni delle query potrebbero diminuire e potresti riscontrare limiti di cardinalità. La rimozione di entrambe le etichette è vivamente sconsigliata.