Monitoring mit Prometheus und Grafana - Vollständiger Leitfaden

In der Ära von Microservices, Containerisierung und verteilten Systemen ist Monitoring kein optionales Add-on mehr -- es ist zu einem fundamentalen Pfeiler der Zuverlässigkeit geworden. Ohne angemessenen Einblick in das Systemverhalten wird jeder Vorfall zu einem Ratespiel. Prometheus und Grafana haben sich als De-facto-Standard in der Open-Source-Observability etabliert und betreiben Systeme von kleinen Startups bis hin zu Fortune-500-Unternehmen.

In diesem Artikel gehen wir den vollständigen Prozess der Monitoring-Implementierung durch -- vom Verständnis der Observability-Grundlagen über die Prometheus-Architektur und Exporter-Konfiguration bis hin zum Aufbau von Grafana-Dashboards und der Einrichtung von Alerting. Wir besprechen auch kommerzielle Alternativen wie Datadog und New Relic, damit Sie eine fundierte Entscheidung treffen können.

Die drei Säulen der Observability#

Observability ist die Fähigkeit eines Systems, seinen internen Zustand anhand externer Signale offenzulegen. Sie basiert auf drei Säulen, von denen jede eine andere Art diagnostischer Informationen liefert.

Metriken (Metrics)#

Metriken sind numerische Daten, die über die Zeit gemessen werden -- Counter, Histogramme, Gauges. Sie beantworten die Frage "Was passiert gerade?". Beispiele umfassen HTTP-Anfragen pro Sekunde, CPU-Auslastung, API-Antwortzeit und aktive Datenbankverbindungen. Metriken sind leichtgewichtig in der Speicherung und ideal für Trenderkennung und Alerting.

Logs#

Logs sind strukturierte oder unstrukturierte Aufzeichnungen von Ereignissen. Sie beantworten die Frage "Warum ist etwas passiert?". Beispiele sind Fehler-Stacktraces, HTTP-Zugriffsprotokolle und Anwendungsnachrichten. Logs sind beim Debugging unschätzbar wertvoll, aber ihre Speicherung und Durchsuchung im großen Maßstab kann teuer sein.

Traces#

Verteilte Traces verfolgen den Fluss einer Anfrage durch mehrere Dienste. Sie beantworten die Frage "Wo in der Aufrufkette liegt das Problem?". Tools wie Jaeger oder Tempo visualisieren Traces als Wasserfall-Diagramme und zeigen genau, wie viel Zeit jeder Dienst für die Verarbeitung einer Anfrage benötigt hat.

Prometheus spezialisiert sich auf Metriken -- und macht das außergewöhnlich gut. Für Logs empfiehlt sich Loki (ebenfalls von Grafana Labs), für Traces Tempo oder Jaeger. Alle drei integrieren sich mit Grafana und bilden einen vollständigen Observability-Stack, bekannt als "Grafana Stack" (früher LGTM -- Loki, Grafana, Tempo, Mimir).

Prometheus-Architektur#

Prometheus zeichnet sich durch seine Pull-basierte Architektur aus. Anstatt Daten von Anwendungen zu empfangen (Push), ruft es aktiv Metriken von HTTP-Endpunkten in regelmäßigen Abständen ab. Dieses Modell vereinfacht die Konfiguration und ermöglicht eine einfache Erkennung, ob ein bestimmtes Ziel verfügbar ist.

Kernkomponenten#

Prometheus Server -- der Hauptserver, verantwortlich für Scraping, Speicherung der Daten in seiner lokalen TSDB (Time Series Database) und Abfrage über PromQL
Exporters -- Prozesse, die Metriken im Prometheus-Format bereitstellen (Node Exporter für Systemmetriken, cAdvisor für Container, Datenbank-Exporter für PostgreSQL/MySQL/Redis)
Pushgateway -- ein Vermittler für kurzlebige Jobs (Batch-Jobs), die im Pull-Modell nicht abgefragt werden können
Alertmanager -- ein dedizierter Dienst zur Alert-Verarbeitung: Routing, Deduplizierung, Stummschaltung und Versand von Benachrichtigungen an Slack, E-Mail, PagerDuty
Service Discovery -- Mechanismen zur automatischen Zielerkennung (Kubernetes, Consul, DNS, statische Dateien)

Datenmodell#

Prometheus speichert Daten als Zeitreihen (Time Series) -- Sequenzen von Werten mit Zeitstempeln. Jede Reihe wird durch einen Metriknamen und einen Satz von Labels identifiziert:

http_requests_total{method="GET", endpoint="/api/users", status="200"} 1547

Metriktypen in Prometheus:

Counter -- ein monoton steigender Wert (z.B. http_requests_total). Sinkt nie, wird nur bei Prozess-Neustart zurückgesetzt
Gauge -- ein Wert, der steigen und fallen kann (z.B. temperature_celsius, active_connections)
Histogram -- gebuckelte Beobachtungen mit Summe und Zähler (z.B. http_request_duration_seconds). Ideal für die Messung von Perzentilen
Summary -- ähnlich wie Histogram, aber mit clientseitig berechneten Quantilen. Seltener verwendet, da eine Aggregation über Instanzen hinweg nicht möglich ist

Prometheus-Konfiguration#

Die Hauptkonfigurationsdatei von Prometheus ist prometheus.yml. Sie definiert globale Einstellungen, Scrape-Ziele und Alert-Regeln:

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  scrape_timeout: 10s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "alertmanager:9093"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"]

  - job_name: "dotnet-app"
    metrics_path: /metrics
    static_configs:
      - targets: ["dotnet-api:5000"]

  - job_name: "nodejs-app"
    static_configs:
      - targets: ["nodejs-api:3000"]

Jeder job_name definiert eine Gruppe von Zielen. Prometheus fragt regelmäßig jedes Ziel unter dem Pfad /metrics (Standard) ab und speichert die empfangenen Metriken in seiner Datenbank.

PromQL -- Die Abfragesprache von Prometheus#

PromQL (Prometheus Query Language) ist eine leistungsstarke, funktionale Abfragesprache zur Analyse von Metrikdaten. Sie ist das Herzstück von Prometheus und der Schlüssel zu effektivem Monitoring.

Grundlegende Abfragen#

# Aktueller Metrikwert
up

# Filterung nach Labels
http_requests_total{method="GET", status="200"}

# Regex-Matching
http_requests_total{status=~"5.."}

# Label-Ausschluss
http_requests_total{method!="OPTIONS"}

Bereichsfunktionen und Rate#

# Anfragerate pro Sekunde (letzte 5 Minuten)
rate(http_requests_total[5m])

# Absoluter Anstieg innerhalb einer Stunde
increase(http_requests_total[1h])

# Rate nach Endpunkt
sum by (endpoint) (rate(http_requests_total[5m]))

Fortgeschrittene Abfragen#

# 95. Perzentil der Antwortzeit (Histogram)
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

# Fehlerrate in Prozent
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
* 100

# Dienstverfügbarkeit (Uptime)
avg_over_time(up[24h]) * 100

# Top 5 Endpunkte nach Traffic
topk(5, sum by (endpoint) (rate(http_requests_total[5m])))

# Vorhersage -- in wie vielen Stunden ist die Festplatte voll
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600)

PromQL unterstützt auch binäre Operationen zwischen Metriken, Ergebnisgruppierung (by, without) und Aggregationsfunktionen (sum, avg, min, max, count).

Node Exporter -- Systemmetriken#

Node Exporter ist der offizielle Prometheus-Exporter für Linux/Unix-Systemmetriken. Er liefert Daten über CPU, Speicher, Festplatte, Netzwerk und viele andere Ressourcen.

Wichtige Metriken#

# CPU-Auslastung (Prozent)
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# RAM-Auslastung (Prozent)
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Festplattenauslastung (Prozent)
(1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100

# Netzwerkverkehr (Bytes/s)
rate(node_network_receive_bytes_total{device="eth0"}[5m])

# Load Average
node_load1
node_load5
node_load15

Weitere nützliche Exporter sind cAdvisor (Docker-Container-Metriken), blackbox_exporter (HTTP/TCP/ICMP-Probing), postgres_exporter, redis_exporter und mysqld_exporter.

Anwendungsmetriken#

.NET -- prometheus-net#

Für .NET-Anwendungen (ASP.NET Core) verwenden wir die Bibliothek prometheus-net:

// Program.cs
using Prometheus;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// Middleware zum Sammeln von HTTP-Metriken
app.UseHttpMetrics(options =>
{
    options.AddCustomLabel("host", context => context.Request.Host.Host);
});

app.MapControllers();

// /metrics Endpunkt bereitstellen
app.MapMetrics();

app.Run();

// Benutzerdefinierte Metriken in einem Service
using Prometheus;

public class OrderService
{
    private static readonly Counter OrdersCreated = Metrics
        .CreateCounter("orders_created_total", "Total orders created",
            new CounterConfiguration
            {
                LabelNames = new[] { "payment_method", "status" }
            });

    private static readonly Histogram OrderProcessingDuration = Metrics
        .CreateHistogram("order_processing_duration_seconds",
            "Time spent processing an order",
            new HistogramConfiguration
            {
                Buckets = Histogram.ExponentialBuckets(0.01, 2, 10)
            });

    private static readonly Gauge ActiveOrders = Metrics
        .CreateGauge("active_orders", "Number of currently active orders");

    public async Task<Order> CreateOrder(OrderRequest request)
    {
        ActiveOrders.Inc();
        using (OrderProcessingDuration.NewTimer())
        {
            try
            {
                var order = await ProcessOrder(request);
                OrdersCreated.WithLabels(request.PaymentMethod, "success").Inc();
                return order;
            }
            catch (Exception)
            {
                OrdersCreated.WithLabels(request.PaymentMethod, "failed").Inc();
                throw;
            }
            finally
            {
                ActiveOrders.Dec();
            }
        }
    }
}

Node.js -- prom-client#

Für Node.js-Anwendungen (Express) verwenden wir prom-client:

// metrics.js
const client = require('prom-client');

// Standard-Metriken (CPU, Speicher, Event Loop, GC)
client.collectDefaultMetrics({ prefix: 'nodejs_' });

// HTTP-Metriken
const httpRequestDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
});

const httpRequestsTotal = new client.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'status_code'],
});

const activeConnections = new client.Gauge({
  name: 'active_connections',
  help: 'Number of active connections',
});

// Express-Middleware
function metricsMiddleware(req, res, next) {
  const end = httpRequestDuration.startTimer();
  activeConnections.inc();

  res.on('finish', () => {
    const route = req.route?.path || req.path;
    const labels = {
      method: req.method,
      route: route,
      status_code: res.statusCode,
    };
    end(labels);
    httpRequestsTotal.inc(labels);
    activeConnections.dec();
  });

  next();
}

module.exports = { metricsMiddleware, client };

// app.js
const express = require('express');
const { metricsMiddleware, client } = require('./metrics');

const app = express();

app.use(metricsMiddleware);

app.get('/metrics', async (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(await client.register.metrics());
});

app.get('/api/health', (req, res) => {
  res.json({ status: 'healthy', uptime: process.uptime() });
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Grafana -- Visualisierung und Dashboards#

Grafana ist eine Visualisierungsplattform, die rohe Metriken in lesbare, interaktive Dashboards verwandelt. Sie unterstützt Dutzende von Datenquellen -- Prometheus, InfluxDB, Elasticsearch, PostgreSQL, Loki und viele mehr.

Datenquellenkonfiguration#

Nach der Installation von Grafana ist der erste Schritt das Hinzufügen von Prometheus als Datenquelle. Dies kann über die grafische Oberfläche oder automatisch per Provisioning erfolgen:

# grafana/provisioning/datasources/prometheus.yml
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false
    jsonData:
      timeInterval: "15s"
      httpMethod: POST

Panel-Typen in Grafana#

Grafana bietet vielfältige Visualisierungstypen:

Time series -- klassisches Liniendiagramm, ideal für Metriken, die sich über die Zeit ändern
Stat -- ein einzelner Wert mit optionaler Sparkline (z.B. aktuelle Fehlerrate)
Gauge -- Tachometer-Visualisierung (z.B. CPU-Auslastung in Prozent)
Table -- tabellarische Daten mit Sortier- und Filterfunktionen
Heatmap -- ideal für die Visualisierung von Histogram-Verteilungen
Bar chart -- Vergleiche zwischen Kategorien
Logs -- Integration mit Loki zur Anzeige von Logs neben Metriken

Die vier goldenen Signale (Golden Signals)#

Google SRE definiert vier Schlüsselsignale, die für jeden Dienst überwacht werden sollten:

1. Latenz (Latency) -- die Antwortzeit für Anfragen:

histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

2. Verkehr (Traffic) -- das Volumen der Anfragen:

sum(rate(http_requests_total[5m]))

3. Fehler (Errors) -- die Fehlerrate:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

4. Sättigung (Saturation) -- der Auslastungsgrad der Ressourcen:

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Dashboard-Provisioning#

Dashboards können als Code (JSON) definiert und automatisch geladen werden:

# grafana/provisioning/dashboards/dashboards.yml
apiVersion: 1

providers:
  - name: 'default'
    orgId: 1
    folder: 'Infrastructure'
    type: file
    disableDeletion: false
    editable: true
    options:
      path: /var/lib/grafana/dashboards
      foldersFromFilesStructure: true

Alerting mit Alertmanager#

Der Alertmanager verarbeitet von Prometheus generierte Alerts -- er gruppiert, dedupliziert, unterdrückt und leitet sie an die entsprechenden Benachrichtigungskanäle weiter.

Alert-Regeln in Prometheus#

# alerts/application.yml
groups:
  - name: application
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))
          > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Hohe Fehlerrate (> 5%)"
          description: "Fehlerrate beträgt {{ $value | humanizePercentage }} für {{ $labels.job }}"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
          > 1.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Hohe P95-Latenz (> 1s)"
          description: "P95-Latenz beträgt {{ $value }}s"

      - alert: HighMemoryUsage
        expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Hohe Speicherauslastung (> 85%)"

      - alert: DiskSpaceRunningLow
        expr: |
          (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 > 80
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Wenig Festplattenplatz (> 80% belegt)"

      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Dienst {{ $labels.job }} ist nicht erreichbar"

Alertmanager-Konfiguration#

# alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_from: "alerts@example.com"
  smtp_smarthost: "smtp.example.com:587"
  smtp_auth_username: "alerts@example.com"
  smtp_auth_password: "secret"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      repeat_interval: 1h
    - match:
        severity: warning
      receiver: 'warning-alerts'

receivers:
  - name: 'default'
    email_configs:
      - to: "team@example.com"

  - name: 'critical-alerts'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/xxx/yyy/zzz"
        channel: "#alerts-critical"
        title: '{{ .CommonAnnotations.summary }}'
        text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'
    pagerduty_configs:
      - service_key: "your-pagerduty-key"

  - name: 'warning-alerts'
    slack_configs:
      - api_url: "https://hooks.slack.com/services/xxx/yyy/zzz"
        channel: "#alerts-warning"

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Alertmanager unterstützt auch Integrationen mit Microsoft Teams, OpsGenie, VictorOps und Webhooks, sodass Sie sich in bestehende Incident-Response-Prozesse einfügen können.

Docker Compose -- Vollständiger Monitoring-Stack#

Nachfolgend die vollständige Docker-Compose-Konfiguration, bereit zum Start in wenigen Minuten:

# docker-compose.monitoring.yml
version: "3.8"

services:
  prometheus:
    image: prom/prometheus:v2.48.0
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./prometheus/alerts:/etc/prometheus/alerts
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'
      - '--web.enable-admin-api'
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:10.2.0
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=SecurePassword123
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://grafana.example.com
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    depends_on:
      - prometheus
    networks:
      - monitoring

  alertmanager:
    image: prom/alertmanager:v0.26.0
    container_name: alertmanager
    restart: unless-stopped
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - alertmanager_data:/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
    networks:
      - monitoring

  node-exporter:
    image: prom/node-exporter:v1.7.0
    container_name: node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    networks:
      - monitoring

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.47.0
    container_name: cadvisor
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    privileged: true
    devices:
      - /dev/kmsg:/dev/kmsg
    networks:
      - monitoring

volumes:
  prometheus_data:
  grafana_data:
  alertmanager_data:

networks:
  monitoring:
    driver: bridge

Zum Starten des Stacks:

docker compose -f docker-compose.monitoring.yml up -d

Nach dem Start sind folgende Dienste verfügbar:

Prometheus: http://localhost:9090
Grafana: http://localhost:3001
Alertmanager: http://localhost:9093
Node Exporter: http://localhost:9100/metrics
cAdvisor: http://localhost:8080

Monitoring in Kubernetes#

In Kubernetes-Umgebungen ist die bequemste Lösung der kube-prometheus-stack (früher prometheus-operator), installiert über Helm:

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

helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword="SecurePassword123" \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

ServiceMonitor -- Automatische Erkennung#

In Kubernetes erfolgt die Dienstüberwachung über ServiceMonitor CRDs:

# servicemonitor.yml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-api-monitor
  namespace: monitoring
  labels:
    release: kube-prometheus
spec:
  namespaceSelector:
    matchNames:
      - production
  selector:
    matchLabels:
      app: my-api
  endpoints:
    - port: http
      path: /metrics
      interval: 15s
      scrapeTimeout: 10s

Benutzerdefinierte Metriken -- Best Practices#

Bei der Definition eigener Metriken sollten Sie folgende Prinzipien beachten:

Namenskonvention -- verwenden Sie das Format namespace_subsystem_name_unit. Beispiel: myapp_orders_processing_duration_seconds
Verwenden Sie geeignete Typen -- Counter für Ereignisse (Anfragen, Fehler), Gauge für Zustände (Verbindungen, Temperatur), Histogram für Verteilungen (Latenz)
Vermeiden Sie Label-Missbrauch -- jede eindeutige Label-Kombination erzeugt eine separate Zeitreihe. Vermeiden Sie Labels mit hoher Kardinalität (z.B. user_id, request_id)
Verwenden Sie SI-Basiseinheiten -- Sekunden statt Millisekunden, Bytes statt Megabytes
RED- und USE-Methoden:
- RED (Rate, Errors, Duration) -- für Dienste
- USE (Utilization, Saturation, Errors) -- für Infrastrukturressourcen
Dokumentieren Sie Ihre Metriken -- jede Metrik sollte einen beschreibenden Help-Text haben, der erklärt, was sie misst

Vergleich mit kommerziellen Lösungen#

| Aspekt | Prometheus + Grafana | Datadog | New Relic | |--------|---------------------|---------|-----------| | Kosten | Kostenlos (Open-Source) | Ab 15 $/Host/Monat | Ab 25 $/Host/Monat | | Hosting | Self-Hosted | SaaS | SaaS | | Skalierbarkeit | Erfordert Thanos/Cortex/Mimir | Integriert | Integriert | | Lernkurve | Steil (PromQL, YAML) | Moderat | Flach | | Integrationen | Hunderte Exporter | 700+ nativ | 500+ nativ | | Datenaufbewahrung | Konfigurierbar (lokal) | 15 Monate (Pro) | 8 Tage (Free) | | Alerting | Alertmanager | Integriert | Integriert | | APM / Traces | Erfordert zusätzliche Tools | Integriert | Integriert | | Logs | Loki (separates Deployment) | Integriert | Integriert |

Wann Prometheus + Grafana wählen:

Kostenkontrolle hat Priorität -- keine Gebühren pro Host oder Metrikvolumen
Sie benötigen volle Kontrolle über Daten und Infrastruktur
Sie haben Kubernetes- und DevOps-Erfahrung
Sie möchten Vendor-Lock-in vermeiden
Sie haben ein Team, das die Monitoring-Infrastruktur warten kann

Wann Datadog oder New Relic in Betracht ziehen:

Kein DevOps-Team zur Wartung der Monitoring-Infrastruktur
Sie benötigen eine All-in-One-Lösung mit APM, Logs und Traces an einem Ort
Schnelle Bereitstellung ist wichtiger als Kosten
Sie benötigen fortgeschrittenes APM mit automatischer Instrumentierung

Weitere beachtenswerte Alternativen sind Elastic Stack (ELK) für Logs und Metriken, Zabbix für traditionelles Infrastruktur-Monitoring und VictoriaMetrics als Drop-in-Ersatz für Prometheus mit besserer Performance und Kompression.

Best Practices für Monitoring#

1. Überwachen Sie, was für den Benutzer wichtig ist#

Beginnen Sie mit Geschäftsmetriken und Benutzererfahrung (Latenz, Verfügbarkeit) und arbeiten Sie sich dann zu den Infrastrukturmetriken vor. Wenn der Benutzer kein Problem wahrnimmt, sollte ein Alert niemanden nachts wecken.

2. Alerting auf Symptome, nicht Ursachen#

Alarmieren Sie bei "Fehlerrate > 5%" statt "CPU > 90%". Hohe CPU-Auslastung bedeutet nicht immer ein Problem -- eine hohe Fehlerrate hingegen schon.

3. Verwenden Sie mehrstufige Dashboards#

Executive -- SLA, Uptime, wichtige Geschäftsmetriken
Service -- Golden Signals pro Dienst
Infrastruktur -- CPU, Speicher, Festplatte, Netzwerk
Debug -- detaillierte Metriken zur Diagnose

4. Aufbewahrung und Kompression#

Speichern Sie hochauflösende Daten (15s) für 2 Wochen, heruntergetastete Daten (5min) für 6 Monate und stark aggregierte Daten (1h) für längere Zeiträume. Thanos, Cortex oder Mimir helfen bei der Langzeitspeicherung.

5. Testen Sie Alerts regelmäßig#

Alerts, die nie ausgelöst wurden, funktionieren möglicherweise nicht, wenn sie benötigt werden. Führen Sie regelmäßig "Fire Drills" durch -- simulierte Vorfälle, die die gesamte Alert-Pipeline testen.

6. Wenden Sie Infrastructure as Code an#

Bewahren Sie Prometheus-Konfigurationen, Alert-Regeln und Grafana-Dashboards in einem Git-Repository auf. Verwenden Sie Provisioning statt manueller Konfiguration über die Benutzeroberfläche.

Fazit#

Prometheus und Grafana bilden ein leistungsstarkes, ausgereiftes und praxiserprobtes Monitoring-Ökosystem. Das Pull-Modell, die PromQL-Sprache, das reichhaltige Exporter-Ökosystem und die native Kubernetes-Integration machen es zur natürlichen Wahl für DevOps- und SRE-Teams.

Wichtige Erkenntnisse:

Beginnen Sie mit den drei Säulen der Observability und den vier goldenen Signalen
Instrumentieren Sie Ihre Anwendungen vom ersten Tag an -- das nachträgliche Hinzufügen von Metriken ist schwieriger
Setzen Sie Alerts auf für den Benutzer sichtbare Symptome
Erstellen Sie mehrstufige Dashboards -- vom Gesamtbild bis zu den Details
Planen Sie Aufbewahrung und Skalierbarkeit von Anfang an
Bewahren Sie Konfigurationen in Git als Infrastructure as Code auf

Brauchen Sie professionelles Monitoring?#

MDS Software Solutions Group ist spezialisiert auf die Implementierung vollständiger Observability-Lösungen. Von der Konfiguration von Prometheus und Grafana über das Design von Alerting-Strategien bis hin zur CI/CD-Pipeline-Integration -- wir helfen Ihnen, ein Monitoring aufzubauen, das Ihre Systeme wirklich schützt.

Unser Team verfügt über Erfahrung im Monitoring von .NET-, Node.js-, Java- und Python-Anwendungen, sowohl in Docker-Compose- als auch in Kubernetes-Umgebungen. Wir entwerfen Dashboards, die wertvolle Erkenntnisse liefern, nicht Rauschen.

Kontaktieren Sie uns -- lassen Sie uns über das Monitoring Ihrer Infrastruktur sprechen.