Dobici:
- Sposobnost razumijevanja tri stuba opservabilnosti (metrički, log, trag) i četiri zlatna signala i da umjetna inteligencija generiše PromQL upite, pravila alarma i nadzorne ploče
- Sposobnost sprečavanja zamora od alarma održavanjem alarma orijentiranim na akciju i odgovarajućom hitnošću i testiranjem pragova prema historijskim podacima vašeg vlastitog sistema
- Sposobnost da se spriječi privatnost i tajno curenje maskiranjem osjetljivih područja prije nego što se zapisnici predaju umjetnoj inteligenciji
Iako se čini da sistem radi, možda umire iznutra: memorija se polako puni, vrijeme odziva se povećava, stopa grešaka raste. Jedini način da to primijetite je da stalno nadgledate sistem. Napredniji koncept je opservabilnost: sposobnost razumijevanja onoga što se dešava unutar sistema gledajući njegove vanjske znakove. Postoje tri stuba uočljivosti, a DevOps profesionalac koristi sva tri:
- Metrik: Numeričke vrijednosti mjerene tokom vremena — korištenje CPU-a, broj zahtjeva, vrijeme odgovora, stopa greške. "Koliko?" odgovara na pitanje.
- Dnevnik: Zapisi o tekstualnim događajima koje proizvodi sistem—„korisnik je prijavljen“, „veza sa bazom podataka je izgubljena“. "Šta se tačno dogodilo?" odgovara na pitanje.
- Praćenje: Put kojim zahtjev slijedi dok prelazi sa usluge na uslugu unutar sistema i trajanje svakog koraka. "Gdje je sporost?" odgovara na pitanje.
Najčešći alati: Prometheus za metriku, Grafana za vizualizaciju, Loki/ELK za log, Jaeger/OpenTelemetry za praćenje. AI je vrlo vješt u pisanju jezika upita (posebno Prometheusovog PromQL), pravila alarma i konfiguracija kontrolne ploče za ove alate. Tu je i AI najjača: sažimanje velikih komada dnevnika i metrika i označavanje anomalija.
Hajde da razjasnimo razliku između nadgledanja i uočljivosti u jednoj rečenici: nadgledanje je postavljanje pitanja koja već znate („Da li je CPU preko 90%?“); uočljivost je mogućnost postavljanja pitanja koja već niste znali („zašto se ova čudna sporost dešava samo određenom kupcu u određeno vrijeme?“). Moderni sistemi su toliko složeni da ne možete predvidjeti sve načine kvara; Stoga, sposobnost prikupljanja bogatih metričkih podataka, dnevnika i tragova, a zatim njihovo dubinski upitnik – odnosno vidljivost – postaje kritična. Ovdje AI dolazi u igru kada odgovara na "prethodno nepoznato pitanje": brzo skenira neobrađene podatke koje imate, predlaže obrasce i anomalije, a vi dolazite do temeljnog uzroka provjeravanjem ovih tragova.
Korak po korak: šta i kako pratiti?
- Odaberite prave metrike. U industriji se kao osnova uzimaju "četiri zlatna signala": kašnjenje, promet, greške, zasićenje - koliko je resurs pun. Oni sažimaju zdravlje većine usluga.
- Prikupite metriku. Neka aplikacija predstavlja krajnju tačku koju Prometheus može čitati.
- Postavite kontrolne table. Vizualizirajte ove metrike u Grafani.
- Napišite pravila za alarm. Ko će biti upozoren kada je prag prekoračen i kako?
- Centralizirajte dnevnike. Omogućite pretraživanje svih servisnih dnevnika na jednom mjestu.
- Smanjite buku. Previše alarma stvara „umor alarma“; Važan alarm nestaje.
Savjet: Dobar alarm ispunjava dvije stvari: djelotvoran je i ima pravu hitnost. Alarm koji budi nekoga u 3 ujutro mora biti nešto što zapravo zahtijeva noćnu intervenciju. Nemojte nikoga buditi zbog nečega što ne zahtijeva samo djelovanje, kao što je "CPU 70%"; prikazati na tabli.
Kako napisati pravilo alarma?
Upozorenje se sastoji od tri komponente: stanja (koji pokazatelj prelazi koji prag i koliko dugo), trajanja („za 5 minuta“ kako bi se izbjegle trenutne fluktuacije) i važnosti/radnje (kome, kroz koji kanal). AI majstorski uspostavlja ova tri s pravim kontekstom. Na primjer, prevođenje pravila poput „kritičnog alarma ako stopa greške prelazi 5% za 5 minuta“ u PromQL je zadatak u djeliću sekunde za AI – ali vi odlučujete da li je prag ispravan za vaš sistem.
Oprez: Pragovi alarma koje predlaže AI su opšte pretpostavke. Normalno opterećenje vašeg sistema, tolerancija i radni uticaj su različiti. Prije nego što postavite prag direktno u prod, pogledate svoje istorijske podatke i pitate "koliko je puta ovaj prag bio aktiviran u prošlosti, koliko su to bili stvarni problemi?" Odgovori na pitanje.
Privatnost dnevnika: kritično upozorenje
Trupci su izvor curenja koji se najčešće zanemaruje. Linija dnevnika može slučajno sadržavati lozinku, broj kreditne kartice ili lične podatke (prema KVKK/GDPR). Prilikom lijepljenja prijava u AI radi analize:
- Maskirati osetljiva područja. Zamijenite vrijednosti kao što su token, lozinka, e-pošta, ID broj sa <REDIGOVANO>.
- Navedite primjere, ne sve. Umjesto milion linija, često je dovoljno nekoliko stotina reprezentativnih linija.
- Odaberite vozilo koje je odobrila institucija. Posebno za dnevnike proizvodnje koristite alat čiji podaci ne idu u obuku.
Četiri zlatna signala i tablice alarma
signal
mereno po
Primjer praga alarma
hitnost
latencija
vrijeme odgovora
p95 > 800 ms, 5 min
visoko
saobraćaja
Zahtjev/sek
Iznenadno povećanje/smanjenje od 300%.
srednje
Greška
Stopa neuspjelog zahtjeva
> 5%, 5 min
kritičan
Saturation
popunjenost resursa
Disk > 85%
visoko
tri mini kofera
Slučaj 1 — 400 redova dnevnika sažetih u 30 sekundi. Usluga je usporila. Inženjer je dao maskiranih 400 linija dnevnika AI-u i rekao, "sažmite ponavljajuće obrasce grešaka i vremenski intenzitet." AI je pokazao da određeni eksterni API poziv istekne svakih 30 sekundi. Osnovni uzrok pronađen za 30 sekundi; Ručno skeniranje dnevnika trajalo bi pola sata.
Slučaj 2 — riješen umor alarma. Jedan tim je primao 200 alarma dnevno i sve ih je ignorirao - sve dok se nije previdio i pravi alarm za prekid rada. Dajte AI sva pravila upozorenja i pitajte "koja od njih nisu djelotvorna i koja se mogu kombinirati?" pitali su. Broj alarma je smanjen na 12 dnevno; Svaki alarm je sada shvaćen ozbiljno.
Slučaj 3 — pogrešan prag je rano uhvaćen. YZ je predložio "Upozori kada je 95% pun" za disk. Inženjer je pogledao istorijske podatke: kada je disk dostigao 95% bilo je malo vremena za intervenciju. Snizio je prag na 80% i dodao drugi alarm na osnovu "stope rasta". Provjera je spriječila stvarni ponoćni prekid rada.
Četiri šablona za kopiranje
1) Sažetak dnevnika (maskiran):
Analizirajte donji primjer dnevnika (maskirao sam osjetljive vrijednosti sa <REDIGOVANO>). Dajte mi: (1) ponavljajuće obrasce grešaka, (2) koncentraciju tokom vremena, (3) najvjerovatniji osnovni uzrok i (4) 3 metrike koje ću pogledati da provjerim. Dnevnik: [LINES]
2) Generisanje pravila alarma:
Napišite pravilo alarma za Prometheus/Alertmanager: Generirajte [SEVERITY] alarm ako [THRESHOLD] premašuje [METRIC][DURATION]. Pravilo bi trebalo da bude orijentisano na radnju i uključuje polje za belešku i vezu runbooka. Objasnite PromQL i napišite zašto je ovaj prag razuman.
3) Pisanje/deklarisanje PromQL upita:
Napišite PromQL upit koji mjeri: [EX. 5xxerror rate postotak u posljednjih 5 minuta]. Objasnite upit korak po korak. Onda mi recite koji bi trebao biti zdrav raspon za ovu vrijednost.
4) Dizajn kontrolne table:
Dizajnirajte Grafana kontrolnu tablu za [SERVIS]: s kojim panelima trebam prikazati četiri zlatna signala (latencija, promet, greška, zasićenost)? Predložite metriku, vrstu vizualizacije i razumni prag za svaki panel. Svrha: vidjeti zdravstveno stanje čuvara za 10 sekundi.
Slaba prompt / Jaka prompt
Slab: "Šta je u tom dnevniku?" (prati 5000 redova neobrađenog dnevnika, tokeni u njemu)
Rezultat: odajete tajne, a AI daje neciljani, površan sažetak.
Snažno: "Pronađite ponavljajuće obrasce grešaka i intenzitet vremena u primjeru maskiranog dnevnika od 300 redova ispod; recite mi najvjerovatniji osnovni uzrok i metriku koju ću pogledati da provjerim. Napravio sam tokene <REDIGOVANO>."
Razlika: drugi prompt daje maskiran i fokusiran primjer, tražeći jasan izlaz analize; To je i sigurno i korisno.
Uobičajene greške
- Zalijepiti log u AI bez maskiranja. Najčešće curenje tajnih/ličnih podataka.
- Postavljanje alarma za sve. Umor od alarma sahranjuje pravi alarm.
- Neaktivan alarm. To je buka upozorenja kojoj niko ništa ne može.
- Prihvatanje praga AI bez pitanja. Prag bi trebao biti postavljen u skladu s historijom vašeg sistema.
- Samo gledam metriku. Bez evidencije i traga, glavni uzrok se većinu vremena ne može pronaći.
- Ne postavlja se vrijeme alarma (za). Trenutne fluktuacije proizvode lažne alarme.
Ukratko
Opservability; To je sposobnost razumijevanja unutrašnjosti sistema izvana pomoću metrike, evidencije i tragova. Četiri zlatna signala (latencija, promet, greška, zasićenost) sumiraju zdravlje većine usluga. AI je vrlo moćan u pisanju PromQL upita, pravila alarma i nadzornih ploča, te u sažimanju velikih komada dnevnika i pronalaženju anomalija. Ali vaša je odgovornost da provjerite pragove alarma u odnosu na historiju vašeg vlastitog sistema, držite alarme orijentiranim na akciju i nikada ne dijelite dnevnike bez maskiranja.
Zadatak aplikacije
Za uslugu (ili primjer usluge): (1) Neka se generiše pravilo alarma za stopu greške sa šablonom "Generacija pravila alarma" i postavite predloženi prag na "koliko puta se ono aktiviralo u prošlosti?" Testirajte ga pitanjem; (2) maskirajte uzorak dnevnika koji imate i dajte ga analizirati pomoću šablona "Rezime dnevnika"; (3) zabilježite koju metriku ćete pogledati kako biste potvrdili najvjerovatniji osnovni uzrok.
kontrolna lista
- [ ] Odabrao sam metriku za praćenje na osnovu četiri zlatna signala.
- [ ] Sve zapise koje sam dao AI maskirao sam u smislu osjetljivih područja.
- [ ] Provjerio sam da je svaki alarm usmjeren na akciju i da je hitan.
- [ ] Testirao sam pragove alarma u odnosu na historijske podatke mog sistema.
- [ ] Filtrirao sam trenutne fluktuacije dodajući za (trajanje) alarmima.
- [ ] Koristio sam metric + log + trace zajedno za osnovni uzrok.