Questa pagina è stata tradotta dall'API Cloud Translation.

Percorso di apprendimento: applicazioni scalabili - Monitoraggio con Prometheus

Questo insieme di tutorial è rivolto agli amministratori IT e agli operatori che vogliono eseguire il deployment, eseguire e gestire ambienti applicativi moderni eseguiti sulla versione Google Kubernetes Engine (GKE) Enterprise. Man mano che procedi in questo insieme di tutorial, imparerai a configurare monitoraggio e avvisi, scalare i carichi di lavoro e simulare errori, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

Crea un cluster ed esegui il deployment di un'applicazione di esempio
Monitoraggio con Google Cloud Managed Service per Prometheus (questo tutorial)
Scala i carichi di lavoro
Simula un errore

Panoramica e obiettivi

L'applicazione di esempio di Cymbal Bank utilizzata in questo set di tutorial è composta da una serie di microservizi eseguiti nel cluster GKE. Eventuali problemi con uno di questi servizi potrebbero comportare un'esperienza negativa per i clienti della banca, ad esempio l'impossibilità di accedere all'applicazione della banca. Scoprire i problemi dei servizi nel più breve tempo possibile ti consente di iniziare rapidamente a risolverli e alla risoluzione dei problemi.

In questo tutorial imparerai a monitorare i carichi di lavoro in un cluster GKE utilizzando Google Cloud Managed Service per Prometheus e Cloud Monitoring. Imparerai come completare le attività seguenti:

Crea un webhook Slack per Alertmanager.
Configura Prometheus per monitorare lo stato di un'applicazione di esempio basata su microservizi.
Simula un'interruzione ed esamina gli avvisi inviati utilizzando il webhook Slack.

Costi

L'abilitazione di GKE Enterprise e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano l'addebito di addebiti per cluster per GKE Enterprise su Google Cloud, come indicato nella nostra pagina Prezzi, fino a quando non disattivi GKE Enterprise o elimini il progetto.

Sei inoltre responsabile di altri costi di Google Cloud sostenuti durante l'esecuzione dell'applicazione di esempio Cymbal Bank, ad esempio gli addebiti per le VM di Compute Engine e Cloud Monitoring.

Prima di iniziare

Per scoprire come monitorare i carichi di lavoro, devi completare il primo tutorial per creare un cluster GKE che utilizzi Autopilot ed eseguire il deployment dell'applicazione di esempio basata su microservizi di Cymbal Bank.

Ti consigliamo di completare questo insieme di tutorial per Cymbal Bank in ordine. Man mano che procedi nella serie di tutorial, acquisisci nuove competenze e utilizzi prodotti e servizi Google Cloud aggiuntivi.

Per mostrare un esempio di come un cluster GKE Autopilot può utilizzare Google Cloud Managed Service per Prometheus per generare messaggi per una piattaforma di comunicazione, questo tutorial utilizza Slack. Nei tuoi deployment di produzione, puoi utilizzare lo strumento di comunicazione preferito della tua organizzazione per elaborare e consegnare i messaggi quando si verifica un problema nel cluster GKE.

Partecipa a un'area di lavoro Slack registrandoti con la tua email o utilizzando un invito inviato da un amministratore di Workspace.

Nota: se non sei un amministratore della tua area di lavoro Slack, potresti dover ottenere l'approvazione di un amministratore di Workspace prima che venga eseguito il deployment dell'app nell'area di lavoro.

crea un'applicazione Slack

Una parte importante della configurazione del monitoraggio è assicurarsi di ricevere una notifica quando si verificano eventi strategici, come le interruzioni. Un metodo comune consiste nell'inviare notifiche a uno strumento di comunicazione come Slack, che è quello che utilizzerai in questo tutorial. Slack offre una funzionalità webhook che consente alle applicazioni esterne, come i deployment di produzione, di generare messaggi. Puoi utilizzare altri strumenti di comunicazione nella tua organizzazione per elaborare e recapitare i messaggi quando il cluster GKE ha un problema.

I cluster GKE che usano Autopilot includono un'istanza di Google Cloud Managed Service per Prometheus. Questa istanza può generare avvisi quando succede qualcosa alle tue applicazioni. Questi avvisi possono quindi utilizzare un webhook Slack per inviare un messaggio alla tua area di lavoro Slack e ricevere notifiche dei prompt in caso di problemi.

Per configurare le notifiche Slack basate su avvisi generati da Prometheus, devi creare un'applicazione Slack, attivare i webhook in entrata per l'applicazione e installarla in un'area di lavoro Slack.

Accedi a Slack utilizzando il nome della tua area di lavoro e le credenziali del tuo account Slack.
Creare una nuova app Slack
1. Nella finestra di dialogo Crea un'app, fai clic su Da zero.
2. Specifica un Nome app e scegli la tua area di lavoro Slack.
3. Fai clic su Create App (Crea app).
4. In Aggiungi funzioni e funzionalità, fai clic su Webhook in entrata.
5. Fai clic sul pulsante di attivazione/disattivazione Attiva webhook in entrata.
6. Nella sezione URL webhook per la tua area di lavoro, fai clic su Aggiungi nuovo webhook a Workspace.
7. Nella pagina di autorizzazione che si apre, seleziona un canale per ricevere le notifiche.
8. Fai clic su Consenti.
9. Un webhook per la tua applicazione Slack è visualizzato nella sezione URL webhook per la tua area di lavoro. Salva l'URL per un secondo momento.

Configura AlertManager

In Prometheus, Alertmanager elabora gli eventi di monitoraggio generati dai deployment. Alertmanager può saltare eventi duplicati, eventi correlati ai gruppi e inviare notifiche, ad esempio utilizzando un webhook Slack. Questa sezione mostra come configurare Alertmanager per utilizzare il nuovo webhook Slack. La specifica del modo in cui vuoi che Alertmanager elabori gli eventi da inviare è descritta nella sezione successiva del tutorial, Configurare Prometheus.

Per configurare Alertmanager per l'utilizzo del webhook Slack, completa questi passaggi:

Passa alla directory del repository Git che include tutti i manifest di esempio per Cymbal Bank del tutorial precedente:
```
cd ~/bank-of-anthos/
```
Se necessario, modifica la località della directory in cui hai clonato in precedenza il repository.
Aggiorna il manifest YAML di esempio Alertmanager con l'URL webhook dell'applicazione Slack:
```
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
```
Sostituisci SLACK_WEBHOOK_URL con l'URL del webhook della sezione precedente.
Per utilizzare in modo dinamico l'URL webhook di Slack univoco senza modifiche al codice dell'applicazione, puoi utilizzare un secret di Kubernetes. Il codice dell'applicazione legge il valore di questo secret. In applicazioni più complesse, questa funzionalità consente di modificare o ruotare i valori per motivi di sicurezza o conformità.

Crea un secret Kubernetes per Alertmanager utilizzando il manifest YAML di esempio che contiene l'URL webhook di Slack:
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
Prometheus può utilizzare esportatori per ottenere metriche dalle applicazioni senza modifiche al codice. L'utilità di esportazione blackbox Prometheus consente di eseguire il probe degli endpoint come HTTP o HTTPS. Questo esportatore funziona bene quando non vuoi o non puoi esporre i meccanismi interni dell'applicazione a Prometheus. L'utilità di esportazione blackbox di Prometheus può funzionare senza modifiche al codice dell'applicazione per esporre le metriche a Prometheus.

Esegui il deployment dell'esportatore blackbox Prometheus nel tuo cluster:
```
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
```

Configura Prometheus

Dopo aver configurato Alertmanager per l'utilizzo del webhook Slack, devi comunicare a Prometheus cosa monitorare in Cymbal Bank e quali tipi di eventi vuoi che AlertManager ti invii notifiche sull'utilizzo del webhook Slack.

Nell'applicazione di esempio di Cymbal Bank che utilizzi in questi tutorial sono presenti vari microservizi in esecuzione nel cluster GKE. Un problema che probabilmente vorrai informarti il prima possibile è se uno dei servizi di Cymbal Bank smette di rispondere normalmente alle richieste, il che potrebbe significare che i tuoi clienti non potranno accedere all'applicazione. Puoi configurare Prometheus in modo che risponda agli eventi in base ai criteri della tua organizzazione.

Probe

Puoi configurare i probe Prometheus per le risorse da monitorare. Questi probe possono generare avvisi in base alla risposta ricevuta dai probe. Nell'applicazione di esempio Cymbal Bank, puoi utilizzare probe HTTP che verificano la presenza di codici di risposta a livello di 200 dai servizi. Una risposta HTTP 200 indica che il servizio è in esecuzione correttamente e può rispondere alle richieste. Se si verifica un problema e il probe non riceve la risposta prevista, puoi definire le regole di Prometheus che generano avvisi affinché Alertmanager elabori ed eseguano azioni aggiuntive.

Creare alcuni probe Prometheus per monitorare lo stato HTTP dei vari microservizi dell'applicazione di esempio di Cymbal Bank. Esamina il seguente manifest di esempio:

# Copyright 2023 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: frontend-probe
  labels:
    app.kubernetes.io/name: frontend-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [frontend:80]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: userservice-probe
  labels:
    app.kubernetes.io/name: userservice-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [userservice:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: balancereader-probe
  labels:
    app.kubernetes.io/name: balancereader-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [balancereader:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: contacts-probe
  labels:
    app.kubernetes.io/name: contacts-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [contacts:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: ledgerwriter-probe
  labels:
    app.kubernetes.io/name: ledgerwriter-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [ledgerwriter:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: transactionhistory-probe
  labels:
    app.kubernetes.io/name: transactionhistory-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [transactionhistory:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s

Come mostrato in questo file manifest, la best practice prevede che ogni PodMonitoringprobe di attività Prometheus monitori ogni deployment separatamente.

Per creare i probe di attività Prometheus, applica il manifest al cluster:
```
kubectl apply -f extras/prometheus/gmp/probes.yaml
```

Regole

Prometheus deve sapere cosa vuoi fare in base alla risposta ricevuta dai probe che hai creato nei passaggi precedenti. Definisci questa risposta utilizzando le regole di Prometheus.

In questo tutorial creerai regole Prometheus per generare avvisi in base alla risposta al probe di attività. Alertmanager elabora quindi l'output di queste regole per generare notifiche utilizzando il webhook Slack.

Crea regole che generano eventi in base alla risposta ai probe di attività. Esamina il seguente manifest di esempio:

# Copyright 2023 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  name: uptime-rule
spec:
  groups:
  - name: Micro services uptime
    interval: 60s
    rules:
    - alert: BalancereaderUnavaiable
      expr: probe_success{job="balancereader-probe"} == 0
      for: 1m
      annotations:
        summary: Balance Reader Service is unavailable
        description: Check Balance Reader pods and it's logs
      labels:
        severity: 'critical'
    - alert: ContactsUnavaiable
      expr: probe_success{job="contacts-probe"} == 0
      for: 1m
      annotations:
        summary: Contacs Service is unavailable
        description: Check Contacs pods and it's logs
      labels:
        severity: 'warning'
    - alert: FrontendUnavaiable
      expr: probe_success{job="frontend-probe"} == 0
      for: 1m
      annotations:
        summary: Frontend Service is unavailable
        description: Check Frontend pods and it's logs
      labels:
        severity: 'critical'
    - alert: LedgerwriterUnavaiable
      expr: probe_success{job="ledgerwriter-probe"} == 0
      for: 1m
      annotations:
        summary: Ledger Writer Service is unavailable
        description: Check Ledger Writer pods and it's logs
      labels:
        severity: 'critical'
    - alert: TransactionhistoryUnavaiable
      expr: probe_success{job="transactionhistory-probe"} == 0
      for: 1m
      annotations:
        summary: Transaction History Service is unavailable
        description: Check Transaction History pods and it's logs
      labels:
        severity: 'critical'
    - alert: UserserviceUnavaiable
      expr: probe_success{job="userservice-probe"} == 0
      for: 1m
      annotations:
        summary: User Service is unavailable
        description: Check User Service pods and it's logs
      labels:
        severity: 'critical'

Questo file manifest descrive un PrometheusRule e include i seguenti campi:

spec.groups.[*].name: il nome del gruppo di regole.
spec.groups.[*].interval: frequenza con cui vengono valutate le regole nel gruppo.
spec.groups.[*].rules[*].alert: il nome dell'avviso.
spec.groups.[*].rules[*].expr: l'espressione PromQL da valutare.
spec.groups.[*].rules[*].for: il periodo di tempo trascorso dagli avvisi prima che vengano considerati attivati.
spec.groups.[*].rules[*].annotations: un elenco di annotazioni da aggiungere a ciascun avviso. È valido solo per le regole di avviso.
spec.groups.[*].rules[*].labels: le etichette da aggiungere o sovrascrivere.

Per creare le regole, applica il manifest al cluster:
```
kubectl apply -f extras/prometheus/gmp/rules.yaml
```

Simula un'interruzione

Per assicurarti che i probe, le regole e la configurazione di Alertmanager Prometheus siano corretti, devi verificare che gli avvisi e le notifiche vengano inviati in caso di problemi. Se non testi questo flusso, potresti non renderti conto che c'è un'interruzione dei tuoi servizi di produzione quando qualcosa va storto.

Per simulare l'interruzione di uno dei microservizi, scala il deployment contacts fino a zero. Con zero istanze del servizio, l'applicazione di esempio Cymbal Bank non può leggere i dati di contatto per i clienti:
```
kubectl scale deployment contacts --replicas 0
```
Lo scale down di GKE potrebbe richiedere fino a 5 minuti.

Controlla lo stato dei deployment nel tuo cluster e verifica che lo scale down del deployment contacts sia stato eseguito correttamente:

kubectl get deployments

Nell'output di esempio seguente, il deployment contacts è stato scalato correttamente a 0 istanze:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
balancereader        1/1     1            1           17m
blackbox-exporter    1/1     1            1           5m7s
contacts             0/0     0            0           17m
frontend             1/1     1            1           17m
ledgerwriter         1/1     1            1           17m
loadgenerator        1/1     1            1           17m
transactionhistory   1/1     1            1           17m
userservice          1/1     1            1           17m

Dopo lo scale down a zero del deployment contacts, il probe Prometheus segnala un codice di errore HTTP. Questo errore HTTP genera un avviso che avviserà l'elaborazione.

Controlla se nel canale Slack dell'area di lavoro è presente un messaggio di notifica di interruzione con testo simile all'esempio seguente:
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
In uno scenario di interruzione reale, dopo aver ricevuto la notifica in Slack, dovresti iniziare a risolvere i problemi e ripristinare i servizi. Per questo tutorial, simula questo processo e ripristina il deployment contacts facendo lo scale up del numero di repliche:
```
kubectl scale deployment contacts --replicas 1
```
Potrebbero essere necessari fino a 5 minuti per scalare il deployment e prima che il probe Prometheus riceva una risposta HTTP 200. Puoi controllare lo stato dei deployment utilizzando il comando kubectl get deployments.

Quando riceve una risposta integro al probe Prometheus, Alertmanager cancella l'evento. Dovresti vedere un messaggio di notifica di risoluzione degli avvisi nel canale dell'area di lavoro di Slack simile all'esempio seguente:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Esegui la pulizia

Se vuoi fare una pausa prima di passare al tutorial successivo ed evitare che al tuo account Google Cloud vengano addebitati costi per le risorse utilizzate in questo tutorial, elimina il progetto che hai creato.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella console Google Cloud, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Scopri come scalare i tuoi deployment in GKE Enterprise nel prossimo tutorial.