{"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":"Wie wir bei CIAN Terabytes von Logs b\u00e4ndigen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie
\n
\nHallo zusammen, mein Name ist Alexander, ich arbeite als Ingenieur bei CIAN und besch\u00e4ftige mich mit Systemadministration und Automatisierung von Infrastrukturprozessen. In den Kommentaren zu einem unserer fr\u00fcheren Artikel wurden wir gebeten, zu erz\u00e4hlen, woher wir t\u00e4glich 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\u00f6glicht, Probleme schnell zu l\u00f6sen. In diesem Artikel werde ich dar\u00fcber berichten, wie wir ihn im Laufe eines Jahres an die st\u00e4ndig wachsenden Datenstr\u00f6me angepasst haben.
\n<\/a><\/noindex><\/p>\n

Wie wir angefangen haben<\/h3>\n

\n\"Wie
\n
\nIn 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\u00f6glichte, Vorf\u00e4lle z\u00fcgig zu bearbeiten, und wir investierten viel Zeit und Energie in deren L\u00f6sung. Au\u00dferdem konnten wir oft die Ursache des Problems nicht finden, und es trat nach einer gewissen Zeit wieder auf. Es war die H\u00f6lle, und wir mussten etwas daran \u00e4ndern.<\/p>\n

Zu diesem Zeitpunkt verwendeten wir zum Speichern der Logs einen Cluster aus 10 Datenknoten mit ElasticSearch Version 5.5.2 mit standardm\u00e4\u00dfigen Indexeinstellungen. Dieses wurde vor mehr als einem Jahr als popul\u00e4re und zug\u00e4ngliche L\u00f6sung implementiert: Damals war der Logstrom nicht so gro\u00df, und es machte keinen Sinn, unkonventionelle Konfigurationen zu entwickeln.\u00a0<\/p>\n

Die Verarbeitung der eingehenden Logs erfolgte durch Logstash auf verschiedenen Ports auf f\u00fcnf ElasticSearch-Koordinatoren. Ein Index, unabh\u00e4ngig von der Gr\u00f6\u00dfe, bestand aus f\u00fcnf Shards. Es gab eine st\u00fcndliche und t\u00e4gliche 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.\u00a0<\/p>\n

Probleme des schnellen Wachstums<\/h3>\n

\nDas 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\u00fcr den Infrastruktur-Cluster.\u00a0<\/p>\n

Das Skalieren hat dazu gef\u00fchrt, dass der Cluster praktisch unverwaltbar wurde. Als die Protokolle mit einer Geschwindigkeit von 20.000 Nachrichten pro Sekunde eintrafen, erh\u00f6hte die h\u00e4ufige, nutzlose Rotation die Anzahl der Shards auf 6.000, und es kamen mehr als 600 Shards auf einen Knoten.\u00a0<\/p>\n

Dies f\u00fchrte 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\u00f6glich wurde. In dieser Zeit hatten wir keine Protokolle. Und bei einem Problem mit Server<\/a> verloren wir im Prinzip 1\/10 des Clusters. Eine Vielzahl von Indizes kleiner Gr\u00f6\u00dfe machte die Situation noch komplizierter.<\/p>\n

Ohne Protokolle konnten wir die Ursachen des Vorfalls nicht verstehen und h\u00e4tten fr\u00fcher oder sp\u00e4ter die gleichen Fehler wiederholen k\u00f6nnen. In der Ideologie unseres Teams war das unakzeptabel, da alle unsere Arbeitsmechanismen darauf ausgelegt sind, die gleichen Probleme niemals zu wiederholen. Dazu ben\u00f6tigten wir das vollst\u00e4ndige Protokollvolumen und deren Zustellung fast in Echtzeit, da das Team der Bereitschaftsingenieure nicht nur Alerts von Metriken, sondern auch von 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 haben uns zum Ziel gesetzt, den Verlust von Protokollen vollst\u00e4ndig auszuschlie\u00dfen und die Lieferzeit in den ELK-Cluster im Maximum auf 15 Minuten w\u00e4hrend von 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\"Wie
\n
\nMit 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 \u2014 schlie\u00dflich gab es ohnehin keine Protokolle. Daher haben wir diesen Wechsel in nur wenigen Stunden vollzogen.<\/p>\n

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\u00e4hrend Problemen mit ElasticSearch bewahrt. Gleichzeitig haben wir 2 Knoten zum Cluster hinzugef\u00fcgt 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\u00fcrfen \u2014 nginx sowie Logs der Anwendungsfehler. Auf die anderen Knoten gingen weniger wichtige Logs \u2014 debug, warning usw., und nach 24 Stunden wurden \"wichtige\" Logs von den \"hot\" Knoten verschoben.<\/p>\n

Um die Anzahl kleiner Indizes nicht zu erh\u00f6hen, 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\u00f6\u00dfe sehr unzuverl\u00e4ssig 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\u00f6\u00dfe erreicht \u2014 nicht mehr als 50 GB.\u00a0<\/p>\n

Cluster-Optimierung<\/h3>\n

\n\"Wie
\n
\nWir haben jedoch die Probleme nicht vollst\u00e4ndig beseitigt. Leider tauchten weiterhin kleine Indizes auf: Sie erreichten nicht das vorgesehene Volumen, wurden nicht rotiert und gel\u00f6scht durch eine globale Bereinigung der Indizes, die \u00e4lter als drei Tage sind, da wir die zeitgesteuerte Rotation entfernt hatten. Dies f\u00fchrte zu Datenverlusten, da der Index vollst\u00e4ndig 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\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
Bei fehlendem Rollover-Alias trat ein Fehler auf:<\/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
Die L\u00f6sung dieses Problems haben wir auf die n\u00e4chste Iteration verschoben und uns einer anderen Frage gewidmet: Wir sind zur Pull-Logik von Logstash \u00fcbergegangen, die sich mit der Verarbeitung eingehender Protokolle (Entfernung \u00fcberfl\u00fcssiger Informationen und Anreicherung) besch\u00e4ftigt. Wir haben es in Docker platziert, das wir \u00fcber Docker-Compose ausf\u00fchren, und dort auch den Logstash-Exporter untergebracht, der Metriken an Prometheus zur Echtzeit\u00fcberwachung des Protokollflusses \u00fcbergibt. So haben wir uns die M\u00f6glichkeit gegeben, die Anzahl der Logstash-Instanzen, die f\u00fcr die Verarbeitung jeder Art von Protokollen zust\u00e4ndig sind, flexibel zu \u00e4ndern.<\/p>\n
W\u00e4hrend 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 \u00c4nderungen in der Produktion Schritt hielten, und wir sahen uns dem Problem gegen\u00fcber, dass die \"warmen\" Knoten mit der Last \u00fcberfordert waren und die gesamte Protokolllieferung verlangsamten. \"Hei\u00dfe\" Daten erhielten wir ohne Ausf\u00e4lle, aber bei der Lieferung der anderen mussten wir manuell eingreifen und einen Roll-over durchf\u00fchren, um die Indizes gleichm\u00e4\u00dfig zu verteilen.\u00a0<\/p>\n
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\u00fchrt werden mussten (um neue Endpunkte hinzuzuf\u00fcgen, musste man manuell auf allen Servern Docker-Compose up -d ausf\u00fchren).<\/p>\n
Neuverteilung der Protokolle<\/h3>\n
\nIm September dieses Jahres setzten wir weiterhin den Monolithen auseinander, die Last im Cluster nahm zu und der Protokollfluss n\u00e4herte sich 30.000 Nachrichten pro Sekunde.\u00a0<\/p>\n
\"Wie
\n
\nDie n\u00e4chste Iteration begannen wir mit einem Hardware-Upgrade. Von f\u00fcnf Koordinatoren gingen wir auf drei \u00fcber, tauschten die Datenknoten aus und gewannen sowohl finanziell als auch in Bezug auf den Speicherplatz. F\u00fcr die Knoten verwenden wir zwei Konfigurationen:\u00a0<\/p>\n