Notera. transl.: Vi presenterar tekniska detaljer om orsakerna till den senaste driftstoppen i molntjänsten som upprätthålls av skaparna av Grafana. Det här är ett klassiskt exempel på hur en ny och till synes extremt användbar funktion utformad för att förbättra kvaliteten på infrastrukturen... kan orsaka skada om du inte tar hänsyn till de många nyanserna av dess tillämpning i produktionens verklighet. Det är fantastiskt när material som detta dyker upp som låter dig lära dig inte bara av dina misstag. Detaljer finns i översättningen av den här texten från vice VD för produkt från Grafana Labs.
Fredagen den 19 juli slutade Hosted Prometheus-tjänsten i Grafana Cloud att fungera i cirka 30 minuter. Jag ber om ursäkt till alla kunder som drabbats av avbrottet. Vårt jobb är att tillhandahålla de övervakningsverktyg du behöver, och vi förstår att om du inte har dem tillgängliga kan det göra ditt liv svårare. Vi tar denna händelse på största allvar. Den här anteckningen förklarar vad som hände, hur vi reagerade och vad vi gör för att säkerställa att det inte händer igen.
förhistoria
Grafana Cloud Hosted Prometheus tjänst är baserad på — CNCF-projekt för att skapa en horisontellt skalbar, högtillgänglig Prometheus-tjänst med flera hyresgäster. Cortex-arkitekturen består av en uppsättning individuella mikrotjänster, som var och en utför sin egen funktion: replikering, lagring, frågor, etc. Cortex är under aktiv utveckling och lägger ständigt till nya funktioner och förbättrar prestandan. Vi distribuerar regelbundet nya Cortex-utgåvor till kluster så att kunder kan dra nytta av dessa funktioner – lyckligtvis kan Cortex uppdateras utan stillestånd.
För sömlösa uppdateringar kräver Ingester Cortex-tjänsten ytterligare en Ingester-replik under uppdateringsprocessen. (Notera. transl.: - den grundläggande komponenten i Cortex. Dess jobb är att samla in en konstant ström av prover, gruppera dem i Prometheus-bitar och lagra dem i en databas som DynamoDB, BigTable eller Cassandra.) Detta gör att gamla Ingesters kan vidarebefordra aktuell data till nya Ingesters. Värt att notera är att Ingesters är resurskrävande. För att de ska fungera behöver du ha 4 kärnor och 15 GB minne per pod, d.v.s. 25 % av basmaskinens processorkraft och minne i fallet med våra Kubernetes-kluster. I allmänhet har vi vanligtvis mycket mer oanvända resurser i klustret än 4 kärnor och 15 GB minne, så vi kan enkelt snurra upp dessa extra intagare under uppgraderingar.
Det händer dock ofta att ingen av maskinerna under normal drift har dessa 25 % av oanvända resurser. Ja, vi strävar inte ens: CPU och minne kommer alltid att vara användbara för andra processer. För att lösa detta problem bestämde vi oss för att använda . Tanken är att ge Ingesters högre prioritet än andra (statslösa) mikrotjänster. När vi behöver köra ytterligare en (N+1) Ingester, förskjuter vi tillfälligt andra, mindre baljor. Dessa kapslar överförs till lediga resurser på andra maskiner, vilket lämnar ett tillräckligt stort "hål" för att köra en extra Ingester.
Torsdagen den 18 juli lanserade vi fyra nya prioritetsnivåer till våra kluster: kritisk, hög, genomsnitt и låg. De testades på ett internt kluster utan kundtrafik under ungefär en vecka. Som standard tas pods utan en specificerad prioritet emot genomsnitt prioritet sattes klass för Ingesters med hög prioritet. Kritisk var reserverad för övervakning (Prometheus, Alertmanager, node-exporter, kube-state-metrics, etc.). Vår konfiguration är öppen och du kan se PR .
olycka
Fredagen den 19 juli lanserade en av ingenjörerna ett nytt dedikerat Cortex-kluster för en stor kund. Konfigurationen för det här klustret inkluderade inte nya pod-prioriteter, så alla nya pods tilldelades en standardprioritet - genomsnitt.
Kubernetes-klustret hade inte tillräckligt med resurser för det nya Cortex-klustret, och det befintliga Cortex-klustret uppdaterades inte (Ingesters lämnades utan hög prioritet). Eftersom Ingesters av det nya klustret som standard hade genomsnitt prioritet, och de befintliga baljorna i produktionen fungerade helt utan prioritet, ersatte Ingesters i det nya klustret Ingesters från det befintliga Cortex-produktionsklustret.
ReplicaSet för den vräkta Ingester i produktionsklustret upptäckte den vräkta poden och skapade en ny för att behålla det angivna antalet kopior. Den nya podden tilldelades som standard genomsnitt prioritet, och en annan "gammal" Ingester i produktionen tappade sina resurser. Resultatet blev lavinprocess, vilket ledde till förskjutningen av alla baljor från Ingester för Cortex-produktionskluster.
Intagna är statistiska och lagrar data för de senaste 12 timmarna. Detta gör att vi kan komprimera dem mer effektivt innan vi skriver dem till långtidslagring. För att uppnå detta skär Cortex data över serier med hjälp av en Distributed Hash Table (DHT) och replikerar varje serie över tre Ingesters med Dynamo-liknande kvorumkonsistens. Cortex skriver inte data till Ingesters som är inaktiverade. Sålunda, när ett stort antal Ingesters lämnar DHT, kan Cortex inte tillhandahålla tillräcklig replikering av posterna, och de kraschar.
Detektion och sanering
Nya Prometheus-meddelanden baserade på "felbudget" (felbudgetbaserad — detaljer kommer att visas i en framtida artikel) började larma 4 minuter efter starten av avstängningen. Under de kommande fem minuterna eller så körde vi lite diagnostik och skalade upp det underliggande Kubernetes-klustret för att vara värd för både de nya och befintliga produktionsklustren.
Efter ytterligare fem minuter skrev de gamla Ingesters sina data framgångsrikt, de nya startade och Cortex-klustren blev tillgängliga igen.
Ytterligare 10 minuter ägnades åt att diagnostisera och korrigera out-of-memory (OOM)-fel från autentiseringsomvända proxyservrar placerade framför Cortex. OOM-fel orsakades av en tiofaldig ökning av QPS (vi tror på grund av alltför aggressiva förfrågningar från klientens Prometheus-servrar).
Aftermath
Den totala stilleståndstiden var 26 minuter. Ingen data gick förlorad. Införare har framgångsrikt laddat in all data i minnet till långtidslagring. Under avstängningen, buffrade klient Prometheus-servrar raderade (avlägset) inspelningar med hjälp av baserad på WAL (författad av från Grafana Labs) och upprepade de misslyckade skrivningarna efter kraschen.
Skrivoperationer för produktionskluster
Resultat
Det är viktigt att lära av denna incident och vidta nödvändiga åtgärder för att undvika att den upprepas.
I efterhand borde vi inte ha angett standard genomsnitt prioritet tills alla Ingesters i produktion har fått hög en prioritet. Dessutom var det nödvändigt att ta hand om dem i förväg hög prioritet. Allt är fixat nu. Vi hoppas att vår erfarenhet kommer att hjälpa andra organisationer som överväger att använda podprioriteter i Kubernetes.
Vi kommer att lägga till en ytterligare nivå av kontroll över distributionen av ytterligare objekt vars konfigurationer är globala för klustret. Från och med nu kommer sådana förändringar att bedömasоfler människor. Dessutom ansågs modifieringen som orsakade kraschen vara för liten för ett separat projektdokument - det diskuterades bara i ett GitHub-nummer. Från och med nu kommer alla sådana ändringar av konfigurationer att åtföljas av lämplig projektdokumentation.
Slutligen kommer vi att automatisera storleksändring av autentiseringsproxyn för att förhindra överbelastningen av OOM vi bevittnat, och kommer att granska Prometheus standardinställningar relaterade till reserv och skalning för att förhindra liknande problem i framtiden.
Misslyckandet hade också några positiva konsekvenser: efter att ha fått de nödvändiga resurserna återhämtade sig Cortex automatiskt utan ytterligare ingrepp. Vi fick också värdefull erfarenhet av att arbeta med - vårt nya loggaggregationssystem - som hjälpte till att säkerställa att alla Ingesters skötte sig ordentligt under och efter felet.
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com