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 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 l'esecuzione regole sui dati in un cluster. Le risorse ClusterRules devono essere applicate una volta per cluster.
Tutta la valutazione delle regole viene eseguita nell'archivio dati globale Monarch.
- Le risorse delle regole filtrano automaticamente le regole in base al progetto, alla località il cluster e lo spazio dei nomi in cui sono installati.
- 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.
Il deployment manuale di un'istanza Prometheus AlertManager viene eseguito in ogni in un cluster Kubernetes. I valutatori delle regole gestite vengono configurati modificando il valore Risorsa OperatorConfig per inviare gli avvisi attivati alla propria istanza AlertManager locale. Silenzia, ringraziamenti e i flussi di lavoro per la gestione degli incidenti sono generalmente 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 la risorsa facoltativa GlobalRules. Usa GlobalRules con parsimonia, per attività come calcolare gli SLO globali nei progetti o per valutare le regole in un singolo progetto Google Cloud. Ti consigliamo vivamente di utilizzare Rules 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 all'interno di Google Cloud è designato come di valutazione globale delle regole 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 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 all'istanza locale progetto: 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 ha anche risorse GlobalRules che eseguono regole per 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 all' AlertManager ospitato autonomamente 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 riscritti Monarca utilizzando il valore originaleproject_iddel sottostante serie temporali.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 in ambiting_project_A, devi anche eseguire manualmente e aggiungi 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 le regole globali mantengono 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 mantenere le etichette cluster e namespace in
risultati di valutazione delle regole, a meno che lo scopo della regola non sia aggregarli
le etichette. In caso contrario, le prestazioni delle query potrebbero diminuire
non ci saranno limiti di cardinalità. La rimozione di entrambe le etichette è vivamente sconsigliata.