Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Percorso di apprendimento: applicazioni scalabili - Monitoraggio con Prometheus

Autopilot

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). Man mano che procedi con questo insieme di tutorial, imparerai a configurare il monitoraggio e gli avvisi, a scalare i carichi di lavoro e a simulare un errore, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

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

Panoramica e obiettivi

L'applicazione di esempio Cymbal Bank utilizzata in questo insieme di tutorial è composta da una serie di microservizi che vengono eseguiti nel cluster GKE. I 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. Se vieni a conoscenza dei problemi con i servizi il prima possibile, puoi iniziare rapidamente a risolvere i 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 a completare le seguenti attività:

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

Costi

L'abilitazione di GKE e il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial comportano addebiti per cluster per GKE on Google Cloud , come indicato nella nostra pagina dei prezzi finché non disabiliti GKE o elimini il progetto.

Sei anche responsabile degli altri Google Cloud costi 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 Cymbal Bank.

Ti consigliamo di completare questo insieme di tutorial per le app scalabili in ordine. Man mano che procedi con l'insieme di tutorial, imparerai nuove competenze e utilizzerai altri Google Cloud prodotti e servizi.

Per mostrare un esempio di come un cluster GKE Autopilot può utilizzare Google Cloud Managed Service per Prometheus per generare messaggi a 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 un workspace Slack, registrandoti con la tua email o utilizzando un invito inviato da un amministratore di Workspace.

Nota: se non sei un amministratore del tuo workspace Slack, potresti aver bisogno dell' approvazione di un amministratore di Workspace prima che la tua app venga sottoposta a deployment nel tuo workspace.

Crea un'applicazione Slack

Una parte importante della configurazione del monitoraggio è assicurarsi di ricevere una notifica quando si verificano eventi che richiedono un'azione, come le interruzioni. Un pattern comune per questo è inviare notifiche a uno strumento di comunicazione come Slack, che è quello che utilizzerai 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 nella 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 si verifica un problema con le tue applicazioni. Questi avvisi possono quindi utilizzare un webhook Slack per inviare un messaggio al tuo workspace Slack in modo da ricevere notifiche immediate in caso di problemi.

Per configurare le notifiche Slack in base agli avvisi generati da Prometheus, devi creare un'applicazione Slack, attivare i webhook in entrata per l'applicazione e installare l'applicazione in un workspace Slack.

Accedi a Slack utilizzando il nome del workspace e le credenziali del tuo account Slack.
Crea una nuova app Slack
1. Nella finestra di dialogo Crea un'app, fai clic su Da zero.
2. Specifica un nome dell'app e scegli il tuo workspace Slack.
3. Fai clic su Crea app.
4. In Aggiungi 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 il tuo workspace, fai clic su Aggiungi nuovo webhook al 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 l'applicazione Slack viene visualizzato nella sezione URL webhook per il tuo workspace. Salva l'URL per un secondo momento.

Configura Alertmanager

In Prometheus, Alertmanager elabora gli eventi di monitoraggio generati dai deployment. Alertmanager può ignorare gli eventi duplicati, raggruppare gli eventi correlati e inviare notifiche, ad esempio utilizzando un webhook Slack. Questa sezione mostra come configurare Alertmanager per utilizzare il nuovo webhook Slack. La specifica di come vuoi che Alertmanager elabori gli eventi da inviare è trattata nella sezione successiva del tutorial, Configura Prometheus.

Per configurare Alertmanager in modo che utilizzi il webhook Slack, segui questi 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 il repository in precedenza.
Aggiorna il manifest YAML di esempio di 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 dinamicamente l'URL webhook Slack univoco senza apportare modifiche al codice dell'applicazione, puoi utilizzare un secret di Kubernetes. Il codice dell'applicazione legge il valore di questo secret. Nelle applicazioni più complesse, questa funzionalità consente di modificare o ruotare i valori per motivi di sicurezza o conformità.

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

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

Configura Prometheus

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

Nell'applicazione di esempio Cymbal Bank utilizzata in questi tutorial, sono presenti vari microservizi in esecuzione nel cluster GKE. Un problema di cui probabilmente vuoi essere informato il prima possibile è se uno dei servizi Cymbal Bank ha smesso di rispondere normalmente alle richieste, il che potrebbe significare che i tuoi clienti non possono accedere all'applicazione. Puoi configurare Prometheus in modo che risponda agli eventi in base alle policy della tua organizzazione.

Probe

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

Crea alcune probe di Prometheus per monitorare lo stato HTTP dei vari microservizi dell'applicazione di esempio 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 è che ogni probe di attività PodMonitoring di Prometheus monitori ogni deployment separatamente.

Per creare le 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 probe create nei passaggi precedenti. Definisci questa risposta utilizzando le regole di Prometheus.

In questo tutorial, creerai le regole di Prometheus per generare avvisi a seconda della risposta alla 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 alle 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: 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 del 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 in cui gli avvisi devono essere restituiti prima di essere considerati attivati.
spec.groups.[*].rules[*].annotations: un elenco di annotazioni da aggiungere a ogni avviso. Questo è 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 le probe, le regole e la configurazione di Alertmanager di Prometheus siano corrette, devi verificare che gli avvisi e le notifiche vengano inviati in caso di problemi. Se non testi questo flusso, potresti non renderti conto che si è verificata un'interruzione dei servizi di produzione quando si verifica un problema.

Per simulare un'interruzione di uno dei microservizi, riduci a zero il deployment di contacts. Con zero istanze del servizio, l'applicazione di esempio Cymbal Bank non può leggere le informazioni di contatto dei clienti:
```
kubectl scale deployment contacts --replicas 0
```
GKE potrebbe impiegare fino a 5 minuti per fare lo scale down del deployment.

Controlla lo stato dei deployment nel cluster e verifica che il deployment di contacts venga ridotto correttamente:

kubectl get deployments

Nell'output di esempio seguente, il deployment di 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, la probe di Prometheus segnala un codice di errore HTTP. Questo errore HTTP genera un avviso che Alertmanager deve elaborare.

Controlla il canale del workspace Slack per un messaggio di notifica di interruzione con testo simile al seguente esempio:
```
[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, inizieresti a risolvere i problemi e a ripristinare i servizi. Per questo tutorial, simula questo processo e ripristina il deployment di contacts aumentando di nuovo il numero di repliche:
```
kubectl scale deployment contacts --replicas 1
```
Potrebbe essere necessario attendere fino a 5 minuti prima che il deployment venga scalato e che la probe di Prometheus riceva una risposta HTTP 200. Controlla lo stato dei deployment utilizzando il comando kubectl get deployments.

Quando viene ricevuta una risposta integra alla probe di Prometheus, Alertmanager cancella l'evento. Dovresti visualizzare un messaggio di notifica di risoluzione dell'avviso nel canale del workspace Slack simile al seguente esempio:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Libera spazio

Ti consigliamo di completare questo insieme di tutorial per Cymbal Bank in ordine. Man mano che procedi con l'insieme di tutorial, imparerai nuove competenze e utilizzerai altri Google Cloud prodotti e servizi.

Se vuoi fare una pausa prima di passare al tutorial successivo ed evitare che al tuo Google Cloud account 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à descritte in questo documento, eliminerai anche tutto il lavoro che hai 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 Google Cloud console, 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 progetto, quindi fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Nel tutorial successivo imparerai a scalare i deployment in GKE.