Monitoring & Logging

KAPITEL 08 · CLOUD & INFRASTRUKTUR

Monitoring & Logging

Observability, Metriken, Logs und Traces – die drei Säulen moderner Systemüberwachung. Lerne Prometheus, Grafana, ELK Stack, SIEM und Cloud-native Monitoring-Tools kennen.

Metriken Logs Traces Alerting SIEM

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernst du alles über Monitoring und Logging:

  • Grundlagen: Was ist Monitoring und Logging?
  • Three Pillars: Metriken, Logs und Traces
  • Monitoring-Tools: Prometheus, Grafana, Zabbix, Nagios, Datadog
  • Logging-Tools: ELK Stack, Splunk, Graylog, Loki
  • Log-Levels: TRACE, DEBUG, INFO, WARN, ERROR, FATAL
  • Alerting: Benachrichtigungen und Eskalation
  • Cloud Monitoring: AWS CloudWatch, Azure Monitor, GCP Operations
  • SIEM: Security Information and Event Management
  • Best Practices: Empfehlungen für effektives Monitoring

1. Grundlagen – Monitoring & Logging

Definition

Monitoring ist die kontinuierliche Überwachung von Systemen, Anwendungen und Infrastruktur, um Performance, Verfügbarkeit und Probleme zu erkennen.

Logging ist das Aufzeichnen von Ereignissen, Aktionen und Zuständen in einem System. Logs helfen bei der Fehlersuche, Analyse und Compliance.

Warum ist Monitoring wichtig?

Proaktive Problemerkennung

Probleme erkennen, bevor Nutzer sie bemerken. Frühwarnsystem für Ausfälle und Performance-Probleme.

Performance-Optimierung

Engpässe identifizieren, Ressourcen optimieren und SLAs einhalten. Datenbasierte Entscheidungen treffen.

Sicherheit

Angriffe erkennen, verdächtige Aktivitäten identifizieren und Compliance-Anforderungen erfüllen.

Kapazitätsplanung

Trends analysieren, Wachstum vorhersagen und Ressourcenbedarf planen. Kosten optimieren.

2. Three Pillars of Observability

Observability (Beobachtbarkeit) basiert auf drei Säulen: Metriken, Logs und Traces. Zusammen ermöglichen sie ein umfassendes Verständnis des Systemzustands.

Metriken

Numerische Messwerte über Zeit

Metriken sind quantifizierbare Messwerte, die über die Zeit erfasst werden. Sie zeigen Trends und Muster.

  • CPU-Auslastung (%)
  • Speicher-Verbrauch (GB)
  • Request-Rate (req/s)
  • Response-Time (ms)
  • Error-Rate (%)
  • Netzwerk-Traffic (Mbps)

Logs

Diskrete Ereignis-Datensätze

Logs sind zeitgestempelte Textdatensätze, die Ereignisse, Aktionen und Zustände dokumentieren.

  • Application Logs
  • System Logs (syslog)
  • Access Logs (Web)
  • Error Logs
  • Audit Logs
  • Security Logs

Traces

Request-Pfade durch verteilte Systeme

Traces verfolgen den Weg einer Anfrage durch mehrere Services. Essenziell für Microservices-Architekturen.

  • Distributed Tracing
  • Service-Abhängigkeiten
  • Latenz pro Service
  • Fehler-Lokalisierung
  • Performance-Bottlenecks
  • End-to-End-Visibility

Observability vs. Monitoring

Monitoring überwacht bekannte Metriken und warnt bei Schwellenwert-Überschreitungen. Observability geht weiter: Es ermöglicht, unbekannte Probleme zu untersuchen und die internen Zustände eines Systems aus seinen externen Outputs zu verstehen.

3. Monitoring-Tools im Überblick

Es gibt zahlreiche Monitoring-Tools, von Open-Source-Lösungen bis zu kommerziellen Plattformen. Hier die wichtigsten:

Prometheus

Open Source · Time-Series Database

Cloud-native Monitoring-System mit Pull-basiertem Ansatz. Standard für Kubernetes-Umgebungen.

  • Pull-basiertes Scraping
  • PromQL Query Language
  • Time-Series Database
  • Alertmanager Integration
  • Service Discovery
Kubernetes CNCF Open Source

Grafana

Open Source · Visualization Platform

Führende Visualisierungsplattform für Metriken, Logs und Traces. Unterstützt zahlreiche Datenquellen.

  • Dashboards & Visualisierungen
  • Multi-Data-Source Support
  • Alerting & Annotations
  • Grafana Loki (Logs)
  • Grafana Tempo (Traces)
Dashboards Visualisierung Open Source

ELK Stack

Open Source · Log Management

Elasticsearch, Logstash, Kibana – der Standard für Log-Analyse und Suche. Jetzt auch Elastic Stack genannt.

  • Elasticsearch (Suche & Speicher)
  • Logstash (Parsing & Transformation)
  • Kibana (Visualisierung)
  • Beats (Data Shippers)
  • Full-Text Search
Logging Search Open Source

Splunk

Commercial · SIEM & Observability

Enterprise-Plattform für Machine Data Analysis, SIEM und Observability. Marktführer im Enterprise-Bereich.

  • SPL Query Language
  • SIEM & Security Analytics
  • IT Service Intelligence
  • Machine Learning Toolkit
  • Enterprise-Grade Support
SIEM Enterprise Commercial

Zabbix

Open Source · Enterprise Monitoring

Enterprise-Monitoring-Lösung für Infrastruktur, Netzwerke und Cloud. Agent-basiert und agentenlos.

  • Agent & Agentless Monitoring
  • Network Discovery
  • Auto-Registration
  • Distributed Monitoring
  • Web-Interface
Infrastructure Network Open Source

Nagios

Open Source · Legacy Monitoring

Klassisches Monitoring-System, seit 1999 im Einsatz. Basis für viele moderne Monitoring-Tools.

  • Plugin-Architektur
  • Host & Service Checks
  • Notification System
  • Nagios XI (Commercial)
  • Große Community
Legacy Plugins Open Source

Datadog

Commercial · Cloud Monitoring

Cloud-basierte Monitoring- und Analytics-Plattform für moderne Infrastrukturen. SaaS-Lösung.

  • Infrastructure Monitoring
  • APM (Application Performance)
  • Log Management
  • Synthetic Monitoring
  • 500+ Integrationen
SaaS APM Commercial

Grafana Loki

Open Source · Log Aggregation

Log-Aggregation-System von Grafana Labs. Inspiriert von Prometheus, aber für Logs optimiert.

  • Label-basierte Indizierung
  • LogQL Query Language
  • Kostengünstig (kein Full-Text)
  • Native Grafana Integration
  • Promtail & Fluent Bit
Logs Grafana Open Source

4. Log-Levels – Schweregrade

Logs werden nach Schweregrad kategorisiert. Dies hilft bei der Filterung und Priorisierung von Ereignissen.

TRACE

Feinste Details, z.B. Variablenwerte. Nur für Entwicklung.

DEBUG

Debug-Informationen für Entwickler. Nicht in Produktion.

INFO

Normale Betriebsereignisse. Start, Stop, erfolgreiche Requests.

WARN

Potentielle Probleme. Deprecated APIs, langsame Queries.

ERROR

Fehler, die behoben werden müssen. Failed Requests, Exceptions.

FATAL

Kritische Fehler. System kann nicht weiterlaufen.

Beispiel: Log-Ausgabe

2026-07-04 10:23:45.123 [INFO] [api-gateway] Request received: GET /api/users/123 2026-07-04 10:23:45.145 [DEBUG] [user-service] Querying database for user ID: 123 2026-07-04 10:23:45.234 [INFO] [user-service] User found: max.mustermann@example.com 2026-07-04 10:23:45.312 [WARN] [api-gateway] Slow response time: 189ms (threshold: 100ms) 2026-07-04 10:23:46.456 [ERROR] [payment-service] Payment failed: Invalid credit card number 2026-07-04 10:23:47.789 [FATAL] [database] Connection pool exhausted, cannot serve requests

Best Practice: Log-Level in Produktion

  • Produktion: INFO oder WARN (selten DEBUG, nie TRACE)
  • Staging: DEBUG für Fehlersuche
  • Entwicklung: DEBUG oder TRACE für vollständige Details
  • Strukturierte Logs: JSON-Format für bessere Parsebarkeit

5. Alerting – Benachrichtigungen

Alerting ist ein kritischer Bestandteil des Monitorings. Wenn Schwellenwerte überschritten werden, müssen die richtigen Personen informiert werden.

Alert-Strategie

Eine gute Alert-Strategie verhindert Alert Fatigue (zu viele Alerts) und stellt sicher, dass kritische Probleme sofort eskaliert werden.

E-Mail

Standard-Benachrichtigung für nicht-kritische Alerts. Gut für Dokumentation und Nachverfolgung.

SMS

Für kritische Alerts außerhalb der Geschäftszeiten. Sofortige Aufmerksamkeit erforderlich.

Telefonanruf

Für höchste Eskalationsstufe. Bei schweren Ausfällen und Sicherheitsvorfällen.

Slack / Teams

Integration in Chat-Tools für Team-Alerts. Gut für Collaboration und schnelle Reaktionen.

Push-Notifications

Mobile Apps wie PagerDuty, Opsgenie. Für On-Call-Teams und mobile Benachrichtigungen.

Webhooks

Integration in eigene Systeme. Für automatisierte Workflows und Ticket-Erstellung.

Alert-Best-Practices

  • Severity-Levels: Critical, Warning, Info – unterschiedliche Eskalationswege
  • On-Call-Rotation: Klare Verantwortlichkeiten für 24/7-Betrieb
  • Runbooks: Dokumentierte Procedures für häufige Alerts
  • Alert Deduplication: Gleiche Alerts zusammenfassen
  • Escalation Policies: Automatische Eskalation nach Zeit
  • Alert Fatigue vermeiden: Nur actionierbare Alerts senden

6. Cloud Monitoring – Native Tools

Die großen Cloud-Anbieter bieten eigene Monitoring-Lösungen, die tief in ihre Plattformen integriert sind.

AWS CloudWatch

  • Metriken für alle AWS-Services
  • CloudWatch Logs (Log Aggregation)
  • CloudWatch Alarms
  • CloudWatch Dashboards
  • X-Ray (Distributed Tracing)
  • Synthetics (Canaries)
  • EventBridge (Event Routing)

Azure Monitor

  • Metrics & Logs
  • Log Analytics Workspace
  • Application Insights (APM)
  • Azure Monitor Alerts
  • Workbooks (Dashboards)
  • Network Watcher
  • Integration mit Microsoft 365

Google Cloud Operations

  • Cloud Monitoring (Metriken)
  • Cloud Logging (Logs)
  • Cloud Trace (Distributed Tracing)
  • Error Reporting
  • Cloud Profiler
  • Alerting Policies
  • Dashboards & SLOs

Cloud Monitoring Vorteile

  • Native Integration: Keine zusätzlichen Agenten nötig
  • Pay-per-Use: Nur für genutzte Ressourcen zahlen
  • Skalierbar: Automatisch mit der Infrastruktur
  • Security: IAM-Integration für Zugriffskontrolle
  • Compliance: Audit-Logs und Data Retention

7. SIEM – Security Information and Event Management

SIEM-Systeme kombinieren Log-Management mit Security Analytics. Sie sammeln, korrelieren und analysieren Sicherheitsereignisse aus der gesamten Infrastruktur.

SIEM-Funktionen

Log Aggregation

Zentrale Sammlung von Logs aus allen Quellen: Firewalls, IDS/IPS, Server, Anwendungen, Endpoints.

Korrelation

Zusammenhang zwischen verschiedenen Ereignissen erkennen. Z.B. mehrere fehlgeschlagene Logins + erfolgreicher Login = möglicher Brute-Force.

Alerting

Automatische Benachrichtigung bei verdächtigen Aktivitäten. Integration mit SOAR-Systemen.

Dashboards

Visualisierung von Sicherheitsmetriken, Bedrohungen und Compliance-Status in Echtzeit.

Compliance

Unterstützung für DSGVO, ISO 27001, PCI-DSS, HIPAA. Audit-Reports und Retention.

Threat Intelligence

Integration von Threat-Feeds. Erkennung bekannter IOCs (Indicators of Compromise).

Bekannte SIEM-Lösungen

Splunk

Marktführer im Enterprise-Bereich. Leistungsstark, aber teuer. SPL Query Language.

Elastic SIEM

Open-Source-basiert (ELK Stack). Flexible, skalierbare Lösung mit Machine Learning.

Microsoft Sentinel

Cloud-native SIEM von Microsoft. Integration mit Azure, Microsoft 365 und Defender.

AWS Security Hub

AWS-native Security-Posture-Management. Integration mit GuardDuty, Inspector, Macie.

8. Best Practices für Monitoring & Logging

Effektives Monitoring erfordert eine durchdachte Strategie. Hier die wichtigsten Empfehlungen:

Definiere SLIs und SLOs

Service Level Indicators (SLIs) messen die Performance, Service Level Objectives (SLOs) definieren die Ziele. Z.B. "99,9% Verfügbarkeit".

Four Golden Signals

Überwache immer: Latency, Traffic, Errors und Saturation. Das sind die wichtigsten Metriken.

Strukturierte Logs

Nutze JSON-Format für Logs mit konsistenten Feldern: timestamp, level, service, message, trace_id. Erleichtert die Analyse.

Alert Fatigue vermeiden

Nur actionierbare Alerts senden. Regelmäßig Alerts überprüfen und nicht-relevante entfernen oder anpassen.

Retention Policies

Definiere Aufbewahrungsfristen: Metriken (13 Monate), Logs (30-90 Tage), Security Logs (1 Jahr+). DSGVO beachten!

Distributed Tracing

In Microservices-Architekturen: Traces über Service-Grenzen hinweg. Tools: Jaeger, Zipkin, OpenTelemetry.

Security Monitoring

Logs auf sensible Daten prüfen. Verschlüsselung für Logs in Transit und at Rest. Zugriffskontrolle implementieren.

Runbooks & Dokumentation

Für jeden kritischen Alert ein Runbook mit Steps zur Behebung. Regelmäßig aktualisieren und testen.

Beispiel: Metriken-Dashboard

Service Metrics (Beispiel)
http_requests_total 1,234,567
http_request_duration_seconds (p95) 0.234s
http_requests_errors_total 123
cpu_usage_percent 45.2%
memory_usage_bytes 2.4 GB
active_connections 342
database_query_duration_seconds (p99) 0.089s

9. Tool-Vergleichstabelle

Welches Tool passt zu welchem Einsatzzweck? Hier eine Übersicht:

Tool Typ Lizenz Stärken Einsatzgebiet
Prometheus Monitoring Open Source Cloud-native, Kubernetes, PromQL Container, Microservices
Grafana Visualization Open Source Dashboards, Multi-Source Alle Umgebungen
ELK Stack Logging Open Source Full-Text Search, Flexibel Log-Analyse, Suche
Splunk SIEM / Logging Commercial Enterprise, SPL, ML Enterprise Security
Zabbix Infrastructure Open Source Netzwerk, Server, Agent On-Premise Infrastruktur
Nagios Monitoring Open Source Plugin-Architektur, Legacy Traditionelle Systeme
Datadog APM / Monitoring Commercial SaaS, 500+ Integrationen Cloud-Umgebungen
Loki Logging Open Source Kostengünstig, Grafana-native Cloud-native Logs
CloudWatch Cloud Monitoring Cloud Service AWS-native, Pay-per-Use AWS-Umgebungen
Azure Monitor Cloud Monitoring Cloud Service Azure-native, Integration Azure-Umgebungen

FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Monitoring & Logging

Was ist der Unterschied zwischen Monitoring und Observability?

Monitoring ist das Sammeln und Anzeigen von vordefinierten Metriken und Logs. Sie wissen, wonach Sie suchen (z.B. CPU-Auslastung, Error-Rate).

Observability geht weiter: Es ist die Fähigkeit, unbekannte Probleme zu entdecken und zu debuggen, indem Sie Metrics, Logs und Traces korrelieren. Observability ermöglicht es Ihnen, Fragen zu stellen, die Sie vorher nicht kannten.

Beispiel: Monitoring sagt Ihnen "Error-Rate ist hoch". Observability ermöglicht es Ihnen zu fragen "Welcher User hatte welchen Fehler in welchem Service und welche Dependency war langsam?"

Prometheus vs. Datadog – was soll ich wählen?

Prometheus (Open Source):

  • Kostenlos, aber Sie müssen Infrastruktur selbst betreiben
  • Sehr flexibel, PromQL ist mächtig
  • Ideal für Kubernetes und Cloud-native
  • Erfordert DevOps-Know-how

Datadog (SaaS):

  • Managed Service, kein Betrieb nötig
  • Teuer bei Scale (pro Host/Metric)
  • Einfach zu starten, viele Integrationen
  • Vendor Lock-in

Empfehlung: Starten Sie mit Prometheus + Grafana. Wenn Sie Budget haben und Managed Services bevorzugen, ist Datadog eine gute Wahl.

Wie viel kostet ein Monitoring-Stack?

Die Kosten hängen stark von der Größe und dem gewählten Stack ab:

  • Open Source (Prometheus + Grafana + Loki): Nur Infrastruktur-Kosten (Server, Storage). Für kleine bis mittlere Umgebungen: 50-200 €/Monat
  • Datadog: 15 $/Host/Monat + 0.10 $/Million Metrics + Log-Kosten. Bei 100 Hosts: ~1.500 $/Monat
  • ELK Stack: Infrastruktur + Elasticsearch-Lizenzen (wenn nicht Open Source). Kann teuer werden bei großen Log-Volumes

Tipp: Starten Sie mit Open Source und migrieren Sie zu SaaS, wenn die Operational Overhead zu hoch wird.

Was sind die wichtigsten Metriken für eine Web-Anwendung?

Die vier Golden Signals sind essenziell:

  • Latency: Request Duration (p50, p95, p99). Unterscheide Success vs. Error Latency
  • Traffic: Requests per Second (RPS). Zeigt Auslastung
  • Errors: Error Rate (5xx Responses / Total Requests). Sollte < 0.1% sein
  • Saturation: CPU, Memory, Disk, Network. Zeigt, wie nah das System am Limit ist

Zusätzlich: Business Metrics wie Conversion Rate, Active Users, Revenue (je nach Anwendung)

Wie lange sollte ich Logs aufbewahren?

Die Retention hängt von Compliance-Anforderungen und Use Cases ab:

  • Hot Storage (0-7 Tage): Für aktives Debugging. Schnell durchsuchbar, teuer
  • Warm Storage (7-30 Tage): Für Troubleshooting. Langsamer, günstiger
  • Cold Storage (30-90 Tage): Für Compliance. Archiviert, sehr günstig
  • Archive (90+ Tage): Für Audit. Object Storage (S3, GCS)

Compliance: DSGVO, PCI-DSS, HIPAA können längere Retention erfordern. Prüfen Sie Ihre Anforderungen!

Tipp: Loki mit S3-Backend ist extrem kosteneffizient für lange Retention.

Was ist der Unterschied zwischen SLO, SLI und SLA?

SLI (Service Level Indicator): Eine Metrik, die das Service-Level misst.

  • Beispiel: Success Rate = (Successful Requests / Total Requests) × 100

SLO (Service Level Objective): Ein Zielwert für den SLI.

  • Beispiel: "99.9% der Requests sollen erfolgreich sein"

SLA (Service Level Agreement): Ein vertragliches Agreement mit Konsequenzen bei Verletzung.

  • Beispiel: "Wenn Availability < 99.9%, erhält der Kunde 10% Rabatt"

Praxis: SLOs sind interne Ziele, SLAs sind externe Verträge. SLOs sollten ambitionierter sein als SLAs.

Wie verhindere ich Alert Fatigue?

Alert Fatigue entsteht, wenn zu viele Alerts ausgelöst werden, von denen die meisten nicht actionable sind. Lösungsstrategien:

  • Alert on Symptoms: Alert bei hoher Error-Rate, nicht bei hoher CPU
  • Actionable Alerts: Jeder Alert sollte eine klare Aktion erfordern
  • Severity Levels: Critical (sofort handeln), Warning (prüfen), Info (ignorieren)
  • Alert Grouping: Verwandte Alerts zusammenfassen (Alertmanager)
  • Inhibition: Wenn Parent-Service down, child Alerts unterdrücken
  • Silencing: Während Wartungsfenstern Alerts stummschalten

Regel: Wenn ein Alert keine Aktion auslöst, löschen Sie ihn oder ändern Sie ihn in ein Dashboard.

Was ist OpenTelemetry und warum ist es wichtig?

OpenTelemetry ist ein Open-Source-Projekt der CNCF, das einen vendor-neutralen Standard für Metrics, Logs und Traces definiert.

  • Unified API: Eine API für alle Observability-Signale
  • Vendor Neutral: Funktioniert mit Jaeger, Zipkin, Prometheus, Datadog, etc.
  • Multi-Language: SDKs für Java, Go, Python, Node.js, .NET, etc.
  • Automatic Instrumentation: Viele Frameworks werden automatisch instrumentiert

Warum wichtig? Verhindert Vendor Lock-in. Sie können von Jaeger zu Zipkin wechseln, ohne Code zu ändern.

Zusammenfassung

Die wichtigsten Punkte

  • Monitoring: Kontinuierliche Überwachung von Systemen und Anwendungen
  • Logging: Aufzeichnung von Ereignissen und Zuständen
  • Three Pillars: Metriken, Logs und Traces für vollständige Observability
  • Tools: Prometheus, Grafana, ELK Stack, Splunk, Zabbix, Datadog
  • Log-Levels: TRACE, DEBUG, INFO, WARN, ERROR, FATAL
  • Alerting: E-Mail, SMS, Slack, PagerDuty – Eskalationsstrategien
  • Cloud Monitoring: AWS CloudWatch, Azure Monitor, GCP Operations
  • SIEM: Splunk, Elastic SIEM, Microsoft Sentinel für Security
  • Best Practices: SLIs/SLOs, Four Golden Signals, strukturierte Logs
  • Alert Fatigue: Nur actionierbare Alerts, regelmäßige Überprüfung

Weiterführende Themen

Cloud Computing

IaaS, PaaS, SaaS – die Grundlagen des Cloud Computings.

Zu Cloud Computing
Container Orchestration

Docker, Kubernetes und Container-Management im Detail.

Zu Container Orchestration
Cloud Security

Sicherheit in der Cloud – IAM, Verschlüsselung, Compliance.

Zu Cloud Security
Infrastructure as Code

Terraform, CloudFormation, Ansible – Infrastruktur automatisieren.

Zu IaC