Wie unterscheidet sich die Aggregation von Metriken von der Log-Aggregation? Können Protokolle keine Metriken enthalten? Können Log-Aggregationssysteme nicht dasselbe tun wie Metrik-Aggregationssysteme?

Diese Fragen höre ich oft. Ich habe auch schon Anbieter gesehen, die ihr Log-Aggregationssystem als die Lösung für alle Beobachtungsprobleme angepriesen haben. Die Log-Aggregation ist ein wertvolles Werkzeug, aber normalerweise kein gutes Werkzeug für Zeitreihendaten.

Ein paar wertvolle Funktionen in einem System zur Aggregation von Zeitreihenmetriken sind das regelmäßige Intervall und das Speichersystem, das speziell für Zeitreihendaten angepasst ist. Das regelmäßige Intervall ermöglicht es einem Benutzer, echte mathematische Ergebnisse konsistent abzuleiten. Wenn ein Log-Aggregationssystem Metriken in einem regelmäßigen Intervall sammelt, kann es potenziell auf dieselbe Weise funktionieren. Das Speichersystem ist jedoch nicht für die Arten von Abfragen optimiert, die für ein System zur Aggregation von Metriken typisch sind. Die Verarbeitung dieser Abfragen erfordert mehr Ressourcen und Zeit bei der Verwendung von Speichersystemen, die in Tools zur Protokollaggregation zu finden sind.

Wir wissen also, dass ein System zur Protokollaggregation wahrscheinlich nicht für Zeitreihendaten geeignet ist, aber wofür ist es dann gut? Ein Log-Aggregationssystem eignet sich hervorragend für die Erfassung von Ereignisdaten. Dabei handelt es sich um unregelmäßige Aktivitäten, die von Bedeutung sind. Ein Beispiel wären Zugriffsprotokolle für einen Webdienst. Diese sind wichtig, weil wir wissen wollen, wer wann auf unsere Systeme zugreift. Ein weiteres Beispiel wäre ein Anwendungsfehler – da es sich nicht um einen normalen Betriebszustand handelt, kann er bei der Fehlersuche von Nutzen sein.

Eine Handvoll Regeln für die Protokollierung:

• DO einen Zeitstempel enthalten
• DO in JSON formatieren
• NICHT unbedeutende Ereignisse protokollieren
• DO alle Anwendungsfehler protokollieren
• vielleicht Warnungen protokollieren
• DO die Protokollierung einschalten
• DO Meldungen in einer für Menschenlesbare Form schreiben
• Keine Informationsdaten in der Produktion protokollieren
• Nichts protokollieren, was ein Mensch nicht lesen oder darauf reagieren kann

Cloud-Kosten

Bei der Untersuchung von Tools zur Protokollaggregation kann die Cloud eine attraktive Option sein. Sie kann jedoch mit erheblichen Kosten verbunden sein. Protokolle stellen eine große Datenmenge dar, wenn sie über Hunderte oder Tausende von Hosts und Anwendungen hinweg aggregiert werden. Das Aufnehmen, Speichern und Abrufen dieser Daten ist in Cloud-basierten Systemen teuer.

Als Anhaltspunkt für ein reales System ergibt eine Sammlung von etwa 500 Knoten mit ein paar hundert Anwendungen 200 GB Protokolldaten pro Tag. Es gibt wahrscheinlich Raum für Verbesserungen in diesem System, aber selbst eine Reduzierung um die Hälfte kostet bei vielen SaaS-Angeboten fast 10.000 US-Dollar pro Monat. Dabei werden die Daten oft nur 30 Tage lang aufbewahrt, was nicht sehr lang ist, wenn man sich die Entwicklung der Daten im Jahresvergleich ansehen will.

Dies soll nicht von der Verwendung dieser Systeme abraten, da sie sehr wertvoll sein können – vor allem für kleinere Unternehmen. Es geht vielmehr darum, darauf hinzuweisen, dass erhebliche Kosten entstehen können, und dass es entmutigend sein kann, wenn diese erkannt werden. Der Rest dieses Artikels konzentriert sich auf Open-Source- und kommerzielle Lösungen, die selbst gehostet werden.

Tool-Optionen

ELK

ELK, kurz für Elasticsearch, Logstash und Kibana, ist das beliebteste Open-Source-Tool für die Protokollaggregation auf dem Markt. Es wird von Netflix, Facebook, Microsoft, LinkedIn und Cisco verwendet. Die drei Komponenten werden alle von Elastic entwickelt und gepflegt. Elasticsearch ist im Wesentlichen eine NoSQL-Implementierung der Lucene-Suchmaschine. Logstash ist ein Log-Pipeline-System, das Daten einlesen, umwandeln und in einen Speicher wie Elasticsearch laden kann. Kibana ist eine Visualisierungsschicht auf Elasticsearch.

Vor einigen Jahren wurden Beats eingeführt. Beats sind Datensammler. Sie vereinfachen den Prozess der Datenübergabe an Logstash. Anstatt die korrekte Syntax jedes Protokolltyps verstehen zu müssen, kann ein Benutzer einen Beat installieren, der NGINX-Protokolle oder Envoy-Proxy-Protokolle korrekt exportiert, so dass sie in Elasticsearch effektiv genutzt werden können.

Bei der Installation eines ELK-Stacks auf Produktionsebene werden möglicherweise einige andere Komponenten wie Kafka, Redis und NGINX einbezogen. Außerdem ist es üblich, Logstash durch Fluentd zu ersetzen, worauf wir später noch eingehen werden. Dieses System kann sehr komplex sein, was in der Anfangszeit zu vielen Problemen und Beschwerden geführt hat. Diese wurden inzwischen weitgehend behoben, aber es ist immer noch ein komplexes System, so dass Sie es vielleicht nicht ausprobieren möchten, wenn Sie ein kleineres Unternehmen sind.

Das heißt, es gibt Dienste, so dass Sie sich darüber keine Sorgen machen müssen. Logz.io führt es für Sie aus, aber der Listenpreis ist ein wenig hoch, wenn Sie viele Daten haben. Natürlich sind Sie wahrscheinlich kleiner und haben vielleicht nicht so viele Daten. Wenn Sie sich Logz.io nicht leisten können, könnten Sie sich etwas wie AWS Elasticsearch Service (ES) ansehen. ES ist ein Service, den Amazon Web Services (AWS) anbietet und der es sehr einfach macht, Elasticsearch schnell zum Laufen zu bringen. Es gibt auch Tools, mit denen alle AWS-Protokolle über Lambda und S3 in ES übertragen werden können. Dies ist eine viel billigere Option, aber es ist ein gewisses Maß an Verwaltung erforderlich und es gibt einige Einschränkungen.

Elastic, die Muttergesellschaft des Stacks, bietet ein robusteres Produkt, das das offene Kernmodell verwendet, das zusätzliche Optionen für Analysetools und Berichte bietet. Es kann auch auf der Google Cloud Platform oder AWS gehostet werden. Dies könnte die beste Option sein, da diese Kombination aus Tools und Hosting-Plattformen eine kostengünstigere Lösung als die meisten SaaS-Optionen darstellt und dennoch einen hohen Mehrwert bietet. Dieses System könnte effektiv ein SIEM-System (Security Information and Event Management) ersetzen bzw. Ihnen dessen Funktionen zur Verfügung stellen.

Der ELK-Stack bietet mit Kibana ebenfalls großartige Visualisierungstools, aber es fehlt eine Alarmierungsfunktion. Elastic bietet mit dem kostenpflichtigen X-Pack-Add-on eine Alarmierungsfunktion, aber für das Open-Source-System ist nichts eingebaut. Yelp hat eine Lösung für dieses Problem entwickelt, die ElastAlert heißt, und es gibt wahrscheinlich noch andere. Diese zusätzliche Software ist ziemlich robust, erhöht aber die Komplexität eines ohnehin schon komplexen Systems.

Graylog

Graylog hat in letzter Zeit an Popularität gewonnen, aber seinen Anfang nahm es, als Lennart Koopmann es im Jahr 2010 entwickelte. Zwei Jahre später wurde ein Unternehmen mit demselben Namen gegründet. Trotz seiner zunehmenden Nutzung liegt es noch weit hinter dem ELK-Stack zurück. Das bedeutet auch, dass es weniger von der Community entwickelte Funktionen hat, aber es kann die gleichen Beats verwenden, die auch der ELK-Stack nutzt. Graylog hat in der Go-Gemeinschaft mit der Einführung des in Go geschriebenen Graylog Collector Sidecar an Ansehen gewonnen.

Graylog verwendet Elasticsearch, MongoDB und den Graylog Server unter der Haube. Dadurch ist es genauso komplex wie der ELK-Stack, vielleicht sogar ein bisschen mehr. Die Open-Source-Version von Graylog verfügt jedoch über eine integrierte Warnfunktion sowie über einige andere bemerkenswerte Funktionen wie Streaming, Rewriting von Nachrichten und Geolokalisierung.

Die Streaming-Funktion ermöglicht die Weiterleitung von Daten an bestimmte Streams in Echtzeit, während sie verarbeitet werden. Mit dieser Funktion kann ein Benutzer alle Datenbankfehler in einem einzigen Stream und Webserverfehler in einem anderen Stream sehen. Warnmeldungen können sogar auf diesen Streams basieren, wenn neue Elemente hinzugefügt werden oder wenn ein Schwellenwert überschritten wird. Latenz ist wahrscheinlich eines der größten Probleme bei Systemen zur Protokollaggregation, und Streams beseitigen dieses Problem in Graylog. Sobald das Protokoll eingeht, kann es über einen Stream an andere Systeme weitergeleitet werden, ohne vollständig verarbeitet zu werden.

Die Funktion zum Umschreiben von Nachrichten verwendet die Open-Source-Regel-Engine Drools. Damit können alle eingehenden Nachrichten anhand einer benutzerdefinierten Regeldatei ausgewertet werden, so dass eine Nachricht ausgelassen (Blacklisting genannt), ein Feld hinzugefügt oder entfernt oder die Nachricht geändert werden kann.

Das coolste Feature ist vielleicht die Geolokalisierungsfunktion von Graylog, die das Aufzeichnen von IP-Adressen auf einer Karte unterstützt. Dies ist eine ziemlich verbreitete Funktion, die auch in Kibana verfügbar ist, aber sie bietet einen großen Mehrwert – vor allem, wenn Sie dieses System als SIEM-System verwenden möchten. Die Geolokalisierungsfunktionalität wird in der Open-Source-Version des Systems bereitgestellt.

Graylog, das Unternehmen, erhebt Gebühren für den Support der Open-Source-Version, wenn Sie dies wünschen. Es bietet auch ein offenes Kernmodell für seine Enterprise-Version an, das Archivierung, Audit-Protokollierung und zusätzlichen Support bietet. Es gibt nicht viele andere Optionen für Support oder Hosting, so dass Sie wahrscheinlich auf sich allein gestellt sind, wenn Sie nicht Graylog (das Unternehmen) verwenden.

Fluentd

Fluentd wurde bei Treasure Data entwickelt und die CNCF hat es als Inkubationsprojekt angenommen. Es wurde in C und Ruby geschrieben und wird von AWS und Google Cloud empfohlen. Fluentd ist in vielen Installationen ein gängiger Ersatz für Logstash geworden. Es fungiert als lokaler Aggregator, der alle Knotenprotokolle sammelt und sie an zentrale Speichersysteme weiterleitet. Es handelt sich nicht um ein Log-Aggregationssystem.

Es verwendet ein robustes Plugin-System, um schnelle und einfache Integrationen mit verschiedenen Datenquellen und Datenausgaben zu ermöglichen. Da es über 500 Plugins gibt, sollten die meisten Ihrer Anwendungsfälle abgedeckt sein. Falls nicht, ist dies eine gute Gelegenheit, einen Beitrag zur Open-Source-Gemeinschaft zu leisten.

Fluentd wird häufig in Kubernetes-Umgebungen eingesetzt, da es nur wenige Megabyte Speicher benötigt und einen hohen Durchsatz bietet. In einer Umgebung wie Kubernetes, in der jeder Pod einen Fluentd-Sidecar hat, steigt der Speicherverbrauch mit jedem neu erstellten Pod linear an. Die Verwendung von Fluentd wird die Systemauslastung drastisch reduzieren. Dies ist ein häufiges Problem bei Tools, die in Java entwickelt wurden und für die Ausführung eines Pods pro Knoten vorgesehen sind, bei denen der Speicher-Overhead kein großes Problem darstellt.