Jan Philipp Hoepfner, Technical Consultant
Jan Philipp Hoepfner ist Consultant bei Medialine und hat das Monitoring des Unternehmens aufgebaut und geprägt. Im Interview gibt er spannende Einblicke in sein Themenfeld.
Dieses Interview wurde im Jahr 2020 durchgeführt.
ML: Monitoring, also die Überwachung und Beobachtung von Systemen oder Prozessen, kennt man aus vielen verschiedenen Branchen und Bereichen. Was ist das Besondere am Monitoring in der IT?
JPH: Gute Frage, was ist besonders am IT Monitoring? Ich glaube besonders kann man nicht wirklich sagen, denn jedes Monitoring was ich kenne steht unter dem Leitspruch „if you can´t measure it, you can´t manage it“. So versuchen wir mit verschiedenen Arten von Überwachung, Ursachen zu ermitteln deren Parameter außerhalb der von uns bestimmten Bereiche liegen. Prinzipiell suchen wir nach Indikatoren, die uns Aufschluss über einen Fehler oder eine Anomalie in unseren Systemen geben. Das macht aber nicht nur das Monitoring in der IT so.
ML: Welches Ziel verfolgt IT Monitoring – oder wo ist der Mehrwert für die Nutzer und Kunden?
JPH: Ausfälle frühzeitig erkennen, höhere Sicherheit, stabiler Betrieb der Systeme, Vermeidung von Incidents und Outages.
ML: Was sind das für Indikatoren, die beobachtet und durch das Monitoring überwacht werden?
JPH: Es gibt unterschiedliche Indikatoren. Beispielsweise die Kontrolle eines Lüfters, die Auslastung von „Computer-Ressourcen“ wie CPU und Memory Usage oder Disk Availabilty, die Abfrage einer Datenbankfunktion oder die „User Experience“ eines Webshops. Es ist für uns also sehr wichtig Abhängigkeiten nachvollziehen zu können, die VM´s auf unsere physikalische Infrastruktur und umgekehrt haben, um diese so bestmöglich zu überwachen und auf noch kommende Anforderungen vorbereiten zu können.
Ein weiterer sehr wichtiger Indikator ist die Zeit. Ein einzelner Peak beispielsweise muss kein Indikator für eine Anomalie sein, mehrere aufeinanderfolgende oder in Korrelation zueinander stehende Peaks können das aber sehr wohl. Wir sammeln also viele verschiedene Daten, um so zu erkennen wie sich unsere Infrastruktur tagtäglich verhält. Ohne die Daten wäre es uns nicht möglich so früh wie möglich eine Anomalie zu erkennen und diese zu beheben bevor daraus beispielsweise ein „Incident“ oder gar ein „Outage“ wird.
ML: Und was ist das Ziel, das hinter dieser Datensammlung und der dazugehörigen Analyse steckt?
JPH: Oberstes Ziel ist natürlich der stabile Betrieb unserer Systeme und die Vermeidung von Störungen beim Kunden. Ein wichtiges Ziel des Monitorings ist daher die Früherkennung von Anomalien. Wir wollen Fehler und Probleme lösen bevor sie auftreten. Dazu müssen wir in der Lage sein, Abweichungen zu erkennen bevor sie zu einem Problem oder Fehler werden. Natürlich können wir nicht alle Eventualitäten direkt abfangen, aber je mehr Daten oder Indikatoren ein Monitoring sammeln kann, umso höher ist die Wahrscheinlichkeit, dass wir wiederkehrende Probleme und Fehler frühzeitig behandeln können.
Nehmen wir beispielsweise den Ansatz des „Application Performance Monitoring“. Dabei überwachen wir die Verfügbarkeit der Applikation und deren Leistung. Wir sammeln also beispielsweise Leistungsindikatoren, die Aufschluss darüber geben sollen wie die Applikation sich in bestimmten Auslastungsgraden verhält und ob sie funktional ist. Jetzt melden verschiedene User, dass die Applikation träge und dadurch quasi nicht bedienbar ist. Im Monitoring können wir aufgrund der gesammelten Daten sehen, dass bei der Applikation deutlich erhöhte Performancewerte in den letzten Minuten üblich sind. Beim genauen Betrachten der Applikation fällt auf, dass ein Dienst deutlich mehr Ressourcen benutzt als er sollte. Nach einem Neustart des Dienstes kommt das Feedback der User: Alles läuft wieder. Was wir im Nachgang dann machen, ist, die Erfahrung aus dem Monitoring mit unserem Lösungsansatz zu verknüpfen, um so den Dienst, sollte die Applikation erneut in diese Problematik laufen, automatisch neu zu starten.
ML: Welche Tools nutzen wir um all diese unterschiedlichen Bereiche zu monitoren?
JPH: Den größten Teil unserer Systeme und besonders den Applikationsbereich, also vom Hypervisor bis zur Applikation decken wir mit PRTG von Paessler ab. PRTG war auch mein Einstieg in das Monitoring und ich habe das Tool bei uns initial mit aufgesetzt und nach und nach weiterentwickelt. Im Netzwerkbereich arbeiten wir mit LibreNMS und nutzen dabei Grafana als Visualisierungs-Software. Dazu kommt noch vRealize Log Insight.
ML: Werden alle Daten bei Grafana gesammelt und visualisiert?
JPH: Nein, nicht alle. Aktuell speisen wir Grafana nur mit Informationen aus unserem Networkmonitoring LibreNMS. PRTG ist zwar auch in Grafana integrierbar, hat aber seine eigenen „out oft he box“ Graphen und seine eigene Datenbank. Wir bauen aber gerade im Hintergrund an einem Konzept wie wir die Datensätze aus PRTG und LibreNMS oder einem möglichen neuen Tool in Grafana visualisieren können.
ML: Das klingt erstmal recht unübersichtlich und nach vielen Tools. Warum werden verschiedene Tools genutzt und was sind die Stärken und Schwächen der jeweiligen Tools?
JPH: Wir arbeiten aktuell mit 4-5 Tools, die uns dabei helfen die Komplexität unserer Systeme zu visualisieren und zu monitoren. Unser Kundenportfolio ist weit gefächert, wir betreuen produzierende Gewerbe ebenso wie Unternehmen aus der Finanzbranche oder den Versandhandel mit Webshops. Um die individuellen Wünsche und Bedürfnisse unserer Kunden und auch die steigenden Anforderungen an unsere eigene Infrastruktur abdecken zu können, haben wir uns dazu entschieden eine sanfte Trennung zwischen Applikation- und Performancemonitoring sowie Netzwerkmonitoring vorzunehmen. Paessler hat mit PRTG ein absolut geniales Produkt entwickelt was definitiv das Ziel, einem System-Administrator so viel wie möglich aus einer Hand zu bieten, nicht nur verfolgt, sondern auch erreicht. Das gesamte Performance- und Applikationsmonitoring bei uns wird durch PRTG realisiert.
Jeder Kunde der einen Service bei uns bucht oder im generellen Monitoring über uns bezieht bekommt Zugriff auf seine gemonitorten Systeme, was eine großartige Transparenz schafft. Mit der Installation unserer eigenen Apllication-Software haben wir uns dann intensiver mit LibreNMS beschäftigt, da dort Protokolle wie OSPF, BGP,FDP oder SNMP out of the box als autodiscovery integriert sind. Die Autodiscovery und die Templates werden regelmäßig geupdated und von der Community gepflegt, was das Tool im Netzwerk wirklich sehr stark macht. Bei der Datenbank haben wir uns für eine Zeitreihen-Datenbank („TimeSeries“) entschieden, um Daten in Echtzeit später auf Grafana visualisieren zu können. Im Endeffekt bauen wir uns ein Ökosystem aus verschiedenen Tools auf und fügen diese auf einer Visualisierungsplattform wie Grafana zusammen.
Also ja, vielleicht sieht es nach außen noch sehr komplex aus, bedenkt man aber das im Durchschnitt ein Systemadministrator mit 7-11 verschiedenen Tools seine Infrastruktur überwacht, haben wir jetzt schon ein ganz gut aufeinander abgestimmtes System, was zudem noch viel Potenzial hat.
ML: Es wird also sehr viel Aufwand betrieben, um Daten zu sammeln und eine effektive Früherkennung zu gewährleisten. Da mal leicht provokativ: Wieso entstehen dann trotz der vielschichtigen Überwachung immer noch Fehler?
JPH: Da komme ich gerne wieder zu meiner anfangs zitierten Aussage zurück: „if you can´t measure it, you can´t manage it“. Wenn ich einen Fehler oder eine Anomalie noch nie zuvor gesehen habe, woher soll ich dann wissen, dass es als solche zu bewerten ist? Ein Monitoring-System ist da nicht viel anders als ein Mensch. Auch wir müssen Erfahrungen sammeln und aus den gesammelten Erfahrungen lernen. So muss es auch ein Monitoring und seine Administratoren. Beim Einrichten eines Monitorings bei einem Kunden erinnere ich die Kunden immer daran, dass man dem Monitoring ebenso wie den Administratoren die Chance geben muss, aus Fehlern zu lernen. Ein perfektes Monitoring out of the Box gibt es nicht. Aus diesem Grund muss man einen hohen Aufwand betreiben, um die Tools zu optimieren und anzupassen und genau dazu gehören eben auch Fehler.
ML: Vielen Dank für diese intensiven Einblicke und interessanten Ausführungen. Wie bewertest du den aktuellen Status Quo des Medialine Monitorings?
JPH: Wir haben in den letzten Monaten viel Zeit in unser Monitoring investiert. Wir haben neue Tools mit in unser „Ökosystem“ aufgenommen und unsere bestehenden Tools optimiert. Mit dem aktuellen Stand bin ich zufrieden, dennoch wartet noch viel Arbeit auf uns, denn im Bereich Monitoring ist man nie „fertig“. Wir werden unser Monitoring immer wieder auf neue Technologien anpassen müssen und deutlich mehr automatisieren müssen als wir es aktuell noch tun. Komplexere Anforderungen müssen genauso monitorbar sein wie Standardabfragen. Dazu müssen wir die Systeme immer weiter optimieren und dürfen uns auch nicht scheuen neue Tools einzusetzen. Aktuell arbeiten wir hart daran neue Technologien wie Kubernetes in unsere Cloud zu integrieren. Aus diesem Grund testen wir parallel zur Produktentwicklung mit unseren Tools, aber auch mit neuen wie Prometheus oder Consul, wie wir eine Kubernetes-Architektur in Zukunft monitoren können. Denn mit jedem neuen Produkt ergeben sich auch neue Anforderungen an das Monitoring. Man sieht also relativ schnell, dass uns im Bereich Monitoring nicht langweilig wird und wir aufgrund interner sowie externer Anforderungen immer wieder vor neue spannende Herausforderungen gestellt werden. Denn auch unsere Kunden kommen immer wieder mit wirklich spannenden neuen Themen und Projekten auf uns zu.
ML: Vielen Dank für das nette Gespräch.
JPH: Sehr gerne!