Sportmaster überwachen – wie und womit

Wir haben darüber nachgedacht, in der Phase der Bildung von Produktteams ein Überwachungssystem einzurichten. Es wurde deutlich, dass unser Geschäft – die Ausbeutung – nicht in diese Teams fällt. Warum so?

Tatsache ist, dass alle unsere Teams um einzelne Informationssysteme, Mikrodienste und Fronten herum aufgebaut sind, sodass die Teams nicht den Gesamtzustand des gesamten Systems als Ganzes sehen. Beispielsweise wissen sie möglicherweise nicht, wie sich ein kleiner Teil im tiefen Backend auf das Frontend auswirkt. Ihr Interessenbereich beschränkt sich auf die Systeme, in die ihr System integriert ist. Wenn ein Team und sein Dienst A fast keine Verbindung zu Dienst B haben, dann ist ein solcher Dienst für das Team nahezu unsichtbar.

Unser Team wiederum arbeitet mit Systemen, die sehr stark miteinander integriert sind: Es gibt viele Verbindungen zwischen ihnen, das ist eine sehr große Infrastruktur. Und der Betrieb des Online-Shops hängt von all diesen Systemen ab (von denen wir übrigens eine große Anzahl haben).

Es stellt sich also heraus, dass unsere Abteilung keinem Team angehört, sondern etwas abseits angesiedelt ist. In dieser ganzen Geschichte besteht unsere Aufgabe darin, umfassend zu verstehen, wie Informationssysteme funktionieren, ihre Funktionalität, Integrationen, Software, Netzwerk, Hardware und wie all dies miteinander verbunden ist.

Die Plattform, auf der unsere Online-Shops betrieben werden, sieht folgendermaßen aus:

• Materials des
• Mittelbüro
• Back-Office

So sehr wir es uns auch wünschen, es kommt nicht vor, dass alle Systeme reibungslos und fehlerfrei funktionieren. Der Punkt ist wiederum die Anzahl der Systeme und Integrationen – bei so etwas wie unserem sind trotz der Qualität der Tests einige Vorfälle unvermeidlich. Darüber hinaus sowohl innerhalb eines separaten Systems als auch im Hinblick auf deren Integration. Und Sie müssen den Zustand der gesamten Plattform umfassend überwachen und nicht nur einen einzelnen Teil davon.

Idealerweise sollte die plattformweite Gesundheitsüberwachung automatisiert werden. Und wir kamen zur Überwachung als unvermeidlichem Teil dieses Prozesses. Ursprünglich war es nur für den Front-Line-Teil konzipiert, während Netzwerkspezialisten, Software- und Hardware-Administratoren über eigene schichtweise Überwachungssysteme verfügten und verfügen. Alle diese Leute folgten der Überwachung nur auf ihrer eigenen Ebene, niemand hatte auch ein umfassendes Verständnis.

Wenn beispielsweise eine virtuelle Maschine abstürzt, erfährt in den meisten Fällen nur der für die Hardware und die virtuelle Maschine zuständige Administrator davon. In solchen Fällen sah das Frontline-Team zwar die Tatsache des Absturzes der Anwendung, hatte jedoch keine Daten über den Absturz der virtuellen Maschine. Und der Administrator kann wissen, wer der Kunde ist und eine ungefähre Vorstellung davon haben, was gerade auf dieser virtuellen Maschine läuft, sofern es sich um ein großes Projekt handelt. Er weiß höchstwahrscheinlich nichts von den Kleinen. In jedem Fall muss der Administrator zum Besitzer gehen und fragen, was sich auf dieser Maschine befindet, was wiederhergestellt werden muss und was geändert werden muss. Und wenn etwas wirklich Schlimmes kaputt ging, drehten sie sich im Kreis – weil niemand das System als Ganzes sah.

Letztendlich wirken sich solche unterschiedlichen Geschichten auf das gesamte Frontend, die Benutzer und unsere Kerngeschäftsfunktion – den Online-Verkauf – aus. Da wir nicht Teil eines Teams sind, sondern im Rahmen eines Online-Shops mit dem Betrieb aller E-Commerce-Anwendungen befasst sind, haben wir es uns zur Aufgabe gemacht, ein umfassendes Monitoring-System für die E-Commerce-Plattform zu erstellen.

Systemstruktur und Stack

Wir begannen damit, mehrere Überwachungsebenen für unsere Systeme zu identifizieren, innerhalb derer wir Metriken sammeln mussten. Und all dies musste kombiniert werden, was wir in der ersten Phase getan haben. In dieser Phase stellen wir nun die Metriksammlung von höchster Qualität über alle unsere Ebenen hinweg fertig, um eine Korrelation aufzubauen und zu verstehen, wie sich Systeme gegenseitig beeinflussen.

Das Fehlen einer umfassenden Überwachung in der Anfangsphase des Anwendungsstarts (da wir mit der Entwicklung begannen, als die meisten Systeme in Produktion waren) führte dazu, dass wir erhebliche technische Schulden hatten, um die Überwachung der gesamten Plattform einzurichten. Wir konnten es uns nicht leisten, uns darauf zu konzentrieren, die Überwachung für ein IS einzurichten und die Überwachung im Detail auszuarbeiten, da die übrigen Systeme für einige Zeit ohne Überwachung bleiben würden. Um dieses Problem zu lösen, haben wir eine Liste der wichtigsten Metriken zur Bewertung des Zustands des Informationssystems nach Schichten erstellt und mit deren Implementierung begonnen.

Deshalb beschlossen sie, den Elefanten in Teilen zu essen.

Unser System besteht aus:

• Hardware;
• Betriebssystem;
• Software;
• UI-Teile in der Überwachungsanwendung;
• Geschäftskennzahlen;
• Integrationsanwendungen;
• Informationssicherheit;
• Netzwerke;
• Verkehrsausgleicher.

Im Zentrum dieses Systems steht die Selbstüberwachung. Um den Zustand des gesamten Systems allgemein zu verstehen, müssen Sie wissen, was mit Anwendungen auf all diesen Ebenen und über die gesamte Anwendungsmenge hinweg geschieht.

Also, zum Stapel.

Wir verwenden Open-Source-Software. Im Zentrum steht Zabbix, das wir vor allem als Alarmierungssystem nutzen. Jeder weiß, dass es ideal für die Infrastrukturüberwachung ist. Was bedeutet das? Genau diese Low-Level-Metriken, die jedes Unternehmen hat, das sein eigenes Rechenzentrum unterhält (und Sportmaster hat seine eigenen Rechenzentren) – Servertemperatur, Speicherstatus, Raid, Netzwerkgerätemetriken.

Wir haben Zabbix mit dem Telegram-Messenger und Microsoft Teams integriert, die aktiv in Teams genutzt werden. Zabbix deckt die Ebene des eigentlichen Netzwerks, der Hardware und einiger Software ab, ist aber kein Allheilmittel. Wir reichern diese Daten aus einigen anderen Diensten an. Auf Hardwareebene verbinden wir uns beispielsweise direkt per API mit unserem Virtualisierungssystem und sammeln Daten.

Was sonst. Zusätzlich zu Zabbix verwenden wir Prometheus, mit dem wir Metriken in einer dynamischen Umgebungsanwendung überwachen können. Das heißt, wir können Anwendungsmetriken über einen HTTP-Endpunkt empfangen und müssen uns keine Gedanken darüber machen, welche Metriken wir dort laden und welche nicht. Auf Basis dieser Daten können analytische Abfragen entwickelt werden.

Datenquellen für andere Ebenen, beispielsweise Geschäftsmetriken, sind in drei Komponenten unterteilt.

Erstens sind dies externe Geschäftssysteme, Google Analytics, wir sammeln Metriken aus Protokollen. Von ihnen erhalten wir Daten zu aktiven Nutzern, Conversions und allem anderen, was mit dem Geschäft zu tun hat. Zweitens handelt es sich um ein UI-Überwachungssystem. Es sollte genauer beschrieben werden.

Es war einmal, als wir mit manuellen Tests begannen und daraus automatische Tests von Funktionalität und Integrationen wurden. Daraus haben wir eine Überwachung gemacht, bei der wir nur die Hauptfunktionalität belassen haben, und uns auf Markierungen verlassen, die möglichst stabil sind und sich im Laufe der Zeit nicht oft ändern.

Die neue Teamstruktur bedeutet, dass alle Anwendungsaktivitäten auf Produktteams beschränkt sind, sodass wir keine reinen Tests mehr durchführen. Stattdessen haben wir eine UI-Überwachung anhand der in Java, Selenium und Jenkins geschriebenen Tests durchgeführt (die als System zum Starten und Generieren von Berichten verwendet werden).

Wir hatten viele Tests, aber am Ende entschieden wir uns für die Hauptstraße, die Metrik auf oberster Ebene. Und wenn wir viele spezifische Tests haben, wird es schwierig, die Daten aktuell zu halten. Jede weitere Veröffentlichung wird das gesamte System erheblich beschädigen, und wir werden es nur reparieren. Deshalb haben wir uns auf sehr grundlegende Dinge konzentriert, die sich selten ändern, und wir überwachen sie nur.

Drittens schließlich ist die Datenquelle ein zentralisiertes Protokollierungssystem. Wir verwenden Elastic Stack für Protokolle und können diese Daten dann in unser Überwachungssystem für Geschäftsmetriken übernehmen. Darüber hinaus verfügen wir über unseren eigenen, in Python geschriebenen Monitoring-API-Dienst, der beliebige Dienste über die API abfragt und Daten von ihnen in Zabbix sammelt.

Ein weiteres unverzichtbares Merkmal der Überwachung ist die Visualisierung. Unseres basiert auf Grafana. Es zeichnet sich von anderen Visualisierungssystemen dadurch aus, dass es Ihnen ermöglicht, Metriken aus verschiedenen Datenquellen auf dem Dashboard zu visualisieren. Wir können Metriken der obersten Ebene für einen Online-Shop erfassen, zum Beispiel die Anzahl der in der letzten Stunde vom DBMS aufgegebenen Bestellungen, Leistungsmetriken für das Betriebssystem, auf dem dieser Online-Shop von Zabbix ausgeführt wird, und Metriken für Instanzen dieser Anwendung von Prometheus. Und das alles auf einem Dashboard. Übersichtlich und zugänglich.

Lassen Sie mich noch etwas zur Sicherheit anmerken: Wir stellen derzeit das System fertig, das wir später in das globale Überwachungssystem integrieren werden. Meiner Meinung nach hängen die Hauptprobleme des E-Commerce im Bereich der Informationssicherheit mit Bots, Parsern und Brute Force zusammen. Wir müssen dies im Auge behalten, denn all dies kann sowohl den Betrieb unserer Anwendungen als auch unseren Ruf aus geschäftlicher Sicht entscheidend beeinträchtigen. Und mit dem gewählten Stack decken wir diese Aufgaben erfolgreich ab.

Ein weiterer wichtiger Punkt ist, dass die Anwendungsschicht von Prometheus zusammengestellt wird. Auch er selbst ist bei Zabbix integriert. Und wir haben auch Sitespeed, einen Dienst, der es uns ermöglicht, Parameter wie die Ladegeschwindigkeit unserer Seite, Engpässe, Seitenrendering, Ladeskripte usw. anzuzeigen, er ist auch API-integriert. Daher werden unsere Kennzahlen in Zabbix erfasst und dementsprechend alarmieren wir auch von dort aus. Alle Benachrichtigungen werden derzeit an die Hauptversandmethoden gesendet (derzeit sind es E-Mail und Telegramm, seit kurzem ist auch MS Teams angebunden). Es ist geplant, die Alarmierung so weit zu verbessern, dass Smart Bots als Dienst arbeiten und allen interessierten Produktteams Überwachungsinformationen bereitstellen.

Für uns sind Metriken nicht nur für einzelne Informationssysteme wichtig, sondern auch allgemeine Metriken für die gesamte Infrastruktur, die Anwendungen nutzen: Cluster physischer Server, auf denen virtuelle Maschinen laufen, Traffic Balancer, Network Load Balancer, das Netzwerk selbst, Nutzung von Kommunikationskanälen . Plus Metriken für unsere eigenen Rechenzentren (wir haben mehrere davon und die Infrastruktur ist ziemlich groß).

Die Vorteile unseres Überwachungssystems bestehen darin, dass wir mit seiner Hilfe den Gesundheitszustand aller Systeme sehen und deren Auswirkungen aufeinander und auf gemeinsame Ressourcen beurteilen können. Und letztlich ermöglicht es uns die Ressourcenplanung, die auch in unserer Verantwortung liegt. Wir verwalten Serverressourcen – einen Pool innerhalb des E-Commerce, nehmen neue Geräte in Betrieb und außer Betrieb, kaufen zusätzliche neue Geräte, führen eine Prüfung der Ressourcennutzung durch usw. Jedes Jahr planen Teams neue Projekte, entwickeln ihre Systeme und es ist uns wichtig, ihnen Ressourcen zur Verfügung zu stellen.

Mithilfe von Kennzahlen erkennen wir die Entwicklung des Ressourcenverbrauchs unserer Informationssysteme. Und auf dieser Grundlage können wir etwas planen. Auf der Virtualisierungsebene sammeln wir Daten und sehen Informationen über die verfügbare Menge an Ressourcen pro Rechenzentrum. Und bereits im Rechenzentrum können Sie das Recycling, die tatsächliche Verteilung und den Verbrauch der Ressourcen beobachten. Darüber hinaus sowohl mit eigenständigen Servern und virtuellen Maschinen als auch mit Clustern physischer Server, auf denen alle diese virtuellen Maschinen kräftig laufen.

Chancen

Jetzt haben wir den Kern des Gesamtsystems fertig, aber es gibt noch viele Dinge, an denen noch gearbeitet werden muss. Zumindest handelt es sich dabei um eine Informationssicherheitsebene, aber es ist auch wichtig, das Netzwerk zu erreichen, Alarme zu entwickeln und das Problem der Korrelation zu lösen. Wir haben viele Schichten und Systeme und auf jeder Schicht gibt es viele weitere Metriken. Es stellt sich heraus, dass es sich um eine Matroschka im Grad einer Matroschka handelt.

Unsere Aufgabe ist es, letztendlich die richtigen Alarme zu setzen. Wenn es beispielsweise ein Problem mit der Hardware oder einer virtuellen Maschine gab und eine wichtige Anwendung vorhanden war und der Dienst in keiner Weise gesichert wurde. Wir stellen fest, dass die virtuelle Maschine gestorben ist. Dann werden Sie von den Geschäftskennzahlen alarmiert: Benutzer sind irgendwo verschwunden, es findet keine Konvertierung statt, die Benutzeroberfläche in der Benutzeroberfläche ist nicht verfügbar, Software und Dienste sind ebenfalls gestorben.

In dieser Situation erhalten wir Spam-Mails, die nicht mehr in das Format eines ordnungsgemäßen Überwachungssystems passen. Es stellt sich die Frage der Korrelation. Daher sollte unser Überwachungssystem im Idealfall mit Hilfe einer einzigen Warnung sagen: „Leute, eure physische Maschine ist ausgefallen, und damit auch diese Anwendung und diese Metriken“, anstatt uns wütend mit hundert Warnungen zu bombardieren. Es sollte die Hauptsache melden – die Ursache, die aufgrund ihrer Lokalisierung hilft, das Problem schnell zu beheben.

Unser Benachrichtigungssystem und die Alarmbearbeitung basieren auf einem XNUMX-Stunden-Hotline-Service. Alle Alarme, die als „Must-Have“ gelten und in der Checkliste enthalten sind, werden dorthin gesendet. Jede Warnung muss eine Beschreibung haben: Was ist passiert, was es eigentlich bedeutet, welche Auswirkungen es hat. Und auch ein Link zum Dashboard und Anweisungen, was in diesem Fall zu tun ist.

Hier geht es um die Voraussetzungen für die Erstellung einer Warnung. Dann kann sich die Situation in zwei Richtungen entwickeln: Entweder liegt ein Problem vor, das gelöst werden muss, oder es liegt ein Fehler im Überwachungssystem vor. Aber auf jeden Fall müssen Sie hingehen und es herausfinden.

Im Durchschnitt erhalten wir mittlerweile etwa hundert Benachrichtigungen pro Tag, wenn man berücksichtigt, dass die Korrelation der Benachrichtigungen noch nicht richtig konfiguriert ist. Und wenn wir technische Arbeiten durchführen müssen und etwas gewaltsam ausschalten, erhöht sich ihre Zahl deutlich.

Neben der Überwachung der von uns betriebenen Systeme und der Erfassung von Kennzahlen, die auf unserer Seite als wichtig erachtet werden, ermöglicht uns das Überwachungssystem auch die Erfassung von Daten für Produktteams. Sie können die Zusammensetzung der Kennzahlen innerhalb der von uns überwachten Informationssysteme beeinflussen.

Möglicherweise kommt unser Kollege und bittet darum, eine Kennzahl hinzuzufügen, die sowohl für uns als auch für das Team nützlich ist. Oder das Team verfügt möglicherweise nicht über genügend grundlegende Kennzahlen, die wir haben; es muss einige spezifische Kennzahlen verfolgen. In Grafana erstellen wir für jedes Team einen Bereich und gewähren Administratorrechte. Auch wenn ein Team Dashboards benötigt, es aber selbst nicht weiß/kann, wie es geht, helfen wir ihm.

Da wir außerhalb des Flusses der Wertschöpfung des Teams, seiner Releases und Planung stehen, kommen wir nach und nach zu dem Schluss, dass Releases aller Systeme nahtlos ablaufen und täglich ohne Abstimmung mit uns ausgerollt werden können. Und es ist für uns wichtig, diese Veröffentlichungen zu überwachen, da sie möglicherweise den Betrieb der Anwendung beeinträchtigen und etwas kaputt machen könnten, und das ist von entscheidender Bedeutung. Zur Verwaltung von Releases nutzen wir Bamboo, von wo wir per API Daten erhalten und sehen können, welche Releases in welchen Informationssystemen veröffentlicht wurden und deren Status. Und das Wichtigste ist, zu welcher Zeit. Wir überlagern die wichtigsten kritischen Kennzahlen mit Release-Markern, was bei Problemen optisch sehr aussagekräftig ist.

Auf diese Weise können wir den Zusammenhang zwischen Neuerscheinungen und aufkommenden Problemen erkennen. Die Hauptidee besteht darin, die Funktionsweise des Systems auf allen Ebenen zu verstehen, das Problem schnell zu lokalisieren und es ebenso schnell zu beheben. Schließlich kommt es häufig vor, dass nicht die Lösung des Problems, sondern die Suche nach der Ursache die meiste Zeit in Anspruch nimmt.

Und in diesem Bereich wollen wir künftig den Fokus auf Proaktivität legen. Idealerweise möchte ich über ein bevorstehendes Problem im Voraus Bescheid wissen und nicht erst im Nachhinein, damit ich es verhindern und nicht lösen kann. Manchmal kommt es zu Fehlalarmen des Überwachungssystems, sowohl aufgrund menschlicher Fehler als auch aufgrund von Änderungen in der Anwendung. Und wir arbeiten daran, debuggen es und versuchen, Benutzer, die es bei uns verwenden, vor jeder Manipulation des Überwachungssystems darüber zu warnen , oder führen Sie diese Aktivitäten im technischen Fenster durch.

Das System wurde also eingeführt und arbeitet seit Frühlingsbeginn erfolgreich ... und weist sehr reale Gewinne auf. Natürlich ist dies nicht die endgültige Version; wir werden noch viele weitere nützliche Funktionen einführen. Aber gerade jetzt, bei so vielen Integrationen und Anwendungen, ist eine Überwachungsautomatisierung wirklich unumgänglich.

Wenn Sie auch große Projekte mit einer nennenswerten Anzahl an Integrationen überwachen, schreiben Sie in die Kommentare, welchen Königsweg Sie hierfür gefunden haben.

Source: habr.com