Monitoring tot? — Es lebe das Monitoring

Unser Unternehmen beschäftigt sich seit 2008 überwiegend mit dem Management von Infrastruktur und rund um die Uhr technischem Support für Webprojekte. Wir haben mehr als 400 Kunden, was etwa 15 % des E-Commerce in Russland ausmacht. Dementsprechend haben wir einen sehr vielfältigen Support. Wenn etwas ausfällt, sind wir verpflichtet, dies innerhalb von 15 Minuten zu beheben. Um festzustellen, ob eine Störung aufgetreten ist, müssen wir das Projekt überwachen und auf Vorfälle reagieren. Aber wie macht man das?

Ich denke, dass in der Organisation eines effektiven Monitoring-Systems ein großes Problem besteht. Wenn es dieses Problem nicht gäbe, würde meine Rede nur aus einem Satz bestehen: "Bitte installieren Sie Prometheus + Grafana und die Plugins 1, 2, 3." Leider funktioniert es heutzutage nicht mehr so. Das Hauptproblem liegt darin, dass alle weiterhin an etwas glauben, das seit 2008 existiert, wenn man die Softwarekomponenten betrachtet.

Wenn es um den Aufbau eines Überwachungssystems geht, würde ich sagen, dass... es so gut wie keine Projekte mit vernünftiger Überwachung gibt. Die Lage ist so schlecht, dass, wenn etwas ausfällt, die Gefahr besteht, dass dies unbemerkt bleibt - schließlich sind alle überzeugt, dass "alles überwacht wird".
Möglicherweise wird alles überwacht. Aber wie?

Wir alle haben Geschichten wie die folgende erlebt: Ein DevOps-Engineer oder ein Administrator arbeitet, und dann kommt ein Entwicklerteam und sagt - „Wir haben released, jetzt überwache bitte“. Was soll ich überwachen? Wie funktioniert das?

Okay. Wir überwachen die alte Art und Weise. Aber es hat sich bereits etwas geändert, und es stellt sich heraus, dass du den Dienst A überwacht hast, der jetzt zu Dienst B wurde, der mit Dienst C interagiert. Aber das Entwicklerteam sagt dir: „Installiere die Software, sie sollte alles überwachen!“

Was hat sich geändert? - Alles hat sich geändert!

2008. Alles ist großartig.

Es gibt ein paar Entwickler, einen Server und einen Datenbankserver. Darauf basiert alles. Wir haben einige Informationen, installieren Zabbix, Nagios und Cacti. Dann stellen wir verständliche Alarme für CPU, Festplattensysteme und Speicherplatz auf den Festplatten ein. Außerdem führen wir ein paar manuelle Überprüfungen durch, um sicherzustellen, dass die Webseite reagiert und Bestellungen in die Datenbank eingehen. Und das war's – wir sind mehr oder weniger geschützt.

Wenn man das Arbeitsvolumen vergleicht, das der Administrator damals für die Überwachung geleistet hat, war es zu 98 % automatisiert: Die Person, die für die Überwachung zuständig ist, muss verstehen, wie man Zabbix installiert, es konfiguriert und die Alarme einstellt. Die restlichen 2 % entfallen auf externe Überprüfungen: ob die Webseite reagiert und Anfragen an die Datenbank sendet, ob neue Bestellungen eingegangen sind.

2010. Die Last wächst.

Wir beginnen, die Webserver zu skalieren und fügen eine Suchmaschine hinzu. Wir wollen sicherstellen, dass der Produktkatalog alle Produkte enthält. Und dass die Produktsuche funktioniert. Dass die Datenbank läuft, Bestellungen bearbeitet werden, dass die Webseite extern reagiert und von zwei Seiten antwortet. Server und der Nutzer nicht von der Seite geworfen wird, während er auf einen anderen Server umgeschaltet wird, usw. Die Entitäten nehmen zu.

Die Beziehung zur Infrastruktur bleibt nach wie vor das zentrale Thema im Kopf des Managers. Es existiert immer noch die Vorstellung, dass die Person, die für das Monitoring verantwortlich ist, einfach Zabbix installiert und konfigurieren kann.

Gleichzeitig entstehen jedoch Arbeiten für externe Prüfungen, um eine Reihe von Skripten zur Abfrage von Suchindizierern zu erstellen, sowie Skripte zur Überprüfung, dass sich das Suchverhalten während der Indizierung ändert, und Skripte, die sicherstellen, dass die Waren an den Lieferservice übergeben werden, und so weiter.

Beachten Sie: Ich habe dreimal «Satz von Skripten» geschrieben. Das bedeutet, dass der Verantwortliche für das Monitoring nicht mehr nur derjenige ist, der Zabbix installiert. Es ist jemand, der anfängt zu programmieren. Aber im Kopf des Teams hat sich bisher nichts geändert.

Die Welt verändert sich und wird zunehmend komplexer. Es kommen Schichten der Virtualisierung hinzu, mehrere neue Systeme. Diese beginnen, miteinander zu interagieren. Wer hat gesagt "Es riecht nach Microservices?" Aber jeder Service sieht immer noch aus wie eine separate Website. Wir können darauf zugreifen und verstehen, dass er die benötigten Informationen bereitstellt und für sich selbst funktioniert. Und wenn Sie ein Administrator sind, der ständig an einem Projekt arbeitet, das sich über 5, 7 oder 10 Jahre entwickelt hat, sammeln sich diese Kenntnisse an: Ein neues Niveau erscheint — Sie haben es erkannt, ein weiteres Niveau erscheint — Sie haben es erkannt…

Aber selten begleitet jemand ein Projekt über 10 Jahre.

Zusammenfassung des Monitoring-Profis

Stellen Sie sich vor, Sie kommen in ein neues Start-up, das sofort 20 Entwickler eingestellt hat und 15 Microservices geschrieben hat, und Sie sind der Administrator, der gesagt bekommt: "Bitte bauen Sie CI/CD." Sie haben CI/CD aufgebaut und plötzlich hören Sie: "Es fällt uns schwer, mit der Produktion im 'Kubernetes' zu arbeiten, ohne zu verstehen, wie die Anwendung darin läuft. Erstellen Sie uns eine Sandbox im selben 'Kubernetes'."
Sie richten eine Sandbox in diesem Cube ein. Sofort hören Sie: „Wir benötigen eine Datenbank-Stage, die täglich aus der Produktion aktualisiert wird, um sicherzustellen, dass alles auf der Datenbank funktioniert, ohne die Produktionsdatenbank zu beeinträchtigen.“

Sie sind mittendrin. Zwei Wochen bis zum Release, und man sagt Ihnen: „Jetzt müssen wir alles überwachen…“ Das heißt, die Clusterinfrastruktur überwachen, die Microservices-Architektur überwachen, die Interaktion mit externen Services überwachen…

Und die Kollegen ziehen dabei ihre gewohnte Vorgehensweise hervor und sagen: „Hier ist doch alles klar! Installieren Sie ein Programm, das das alles überwacht.“ Ja, genau: Prometheus + Grafana + Plugins.
Und sie fügen hinzu: „Du hast zwei Wochen, mach es so, dass alles zuverlässig ist.“

In vielen Projekten, die wir sehen, wird eine Person für das Monitoring zugewiesen. Stellen Sie sich vor, wir möchten jemanden für zwei Wochen einstellen, der sich um das Monitoring kümmert, und wir erstellen seinen Lebenslauf. Über welche Fähigkeiten sollte diese Person verfügen, wenn wir alles, was wir zuvor gesagt haben, berücksichtigen?

• Er oder sie sollte die Überwachung und die Besonderheiten der Hardware-Infrastruktur verstehen.
• Er sollte die Besonderheiten des Kubernetes-Monitorings verstehen (jeder möchte in "Kube", weil man sich davon abstrahieren kann, sich verstecken kann, während der Admin sich um den Rest kümmert) – sowohl vom Kubernetes selbst als auch von seiner Infrastruktur, und wissen, wie man Anwendungen darin überwacht.
• Er muss verstehen, dass Dienste auf spezielle Weisen miteinander kommunizieren und die Besonderheiten der Interaktion zwischen den Diensten kennen. Es ist durchaus möglich, ein Projekt zu sehen, in dem einige Dienste synchron kommunizieren, weil es anders nicht funktioniert. Zum Beispiel kommuniziert das Backend über REST, geht über gRPC zum Katalogdienst, erhält die Liste der Produkte und gibt sie zurück. Hier kann man nicht warten. Mit anderen Diensten hingegen arbeitet er asynchron. Eine Bestellung an den Lieferdienst übermitteln, eine E-Mail versenden usw.
  Sie sind wahrscheinlich schon von alldem verwirrt? Und der Admin, der das überwachen muss, ist noch verwirrter.
• Er sollte in der Lage sein zu planen und das richtig zu tun – da die Aufgaben immer mehr werden.
• Daher muss er eine Strategie für den entwickelten Service erstellen, um zu verstehen, wie man ihn konkret überwachen kann. Er benötigt ein Verständnis für die Projektarchitektur und deren Entwicklung sowie für die Technologien, die bei der Entwicklung verwendet werden.

Betrachten wir einen absolut normalen Fall: Einige Dienste sind auf PHP, andere auf Go und wieder andere auf JS programmiert. Sie arbeiten irgendwie zusammen. Daher stammt der Begriff „Mikroservice“: Es gibt so viele separate Systeme, dass die Entwickler das Projekt als Ganzes nicht mehr verstehen können. Ein Teil des Teams schreibt Dienste in JS, die autonom arbeiten, ohne zu wissen, wie der Rest des Systems funktioniert. Ein anderer Teil entwickelt Dienste in Python und beschäftigt sich nicht damit, wie die anderen Dienste arbeiten; sie sind in ihrem Bereich isoliert. Ein dritter Teil schreibt Dienste in PHP oder in einer anderen Sprache.
All diese 20 Personen sind auf 15 Dienste verteilt, und es gibt nur einen Administrator, der das alles verstehen muss. Halt! Wir haben gerade das System in 15 Mikroservices unterteilt, weil 20 Personen das gesamte System nicht verstehen können.

Aber wir müssen es irgendwie überwachen...

Was bleibt am Ende? Am Ende gibt es eine Person, die alles versteht, was ein ganzes Entwicklerteam nicht begreifen kann, und die gleichzeitig das Wissen und die Fähigkeiten besitzen muss, die wir oben erwähnt haben – eine robuste Infrastruktur, Kubernetes-Infrastruktur usw.

Was soll man sagen... Houston, wir haben ein Problem.

Die Überwachung eines modernen Softwareprojekts ist an sich ein Softwareprojekt.

Aus der falschen Überzeugung, dass Monitoring nur Software ist, entsteht der Glaube an Wunder. Doch Wunder gibt es leider nicht. Man kann Zabbix installieren und nicht erwarten, dass alles reibungslos läuft. Es macht keinen Sinn, Grafana einzurichten und zu hoffen, dass alles gut läuft. Der Großteil der Zeit wird damit verbracht, die Funktionsweise der Dienste und deren Interaktion zu organisieren sowie die Funktionsweise externer Systeme zu überprüfen. Tatsächlich werden 90 % der Zeit nicht für das Schreiben von Skripten, sondern für die Softwareentwicklung benötigt. Und dafür sollte ein Team zuständig sein, das die Funktionsweise des Projekts versteht.
Wenn in dieser Situation eine Person mit dem Monitoring beauftragt wird, wird es Probleme geben. So läuft es überall.

Zum Beispiel gibt es mehrere Dienste, die über Kafka miteinander kommunizieren. Eine Bestellung wird aufgegeben, und wir senden die Bestellung als Nachricht an Kafka. Es gibt einen Dienst, der die Informationen zur Bestellung überwacht und die Ware versendet. Ein anderer Dienst hört die Informationen zur Bestellung und sendet eine E-Mail an den Benutzer. Dann kommen noch viele weitere Dienste hinzu, und wir beginnen, den Überblick zu verlieren.

Und wenn Sie das noch an den Administrator und die Entwickler übergeben, wenn bis zur Veröffentlichung nicht mehr viel Zeit bleibt, muss die Person das gesamte Protokoll verstehen. Das heißt, ein Projekt in diesem Maßstab benötigt erheblich Zeit, und dies sollte in der Systementwicklung eingeplant werden.
Doch ganz oft, insbesondere in der Gründungsphase, erleben wir, dass das Monitoring aufgeschoben wird. „Zunächst erstellen wir ein Proof of Concept, starten damit und lassen es abstürzen – wir sind bereit, dafür zu opfern. Und später werden wir alles monitoren.“ Wenn (oder falls) das Projekt anfängt, Geld zu bringen, möchte das Unternehmen immer mehr Funktionen entwickeln – denn es funktioniert nun, also muss man weiter anbringen! Doch Sie befinden sich an dem Punkt, an dem zunächst alles Vorangegangene überwacht werden muss, was nicht nur 1% der Zeit in Anspruch nimmt, sondern erheblich mehr. Und übrigens, für das Monitoring benötigen Sie Entwickler, die stattdessen einfacher für neue Funktionen eingesetzt werden können. Am Ende werden neue Features entwickelt, alles wird angestoßen, und Sie geraten in eine endlose Sackgasse.

Wie kann man also das Projekt von Anfang an monitoren, und was tun, wenn Ihnen ein Projekt zugeteilt wurde, das überwacht werden muss, und Sie nicht wissen, wo Sie beginnen sollen?

Zunächst müssen Sie planen.

Lyrisches Einschub: Oft beginnt man mit der Überwachung der Infrastruktur. Zum Beispiel haben wir Kubernetes. Lassen Sie uns zunächst Prometheus mit Grafana installieren und die Plugins zur Überwachung des "Kübels" hinzufügen. Es gibt eine bedauerliche Praxis sowohl bei Entwicklern als auch bei Administratoren: "Wir installieren dieses Plugin, denn es scheint zu wissen, wie es geht." Menschen neigen dazu, mit einfachen und verständlichen Dingen zu beginnen, anstatt mit den wichtigen Tätigkeiten. Und die Überwachung der Infrastruktur ist einfach.

Zunächst sollten Sie entscheiden, was und wie Sie überwachen möchten, und dann das richtige Werkzeug auswählen. Denn andere Menschen können nicht für Sie denken. Sollten sie es auch? Andere dachten an sich selbst, an ein universelles System – oder dachten überhaupt nicht darüber nach, als sie dieses Plugin schrieben. Und nur weil dieses Plugin 5000 Nutzer hat, bedeutet das nicht, dass es irgendeinen Nutzen bringt. Möglicherweise werden Sie der 5001. Nutzer, weil es zuvor schon 5000 gab.

Wenn Sie mit der Überwachung der Infrastruktur begonnen haben und das Backend Ihrer Anwendung nicht mehr reagiert, verlieren alle Benutzer den Zugriff auf die mobile Anwendung. Es wird zu einem Fehler kommen. Sie werden zu Ihnen kommen und sagen: „Die Anwendung funktioniert nicht, was machen Sie hier?“ – „Wir überwachen.“ – „Wie können Sie überwachen, wenn Sie nicht sehen, dass die Anwendung nicht funktioniert?!“

1. Ich denke, dass man mit der Überwachung genau am Eintrittspunkt des Benutzers beginnen sollte. Wenn der Benutzer nicht sieht, dass die Anwendung funktioniert – ist alles verloren. Und das Überwachungssystem sollte in erster Linie darauf hinweisen.
2. Und erst danach können wir die Infrastruktur überwachen. Oder das parallel machen. Mit der Infrastruktur ist es einfacher – hier können wir schließlich einfach Zabbix installieren.
3. Und jetzt müssen wir in die Wurzeln der Anwendung gehen, um zu verstehen, wo etwas nicht funktioniert.

Mein zentraler Gedanke ist – die Überwachung sollte parallel zum Entwicklungsprozess laufen. Wenn Sie das Überwachungsteam mit anderen Aufgaben ablenken (z.B. CI/CD, Sandbox-Erstellung, Umstrukturierung der Infrastruktur), wird die Überwachung hinterherhinken, und möglicherweise werden Sie die Entwicklung nie wieder einholen (oder müssen sie irgendwann stoppen).

Alles auf verschiedenen Ebenen.

So sehe ich die Organisation des Monitoring-Systems.

1) Anwendungsebene:

• Überwachung der Geschäftslogik der Anwendung;
• Überwachung der Gesundheitsmetriken der Dienste;
• Integrationsüberwachung.

2) Infrastrukturebene:

• Überwachung der Orchestrierungsebene;
• Überwachung der Systemsoftware;
• Überwachung der Hardwareebene.

3) Wieder Anwendungsebene — jedoch als ingenieurtechnisches Produkt:

• Sammlung und Beobachtung der Anwendungsprotokolle;
• APM;
• Tracing.

4) Alerting:

• Organisation des Alarmsystems;
• Organisation des Bereitschaftsdienstes;
• Aufbau einer Wissensdatenbank und Workflow für die Bearbeitung von Vorfällen.

Wichtig: Wir kommen nicht erst zum Alerting, sondern gleich zu Beginn! Es ist nicht notwendig, die Überwachung zu starten und 'irgendwann später' zu überlegen, wer die Alerts erhält. Denn was ist das Ziel des Monitorings: herauszufinden, wo in der System etwas nicht funktioniert, und die nötigen Personen darüber zu informieren. Wenn man das bis zuletzt aufschiebt, erfahren die entsprechenden Personen nur über den Anruf: 'Bei uns funktioniert nichts'.

Anwendungsebene — Überwachung der Geschäftslogik

Hier geht es darum, zu überprüfen, ob die Anwendung für den Benutzer funktioniert.

Diese Stufe sollte in der Entwicklungsphase umgesetzt werden. Nehmen wir an, wir haben ein hypothetisches Prometheus: Es greift auf einen Server zu, der Überprüfungen durchführt, ruft den Endpoint auf, und dieser Endpoint prüft dann die API.

Wenn häufig darum gebeten wird, die Hauptseite zu überwachen, um sicherzustellen, dass die Website funktioniert, geben die Programmierer einen Hook, den man jedes Mal ziehen kann, wenn man überprüfen möchte, ob die API funktioniert. In diesem Moment schreiben die Programmierer zudem "/api/test/helloworld".
Der einzige Weg, um sicherzustellen, dass alles funktioniert? – Nein!

• Die Erstellung solcher Überprüfungen ist im Grunde genommen die Aufgabe der Entwickler. Unit-Tests sollten von den Programmierern geschrieben werden, die den Code erstellen. Denn wenn Sie dies an den Admin weitergeben mit: „Hey, hier ist eine Liste der API-Protokolle aller 25 Funktionen, bitte überwache alles!“ – wird das nicht funktionieren.
• Wenn Sie "print 'hello world'" machen, wird niemand jemals erfahren, dass die API tatsächlich funktioniert. Jede Änderung an der API sollte eine entsprechende Änderung der Überprüfungen nach sich ziehen.
• Wenn Sie bereits ein solches Problem haben – halten Sie die Funktionen an und setzen Sie Entwickler ein, die diese Überprüfungen schreiben, oder akzeptieren Sie die Verluste und damit, dass nichts überwacht wird und alles abstürzt.

Technische Tipps:

• Stellen Sie sicher, dass Sie einen externen Server für die Überprüfungen einrichten – Sie müssen sicher sein, dass Ihr Projekt für die Außenwelt zugänglich ist.
• Führen Sie eine Überprüfung über das gesamte API-Protokoll durch und nicht nur über einzelne Endpunkte.
• Erstellen Sie einen Prometheus-Endpunkt mit den Ergebnissen der Überprüfungen.

Anwendungsebene – Überwachung der Health-Metriken

Jetzt konzentrieren wir uns auf die externen Health-Metriken der Dienste.

Wir haben beschlossen, alle „Endpoints“ der Anwendung mithilfe externer Überprüfungen zu überwachen, die wir aus einem externen Überwachungssystem abrufen. Dabei handelt es sich um die „Endpoints“, die der Benutzer sieht. Wir möchten jedoch sicherstellen, dass die Dienste selbst funktionieren. Hier sieht die Situation besser aus: In K8s gibt es Health-Checks, damit zumindest der „Pod“ bestätigen kann, dass der Dienst funktioniert. Aber die Hälfte der Checks, die ich gesehen habe, sind genau diese Print-„Hello World“. Das bedeutet, es wird einmal nach dem Deployment abgefragt, und wenn die Antwort gut ist, war's das. Aber ein Dienst, der über REST seine API bereitstellt, hat eine Vielzahl von Eingangs-/Ausgangspunkten dieser API, die ebenfalls überwacht werden müssen, weil wir wissen möchten, dass sie funktioniert. Und das überwachen wir bereits intern.

Wie dies technisch richtig umgesetzt werden kann: Jeder Dienst stellt einen Endpoint für seinen aktuellen Betriebsstatus bereit, und in Grafana-Diagrammen (oder einer anderen Anwendung) sehen wir den Status aller Dienste.

• Jede Änderung der API sollte eine Anpassung der Prüfungen nach sich ziehen.
• Erstellen Sie neuen Dienst sofort mit Health-Metriken.
• Ein Administrator kann zu den Entwicklern kommen und bitten: 'Fügen Sie mir ein paar Funktionen hinzu, damit ich alles verstehe und diese Informationen in mein Monitoringsystem integrieren kann'. Doch die Entwickler antworten normalerweise: 'Wir werden zwei Wochen vor dem Release nichts mehr hinzufügen.'
  Lassen Sie die Entwicklungsmanager wissen, dass solche Verluste auftreten werden, und auch das Management der Entwicklungsmanager sollte darüber informiert sein. Denn wenn alles ausfällt, wird jemand trotzdem anrufen und verlangen, den 'ständig ausfallenden Dienst' zu überwachen.
• Übrigens, weisen Sie Entwickler an, Plugins für Grafana zu schreiben – das wird eine große Unterstützung für die Administratoren sein.

Anwendungsebene – Integrationsmonitoring

Das Integrationsmonitoring konzentriert sich auf die Überwachung der Kommunikation zwischen geschäftskritischen Systemen.

Zum Beispiel gibt es 15 Dienste, die miteinander kommunizieren. Es handelt sich nicht mehr um separate Webseiten. Das bedeutet, dass wir nicht einfach einen Dienst isoliert aufrufen und /helloworld überprüfen können, um zu sehen, ob er funktioniert. Denn der Webservice zur Auftragsbearbeitung muss Informationen über die Bestellung an den Bus senden — dieser Bus muss das Nachrichtensignal an den Lagerdienst weiterleiten, damit dieser damit arbeiten kann. Der E-Mail-Versanddienst muss dies weiterverarbeiten, und so weiter.

Daher können wir nicht verstehen, indem wir jeden einzelnen Dienst aufrufen, ob das gesamte System funktioniert. Denn wir haben einen zentralen Bus, über den alle kommunizieren und interagieren.
Daher sollte dieser Schritt den Test der Dienste im Hinblick auf die Interaktion mit anderen Diensten umfassen. Es ist nicht möglich, durch die Überwachung des Nachrichtensystems die Kommunikation zu überwachen. Wenn es einen Dienst gibt, der Daten bereitstellt, und einen Dienst, der diese annimmt, werden wir beim Monitoring des Brokers nur die Daten sehen, die hin und her fließen. Selbst wenn wir es schaffen, die Interaktion dieser Daten intern zu überwachen – dass ein Producer Daten veröffentlicht und jemand sie liest, während dieser Fluss weiterhin in Kafka abläuft – erhalten wir trotzdem keine Informationen, falls ein Dienst die Nachricht in einer Version gesendet hat und der andere Dienst diese Version nicht erwartet hat und sie daher überspringt. Das werden wir nicht erfahren, da uns die Dienste sagen werden, dass alles funktioniert.

Wie ich empfehle, vorzugehen:

• Für die synchronisierte Kommunikation: der Endpoint führt Anfragen an verbundene Dienste aus. Das heißt, wir nehmen diesen Endpoint, führen ein Skript innerhalb des Dienstes aus, das alle Punkte durchläuft und sagt: „Ich kann dort anfragen, und dort anfragen, ich kann dort anfragen…“
• Für asynchrone Kommunikation: Eingehende Nachrichten – der Endpunkt überprüft den Bus auf Testnachrichten und gibt den Verarbeitungsstatus zurück.
• Für asynchrone Kommunikation: Ausgehende Nachrichten – der Endpunkt sendet Testnachrichten an den Bus.

Wie gewohnt läuft es ab: Wir haben einen Service, der Daten in den Bus einspeist. Wir wenden uns an diesen Service und fragen nach seinem Integrationsstatus. Wenn der Service eine Nachricht an eine andere Stelle (WebApp) weiterleiten soll, produziert er diese Testnachricht. Wenn wir den Service in der Auftragsbearbeitung ansprechen, veröffentlicht er zunächst die unabhängigen Daten, die er hat. Falls es abhängige Elemente gibt, liest er eine Reihe von Testnachrichten aus dem Bus, versteht, welche er verarbeiten kann, gibt dies bekannt und veröffentlicht sie weiter, wenn nötig. Er sagt dann, alles in Ordnung, ich bin verfügbar.

Sehr oft hören wir die Frage: "Wie können wir das mit echten Daten testen?" Nehmen wir als Beispiel den Bestellservice. Eine Bestellung sendet Nachrichten an das Lager, in dem die Produkte abgebucht werden: Wir können das nicht mit echten Daten testen, denn "Ich habe Produkte, die abgebucht werden!" Die Lösung: Planen Sie diesen Test von Anfang an. Sie haben Unit-Tests, die Mock-Daten verwenden. Also führen Sie das auf einer tieferen Ebene durch, wo Sie einen Kommunikationskanal haben, der den Geschäftsbetrieb nicht stört.

Infrastrukturebene

Infrastrukturmonitoring gilt seit langem als das eigentliche Monitoring.

• Infrastrukturmonitoring sollte als separater Prozess gestartet werden.
• Beginnen Sie nicht mit der Überwachung der Infrastruktur in einem laufenden Projekt, auch wenn die Versuchung groß ist. Das ist ein häufiges Problem für alle DevOps-Profis. "Zuerst überwache ich den Cluster, dann die Infrastruktur" – das heißt, man kümmert sich zuerst um die Grundlagen und vernachlässigt die Anwendung. Denn die Anwendung ist für den DevOps-Experten oft ein schwarzes Loch. Er hat sie geliefert bekommen und versteht nicht, wie sie funktioniert. Die Infrastruktur ist dagegen klarer und darauf konzentriert man sich. Aber nein – immer zuerst die Anwendung überwachen.
• Vermeiden Sie es, die Anzahl der Benachrichtigungen zu übertreiben. Angesichts der Komplexität moderner Systeme kommen die Alarme ständig, und man muss lernen, mit diesem Berg an Alarme zu leben. Ein On-Call-Mitarbeiter, der sich eine Hundertschaft von Alarmen anschaut, denkt sich: "Ich möchte darüber nicht nachdenken." Alarme sollten nur über kritische Ereignisse informieren.

Die Anwendungsebene als Geschäftseinheit

Wichtige Punkte:

• ELK. Das ist der Industriestandard. Wenn Sie aus irgendeinem Grund keine Logs aggregieren, sollten Sie das dringend tun.
• APM. Externe APMs sind eine schnelle Lösung, um die Anwendungsüberwachung zu schließen (NewRelic, BlackFire, Datadog). Sie können dieses Tool vorübergehend einsetzen, um wenigstens einen Eindruck davon zu bekommen, was bei Ihnen vor sich geht.
• Tracing. In vielen Mikrodiensten müssen Sie alles nachverfolgen, da eine Anfrage nicht mehr alleine besteht. Es ist sehr schwierig, später etwas hinzuzufügen, daher ist es besser, das Tracing bereits in der Entwicklung einzuplanen – das ist die Aufgabe und das Werkzeug der Entwickler. Wenn Sie es noch nicht implementiert haben, tun Sie es jetzt! Siehe Jaeger/Zapkin.

Alerting

• Organisation des Alarmierungssystems: Bei der Überwachung zahlreicher Aspekte sollte es ein einheitliches System für die Versendung von Alarmen geben. Dies kann in Grafana realisiert werden. Im Westen verwenden alle PagerDuty. Die Alarme sollten klar verständlich sein (z. B. woher sie stammen…). Es ist außerdem wünschenswert, sicherzustellen, dass die Alarme tatsächlich ankommen.
• Organisation des Bereitschaftsdienstes: Die Alarme sollten nicht an alle gesendet werden (sonst reagieren alle zusammen oder keiner reagiert). Auch Entwickler müssen im Bereitschaftsdienst sein: Definieren Sie unbedingt die Verantwortungsbereiche, erstellen Sie eine klare Anleitung und vermerken Sie, an wen genau man sich am Montag und Mittwoch wenden soll, und an wen am Dienstag und Freitag (ansonsten wird im Falle eines großen Problems niemand anrufen – sie haben Angst, andere zu wecken; Menschen mögen es nicht, andere zu stören, insbesondere nachts). Erklären Sie, dass die Bitte um Hilfe kein Zeichen von Inkompetenz ist ("Ich bitte um Hilfe, also bin ich ein schlechter Mitarbeiter"), und fördern Sie Hilfsanfragen.
• Organisation einer "Wissensdatenbank" und der Workflow zur Bearbeitung von Vorfällen: Für jeden schwerwiegenden Vorfall muss eine Nachbesprechung eingeplant werden, als vorübergehende Maßnahme müssen die Maßnahmen dokumentiert werden, die den Vorfall lösen. Etablieren Sie die Praxis, dass wiederkehrende Alarme ein Fehler sind; diese sollten im Code oder in der Infrastruktur bearbeitet werden.

Technologischer Stack

Lassen Sie uns annehmen, dass unser Stack folgendermaßen aussieht:

• Datensammlung – Prometheus + Grafana;
• Protokollanalyse – ELK;
• für APM oder Tracing – Jaeger (Zipkin).

Die Wahl der Optionen ist nicht kritisch. Wenn Sie zu Beginn verstanden haben, wie Sie Ihr System überwachen können und einen Plan erstellt haben, können Sie danach die Werkzeuge entsprechend Ihren Anforderungen auswählen. Die Frage ist, was Sie anfangs überwachen wollen. Denn vielleicht passt das Werkzeug, das Sie zunächst ausgewählt haben, überhaupt nicht zu Ihren Anforderungen.

Einige technische Punkte, die ich in letzter Zeit überall sehe:

Prometheus wird in Kubernetes integriert – wer hat sich das ausgedacht?! Was machen Sie, wenn Ihr Cluster ausfällt? Wenn Sie einen komplexen Cluster im Inneren haben, sollte ein Überwachungssystem innerhalb des Clusters und eines außerhalb funktionieren, das Daten aus dem Inneren des Clusters sammelt.

Innerhalb des Clusters sammeln wir Protokolle und alles andere. Aber das Überwachungssystem sollte extern sein. Sehr oft gibt es in einem Cluster, in dem Prometheus installiert ist, Systeme, die externe Überprüfungen der Webseitenfunktionalität durchführen. Und was passiert, wenn Ihre Verbindungen zur Außenwelt abgebrochen sind und die Anwendung nicht funktioniert? Es stellt sich heraus, dass innerhalb alles in Ordnung ist, aber das hilft den Nutzern nicht.

Fazit

• Die Entwicklung von Monitoring ist nicht nur die Installation von Tools, sondern die Schaffung eines Softwareprodukts. 98 % des heutigen Monitorings besteht aus Programmierung: Programmierung für Dienste, externe Prüfungen, Überprüfungen von externen Services und vieles mehr.
• Schonen Sie die Zeit Ihrer Entwickler beim Monitoring nicht: Es kann bis zu 30 % ihrer Arbeit in Anspruch nehmen, aber es ist es wert.
• DevOps, macht euch keine Sorgen, wenn ihr etwas nicht überwachen könnt, denn einige Dinge erfordern eine völlig andere Denkweise. Ihr seid keine Programmierer, und das Monitoring ist genau deren Aufgabe.
• Wenn das Projekt bereits läuft und noch nicht überwacht wird (und ihr der Manager seid) – stellt Ressourcen für das Monitoring bereit.
• Wenn das Produkt bereits in Produktion ist und ihr ein DevOps seid, dem gesagt wurde, er solle das Monitoring einrichten – versucht, der Führungskraft zu erklären, worüber ich hier schreibe.

Dies ist die erweiterte Version eines Vortrags auf der Konferenz Saint Highload++.

Wenn euch meine Ideen und Gedanken zu IT und verwandten Themen interessieren, könnt ihr hier den Kanal lesen. 🙂

Quelle: habr.com