Prometheus Operator – Prometheus Monitoring in der Kubernetes-Umgebung

Kubernetes Monitoring mit dem Prometheus Operator

Cloud • UPDATED ON Mai 28, 2021

Roman Prydybailo

Author

In diesem Beitrag unseres Kubernetes-Ratgebers geben wir unseren Lesern einen Überblick und eine Schritt-für-Schritt-Anleitung für die Open-Source Prometheus Operator Software. Der Prometheus Operator wird hierbei bei der Integration des Prometheus-Überwachungssystems in einer Kubernetes-Umgebung eingesetzt.

Beim Operator handelt es sich um eine neue Klasse von Software, die 2016 von CoreOS eingeführt wurde (kürzlich von Red Hat erworben). CoreOS ist das Unternehmen hinter Tectonic, der kommerziellen Kubernetes-Verteilerplattform, die den CoreOS-Stack mit Kubernetes zusammenführt, um Unternehmen eine Google-ähnliche Infrastruktur in jeder Cloud oder On-Premise-/Bare-Metal-Umgebung bereitzustellen.

Operators

Beim Operator handelt es sich um eine neue Klasse von Software, die 2016 von CoreOS eingeführt wurde (kürzlich von Red Hat erworben). CoreOS ist das Unternehmen hinter Tectonic, der kommerziellen Kubernetes-Verteilerplattform, die den CoreOS-Stack mit Kubernetes zusammenführt, um Unternehmen eine Google-ähnliche Infrastruktur in jeder Cloud oder On-Premise-/Bare-Metal-Umgebung bereitzustellen.

CoreOS erstellte Operators als eine eigene Software-Kategorie, die in der Lage ist, andere Software-Anwendungen zu bedienen. Hierzu werden betriebliche Fähigkeiten injiziert. Der Prometheus Operator optimiert die Funktionalität von Prometheus auf Kubernetes, während die Kubernetes-nativen Konfigurationsoptionen beibehalten werden können.

Die Operator-Software enthält Wissen über die Anwendungsdomänen, um regelmäßig auftretende Aufgaben zu automatisieren, was auf den Kubernetes Ressourcen- und Controller-Konzepten aufbaut. Das Kernelement der Operator-Software besteht darin, dass manuelle Bereitstellungen sowie Lebenszyklusmanagement entfernt werden, sodass sich DevOps-Ingenieure auf die Konfigurationsoptimierung konzentrieren können.

Prometheus selbst ist eng mit Kubernetes verbunden – beide befinden sich unter der Aufsicht der Cloud Native Computing Foundation (CNCF). Kubernetes entwickelte sich als Open-Source-Erweiterung von Googles Borg Cluster-System und wurde auch ursprünglich von Google veröffentlicht. Prometheus enthält dagegen viele Merkmale vom Borgmon Design-Konzept, dem Monitoring-System, das Google für Borg entwickelt hatte. Diese gemeinsame Abstammung wird deutlich, wenn man hinter die Kulissen von Kubernetes schaut, da die internen Metriken von Borg im gleichen Prometheus-nativen Format exportiert werden.

Prometheus Operator für Kubernetes

Die Zweck des Prometheus Operators besteht darin, den Betrieb von Prometheus auf Kubernetes so einfach wie möglich zu gestalten und gleichzeitig die Konfigurationsfähigkeit aufrechtzuerhalten und die Konfiguration Kubernetes-nativ zu erstellen (Quelle).

Der Operator nimmt dem Benutzer (Administrator) die Bearbeitung von Konfigurationsdateien ab und konfiguriert Prometheus automatisch basierend auf YAML-Dateien.

So funktioniert’s

Prometheus Operator Architektur (Quelle)

Der Prometheus Operator: Optimierung der Prometheus- und Kubernetes-Integration

Die Installation vom Prometheus Operator gestaltet sich so einfach wie das Schreiben einer einzigen Befehlszeile. Das Ergebnis dieser einfachen Befehlszeile besteht darin, dass DevOps-Ingenieure Prometheus-Instanzen mit einer abgespeckten deklarativen Konfiguration verwalten können. Diese Konfiguration führt zur Erstellung, Konfiguration und Verwaltung von Prometheus-Monitoring-Instanzen.

Der Prometheus Operator bietet eine Reihe von Kernfunktionen an:

Create/Destroy

Eine Prometheus-Instanz kann einfach im Kubernetes namespace, durch ein Team, das den Operator bedient oder mit einer bestimmten Anwendung eingeleitet werden.

Einfache Konfiguration

Die Grundlagen von Prometheus sind wie die Versionen, Beständigskeits-, Retentionsrichtlinien und Repliken einer nativen Kubernetes-Ressource konfiguriert.

Target-Services durch Labels

Die Überwachung von Zielkonfigurationen wird automatisch erstellt und basiert auf bekannten Kubernetes-Label-Anfragen. Prometheus benötigt keine Entwickler, die eine eindeutige Konfigurationssprache lernen.

Custom Resource Definitions (CRD) im Prometheus Operator

Der Prometheus Operator verwendet CRD (Custom Resource Definitions), um Konfigurationsdateien zu generieren und Prometheus-Ressourcen zu ermitteln.

• Alertmanagers – Definiert die Installation für Alertmanager
• Podmonitors – Bestimmt, welche Pods überwacht werden sollen
• Prometheuses – Definiert die Installation für Prometheus
• Prometheusrules – Definiert Regeln für den Alertmanager
• Servicemonitors – Bestimmt, welche Dienste überwacht werden sollen

Der Operator überwacht die Prometheus-Ressourcen und generiert das StatefullSet (Prometheus und Alertmanager) sowie die Konfigurationsdateien (prometheus.yaml, alertmanager.yaml).

Der Operator überwacht ebenfalls Ressourcen von ServiceMonitors, PodMonitors und ConfigMaps und generiert hierauf basierend Prometheus.yaml.

Prometheus Pod

3 Container werden in Prometheus gestartet:

• Prometheus
• Prometheus-config-Reloader – ein Add-on von Prometheus, das Änderungen in Prometheus.yaml überwacht sowie eine HTTP-Anfrage, die die Prometheus-Konfiguration erneut aufruft
• Rules-ConfigMap-Reloader – überwacht Änderungen in der Alerts-Datei und ruft ebenfalls Prometheus erneut auf

Verarbeitung der Service Monitors:

• Der Prometheus Operator überwacht die Eingabe, Entfernung und Modifizierung der Service Monitor Ressource Events.
• Basierend auf ServiceMonitors erzeugt Prometheus einen Teil der Konfigurationsdatei und speichert das Secret in Kubernetes
• Von Kubernetes Secret Config nach under
• Änderungen werden vom Prometheus-Config-Reloader entdeckt und Prometheus wird neu geladen
• Prometheus lädt die Konfiguration nach reboot erneut und sammelt neue Metriken entsprechend dieser Logik

Alertmanager-Pod

Wie bei Prometheus laufen 2 containers in einem Pod:

• Alertmanager
• config-reloader – ein Add-on zum Alertmanager, welches Änderungen überwacht und den Alertmanager via HTTP-Anforderung neu lädt

Grafana Pod

• Grafana
• Grafana-SC-Dashboard – ein Add-on für Grafana, das basierend auf den Ressourcen von ConfigMaps json Dashboards für Grafana
• Grafana-sc-dashboard – an add-on to grafana which will subsribe to ConfigMaps resources and generate json dashboards for Grafana based on them

So installieren und konfigurieren Sie den Prometheus Operator: Eine Schritt-für-Schritt-Anleitung

Prometheus wird mithilfe von helm installiert.

Wir klonen das Repository und aktualisieren den Envoy:

cd charts/stable/prometheus-operator
helm dependency update

Nun wird Prometheus installiert:

helm install --name prometheus --namespace monitoring prometheus-operator

Jetzt sollten Nutzer Folgendes sehen:

kubectl get pod

NAME                                                     READY   STATUS    RESTARTS   AGE
alertmanager-prometheus-prometheus-oper-alertmanager-0   2/2     Running   0          1m
prometheus-grafana-656769c888-445wm                      2/2     Running   0          1m
prometheus-kube-state-metrics-57f9c94c59-sg5bn           1/1     Running   0          1m
prometheus-prometheus-oper-operator-6844ff8f64-rzwlf     2/2     Running   0          1m
prometheus-prometheus-prometheus-oper-prometheus-0       3/3     Running   1          1m

Nachdem alle Pods gestartet sind, können wir uns das Web-UI ansehen:

kubectl port-forward prometheus-prometheus-prometheus-oper-prometheus-0 9090:9090

Öffnen Sie im Browser http: // localhost: 9090. Die Standarddienste sollten unter „Service Discovery“ aufgeführt sein:

Um zu sehen, welche Metriken benötigt werden, sollte folgender Befehl ausgeführt werden:

kubectl get servicemonitors.monitoring.coreos.com

Ergebnisse:

prometheus-prometheus-oper-alertmanager              19d
prometheus-prometheus-oper-apiserver                 19d
prometheus-prometheus-oper-coredns                   19d
prometheus-prometheus-oper-grafana                   19d
prometheus-prometheus-oper-kube-controller-manager   19d
prometheus-prometheus-oper-kube-etcd                 19d
prometheus-prometheus-oper-kube-proxy                19d
prometheus-prometheus-oper-kube-scheduler            19d
prometheus-prometheus-oper-kube-state-metrics        19d
prometheus-prometheus-oper-kubelet                   19d
prometheus-prometheus-oper-operator                  19d
prometheus-prometheus-oper-prometheus                19d

Wir haben dasselbe im Web-UI gesehen.

Fügen Sie nun unsere eigenen Metriken zu Prometheus hinzu. Als Beispiel verwenden wir traefik. Erstellen Sie die traefik-deployment.yaml-Datei und installieren Sie diese in Kubernetes:

vi traefik-deployment.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: traefik
  namespace: ingress
  labels:
    app: traefik
spec:
  replicas: 1
  selector:
    matchLabels:
      app: traefik
  template:
    metadata:
      labels:
        app: traefik
    spec:
      containers:
      - image: traefik:v1.7.11-alpine
        name: traefik-ingress-lb
        args:
        - --api
        - --api.statistics
        - --kubernetes
        - --logLevel=INFO
        - --configfile=/config/traefik.toml
        ports:
          - containerPort: 8080
            name: metrics

kubectl apply -f traefik-deployment.yaml

Schauen Sie nach folgenden Metriken:

kubectl port-forward  traefik-hjbjk 8080:8080

Öffnen Sie den Browser http: // localhost: 8080 / metrics. Hier sollte Folgendes erscheinen:

Erstellen Sie nun die traefik-metrics-service.yaml Service-Datei für folgende Metriken:

vi traefik-metrics-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: traefik-metrics
  namespace: ingress
  labels:
    app: traefik-metrics
    release: monitoring
spec:
  selector:
    app: traefik
  ports:
  - name: metrics
    port: 8080
    targetPort: 8080
  type: ClusterIP

Stellen Sie diese in unserem Kubernetes bereit:

kubectl apply -f traefik-metrics-service.yaml

Wir prüfen unseren Service:

kubectl port-forward svc/traefik-metrics 8080:8080

Auf http: // localhost: 8080 / metrics sollten Sie dieselben Metriken wie im oben beschriebenen Port-Forward sehen.

Jetzt: deployServiceMonitors. Prometheus entdeckt ServiceMonitors nach Label. Sie sollten wissen, nach welchem ServiceMonitors-Label Ausschau gehalten wird. Hierzu ist folgender Schritt nötig:

kubectl get prometheuses.monitoring.coreos.com -oyaml

Wir schauen uns den serviceMonitorSelector-Block an:

serviceMonitorNamespaceSelector: {}
serviceMonitorSelector:
  matchLabels:
    release: monitoring

In unserem Fall handelt es sich um release: monitoring. Da wir das Label kennen, können wir den traefik-servicemonitor.yaml-File erstellen:

vi traefik-servicemonitor.yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: traefik
  labels:
    release: monitoring
    app: traefik-metrics
spec:
  endpoints:
  - port: metrics
    path: '/metrics'
  namespaceSelector:
    any: true
  selector:
    matchLabels:
      app: traefik-metrics
      release: monitoring

Ein neues Target sollte nun in Prometheus erscheinen, schauen Sie hierzu nach:

kubectl port-forward prometheus-prometheus-prometheus-oper-prometheus-0 9090:9090

Öffnen Sie den Browser http: // localhost: 9090:

Wenn die Metriken erfolgreich sind, kann ein Dashboard für Grafana erstellt werden.

Laden Sie das Dashboard hier herunter -. Und ändern Sie es in ConfigMap:

vi traefik-dashboard.yaml

{{- if and .Values.grafana.enabled .Values.grafana.defaultDashboardsEnabled .Values.kubeEtcd.enabled }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ printf "%s-%s" (include "prometheus-operator.fullname" $) "traefik" | trunc 63 | trimSuffix "-" }}
  labels:
    {{- if $.Values.grafana.sidecar.dashboards.label }}
    {{ $.Values.grafana.sidecar.dashboards.label }}: "1"
    {{- end }}
    app: {{ template "prometheus-operator.name" $ }}-grafana
{{ include "prometheus-operator.labels" $ | indent 4 }}
data:
  traefik.json: |-
    JSON Dashboard starts
    ......
    JSON Dashboard ends
{{- end }}

Rücken Sie json unseres Dashboards mit JSON Dashboard starts ……. JSON Dashboard ends ein. In JSON selbst ist es wichtig, Ausdrücken wie {{Instance}} in {{{{Instance}}}} zu entgehen.

Wir fügen jetzt unsere Datei in den Prometheus Operator / Templates / Grafana / Dashboards ein:

 
helm upgrade prometheus ./

Nun erscheint das Dashboard in Grafana.

Der Prometheus Operator befindet sich noch in der Entwicklungsphase

Dies sind die Grundprinzipien des Prometheus Operators. Beachten Sie bitte, dass sich der Prometheus Operator noch in der Entwicklungsphase befindet, was bedeutet, dass die Schritt-für-Schritt-Anweisung schnell veralten kann. Wir werden diese Anleitung zeitnahe aktualisieren, verweisen jedoch gleichzeitig auf das CoreOS-Benutzerhandbuch und das Github-Projekt für die neuesten Informationen.

DevOps-Consulting von K&C

Prometheus Operator Monitoring zur Überwachung der Infrastruktur, um Ausfälle und Fehler vorherzusagen und Sicherheitsbedrohungen bereits im Vorfeld ausfindig zu machen, ist nur ein Teil von