Unser Weg zur zentralen Protokollspeicherung

Grüße an alle! Ich arbeite als Systemingenieur bei Onlanta . Bei einem unserer Projekte war ich an der Implementierung und Wartung von Elastic Stack beteiligt. Wir gingen vom virtuellen Sammeln von Protokollen zu einem zentralisierten, automatisierten Prozess über. Seit zwei Jahren haben wir die Architektur der Lösung praktisch nicht geändert und planen, in anderen Projekten ein praktisches Tool zu verwenden. Ich teile Ihnen unsere Geschichte der Umsetzung sowie einige Stärken und Schwächen in diesem Beitrag mit.

Quelle

Anfang 2016 waren die Protokolle unserer Administratoren und Entwickler sozusagen „an Ihren Fingerspitzen“, dh ein Ingenieur, der mit ihnen über SSH mit dem Host verbunden war, an dem der Dienst, an dem er interessiert war, das universelle Set von tail / grep / sed aufgedeckt hat / awk und hoffte, dass es möglich sein würde, die notwendigen Daten auf diesem Host zu finden.

Quelle

Wir hatten auch einen separaten Server, auf dem alle Verzeichnisse mit Protokollen von allen Servern über NFS bereitgestellt wurden, und der manchmal lange darüber nachdachte, was jeder mit den Protokollen darauf machen wollte. Nun, tmux mit mehreren Panels auf einigen aktiv aktualisierten Protokollen sah für Außenstehende auf einem großen Monitor sehr beeindruckend aus und schuf eine aufregende Atmosphäre der Beteiligung an den Sakramenten der Produktion.

All dies funktionierte sogar, aber genau so lange, bis eine große Datenmenge schnell verarbeitet werden musste, und dies war meistens in den Momenten erforderlich, in denen etwas in den Stoß gefallen war.

Manchmal dauerte es unanständig, Vorfälle zu untersuchen. Ein erheblicher Teil davon wurde für die manuelle Aggregation von Protokollen, das Starten von Krücken verschiedener Skripte in Bash und Python, das Warten auf das Hochladen von Protokollen zur Analyse usw. aufgewendet.

Mit einem Wort, all dies war sehr langsam, inspiriert von Niedergeschlagenheit und deutete eindeutig an, dass es Zeit war, sich um die zentrale Speicherung von Protokollen zu kümmern.

Um ehrlich zu sein, gab es kein kompliziertes Verfahren zur Auswahl von Kandidaten für die Rolle des technologischen Stacks, das uns dies ermöglichen würde: Damals war das ELK-Bundle bereits zu dieser Zeit beliebt, hatte eine gute Dokumentation, es gab eine große Anzahl von Artikeln im Internet für alle Komponenten. Die Entscheidung war sofort: Sie müssen es versuchen.

Quelle

Die allererste Installation des Stacks erfolgte nach dem Webinar „Logstash: 0-60 in 60“ auf drei virtuellen Maschinen, von denen jede eine Instanz von Elasticsearch, Logstash und Kibana startete.

Außerdem sind einige Probleme bei der Übermittlung von Protokollen von Endhosts an Logstash-Server aufgetreten. Tatsache ist, dass Filebeat (eine Standard-Stack-Lösung für die Bereitstellung von Protokollen aus Textdateien) zu dieser Zeit mit großen und schnell aktualisierten Dateien, die regelmäßig im RAM leckten und in unserem Fall insgesamt die Aufgabe nicht bewältigen konnten, viel schlechter funktionierte.

Hinzu kam die Notwendigkeit, einen Weg zu finden, um Anwendungsserverprotokolle von Computern mit IBM AIX bereitzustellen: Der Großteil unserer Anwendungen wurde dann in WebSphere Application Server gestartet, das speziell unter diesem Betriebssystem funktionierte. Filebeat ist in Go geschrieben, es gab 2016 keinen mehr oder weniger effizienten Go-Compiler für AIX, und ich wollte Logstash wirklich nicht als Agenten für die Bereitstellung verwenden.

Wir haben verschiedene Log Delivery Agents getestet: Filebeat, Logstash-Forwarder-Java, Log-Courier , Python-Beaver und NXLog. Von den Agenten erwarteten wir eine hohe Leistung, einen geringen Verbrauch an Systemressourcen, eine einfache Integration in Logstash und die Fähigkeit, grundlegende Datenmanipulationen mit den Kräften des Agenten durchzuführen (z. B. die Zusammenstellung mehrzeiliger Ereignisse).

Über die Zusammenstellung von mehrzeiligen Ereignissen ist es gesondert zu erwähnen. Tatsächlich kann es nur auf der Seite des Agenten ausgeführt werden, der eine bestimmte Datei liest. Trotz der Tatsache, dass Logstash früher einen mehrzeiligen Filter hatte und jetzt einen mehrzeiligen Codec hat, schlugen alle unsere Versuche, den Ereignisausgleich über mehrere Logstash-Server mit der mehrzeiligen Verarbeitung zu kombinieren, fehl. Diese Konfiguration macht einen effizienten Ereignisausgleich nahezu unmöglich. Daher war für uns der wichtigste Faktor bei der Auswahl der Agenten die mehrzeilige Unterstützung.

Die Gewinner waren: Log-Courier für Maschinen mit Linux, NXLog für Maschinen mit AIX. Mit dieser Konfiguration lebten wir fast ein Jahr ohne Probleme: Die Protokolle wurden geliefert, die Agenten fielen nicht (na ja, fast), alle waren glücklich.

Im Oktober 2016 wurde die fünfte Version der Elastic Stack-Komponenten veröffentlicht, einschließlich Beats 5.0. In dieser Version wurde viel Arbeit an allen Beats-Agenten geleistet, und wir konnten den Log-Courier (der zu diesem Zeitpunkt seine eigenen Probleme hatte) durch Filebeat ersetzen, den wir immer noch verwenden.

Bei der Migration auf Version 5.0 wurden nicht nur Protokolle, sondern auch einige Metriken erfasst: Packetbeat wurde hier und da als Alternative zum Schreiben von HTTP-Anforderungsprotokollen in Dateien verwendet, und Metricbeat sammelte Systemmetriken und Metriken einiger Dienste.

Zu diesem Zeitpunkt wurde die Arbeit unserer Ingenieure mit Protokollen viel einfacher: Jetzt musste nicht mehr bekannt sein, auf welchem ​​Server das Protokoll angezeigt werden soll, an dem Sie interessiert sind. Der Informationsaustausch wurde vereinfacht, indem der Link zu Kibana einfach in Chatrooms oder E-Mails übertragen und Berichte erstellt wurden, die zuvor erstellt wurden in wenigen Stunden begann in wenigen Sekunden erstellt zu werden. Dies kann nicht gesagt werden, dass es nur eine Frage des Komforts war: Wir haben Veränderungen in der Qualität unserer Arbeit, in der Quantität und Qualität geschlossener Aufgaben sowie in der Geschwindigkeit der Reaktion auf Probleme an unseren Ständen festgestellt.

Irgendwann haben wir begonnen, das ElastAlert-Dienstprogramm von Yelp zu verwenden, um Warnungen an Ingenieure zu senden. Und dann haben wir uns gedacht: Warum nicht in unser Zabbix integrieren, damit alle Warnungen ein Standardformat haben und zentral gesendet werden? Die Lösung wurde ziemlich schnell gefunden: Mit ElastAlert können Sie beliebige Befehle ausführen, anstatt von uns verwendete Warnungen zu senden.

Jetzt führen unsere ElastAlert-Regeln beim Auslösen ein Bash-Skript in mehreren Zeilen aus, an das die erforderlichen Daten in den Argumenten des Ereignisses übergeben werden, das die Regel ausgelöst hat, und zabbix_sender wird vom Skript aufgerufen, das die Daten für den gewünschten Knoten an Zabbix sendet.

Da alle Informationen darüber, wer das Ereignis generiert hat und wo, in Elasticsearch immer verfügbar sind, gab es keine Schwierigkeiten bei der Integration. Zum Beispiel hatten wir zuvor einen Mechanismus zum automatischen Erkennen von WAS-Anwendungsservern, und in den von ihnen generierten Ereignissen wird immer der Name des Servers, Clusters, der Zelle usw. geschrieben. Dadurch konnten wir die Option query_key in ElastAlert-Regeln verwenden, sodass die Bedingungen der Regeln für jeden Server separat verarbeitet werden. Das Skript mit zabbix_sender erhält dann die genauen "Koordinaten" des Servers und die Daten werden für den entsprechenden Knoten an Zabbix gesendet.

Eine andere Lösung, die uns sehr gefällt und die dank der zentralisierten Protokollsammlung ermöglicht wurde, ist ein Skript zum automatischen Erstellen von Aufgaben in JIRA: Einmal am Tag werden alle Fehler aus den Protokollen entfernt und, falls noch keine Aufgaben vorhanden sind, gestartet. Gleichzeitig werden aus verschiedenen Indizes durch eine eindeutige Anforderungs-ID alle Informationen, die für die Untersuchung nützlich sein können, in die Aufgabe gezogen. Das Ergebnis ist eine Art Standardwerkstück mit den erforderlichen Mindestinformationen, die die Ingenieure bei Bedarf ergänzen können.

Natürlich standen wir vor dem Problem, den Stack selbst zu überwachen. Dies wird teilweise mit Zabbix implementiert, teilweise mit demselben ElastAlert, und wir erhalten die wichtigsten Leistungsmetriken für Elasticsearch, Logstash und Kibana mithilfe der im Stack integrierten Standardüberwachung (der Überwachungskomponente im X-Pack). Außerdem haben wir auf den Servern mit den Stack-Diensten selbst Netzdaten von Firehol installiert. Dies ist nützlich, wenn Sie in Echtzeit und mit hoher Auflösung sehen möchten, was gerade mit einem bestimmten Knoten passiert.

Es war einmal, dass das Elasticsearch-Überwachungsmodul darin leicht defekt war. Wir haben es gefunden, behoben, alle möglichen nützlichen Metriken hinzugefügt und eine Pull-Anfrage gestellt. Jetzt kann netdata die neuesten Versionen von Elasticsearch überwachen, einschließlich grundlegender JVM-Metriken, Indizierung, Suchleistungsindikatoren, Transaktionsprotokollstatistiken, Indexsegmenten usw. Wir mögen Netdata und freuen uns, dass wir einen kleinen Beitrag dazu leisten konnten.

Heute, nach fast drei Jahren, sieht unser Elastic Stack ungefähr so ​​aus:


Ingenieure arbeiten auf drei Arten mit dem Stapel:

• Anzeigen und Analysieren von Protokollen und Metriken in Kibana;
• Dashboards in Grafana und Kibana;
• direkte Abfragen an Elasticsearch mithilfe von SQL oder der integrierten Abfrage DSL.

Insgesamt werden alle diese Ressourcen zugewiesen: 146 CPU, 484 GB RAM, 17 TB werden für das Elasticsearch Data Warehouse zugewiesen.

Insgesamt arbeiten 13 virtuelle Maschinen im Rahmen von Elastic Stack: 4 Maschinen für „heiße“ Elasticsearch-Knoten, 4 für „warme“ Knoten, 4 Maschinen mit Logstash und eine Ausgleichsmaschine. Auf jedem Hot Node führt Elasticsearch eine Kibana-Instanz aus. Es ist von Anfang an passiert, und bisher mussten wir Kibana nicht bewegen, um Autos zu trennen.

Die Entscheidung, Logstash auf getrennte Maschinen zu übertragen, erwies sich jedoch als eine der korrektesten und effizientesten während des Stapelbetriebs: Die hohe Konkurrenz um die CPU-Zeit zwischen JVM Elasticsearch und Logstash führte zu nicht sehr angenehmen Spezialeffekten bei Lastausbrüchen. Müllsammler litten am meisten.

Quelle

Wir speichern Daten für die letzten 30 Tage im Cluster: Jetzt sind es ungefähr 12 Milliarden Ereignisse. Täglich schreiben „heiße“ Knoten neue Daten mit einem maximalen Komprimierungsverhältnis (einschließlich Shard-Replica-Daten) auf die 400-500-GB-Festplatte. Unser Elasticsearch-Cluster hat eine Hot / Warm-Architektur, aber wir haben vor relativ kurzer Zeit darauf umgestellt, sodass immer noch weniger Daten auf "warmen" Knoten gespeichert sind als auf "heißen".

Unsere typische Arbeitsbelastung:

• Indexierung - durchschnittlich 13.000 U / min mit Spitzenwerten von bis zu 30.000 (ohne Indizierung in Replikatsplitter);
• Suche - 5200 rps.

Wir versuchen, eine CPU-Marge von 40-50% auf Elasticsearch-Hotknoten aufrechtzuerhalten, damit die Anzahl der indizierten Ereignisse und die hohen Anforderungen von Kibana / Grafana oder externen Überwachungssystemen leicht plötzlich ansteigen. Etwa 50% des Arbeitsspeichers auf Hosts mit Elasticsearch-Knoten sind immer für den Seiten-Cache und die Off-Heap-Anforderungen der JVM verfügbar.

In der Zeit seit dem Start des ersten Clusters konnten wir einige der positiven und negativen Seiten von Elastic Stack als Mittel zur Aggregation von Protokollen und als Such- und Analyseplattform für uns identifizieren.

Was uns am Stack besonders gefällt:

• Ein einziges Ökosystem von Produkten, das gut miteinander integriert ist und fast alles bietet, was Sie brauchen. Die Beats waren früher nicht sehr gut, aber jetzt haben wir keine Beschwerden über sie.
• Logstash ist mit all seiner Monstrosität ein sehr flexibler und leistungsstarker Präprozessor, mit dem Sie viel mit Rohdaten tun können (und wenn etwas dies nicht zulässt, können Sie jederzeit ein Snippet in Ruby schreiben).
• Elasticsearch mit Plugins (und in jüngerer Zeit sofort verfügbar) unterstützt SQL als Abfragesprache, was die Integration mit anderer Software und Personen vereinfacht, die SQL als Abfragesprache näher stehen.
• Hochwertige Dokumentation, mit der Sie schnell neue Mitarbeiter in das Projekt einführen können. Der Betrieb des Stapels wird daher nicht zum Geschäft einer Person, die über bestimmte Erfahrungen und „geheimes Wissen“ verfügt.
• Es ist nicht erforderlich, im Voraus über die Struktur der empfangenen Daten Bescheid zu wissen, um sie zu erfassen: Sie können Ereignisse so wie sie sind aggregieren und dann, wenn Sie verstehen, welche nützlichen Informationen Sie daraus extrahieren können, den Ansatz zur Verarbeitung ändern, ohne die „Abwärtskompatibilität“ zu verlieren. Hierfür gibt es viele praktische Tools auf dem Stapel: Feldaliasnamen in Indizes, Skriptfeldern usw.

Quelle

Was wir nicht mögen:

• X-Pack-Komponenten werden nur nach dem Abonnementmodell und sonst nichts verteilt: Wenn von Gold beispielsweise nur RBAC- oder PDF-Berichte unterstützt werden, müssen Sie für alles bezahlen, was Gold hat. Dies ist besonders frustrierend, wenn Sie beispielsweise nur Graph from Platinum benötigen und Machine Learning und ein weiteres Bündel anderer Funktionen, die Sie möglicherweise nicht wirklich benötigen, zum Kauf angeboten werden. Unsere Versuche, vor etwa einem Jahr mit der Elastic-Verkaufsabteilung über die Lizenzierung einzelner X-Pack-Komponenten zu kommunizieren, führten zu nichts, aber vielleicht hat sich seitdem etwas geändert.
• Sehr häufige Releases, bei denen die Abwärtskompatibilität irgendwie (jedes Mal neu) unterbrochen wird. Sie müssen das Änderungsprotokoll sehr sorgfältig lesen und sich im Voraus auf Aktualisierungen vorbereiten. Jedes Mal, wenn Sie sich entscheiden müssen: Bleiben Sie bei der alten Version, die stabil funktioniert, oder versuchen Sie, ein Upgrade durchzuführen, um neue Funktionen und Leistungssteigerungen zu erhalten.

Im Allgemeinen sind wir sehr zufrieden mit unserer Wahl im Jahr 2016 und planen, die Erfahrung mit dem Betrieb von Elastic Stack auf unsere anderen Projekte zu übertragen: Die vom Stack bereitgestellten Tools sind sehr eng in unseren Workflow integriert, und es wäre sehr schwierig, sie jetzt abzulehnen.