Google Cloud Managed Service per Prometheus supporta la valutazione delle regole compatibili con Prometheus e avvisi di sicurezza. Questo documento descrive come configurare la valutazione delle regole gestite.
Valutazione delle regole
Managed Service per Prometheus fornisce un componente per la valutazione delle regole che consente di scrivere in sicurezza le regole nel contesto di un ambiente Prometheus globale , impedendoti di interferire con il traffico di altri utenti. in modo che i dati le tue organizzazioni. Il deployment del componente viene eseguito automaticamente nell'ambito dei raccolta durante l'esecuzione su cluster Kubernetes.
Puoi scrivere regole e avvisi su entrambe le metriche Managed Service per Prometheus e metriche di Cloud Monitoring. Devi utilizzare Risorsa GlobalRules durante la scrittura delle regole per Cloud Monitoring metriche di valutazione.
Regole
Il valutatore delle regole gestite utilizza le regole risorsa su e configurare le regole di registrazione e avviso. Di seguito è riportato un esempio di risorsa di regole:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Il formato dell'elemento .spec.groups
è identico a quello di Prometheus a monte
Array rule_group
. Avvisi e registrazione
Le regole definite in Rules
hanno come ambito project_id
, cluster
e namespace
della risorsa. Ad esempio, la regola job:up:sum
nella risorsa riportata sopra
query in modo efficace
sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"})
.
Questa garanzia assicura che le regole di avviso o registrazione non vengano accidentalmente
e valutano le metriche
di applicazioni che potresti anche non conoscere.
Per applicare le regole di esempio al cluster, esegui questo comando:
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/examples/rules.yaml
Dopo alcuni minuti, diventa disponibile la metrica job:up:sum
.
Viene avviato anche l'avviso AlwaysFiring
. Per informazioni su
su come inviare avvisi a AlertManager, vedi
Configurazione di Alertmanager.
Il parametro ClusterRules e
Le risorse GlobalRules offrono lo stesso
come risorsa Rules
, ma applicano le regole ad ambiti più ampi.
ClusterRules seleziona i dati usando le etichette project_id
e cluster
,
e GlobalRules selezionano tutti i dati nell'ambito delle metriche sottoposte a query senza
delle etichette.
Per la documentazione di riferimento su tutti i servizi Managed Service per Prometheus di risorse personalizzate, consulta riferimento prometheus-engine/doc/api.
Conversione dalle regole di Prometheus alle regole
La risorsa Rules (Regole) fornisce un'interfaccia compatibile con le regole Prometheus per: Offrire un percorso di migrazione senza soluzione di continuità per l'integrazione delle regole esistenti e la valutazione delle regole gestite. Puoi includere le regole esistenti in una sezione Regole risorsa. Ad esempio, di seguito è riportata una regola di Prometheus:
groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
La risorsa Regole corrispondente, con la versione originale di Prometheus in grassetto, segue:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
ClusterRules
Puoi utilizzare la risorsa ClusterRules
per configurare la registrazione
regole di avviso in grado di valutare tutte le serie temporali inviate
Managed Service per Prometheus da tutti gli spazi dei nomi di un determinato cluster.
Le specifiche sono identiche a quelle di Rules
. La precedente
regola di Prometheus di esempio diventa la seguente
ClusterRules
risorsa:
apiVersion: monitoring.googleapis.com/v1 kind: ClusterRules metadata: name: example-clusterrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Ti consigliamo di utilizzare le risorse ClusterRules solo su metriche orizzontali, come quelle generate da un mesh di servizi. Per le metriche dei singoli deployment, utilizzare le risorse delle regole per garantire che la valutazione non includa errori e i dati di Google Cloud.
GlobalRules
Puoi utilizzare la risorsa GlobalRules
per configurare la registrazione
regole di avviso in grado di valutare tutte le serie temporali inviate
Managed Service per Prometheus in tutti i progetti in un ambito delle metriche.
Le specifiche sono identiche a quelle di Rules
. La precedente
regola di Prometheus di esempio diventa la seguente
GlobalRules
risorsa:
apiVersion: monitoring.googleapis.com/v1 kind: GlobalRules metadata: name: example-globalrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Poiché le metriche di Cloud Monitoring non rientrano nell'ambito di una dello spazio dei nomi o di cluster, devi utilizzare la risorsa GlobalRules quando scrivi le regole o avvisi per le metriche di Cloud Monitoring. È obbligatorio anche utilizzare GlobalRules quando ricevi avvisi sulle metriche di sistema di Google Kubernetes Engine.
Se la regola non conserva il valore project_id
o location
, vengono utilizzati per impostazione predefinita i valori del cluster.
Per le metriche di Managed Service per Prometheus, ti consigliamo di utilizzare
GlobalRules solo per quei rari casi d'uso in cui un avviso potrebbe richiedere dati tra
in tutti i cluster contemporaneamente. Per le metriche dei singoli deployment, usa le regole
alle risorse ClusterRules per una maggiore affidabilità e per garantire che la valutazione
non include dati indesiderati. Ti consigliamo vivamente di conservare cluster
e namespace
etichetta nei risultati di valutazione delle regole, a meno che lo scopo della regola
consiste nell'aggregare le etichette, altrimenti le prestazioni delle query potrebbero diminuire
potresti riscontrare limiti di cardinalità. La rimozione di entrambe le etichette è fortemente
scoraggiati.
Valutazione di regole globali e multiprogetto
Quando viene eseguito il deployment su Google Kubernetes Engine, il valutatore delle regole utilizza Progetto Google Cloud associato al cluster, che il valutatore delle regole automaticamente. Per valutare le regole che riguardano i progetti, devi configurare il valutatore delle regole che esegue la risorsa GlobalRules per utilizzare un progetto un ambito delle metriche multiprogetto. Puoi farlo in due modi:
- Posiziona la risorsa GlobalRules in un progetto con metriche multiprogetto l'ambito di attività.
- Imposta il campo
queryProjectID
in OperatorConfig per utilizzare un progetto con un ambito delle metriche multiprogetto.
Devi anche aggiornare le autorizzazioni dell'account di servizio utilizzato lo strumento di valutazione delle regole (che in genere è l'account di servizio predefinito sul nodo). in modo che l'account di servizio possa leggere dal progetto di definizione dell'ambito e scrivere su tutti a progetti monitorati nell'ambito delle metriche.
Se l'ambito delle metriche contiene tutti i progetti, le regole valutano a livello globale. Per saperne di più, consulta Ambiti delle metriche.
Avvisi mediante le metriche di Cloud Monitoring
Puoi utilizzare la risorsa GlobalRules per inviare avvisi su Google Cloud metriche di sistema usando PromQL. Per istruzioni su come creare un una query valida, consulta le metriche di PromQL per Cloud Monitoring.
Configurazione di regole e avvisi mediante Terraform
Puoi automatizzare la creazione e la gestione di regole, ClusterRules e
Risorse GlobalRules usando lo strumento Terraform kubernetes_manifest
risorsa o kubectl_manifest
Tipo di risorsa Terraform, uno di
che consente di specificare risorse personalizzate arbitrarie.
Per informazioni generali sull'utilizzo di Google Cloud con Terraform, consulta Terraform con Google Cloud.
Fornisci le credenziali in modo esplicito
Durante l'esecuzione su GKE, il valutatore recupera automaticamente le credenziali dall'ambiente in base l'account di servizio del nodo. Nei cluster Kubernetes non GKE, le credenziali devono essere fornita tramite la risorsa OperatorConfig in dello spazio dei nomi gmp-public,
Imposta il contesto sul progetto di destinazione:
gcloud config set project PROJECT_ID
Crea un account di servizio:
gcloud iam service-accounts create gmp-test-sa
Concedi le autorizzazioni richieste all'account di servizio:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Crea e scarica una chiave per l'account di servizio:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
Aggiungi il file della chiave come secret al cluster non GKE:
kubectl -n gmp-public create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Apri la risorsa OperatorConfig per la modifica:
kubectl -n gmp-public edit operatorconfig config
Aggiungi il testo visualizzato in grassetto alla risorsa:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: credentials: name: gmp-test-sa key: key.json
Assicurati di aggiungere anche queste credenziali alla sezionecollection
per far sì che la raccolta gestita funzioni.Salva il file e chiudi l'editor. Una volta applicata la modifica, vengono ricreati e avviano l'autenticazione nella metrica con l'account di servizio specificato.
Valutazione delle regole di scalabilità
Il valutatore delle regole viene eseguito come un deployment di replica singola con risorsa fissa richieste e limiti. Potrebbero verificarsi interruzioni del carico di lavoro, ad esempio come OOM Eliminato durante la valutazione di un elevato numero di regole. Per mitigare questo problema, puoi eseguire il deployment
VerticalPodAutoscaler
per scalare verticalmente il deployment. Innanzitutto, assicurati che Scalabilità automatica pod verticale sia abilitata sul tuo cluster Kubernetes. Poi applica unVerticalPodAutoscaler
come la seguente:apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: rule-evaluator namespace: gmp-system spec: resourcePolicy: containerPolicies: - containerName: evaluator controlledResources: - memory maxAllowed: memory: 4Gi minAllowed: memory: 16Mi mode: Auto targetRef: apiVersion: apps/v1 kind: Deployment name: rule-evaluator updatePolicy: updateMode: Auto
Puoi verificare che il gestore della scalabilità automatica funzioni controllando lo stato del gestore della scalabilità automatica:
kubectl get vpa --namespace gmp-system rule-evaluator
Se il gestore della scalabilità automatica funziona, segnala di aver calcolato la risorsa per il carico di lavoro nel colonna:
NAME MODE CPU MEM PROVIDED AGE rule-evaluator Auto 2m 11534336 True 30m
Configurazioni di compressione
Se hai molte risorse di regole, potresti esaurire lo spazio ConfigMap. Per risolvere il problema questo, attiva la compressione
gzip
nel tuo Risorsa OperatorConfig:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config features: config: compression: gzip
Configurazione Alertmanager
Puoi utilizzare la risorsa OperatorConfig per configurare il valutatore delle regole gestito in modo che invii avvisi a Alertmanager Prometheus. Puoi inviare avvisi a Alertmanager gestito di cui è stato eseguito il deployment automatico oltre che a qualsiasi altro Alertmanager di cui è stato eseguito il deployment autonomo.
Gestore avvisi gestito
Managed Service per Prometheus esegue il deployment di un'istanza gestita di Alertmanager, a cui i valutatori delle regole sono automaticamente configurati per inoltrare gli avvisi. Per impostazione predefinita, questa configurazione è impostata con un secret Kubernetes denominato un file di configurazione Alertmanager.
Per abilitare e configurare il reporting per l'istanza Alertmanager di cui è stato eseguito il deployment, procedi nel seguente modo:
Crea un file di configurazione locale contenente le tue impostazioni di Alertmanager (vedi i modelli di configurazione di esempio):
touch alertmanager.yaml
Aggiorna il file con le impostazioni di Alertmanager che preferisci. e creerai un secret denominato
alertmanager
nello spazio dei nomigmp-public
:kubectl create secret generic alertmanager \ -n gmp-public \ --from-file=alertmanager.yaml
Dopo qualche istante, Managed Service per Prometheus recupera il nuovo config Secret e abilita Alertmanager gestito con le tue impostazioni.
Personalizzazione del nome del secret di configurazione
Alertmanager gestito supporta anche i nomi dei secret personalizzati per il caricamento della configurazione. Questa funzionalità è utile quando hai più secret di configurazione e vuoi alla tua istanza Alertmanager per passare tra le configurazioni corrispondenti. Ad esempio, potresti voler cambiare i canali di notifica degli avvisi in base ai turni di chiamata, oppure passa a una configurazione sperimentale Alertmanager per testare una nuova route di avviso.
Per specificare un nome del secret non predefinito utilizzando la risorsa OperatorConfig, procedi nel seguente modo:
Crea un secret dal tuo file di configurazione Alertmanager locale:
kubectl create secret generic SECRET_NAME \ -n gmp-public \ --from-file=FILE_NAME
Apri la risorsa OperatorConfig per la modifica:
kubectl -n gmp-public edit operatorconfig config
Per abilitare i report Alertmanager gestiti, modifica la risorsa modificando la sezione
managedAlertmanager
, come mostrato nel seguente testo in grassetto:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: configSecret: name: SECRET_NAME key: FILE_NAME
Se devi apportare modifiche alla configurazione Alertmanager, puoi quindi modificare la configurazione per questo Alertmanager aggiornando il campo Secret che hai creato in precedenza.
Personalizzazione dell'URL esterno
Puoi configurare l'URL esterno per AlertManager gestito in modo che le notifiche possono fornire un link di callback all'UI per gli avvisi. Equivale a utilizzare Prometheus Alertmanager upstream
--web.external-url
flag.apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: externalURL: EXTERNAL_URL
Gestore avvisi con deployment autonomo
Per configurare il valutatore delle regole per un Alertmanager di cui è stato eseguito il deployment autonomo:
Apri la risorsa OperatorConfig per la modifica:
kubectl -n gmp-public edit operatorconfig config
Configura la risorsa per inviare avvisi al servizio Alertmanager:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: alerting: alertmanagers: - name: SERVICE_NAME namespace: SERVICE_NAMESPACE port: PORT_NAME
Se Alertmanager si trova in un cluster diverso rispetto al valutatore delle regole, potresti dover configurare una risorsa endpoint. Ad esempio, se OperatorConfig indica che gli endpoint Alertmanager possono essere trovato nell'oggetto Endpoints
ns=alertmanager/name=alertmanager
, puoi manualmente o in modo programmatico, crea personalmente questo oggetto e compilalo con IP raggiungibili dall'altro cluster. La Sezione di configurazione AlertmanagerEndpoints fornisce opzioni per la configurazione dell'autorizzazione, se necessario.