EINLEITUNG
Dieser Artikel betrachtet das Thema Logging nach einer Migration einer Bestandsanwendung Richtung Cloud Foundry. Dabei wird zunächst geklärt, was in Bezug auf das Thema Logging erreicht werden soll. Im Anschluss werden verschiedene Lösungsansätze aufgezeigt, vorgestellt und der Hauptunterschied kurz erläutert. Zum Abschluss gibt es einen kurzen Ausblick mit weiterführenden Themen rund um das Logging in Cloud Foundry.
WAS IST DAS ZIEL?
Beim Portieren einer Bestandsanwendung Richtung Cloud Foundry taucht zwangsläufig die Frage auf, was mit den Log-Dateien der Anwendung passiert. Es ist bekannt, dass keine Log-Dateien in Cloud Foundry existieren. Stattdessen existiert eine Systemkomponente in Cloud Foundry, der Loggregator, der alle Logausgaben auf die Standardkanäle (stdout und stderr) weiterleitet. Cloud Foundry bietet auch die Möglichkeit, die Logausgaben der jeweiligen Anwendung einzusehen. Dies geschieht über den Befehl cf logs. Die Ausgabe sieht wie folgt aus:
github:1d5eb471518c1a25bb3754b73af057a4
Es ist zu erkennen, dass dort nicht nur Logausgaben unserer Anwendung erscheinen sondern auch von Cloud Foundry direkt. Jetzt könnte der Gedanke aufkommen, dass das alles kein Problem sei, die Informationen sind vorhanden, sie müssen nur bei Bedarf abgefragt werden und dann z.B. manuell in eine Datei kopiert werden. Im Anschluss könnte dann eine Analyse stattfinden. Allerdings gibt es neben Dateien eine weitere Einschränkung. Wie oben bereits erwähnt, ist die Systemkomponente Loggregator für die Verwaltung der Logs von Anwendungen zuständig. Diese verwendet einen Buffer, um die Ausgaben zwischenzuspeichern. Dieser Buffer ist allerdings sehr limitiert und verfügt über keine große Kapazität. Die Folge ist, dass frühere Logausgaben zwangsläufig verloren gehen, wenn diese nicht persistent gespeichert werden (siehe auch Application Logging in Cloud Foundry). Und genau an diesem Punkt setzt dieser Beitrag an. Es sollen verschiedene Lösungsansätze aufgezeigt werden, um die Logausgaben in einer persistente Form zu überführen.
WELCHE LÖSUNGSANSÄTZE EXISTIEREN?
Es gibt auch für dieses Problem mehrere Möglichkeiten, dieses zu lösen. Ein paar dieser Möglichkeiten sind folgende:
- User-provided Services
- Logging Frameworks
In diesem Beitrag sollen der Einsatz dieser beiden Möglichkeiten näher betrachtet werden. Als Testgegenstand dient eine einfache Spring Boot Java Anwendung, die als Webanwendung (.war) ausgeliefert wird. Damit die Anwendung und die entsprechenden Empfänger der Logausgaben untereinader kommunizieren können, wird vorausgesetzt, dass eine Verbindung zwischen den jeweiligen Anwendungen möglich ist. Dieser Ansatz entspricht dann mehr einer On-premises Lösung in einem Unternehmen (eigene Infrastruktur und Cloud Foundry Installation).
VERWENDUNG EINES LOGGING-FRAMEWORKS
Wie bereits angesprochen, handelt es sich bei der Beispielanwendung um eine Java-Anwendung. Ein bekanntest Logging Framework in diesem Bereich ist Logback, was auch hier zum Einsatz kommt. Als Ziel wird ein ELK-Stack verwendet, um die Logausgaben letztendlich zu speichern. Um ein konformes Format für den ELK-Stack zu erstellen, wurde in dem GitHub-Projekt Logback JSON encoder ein Appender implementiert, der eben genau dieses Format produziert. Dies löst aber nicht das Problem, dass der ELK-Stack nicht in Cloud Foundry verfügbar ist. Glücklicherweise beinhaltet die Erweiterung für Logback ebenfalls einen Appender, der über das Netzwerk (TCP/UDP) versenden kann. Daher konfigurieren wir nun einen solchen Appender in der logback.xml:
github:8ce343cb07b4c22e53ff20037bd30b1b
Über das Tag destination wird angegeben, über welchen Host und Port der ELK-Stack erreichbar ist. Das Tag encoder ist notwendig, damit die Logausgabe in ein entsprechendes Format gebracht wird. Weitere Informationen zu den Appendern und dessen Konfiguration können über das GitHub-Projekt bezogen werden.
Anschließend wird die Anwendung in Cloud Fondry aktualisieren, um die Logausgaben nun ebenfalls an den ELK-Stack zu schicken. Nachdem dem Starten sollten nun auch alle Logausgaben im ELK-Stack enthalten sein, die Teil der com.comsysto.cf-Paketstruktur sind. Nachfolgend ein Bild von Kibana (Produkt zur Visualisierung innerhalb des ELK-Stacks):
Dank dieser Erweiterung für Logback ist der Einsatz im Zusammenspiel mit einem ELK-Stack, der nicht innerhalb von Cloud Foundry verfügbar ist, sehr einfach und kann schnell konfiguriert werden. Logback selbst bietet auch einen SocketAppender an, der ebenfalls genutzt werden kann, um die Logausgaben an ein Ziel außerhalb von Cloud Foundry zu schicken.
VERWENDUNG EINES USER-PROVIDED SERVICES
Eine weitere Möglichkeit ist der Einsatz eines user-provided Services. Dies ist auch der präferierte Weg, den die Dokumentation von Cloud Foundry vorschlägt, um die Logausgaben einer Anwendung langfristig zu persistieren. Hierbei muss keine Konfiguration innerhalb der Anwendung angepasst werden, sondern lediglich ein user-provided Service erstellt und an die jeweilige Anwendung gebunden werden. Als Protokoll wird syslog genutzt.
Zuerst wird ein user-provided Service erstellt, der das Protokoll, den Host und den Port angibt. Dazu wird folgender Befehl verwendet:
shell:cf cups logstash -l syslog://cfext.ddns.net:9001
Der neue Service heißt “logstash”, als Protokoll wird syslog verwendet, wie bereits erwähnt, und der Host und der Port entsprechen den selben Werten, die bereits beim Logging-Framework konfiguriert wurden. Der wichtige Punkt an dieser Stelle stellt das Flag -l dar. Dadurch wird signalisiert, dass die Logausgaben bzw. die Standardkanäle an diese Adresse gesendet werden sollen. In der Dokumentation von Cloud Foundry wird so etwas Syslog Drain genannt.
Als nächstes müssen wir nun den neuen Service an die Anwendung binden. Dazu bemühen wir ein weiteres Mal die Clound Foundry CLI mit dem folgenden Befehl:
shell:cf bind-service myapp logstash
Dadurch binden wir den user-provided Service “logstash” an die Anwendung “myapp” (Bestandsanwendung). Damit die Änderung auch wirksam wird, muss der Anwendungscontainer innerhalb von Cloud Foundry neu erstellt werden:
shell:cf restage myapp
Aktuell ist unter dieser Adresse der bereits genannte ELK-Stack erreichbar. Daher können die Logausgaben auch wieder dort eingesehen werden:
Anstatt des ELK-Stacks kann aber auch ein anderes System über die Adresse erreichbar sein und die Logausgaben entgegen nehmen. Mit Syslog4j ist es möglich, einen Server zu starten, der mit dem syslog-Protokoll umgehen kann. Der Server wird so gestartet, dass er unter der selben Adresse erreichbar ist wie zuvor der ELK-Stack und die empfangenen Logausgaben auf der Konsole ausgibt und gleichzeitig in eine Datei schreibt. Das ergibt folgendes Erscheinungsbild der Konsole:
In der Cloud Foundry Dokumentation werden noch weitere Systeme zur Verwaltung von Logs genannt und Hilfe für die Konfiguration zur Verfügung gestellt.
WAS SIND DIE UNTERSCHIEDE DER BEIDEN LÖSUNGSANSÄTZE?
Der Hauptunterschied zwischen diesen beiden Ansätzen besteht in dem Umfang, was an ein anderes System weitergeleitet wird. Beim Logging-Framework werden nur Logausgaben geschickt, die die Anwendung direkt betreffen. Beim user-provided Service hingegen werden zusätzlich zu den rein anwendungsspezifischen Logausgaben auch noch weitere Komponentenlogausgaben von Cloud Foundry geschickt, wie zum Beispiel über das Routing. Somit erhält man auf der einen Seite die anwendungsspezifischen und auf der anderen Seite die verwaltungstechnischen Logausgaben. Das kann in Fällen sinnvoll sein, wenn es Probleme beim Start oder auch beim Erreichen der Anwendungen gibt. In der Dokumentation von Cloud Foundry wird den Ansatz über user-provided Services präferiert, wie bereits erwähnt.
WIE GEHT ES WEITER?
Die Logausgaben der Bestandsanwendung können nun auf unterschiedliche Art und Weise aus Cloud Foundry heraus umgeleitet werden, wie bereits gezeigt. In diesem Beitrag wurde eine eigene Installation des ELK-Stacksverwendet. In Zeiten der Cloud scheint das fast altmodisch. Inzwischen existieren Anbieter, wie z.B. Papertrail, die Lösungen wie einen ELK-Stack als Onlineservice anbieten. An dieser Stelle sei darauf hingewiessen, dass die Dokumentation von Cloud Foundry für eine Handvoll solcher Anbieter bereits Installations- und Konfigurationsanleitungen beinhaltet. Falls der gewünschte Anbieter nicht enthalten ist, können die Anleitungen anderer Anbieter oftmals Aufschlüsse geben, wie der neue Anbieter in Cloud Foundry integriert werden kann.
Ein weiteres Thema im Bereich Logging ist die Unterscheidung von unterschiedlichen Umgebungen wie z.B. Entwicklung, Test, Produktion. Es ist bereits ein Vorteil, wenn alle Logausgaben z.B. in einem ELK-Stack vorliegen, damit diese einfacher durchsucht werden können. Allerdings ist es ebenfalls wichtig zu wisssen, woher ein Eintrag stammt. Daher ist es notwendig, dass auch die Umgebung der Logausgabe bekannt und im besten Fall auch als Suchkriterium in z.B. einem ELK-Stack verfügbar ist. In diesem Zusammenhang spielen Spaces in Cloud Foundry eine Rolle, da unterschiedliche Umgebungen über diese abgebildet werden können. Dieses Thema ist dementsprechend ein weiterer Aspekt, um das Logging innerhalb von Cloud Foundry weiter zu optimieren.
