Questa pagina mostra come creare criteri di avviso per i cluster GKE su VMware.
Prima di iniziare
Per creare criteri di avviso devi disporre delle autorizzazioni seguenti:
monitoring.alertPolicies.create
monitoring.alertPolicies.delete
monitoring.alertPolicies.update
Avrai queste autorizzazioni se hai uno dei seguenti ruoli:
monitoring.alertPolicyEditor
monitoring.editor
- Editor progetto
- Proprietario progetto
Per creare un criterio di avviso basato su log utilizzando Google Cloud CLI, devi anche avere il ruolo serviceusage.serviceUsageConsumer
.
Per verificare i ruoli, vai alla pagina IAM nella console Google Cloud.
Creazione di un criterio di esempio: server API non disponibile
In questo esercizio creerai un criterio di avviso per i server API Kubernetes. Se questo criterio viene impostato, puoi scegliere di ricevere una notifica 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 appena scaricato.
Visualizza i criteri di avviso:
Console
Nella console Google Cloud, vai alla pagina Monitoring.
A sinistra, seleziona Avvisi.
In Criteri puoi vedere un elenco dei tuoi criteri di avviso.
Nell'elenco, seleziona Server API del cluster Anthos non disponibile (critico) per visualizzare i dettagli del nuovo criterio. In 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 sul criterio. 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 criteri di avviso consigliati.
Per creare un criterio, segui gli stessi passaggi utilizzati nell'esercizio precedente:
Fai clic sul link nella colonna di destra per scaricare il file di configurazione.
Facoltativamente, ottimizza le condizioni per soddisfare meglio le tue esigenze specifiche, ad esempio puoi aggiungere altri filtri per un sottoinsieme di cluster o regolare i valori della soglia per bilanciare rumore e criticità.
Esegui
gcloud alpha monitoring policies create
per creare il criterio.
Disponibilità dei componenti del piano di controllo
Nome avviso | Descrizione | Definizione dei criteri di avviso in Cloud Monitoring |
---|---|---|
Server API non disponibile (critico) | La metrica di uptime del server API non è disponibile | apiserver-unavailable.json |
Scheduler non disponibile (critico) | La metrica di uptime dello scheduler non è disponibile | scheduler-unavailable.json |
Gestione del controller non disponibile (critico) | La metrica di 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 arresto anomalo dei pod (avviso) | Il pod continua a riavviarsi e potrebbe trovarsi in un loop di arresto anomalo | pod-crash-looping.json |
Pod non pronto per più di un'ora (critico) | Il pod è in uno stato non pronto per 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 di volumi permanenti (critici) | 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 dei nodi è superiore all'80% del totale allocabile per 5 m | 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 della memoria dei nodi è superiore all'80% del totale allocabile per 5 m | node-memory-usage-high.json |
Nodo non pronto da più di un'ora (critico) | Il nodo è in uno 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 più del 20% di tutte le richieste per verbo per 15 minuti | apiserver-error-ratio-high.json |
Modifica della leader ETCD o errore della proposta troppo frequente (avviso) | Le modifiche alla leader etcd o gli errori nella proposta si verificano troppo spesso |
etcd-leader-changes-or-proposal-failures-frequent.json |
Il server ETCD non è in quorum (critico) | Nessuna proposta di server etcd impegnata 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 di etcd supera il 90% del limite |
etcd-storage-usage-high.json |
Criteri di avviso con PromQL
Le query nei criteri di avviso possono essere espresse anche in PromQL anziché in MQL.
Ad esempio, è disponibile per il download la versione PromQL del criterio API server error ratio exceeds 20
percent (critical)
: apiserver-error-ratio-high-promql.json.
Per ulteriori informazioni, consulta la documentazione relativa all'utilizzo di Managed Service per Prometheus per GKE su VMware e la documentazione relativa ai criteri di avviso con PromQL per 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, potresti ricevere notifiche via email, tramite un canale Slack o un'app mobile. Puoi scegliere i canali più adatti alle tue esigenze.
Per istruzioni su come configurare i canali di notifica, consulta Gestione dei canali di notifica.