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. Procedendo in questa serie di tutorial, imparerai a configurare monitoraggio e avvisi, scalare carichi di lavoro e simulare errori, il tutto utilizzando l'applicazione di microservizi di esempio Cymbal Bank:

  1. Crea un cluster ed esegui il deployment di un'applicazione di esempio
  2. Monitora con Google Cloud Managed Service per Prometheus (questo tutorial)
  3. Scala i carichi di lavoro
  4. Simulare 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, come l'impossibilità di accedere all'applicazione della banca. Scoprire i problemi relativi ai servizi nel più breve tempo possibile consente di iniziare subito a risolverli e 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. Scoprirai come completare le seguenti attività:

  • Creare un webhook Slack per Alertmanager.

  • Configurare 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

Se abiliti GKE Enterprise ed esegui il deployment dell'applicazione di esempio Cymbal Bank per questa serie di tutorial, ti verranno addebitati costi per cluster GKE Enterprise su Google Cloud, come indicato nella nostra pagina Prezzi, finché non disabiliti GKE Enterprise o non elimini il progetto.

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

Prima di iniziare

Per imparare a monitorare i 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 di Cymbal Bank.

Ti consigliamo di completare questa serie di tutorial per Cymbal Bank nell'ordine indicato. Man mano che procedi nella serie di tutorial, acquisirai nuove competenze e utilizzerai 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 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 consegnare i messaggi quando il tuo cluster GKE presenta un problema.

  • Partecipa a un'area di lavoro Slack registrandosi con il proprio indirizzo email o utilizzando un invito inviato da un amministratore di Workspace.

Creazione di un'applicazione Slack

Una parte importante della configurazione del monitoraggio è assicurarsi di ricevere notifiche quando si verificano eventi strategici, come le interruzioni. Un modello comune per farlo è inviare notifiche a uno strumento di comunicazione come Slack, che utilizzi in questo tutorial. Slack fornisce 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 messaggi quando il tuo cluster GKE presenta un problema.

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

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

  1. Accedi a Slack usando il nome della tua area di lavoro e le credenziali del tuo account Slack.

  2. Crea 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 caratteristiche e funzionalità, fai clic su Webhook in entrata.
    5. Fai clic sull'opzione di attivazione/disattivazione Attiva webhook in arrivo.
    6. Nella sezione URL webhook per area di lavoro, fai clic su Aggiungi nuovo webhook a Workspace.
    7. Nella pagina di autorizzazione che si apre, seleziona un canale per la ricezione delle notifiche.
    8. Fai clic su Consenti.
    9. Un webhook per l'applicazione Slack viene visualizzato nella sezione URL webhook per l'area di lavoro. Salva l'URL per un utilizzo futuro.

Configura AlertManager

In Prometheus, Alertmanager elabora gli eventi di monitoraggio generati dai deployment. Alertmanager può saltare eventi duplicati, raggruppare gli eventi correlati e inviare notifiche, come l'uso di un webhook Slack. Questa sezione mostra come configurare Alertmanager per utilizzare il nuovo webhook Slack. La specifica della modalità di elaborazione degli eventi da inviare a Alertmanager viene trattata nella sezione successiva del tutorial, Configurare Prometheus.

Per configurare Alertmanager in modo che utilizzi il webhook Slack, segui questi passaggi:

  1. Cambia le directory nel repository Git che include tutti i file manifest di esempio per Cymbal Bank del tutorial precedente:

    cd ~/bank-of-anthos/
    

    Se necessario, cambia la posizione della directory in quella in cui hai precedentemente clonato il repository.

  2. Aggiorna il manifest YAML di esempio 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.

  3. Per utilizzare in modo dinamico l'URL webhook Slack univoco senza 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 capacità 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 Slack:

    kubectl create secret generic alertmanager \
      -n gmp-public \
      --from-file=extras/prometheus/gmp/alertmanager.yaml
    
  4. Prometheus può utilizzare gli esportatori per ottenere metriche dalle applicazioni senza modifiche al codice. L'utilità di esportazione blackbox di Prometheus consente di eseguire il probe su endpoint come HTTP o HTTPS. Questo esportatore funziona bene quando non vuoi o non puoi esporre i meccanismi interni della tua applicazione a Prometheus. L'utilità di esportazione per Prometheus può funzionare senza modifiche al codice dell'applicazione per esporre le metriche a Prometheus.

    Esegui il deployment dell'esportatore blackbox di Prometheus nel 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 una notifica 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 di cui dovresti essere a conoscenza 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 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 di Prometheus per le risorse che vuoi 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 di livello 200 dai servizi. Una risposta di 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 di Prometheus che generano avvisi affinché Alertmanager possa elaborare ed eseguire azioni aggiuntive.

  1. Creare alcuni probe 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
    

    Questo manifest descrive i probe di attività Prometheus e include i campi seguenti:

    • spec.jobName: il nome del job assegnato alle metriche di altri siti.
    • spec.prober.url: l'URL del servizio dell'esportatore blackbox. Include la porta predefinita per l'esportatore blackbox.
    • spec.prober.path: il percorso di raccolta delle metriche.
    • spec.targets.staticConfig.labels: le etichette assegnate a tutte le metriche tramite lo scraping dei target.
    • spec.targets.staticConfig.static: l'elenco di host da scansionare.
  2. Per creare i probe di attività 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 creati nei passaggi precedenti. Puoi definire questa risposta utilizzando le regole di Prometheus.

In questo tutorial creerai regole di 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.

  1. Creare 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 elemento 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 entro il quale gli avvisi devono essere restituiti prima che vengano considerati attivati.
    • spec.groups.[*].rules[*].annotations: un elenco di annotazioni da aggiungere a ogni avviso. È valido solo per le regole di avviso.
    • spec.groups.[*].rules[*].labels: le etichette da aggiungere o sovrascrivere.
  2. Per creare le regole, applica il manifest al cluster:

    kubectl apply -f extras/prometheus/gmp/rules.yaml
    

Simula un'interruzione

Per assicurarti che la configurazione di probe, regole e avvisi di Prometheus sia corretta, verifica che vengano inviati avvisi e notifiche in caso di problema. Se non testi questo flusso, potresti non renderti conto dell'interruzione dei servizi di produzione a causa di un problema.

  1. Per simulare un'interruzione di uno dei microservizi, scala il deployment di contacts fino a zero. In assenza di 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.

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

    kubectl get deployments
    

    Nell'output di esempio seguente, il deployment contacts ha eseguito correttamente lo scale down 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
    
  3. Dopo che il deployment contacts è stato fatto lo scale down a zero, il probe Prometheus segnala un codice di errore HTTP. Questo errore HTTP genera un avviso per l'elaborazione di Alertmanager.

    Controlla se nel canale della tua area di lavoro Slack è presente un messaggio di notifica di interruzione con un 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
    
  4. 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 questo processo e ripristina il deployment contacts facendo lo scale up del numero di repliche:

    kubectl scale deployment contacts --replicas 1
    

    La scalabilità del deployment potrebbe richiedere fino a 5 minuti e il probe Prometheus riceve una risposta HTTP 200. Puoi controllare lo stato dei deployment utilizzando il comando kubectl get deployments.

    Quando viene ricevuta una risposta integro al probe di Prometheus, Alertmanager cancella l'evento. Dovresti vedere un messaggio di notifica di risoluzione degli avvisi nel canale dell'area di lavoro 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

Ti consigliamo di completare questa serie di tutorial per Cymbal Bank nell'ordine indicato. Man mano che procedi nella serie di tutorial, acquisirai nuove competenze e utilizzerai altri prodotti e servizi Google Cloud.

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.

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. 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.