Ein praktischer Leitfaden zur Observability von Datenpipelines

Wenn Sie diese Blog-Reihe schon eine Weile verfolgen, wird Ihnen auffallen, dass es bei vielen der Themen darum geht, wie sich die Health von Software und der zugehörigen Infrastruktur überwachen lässt. Dieser Beitrag beschäftigt sich mit einem eher unkonventionellen Anwendungsfall – Observability von Datenpipelines –, und wie Sie Observability von Datenpipelines mit Plattformen wie New Relic verbessern können. 

Hintergrund

Wir alle wissen, dass im modernen digitalen Unternehmen Daten von zentraler Bedeutung sind. Sie bilden oft den Kern des Entscheidungsprozesses. Bei New Relic ist ein Teil unserer Daten ganz besonders wichtig, da sie die Grundlage für die von uns erstellten Rechnungen bilden. Dies liegt daran, dass New Relic im Jahr 2020 von einem lizenzbasierten Modell zu einem nutzungsabhängigen Preismodell übergegangen ist. Das ist zwar kein neues Konzept, aber die damals vorgenommene Umstellung hat auch heute noch große Auswirkungen auf unsere eigenen Observability-Methoden.  Das gilt insbesondere für die Nutzungspipeline, die die kostenpflichtige Anwendungsnutzung erfasst. Dabei ist Genauigkeit natürlich enorm wichtig, damit wir unserer Kundschaft stets den richtigen Betrag in Rechnung stellen. Und da wir jeden Monat Tausende von Rechnungen verschicken, ist es schlichtweg nicht möglich, die Nutzungsdaten jeder Rechnung manuell zu prüfen.  Das folgende Framework bietet eine Grundlage für die richtige Herangehensweise an Observability von Datenpipelines.  Er ist zwar aus unserer eigenen Erfahrung entstanden, doch die einzelnen Punkte lassen sich auch auf andere Situationen übertragen. 

1. Ziele setzen

Als ersten Schritt sollten Sie sich überlegen: „Was möchte ich mit Observability in meiner Datenpipeline erreichen?“ Es gibt einige allgemeine Ziele, die für die meisten Pipelines anwendbar sind: Überwachung der SLA-Erfüllung, Fehlermeldungen, Beobachtung bestimmter Traffic-Muster oder Ausreißer und so weiter.  Es kann aber auch ganz bestimmte Ziele speziell für Ihr Unternehmen geben.  Wir haben zum Beispiel zwei Hauptziele:

• Die abrechenbare Nutzung genau erfassen und eine entsprechende Rechnung stellen.
• Die Datenqualität in der Nutzungspipeline automatischen Prüfungen unterziehen.

2. Die eigenen Daten verstehen

Dies mag selbstverständlich erscheinen, ist aber ein Schritt, der oft übersehen wird. Nehmen Sie sich etwas Zeit dafür, Ihre Daten besser zu verstehen. Das kann Ihnen helfen zu erkennen, wo Sie zum Erreichen Ihrer Ziele ansetzen müssen. Dabei sollten Sie sich zum Beispiel folgende Fragen stellen:

• In welcher Form liegen die Daten vor? Welches Schema haben sie und verfügen sie über alle Attribute, die zum Erreichen der gewünschten Ziele notwendig sind? Oder müssen sie mit weiteren Datenquellen angereichert werden?
• Was ist das Datenvolumen? Wie viele Datenpunkte verarbeiten Ihre Systeme pro Minute? Gibt es bestimmte Spitzen?

Wenn Sie diese Fragen nicht oder nicht ausreichend beantworten können, haben Sie die Option, Ihre Datenverarbeitungs-Pipelines mithilfe von Custom-Events oder benutzerdefinierten Metriken zu instrumentieren. Wenn Sie das getan haben, können Sie mit der New Relic Query Language (NRQL) Abfragen schreiben, die Ihnen grundlegende Antworten auf diese Fragen liefern.

In unserem Fall ist einer der vielen Punkte, die wir in unserer Pipeline verfolgen, die Anzahl der Nutzungs-Events, die von den Produktteams produziert werden. Diese Events stellen die rohen Nutzungsdaten dar, die von einem einzelnen Service oder einer API gesammelt werden, und dienen als Haupt-Input für unsere Pipeline. Um Einheitlichkeit zu gewährleisten, haben wir eine interne Bibliothek erstellt, die alle Produktteams zur Erstellung dieser Rohdaten verwenden. Diese Bibliothek standardisiert nicht nur die Event-Payload, sondern bietet auch Funktionen für das Reporting über benutzerdefinierte Metriken zu den erzeugten Events. Mit diesen benutzerdefinierten Metriken können wir NRQL-Abfragen wie diese schreiben:

Diese spezifische Abfrage generiert ein Diagramm wie das folgende, das uns einen Einblick in etwaige Trendabweichungen auf Makroebene gibt (wir haben auch Alert-Bedingungen für diese Daten eingerichtet).

Auch für die Kapazitätenplanung können diese Art von Daten genutzt werden. Wenn Sie wissen, dass für X Millionen Events pro Stunde Y Kafka-Broker erforderlich sind, können Sie relativ genau vorhersagen, wie viele zusätzliche Broker benötigt werden, wenn die Anzahl der Events um einen bestimmten Wert steigt.

3. Klein anfangen

Wenn Sie mit der Erstellung einer neuen Datenpipeline beginnen, ist es am besten, von Anfang an Observability einzuplanen. Bei bereits bestehenden Pipelines ist es dagegen ratsam, klein anzufangen. 

Eine typische Datenverarbeitungs-Pipeline umfasst in der Regel mehrere Phasen zwischen Input und Output.

Anstatt zu versuchen, die gesamte Pipeline auf einmal zu instrumentieren, sollten Sie sich zunächst auf kleinere Bereiche mit hohem Potenzial konzentrieren. Dabei sollten Sie Folgendes berücksichtigen:

• Bereiche, von denen Sie wissen, dass sie potenziell instabil sein können. Wenn Sie zum Beispiel wissen, dass eine bestimmte Phase aufgrund ihres Codes oder ihrer Infrastruktur potenziell instabil ist, sollten Sie diese zuerst instrumentieren.
• Bereiche mit hohen geschäftlichen Auswirkungen. Wenn zum Beispiel eine bestimmte Phase eine geschäftskritische Metrik berechnet, könnte es sinnvoll sein, diese zu priorisieren.

Wenn Sie festgelegt haben, worauf Sie sich konzentrieren möchten, können Sie die bereits erwähnten APIs für Custom-Events und benutzerdefinierten Metriken sowie die Quickstart-Integrationen von New Relic für Instant Observability einsetzen, um das Observability-Potenzial auszuschöpfen.

4. Nicht zu kompliziert denken

Es gibt zwar hochmoderne und komplexe Verfahren für Observability in Datenpipelines (z. B. mittels künstlicher Intelligenz und maschinellem Lernen), doch auch einfachere Verfahren, die schnelle Erfolge liefern können, sind nicht zu unterschätzen. Eine Verfahren, dass wir selbst einsetzen, besteht darin, regelmäßig Beispieldaten durch unsere gesamte Nutzungspipeline zu senden und dann den transformierten Output auf seine Richtigkeit zu überprüfen. In der folgenden Abbildung sehen Sie, wie das in der Praxis aussehen kann.

Ausgehend von der oben abgebildeten Beispiel-Pipeline können Sie einen Prozess erstellen, der in einem bestimmten Intervall einen Input (X) erzeugt. Anschließend können Sie mit New Relic den tatsächlichen Output mit dem erwarteten Wert (Y) vergleichen. Sie können dieses Monitoring weiter automatisieren, indem Sie Alert-Bedingungen erstellen, die verschiedene Kanäle benachrichtigen, wenn der Input X nicht zum Output Y führt.

Das sagt Ihnen zwar nicht, wo ein Problem in der Pipeline besteht, aber es ist ein guter Ausgangspunkt für die weitere Überprüfung, ob die Pipeline normal funktioniert (oder nicht). Bei New Relic führen wir eine solche einfache, ganzheitliche Datenprüfung für jeden in Rechnung gestellten Wert durch. Wenn ein Input nicht zum erwarteten Output passt, benachrichtigt die Plattform sofort das zuständige Team, damit der Vorfall untersucht wird.

Fazit

Observability von Datenpipelines ist ein umfangreicher und äußerst komplexer Bereich. Auch wenn jede Pipeline andere technische und geschäftliche Anforderungen hat, so haben doch alle Pipelines eines gemeinsam: Sie müssen überwacht werden.  Wir hoffen, dass wir Ihnen mit diesem Blogpost ein paar nützliche Tipps für die Entwicklung Ihrer eigenen Observability-Strategie geben konnten.  Außerdem haben wir damit hoffentlich gezeigt, wie Plattformen wie New Relic den Einstieg deutlich vereinfachen können.