Das Zeitalter der Observability: Warum die Zukunft offen, vernetzt und programmierbar ist

Als Lew Cirne, Gründer von New Relic, Application Performance Monitoring (APM) entwickelte, bestand die wichtigste Innovation in der umfassenden Code-Transparenz monolithischer Anwendungen, die in einem Rechenzentrum ausgeführt werden. Anschließend stellte er es jedem Ingenieur in Entwicklung und in Operations als SaaS-Lösung zur Verfügung. Heute erhöhen neue Technologien und Praktiken – Cloud, Microservices, Container, Serverless, DevOps, Site Reliability Engineering (SRE) und mehr – die Geschwindigkeit und verringern die Reibung beim Abrufen von Software vom Code zur Produktion. Und führen so auch zu einer höheren Komplexität. 

Unser Unternehmen hat das Monitoring der Anwendungs-Performance als Vorreiter entwickelt und perfektioniert. Wir glauben, dass die Herausforderungen für moderne Softwareteams einen neuen Ansatz erfordern. Das Gegenmittel gegen die Komplexität und die Möglichkeit für Ingenieure, moderne Systeme verfügbar zu halten und ein hervorragendes Kundenerlebnis zu erzielen, ist Observability.

Observability gewinnt in der Welt der Software an Aufmerksamkeit. Ingenieure können dank ihr und trotz der Komplexität des modernen digitalen Unternehmens hervorragende Kundenerlebnisse mit Software erzielen.

Aber eines sei gesagt: Observability ist kein schickes Synonym für Monitoring.

Mithilfe von Monitoring erhalten Softwareteams Instrumente, mit denen Daten über ihre Systeme erfasst werden und auf Fehler und Probleme schnell reagiert werden kann. Mit anderen Worten, das Monitoring baut Ihre Systeme auf, um Daten zu sammeln, mit dem Ziel, Ausfälle vorauszusagen und schneller reagieren zu können. 

Observability hingegen ist die Praxis, diese Systeme mit Tools zu instrumentieren, um umsetzbare Daten zu sammeln, die nicht nur das wenn eines Fehlers oder Problems liefern, sondern – was noch wichtiger ist – das warum. Und genau das benötigen Teams, um schnell zu reagieren und Notfälle mit moderner Software zu lösen.

Observability hilft modernen Softwareteams:

• Hochwertige Software in großem Maßstab zu liefern
• Eine nachhaltige Innovationskultur aufzubauen
• Investitionen in Cloud und moderne Tools zu optimieren
• Die Echtzeit-Performance ihres digitalen Geschäfts zu überblicken

Wir bei New Relic glauben, dass Metriken, Ereignisse, Protokolle und Traces (oder M.E.L.T., wie wir sie bezeichnen) die wesentlichen Datentypen für die Observability sind. Bei der Observability geht es jedoch um viel mehr als nur um Daten.

Wie können Sie die Observability Ihrer Systeme sicherstellen? Und welche Ergebnisse können Sie erwarten, wenn Sie Observability haben? Unserer Meinung nach gibt es vier zentrale Herausforderungen, die das Bedürfnis nach Observability bestimmen. Um diesen Herausforderungen gerecht zu werden, müssen Unternehmen eine ganz bestimmte Observability-Praxis anwenden. Diese basiert auf drei Komponenten: offene Instrumentierung, verbundene Daten und Programmierbarkeit. In diesem E-Book stellen wir Ihnen diese Trends, Herausforderungen und Komponenten vor.

Die Geschwindigkeit der technologischen Innovation in den letzten fünf bis zehn Jahren war umwerfend und hatte enorme Auswirkungen auf die Softwareteams. Wichtige Trends sind:

• Innovationsdruck: Software-Teams stehen unter enormem Druck, neue Funktionen und Erfahrungen schneller als die Konkurrenz auf den Markt zu bringen. Die Cloud hat die Wettbewerbslandschaft vergrößert, indem die Eintrittsbarriere gesenkt wurde. Sie verlangt, dass Softwareteams schneller als je zuvor liefern und sich anpassen – oftmals mit weniger Ressourcen. Leistungsstarke Performer stellen Software zwischen einmal pro Stunde und einmal pro Tag bereit. Herausragende Performer stellen sie bei Bedarf mehrmals pro Tag bereit.
• Höhere Kundenerwartungen: Kunden erwarten mehr und tolerieren weniger. Langsame, fehleranfällige oder schlecht gestaltete Benutzererfahrungen sind für Kunden kein guter Anfang. Wenn sie nicht das tun können, wozu sie gekommen sind, werden sie nicht zurückkommen. Laut Dot Com Infoway, dem Entwickler mobiler Apps, deinstallieren 62 % der Nutzer eine App, wenn sie auf einem Handy abstürzt, einfriert oder Fehler aufweist. Herausragende Performer im Bereich Software Delivery Performance Restore Service können im Falle eines Incidents oder Fehlers, der die Benutzer beeinträchtigt, diesen umgehend oder in weniger als einer Stunde beheben. Niedrigeren Performer dagegen benötigen dafür zwischen einer Woche und einem Monat.1
• Mehr Technologieoptionen: Heute bauen Unternehmen Mikroservice-Architekturen und verteilte Systeme auf einer beliebigen Anzahl von Cloud-Anbietern und Computerplattformen auf. Diese Dienste sind einfacher als je zuvor zu übernehmen und zu nutzen. Noch dazu arbeiten diese zunehmend nahtlos zusammen. Sie können verschiedene Systeme und Services auswählen, um alles zu unterstützen, was Sie in einem modernen Technologie-Stack benötigen. Gleichzeitig können sie den Verwaltungsaufwand für die Konfiguration und Wartung des Stacks reduzieren.
• Der Aufstieg von DevOps und Automatisierung: Unternehmen organisieren sich in Form autonomer Teams, die für die durchgängige Konzeption, Bereitstellung und den Betrieb von Diensten verantwortlich sind, die sie in der Produktion besitzen. Manchmal nutzen sie gemeinsame Plattformen und Tools, die von internen Plattform-Teams als Services bereitgestellt werden. Die Automatisierung reduziert sich wiederholende, geringwertige Arbeit und verbessert die Zuverlässigkeit. In einer cloud-nativen Architektur wird alles im Stack von Software gesteuert. Die gesamte Oberfläche ist programmierbar. Und da all diese Automatisierung auf Software basiert, kann sie fehlschlagen. Teams müssen ihre CI/CD und andere Automatisierungstools genauso überwachen wie Anwendungen, die ihren Kunden direkt zur Verfügung stehen. Das Sammeln von Daten zu jeder Komponente in einem System ist das Wesentliche der Observability.

Diese Trends führen zu vier großen Herausforderungen, die die Observability moderner Systeme erfordern:

1. Höhere Komplexität: Cloud-native Technologien haben die Art und Weise, in der Anwendungen erstellt, bereitgestellt und betrieben werden, verändert. Aber sie haben auch die Komplexität der für deren Wartung verantwortlichen Teams erhöht. Während monolithische Anwendungen zu Mikrodiensten umgestaltet werden, bei denen die Lebensdauer eines Containers in Minuten oder weniger gemessen werden kann, haben Softwareteams plötzlich Services, die sich ständig ändern. Die Zerlegung jeder Anwendung in potenziell Dutzende von Microservices bedeutet für Betriebsteams eine Komplexität von Skaleneffekten. Sie sind nun für Services verantwortlich, über die sie nur wenig wissen und dennoch warten müssen.
2. Höheres Risiko: Durch häufige Deployments und dynamische Infrastruktur entstehen mehr Risiken. Dies macht die sofortige Erkennung und das sofortige Handeln wichtiger als in Zeiten seltener Deployments. Und da Unternehmen agile Vorgehensweisen und die kontinuierliche Bereitstellung von Software schneller implementieren, fügen sie einen weiteren Oberflächenbereich von Software hinzu (über Bereitstellungstools und Pipelines), die überwacht und gewartet werden muss.
3. Wissenslücken: Der rapide Anstieg von Microservices-Architekturen hat neue Herausforderungen mit sich gebracht. Softwareteams müssen nun überdenken, wie sie Anwendungen entwerfen, erstellen und bereitstellen. Jedes Teammitglied muss auch ihm zuvor nicht vertraute Teile einer Anwendung verstehen und in der Lage sein, Fehler zu beheben. Heute muss ein Datenbankexperte beispielsweise auch Kenntnisse über Netzwerk und APIs haben. Der Nachteil ist, dass die Anzahl der neuen und unterschiedlichen Technologien, mit denen Teams umgehen müssen, für eine Person allein zu groß ist. Teams brauchen Möglichkeiten, um diese Technologien im Kontext der von ihnen geleisteten Arbeit besser zu verstehen.
4. Zu viele Tools: Hybridumgebungen, Tausende von Containern in der Produktion und mehrere Bereitstellungen pro Tag führen zu enormen Mengen an betrieblichen Telemetriedaten. Das Jonglieren mehrerer Monitoring-Tools und des erforderlichen Kontextwechsels zum Auffinden und Korrelieren der wichtigsten Daten oder zur Problemfindung und -lösung nimmt wertvolle Zeit in Anspruch. Diese haben die Teams nicht, wenn ihre Kunden von einem Produktionsproblem betroffen sind.

Angesichts dieser Trends und Herausforderungen sowie der allgemeinen Geschwindigkeit des technologischen Wandels benötigen Teams eine einzige Lösung, die die Komplexität und das Risiko reduziert, und dies bei geringem Overhead. Sie muss die Kompetenzlücke schließen und beim Sammeln des wesentlichen Kontexts einfach zu handhaben, zu verstehen und zu durchlaufen sein. Mit der Lösung muss jedes Team alle Observability-Daten an einem Ort sehen können und den Kontext erhalten, den es für eine schnelle Deutung und die Einleitung richtiger Maßnahmen benötigt.

1. « Accelerate: State of DevOps 2019 », DORA, September 2019

Während das Monitoring im Allgemeinen mindestens auf den Beginn der Unix-Ära (die erste Ausgabe wurde 1971 veröffentlicht) zurückgeht, wurde der Begriff Application Performance Monitoring (APM) erst in den frühen 2000er-Jahren allgemein verwendet. Seitdem wurde das Monitoring weiterentwickelt, um detaillierte Metriken, Nachverfolgungen und Benachrichtigungen zur Performance und Benutzererfahrung auf dem gesamten Technologie-Stack, einschließlich der Cloud, bereitzustellen.

Angesichts der zunehmenden Komplexität moderner Umgebungen ist die Observability von entscheidender Bedeutung für den zukünftigen Erfolg von Softwareteams und ihren Organisationen. Auf diese Weise können Teams eine zusammenhängende Ansicht aller ihrer Leistungsdaten in Echtzeit an einem Ort anzeigen. Sie können Probleme schneller erkennen, die Ursachen des Problems verstehen und letztendlich hervorragende Kundenerlebnisse erzielen.

Observability ist kein neues Konzept. Es stammt ursprünglich aus der Ingenieur- und Steuerungstheorie und wurde vom ungarisch-amerikanischen Ingenieur Rudolf E. Kálmán für lineare dynamische Systeme eingeführt. Eine anerkannte Definition der Observability in der Ingenieur- und Steuerungstheorie ist ein Maß dafür, wie gut interne Zustände eines Systems aus der Kenntnis seiner externen Ergebnisse abgeleitet werden können.

Im Software-Lebenszyklus umfasst Observability die Erfassung, Visualisierung und Analyse von Metriken, Events, Protokollen und Traces, um ein ganzheitliches Verständnis der Funktionsweise eines Systems zu erhalten. Mit Observability können Sie verstehen, warum etwas nicht stimmt. Das Monitoring sagt ihnen lediglich, dass etwas nicht stimmt.

Yuri Shkuro, Autor und Software-Ingenieur bei Uber Technologies, erklärt den Unterschied folgendermaßen: Beim Monitoring geht es darum, zu messen, was Sie im Voraus entscheiden, und bei der Observability geht es um die Fähigkeit, Fragen zu stellen, die Sie nicht im Voraus über Ihr System wissen.

Wie bereits erwähnt sind wir bei New Relic der Ansicht, dass Metriken, Events, Protokolle und Traces die wesentlichen Datentypen für die Observability sind und dass Events ein kritischer (und häufig übersehener) Telemetrietyp sind, der Teil jeder Observability-Lösung sein muss – darauf gehen wir in Kürze noch weiter ein. Wenn wir letztendlich alles instrumentieren und diese Telemetriedaten verwenden, um ein grundlegendes, funktionierendes Wissen über die Beziehungen und Abhängigkeiten in unserem System sowie über deren Leistung und Zustand zu erhalten, ist das Observability in der Praxis. Bei New Relic ist unser Ansatz jedoch noch differenzierter, da wir an drei Kernkomponenten der Observability glauben.

Bisher haben wir Observability als die Praxis der Instrumentierung von Systemen zur Erfassung verwertbarer Daten definiert. Diese liefern nicht nur das wann eines Fehlers oder Problems, sondern auch das warum. Die Fähigkeit, das warum zu beantworten, ist für Teams der Weg, Probleme wirklich an der Wurzel lösen zu können und so die Systemzuverlässigkeit sicherzustellen. Um die Observability Ihrer Systeme zu erreichen, benötigen Sie unserer Ansicht nach drei Kernelemente:

1. Open Instrumentation: Open Instrumentation ist die Erfassung von Open Source- oder herstellerspezifischen Telemetriedaten aus einer Anwendung, einem Dienst, einem Infrastruktur-Host, einem Container, einem Cloud-Dienst, einer serverlosen Funktion, einer mobilen Anwendung oder einer anderen Einheit, die Daten sendet. Es bietet Einblick in die gesamte Oberfläche geschäftskritischer Anwendungen und Infrastrukturen.
2. Verbundene Entitäten: Alle Telemetriedaten müssen analysiert werden, damit die produzierenden Entitäten identifiziert und verbunden werden können. Außerdem müssen Metadaten einbezogen werden, um eine Korrelation zwischen den Entitäten und ihren Daten herzustellen. Diese beiden Aktionen erzeugen Kontext und Bedeutung aus großen Datenmengen. In diesem Kontext kann die Kuratierung als visuelles Modell des Systems oder der Technologie ohne zusätzliche Konfiguration bereitgestellt werden. Der letzte Vorteil verbundener Einheiten ist, dass Intelligenz angewendet werden kann, um noch mehr Bedeutung abzuleiten. Angewandte Intelligenz ist die Anwendung von maschinellem Lernen und Datenwissenschaft, um nach Mustern oder Anomalien in Daten zu suchen, damit Menschen Entscheidungen treffen und Maßnahmen ergreifen können.
3. Programmierbarkeit: Jedes Unternehmen ist einzigartig, und keine automatische Kuratierung kann alle unterschiedlichen Anforderungen eines Unternehmens erfüllen oder für alle Anwendungsfälle geeignet sein. Unternehmen benötigen eine Möglichkeit, ihren eigenen Kontext und ihre eigene Sammlung auf der Grundlage aller Telemetriedaten zu erstellen und wichtige Geschäftsdaten und -dimensionen zu mischen. New Relic ist einzigartig im Bereich der Observability, da es die Bedeutung dieses Bedarfs erkennt und Kunden ermöglicht, Anwendungen auf der Grundlage all dieser Telemetriedaten zu erstellen. Ein Beispiel: Sie haben die Möglichkeit, die Kosten für Fehler und Ausfälle in einem Geschäftsprozess klar darzustellen, diesen Ausfällen einen Gesamtbetrag zuzuweisen und einen Drill-in-Pfad für die Daten bereitzustellen, um den Grund dafür zu finden.

Mehr über die Entwicklung von Observability zur Unterstützung moderner Software erfahren Sie in den 10 Prinzipien der Observability: Wegweiser auf dem Weg zum Erfolg mit moderner Software.

Als New Relic im Jahr 2008 begann, war die beste Möglichkeit zur Sammlung von Telemetrie für die Observability die Verwendung von Agenten. Softwareentwickler und Betriebsteams setzten Agenten in ihren Anwendungen und Hosts ein. Diese Agenten sammelten Metriken, Events, Traces und Log-Daten, packten sie auf proprietäre Weise und sendeten sie zur Aggregation und Anzeige.

Während dies auch heute noch ein effektiver Weg für das Sammeln von Telemetrie ist, hat sich die Branche verändert. Heute gibt es viel mehr Telemetriequellen. Viele offene Systeme und Frameworks für die Softwareentwicklung verfügen über integrierte Metriken, Events, Protokolle und Traces, die sie in gemeinsamen Formaten ausgeben. Für die Observability müssen Sie Daten sowohl aus offenen als auch aus proprietären Quellen sammeln und an einem Ort kombinieren. Sie müssen die Instrumentierung automatisch dort anwenden, wo es Sinn macht, und dort Instrumentierungen hinzufügen, wo Sie am meisten Sichtbarkeit benötigen.

In den meisten Fällen sind Metriken der Ausgangspunkt für die Observability. Sie lassen sich mit geringem Aufwand sammeln, sind kostengünstig zu lagern, für eine schnelle Analyse dimensioniert und eignen sich hervorragend zum Messen des Gesamtzustands. Aus diesem Grund wurden viele Tools für die Metrikerfassung entwickelt, wie etwa Prometheus, Telegraf, StatsD, DropWizard und Micrometer. Viele Unternehmen haben sogar ihre eigenen proprietären Formate für die Erfassung von Metriken auf der Basis von zeitreihenfreundlichen Datenspeichern wie Elasticsearch erstellt. Eine Observability-Lösung muss in der Lage sein, Messdaten aus einer dieser Quellen zu verwenden, die verschiedene Teams in modernen digitalen Unternehmen übernommen haben.

Traces sind hilfreich, um die durchgehende Latenz einzelner Anrufe in einer verteilten Architektur anzuzeigen. Diese Anrufe geben einen konkreten Einblick in die unzähligen Kundenreisen durch ein System. Mithilfe von Traces können Ingenieure diese Fahrten nachvollziehen, Bottlenecks finden und Fehler identifizieren, beheben und optimieren. Ähnlich wie bei Metriken sind viele Tools (u. a. Jaeger, Zipkin und AWS X-ray) aus benutzerdefinierten Lösungen hervorgegangen, die von anspruchsvollen Organisationen erstellt wurden.

W3C-Trace-Kontext wird bald zum Standard für die Weitergabe des Trace-Kontexts über Prozessgrenzen hinweg. Der Ablaufverfolgungskontext bietet eine Standardmethode zum Verfolgen des Datenflusses durch ein System und zum Verfolgen von ausgehenden Anrufen (übergeordnete Bereiche und deren untergeordnete Bereiche) über komplexe verteilte Systeme hinweg. Wenn Entwickler einen Standard für ihren Trace-Kontext verwenden, können Bereiche aus vielen verschiedenen Systemen für die Anzeige und Suche in einer Observability-Plattform zuverlässig wieder zusammengefügt werden. Der Trace-Kontext enthält auch wichtige Tags und andere Metadaten, die die Suche und Korrelation verbessern.

Als Teil der Cloud Native Computing Foundation (CNCF) führt das OpenTelemetry-Projekt Metrik- und Traceerfassung in einem offenen Format zusammen. Da immer mehr Unternehmen OpenTelemetry einsetzen, erwarten wir mehr standardmäßige und allgemein integrierte Instrumente, die die Notwendigkeit verringern, Agenten für die Bytecode-Instrumentierung zur Laufzeit auszuführen. Aufgrund der Vielzahl von Tools wie Kubernetes und Istio in der CNCF und ihrer schnellen Verbreitung wird OpenTelemetry in der modernen Software als Quelle für Telemetrie allgegenwärtig.

Protokolle sind wichtig, wenn sich ein Techniker im Debugging-Modus befindet und versucht, ein Problem zu verstehen. Protokolle bieten High-Fidelity-Daten und einen detaillierten Kontext zu einem Event, sodass Ingenieure Millisekunden für Millisekunde nachvollziehen können, was passiert ist. Wie bei Metriken und Traces haben sich Tools herausgebildet, um den Aufwand für das Sammeln, Filtern und Exportieren von Protokollen zu verringern. Zu den gebräuchlichen Lösungen gehören Fluentd, Fluent Bit, Logstash und AWS CloudWatch sowie viele andere neu entstehende Standards.

All diese Projekte für Metriken, Protokolle und Traces sind auf eine Zukunft ausgerichtet, in der die Instrumentierung durch diesen Ansatz mit eingeschlossenen Batterien für alle einfacher wird.

Events sind ein kritischer (und häufig übersehener) Telemetrietyp, der Teil einer Observability-Lösung sein muss. Obwohl Events und Protokolle einige Gemeinsamkeiten aufweisen, werden die beiden jedoch häufig fälschlicherweise zusammengefasst. Events sind diskrete, detaillierte Aufzeichnungen wichtiger Analysepunkte. Sie enthalten jedoch eine höhere Abstraktionsebene als die von Protokollen bereitgestellte Detailebene. Protokolle sind umfassend und diskrete Aufzeichnungen von allem, was in einem System passiert. Events sind Aufzeichnungen von ausgewählten signifikanten Dingen, die mit an die Aufzeichnung angehängten Metadaten geschehen sind, um ihren Kontext zu schärfen. Wenn New Relic beispielsweise Transaktionsevents sammelt – einzelne Instanzen der Ausführung einer Methode oder eines Codeblocks in einem Prozess –, werden automatisch Daten hinzugefügt, um die Anzahl der ausgeführten Datenbankaufrufe und die Dauer dieser Aufrufe anzuzeigen.

Telemetriedaten von praktisch überall an einen Ort zu bringen, ist ein guter Anfang, aber nicht genug. Ihre Daten müssen so verbunden sein, dass Sie die Beziehungen zwischen Entitäten nachvollziehen können. Und sie müssen mit Metadaten korreliert sein, damit Sie die Beziehung zu Ihrem Unternehmen nachvollziehen können. Solche Verbindungen geben Ihren Daten Kontext und Bedeutung. Der Kontext führt beispielsweise zu kuratierten Ansichten, in denen die wichtigsten Informationen zu Ihren Daten angezeigt werden und deren spezifische Umgebung modelliert wird. Wenn alle Ihre Telemetriedaten und -verbindungen an einem Ort gespeichert sind, können Sie Informationen auf sehr große Datenmengen sowie Oberflächenmuster, Anomalien und Korrelationen anwenden, die von Menschen, die Dashboards beobachten, nicht leicht zu erkennen sind.

Im Wesentlichen benötigen Sie eine Möglichkeit, um zu sehen, wie alle Entitäten in Ihrem System zu einem beliebigen Zeitpunkt miteinander verknüpft sind. Es ist einfach nicht machbar, eine mentale Karte Ihres Systems zu führen, wenn es sich jederzeit ändert. Es ist auch nicht möglich, sich auf die Konfiguration zu verlassen, um diese Beziehungen zu verwalten. Wenn Teams neue Dienste hinzufügen, alte überarbeiten und kurzlebige Anwendungsinstanzen hoch- und runterfahren, ist es unmöglich, eine mentale Zuordnung zu pflegen. Entitäten, ihre Verbindungen und Beziehungen sind jedoch ein Teil des wesentlichen Kontexts für die Observability.

Ohne Metadaten und Dimensionen ist Kontext nicht möglich. Abhängig von Ihrem System, Ihrem Unternehmen oder Ihrer Anwendung ist das Spektrum an wertvollen Daten möglicherweise enorm. Im Fall einer E-Commerce-Anwendung umfasst der hilfreiche Kontext beispielsweise Folgendes, ist jedoch nicht darauf beschränkt:

• Details zu dem Team, dem die Anwendung, das Runbook und das Code-Repository gehören
• Tags von Docker oder dem Cloud-Anbieter, bei dem es bereitgestellt wird
• Art und Funktion des Services
• Die Regionen, in denen es bereitgestellt wurde
• Seine vor- und nachgelagerten Abhängigkeiten
• Die Bereitstellung oder Änderung von Events
• Der Alertstatus
• Alle Trace- oder Protokolldaten, die mit den durchgeführten Transaktionen verknüpft sind
• Zusätzliche Geschäftsdaten (z. B. Warenkorbwert)

Das Kuratieren von Datenvisualisierungen ist ein leistungsstarkes Werkzeug, um zusammenhängende, gut verstandene und gut definierte Entitäten sichtbar zu machen. Wir wissen bereits, wie ein Java-Anwendungsprozess, der in einem Container ausgeführt wird, oder eine AWS Lambda-Funktion, die DynamoDB nach einem Aufruf von SQS aufruft, oder ein Kubernetes-Cluster, auf dem eine dynamische Bereitstellung ausgeführt wird, am besten dargestellt werden können. Wir haben diese Probleme gelöst. Für einen vielbeschäftigten SRE- oder DevOps-Ingenieur ist die Modellierung dieser Umgebungen in einer Reihe von Dashboards eine Verschwendung wertvoller Zeit. Eine Observability-Plattform muss die Best Practices von Branchenführern einbeziehen und die wichtigsten Gesundheitssignale aufzeigen sowie interaktive Erfahrungen bieten, mit denen Ingenieure Probleme schnell beheben können. Das manuelle Erstellen von Visualisierungen und Dashboards für spezifische und allgegenwärtige Technologien ist schlichtweg mühselig.

Das Kuratieren durch den Kontext hilft auch bei der Bewältigung der Qualifikationslücke in einem komplexen digitalen Unternehmen. Damit kann jeder in der Organisation die Abläufe und Abhängigkeiten in seinen komplexen Systemen visualisieren und alles einsehen, was für die gesamte Umgebung relevant ist. Da dieses Kuratieren eine Vielzahl von Systemen gut modelliert, wird das Verständnis für die Menschen zugänglicher, auch wenn sie mit einer bestimmten Technologie oder einem Code nicht vertraut sind.

Observability ist praktisch nutzlos, wenn Sie bei Systemfehlern nicht schnell Maßnahmen ergreifen können. Durch maschinelles Lernen und prädiktive Analysen werden Beobachtbarkeitsdaten von der angewandten Intelligenz erfasst und aussagekräftig und umsetzbar gemacht. Gelegentlich als künstliche Intelligenz für den IT-Betrieb oder als AIOps vom Branchenanalysten Gartner bezeichnet, wird angewandte Intelligenz im Chaos fündig, sodass Sie die richtigen Maßnahmen ergreifen können. 

Angewandte Intelligenz liefert klare Richtlinien, auch bei großen und komplexen Datenmengen. Maschinen sind sehr gut darin, Muster, Trends und Fehler in Daten auf einer Skala zu identifizieren, die Menschen nicht einfach replizieren können. Die richtigen Intelligenzfunktionen erkennen Probleme so früh wie möglich anhand von Telemetriedaten und korrelieren und priorisieren Events, um Rauschen und Alert-Verdruss zu reduzieren. Angewandte Intelligenz kann Incident-Alerts automatisch mit relevanten Kontexten, Anleitungen und Vorschlägen anreichern. Dazu gehören auch Empfehlungen, mit denen Sie die wahre Ursache eines Problems und dessen Behebung schnell lokalisieren können.

Im Folgenden finden Sie ein Beispiel für angewandte Intelligenz in Aktion: Ihr Team erhält einen Alert über eine Verletzung des Antwortzeit-Schwellenwerts für eine Anwendung. Intelligence hat den Throughput, Latenzfehler und Transaktionssignale im Zusammenhang mit der Anwendung in den sechs Stunden vor dem Alert automatisch überprüft. In diesem Szenario erkennt Intelligence die Latenz im Datastore, auf den sich die Anwendung stützt, und zeigt eine direkte Verbindung zwischen dem Datenbankproblem und der langsamen Antwortzeit der Anwendung an. Hier gibt es zwei Vorteile:

1. Die angewandte Intelligenz hat bereits wichtige Fehlerbehebungsanalysen durchgeführt und die durchschnittliche Zeit bis zur Entdeckung (MTTD) verkürzt. So kann Ihr Team das zugrunde liegende Problem schneller lösen und die durchschnittliche Zeit bis zur Lösung (MTTR) reduzieren.
2. Die angewandte Intelligenz wird beim Trainieren mit mehr Daten nützlicher. Störungen durch geringfügige oder falsche Alarme können herausgefiltert werden. Dies verhilft Ihrem Team zu vermindertem Alert-Verdruss und einem schnelleren Versand besserer Software.

Wenn Sie Abhängigkeiten visualisieren und in Echtzeit einen Drilldown für verschiedene Telemetrietypen durchführen können, können Sie Systemprobleme schneller und einfacher verstehen und Probleme beheben, um den Grund für das „Warum“ der Daten zu ermitteln. Wenn diese die technische Umgebung automatisch effektiv modellieren, erleichtern kuratierte Visualisierungen jedem das Auffinden von Ursachen. Durch das Anwenden von Intelligenz auf große Datensätze werden Verbindungen in den Daten sichtbar. So können die Mitarbeiter das tun, wozu sie am besten in der Lage sind: differenzierte Entscheidungen treffen, was in einer schwierigen Situation zu tun ist.

Das Verbinden von Observability-Daten mit Geschäftsergebnissen ist ein entscheidender Schritt, den Unternehmen gehen müssen, um ein ausgereiftes digitales Unternehmen zu werden. Beginnen Sie mit kritischen Geschäftsmessgrößen für den Erfolg und identifizieren Sie dann die Key Performance Indicators (KPIs), die für diese Metriken direkt zum Erfolg beitragen. Metriken wie Latenz, Fehler oder Seitenladevorgänge sind naheliegende Kriterien, um die Anwendungsleistung zu verstehen. Sie sind jedoch nicht so hilfreich, um die Auswirkungen einer Anwendung auf das Kundenerlebnis und die Geschäfts-KPIs zu verstehen.

Aus diesem Grund ist es wichtig, die Observability wieder mit dem Unternehmen zu verknüpfen und den Teams die nötige Einsicht zu geben, um datenbasierte Entscheidungen zu treffen. Die Frage ist, wie? 

Bei den meisten Lösungen lautete die Antwort, KPIs in Dashboards zu visualisieren. Dashboards sind ein großartiges Tool zum schnellen Anzeigen von Ad-hoc-Ansichten von Daten. Sie sind flexible leistungsstarke Tools, die für jede Observability-Lösung von grundlegender Bedeutung sind. Angesichts der besonderen Technologieumgebung und der einzigartigen KPIs Ihres Unternehmens ist es jedoch wichtiger denn je, über das Dashboard hinauszugehen. Es sollten Anwendungen entwickelt werden, die Daten über Ihr digitales Geschäft liefern und diese mit Ihren Telemetriedaten kombinieren. Durch die Verbindung von Geschäftsdaten über Ihre Observability-Plattform liefert eine Anwendung eine kuratierte interaktive Erfahrung. Häufig sind darin Workflows direkt integriert, und externe Datensätze können in Echtzeit kombiniert werden. Dashboards können das nicht – Anwendungen dagegen schon.

Um Geschäfts- und Telemetriedaten in Anwendungen zu verbinden, muss Ihre Observability-Lösung eine Plattform sein, auf die Sie aufbauen können. Sie muss programmierbar sein.

Wenn Sie über eine Observability-Plattform verfügen, auf der Sie maßgeschneiderte Anwendungen erstellen können, können Sie mit einem Observability-Tool Dinge tun, die bisher nicht möglich waren.

• Priorisieren Sie Investitionen in Software und messen Sie deren Effektivität in Echtzeit.
• Verstehen Sie die Beziehungen zwischen Ihrer Technologie, Ihrem Unternehmen und Ihren Kunden besser als je zuvor.
• Treffen Sie datenbasierte Entscheidungen, die die größten direkten Auswirkungen auf bestimmte KPIs haben.
• Teilen Sie Ihr Verständnis durch interaktive Visualisierungen, die Ihr einzigartiges Unternehmen modellieren, nicht nur Ihre Technologieumgebung.

Über eine programmierbare Observability-Plattform können Teams schließlich Anwendungen erstellen, die in einem einzigen Aufzeichnungssystem enthalten sind, ohne ein anderes Tool bereitstellen zu müssen. Dies bietet eine Reihe von Vorteilen: Es reduziert den Kontextwechsel zwischen Tools im Notfall. Es reduziert den Zeit- und Arbeitsaufwand für die Bereitstellung, den Betrieb, die Wartung und das Monitoring eines anderen Systems. Und es reduziert die Kosten für den Kauf, den Bau oder das Erlernen eines weiteren Tools.

Mit der fortschreitenden Softwareinnovation wird sich die Welt weiter beschleunigen und komplexer werden. So wie die neuesten Technologien und Technologietrends noch vor wenigen Jahren nicht vorhersehbar waren, wissen wir nicht, was die nächsten großen Errungenschaften sein werden. Aber wir wissen, dass diese kontinuierliche Innovation und Komplexität die Erwartungen an Ihre Teams, schneller voranzukommen, mehr Technologien zu nutzen und blitzschnell und ohne Fehler zu liefern, immer weiter in die Höhe treibt. Sie müssen außerdem mehr automatisieren und mit den Kundenerwartungen Schritt halten, die von anderen Unternehmen – einschließlich Ihrer Konkurrenten – gestellt werden, um ein topaktuelles Kundenerlebnis zu erzielen.

Angesichts dieser Herausforderungen benötigen Sie eine einzige Observability-Plattform, die die Komplexität und das Risiko reduziert, und dies bei geringem Overhead. Sie benötigen eine Plattform, die die Kompetenzlücke schließt, indem sie einfach zu bedienen, zu verstehen und zu durchlaufen ist. Sie darf für kein Team innerhalb einer Organisation zum Stolperstein werden. Sie benötigen eine Plattform, mit der Ihre Teams alle ihre Telemetrie- und Geschäftsdaten an einem Ort sehen und den benötigten Kontext erhalten. So können sie rasch die Bedeutung der Daten ableiten und die richtigen Maßnahmen ergreifen, und für Sie und Ihr Geschäft Mehrwert erarbeiten.

Eine Observability-Plattform sollte Folgendes bieten:

• An einem Ort Telemetriedaten aus offenen und proprietären Quellen sammeln und kombinieren. Diese offene Instrumentierung reduziert die Verbreitung von Tools und den Kontextwechsel bei Problemen und Notfällen, da sie die Interoperabilität aller Daten unabhängig von der Quelle gewährleistet.
• Verbindungen und Beziehungen zwischen Entitäten bilden und diese Verbindungen anwenden, um Kontext und Bedeutung zu erstellen, damit Sie die Daten verstehen können. Der Kontext sollte in kuratierten Ansichten dargestellt werden, die die wichtigsten Informationen enthalten.
• Ihnen die Möglichkeit bieten, noch dazu benutzerdefinierte Anwendungen zu erstellen. Im Gegensatz zu Dashboards bieten Anwendungen interaktive kuratierte Erlebnisse. Sie verfügen häufig über integrierte Workflows. Und sie ermöglichen die Kombination externer Datensätze in Echtzeit. Programmierbarkeit definiert die Möglichkeiten der Observability neu.

Wenn Sie über eine offene, vernetzte und programmierbare Observability-Plattform verfügen, hat Ihr Unternehmen große Vorteile: schnellere Innovation, schnelleres Deployment, weniger Aufwand, geringere Kosten und ein besseres Verständnis für die Priorisierung Ihrer begrenzten Zeit und Aufmerksamkeit. All dies führt zu einem viel tieferen gemeinsamen Verständnis Ihrer Daten, Ihrer Systeme und Ihrer Kunden. Und das wiederum verbessert Ihre Unternehmenskultur und führt zu Unternehmenswachstum – Sie erhalten in Echtzeit einen Überblick über die Leistung Ihrer digitalen Systeme und die Interaktion Ihrer Kunden mit Ihrer Software. So können Sie sich auf das Wichtigste konzentrieren – die Geschäftsergebnisse, die von Ihnen täglich erwartet werden.