Creazione di criteri di avviso

Questa pagina mostra come creare criteri di avviso basati su metriche per i cluster Google Distributed Cloud. Abbiamo fornito diversi esempi scaricabili per configurare criteri di avviso per scenari comuni. Per ulteriori informazioni sui criteri di avviso basati sulle metriche, consulta Creare criteri di avviso con soglia di metrica nella documentazione di Google Cloud Observability.

Prima di iniziare

Per creare criteri di avviso, devi disporre delle autorizzazioni seguenti:

  • monitoring.alertPolicies.create
  • monitoring.alertPolicies.delete
  • monitoring.alertPolicies.update

Hai 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 gli avvisi basati su log nella documentazione di Google Cloud Observability.

Per verificare i tuoi 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 dei cluster. Con questo criterio, puoi organizzare la ricezione di una notifica ogni volta che il server API di un cluster non è disponibile.

  1. Scarica il file di configurazione dei criteri: apiserver-unavailable.json

  2. 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.

  3. Visualizza i criteri di avviso:

    Console

    1. Nella console Google Cloud, vai alla pagina Monitoring.

      Vai a Monitoring

    2. A sinistra, seleziona Avvisi.

    3. In Criteri puoi vedere un elenco dei tuoi criteri di avviso.

      Nell'elenco, seleziona Server API 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 una norma, segui gli stessi passaggi utilizzati nell'esercizio precedente:

  1. Per scaricare il file di configurazione, fai clic sul link nella colonna di destra.

  2. 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 di soglia per bilanciare il rumore e la criticità.

  3. Per creare il criterio, 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/anthos/clusters/docs/bare-metal/latest/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 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
Gestore 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 avere uno stato di arresto anomalo pod-crash-looping.json
Pod non pronto per più di un'ora (critico) Il pod è in 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 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 per il nodo supera l'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% di spazio disponibile per ciascun punto di montaggio del disco per 10 minuti node-disk-usage-high.json
L'utilizzo della memoria del nodo supera l'80% (avviso) L'utilizzo della memoria dei nodi supera l'80% del totale allocabile per 5 minuti node-memory-usage-high.json
Nodo non pronto per più di un'ora (critico) Il nodo è in stato non pronto da 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
La modifica del leader ETCD o gli errori della proposta sono troppo frequenti (avviso) Le modifiche principali o gli errori delle proposte etcd si verificano troppo spesso etcd-leader-changes-or-proposal-failures-frequent.json
Il server ETCD non è al 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, è possibile scaricare 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 sull'utilizzo di Managed Service per Prometheus per Google Distributed Cloud e la documentazione sui 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, puoi 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.