Ich heiße Anton Baderin. Ich arbeite am Center for High Technologies und bin in der Systemadministration tätig. Vor einem Monat endete unsere Unternehmenskonferenz, auf der wir unsere Erfahrungen mit der IT-Community unserer Stadt teilten. Ich habe über die Überwachung von Webanwendungen gesprochen. Das Material war für Junior oder Middle Level gedacht, die diesen Prozess nicht von Grund auf neu aufgebaut haben.
Der Eckpfeiler eines Überwachungssystems ist die Lösung von Geschäftsproblemen. Die Überwachung zum Zwecke der Überwachung ist für niemanden von Interesse. Was will das Geschäft? Damit alles schnell und fehlerfrei funktioniert. Unternehmen wollen Proaktivität, damit wir Probleme im Service selbst identifizieren und so schnell wie möglich beseitigen können. Dies sind in der Tat die Aufgaben, die ich im letzten Jahr im Projekt eines unserer Kunden gelöst habe.
Über das Projekt
Das Projekt ist eines der größten Treueprogramme des Landes. Wir helfen Einzelhändlern, ihre Verkaufsfrequenz durch verschiedene Marketinginstrumente wie Bonuskarten zu erhöhen. Insgesamt umfasst das Projekt 14 Anwendungen, die auf zehn Servern ausgeführt werden.
Bei der Durchführung von Interviews habe ich wiederholt festgestellt, dass Administratoren Webanwendungen bei weitem nicht immer ordnungsgemäß überwachen: Bisher haben viele die Betriebssystemmetriken eingestellt und gelegentlich Dienste überwacht.
In meinem Fall war Icinga zuvor die Basis des Kundenüberwachungssystems. Sie hat die oben genannten Probleme nicht gelöst. Oft hat uns der Kunde selbst über Probleme informiert, und zumindest hatten wir einfach nicht genügend Daten, um dem Grund auf den Grund zu gehen.
Darüber hinaus bestand ein klares Verständnis für die Sinnlosigkeit seiner Weiterentwicklung. Ich denke, diejenigen, die mit Icinga vertraut sind, werden mich verstehen. Daher haben wir uns entschlossen, das Überwachungssystem für Webanwendungen im Projekt komplett neu zu gestalten.
Prometheus
Wir haben Prometheus anhand von drei Schlüsselindikatoren ausgewählt:
- Eine große Anzahl verfügbarer Metriken. In unserem Fall gibt es 60.000 von ihnen. Natürlich ist es erwähnenswert, dass die überwiegende Mehrheit von ihnen nicht verwendet wird (wahrscheinlich etwa 95%). Andererseits sind sie alle relativ billig. Für uns ist dies ein weiteres Extrem im Vergleich zum zuvor verwendeten Icinga. Das Hinzufügen von Metriken war ein besonderes Problem: Die verfügbaren waren teuer (sehen Sie sich nur den Quellcode eines Plugins an). Jedes Plug-In war ein Bash- oder Python-Skript, dessen Start im Hinblick auf die verbrauchten Ressourcen nicht billig ist.
- Dieses System verbraucht relativ wenig Ressourcen. Alle unsere Metriken haben 600 MB RAM, 15% eines Kerns und ein paar Dutzend IOPS. Natürlich müssen Sie Exporteure von Metriken ausführen, aber sie sind alle in Go geschrieben und unterscheiden sich auch nicht in der Völlerei. Ich denke nicht, dass dies in der modernen Realität ein Problem ist.
- Es ermöglicht den Wechsel zu Kubernetes. Angesichts der Pläne des Kunden liegt die Wahl auf der Hand.
ELK
Bisher haben wir keine Protokolle gesammelt oder verarbeitet. Die Mängel sind allen klar. Wir haben uns für ELK entschieden, da wir bereits Erfahrung mit diesem System hatten. Wir speichern dort nur Anwendungsprotokolle. Die Hauptauswahlkriterien waren die Volltextsuche und ihre Geschwindigkeit.
Clickhouse
Die Wahl fiel zunächst auf InfluxDB. Wir haben die Notwendigkeit erkannt, Nginx-Protokolle und Statistiken aus pg_stat_statements zu sammeln und Prometheus-Verlaufsdaten zu speichern. Influx gefiel uns nicht, da es regelmäßig viel Speicher verbrauchte und abstürzte. Außerdem wollte ich Anforderungen nach remote_addr gruppieren und in diesem DBMS nur nach Tags gruppieren. Tags der Straße (Speicher), deren Anzahl bedingt begrenzt ist.
Wir haben die Suche erneut gestartet. Wir brauchten eine analytische Basis mit minimalem Ressourcenverbrauch, vorzugsweise mit Datenkomprimierung auf der Festplatte.
Clickhouse erfüllt all diese Kriterien und wir haben die Wahl nie bereut. Wir schreiben keine ausstehenden Datenmengen hinein (die Anzahl der Einfügungen beträgt nur etwa fünftausend pro Minute).
NewRelic
NewRelic ist seit jeher bei uns, seit es die Wahl des Kunden war. Wir verwenden es als APM.
Zabbix
Wir verwenden Zabbix ausschließlich zur Überwachung der Black Box verschiedener APIs.
Definieren eines Überwachungsansatzes
Wir wollten die Aufgabe zerlegen und damit den Überwachungsansatz systematisieren.
Dazu habe ich unser System in folgende Ebenen unterteilt:
- Hardware und VMS;
- operationssystem;
- Systemdienste, Software-Stack;
- Anwendung
- Geschäftslogik.
Was macht diesen Ansatz bequem:
- Wir wissen, wer für die Arbeit der einzelnen Ebenen verantwortlich ist, und können auf dieser Grundlage Warnungen senden.
- Wir können die Struktur verwenden, um Warnungen zu unterdrücken. Es wäre seltsam, eine Warnung über die Unzugänglichkeit der Datenbank zu senden, wenn auf die virtuelle Maschine im Allgemeinen nicht zugegriffen werden kann.
Da es unsere Aufgabe ist, Unregelmäßigkeiten im System zu erkennen, müssen wir auf jeder Ebene einen bestimmten Satz von Metriken auswählen, die beim Schreiben der Regeln der Warnung berücksichtigt werden sollten. Als nächstes werden wir die Ebenen "VMS", "Betriebssystem" und "Systemdienste, Software-Stack" durchgehen.
Virtuelle Maschinen
Hosting gibt uns einen Prozessor, eine Festplatte, einen Speicher und ein Netzwerk. Und mit den ersten beiden hatten wir Probleme. Also Metriken:
CPU-gestohlene Zeit - Wenn Sie eine virtuelle Maschine bei Amazon kaufen (z. B. t2.micro), sollten Sie verstehen, dass Ihnen nicht ein ganzer Prozessorkern zugewiesen wird, sondern nur ein Teil ihrer Zeit. Und wenn Sie es erschöpfen, wird Ihnen der Prozessor weggenommen.
Mit dieser Metrik können Sie solche Momente verfolgen und Entscheidungen treffen. Ist es beispielsweise erforderlich, einen Tarif fetter zu nehmen oder die Verarbeitung von Hintergrundaufgaben und -anforderungen in der API auf verschiedene Server zu verteilen.
IowaPS + CPU iowait Zeit - aus irgendeinem Grund sündigen viele Cloud-Hosting-Unternehmen, indem sie IOPS nicht bereitstellen. Darüber hinaus ist ein Zeitplan mit niedrigem IOPS kein Argument für sie. Daher lohnt es sich, iowait CPU zu sammeln. Mit diesem Grafikpaar - mit niedrigen IOPS und hohen E / A-Erwartungen - können Sie bereits mit dem Hosting sprechen und das Problem lösen.
Operationssystem
Betriebssystemmetriken:
- Menge des verfügbaren Speichers in%;
- Aktivität mit Swap: vmstat swapin, swapout;
- Die Anzahl der verfügbaren Inodes und des freien Speicherplatzes im Dateisystem in%
- durchschnittliche Belastung;
- Anzahl der Verbindungen in zwei Zuständen;
- Conntrack Tischfülle;
- Die Netzwerkleistung kann mit dem Dienstprogramm ss, iproute2-Paket, überwacht werden. Ruft den RTT-Verbindungsindikator von seiner Ausgabe ab und gruppiert ihn nach Zielport.
Auch auf der Ebene des Betriebssystems haben wir eine Entität wie Prozesse. Es ist wichtig, im System eine Reihe von Prozessen hervorzuheben, die bei seiner Arbeit eine wichtige Rolle spielen. Wenn Sie beispielsweise mehrere pgpool haben, müssen Sie Informationen für jeden von ihnen sammeln.
Der Satz von Metriken lautet wie folgt:
- CPU
- das Gedächtnis ist hauptsächlich resident;
- IO - vorzugsweise in IOPS;
- FileFd - öffnen und begrenzen;
- Signifikante Seitenfehler - damit Sie verstehen, welcher Prozess ausgetauscht wird.
Die gesamte Überwachung wird in Docker bereitgestellt. Wir verwenden advisor, um Metrikdaten zu erfassen. Auf anderen Maschinen verwenden wir Process-Exporter.
Systemdienste, Software-Stack
Jede Anwendung hat ihre eigenen Besonderheiten, und es ist schwierig, bestimmte Metriken zu unterscheiden.
Universelles Set sind:
- Anforderungsrate;
- Anzahl der Fehler;
- Latenz
- Sättigung.
Die auffälligsten Beispiele für die Überwachung auf dieser Ebene sind Nginx und PostgreSQL.
Der am meisten ausgelastete Dienst in unserem System ist die Datenbank. Früher hatten wir oft Probleme, herauszufinden, was die Datenbank tut.
Wir haben eine hohe Belastung der Festplatten gesehen, aber die Slogans zeigten nicht wirklich etwas. Wir haben dieses Problem mit pg_stat_statements gelöst, einer Ansicht, die Statistiken zu Anforderungen sammelt.
Dies ist alles, was der Administrator benötigt.
Wir zeichnen die Aktivität von Lese- und Schreibanforderungen auf:
Alles ist einfach und klar, jede Anfrage hat ihre eigene Farbe.
Ein ebenso auffälliges Beispiel sind Nginx-Protokolle. Es überrascht nicht, dass nur wenige sie analysieren oder in der Liste der erforderlichen erwähnen. Das Standardformat ist nicht sehr informativ und muss erweitert werden.
Persönlich habe ich request_time, upstream_response_time, body_bytes_sent, request_length, request_id hinzugefügt. Wir zeichnen die Antwortzeit und die Anzahl der Fehler auf:
Wir zeichnen die Antwortzeit und die Anzahl der Fehler auf. Erinnerst du dich? Habe ich über Geschäftsziele gesprochen? Zu schnell und fehlerfrei? Wir haben diese Probleme bereits mit zwei Diagrammen abgeschlossen. Und auf ihnen können Sie bereits die Dienstadministratoren anrufen.
Ein weiteres Problem blieb jedoch bestehen - um die rasche Beseitigung der Ursachen des Vorfalls zu gewährleisten.
Incident Management
Der gesamte Prozess von der Identifizierung bis zur Lösung eines Problems kann in mehrere Schritte unterteilt werden:
- Problemidentifikation;
- Benachrichtigung des diensthabenden Administrators;
- Reaktion auf den Vorfall;
- Beseitigung der Ursachen.
Es ist wichtig, dass wir dies so schnell wie möglich tun. Und wenn wir in der Phase der Identifizierung eines Problems und des Versendens einer Benachrichtigung nicht viel Zeit gewinnen können - sie werden in jedem Fall zwei Minuten lang bleiben, dann sind die nächsten nur ein unberührtes Feld für Verbesserungen.
Stellen wir uns vor, das Telefon klingelte im Dienst. Was wird er tun? Suchen Sie nach Antworten auf Fragen - was ist kaputt, wo ist es kaputt, wie soll man reagieren? So beantworten wir diese Fragen:
Wir fügen einfach alle diese Informationen in den Benachrichtigungstext ein und geben ihm einen Link zu einer Wiki-Seite, auf der beschrieben wird, wie auf dieses Problem reagiert, wie es gelöst und eskaliert wird.
Ich habe noch nichts über die Anwendungsschicht und die Geschäftslogik gesagt. Leider wurde die Erfassung von Metriken in unseren Anwendungen noch nicht implementiert. Die einzige Quelle für zumindest einige Informationen aus diesen Ebenen sind die Protokolle.
Ein paar Punkte.
Schreiben Sie zunächst strukturierte Protokolle. Es ist nicht erforderlich, den Kontext in den Nachrichtentext aufzunehmen. Dies macht es schwierig, sie zu gruppieren und zu analysieren. Logstash braucht lange, um all dies zu normalisieren.
Zweitens verwenden Sie die Schweregrade korrekt. Jede Sprache hat ihren eigenen Standard. Persönlich unterscheide ich vier Ebenen:
- kein Fehler;
- clientseitiger Fehler;
- Ein Fehler ist auf unserer Seite, wir verlieren kein Geld, wir tragen kein Risiko.
- Der Fehler ist auf unserer Seite, wir verlieren Geld.
Ich fasse zusammen. Es muss versucht werden, die Überwachung genau aus der Geschäftslogik heraus aufzubauen. Versuchen Sie, die Anwendung selbst zu überwachen und mit Metriken wie der Anzahl der Verkäufe, der Anzahl neuer Benutzerregistrierungen, der Anzahl der derzeit aktiven Benutzer usw. zu arbeiten.
Wenn Ihr gesamtes Unternehmen eine einzelne Schaltfläche in Ihrem Browser ist, müssen Sie überwachen, ob sie gedrückt wird und ordnungsgemäß funktioniert. Alles andere ist nicht wichtig.
Wenn Sie dies nicht haben, können Sie versuchen, es in den Anwendungsprotokollen, Nginx-Protokollen usw. nachzuholen, wie wir es getan haben. Sie sollten so nah wie möglich an der Anwendung sein.
Betriebssystemmetriken sind natürlich wichtig, aber für das Geschäft nicht interessant, wir werden nicht dafür bezahlt.