Wir beobachten Sportmaster – wie und womit

Bei der Schaffung eines Überwachungssystems haben wir uns bereits in der Phase der Bildung von Produktteams Gedanken gemacht. Es wurde klar, dass unser Bereich — die Betriebsführung — in diese Teams nicht integriert ist. Warum ist das so?

Der Grund ist, dass alle unsere Teams um separate Informationssysteme, Mikrodienste und Frontends gebaut sind, weshalb sie den allgemeinen Gesundheitszustand des Gesamtsystems nicht sehen. Zum Beispiel könnten sie nicht wissen, wie ein kleiner Teil im tiefen Backend das Frontend beeinflusst. Ihr Interessenbereich ist auf die Systeme beschränkt, mit denen ihr System integriert ist. Wenn Team A und sein Service kaum mit Service B verbunden sind, dann ist dieser Service für das Team fast unsichtbar.

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

So kommt es, dass unsere Abteilung zu keinem Team gehört und etwas abseits steht. In dieser ganzen Geschichte besteht unsere Aufgabe darin, komplex zu verstehen, wie Informationssysteme funktionieren, ihre Funktionalität, Integrationen, Software, Netzwerke und Hardware und wie all dies miteinander verbunden ist.

Die Plattform, auf der unsere Onlineshops betrieben werden, sieht so aus:

• front
• middle-office
• back-office

So sehr wir es uns wünschen, es gibt keinen Zustand, in dem alle Systeme reibungslos und fehlerfrei funktionieren. Der Grund liegt erneut in der Anzahl der Systeme und Integrationen — in unserem Fall sind bestimmte Vorfälle unvermeidlich, trotz der Qualität der Tests. Sowohl innerhalb eines bestimmten Systems als auch in Bezug auf ihre Integration. Es ist notwendig, den Zustand der gesamten Plattform umfassend zu überwachen und nicht nur einen bestimmten Teil davon.

Idealerweise sollte die Überwachung des Gesundheitszustands der gesamten Plattform automatisiert werden. Und wir sind zum Monitoring als einem unvermeidlichen Teil dieses Prozesses gekommen. Ursprünglich wurde es nur für den Frontend-Bereich eingerichtet, während die Netzwerkadministratoren, Software- und Hardware-Administratoren eigene Monitoring-Systeme nach Schichten hatten und haben. All diese Personen überwachten das Monitoring nur auf ihrem Niveau, ein umfassendes Verständnis hatte ebenfalls niemand.

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 Front-Team hat in solchen Fällen lediglich den Fakt des Anwendungsabsturzes gesehen, aber keine Daten über den Ausfall der virtuellen Maschine. Der Administrator könnte wissen, wer der Auftraggeber ist und eine ungefähre Vorstellung davon haben, was zurzeit auf dieser virtuellen Maschine läuft, vorausgesetzt, es handelt sich um ein größeres Projekt. Über kleinere Projekte wird er wahrscheinlich nichts wissen. In jedem Fall muss der Administrator zum Eigentümer gehen, um zu fragen, was auf dieser Maschine war, was wiederhergestellt werden muss und was geändert werden soll. Und wenn etwas wirklich Ernstes kaputtging, begann das Durcheinander, denn niemand sah das System als Ganzes.

Letztendlich beeinflussen solche verstreuten Geschichten das gesamte Frontend, die Nutzer und unsere zentrale Geschäfts- funktion – den Online-Verkauf. Da wir nicht in Teams arbeiten, sondern die gesamte Infrastruktur der E-Commerce-Anwendungen im Rahmen des Online-Shops betreuen, haben wir uns die Aufgabe gestellt, ein umfassendes Monitoring-System für unsere E-Commerce-Plattform zu schaffen.

Die Struktur des Systems und der Stack

Wir haben damit begonnen, mehrere Monitoring-Schichten für unsere Systeme zu definieren, innerhalb derer wir Metriken sammeln müssen. All dies musste zusammengeführt werden, was wir auch in der ersten Phase getan haben. Jetzt optimieren wir in dieser Phase die qualitativ hochwertigste Sammlung von Metriken für all unsere Schichten, um Korrelationen zu erstellen und zu verstehen, wie die Systeme sich gegenseitig beeinflussen.

Das Fehlen eines umfassenden Monitorings in den frühen Phasen des Anwendungsstarts (da wir damit begonnen haben, als der Großteil der Systeme bereits im Einsatz war) hat dazu geführt, dass wir einen erheblichen technischen Schuldenstand bei der Einrichtung des Monitorings der gesamten Plattform aufgebaut haben. Wir konnten es uns nicht leisten, uns auf die Einrichtung des Monitorings eines bestimmten Informationssystems zu konzentrieren und dies im Detail für dieses umzusetzen, da die anderen Systeme für eine gewisse Zeit ohne Monitoring geblieben wären. Um dieses Problem zu lösen, haben wir eine Liste der notwendigsten Metriken zur Bewertung des Zustands des Informationssystems nach Schichten erstellt und mit deren Implementierung begonnen.

Deshalb haben wir beschlossen, den Elefanten in Stücke zu essen.

Unser System besteht aus:

• Hardware;
• Betriebssystem;
• Software;
• UI-Elemente in der Monitoring-Anwendung;
• Geschäftsmetriken;
• Integrationsanwendungen;
• Informationssicherheit;
• Netzwerke;
• Lastenausgleich.

Im Zentrum dieses Systems steht das eigentliche Monitoring. Um den Zustand des gesamten Systems insgesamt verstehen zu können, muss man wissen, was mit den Anwendungen in all diesen Schichten und über die Vielzahl der Anwendungen hinweg passiert.

Also, zum Stack.

Wir nutzen Open-Source-Software. Im Zentrum steht Zabbix, das wir in erster Linie als Alarmsystem verwenden. Es ist bekannt, dass es sich hervorragend für das Monitoring von Infrastrukturen eignet. Was ist damit gemeint? Genau die niedrigstufigen Metriken, die jede Firma hat, die ihr eigenes Rechenzentrum betreibt (und Sportmaster hat eigene Rechenzentren) — Temperatur des Servers, Zustand des Speichers, des RAID, Metriken der Netzwerkgeräte.

Wir haben Zabbix mit dem Messenger Telegram und Microsoft Teams integriert, die in den Teams aktiv genutzt werden. Zabbix deckt die Schicht des tatsächlichen Netzwerks, der Hardware und teilweise der Software ab, aber es ist kein Allheilmittel. Wir bereichern diese Daten mit Informationen aus anderen Diensten. Beispielsweise verbinden wir uns über die API in unserem Virtualisierungssystem und holen die Daten ab.

Was noch. Neben Zabbix nutzen wir Prometheus, das es ermöglicht, Metriken in der Anwendung dynamischer Umgebungen zu überwachen. Das heißt, wir können Metriken der Anwendung über HTTP-Endpunkte erhalten und müssen uns keine Gedanken darüber machen, welche Metriken wir in sie laden und welche nicht. Auf Grundlage dieser Daten können analytische Anfragen bearbeitet werden.

Die Datenquellen für die anderen Schichten, z. B. Geschäftsmetriken, teilen sich bei uns in drei Bestandteile.

Erstens sind das externe Geschäftssysteme, Google Analytics, wir erfassen Metriken aus Protokollen. Daraus erhalten wir Daten über aktive Benutzer, Konversionen und alles andere, was mit dem Geschäft zu tun hat. Zweitens ist das das UI-Monitoring-System. Darüber sollten wir detaillierter berichten.

Früher haben wir mit manuellen Tests begonnen, und die sind in automatische Tests von Funktionalitäten und Integrationen übergegangen. Daraus haben wir das Monitoring entwickelt, wobei wir nur die Hauptfunktionalität beibehalten haben und uns auf die Marker konzentriert haben, die möglichst stabil sind und sich nicht oft ändern.

Die neue Teamstruktur sieht vor, dass alle Aktivitäten in Bezug auf Anwendungen auf die Produktteams konzentriert werden, weshalb wir mit reinem Testen aufgehört haben. Stattdessen haben wir aus den Tests UI-Überwachung gemacht, die in Java, Selenium und Jenkins (verwendet als System zur Ausführung und Berichterstattung) geschrieben ist.

Wir hatten viele Tests, aber letztendlich haben wir uns entschieden, auf die Hauptstraße zu gehen, die obersten Metriken. Und wenn wir viele spezifische Tests haben, wird es schwierig sein, die Daten aktuell zu halten. Jede nachfolgende Version wird das gesamte System erheblich brechen, und wir werden nur mit dessen Reparatur beschäftigt sein. Daher haben wir uns auf ganz grundlegende Dinge konzentriert, die sich selten ändern, und überwachen nur diese.

Drittens ist die Datenquelle ein zentrales Protokollierungssystem. Für die Protokolle verwenden wir den Elastic Stack, und dann können wir diese Daten in unser Überwachungssystem für Geschäftsmetriken ziehen. Zusätzlich dazu funktioniert unser eigener Monitoring-API-Dienst, der in Python geschrieben ist, der über API beliebige Dienste abfragt und Daten in Zabbix zieht.

Ein weiteres unverzichtbares Attribut der Überwachung ist die Visualisierung. Bei uns basiert sie auf Grafana. Unter den verschiedenen Visualisierungssystemen sticht es hervor, dass auf dem Dashboard Metriken aus verschiedenen Datenquellen visualisiert werden können. Wir können oberste Metriken eines Online-Shops sammeln, zum Beispiel die Anzahl der Bestellungen, die in der letzten Stunde getätigt wurden, aus der Datenbank, Leistungsmetriken des Betriebssystems, auf dem dieser Online-Shop läuft, aus Zabbix, sowie Metriken der Instanzen dieser Anwendung aus Prometheus. Und all das wird auf einem Dashboard dargestellt. Anschaulich und zugänglich.

Ich möchte auf die Sicherheit hinweisen – wir arbeiten gerade an einem System, das wir später mit einem globalen Monitoring-System integrieren werden. Meiner Meinung nach sind die wichtigsten Probleme, mit denen der E-Commerce im Bereich der Cybersicherheit konfrontiert ist, mit Bots, Crawlern und Brute-Force-Angriffen verbunden. Das muss überwacht werden, da es sowohl die Leistung unserer Anwendungen als auch die Reputation aus geschäftlicher Sicht erheblich beeinträchtigen kann. Und mit dem gewählten Stack decken wir diese Aufgaben erfolgreich ab.

Ein weiterer wichtiger Punkt ist, dass der Anwendungslevel von Prometheus gesammelt wird. Er ist auch bei uns mit Zabbix integriert. Außerdem haben wir Sitespeed, einen Dienst, der es uns ermöglicht, Parameter wie die Ladegeschwindigkeit unserer Seite, Bottlenecks, das Rendering der Seite, das Laden von Skripten usw. zu überwachen, und der ebenfalls per API integriert ist. So werden die Metriken in Zabbix gesammelt, und wir alerten auch von dort aus. Alle Alarme gehen derzeit über die Hauptversandmethoden (aktuell sind das E-Mail und Telegram, und kürzlich haben wir auch MS Teams angebunden). Geplant ist, das Alerting so zu verbessern, dass intelligente Bots wie ein Service funktionieren und allen interessierten Produktteams Informationen zur Überwachung bereitstellen.

Für uns sind Metriken nicht nur für einzelne Informationssysteme wichtig, sondern auch für allgemeine Metriken für die gesamte Infrastruktur, die von den Anwendungen verwendet wird: Cluster physischer Server, auf denen die virtuellen Maschinen laufen, Lastenausgleicher, Network Load Balancer, das Netzwerk selbst, die Auslastung der Kommunikationskanäle. Außerdem Metriken zu unseren eigenen Rechenzentren (von denen wir mehrere haben und die Infrastruktur ziemlich groß ist).

Die Vorteile unseres Monitoringsystems liegen darin, dass wir damit den Betriebsstatus aller Systeme sehen, deren Einfluss aufeinander und auf gemeinsame Ressourcen bewerten können. Letztlich ermöglicht es uns auch die Ressourcenplanung, was ebenfalls in unseren Verantwortungsbereich fällt. Wir verwalten Serverressourcen – ein Pool im Rahmen des E-Commerce, nehmen neue Hardware in Betrieb, ziehen sie aus dem Betrieb, kaufen neue ein, führen Audits zur Ressourcennutzung durch usw. Jedes Jahr planen die Teams neue Projekte, entwickeln ihre Systeme weiter, und es ist wichtig, dass wir sie mit Ressourcen versorgen.

Und anhand der Metriken sehen wir die Tendenz des Ressourcenverbrauchs unserer Informationssysteme. Und bereits auf dieser Grundlage können wir etwas planen. Auf der Virtualisierungsebene sammeln wir Daten und sehen Informationen zur Verfügbarkeit von Ressourcen im Hinblick auf die Rechenzentren. Innerhalb des Rechenzentrums sind sowohl die Auslastung als auch die tatsächliche Verteilung und der Ressourcenverbrauch sichtbar. Und zwar sowohl bei Standalone-Servern als auch bei virtuellen Maschinen und Clustern physischer Server, auf denen all diese virtuellen Maschinen betrieben werden.

Aussichten

Jetzt haben wir das Kernsystem im Großen und Ganzen fertig, aber es gibt noch genug Punkte, an denen wir weiterarbeiten müssen. Mindestens ist dies die Schicht der Informationssicherheit, aber es ist auch wichtig, das Netzwerk zu erreichen, das Alerting zu entwickeln und die Frage der Korrelation zu klären. Wir haben viele Schichten und Systeme, und auf jeder Schicht gibt es viele Metriken. Es ist ein Matroschka in der Potenz einer Matroschka.

Unsere Aufgabe ist es letztendlich, die richtigen Alerts zu erstellen. Zum Beispiel, wenn ein Problem mit der Hardware aufgetreten ist, wieder mit der virtuellen Maschine, und darauf eine wichtige Anwendung war, die nicht reserviert war. Wir erfahren, dass die virtuelle Maschine abgestürzt ist. Dann werden die Geschäftsmängel alarmiert: Die Benutzer sind verschwunden, es gibt keine Konversion, die UI ist im Interface nicht verfügbar, die Software und die Dienste sind ebenfalls abgestürzt.

In einem solchen Szenario erhalten wir Spam aus Alerts, und das passt nicht in das Format eines ordentlichen Monitoring-Systems. Die Frage der Korrelation stellt sich. Daher sollte unser Monitoring-System idealerweise sagen: "Leute, eure physische Maschine ist abgestürzt, und zusammen mit ihr diese Anwendung und solche Metriken", mithilfe eines Alerts, anstatt uns mit einer Flut von hundert Alerts zu überhäufen. Es sollte das Wesentliche mitteilen – den Grund, was zur schnellen Behebung des Problems beiträgt, indem es lokalisiert wird.

Unser Alarmierungssystem und die Verarbeitung der Alerts basieren auf einem 24/7-Helpdesk. Alle Alerts, die wir als Must-Have betrachten und die in die Checkliste aufgenommen werden, werden dorthin weitergeleitet. Jeder Alert muss unbedingt eine Beschreibung haben: Was ist passiert, was bedeutet das im Wesentlichen, worauf hat es Einfluss. Außerdem einen Link zum Dashboard und eine Anleitung, was in diesem Fall zu tun ist.

Das sind die Anforderungen an den Aufbau des Alertings. Danach kann sich die Situation 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 müssen wir aktiv werden und nachhaken.

Im Durchschnitt erhalten wir jetzt täglich etwa hundert Alerts, was die Tatsache berücksichtigt, dass die Korrelation der Alerts noch nicht richtig eingestellt ist. Und wenn technische Arbeiten durchgeführt werden müssen und wir etwas gewaltsam deaktivieren, steigt ihre Anzahl exponentiell.

Neben der Überwachung der Systeme, die wir betreiben, und der Erfassung von Metriken, die wir als wichtig erachten, ermöglicht das Überwachungssystem die Sammlung von Daten für die Produktteams. Diese können Einfluss auf die Zusammensetzung der Metriken in den Informationssystemen nehmen, die wir überwachen.

Unser Kollege kann kommen und bitten, eine nützliche Metrik hinzuzufügen, die sowohl für uns als auch für das Team von Vorteil ist. Oder beispielsweise könnte es dem Team an den grundlegenden Metriken, die wir haben, nicht ausreichen; sie müssen eine spezifische verfolgen. In Grafana erstellen wir einen Raum für jedes Team und gewähren Admin-Rechte. Außerdem, wenn das Team Dashboards benötigt und nicht selbst weiß, wie es das machen soll, helfen wir ihnen.

Da wir nicht unmittelbar am Schaffen von Werten des Teams, deren Releases und der Planung beteiligt sind, nähern wir uns allmählich dem Punkt, dass die Releases aller Systeme nahtlos sind und täglich ausgerollt werden können, ohne zuvor unsere Zustimmung einzuholen. Für uns ist es wichtig, diese Releases zu verfolgen, da sie potenziell die Funktionalität der Anwendung beeinträchtigen und etwas kaputtgehen könnte, was kritisch ist. Zur Verwaltung der Releases nutzen wir Bamboo, von dem wir über die API Daten erhalten und sehen können, welche Releases in welchen Informationssystemen erschienen sind und ihren Status. Und das Wichtigste — zu welcher Zeit. Die Marker zur Veröffentlichung legen wir auf die wesentlichen kritischen Metriken, was visuell sehr aussagekräftig im Falle von Problemen ist.

Auf diese Weise können wir die Korrelation zwischen neuen Releases und auftretenden Problemen sehen. Die Hauptidee ist, zu verstehen, wie das System auf allen Ebenen funktioniert, Probleme schnell zu lokalisieren und ebenso schnell zu beheben. Denn oft dauert es länger, die Ursache zu finden, als das Problem zu lösen.

In dieser Hinsicht möchten wir uns in Zukunft auf Proaktivität konzentrieren. Ideal wäre es, im Voraus über aufkommende Probleme informiert zu werden, anstatt sie nachträglich zu erkennen, um ihre Vermeidung und nicht nur ihre Lösung zu gewährleisten. Manchmal kommt es zu Fehlalarmsystemen, sowohl aufgrund menschlicher Fehler als auch aufgrund von Änderungen in der Anwendung. Wir arbeiten daran, optimieren es und bemühen uns, vor jeglichen Manipulationen am Überwachungssystem die Nutzer, die es gemeinsam mit uns verwenden, darüber zu informieren oder diese Maßnahmen im Wartungsfenster durchzuführen.

So, das System ist in Betrieb und funktioniert seit Anfang des Frühlings erfolgreich... und zeigt einen durchaus realen Gewinn. Natürlich ist dies nicht die finale Version; wir werden noch viele nützliche Funktionen implementieren. Aber im Moment, bei so vielen Integrationen und Anwendungen, kommt man ohne Automatisierung der Überwachung tatsächlich nicht aus.

Wenn Sie auch große Projekte mit einer ernsthaften Anzahl von Integrationen überwachen — schreiben Sie in die Kommentare, welches die ‚Silberkugel‘ war, die Sie dafür gefunden haben.

Quelle: habr.com