Ist die Überwachung tot? — Es lebe die Überwachung

Seit 2008 beschäftigt sich unser Unternehmen hauptsächlich mit dem Infrastrukturmanagement und der technischen Unterstützung von Webprojekten rund um die Uhr: Wir haben mehr als 400 Kunden, was etwa 15 % des russischen E-Commerce ausmacht. Dementsprechend wird eine sehr vielfältige Architektur unterstützt. Wenn etwas herunterfällt, sind wir verpflichtet, es innerhalb von 15 Minuten zu reparieren. Um jedoch zu verstehen, dass ein Unfall aufgetreten ist, müssen Sie das Projekt überwachen und auf Vorfälle reagieren. Wie macht man das?

Ich glaube, dass es ein Problem bei der Organisation eines ordnungsgemäßen Überwachungssystems gibt. Wenn es keine Probleme gegeben hätte, würde meine Rede nur aus einer These bestehen: „Bitte installieren Sie Prometheus + Grafana und die Plugins 1, 2, 3.“ Leider funktioniert es so nicht mehr. Und das Hauptproblem besteht darin, dass alle weiterhin an etwas glauben, was 2008 existierte, was Softwarekomponenten angeht.

Was die Organisation des Monitoring-Systems betrifft, wage ich zu behaupten, dass ... Projekte mit kompetentem Monitoring nicht existieren. Und die Situation ist so schlimm, dass die Gefahr besteht, dass etwas unbemerkt bleibt, wenn etwas herunterfällt – schließlich ist sich jeder sicher, dass „alles überwacht wird“.
Vielleicht wird alles überwacht. Aber wie?

Wir alle kennen eine Geschichte wie die folgende: Ein bestimmter Entwickler, ein bestimmter Administrator arbeitet, ein Entwicklungsteam kommt zu ihnen und sagt: „Wir sind freigegeben, jetzt überwachen.“ Was überwachen? Wie es funktioniert?

OK. Wir überwachen auf die altmodische Art und Weise. Und es ändert sich bereits, und es stellt sich heraus, dass Sie Dienst A überwacht haben, der zu Dienst B wurde, der mit Dienst C interagiert. Aber das Entwicklungsteam sagt Ihnen: „Installieren Sie die Software, sie sollte alles überwachen!“

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

2008 Alles ist gut

Es gibt ein paar Entwickler, einen Server, einen Datenbankserver. Von hier aus geht alles weiter. Wir haben einige Informationen, wir installieren Zabbix, Nagios, Kakteen. Und dann legen wir eindeutige Warnungen für die CPU, den Festplattenbetrieb und den Festplattenspeicher fest. Wir führen auch einige manuelle Überprüfungen durch, um sicherzustellen, dass die Website reagiert und Bestellungen in der Datenbank eingehen. Und das ist alles – wir sind mehr oder weniger geschützt.

Wenn wir den Arbeitsaufwand vergleichen, den der Administrator damals für die Überwachung aufgewendet hat, dann erfolgte 98 % davon automatisch: Die Person, die die Überwachung durchführt, muss wissen, wie man Zabbix installiert, wie man es konfiguriert und Warnungen konfiguriert. Und 2 % – für externe Kontrollen: dass die Site antwortet und eine Anfrage an die Datenbank stellt, dass neue Bestellungen eingegangen sind.

2010 Die Belastung wächst

Wir beginnen mit der Skalierung des Webs und fügen eine Suchmaschine hinzu. Wir möchten sicherstellen, dass der Produktkatalog alle Produkte enthält. Und diese Produktsuche funktioniert. Dass die Datenbank funktioniert, dass Bestellungen getätigt werden, dass die Site extern antwortet und von zwei Servern aus antwortet und dass der Benutzer nicht von der Site geworfen wird, während diese auf einen anderen Server umgestellt wird usw. Es gibt mehr Entitäten.

Darüber hinaus bleibt die mit der Infrastruktur verbundene Einheit im Kopf des Managers immer noch die größte. Ich habe immer noch die Idee, dass die Person, die die Überwachung durchführt, die Person ist, die Zabbix installiert und es konfigurieren kann.

Gleichzeitig wird jedoch an der Durchführung externer Prüfungen gearbeitet, an der Erstellung einer Reihe von Suchindexer-Abfrageskripten, einer Reihe von Skripten zur Überprüfung, ob sich die Suche während des Indexierungsprozesses ändert, einer Reihe von Skripten, die überprüfen, ob Waren an die übertragen werden Lieferservice usw. usw.

Hinweis: Ich habe dreimal „eine Reihe von Skripten“ geschrieben. Das heißt, der Verantwortliche für die Überwachung ist nicht mehr derjenige, der zabbix einfach installiert. Dies ist eine Person, die mit dem Codieren beginnt. Aber in den Köpfen der Mannschaft hat sich noch nichts geändert.

Doch die Welt verändert sich und wird immer komplexer. Eine Virtualisierungsschicht und mehrere neue Systeme werden hinzugefügt. Sie beginnen miteinander zu interagieren. Wer hat gesagt: „Riecht nach Microservices“? Aber jeder Dienst sieht für sich immer noch wie eine Website aus. Wir können uns daran wenden und verstehen, dass es die notwendigen Informationen liefert und eigenständig funktioniert. Und wenn Sie ein Administrator sind, der ständig an einem Projekt beteiligt ist, das sich seit 5-7-10 Jahren entwickelt, häuft sich dieses Wissen an: Eine neue Ebene erscheint – Sie haben es erkannt, eine andere Ebene erscheint – Sie haben es erkannt ...

Aber selten begleitet jemand ein Projekt 10 Jahre lang.

Lebenslauf von Monitoringman

Angenommen, Sie kommen zu einem neuen Startup, das sofort 20 Entwickler anstellt, 15 Microservices schreibt, und Sie sind ein Administrator, dem gesagt wird: „Erstellen Sie CI/CD.“ Bitte." Sie haben CI/CD erstellt und plötzlich hören Sie: „Es ist schwierig für uns, mit der Produktion in einem „Cube“ zu arbeiten, ohne zu verstehen, wie die Anwendung darin funktionieren wird. Machen Sie uns zu einer Sandbox im selben „Würfel“.
In diesem Würfel bauen Sie einen Sandkasten. Sie sagen Ihnen sofort: „Wir wollen eine Bühnendatenbank, die täglich von der Produktion an aktualisiert wird, damit wir verstehen, dass sie auf der Datenbank funktioniert, aber gleichzeitig die Produktionsdatenbank nicht beeinträchtigt.“

Du lebst in all dem. Bis zur Veröffentlichung sind es noch 2 Wochen, man sagt dir: „Jetzt lasst uns das alles überwachen ...“ Das heißt. Überwachen Sie die Cluster-Infrastruktur, überwachen Sie die Microservice-Architektur, überwachen Sie die Arbeit mit externen Diensten ...

Und meine Kollegen nehmen das übliche Schema aus dem Kopf und sagen: „Na ja, hier ist alles klar!“ Installieren Sie ein Programm, das das alles überwacht.“ Ja, ja: Prometheus + Grafana + Plugins.
Und sie fügen hinzu: „Sie haben zwei Wochen Zeit, stellen Sie sicher, dass alles sicher ist.“

Bei vielen Projekten, die wir sehen, wird eine Person für die Überwachung eingesetzt. Stellen Sie sich vor, wir möchten eine Person einstellen, die für zwei Wochen die Überwachung übernimmt, und wir schreiben einen Lebenslauf für ihn. Welche Fähigkeiten sollte diese Person nach allem, was wir bisher gesagt haben, haben?

• Er muss die Überwachung und Besonderheiten des Betriebs der Eiseninfrastruktur verstehen.
• Er muss die Besonderheiten der Überwachung von Kubernetes verstehen (und jeder möchte zum „Würfel“ gehen, weil man von allem abstrahieren und sich verstecken kann, weil sich der Administrator um den Rest kümmert) – sich selbst, seine Infrastruktur und verstehen, wie man Anwendungen überwacht innen.
• Er muss verstehen, dass Dienste auf besondere Weise miteinander kommunizieren, und die Besonderheiten kennen, wie Dienste miteinander interagieren. Es ist durchaus möglich, ein Projekt zu sehen, bei dem einige Dienste synchron kommunizieren, denn anders geht es nicht. Das Backend geht zum Beispiel über REST, über gRPC zum Katalogdienst, empfängt eine Produktliste und gibt sie zurück. Sie können es kaum erwarten, hier zu warten. Und mit anderen Diensten funktioniert es asynchron. Übergeben Sie die Bestellung an den Lieferdienst, senden Sie einen Brief usw.
  Du bist wahrscheinlich schon vor all dem geschwommen? Und der Administrator, der dies überwachen muss, wurde noch verwirrter.
• Er muss in der Lage sein, richtig zu planen und zu planen – da die Arbeit immer mehr wird.
• Er muss daher aus dem erstellten Service eine Strategie erstellen, um zu verstehen, wie er diesen konkret überwachen kann. Er benötigt ein Verständnis für die Architektur des Projekts und seine Entwicklung sowie ein Verständnis für die bei der Entwicklung verwendeten Technologien.

Erinnern wir uns an einen ganz normalen Fall: Einige Dienste sind in PHP, einige Dienste sind in Go, einige Dienste sind in JS. Sie arbeiten irgendwie zusammen. Daher kommt auch der Begriff „Microservice“: Es gibt so viele Einzelsysteme, dass Entwickler das Projekt als Ganzes nicht verstehen können. Ein Teil des Teams schreibt Dienste in JS, die eigenständig funktionieren und nicht wissen, wie der Rest des Systems funktioniert. Der andere Teil schreibt Dienste in Python und beeinträchtigt nicht die Funktionsweise anderer Dienste; sie sind in ihrem eigenen Bereich isoliert. Die dritte besteht darin, Dienste in PHP oder etwas anderem zu schreiben.
Alle diese 20 Personen sind in 15 Dienste aufgeteilt, und es gibt nur einen Administrator, der das alles verstehen muss. Stoppen! Wir haben das System einfach in 15 Microservices aufgeteilt, weil 20 Leute das gesamte System nicht verstehen können.

Aber es muss irgendwie überwacht werden ...

Was ist das Ergebnis? Infolgedessen gibt es eine Person, die sich alles ausdenkt, was das gesamte Entwicklerteam nicht verstehen kann, und gleichzeitig muss sie auch wissen und in der Lage sein, das zu tun, was wir oben angegeben haben – Hardware-Infrastruktur, Kubernetes-Infrastruktur usw.

Was soll ich sagen... Houston, wir haben Probleme.

Die Überwachung eines modernen Softwareprojekts ist ein Softwareprojekt für sich

Aus dem falschen Glauben, Überwachung sei Software, entwickeln wir den Glauben an Wunder. Aber Wunder geschehen leider nicht. Sie können Zabbix nicht installieren und erwarten, dass alles funktioniert. Es hat keinen Sinn, Grafana zu installieren und zu hoffen, dass alles gut wird. Die meiste Zeit wird darauf verwendet, Überprüfungen des Betriebs von Diensten und ihrer Interaktion untereinander zu organisieren und die Funktionsweise externer Systeme zu überprüfen. Tatsächlich werden 90 % der Zeit nicht mit dem Schreiben von Skripten, sondern mit der Entwicklung von Software verbracht. Und es sollte von einem Team bearbeitet werden, das die Arbeit des Projekts versteht.
Wenn in dieser Situation eine Person in die Überwachung geworfen wird, wird eine Katastrophe passieren. Das passiert überall.

Beispielsweise gibt es mehrere Dienste, die über Kafka miteinander kommunizieren. Die Bestellung kam an, wir schickten eine Nachricht über die Bestellung an Kafka. Es gibt einen Dienst, der Informationen über die Bestellung abhört und die Ware versendet. Es gibt einen Dienst, der Informationen über die Bestellung abhört und einen Brief an den Benutzer sendet. Und dann tauchen noch eine Menge weiterer Dienste auf und wir geraten in Verwirrung.

Und wenn Sie dies auch dem Administrator und den Entwicklern mitteilen, wenn bis zur Veröffentlichung nur noch kurze Zeit verbleibt, muss die Person das gesamte Protokoll verstehen. Diese. Ein Projekt dieser Größenordnung nimmt viel Zeit in Anspruch und dies sollte bei der Systementwicklung berücksichtigt werden.
Aber sehr oft, insbesondere in Startups, erleben wir, dass die Überwachung auf einen späteren Zeitpunkt verschoben wird. „Jetzt werden wir einen Proof of Concept machen, wir werden damit starten, es fallen lassen – wir sind bereit, Opfer zu bringen.“ Und dann werden wir alles überwachen.“ Wenn (oder wenn) das Projekt anfängt, Geld zu verdienen, möchte das Unternehmen noch mehr Funktionen hinzufügen – weil es bereits funktioniert, muss es also weiter eingeführt werden! Und Sie sind an dem Punkt angelangt, an dem Sie zunächst alles Vorhergehende überwachen müssen, was nicht nur 1 % der Zeit, sondern viel mehr in Anspruch nimmt. Übrigens werden Entwickler für die Überwachung benötigt, und es ist einfacher, sie an neuen Funktionen arbeiten zu lassen. Infolgedessen werden neue Funktionen geschrieben, alles wird durcheinander gebracht und Sie befinden sich in einer endlosen Sackgasse.

Wie überwacht man also ein Projekt von Anfang an und was ist zu tun, wenn man ein Projekt erhält, das überwacht werden muss, aber nicht weiß, wo man anfangen soll?

Zuerst müssen Sie planen.

Lyrischer Exkurs: Sehr oft beginnen sie mit der Überwachung der Infrastruktur. Wir haben zum Beispiel Kubernetes. Beginnen wir mit der Installation von Prometheus mit Grafana und der Installation von Plugins zur Überwachung des „Würfels“. Nicht nur Entwickler, sondern auch Administratoren haben die unglückliche Praxis: „Wir werden dieses Plugin installieren, aber das Plugin weiß wahrscheinlich, wie es geht.“ Menschen fangen lieber mit dem Einfachen und Unkomplizierten an, als mit den wichtigen Handlungen. Und die Überwachung der Infrastruktur ist einfach.

Entscheiden Sie zunächst, was und wie Sie überwachen möchten, und wählen Sie dann ein Tool aus, da andere nicht für Sie denken können. Und sollten sie? Andere dachten an ein universelles System – oder dachten überhaupt nicht daran, als dieses Plugin geschrieben wurde. Und nur weil dieses Plugin 5 Benutzer hat, heißt das nicht, dass es von Nutzen ist. Vielleicht werden Sie der 5001., einfach weil dort schon 5000 Menschen waren.

Wenn Sie mit der Überwachung der Infrastruktur beginnen und das Backend Ihrer Anwendung nicht mehr reagiert, verlieren alle Benutzer die Verbindung zur mobilen Anwendung. Es erscheint ein Fehler. Sie werden zu Ihnen kommen und sagen: „Die Anwendung funktioniert nicht, was machen Sie hier?“ - „Wir überwachen.“ – „Wie überwachen Sie, wenn Sie nicht sehen, dass die Anwendung nicht funktioniert?!“

1. Ich glaube, dass man mit der Überwachung genau am Einstiegspunkt des Benutzers beginnen muss. Wenn der Benutzer nicht sieht, dass die Anwendung funktioniert, liegt ein Fehler vor. Und das Überwachungssystem sollte zuerst davor warnen.
2. Und nur dann können wir die Infrastruktur überwachen. Oder machen Sie es parallel. Mit der Infrastruktur ist es einfacher – hier können wir endlich einfach Zabbix installieren.
3. Und jetzt müssen Sie zu den Wurzeln der Anwendung vordringen, um zu verstehen, wo etwas nicht funktioniert.

Mein Hauptgedanke ist, dass die Überwachung parallel zum Entwicklungsprozess erfolgen sollte. Wenn Sie das Überwachungsteam mit anderen Aufgaben ablenken (Erstellen von CI/CD, Sandboxing, Neuorganisation der Infrastruktur), beginnt die Überwachung zu verzögern und Sie können möglicherweise nie mit der Entwicklung Schritt halten (oder früher oder später müssen Sie sie stoppen).

Alles nach Level

So sehe ich die Organisation eines Überwachungssystems.

1) Anwendungsebene:

• Überwachung der Anwendungsgeschäftslogik;
• Überwachung der Gesundheitskennzahlen von Diensten;
• Integrationsüberwachung.

2) Infrastrukturebene:

• Überwachung auf Orchestrierungsebene;
• Überwachung der Systemsoftware;
• Überwachung des Eisengehalts.

3) Wieder die Anwendungsebene – aber als Ingenieurprodukt:

• Sammeln und Überwachen von Anwendungsprotokollen;
• APM;
• Rückverfolgung.

4) Alarmierung:

• Organisation eines Warnsystems;
• Organisation eines Pflichtsystems;
• Organisation einer „Wissensdatenbank“ und eines Workflows für die Bearbeitung von Vorfällen.

Es ist wichtig,: Wir werden nicht später, sondern sofort alarmiert! Es besteht keine Notwendigkeit, die Überwachung zu starten und „irgendwie später“ herauszufinden, wer Benachrichtigungen erhält. Denn die Aufgabe der Überwachung besteht darin, zu verstehen, wo im System etwas nicht funktioniert, und die richtigen Leute darüber zu informieren. Wenn Sie dies bis zum Ende aufschieben, werden die richtigen Leute nur dann wissen, dass etwas schief läuft, wenn sie sagen: „Bei uns funktioniert nichts.“

Anwendungsschicht – Überwachung der Geschäftslogik

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

Diese Ebene sollte während der Entwicklungsphase durchgeführt werden. Wir haben zum Beispiel einen bedingten Prometheus: Er geht an den Server, der die Prüfungen durchführt, ruft den Endpunkt ab, und der Endpunkt geht und prüft die API.

Wenn Programmierer oft gebeten werden, die Homepage zu überwachen, um sicherzustellen, dass die Site funktioniert, geben sie einen Griff an, der jedes Mal gezogen werden kann, wenn sie sicherstellen müssen, dass die API funktioniert. Und Programmierer nehmen und schreiben derzeit immer noch /api/test/helloworld
Der einzige Weg, um sicherzustellen, dass alles funktioniert? - Nein!

• Die Erstellung solcher Prüfungen ist grundsätzlich Aufgabe der Entwickler. Unit-Tests sollten von den Programmierern geschrieben werden, die den Code schreiben. Denn wenn Sie dem Administrator sagen: „Alter, hier ist eine Liste der API-Protokolle für alle 25 Funktionen, bitte überwachen Sie alles!“ - Nichts wird klappen.
• Wenn Sie „Hallo Welt“ drucken, wird niemand jemals erfahren, dass die API funktionieren sollte und tatsächlich funktioniert. Jede API-Änderung muss zu einer Änderung der Prüfungen führen.
• Wenn Sie bereits ein solches Problem haben, stoppen Sie die Funktionen und weisen Sie Entwickler zu, die diese Prüfungen schreiben, oder akzeptieren Sie die Verluste, akzeptieren Sie, dass nichts überprüft wird und fehlschlägt.

Technische Tipps:

• Stellen Sie sicher, dass Sie einen externen Server einrichten, um die Kontrollen zu organisieren – Sie müssen sicherstellen, dass Ihr Projekt für die Außenwelt zugänglich ist.
• Organisieren Sie Prüfungen für das gesamte API-Protokoll, nicht nur für einzelne Endpunkte.
• Erstellen Sie einen Prometheus-Endpunkt mit den Testergebnissen.

Anwendungsschicht – Überwachung von Gesundheitsmetriken

Jetzt sprechen wir über externe Gesundheitsmetriken von Diensten.

Wir haben beschlossen, alle „Handles“ der Anwendung mithilfe externer Prüfungen zu überwachen, die wir von einem externen Überwachungssystem aufrufen. Aber das sind die „Handles“, die der Benutzer „sieht“. Wir möchten sicher sein, dass unsere Dienste selbst funktionieren. Hier gibt es eine bessere Geschichte: K8s verfügt über Gesundheitsprüfungen, sodass zumindest der „Würfel“ selbst davon überzeugt werden kann, dass der Dienst funktioniert. Aber die Hälfte der Schecks, die ich gesehen habe, haben den gleichen Aufdruck „Hallo Welt“. Diese. Also zieht er einmal nach dem Einsatz und antwortete, dass alles in Ordnung sei – das ist alles. Und wenn der Dienst eine eigene API bereitstellt, verfügt er über eine große Anzahl von Einstiegspunkten für dieselbe API, die ebenfalls überwacht werden muss, weil wir wissen möchten, dass sie funktioniert. Und wir überwachen es bereits im Inneren.

So implementieren Sie dies technisch richtig: Jeder Dienst stellt einen Endpunkt über seine aktuelle Leistung bereit, und in den Diagrammen von Grafana (oder einer anderen Anwendung) sehen wir den Status aller Dienste.

• Jede API-Änderung muss zu einer Änderung der Prüfungen führen.
• Erstellen Sie sofort einen neuen Dienst mit Gesundheitsmetriken.
• Ein Administrator kann zu den Entwicklern kommen und fragen: „Fügen Sie mir ein paar Funktionen hinzu, damit ich alles verstehe und Informationen dazu zu meinem Überwachungssystem hinzufüge.“ Aber Entwickler antworten normalerweise: „Wir werden zwei Wochen vor der Veröffentlichung nichts hinzufügen.“
  Teilen Sie den Entwicklungsleitern mit, dass es solche Verluste geben wird, und informieren Sie auch die Geschäftsführung der Entwicklungsleiter. Denn wenn alles zusammenbricht, wird immer noch jemand anrufen und verlangen, den „ständig fallenden Dienst“ zu überwachen (c)
• Beauftragen Sie übrigens Entwickler damit, Plugins für Grafana zu schreiben – das wird eine gute Hilfe für Administratoren sein.

Anwendungsschicht – Integrationsüberwachung

Der Schwerpunkt der Integrationsüberwachung liegt auf der Überwachung der Kommunikation zwischen geschäftskritischen Systemen.

Beispielsweise gibt es 15 Dienste, die miteinander kommunizieren. Dies sind keine separaten Websites mehr. Diese. Wir können den Dienst nicht alleine abrufen, /helloworld abrufen und verstehen, dass der Dienst ausgeführt wird. Denn der bestellende Webservice muss Informationen über die Bestellung an den Bus senden – vom Bus muss der Lagerservice diese Nachricht empfangen und weiter damit arbeiten. Und der E-Mail-Verteiler muss das irgendwie weiterverarbeiten usw.

Dementsprechend können wir bei Betrachtung jedes einzelnen Dienstes nicht nachvollziehen, dass alles funktioniert. Denn wir haben einen bestimmten Bus, über den alles kommuniziert und interagiert.
Daher sollte diese Phase die Phase des Testens von Diensten auf Interaktion mit anderen Diensten markieren. Es ist unmöglich, die Kommunikationsüberwachung durch Überwachung des Nachrichtenbrokers zu organisieren. Wenn es einen Dienst gibt, der Daten ausgibt, und einen Dienst, der sie empfängt, sehen wir bei der Überwachung des Brokers nur Daten, die hin und her fliegen. Selbst wenn wir es irgendwie geschafft haben, das Zusammenspiel dieser Daten intern zu überwachen – dass ein bestimmter Produzent die Daten veröffentlicht, jemand sie liest, dieser Fluss weiterhin an Kafka geht – wird uns dies immer noch keine Informationen darüber geben, ob ein Dienst die Nachricht in einer Version gesendet hat , aber der andere Dienst hat diese Version nicht erwartet und sie übersprungen. Davon erfahren wir nichts, da die Dienste uns mitteilen, dass alles funktioniert.

Was ich empfehle:

• Für synchrone Kommunikation: Der Endpunkt stellt Anfragen an verwandte Dienste. Diese. Wir nehmen diesen Endpunkt und rufen ein Skript innerhalb des Dienstes ab, das zu allen Punkten geht und sagt: „Ich kann dorthin ziehen, und dort ziehen, ich kann dorthin ziehen ...“
• Für asynchrone Kommunikation: Eingehende Nachrichten – der Endpunkt prüft den Bus auf Testnachrichten und zeigt den Verarbeitungsstatus an.
• Für asynchrone Kommunikation: Ausgehende Nachrichten – der Endpunkt sendet Testnachrichten an den Bus.

Wie üblich: Wir haben einen Dienst, der Daten in den Bus wirft. Wir kommen zu diesem Dienst und bitten Sie, uns etwas über den Integrationszustand zu erzählen. Und wenn der Dienst irgendwo weiter entfernt (WebApp) eine Nachricht erzeugen muss, dann wird er diese Testnachricht erzeugen. Und wenn wir einen Dienst auf der OrderProcessing-Seite ausführen, postet er zuerst das, was er unabhängig posten kann, und wenn es einige abhängige Dinge gibt, dann liest er eine Reihe von Testnachrichten vom Bus, versteht, dass er sie verarbeiten kann, meldet sie und , wenn nötig, poste sie weiter, und dazu sagt er - alles ist in Ordnung, ich lebe.

Sehr oft hören wir die Frage: „Wie können wir das anhand von Kampfdaten testen?“ Wir sprechen zum Beispiel vom gleichen Bestellservice. Der Befehl sendet Nachrichten an das Lager, in dem die Waren abgeschrieben werden: Wir können dies nicht anhand von Kampfdaten testen, denn „Meine Waren werden abgeschrieben!“ Lösung: Planen Sie den gesamten Test von Anfang an. Es gibt auch Unit-Tests, die Mocks erstellen. Tun Sie dies also auf einer tieferen Ebene, wo Sie über einen Kommunikationskanal verfügen, der den Geschäftsbetrieb nicht beeinträchtigt.

Infrastrukturebene

Die Überwachung der Infrastruktur wird seit langem als Überwachung selbst betrachtet.

• Die Überwachung der Infrastruktur kann und sollte als separater Prozess gestartet werden.
• Sie sollten nicht mit der Infrastrukturüberwachung eines laufenden Projekts beginnen, selbst wenn Sie es wirklich möchten. Das ist ein Schmerz für alle Entwickler. „Zuerst überwache ich den Cluster, ich überwache die Infrastruktur“ – d.h. Zunächst wird überwacht, was darunter liegt, aber nicht in die Anwendung übernommen. Weil die Anwendung für Entwickler eine unverständliche Sache ist. Es wurde ihm zugespielt und er versteht nicht, wie es funktioniert. Und er versteht die Infrastruktur und beginnt damit. Aber nein – Sie müssen die Anwendung immer zuerst überwachen.
• Übertreiben Sie es nicht mit der Anzahl der Warnungen. Angesichts der Komplexität moderner Systeme gibt es ständig Warnungen, und man muss irgendwie mit dieser Flut an Warnungen leben. Und der Bereitschaftsdienstmitarbeiter wird, nachdem er sich hunderte der nächsten Alarme angesehen hat, entscheiden: „Ich möchte nicht darüber nachdenken.“ Warnungen sollten nur über kritische Dinge informieren.

Anwendungsebene als Geschäftseinheit

Wichtige Punkte:

• ELCH. Dies ist der Industriestandard. Wenn Sie aus irgendeinem Grund keine Protokolle aggregieren, beginnen Sie sofort damit.
• APM. Externe APMs als Möglichkeit, die Anwendungsüberwachung schnell zu schließen (NewRelic, BlackFire, Datadog). Sie können dieses Ding vorübergehend installieren, um zumindest irgendwie zu verstehen, was mit Ihnen los ist.
• Nachverfolgung. Bei Dutzenden von Microservices muss man alles nachverfolgen, da die Anfrage nicht mehr für sich allein lebt. Es ist sehr schwierig, es später hinzuzufügen, daher ist es besser, die Ablaufverfolgung sofort in der Entwicklung einzuplanen – das ist die Arbeit und der Nutzen der Entwickler. Wenn Sie es noch nicht implementiert haben, implementieren Sie es! Siehe Jaeger/Zipkin

Alarmierung

• Organisation eines Benachrichtigungssystems: Bei der Überwachung einer Reihe von Dingen sollte es ein einheitliches System zum Versenden von Benachrichtigungen geben. Das ist in Grafana möglich. Im Westen nutzt jeder PagerDuty. Warnungen sollten klar sein (z. B. woher sie kommen...). Und es empfiehlt sich zu kontrollieren, ob Benachrichtigungen überhaupt eingehen
• Organisation eines Dienstsystems: Warnungen sollten nicht an alle gesendet werden (entweder reagieren alle in einer Menschenmenge oder niemand reagiert). Entwickler müssen auch auf Abruf sein: Definieren Sie unbedingt Verantwortungsbereiche, machen Sie klare Anweisungen und schreiben Sie darin genau, wen Sie am Montag und Mittwoch und wen am Dienstag und Freitag anrufen sollen (sonst rufen sie auch in der Woche niemanden an). Im Falle eines großen Problems haben sie Angst, Sie zu wecken oder zu stören: Menschen rufen im Allgemeinen nicht gerne andere Menschen an und wecken sie, besonders nachts). Und erklären Sie, dass das Bitten um Hilfe kein Anzeichen für Inkompetenz ist („Ich bitte um Hilfe, das bedeutet, dass ich ein schlechter Arbeiter bin“), und ermutigen Sie dazu, um Hilfe zu bitten.
• Organisation einer „Wissensbasis“ und eines Arbeitsablaufs für die Vorfallbearbeitung: Für jeden schwerwiegenden Vorfall sollte eine Obduktion geplant und als vorübergehende Maßnahme Maßnahmen zur Lösung des Vorfalls aufgezeichnet werden. Und machen Sie es sich zur Gewohnheit, dass wiederholte Warnungen eine Sünde sind; Sie müssen im Code oder in der Infrastruktur behoben werden.

Technologie-Stack

Stellen wir uns vor, dass unser Stapel wie folgt aussieht:

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

Die Wahl der Optionen ist nicht kritisch. Denn wenn Sie zu Beginn verstanden haben, wie Sie das System überwachen und einen Plan aufschreiben, beginnen Sie mit der Auswahl der Tools, die Ihren Anforderungen entsprechen. Die Frage ist, was Sie überhaupt überwachen wollten. Denn vielleicht entspricht das Tool, für das Sie sich zu Beginn entschieden haben, überhaupt nicht Ihren Anforderungen.

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

Prometheus wird in Kubernetes gepusht – wer hat sich das ausgedacht?! Was werden Sie tun, wenn Ihr Cluster abstürzt? Wenn Sie einen komplexen Cluster im Inneren haben, sollte es innerhalb des Clusters eine Art Überwachungssystem und außerhalb des Clusters eine Art Überwachungssystem geben, das Daten aus dem Inneren des Clusters sammelt.

Innerhalb des Clusters sammeln wir Protokolle und alles andere. Aber das Überwachungssystem muss draußen sein. Sehr oft gibt es in einem Cluster, in dem Promtheus intern installiert ist, auch Systeme, die externe Überprüfungen des Betriebs der Site durchführen. Was passiert, wenn Ihre Verbindung zur Außenwelt unterbrochen ist und die Anwendung nicht funktioniert? Es stellt sich heraus, dass im Inneren alles in Ordnung ist, aber es macht die Sache für die Benutzer nicht einfacher.

Befund

• Bei der Überwachung der Entwicklung geht es nicht um die Installation von Dienstprogrammen, sondern um die Entwicklung eines Softwareprodukts. 98 % der heutigen Überwachung erfolgt durch Codierung. Dienste einkodieren, externe Prüfungen kodieren, externe Dienste prüfen, und das ist alles.
• Verschwenden Sie nicht die Zeit Ihrer Entwickler mit der Überwachung: Es kann bis zu 30 % ihrer Arbeit in Anspruch nehmen, aber es lohnt sich.
• Devops, machen Sie sich keine Sorgen, dass Sie etwas nicht überwachen können, denn manche Dinge sind eine völlig andere Denkweise. Sie waren kein Programmierer und die Überwachungsarbeit ist genau ihre Aufgabe.
• Wenn das Projekt bereits läuft und nicht überwacht wird (und Sie ein Manager sind), weisen Sie Ressourcen für die Überwachung zu.
• Wenn das Produkt bereits in Produktion ist und Sie ein Entwickler sind, dem gesagt wurde, er solle „die Überwachung einrichten“, versuchen Sie, dem Management zu erklären, worüber ich das alles geschrieben habe.

Dies ist eine erweiterte Version des Berichts auf der Saint Highload++-Konferenz.

Wenn Sie an meinen Ideen und Gedanken dazu und verwandten Themen interessiert sind, dann können Sie dies hier tun Lesen Sie den Kanal 🙂

Source: habr.com