Vienetas 6 / 11

Stebėjimas ir stebėjimas: metrinės, žurnalo, sekimo ir aliarmo taisyklės

Pelnas:

  • Gebėjimas suprasti tris stebėjimo ramsčius (metriką, žurnalą, sekimą) ir keturis auksinius signalus bei dirbtinį intelektą generuoti PromQL užklausas, aliarmo taisykles ir prietaisų skydelius.
  • Galimybė išvengti aliarmo nuovargio, palaikant signalus orientuotus į veiksmą ir tinkamo skubumo bei tikrinant slenksčius pagal jūsų sistemos istorinius duomenis
  • Galimybė užkirsti kelią privatumui ir slaptam nutekėjimui užmaskuojant jautrias vietas prieš atiduodant rąstus dirbtiniam intelektui

Nors gali atrodyti, kad sistema veikia, ji gali miršta viduje: atmintis lėtai pildosi, atsako laikas didėja, klaidų dažnis didėja. Vienintelis būdas tai pastebėti – nuolat stebėti sistemą. Pažangesnė koncepcija yra stebimumas: galimybė suprasti, kas vyksta sistemos viduje, žiūrint į jos išorinius požymius. Yra trys stebėjimo ramsčiai, o „DevOps“ profesionalas naudoja visus tris:

  • Metrika: skaitinės vertės, išmatuotos laikui bėgant – procesoriaus naudojimas, užklausų skaičius, atsako laikas, klaidų dažnis. — Kiek? atsako į klausimą.
  • Žurnalas: sistemos sukurti tekstiniai įvykių įrašai – „vartotojas prisijungė“, „nutrūko duomenų bazės ryšys“. – Kas tiksliai atsitiko? atsako į klausimą.
  • Sekimas: kelias, kuriuo užklausa eina pereinant iš paslaugos į paslaugą sistemoje, ir kiekvieno veiksmo trukmė. "Kur tas lėtumas?" atsako į klausimą.

Dažniausi įrankiai: Prometheus metrikai, Grafana vizualizacijai, Loki/ELK žurnalui, Jaeger/OpenTelemetry sekimui. AI yra labai įgudęs rašyti šių įrankių užklausų kalbas (ypač Prometheus PromQL), aliarmo taisykles ir prietaisų skydelio konfigūracijas. Čia taip pat yra stipriausias dirbtinis intelektas: apibendrina didelius žurnalų ir metrikų gabalus ir pažymi anomalijas.

Paaiškinkime skirtumą tarp stebėjimo ir stebimumo vienu sakiniu: stebėjimas – tai jums jau žinomų klausimų uždavimas („Ar CPU viršijo 90%?“); Stebimumas – tai galimybė užduoti klausimus, kurių dar nežinojote ("kodėl šis keistas lėtumas vyksta tik tam tikram klientui tam tikru metu?"). Šiuolaikinės sistemos yra tokios sudėtingos, kad negalite numatyti visų gedimų būdų; Todėl galimybė rinkti išsamią metriką, žurnalus ir pėdsakus, o tada atlikti jų išsamią užklausą, ty stebėti, tampa labai svarbi. Čia AI pradeda veikti atsakant į „anksčiau nežinomą klausimą“: jis greitai nuskaito jūsų turimus neapdorotus duomenis, pasiūlo modelius ir anomalijas ir, patikrinęs šiuos patarimus, pasieksite pagrindinę priežastį.

Žingsnis po žingsnio: ką ir kaip stebėti?

  1. Pasirinkite tinkamą metriką. Pramonėje remiamasi „keturiais auksiniais signalais“: delsa, srautu, klaidomis, prisotinimu – kiek išteklių pilna. Tai apibendrina daugelio paslaugų būklę.
  2. Surinkite metrikas. Tegul programa pateikia galutinį tašką, kurį Prometėjas gali perskaityti.
  3. Nustatykite prietaisų skydelius. Vizualizuokite šias metrikas Grafana.
  4. Parašykite signalizacijos taisykles. Kas ir kaip bus įspėtas viršijus ribą?
  5. Centralizuoti žurnalus. Padarykite visų paslaugų žurnalų paiešką vienoje vietoje.
  6. Sumažinti triukšmą. Per daug aliarmo sukelia „budrų nuovargį“; Svarbus signalas dingsta.
Patarimas: geras pavojaus signalas atitinka du dalykus: jis yra tinkamas veikti ir turi reikiamą skubumą. Žadintuvas, pažadinantis ką nors 3 val. ryto, turi būti kažkas, dėl kurio iš tikrųjų reikia įsikišti naktį. Nežadinkite nieko dėl to, kas nereikalauja savarankiškų veiksmų, pavyzdžiui, „CPU 70%“; parodyti jį lentoje.

Kaip parašyti aliarmo taisyklę?

Įspėjimas susideda iš trijų komponentų: būklės (kuri metrika viršija kurią slenkstį ir kiek laiko), trukmės („5 minutes“, kad nesukeltų momentinių svyravimų) ir svarbos / veiksmo (kam, kuriuo kanalu). AI meistriškai nustato šiuos tris tinkamus kontekstus. Pavyzdžiui, taisyklę, pvz., „kritinis pavojaus signalas, jei klaidų dažnis viršija 5 % 5 minutes“ išversti į PromQL, dirbtinio intelekto užduotis yra sekundės dalis, tačiau jūs nusprendžiate, ar slenkstis tinka jūsų sistemai.

Atsargiai: AI siūlomi pavojaus slenksčiai yra bendros prielaidos. Jūsų sistemos įprasta apkrova, tolerancija ir darbo poveikis skiriasi. Prieš nustatydami slenkstį tiesiai į gaminį, peržiūrėkite savo istorinius duomenis ir paklausite „kiek kartų šis slenkstis buvo suaktyvintas praeityje, kiek iš jų buvo tikros problemos? Atsakykite į klausimą.

Žurnalo privatumas: kritinis įspėjimas

Rąstai yra dažniausiai nepastebimas nuotėkio šaltinis. Žurnalo eilutėje netyčia gali būti slaptažodis, kredito kortelės numeris arba asmens duomenys (pagal KVKK/GDPR). Įklijuojant žurnalus į AI analizei:

  1. Užmaskuokite jautrias vietas. Pakeiskite tokias reikšmes kaip prieigos raktas, slaptažodis, el. pašto adresas, ID numeris <REDACTED>.
  2. Pateikite pavyzdžių, o ne visus. Vietoj milijono eilučių dažnai pakanka kelių šimtų reprezentatyvių eilučių.
  3. Pasirinkite institucijos patvirtintą transporto priemonę. Ypač gamybos žurnalams naudokite įrankį, kurio duomenys nepatenka į mokymą.

Keturi auksiniai signalai ir pavojaus lentelės

signalas

matuojamas pagal

Pavojaus slenksčio pavyzdys

skubumas

delsos laikas

atsako laikas

p95 > 800 ms, 5 min

aukštas

eismo

Užklausa/sek

Staigus 300% padidėjimas/sumažėjimas

vidutinis

Klaida

Nepavykusių užklausų rodiklis

> 5%, 5 min

kritiškas

Sodrumas

išteklių užimtumas

Diskas > 85 %

aukštas

trys mini dėklai

1 atvejis – 400 žurnalo eilučių apibendrinta per 30 sekundžių. Paslauga sulėtėjo. Inžinierius AI davė užmaskuotą 400 žurnalo eilučių ir pasakė: „Apibendrinkite pasikartojančius klaidų modelius ir laiko intensyvumą“. AI parodė, kad konkretus išorinis API skambutis baigiasi kas 30 sekundžių. Pagrindinė priežastis rasta per 30 sekundžių; Žurnalų nuskaitymas rankiniu būdu užtruktų pusvalandį.

2 atvejis – aliarmo nuovargis išspręstas. Viena komanda gaudavo 200 pavojaus signalų per dieną ir nekreipdavo dėmesio į juos, kol nebuvo pastebėtas tikras signalas apie gedimą. Suteikite AI visas įspėjimo taisykles ir paklauskite „kurios iš jų nėra veiksmingos ir kurias galima derinti? jie paklausė. Pavojaus signalų skaičius sumažėjo iki 12 per dieną; Į kiekvieną pavojaus signalą dabar buvo žiūrima rimtai.

3 atvejis – anksti pastebėta neteisinga riba. YZ diskui pasiūlė „Įspėti, kai pilna 95 proc.“. Inžinierius pažvelgė į istorinius duomenis: kai diskas pasiekė 95%, buvo mažai laiko įsikišti. Jis sumažino slenkstį iki 80% ir pridėjo antrą pavojaus signalą, pagrįstą „augimo tempu“. Patvirtinimas užkirto kelią faktiniam vidurnakčio sutrikimui.

Keturi kopijuojami šablonai

1) Žurnalo suvestinė (užmaskuota):

Išanalizuokite toliau pateiktą žurnalo pavyzdį (aš užmaskavau jautrias reikšmes su <REDACTED>). Pateikite man: (1) pasikartojančius klaidų modelius, (2) koncentraciją laikui bėgant, (3) labiausiai tikėtiną pagrindinę priežastį ir (4) 3 metrikas, kurias peržiūrėsiu, kad patikrinčiau. Žurnalas: [LINES]

2) Signalizacijos taisyklių generavimas:

Parašykite „Prometheus“ / „Alertmanager“ aliarmo taisyklę: sugeneruokite [SEVERITY] signalą, jei [THRESHOLD] viršija [METRIC][TRUKMĖ]. Taisyklė turėtų būti orientuota į veiksmą ir apimti anotacijos bei runbook nuorodos lauką. Paaiškinkite PromQL ir parašykite, kodėl ši riba yra pagrįsta.

3) PromQL užklausos rašymas / deklaravimas:

Parašykite PromQL užklausą, kuri matuotų: [EX. 5xxklaidų procentas per paskutines 5 minutes]. Žingsnis po žingsnio paaiškinkite užklausą. Tada pasakykite man, koks turėtų būti šios vertės sveikas diapazonas.

4) Prietaisų skydelio dizainas:

Sukurkite „Grafana“ prietaisų skydelį, skirtą [SERVICE]: kuriuose skydeliuose turėčiau rodyti keturis auksinius signalus (delsą, srautą, klaidą, sodrumą)? Pasiūlykite kiekvieno skydelio metriką, vizualizacijos tipą ir pagrįstą slenkstį. Tikslas: per 10 sekundžių pamatyti sargo sveikatos būklę.

Silpnas raginimas / Stiprus raginimas

Silpnas: "Kas tame žurnale?" (po to seka 5000 žalio rąsto eilučių, jame yra žetonų)

Rezultatas: nutekinate paslaptis ir AI pateikia netikslingą, paviršutinišką santrauką.

Stiprus: „Raskite pasikartojančius klaidų modelius ir laiko intensyvumą toliau pateiktame 300 eilučių užmaskuoto žurnalo pavyzdyje; nurodykite labiausiai tikėtiną pagrindinę priežastį ir metriką, kurią peržiūrėsiu, kad patikrinčiau. Sukūriau prieigos raktus <REDACTED>“.

Skirtumas: antrasis raginimas pateikia užmaskuotą ir sutelktą pavyzdį, kuriame prašoma aiškios analizės išvesties; Tai ir saugu, ir naudinga.

Dažnos klaidos

  • Žurnalo įklijavimas į AI jo neužmaskuojant. Dažniausias paslapčių/asmens duomenų nutekėjimas.
  • Žadintuvų nustatymas viskam. Signalizacijos nuovargis slepia tikrą nerimą.
  • Neveikiantis signalas. Tai įspėjamasis triukšmas, dėl kurio niekas nieko negali padaryti.
  • Sutikti su AI slenksčiu be jokių klausimų. Slenkstis turėtų būti nustatytas pagal jūsų sistemos istoriją.
  • Tiesiog žiūri į metriką. Be žurnalo ir pėdsakų dažniausiai nepavyksta rasti pagrindinės priežasties.
  • Nenustato žadintuvo laiko (for). Momentiniai svyravimai sukelia klaidingus pavojaus signalus.

Apibendrinant

Stebimumas; Tai galimybė suprasti sistemos vidų iš išorės naudojant metrikas, žurnalus ir pėdsakus. Keturi auksiniai signalai (delsavimas, srautas, klaida, prisotinimas) apibendrina daugumos paslaugų būklę. AI yra labai galingas rašant PromQL užklausas, aliarmo taisykles ir prietaisų skydelius, apibendrinant didelius žurnalų gabalus ir aptinkant anomalijas. Tačiau jūs esate atsakingi už pavojaus signalų slenksčių patikrinimą pagal savo sistemos istoriją, pavojaus signalus nukreipdami į veiksmą ir niekada nebendrinkite žurnalų jų nepaslėpdami.

Taikymo užduotis

Paslaugai (arba pavyzdinei paslaugai): (1) sugeneruokite klaidų dažnio aliarmo taisyklę naudodami šabloną „Signalumo taisyklės generavimas“ ir nustatykite siūlomą slenkstį į „kiek kartų ji buvo suaktyvinta praeityje? Išbandykite tai su klausimu; (2) užmaskuokite turimą žurnalo pavyzdį ir padėkite jį išanalizuoti naudodami šabloną „Žurnalo suvestinė“; (3) atkreipkite dėmesį, į kurią metriką žiūrėsite, kad patvirtintumėte labiausiai tikėtiną pagrindinę priežastį.

kontrolinis sąrašas

  • [ ] Metriką sekti pasirinkau remdamasis keturiais auksiniais signalais.
  • [ ] Užmaskavau visus rąstus, kuriuos daviau dirbtiniam intelektui jautriose srityse.
  • [ ] Patikrinau, ar kiekvienas pavojaus signalas buvo nukreiptas į veiksmą ir yra tinkamo skubumo.
  • [ ] Išbandžiau aliarmo slenksčius pagal savo sistemos istorinius duomenis.
  • [ ] Išfiltravau momentinius svyravimus, pridėdamas (trukmė) prie aliarmų.
  • [ ] Naudojau metriką + žurnalą + pėdsaką kartu kaip pagrindinę priežastį.