Von Log-Debugging zu echter Observability: Wie ayedo eine SaaS-Plattform mit APM auf Kubernetes stabilisiert hat

Viele SaaS-Unternehmen investieren früh in saubere Architektur: containerisierte Workloads, Kubernetes, Infrastructure as Code, GitOps. Technisch wirkt alles modern. Und doch fehlt häufig ein entscheidender Baustein: Transparenz über das tatsächliche Laufzeitverhalten der Anwendung.

In diesem Beitrag zeigen wir anhand eines anonymisierten Projekts, wie ayedo für einen SaaS-Anbieter mit mehreren Millionen aktiven Nutzern ein skalierbares Application Performance Monitoring (APM) auf Basis von VictoriaMetrics, VictoriaLogs, Grafana und OpenTelemetry aufgebaut hat – vollständig integriert in die bestehende Kubernetes-Infrastruktur.

Der Kunde bleibt anonym. Der Ansatz ist übertragbar – insbesondere für SaaS-Unternehmen, die wachsen und merken, dass „Logs anschauen" keine Observability-Strategie ist.

Ausgangslage: Cloud-native Architektur – aber kein Systemverständnis

Der Kunde betreibt eine SaaS-Plattform für digitale Prozessautomatisierung und Datenintegration mit monatlich über fünf Millionen aktiven Nutzern. Das Engineering-Team ist schlank: rund 10 Personen für Development und DevOps. Die Anwendung läuft vollständig containerisiert auf Kubernetes, Deployments erfolgen automatisiert über GitOps.

Architektonisch war vieles richtig umgesetzt: stateless Services nach 12-Factor-Prinzip, PostgreSQL als persistente Basis, Redis für Caching, S3 für Objektspeicher. Infrastruktur und Delivery waren sauber aufgesetzt.

Was fehlte, war die systematische Beobachtung des Systems.

Logs wurden ad hoc aus einzelnen Pods gezogen – oft erst dann, wenn ein Fehler bereits sichtbar war. Es gab keine zentrale Aggregation, keine strukturierte Korrelation zwischen Logs, Metriken und konkreten User-Requests. Jeder Incident begann mit derselben Frage: „Wo schauen wir zuerst?"

Mit steigender Komplexität der Plattform und zunehmender Nutzerzahl traten typische Wachstumsprobleme auf: Regressions nach Releases, N+1-Query-Probleme, sporadische Latenzspitzen. Technisch waren die Ursachen lösbar – operativ war die Analyse zu langsam.

Die Symptome: Reaktive Fehleranalyse statt proaktiver Steuerung

Ohne durchgängige Observability verschiebt sich der Fokus zwangsläufig auf reaktive Fehlerbehebung.

Fehleranalysen dauerten Stunden statt Minuten, weil Logs kontextlos waren. Ein einzelner Stacktrace verrät wenig, wenn nicht klar ist, welcher User-Request ihn ausgelöst hat, welche Services beteiligt waren und wie sich CPU-, Memory- oder Datenbankmetriken in diesem Moment verhalten haben.

Performance-Probleme wurden häufig erst bemerkt, wenn Endnutzer sie spürten. Für eine Plattform mit Millionen Nutzern bedeutet das unmittelbar: steigender User-Churn, Support-Tickets, Vertrauensverlust.

Parallel entstand im Engineering-Team eine zunehmende Unsicherheit. Wenn Änderungen deployed wurden, war unklar, welche Seiteneffekte sie im System auslösen. Ohne Metriken und Traces bleibt jede Optimierung ein Stück weit Blindflug.

Das Problem war also nicht die Architektur. Es war die fehlende Korrelation zwischen Code, Infrastruktur und realem Laufzeitverhalten.

ayedos Ansatz: Observability als Plattform-Standard – nicht als Add-on

Unser Ziel war es nicht, „ein Monitoring-Tool einzuführen", sondern eine ganzheitliche Observability-Schicht aufzubauen, die tief in die bestehende Kubernetes-Umgebung integriert ist und Metriken, Logs und Traces als zusammenhängendes System begreift.

Die Lösung basierte auf einem modularen, skalierbaren Stack:

VictoriaMetrics als Time-Series-Datenbank für hochperformante Metrik-Erfassung,
VictoriaLogs als zentrales Log-Backend,
Grafana für Visualisierung und Alerting,
Grafana Tempo für Distributed Tracing,
OpenTelemetry als standardisierte Instrumentierungs-Schicht.

Entscheidend war dabei, dass dieser Stack nicht neben der Anwendung existiert, sondern integraler Bestandteil des Betriebsmodells wird.

OpenTelemetry: Instrumentierung statt Log-Sammeln

Der erste Schritt war die Integration von OpenTelemetry (OTel) in die Anwendung. Anstatt sich ausschließlich auf Infrastrukturmetriken zu verlassen, wurden Metriken, Logs und Traces direkt aus den Services heraus erzeugt.

Jeder relevante Request erzeugt nun eine Trace-Kette über alle beteiligten Services hinweg. Datenbank-Calls, externe API-Requests, Cache-Zugriffe – alles wird als Teil einer Transaktion sichtbar.

Damit verschiebt sich die Perspektive von „Pod hat Fehler geworfen" zu „User-Request X hat in Service Y eine 1,8-Sekunden-Latenz verursacht, ausgelöst durch Z Datenbank-Queries". Das ist ein qualitativer Unterschied.

VictoriaMetrics & VictoriaLogs: Skalierbarkeit ohne Komplexitätsballast

Für die Speicherung der Metriken haben wir VictoriaMetrics eingesetzt – eine hochperformante, ressourceneffiziente Time-Series-Datenbank, die auch bei Millionen von Zeitreihen stabil bleibt.

Gerade in stark wachsenden SaaS-Umgebungen ist Skalierbarkeit im Monitoring selbst ein Thema. Klassische Prometheus-Setups stoßen bei hoher Kardinalität schnell an Grenzen. VictoriaMetrics erlaubt horizontale Skalierung und langfristige Speicherung ohne exponentiellen Ressourcenbedarf.

Logs werden zentral über VictoriaLogs aggregiert. Statt verteiltem „kubectl logs" gibt es nun einen konsistenten, durchsuchbaren Log-Stream über alle Services hinweg. Fehler können über Trace-IDs direkt mit konkreten Metriken und Systemzuständen korreliert werden.

Grafana & Tempo: Kontext in einer Oberfläche

Grafana dient als zentrale Oberfläche für das gesamte Team. Dashboards zeigen nicht nur CPU- und Memory-Werte, sondern Applikationsmetriken wie Request-Duration, Error-Rates, Query-Latenzen oder Cache-Hit-Rates.

Mit Grafana Tempo werden Distributed Traces visualisiert. Ein einzelner Klick auf eine Fehlermeldung führt zur vollständigen Transaktionskette – inklusive aller beteiligten Services.

Das verändert die Fehleranalyse fundamental. Statt isolierte Logzeilen zu interpretieren, sehen Engineers das Verhalten einer Anfrage im Gesamtkontext.

Infrastruktur- und Applikationsmetriken im Zusammenspiel

Ein wichtiger Fortschritt war die Korrelation von Infrastruktur- und Applikationsdaten.

Cluster-weite Metriken wie CPU-Last, Memory-Usage oder Netzwerk-Traffic werden kontinuierlich erfasst und im Kontext der Applikations-Traces dargestellt. So wird sichtbar, ob eine Latenzspitze durch eine ineffiziente Query, eine überlastete Node oder ein externes API-Timeout verursacht wird.

Diese Kontextualisierung ist der Unterschied zwischen Monitoring und Observability.

Intelligentes Alerting: Kontext statt Lärm

Alerting wurde nicht als „Threshold auf CPU > 80 %" implementiert, sondern kontextbasiert.

Wenn Error-Rates steigen oder Request-Latenzen bestimmte SLO-Grenzen überschreiten, werden Alerts direkt in die Slack-Channels des Teams gesendet – inklusive Link zu Dashboard, Trace und relevanten Logs.

Das reduziert False Positives und beschleunigt die Reaktion erheblich. Statt erst Daten zu sammeln, beginnt die Analyse sofort.

Ergebnis: Von Stunden zu Minuten – und von Reaktion zu Steuerung

Nach Einführung des APM-Stacks hat sich der operative Alltag des Teams deutlich verändert.

Fehleranalysezeiten wurden drastisch reduziert. Was zuvor mehrere Stunden in Anspruch nahm – Log-Sammeln, Kontext herstellen, Hypothesen testen – lässt sich heute in wenigen Minuten nachvollziehen.

Regressions nach Deployments werden frühzeitig erkannt, oft bevor sie für Endnutzer spürbar sind. Performance-Degradierungen werden anhand von Trends sichtbar, nicht erst beim Ausfall.

Die Stabilität der Plattform ist gestiegen, die User Experience hat sich messbar verbessert. Gleichzeitig wuchs das Architekturverständnis im Team: Engpässe, ineffiziente Komponenten oder problematische Abhängigkeiten werden datenbasiert identifiziert – nicht vermutet.

Ein Nebeneffekt, der strategisch besonders wertvoll ist: Observability-Daten werden inzwischen aktiv für Produktentscheidungen genutzt. Feature-Nutzung, Lastprofile, Performance-Korrelationen – all das fließt in Priorisierung und Skalierungsentscheidungen ein.

Warum APM auf Kubernetes heute kein „Nice-to-have" mehr ist

Mit wachsender Nutzerzahl steigt nicht nur die Last, sondern auch die Erwartungshaltung. SaaS-Kunden tolerieren keine Performance-Unsicherheit. Gleichzeitig werden Architekturen komplexer – Microservices, asynchrone Verarbeitung, Caching-Schichten.

Ohne durchgängige Observability ist diese Komplexität nicht beherrschbar.

Ein skalierbares APM-System auf Basis von VictoriaMetrics, Grafana und OpenTelemetry schafft genau diese Transparenz – ohne proprietäre Lock-ins und ohne die Monitoring-Infrastruktur selbst zum Problem zu machen.

Call to Action

Wenn eure SaaS-Plattform heute noch primär über Log-Debugging in Production betrieben wird, ist das ein Wachstumsrisiko – auch wenn die Architektur modern wirkt.

ayedo unterstützt beim Aufbau skalierbarer Application Performance Monitoring-Systeme auf Kubernetes – mit VictoriaMetrics, VictoriaLogs, Grafana, Tempo und OpenTelemetry, vollständig integriert in eure bestehende Plattform.

Wenn ihr nicht nur wissen wollt, ob eure Anwendung läuft, sondern verstehen wollt, wie sie sich verhält, sprechen wir über eure Observability-Strategie.