Märge. tõlge: tutvustame teie tähelepanu tehnilisi üksikasju Grafana loojate hallatava pilveteenuse hiljutise seisaku põhjuste kohta. See on klassikaline näide sellest, kuidas uus ja esmapilgul äärmiselt kasulik funktsioon, mis on loodud infrastruktuuri kvaliteedi parandamiseks..., võib kahjustada, kui te ei näe ette selle arvukaid nüansse selle rakendamisel tootmisreaalsuses. On suurepärane, kui ilmuvad sellised materjalid, mis võimaldavad teil õppida mitte ainult oma vigadest. Üksikasjad on selle teksti tõlkes Grafana Labsi toote asepresidendilt.
Reedel, 19. juulil peatus Grafana pilves hostitud Prometheuse teenus ligikaudu 30 minutiks. Vabandan kõikide klientide ees, keda katkestus puudutas. Meie ülesanne on pakkuda teile vajalikke jälgimistööriistu ja mõistame, et nende puudumine võib teie elu keerulisemaks muuta. Me võtame seda juhtumit äärmiselt tõsiselt. See märkus selgitab, mis juhtus, kuidas me reageerisime ja mida me teeme, et see ei korduks.
eelajalugu
Grafana Cloud Hosted Prometheuse teenus põhineb — CNCF-i projekt, mille eesmärk on luua horisontaalselt skaleeritav, väga kättesaadav, mitme rentnikuga Prometheuse teenus. Cortexi arhitektuur koosneb üksikute mikroteenuste komplektist, millest igaüks täidab oma funktsiooni: replikatsioon, salvestus, päringud jne. Cortex on aktiivses arenduses ning lisab pidevalt uusi funktsioone ja parandab jõudlust. Juurutame klastritesse regulaarselt uusi Cortexi väljaandeid, et kliendid saaksid neid funktsioone ära kasutada – õnneks saab Cortexi värskendada ilma seisakuta.
Sujuvate värskenduste jaoks nõuab Ingester Cortexi teenus värskendusprotsessi ajal täiendavat Ingesteri koopiat. (Märge. tõlge: - Cortexi põhikomponent. Selle ülesanne on koguda pidevat proovivoogu, rühmitada need Prometheuse tükkideks ja salvestada andmebaasi, nagu DynamoDB, BigTable või Cassandra.) See võimaldab vanadel Ingesteritel edastada praeguseid andmeid uutele Ingesteritele. Väärib märkimist, et ingesterid on ressursinõudlikud. Et need töötaksid, peab ühe podi kohta olema 4 tuuma ja 15 GB mälu, st. 25% baasmasina töötlemisvõimsusest ja mälust meie Kubernetese klastrite puhul. Üldiselt on meil tavaliselt klastris palju rohkem kasutamata ressursse kui 4 tuuma ja 15 GB mälu, nii et saame neid täiendavaid sisestusseadmeid uuendamise ajal hõlpsalt üles keerata.
Tihti aga juhtub, et tavatöö käigus pole ühelgi masinal seda 25% kasutamata ressurssidest. Jah, me isegi ei pinguta: protsessor ja mälu on alati kasulikud muude protsesside jaoks. Selle probleemi lahendamiseks otsustasime kasutada . Idee on anda Ingesteritele kõrgem prioriteet kui teistele (kodakondsuseta) mikroteenustele. Kui meil on vaja käivitada täiendav (N+1) Ingester, tõrjume ajutiselt välja teised väiksemad kaunad. Need kaustad kantakse üle teiste masinate vabadesse ressurssidesse, jättes piisavalt suure "augu" täiendava Ingesteri käitamiseks.
Neljapäeval, 18. juulil võtsime oma klastritesse kasutusele neli uut prioriteetsuse taset: kriitiline, kõrge, keskmine и madal. Neid testiti umbes ühe nädala jooksul sisemises klastris ilma kliendiliikluseta. Vaikimisi võeti vastu ilma määratud prioriteedita kaustad keskmine prioriteet, klass määrati Ingesteritele koos kõrge prioriteet. Kriitiline oli reserveeritud jälgimiseks (Prometheus, Alertmanager, node-exporter, kube-state-metrics jne). Meie konfiguratsioon on avatud ja saate vaadata PR-i .
Krahhi
Reedel, 19. juulil käivitas üks inseneridest suurkliendi jaoks uue spetsiaalse Cortexi klastri. Selle klastri konfiguratsioon ei sisaldanud uusi kaustade prioriteete, seega määrati kõigile uutele kaustadele vaikeprioriteet - keskmine.
Kubernetese klastris ei olnud uue Cortexi klastri jaoks piisavalt ressursse ja olemasolevat Cortexi klastrit ei värskendatud (Ingesterid jäid ilma kõrge prioriteet). Kuna uue klastri Ingesteritel vaikimisi oli keskmine prioriteediks ja tootmises olevad kaunad töötasid üldse prioriteedita, asendasid uue klastri ingesterid olemasoleva Cortexi tootmisklastri Ingesterid.
Tootmisklastri väljatõstmise Ingesteri jaoks mõeldud ReplicaSet tuvastas väljatõstetud kausta ja lõi uue, et säilitada määratud arv koopiaid. Uus pod määrati vaikimisi keskmine prioriteet ja teine "vana" Ingester tootmises kaotas oma ressursid. Tulemuseks oli laviiniprotsess, mis tõi kaasa kõigi kaunade väljatõrjumise Ingesterist Cortexi tootmisklastrite jaoks.
Sisestajad on olekupõhised ja salvestavad andmeid viimase 12 tunni kohta. See võimaldab meil neid enne pikaajalisele salvestamisele kirjutamist tõhusamalt tihendada. Selle saavutamiseks jagab Cortex andmeid seeriate lõikes, kasutades hajutatud räsitabelit (DHT) ja kordab iga seeriat kolme ingesteri vahel, kasutades Dynamo-stiilis kvoorumi järjepidevust. Cortex ei kirjuta andmeid keelatud ingesteritele. Seega, kui suur hulk ingestreid lahkub DHT-st, ei suuda Cortex tagada kirjete piisavat replikatsiooni ja need jooksevad kokku.
Avastamine ja heastamine
Uued Prometheuse teated, mis põhinevad "veaeelarvel" (vea-eelarvepõhine — üksikasjad ilmuvad tulevases artiklis) hakkasid 4 minutit pärast seiskamise algust alarmi andma. Umbes järgmise viie minuti jooksul tegime diagnostikat ja suurendasime selle aluseks olevat Kubernetese klastrit, et majutada nii uusi kui ka olemasolevaid tootmisklastreid.
Veel viie minuti pärast kirjutasid vanad ingesterid edukalt oma andmed, uued käivitusid ja Cortexi klastrid said taas kättesaadavaks.
Veel 10 minutit kulutati Cortexi ees asuvate autentimise pöördpuhverserverite mälu puudumise (OOM) vigade diagnoosimisele ja parandamisele. OOM-i tõrkeid põhjustas QPS-i kümnekordne tõus (usume kliendi Prometheuse serverite liiga agressiivsete päringute tõttu).
Tagajärg
Kogu seisak oli 26 minutit. Andmeid ei kadunud. Ingesters on edukalt laadinud kõik mälus olevad andmed pikaajalisele salvestusruumile. Seiskamise ajal kustutati kliendi Prometheuse serverid puhverdatud (kaugjuhtimine) salvestisi kasutades põhineb WAL-il (autor Grafana Labsist) ja kordas pärast krahhi ebaõnnestunud kirjutisi.
Tootmisklastri kirjutamisoperatsioonid
Järeldused
Oluline on sellest juhtumist õppida ja võtta vajalikud meetmed, et vältida selle kordumist.
Tagantjärele mõeldes poleks me pidanud vaikeseadet määrama keskmine prioriteet, kuni kõik tootmises olevad Ingesterid on selle kätte saanud kõrge prioriteet. Lisaks oli vaja nende eest eelnevalt hoolt kanda kõrge prioriteet. Nüüd on kõik paika pandud. Loodame, et meie kogemused aitavad ka teisi organisatsioone, kes kaaluvad Kubernetesis pod-prioriteetide kasutamist.
Lisame täiendava kontrolli taseme kõigi täiendavate objektide juurutamise üle, mille konfiguratsioonid on klastris globaalsed. Edaspidi hakatakse selliseid muudatusi hindama bоrohkem inimesi. Lisaks peeti krahhi põhjustanud muudatust eraldi projektidokumendi jaoks liiga väikeseks – seda arutati ainult GitHubi numbris. Nüüdsest on kõikide selliste konfiguratsioonide muudatustega kaasas asjakohane projektidokumentatsioon.
Lõpuks automatiseerime autentimise pöördpuhverserveri suuruse muutmise, et vältida OOM-i ülekoormust, mille tunnistajaks oleme, ning vaatame üle Prometheuse vaikesätted, mis on seotud tagavara ja skaleerimisega, et vältida sarnaseid probleeme tulevikus.
Rikkel olid ka mõned positiivsed tagajärjed: pärast vajalike ressursside saamist taastus Cortex automaatselt ilma täiendava sekkumiseta. Samuti saime väärtuslikku kogemust koos töötades - meie uus palkide koondamise süsteem, mis aitas tagada, et kõik Ingesterid käitusid rikke ajal ja pärast seda õigesti.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com