Monitoring von Sportmaster — wie und womit

Bei der Entwicklung unseres Überwachungssystems dachten wir bereits in der Phase der Bildung der Produktteams darüber nach. Es wurde klar, dass unser Bereich - die Betriebsführung - in diese Teams nicht integriert ist. Warum ist das so?

Das liegt daran, dass unsere Teams um separate Informationssysteme, Mikrodienste und Frontends aufgebaut sind, weshalb sie den allgemeinen Gesundheitszustand des gesamten Systems nicht sehen. Zum Beispiel könnten sie nicht wissen, wie ein kleiner Teil im tiefen Backend die Frontend-Teile beeinflusst. Ihr Interessensbereich beschränkt sich auf die Systeme, mit denen ihr System integriert ist. Wenn Team A und dessen Dienst kaum mit Dienst B verbunden sind, ist dieser Dienst für das Team praktisch unsichtbar.

Unser Team hingegen arbeitet mit Systemen, die stark miteinander integriert sind: Es gibt zahlreiche Verbindungen zwischen ihnen, und sie bilden eine relativ große Infrastruktur. Und die Funktionsweise des Onlineshops hängt von all diesen Systemen ab (von denen wir übrigens eine enorme Anzahl haben).

Es stellt sich heraus, dass unser Team keiner bestimmten Gruppe zugeordnet ist, sondern ein wenig im Hintergrund arbeitet. In dieser gesamten Situation ist es unsere Aufgabe, ein umfassendes Verständnis darüber zu entwickeln, wie Informationssysteme funktionieren, ihre Funktionalität, Integration, Software, Netzwerke und Hardware und wie all diese Elemente miteinander verbunden sind.

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

• Front
• Middleware
• Backoffice

So sehr wir uns auch wünschen, dass alles reibungslos und fehlerfrei funktioniert, gibt es das einfach nicht. Das liegt wieder an der Anzahl der Systeme und Integrationen — bei uns sind gewisse Vorfälle unvermeidlich, egal wie gut die Tests sind. Dies betrifft sowohl die einzelnen Systeme als auch deren Integration. Man muss den Zustand der gesamten Plattform ganzheitlich im Blick behalten und nicht nur einen bestimmten Teil davon.

Idealerweise sollte die Überwachung des gesamten Plattformzustands automatisiert werden. Daher haben wir Monitoring als unverzichtbaren Bestandteil dieses Prozesses betrachtet. Ursprünglich war es nur für die Frontend-Seite konzipiert, während eigene Monitoring-Systeme in den verschiedenen Schichten sowohl von Netzwerk- als auch von Software- und Hardware-Administratoren genutzt wurden. All diese Personen überwachten das System nur auf ihrer Ebene, ein umfassendes Verständnis gab es jedoch bei niemandem.

Wenn beispielsweise eine virtuelle Maschine ausfällt, weiß in den meisten Fällen nur der Administrator, der für die Hardware und die virtuelle Maschine zuständig ist, davon. Das Frontend-Team erkennt in solchen Situationen lediglich, dass die Anwendung abgestürzt ist, hat jedoch keine Informationen über den Ausfall der virtuellen Maschine. Der Administrator könnte wissen, wer der Kunde ist und ungefähr verstehen, was derzeit auf dieser virtuellen Maschine läuft, vorausgesetzt, es handelt sich um ein größeres Projekt. Bei kleineren Projekten hat er wahrscheinlich keine Ahnung. In jedem Fall muss der Administrator zum Besitzer gehen und fragen, welche Anwendungen auf dieser Maschine liefen, was wiederhergestellt und was geändert werden muss. Wenn etwas Schwerwiegendes defekt ist, beginnt ein Kreislauf, weil niemand die gesamte Systemarchitektur gesehen hat.

Letztendlich wirken sich solche isolierten Vorfälle auf das gesamte Frontend, die Benutzer und unsere Hauptgeschäftsfunktion — den Online-Verkauf — aus. Da wir nicht Teil der Teams sind und uns um den Betrieb aller E-Commerce-Anwendungen im Rahmen des Online-Shops kümmern, haben wir uns die Aufgabe gestellt, ein umfassendes Überwachungssystem für die E-Commerce-Plattform zu schaffen.

Aufbau und Technologie-Stack

Wir begannen mit der Definition mehrerer Überwachungsebenen für unsere Systeme, in denen wir Metriken sammeln mussten. Und all das musste zusammengeführt werden, was wir in der ersten Phase getan haben. Jetzt verfeinern wir in dieser Phase die qualitativ hochwertigste Sammlung von Metriken über all unsere Schichten, um Korrelationsanalysen durchzuführen und zu verstehen, wie die Systeme sich gegenseitig beeinflussen.

Das Fehlen einer umfassenden Überwachung in den Anfangsphasen des Anwendungsstarts (da wir erst mit dem Aufbau begannen, als der Großteil der Systeme bereits in Betrieb war) führte dazu, dass wir einen erheblichen technischen Schuldenstand für die Konfiguration der Überwachung der gesamten Plattform angesammelt haben. Es war uns nicht möglich, uns auf die Überwachung eines bestimmten Informationssystems zu konzentrieren und diese im Detail zu bearbeiten, da die anderen Systeme eine Zeit lang ohne Überwachung bleiben würden. Um dieses Problem zu lösen, haben wir eine Liste der dringend benötigten Metriken zur Bewertung des Zustands der Informationssysteme in den Schichten erstellt und mit deren Implementierung begonnen.

Deshalb haben wir uns entschieden, den Elefanten in Teilen zu essen.

Unser System besteht aus:

• Hardware;
• Betriebssystem;
• Software;
• UI-Komponenten in der Monitoring-Anwendung;
• Unternehmenskennzahlen;
• Integrationsanwendungen;
• Informationssicherheit;
• Netzwerke;
• Lastenausgleich.

Im Mittelpunkt dieses Systems steht die Überwachung selbst. Um den Zustand des gesamten Systems insgesamt zu verstehen, muss man wissen, was mit den Anwendungen auf all diesen Ebenen und im Kontext der Vielzahl an Anwendungen passiert.

Und jetzt zum Stack.

Wir verwenden Software mit offenem Quellcode. Im Zentrum steht Zabbix, das wir in erster Linie als Alarmsystem nutzen. Es ist allgemein bekannt, dass es sich hervorragend für die Überwachung von Infrastrukturen eignet. Was bedeutet das genau? Es bezieht sich auf die wichtigen Metriken, die jedes Unternehmen mit eigenem Rechenzentrum hat (und Sportmaster hat eigene Rechenzentren) – Servertemperatur, Speicherzustand, RAID-Zustand, Metriken von Netzwerkgeräten.

Wir haben Zabbix mit den in Teams weit verbreiteten Messaging-Diensten Telegram und Microsoft Teams integriert. Zabbix deckt die Ebene des tatsächlichen Netzwerks, der Hardware und teilweise der Software ab, ist jedoch kein Allheilmittel. Diese Daten bereichern wir aus verschiedenen anderen Diensten. Zum Beispiel verbinden wir uns über die API direkt mit unserem Virtualisierungssystem und holen Daten zum Hardware-Level ab.

Zusätzlich zu Zabbix nutzen wir Prometheus, das es uns ermöglicht, Metriken in dynamischen Anwendungsumgebungen zu überwachen. Das bedeutet, dass wir Metriken über HTTP-Endpunkte abrufen können, ohne uns Gedanken darüber machen zu müssen, welche Metriken geladen werden sollen und welche nicht. Basierend auf diesen Daten können wir analytische Abfragen entwickeln.

Die Datenquellen für die anderen Schichten, wie zum Beispiel Geschäftsmetriken, lassen sich in drei Komponenten unterteilen.

Erstens sind das externe Geschäftssysteme, Google Analytics, aus denen wir Metriken aus Log-Dateien sammeln. Daraus erhalten wir Daten zu aktiven Nutzern, Konversionen und allem anderen, was mit dem Geschäft verbunden ist. Zweitens gibt es das UI-Monitoring-System, über das wir ausführlicher berichten sollten.

Früher begannen wir mit manuellen Tests, die sich zu automatisierten Funktionstests und Integrationen weiterentwickelten. Daraus entstand unser Monitoring, bei dem wir uns auf die Kernfunktionalitäten konzentrierten und uns auf Marker stützten, die möglichst stabil sind und im Laufe der Zeit nur selten geändert werden.

Die neue Teamstruktur sieht vor, dass alle Aktivitäten im Bereich Anwendungen in den Produktteams konzentriert sind, weshalb wir uns nicht mehr ausschließlich mit dem Testen beschäftigen. Stattdessen haben wir die Tests in ein UI-Monitoring umgewandelt, das mit Java, Selenium und Jenkins (verwendet als Ausführungssystem und für die Berichtserstellung) erstellt wurde.

Wir hatten viele Tests, aber letztendlich beschlossen wir, den Fokus auf die Hauptmetriken, die übergeordneten Kennzahlen, zu legen. Wenn wir zu viele spezifische Tests haben, wird es schwierig sein, die Daten aktuell zu halten. Jeder nachfolgende Release würde das gesamte System erheblich stören, und wir würden nur mit dessen Reparatur beschäftigt sein. Daher konzentrieren wir uns auf grundlegende Aspekte, die sich nur selten ändern, und überwachen ausschließlich diese.

Zu guter Letzt stellt das zentrale Logging-System die Datenquelle dar. Für die Protokolle verwenden wir den Elastic Stack, und dann können wir diese Daten in unser Monitoring-System für Geschäftsmetriken integrieren. Darüber hinaus verfügen wir über unseren eigenen Monitoring-API-Dienst, der in Python geschrieben ist, der über die API beliebige Dienste abfragt und Daten in Zabbix importiert.

Ein weiterer unverzichtbarer Bestandteil des Monitorings ist die Visualisierung. Diese basiert bei uns auf Grafana. Im Gegensatz zu anderen Visualisierungssystemen zeichnet es sich dadurch aus, dass auf dem Dashboard Metriken aus verschiedenen Datenquellen visualisiert werden können. Wir können beispielsweise Oberflächenmetriken eines Online-Shops wie die Anzahl der in der letzten Stunde abgeschlossenen Bestellungen aus der Datenbank, Leistungsmetriken des Betriebssystems, auf dem dieser Online-Shop läuft, aus Zabbix und Metriken der Instanzen dieser Anwendung aus Prometheus zusammenstellen. Und all dies wird auf einem einzigen Dashboard angezeigt. Anschaulich und zugänglich.

Ich möchte auf die Sicherheit hinweisen – wir arbeiten derzeit an einem System, das wir später in unser globales Überwachungssystem integrieren werden. Meiner Meinung nach stehen die Hauptprobleme, mit denen der E-Commerce im Bereich der Informationssicherheit konfrontiert ist, im Zusammenhang mit Bots, Scraping und Brute-Force-Angriffen. Diese Aspekte müssen überwacht werden, da sie sowohl die Funktionalität unserer Anwendungen als auch die Unternehmensreputation erheblich beeinflussen können. Mit dem gewählten Stack decken wir diese Anforderungen erfolgreich ab.

Ein weiterer wichtiger Punkt ist, dass die Anwendungslevel von Prometheus erfasst werden. Dieser ist auch in unser System integriert, zusammen mit Zabbix. Zusätzlich nutzen wir sitespeed, einen Service, der es uns ermöglicht, Parameter wie die Ladegeschwindigkeit unserer Seite, Bottlenecks, die Seitenrendering-Zeit, das Laden von Skripten und mehr zu überwachen. Auch dieser Service ist über die API integriert. Somit werden unsere Metriken in Zabbix erfasst und wir erhalten auch unsere Alarme von dort. Derzeit werden alle Alarme über die Hauptkommunikationskanäle gesendet (aktuell E-Mail und Telegram; kürzlich haben wir auch MS Teams angeschlossen). Wir planen, das Alert-System so weiterzuentwickeln, dass intelligente Bots als Service arbeiten und den Produktteams Informationen zu Monitoring zur Verfügung stellen.

Für uns sind Metriken nicht nur von einzelnen Informationssystemen wichtig, sondern auch die allgemeinen Metriken der gesamten Infrastruktur, die von den Anwendungen genutzt wird: Cluster physikalischen Servern, in denen die virtuellen Maschinen laufen, Lastenverteilung, Network Load Balancer, das Netzwerk selbst und die Auslastung der Kommunikationskanäle. Zudem erheben wir Metriken aus unseren eigenen Rechenzentren (wir betreiben mehrere und die Infrastruktur hat beträchtliche Größen).

Die Vorteile unseres Monitoringsystems liegen darin, dass wir damit den Zustand aller Systeme überwachen können. Dies ermöglicht uns, die Auswirkungen der Systeme aufeinander und auf die gemeinsamen Ressourcen zu bewerten. Letztlich hilft es uns auch bei der Planung von Ressourcen, was ebenfalls in unseren Zuständigkeitsbereich fällt. Wir verwalten Serverressourcen – einen Pool im Bereich E-Commerce. Dazu gehört das Ein- und Ausmustern neuer Hardware, der Kauf zusätzlicher Komponenten sowie die Durchführung von Audits zur Ressourcennutzung und mehr. Jedes Jahr planen die Teams neue Projekte und entwickeln ihre Systeme weiter, und es ist wichtig, dass wir sie mit den notwendigen Ressourcen unterstützen.

Mit Hilfe von Metriken können wir die Tendenzen im Ressourcenverbrauch unserer Informationssysteme erkennen. Auf dieser Grundlage sind wir in der Lage, Planung zu betreiben. Auf der Virtualisierungsebene sammeln wir Daten und erhalten Informationen über die verfügbaren Ressourcen nach Rechenzentren. Innerhalb des Rechenzentrums sehen wir sowohl die Nutzung als auch die tatsächliche Verteilung und den Verbrauch der Ressourcen. Dies gilt sowohl für stand-alone Server als auch für virtuelle Maschinen und Cluster physischer Server, auf denen all diese virtuellen Systeme effizient laufen.

Perspektiven

Aktuell haben wir die Systemarchitektur insgesamt vorbereitet, es gibt jedoch noch viele Aspekte, an denen wir arbeiten müssen. Zumindest benötigen wir eine Schicht für Informationssicherheit, aber es ist auch wichtig, das Netzwerk zu erreichen, ein Alarmsystem auszubauen und die Korrelation zu klären. Wir haben viele Schichten und Systeme, und auf jeder Schicht gibt es zahlreiche Metriken. Es ergibt sich eine Matroschka in der Matroschka.

Unsere Aufgabe ist es letztendlich, die richtigen Alarme zu erstellen. Zum Beispiel, wenn es ein Problem mit der Hardware gibt, wiederum mit der virtuellen Maschine, auf der eine wichtige Anwendung lief, und der Service nicht irgendwie reserviert war. Wir erfahren, dass die virtuelle Maschine ausgefallen ist. Dann müssen die geschäftlichen Metriken alarmiert werden: Die Benutzer sind verschwunden, es gibt keine Konversion, die Benutzeroberfläche ist nicht verfügbar, Software und Dienste sind ebenfalls ausgefallen.

In diesem Fall erhalten wir Spam aus Alarmen, was nicht dem Format eines effektiven Monitoring-Systems entspricht. Es stellt sich die Frage nach der Korrelation. Ideal wäre es, wenn unser Monitoring-System sagen könnte: „Leute, eure physische Maschine ist ausgefallen, und damit auch diese Anwendung und diese Metriken“, und zwar mit nur einem Alarm, anstatt uns mit einer Flut von Hunderten von Alarmen zu überhäufen. Es sollte das Wesentliche berichten – den Grund, um die schnelle Behebung des Problems durch Lokalisierung zu unterstützen.

Unser Benachrichtigungssystem und die Alarmbearbeitung sind rund um einen 24/7-Notdienst aufgebaut. Alle Alarme, die für uns unerlässlich sind und in die Checkliste aufgenommen wurden, werden dorthin weitergeleitet. Jeder Alarm muss unbedingt eine Beschreibung haben: Was ist passiert? Was bedeutet das eigentlich? Auf was hat es Auswirkungen? Außerdem sollte es einen Link zum Dashboard und eine Anleitung geben, was in diesem Fall zu tun ist.

Das sind alle Anforderungen an die Alarmierung. Die Situation kann sich dann in zwei Richtungen entwickeln – entweder gibt es ein Problem, das gelöst werden muss, oder es ist ein Fehler im Monitoring-System aufgetreten. In jedem Fall ist es notwendig, die Situation zu prüfen und zu klären.

Im Durchschnitt erhalten wir jetzt täglich etwa hundert Alarme, wobei zu beachten ist, dass die Korrelation der Alarme noch nicht richtig eingestellt ist. Wenn technische Arbeiten erforderlich sind und wir etwas absichtlich deaktivieren, steigt deren Anzahl erheblich.

Neben der Überwachung der von uns betriebenen Systeme und der Erfassung von Metriken, die für uns als wichtig erachtet werden, ermöglicht das Überwachungssystem, Daten für die Produktteams zu sammeln. Diese können Einfluss auf die Metrikgestaltung innerhalb der Informationssysteme nehmen, die von uns überwacht werden.

Unser Kollege kann kommen und um die Hinzufügung einer Metrik bitten, die für uns und das Team nützlich sein könnte. Oder das Team benötigt möglicherweise mehr als die grundlegenden Metriken, die wir haben; sie müssen eine spezifische verfolgen. In Grafana erstellen wir für jedes Team einen Raum und gewähren Admin-Rechte. Außerdem unterstützen wir das Team, wenn sie Dashboards benötigen, aber selbst nicht in der Lage sind oder nicht wissen, wie man das macht.

Da wir nicht im Fluss der Wertschöpfung des Teams, ihrer Releases und der Planung involviert sind, nähern wir uns allmählich dem Punkt, an dem die Releases aller Systeme nahtlos sind und täglich bereitgestellt werden können, ohne dass dies mit uns abgestimmt werden muss. Es ist jedoch wichtig für uns, diese Releases zu verfolgen, da sie potenziell die Funktionalität der Anwendung beeinträchtigen und etwas kaputtmachen könnten, was kritisch ist. Für das Management der Releases nutzen wir Bamboo, von wo wir über die API Daten erhalten und sehen können, welche Releases in welchen Informationssystemen veröffentlicht wurden und welchen Status sie haben. Das Wichtigste dabei ist der Zeitpunkt der Releases. Wir legen Marker für die Releases über die wesentlichen kritischen Metriken, was visuell sehr aufschlussreich ist, wenn Probleme auftreten.

Auf diese Weise können wir die Korrelation zwischen neuen Releases und aufkommenden Problemen erkennen. Die Hauptidee ist, zu verstehen, wie das System auf allen Ebenen funktioniert, Probleme schnell zu lokalisieren und ebenso schnell zu beheben. Oftmals ist es nämlich so, dass nicht die Lösung des Problems am meisten Zeit in Anspruch nimmt, sondern die Suche nach der Ursache.

In Zukunft möchten wir uns in diesem Bereich auf Proaktivität konzentrieren. Idealerweise möchten wir bereits im Voraus über anstehende Probleme informiert werden, anstatt nachträglich darauf reagieren zu müssen, um präventiv eingreifen zu können. Manchmal gibt es Fehlalarme im Überwachungssystem, sowohl aufgrund menschlicher Fehler als auch durch Änderungen in der Anwendung. Wir arbeiten daran, optimieren das System und versuchen, vor jeglichen Änderungen die Benutzer, die es gemeinsam mit uns nutzen, darüber zu informieren oder diese Maßnahmen in einem Wartungsfenster durchzuführen.

Das System ist seit Anfang des Frühlings aktiv und funktioniert erfolgreich ... und zeigt durchaus realistische Gewinne. Natürlich ist dies nicht die endgültige Version; wir werden viele nützliche Funktionen integrieren. Doch momentan, bei einer so großen Zahl an Integrationen und Anwendungen, ist eine automatisierte Überwachung wirklich unerlässlich.

Wenn Sie ebenfalls große Projekte mit einer erheblichen Anzahl an Integrationen überwachen — teilen Sie uns in den Kommentaren mit, welche ‚silberne Kugel‘ Sie dafür gefunden haben.

Quelle: habr.com