Der Begriff Observability und seine praktische Umsetzung werden aktuell vielfach besprochen. Wir haben deshalb mit Erkan Yanar, Experte für Kubernetes und DevOps, über sein Verständnis des Observability-Mindsets und dessen Anwendung gesprochen.

Torsten Bøgh Köster: Als Freelancer und Trainer bist du wohl die Kubernetes-Koryphäe in Deutschland. Wann bist du erstmals mit dem Thema Observability in Kontakt gekommen?

Erkan Yanar: Das erste Mal mit so etwas wie Observability in Berührung gekommen bin ich Anfang der 2000er als MySQL-DBA. Wir haben versucht, Metriken und Logs einen Sinn zu geben. Mit dem jetzt neu aufkommenden Begriff der Observability habe ich daher so ein Problem, denn wir haben das schon lange gemacht.

Köster: Ist Observability nur alter Wein in neuen Schläuchen?

Yanar: Was jetzt neu ist, ist die Masse an Metriken und Logs. Zudem ist der Ansatz ein holistischer, der Fokus liegt auf der Korrelation von Logs, Metriken und Traces. Grafana und Elastic schreiten da voran, in deren Lösungen gehst du weg von Einzel-Events hin zu einer ganzheitlichen Betrachtung des Systems – eben durch Korrelation von Logs, Metriken und Traces. Die Daten sind die gleichen, aber ich kann sie besser interpretieren.

Köster: Die reine Lehre der Observability legt großen Wert auf das Vorhandensein von Rohdaten. Aggregationen sollen bei Bedarf gebildet werden und nicht die Datenbasis sein.

Yanar: Das Problem kenne ich schon seit PHP4Nagios. Dort werden vorher die Aggregationen definiert, die ich speichern möchte (Durchsatz, Antwortzeiten). Für die tiefergehende Analyse fehlen mir dann aber die Rohdaten. Und Rohdaten sind wichtig, denn ich muss in der Lage sein, diese aus den verschiedensten Systemen zu korrelieren. Den Rohdaten kann man unterschiedlichen Sinn geben. Der Klassiker war (und ist) die Aussage: „Die Datenbank ist langsam“. In einem Fall habe ich dann die Antwortzeit der Datenbank mit dem Netzwerkdurchsatz korreliert, und siehe da: Man kommt man zu einem ganz anderen Ergebnis. Das Netzwerk ist saturiert. Hätte ich als DBA nur auf die Metriken der Datenbank geschaut, hätte ich dieses Problem nicht lösen können. Ich sehe Observability als holistische oder ganzheitliche Fortführung dieses Gedankens. Das klingt jetzt ein wenig esoterisch …

Köster: Aber Observability hat ja auch etwas Esoterisches. Es ist analog zu DevOps ein Mindset. Konstantin Diener hat es als Asymptote beschrieben, der man sich versucht anzunähern – diese aber gar nicht erreichen kann. Mit jeder Änderung in deiner Anwendung oder deiner Infrastruktur verschiebt sich das Ziel. Wie mache ich denn Observability?

Yanar: Kann man das denn machen? Wenn Observability Daten einen Sinn gibt, muss ich ja zwei Dinge klären: Wie bekomme ich hinreichend Daten und wie gebe ich denen einen Sinn? Ich würde Observability jetzt nicht so hochhängen und einfach sagen, sobald man Monitoring ernsthaft betreibt, macht man schon Observability. Und damit meine ich jetzt kein reines Verfügbarkeitsmonitoring. Andersherum sagt mir zum Beispiel der Wasserstand der Elbe nichts, solange ich dieser Zahl keine Bedeutung gebe.

Köster: Ich wohne zwar in Hamburg, mir sagen die Hochwasserstände aber auch nichts. Was mich interessiert ist, ob ich etwas tun sollte (anschauen, Freunde warnen etc.) Würde diese Ableitung dem Hochwasserstand einen Sinn geben?

Yanar: Die reine Zahl von 2 Metern über Normalnull sagt dir nichts. Wenn du aber weißt, dass der Deich 9,25 Meter über Normalnull liegt, brauchst du dir erst einmal keine Sorgen machen. Was du aus den Rohdaten der Wasserstände dann aber auch ableiten kannst, ist die Geschwindigkeit, mit der sich der Wasserstand ändert. Damit kannst du denselben Daten einen vollkommen anderen Sinn geben, nämlich: In 2 Stunden läuft der Deich über. So etwas lässt sich linear aber auch durch AI unterstützt berechnen, wo dann auch historische Daten mit einfließen. Durch solche Werkzeuge bin ich in der Lage, mein System über die Zeit sehr genau kennenzulernen.

Köster: Bei deinen Ausführungen kommen mir direkt Prometheus Rules in den Sinn. Mit denen kann ich zumindest lineare Vorhersagen auch abbilden.

Yanar: Das stimmt schon. Philosophisch betrachtet muss man aber zwischen Rule und Alarm unterscheiden. Der Alarm hat halt mehrere Bedeutungen, denn auf einen Alarm muss ich reagieren. Wo ich aber bei dir bin, das sind die Prometheus Rules. Damit kann ich in der Tat meinen Daten einen Sinn geben. Ich korreliere und aggregiere meine Daten zu einer Aussage. In dem Beispiel von vorhin schreibe ich eine Rule, in der ich Datenbankantwortzeiten und Netzwerkdurchsatz miteinander korreliere. Dann haben wir eine sinnhafte Korrelation, aber verlieren die Rohdaten für andere Analysen nicht.

Köster: Observability heißt eben nicht nur, Unmengen an Daten zu sammeln, sondern ich muss mich mit denen auch beschäftigen. Manchmal ist Haben halt doch nicht besser als Brauchen.

Yanar: Bei einer SaaS-Lösung stimmt das definitiv!

Köster: Neben deinen Kubernetes-Trainings verwaltest du auch Cloud-Infrastrukturen für Kunden. Wie wirkt sich Observability beim Aufbau und im Betrieb einer Cloud-Infrastruktur aus? Baust du Infrastruktur anders, wenn du Observability im Hinterkopf hast?

Yanar: Ich baue jede Infrastruktur, in meinem Fall Kubernetes-Cluster, mit Observability im Hinterkopf. Egal wo, on Premise in AWS oder mit EKS, ich rolle zum Beispiel immer einen Prometheus, Promtail, Loki und ein Grafana mit aus. Damit gebe ich den Anwendungsentwickler:innen ein Werkzeug an die Hand, ihre Metriken und Logs zu verwalten. Für zentrale Clusterdienste nutze ich das natürlich auch.

Köster: Als kleine Exkursion: Loki ist vom Ansatz ja anders als die klassischen Logmanagementtools wie der Elastic Stack oder halt Graylog. Bei Loki setzt man sehr auf Metadaten, wie man sie von Prometheus her kennt, und parst die Daten erst zur Anfragezeit auseinander, was bei den anderen Ansätzen bereits beim Ingest gemacht wird.

Yanar: Das stimmt, Loki ist kein strukturiertes Logging. Und genau das ist der Vorteil, denn Loki bleibt dadurch simpel. Es gibt zwar einen Ingester, aber der ist erst einmal zweitrangig. Aus meiner Erfahrung sind diese großen Elasticsearch-Instanzen oftmals die eigentliche Fehlerquelle in einem Cluster. Das größte Problem ist aber, dass ich Prometheus-Metriken so gut wie gar nicht mit Elasticsearch-Logdaten korrelieren kann. Über Grafana kann ich das mit Prometheus-Metriken und Logs aus Loki aber schon, und das ist ein großer Vorteil. Die Korrelation erfolgt anhand der gespeicherten Metadaten.

Köster: Aus meiner Erfahrung wurde Kibana von vielen Anwendungsentwickler:innen bereits erlernt. Das ist ein Argument, das wiederum für den Elastic-Stack spricht.

Yanar: Der Elastic Stack liegt halt vom Pflegeaufwand und Ressourcenverbrauch weit über dem von Loki. Wenn man den betreibt, kann man sich auch direkt überlegen, eine SaaS-Lösung anzuschaffen.

Köster: Gibt es für das Monitoring von (Cloud-)Infrastruktur einen Observability-Stack, den du empfehlen kannst und/oder auch in der Praxis einsetzt? Wie groß ist der Trade-off zwischen SaaS-Lösungen und Open-Source-Lösungen?

Yanar: Bei SaaS-Lösungen bin ich an die SLAs von Anbietern gebunden und habe keine Möglichkeit, bei Problemen selbst einzugreifen. Vom monetären Aspekt möchte ich gar nicht anfangen. Ich glaube, wenn man sich mit einer solchen Lösung beschäftigt, kann man selbst für einen besseren und stabileren Dienst sorgen. Wahrscheinlich bieten selbstbetriebene Lösungen auf lange Sicht auch eine bessere Wertschöpfung. Zusammengefasst ist es einfach nicht mein Style.

Köster: Bei einer On-Premise-Lösung musst du dich mit deiner Software und deinen Metriken beschäftigen.

Yanar: Eine Open-Source-Lösung unterstützt dich auf deiner Observability-Reise, denn du musst dich mit den Daten beschäftigen. Durch die Nähe zu ihnen wirst du auch das Beste aus ihnen herausholen. Die Lösung, die ich gerne ausrolle, ist wie gesagt Prometheus, Promtail, Loki, Grafana und eine Tracing-Lösung wie Jaeger oder Tempo. Grafana drückt als neue Lösung gerade Tempo in den Markt und nutzt seine Position ein wenig aus.

Köster: Grafana erkennt den Bedarf an Korrelation zwischen den verschiedenen Datentypen. Sonst können das nur SaaS-Anbieter durch ihr geschlossenes System anbieten.

Yanar: Das tun sie für ein Open-Source-System und es funktioniert hervorragend, Logs, Metriken und Traces miteinander zu korrelieren.

Köster: Für das Überwachen von (Cloud-)Infrastruktur gibt es Anleitungen und für viele Tools Exporter, z. B. für Prometheus. Wie ist das bei selbstentwickelten Anwendungen?

Yanar: Wenn wir bei Prometheus-Metriken bleiben, wird es den Anwendungsentwickler:innen ja leicht gemacht. Prometheus läuft in jedem meiner Cluster mit, und in Java können mittels einfacher Annotations Metriken exportiert werden. Alternativ kann das über dedizierte Exporter als Sidecar realisiert werden, aber der Mechanismus des Einsammelns ist derselbe. Die Logs werden dank Promtail mit identischen Metadaten wie die Metriken versehen und eingesammelt, denn Container loggen nur noch nach Standard-out und -Error.

Köster: Ich bin von der Möglichkeit, Prometheus auch außerhalb von Kubernetes, z. B. für diverse Cloud-Umgebungen, zu konfigurieren, extrem angetan. Sogar für die Hetzner Cloud gibt es eine Autodiscovery.

Yanar: In einem Projekt konnte ich sogar AWS CloudWatch durch Prometheus ersetzen, weil sie damit nicht nur ihre Kubernetes-Cluster, sondern auch ihre übrige AWS-Infrastruktur und sogar AWS-Ressourcen selbst überwachen können.

Köster: Hast du eine Observability-Checkliste für den Betrieb selbst entwickelter Anwendungen?

Yanar: Leider nein. Die Checkliste von Zalando [1] ist bis auf Details sehr gut und geht sehr in die Tiefe. Allerdings müssen die Anwendungsentwickler:innen selbst sehen, welche Metriken und welche Inhalte in ihren Logs stehen. Ich stelle die Infrastruktur bereit, aber den jeweiligen Inhalt müssen die Anwendungsentwickler:innen festlegen.Es ist derzeit im Fehlerfall immer noch schwierig zu unterscheiden, wo das Problem liegt. In der Anwendung oder im Kubernetes-Cluster? Deshalb sind oft Systemadmins die ersten in der Eskalationskette. Der Systemadmin eskaliert dann an den Verantwortlichen im Entwickler:innenteam weiter.

Köster: Ist das nicht sogar der Regelfall?

Yanar: Mit Observability können sich die Anwendungsentwickler:innen zwar selbst alarmieren lassen, aber diese Eskalationskette bleibt bestehen, gerade in großen Firmen. Man könnte den Eskalationspfad umdrehen und die Anwendungsentwickler:innen prüfen, ob es ein Anwendungsproblem oder ein Kubernetes-Problem ist, aber eine gezielte Alarmierung wäre ideal.

Startet z. B. eine Anwendung im Kubernetes-Cluster oft neu, können die Ursachen vielfältig sein. Entweder hat die Anwendung ein Speicherproblem, die Limits wurden falsch gesetzt oder der Cluster skaliert oder rotiert gerade Nodes durch. Fehlt dann Kubernetes-Know-how, lernt man erst im Betrieb, dass dies ein Problem in der Anwendung ist. Wenn eine Anwendung mit der Eviction auf einen anderen Knoten nicht klarkommt, ist das in der Kubernetes-Theorie ein Applikationsproblem.

Köster: Ändert sich diese Eskalationsstrategie nicht, weil die 24/7-Rufbereitschaft für Systemadmins schon geklärt ist? Erzeugen transparente Kennzahlen wie Downtimes, Antwortzeiten, Fehlerraten mehr Druck?

Yanar: Mit der Frage zeigst du, wo das Problem liegt: nicht in der Transparenz, sondern in der Fehler- bzw. der Unternehmenskultur. Herrscht ein Klima der Angst, werden Fehler nach oben kaschiert, was weder dem Produkt noch der Firma hilft. Stattdessen sollten alle lösungsorientiert zusammenarbeiten. Der Vorteil transparenter Daten ist, dass man auch über seine Systeme hinaus Korrelationen aufbauen kann. Das führt zu einem viel größeren diskursiven Element, denn Teams können sich über diese Korrelationen über Teamgrenzen hinaus austauschen und lernt voneinander. So schafft die Transparenz auch Sichtbarkeit, z. B. für den Systemadmin, denn der fällt ehrlicherweise nur auf, wenn irgendetwas nicht funktioniert.

Köster: Was rätst du mir für den Beginn mit Observability in meiner Infrastruktur und in meiner Anwendung?

Yanar: In Kubernetes hast du schon sehr viel out of the box, wenn du einen Cluster hast, der so aufgebaut ist, wie der Erkan das sagt [2]. Mit Prometheus und Grafana siehst du schon den Zustand des Clusters und den Ressourcenverbrauch deiner Anwendung. Am wichtigsten aber: Es ist überhaupt kein Problem, eigene Metriken zu erfassen. Deshalb mach es einfach.