Notiz. übersetzen: Wir präsentieren Ihnen technische Details zu den Gründen für die kürzliche Ausfallzeit des Cloud-Dienstes, der von den Entwicklern von Grafana verwaltet wird. Dies ist ein klassisches Beispiel dafür, wie eine neue und scheinbar äußerst nützliche Funktion zur Verbesserung der Infrastrukturqualität Schaden anrichten kann, wenn die zahlreichen Nuancen ihrer Anwendung in der Produktionsrealität nicht berücksichtigt werden. Es ist großartig, wenn solche Materialien auftauchen, die es Ihnen ermöglichen, nicht nur aus Ihren Fehlern zu lernen. Einzelheiten finden Sie in der Übersetzung dieses Textes vom Vizepräsidenten für Produkte von Grafana Labs.
Am Freitag, den 19. Juli, funktionierte der Hosted Prometheus-Dienst in der Grafana Cloud für etwa 30 Minuten nicht mehr. Ich entschuldige mich bei allen Kunden, die von dem Ausfall betroffen sind. Unsere Aufgabe ist es, die Überwachungstools bereitzustellen, die Sie benötigen, und wir verstehen, dass es Ihr Leben schwieriger machen kann, wenn diese nicht verfügbar sind. Wir nehmen diesen Vorfall äußerst ernst. In dieser Notiz wird erläutert, was passiert ist, wie wir reagiert haben und was wir tun, um sicherzustellen, dass so etwas nicht noch einmal passiert.
Vorgeschichte
Der Grafana Cloud Hosted Prometheus-Dienst basiert auf — CNCF-Projekt zur Schaffung eines horizontal skalierbaren, hochverfügbaren, mandantenfähigen Prometheus-Dienstes. Die Cortex-Architektur besteht aus einer Reihe einzelner Microservices, von denen jeder seine eigene Funktion erfüllt: Replikation, Speicherung, Abfragen usw. Cortex befindet sich in aktiver Entwicklung und fügt ständig neue Funktionen hinzu und verbessert die Leistung. Wir stellen regelmäßig neue Cortex-Releases in Clustern bereit, damit Kunden diese Funktionen nutzen können – glücklicherweise kann Cortex ohne Ausfallzeiten aktualisiert werden.
Für nahtlose Updates benötigt der Ingester Cortex-Dienst während des Update-Vorgangs ein zusätzliches Ingester-Replikat. (Notiz. übersetzen: - die Grundkomponente des Cortex. Seine Aufgabe besteht darin, einen konstanten Strom von Proben zu sammeln, sie in Prometheus-Blöcken zu gruppieren und sie in einer Datenbank wie DynamoDB, BigTable oder Cassandra zu speichern.) Dadurch können alte Ingester aktuelle Daten an neue Ingester weiterleiten. Es ist erwähnenswert, dass Ingester ressourcenintensiv sind. Damit sie funktionieren, müssen Sie über 4 Kerne und 15 GB Speicher pro Pod verfügen, d. h. 25 % der Rechenleistung und des Speichers der Basismaschine im Fall unserer Kubernetes-Cluster. Im Allgemeinen verfügen wir im Cluster normalerweise über viel mehr ungenutzte Ressourcen als 4 Kerne und 15 GB Speicher, sodass wir diese zusätzlichen Ingester bei Upgrades problemlos hochfahren können.
Allerdings kommt es häufig vor, dass im Normalbetrieb keine der Maschinen über diese 25 % ungenutzter Ressourcen verfügt. Ja, wir streben nicht einmal danach: CPU und Speicher werden immer für andere Prozesse nützlich sein. Um dieses Problem zu lösen, haben wir uns für die Verwendung entschieden . Die Idee besteht darin, Ingestern eine höhere Priorität einzuräumen als anderen (zustandslosen) Microservices. Wenn wir einen zusätzlichen (N+1) Ingester betreiben müssen, ersetzen wir vorübergehend andere, kleinere Pods. Diese Pods werden auf freie Ressourcen auf anderen Maschinen übertragen, wodurch eine ausreichend große „Lücke“ entsteht, um einen zusätzlichen Ingester auszuführen.
Am Donnerstag, den 18. Juli, haben wir vier neue Prioritätsstufen für unsere Cluster eingeführt: kritisch, hoch, Durchschnitt и niedrig. Sie wurden etwa eine Woche lang auf einem internen Cluster ohne Client-Verkehr getestet. Standardmäßig werden Pods ohne angegebene Priorität empfangen Durchschnitt Priorität, Klasse wurde für Ingester mit festgelegt hoch Priorität. Kritisch war für die Überwachung reserviert (Prometheus, Alertmanager, Node-Exporter, Kube-State-Metrics usw.). Unsere Konfiguration ist geöffnet und Sie können die PR anzeigen .
Unfall
Am Freitag, den 19. Juli, startete einer der Ingenieure einen neuen dedizierten Cortex-Cluster für einen großen Kunden. Die Konfiguration für diesen Cluster enthielt keine neuen Pod-Prioritäten, daher wurde allen neuen Pods eine Standardpriorität zugewiesen – Durchschnitt.
Der Kubernetes-Cluster verfügte nicht über genügend Ressourcen für den neuen Cortex-Cluster und der vorhandene Produktions-Cortex-Cluster wurde nicht aktualisiert (Ingester blieben ohne высокого Priorität). Da die Ingesters den neuen Cluster standardmäßig hatten Durchschnitt Da die Pods keine Priorität hatten und die vorhandenen Pods in der Produktion überhaupt ohne Priorität arbeiteten, ersetzten die Ingester des neuen Clusters die Ingester des bestehenden Cortex-Produktionsclusters.
ReplicaSet für den geräumten Ingester im Produktionscluster hat den geräumten Pod erkannt und einen neuen erstellt, um die angegebene Anzahl von Kopien beizubehalten. Der neue Pod wurde standardmäßig zugewiesen Durchschnitt Priorität, und ein weiterer „alter“ Ingester in der Produktion verlor seine Ressourcen. Das Ergebnis war Lawinenprozess, was zur Verdrängung aller Pods von Ingester für Cortex-Produktionscluster führte.
Ingester sind zustandsbehaftet und speichern Daten für die letzten 12 Stunden. Dadurch können wir sie effizienter komprimieren, bevor wir sie in den Langzeitspeicher schreiben. Um dies zu erreichen, teilt Cortex die Daten mithilfe einer Distributed Hash Table (DHT) serienübergreifend auf und repliziert jede Serie über drei Ingester unter Verwendung der Quorumkonsistenz im Dynamo-Stil. Cortex schreibt keine Daten an Ingester, die deaktiviert sind. Wenn also eine große Anzahl von Ingestern das DHT verlässt, kann Cortex die Einträge nicht ausreichend replizieren und sie stürzen ab.
Erkennung und Behebung
Neue Prometheus-Benachrichtigungen basierend auf „Fehlerbudget“ (fehlerbudgetbasiert – Details werden in einem zukünftigen Artikel erscheinen) begann vier Minuten nach Beginn der Abschaltung den Alarm auszulösen. In den nächsten etwa fünf Minuten führten wir einige Diagnosen durch und skalierten den zugrunde liegenden Kubernetes-Cluster hoch, um sowohl den neuen als auch den vorhandenen Produktionscluster zu hosten.
Nach weiteren fünf Minuten schrieben die alten Ingester ihre Daten erfolgreich, die neuen starteten und die Cortex-Cluster waren wieder verfügbar.
Weitere 10 Minuten wurden mit der Diagnose und Korrektur von Out-of-Memory (OOM)-Fehlern von Authentifizierungs-Reverse-Proxys vor Cortex verbracht. OOM-Fehler wurden durch einen zehnfachen Anstieg der QPS verursacht (wir gehen davon aus, dass dies auf übermäßig aggressive Anfragen von den Prometheus-Servern des Clients zurückzuführen ist).
Nachwirkungen
Die gesamte Ausfallzeit betrug 26 Minuten. Es gingen keine Daten verloren. Ingester haben alle In-Memory-Daten erfolgreich in den Langzeitspeicher geladen. Während des Herunterfahrens wurden die Puffer der Client-Prometheus-Server gelöscht (Fernbedienung) Aufnahmen mit basierend auf WAL (verfasst von von Grafana Labs) und wiederholte die fehlgeschlagenen Schreibvorgänge nach dem Absturz.
Schreibvorgänge im Produktionscluster
Befund
Es ist wichtig, aus diesem Vorfall zu lernen und die notwendigen Schritte zu unternehmen, um eine Wiederholung zu verhindern.
Im Nachhinein betrachtet hätten wir die Standardeinstellung nicht festlegen sollen Durchschnitt Priorität, bis alle Ingester in der Produktion erhalten haben hoch eine Priorität. Darüber hinaus war es notwendig, sich im Vorfeld um sie zu kümmern hoch Priorität. Jetzt ist alles behoben. Wir hoffen, dass unsere Erfahrung anderen Organisationen helfen wird, die Verwendung von Pod-Prioritäten in Kubernetes in Betracht zu ziehen.
Wir werden eine zusätzliche Ebene der Kontrolle über die Bereitstellung zusätzlicher Objekte hinzufügen, deren Konfigurationen global für den Cluster sind. Von nun an werden solche Änderungen bewertet. bоmehr Leute. Darüber hinaus wurde die Änderung, die den Absturz verursachte, als zu geringfügig für ein separates Projektdokument angesehen – sie wurde nur in einem GitHub-Problem besprochen. Von nun an werden alle derartigen Konfigurationsänderungen von einer entsprechenden Projektdokumentation begleitet.
Schließlich werden wir die Größenänderung des Authentifizierungs-Reverse-Proxys automatisieren, um die von uns beobachtete OOM-Überlastung zu verhindern, und wir werden die Standardeinstellungen von Prometheus in Bezug auf Fallback und Skalierung überprüfen, um ähnliche Probleme in Zukunft zu verhindern.
Der Ausfall hatte auch einige positive Folgen: Nachdem Cortex die erforderlichen Ressourcen erhalten hatte, erholte sich Cortex automatisch, ohne dass zusätzliche Eingriffe erforderlich waren. Wir haben auch wertvolle Erfahrungen in der Zusammenarbeit mit gesammelt – unser neues Protokollaggregationssystem – das dazu beigetragen hat, sicherzustellen, dass sich alle Ingester während und nach dem Ausfall ordnungsgemäß verhielten.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com