Monitoring und Observability: Der vollständige Guide
In der komplexen Welt moderner verteilter Systeme reicht einfaches Monitoring nicht mehr aus. Observability ist zum neuen Standard geworden. Dieser Artikel erklärt beide Konzepte und zeigt, wie du sie in deiner Infrastruktur implementieren kannst.
Monitoring vs. Observability: Was ist der Unterschied?
Monitoring konzentriert sich auf das Sammeln und Anzeigen vordefinierter Metriken über den Systemzustand. Es beantwortet die Frage: “Funktioniert das System wie erwartet?”
Observability geht einen Schritt weiter und ermöglicht es, den internen Zustand eines Systems anhand seiner externen Ausgaben zu verstehen. Es beantwortet die Frage: “Warum verhält sich das System so?”
Die drei Säulen der Observability sind:
- Metriken: Numerische Repräsentationen des Systemzustands
- Logs: Detaillierte Ereignisaufzeichnungen
- Traces: Verfolgung des Anfrageflusses durch ein verteiltes System
Aufbau eines umfassenden Monitoring-Stacks
1. Metriken-Sammlung mit Prometheus
Prometheus ist ein Open-Source-System zur Metriken-Sammlung und -Auswertung:
# prometheus.yml
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'api-server'
static_configs:
- targets: ['api:8080']
- job_name: 'database'
static_configs:
- targets: ['db-exporter:9187']
Prometheus-Exporters
Exporters machen Systeme und Services für Prometheus überwachbar:
- node_exporter: Hostsystem-Metriken
- blackbox_exporter: Endpunkt-Überwachung
- mysql_exporter: MySQL-Metriken
PromQL-Beispiele
# Durchschnittliche CPU-Auslastung in den letzten 5 Minuten
avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
# HTTP-Fehlerrate in Prozent
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100
2. Visualisierung mit Grafana
Grafana ist die führende Plattform für die Visualisierung von Monitoring-Daten:
# grafana.ini
[server]
http_port = 3000
[security]
admin_user = admin
admin_password = secure_password
[dashboards]
default_home_dashboard_path = /etc/grafana/dashboards/overview.json
Dashboards für verschiedene Zwecke
- Systemübersicht
- Anwendungsperformance
- Fehlerraten und Alerts
- Business-Metriken
3. Logging mit dem ELK/EFK-Stack
# filebeat.yml
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/*.log
- /var/log/app/*.log
output.elasticsearch:
hosts: ["elasticsearch:9200"]
Log-Aggregation mit Fluentd/Fluentbit
<source>
@type tail
path /var/log/containers/*.log
pos_file /var/log/fluentd-containers.log.pos
tag kubernetes.*
read_from_head true
<parse>
@type json
</parse>
</source>
<match **>
@type elasticsearch
host elasticsearch
port 9200
logstash_format true
</match>
4. Distributed Tracing mit Jaeger/Zipkin
// OpenTelemetry Java Instrumentation
Tracer tracer = openTelemetry.getTracer("my-service");
Span span = tracer.spanBuilder("processOrder")
.setAttribute("orderId", orderId)
.startSpan();
try (Scope scope = span.makeCurrent()) {
// Geschäftslogik hier
processPayment(orderId);
} catch (Exception e) {
span.recordException(e);
span.setStatus(StatusCode.ERROR, e.getMessage());
throw e;
} finally {
span.end();
}
Alerts und Incident Response
Prometheus Alertmanager-Konfiguration
# alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: ['alertname', 'job']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'team-email'
receivers:
- name: 'team-email'
email_configs:
- to: '[email protected]'
- name: 'pager'
pagerduty_configs:
- service_key: '<pagerduty-key>'
SLI/SLO-Definition
Service Level Indicators (SLIs) und Service Level Objectives (SLOs) bilden die Grundlage eines datengestützten Ansatzes zur Servicequalität:
# Verfügbarkeits-SLI (99.9% SLO)
sum(rate(http_requests_total{status!~"5.."}[30d])) / sum(rate(http_requests_total[30d])) >= 0.999
# Latenz-SLI (95% der Anfragen unter 300ms)
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[30d])) by (le)) <= 0.3
Best Practices für moderne Observability
1. USE-Methode für Ressourcen-Monitoring
- Utilization: Wie ausgelastet ist die Ressource?
- Saturation: Wie viel Arbeit wird zurückgestellt?
- Errors: Wie viele Fehler treten auf?
2. RED-Methode für Service-Monitoring
- Rate: Anfragen pro Sekunde
- Errors: Fehlerrate
- Duration: Latenz von Anfragen
3. Implementiere Zentrale Observability von Anfang an
# Docker Compose mit vollständigem Monitoring-Stack
version: '3'
services:
app:
image: myapp:latest
ports:
- "8080:8080"
labels:
- "prometheus.scrape=true"
prometheus:
image: prom/prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
grafana:
image: grafana/grafana
ports:
- "3000:3000"
depends_on:
- prometheus
loki:
image: grafana/loki
ports:
- "3100:3100"
promtail:
image: grafana/promtail
volumes:
- /var/log:/var/log
Kostenoptimierung für Observability
- Selektive Instrumentierung: Fokussiere dich auf kritische Dienste
- Intelligentes Sampling: Reduziere das Datenvolumen, behalte aber aussagekräftige Daten
- Datenaufbewahrung: Definiere Aufbewahrungsrichtlinien basierend auf Datenalter und Wichtigkeit
Fazit
Moderne Observability geht weit über traditionelles Monitoring hinaus. Durch die Integration von Metriken, Logs und Traces erhältst du ein vollständiges Bild deiner Systeme, was schnellere Fehlerbehebung und bessere Systemzuverlässigkeit ermöglicht.
Die richtige Kombination aus Tools wie Prometheus, Grafana, dem ELK-Stack und Distributed-Tracing-Lösungen schafft eine umfassende Observability-Plattform, die sowohl für kleine Startups als auch für große Unternehmen geeignet ist.
Denke daran, dass die Implementierung von Observability ein iterativer Prozess ist. Beginne mit grundlegenden Metriken, füge nach und nach weitere Dimensionen hinzu und passe deine Strategie basierend auf den gewonnenen Erkenntnissen an.
Welche Observability-Tools verwendest du in deiner Umgebung? Teile deine Erfahrungen in den Kommentaren!