Ich heiße Anton Baderin. Ich arbeite im Zentrum für Hochtechnologie und bin für Systemadministration zuständig. Vor einem Monat fand unsere Firmenkonferenz statt, auf der wir unsere Erfahrungen mit der IT-Community unserer Stadt teilten. Ich sprach über das Monitoring von Webanwendungen. Das Material war für Junior- oder Middle-Level gedacht, die diesen Prozess nicht von Grund auf neu aufgebaut haben.
Der Grundpfeiler, auf dem jede Monitoring-Lösung basiert, sind die Anforderungen des Geschäfts. Monitoring nur um des Monitorings willen interessiert niemanden. Was will das Geschäft? Dass alles schnell und fehlerfrei funktioniert. Das Geschäft verlangt Proaktivität, dass wir selbst Probleme im Betrieb des Dienstes erkennen und sie so schnell wie möglich beheben. Das sind im Wesentlichen die Aufgaben, die ich im vergangenen Jahr im Projekt eines unserer Kunden gelöst habe.
Über das Projekt
Das Projekt ist eines der größten Loyalitätsprogramme im Land. Wir helfen Einzelhandelsketten, die Verkaufsfrequenz durch verschiedene Marketinginstrumente wie Bonuskarten zu steigern. Insgesamt umfasst das Projekt 14 Anwendungen, die auf zehn Servern laufen.
Während ich Interviews führte, habe ich mehrmals bemerkt, dass Administratoren nicht immer richtig an das Monitoring von Webanwendungen herangehen: Viele beschränken sich nach wie vor auf die Kennzahlen des Betriebssystems und überwachen sporadisch die Dienste.
In meinem Fall basierte das Monitoring-System des Kunden zuvor auf Icinga. Es konnte die oben genannten Aufgaben nicht lösen. Oft informierte der Kunde selbst uns über Probleme, und nicht selten fehlten uns einfach die Daten, um die Ursache herauszufinden.
Darüber hinaus war das klare Verständnis der Aussichtslosigkeit ihrer weiteren Entwicklung vorhanden. Ich denke, diejenigen, die mit Icinga vertraut sind, werden mich verstehen. Also haben wir beschlossen, das Monitoring-System für Webanwendungen im Projekt vollständig neu zu überarbeiten.
Prometheus
Wir wählten Prometheus basierend auf drei Hauptkriterien:
- Eine enorme Anzahl verfügbarer Metriken. In unserem Fall sind es 60.000. Natürlich ist zu beachten, dass die überwiegende Mehrheit von ihnen nicht verwendet wird (wahrscheinlich etwa 95 %). Auf der anderen Seite sind sie alle relativ günstig. Diese andere Extreme ist im Vergleich zu dem zuvor verwendeten Icinga. Dort war das Hinzufügen von Metriken besonders schmerzhaft: Die vorhandenen waren teuer (man muss sich nur den Quellcode eines beliebigen Plugins ansehen). Jedes Plugin war ein Bash- oder Python-Skript, dessen Ausführung ressourcenintensiv war.
- Dieses System verbraucht relativ wenig Ressourcen. Für all unsere Metriken reichen 600 MB RAM, 15 % eines Kerns und ein paar Dutzend IOPS. Natürlich müssen Metrik-Exporter gestartet werden, aber alle sind in Go geschrieben und sind ebenfalls nicht ressourcenhungrig. Ich glaube nicht, dass dies in der heutigen Zeit ein Problem ist.
- Ermöglicht den Übergang zu Kubernetes. Angesichts der Pläne des Auftraggebers ist die Wahl offensichtlich.
ELK
Früher haben wir keine Protokolle gesammelt und verarbeitet. Die Nachteile sind allen klar. Wir haben uns für ELK entschieden, da wir bereits Erfahrung mit diesem System hatten. Wir speichern dort nur die Protokolle der Anwendungen. Die Hauptkriterien für die Auswahl waren Volltextsuchen und deren Geschwindigkeit.
Clickhouse
Ursprünglich fiel die Wahl auf InfluxDB. Wir waren uns der Notwendigkeit bewusst, Protokolle von Nginx zu sammeln, Statistiken aus pg_stat_statements zu erfassen und historische Daten von Prometheus zu speichern. Influx hat uns nicht gefallen, da es gelegentlich viel Speicher verbrauchte und abstürzte. Außerdem wollten wir Anfragen nach remote_addr gruppieren, aber die Gruppierung in diesem DBMS ist nur nach Tags möglich. Tags sind teuer (Speicher), ihre Anzahl ist bedingt begrenzt.
Wir haben die Suche neu begonnen. Wir benötigten eine analytische Basis mit minimalem Ressourcenverbrauch, vorzugsweise mit Datensicherung auf der Festplatte.
Clickhouse erfüllt all diese Kriterien, und wir haben die Wahl niemals bereut. Wir schreiben keine herausragenden Datenmengen hinein (die Anzahl der Einfügungen beträgt nur etwa fünf Tausend pro Minute).
NewRelic
NewRelic war historisch gesehen immer bei uns, da es die Wahl des Auftraggebers war. Es wird bei uns als APM eingesetzt.
Zabbix
Wir verwenden Zabbix ausschließlich zur Überwachung von Black Box verschiedener APIs.
Definition des Überwachungsansatzes
Wir wollten die Aufgabe dekonstruiert und dadurch den Ansatz zur Überwachung systematisieren.
Dafür habe ich unser System in folgende Ebenen unterteilt:
- „Hardware“ und VMS;
- Betriebssystem;
- Systemdienste, Software-Stack;
- Anwendung;
- Geschäftslogik.
Was den Ansatz so praktisch macht:
- wir wissen, wer für die Funktion jeder dieser Ebenen verantwortlich ist und können daher Warnungen versenden;
- wir können die Struktur beim Unterdrücken von Warnungen nutzen — es wäre seltsam, eine Warnung über die Nichterreichbarkeit einer Datenbank zu versenden, wenn die gesamte virtuelle Maschine nicht erreichbar ist.
Da unsere Aufgabe darin besteht, Störungen im Betrieb des Systems zu identifizieren, müssen wir auf jeder Ebene einen bestimmten Satz von Metriken definieren, auf die wir bei der Erstellung von Alarmierungsregeln achten sollten. Lassen Sie uns nun die Ebenen „VMS“, „Betriebssystem“ und „Systemdienste, Software-Stack“ durchgehen.
Virtuelle Maschinen
Hosting weist uns CPU, Festplatte, Speicher und Netzwerk zu. Bei den ersten beiden hatten wir Probleme. Also, die Metriken:
CPU gestohlene Zeit — wenn Sie eine virtuelle Maschine bei Amazon (z. B. t2.micro) kaufen, sollten Sie verstehen, dass Ihnen kein ganzes Prozessorkern zugewiesen wird, sondern nur ein Kontingent seiner Zeit. Und wenn Sie dieses überschreiten, wird Ihnen die CPU entzogen.
Diese Metrik erlaubt es, solche Momente zu verfolgen und Entscheidungen zu treffen. Zum Beispiel, ob es notwendig ist, einen umfangreicheren Tarif zu wählen oder die Verarbeitung von Hintergrundaufgaben und API-Anfragen auf verschiedene Server.
IOPS + CPU iowait Zeit — aus irgendeinem Grund geben viele Cloud-Hosting-Anbieter nicht genug IOPS. Zudem ist ein Diagramm mit niedrigen IOPS für sie kein Argument. Daher sollten wir auch CPU iowait sammeln. Mit diesem Paar an Diagrammen — mit niedrigen IOPS und hoher E/A-Wartezeit — kann man bereits mit dem Hosting-Anbieter sprechen und das Problem lösen.
Das Betriebssystem
Metriken des Betriebssystems:
- verfügbare Speichermenge in %;
- Aktivität der Nutzung des Swaps: vmstat swapin, swapout;
- Anzahl verfügbarer Inode und freien Speicherplatz im Dateisystem in %
- Durchschnittliche Auslastung;
- Anzahl der Verbindungen im Status tw;
- Füllstand der conntrack-Tabelle;
- Die Qualität des Netzwerks kann mit dem Tool ss und dem Paket iproute2 überwacht werden — wir erhalten aus dessen Ausgabe den RTT-Wert der Verbindungen und gruppieren nach Zielport.
Auf der Ebene des Betriebssystems haben wir auch eine Entität wie Prozesse. Es ist wichtig, in dem System eine Reihe von Prozessen zu identifizieren, die eine wichtige Rolle in seinem Betrieb spielen. Wenn Sie beispielsweise mehrere pgpool haben, sollten Sie Informationen über jeden von ihnen sammeln.
Die Sammlung von Metriken ist wie folgt:
- CPU;
- Speicher ist in erster Linie resident;
- IO — vorzugsweise in IOPS;
- FileFd — offene und limitierte;
- wesentliche Seitenfehler — so können Sie verstehen, welcher Prozess gerade ausgelagert wird.
Die gesamte Überwachung haben wir in Docker implementiert, um Metrikdaten zu sammeln, verwenden wir Cadvisor. Auf anderen Maschinen setzen wir process-exporter ein.
Systemdienste, Software-Stack
Jede Anwendung hat ihre eigenen Besonderheiten, und es ist schwierig, eine bestimmte Metrikansammlung hervorzuheben.
Ein universelles Set sind:
- Anfrage-Rate;
- Anzahl der Fehler;
- Latenz;
- Sättigung.
Die auffälligsten Beispiele für das Monitoring dieses Niveaus bei uns sind — Nginx und PostgreSQL.
Der am stärksten belastete Dienst in unserem System ist die Datenbank. Früher hatten wir oft Schwierigkeiten herauszufinden, womit die Datenbank beschäftigt war.
Wir haben eine hohe Belastung auf die Festplatten gesehen, aber die Slowlogs haben nichts Nennenswertes gezeigt. Dieses Problem haben wir mit Hilfe von pg_stat_statements gelöst, einer Sicht, in der Statistiken zu Anfragen gesammelt werden.
Das ist alles, was ein Administrator braucht.
Wir erstellen Grafiken zur Aktivität von Lese- und Schreibanfragen:
Alles ist einfach und verständlich, jede Anfrage hat ihre eigene Farbe.
Ein nicht minder auffälliges Beispiel sind die Nginx-Logs. Es ist nicht überraschend, dass sie von den wenigsten geparst oder in die Liste der Notwendigkeiten aufgenommen werden. Das Standardformat ist nicht sehr informativ und muss erweitert werden.
Ich persönlich habe request_time, upstream_response_time, body_bytes_sent, request_length, request_id hinzugefügt. Wir erstellen Grafiken zur Antwortzeit und zur Anzahl der Fehler:
Wir erstellen Grafiken zur Antwortzeit und zur Anzahl der Fehler. Erinnern Sie sich? Ich sprach über die Geschäftsanforderungen? Damit alles schnell und fehlerfrei ist? Mit diesen zwei Grafiken haben wir diese Fragen bereits geklärt. Und auf deren Basis können wir die diensthabenden Administratoren anrufen.
Aber es bleibt ein weiteres Problem — die schnelle Beseitigung der Ursachen des Vorfalls sicherzustellen.
Vorfallbeseitigung
Den gesamten Prozess von der Identifizierung bis zur Problemlösung kann man in mehrere Schritte unterteilen:
- Problemerkennung;
- Benachrichtigung des diensthabenden Administrators;
- Reaktion auf den Vorfall;
- Ursachenbeseitigung.
Es ist wichtig, dass wir dies so schnell wie möglich tun. Und wenn wir in den Phasen der Problemerkennung und der Benachrichtigung nicht viel Zeit sparen können — zwei Minuten werden in jedem Fall benötigt — dann sind die nachfolgenden Phasen ein unerschlossenes Feld für Verbesserungen.
Lassen Sie uns einfach vorstellen, dass das Telefon des Bereitschaftsdienstes klingelt. Was wird er tun? Antworten auf die Fragen suchen – was ist kaputt, wo ist es kaputt, wie reagiert man? So beantworten wir diese Fragen:
Wir integrieren einfach all diese Informationen in den Benachrichtigungstext und geben darin einen Link zur Wiki-Seite an, auf der beschrieben wird, wie man auf dieses Problem reagiert, wie man es löst und eskaliert.
Ich habe bisher nichts über die Anwendungsebene und die Geschäftslogik gesagt. Leider ist in unseren Anwendungen die Erfassung von Metriken noch nicht implementiert. Die einzige Quelle für einige Informationen aus diesen Ebenen sind die Protokolle.
Ein paar Punkte.
Erstens, schreiben Sie strukturierte Protokolle. Es ist nicht nötig, den Kontext in den Nachrichtentext einzubeziehen. Das erschwert deren Gruppierung und Analyse. Logstash benötigt viel Zeit, um das alles zu normalisieren.
Zweitens, verwenden Sie die Schweregrade korrekt. Jede Sprache hat ihren eigenen Standard. Ich unterscheide persönlich vier Ebenen:
- keine Fehler;
- fehler auf der Client-Seite;
- Fehler auf unserer Seite, wir verlieren kein Geld und tragen kein Risiko;
- Fehler auf unserer Seite, wir verlieren Geld.
Zusammenfassend. Man sollte versuchen, das Monitoring genau von der Geschäftslogik aus aufzubauen. Versuchen Sie, die Anwendung selbst zu überwachen und mit Metriken wie der Anzahl der Verkäufe, der Anzahl neuer Benutzerregistrierungen, der Anzahl aktiver Benutzer zu operieren.
Wenn Ihr gesamtes Geschäft nur ein Button im Browser ist, müssen Sie überwachen, ob er gedrückt wird und ob er richtig funktioniert. Alles andere ist unwichtig.
Wenn Sie das nicht haben, können Sie versuchen, dies in den Protokollen der Anwendung, den Nginx-Protokollen usw. nachzuholen, wie wir es getan haben. Sie sollten so nah wie möglich an der Anwendung sein.
Metriken des Betriebssystems sind natürlich wichtig, aber sie sind für das Geschäft nicht interessant, wir werden nicht dafür bezahlt.
Quelle: habr.com
