© alphaspirit, 123RF

Die Zeiten, in denen Nagios & Co. ein Synonym für Monitoring waren, sind längst vorbei – Sumo Logic tritt als Monitoringdienst aus der Cloud für die Cloud an, der auch Daten zur Performance liefern kann.

Dass Monitoring von Cloudumgebungen komplizierter als das konventioneller Setups ist, versteht sich von selbst. Grund dafür ist vor allem die riesige Menge von Daten. Wo in klassischen Setups ein paar Dutzend oder in Ausnahmefällen ein paar Hundert Server ihren Dienst verrichten, sind es in Clouds schnell Tausende Systeme. Und weil die Cloud nahtlos wachsen will, muss das Monitoring mitwachsen.

Die Überwachung der Hardware einer Cloud ist auch nicht die alleinige Herausforderung. Kundenanwendungen wandern als klassische Applikationen oder als schicke Cloud-native-Konstruktion in die Cloud. Und diese Applikationen sind natürlich ebenso zwangsläufig zu überwachen wie das Blech selbst. Viele Cloudanbieter winken an dieser Stelle ab. Kein Wunder, ihr Ziel ist es ja gerade, vom IT-Dienstleister zum Anbieter einer Plattform zu werden, in der Kunden Ressourcen bedarfsgerecht abrufen.

Wenn sich die Rollenverteilung so verändert, hat der Betreiber der Plattform allerdings nicht notwendigerweise auch etwas mit der Überwachung seiner Kunden und ihrer Dienste zu tun – das Monitoring ist dann eher das Problem der Cloudnutzer. Dabei bieten AWS, Azure & Co. manches Werkzeug, über das sich bestimmte Daten erheben und auch grafisch darstellen lassen.

Verschiedene Aspekte bleiben dabei allerdings außen vor, die für die Setups jedoch sehr wichtig sind. Sumo Logic will an dieser Stelle die eierlegende Wollmilchsau für den Kunden sein und verspricht Monitoring, Loganalyse, Security-Funktionalität und Devops-Helferlein aus ein und derselben Hand anzubieten. Das Linux-Magazin fühlt Sumo Logic auf den Zahn: Hält die Lösung, was ihr Hersteller verspricht? Welche Features hat das Werkzeug mit an Bord, wie ist es benutzbar? Dieser Artikel liefert Antworten.

Was nötig ist

Glaubt man dem Hersteller, liefert er alles, was der Admin im Cloudkontext braucht, aus einer Hand. Um Marketing von Realität zu trennen, ist es aber nötig, zunächst zu definieren, was der Admin denn tatsächlich in seinem Setup will – und hier gilt, dass sich für Setups in der Cloud etliche Unterschiede zu konventionellen Setups ergeben. Der größte ist die Dynamik von virtuellen Umgebungen in der Cloud. Konventionelle Setups baut der ausführende Anbieter meist nach einem festen Plan mit zuvor definierten Werten für die Anzahl von Knoten eines bestimmten Typs.

In der Cloud funktioniert das so nicht, denn hier spielen Automation und Orchestrierung eine große Rolle. Sehr beliebt bei vielen Cloudanwendern ist etwa die Möglichkeit, die Größe eines Setups auf Basis der anliegenden Last automatisch zu skalieren. Wenn also mehr Last gegeben ist, starten die API-Dienste der Cloud nach festgelegten Regeln neue VMs. Umgekehrt gilt das Gleiche: Ist gerade wenig zu tun, schaltet die Cloud automatisch Instanzen etwa von App-Servern ab, um Kosten zu sparen.

Für Monitoring-Systeme ist das eine große Herausforderung. Denn anders als in konventionellen Umgebungen können sie sich in Cloudsetups nicht auf eine quasi unveränderliche Liste von zu überwachenden Systemen berufen. Stattdessen gilt: Kommt ein neuer, von der Cloud automatisch gestarteter Knoten ins Spiel, sollte er automatisch auch Teil des Monitorings werden.

Weitere Anforderungen machen dem Admin in virtuellen Umgebungen wie Clouds das Leben schwer. Um Themen wie Einbruchserkennung, Sicherheitsanalyse sowie Compliance-Tests kümmerten sich in konventionellen Setups meist die Anbieter. Wer sein Setup anhand der geltenden Cloud-Best-Practices gebaut hat und Automation und Orchestrierung nutzt, tut sich zumindest in Sachen Compliance leichter. Denn dann sind die letztlich in der Cloud ausgerollten Dienste ja in Containern verpackt. Und die wiederum fallen am Ende als Resultat eines ganzen CI/CD-Workflow schlüsselfertig aus der Klappe.

Andere Themen wie klassische Intrusion Detection oder Logfile-Analyse im Hinblick auf besondere Ereignisse müssen aber trotzdem passieren. Kaum ein Admin wird Freude daran haben, in seiner Cloud eine komplette ELK-Lösung (also Logstash, Elasticsearch, Kibana) samt SIEM-Komponente auszurollen. Denn dieses Vorhaben würde den Wartungsaufwand für die komplette Lösung auf einmal vervielfachen.

Ohne geht es aber auch nicht. Ganz gleich, ob Ereignisse sicherheitsrelevant sind oder potenziell Auswirkungen auf die Stabilität haben können, der Admin muss wissen, was los ist. Das klassische Zeitreihen-Monitoring, wie es etwa Prometheus liefert, ist keine Hilfe: Es kann eben nur eingehende Metrikdaten mit Sollwerten vergleichen und Forecasts zusammenzimmern; ein Ereignis des Typs “Eigenartige Zeile im Log, potenzieller Einbruch” lässt sich mit Prometheus nicht erkennen.

Was Sumo Logic verspricht

Genau an dieser Stelle kommt Sumo Logic http://1 ins Spiel. Der Hersteller gibt an, die Bedürfnisse von Admins virtueller Umgebungen verstanden zu haben, und will sie mit einer Art Schweizer Taschenmesser versorgen, um eben jene Arbeiten zu erledigen. Dazu kombiniert Hersteller Sumo Logic in seiner gleichnamigen Lösung eine Vielzahl verschiedener Funktionen.

Neben dem bereits erwähnten Monitoring und Trending auf Basis von Metrikdaten gehört zu Sumo Logic auch eine umfassende Integration in die Werkzeuge der großen Public-Cloud-Anbieter. Im Dialog mit jenen kann Sumo Logic zu einer Art Makler werden, der die verschiedenen Dienste der Umgebungen bestmöglich kombiniert.

Hinzu gesellen sich umfassende Features zur Überwachung und Analyse von Logdateien – das gilt sowohl für Ereignisse mit Ausfallpotenzial als auch für sicherheitsrelevante Ereignisse. Last but not least gehört zu Sumo Logic eine CI/CD-Umgebung, die den Bau von Diensten für die Cloud einfach machen und standardisieren soll. Compliance von Anfang an lautet hier offensichtlich das Motto. Im Folgenden geht dieser Artikel auf die verschiedenen Features von Sumo Logic ein und stellt sie detailliert vor.

Die technische Grundlage

Sumo Logic beschreibt sich als “Monitoring aus der Cloud für die Cloud” – und damit ist im Grunde schon klar, wie das Produkt sich positioniert: Im Gegensatz zu den klassischen Monitoring-Lösungen ist Sumo Logic eine One-Click-App, die der Anbieter selbst hostet.

Wer Sumo Logic betreiben will, bekommt entsprechend vom Anbieter die Software nicht per Download und muss sich um das Setup selbst kümmern. Stattdessen registriert sich der Admin einfach bei Sumo Logic auf der Website [1] und hat in wenigen Minuten eine grundlegende Sumo-Logic-Umgebung zusammengeklickt. Das geht leicht von der Hand und erspart es ihm auch, erst stundenlang Dokumentation zu wälzen.

Nicht zuletzt senkt dieser Ansatz auch die Kosten, die allen entstehen, die sich selbst mit Sumo Logic beschäftigen. Denn wer sich selbst Lösungen wie ELK oder Prometheus bauen möchte, tut das entweder auf echtem Blech mit viel Bumms oder in potenten VMs in Clouds. Beides ist allerdings nicht günstig. Da ist die 30-tägige Testphase bei Sumo Logic gleich um so verlockender.

Es ist aber natürlich noch nicht damit getan, sich nur einen Sumo-Account anzulegen. Der ist zwar schön, aber ohne Lieferanten für tatsächliche Nutzdaten sinnlos. Zu Sumo Logic gehört deshalb auch eine auf den Namen Collector getaufte Komponente, die auf den Zielsystemen laufen muss.

Komplementär zum Collector gibt es eine zweite Art von Suchwerkzeug, den Hosted Collector. Wie der Name vermuten lässt, läuft er nicht auf einem System innerhalb des eigenen Setups. Stattdessen betreibt Sumo Logic die Hosted Collectors selbst als Teil der eigenen Infrastruktur. Sie besorgen sich auf Zuruf des Nutzers Werte des Zieldienstes, etwa Amazon S3.

Collectors und Sourcen

Der von Sumo Logic bereitgestellte Collector funktioniert ähnlich, wie man es von den Agents anderer Lösungen kennt. Das Programm steht sowohl für Windows als auch für Mac OS bereit; wer es auf Linux betreiben möchte, bekommt es in Form fertiger RPM- oder DEB-Pakete. Die Installation des Collectors ist in den meisten Fällen also sehr simpel. Etwas komplizierter ist es, den Collector nach der Installation einzurichten.

Hier spielt die Sumo-Logic-Nomenklatur eine wichtige Rolle: Ein Collector auf einem Zielsystem sorgt dafür, dass Daten aus verschiedenen Quellen (Sources) ihren Weg hin zu Sumo Logic finden. Eine Quelle ist dabei im Normalfall ein spezifischer Dienst auf dem Zielsystem, dessen Metrikdaten Sumo Logic abgreift. Läuft lokal etwa ein Docker oder ein Kubernetes, kann der Admin das im Sumo Logic Collector ganz einfach eingeben – und schon erhebt Sumo Logic die entsprechenden Daten.

Wichtig ist die Art und Weise der Namespace-Verwaltung: Der Nutzer legt fest, unter welchen Namensschildern Daten zu speichern und später zu analysieren sind. Bevor der Admin mit Sumo zu Werke geht, empfiehlt es sich also, sich mit diesem Thema in sehr ausführlicher Weise zu beschäftigen – denn wenn er die Daten nicht in der Struktur in Sumo Logic ablegt, die er später beim Anzeigen bunter Graphen erwartet, hat er die doppelte Arbeit.

Die Zahl der vom Collector unterstützten Betriebssysteme ist beachtlich, die Zahl der lokalen Sourcen, die er abfrühstücken kann, ebenfalls. Für fast jeden Vertreter der modernen hippen Applikationen aus der Cloud-native-Welt wie eben Kubernetes finden sich Datensammler. Aber auch klassische Anwendungen wie Apache haben die Entwickler von Sumo nicht vergessen.

Bonuspunkte gibt es übrigens dafür, dass Sumo Logic sich bei Bedarf auch in bereits bestehende Sammelagenten einbinden lässt. Wer also bereits ein Fluentd betreibt, kann dort das Sumo-Logic-Output-Plugin aktivieren. Das führt ganz automatisch dazu, dass die erhobenen Daten und Metriken in Sumo Logic landen.

Push statt Pull

Über die Frage, ob Metrik- und Log-Sammler dem Push- oder dem Pull-Prinzip folgen sollten, entbrennt unter Admins regelmäßig ein Glaubenskrieg. Das hier vorgestellte Sumo Logic folgt dem Push-Prinzip, was praktischen Überlegungen geschuldet sein dürfte: Wollte Sumo die anfallenden Daten von den Zielsetups abholen, müssten die dortigen Firewallregeln entsprechend aufgebohrt sein. Im schlimmsten Fall müssten sogar Maschinen mit dem Internet verbunden werden, die dort eigentlich gar nicht sein sollen – in Summe also kein guter Ansatz (Abbildung 1).

Abbildung 1: Sumo Logic folgt dem Push-Prinzip; die Collectors auf den Systemen senden ihre Daten direkt zu Sumo Logic in die Cloud.

In die andere Richtung ist der Aufwand geringer: Die Systeme, die ihre Daten bei Sumo Logic loswerden sollen, brauchen nur eine Netzwerkverbindung. Zudem sollte keine Firewall vorhanden sein, die ausgehenden Traffic filtert – das ist in virtuellen Umgebungen innerhalb der Cloud aber ohnehin selten.

Praktisch am Push-Prinzip ist auch, dass sich die Integration auf Seite des Clients problemlos in einen CI/CD-Workflow und Automation integrieren lässt. Ein Container-Abbild etwa, aus dem in Kubernetes Applikationsserver werden, muss lediglich die benötigten Collector-Dienste an Bord haben und die richtige Konfigurationsdatei. Automatisch beginnt es dann nach dem Deployment des Containers mit dem Einsenden von Metrikdaten. Damit der Versand sicher ist, nutzt Sumo Logic ein Verschlüsselungssystem auf Basis eines API-Key: Nur mit einem solchen Schlüssel kommt der Nutzer per API überhaupt an Sumo Logic und die dortigen Daten heran.

Es gibt übrigens noch einen weiteren Weg für Sumo Logic, Daten zu beschaffen: Das Programm kann auch im Tandem mit den Metrikdiensten der großen Public Clouds operieren, etwa bei Amazons AWS oder Azure. Die dort nutzbaren Daten etwa zur Gesamtzahl der vorhandenen virtuellen Maschinen pro Setup sind ja am Ende auch nur Metrikdaten, die Sumo Logic grafisch aufbereiten kann. Es ist an dieser Stelle deutlich erkennbar, dass Sumo Logic die eierlegende Wollmilchsau in Sachen Monitoring sein will, die alle anderen Werkzeuge überflüssig macht (Abbildung 2).

Abbildung 2: Sumo Logic unterscheidet zwischen eingehenden Logs und Metriken und errechnet daraus ein Digest, das das Pricing beeinflusst.

Was Sumo Logic sammelt und auswertet

Da stellt sich freilich die Frage, ob der Anbieter diesem Anspruch gerecht wird oder nicht. Fakt ist: Das Programm kann über seinen eigenen Collector und die Fremd-Einsammler, die es nahtlos einbinden kann, eine riesige Menge von verschiedenen Datentypen und Daten sammeln. Viele Sources fallen in die Riege der klassischen Metrikdaten-Quellen, die beispielsweise Prometheus auch liefern würde. Dabei findet jede Menge Zahlen ihren Weg in Sumo Logic, das diese anschließend auswertet und grafisch aufbereitet.

Aber Sumo Logic kann eben noch mehr: Das Programm versteht sich auch auf den Umgang mit Logdateien und ist in der Lage, eingehende Logdaten zu speichern und – das ist viel wichtiger – zu analysieren. Wollte man Sumo Logic also mit Open-Source-Werkzeugen vergleichen, handelt es sich um eine Art Zwitter aus Prometheus auf der einen und einem ELK-Stack auf der anderen Seite. Dabei ist das Killer-Feature zweifellos die grafische Oberfläche des Werkzeugs, die sich intuitiv bedienen lässt, aber trotzdem Zugriff auf jedes noch so winzige Feature von Sumo Logic bietet.

Analyse mit fertigen Apps

Wer schon mal ein Prometheus oder einen ELK-Stack aufgesetzt hat, der weiß: Es ist nur die eine Hälfte der Miete, alle beteiligten Komponenten so unter einen Hut zu bekommen, dass sie funktionieren wie gewünscht. Wer etwa Prometheus sowie Grafana kombiniert, hat am Ende zwar eine funktionale Datenquelle – Prometheus in Grafana.

Doch das bringt erst mal nichts. Denn im nächsten Schritt ist es die ziemlich lästige Aufgabe für den Admin, die vorhandenen Metrikdaten aus Prometheus so in einzelne Dashboards zu verpacken, dass er mit ihnen tatsächlich auch etwas anfangen kann.

Als kombinierte Lösung für Monitoring, Alerting und Trending sowie Sammeln von Logdateien steht Sumo Logic freilich vor demselben Problem. Die Lösung, die der Hersteller sich überlegt hat, ist in mancherlei Hinsicht sicherlich mit dem Open-Source-Ansatz vergleichbar: Für typische Standardaufgaben bieten sich so genannte Apps an. Die gibt es bei Grafana auch, dort heißen sie Dashboards und können im Rahmen einer Börse auf der Grafana-Website auch publik gemacht werden.

Apps für Sumo Logic können jedoch mehr als Dashboards in Grafana, denn sie bringen neben der Möglichkeit zur optischen Aufbereitung von Daten auch einen großen Teil der Logik mit, um eingehende Messwerte und Log-Einträge zu verarbeiten und zu analysieren. Man könnte die Apps also als das Herz der Lösung bezeichnen, und Sumo Logic tritt gleich mit einer riesigen Summe verfügbarer Apps an.

Darunter finden sich viele Apps, die so zu erwarten wären, etwa jene für Mongo DB oder den Microsoft-SQL-Server. Aber auch Kubernetes-Betreiber kommen in den Genuss einer fertigen App – und für Clouddienste wie Amazon S3, Salesforce oder Google Apps haben die Entwickler sich etwas ausgedacht. Auch für klassische Linux-Anwendungen gibt es fertige Apps, etwa für Nginx, Apache (Abbildung 3), Varnish oder die verschiedenen Heroku-Dienste [2].

Abbildung 3: Apps sind vorgefertigte Sammlungen aus Dashboards und Suchen für eine Reihe von Werkzeugen, im Beispiel Apache.

Der Vorteil bei der Verwendung einer App liegt auf der Hand: Hat der Admin in der Sumo-Logic-Oberfläche die logische Verbindung zwischen einer App und eingehenden Daten einer Quelle hergestellt, erfolgt der Rest automatisch. Vorgefertigte Dashboards füllt Sumo Logic dann mit konkreten Daten, vorgefertigte Suchen im Datenschatz von Sumo Logic erleichtern es, bestimmte Informationen zu finden, etwa spezielle Logzeilen.

Im Test machte sich die Funktion sehr gut: In kürzester Zeit war es mit Sumo Logic möglich, umfassende Metrikdaten aus Apache zu lesen. Ein vergleichbares Setup mit Prometheus und ELK hätte mehr Zeit in der Dimension von Zehnerpotenzen verschlungen.

Dass es die Apps gibt, hindert den Admin übrigens nicht daran, die vorhandenen Daten mit eigenen Suchen zu malträtieren und eigene Dashboards als Zusatz zu den bestehenden zu definieren. Apps sind aber zweifellos ein gutes Angebot, um schnell zu einem funktionalen Ergebnis zu kommen.

Besseres SIEM ohne SIEM

Klar: Wer Sumo Logic in seinem Setup flächendeckend zum Einsatz bringt, der hat früher oder später alle relevanten Metrikdaten und Log-Einträge seines Setups in der Lösung. Der vorhandene Datenschatz ist also beträchtlich. Kein Wunder also, dass die Sumo-Logic-Leute auf die Idee gekommen sind, ihn auch für sicherheitsbezogene Themen anzuzapfen.

Explizit erwähnen sie SIEM. Das ist ja eigentlich ein aus der “alten” Welt bekanntes Prinzip, um das “Security Information and Event Management” eines Setup zu implementieren. Und in fast allen größeren Unternehmen findet sich irgendwo eine Policy, die umfassende SIEM-Funktionalität zwingend vorschreibt.

In virtuellen Cloudumgebungen steht SIEM allerdings vor dem Problem, das auch konventionelle Monitoring-Lösungen haben: Die Setups sind zu dynamisch und flexibel, um mit klassischen SIEM-Werkzeugen noch gut zu funktionieren. Sumo Logic nähert sich dem Problem pragmatisch: Wer ohnehin schon auf alle relevanten Daten Zugriff hat, so lautet die Maxime, kann SIEM-Funktionalität ja auch auf der Sumo-Logic-Ebene implementieren.

Entsprechend finden sich in Sumo Logic auch diverse Funktionen mit Sicherheitsbezug und passende Apps, um bei Incidents automatisch per Alarmfunktion den Admin zu informieren. Alarming beherrscht Sumo aber auch für reguläres Monitoring oder für die Überwachung von Logs, Abbildung 4.

Abbildung 4: SIEM funktioniert in Clouds nur bedingt. Weil Sumo Logic aber ohnehin alle Daten hat, bietet es ähnliche Features.

Weil Sumo die Security-Funktionalität zentral steuern kann, aktualisiert es etwa die Datenbanken bekannter Bedrohungen zentral und regelmäßig, ohne dass der Admin sich darum im Detail kümmern müsste. Auch hier fällt im direkten Vergleich mit einer selbst geklöppelten Lösung auf, dass Sumo Logic dem Admin sehr schnell zu sinnvoller Funktionalität verhilft. Letztlich ist ja genau das auch das zentrale Versprechen der Anwendung, nämlich dass das Produkt eine kürzere Time to Value ermöglicht.

Werkzeuge für CI und CD

Besonders stolz sind die Entwickler übrigens darauf, dass sie mit ihren Werkzeugen bestehende CI/CD-Architekturen unterstützen. Dabei bietet Sumo Logic selbst ausdrücklich gar kein CI/CD-Framework an – das wäre im Hinblick auf die diversen fertigen Systeme am Markt auch nicht hilfreich. Was Sumo Logic aber durchaus kann: Metrikdaten und Statistiken von solchen Umgebungen einsammeln und analysieren.

Das treibt manchmal eigenartige Blüten, etwa wenn Sumo Logic Git-Verzeichnisse analysiert und die generelle Aktivität pro Repository erhebt – um Alarm zu schlagen, falls diese unter ein bestimmtes Limit fällt (Abbildung 5). Hier ist erkennbar, dass Sumo Logic ein amerikanisches Tool ist, denn was ein deutscher Betriebsrat zu einer solch minutiösen Überwachung zu sagen hätte, kann sich jeder ausmalen. Es gibt aber durchaus nützliche Funktionen in Sumo Logic im Hinblick auf CI- und CD-Werkzeuge, und in der Tat ist das Tool für Leiter von Entwicklerteams einen Blick wert.

Abbildung 5: Zu den eher grotesken Funktionen in Sumo Logic zählt die Option, ein Github-Repository zu überwachen.

Wer soll das bezahlen?

Am Ende stellt sich die Frage nach dem Preis. Sumo Logic verfolgt ein angenehm einfaches Verrechnungsmodell, das sich – ähnlich wie Splunk – an der Summe der übertragenen Daten orientiert. Das Modell kennt drei Stufen: In Sumo Free zahlt man gar nichts, darf aber maximal 500 MByte an Daten im Abrechnungszeitraum übertragen. Das reicht höchstens für kleine Setups. Zudem fehlt beim Free-Modell der Metrik-Sammeldienst, es gehen also ausschließlich Logdaten in Sumo Logic ein. Das ist beim Professional-Modell anders: Das schlägt mit 108 Dollar pro Monat und GByte an durchschnittlichen täglichen Daten (Abbildung 2) zu Buche und ist nur als Jahresvertrag verfügbar.

Wer SIEM-ähnliche Features oder Single-Sign-on mit Saml will, muss zur Enterprise-Variante greifen: Die kommt auf 180 Dollar pro GByte einer durchschnittlichen Tagesration pro Monat. Beide Pakete müssen jährlich bezahlt werden, andernfalls erhöhen sich die Preise um 22 beziehungsweise 36 Euro pro GByte. Das Enterprise-Paket umfasst alle Funktionen, die in Sumo Logic im Augenblick zur Verfügung stehen. Eine 30-tägige Trial-Variante steht dem Nutzer kostenlos zur Verfügung [3].

Fazit: Cooles Teil

Sumo Logic ist eine typische Cloudanwendung, deren Entwickler sich jedoch eine ganze Menge im Hinblick auf Systemadministration überlegt haben. Die Idee, das langwierige und schwerfällige Setup von Prometheus & Co. durch einen Clouddienst zu ersetzen, ist brillant. Und die Qualität von Sumo ist gut: Im Test funktionierte das Programm problemlos und ermöglichte es, dort schnell zu Lösungen zu kommen, wo der Admin andernfalls lange basteln müsste. Die Daten finden ihren Weg über Standardwerkzeuge zu Sumo Logic, die eingebauten Tools zur Analyse funktionieren gut und bieten echten Mehrwert.

Einen Wermutstropfen gibt es allerdings: Sumo Logic selbst ist in der Cloud gehostet, und zwar auf AWS. Die Firma ist ebenfalls ein amerikanisches Unternehmen. Flugs hebt die Website zwar hervor, wie gut man sich um das Thema Privacy kümmere – unter anderem lagern die in Sumo Logic gespeicherten Daten verschlüsselt in der Cloud. Das wird Unternehmen in Deutschland letztlich aber nicht darüber hinwegtäuschen, dass der lange Arm der US-Regierung in der Vergangenheit durchaus in solche Setups gereicht hat.

Mancher Admin wird also Sumo nicht nutzen dürfen, obwohl er es gern möchte. Wer sich um solche Probleme nicht kümmern muss, dem sei ein Test von Sumo Logic dringend empfohlen – es lohnt sich. (jcb)