Bei Braintower haben wir schon lange erkannt, welchen hohen Stellenwert die automatisierte Überwachung (Monitoring) von IT-Infrastrukturen hat und können in diesem Bereich eine jahrelange Erfahrung vorweisen. Unsere Kunden vertrauen darauf, dass auftretende Probleme zeitnah erkannt und behandelt werden können. Gleichzeitig ist man durch ein gutes Monitoringsystem ebenfalls in der Lage zukünftige Engpässe frühzeitig zu erkennen und zielgerichtet darauf zu reagieren.

Das alles ist schön und gut und mit dieser Strategie haben wir schon mal ein Kind ins Trockene gebracht: Die Überwachung unserer Systeme und Server ist sichergestellt und wir können uns darauf verlassen, dass Ausfälle schnell bearbeitet werden. Aber wie sieht es damit aus, die historischen Daten aus dem Monitoring für Auswertungszwecke zu bündeln? Wie kann man sicherstellen, dass bspw. fest definierte Verfügbarkeiten der Server eingehalten wurden und die Ausfallzeit nicht zu hoch war? An dieser Stelle kommt das Reporting mit ins Spiel. Mit einem Reporting ist es möglich den Zustand unserer IT-Infrastruktur nach beliebig festgelegten Metriken zu bewerten. Das kann dazu führen unnötige Kosten und Ausgaben zu entdecken und es hilft auch dabei die Ausstattung unserer IT besser zu planen. Auch in diesem Bereich können wir bei Braintower auf eine breite Expertise blicken.

Konventionelle Reportingtools wie z.B. JasperReports sind schon sehr hilfreich und mächtig. Ich möchte euch heute aber eine etwas andere Strategie vorstellen, mit der man zum einen Daten für einen Report flexibel sammeln und auswerten kann und zum anderen spezielle Rahmenbedingungen präzise in die Erstellung der Reports einfließen lassen kann. Helfen soll uns dabei das Tool Talend Open Studio for ESB.

Was ist Talend Open Studio?

Talend Open Studio (oder einfach nur kurz: Talend) ist im Grunde nichts anderes als eine Entwicklungsumgebung (IDE). Dabei fokussiert sich das Tool aber auf Daten- und Systemintegration und arbeitet je nach Einsatzgebiet nach dem ETL-Prinzip (Extract, Transform, Load). Somit nimmt Talend die Funktion einer Middleware ein, von der wir bei Braintower auch für interne Prozesse stark Gebrauch machen.

Das Besondere an Talend ist aber die Art und Weise zu programmieren. Als grafische Entwicklungsumgebung werden zum Implementieren eines sogenannten Jobs (im Grunde handelt es sich dabei einfach um ein Java-Programm) verschiedenste Komponenten nach dem Drag-and-Drop-Prinzip genutzt, durch die dann der Quellcode ihrer Funktion entsprechend im Hintergrund generiert wird. Das führt dazu, dass man in der Regel nicht viel Code selbst schreiben muss. Stattdessen muss man wissen, wie und welche Komponenten man miteinander verbinden muss, um ein lauffähiges Programm zu erhalten. Für alle Codeliebhaber sei aber an der Stelle zur Beruhigung gesagt, dass es, wenn nötig, trotzdem möglich ist, eigenen Code zu schreiben. In vielen Fällen ist das sogar unumgänglich.

Talend in Zusammenspiel mit dem Monitoringsystem als Reporting-Tool

Was möchten wir denn überhaupt erreichen? Uns steht bereits ein aufgesetztes Monitoringsystem, wie z.B. Icinga 2 zur Verfügung. Für gewisse Hosts und Services möchten wir einen regelmäßigen monatlichen Report über die Verfügbarkeiten erstellen und dadurch prüfen, ob die gesteckten Ziele eingehalten wurden. Dabei machen wir uns das bereits erwähnte ETL-Prinzip zunutze. Talend erlaubt es alle relevanten Informationen aus der Datenbank von Icinga 2 abzufragen, diese dann in ein geeignetes Format zu bringen oder ein paar Rechnungen damit auszuführen und schließlich sauber formatiert abzuspeichern, sodass diese Daten für den Report genutzt werden können.

Dadurch, dass Icinga sich selbst um seine Daten und die Ergebnisse der verschiedenen Checks kümmert, ist die Hälfte der Arbeit schon getan. Sämtliche vergangenen Ergebnisse speichert Icinga in der Tabelle icinga_statehistory. Diese Tabelle bildet die Grundlage für das weitere Vorgehen. In Talend muss nun erst mal eine Funktion implementiert werden, die sich darum kümmert, die Historie der für den Report relevanten Hosts und Services aus icinga_statehistory auszulesen. Nicht wundern, je nachdem wie oft Icinga die Objekte prüft und wie groß die Check-Intervalle sind, werden das eine ganze Menge Zeilen sein.

Nun stehen wir aber schon vor einem kleinen Problem: Icinga 2 speichert jedes Event in die Tabelle, sei es ein Soft- oder Hard-State oder auch jede Problem- und Recovery-Notification. An der Stelle ist es daher wichtig, mit Talend die ausgelesenen Zeitintervalle zu filtern und nur die Zeilen mitzunehmen, die für die weitere Berechnung relevant sind. Für unseren Zweck werden wir uns pro Objekt nur die Intervalle herausziehen, die einem Hard-State und einem Problem entsprechen;  sprich, das Objekt war im Icinga entweder DOWN oder CRITICAL. Dadurch stehen uns alle Ausfälle des Hosts bzw. des Services zur Verfügung. Wie sieht es denn mit Downtimes aus dem Monitoring aus? Auch diese können wir von der Datenbank abfragen, seien es vergangene oder auch für die Zukunft gesetzte Downtimes. Verrechnen wir bspw. die zukünftigen Downtimes mit den bisher aufbereiteten Ausfallintervallen, so können wir uns schon mitten im Monat einen realistischen Überblick über die tatsächliche Verfügbarkeit des Objekts machen, da wir auch geplante Ausfälle in unsere Betrachtung mitaufnehmen.

Jetzt stehen wir vor schön bereinigten Daten. Aber wozu dieser ganze Aufwand? Ganz einfach: Durch geschicktes Ausnutzen von einigen Features unseres Monitoringsystems können wir Talend nun gezielt Rahmenbedingungen vorsetzen anhand dieser der Report vorbereitet werden kann. Wir können im Monitoring jedes unserer Objekte mit benutzerdefinierten Attributen versehen, die z.B. den Prozentsatz der Verfügbarkeit definieren oder auch den Zeitraum, für den die Verfügbarkeit gelten soll (Measurement Window). Möchten wir die Verfügbarkeit möglicherweise auf der Grundlage „werktags von 08:00 Uhr bis 17:00 Uhr“ oder doch lieber „täglich von 00:00 Uhr bis 24:00 Uhr“ berechnen? All das können wir in den Custom Variablen von Icinga festlegen, sodass Talend die Werte verstehen kann. Außerdem kann jeder Host und jeder Service individuelle Werte bekommen. Talend liest für jedes Objekt diese Parameter aus der Datenbank aus und wendet unsere bereinigten Daten darauf an.

Wie funktioniert das? Angenommen, uns stehen die bereinigten Ausfallzeiten (d.h. nach Filterung der State Types und Betrachtung aller Downtimes) zur Verfügung. Die Ausfälle dieser Daten können allerdings zu jeder beliebigen Uhrzeit stattgefunden haben. Im Monitoringsystem haben wir aber mittels Custom Variablen definiert, dass bspw. die Verfügbarkeiten nur „werktags von 08:00 Uhr bis 17:00 Uhr“ gelten sollen und wir eine Uptime von 99 % garantieren möchten. Talend muss nun die Ausfallintervalle auf das festgelegte Measurement Window anpassen, indem einige Intervalle geteilt werden oder andere komplett rausfliegen, weil sie außerhalb des Zeitfensters liegen. Am Ende haben wir die tatsächlichen Ausfallzeiten in Anbetracht des Measurement Windows. Wenn Talend nun die Soll-Verfügbarkeit (d.h. wie lange kann der Host bzw. Service unter Einbeziehung des Measurement Windows denn überhaupt maximal verfügbar sein) des Objekts für den Zeitraum des Reports (z.B. ein Monat) mit der Summe der Ausfallzeiten ins Verhältnis setzt, so erkennen wir, ob die 99 % eingehalten werden konnten oder nicht.

All diese Daten (tatsächliche Ausfallzeit, Soll-Verfügbarkeit, Measurement Window, Liste der Zeitintervalle usw.) können natürlich von Talend auch in einer eigenen Datenbank gesammelt und gespeichert werden. Dadurch können weitere Tools verwendet werden, um die Daten vielleicht grafisch aufbereitet anzuzeigen. Ansonsten ist es auch möglich den Report einfach selbst mit Talend zu generieren, indem man die Ergebnisse der Berechnungen einfach in eine Excel-Datei einfügt. All dem sind kaum Grenzen gesetzt.

Fazit

Talend ist ein wunderbares Tool, um Systeme miteinander zu integrieren. Durch seine Eigenschaften ist es ideal dafür geeignet, Daten aus fremden Systemen auszuwerten, weiterzuverarbeiten und schließlich anderen Systemen zur Verfügung zu stellen.

Dieses Prinzip haben wir uns zunutze gemacht, um eine Reportinglösung zu entwickeln, die maßgeschneidert auf unsere Bedürfnisse passt. Damit können wir gut auf Rahmenbedingungen reagieren, die uns vom Monitoring vorgegeben werden und Berechnungen sehr flexibel implementieren.

Ich für meinen Teil bin auf jeden Fall gespannt weitere Möglichkeiten und Einsatzgebiete dieses Tools zu entdecken.

Basit Rehman

Basit Rehman

Developer

Gefällt dir der Artikel? Bitte teile ihn!
Share on Facebook
Facebook
0Share on LinkedIn
Linkedin
Email this to someone
email
Tweet about this on Twitter
Twitter