Wie wir bei CIAN Terabytes von Logs bändigen

Hallo zusammen, mein Name ist Alexander, ich arbeite als Ingenieur bei CIAN und beschäftige mich mit Systemadministration und Automatisierung von Infrastrukturprozessen. In den Kommentaren zu einem unserer früheren Artikel wurden wir gebeten, zu erzählen, woher wir täglich 4 TB Logs beziehen und was wir damit machen. Ja, wir haben viele Logs, und zur Verarbeitung wurde ein eigener Infrastruktur-Cluster eingerichtet, der es uns ermöglicht, Probleme schnell zu lösen. In diesem Artikel werde ich darüber berichten, wie wir ihn im Laufe eines Jahres an die ständig wachsenden Datenströme angepasst haben.

Wie wir angefangen haben

In den letzten Jahren ist die Last auf cian.ru sehr schnell gewachsen, und im dritten Quartal 2018 erreichte die Besucherzahl der Plattform 11,2 Millionen eindeutige Nutzer pro Monat. In kritischen Momenten verloren wir damals bis zu 40 % der Logs, was es uns nicht ermöglichte, Vorfälle zügig zu bearbeiten, und wir investierten viel Zeit und Energie in deren Lösung. Außerdem konnten wir oft die Ursache des Problems nicht finden, und es trat nach einer gewissen Zeit wieder auf. Es war die Hölle, und wir mussten etwas daran ändern.

Zu diesem Zeitpunkt verwendeten wir zum Speichern der Logs einen Cluster aus 10 Datenknoten mit ElasticSearch Version 5.5.2 mit standardmäßigen Indexeinstellungen. Dieses wurde vor mehr als einem Jahr als populäre und zugängliche Lösung implementiert: Damals war der Logstrom nicht so groß, und es machte keinen Sinn, unkonventionelle Konfigurationen zu entwickeln. 

Die Verarbeitung der eingehenden Logs erfolgte durch Logstash auf verschiedenen Ports auf fünf ElasticSearch-Koordinatoren. Ein Index, unabhängig von der Größe, bestand aus fünf Shards. Es gab eine stündliche und tägliche Rotation, wodurch jede Stunde etwa 100 neue Shards im Cluster erstellt wurden. Solange die Logs nicht zu viele waren, kam der Cluster damit zurecht, und niemand achtete auf seine Einstellungen. 

Probleme des schnellen Wachstums

Das Volumen der generierten Logs wuchs sehr schnell, da zwei Prozesse aufeinandertrafen. Einerseits gab es immer mehr Nutzer des Dienstes. Andererseits begannen wir aktiv, auf eine Mikroservice-Architektur umzusteigen, indem wir unsere alten Monolithe in C# und Python aufteilten. Mehrere Dutzend neuer Mikroservices, die Teile des Monolithen ersetzten, generierten deutlich mehr Logs für den Infrastruktur-Cluster. 

Das Skalieren hat dazu geführt, dass der Cluster praktisch unverwaltbar wurde. Als die Protokolle mit einer Geschwindigkeit von 20.000 Nachrichten pro Sekunde eintrafen, erhöhte die häufige, nutzlose Rotation die Anzahl der Shards auf 6.000, und es kamen mehr als 600 Shards auf einen Knoten. 

Dies führte zu Problemen mit dem Arbeitsspeicher, und bei dem Ausfall eines Knotens begann der gleichzeitige Umzug aller Shards, was den Datenverkehr vervielfachte und die anderen Knoten belastete, wodurch das Schreiben von Daten in den Cluster fast unmöglich wurde. In dieser Zeit hatten wir keine Protokolle. Und bei einem Problem mit Server verloren wir im Prinzip 1/10 des Clusters. Eine Vielzahl von Indizes kleiner Größe machte die Situation noch komplizierter.

Ohne Protokolle konnten wir die Ursachen des Vorfalls nicht verstehen und hätten früher oder später die gleichen Fehler wiederholen können. In der Ideologie unseres Teams war das unakzeptabel, da alle unsere Arbeitsmechanismen darauf ausgelegt sind, die gleichen Probleme niemals zu wiederholen. Dazu benötigten wir das vollständige Protokollvolumen und deren Zustellung fast in Echtzeit, da das Team der Bereitschaftsingenieure nicht nur Alerts von Metriken, sondern auch von Protokollen überwachte. Um das Ausmaß des Problems zu verstehen: Zu diesem Zeitpunkt betrug das gesamte Protokollvolumen etwa 2 TB pro Tag. 

Wir haben uns zum Ziel gesetzt, den Verlust von Protokollen vollständig auszuschließen und die Lieferzeit in den ELK-Cluster im Maximum auf 15 Minuten während von Notfällen zu reduzieren (auf diese Zahl stützten wir uns später als internes KPI).

Neuer Rotationsmechanismus und Hot-Warm-Knoten

Mit der Umstellung des Clusters begannen wir mit der Aktualisierung der ElasticSearch-Version von 5.5.2 auf 6.4.3. Der Cluster der Version 5 fiel erneut aus, und wir beschlossen, ihn abzuschalten und komplett zu aktualisieren — schließlich gab es ohnehin keine Protokolle. Daher haben wir diesen Wechsel in nur wenigen Stunden vollzogen.

Die umfangreichste Umstellung in dieser Phase war die Implementierung von Apache Kafka auf drei Knoten mit dem Koordinator als Zwischenpuffer. Der Nachrichtensbroker hat uns vor dem Verlust von Logs während Problemen mit ElasticSearch bewahrt. Gleichzeitig haben wir 2 Knoten zum Cluster hinzugefügt und sind auf eine Hot-Warm-Architektur mit drei "hot" Knoten umgestiegen, die in verschiedenen Racks im Rechenzentrum platziert sind. Auf diesen haben wir die Logs umgeleitet, die auf keinen Fall verloren gehen dürfen — nginx sowie Logs der Anwendungsfehler. Auf die anderen Knoten gingen weniger wichtige Logs — debug, warning usw., und nach 24 Stunden wurden "wichtige" Logs von den "hot" Knoten verschoben.

Um die Anzahl kleiner Indizes nicht zu erhöhen, sind wir von der zeitbasierten Rotation auf das Mechanismus des Rollovers umgestiegen. In den Foren gab es viele Informationen, dass die Rotation nach der Indexgröße sehr unzuverlässig ist, weshalb wir beschlossen haben, die Rotation nach der Anzahl der Dokumente im Index zu verwenden. Wir haben jeden Index analysiert und die Anzahl der Dokumente festgehalten, nach der die Rotation erfolgen sollte. So haben wir die optimale Shard-Größe erreicht — nicht mehr als 50 GB. 

Cluster-Optimierung

Wir haben jedoch die Probleme nicht vollständig beseitigt. Leider tauchten weiterhin kleine Indizes auf: Sie erreichten nicht das vorgesehene Volumen, wurden nicht rotiert und gelöscht durch eine globale Bereinigung der Indizes, die älter als drei Tage sind, da wir die zeitgesteuerte Rotation entfernt hatten. Dies führte zu Datenverlusten, da der Index vollständig aus dem Cluster verschwand, und der Versuch, in einen nicht existierenden Index zu schreiben, brach die Logik des Curators, den wir zur Verwaltung verwendeten. Alias zum Schreiben verwandelte sich in einen Index und brach die Logik des Rollovers, was zu einem unkontrollierten Wachstum einiger Indizes auf bis zu 600 GB führte. 

Zum Beispiel für die Rollover-Konfiguration:

curator-elk-rollover.yaml

---
actions:
 1:
 action: rollover
 options:
 name: "nginx_write"
 conditions:
 max_docs: 100000000
 2:
 action: rollover
 options:
 name: "python_error_write"
 conditions:
 max_docs: 10000000

Bei fehlendem Rollover-Alias trat ein Fehler auf:

ERROR     alias "nginx_write" nicht gefunden.
ERROR     Aktion konnte nicht abgeschlossen werden: rollover.  : Unable to perform index rollover with alias "nginx_write".

Die Lösung dieses Problems haben wir auf die nächste Iteration verschoben und uns einer anderen Frage gewidmet: Wir sind zur Pull-Logik von Logstash übergegangen, die sich mit der Verarbeitung eingehender Protokolle (Entfernung überflüssiger Informationen und Anreicherung) beschäftigt. Wir haben es in Docker platziert, das wir über Docker-Compose ausführen, und dort auch den Logstash-Exporter untergebracht, der Metriken an Prometheus zur Echtzeitüberwachung des Protokollflusses übergibt. So haben wir uns die Möglichkeit gegeben, die Anzahl der Logstash-Instanzen, die für die Verarbeitung jeder Art von Protokollen zuständig sind, flexibel zu ändern.

Während wir den Cluster optimierten, wuchs die Besucherzahl von cian.ru auf 12,8 Millionen einzigartige Nutzer pro Monat. Infolgedessen stellte sich heraus, dass unsere Transformationen nicht ganz mit den Änderungen in der Produktion Schritt hielten, und wir sahen uns dem Problem gegenüber, dass die "warmen" Knoten mit der Last überfordert waren und die gesamte Protokolllieferung verlangsamten. "Heiße" Daten erhielten wir ohne Ausfälle, aber bei der Lieferung der anderen mussten wir manuell eingreifen und einen Roll-over durchführen, um die Indizes gleichmäßig zu verteilen. 

Das Skalieren und Anpassen der Einstellungen der Logstash-Instanzen im Cluster wurde dadurch erschwert, dass es sich um ein lokales Docker-Compose handelte und alle Aktionen manuell durchgeführt werden mussten (um neue Endpunkte hinzuzufügen, musste man manuell auf allen Servern Docker-Compose up -d ausführen).

Neuverteilung der Protokolle

Im September dieses Jahres setzten wir weiterhin den Monolithen auseinander, die Last im Cluster nahm zu und der Protokollfluss näherte sich 30.000 Nachrichten pro Sekunde. 

Die nächste Iteration begannen wir mit einem Hardware-Upgrade. Von fünf Koordinatoren gingen wir auf drei über, tauschten die Datenknoten aus und gewannen sowohl finanziell als auch in Bezug auf den Speicherplatz. Für die Knoten verwenden wir zwei Konfigurationen: 

• Für "heiße" Knoten: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 für Hot1 und 3 für Hot2).
• Für "warme" Knoten: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

In dieser Iteration haben wir den Index mit den Access-Logs der Mikrodienste, der den gleichen Platz wie die Logs der Frontend-Nginx einnimmt, in die zweite Gruppe aus drei "heißen" Knoten verschoben. Daten auf den "heißen" Knoten speichern wir jetzt 20 Stunden und übertragen sie dann zu den "warmen" Knoten mit den anderen Protokollen. 

Wir haben das Problem mit dem Verschwinden kleiner Indizes durch eine Neuausrichtung ihrer Rotation gelöst. Jetzt rotieren die Indizes in jedem Fall alle 23 Stunden, auch wenn nur wenige Daten vorhanden sind. Das hat die Anzahl der Shards leicht erhöht (auf etwa 800), was jedoch aus Sicht der Cluster-Leistung akzeptabel ist. 

Im Cluster gibt es nun sechs "heiße" und nur vier "warme" Knoten. Dies verursacht eine kleine Verzögerung bei Anfragen über große Zeiträume hinweg, aber die Erhöhung der Knotenanzahl in der Zukunft wird dieses Problem lösen.

In dieser Iteration haben wir auch das Problem der fehlenden halbautomatischen Skalierung behoben. Dazu haben wir ein infrastrukturelles Nomad-Cluster bereitgestellt – ähnlich dem, das bereits bei uns in der Produktion eingesetzt wird. Momentan variiert die Anzahl der Logstash-Instanzen noch nicht automatisch je nach Last, aber wir werden auch dies in Angriff nehmen.

Zukunftspläne

Die implementierte Konfiguration skaliert hervorragend und derzeit speichern wir 13,3 TB Daten – alle Logs von 4 Tagen, die für die dringende Analyse von Alerts benötigt werden. Teile der Logs wandeln wir in Metriken um, die wir in Graphite speichern. Um die Arbeit der Ingenieure zu erleichtern, haben wir Metriken für das Infrastruktur-Cluster sowie Skripte zur halbautomatischen Behebung typischer Probleme. Nach der geplanten Erhöhung der Anzahl an Datenknoten im nächsten Jahr werden wir die Datenspeicherung von 4 auf 7 Tage umstellen. Das wird für die operative Arbeit ausreichend sein, da wir immer versuchen, Vorfälle so schnell wie möglich zu untersuchen, und für langfristige Ermittlungen stehen Telemetriedaten zur Verfügung. 

Im Oktober 2019 stieg die Besucherzahl von cian.ru bereits auf 15,3 Millionen einzigartige Nutzer pro Monat. Dies stellte eine ernsthafte Prüfung der architektonischen Lösung zur Log-Übertragung dar. 

Jetzt bereiten wir das Update auf ElasticSearch Version 7 vor. Allerdings müssen wir dafür das Mapping vieler Indizes in ElasticSearch aktualisieren, da sie von Version 5.5 stammen und in Version 6 als veraltet gekennzeichnet wurden (in Version 7 sind sie einfach nicht mehr vorhanden). Das bedeutet, dass es während des Updates mit Sicherheit zu unvorhergesehenen Problemen kommen wird, die uns kurzfristig ohne Logs lassen. Von Version 7 erhoffen wir uns vor allem Kibana mit einer verbesserten Benutzeroberfläche und neuen Filtern. 

Wir haben unser Hauptziel erreicht: Wir haben aufgehört, Protokolle zu verlieren, und die Ausfallzeit unseres Infrastrukturclusters von 2-3 Abstürzen pro Woche auf ein paar Stunden Wartungsarbeiten pro Monat reduziert. All diese Arbeit ist in der Produktion fast unbemerkt. Dennoch können wir nun genau bestimmen, was mit unserem Service passiert, können dies schnell in einem ruhigen Modus tun und uns keine Sorgen machen, dass Protokolle verloren gehen. Insgesamt sind wir zufrieden, glücklich und bereiten uns auf neue Heldentaten vor, über die wir später berichten werden.

Quelle: habr.com