Jegyzet. ford.: Technikai részleteket mutatunk be a Grafana készítői által fenntartott felhőszolgáltatás közelmúltbeli leállásának okairól. Klasszikus példája ez annak, hogy egy új és rendkívül hasznosnak tűnő, az infrastruktúra minőségének javítására... Nagyszerű, amikor megjelennek az ehhez hasonló anyagok, amelyek lehetővé teszik, hogy ne csak a hibáiból tanuljon. A részletek a Grafana Labs termékért felelős alelnökének fordításában találhatók.
Július 19-én, pénteken a Hosted Prometheus szolgáltatás a Grafana Cloudban körülbelül 30 percre leállt. Elnézést kérek minden, a kiesés által érintett vásárlótól. A mi feladatunk az, hogy biztosítsuk a szükséges felügyeleti eszközöket, és megértjük, hogy ezek hiánya megnehezítheti az életét. Rendkívül komolyan vesszük ezt az esetet. Ez a megjegyzés elmagyarázza, mi történt, hogyan reagáltunk, és mit teszünk annak érdekében, hogy ez ne ismétlődhessen meg.
őstörténet
A Grafana Cloud Hosted Prometheus szolgáltatás alapja — CNCF projekt egy vízszintesen méretezhető, magas rendelkezésre állású, több bérlős Prometheus szolgáltatás létrehozására. A Cortex architektúra egyedi mikroszolgáltatások készletéből áll, amelyek mindegyike ellátja a saját funkcióját: replikáció, tárolás, lekérdezések stb. A Cortex aktív fejlesztés alatt áll, és folyamatosan új funkciókkal bővíti és javítja a teljesítményt. Rendszeresen telepítünk új Cortex-kiadásokat a fürtökbe, hogy az ügyfelek kihasználhassák ezeket a funkciókat – szerencsére a Cortex leállás nélkül frissíthető.
A zökkenőmentes frissítések érdekében az Ingester Cortex szolgáltatás további Ingester-replikát igényel a frissítési folyamat során. (Jegyzet. ford.: - a Cortex alapkomponense. Feladata az, hogy állandó mintaáramot gyűjtsön, Prometheus-darabokba csoportosítsa, és olyan adatbázisban tárolja őket, mint a DynamoDB, a BigTable vagy a Cassandra.) Ez lehetővé teszi a régi Ingesterek számára, hogy az aktuális adatokat továbbítsák az új Ingestereknek. Érdemes megjegyezni, hogy az Ingesterek erőforrásigényesek. Ahhoz, hogy működjenek, podonként 4 magra és 15 GB memóriára van szükség, pl. Kubernetes klasztereink esetében az alapgép feldolgozási teljesítményének és memóriájának 25%-a. Általánosságban elmondható, hogy a fürtben általában jóval több a kihasználatlan erőforrásunk, mint 4 mag és 15 GB memória, így a frissítések során könnyedén felpörgethetjük ezeket a további beolvasókat.
Gyakran előfordul azonban, hogy normál működés közben egyik gépnek sincs meg ez a 25%-a kihasználatlan erőforrás. Igen, nem is törekszünk: a CPU és a memória mindig hasznos lesz más folyamatokhoz. A probléma megoldására úgy döntöttünk, hogy használjuk . Az ötlet az, hogy az Ingesters magasabb prioritást kapjon, mint a többi (hontalan) mikroszolgáltatás. Amikor további (N+1) Ingestert kell futtatnunk, ideiglenesen kiszorítunk más, kisebb hüvelyeket. Ezek a pod-ok átkerülnek más gépek szabad erőforrásaiba, így elég nagy „lyuk” marad egy további Ingester futtatásához.
Július 18-án, csütörtökön négy új prioritási szintet vezettünk be klasztereink számára: kritikai, magas, átlagos и alacsony. Egy belső fürtön tesztelték őket, ahol körülbelül egy hétig nem volt ügyfélforgalom. Alapértelmezés szerint meghatározott prioritás nélküli sorba rendezések érkeznek átlagos prioritás, az osztály az Ingesters számára lett beállítva magas kiemelten fontos. Kritikai figyelésre volt fenntartva (Prometheus, Alertmanager, node-exporter, kube-state-metrics stb.). A konfigurációnk nyitva van, és megtekintheti a PR-t .
baleset
Július 19-én, pénteken az egyik mérnök új, dedikált Cortex-fürtöt indított egy nagy ügyfél számára. Ennek a fürtnek a konfigurációja nem tartalmazott új pod-prioritásokat, így minden új sorba rendezés alapértelmezett prioritást kapott - átlagos.
A Kubernetes-fürtnek nem volt elegendő erőforrása az új Cortex-fürthöz, és a meglévő éles Cortex-fürt nem frissült (az ingerlők nélkül maradtak magas kiemelten fontos). Mivel az új fürt Ingesterei alapértelmezés szerint megvoltak átlagos prioritás, és a termelésben lévő meglévő podok prioritás nélkül működtek, az új klaszter Ingesterei felváltották a meglévő Cortex termelési klaszter Ingestereit.
Az éles fürtben lévő kilakoltatott Ingester ReplicaSet programja észlelte a kilakoltatott pod-ot, és létrehozott egy újat, hogy fenntartsa a megadott példányszámot. Az új pod alapértelmezés szerint hozzá lett rendelve átlagos prioritást, és egy másik „régi” Ingester a termelésben elvesztette erőforrásait. Az eredmény az volt lavina folyamat, ami az összes hüvely kiszorításához vezetett az Ingester for Cortex termelési klasztereihez.
A feldolgozók állapotjelzők, és az előző 12 óra adatait tárolják. Ez lehetővé teszi, hogy hatékonyabban tömörítsük őket, mielőtt hosszú távú tárolásra írnánk őket. Ennek elérése érdekében a Cortex szétosztja az adatokat a sorozatok között egy elosztott kivonattábla (DHT) segítségével, és az egyes sorozatokat három Ingester között replikálja a Dynamo-stílusú kvórumkonzisztencia használatával. A Cortex nem ír adatokat a letiltott Ingesterekre. Így, amikor nagyszámú Ingester elhagyja a DHT-t, a Cortex nem tudja biztosítani a bejegyzések megfelelő replikációját, és összeomlik.
Észlelés és helyreállítás
Új Prometheus értesítések "hibaköltségvetés" alapján (hibaköltségvetés alapú — részletek egy későbbi cikkben jelennek meg) 4 perccel a leállás kezdete után ébresztőt fújt. A következő körülbelül öt percben lefuttattunk néhány diagnosztikát, és kibővítettük az alapul szolgáló Kubernetes-fürtöt, hogy az új és a meglévő éles fürtöket is befogadja.
Újabb öt perc elteltével a régi Ingesterek sikeresen megírták adataikat, elindultak az újak, és újra elérhetővé váltak a Cortex klaszterek.
További 10 percet töltöttek a memóriahiány (OOM) hibák diagnosztizálásával és kijavításával a Cortex előtt található hitelesítési fordított proxykon keresztül. Az OOM hibákat a QPS tízszeres növekedése okozta (szerintünk az ügyfél Prometheus szervereitől érkező túl agresszív kérések miatt).
Utóhatás
A teljes állásidő 26 perc volt. Nem veszett el adat. Az Ingesters sikeresen betöltötte a memóriában lévő összes adatot a hosszú távú tárolásba. A leállítás során a Prometheus kliens szerverek pufferei törölve lettek (távolról) felvételek segítségével WAL alapján (szerző: a Grafana Labs-tól), és megismételte a sikertelen írásokat az összeomlás után.
Termelési fürt írási műveletei
Álláspontja
Fontos, hogy tanuljunk ebből az esetből, és megtegyük a szükséges lépéseket annak elkerülése érdekében, hogy megismétlődjön.
Utólag visszagondolva, nem kellett volna beállítani az alapértelmezettet átlagos elsőbbséget, amíg az összes termelésben lévő Ingester meg nem kapja magas prioritás. Ráadásul előre kellett gondoskodni róluk magas kiemelten fontos. Most már minden meg van oldva. Reméljük, hogy tapasztalatunk segíteni fog más szervezeteknek, amelyek fontolóra veszik a pod prioritások alkalmazását a Kubernetesben.
Egy további vezérlési szintet fogunk hozzáadni minden olyan további objektum telepítéséhez, amelyek konfigurációja globális a fürtben. Ezentúl az ilyen változásokat értékelik bоtöbb ember. Ezenkívül az összeomlást okozó módosítást túl kicsinek tartották egy külön projektdokumentumhoz – csak egy GitHub-számban tárgyalták. Mostantól a konfigurációk minden ilyen módosításához megfelelő projektdokumentáció is társul.
Végül automatizáljuk a hitelesítés fordított proxyjának átméretezését, hogy megakadályozzuk az általunk tapasztalt OOM túlterhelést, és felülvizsgáljuk a Prometheus alapértelmezett beállításait a tartalékkal és a méretezéssel kapcsolatban, hogy a jövőben elkerüljük a hasonló problémákat.
A kudarcnak pozitív következményei is voltak: miután megkapta a szükséges erőforrásokat, a Cortex további beavatkozás nélkül automatikusan felépült. Emellett értékes tapasztalatokat is szereztünk a közös munkában - az új naplóösszesítő rendszerünk - amely biztosította, hogy minden Ingester megfelelően viselkedjen a hiba alatt és után.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com