Questa pagina mostra come creare criteri di avviso basati su metriche per i cluster Google Distributed Cloud. Abbiamo fornito diversi esempi scaricabili per aiutarti a configurare i criteri di avviso per scenari comuni. Per saperne di più sulle policy di avviso basate su metriche, consulta Creare policy di avviso basate su soglie delle metriche nella documentazione di Google Cloud Observability.
Prima di iniziare
Per creare policy di avviso, devi disporre delle seguenti autorizzazioni:
monitoring.alertPolicies.create
monitoring.alertPolicies.delete
monitoring.alertPolicies.update
Disponi di queste autorizzazioni se hai uno dei seguenti ruoli:
monitoring.alertPolicyEditor
monitoring.editor
- Editor progetto
- Proprietario progetto
Se vuoi creare criteri di avviso basati su log utilizzando
Google Cloud CLI, devi disporre anche del ruolo serviceusage.serviceUsageConsumer
. Per istruzioni su come configurare i criteri di avviso basati su log, consulta
Configurare avvisi basati su log
nella documentazione di Google Cloud Observability.
Per controllare i tuoi ruoli, vai alla pagina IAM nella console Google Cloud .
Creazione di una policy di esempio: server API non disponibile
In questo esercizio, creerai un criterio di avviso per i server API Kubernetes dei cluster. Con questo criterio in vigore, puoi organizzare la ricezione di notifiche ogni volta che il server API di un cluster non è disponibile.
Scarica il file di configurazione dei criteri: apiserver-unavailable.json
Crea il criterio:
gcloud alpha monitoring policies create --policy-from-file=POLICY_CONFIG
Sostituisci POLICY_CONFIG con il percorso del file di configurazione che hai appena scaricato.
Per visualizzare le policy di avviso:
Console
Nella console Google Cloud , vai alla pagina Monitoring.
A sinistra, seleziona Avvisi.
Nella sezione Policy puoi visualizzare un elenco delle tue policy di avviso.
Nell'elenco, seleziona Server API del cluster Anthos non disponibile (critico) per visualizzare i dettagli della nuova policy. Nella sezione Condizioni, puoi visualizzare una descrizione delle norme. Ad esempio:
Policy violates when ANY condition is met Anthos cluster API server uptime is absent for 5m
gcloud
gcloud alpha monitoring policies list
L'output mostra informazioni dettagliate sulle norme. Ad esempio:
combiner: OR conditions: - conditionAbsent: aggregations: - alignmentPeriod: 60s crossSeriesReducer: REDUCE_MEAN groupByFields: - resource.label.project_id - resource.label.location - resource.label.cluster_name - resource.label.namespace_name - resource.label.container_name - resource.label.pod_name perSeriesAligner: ALIGN_MAX duration: 300s filter: resource.type = "k8s_container" AND metric.type = "kubernetes.io/anthos/container/uptime" AND resource.label."container_name"=monitoring.regex.full_match("kube-apiserver") trigger: count: 1 displayName: Anthos cluster API server uptime is absent for 5m name: projects/…/alertPolicies/…/conditions/… displayName: Anthos cluster API server unavailable (critical) enabled: true mutationRecord: mutateTime: … mutatedBy: … name: projects/…/alertPolicies/…
Creazione di criteri di avviso aggiuntivi
Questa sezione fornisce descrizioni e file di configurazione per un insieme di norme di avviso consigliate.
Per creare una norma, segui gli stessi passaggi utilizzati nell'esercizio precedente:
Per scaricare il file di configurazione, fai clic sul link nella colonna a destra.
Se vuoi, puoi perfezionare le condizioni per adattarle meglio alle tue esigenze specifiche. Ad esempio, puoi aggiungere filtri aggiuntivi per un sottoinsieme di cluster o modificare i valori di soglia per trovare un equilibrio tra rumore e criticità.
Per creare la policy, esegui
gcloud alpha monitoring policies create
.
Puoi scaricare e installare tutti gli esempi di criteri di avviso descritti in questo documento con il seguente script:
# 1. Create a directory named alert_samples:
mkdir alert_samples && cd alert_samples
declare -a alerts=("apiserver-unavailable.json" "controller-manager-unavailable.json" "scheduler-unavailable.json" \
"pod-crash-looping.json" "pod-not-ready-1h.json" "container-cpu-usage-high-reaching-limit.json" \
"container-memory-usage-high-reaching-limit.json" "persistent-volume-usage-high.json" "node-cpu-usage-high.json" \
"node-disk-usage-high.json" "node-memory-usage-high.json" "node-not-ready-1h.json" "apiserver-error-ratio-high.json" \
"etcd-leader-changes-or-proposal-failures-frequent.json" "etcd-server-not-in-quorum.yaml" "etcd-storage-usage-high.json")
# 2. Download all alert samples into the alert_samples/ directory:
for x in "${alerts[@]}"
do
wget https://cloud.google.com/kubernetes-engine/distributed-cloud/bare-metal/docs/samples/${x}
done
# 3. (optional) Uncomment and provide your project ID to set the default project
# for gcloud commands:
# gcloud config set project <PROJECT_ID>
# 4. Create alert policies for each of the downloaded samples:
for x in "${alerts[@]}"
do
gcloud alpha monitoring policies create --policy-from-file=${x}
done
Disponibilità dei componenti del control plane
Nome avviso | Descrizione | Definizione dei criteri di avviso in Cloud Monitoring |
---|---|---|
Server API non disponibile (critico) | La metrica Uptime del server API non è disponibile | apiserver-unavailable.json |
Scheduler non disponibile (critico) | La metrica sull'uptime dello scheduler non è disponibile | scheduler-unavailable.json |
Gestore del controller non disponibile (critico) | La metrica relativa all'uptime del gestore del controller non è disponibile | controller-manager-unavailable.json |
Sistema Kubernetes
Nome avviso | Descrizione | Definizione dei criteri di avviso in Cloud Monitoring |
---|---|---|
Loop di arresto anomalo del pod (avviso) | Il pod continua a riavviarsi e potrebbe essere in uno stato di loop di arresto anomalo | pod-crash-looping.json |
Pod non pronto da più di un'ora (critico) | Il pod è in uno stato non pronto da più di un'ora | pod-not-ready-1h.json |
L'utilizzo della CPU del container supera l'80% (avviso) | L'utilizzo della CPU del container supera l'80% del limite | container-cpu-usage-high-reaching-limit.json |
L'utilizzo della memoria del container supera l'85% (avviso) | L'utilizzo della memoria del container supera l'85% del limite | container-memory-usage-high-reaching-limit.json |
Utilizzo elevato del volume permanente (critico) | Il volume permanente rivendicato ha meno del 3% di spazio libero | persistent-volume-usage-high.json |
L'utilizzo della CPU del nodo supera l'80% (avviso) | L'utilizzo della CPU del nodo è superiore all'80% del totale allocabile per 5 minuti | node-cpu-usage-high.json |
L'utilizzo del disco del nodo supera l'85% (avviso) | Meno del 15% è libero per punto di montaggio del disco per 10 minuti | node-disk-usage-high.json |
L'utilizzo della memoria dei nodi supera l'80% (avviso) | L'utilizzo di memoria del nodo supera l'80% del totale allocabile per 5 minuti | node-memory-usage-high.json |
Il nodo non è pronto da più di un'ora (critico) | Il nodo è in stato non pronto per più di un'ora | node-not-ready-1h.json |
Prestazioni di Kubernetes
Nome avviso | Descrizione | Definizione dei criteri di avviso in Cloud Monitoring |
---|---|---|
Il rapporto di errori del server API supera il 20% (critico) | Il server API restituisce errori 5xx o 429 su oltre il 20% di tutte le richieste per verbo per 15 minuti | apiserver-error-ratio-high.json |
Modifica del leader ETCD o errore di proposta troppo frequente (avviso) | Il leader di etcd cambia o le proposte non vanno a buon fine troppo spesso |
etcd-leader-changes-or-proposal-failures-frequent.json |
Il server ETCD non è in quorum (critico) | Nessuna proposta di server etcd eseguita per 5 minuti, quindi potrebbe aver perso il quorum |
etcd-server-not-in-quorum.yaml |
Lo spazio di archiviazione ETCD supera il limite del 90% (avviso) | L'utilizzo dello spazio di archiviazione etcd supera il 90% del limite |
etcd-storage-usage-high.json |
Policy di avviso con PromQL
Le query nelle norme di avviso possono essere espresse anche in PromQL anziché in MQL.
Ad esempio, la versione PromQL del criterio API server error ratio exceeds 20
percent (critical)
è disponibile per il download: apiserver-error-ratio-high-promql.json.
Per saperne di più, consulta la Utilizzo di Managed Service per Prometheus per la documentazione di Google Distributed Cloud e le Norme di avviso con PromQL per la documentazione di Cloud Monitoring.
Ricevere notifiche
Dopo aver creato un criterio di avviso, puoi definire uno o più canali di notifica per il criterio. Esistono diversi tipi di canali di notifica. Ad esempio, puoi ricevere notifiche via email, su un canale Slack o su un'app mobile. Puoi scegliere i canali più adatti alle tue esigenze.
Per istruzioni su come configurare i canali di notifica, vedi Gestione dei canali di notifica.