Ein neues Jahr bietet immer auch die Chance für einen Neuanfang. Die perfekte Gelegenheit, um die aktuelle Monitoring- und Observability-Plattform für eure Anwendungen genauer unter die Lupe zu nehmen. Solltet ihr noch ein veraltetes Monitoring-System nutzen, habt ihr im Netz vermutlich schon viel über Observability gelesen und wollt gerne wissen, ob ihr euch mit diesem Thema wirklich intensiver befassen solltet.
In diesem Beitrag erkläre ich euch kurz und bündig, was Observability überhaupt ist, was ein echtes Observability-System können muss und wie ihr euch selbst auf den Weg in Richtung Observability machen könnt.
Observability ist ein Mindset, mit dem sich die wichtigsten Fragen rund um euer Unternehmen ganz einfach beantworten lassen – von der User Experience (UX) über die Anwendung selbst bis hin zu Geschäftsmetriken und -prozessen, welche die Grundlage eurer Anwendung bilden. Oder anders formuliert: Bei Observability handelt sich um eine Weiterentwicklung des klassischen Monitorings, bei der die Menge der erfassten Daten bzw. die Anzahl und Art der möglichen Analysen erheblich gesteigert wird. Allerdings handelt es sich bei Observability nicht einfach nur um „Metriken, Traces und Logs“. Vielmehr ermöglicht Observability die Instrumentierung von allem und trägt durch die gezielte Nutzung von Daten dazu bei, fundierte Entscheidungen treffen zu können. Wenn ihr euch eingehender mit dieser Thematik beschäftigen wollt, solltet ihr unbedingt auch meinen Beitrag: „Observability ist nicht das, was ihr denkt“ lesen.
Vor meiner Tätigkeit für Splunk war ich als SRE bzw. als Systemadministrator tätig. Daher weiß ich ganz genau, wie wichtig Observability auf Unternehmensebene ist. Denn bei vielen Problemen, die ich in der Vergangenheit lösen musste, hätte ich mir ein Observability-System wie das von Splunk angebotene definitiv gewünscht. Nachfolgend werde ich auf fünf wichtige Aspekte eingehen, die ein Observability-System mitbringen muss, damit sich eine Investition für euch wirklich lohnt. Warum gerade diese so wichtig sind, will ich euch anhand einiger Beispiele veranschaulichen, die ich selbst während meiner Tätigkeit im Operations-Bereich in Erfahrung bringen konnte.
Jeder Anbieter wird vermutlich behaupten, dass ihr nach dem Kauf und der Installation ihres Produkts sofort von Observability profitieren könnt. Doch das trifft in der Regel nicht zu - nicht einmal dann, wenn ihr euch für unser Produkt entscheidet. Fest steht nur, dass die Inhalte der verschiedenen Angebote zum Teil enorm variieren. Mit Blick auf den zu erfüllenden Nutzen einer Observability-Lösung solltet ihr immer auch jene Aspekte berücksichtigen, die nicht auf entsprechenden Websites veröffentlicht oder in Rezensionen diskutiert werden. Im nächsten Abschnitt werde ich daher die fünf wichtigsten Grundsätze vorstellen, die meiner Meinung nach ein Observability-System mitbringen sollte. Diese gelten für jede Art von System – sei es nun kommerziell oder selbst entwickelt – und haben unmittelbare Auswirkungen darauf, welche Vorteile und welchen Nutzen ihr aus einer Observability-Migration ziehen könnt.
Um ein Observability-System optimal bewerten zu können, solltet ihr die folgenden fünf Grundsätze der Observability beachten: End-to-End-Transparenz im gesamten Stack, Rückmeldungen in Echtzeit, analysegestützte Erkenntnisse, Skalierung und Funktionen auf Unternehmensebene sowie offene Standards. Werfen wir als nächstes einen genaueren Blick auf jeden einzelnen dieser Aspekte:
Wer eine Observability-Plattform integriert, die keine 100-prozentige Transparenz aller Transaktionen bietet – angefangen bei den Browsern der Nutzer über die Anwendung selbst bis hin zur zugrundeliegenden Business-Plattform - dem wird am Ende etwas Entscheidendes fehlen. Hierzu zählt neben der Unterstützung von Methoden zur Analyse des Benutzerverhaltens im Browser (RUM) auch die Vermeidung von Stichprobennahmen (Sampling). Wenn ihr mehr darüber erfahren wollt, warum das Sampling im Widerspruch zur Observability steht, lest ihr am besten meinen Blogbeitrag zum Thema. Zusätzlich zur Nutzererfahrung benötigt ihr aber auch einen Einblick in die Backend-Performance wie bpsw. die Performance von Datenbankabfragen oder dem Code-Profiling.
Zugegeben, ich kann die Zahl an Problemen gar nicht beziffern, die ich bei LinkedIn zu lösen hatte, nachdem mich jemand wichtiges durch die Zusendung eines Fehlerreports an die Mailing-Liste „sre@“ darauf aufmerksam gemacht hatte. An diesem Punkt bleibt einem nichts anderes übrig, als der Ursache auf den Grund zu gehen und das Problem zu beheben. Wenn unsere Tools bei LinkedIn nicht in der Lage gewesen wären, den gesamten End-to-End-Verlauf für alle Nutzer transparent zu machen, wäre es mir kaum möglich gewesen, diese Probleme zu beheben oder es hätte weitaus länger gedauert als nötig.
Eine gute Observability-Plattform muss Erkenntnisse und Daten in Echtzeit bereitstellen können. Wenn ihr erst über das regelmäßige Warnmeldungs-Rollup offiziell von einem Problem erfahrt, dürfte es vermutlich bereits zu spät sein und euch vorab ein verärgerter Tweet oder unzufriedene Kunden darüber in Kenntnis setzen. Außerdem kann die Lebensdauer einer Funktion in einer serverlosen Umgebung bei einigen Hundert Millisekunden (oder weniger) liegen. Daher ist es entscheidend, dass eure Plattform etwaige Probleme so schnell wie möglich anzeigen kann.
Bei einer meiner ersten Tätigkeiten im Tech-Bereich wurden wir per Anruf des CTO über ein Problem informiert, bevor auch nur eine einzige unserer Warnmeldungen überhaupt ausgelöst wurden. Während er uns am Telefon das Problem genauer erklärte, schrillten auch schon die "Alarmglocken". Allerdings bestand die Störung zu diesem Zeitpunkt bereits seit knapp 15 Minuten. Klar war es ein ziemlich ungünstiger Natürlich war es ein ziemlich ungünstiger Zeitpunkt, als das Problem auftratt. Aber das hätte jedem passieren können.
Ein Observability-System generiert eine ungeheure Datenmenge – daran führt kein Weg vorbei. Genau deshalb braucht ihr Funktionen, die euch dabei unterstützen, die vorhandenen Daten sinnvoll zu nutzen und Wichtiges von Unwichtigem zu trennen. Eine Observability-Plattform soll die Lösung von Problemen erleichtern, nicht zusätzlich erschweren. Wer jedoch nur instrumentiert und tonnenweise Daten in ein System einspeist, das keine Möglichkeiten zum Herausfiltern wirklich wichtiger Dinge bietet, macht die Probleme am Ende nur noch schlimmer.
Wenn ihr einem Observability-System zusätzliche Informationen hinzufügt, diese aber nicht analysieren könnt, kann das leicht ins Auge gehen. Bei einem meiner früheren Jobs wurden fast alle Services in einer JVM ausgeführt. Daher war es natürlich sinnvoll, JVM-Arbeitsspeicherstatistiken zu erfassen, um bei zu starker Auslastung, GC-Pausen oder ähnlichen Prozessen entsprechende Benachrichtigungen zu generieren. Allerdings hatten wir beim Hinzufügen dieser Metriken nicht vorausgesehen, wie viele Ereignisse allein durch kleinste Probleme innerhalb einer Anwendung generiert werden würden. Das Warntool verfügte nicht über die nötige Deduplizierung. So mussten wir jedes Mal tausende von Events manuell klären, wenn die Workload-Änderungen so groß waren, dass sich die Speicherzuweisungsmuster in einer App änderten. Auch wenn sich diese Muster überhaupt nicht auf die Nutzer auswirkten, so verhielt sich die App zumindest uns gegenüber einfach anders. Ein gutes Analysetool hätte wenigstens dedupliziert und bestenfalls angezeigt, dass diese Ereignisse keinerlei kundenseitige Metriken beeinflussen und sich somit eine Echtzeituntersuchung gar nicht lohnt.
Ja, ich weiß, dass sich der Begriff „Enterprise“ inzwischen zu einem Buzzword entwickelt hat. Aber ein robustes Observability-System muss weitaus mehr leisten können als ein simples Monitoring. Euer System wird vermutlich über mehrere Clouds (und wahrscheinlich auch über einige lokale Systeme) hinweg funktionieren müssen. Ebenso werdet ihr euch zunehmend darauf verlassen, weshalb es unabhängig vom Wachstum und der Anzahl der Services zuverlässig laufen muss. Ab dem Erreichen einer bestimmten Unternehmensgröße sind dann echte „Enterprise“-Features wie RBAC, Zugriffstoken und Accounting erforderlich. Schlimmstenfalls braucht ihr diese Features, die dann nicht verfügbar sind. Weshalb ihr euch erneut mit einem völlig unnötigen und zeitaufwändigen Wechsel des Observability-Tools konfrontiert seht.
OpenTelemetry ist die Zukunft von Observability. In erster Linie weil die Instrumentierung eine anspruchsvolle Aufgabe ist. Wenn ihr von den Vorteilen der Observability profitieren wollt, müssten all eure Anwendungen instrumentiert werden. Idealerweise braucht es aber nur eine einmalige Instrumentierung, um dann von überall aus jederzeit den Überblick behalten zu können. Genau das ermöglicht OpenTelemetry. Ohne offenen Standard werdet ihr bei der Instrumentierung eurer Umgebung jedes Mal viel Zeit und Mühe investieren müssen, weil ihr gewisse Aufgaben mit ziemlich hoher Sicherheit irgendwann in Zukunft erneut ausführen müsst. Mit OpenTelemetry könnt ihr die Observability-Plattform bei Bedarf spielend leicht wechseln. Außerdem behaltet ihr jederzeit die Kontrolle darüber, welche Daten wohin gesendet werden. Zugleich profitiert ihr von einem besserem Schutz der Kundendaten und möglicherweise einer besseren Performance eures gesamten Observability-Systems.
Beim Einstieg in die Observability solltet ihr von Anfang an auf eine Plattform setzen, welche die oben beschriebenen fünf Grundsätze problemlos erfüllen kann. Splunk Observability Cloud wird diesen Anforderungen gerecht und bietet euch darüber hinaus eine zentrale Anlaufstelle zur Beobachtung sämtlicher Abläufe - sei es in einem lokalen Monolithen oder einer global verteilten Kubernetes-Umgebung. Über Terraform wird zudem „Observability-as-Code“ und vieles mehr unterstützt.
Wenn ihr euch selbst von den Vorzügen überzeugen wollt, könnt ihr entweder eine kostenlose Testversion bestellen , für die ihr keine Kreditkarte benötigt. Oder ihr werft alternativ einen Blick auf unsere Produktübersichtsseite , um euch eine Demo anzusehen.
Die Splunk-Plattform beseitigt die Hürden zwischen Daten und Handlungen, damit Observability-, IT- und Security-Teams in ihren Unternehmen für Sicherheit, Resilienz und Innovation sorgen können.
Splunk wurde 2003 gegründet und ist ein globales Unternehmen – mit mehr als 7.500 Mitarbeitern, derzeit über 1.020 Patenten und einer Verfügbarkeit in 21 Regionen rund um den Globus. Mit seiner offenen, erweiterbaren Datenplattform, die die gemeinsame Nutzung von Daten in beliebigen Umgebungen unterstützt, bietet Splunk allen Teams im Unternehmen für jede Interaktion und jeden Geschäftsprozess End-to-End-Transparenz mit Kontext. Bauen auch Sie eine starke Datenbasis auf – mit Splunk.