Questo insieme di tutorial è rivolto a operatori e amministratori IT che vogliono distribuire, eseguire e gestire ambienti di applicazioni moderne che vengono eseguiti su Google Kubernetes Engine (GKE). Man mano che avanzi in questo insieme di tutorial, imparerai a configurare il monitoraggio e gli avvisi, a scalare i carichi di lavoro e a 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
- Monitora con Google Cloud Managed Service per Prometheus (questo tutorial)
- Scalare i workload
- Simulare un errore
- Centralizzare 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 tutti nel cluster GKE. 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 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 Slack per Alertmanager.
Configura Prometheus per monitorare lo stato di un'applicazione basata su microservizi di esempio.
Simula un'interruzione e rivedi gli avvisi inviati utilizzando il webhook di Slack.
Creare un'applicazione Slack
Una parte importante della configurazione del monitoraggio è assicurarsi di ricevere una notifica quando si verificano eventi azionabili come interruzioni. Un pattern comune per questo è inviare notifiche a uno strumento di comunicazione come Slack, che è quello che utilizzi in questo tutorial. Slack offre una funzionalità di webhook che consente ad applicazioni esterne, come le implementazioni di produzione, di generare messaggi. Puoi utilizzare altri strumenti di comunicazione nella tua organizzazione per elaborare e consegnare i messaggi quando il cluster GKE ha un problema.
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 tempestive quando si verifica un problema.
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 installare l'applicazione in un workspace Slack.
Accedi a Slack utilizzando il nome del tuo spazio di lavoro e le credenziali del tuo account Slack.
-
- Nella finestra di dialogo Crea un'app, fai clic su Da zero.
- Specifica un nome app e scegli il tuo workspace Slack.
- Fai clic su Crea app.
- Nella sezione Aggiungi funzionalità, fai clic su Webhook in arrivo.
- Fai clic sul pulsante di attivazione/disattivazione Attiva webhook in entrata.
- Nella sezione Webhook URLs for Your Workspace (URL webhook per il tuo workspace), fai clic su Add New Webhook to Workspace (Aggiungi nuovo webhook al workspace).
- Nella pagina di autorizzazione che si apre, seleziona un canale per ricevere le notifiche.
- Fai clic su Consenti.
- Un webhook per la tua applicazione Slack viene visualizzato nella sezione URL webhook per il tuo workspace. Salva l'URL per un utilizzo futuro.
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 di Slack. Questa sezione mostra come configurare Alertmanager per utilizzare il nuovo webhook 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 webhook Slack, completa i seguenti 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, cambia la posizione della directory in cui hai clonato in precedenza il repository.
Aggiorna il 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 di Slack univoco senza apportare modifiche al codice dell'applicazione, puoi utilizzare un secret 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 del webhook di 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'esportatore blackbox di Prometheus consente di eseguire il probing di 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 l'utilizzo del webhook Slack, devi indicare a Prometheus cosa monitorare in Cymbal Bank e per quali tipi di eventi vuoi che Alertmanager ti invii una notifica utilizzando il webhook Slack.
Nell'applicazione di esempio Cymbal Bank che utilizzi 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 ai criteri della tua organizzazione.
Probe
Puoi configurare i probe Prometheus per le risorse che vuoi monitorare. Questi probe possono generare avvisi in base alla risposta che ricevono. Nell'applicazione di esempio Cymbal Bank, puoi utilizzare probe HTTP che controllano i codici di risposta di livello 200 dai servizi. Una risposta a livello HTTP 200 indica che il servizio funziona correttamente e può rispondere alle richieste. Se si verifica un problema e il probe non riceve la risposta prevista, puoi definire regole Prometheus che generano avvisi per Alertmanager da elaborare 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:
Come mostrato in questo file manifest, la best practice prevede che ogni
PodMonitoring
probe di attività di Prometheus monitori ogni deployment separatamente.Per creare i probe di attività di Prometheus, applica il manifest al tuo 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 di Slack.
Crea regole che generano eventi in base alla risposta ai probe di liveness. Esamina il seguente file manifest di esempio:
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 attivi.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 del servizio
Per assicurarti che le sonde, le regole e la configurazione di Alertmanager di Prometheus siano corrette, devi verificare che gli avvisi e le notifiche vengano inviati quando si verifica un problema. Se non esegui il test di questo flusso, potresti non renderti conto che si è verificata un'interruzione dei tuoi servizi di produzione quando qualcosa va storto.
Per simulare un'interruzione di uno dei microservizi, scala il deployment
contacts
a zero. Con zero istanze del servizio, l'applicazione di esempio Cymbal Bank 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 del deployment.
Controlla lo stato dei deployment nel cluster e verifica che lo scale down del
contacts
deployment venga eseguito correttamente:kubectl get deployments
Nell'output di esempio riportato di seguito, il deployment di
contacts
è stato ridimensionato a0
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
contacts
è stato ridotto a zero, il probe Prometheus segnala un codice di errore HTTP. Questo errore HTTP genera un avviso che Alertmanager deve elaborare.Controlla il canale del tuo 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
contacts
Deployment riducendo il numero di repliche:kubectl scale deployment contacts --replicas 1
Potrebbero essere necessari fino a 5 minuti per scalare la deployment e per la sonda Prometheus per ricevere una risposta HTTP 200. Controlla lo stato delle implementazioni utilizzando il comando
kubectl get deployments
.Quando viene ricevuta una risposta di stato integro al probe Prometheus, Alertmanager cancella l'evento. Nel canale del tuo workspace Slack dovresti visualizzare un messaggio di notifica di risoluzione dell'avviso simile al seguente esempio:
[RESOLVED] ContactsUnavailable Severity: Warning :warning: Summary: Contacts Service is unavailable Namespace: default Check Contacts pods and it's logs