Auf dem Markt wird eine Vielzahl von Protokollierungssystemen angeboten - sowohl offene als auch proprietäre. Jeder von ihnen hat seine eigene Funktionalität, seine eigenen Vor- und Nachteile.
Heute haben wir beschlossen, unsere Erfahrungen bei der Auswahl eines Protokollierungssystems zu teilen und uns zu
erklären , warum wir bei ELK in
1cloud angehalten haben .
/ Pixabay / picupyourphoto / PDMinutentheorie
Bei der Umstellung auf die Produktion werden Anwendungen zu einer Art "Black Box". Ihre Arbeit muss ständig überwacht werden, um potenzielle Notsituationen zu verhindern und darauf zu reagieren und Engpässe zu erkennen.
Protokollierungssysteme sind ein unverzichtbares Werkzeug, das in diesem Prozess nicht vermieden werden kann. Durch eine detaillierte Analyse der gesammelten Daten ist es möglich, „Eingriffe“ in das Netzwerk zu identifizieren, nicht ordnungsgemäß konfigurierte Geräte zu identifizieren und umgehend Maßnahmen zu ergreifen. Die Protokollierung ist außerdem eine obligatorische Anforderung, wenn verschiedene Arten von Zertifizierungen wie PCI DSS bestanden werden.
Es gibt spezielle Frameworks für die Automatisierung von Protokollierungsprozessen: log4j, log4net, Retrace, Logback, Logstash und andere - es gibt viele davon. Ihre Protokollierungstools verfügen über separate Entwicklungstools, z. B. JDK -
es gibt java.util.logging . Natürlich ist die Funktionalität verschiedener Protokollierungswerkzeuge unterschiedlich, und die erforderlichen Funktionen müssen basierend auf den Anforderungen des Unternehmens ausgewählt werden. Es gibt jedoch eine Reihe allgemeiner Punkte, die bei der Auswahl eines Systems zur Analyse von Protokollen beachtet werden sollten.
Benutzerfreundlichkeit und Community-Größe
Einfachheit ist eine der Schlüsselkomponenten bei der Auswahl eines Protokollierungssystems. Alle Entwickler im Team arbeiten mit Protokoll-Frameworks. Daher sollte die Erfahrung mit diesem Tool positiv sein und die Protokollanalyse nicht zu einem Albtraum machen. Die Framework-API sollte intuitiv sein, damit jeder, der zuvor noch nicht mit dem System gearbeitet hat, schnell herausfinden kann, wie es organisiert und konfiguriert ist.
Wenn wir das Open-Source-Protokollierungssystem betrachten, ist es sinnvoll, die Community zu bewerten, die sich um es herum gebildet hat. Dazu können Sie untersuchen, wie oft es auf speziellen Plattformen (
Stack Overflow ) sowie in speziellen Threads,
beispielsweise auf Reddit, erwähnt wird . Sehen Sie sich optional die Beliebtheit des Projekts auf GitHub (die Anzahl der Sterne) an und sehen Sie, wie oft es in verschiedene Werkzeugsammlungen im Netzwerk (
wie diese ) eingegeben wird. Je größer die Community, desto höher ist natürlich die Wahrscheinlichkeit, dass Ihnen bei unvorhergesehenen Schwierigkeiten geholfen wird.
Bei der Auswahl der proprietären Protokollierungssysteme lohnt es sich zunächst, die Geschwindigkeit der Antworten und die Angemessenheit des Support-Service der ausgewählten Lösung sowie deren Preis zu betrachten.
Die Möglichkeit, "verschiedene" Protokolle zu sammeln
Nicht alle Protokollierungsplattformen sind in der Lage, eine große Datenmenge zu verarbeiten und vollständige Informationen über die verwendeten Systeme bereitzustellen.
Bevor Sie sich für eine Lösung entscheiden, sollten Sie entscheiden, welche Protokolle Sie sammeln möchten: HTTP-Protokolle (helfen, das Verhalten der Benutzer auf der Site zu verstehen), API-Protokolle (ermöglichen die Bewertung der von der API am häufigsten angeforderten Dienste), Fehlerprotokolle und das einfache Aufzeichnen von Änderungen System (ggf. Engpässe anzeigen).
Skalierbarkeit
Das Protokollierungstool sollte Protokolle von jeder Systemkomponente sammeln und an einem Ort darauf zugreifen. Wenn das System nicht für die Skalierung geeignet ist, sinkt die Qualität der Protokollanalyse.
Wir in 1cloud haben ursprünglich MS SQL für die Protokollierung verwendet. Mit zunehmender Anzahl von Clients und Diensten (zum Beispiel haben
wir zuletzt
Geräte im Rechenzentrum von Minsk bereitgestellt und
die Unterstützung für IPv6 hinzugefügt ) haben wir geografisch verteilte Infrastrukturkomponenten entwickelt, die keinen Zugriff auf die Datenbank hatten. Eine unserer Hauptaufgaben bestand darin, die Analyse von Protokollen von einem einzigen Ort aus aufrechtzuerhalten.
1cloud Protokollierungssystem
Wie bereits erwähnt, wurde MS SQL zum Speichern von Protokollen in 1cloud und log4net zum Aufzeichnen verwendet. Und dies führte zu gewissen Schwierigkeiten für uns. Aufgrund geografisch verteilter Komponenten ist es unmöglich geworden, die Netzwerkkonnektivität mit der Datenbank aufrechtzuerhalten und einen einzigen Punkt für die Analyse bereitzustellen.
Gleichzeitig führten eine große Anzahl von Protokollen und die Unfähigkeit, Indizes für alle Felder zu erstellen, nach denen gesucht werden muss, zu einer übermäßigen Vereinfachung der Protokollanalyse - wir mussten die Funktionalität aus Gründen der Leistung aufgeben.
Um dieses Problem zu lösen und Skalierbarkeit zu gewährleisten, haben wir ein neues Protokollierungssystem eingeführt. Insgesamt haben wir mehr als fünfzig verschiedene Lösungen untersucht und vier identifiziert, die unsere Anforderungen vollständig erfüllen:
- einzelner Ort zum Speichern von Protokollen;
- ggf. horizontale Skalierung des Systems;
- Verarbeitung großer Datenmengen;
- leistungsstarkes Protokollanalysesystem.
Diese vier Lösungen sind: Fluentd, Graylog, Logalyse und Logstash.
Die Lösung hat 9,2 Tausend Sterne auf
GitHub . Logstash ist unter der Apache 2.0-Lizenz lizenziert und Teil des ELK-Stacks. Es hat eine große Anzahl von Plugins (
es gibt ungefähr 250 davon auf GitHub). Es funktioniert unter Windows und Linux und hat eine hohe Leistung, die praktisch unabhängig von Datenmengen ist.
Mit dem System
können Sie Ereignisse von Workstations, Firewalls, Routern und Switches schnell überprüfen und analysieren. Dies liegt an der Tatsache, dass keine "Normalisierung" von Ereignissen erforderlich ist.
Es versteht sich jedoch, dass dies eine "nackte" Engine ist, da sie keine vorgefertigten Visualisierungen bietet. Unter anderem weisen wir darauf hin, dass Java auf allen Servern installiert werden muss, da Logstash in Ruby (JRuby) geschrieben ist.
Die Lösung hat eine ziemlich große Community: Es gibt einen
IRC-Kanal und ein separates
Forum . Im Netzwerk gibt es Beispiele für die
Konfiguration des gesamten Systems und der
API .
Die folgenden Organisationen
verwenden Logstash: CERN Control Center, GitHub, SoundCloud.
6,6 Tausend Sterne auf
GitHub . Unter der Apache 2.0-Lizenz von der
CNCF (Cloud Native Computing Foundation) vertrieben - wurde es von Google und der Linux Foundation gegründet, um die Containertechnologie zu fördern.
Fluentd läuft unter Linux, Windows und Mac und ist in Ruby (CRuby) geschrieben. Fluentd verfügt über ein
flexibles Plugin-System , das seine Funktionalität erweitert.
Die Lösung verfügt über ein einheitliches Protokollierungsformat: Fluentd versucht, die empfangenen Daten in das JSON-Format zu konvertieren. Um einen zuverlässigen Betrieb zu gewährleisten, sind keine Lösungen von Drittanbietern erforderlich. Hierzu ist jedoch eine zusätzliche Konfiguration erforderlich. Es wird auch nicht empfohlen, es auf Servern zu installieren, die Protokolle generieren.
Die Community ist groß: Es gibt einen
Kanal in Slack sowie einen
Thread in Google Groups . Auf der offiziellen Website des Projekts
finden Sie Beispiele für Konfigurationen und
APIs . Unternehmen wie Microsoft, Amazon, change.org und Nintendo verwenden Fluentd.
4,3 Tausend Sterne auf
GitHub . Unter der GNU GPL v3-Lizenz vertrieben. Es funktioniert nur unter Linux. Ein zentrales
Ökosystem von Plugins und ein benutzerdefiniertes Puffersystem. Der Einfachheit halber kann das Schlüsselwort eingehende Nachrichten zu Streams kombinieren und diese Streams von verschiedenen Hosts gruppieren.
Das System verwendet die Elasticsearch-Funktionen, aber trotz der häufigen Aktualisierungen von Graylog und der entwickelten Community (es gibt ein
Forum , einen
IRC-Kanal ,
es gibt Beispiele für Konfigurationen und
APIs auf der offiziellen Projektwebsite) dauert die Integration der aktuellen Versionen von Elasticsearch in das Projekt lange. Im letzten Jahr kam es beispielsweise zu einer Situation, in der Graylog 2.2.1 (das letzte zu diesem Zeitpunkt)
nur mit Elasticsearch Version 2.4.4
funktionierte , die als veraltet angesehen wurde.
In seiner Arbeit
nutzt Graylog
die Europäische Umweltagentur, Dial Once, Stockopedia und andere.
Es funktioniert unter Linux und Windows. Das System verfügt über eine hohe Leistung und kann detaillierte Berichte zu Schlüsselwörtern erstellen. Es gibt einen schwerwiegenden Nachteil: LOGalyze sammelt Protokolle in seiner Dateidatenbank, wo es sie dann indiziert und viel Speicherplatz beansprucht.
LOGalyze-Entwickler
haben ein eigenes Blog , und die Diskussion über die Lösung findet in
Google-Gruppen statt . Es gibt eine Anleitung
zur Systemkonfiguration und
Datenmigration sowie zur
CLI .
Nachdem wir diese vier Optionen evaluiert hatten, entschieden wir uns für Logstash und beschlossen, einen ELK-Stack (ElasticSearch, Logstash, Kibana) zu organisieren. Von diesen ist Elasticsearch eine Suchmaschine, Logstash ist ein Mechanismus zum Sammeln und Analysieren von Protokollen, und Kibana befasst sich mit Analyse und Datenvisualisierung.
Wir haben uns für ELK entschieden, da alle drei Komponenten von einem "Hersteller" entwickelt wurden und sich daher gut ineinander integrieren lassen. Bei Bedarf können wir jedes dieser Tools einzeln verwenden, um andere Probleme zu lösen.
Dieser Ansatz macht das Produkt flexibel und vielseitig. All dies ermöglicht eine effizientere Verarbeitung vorhandener Datenmengen und eine schnellere Implementierung neuer Dienste - die Verbindung wird einfacher.
Jetzt ist die Testumgebung fertig. Es „deckt“ alle Dienste ab, deren Protokolle wir analysieren werden. Wir beenden die letzten Debugging-Prozesse und planen in naher Zukunft einen vollständigen Start der Lösung.
Übrigens, trotz der Tatsache, dass wir verschiedene Optionen im Detail analysiert und die beste für unsere Bedürfnisse ausgewählt haben, war es am Ende nicht ohne eine Fliege in der Salbe. Beim Testen der Lösung waren wir mit einer Situation konfrontiert, in der Kibana Elasticsearch auf Anfrage fallen ließ - was als äußerst seltener und entarteter Fall angesehen wird. Auch während der "Montage" des Systems stellten sich eine Reihe von Fragen, die sich hauptsächlich auf die Sicherheit bezogen. In der Basisversion ist Elasticsearch durch nichts geschützt - es war notwendig, Software von Drittanbietern für diese Zwecke anzupassen.
Nach dem Start werden wir Überwachungssysteme einrichten, um so schnell wie möglich auf Fehler im Protokolldienst zu reagieren. Wir hoffen, dass der neue Technologie-Stack das Benutzererlebnis unserer Kunden verbessert und unsere Services schneller weiterentwickelt.
Materialien aus unserem Unternehmensblog: