Teil 2: Versand von Logeinträgen per UDP, Einrichtung von Kibana und Anwendungsfälle

Logging mit Logstash und log4net im Microsoft-Umfeld [Teil 2]
Keine Kommentare

Wie lässt sich eine Protokollinformationsflut in den Griff bekommen? Mit Logstash! Im zweiten Teil dieses Artikels erklären wir, wie sich Logeinträge per UDP versenden lassen, wie das Visualisierungs-Plugin Kibana eingerichtet wird und welche Anwendungsfälle denkbar sind.

Nachdem Teil 1 dieses Artikels einen Überblick über die benötigten Komponenten und deren Einrichtung gegeben hat, betrachten wir im zweiten Teil den Versand von Logeinträgen per UDP, die Einrichtung von Elasticsearchs Datenvisualisierungs-Plugin Kibana sowie möglichen Anwendungsfällen wie der Kombination von mehreren Logeintragsquellen oder dem Monitoring.

Einen Logeintrag per UDP versenden

Wie schon erwähnt, gibt es viele Inputs für Logstash. Dieser Artikel verwendet den UDP-Input. Ob man nun mit log4net, Enterprise Library Logging oder einer anderen Logging-Lösung arbeitet – es ist meist recht einfach, eine Nachricht per UDP zu versenden. Daher eignet sich dieser Input gut als Allzwecklösung für verschiedene Quellen; als Beispiel wird hier log4net verwendet. Das ist naheliegend, wenn man sich die Downloadzahlen bei NuGet ansieht; log4net läuft unter derselben Lizenz wie schon die drei bisher verwendeten Komponenten. log4net ist eine .NET-Portierung des log4j-Frameworks und lässt sich schnell und einfach per XML konfigurieren. Zudem bietet es von Haus aus einen UdpAppender, mit dem sich Logeinträge per UDP verschicken lassen. In Listing 2 ist eine log4net-Konfiguration mit einem UdpAppender zu finden, der Logeinträge an den konfigurierten Logstash-Input senden kann. Wenn nun das Format des Logeintrags stimmt, kann der in Logstash konfigurierte Filter die Felder auslesen.

<log4net>
  <appender name="UdpAppender" type="log4net.Appender.UdpAppender">
    <RemoteAddress value="127.0.0.1" />
    <RemotePort value="5960" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="MyApplication - %-5level - %message" />
    </layout>
  </appender>
    
  <root>
    <level value="DEBUG" />
    <appender-ref ref="UdpAppender" />
  </root>
</log4net>

Um zu verstehen, wie der Filter die Felder erkennt, ist ein Vergleich der log4net-Konfiguration mit der von Logstash sinnvoll. Das conversionPattern in der log4net-Konfiguration gibt an, wie log4net die Nachricht formatiert. Hier sieht man, dass der Applikationsname fest verbaut ist. Ihm folgt eine log4net-Variable für das Logging-Level und eine ebenfalls als Variable vorliegende Nachricht; als Trennzeichen wird ein Bindestrich verwendet. In der Logstash-Konfiguration interessiert für diesen Vergleich nur der Bereich hinter filter in den geschweiften Klammern. Hier wird der Grok-Filter verwendet. Er interpretiert die message und liest die drei Werte aus, die mit Bindestrichen getrennt sind. Diese Werte werden in den Feldern app, level und message gespeichert. Die message wird mit dem ausgelesenen Feld message überschrieben, da sonst die gesamte Nachricht im entsprechenden Feld stünde. Die Syntax von Grok ist einfach %{SYNTAX:SEMANTIC}; zudem gibt es viele vorgefertigte Patterns. In der Dokumentation von Logstash findet man auch die Dokumentation von Grok. Zudem gibt es einen guten Debugger, der auch Patterns vorschlagen kann. Allerdings belastet Grok die CPU, was man durchaus in Kauf nimmt, wenn die Logeinträge von jemand anderem kommen. Für die eigenen Anwendungen kann es aber sinnvoll sein, direkt JSON-Objekte an Logstash zu schicken, wenn man den Logstash-Server entlasten muss.

Kibana einrichten

Hat man die ersten Logeinträge in Logstash hinzugefügt, kann man sich der Visualisierung dieser Einträge zuwenden. Die im IIS eingerichtete Kibana-Webseite sollte den Nutzer nach dem Aufruf mit einem „Welcome to Kibana“ begrüßen. Auf der Welcome-Seite von Kibana befinden sich Links zur Dokumentation, die am Anfang sehr hilfreich sein können. Um direkt zu seinen Logeinträgen zu gelangen, klickt man auf das vorerstellte Logstash-Dashboard. Wenn alles richtig eingerichtet ist und Logeinträge verschickt wurden, sollte man auf dem Logstash-Dashboard in etwa das vorfinden, was auch in Abbildung 2 zu sehen ist.

Abb. 2: Das Standard-Logstash-Dashboard

Abb. 2: Das Standard-Logstash-Dashboard

Auf dem Default-Dashboard befindet sich ganz oben eine Eingabemöglichkeit, um per Query Logeinträge abzufragen. Darunter findet man einen Graph, auf dem man erkennen kann, wie viele Logeinträge in den letzten Stunden (oder Minuten, je nach Intervall) eingetroffen sind. Ganz unten befindet sich eine Tabelle, in der alle Logeinträge aus dem eingestellten Zeitraum zu sehen sind. Hier findet man nun auch die per UDP übertragenen Einträge. Klickt man einen Eintrag an, werden Details aufgelistet. Wenn alles geklappt hat, sollte man, neben einigen allgemeinen Feldern, die drei Felder app, level und message sehen. Ansonsten ist es sehr wahrscheinlich, dass das Tag _grokparsefailure gesetzt ist, das signalisiert, dass die Nachricht so nicht zum Filter passt bzw. nicht geparst werden konnte.

Die Query-Syntax von Kibana ist sehr einfach. Mit app:“MyApplicaton“ kann man bequem nach dem Feld app filtern. AND– und OR-Verknüpfungen sowie das Ausschließen mit NOT sind möglich. Es ist auch möglich, mehrere Queries zu erstellen und jedem Query einen Alias und eine Farbe zuzuweisen, wodurch sich zum Beispiel im Graph Fehlerwarnungen farblich unterscheiden lassen. Der Graph selbst (das Histogramm-Panel) zeigt nicht nur das Auftreten und die Menge von Meldungen auf einem Zeitstrahl an. Es ist sogar möglich, mit der Maus einen Bereich zu selektieren, um so schnell und einfach die auf dem Dashboard dargestellten Daten einzuschränken. In der Tabelle kann man die sichtbaren Felder selbst bestimmen, anordnen und sortieren. Neben der Tabelle und dem Histogramm gibt es noch andere Panels, die sich einfügen lassen, zum Beispiel das Term-Panel, mit dem sich unter anderem Kuchendiagramme anhand der Queries erstellen lassen. So wird erkennbar, bei welchem Host es zu den meisten Fehlern kommt. Klickt man dann auf dieses Stück des Kuchens, so wird automatisch nach dem Host gefiltert. Die Panels kann man beliebig anordnen und auch in der Größe anpassen. Dadurch lässt sich das Kibana-Dashboard an individuelle Ansprüche anpassen. Oben rechts hat man die Möglichkeit, das angepasste Dashboard zu speichern, um sich so verschiedene Boards für die jeweiligen Anwendungsfälle anzulegen (Abb. 3).

Abb. 3: Ein angepasstes logstash-Dashboard

Abb. 3: Ein angepasstes logstash-Dashboard

Die Möglichkeiten

Einer der möglichen Anwendungsfälle ist die Kombination von mehreren Logeintragsquellen. Ein Beispiel ist eine Clientanwendung, die mit einem Web Service kommuniziert. Beide erzeugen Logs. Würde man beide Informationen im selben Dashboard sammeln, könnte man feststellen, ob der Fehler bei der Clientanwendung auch einen Fehler bei dem Web Service erzeugt hat, oder ob umgekehrt ein Fehlverhalten des Service zu Fehlern bei den Clients führt. Wenn man jetzt noch die Windows-Ereignisprotokolle zu den Daten hinzuzieht, könnte man sogar erkennen, ob der Fehler nicht von ganz woanders kommt. Nimmt man das SQL-Server-Log und das IIS-Log hinzu, hat man eine Vielzahl an Mehrinformationen, um dem Fehler auf den Grund zu gehen. Diese Informationen hätte man ohne Logstash zwar auch, könnte aber nicht einfach mit ein paar Klicks alle Logeinträge zu einem bestimmten Zeitpunkt miteinander vergleichen. Gerade, wenn man beachtet, wie verschieden die Logfiles der einzelnen Systeme aufgebaut sind – sei es die Datumsformatierung oder einfach die fehlende Lesbarkeit für Menschen – sind diese Mehrinformationen nützlich. Versucht man in einer Systemanwendung wie dem IIS eine bestimmte Anfrage zu finden, ist das durch die Formatierung des Logs nur schwer möglich. Mit Logstash lassen sich alle Logeinträge vergleichbar machen – jeder Timestamp im selben Format, alles gut lesbar für den Problembearbeiter. So lassen sich Auswirkungen von Fehlern schneller von der eigentlichen Fehlerquelle trennen und so viel Zeit sparen.

BASTA! 2021

Neuerungen in .NET 6.0 – das eine .NET, sie alle zu beherrschen

mit Dr. Holger Schwichtenberg (DOTNET-DOKTOR)

C# Workshop: — was kommt Neues mit C# 10 und .NET 6?

mit Rainer Stropek (timecockpit.com)

Funktionaler Code mit C# 9

Oliver Sturm (DevExpress)

 

Software Architecture Camp

Advanced Web Pentesting

mit Christian Schneider (Schneider IT-Security)

What Star Wars Taught Me About Secure System Design

mit Anne Oikarinen (Nixu Corporation)

Ein weiterer Anwendungsbereich ist das Monitoring. Mithilfe der verschiedenen Plug-ins ist es möglich, den Status eingesetzter Komponenten zu überwachen. Logstash wird kein Nagios oder Alternativen ersetzen, kann aber solche Systeme unterstützen. Es gibt zum Beispiel einen Nagios-Output für Logstash. Auch sind Kibana-Boards denkbar, auf denen man sehen kann, ob ein Build fehlgeschlagen ist. Hierfür gibt es sogar ein Jenkins-Plug-in. Ein weiteres Beispiel sind die „Kein Unfall in den letzten x Stunden“-Tafeln: So etwas könnte man auch mit Logstash als „die Anwendung läuft seit x Tagen fehlerfrei“ abbilden. Solche Informationen sind nicht nur eine nette Zugabe, sie fördern auch das Vertrauen. Zudem lassen sich Auslastungen anzeigen, indem man nicht nur die Fehler, sondern auch Zugriffe auf begrenzte Ressourcen wegschreibt. Fasst man diese Zugriffe in mehreren Queries zusammen (eine pro Anwendung), so kann man sich ein Diagramm in Kibana erstellen, das den Zugriff auf diese Ressource und zusätzlich die Menge der Zugriffe anzeigt. Das IIS-Log oder das Datenbanklog können so gut lesbar überwacht und Auslastungsspitzen bei möglichen Fehleranalysen mit hinzugezogen werden.

Bei adesso besteht aktuell in einem Projekt die Schwierigkeit, dass die Anwendung beim Kunden nicht immer die Möglichkeit hat, den Server zu erreichen. Fehler sollen dennoch zentral protokolliert sein. Eine einfache Lösung für dieses Problem ist es, die Logs in eine RabbitMQ-Instanz zu schreiben. Durch das RabbitMQ-Input-Plug-in für Logstash lassen diese sich dann ohne viel Aufwand abrufen. Zudem wird beim Client eine lokale RabbitMQ-Instanz installiert, in die die Anwendung die Logeinträge schreibt. Ist der Client offline, hält die Queue die Einträge vor. Sobald der Client online geht, wird per Shovel-Plug-in der Logeintrag in die zentrale RabbitMQ gelegt und dort von Logstash abgeholt. Dieses Szenario ermöglicht es auch, problemlos Teile abzuschalten und zu aktualisieren, da die Nachricht entweder beim Client bleibt oder in der zentralen Queue liegt, bis Logstash sie abholt. Somit ist auch ein Update von Elasticsearch oder Logstash ohne Wartungsfenster durchführbar – ohne, dass dabei Logeinträge verlorengehen.

Fazit

Logstash ist schnell und einfach eingerichtet und steht kostenlos zur Verfügung. Die Möglichkeiten sind dank vieler Plug-ins und einer durchdachten Webanwendung vielfältig. Natürlich lässt sich all das, was Logstash bietet, auch selbst nachbauen, aber das kostet Zeit und damit auch Geld. Mit Logstash hat man eine durchdachte Lösung, um mit vielen Protokollinformationen elegant umzugehen und diese auszuwerten. Dank einer aktiven Community kommen zudem immer weitere Plug-ins hinzu. Mit Elasticsearch ist auch bei großen Datenmengen noch eine schnelle Abfrage der Logs möglich. Somit ist Logstash allen zu empfehlen, die mehr wollen, als nur ein Logfile irgendwo auf einer Festplatte.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -