Opmerking. vert.: We presenteren technische details onder uw aandacht over de redenen voor de recente downtime in de cloudservice die wordt onderhouden door de makers van Grafana. Dit is een klassiek voorbeeld van hoe een nieuwe en ogenschijnlijk uiterst nuttige functie, ontworpen om de kwaliteit van de infrastructuur te verbeteren... schade kan veroorzaken als je niet rekening houdt met de talrijke nuances van de toepassing ervan in de realiteit van de productie. Het is geweldig als dit soort materialen verschijnen waarmee je niet alleen van je fouten kunt leren. Details staan in de vertaling van deze tekst van de vice-president van product van Grafana Labs.
Op vrijdag 19 juli functioneerde de Hosted Prometheus-service in Grafana Cloud ongeveer 30 minuten niet meer. Mijn excuses aan alle klanten die getroffen zijn door de storing. Het is onze taak om u de monitoringtools te bieden die u nodig heeft, en we begrijpen dat het niet beschikbaar hebben ervan uw leven moeilijker kan maken. Wij nemen dit incident uiterst serieus. In deze notitie wordt uitgelegd wat er is gebeurd, hoe we hebben gereageerd en wat we doen om ervoor te zorgen dat dit niet opnieuw gebeurt.
prehistorie
De Grafana Cloud Hosted Prometheus-service is gebaseerd op — CNCF-project om een horizontaal schaalbare, zeer beschikbare Prometheus-service met meerdere tenants te creëren. De Cortex-architectuur bestaat uit een reeks individuele microservices, die elk hun eigen functie vervullen: replicatie, opslag, queries, enz. Cortex wordt actief ontwikkeld en voegt voortdurend nieuwe functies toe en verbetert de prestaties. We implementeren regelmatig nieuwe Cortex-releases in clusters, zodat klanten van deze functies kunnen profiteren. Gelukkig kan Cortex zonder downtime worden bijgewerkt.
Voor naadloze updates vereist de Ingester Cortex-service een extra Ingester-replica tijdens het updateproces. (Opmerking. vert.: - het basiscomponent van de Cortex. Het is zijn taak om een constante stroom monsters te verzamelen, deze in Prometheus-brokken te groeperen en ze op te slaan in een database zoals DynamoDB, BigTable of Cassandra.) Hierdoor kunnen oude Ingesters actuele gegevens doorsturen naar nieuwe Ingesters. Het is vermeldenswaard dat Ingesters veel hulpbronnen vereisen. Om ze te laten werken, heb je 4 cores en 15 GB geheugen per pod nodig, d.w.z. 25% van de verwerkingskracht en het geheugen van de basismachine in het geval van onze Kubernetes-clusters. Over het algemeen hebben we meestal veel meer ongebruikte bronnen in het cluster dan 4 cores en 15 GB geheugen, dus we kunnen deze extra opnames gemakkelijk gebruiken tijdens upgrades.
Het komt echter vaak voor dat tijdens normaal gebruik geen van de machines deze 25% ongebruikte bronnen heeft. Ja, we streven er niet eens naar: CPU en geheugen zullen altijd nuttig zijn voor andere processen. Om dit probleem op te lossen, hebben we besloten om te gebruiken . Het idee is om Ingesters een hogere prioriteit te geven dan andere (staatloze) microservices. Wanneer we een extra (N+1) Ingester moeten gebruiken, verplaatsen we tijdelijk andere, kleinere pods. Deze pods worden overgebracht naar vrije bronnen op andere machines, waardoor er een “gat” overblijft dat groot genoeg is om een extra Ingester te laten draaien.
Op donderdag 18 juli hebben we vier nieuwe prioriteitsniveaus uitgerold naar onze clusters: kritiek, hoog, gemiddeld и laag. Ze werden ongeveer een week lang getest op een intern cluster zonder clientverkeer. Standaard worden pods zonder opgegeven prioriteit ontvangen gemiddeld prioriteit, klasse is ingesteld voor Ingesters met hoog prioriteit. kritisch was gereserveerd voor monitoring (Prometheus, Alertmanager, node-exporter, kube-state-metrics, enz.). Onze configuratie is geopend en u kunt de PR bekijken .
ongeval
Op vrijdag 19 juli lanceerde een van de engineers een nieuw dedicated Cortex-cluster voor een grote klant. De configuratie voor dit cluster bevatte geen nieuwe podprioriteiten, dus aan alle nieuwe pods werd een standaardprioriteit toegewezen: gemiddeld.
Het Kubernetes-cluster beschikte niet over voldoende bronnen voor het nieuwe Cortex-cluster en het bestaande Cortex-productiecluster werd niet bijgewerkt (Ingesters bleven zonder hoog prioriteit). Omdat de Ingesters van het nieuwe cluster dat standaard hadden gemiddeld prioriteit, en de bestaande pods in productie werkten helemaal zonder prioriteit, vervingen de Ingesters van het nieuwe cluster de Ingesters van het bestaande Cortex-productiecluster.
ReplicaSet voor de verwijderde Ingester in het productiecluster heeft de verwijderde pod gedetecteerd en een nieuwe gemaakt om het opgegeven aantal exemplaren te behouden. De nieuwe pod is standaard toegewezen gemiddeld prioriteit, en een andere “oude” Ingester in productie verloor zijn hulpbronnen. Het resultaat was lawine proces, wat leidde tot de verplaatsing van alle pods van Ingester voor Cortex-productieclusters.
Ingesters zijn stateful en slaan gegevens op van de afgelopen 12 uur. Hierdoor kunnen we ze efficiënter comprimeren voordat we ze naar langdurige opslag schrijven. Om dit te bereiken verdeelt Cortex gegevens over reeksen met behulp van een Distributed Hash Table (DHT) en repliceert elke reeks over drie Ingesters met behulp van quorumconsistentie in Dynamo-stijl. Cortex schrijft geen gegevens naar Ingesters die zijn uitgeschakeld. Wanneer een groot aantal Ingesters de DHT verlaat, kan Cortex dus niet voldoende replicatie van de vermeldingen bieden en crashen ze.
Detectie en herstel
Nieuwe Prometheus-meldingen op basis van "foutbudget" (op foutenbudget gebaseerd (details verschijnen in een toekomstig artikel) begon vier minuten na het begin van de uitschakeling alarm te slaan. In de daaropvolgende vijf minuten hebben we wat diagnostische tests uitgevoerd en het onderliggende Kubernetes-cluster opgeschaald om zowel de nieuwe als de bestaande productieclusters te hosten.
Na nog eens vijf minuten schreven de oude Ingesters met succes hun gegevens, startten de nieuwe op en kwamen de Cortex-clusters weer beschikbaar.
Nog eens 10 minuten werden besteed aan het diagnosticeren en corrigeren van OOM-fouten (out-of-memory) van reverse proxy's voor authenticatie die zich vóór Cortex bevonden. OOM-fouten werden veroorzaakt door een vertienvoudiging van de QPS (naar onze mening als gevolg van te agressieve verzoeken van de Prometheus-servers van de klant).
Nasleep
De totale downtime bedroeg 26 minuten. Er zijn geen gegevens verloren gegaan. Ingesters hebben alle gegevens in het geheugen met succes in de langetermijnopslag geladen. Tijdens het afsluiten zijn de client-Prometheus-servers gebufferd verwijderd (op afstand) opnames gebruiken gebaseerd op WAL (auteur van van Grafana Labs) en herhaalde de mislukte schrijfbewerkingen na de crash.
Schrijfbewerkingen voor productieclusters
Bevindingen
Het is belangrijk om van dit incident te leren en de nodige stappen te ondernemen om herhaling te voorkomen.
Achteraf gezien hadden we de standaard niet moeten instellen gemiddeld prioriteit totdat alle Ingesters in productie dit hebben ontvangen hoog een prioriteit. Bovendien was het noodzakelijk om er van tevoren voor te zorgen hoog prioriteit. Alles is nu opgelost. We hopen dat onze ervaring andere organisaties zal helpen die overwegen podprioriteiten in Kubernetes te gebruiken.
We zullen een extra niveau van controle toevoegen over de implementatie van eventuele extra objecten waarvan de configuraties globaal zijn voor het cluster. Dergelijke wijzigingen worden voortaan beoordeeld. bоmeer mensen. Bovendien werd de wijziging die de crash veroorzaakte als te klein beschouwd voor een afzonderlijk projectdocument; deze werd alleen besproken in een GitHub-probleem. Vanaf nu zullen al dergelijke wijzigingen in de configuratie vergezeld gaan van de juiste projectdocumentatie.
Ten slotte zullen we het aanpassen van de grootte van de reverse proxy voor authenticatie automatiseren om de overbelasting van OOM die we hebben gezien te voorkomen, en zullen we de standaardinstellingen van Prometheus met betrekking tot fallback en schaling herzien om soortgelijke problemen in de toekomst te voorkomen.
De mislukking had ook enkele positieve gevolgen: nadat Cortex de nodige middelen had ontvangen, herstelde hij zich automatisch zonder extra tussenkomst. We hebben ook waardevolle ervaring opgedaan met het werken met - ons nieuwe logaggregatiesysteem - dat ervoor heeft gezorgd dat alle instellers zich correct gedroegen tijdens en na de storing.
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com