Dobički:
- Sposobnost razumevanja treh stebrov opazljivosti (metrika, dnevnik, sledenje) in štirih zlatih signalov ter ustvarjanje poizvedb PromQL, pravil alarmov in nadzornih plošč z umetno inteligenco
- Sposobnost preprečevanja utrujenosti alarmov z ohranjanjem usmerjenosti alarmov v akcijo in ob pravi nujnosti ter testiranjem pragov glede na zgodovinske podatke vašega sistema
- Sposobnost preprečevanja uhajanja zasebnosti in skrivnosti s prikrivanjem občutljivih območij, preden dnevnike predate umetni inteligenci
Čeprav se morda zdi, da sistem deluje, lahko znotraj umira: pomnilnik se počasi polni, odzivni časi se podaljšujejo, stopnja napak narašča. Edini način, da to opazite, je nenehno spremljanje sistema. Naprednejši koncept je opazljivost: sposobnost razumeti, kaj se dogaja znotraj sistema, tako da pogledamo njegove zunanje znake. Obstajajo trije stebri opazljivosti in strokovnjak za DevOps uporablja vse tri:
- Metrika: Številske vrednosti, izmerjene skozi čas — uporaba procesorja, število zahtev, odzivni čas, stopnja napak. "Koliko?" odgovarja na vprašanje.
- Dnevnik: Besedilni zapisi dogodkov, ki jih ustvari sistem—"uporabnik prijavljen", "prekinjena povezava z bazo podatkov". "Kaj točno se je zgodilo?" odgovarja na vprašanje.
- Trace: pot, ki ji sledi zahteva med prehodom od storitve do storitve znotraj sistema in trajanje vsakega koraka. "Kje je počasnost?" odgovarja na vprašanje.
Najpogostejša orodja: Prometheus za metriko, Grafana za vizualizacijo, Loki/ELK za dnevnik, Jaeger/OpenTelemetry za sledenje. AI je zelo spreten pri pisanju poizvedovalnih jezikov (zlasti Prometheusov PromQL), alarmnih pravil in konfiguracij nadzorne plošče za ta orodja. Tu je tudi AI najmočnejši: povzemanje velikih kosov dnevnikov in meritev ter označevanje nepravilnosti.
Razjasnimo razliko med spremljanjem in opazljivostjo v enem stavku: spremljanje je zastavljanje vprašanj, ki jih že poznate (»Ali je procesor presegel 90 %?«); opazljivost je zmožnost postavljanja vprašanj, ki jih še niste vedeli ("zakaj se ta čudna počasnost dogaja samo določeni stranki ob določenem času?"). Sodobni sistemi so tako zapleteni, da ne morete predvideti vseh načinov okvare; Zato postane zmožnost zbiranja bogatih meritev, dnevnikov in sledi ter nato poglobljenega poizvedovanja po njih – to je opazljivost – kritična. Tu nastopi umetna inteligenca pri odgovoru na "prej neznano vprašanje": hitro pregleda neobdelane podatke, ki jih imate, predlaga vzorce in anomalije, vi pa s preverjanjem teh namigov pridete do temeljnega vzroka.
Korak za korakom: kaj in kako spremljati?
- Izberite prave meritve. V industriji se za osnovo vzamejo "štirje zlati signali": zakasnitev, promet, napake, nasičenost - kako poln je vir. Ti povzemajo zdravje večine storitev.
- Zbirajte meritve. Naj aplikacija predstavi končno točko, ki jo Prometheus lahko prebere.
- Nastavite nadzorne plošče. Vizualizirajte te meritve v Grafani.
- Napišite pravila alarma. Kdo bo opozorjen, ko bo prag presežen in kako?
- Centralizirajte dnevnike. Omogočite iskanje po vseh dnevnikih storitev na enem mestu.
- Zmanjšajte hrup. Preveč alarma povzroči "utrujenost zaradi alarma"; Pomemben alarm izgine.
Nasvet: Dober alarm izpolnjuje dve stvari: je izvedljiv in ima pravo nujnost. Alarm, ki nekoga zbudi ob 3. uri zjutraj, mora biti nekaj, kar dejansko zahteva nočno posredovanje. Nikogar ne zbudite zaradi nečesa, kar samo po sebi ne zahteva ukrepanja, na primer "CPU 70 %"; prikažete na tabli.
Kako napisati pravilo alarma?
Opozorilo je sestavljeno iz treh komponent: pogoja (katera metrika presega kateri prag in za koliko časa), trajanja (»za 5 minut«, da se izognete sprožitvi trenutnih nihanj) in pomembnosti/dejanja (za koga, prek katerega kanala). AI mojstrsko vzpostavi te tri s pravim kontekstom. Na primer, prevajanje pravila, kot je »kritičen alarm, če stopnja napake preseže 5 % za 5 minut« v PromQL, je naloga umetne inteligence v delčku sekunde — vendar se sami odločite, ali je prag primeren za vaš sistem.
Pozor: Mejne vrednosti alarma, ki jih predlaga umetna inteligenca, so splošne predpostavke. Običajna obremenitev, toleranca in delovni vpliv vašega sistema so drugačni. Preden postavite prag neposredno v prod, pogledate svoje zgodovinske podatke in vprašate, "kolikokrat je bil ta prag sprožen v preteklosti, koliko od tega so bile resnične težave?" Odgovorite na vprašanje.
Zasebnost dnevnika: kritično opozorilo
Dnevniki so najpogosteje spregledan vir puščanja. Dnevniška vrstica lahko pomotoma vsebuje geslo, številko kreditne kartice ali osebne podatke (po KVKK/GDPR). Pri lepljenju dnevnikov v AI za analizo:
- Zakrijte občutljive predele. Zamenjajte vrednosti, kot so žeton, geslo, e-pošta, ID številka z <REDIGOVANO>.
- Navedite primere, ne vseh. Namesto milijon vrstic je pogosto dovolj nekaj sto reprezentativnih vrstic.
- Izberite vozilo, ki ga odobri institucija. Zlasti za proizvodne dnevnike uporabite orodje, katerega podatki ne gredo v usposabljanje.
Štiri zlate mize za signale in alarme
signal
merjeno z
Primer alarmnega praga
nujnost
zakasnitev
odzivni čas
p95 > 800 ms, 5 min
visoka
prometa
Zahteva/sek
Nenadno povečanje/zmanjšanje za 300 %
srednje
Napaka
Stopnja neuspelih zahtev
> 5%, 5 min
kritičen
Nasičenost
zasedenost virov
Disk > 85 %
visoka
trije mini kovčki
Primer 1 — 400 vrstic dnevnika, povzetih v 30 sekundah. Storitev se je upočasnila. Inženir je umetni inteligenci dal maskiranih 400 vrstic dnevnika in rekel, "povzemite ponavljajoče se vzorce napak in časovno intenzivnost." Umetna inteligenca je pokazala, da določen zunanji klic API-ja poteče vsakih 30 sekund. Glavni vzrok najdemo v 30 sekundah; Ročno skeniranje dnevnikov bi trajalo pol ure.
Primer 2 – utrujenost alarma rešena. Ena ekipa je prejemala 200 alarmov na dan in jih je vse ignorirala – dokler ni spregledal tudi pravi alarm zaradi izpada. Dajte AI vsa opozorilna pravila in vprašajte, "katera niso izvedljiva in katera je mogoče kombinirati?" so vprašali. Število alarmov se je zmanjšalo na 12 na dan; Vsak alarm so zdaj jemali resno.
Primer 3 — zgodaj ujet napačen prag. YZ je predlagal "Opozori, ko je 95% poln" za disk. Inženir je pogledal zgodovinske podatke: ko je disk dosegel 95 %, je bilo malo časa za poseg. Znižal je prag na 80 % in dodal drugi alarm na podlagi »stopnje rasti«. Preverjanje je preprečilo dejanski opolnočni izpad.
Štiri predloge za kopiranje
1) Povzetek dnevnika (zamaskiran):
Analizirajte spodnji primer dnevnika (občutljive vrednosti sem prikril z <REDIGOVANO>). Povejte mi: (1) vzorce ponavljajočih se napak, (2) koncentracijo skozi čas, (3) najverjetnejši temeljni vzrok in (4) 3 meritve, ki jih bom preveril. Dnevnik: [LINES]
2) Generiranje pravila alarma:
Napišite pravilo alarma za Prometheus/Alertmanager: Ustvari alarm [SEVERITY], če [THRESHOLD] preseže [METRIC][DURATION]. Pravilo mora biti usmerjeno k dejanjem in mora vključevati opombo in polje povezave runbook. Razložite PromQL in napišite, zakaj je ta prag razumen.
3) Pisanje/deklariranje poizvedbe PromQL:
Napišite poizvedbo PromQL, ki meri: [EX. 5xx odstotek stopnje napak v zadnjih 5 minutah]. Razložite poizvedbo korak za korakom. Potem mi povejte, kakšen bi moral biti zdrav razpon za to vrednost.
4) Oblikovanje armaturne plošče:
Oblikujte nadzorno ploščo Grafana za [STORITEV]: s katerimi ploščami naj prikažem štiri zlate signale (zakasnitev, promet, napaka, nasičenost)? Predlagajte meritev, vrsto vizualizacije in razumen prag za vsako ploščo. Namen: v 10 sekundah videti zdravstveno stanje paznika.
Šibek poziv/močan poziv
Slab: "Kaj je v tem dnevniku?" (sledi 5000 vrstic neobdelanega dnevnika, žetoni v njem)
Rezultat: izdate skrivnosti in umetna inteligenca poda neciljan, površen povzetek.
Močno: "Poiščite ponavljajoče se vzorce napak in časovno intenzivnost v spodnjem primeru 300-vrstičnega maskiranega dnevnika; povejte mi najverjetnejši glavni vzrok in meritve, ki jih bom preučil, da preverim. Žetone sem naredil <REDIGIRANO>."
Razlika: drugi poziv daje prikrit in osredotočen primer, ki zahteva jasen rezultat analize; Je hkrati varen in uporaben.
Pogoste napake
- Lepljenje dnevnika v AI brez maskiranja. Najpogostejše uhajanje skrivnosti/osebnih podatkov.
- Nastavitev alarmov za vse. Utrujenost od alarma pokoplje pravi alarm.
- Nedejavni alarm. To je opozorilni hrup, ki mu nihče ne more nič.
- Sprejemanje praga AI brez vprašanj. Mejno vrednost je treba nastaviti glede na zgodovino vašega sistema.
- Samo gledam metriko. Brez dnevnika in sledenja vzroka večino časa ni mogoče najti.
- Nenastavitev časa alarma (za). Trenutna nihanja povzročajo lažne alarme.
Če povzamem
Opazljivost; Je zmožnost razumevanja notranjosti sistema od zunaj z metrikami, dnevniki in sledmi. Štirje zlati signali (zakasnitev, promet, napaka, nasičenost) povzemajo zdravje večine storitev. AI je zelo močan pri pisanju poizvedb PromQL, pravil za alarme in nadzornih plošč ter pri povzemanju velikih kosov dnevnikov in iskanju anomalij. Toda vaša odgovornost je, da preverite pragove alarmov glede na zgodovino svojega sistema, poskrbite, da so alarmi usmerjeni k ukrepanju, in nikoli ne delite dnevnikov, ne da bi jih prikrili.
Aplikacijska naloga
Za storitev (ali vzorčno storitev): (1) ustvarite pravilo alarma za stopnjo napake s predlogo »Generacija pravila alarma« in nastavite predlagani prag na »kolikokrat se je sprožilo v preteklosti?« Preizkusite z vprašanjem; (2) maskirajte vzorec dnevnika, ki ga imate, in ga dajte analizirati s predlogo »Povzetek dnevnika«; (3) zabeležite, katero meritev boste upoštevali, da potrdite najverjetnejši glavni vzrok.
kontrolni seznam
- [ ] Meritve za sledenje sem izbral na podlagi štirih zlatih signalov.
- [ ] Vse dnevnike, ki sem jih dal AI, sem prikril v smislu občutljivih področij.
- [ ] Preveril sem, da je bil vsak alarm usmerjen k ukrepanju in pravilno nujen.
- [ ] Mejne vrednosti alarma sem preizkusil glede na zgodovinske podatke svojega sistema.
- [ ] Trenutna nihanja sem filtriral tako, da sem alarmom dodal čas (trajanje).
- [] Uporabil sem metriko + dnevnik + sled skupaj za glavni vzrok.