Questa pagina è stata tradotta dall'API Cloud Translation.

Percorso di apprendimento: applicazioni scalabili - Monitoraggio con Prometheus

Questo insieme di tutorial è rivolto a operatori e amministratori IT che vogliono eseguire il deployment, eseguire e gestire ambienti di applicazioni moderne che vengono eseguiti su Google Kubernetes Engine (GKE) Enterprise. Man mano che avanzi in questo insieme di tutorial, imparerai come configurare il monitoraggio e gli avvisi, scalare i carichi di lavoro e simulare i guasti, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

Creare un cluster ed eseguire il deployment di un'applicazione di esempio
Monitoraggio con Google Cloud Managed Service per Prometheus (questo tutorial)
Scala i carichi di lavoro
Simulare un errore
Gestisci in modo centralizzato la gestione dei cambiamenti

Panoramica e obiettivi

L'applicazione di esempio Cymbal Bank utilizzata in questo insieme di tutorial è composta da un insieme di microservizi che vengono eseguiti nel cluster GKE. I problemi con uno di questi servizi potrebbero comportare una cattiva esperienza per i clienti della banca, ad esempio la mancata possibilità di accedere all'applicazione della banca. Se conosci i problemi relativi ai servizi il prima possibile, puoi iniziare rapidamente a risolverli.

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

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

Costi

Se attivi GKE Enterprise e esegui il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial, dovrai sostenere costi per GKE Enterprise su Google Cloud per ogni cluster, come indicato nella nostra pagina dei prezzi, finché non disattivi GKE Enterprise o non 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 Compute Engine e Cloud Monitoring.

Prima di iniziare

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

Ti consigliamo di completare questa serie di tutorial per Cymbal Bank in ordine. Man mano che avanzi nella serie di tutorial, acquisisci nuove competenze e utilizzi altri prodotti e servizi Google Cloud.

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 inviare messaggi quando si verifica un problema con il cluster GKE.

Unisciti a uno spazio di lavoro Slack, registrandoti con il tuo indirizzo email o utilizzando un invito inviato da un amministratore dello spazio di lavoro.

Nota: se non sei un amministratore della tua area di lavoro di Slack, potresti dover ottenere l'approvazione di un amministratore dello spazio di lavoro prima che l'app venga dispiata nella tua area di lavoro.

Creare un'applicazione Slack

Un aspetto importante della configurazione del monitoraggio è assicurarti di ricevere una notifica quando si verificano eventi importanti come le interruzioni del servizio. Un pattern comune per farlo è inviare notifiche a uno strumento di comunicazione come Slack, che è quello che utilizzi in questo tutorial. Slack fornisce una funzionalità di webhook che consente alle applicazioni esterne, come i deployment di produzione, di generare messaggi. Puoi utilizzare altri strumenti di comunicazione della tua organizzazione per elaborare e inviare messaggi quando si verifica un problema con il cluster GKE.

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

Per configurare le notifiche di Slack in base agli avvisi generati da Prometheus, devi creare un'applicazione Slack, attivare i webhook in entrata per l'applicazione e installarla in uno spazio di lavoro Slack.

Accedi a Slack utilizzando il nome dello spazio 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 il tuo spazio di lavoro Slack.
3. Fai clic su Create App (Crea app).
4. In Aggiungi funzionalità, fai clic su Webhook in arrivo.
5. Fai clic sul pulsante di attivazione/disattivazione Attiva webhook in entrata.
6. Nella sezione URL webhook per il tuo spazio di lavoro, fai clic su Aggiungi nuovo webhook allo spazio di lavoro.
7. Nella pagina di autorizzazione che si apre, seleziona un canale per ricevere le notifiche.
8. Fai clic su Consenti.
9. Nella sezione URL webhook per il tuo spazio di lavoro viene visualizzato un webhook per la tua applicazione Slack. Salva l'URL per un utilizzo futuro.

Configura Alertmanager

In Prometheus, Alertmanager elabora gli eventi di monitoraggio generati dai tuoi deployment. Alertmanager può saltare gli eventi duplicati, raggruppare gli eventi correlati e inviare notifiche, ad esempio utilizzando un webhook di Slack. Questa sezione spiega come configurare Alertmanager per utilizzare il nuovo webhook di Slack. La specifica della modalità di elaborazione degli eventi da inviare da parte di Alertmanager è trattata nella sezione successiva del tutorial, Configurare Prometheus.

Per configurare Alertmanager in modo che utilizzi il tuo webhook Slack, completa i seguenti passaggi:

Cambia directory nel repository Git che include tutti i manifest di esempio per Cymbal Bank del tutorial precedente:
```
cd ~/bank-of-anthos/
```
Se necessario, modifica la posizione della directory in cui hai clonato precedentemente il repository.
Aggiorna il file manifest YAML di esempio di Alertmanager con l'URL webhook della tua 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 dinamicamente l'URL webhook Slack univoco senza modifiche al codice dell'applicazione, puoi utilizzare un segreto 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 gli esportatori per ottenere le metriche dalle applicazioni senza modifiche al codice. L'esportatore blackbox di Prometheus ti consente di eseguire sondaggi su endpoint come HTTP o HTTPS. Questo esportatore funziona bene quando non vuoi o non puoi esporre il funzionamento interno della tua applicazione a Prometheus. L'esportatore blackbox di Prometheus può funzionare senza modifiche al codice dell'applicazione per esporre le metriche a Prometheus.

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

Configura Prometheus

Dopo aver configurato Alertmanager per utilizzare il webhook di Slack, devi indicare a Prometheus cosa monitorare in Cymbal Bank e quali tipi di eventi vuoi che Alertmanager ti invii tramite il webhook di Slack.

Nell'applicazione di esempio Cymbal Bank utilizzata in questi tutorial sono presenti diversi microservizi in esecuzione nel cluster GKE. Un problema che probabilmente vorrai conoscere il prima possibile è se uno dei servizi di Cymbal Bank ha smesso di rispondere normalmente alle richieste, il che potrebbe significare che i tuoi clienti non riescono ad 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 che vuoi monitorare. Queste sonde possono generare avvisi in base alla risposta che ricevono. Nell'applicazione di esempio di Cymbal Bank, puoi utilizzare sonde HTTP che controllano la presenza di codici di risposta di livello 200 dei servizi. Una risposta a livello HTTP 200 indica che il servizio è in esecuzione correttamente e può rispondere alle richieste. Se si verifica un problema e la sonda non riceve la risposta prevista, puoi definire regole Prometheus che generano avvisi per l'elaborazione da parte di Alertmanager ed eseguire azioni aggiuntive.

Crea alcuni probe Prometheus per monitorare lo stato HTTP dei vari microservizi dell'applicazione di esempio Cymbal Bank. Esamina il seguente manifesto 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, è buona prassi che ogni PodMonitoring Prometheus liveness probe monitori ogni deployment separatamente.

Per creare i probe di attività di 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 dalle sonde che hai creato nei passaggi precedenti. Definisci questa risposta utilizzando le regole Prometheus.

In questo tutorial, crei 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 di Slack.

Crea regole che generano eventi in base alla risposta ai controlli 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: BalancereaderUnavailable
      expr: probe_success{job="balancereader-probe"} == 0
      for: 1m
      annotations:
        summary: Balance Reader Service is unavailable
        description: Check Balance Reader pods and its logs
      labels:
        severity: 'critical'
    - alert: ContactsUnavailable
      expr: probe_success{job="contacts-probe"} == 0
      for: 1m
      annotations:
        summary: Contacts Service is unavailable
        description: Check Contacts pods and its logs
      labels:
        severity: 'warning'
    - alert: FrontendUnavailable
      expr: probe_success{job="frontend-probe"} == 0
      for: 1m
      annotations:
        summary: Frontend Service is unavailable
        description: Check Frontend pods and its logs
      labels:
        severity: 'critical'
    - alert: LedgerwriterUnavailable
      expr: probe_success{job="ledgerwriter-probe"} == 0
      for: 1m
      annotations:
        summary: Ledger Writer Service is unavailable
        description: Check Ledger Writer pods and its logs
      labels:
        severity: 'critical'
    - alert: TransactionhistoryUnavailable
      expr: probe_success{job="transactionhistory-probe"} == 0
      for: 1m
      annotations:
        summary: Transaction History Service is unavailable
        description: Check Transaction History pods and its logs
      labels:
        severity: 'critical'
    - alert: UserserviceUnavailable
      expr: probe_success{job="userservice-probe"} == 0
      for: 1m
      annotations:
        summary: User Service is unavailable
        description: Check User Service pods and its logs
      labels:
        severity: 'critical'

Questo manifest descrive un PrometheusRule e include i seguenti campi:

spec.groups.[*].name: il nome del gruppo di regole.
spec.groups.[*].interval: la 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 per il quale gli avvisi devono essere restituiti prima di essere considerati attivati.
spec.groups.[*].rules[*].annotations: un elenco di annotazioni da aggiungere a ogni avviso. Questo vale 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

Simulare un'interruzione del servizio

Per assicurarti che i probe, le regole e la configurazione di Alertmanager di Prometheus siano corretti, devi verificare che gli avvisi e le notifiche vengano inviati in caso di problemi. Se non testi questo flusso, potresti non accorgerti che si è verificata un'interruzione dei servizi di produzione quando si verifica un problema.

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

Controlla lo stato dei deployment nel cluster e verifica che il deployment di contacts riduca correttamente le dimensioni:

kubectl get deployments

Nell'esempio di output riportato di seguito, il deployment contacts è stato ridotto 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 che il deployment di contacts è stato ridotto a zero, il probe Prometheus segnala un codice di errore HTTP. Questo errore HTTP genera un avviso che verrà poi elaborato da Alertmanager.

Controlla il canale della tua area di lavoro Slack per verificare la presenza di un messaggio di notifica dell'interruzione con un 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, inizierai a risolvere i problemi e a ripristinare i servizi. Per questo tutorial, simula questa procedura e ripristina il deployment contacts riducendo il numero di repliche:
```
kubectl scale deployment contacts --replicas 1
```
Potrebbero essere necessari fino a 5 minuti per eseguire il ridimensionamento del deployment e per consentire al probe Prometheus di ricevere una risposta HTTP 200. Puoi controllare lo stato dei deployment utilizzando il comando kubectl get deployments.

Quando viene ricevuta una risposta corretta al probe Prometheus, Alertmanager cancella l'evento. Nel canale dello spazio di lavoro di Slack dovresti visualizzare un messaggio di notifica relativo alla risoluzione dell'avviso 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 relativi alle 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à descritte in questo documento, quando lo elimini elimini anche tutto il 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 appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

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