Wie Entwickler und Admins Problemen mit Jaeger auf die Schliche kommen
Mancher Administrator, der sich zum ersten Mal in seiner Karriere einem Container-basierten Setup mit darauf laufenden, verteilten Applikationen gegenüber sieht, mag denken, dass früher vieles anders war, vielleicht sogar besser. Aus seiner Perspektive ließe sich jedenfalls nachvollziehen, wie es zu diesem Fehlschluss kommt. Wer früher dafür zuständig war, die Ursache von Problemen zu finden, hatte ein paar offensichtliche Ansatzpunkte. Große Monolithen wie etwa MySQL schreiben ganz banal ihre Fehlermeldungen auf. Ein Blick in die Log-Datei genügte also oft bereits, um dem Admin zumindest einen Fingerzeig in die richtige Richtung zu geben.
Wenn in der Log-Datei nichts Sinnvolles stand, blieb immer noch die Ebene darunter als Ansatzpunkt: Funktionierte beispielsweise die Kommunikation zwi schen Server und Client nicht so, wie die Dokumentation es beschrieb, half sich so mancher Admin routiniert mit Werkzeugen wie Tcpdump aus der Patsche 1. Damit lässt sich bis auf die untersten Ebenen einer Netzwerkverbindung der Datenverkehr mitlesen, anschließend mittels Wireshark visualisieren und dann auf potenzielle Probleme abklopfen.
Hinzu kommt die Perspektive des Clients: Der sieht ja ebenfalls noch eventuelle Fehler und gibt die passenden Meldungen bei Bedarf einfach im Terminal aus.
Moderne Anwendungen
Von derartig einfachen DebuggingMechanismen können Admins und auch Entwickler bei moderneren, verteilten Anwendungen nur träumen. Zur Erinnerung: Die Cloud-native-Architektur bringt zwar einige Vorteile mit sich, etwa implizite Redundanz oder die Option, externe Lösungen wie Istio dynamisch einzubinden. Im Gegenzug wächst aber auch die Komplexität. Zur Illustration eignet sich das erwähnte Beispiel einer Datenbank hervorragend.
Clients bauen persistente Verbindungen zur Datenbank auf. Sie stellen sie also einmal her und nutzen sie dann kontinuierlich, bis sie entweder eine Seite terminiert oder ein Fehler der
