Mein Name ist Anton Baderin. Ich arbeite im High Technology Center und kümmere mich um die Systemadministration. Vor einem Monat endete unsere Unternehmenskonferenz, auf der wir unsere gesammelten Erfahrungen mit der IT-Community unserer Stadt teilten. Ich habe über die Überwachung von Webanwendungen gesprochen. Das Material war für die untere oder mittlere Ebene gedacht, die diesen Prozess nicht von Grund auf neu aufgebaut hat.
Der Grundstein jedes Überwachungssystems ist die Lösung geschäftlicher Probleme. Überwachung um der Überwachung willen interessiert niemanden. Was will das Unternehmen? Damit alles schnell und fehlerfrei funktioniert. Unternehmen möchten proaktiv sein, sodass wir selbst Probleme im Service erkennen und diese so schnell wie möglich beheben können. Das sind tatsächlich die Probleme, die ich letztes Jahr bei einem Projekt für einen unserer Kunden gelöst habe.
Über das Projekt
Das Projekt ist eines der größten Treueprogramme des Landes. Wir helfen Handelsketten, die Verkaufshäufigkeit durch verschiedene Marketinginstrumente wie Bonuskarten zu erhöhen. Insgesamt umfasst das Projekt 14 Anwendungen, die auf zehn Servern laufen.
Während des Interviewprozesses ist mir immer wieder aufgefallen, dass Administratoren die Überwachung von Webanwendungen nicht immer richtig angehen: Viele konzentrieren sich immer noch auf Betriebssystemmetriken und überwachen gelegentlich Dienste.
In meinem Fall basierte das Überwachungssystem des Kunden bisher auf Icinga. Die oben genannten Probleme wurden dadurch in keiner Weise gelöst. Oft hat uns der Kunde selbst über Probleme informiert, und in den meisten Fällen hatten wir einfach nicht genügend Daten, um der Ursache auf den Grund zu gehen.
Darüber hinaus herrschte ein klares Verständnis für die Sinnlosigkeit seiner Weiterentwicklung. Ich denke, wer Icinga kennt, wird mich verstehen. Deshalb haben wir beschlossen, das Webanwendungsüberwachungssystem für das Projekt komplett neu zu gestalten.
Prometheus
Wir haben uns aufgrund von drei Hauptindikatoren für Prometheus entschieden:
- Eine große Anzahl verfügbarer Metriken. In unserem Fall sind es 60. Natürlich ist es erwähnenswert, dass wir die überwiegende Mehrheit davon (wahrscheinlich etwa 95 %) nicht verwenden. Andererseits sind sie alle relativ günstig. Für uns ist das das andere Extrem im Vergleich zum bisher verwendeten Icinga. Dabei war das Hinzufügen von Metriken besonders mühsam: Die vorhandenen waren teuer (schauen Sie sich einfach den Quellcode eines Plugins an). Jedes Plugin war ein Skript in Bash oder Python, dessen Start im Hinblick auf die verbrauchten Ressourcen teuer ist.
- Dieses System verbraucht relativ wenig Ressourcen. 600 MB RAM, 15 % eines Kerns und ein paar Dutzend IOPS reichen für alle unsere Kennzahlen. Natürlich müssen Sie Metrik-Exporteure ausführen, aber diese sind alle in Go geschrieben und auch nicht sehr energiehungrig. Ich glaube nicht, dass dies in der modernen Realität ein Problem darstellt.
- Bietet die Möglichkeit zur Migration auf Kubernetes. Angesichts der Pläne des Kunden liegt die Wahl auf der Hand.
ELCH
Bisher haben wir keine Protokolle erfasst oder verarbeitet. Die Mängel sind jedem klar. Wir haben uns für ELK entschieden, weil wir bereits Erfahrung mit diesem System hatten. Wir speichern dort ausschließlich Anwendungsprotokolle. Hauptauswahlkriterien waren die Volltextsuche und deren Geschwindigkeit.
Clickhouse
Zunächst fiel die Wahl auf InfluxDB. Wir erkannten die Notwendigkeit, Nginx-Protokolle und Statistiken von pg_stat_statements zu sammeln und historische Prometheus-Daten zu speichern. Influx gefiel uns nicht, weil es regelmäßig viel Speicher verbrauchte und abstürzte. Außerdem wollte ich Abfragen nach remote_addr gruppieren, aber in diesem DBMS erfolgt die Gruppierung nur nach Tags. Tags sind teuer (Speicher), ihre Anzahl ist bedingt begrenzt.
Wir begannen unsere Suche erneut. Benötigt wurde eine analytische Datenbank mit minimalem Ressourcenverbrauch, vorzugsweise mit Datenkomprimierung auf Festplatte.
Clickhouse erfüllt alle diese Kriterien und wir haben unsere Wahl nie bereut. Wir schreiben keine außergewöhnlichen Datenmengen hinein (die Anzahl der Einfügungen beträgt nur etwa fünftausend pro Minute).
NewRelic
NewRelic war schon immer bei uns, weil es die Wahl des Kunden war. Wir verwenden es als APM.
Zabbix
Wir nutzen Zabbix ausschließlich zur Überwachung der Black Box verschiedener APIs.
Definieren eines Überwachungsansatzes
Wir wollten die Aufgabe zerlegen und dadurch den Überwachungsansatz systematisieren.
Dazu habe ich unser System in folgende Ebenen unterteilt:
- Hardware und VMS;
- operationssystem;
- Systemdienste, Software-Stack;
- Anwendung;
- Geschäftslogik.
Warum dieser Ansatz praktisch ist:
- Wir wissen, wer für die Arbeit der einzelnen Ebenen verantwortlich ist, und können auf dieser Grundlage Benachrichtigungen versenden.
- Wir können die Struktur beim Unterdrücken von Warnungen verwenden – es wäre seltsam, eine Warnung über die Nichtverfügbarkeit der Datenbank zu senden, wenn die virtuelle Maschine als Ganzes nicht verfügbar ist.
Da es unsere Aufgabe ist, Verstöße im Systembetrieb zu identifizieren, müssen wir auf jeder Ebene eine bestimmte Reihe von Metriken hervorheben, die es wert sind, beim Schreiben von Alarmierungsregeln beachtet zu werden. Als nächstes gehen wir die Ebenen „VMS“, „Betriebssystem“ und „Systemdienste, Software-Stack“ durch.
Virtuelle Maschinen
Beim Hosting stellen wir Prozessor, Festplatte, Speicher und Netzwerk zur Verfügung. Und mit den ersten beiden hatten wir Probleme. Also die Kennzahlen:
Geraubte CPU-Zeit – wenn Sie eine virtuelle Maschine bei Amazon kaufen (z. B. t2.micro), sollten Sie sich darüber im Klaren sein, dass Ihnen nicht ein ganzer Prozessorkern, sondern nur ein Kontingent seiner Zeit zugewiesen wird. Und wenn Sie es erschöpft haben, wird Ihnen der Prozessor weggenommen.
Mit dieser Metrik können Sie solche Momente verfolgen und Entscheidungen treffen. Ist es beispielsweise notwendig, einen höheren Tarif zu nehmen oder die Verarbeitung von Hintergrundaufgaben und API-Anfragen auf verschiedene Server zu verteilen?
IOPS + CPU-Wartezeit – aus irgendeinem Grund sündigen viele Cloud-Hostings, indem sie nicht genügend IOPS bereitstellen. Darüber hinaus ist ein Zeitplan mit niedrigen IOPS kein Argument für sie. Daher lohnt es sich, CPU-Iowait zu sammeln. Mit diesem Diagrammpaar – mit niedrigen IOPS und hoher I/O-Wartezeit – können Sie bereits mit dem Hosting sprechen und das Problem lösen.
Operationssystem
Betriebssystemmetriken:
- Menge des verfügbaren Speichers in %;
- Swap-Nutzungsaktivität: vmstat swapin, swapout;
- Anzahl der verfügbaren Inodes und freier Speicherplatz im Dateisystem in %
- durchschnittliche Belastung;
- Anzahl der Verbindungen im TW-Zustand;
- conntrack Tabellenfülle;
- Die Qualität des Netzwerks kann mit dem SS-Dienstprogramm, dem Paket iproute2, überwacht werden. Erhalten Sie einen Indikator für RTT-Verbindungen aus der Ausgabe und gruppieren Sie ihn nach Zielport.
Auch auf Betriebssystemebene gibt es eine Entität wie Prozesse. Es ist wichtig, im System eine Reihe von Prozessen zu identifizieren, die für seinen Betrieb eine wichtige Rolle spielen. Wenn Sie beispielsweise über mehrere PGPools verfügen, müssen Sie für jeden von ihnen Informationen sammeln.
Die Metriken sind wie folgt:
- ZENTRALPROZESSOR;
- das Gedächtnis ist in erster Linie resident;
- IO – vorzugsweise in IOPS;
- FileFd – öffnen und begrenzen;
- erhebliche Seitenfehler – auf diese Weise können Sie verstehen, welcher Prozess ausgetauscht wird.
Wir stellen die gesamte Überwachung in Docker bereit und verwenden Advisor, um Metrikdaten zu sammeln. Auf anderen Maschinen verwenden wir Process-Exporter.
Systemdienste, Software-Stack
Jede Anwendung hat ihre eigenen Besonderheiten und es ist schwierig, einen bestimmten Satz von Metriken herauszuarbeiten.
Das universelle Set ist:
- Anfragerate;
- Anzahl der Fehler;
- Latenz;
- Sättigung.
Unsere auffälligsten Beispiele für Überwachung auf dieser Ebene sind Nginx und PostgreSQL.
Der am stärksten belastete Dienst in unserem System ist die Datenbank. In der Vergangenheit hatten wir oft Probleme herauszufinden, was die Datenbank tat.
Wir haben eine hohe Auslastung der Festplatten festgestellt, aber die langsamen Protokolle zeigten nicht wirklich etwas. Wir haben dieses Problem mithilfe von pg_stat_statements gelöst, einer Ansicht, die Abfragestatistiken sammelt.
Das ist alles, was der Administrator braucht.
Wir erstellen Diagramme der Aktivität von Lese- und Schreibanfragen:
Alles ist einfach und klar, jede Anfrage hat ihre eigene Farbe.
Ein ebenso eindrucksvolles Beispiel sind Nginx-Protokolle. Es ist nicht verwunderlich, dass nur wenige Menschen sie analysieren oder in der Liste der Must-Haves 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 erstellen Diagramme der Reaktionszeit und der Anzahl der Fehler. Erinnern? Habe ich über geschäftliche Aufgaben gesprochen? Zu schnell und fehlerfrei? Wir haben diese Themen bereits mit zwei Diagrammen abgedeckt. Und Sie können damit bereits die diensthabenden Administratoren anrufen.
Es bleibt jedoch noch ein Problem: die schnelle Beseitigung der Ursachen des Vorfalls sicherzustellen.
Lösung des Vorfalls
Der gesamte Prozess von der Identifizierung bis zur Lösung eines Problems kann in mehrere Schritte unterteilt werden:
- identifiziere das Problem;
- Benachrichtigung an den diensthabenden Administrator;
- Reaktion auf einen Vorfall;
- Beseitigung der Ursachen.
Es ist wichtig, dass wir dies so schnell wie möglich tun. Und wenn wir in den Phasen der Identifizierung eines Problems und dem Versenden einer Benachrichtigung nicht viel Zeit gewinnen können – zwei Minuten werden in jedem Fall dafür aufgewendet, dann sind die folgenden Phasen einfach ungepflügtes Feld für Verbesserungen.
Stellen wir uns vor, das Telefon des diensthabenden Beamten klingelte. Was wird er tun? Suchen Sie nach Antworten auf Fragen – was ist kaputt gegangen, wo ist es kaputt gegangen, wie soll man reagieren? So beantworten wir diese Fragen:
Wir fügen einfach alle diese Informationen in den Text der Benachrichtigung ein und geben ihr einen Link zu einer Wiki-Seite, die beschreibt, wie auf dieses Problem reagiert, es gelöst und eskaliert werden kann.
Zur Anwendungsschicht und Geschäftslogik habe ich noch nichts gesagt. Leider implementieren unsere Anwendungen noch keine Metrikerfassung. Die einzige Informationsquelle aus diesen Ebenen sind Protokolle.
Ein paar Punkte.
Schreiben Sie zunächst strukturierte Protokolle. Es ist nicht erforderlich, den Kontext in den Text der Nachricht aufzunehmen. Dies macht es schwierig, sie zu gruppieren und zu analysieren. Logstash braucht lange, um das alles zu normalisieren.
Zweitens: Verwenden Sie die Schweregrade richtig. Jede Sprache hat ihren eigenen Standard. Persönlich unterscheide ich vier Ebenen:
- kein Fehler;
- clientseitiger Fehler;
- Der Fehler liegt auf unserer Seite, wir verlieren kein Geld, wir gehen kein Risiko ein;
- Der Fehler liegt auf unserer Seite, wir verlieren Geld.
Lassen Sie mich zusammenfassen. Sie müssen versuchen, eine Überwachung basierend auf Geschäftslogik aufzubauen. Versuchen Sie, die Anwendung selbst zu überwachen und mit Kennzahlen wie der Anzahl der Verkäufe, der Anzahl neuer Benutzerregistrierungen, der Anzahl derzeit aktiver Benutzer usw. zu arbeiten.
Wenn Ihr gesamtes Unternehmen aus einer einzigen Schaltfläche im Browser besteht, müssen Sie überwachen, ob es klickt und ordnungsgemäß funktioniert. Der Rest ist egal.
Wenn Sie dies nicht haben, können Sie versuchen, es in Anwendungsprotokollen, Nginx-Protokollen usw. nachzuholen, wie wir es getan haben. Sie sollten so nah wie möglich an der Anwendung sein.
Betriebssystemkennzahlen sind natürlich wichtig, aber die Wirtschaft interessiert sich nicht dafür, wir werden nicht dafür bezahlt.
Source: habr.com