Cloud
Dies ist der erste Teil eines zweiteiligen Blogs. Im nächsten Blogpost werden wir beschreiben, wie wir die Beobachtbarkeit und das Monitoring bei Public Cloud Managed Services für unsere Kunden als Teil unseres Leistungsangebots verwalten.
Unsere Kunden sind mehr und mehr auf verteilte Architekturen angewiesen, um Dienstleistungen zu nutzen. Die Infrastruktur und die Fernmeldewesen-Anwendungen werden immer breiter gefächert, je nachdem, wo sie gehostet werden und wie sie kommunizieren. Dies hat sich in den letzten Jahren durch die großen Fortschritte bei der Einführung von Clouds noch verstärkt. Auf der einen Seite wählen die Kunden den Standort und die Kategorie ihrer Betriebsmittel nach Preisen, Dienstmerkmalen und Compliance-Anforderungen innerhalb desselben Public Cloud-Anbieters aus; auf der anderen Seite wenden sie sich Multi-Cloud- oder Hybrid-Cloud-Architekturen zu, um ihre digitale Transformation voranzutreiben, ihre Agilität zu verbessern, von CapEx auf OpEx zu wechseln usw.
Diese Trends haben zu Fortschritten bei der Beobachtbarkeit und dem Monitoring geführt. Aber was genau ist Monitoring und was ist Observability? Ja, sie sind sehr unterschiedlich, und es ärgert mich, wenn ich höre oder lese, dass Monitoring durch Beobachtbarkeit ersetzt wird; das ist nicht der Fall, denn Beobachtbarkeit verbessert und verstärkt Monitoring. Lasst mich das ein wenig erklären.
Eine der besten Erklärungen über Monitoring und Beobachtbarkeit, die ich gelesen habe, stammt von Morgan Willis, einem Senior Cloud Technologist bei AWS.
"Monitoring ist das Sammeln von Daten. Welche Art von Daten wir sammeln, was wir mit den Daten machen und ob diese Daten leicht zu analysieren oder verfügbar sind, ist eine andere Story. Hier kommt die Beobachtbarkeit ins Spiel. Beobachtbarkeit ist kein Verb, es ist nicht etwas, das man tut. Stattdessen ist Beobachtbarkeit eher eine Eigenschaft eines Systems."
Nach dieser Erklärung können Tools wie CloudWatch, Azure Monitor, X-Ray und App Insights als Monitoring- oder Tracing-Tools eingestuft werden. Sie ermöglichen es uns, Inkasso von Forderungen und Metriken über unser System zu sammeln und Warnungen über Fehler und Vorfälle zu senden. Das Monitoring ist also ein aktiver Teil der Datensammlung, der uns hilft, das Inkasso von Forderungen und das Zusammenspiel der verschiedenen Komponenten unseres Systems zu beurteilen. Sobald wir ein Monitoring eingerichtet haben, das kontinuierlich das Inkasso von Forderungen, Systemausgaben, Metriken und Traces übernimmt, wird unser System beobachtbar.
Mein Verständnis davon, was Monitoring bedeutet, hat sich im Laufe meiner beruflichen Laufbahn ständig weiterentwickelt; derzeit betrachte ich Monitoring als den Dateneingangsteil von ETL (extract, transform, load). Das heißt, du sammelst Daten aus verschiedenen Quellen (Logs, Traces, Metriken) und speicherst sie in einem Datenspeicher. Sobald all diese Daten verfügbar sind, kann ein erfahrener Analytiker daraus Erkenntnisse gewinnen und schöne Dashboards erstellen, die eine Story erzählen, die diese Daten vermitteln. Das ist der Teil der Beobachtbarkeit - die Gewinnung von Erkenntnissen aus den gesammelten Daten. Plattformen wie Elasticsearch Kibana spielen die Rolle eines erfahrenen Analysten. Sie liefern dir Visualisierungen und Einblicke in den Zustand deines Systems.
Die Beobachtbarkeit, die aus der Kontrolltheorie stammt, misst, wie gut man die internen Zustände eines Systems anhand seiner externen Ausgaben verstehen kann. Die Beobachtungsfähigkeit nutzt Instrumente, um
Das ist Telemetrie, nicht Beobachtbarkeit.
Erkenntnisse zu liefern, die das Monitoring unterstützen. Mit anderen Worten: Monitoring ist das, was du tust, nachdem ein System beobachtbar ist. Ohne ein gewisses Maß an Beobachtbarkeit ist ein Monitoring nicht möglich.
Das ist Telemetrie, nicht Beobachtbarkeit.
Sehr oft beobachte ich die Tendenz, Beobachtbarkeit mit Telemetrie zu verwechseln. Oder zumindest mit lose integrierten Benutzeroberflächen, die auf Telemetrie-Silos aufgebaut sind, wie im obigen Diagramm dargestellt. In dieser Formulierung wird die Beobachtbarkeit mit der bloßen Koexistenz eines Metrik-Tools, eines Logging-Tools und eines Tracing-Tools erklärt.
Kurz gesagt: Verwechsle die Koexistenz von Metriken, Tracing/APM und Logging nicht mit "Observability".
Wie bei den meisten schlechten Ideen, die sich durchsetzen, ist auch hier ein Körnchen Wahrheit dabei: insbesondere, dass Traces, Metriken und Logs einen Platz in der Lösung haben. Aber sie sind nicht das Produkt; sie sind nur die Rohdaten. Die Telemetrie.
Die Anatomie der Beobachtbarkeit.
Die erste Ebene ist die Telemetrie; ohne die Telemetrie-Rohdaten gibt es keine Beobachtbarkeit. Je nach Infrastruktur und Einsatzbereitschaft gibt es viele Optionen für Tools zur Erfassung der Telemetrie-Rohdaten. Das Hauptaugenmerk auf der ersten Ebene sollte immer darauf liegen, Zugang zu qualitativ hochwertigen Telemetriedaten zu erhalten.
Die zweite Ebene ist der Storage: nicht nur, wie wir sie speichern, sondern auch, wie lange. Wenn es um die Speicherung von Daten für die Beobachtung geht, kann es schwierig sein, den richtigen Bestand zu finden. Grundsätzlich gilt: Wenn wir Daten mit hohem Download-Durchsatz effizient handhaben wollen (z. B. Rechnungsstellung für 100 % aller Mitteilungen in einer skalierten App oder sogar Messresultate mit hoher Genauigkeit wie CPU-Last oder Speicherverbrauch pro Container), müssen wir Statistiken in eine Normenreihe aufnehmen. Andernfalls verschwenden wir zu viel Zeit mit dem Überspielen und dem Storage von einzelnen Ereignissen. Und auch wenn manche meinen, dass man die Ereignisse abtasten kann, kann man bei Daten mit niedriger Frequenz, die in der Hochfrequenz versteckt sind, völlig daneben liegen. In dieser Situation ist eine spezielle Zeitreihen-DB (TSDB) gefragt: ein Datenspeicher, der speziell für die Speicherung, Indizierung und Abfrage von Normenreihen wie diesen entwickelt wurde.
Und doch! Wenn wir Daten mit hoher Kardinalität (z. B. Tags pro Kunde, eindeutige IDs für ephemere Infrastrukturen oder URL-Fragmente) verarbeiten wollen, ist eine TSDB eine absolute Katastrophe. Mit der Explosion der Tag-Kardinalität kommt eine Explosion der Normenreihen und damit eine Explosion der Kosten. Daher muss es auch eine Transaktions-DB geben; traditionell war dies eine Logging-Datenbank, obwohl es klüger ist, auf einer Transaktions-DB mit verteilter Rückverfolgung aufzubauen (mehr dazu später), die zwei Fliegen mit einer Klappe schlagen kann (Logs und Traces).
Eine Transaktions- und Normenreihe auf dem neuesten Stand der Technik zu haben, ist zwar notwendig, aber nicht ausreichend. Um die eigentliche "Beobachtbarkeit" nahtlos zu gestalten, muss auch die Datenschicht integriert und mit Querverweisen versehen werden, am besten mit einer tiefen Integration.
Die oben genannten Herausforderungen können die Beobachtbarkeit manchmal erschweren, und manchmal kann sie sich schwer fassbar anfühlen. Dies bringt uns zur dritten Ebene, den eigentlichen Leistungen, die im Bereich der Geschäftsführung einfach als Geschäftsergebnisse bezeichnet werden und einen wesentlichen Teil des Wertversprechens ausmachen, wenn wir unseren Kunden Beobachtbarkeit und Monitoring verkaufen.
Telemetrie, ob in Bewegung oder im Ruhezustand, ist nicht an sich wertvoll. Nur die darauf aufbauenden Workflows und Anwendungen können wertvoll sein. Bei der herkömmlichen Darstellung von "Beobachtbarkeit als Metriken, Logs und Traces" wissen wir jedoch nicht einmal, welches Problem wir lösen! Und schon gar nicht, wie wir es lösen.
Wenn es um moderne, verteilte Softwareanwendungen geht, gibt es zwei übergreifende Probleme, die es wert sind, mit Observability gelöst zu werden:
Monitoring und Beobachtbarkeit gehen also Hand in Hand, das eine ersetzt das andere nicht, sondern ermöglicht und verbessert gemeinsam definierte Geschäftsergebnisse.
Weitere Informationen findest du unter Swisscom Public Cloud Services. Du kannst dich auch an unsere Experten wenden, die dir helfen, deine cloudbasierten Lösungen auf den Weg zu bringen.
Dies ist der erste Teil eines zweiteiligen Blogs. Im nächsten Blogbeitrag werden wir beschreiben, wie wir die Beobachtbarkeit und das Monitoring bei Public Cloud Managed Services für unsere Kunden als Teil unseres Leistungsangebots verwalten.
DevOps Engineer
Finde deinen Job oder die Karrierewelt, die zu dir passt. In der du mitgestalten und dich weiterentwickeln willst.
Was du draus machst, ist was uns ausmacht.
