{"id":53590,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-my-v-tsian-ukroshhali-terabajty-logov"},"modified":"2020-02-18T14:01:30","modified_gmt":"2020-02-18T11:01:30","slug":"kak-my-v-tsian-ukroshhali-terabajty-logov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Meine Hauptaufgabe besteht haupts\u00e4chlich darin, Software-Systeme bereitzustellen, das hei\u00dft, ich verbringe viel Zeit damit, auf solche Fragen zu antworten: Bei dem Entwickler funktioniert die Software, bei mir jedoch nicht. Warum? Gestern hat die Software bei mir funktioniert, heute nicht mehr. Warum? Das ist eine Art Fehlersuche, die sich ein wenig von der gew\u00f6hnlichen Software-Fehlersuche unterscheidet.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Meine
\n
\nHallo zusammen, ich bin Alexander, arbeite als Ingenieur bei CIAN und besch\u00e4ftige mich mit Systemadministration sowie der Automatisierung infrastruktureller Prozesse. In den Kommentaren zu einem unserer fr\u00fcheren Artikel wurden wir gebeten, zu erz\u00e4hlen, woher wir 4 TB Logs pro Tag beziehen und was wir damit machen. Ja, wir haben viele Logs, und um sie zu verarbeiten, wurde ein separater Infrastruktur-Cluster eingerichtet, der es uns erm\u00f6glicht, Probleme schnell zu l\u00f6sen. In diesem Artikel werde ich erl\u00e4utern, wie wir ihn im vergangenen Jahr an den st\u00e4ndig wachsenden Datenstrom angepasst haben.
\n<\/a><\/noindex><\/p>\n

Wie wir angefangen haben<\/h3>\n

\n\"Meine
\n
\nIn den letzten Jahren ist die Last auf cian.ru sehr schnell gewachsen, und im dritten Quartal 2018 erreichte die Besucherzahl 11,2 Millionen eindeutige Nutzer pro Monat. In kritischen Momenten verloren wir damals bis zu 40% der Logs, wodurch wir bei Vorf\u00e4llen nicht schnell reagieren konnten und sehr viel Zeit und M\u00fche aufwenden mussten, um sie zu l\u00f6sen. Oft konnten wir auch die Ursache des Problems nicht finden, und es trat nach einiger Zeit erneut auf. Das war die H\u00f6lle, und wir mussten etwas dagegen unternehmen.<\/p>\n

Zu diesem Zeitpunkt verwendeten wir zum Speichern der Protokolle einen Cluster aus 10 Datenknoten mit ElasticSearch Version 5.5.2 und Standardindizes. Dies wurde vor \u00fcber einem Jahr als beliebte und kosteng\u00fcnstige L\u00f6sung implementiert: Zu diesem Zeitpunkt war das Protokollvolumen nicht besonders hoch, sodass es keinen Sinn machte, nicht Standardkonfigurationen zu entwickeln.\u00a0<\/p>\n

Die Verarbeitung der eingehenden Protokolle wurde von Logstash auf verschiedenen Ports auf f\u00fcnf ElasticSearch-Koordinatoren durchgef\u00fchrt. Ein Index bestand unabh\u00e4ngig von seiner Gr\u00f6\u00dfe aus f\u00fcnf Shards. Es wurde eine st\u00fcndliche und t\u00e4gliche Rotation organisiert, sodass st\u00fcndlich etwa 100 neue Shards im Cluster hinzukamen. Solange die Protokolle nicht zu zahlreich waren, bew\u00e4ltigte der Cluster die Einstellungen problemlos, und niemand achtete darauf.\u00a0<\/p>\n

Probleme des schnellen Wachstums<\/h3>\n

\nDas Volumen der generierten Protokolle wuchs sehr schnell, da zwei Prozesse zusammenfielen. Einerseits wurden die Nutzer des Services immer mehr. Andererseits begannen wir aktiv, auf eine Microservices-Architektur umzusteigen, indem wir unsere alten Monolithen in C# und Python aufteilten. Mehrere Dutzend neuer Microservices, die Teile des Monolithen ersetzten, erzeugten deutlich mehr Protokolle f\u00fcr den Infrastruktur-Cluster.\u00a0<\/p>\n

Genau das Skalieren hat dazu gef\u00fchrt, dass der Cluster praktisch unmanagebar wurde. Als die Protokolle mit einer Geschwindigkeit von 20.000 Nachrichten pro Sekunde eintrafen, erh\u00f6hte h\u00e4ufige ineffektive Rotation die Anzahl der Shards auf 6.000, wobei auf einen Knoten mehr als 600 Shards entfielen.\u00a0<\/p>\n

Das f\u00fchrte zu Problemen mit der Zuweisung von Arbeitsspeicher, und beim Ausfall eines Knotens begann der gleichzeitige Umzug aller Shards, was den Traffic vervielfachte und die anderen Knoten belastete. Dadurch wurde es nahezu unm\u00f6glich, Daten in den Cluster zu schreiben. In dieser Zeit waren wir ohne Protokolle. Und bei einem Problem mit dem Server durch<\/a> verloren wir praktisch 1\/10 des Clusters. Die gro\u00dfe Anzahl der kleinen Indizes stellte zus\u00e4tzlich eine Herausforderung dar.<\/p>\n

Ohne Protokolle konnten wir die Ursachen des Vorfalls nicht verstehen und liefen Gefahr, erneut in dieselben Fallen zu tappen. In unserer Teamideologie war dies unzul\u00e4ssig, da alle unsere Arbeitsmechanismen darauf ausgerichtet sind, niemals die gleichen Probleme zu wiederholen. Daf\u00fcr ben\u00f6tigten wir eine vollst\u00e4ndige Protokolldatenmenge und deren Lieferung praktisch in Echtzeit, da das Team der Ingenieure die Warnungen nicht nur von den Metriken, sondern auch von den Protokollen \u00fcberwachte. Um das Ausma\u00df des Problems zu verstehen: Zu diesem Zeitpunkt betrug das gesamte Protokollvolumen etwa 2 TB pro Tag.\u00a0<\/p>\n

Wir hatten die Aufgabe gestellt, den Verlust von Protokollen vollst\u00e4ndig auszuschlie\u00dfen und die Zeit f\u00fcr deren Lieferung in den ELK-Cluster auf maximal 15 Minuten w\u00e4hrend Notf\u00e4llen zu reduzieren (auf diese Zahl st\u00fctzten wir uns sp\u00e4ter als internes KPI).<\/p>\n

Neuer Rotationsmechanismus und Hot-Warm-Knoten<\/h3>\n

\n\"Meine
\n
\nWir begannen die Transformation des Clusters mit einem Upgrade der ElasticSearch-Version von 5.5.2 auf 6.4.3. Unser Cluster der Version 5 war erneut ausgefallen, und wir beschlossen, ihn abzuschalten und vollst\u00e4ndig zu aktualisieren \u2014 schlie\u00dflich hatten wir sowieso keine Protokolle. Daher vollzogen wir diesen \u00dcbergang in nur wenigen Stunden.<\/p>\n

Das umfassendste Upgrade in dieser Phase war die Implementierung von Apache Kafka auf drei Knoten, wobei der Koordinator als Zwischenpuffer fungierte. Der Nachrichtenbroker verhinderte den Verlust von Logs w\u00e4hrend der Probleme mit ElasticSearch. Gleichzeitig haben wir dem Cluster zwei Knoten hinzugef\u00fcgt und sind auf eine Hot-Warm-Architektur mit drei \"hei\u00dfen\" Knoten umgestiegen, die in verschiedenen Racks des Rechenzentrums platziert sind. Auf diesen haben wir nach dem Muster Logs umgeleitet, deren Verlust auf keinen Fall akzeptabel ist \u2014 nginx sowie Anwendungsfehlerlogs. Auf die \u00fcbrigen Knoten gingen geringf\u00fcgige Logs \u2014 debug, warning usw., w\u00e4hrend \u201ewichtige\u201c Logs nach 24 Stunden von den \u201ehei\u00dfen\u201c Knoten verschoben wurden.<\/p>\n

Um die Anzahl der kleinen Indizes nicht zu erh\u00f6hen, sind wir von der zeitbasierten Rotation auf den Rollover-Mechanismus umgestiegen. In Foren gab es viele Informationen dar\u00fcber, dass die Rotation nach der Gr\u00f6\u00dfe des Index sehr unzuverl\u00e4ssig ist, weshalb wir uns entschieden 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 ausgel\u00f6st werden soll. So haben wir eine optimale Shard-Gr\u00f6\u00dfe erreicht \u2014 nicht mehr als 50 GB.\u00a0<\/p>\n

Clusteroptimierung<\/h3>\n

\n\"Meine
\n
\nWir haben jedoch weiterhin Probleme. Leider tauchten immer noch kleine Indizes auf: Sie erreichten nicht das erforderliche Volumen, wurden nicht rotiert und durch die globale Bereinigung von Indizes, die \u00e4lter als drei Tage waren, gel\u00f6scht, da wir die Rotation nach Datum entfernt hatten. Dies f\u00fchrte zu Datenverlust, weil der Index aus dem Cluster vollst\u00e4ndig verschwand, und der Versuch, in einen nicht existierenden Index zu schreiben, brach die Logik des Curators, den wir zur Verwaltung verwendet haben. Der Alias zum Schreiben wurde in einen Index umgewandelt und st\u00f6rte die Logik des Rollover, was zu einem unkontrollierten Wachstum einiger Indizes auf bis zu 600 GB f\u00fchrte.\u00a0<\/p>\n

Zum Beispiel f\u00fcr die Rollover-Konfiguration:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n  1:\n    action: rollover\n    options:\n      name: \"nginx_write\"\n      conditions:\n        max_docs: 100000000\n  2:\n    action: rollover\n    options:\n      name: \"python_error_write\"\n      conditions:\n        max_docs: 10000000\n<\/code><\/pre>\n
Ohne Rollover-Alias entstand ein Fehler:<\/p>\n
ERROR     Alias \"nginx_write\" nicht gefunden.\nERROR     Aktion konnte nicht abgeschlossen werden: rollover.  : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Wir haben die L\u00f6sung dieses Problems f\u00fcr die n\u00e4chste Iteration zur\u00fcckgestellt und uns mit einem anderen Thema besch\u00e4ftigt: Wir sind zur Pull-Logik von Logstash gewechselt, das f\u00fcr die Verarbeitung eingehender Logs zust\u00e4ndig ist (Entfernung \u00fcberfl\u00fcssiger Informationen und Anreicherung). Wir haben es in Docker platziert, das wir \u00fcber Docker-Compose starten, und dort auch den Logstash-Exporter integriert, der Metriken an Prometheus f\u00fcr die Echtzeit\u00fcberwachung des Logstroms \u00fcbergibt. So haben wir uns die M\u00f6glichkeit gegeben, die Anzahl der Logstash-Instanzen, die f\u00fcr die Verarbeitung jeder Art von Logs zust\u00e4ndig sind, flexibel zu \u00e4ndern.<\/p>\n
W\u00e4hrend wir den Cluster verbesserten, stieg die Besucherzahl von cian.ru auf 12,8 Millionen eindeutige Nutzer pro Monat. In der Folge stellte sich heraus, dass unsere Transformationen mit den \u00c4nderungen in der Produktion nicht ganz Schritt halten konnten, sodass wir mit dem Problem konfrontiert wurden, dass die 'warmen' Knoten mit der Last nicht zurechtkamen und die gesamte Logzustellung verlangsamt wurde. 'Hei\u00dfe' Daten erhielten wir ohne Unterbrechungen, aber bei der Zustellung der anderen mussten wir eingreifen und ein manuelles Roll over durchf\u00fchren, um die Indizes gleichm\u00e4\u00dfig zu verteilen.\u00a0<\/p>\n
Die Skalierung und Anpassung der Logstash-Instanzen im Cluster wurde dadurch erschwert, dass es sich um ein lokales Docker-Compose handelte und alle Aktionen manuell durchgef\u00fchrt werden mussten (um neue Endpunkte hinzuzuf\u00fcgen, musste man manuell alle Server durchgehen und \u00fcberall 'docker-compose up -d' ausf\u00fchren).<\/p>\n
Neuverteilung der Protokolle<\/h3>\n
\nIm September dieses Jahres setzten wir die Zerlegung des Monolithen fort, die Last auf dem Cluster stieg, und der Logstrom n\u00e4herte sich 30.000 Nachrichten pro Sekunde.\u00a0<\/p>\n
\"Meine
\n
\nDie n\u00e4chste Iteration begann mit einem Hardware-Update. Wir reduzierten die Anzahl der Koordinatoren von f\u00fcnf auf drei, ersetzten die Datennodes und gewannen an Kosten und Speicherplatz. F\u00fcr die Nodes verwenden wir zwei Konfigurationen:\u00a0<\/p>\n