Die Cloud sorgt in der IT für diverse Umwälzungen. Eine massive Änderung ist, dass sich klassische IT-Dienstleister heute immer öfter zu Plattformbetreibern wandeln, die ihren Kunden verschiedene As-a-Service-Angebote zur Verfügung stellen – oder virtuelle Hardware, um darauf eigene Dienste zu betreiben. So oder so nimmt die Zahl an Systemen, mit denen ein durchschnittlicher IT-Verantwortlicher es heute zu tun hat, kontinuierlich zu. Selbst einfache Virtualisierung sorgt bereits dafür, dass auf einem einzelnen Blech Dutzende virtuelle Instanzen laufen, die der Admin irgendwie unter Kontrolle bringen muss.
Dieser Wildwuchs an zu wartenden Systemen erhöht die Komplexität des gesamten Setups und macht es bei einem Ausfall nicht leichter, das Problem zu identifizieren. Denn statt ein paar Systemen sieht sich der Administrator heute üblicherweise weit verstreuten virtuellen Instanzen gegenüber, in denen Dienste nach dem Microservices-Prinzip laufen und untereinander munter Daten austauschen. Bei der Fehlersuche tummelt sich der IT-Verantwortliche im schlechtesten Fall auf etlichen Systemen gleichzeitig, indem er die dortigen Logs durchstöbert. Das ist weder effizient noch sonderlich zuverlässig. Und dass ein Admin vor dem Hintergrund des Stresses, den ein flächendeckender Ausfall auslöst, etwas übersieht, ist höchstwahrscheinlich.
Vor Jahren schon hat sich in der IT deshalb die Überzeugung durchgesetzt, anstelle vieler kleiner loggender Inseln brauche es eine zentrale Instanz, die sämtliche Logs eines Setups vorhält, indiziert und durchsuchbar macht. Praktisch gibt es im Augenblick zwei konkurrierende Ansätze am Markt, die dieses Prinzip umsetzen. Wer es sich leisten will greift zu Splunk und bekommt gut funktionierende, zentrale Logging-Fähigkeiten nach strikten Vorgaben. Wer das Geld sparen will oder für die eigene Umgebung mehr Flexibilität braucht, landet heute meist bei einer Mischung aus ElasticSearch, LogStash und Kibana,
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.