Dzmitry Lazerka, Mitbegründer von VictoriaMetrics – Interviewreihe

Dzmitry Lazerka, Mitbegründer von VictoriaMetrics ist ein erfahrener Softwareingenieur und Technologie‑Leader mit tiefgreifender Expertise in Machine Learning, großskaligen Datensystemen, Observability und Infrastruktur. Vor der Mitbegründung von VictoriaMetrics im Jahr 2018 arbeitete er als Machine‑Learning‑Ingenieur bei Lyft’s Level‑5‑Abteilung für autonome Fahrzeuge, wo er an der Entwicklung von Systemen zur Erkennung und Analyse realer Fahrszenarien mitwirkte. Zuvor leitete er Machine‑Learning‑ und Dateninfrastruktur‑Projekte bei Spire Global, war Mitbegründer im Ingenieurwesen bei Bellgram und arbeitete an Daten‑ und Analytik‑Systemen bei Duetto Research und Google über EPAM Systems. Im Laufe seiner Karriere hat Lazerka Projekte in den Bereichen autonomes Fahren, maritime Vorhersage, Suche, Analytik, verteilte Datenverarbeitung und hochskalierbare Backend‑Systeme aufgebaut und geleitet.

VictoriaMetrics ist ein Open‑Source‑Observability‑Unternehmen, das Werkzeuge zum Sammeln, Speichern, Abfragen und Analysieren großer Mengen betrieblicher Daten entwickelt. Die Technologie begann mit VictoriaMetrics, einer leistungsstarken Zeitreihendatenbank und Monitoring‑Lösung, die für Skalierbarkeit, schnelle Abfragen, effiziente Speicherung und geringen Betriebsaufwand konzipiert ist, und hat sich seitdem zu einem umfassenderen Observability‑Stack ausgeweitet, der Metriken, Logs und verteilte Traces über VictoriaMetrics, VictoriaLogs und VictoriaTraces abdeckt. Das Unternehmen bietet zudem Unternehmens‑ und vollständig verwaltete Cloud‑Deployments sowie Anomalie‑Erkennungs‑Funktionen, die Machine Learning auf Zeitreihendaten anwenden. Die Plattform unterstützt Technologien wie OpenTelemetry, Prometheus‑kompatible Workflows, Grafana und Kubernetes und gibt Organisationen die Flexibilität, VictoriaMetrics in bestehende Observability‑Umgebungen zu integrieren.

Bevor Sie VictoriaMetrics mitbegründeten, haben Sie an großskaligen Daten-, Analyse‑ und Machine‑Learning‑Systemen bei Google, Spire Global, Lyft’s Abteilung für autonome Fahrzeuge und anderen Start‑ups gearbeitet. Was hat Sie letztlich dazu bewogen, VictoriaMetrics zu gründen, und welche Probleme aus diesen früheren Rollen haben Sie überzeugt, dass Monitoring und Observability einen grundlegend anderen Ansatz benötigen?

Ich habe meine Karriere damit verbracht, mit großen Datenmengen zu arbeiten. Bei Google, Spire, Lyft und anderen Unternehmen lernt man schnell, dass etwas, das in einem Maßstab gut funktioniert, in einem anderen Maßstab teuer oder schwer zu betreiben sein kann. Monitoring hat genau dieses Problem.

Wenn die Infrastruktur wächst, erzeugt man mehr Metriken. Man fügt mehr Services, mehr Instanzen und mehr Labels hinzu, bis plötzlich das Monitoring‑System selbst eine erhebliche Menge an Infrastruktur benötigt, was für uns nie Sinn ergab. Ein System, das dazu gedacht ist, Ihre Produktionsumgebung zu überwachen, sollte nicht komplexer und teurer im Betrieb werden.

Das war es, was meine Mitgründer Aliaksandr Valialkin und Roman Khavronenko direkt beobachteten. Sie hatten Erfahrung im Betrieb von Prometheus und stießen auf Speichergrenzen. Das Hinzufügen von Systemen wie Thanos löste bestimmte Skalierungsprobleme, führte jedoch auch mehr Komponenten und mehr betriebliche Komplexität ein. Und bei InfluxDB sahen wir, wie eine Lizenzänderung Engineering‑Entscheidungen beeinflussen kann, nachdem Teams bereits in die Technologie investiert hatten.

Die Idee hinter VictoriaMetrics war also praktisch: Können wir eine Zeitreihendatenbank bauen, die dieselbe Aufgabe mit deutlich weniger Ressourcen erledigt und einfacher zu betreiben ist?

Wir haben nicht mit dem Plan begonnen, ein großes Observability‑Unternehmen aufzubauen. Wir begannen damit, ein technisches Problem zu lösen.

Open‑Source‑Bereitstellung war ein Teil davon. Ingenieure konnten VictoriaMetrics herunterladen, reale Produktions‑Workloads darauf ausführen und die Ergebnisse selbst vergleichen. Wir mussten ihnen nicht sagen, dass es schneller oder effizienter ist. Sie konnten es selbst messen.

Das ist der beste Weg, Infrastruktur‑Software zu entwickeln. Wenn die Technologie gut ist, sollten Ingenieure sie selbst beweisen können.

Observability‑Kosten können stillschweigend einen erheblichen Teil der Cloud‑Rechnung eines Unternehmens ausmachen. Wo geraten diese Kosten typischerweise außer Kontrolle, und welche architektonischen oder Beschaffungsentscheidungen treffen Engineering‑Teams am häufigsten falsch?

Ich würde zuerst die Kardinalität betrachten.

Angenommen, Sie beginnen mit einer vernünftigen Metrik und fügen dann ein Label mit möglichen Werten hinzu. Plötzlich wird aus einer Metrik Tausende oder Millionen eindeutiger Zeitreihen. Das System muss nun mehr Daten ingestieren, indexieren, speichern und abfragen, was zu mehr CPU, Speicher und Speicherplatz führt.

Der schwierige Teil ist, dass dies nicht durch eine einzelne falsche Entscheidung geschieht. Es passiert schrittweise. Fügt man mehr Services, K8s‑Pods, Kunden und Labels hinzu, vervielfacht sich der Aufwand.

Das zweite Problem besteht darin, alles mit derselben Auflösung über denselben Zeitraum zu speichern. Nicht alle Observability‑Daten haben denselben Wert. Die Metriken, die Sie für einen Alarm oder ein SLO benötigen, unterscheiden sich von hochvolumigen Diagnose‑Telemetrien, die Sie während eines Vorfalls einmalig betrachten.

Wenn Sie all diese Daten gleich behandeln, zahlen Sie letztlich Premium‑Infrastruktur‑ oder SaaS‑Preise für Daten, die dies nicht benötigen.

Deshalb sehen einige Unternehmen Observability als Beschaffungsproblem und fragen, welche Plattform heute am einfachsten zu deployen ist. Ich stelle Fragen wie: “Was passiert, wenn die Menge an Telemetrie um das 10‑fache steigt? Was passiert mit der Kardinalität? Was speichern wir? Wie lange? Und was passiert mit den Kosten?”

Es gibt technische Lösungen für diese Probleme. Beispielsweise können Sie bei Streaming‑Aggregation Metriken bereits vor dem Speichern zusammenfassen, anstatt jede Rohzeitreihe zu speichern und später zu aggregieren. Sie können hochkardinale Workloads von geschäftskritischem Monitoring trennen. Außerdem können Sie je nach Wert der Daten unterschiedliche Aufbewahrungs‑ und Auflösungsrichtlinien verwenden.

Ziel ist nicht, so wenig Telemetrie wie möglich zu sammeln. Sie benötigen genügend Informationen, um zu verstehen, was Ihre Systeme tun.

Ziel ist es, zu vermeiden, Ressourcen für das Sammeln, Verarbeiten und Speichern von Daten aufzuwenden, die keinen zusätzlichen Mehrwert bieten.

Observability ist ein technisches System. Seine Kosten sollten ebenfalls technisch gestaltet werden.

Grammarly hat gesagt, dass sein Proof‑of‑Concept mit VictoriaMetrics zu einer zehnfach niedrigeren AWS‑Rechnung führte. Wenn Unternehmen Einsparungen in diesem Ausmaß erzielen, was ändert sich dann tatsächlich im Hintergrund: Datenkompression, Rechenanforderungen, Speicherarchitektur, operative Komplexität oder eine Kombination dieser Faktoren?

Es ist eine Kombination, aber die Kompression und der Ressourcen‑Footprint erledigen den größten Teil der Arbeit. VictoriaMetrics verwendet eigens entwickelte Kompression für Zeitreihendaten, sodass dieselben Metriken nur einen Bruchteil des Speicherplatzes beanspruchen, den sie in einer generischen Datenbank benötigen würden. Darüber hinaus verbrauchen wir bei gleichen Ingest‑Raten vier‑ bis fünfmal weniger RAM als Prometheus und bis zu zehnmal weniger Festplattenspeicher. Als Grammarly ihr Proof‑of‑Concept durchführte, zeigte sich das direkt in ihrer AWS‑Rechnung, weil sie nicht nur weniger Daten speicherten, sondern auch weniger und kleinere Instanzen dafür einsetzten.

Der Aspekt der operativen Komplexität ist ebenfalls wichtig, aber er ist indirekter. Viele Teams, die Observability‑Kosten kalkulieren, betrachten nur die Posten für Speicher und Rechenleistung und übersehen die Ingenieur‑Stunden, die für den Betrieb eines fünf‑Komponenten‑Thanos‑Stacks im Vergleich zu einer einzelnen Binärdatei aufgewendet werden. Das ist echtes Geld; es ist nur schwer, eine konkrete Zahl dafür zu nennen.

Prometheus ist zu einer Grundlage für cloud‑native Monitoring geworden, doch einige Organisationen stoßen schließlich an Skalierbarkeits‑ oder Betriebsgrenzen. Was veranlasst ein Unternehmen typischerweise, über eine konventionelle Prometheus‑Implementierung hinauszublicken, und wann wird VictoriaMetrics zu einer logischen Alternative?

Prometheus ist hervorragend in dem, wofür es entwickelt wurde: einer ein‑Node‑Scrape‑ und Alarm‑Engine. Teams stoßen in der Regel auf zwei Arten an ihre Grenzen: Entweder wächst die Kardinalität über das hinaus, was eine einzelne Prometheus‑Instanz im Speicher halten kann, oder sie benötigen langfristige Aufbewahrung und globale Abfragen über mehrere Cluster hinweg, wofür Prometheus von Haus aus nie konzipiert wurde. Dann fügen die Leute Thanos oder Cortex hinzu, und genau dort beginnt meist der operative Schmerz. Man geht von einem einzelnen Binary zu einem verteilten System mit einem Compactor, einem Querier, einem Store‑Gateway und vielem mehr über, das um 3 Uhr morgens ausfallen kann.

VictoriaMetrics ist der logische nächste Schritt, weil es ein Drop‑in‑Replacement ist, keine Neuarchitektur. Teams richten ihre bestehende Prometheus‑Scrape‑Konfiguration auf VictoriaMetrics aus und behalten jedes Grafana‑Dashboard, jeden Alarm und jede Aufzeichnungsregel, die sie bereits erstellt haben. Die Migration ist eine Konfigurationsänderung, kein Projekt, und sie erhalten die Skalierbarkeit, ohne fünf neue Komponenten betreiben zu müssen.

Wir sehen, dass Engineering‑Teams darüber nachdenken, ob sie große, vollständig verwaltete Observability‑Plattformen benötigen oder ob sie effizientere Stacks aus Open‑Source‑Komponenten bauen können. Sehen Sie das als einen breiteren strukturellen Wandel im Observability‑Markt und wie stark Open Source den traditionellen Preis‑Modellen Druck macht?

Es ist strukturell; keine vorübergehende Reaktion auf ein schlechtes Haushaltsjahr. Observability‑Anbieter haben historisch nach Eingangs‑Volumen oder Host‑Anzahl abgerechnet, und dieses Modell wirkt sich umso stärker negativ auf den Kunden aus, je mehr das Unternehmen wächst. Je erfolgreicher ein Unternehmen ist, desto mehr zahlt es, und die Preisgestaltung hat kaum einen realen Bezug zum gelieferten Wert. Engineering‑Teams haben begonnen, die Rechnung selbst zu machen, und erkennen, dass ein selbstgehosteter, effizienter Open‑Source‑Stack diese Gleichung komplett verändert. Das liegt daran, dass die Kosten mit der tatsächlich betriebenen Infrastruktur skalieren und nicht nach einer vom Anbieter kontrollierten Messformel.

Das setzt die etablierten Anbieter unter echten Preisdruck. Wenn ein Team seine bestehende Scrape‑Konfiguration auf eine Open‑Source‑Alternative umstellen und die Rechnung um 60 % bis 80 % senken kann, ohne Funktionalität zu verlieren, ist das intern kein schweres Gespräch. Anbieter, die weiterhin pro Host oder pro benutzerdefinierte Metrik abrechnen, werden weiterhin Kunden verlieren, die diese Rechnung nicht mehr machen.

AI‑Infrastruktur führt eine ungewöhnlich teure neue Ressource in die Gleichung ein: GPUs. Was sollten Unternehmen, die KI‑Training oder -Inference betreiben, über die reine GPU‑Auslastung hinaus überwachen, und wo kann bessere Observability direkt zu niedrigeren KI‑Infrastruktur‑Kosten führen?

Die reine GPU‑Auslastung sagt nicht genug.

Man kann auf einem Dashboard 90 % Auslastung sehen und annehmen, alles sei in Ordnung. Aber was man wirklich wissen will, ist: Was macht die GPU?

Man muss tiefer schauen. Welche CUDA‑Kernels laufen? Wie wird GPU‑Speicher zugewiesen? Wie viel Zeit wird damit verbracht, Speicher zu verschieben, anstatt zu rechnen? Nutzt die Workload Tensor‑Cores, wenn sie sollte? Ist die GPU tatsächlich der Engpass, oder wartet sie auf Daten von irgendwo anders?

Das sind wichtige Fragen, weil GPUs teuer sind. Eine kleine Ineffizienz, die sich über Hunderte oder Tausende von GPUs wiederholt, wird zu einer sehr großen Geldsumme.

Zum Beispiel, wenn GPUs warten, weil die Datenpipeline sie nicht schnell genug versorgen kann, wird das Kaufen weiterer GPUs das Problem nicht lösen. Man muss den Engpass finden. Gleiches gilt für den Speicher. Wenn Workloads Speicher ineffizient zuweisen, kann bessere Sichtbarkeit den Ingenieuren helfen, Batch‑Größen anzupassen oder mehr Workloads auf derselben Hardware laufen zu lassen.

Hier wird Observability für AI‑Infrastruktur interessant. Es geht nicht nur darum, zu erkennen, dass etwas kaputt ist. Es kann zeigen, wo Rechenleistung verschwendet wird.

Es gibt zudem ein Observability‑Problem, das durch all dieses Monitoring entsteht. GPUs können eine Menge detaillierter, hochkardinaler Telemetrie erzeugen. Wenn man alles sammelt und direkt in eine teure SaaS‑Plattform schickt, kann man zwar die GPU‑Kosten senken und dann einen Teil der Einsparungen für die Speicherung von Monitoring‑Daten verwenden. Das ist jedoch keine sinnvolle Optimierung.

Mit OpenTelemetry und Projekten wie OpenLIT können wir viel tiefere Einblicke in GPU‑Workloads erhalten. Dann können wir mit VictoriaMetrics die Daten aggregieren, unnütze Dimensionen entfernen und die Informationen effizient behalten, die Ingenieure tatsächlich benötigen.

Die nützliche Frage ist nicht: „Wie stark sind meine GPUs ausgelastet?“

Sie lautet: „Welche nützliche Arbeit bekomme ich von den GPUs, für die ich zahle?“

Sobald Sie das beantworten können, lassen sich bessere technische und Kosten‑Entscheidungen treffen.

KI‑Agenten schaffen sehr unterschiedliche Observability‑Herausforderungen im Vergleich zu traditioneller Software, weil eine einzelne Anfrage Modell‑Aufrufe, Tool‑Nutzung, Vektor‑Datenbank‑Abfragen, Übergaben und potenziell lange Ketten autonomer Aktionen auslösen kann. Wie muss sich Observability weiterentwickeln, wenn Unternehmens‑Anwendungen zunehmend agenten‑basiert werden?

Traditionelle Observability geht davon aus, dass eine Anfrage einen relativ vorhersehbaren Pfad durch Ihre Infrastruktur nimmt. Agenten‑Workloads funktionieren nicht so. Ein einzelner Agent kann ein Modell aufrufen, dann ein Tool, dann ein weiteres Modell und dreimal neu versuchen, bevor er etwas zurückgibt. Jeder dieser Schritte benötigt eigene Sichtbarkeit.

Die Fehlermodi sind ebenfalls anders. Ein traditioneller Service antwortet entweder korrekt oder nicht. Ein Agent kann erfolgreich antworten und dennoch falsch, langsam oder teuer sein, und das erscheint nicht als typischer Fehler in einem Dashboard, das für Verfügbarkeit gebaut wurde.

Der Aspekt, der Teams überrascht, ist die Kardinalität. Ein einzelner Agent‑Workflow kann Metriken erzeugen, die an einen bestimmten Nutzer, Prompt und Tool‑Aufruf gebunden sind, und dieses Volumen summiert sich schnell, besonders bei Rekursions‑Schleifen, in denen ein Planner dasselbe Tool immer wieder aufruft. Jedes System, das agenten‑basierte Workloads beobachten soll, muss diese Skalierung bewältigen, ohne dass die Kostenkurve vertikal ansteigt – genau das Problem, das wir lösen. Metriken, Logs und Traces bleiben die richtigen Bausteine. Was sich ändern muss, ist das Volumen und das Kostenmodell darunter.

VictoriaMetrics setzt zudem maschinelles Lernen und KI‑unterstützte Workflows für Anomalieerkennung ein. Wo glauben Sie, dass KI heute das Monitoring und die Incident‑Response wirklich verbessern kann, und wo ist menschliches Urteilsvermögen noch schwer zu ersetzen?

Es ist wichtig, eine Person im Prozess zu behalten, um Ideen zu generieren, die Umsetzung zu steuern und die Ergebnisse zu validieren. Mit anderen Worten, im Vergleich zum traditionellen Workflow hat sich nichts grundlegend geändert. Was sich geändert hat, ist, dass die Möglichkeiten zur Lösungsfindung verstärkt wurden. Jeder kann jetzt Software erstellen, aber das sollte die Akzeptanzkriterien nicht senken. Sie sollten vielmehr deutlich steigen.

Wo KI wirklich hilft, ist beim Aufdecken dessen, was eine Person im Rauschen sonst übersehen würde – Ausreißer und Trends, die keinen manuellen Schwellenwert auslösen. Bei VictoriaMetrics haben wir eine einfache interne KI‑Richtlinie: Mitarbeitende dürfen ihren Workflow beliebig automatisieren, bleiben aber für das Endergebnis verantwortlich. Das entspricht ungefähr dem Standard, den wir bei der Anomalieerkennung in der Produktionsumgebung eines Kunden anwenden würden. Das Modell kann etwas markieren, aber ein Mensch muss entscheiden, was das bedeutet und was zu tun ist.

VictoriaMetrics ist weiterhin Open Source und hat einen selbst‑finanzierten, kundenfinanzierten Ansatz gewählt, anstatt dem traditionellen, von Risikokapital getriebenen Infrastruktur‑Startup‑Modell zu folgen. Wie hat das Ihre Produktentwicklung, Preisgestaltung und die Entscheidung, welche Technologien Open Source bleiben, beeinflusst?

Selbstfinanzierung verändert die Anreizstruktur stärker, als die meisten erwarten. Ohne einen Vorstand, der uns zwingt, bis zu einem bestimmten Quartal einen ARR‑Wert zu erreichen, mussten wir nicht die üblichen Kompromisse eingehen, wie die Open‑Source‑Version zu schwächen, um die Kunden in eine kostenpflichtige Stufe zu drängen, oder die Lizenz zu ändern – wie es InfluxDB oder HashiCorp getan haben, als sie Einnahmen vor Cloud‑Anbietern schützen wollten. VictoriaMetrics OSS ist heute Apache 2.0 und wir haben nicht vor, das zu ändern.

Wie wir entscheiden, was Open Source bleibt, ist einfach: Die Kern‑Engine, das, was Ingenieure benötigen, um uns ihre Produktionsdaten anzuvertrauen, bleibt offen. Wir berechnen das, was ein Unternehmen benötigt, sobald es in großem Maßstab läuft und jemanden verantwortlich haben muss: Multi‑Tenancy, Unternehmens‑Authentifizierung, Compliance‑Support, ein CVE‑SLA und direkten Zugriff auf die Ingenieure, die den Code geschrieben haben, anstatt einer Support‑Warteschlange. Kundenfinanzierung bedeutet zudem, dass die Roadmap von den tatsächlichen Problemen in der Produktion bestimmt wird und nicht von dem, was in einem Pitch‑Deck finanzierbar ist.

Da Metriken, Logs, Traces, KI‑Anwendungs‑Telemetrie, GPU‑Monitoring und automatisierte Anomalieerkennung zunehmend zusammenlaufen, wie wird Ihrer Meinung nach der Observability‑Stack in den nächsten Jahren aussehen und was werden Engineering‑Teams von Plattformen erwarten, die relevant bleiben wollen?

Der Stack konvergiert operativ, bevor er zu einem einzigen Produkt zusammenläuft, und diese Unterscheidung ist wichtig. Die meisten Teams wollen keine monolithische Plattform mit einer einzigen UI, die alles zusammenhält. Sie möchten Metriken, Logs und Traces auf einem einheitlichen Betriebsmodell, bei einem Anbieter und einer Lizenzierung laufen lassen, ohne die Möglichkeit aufgeben zu müssen, jedes Signal unabhängig zu betreiben, wenn ein bestimmtes Team das benötigt. Das ist die Richtung, in die VictoriaMetrics entwickelt. Wir versuchen nicht, alles in einer einzigen Binärdatei zu bündeln. Wir wollen sicherstellen, dass die drei Signale dieselbe Engine und dieselben Effizienz‑Merkmale teilen, sodass das Hinzufügen eines zweiten oder dritten Signals nicht bedeutet, ein zweites oder drittes operatives Problem zu übernehmen.

Die Plattformen, die relevant bleiben, sind diejenigen, die KI‑Telemetrie und GPU‑Monitoring in dasselbe Modell integrieren können, ohne dass die Kostenkurve bricht. KI‑Workloads erzeugen Telemetrie in einem Umfang, für den herkömmliche Preis‑modelle pro Metrik oder pro Host nie ausgelegt waren. Teams hören entweder auf, die benötigten Daten zu sammeln, oder ihre Observability‑Kosten steigen schneller als die KI‑Investition, die sie überwachen sollen. Engineering‑Teams werden von Plattformen erwarten, dass sie dieses Volumen genauso handhaben, wie sie von jeder Infrastruktur Skalierbarkeit erwarten, ohne dass sie jedes Mal die Architektur neu gestalten oder neu verhandeln müssen, wenn das Workload‑Volumen wächst.

Danke für das großartige Interview, Leser, die mehr erfahren möchten, sollten VictoriaMetrics besuchen.