Produktionsüberwachung und Alarmierung: Die vollständige Einrichtungsanleitung

Der durchschnittliche Produktionsvorfall kostet 5.600 US-Dollar pro Minute Ausfallzeit. Unternehmen mit ausgereifter Überwachung erkennen Probleme in weniger als 5 Minuten, während Unternehmen ohne Überwachung durchschnittlich 197 Minuten bis zur Entdeckung benötigen – der Unterschied zwischen einem kleinen Fehler und einer Kundenverlustkatastrophe.

In diesem Leitfaden geht es um die Einrichtung der End-to-End-Produktionsüberwachung: Was soll gemessen werden, wie wird es erfasst, wo wird es visualisiert und wann wird eine Warnung ausgegeben?

Wichtige Erkenntnisse

• Die drei Säulen der Beobachtbarkeit (Metriken, Protokolle, Traces) dienen unterschiedlichen Zwecken und alle drei sind notwendig
• Warnung bei Symptomen (Fehlerrate, Latenz) und nicht bei Ursachen (CPU-Auslastung), um das Rauschen um 80 % zu reduzieren
• An jede Warnung angehängte Runbooks gewährleisten eine konsistente Reaktion auf Vorfälle, unabhängig davon, wer im Einsatz ist – Beginnen Sie mit 5 wesentlichen Warnungen und erweitern Sie diese erst, wenn Sie die Grundlinie verstanden haben

---

Die drei Säulen der Beobachtbarkeit

Metriken

Numerische Messungen im Zeitverlauf. Metrik-Antwort: „Was passiert gerade?“

Anwendungsmetriken:

• Anfragerate (Anfragen pro Sekunde)
• Fehlerrate (5xx Antworten pro Sekunde)
• Latenzverteilung (P50, P95, P99)
• Aktive Sitzungen/gleichzeitige Benutzer

Infrastrukturkennzahlen:

• CPU-Auslastung pro Dienst
• Speichernutzung und Garbage Collection
• Festplatten-E/A und verfügbarer Speicherplatz
• Netzwerkdurchsatz

Geschäftskennzahlen:

• Bestellungen pro Minute
• Warenkorbabbruchrate
• Umsatz pro Stunde
• API-Aufrufe nach Endpunkt

Protokolle

Zeitgestempelte, strukturierte Aufzeichnungen diskreter Ereignisse. Protokollantwort: „Warum ist es passiert?“

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

Best Practices für Protokolle:

• Verwenden Sie strukturierte JSON-Protokollierung, keinen einfachen Text – Schließen Sie Korrelations-IDs (requestId) über alle Dienste hinweg ein
• Protokollieren Sie auf geeigneten Ebenen (ERROR für Ausfälle, WARN für Verschlechterung, INFO für wichtige Ereignisse)
• Protokollieren Sie niemals sensible Daten (Passwörter, Token, vollständige Kreditkartennummern)

Spuren

End-to-End-Anfragepfade durch verteilte Systeme. Traces antwortet: „Wo ist der Engpass?“

Eine einzelne Benutzeranfrage an eine E-Commerce-Kaufabwicklung könnte Folgendes berühren:

1. Nginx (2 ms) zum Next.js-Frontend (50 ms) zur NestJS-API (120 ms) zu PostgreSQL (45 ms) zur Stripe-API (800 ms) zum E-Mail-Dienst (200 ms)

Ohne Nachverfolgung wird angezeigt, dass der Checkout 1,2 Sekunden dauert. Bei der Nachverfolgung wird angezeigt, dass „67 % der Checkout-Latenz auf die Stripe-API zurückzuführen ist.“

---

Überwachungsstapel-Setup

Prometheus + Grafana (selbst gehostet)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

Prometheus-Konfiguration

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

rule_files:
  - "alerts/*.yml"

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

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

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

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

---

NestJS-Anwendungsmetriken

Offenlegung von Prometheus-Metriken

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

---

Alarmkonfiguration

Die fünf wesentlichen Warnungen

Jedes Produktionssystem benötigt vom ersten Tag an diese Warnungen:

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

Alarmweiterleitung

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

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

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

Regeln für die Alarmqualität

---

Grafana-Dashboards

Dashboard-Hierarchie

1. Übersichts-Dashboard: Hoher Zustand aller Dienste. Dies ist der erste Bildschirm, auf den jemand während eines Vorfalls schaut.
2. Service-Dashboards: Detaillierte Metriken für jeden Service (API, Web, Worker).
3. Infrastruktur-Dashboards: Metriken auf Knotenebene (CPU, Speicher, Festplatte, Netzwerk).
4. Business-Dashboards: Umsatz, Bestellungen, Benutzeraktivität.

Die RED-Methode für Service-Dashboards

Zeigen Sie für jeden Dienst Folgendes an:

• Rate: Anfragen pro Sekunde
• **Fehler: Fehlerquote in Prozent
• Duration: Latenzverteilung (P50, P95, P99)

Dies bietet sofortigen Einblick in den Servicezustand ohne kognitive Überlastung.

---

Fehlerverfolgung mit Sentry

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Sentry bietet:

• Automatische Fehlergruppierung und Deduplizierung
• Stapeln Sie Spuren mit Quellkarten
• Release-Tracking (welches Deployment verursachte den Fehler)
• Leistungsüberwachung (Transaktionsspuren)

---

Häufig gestellte Fragen

Wie viel kostet ein Überwachungsstapel?

Selbstgehostet (Prometheus + Grafana + Loki): ca. 50–100 $/Monat für die Hosting-Ressourcen. Verwaltete Alternativen: Datadog beginnt bei 15 $/Host/Monat für Infrastruktur, plus 0,10 $/GB für Protokolle. Sentry Cloud kostet für den Teamplan 26 $/Monat. Ein angemessenes Startbudget für ein kleines Unternehmen liegt bei insgesamt 100–200 US-Dollar pro Monat.

Was ist der Unterschied zwischen Überwachung und Beobachtbarkeit?

Die Überwachung sagt Ihnen, wenn etwas nicht stimmt. Die Beobachtbarkeit verrät Ihnen, warum. Bei der Überwachung handelt es sich um vordefinierte Dashboards und Warnungen für bekannte Fehlermodi. Bei der Beobachtbarkeit geht es um die Möglichkeit, mithilfe von Metriken, Protokollen und Traces beliebige Fragen zum Verhalten Ihres Systems zu stellen. Sie brauchen beides, aber die Überwachung ist die Grundlage.

Wie vermeiden wir Alarmmüdigkeit?

Drei Regeln: (1) Jede Warnung muss menschliches Eingreifen erfordern, (2) Schwellenwerte festlegen, die auf tatsächlichen Grundwerten und nicht auf theoretischen Idealen basieren, (3) Warnungen monatlich überprüfen und anpassen. Wenn eine Warnung mehr als einmal pro Woche ausgelöst wird, ohne dass Maßnahmen erforderlich sind, beheben Sie entweder das zugrunde liegende Problem oder erhöhen Sie den Schwellenwert. Teams, die unter Alarmmüdigkeit leiden, ignorieren alle Alarme, auch die kritischen.

Sollten wir unser ERP-System anders überwachen?

ERP-Systeme haben besondere Überwachungsanforderungen. Über die Standard-Webmetriken hinaus können Sie Folgendes überwachen: Nutzung des Datenbankverbindungspools, Tiefe der Warteschlange für Hintergrundjobs, Synchronisierungsstatus der Integration (Shopify, Zahlungsgateways), geplante Berichtsausführungszeit und Anzahl der Benutzersitzungen nach Modul. ECOSIRE bietet managed Odoo Monitoring als Teil unserer Supportpakete.

---

Was als nächstes kommt

Die Überwachung ist die Augen und Ohren Ihrer Produktionsinfrastruktur. Kombinieren Sie es mit CI/CD-Automatisierung für Bereitstellungssicherheit und Disaster-Recovery-Planung für Ausfallsicherheit. Eine umfassende DevOps-Roadmap finden Sie in unserem DevOps-Leitfaden für kleine Unternehmen.

Kontaktieren Sie ECOSIRE für die Überwachung der Einrichtung und verwalteter Infrastrukturdienste.

---

Herausgegeben von ECOSIRE – hilft Unternehmen zu erkennen, worauf es in der Produktion ankommt.