Protokolle sind ein wichtiger Teil des Systems und geben Ihnen Aufschluss darüber, ob es wie erwartet funktioniert (oder nicht funktioniert). Unter den Bedingungen der Microservice-Architektur wird die Arbeit mit Protokollen zu einer eigenen Disziplin der Sonderolympiade. Es gibt viele Probleme, die angegangen werden müssen:
- wie man Protokolle aus der Anwendung schreibt;
- wo Protokolle geschrieben werden sollen;
- wie Protokolle zur Speicherung und Verarbeitung bereitgestellt werden;
- wie Protokolle verarbeitet und gespeichert werden.
Der Einsatz aktuell populärer Containerisierungstechnologien bringt Sand auf die Waage im Bereich der Problemlösungsmöglichkeiten.
Genau das ist die Abschrift des Berichts von Yuri Bushmelev „Karte eines Rechens im Bereich der Sammlung und Lieferung von Baumstämmen“
Wen kümmert's, bitte unter die Katze.
Mein Name ist Yuri Bushmelev. Ich arbeite für Lazada. Heute werde ich darüber sprechen, wie wir unsere Protokolle erstellt haben, wie wir sie gesammelt haben und was wir dort schreiben.
Wo sind wir her? Wer sind wir? Lazada ist der führende Online-Händler in sechs Ländern Südostasiens. Alle diese Länder sind auf Rechenzentren verteilt. Mittlerweile gibt es insgesamt 1 Rechenzentren. Warum ist das wichtig? Denn einige Entscheidungen waren darauf zurückzuführen, dass zwischen den Zentren eine sehr schwache Verbindung besteht. Wir haben eine Microservice-Architektur. Ich war überrascht, dass wir bereits 4 Microservices haben. Als ich mit der Aufgabe mit den Protokollen angefangen habe, waren es nur 80. Außerdem gibt es noch ein ziemlich großes Stück PHP-Altlast, mit dem ich ebenfalls leben und mich abfinden muss. All dies generiert für uns derzeit mehr als 20 Millionen Nachrichten pro Minute für das Gesamtsystem. Weiter werde ich zeigen, wie wir damit leben wollen und warum das so ist.
Irgendwie muss man mit diesen 6 Millionen Nachrichten leben. Was sollen wir mit ihnen machen? 6 Millionen Nachrichten benötigt:
- aus App senden
- zur Lieferung annehmen
- zur Analyse und Lagerung liefern.
- zu analysieren
- irgendwie lagern.
Als es drei Millionen Nachrichten gab, hatte ich ungefähr das gleiche Aussehen. Weil wir mit ein paar Pennys angefangen haben. Es ist klar, dass dort Anwendungsprotokolle geschrieben werden. Konnte beispielsweise keine Verbindung zur Datenbank herstellen, konnte eine Verbindung zur Datenbank herstellen, konnte aber etwas nicht lesen. Darüber hinaus schreibt jeder unserer Microservices aber auch ein Zugriffsprotokoll. Jede Anfrage, die beim Microservice eintrifft, wird in das Protokoll aufgenommen. Warum machen wir das? Entwickler wollen nachverfolgen können. Jedes Zugriffsprotokoll enthält das Traceid-Feld, anhand dessen eine spezielle Schnittstelle dann die gesamte Kette abwickelt und den Trace schön anzeigt. Der Trace zeigt, wie die Anfrage verlaufen ist, und hilft unseren Entwicklern, mit unbekanntem Müll schneller umzugehen.
Wie kann man damit leben? Nun beschreibe ich kurz den Bereich der Optionen – wie dieses Problem generell gelöst wird. So lösen Sie das Problem des Sammelns, Übertragens und Speicherns von Protokollen.
Wie schreibe ich aus der Bewerbung? Es ist klar, dass es verschiedene Wege gibt. Insbesondere gibt es Best Practice, wie uns Modekameraden erzählen. Es gibt zwei Arten von Old School, wie Großväter sagten. Es gibt andere Möglichkeiten.
Bei der Sammlung von Protokollen ist die Situation ungefähr gleich. Es gibt nicht so viele Möglichkeiten, diesen speziellen Teil zu lösen. Es gibt noch mehr davon, aber noch nicht so viele.
Doch mit der Lieferung und anschließenden Analyse beginnt die Zahl der Variationen zu explodieren. Ich werde jetzt nicht jede Option beschreiben. Ich denke, die wichtigsten Optionen sind jedem bekannt, der sich für das Thema interessiert.
Ich zeige Ihnen, wie wir es bei Lazada gemacht haben und wie alles begann.
Vor einem Jahr kam ich nach Lazada und wurde zum Protokollprojekt geschickt. Dort war es so. Das Protokoll der Anwendung wurde in stdout und stderr geschrieben. Alles wurde auf modische Weise gemacht. Aber dann haben die Entwickler es aus den Standardströmen geworfen, und dann werden Infrastrukturspezialisten es irgendwie herausfinden. Zwischen Infrastrukturspezialisten und Entwicklern gibt es auch Releaser, die sagten: „Äh ... nun, packen wir sie einfach in eine Datei mit einer Shell, und das war’s.“ Und da sich all dies in einem Container befindet, haben sie es direkt in den Container selbst verpackt, das Verzeichnis darin abgebildet und es dort abgelegt. Ich denke, es ist für jeden ziemlich offensichtlich, was passiert ist.
Schauen wir etwas weiter. Wie wir diese Protokolle geliefert haben. Jemand hat sich für td-agent entschieden, was zwar fließend, aber nicht ganz fließend ist. Ich verstehe die Beziehung zwischen diesen beiden Projekten immer noch nicht, aber sie scheinen ungefähr dasselbe zu sein. Und dieser in Ruby geschriebene Fluentd las Protokolldateien und analysierte sie mithilfe einiger regulärer Ausdrücke in JSON. Dann wurden sie zu Kafka geschickt. Darüber hinaus hatten wir in Kafka vier separate Themen für jede API. Warum 4? Weil es Live gibt, es Staging gibt und weil es stdout und stderr gibt. Entwickler produzieren sie, und Infrastrukturarbeiter müssen sie in Kafka erstellen. Darüber hinaus wurde Kafka von einer anderen Abteilung kontrolliert. Daher war es notwendig, ein Ticket zu erstellen, damit dort für jede API 4 Themen erstellt wurden. Jeder hat es vergessen. Im Allgemeinen war es Müll und Verschwendung.
Was haben wir als nächstes damit gemacht? Wir haben es an Kafka geschickt. Weiter von Kafka flog die Hälfte der Protokolle nach Logstash. Die andere Hälfte der Protokolle wurde geteilt. Einige flogen zu einem Graylog, andere zu einem anderen Graylog. Infolgedessen floss alles in einen Elasticsearch-Cluster. Das heißt, dieser ganze Schlamassel ist dort am Ende zusammengebrochen. Das musst du nicht tun!
So sieht es von oben betrachtet aus. Das musst du nicht tun! Dabei werden die Problemstellen gleich mit Nummern gekennzeichnet. Es gibt tatsächlich mehr davon, aber 6 davon sind wirklich problematisch, bei denen etwas getan werden muss. Ich werde jetzt separat darüber berichten.
Hier (1,2,3) schreiben wir Dateien und dementsprechend gibt es hier drei Rechen gleichzeitig.
Der erste (1) ist, dass wir sie irgendwo schreiben müssen. Es ist nicht immer wünschenswert, einer API die Möglichkeit zu geben, direkt in eine Datei zu schreiben. Es ist wünschenswert, dass die API in einem Container isoliert ist und noch besser, dass sie schreibgeschützt ist. Ich bin Systemadministrator und sehe diese Dinge daher etwas anders.
Der zweite Punkt (2,3) ist, dass viele Anfragen an die API gehen. Die API schreibt viele Daten in eine Datei. Die Dateien wachsen. Wir müssen sie rotieren. Denn sonst können Sie dort keine Datenträger speichern. Sie zu rotieren ist schlecht, da sie über die Shell in ein Verzeichnis umgeleitet werden. Es gibt keine Möglichkeit, es zu drehen. Sie können die Anwendung nicht anweisen, die Handles erneut zu öffnen. Denn die Entwickler werden Sie wie einen Idioten ansehen: „Welche Deskriptoren?“ Wir schreiben im Allgemeinen auf stdout. Die Frameworks haben copytruncate in logrotate umgewandelt, wodurch lediglich eine Kopie der Datei erstellt und das Original gebündelt wird. Dementsprechend ist zwischen diesen Kopiervorgängen in der Regel der Speicherplatz auf der Festplatte erschöpft.
(4) Wir hatten unterschiedliche Formate in verschiedenen APIs. Sie waren etwas anders, aber Regexp musste anders geschrieben werden. Da alles von Puppet verwaltet wurde, gab es viele Klassen mit eigenen Kakerlaken. Außerdem konnte der TD-Agent die meiste Zeit sein Gedächtnis fressen, dumm sein, er konnte einfach so tun, als würde er arbeiten, und nichts tun. Äußerlich war es unmöglich zu verstehen, dass er nichts tat. Im besten Fall fällt er und jemand wird ihn später aufheben. Genauer gesagt wird ein Alarm eintreffen und jemand wird ihn mit den Händen auslösen.
(6) Und der größte Müll und Abfall – es war Elasticsearch. Weil es eine alte Version war. Weil wir damals keine engagierten Meister hatten. Wir hatten heterogene Protokolle, deren Felder sich überschneiden konnten. Verschiedene Protokolle verschiedener Anwendungen könnten mit den gleichen Feldnamen geschrieben werden, aber gleichzeitig könnten darin unterschiedliche Daten enthalten sein. Das heißt, ein Protokoll enthält eine Ganzzahl in einem Feld, beispielsweise „level“. Ein weiteres Protokoll enthält einen String im Level-Feld. Ohne statische Zuordnung ergibt sich so etwas Wunderbares. Wenn nach der Indexrotation zuerst eine Nachricht mit einer Zeichenfolge in Elasticsearch eintrifft, leben wir normal. Und wenn die erste mit Integer angekommen ist, werden alle nachfolgenden Nachrichten, die mit String angekommen sind, einfach verworfen. Weil der Feldtyp nicht übereinstimmt.
Wir begannen, diese Fragen zu stellen. Wir beschlossen, nicht nach den Schuldigen zu suchen.
Aber es muss etwas getan werden! Das Offensichtliche ist, dass wir Standards etablieren müssen. Wir hatten bereits einige Standards. Einige haben wir etwas später mitgebracht. Glücklicherweise wurde zu diesem Zeitpunkt bereits ein einziges Protokollformat für alle APIs genehmigt. Es ist direkt in die Service-Interaktionsstandards geschrieben. Wer Protokolle erhalten möchte, sollte dementsprechend diese in diesem Format verfassen. Wenn jemand keine Protokolle in diesem Format schreibt, übernehmen wir keine Garantie.
Darüber hinaus hätte ich gerne einen einzigen Standard für die Methoden zur Aufzeichnung, Übermittlung und Erfassung von Protokollen. Eigentlich, wo man sie schreibt und wie man sie übermittelt. Der Idealfall liegt vor, wenn Projekte dieselbe Bibliothek verwenden. Es gibt eine separate Protokollierungsbibliothek für Go und eine separate Bibliothek für PHP. Jeder, den wir haben, jeder sollte sie nutzen. Im Moment würde ich sagen, dass uns das zu 80 Prozent gelingt. Aber einige essen weiterhin Kakteen.
Und dort (auf der Folie) taucht das „SLA für die Protokollzustellung“ gerade erst auf. Es ist noch nicht so weit, aber wir arbeiten daran. Weil es sehr praktisch ist, wenn Infra sagt, dass wir sie höchstwahrscheinlich dorthin übermitteln werden, wenn Sie in diesem oder jenem Format an diesen oder jenen Ort schreiben und nicht mehr als N Nachrichten pro Sekunde. Es nimmt viele Kopfschmerzen weg. Wenn es ein SLA gibt, dann ist es einfach großartig!
Wie haben wir begonnen, das Problem zu lösen? Der Hauptanteil lag bei td-agent. Es war unklar, wohin unsere Protokolle gehen. Werden sie geliefert? Gehen Sie? Wo sind sie überhaupt? Daher wurde beschlossen, td-agent durch das erste Element zu ersetzen. Optionen, durch was man es ersetzen kann, habe ich hier kurz skizziert.
Fließend. Erstens bin ich ihm bei einem früheren Job begegnet, und dort ist er auch hin und wieder hingefallen. Zweitens ist das dasselbe, nur im Profil.
Filebeat. Wie hat es uns gut getan? Die Tatsache, dass er in Go ist und wir über eine große Expertise in Go verfügen. Dementsprechend könnten wir es, wenn überhaupt, irgendwie zu uns selbst hinzufügen. Deshalb haben wir es nicht genommen. Damit gar nicht erst die Versuchung aufkommt, es selbst neu zu schreiben.
Die offensichtliche Lösung für den Systemadministrator sind alle Arten von Syslogs in dieser Menge (syslog-ng/rsyslog/nxlog).
Oder schreiben Sie etwas Eigenes, aber wir haben es verworfen, ebenso wie Filebeat. Wenn Sie etwas schreiben, ist es besser, etwas zu schreiben, das für das Geschäft nützlich ist. Um Protokolle zu liefern, ist es besser, etwas Fertiges mitzunehmen.
Daher fiel die Wahl tatsächlich auf die Wahl zwischen syslog-ng und rsyslog. Ich habe mich einfach für rsyslog entschieden, weil wir in Puppet bereits Klassen für rsyslog hatten und ich keinen offensichtlichen Unterschied zwischen ihnen feststellen konnte. Was ist Syslog, was ist Syslog? Ja, einige Dokumentationen sind schlechter, andere besser. Er weiß es so, und er macht es anders.
Und ein wenig über rsyslog. Erstens ist es cool, weil es viele Module hat. Es verfügt über ein für Menschen lesbares RainerScript (moderne Konfigurationssprache). Ein toller Bonus ist, dass wir das Verhalten von td-agent mit seinen Standardtools emulieren konnten und sich für Anwendungen nichts geändert hat. Das heißt, wir ändern td-agent in rsyslog und berühren alles andere noch nicht. Und sofort erhalten wir eine funktionierende Lieferung. Als nächstes ist mmnormalize das Coole an rsyslog. Sie können damit Protokolle analysieren, jedoch nicht mit Grok und Regexp. Es erstellt einen abstrakten Syntaxbaum. Es analysiert Protokolle auf die gleiche Weise, wie ein Compiler Quellcode analysiert. Dadurch kann man sehr schnell arbeiten, verbraucht wenig CPU und ist im Großen und Ganzen einfach eine sehr coole Sache. Es gibt eine Reihe weiterer Boni. Ich werde nicht weiter darauf eingehen.
rsyslog hat noch viel mehr Nachteile. Sie sind ungefähr dasselbe wie Boni. Die Hauptprobleme bestehen darin, dass Sie es kochen können und eine Version auswählen müssen.
Wir beschlossen, Protokolle in einem Unix-Socket zu schreiben. Und nicht in /dev/log, weil wir dort ein Durcheinander von Systemprotokollen haben, da ist in dieser Pipeline Journald. Schreiben wir also in einen benutzerdefinierten Socket. Wir werden es einem separaten Regelsatz hinzufügen. Wir wollen uns in nichts einmischen. Alles wird transparent und verständlich sein. Das haben wir tatsächlich getan. Das Verzeichnis mit diesen Sockets wird standardisiert und an alle Container weitergeleitet. Container können den benötigten Socket sehen, ihn öffnen und darauf schreiben.
Warum nicht eine Datei? Denn jeder hat es gelesen , der versucht hat, die Datei an Docker weiterzuleiten, und festgestellt hat, dass sich nach dem Neustart von rsyslog der Dateideskriptor ändert und Docker diese Datei verliert. Er hält etwas anderes offen, aber nicht den gleichen Sockel, in den sie schreiben. Wir beschlossen, dieses Problem und gleichzeitig das Blockierungsproblem zu umgehen.
Rsyslog führt die auf der Folie angegebenen Aktionen aus und sendet Protokolle entweder an Relay oder Kafka. Kafka folgt dem alten Weg. Rayleigh – Ich habe versucht, reines rsyslog zum Übermitteln von Protokollen zu verwenden. Ohne Message Queue, mit Standard-rsyslog-Tools. Im Grunde funktioniert es.
Aber es gibt Nuancen, wie man sie später in diesen Teil stopft (Logstash/Graylog/ES). Dieser Teil (rsyslog-rsyslog) wird zwischen Rechenzentren verwendet. Hier ist ein komprimierter TCP-Link, mit dem Sie Bandbreite sparen und dementsprechend die Wahrscheinlichkeit erhöhen können, dass wir Protokolle von einem anderen Rechenzentrum erhalten, wenn der Kanal voll ist. Denn wir haben Indonesien, wo alles schlecht ist. Darin liegt das ständige Problem.
Wir haben darüber nachgedacht, wie wir eigentlich überwachen, mit welcher Wahrscheinlichkeit die Protokolle, die wir von der Anwendung aufgezeichnet haben, dieses Ziel erreichen? Wir haben beschlossen, Metriken zu starten. Rsyslog verfügt über ein eigenes Statistikerfassungsmodul, das über eine Art Zähler verfügt. Es kann Ihnen beispielsweise die Größe der Warteschlange anzeigen oder wie viele Nachrichten in dieser oder jener Aktion angekommen sind. Da kann man schon etwas von ihnen mitnehmen. Darüber hinaus verfügt es über benutzerdefinierte Zähler, die Sie konfigurieren können, und zeigt Ihnen beispielsweise die Anzahl der Nachrichten an, die eine API aufgezeichnet hat. Als nächstes habe ich rsyslog_exporter in Python geschrieben und wir haben alles an Prometheus gesendet und Diagramme erstellt. Wir wollten unbedingt Graylog-Metriken, hatten aber bisher keine Zeit, sie einzurichten.
Was sind die Probleme? Das Problem entstand durch die Tatsache, dass wir (PLÖTZLICH!) herausfanden, dass unsere Live-APIs 50 Nachrichten pro Sekunde schreiben. Dies ist nur eine Live-API ohne Staging. Und Graylog zeigt uns nur 12 Nachrichten pro Sekunde. Und es stellte sich die berechtigte Frage: Wo sind die Überreste? Daraus haben wir geschlossen, dass Graylog einfach nicht damit klarkommt. Wir haben nachgeschaut, und tatsächlich hat Graylog mit Elasticsearch diesen Ablauf nicht gemeistert.
Als nächstes folgen weitere Entdeckungen, die wir unterwegs gemacht haben.
Schreibvorgänge auf den Socket sind blockiert. Wie ist das passiert? Als ich rsyslog für die Bereitstellung verwendet habe, haben wir irgendwann den Kanal zwischen den Rechenzentren unterbrochen. Die Lieferung erfolgte an einem Ort, die Lieferung erfolgte an einem anderen Ort. All dies ist auf eine Maschine mit APIs zurückzuführen, die in den rsyslog-Socket schreiben. Es gab eine Warteschlange. Dann füllte sich die Warteschlange zum Schreiben in den Unix-Socket, die standardmäßig 128 Pakete umfasst. Und das nächste write() in den Anwendungsblöcken. Als wir uns die Bibliothek angesehen haben, die wir in Go-Anwendungen verwenden, wurde dort geschrieben, dass das Schreiben in den Socket im nicht blockierenden Modus erfolgt. Wir waren sicher, dass nichts blockiert war. Weil wir gelesen haben der darüber geschrieben hat. Aber es gibt einen Moment. Auch um diesen Aufruf herum gab es eine Endlosschleife, in der ständig versucht wurde, eine Nachricht in den Socket zu schieben. Wir haben ihn nicht bemerkt. Ich musste die Bibliothek neu schreiben. Seitdem hat es sich mehrmals geändert, aber jetzt haben wir Sperren in allen Subsystemen beseitigt. Daher können Sie rsyslog stoppen und nichts wird abstürzen.
Es ist notwendig, die Größe der Warteschlangen zu überwachen, um nicht auf diesen Rechen zu treten. Erstens können wir überwachen, wann Nachrichten verloren gehen. Zweitens können wir überwachen, dass wir grundsätzlich Probleme mit der Lieferung haben.
Und noch ein unangenehmer Moment: Die Verstärkung um das Zehnfache in einer Microservice-Architektur ist sehr einfach. Wir haben nicht so viele eingehende Anfragen, aber aufgrund des Diagramms, entlang dem diese Nachrichten weiterlaufen, aufgrund der Zugriffsprotokolle erhöhen wir die Belastung der Protokolle tatsächlich um etwa das Zehnfache. Leider hatte ich keine Zeit, die genauen Zahlen zu berechnen, aber Microservices sind, was sie sind. Dies muss im Hinterkopf behalten werden. Es stellt sich heraus, dass das Protokollsammlungs-Subsystem derzeit in Lazada am stärksten ausgelastet ist.
Wie löst man das Elasticsearch-Problem? Wenn Sie Protokolle schnell an einem Ort abrufen müssen, um nicht alle Maschinen zu durchlaufen und sie dort zu sammeln, verwenden Sie die Dateispeicherung. Das klappt garantiert. Dies erfolgt von jedem Server aus. Sie müssen nur die Datenträger dort anbringen und Syslog einfügen. Danach haben Sie garantiert alle Protokolle an einem Ort. Dann wird es möglich sein, Elasticsearch, Graylog oder etwas anderes langsam zu konfigurieren. Sie verfügen jedoch bereits über alle Protokolle und können diese darüber hinaus speichern, sofern genügend Festplatten-Arrays vorhanden sind.
Zum Zeitpunkt meines Berichts sah das Schema ungefähr so aus. Wir haben praktisch aufgehört, in die Datei zu schreiben. Jetzt werden wir höchstwahrscheinlich die Überreste ausschalten. Auf lokalen Computern, auf denen die API ausgeführt wird, hören wir auf, in Dateien zu schreiben. Erstens gibt es die Dateispeicherung, die sehr gut funktioniert. Zweitens geht diesen Maschinen ständig der Platz aus, Sie müssen ihn ständig überwachen.
Dieser Teil mit Logstash und Graylog ist wirklich ein Höhenflug. Deshalb müssen Sie es loswerden. Sie müssen sich für eines entscheiden.
Wir haben beschlossen, Logstash und Kibana fallen zu lassen. Weil wir eine Sicherheitsabteilung haben. Was ist der Zusammenhang? Der Zusammenhang besteht darin, dass Kibana ohne X-Pack und ohne Shield keine Differenzierung der Zugriffsrechte auf die Protokolle ermöglicht. Deshalb nahmen sie Graylog. Es hat alles. Ich mag es nicht, aber es funktioniert. Wir haben neue Hardware gekauft, dort ein neues Graylog installiert und alle Protokolle mit strengen Formaten in ein separates Graylog verschoben. Wir haben das Problem mit verschiedenen Typen der gleichen Felder organisatorisch gelöst.
Was genau im neuen Graylog enthalten ist. Wir haben einfach alles im Docker geschrieben. Wir nahmen eine Reihe von Servern, führten drei Kafka-Instanzen und sieben Graylog-Server Version 7 ein (weil ich Elasticsearch Version 2.3 wollte). All dies wurde bei Razzien von der Festplatte erhoben. Wir haben eine Indexierungsrate von bis zu 5 Nachrichten pro Sekunde festgestellt. Wir haben die Zahl gesehen, dass 100 Terabyte Daten pro Woche anfallen.
Und wieder ein Rechen! Wir haben zwei Verkäufe vor uns. Wir haben die Grenze von 6 Millionen Beiträgen überschritten. Wir Graylog haben keine Zeit zum Kauen. Irgendwie muss man wieder überleben.
So haben wir überlebt. Ein paar weitere Server und SSDs hinzugefügt. Im Moment leben wir so. Jetzt kauen wir bereits 160 Nachrichten pro Sekunde. Wir haben das Limit noch nicht erreicht, daher ist unklar, wie viel wir realistischerweise daraus herausholen können.
Das sind unsere Pläne für die Zukunft. Die wichtigste davon ist wahrscheinlich die hohe Verfügbarkeit. Wir haben es noch nicht. Mehrere Autos sind gleich aufgebaut, aber bisher läuft alles über ein Auto. Es muss Zeit aufgewendet werden, um ein Failover zwischen ihnen einzurichten.
Sammeln Sie Metriken von Graylog.
Legen Sie eine Ratenbegrenzung fest, damit wir eine verrückte API haben, die uns nicht die Bandbreite und alles andere vernichtet.
Und schließlich schließen Sie eine Art SLA mit den Entwicklern ab, damit wir diesen Service anbieten können. Wenn du mehr schreibst, dann tut es mir leid.
Und Dokumentation schreiben.
Kurz gesagt, die Ergebnisse von allem, was wir erlebt haben. Erstens die Standards. Zweitens ist Syslog ein Kinderspiel. Drittens funktioniert rsyslog genau so, wie es auf der Folie beschrieben ist. Und kommen wir zu den Fragen.
Fragen.
Frage: Warum haben sie sich entschieden, nicht zu nehmen ... (Filebeat?)
Antwort: Muss in eine Datei schreiben. Ich wollte es wirklich nicht. Wenn Ihre API Tausende von Nachrichten pro Sekunde schreibt, ist dies immer noch keine Option, selbst wenn Sie einmal pro Stunde rotieren. Sie können in die Pipe schreiben. Worauf mich die Entwickler fragten: „Was passiert, wenn der Prozess, in dem wir schreiben, zusammenbricht“? Ich fand einfach keine Antwort und sagte: „Na gut, das machen wir nicht.“
Frage: Warum schreiben Sie Protokolle nicht einfach in HDFS?
AntwortA: Dies ist der nächste Schritt. Wir haben ganz am Anfang darüber nachgedacht, aber da es im Moment keine Ressourcen gibt, um damit umzugehen, hängt es von unserer langfristigen Lösung ab.
Frage: Ein Spaltenformat wäre angemessener.
Antwort: Ich verstehe alles. Wir sind mit beiden Händen „dafür“.
Frage: Sie schreiben in rsyslog. Dort stehen sowohl TCP als auch UDP zur Verfügung. Aber wenn UDP, wie garantiert man dann die Lieferung?
AntwortA: Es gibt zwei Punkte. Zunächst sage ich allen sofort, dass wir keine Garantie für die Lieferung von Protokollen übernehmen. Denn wenn die Entwickler kommen und sagen: „Lass uns dort anfangen, Finanzdaten zu schreiben, und du legst sie irgendwo für uns ab, falls etwas passiert“, antworten wir ihnen: „Großartig! Beginnen wir mit dem Blockieren beim Schreiben in den Socket und tun dies in Transaktionen, damit Sie es garantiert für uns in den Socket stecken und sicherstellen, dass wir es von der anderen Seite erhalten haben. Und in diesem Moment wird jeder sofort unnötig. Und wenn nicht, welche Fragen haben wir dann? Wenn Sie keinen Schreibzugriff auf den Socket garantieren möchten, warum sollten wir dann die Lieferung garantieren? Wir geben unser Bestes. Wir versuchen wirklich, so viel wie möglich und so gut wie möglich zu liefern, geben aber keine 100%ige Garantie. Daher müssen Sie dort keine Finanzdaten schreiben. Hierfür gibt es Transaktionsdatenbanken.
Frage: Wenn die API eine Nachricht im Protokoll generiert und die Kontrolle an Microservices überträgt, sind Sie dann auf das Problem gestoßen, dass Nachrichten von verschiedenen Microservices in der falschen Reihenfolge eintreffen? Aus diesem Grund entsteht Verwirrung.
AntwortA: Es ist normal, dass sie in einer anderen Reihenfolge kommen. Darauf müssen Sie vorbereitet sein. Denn jede Netzwerkzustellung garantiert Ihnen keine Ordnung, oder Sie müssen dafür besondere Ressourcen aufwenden. Wenn wir Dateispeicher verwenden, speichert jede API Protokolle in ihrer eigenen Datei. Stattdessen zerlegt rsyslog sie dort in Verzeichnisse. Jede API verfügt dort über eigene Protokolle, in denen Sie nachsehen und diese dann anhand des Zeitstempels in diesem Protokoll vergleichen können. Wenn sie in Graylog suchen, werden sie dort nach Zeitstempel sortiert. Dort wird alles gut.
Frage: Der Zeitstempel kann um Millisekunden variieren.
Antwort: Der Zeitstempel wird von der API selbst generiert. Das ist in der Tat der springende Punkt. Wir haben NTP. Die API generiert bereits in der Nachricht selbst einen Zeitstempel. Es wird nicht von rsyslog hinzugefügt.
Frage: Die Interaktion zwischen Rechenzentren ist nicht ganz klar. Im Rahmen des Rechenzentrums ist ersichtlich, wie die Protokolle erfasst und verarbeitet wurden. Wie ist die Interaktion zwischen Rechenzentren? Oder lebt jedes Rechenzentrum sein eigenes Leben?
Antwort: Fast. Wir haben jedes Land in einem Rechenzentrum untergebracht. Bei uns gibt es derzeit kein Spreading, sodass ein Land in verschiedenen Rechenzentren platziert wird. Daher besteht keine Notwendigkeit, sie zu kombinieren. In jedem Zentrum gibt es ein Log Relay. Dies ist ein Rsyslog-Server. Tatsächlich zwei Verwaltungsmaschinen. Sie sind auf die gleiche Weise aufgebaut. Aber im Moment läuft der Verkehr nur über einen von ihnen. Sie protokolliert alles aggregiert. Für alle Fälle verfügt es über eine Festplattenwarteschlange. Sie presst die Protokolle zusammen und sendet sie an das zentrale Datenzentrum (Singapur), wo sie dann bereits in Graylog vergiftet werden. Und jedes Rechenzentrum verfügt über einen eigenen Dateispeicher. Für den Fall, dass wir die Verbindung verloren haben, haben wir alle Protokolle dort. Sie werden dort bleiben. Sie werden dort gespeichert.
Frage: Erhalten Sie in ungewöhnlichen Situationen Protokolle von dort?
Antwort: Sie können dorthin (zum Dateispeicher) gehen und nachsehen.
Frage: Wie stellen Sie sicher, dass keine Protokolle verloren gehen?
Antwort: Wir verlieren sie tatsächlich und wir beobachten das. Die Überwachung begann vor einem Monat. Die von den Go-APIs verwendete Bibliothek verfügt über Metriken. Sie kann zählen, wie oft es ihr nicht gelungen ist, in den Socket zu schreiben. Da gibt es derzeit eine knifflige Heuristik. Da ist ein Puffer. Es versucht, eine Nachricht von dort an den Socket zu schreiben. Wenn der Puffer überläuft, werden sie gelöscht. Und er zählt, wie viele er fallen gelassen hat. Sollten dort die Zähler überlaufen, werden wir davon erfahren. Sie kommen jetzt auch zu Prometheus, und Sie können die Grafiken in Grafana sehen. Sie können Benachrichtigungen einrichten. Es ist jedoch noch nicht klar, an wen sie geschickt werden sollen.
Frage: In Elasticsearch speichern Sie Protokolle mit Redundanz. Wie viele Replikate haben Sie?
Antwort: Eine Replik.
Frage: Ist es nur eine Zeile?
Antwort: Dies ist der Master und die Replik. Die Daten werden doppelt gespeichert.
Frage: Haben Sie die Größe des Rsyslog-Puffers irgendwie angepasst?
Antwort: Wir schreiben Datagramme in einen benutzerdefinierten Unix-Socket. Dies erlegt uns sofort eine Begrenzung von 128 Kilobyte auf. Wir können nicht mehr darüber schreiben. Wir haben dies in den Standard geschrieben. Wer in den Speicher will, schreibt 128 Kilobyte. Darüber hinaus unterbrechen Bibliotheken die Nachricht und weisen darauf hin, dass die Nachricht abgeschnitten ist. Wir haben im Standard der Nachricht selbst ein spezielles Feld, das anzeigt, ob sie während der Aufnahme abgeschnitten wurde oder nicht. Wir haben also die Möglichkeit, diesen Moment zu verfolgen.
Frage: Schreiben Sie kaputtes JSON?
Antwort: Defekter JSON-Code wird während der Weiterleitung verworfen, da das Paket zu groß ist. Oder Graylog wird gelöscht, da es JSON nicht analysieren kann. Aber es gibt hier Nuancen, die behoben werden müssen, und sie hängen größtenteils mit rsyslog zusammen. Ich habe dort bereits einige Ausgaben ausgefüllt, die noch bearbeitet werden müssen.
Frage: Warum Kafka? Haben Sie RabbitMQ ausprobiert? Graylog summiert sich unter solchen Belastungen nicht?
Antwort: Mit Graylog klappt es nicht. Und Graylog nimmt Gestalt an. Es ist wirklich problematisch für ihn. Er ist so etwas wie ein Ding. Und tatsächlich ist es nicht nötig. Ich schreibe lieber von rsyslog direkt nach Elasticsearch und schaue mir dann Kibana an. Aber wir müssen das Problem mit den Sicherheitsleuten klären. Dies ist eine mögliche Variante unserer Entwicklung, wenn wir Graylog wegwerfen und Kibana verwenden. Logstash ergibt keinen Sinn. Weil ich dasselbe mit rsyslog machen kann. Und es verfügt über ein Modul zum Schreiben in Elasticsearch. Mit Graylog versuchen wir irgendwie zu leben. Wir haben es sogar ein wenig optimiert. Aber es gibt noch Raum für Verbesserungen.
Über Kafka. So geschah es historisch. Als ich ankam, war es bereits da und es wurden bereits Protokolle darauf geschrieben. Wir haben gerade unseren Cluster erstellt und Protokolle dorthin verschoben. Wir managen ihn, wir wissen, wie er sich fühlt. Was RabbitMQ betrifft ... wir haben Probleme mit RabbitMQ. Und RabbitMQ entwickelt sich für uns. Wir haben es in Produktion und es gab Probleme damit. Jetzt, vor dem Verkauf, würde er schamanisiert werden und beginnen, normal zu arbeiten. Aber vorher war ich noch nicht bereit, es in Produktion zu geben. Da ist noch etwas. Graylog kann die AMQP 0.9-Version lesen und rsyslog kann die AMQP 1.0-Version schreiben. Und es gibt keine einzige Lösung, die beides in der Mitte kann. Es gibt entweder das eine oder das andere. Also vorerst nur Kafka. Aber es gibt auch Nuancen. Denn omkafka der von uns verwendeten Version von rsyslog kann den gesamten Nachrichtenpuffer verlieren, den es aus rsyslog aufgenommen hat. Solange wir es ertragen.
Frage: Benutzen Sie Kafka, weil Sie es hatten? Für keinen anderen Zweck verwendet?
Antwort: Kafka, das vom Data Science-Team verwendet wurde. Dabei handelt es sich um ein völlig eigenständiges Projekt, zu dem ich leider nichts sagen kann. Ich weiß nicht. Sie wurde vom Data Science-Team geleitet. Als die Protokolle begannen, beschlossen sie, sie zu verwenden, um keine eigenen Protokolle zu erstellen. Jetzt haben wir Graylog aktualisiert und die Kompatibilität verloren, da es eine alte Version von Kafka gibt. Wir mussten es selbst machen. Gleichzeitig haben wir diese vier Themen für jede API entfernt. Wir haben ein Wide Top für alle Live-Aufnahmen gemacht, ein Wide Wide Top für alle Inszenierungen und wir haben einfach alles dort gedreht. Graylog rechnet das alles parallel.
Frage: Warum brauchen wir diesen Schamanismus mit Steckdosen? Haben Sie versucht, den Syslog-Protokolltreiber für Container zu verwenden?
Antwort: Als wir diese Frage stellten, hatten wir ein angespanntes Verhältnis zum Hafenarbeiter. Es war Docker 1.0 oder 0.9. Docker selbst war seltsam. Zweitens, wenn Sie auch Protokolle hineinschieben ... habe ich den unbestätigten Verdacht, dass alle Protokolle durch sich selbst, durch den Docker-Daemon, weitergeleitet werden. Wenn eine API verrückt spielt, werden die übrigen APIs auf die Tatsache stoßen, dass sie stdout und stderr nicht senden können. Ich weiß nicht, wohin das führen wird. Ich habe den Verdacht, dass es an dieser Stelle nicht notwendig ist, den Docker-Syslog-Treiber zu verwenden. Unsere Abteilung für Funktionstests verfügt über einen eigenen Graylog-Cluster mit Protokollen. Sie verwenden Docker-Protokolltreiber und dort scheint alles in Ordnung zu sein. Aber sie schreiben sofort GELF an Graylog. In dem Moment, als wir mit all dem begannen, brauchten wir einfach, dass es funktionierte. Vielleicht versuchen wir es später, wenn jemand kommt und sagt, dass es seit hundert Jahren normal funktioniert.
Frage: Sie liefern zwischen Rechenzentren mithilfe von rsyslog. Warum nicht über Kafka?
Antwort: Wir machen das, und so ist es wirklich. Aus zwei Gründen. Wenn der Kanal völlig tot ist, können nicht alle unsere Baumstämme, auch nicht in komprimierter Form, durch ihn hindurch klettern. Und Kafka lässt zu, dass sie dabei einfach verlieren. Auf diese Weise vermeiden wir das Festkleben dieser Protokolle. In diesem Fall verwenden wir Kafka direkt. Wenn wir einen guten Kanal haben und ihn freigeben möchten, verwenden wir dessen rsyslog. Aber Sie können es tatsächlich so einrichten, dass es das fallen lässt, was es nicht durchgekommen ist. Im Moment verwenden wir einfach die rsyslog-Zustellung direkt irgendwo, irgendwo bei Kafka.
Source: habr.com