Observability-Stack 2026 — Monitoring, Logging und Tracing für den Mittelstand

Wer 2026 produktiv Software betreibt, hat ein Problem, das vor zehn Jahren noch keines war: die Systeme sind verteilt, ephemer und vielsprachig. Eine einzige Kunden-Anfrage durchläuft heute typischerweise fünf bis fünfzehn Services, eine Handvoll Datenbanken, mehrere Caches, eine Message-Queue und mindestens einen externen API-Aufruf. Wenn diese Anfrage langsam oder fehlerhaft beantwortet wird, hilft der Blick in eine einzelne Log-Datei nicht mehr weiter. Genau hier setzt Observability an — die Disziplin, ein System so zu instrumentieren, dass seine inneren Zustände von außen verständlich werden. Für den deutschen Mittelstand ist das Thema in den letzten zwei Jahren von „nice to have“ zu „unverzichtbar“ gewachsen: Cloud-Migrationen, Kubernetes-Einführungen und der Druck auf Verfügbarkeit machen einen belastbaren Observability-Stack zur Grundlage jedes seriösen IT-Betriebs. Dieser Artikel zeigt, welche Bausteine ein moderner Stack 2026 enthält, welche Open-Source- und kommerziellen Optionen sich bewährt haben, mit welchen Kosten Sie realistisch rechnen und wo die typischen Fallen liegen. Für die Einordnung in die Gesamtstrategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Monitoring vs. Observability — der Unterschied zählt

Die beiden Begriffe werden im Markt häufig synonym verwendet, das ist falsch. Monitoring beschreibt das Beobachten vorher definierter Kennzahlen mit vorher definierten Schwellwerten — CPU-Last über 80 Prozent, Festplatte unter 10 Prozent frei, Antwortzeit über zwei Sekunden. Das funktioniert hervorragend für bekannte Probleme, scheitert aber an dem, was im Betrieb verteilter Systeme die Mehrheit ist: unbekannte Probleme, die niemand vorher antizipiert hat. Observability dreht die Logik um. Statt zu fragen „ist alles in den definierten Schwellwerten?“, fragt sie „kann ich diesem System jede beliebige Frage stellen und eine Antwort bekommen?“. Damit das funktioniert, braucht es nicht nur mehr Daten, sondern strukturierte, miteinander verknüpfte Daten.

Praktisch heißt das: ein Alert in einem Observability-System ist nicht das Ende, sondern der Anfang. Wer eine Anomalie sieht, springt vom Metrics-Dashboard in den passenden Trace, von dort in die Logs der beteiligten Services, von dort zur Profiling-Information eines einzelnen Prozesses — alles über gemeinsame Identifikatoren wie Trace-ID, Service-Name und Deployment-Version verknüpft. Ein reines Monitoring-System zeigt, dass etwas brennt. Ein Observability-System zeigt, was, wo, warum und seit wann brennt. Diese Differenz entscheidet bei einem Ausfall über Minuten oder Stunden Wiederherstellungszeit.

Für mittelständische Unternehmen ist der pragmatische Mittelweg sinnvoll: nicht jedes System braucht volle Observability vom ersten Tag an. Eine statische Marketing-Website kommt mit grundlegendem Monitoring aus. Sobald Microservices, Kubernetes oder eine kundenkritische Plattform im Spiel sind, lohnt sich die Investition in einen vollständigen Observability-Stack — typischerweise innerhalb der ersten sechs bis zwölf Monate nach Cloud-Migration oder Plattform-Modernisierung.

Die drei Säulen plus Events

Klassisch wird Observability auf drei Säulen aufgebaut, in den letzten Jahren ist eine vierte hinzugekommen, die in der Praxis enorm hilft.

Säule	Antwortet auf	Typische Daten	Speicher-Verhalten
Metrics	Wie viel? Wie schnell? Wie oft?	Numerische Zeitreihen, niedrige Kardinalität, hohe Frequenz	Klein pro Datenpunkt, viele Datenpunkte, lange Retention möglich
Logs	Was ist passiert?	Strukturierte oder unstrukturierte Text-Ereignisse	Groß pro Eintrag, kürzere Retention, hoher I/O-Bedarf
Traces	Wo hat es lange gedauert oder gefehlt?	Verteilte Request-Spuren mit Span-Hierarchie	Sehr groß bei voller Aufzeichnung, daher Sampling üblich
Events	Was hat sich geändert?	Deployments, Feature-Flags, Config-Änderungen, Releases	Klein, hohe Geschäfts-Relevanz für Correlation

Die vierte Säule — Events oder Change-Events — ist in der Praxis Gold wert. Über 70 Prozent aller produktiven Vorfälle stehen in direktem Zusammenhang mit einer kurz vorher erfolgten Änderung: Deployment, Feature-Flag-Schaltung, Migration, Library-Update. Wer Events strukturiert erfasst und in seine Dashboards überlagert, sieht Ursache und Wirkung sofort statt erst nach langer Suche. Tools wie Grafana, Datadog und Honeycomb haben dafür eigene Overlay-Funktionen, die viele Organisationen ungenutzt liegen lassen.

Wichtig ist die Verknüpfung der Säulen durch gemeinsame Identifikatoren. In der Praxis bedeutet das: jeder Log-Eintrag enthält die aktuelle Trace-ID, jeder Trace verlinkt auf die zugehörigen Logs, jede Metrik kennt den Service-Namen und das Deployment-Label. Diese Verknüpfung ist nicht selbstverständlich — sie entsteht erst durch konsequente Instrumentierung mit einem einheitlichen Standard. Genau hier kommt OpenTelemetry ins Spiel.

OpenTelemetry als Standard 2026

OpenTelemetry — kurz OTel — ist seit 2023 der unbestrittene De-facto-Standard für Instrumentierung. Es ist ein CNCF-Projekt, vereint die früheren OpenTracing- und OpenCensus-Initiativen, und bietet SDKs für alle relevanten Programmiersprachen sowie einen leistungsfähigen Collector, der Daten transformiert und an beliebige Backends weiterleitet. Der entscheidende Vorteil: Anwendungen werden einmal mit OpenTelemetry-SDKs instrumentiert und können danach an jedes beliebige Backend angeschlossen werden — Prometheus, Grafana, Datadog, Honeycomb, New Relic. Ein Wechsel des Backends ist möglich, ohne den Anwendungscode zu ändern.

Für den Mittelstand bedeutet das konkret: die Auswahl eines Backends ist keine 10-Jahres-Festlegung mehr. Wer heute mit Grafana Cloud oder einem self-hosted Stack startet und in drei Jahren auf Datadog wechselt, braucht nur die Collector-Konfiguration zu ändern. Das senkt das Risiko der Tool-Auswahl dramatisch und ist einer der wichtigsten Gründe, warum OpenTelemetry sich so schnell durchgesetzt hat.

In der Praxis lohnt sich ein klarer Roll-out-Pfad: Phase 1 instrumentiert neue Services nativ mit OpenTelemetry-SDKs. Phase 2 zieht bestehende Services über Auto-Instrumentation nach — für Java, Python, Node.js und Go funktioniert das mit minimalem Code-Eingriff. Phase 3 ersetzt Legacy-Agenten wie StatsD, Fluentd oder direkte CloudWatch-Aufrufe durch den OpenTelemetry-Collector. Erst danach ist der Stack vollständig vendor-neutral und das Backend austauschbar.

Metrics-Stack — Prometheus, VictoriaMetrics, Mimir, Thanos

Im Metrics-Bereich ist Prometheus seit Jahren die Referenz-Implementierung. Es funktioniert hervorragend bis zu einer mittleren Größe — typischerweise einige Millionen aktive Zeitreihen — und scheitert dann an Skalierung, Hochverfügbarkeit und Langzeit-Retention. Genau für diese Schwächen sind in den letzten Jahren mehrere Erweiterungen entstanden, die im Mittelstand zunehmend Standard sind.

• Prometheus — der Standard für Pull-basiertes Metrics-Scraping, ideal für Kubernetes-Umgebungen, einfache Konfiguration, aktive Community
• VictoriaMetrics — drop-in-kompatible Alternative mit deutlich besserer Speicher-Effizienz und horizontaler Skalierung, im Mittelstand stark wachsend
• Grafana Mimir — horizontaler, multi-tenant Long-Term-Storage hinter Prometheus, geeignet für größere Umgebungen mit mehreren Teams
• Thanos — die ältere, ebenfalls bewährte Lösung für globale Sicht und Langzeit-Retention über mehrere Prometheus-Instanzen hinweg

Pragmatische Empfehlung für mittelständische Umgebungen: starten Sie mit nativem Prometheus, beobachten Sie die Speicher- und CPU-Last über die ersten sechs Monate, und wechseln Sie zu VictoriaMetrics oder Mimir, sobald eine einzelne Prometheus-Instanz nicht mehr ausreicht. Ein vorzeitiger Einstieg in eine verteilte Architektur ist häufig Over-Engineering — die Komplexität kostet mehr Betriebs-Aufwand als sie an Skalierung gewinnt.

Logs — Loki, Elastic/OpenSearch, ClickHouse

Im Logs-Bereich hat sich der Markt in den letzten drei Jahren stark bewegt. Die klassische Wahl Elasticsearch ist betriebs-aufwendig, ressourcen-hungrig und im Vergleich zu modernen Alternativen teuer. OpenSearch ist die offene Abspaltung nach dem AWS-Konflikt mit Elastic und für viele mittelständische Anwendungen die natürliche Wahl, wenn der Funktions-Umfang von Elastic gebraucht wird. Beide eignen sich gut für Volltext-Suche, komplexe Queries und Compliance-Use-Cases.

Eine deutlich leichtgewichtigere Alternative ist Grafana Loki. Loki indiziert nur Labels, nicht den Log-Inhalt, und speichert die eigentlichen Log-Daten in Objekt-Storage wie S3 oder MinIO. Das macht Loki um den Faktor 10 bis 30 günstiger im Betrieb als Elasticsearch — bei einer wesentlich einfacheren Architektur. Der Preis ist eingeschränkte Volltext-Such-Performance, die für die meisten Observability-Use-Cases aber irrelevant ist, weil Logs in Kombination mit Traces und Metrics abgefragt werden.

Für sehr große Log-Volumen ist ClickHouse seit etwa 2024 die schnell wachsende Alternative. Plattformen wie SigNoz, Uptrace und Quickwit nutzen ClickHouse als Storage-Backend und liefern beeindruckende Query-Performance bei niedrigen Speicher-Kosten. Für mittelständische Unternehmen lohnt sich ClickHouse erst, wenn Loki an Grenzen kommt — typischerweise im einstelligen Terabyte-Bereich pro Tag.

Traces — Tempo, Jaeger, Zipkin

Distributed Tracing ist die dritte Säule und in vielen Mittelstands-Setups die am wenigsten ausgereifte. Drei Open-Source-Optionen dominieren den Markt. Jaeger ist die ältere CNCF-Lösung, sehr stabil, gut dokumentiert, gut integriert mit Kubernetes. Zipkin ist die noch ältere Twitter-Lösung, im Funktions-Umfang etwas eingeschränkter, in Java-Umgebungen weit verbreitet. Grafana Tempo ist die neueste der drei und folgt einer ähnlichen Logik wie Loki: Traces werden in Objekt-Storage gespeichert, der Index ist minimal, die Korrelation mit Metrics und Logs erfolgt über Trace-IDs in Grafana-Dashboards.

In neuen Setups ist Tempo heute die meistgewählte Variante, weil sie sich nahtlos in einen Grafana-zentrierten Stack einfügt und im Betrieb deutlich günstiger ist als Jaeger. Wichtig ist in jedem Fall ein durchdachtes Sampling-Konzept — vollständige Aufzeichnung aller Traces ist bei produktivem Verkehr nicht bezahlbar. Tail-based Sampling, bei dem nur fehlerhafte oder langsame Traces vollständig gespeichert werden, ist die übliche Lösung und in OpenTelemetry-Collector-Konfigurationen leicht aktivierbar.

Dashboards — Grafana und Kibana

Im Dashboard-Bereich ist Grafana seit Jahren der unbestrittene Standard und 2026 stärker denn je. Es unterstützt nativ alle relevanten Daten-Quellen, hat ausgereifte Alerting-Funktionen, ein riesiges Plugin-Ökosystem und eine aktive Community. Wer einen offenen Observability-Stack betreibt, kommt an Grafana praktisch nicht vorbei.

Kibana bleibt relevant in Umgebungen, die stark in den Elastic-Stack investiert haben — dort liefert es tiefe Volltext-Such-Funktionen und Sicherheits-Use-Cases wie SIEM-Auswertungen, die in Grafana nur eingeschränkt verfügbar sind. Für reine Observability ist Grafana die robustere Wahl, für kombinierte Observability- und Security-Analytics-Use-Cases lohnt ein Hybrid mit Kibana.

Kommerzielle Plattformen — Datadog, New Relic, Honeycomb

Neben dem Open-Source-Ökosystem gibt es ein etabliertes Feld kommerzieller Plattformen, die alle drei Säulen aus einer Hand liefern und durch hohe Out-of-the-Box-Qualität punkten. Datadog ist mit Abstand die breiteste Plattform, deckt Metrics, Logs, Traces, RUM, Synthetic Monitoring und Security in einem einzigen UI ab und ist im Mittelstand stark vertreten. New Relic spielt im selben Segment, ist im Preis-Modell seit 2020 transparenter und für viele Anwendungs-Profile günstiger. Honeycomb ist die Spezial-Plattform für event-basierte, hoch-kardinale Observability und in Engineering-getriebenen Organisationen sehr beliebt — etwas Nischen-Produkt, aber sehr stark in seinem Bereich.

Weitere relevante Anbieter sind Dynatrace mit starkem APM- und Infrastructure-Fokus, Splunk mit Schwerpunkt Logs und SIEM, sowie Elastic Cloud als gemanagte Variante des Elastic-Stacks. Die Auswahl hängt stark von der bestehenden Tool-Landschaft, dem Sprach-Mix der Anwendungen und der Größe der Plattform-Organisation ab.

Self-hosted vs. SaaS — die Kostenrechnung

Die Frage „selbst betreiben oder einkaufen“ ist nicht die Frage „kostenfrei oder teuer“. Self-hosted hat keine Lizenz-Kosten, dafür hohe Personal- und Infrastruktur-Kosten. SaaS hat klare Lizenz-Kosten, dafür praktisch keine Betriebs-Belastung. Die folgende Tabelle zeigt typische Jahres-Kosten für mittelständische Umgebungen.

Variante	Lizenz-Kosten/Jahr	Infrastruktur	Personalaufwand
Self-hosted Open-Source (20–50 Hosts)	0 €	15.000–30.000 €	20–40 % einer Stelle
Self-hosted Open-Source (50–200 Hosts)	0 €	40.000–90.000 €	50–100 % einer Stelle
Grafana Cloud (managed)	15.000–50.000 €	—	10–20 % einer Stelle
Datadog/New Relic (50–200 Hosts)	40.000–180.000 €	—	10–20 % einer Stelle

Wichtiger als die Zahlen ist die Logik dahinter: SaaS-Plattformen rechnen oft pro Host und pro Event-Volumen. Wer unvorsichtig mit Log-Volumen oder Metrik-Kardinalität umgeht, kann die Rechnung schnell verdoppeln. Self-hosted bestraft denselben Fehler mit Infrastruktur-Kosten und Performance-Problemen. Disziplin in der Instrumentierung ist in beiden Varianten die zentrale Stellschraube und eng verbunden mit dem Thema Cloud-Kosten und FinOps.

Alerting, SLIs und SLOs

Ein Observability-Stack ohne durchdachtes Alerting ist eine teure Daten-Sammlung. Die in den letzten Jahren etablierte Best Practice basiert auf SLIs und SLOs: ein Service Level Indicator ist eine konkrete Messgröße — Antwortzeit, Verfügbarkeit, Fehler-Quote — und ein Service Level Objective ist das Zielwert dafür, zum Beispiel „99,5 Prozent der Antworten unter 800 Millisekunden über 30 Tage“. Aus dem SLO ergibt sich automatisch ein Fehler-Budget, das wiederum die Grundlage für Alerting wird: Alarme feuern, wenn das Fehler-Budget zu schnell verbraucht wird, nicht bei jedem einzelnen langsamen Request.

• SLI definierenKonkrete Messgröße aus Nutzer-Sicht, etwa Anteil erfolgreicher Antworten unter einem Latenz-Schwellwert. Vermeiden Sie reine Infrastruktur-Metriken wie CPU-Last als primären Indikator.
• SLO festlegenRealistischer Zielwert mit Zeitraum, etwa 99,5 Prozent über 30 Tage. Nicht jeder Service muss 99,99 Prozent erreichen — höhere Ziele kosten exponentiell mehr.
• Fehler-Budget trackenVerbrauchs-Geschwindigkeit des Fehler-Budgets ist die Alarmgröße, nicht der einzelne Ausreißer. Burn-Rate-Alerts sind in Prometheus, Grafana und Datadog Standard.
• Eskalation klar regelnWer wird wann wie alarmiert? On-Call-Rotation, Eskalations-Stufen und stille Stunden gehören in eine schriftliche Policy, nicht in Slack-Kanäle.
• Alarm-Müll vermeidenJeder Alarm muss zu einer Aktion führen. Alarme, die nicht zu Handlung führen, werden ignoriert — auch die wichtigen. Regelmäßige Alarm-Reviews gehören in jedes Quartal.

Die SLO-Methodik kommt ursprünglich aus dem Google-SRE-Buch und ist heute weit über reine SRE-Organisationen verbreitet. Für den Mittelstand ist sie ab dem Moment relevant, an dem mehrere Teams an produktiven Systemen arbeiten und Verfügbarkeits-Diskussionen sonst diffus bleiben. Detailliert dazu siehe unseren Cluster zu SRE im Mittelstand.

Die Cardinality-Falle

Der häufigste Stolperstein junger Observability-Programme ist die Kardinalitäts-Explosion. Prometheus, VictoriaMetrics und alle vergleichbaren Systeme speichern Metriken als Kombination aus Name und Label-Set. Jede einzigartige Kombination ist eine eigene Zeitreihe. Eine Metrik http_requests_total{service="api", endpoint="/users", status="200"} mit drei Labels und überschaubaren Werte-Mengen ergibt vielleicht ein paar hundert Zeitreihen. Wird ein Label wie user_id oder request_id hinzugefügt, das Millionen verschiedener Werte annehmen kann, explodieren die Zeitreihen und mit ihnen Speicher, Index und Query-Performance.

Praktische Faustregeln: Labels nur für Werte mit unter etwa 100 möglichen Ausprägungen verwenden. Werte wie User-ID, Session-ID, Trace-ID oder URL mit Parametern gehören in Logs oder Traces, nicht in Metriken. Vor jedem neuen Label sollten Sie die maximale Kardinalität abschätzen. Tools wie Grafana Mimir und VictoriaMetrics bieten eingebaute Kardinalitäts-Analyse, die zur Pflicht-Übung im Quartals-Review werden sollte.

Diese Disziplin klingt akademisch, ist aber in vielen mittelständischen Setups der Unterschied zwischen einem performanten Observability-Stack für 2.000 Euro im Monat und einem trägen System für 20.000 Euro im Monat. Cardinality ist die größte unsichtbare Kostentreiberin in Observability-Plattformen.

Reepa-Empfehlung für mittelständische Stacks

Aus unserer Beratungs-Praxis hat sich für mittelständische Unternehmen ohne dediziertes Plattform-Team folgender Stack als robust und wirtschaftlich erwiesen: OpenTelemetry-SDKs in allen produktiven Services, OpenTelemetry-Collector als zentraler Telemetrie-Hub, Grafana Cloud oder ein self-hosted Grafana-LGTM-Stack (Loki, Grafana, Tempo, Mimir) für die ersten zwei bis drei Jahre. Damit ist die Tool-Auswahl vendor-neutral, der Betriebs-Aufwand handhabbar und ein späterer Wechsel zu Datadog, New Relic oder einer self-hosted Variante jederzeit möglich.

Für sehr kleine Umgebungen unter etwa 20 Hosts ist Grafana Cloud Free Tier oft ausreichend und ein guter Einstieg ohne Investitions-Risiko. Für größere Umgebungen mit klarem Engineering-Team lohnt sich ein self-hosted LGTM-Stack auf Kubernetes — eng integriert mit den restlichen Cluster-Workloads, siehe unseren Cluster zu Kubernetes im Mittelstand. Für Hochlast-Plattformen oder Compliance-getriebene Branchen ist Datadog oder Dynatrace der pragmatische Standard.

Unabhängig vom konkreten Toolset gilt: der Stack lebt von der Instrumentierungs-Disziplin der Entwicklungs-Teams. Ein perfekter Stack mit schlecht instrumentierten Services liefert keine brauchbare Telemetrie. Investieren Sie früh in Schulungen, Code-Templates und einen klaren Observability-Standard im Unternehmen — die Tool-Auswahl ist sekundär.

Häufige Fragen