Die Fehlersuche in einem verteilten System gestaltet sich viel schwieriger als es bei einem monolithischen System der Fall ist. Die Abarbeitung der Client-Requests erfolgt über eine typische Service-zu-Service-Aufrufkette. Jeder an dieser Aufrufkette beteiligte Service erzeugt dabei seine eigenen Logausgaben, die über unterschiedliche Logstreams ausgegeben werden. Sofern diese Logstreams nicht in einem zentralen System gesammelt werden, bleibt es schwierig, die Ursache eines Fehlers zu finden.

Es bleibt einem Entwickler nichts anderes übrig, als jede Logausgabe einzeln zu untersuchen. In produktiv betriebenen Systemen werden in der Regel die einzelnen Logausgaben zentral gesammelt. Systeme, wie beispielsweise der sogenannte EFK-Stack (Elasticsearch [1], Fluentd [2], Kibana [3]), bieten hierfür die notwendige Funktionalität an. Doch wie kann sich ein Entwickler behelfen, wenn in seiner (lokalen) Entwicklungsumgebung diese zentrale Sammlung (noch) nicht existiert?

Die Installation des EFK-Stacks in seinem (lokalen) Kubernetes-Cluster ist nicht ganz trivial, und auch der Ressourcenbedarf der drei EFK-Services ist nicht gerade gering. Zum Glück gibt es hierfür eine ressourcenschonende und einfache Alternative: Stern [4]. Stern sammelt die Logausgaben verschiedener Kubernetes-Pods und deren zugehörigen Container, auch dann, wenn ein Kubernetes-Pod aus mehreren Containern besteht. Damit diese gesammelten Logausgaben hinsichtlich ihrer Quelle unterschieden werden können, werden die Ausgaben mit unterschiedlichen Farben hervorgehoben. Unter Verwendung eines regulären Ausdrucks als Befehlsparameter kann die Auswahl der Pods bzw. Container genauer eingeschränkt werden. Um an die jeweiligen Logstreams zu kommen, verwendet Stern die aktuelle Verbindung zum Kubernetes-Cluster. Abbildung 1 zeigt die typische Ausgabe von Stern, wobei die Logstreams der einzelnen Pods in Gelb, Grün, Hellblau und Dunkelblau hervorgehoben werden.

Abb. 1: Logausgabe Stern

Die Alternative zu Stern ist der Befehl kubectl logs [5]. Als Befehlsparameter wird der Pod-Name und der Name des Containers, falls der Pod aus mehreren Containern besteht, angegeben. Die Ausgaben des so gewählten Logstreams werden an die lokale Shell weitergeleitet. Im Vergleich zu Stern hat diese Möglichkeit des Logstreamings zwei entscheidende Nachteile. kubectl logs streamt genau einen Logstream in die lokale Shell. Bei der Fehlersuche über mehrere Pods bzw. Container hinweg müssen hierfür mehrere Logstreams in separaten...