Zum Hauptinhalt springen

Erweiterte Metriken

Der Tab Analytics zeigt CPU-, Arbeitsspeicher-, Disk-I/O- und Bandbreitenauslastung Ihrer Nodes über die letzten 24 Stunden. Für längere Aufbewahrung, anwendungsspezifische Metriken oder eigene Dashboards installieren Sie zusätzliche Komponenten im Cluster.

Eine Übersicht der eingebauten Diagramme finden Sie unter Metriken ansehen.

Voraussetzungen

  • Ein Kubernetes Cluster im Status Running und eine geprüfte Verbindung per kubectl
  • Installiertes Helm

Wann reichen die eingebauten Metriken nicht aus?

  • Sie benötigen einen längeren Zeitraum als 24 Stunden.
  • Sie möchten anwendungseigene Metriken erfassen, etwa Anfragen pro Sekunde oder Warteschlangenlängen.
  • Sie benötigen Metriken je Pod oder Namespace statt je Node.
  • Sie möchten Alerts mit eigenen Schwellenwerten und Benachrichtigungswegen definieren.

metrics-server

Der metrics-server ist die Voraussetzung für kubectl top und für Horizontal Pod Autoscaling anhand von CPU- und Speicherauslastung. Prüfen Sie zunächst, ob er bereits läuft:

kubectl get deployment metrics-server -n kube-system

Liefert der Befehl kein Ergebnis, installieren Sie ihn:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Anschließend prüfen:

kubectl top nodes
kubectl top pods --all-namespaces
Hinweis

Der metrics-server hält nur aktuelle Momentaufnahmen vor und speichert keine Historie. Für zeitliche Verläufe benötigen Sie eine Zeitreihendatenbank wie Prometheus.

Prometheus und Grafana

Für Verlaufsdaten, eigene Metriken und Alerts hat sich der kube-prometheus-stack etabliert. Er umfasst Prometheus, Grafana, den Alertmanager sowie vorkonfigurierte Dashboards.

Installation per Helm

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace

Installation prüfen:

kubectl get pods -n monitoring

Grafana aufrufen

Leiten Sie den Port lokal weiter:

kubectl port-forward -n monitoring service/monitoring-grafana 3000:80

Grafana ist danach unter http://localhost:3000 erreichbar. Das initiale Kennwort lesen Sie aus dem zugehörigen Secret:

kubectl get secret -n monitoring monitoring-grafana \
-o jsonpath="{.data.admin-password}" | base64 --decode
Warnung

Machen Sie Grafana und Prometheus nicht ohne Authentifizierung über einen NodePort öffentlich erreichbar. Verwenden Sie stattdessen port-forward oder einen Ingress mit vorgeschalteter Authentifizierung.

Ressourcenbedarf einplanen

Ein vollständiger Monitoring-Stack benötigt spürbar Ressourcen – Prometheus hält Daten im Arbeitsspeicher und schreibt kontinuierlich auf die Festplatte. Planen Sie dafür Kapazität ein und begrenzen Sie die Aufbewahrungsdauer:

helm upgrade monitoring prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--set prometheus.prometheusSpec.retention=15d

Da im Cluster kein persistenter Blockspeicher zur Verfügung steht, gehen die gesammelten Daten beim Neustart des Prometheus-Pods verloren. Für dauerhafte Auswertungen betreiben Sie Prometheus außerhalb des Clusters oder schreiben die Daten in einen externen Dienst.

Eigene Anwendungsmetriken

Stellt Ihre Anwendung Metriken im Prometheus-Format bereit, erfassen Sie diese über einen ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: meine-app
namespace: monitoring
labels:
release: monitoring
spec:
namespaceSelector:
matchNames:
- produktion
selector:
matchLabels:
app: meine-app
endpoints:
- port: metrics
interval: 30s

Der Service Ihrer Anwendung muss dafür einen benannten Port metrics bereitstellen.

Verwandte Themen