News
ZurückUnser Weg mit Monitoring und Alerting
Die Infrastruktur von cloudscale.ch ist nicht nur die Basis für die Services, die wir selber anbieten, sondern bildet auch das Rückgrat für alles, was unsere Kunden darauf aufbauen. Unser Monitoring prüft daher laufend, dass all unsere Komponenten "up" sind und wie gewünscht zusammenspielen – und schlägt Alarm, falls eine Intervention nötig sein sollte. Über die Zeit haben wir die Maschen unseres Monitorings immer feiner geknüpft und optimiert, so dass selbst Probleme innerhalb des Monitorings nicht unentdeckt bleiben und gleichzeitig unnötige Alerts auf ein Minimum reduziert werden.
Unsere bewährte Monitoring-Basis
Dank Redundanz auf allen Ebenen merken unsere Kunden von den meisten isolierten Problemen nichts: Ob Kabel, Harddisk oder Load-Balancer, bei einem Ausfall läuft das Gesamtsystem unbeirrt weiter. Selbstverständlich müssen wir solchen Fällen jedoch nachgehen und z.B. die Redundanz wieder herstellen, damit unsere Cloud so zuverlässig bleibt, wie sie ist. Über das Detektieren und Melden defekter Komponenten hinaus erfasst unser Monitoring aber auch Leistungsdaten und das korrekte Funktionieren ganzer Abläufe "end to end", so dass wir einen allfälligen Handlungsbedarf frühzeitig erkennen.
Von Beginn weg setzten wir bei cloudscale.ch auf Zabbix als Dreh- und Angelpunkt für unser Monitoring und Alerting. Dank seiner Vielseitigkeit und Anpassbarkeit konnten wir damit die meisten Monitoring-Bedürfnisse – die im Laufe der Zeit immer zahlreicher und komplexer wurden – abdecken. In Ergänzung zu unserem internen Zabbix nahmen wir schon früh auch ein externes Monitoring hinzu. Damit konnten wir einerseits zusätzliche Use-Cases abbilden und auch die Nutzerperspektive besser einbeziehen. Andererseits decken wir so Fälle ab, in denen unser eigenes Monitoring von einem Problem mitbetroffen ist und/oder die generierten Alerts aus irgendeinem Grund nicht versendet werden können.
Vielfältige Optimierungen
Neben unserem internen Zabbix prüfen heute zwei externe Monitoring-Dienste die verschiedensten von aussen "sichtbaren" Aspekte unserer Cloud, vom Object Storage bis zu API-Calls. Die sprichwörtlichen Fäden laufen schliesslich bei Opsgenie zusammen. Dieser Service ermöglicht es, die festgelegte Pikett-Einteilung zu hinterlegen und Alerts an die jeweils richtige Person weiterzuleiten. Kann der zuständige Engineer auf eine Meldung einmal nicht umgehend reagieren, erfolgt automatisch eine Eskalation an definierte weitere Personen. Mit der Anzahl involvierter Services steigt natürlich die Komplexität. Mittels automatisierter "Dummy-Alerts" testen wir daher auch immer wieder, ob die Alert-Verarbeitung an sich korrekt funktioniert und ob das Setup bis hin zum Mobiltelefon des eingeplanten Pikett-Mitarbeiters einsatzbereit ist.
Ein erkanntes Problem richtig zu eskalieren ist aber nur der eine Teil. Daneben haben wir auch viel Aufwand in die Optimierung der Datenbasis gesteckt, aus der die Anomalien herausdestilliert werden. Ausgehend von einem bereits breiten Set an Werten, die Monitoring-Systeme typischerweise aus einem laufenden Zielsystem auslesen, haben wir weitere, teils noch Hardware-nähere Checks hinzugefügt. So erkennt unser Monitoring beispielsweise, wenn eine NVMe-Disk am PCIe-Bus nicht die übliche Datenrate ausgehandelt hat. Zur anderen Seite hin – losgelöst von der Hardware – verfügen wir über immer mehr Checks, die den Zustand von ganzen Clustern überwachen, ohne von einem spezifischen Host abhängig zu sein, welcher hierzu abgefragt werden kann. Dank einer soliden Baseline von Messwerten können wir dann die Schwellenwerte so festlegen, dass Probleme zuverlässig erkannt werden, ohne dabei viel Lärm zu generieren.
Weshalb wir ruhig schlafen
Bei cloudscale.ch schläft der diensthabende Pikett-Engineer in der Regel durch. Die erwähnte Redundanz und wohlüberlegte Schwellenwerte erklären dies jedoch nur zum Teil. Wo eine Analyse zu Bürozeiten ausreicht, haben wir den Checks eine niedrige "Severity" zugewiesen und Opsgenie so eingestellt, dass deswegen niemand geweckt wird. Wichtig ist dann die konsequente Nachbearbeitung: Auch niedrige Severities und Anomalien, die tagsüber auffallen, werden zeitnah untersucht, bevor daraus ein Problem wird, für das man nachts aufstehen müsste. Das Gleiche gilt, falls trotzdem mal etwas durchschlägt; fast immer finden wir einen Weg, um künftige, ähnliche Fälle früher zu entdecken oder ganz zu vermeiden.
Zu alledem kommt eine weitere, eher untechnische Ebene: Dank einem separaten Monitoring für unser Lab können sich neue Engineers ganz ohne Druck eingewöhnen und kennen nach kurzer Zeit die Punkte, die es zu beachten gilt. Zudem sorgen beim Beheben von Problemen, die sich trotz ständiger Verbesserung nicht gänzlich vermeiden lassen, direkt verknüpfte Runbooks für die nötige Rückendeckung. Wer als Pikett-Engineer ausnahmsweise doch mal geweckt wird, kann sich so kurz darauf mit einem guten Gefühl wieder hinlegen.
Der zuverlässige Betrieb unserer Cloud-Infrastruktur ist für viele unserer Kunden zentral. Grundlage dafür ist, dass wir Anomalien möglichst frühzeitig erkennen und so die meisten Probleme vermeiden können, bevor sie sich für Kunden auswirken. Unser über die Jahre gewachsenes und laufend verbessertes Monitoring dient uns sozusagen als Augen und Ohren bis in die hintersten Winkel unserer Systeme; es enthält aber auch die Intelligenz, um unsere Engineers bei ihrer Arbeit zu unterstützen und zu entlasten.
Schlafen (auch) Sie gut!
Ihr cloudscale.ch-Team