Lernpfad: Skalierbare Anwendungen – Mit Prometheus überwachen

Autopilot

Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen, die in Google Kubernetes Engine (GKE) ausgeführt werden, bereitstellen, ausführen und verwalten möchten. In diesen Anleitungen erfahren Sie, wie Sie Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren – und zwar anhand der Beispiel-Mikrodienstanwendung „Cymbal Bank“:

Cluster erstellen und Beispielanwendung bereitstellen
Mit Google Cloud Managed Service for Prometheus überwachen (diese Anleitung)
Arbeitslasten skalieren
Fehler simulieren

Übersicht und Ziele

Die in dieser Anleitungsreihe verwendete Beispielanwendung „Cymbal Bank“ besteht aus einer Reihe von Mikrodiensten, die alle im GKE-Cluster ausgeführt werden. Probleme mit einem dieser Dienste können zu einer schlechten Nutzererfahrung für die Kunden der Bank führen, z. B. wenn sie nicht auf die Bankanwendung zugreifen können. Wenn Sie so schnell wie möglich von Problemen mit den Diensten erfahren, können Sie zügig mit der Fehlerbehebung beginnen und die Probleme beheben.

In dieser Anleitung erfahren Sie, wie Sie Arbeitslasten in einem GKE-Cluster mit Google Cloud Managed Service for Prometheus und Cloud Monitoring überwachen. Sie lernen, wie Sie die folgenden Aufgaben ausführen:

Erstellen Sie einen Slack-Webhook für Alertmanager.
Konfigurieren Sie Prometheus so, dass der Status einer Beispielanwendung auf Basis von Mikrodiensten überwacht wird.
Simulieren Sie einen Ausfall und prüfen Sie die Benachrichtigungen, die über den Slack-Webhook gesendet werden.

Kosten

Wenn Sie GKE aktivieren und die Beispielanwendung „Cymbal Bank“ für diese Reihe von Anleitungen bereitstellen, fallen für GKE in Google Cloud Gebühren pro Cluster an, bis Sie GKE deaktivieren oder das Projekt löschen. Weitere Informationen finden Sie auf der Preisseite.

Sie sind auch für andere Google Cloud-Kosten verantwortlich, die während der Ausführung der Cymbal Bank-Beispielanwendung anfallen, z. B. Gebühren für Compute Engine-VMs und Cloud Monitoring.

Hinweise

Wenn Sie lernen möchten, wie Sie Ihre Arbeitslasten überwachen, müssen Sie die erste Anleitung zum Erstellen eines GKE-Clusters mit Autopilot und zum Bereitstellen der auf Mikrodiensten basierenden Beispielanwendung „Cymbal Bank“ ausführen.

Wir empfehlen Ihnen, diese Reihe von Anleitungen für skalierbare Anwendungen in der richtigen Reihenfolge durchzugehen. Während Sie die einzelnen Anleitungen durcharbeiten, lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.

In dieser Anleitung wird anhand von Slack gezeigt, wie ein GKE Autopilot-Cluster Google Cloud Managed Service for Prometheus verwenden kann, um Nachrichten an eine Kommunikationsplattform zu senden. In Ihren eigenen Produktionsumgebungen können Sie das bevorzugte Kommunikationstool Ihrer Organisation verwenden, um Nachrichten zu verarbeiten und zuzustellen, wenn in Ihrem GKE-Cluster ein Problem auftritt.

Um einem Slack-Arbeitsbereich beizutreten, registrieren Sie sich entweder mit Ihrer E-Mail-Adresse oder nutzen eine von einem Workspace-Administrator gesendete Einladung.
Hinweis: Wenn Sie kein Administrator für Ihren Slack-Arbeitsbereich sind, benötigen Sie möglicherweise die Genehmigung eines Arbeitsbereichadministrators, damit die Anwendung in Ihrem Arbeitsbereich bereitgestellt wird.

Slack-Anwendung erstellen

Ein wichtiger Teil der Einrichtung des Monitorings besteht darin, dafür zu sorgen, dass Sie benachrichtigt werden, wenn es zu Ereignissen wie Ausfällen kommt, auf die reagiert werden muss. Ein gängiges Muster hierfür ist das Senden von Benachrichtigungen an ein Kommunikationstool wie Slack, das Sie in dieser Anleitung verwenden. Slack bietet eine Webhook-Funktion, mit der externe Anwendungen wie Ihre Produktionsbereitstellungen Nachrichten generieren können. Sie können andere Kommunikationstools in Ihrer Organisation verwenden, um Nachrichten zu verarbeiten und zuzustellen, wenn bei Ihrem GKE-Cluster ein Problem auftritt.

GKE-Cluster, die Autopilot verwenden, enthalten eine Instanz von Google Cloud Managed Service for Prometheus. Diese Instanz kann Benachrichtigungen generieren, wenn sich etwas mit Ihren Anwendungen ereignet. Diese Benachrichtigungen können dann über einen Slack-Webhook eine Nachricht an Ihren Slack-Arbeitsbereich senden, damit Sie bei Problemen sofort benachrichtigt werden.

Wenn Sie Slack-Benachrichtigungen basierend auf von Prometheus generierten Benachrichtigungen einrichten möchten, müssen Sie eine Slack-Anwendung erstellen, eingehende Webhooks für die Anwendung aktivieren und die Anwendung in einem Slack-Arbeitsbereich installieren.

Melden Sie sich bei Slack an. Verwenden Sie hierfür den Namen Ihres Arbeitsbereichs und die Anmeldedaten für Ihr Slack-Konto.
Neue Slack-App erstellen
1. Klicken Sie im Dialogfeld Anwendung erstellen auf Neu erstellen.
2. Geben Sie einen Anwendungsnamen an und wählen Sie Ihren Slack-Arbeitsbereich aus.
3. Klicken Sie auf Create App (App erstellen).
4. Klicken Sie unter Features und Funktionen hinzufügen auf Eingehende Webhooks.
5. Klicken Sie auf die Schaltfläche Eingehende Webhooks aktivieren.
6. Klicken Sie im Abschnitt Webhook-URLs für Ihren Arbeitsbereich auf Neuen Webhook zu Arbeitsbereich hinzufügen.
7. Wählen Sie auf der angezeigten Autorisierungsseite einen Kanal aus, um Benachrichtigungen zu erhalten.
8. Klicken Sie auf Zulassen.
9. Ein Webhook für Ihre Slack-Anwendung wird im Abschnitt Webhook-URLs für Ihren Arbeitsbereich angezeigt. Speichern Sie die URL für eine spätere Verwendung.

Alertmanager konfigurieren

In Prometheus verarbeitet Alertmanager Monitoring-Ereignisse, die von Ihren Bereitstellungen generiert werden. Alertmanager kann doppelte Ereignisse überspringen, ähnliche Ereignisse gruppieren und Benachrichtigungen senden, z. B. über einen Slack-Webhook. In diesem Abschnitt erfahren Sie, wie Sie Alertmanager so konfigurieren, dass er Ihren neuen Slack-Webhook verwendet. Wie Sie festlegen, wie Alertmanager zu sendende Ereignisse verarbeiten soll, wird im nächsten Abschnitt des Tutorials Prometheus konfigurieren behandelt.

So konfigurieren Sie Alertmanager für die Verwendung Ihres Slack-Webhooks:

Wechseln Sie das Verzeichnis zum Git-Repository, das alle Beispielmanifeste für Cymbal Bank aus der vorherigen Anleitung enthält:
```
cd ~/bank-of-anthos/
```
Ändern Sie bei Bedarf den Verzeichnisspeicherort in den Ort, an dem Sie das Repository zuvor geklont haben.
Aktualisieren Sie das Beispiel-YAML-Manifest für Alertmanager mit der Webhook-URL Ihrer Slack-Anwendung:
```
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
```
Ersetzen Sie SLACK_WEBHOOK_URL durch die URL des Webhooks aus dem vorherigen Abschnitt.
Wenn Sie Ihre eindeutige Slack-Webhook-URL dynamisch ohne Änderungen am Anwendungscode verwenden möchten, können Sie ein Kubernetes-Secret verwenden. Der Anwendungscode liest den Wert dieses Secrets. Bei komplexeren Anwendungen können Sie mit dieser Funktion Werte aus Sicherheits- oder Compliance-Gründen ändern oder rotieren.

Erstellen Sie ein Kubernetes-Secret für Alertmanager mit dem Beispiel-YAML-Manifest, das die Slack-Webhook-URL enthält:
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
Prometheus kann Exporter verwenden, um Messwerte aus Anwendungen ohne Codeänderungen abzurufen. Mit dem Prometheus Blackbox Exporter können Sie Endpunkte wie HTTP oder HTTPS prüfen. Dieser Exporter eignet sich gut, wenn Sie die internen Abläufe Ihrer Anwendung nicht für Prometheus freigeben möchten oder können. Der Prometheus-Blackbox-Exporter kann ohne Änderungen am Anwendungscode verwendet werden, um Messwerte für Prometheus freizugeben.

Stellen Sie den Prometheus-Blackbox-Exporter in Ihrem Cluster bereit:
```
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
```

Prometheus konfigurieren

Nachdem Sie Alertmanager für die Verwendung Ihres Slack-Webhooks konfiguriert haben, müssen Sie Prometheus mitteilen, was in Cymbal Bank überwacht werden soll und über welche Arten von Ereignissen Sie von Alertmanager über den Slack-Webhook benachrichtigt werden möchten.

In der Beispielanwendung Cymbal Bank, die Sie in diesen Anleitungen verwenden, gibt es verschiedene Mikrodienste, die im GKE-Cluster ausgeführt werden. Ein Problem, von dem Sie wahrscheinlich so schnell wie möglich erfahren möchten, ist, wenn einer der Cymbal Bank-Dienste nicht mehr normal auf Anfragen reagiert. Das kann bedeuten, dass Ihre Kunden nicht auf die Anwendung zugreifen können. Sie können Prometheus so konfigurieren, dass es auf Ereignisse gemäß den Richtlinien Ihrer Organisation reagiert.

Prüfungen

Sie können Prometheus-Prüfungen für die Ressourcen konfigurieren, die Sie überwachen möchten. Diese Proben können basierend auf der Antwort, die sie erhalten, Benachrichtigungen generieren. In der Beispielanwendung Cymbal Bank können Sie HTTP-Prüfungen verwenden, die auf Antwortcodes der Ebene 200 von den Diensten prüfen. Eine Antwort auf HTTP-Ebene 200 gibt an, dass der Dienst ordnungsgemäß ausgeführt wird und auf Anfragen reagieren kann. Wenn ein Problem auftritt und die Probe nicht die erwartete Antwort erhält, können Sie Prometheus-Regeln definieren, die Benachrichtigungen generieren, die Alertmanager verarbeitet und daraufhin weitere Aktionen ausführt.

Erstellen Sie einige Prometheus-Prüfungen, um den HTTP-Status der verschiedenen Mikrodienste der Beispielanwendung Cymbal Bank zu überwachen. Sehen Sie sich das folgende Beispielmanifest an:

# 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

Wie in dieser Manifestdatei dargestellt, empfiehlt es sich, dass jede PodMonitoring Prometheus-Aktivitätsprüfung jedes Deployment separat überwacht.

Wenden Sie das Manifest auf Ihren Cluster an, um die Prometheus-Aktivitätsprüfungen zu erstellen:
```
kubectl apply -f extras/prometheus/gmp/probes.yaml
```

Regeln

Prometheus muss wissen, was Sie tun möchten, basierend auf der Antwort, die die in den vorherigen Schritten erstellten Prüfungen erhalten. Sie definieren diese Antwort mit Prometheus-Regeln.

In dieser Anleitung erstellen Sie Prometheus-Regeln, um je nach Antwort auf die Aktivitätsprüfung Benachrichtigungen zu generieren. Alertmanager verarbeitet dann die Ausgabe dieser Regeln, um Benachrichtigungen über den Slack-Webhook zu generieren.

Erstellen Sie Regeln, die Ereignisse basierend auf der Reaktion auf die Aktivitätsprüfungen generieren. Sehen Sie sich das folgende Beispielmanifest an:

# 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'

Dieses Manifest beschreibt einen PrometheusRule und enthält die folgenden Felder:

spec.groups.[*].name: der Name der Regelgruppe.
spec.groups.[*].interval: wie oft Regeln in der Gruppe ausgewertet werden.
spec.groups.[*].rules[*].alert: der Name der Benachrichtigung.
spec.groups.[*].rules[*].expr: der PromQL-Ausdruck, der ausgewertet wird.
spec.groups.[*].rules[*].for: die Zeitspanne, in der Benachrichtigungen zurückgegeben werden müssen, bevor sie als ausgelöst gelten.
spec.groups.[*].rules[*].annotations: eine Liste von Annotationen, die jeder Benachrichtigung hinzugefügt werden sollen. Das gilt nur für Benachrichtigungsregeln.
spec.groups.[*].rules[*].labels: die Labels, die hinzugefügt oder überschrieben werden sollen.

Wenden Sie das Manifest auf Ihren Cluster an, um die Regeln zu erstellen:
```
kubectl apply -f extras/prometheus/gmp/rules.yaml
```

Ausfall simulieren

Um sicherzustellen, dass Ihre Prometheus-Prüfungen, ‑Regeln und ‑AlertManager-Konfiguration korrekt sind, sollten Sie testen, ob Benachrichtigungen bei einem Problem gesendet werden. Wenn Sie diesen Ablauf nicht testen, bemerken Sie möglicherweise nicht, dass Ihre Produktionsdienste ausfallen, wenn etwas schiefgeht.

Skalieren Sie das contacts-Deployment auf null, um einen Ausfall eines der Mikrodienste zu simulieren. Ohne Instanzen des Dienstes kann die Beispielanwendung Cymbal Bank keine Kontaktdaten für Kunden lesen:
```
kubectl scale deployment contacts --replicas 0
```
Es kann bis zu fünf Minuten dauern, bis GKE das Deployment herunterskaliert hat.

Prüfen Sie den Status der Deployments in Ihrem Cluster und ob das contacts-Deployment richtig herunterskaliert wird:

kubectl get deployments

In der folgenden Beispielausgabe wurde das Deployment von contacts erfolgreich auf 0 Instanzen herunterskaliert:

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

Nachdem das contacts-Deployment auf null herunterskaliert wurde, meldet die Prometheus-Prüfung einen HTTP-Fehlercode. Dieser HTTP-Fehler generiert eine Benachrichtigung, die von Alertmanager verarbeitet wird.

Prüfen Sie in Ihrem Slack-Arbeitsbereich-Kanal, ob eine Benachrichtigung zur Störung mit einem Text ähnlich dem folgenden Beispiel angezeigt wird:
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
Bei einem echten Ausfallszenario würden Sie nach Erhalt der Benachrichtigung in Slack mit der Fehlerbehebung beginnen und die Dienste wiederherstellen. Simulieren Sie für diese Anleitung diesen Prozess und stellen Sie das contacts-Deployment wieder her, indem Sie die Anzahl der Replikate wieder hochskalieren:
```
kubectl scale deployment contacts --replicas 1
```
Es kann bis zu fünf Minuten dauern, bis das Deployment skaliert ist und die Prometheus-Prüfung eine HTTP 200-Antwort erhält. Sie können den Status der Deployments mit dem Befehl kubectl get deployments prüfen.

Wenn eine fehlerfreie Antwort auf die Prometheus-Prüfung empfangen wird, löscht Alertmanager das Ereignis. Im Slack-Arbeitsbereich-Kanal sollten Sie eine Benachrichtigung zur Auflösung sehen können, die in etwa so aussieht:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Bereinigen

Wir empfehlen Ihnen, diese Reihe von Anleitungen für Cymbal Bank in der richtigen Reihenfolge durchzugehen. Während Sie die einzelnen Anleitungen durcharbeiten, lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.

Wenn Sie eine Pause beim Durcharbeiten der Anleitungen einlegen möchten und nicht möchten, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden, löschen Sie das erstellte Projekt.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

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.

Nächste Schritte

In der nächsten Anleitung erfahren Sie, wie Sie Ihre Deployments in GKE skalieren.