Ieguvumi:
- Spēja izprast trīs novērojamības pīlārus (metriska, žurnāls, izsekošana) un četrus zelta signālus, un mākslīgais intelekts ģenerē PromQL vaicājumus, trauksmes noteikumus un informācijas paneļus.
- Spēja novērst trauksmes nogurumu, saglabājot trauksmes signālus, kas vērsti uz darbību un ar pareizo steidzamību, un pārbaudot sliekšņus, salīdzinot ar jūsu sistēmas vēsturiskajiem datiem
- Spēja novērst privātumu un slepenu noplūdi, maskējot jutīgās zonas pirms baļķu nodošanas mākslīgajam intelektam
Lai gan šķiet, ka sistēma darbojas, tā var iet bojā: atmiņa lēnām piepildās, reakcijas laiks palielinās, kļūdu līmenis palielinās. Vienīgais veids, kā to pamanīt, ir pastāvīgi uzraudzīt sistēmu. Uzlabotāks jēdziens ir novērojamība: spēja saprast, kas notiek sistēmā, aplūkojot tās ārējās pazīmes. Ir trīs novērojamības pīlāri, un DevOps profesionālis izmanto visus trīs:
- Metrika: laika gaitā izmērītas skaitliskās vērtības — CPU lietojums, pieprasījumu skaits, atbildes laiks, kļūdu līmenis. "Cik daudz?" atbild uz jautājumu.
- Žurnāls: sistēmas izveidotie teksta notikumu ieraksti — "lietotājs pieteicies", "zaudēts datu bāzes savienojums". "Kas tieši notika?" atbild uz jautājumu.
- Izsekošana: ceļš, kas seko pieprasījumam, pārejot no pakalpojuma uz pakalpojumu sistēmā, un katras darbības ilgums. "Kur ir lēnums?" atbild uz jautājumu.
Visizplatītākie rīki: Prometheus metrikai, Grafana vizualizācijai, Loki/ELK žurnālam, Jaeger/OpenTelemetry izsekošanai. AI ir ļoti prasmīgs šo rīku vaicājumu valodu (īpaši Prometheus PromQL), trauksmes noteikumu un informācijas paneļa konfigurāciju rakstīšanā. Šeit arī AI ir visspēcīgākais: apkopo lielus žurnālu un metrikas gabalus un atzīmē anomālijas.
Noskaidrosim atšķirību starp monitoringu un novērojamību vienā teikumā: uzraudzība ir jau zināmu jautājumu uzdošana (“Vai CPU pārsniedz 90%?”); novērojamība ir iespēja uzdot jautājumus, kurus jūs jau nezināt ("kāpēc šī dīvainā lēnība notiek tikai konkrētam klientam noteiktā laikā?"). Mūsdienu sistēmas ir tik sarežģītas, ka nevar paredzēt visus atteices veidus; Tāpēc iespēja apkopot bagātīgu metriku, žurnālus un pēdas un pēc tam veikt tos padziļinātu vaicājumu, tas ir, novērojamību, kļūst kritiska. Šeit darbojas AI, atbildot uz "iepriekš nezināmo jautājumu": tas ātri skenē jūsu rīcībā esošos neapstrādātos datus, ierosina modeļus un anomālijas, un, pārbaudot šīs norādes, jūs nonākat pie galvenā cēloņa.
Soli pa solim: ko un kā uzraudzīt?
- Izvēlieties pareizos rādītājus. Nozarē par pamatu tiek ņemti "četri zelta signāli": latentums, satiksme, kļūdas, piesātinājums — cik pilns ir resurss. Tie apkopo vairuma pakalpojumu stāvokli.
- Apkopojiet metriku. Ļaujiet lietojumprogrammai parādīt beigu punktu, ko Prometejs var nolasīt.
- Iestatiet informācijas paneļus. Vizualizējiet šos rādītājus programmā Grafana.
- Uzrakstiet trauksmes noteikumus. Kurš tiks brīdināts par sliekšņa pārsniegšanu un kā?
- Centralizēt žurnālus. Padariet visus pakalpojumu žurnālus meklējamus vienuviet.
- Samaziniet troksni. Pārāk daudz trauksmes rada "trauksmes nogurumu"; Svarīgais trauksmes signāls pazūd.
Padoms. Labs trauksmes signāls atbilst divām lietām: tas ir praktiski lietojams un tam ir pareiza steidzamība. Modinātājam, kas pamodina kādu pulksten 3:00, noteikti ir nepieciešama nakts iejaukšanās. Nemodiniet nevienu par kaut ko tādu, kas pats par sevi neprasa darbību, piemēram, "CPU 70%"; parādiet to uz tāfeles.
Kā uzrakstīt trauksmes noteikumu?
Brīdinājums sastāv no trim sastāvdaļām: nosacījums (kura metrika pārsniedz kuru slieksni un cik ilgi), ilgums (“uz 5 minūtēm”, lai izvairītos no īslaicīgu svārstību rašanās) un svarīguma/darbības (kam, caur kuru kanālu). AI meistarīgi izveido šos trīs ar pareizo kontekstu. Piemēram, tādas kārtulas kā “kritisks trauksmes signāls, ja kļūdu līmenis 5 minūtēs pārsniedz 5%” pārtulkošana uz PromQL ir sekundes daļa AI — taču jūs izlemjat, vai slieksnis ir piemērots jūsu sistēmai.
Uzmanību: AI ieteiktie trauksmes sliekšņi ir vispārīgi pieņēmumi. Jūsu sistēmas parastā slodze, tolerance un darba ietekme atšķiras. Pirms ievietojat slieksni tieši prod, apskatiet savus vēsturiskos datus un jautājiet: "cik reizes šis slieksnis ir ticis aktivizēts pagātnē, cik no tām bija reālas problēmas?" Atbildi uz jautājumu.
Žurnāla privātums: kritisks brīdinājums
Baļķi ir visbiežāk aizmirstais noplūžu avots. Žurnāla rindā nejauši var būt ietverta parole, kredītkartes numurs vai personas dati (saskaņā ar KVKK/GDPR). Ielīmējot žurnālus AI analīzei:
- Maskējiet jutīgās zonas. Aizstājiet tādas vērtības kā marķieris, parole, e-pasts, ID numurs ar <REDACTED>.
- Sniedziet piemērus, nevis visus. Miljona rindu vietā bieži vien pietiek ar dažiem simtiem reprezentatīvu rindu.
- Izvēlieties iestādes apstiprinātu transportlīdzekli. Īpaši ražošanas žurnāliem izmantojiet rīku, kura dati netiek izmantoti apmācībā.
Četri zelta signāli un trauksmes galdi
signāls
mēra ar
Trauksmes sliekšņa piemērs
steidzamība
latentums
reakcijas laiks
p95 > 800 ms, 5 min
augsts
satiksme
Pieprasījums/sek
Pēkšņs 300% pieaugums/samazinājums
vidējs
Kļūda
Neizdevušos pieprasījumu rādītājs
> 5%, 5 min
kritisks
Piesātinājums
resursu noslogojums
disks > 85%
augsts
trīs mini futrāļi
1. gadījums — 400 žurnāla rindiņas apkopotas 30 sekundēs. Pakalpojums bija palēninājies. Inženieris AI nodeva maskētās 400 žurnāla rindas un teica: "Apkopojiet atkārtoto kļūdu modeļus un laika intensitāti." AI parādīja, ka konkrētam ārējam API izsaukumam iestājas noildze ik pēc 30 sekundēm. Galvenais cēlonis atrasts 30 sekundēs; Manuāla žurnālu skenēšana aizņemtu pusstundu.
2. gadījums — trauksmes nogurums atrisināts. Viena komanda saņēma 200 trauksmes signālus dienā un ignorēja tos visus — līdz brīdim, kad netika ņemta vērā arī reāla avārijas trauksme. Sniedziet AI visus brīdinājuma noteikumus un jautājiet: "kurus no tiem nevar piemērot un kurus var apvienot?" viņi jautāja. Trauksmes signālu skaits samazinājies līdz 12 dienā; Katrs trauksmes signāls tagad tika uztverts nopietni.
3. gadījums — agri tika konstatēts nepareizs slieksnis. YZ ieteica diskam "Brīdināt, kad 95% pilna". Inženieris aplūkoja vēsturiskos datus: kad disks sasniedza 95%, iejaukšanās bija maz laika. Tas pazemināja slieksni līdz 80% un pievienoja otru trauksmi, pamatojoties uz “izaugsmes tempu”. Pārbaude novērsa faktisku pusnakts pārtraukumu.
Četras kopējamas veidnes
1) Žurnāla kopsavilkums (maskēts):
Analizējiet tālāk redzamo žurnāla piemēru (es maskēju sensitīvās vērtības ar <REDACTED>). Sniedziet man: (1) atkārtotus kļūdu modeļus, (2) koncentrēšanos laika gaitā, (3) visticamāko galveno cēloni un (4) 3 metriku, ko es apskatīšu, lai pārbaudītu. Žurnāls: [LINES]
2) Trauksmes noteikumu ģenerēšana:
Uzrakstiet Prometheus/Alertmanager trauksmes noteikumu: ģenerējiet [SEVERITY] trauksmi, ja [THRESHOLD] pārsniedz [METRIC][DURATION]. Noteikumam ir jābūt vērstam uz darbību un jāietver anotācijas un izpildgrāmatas saites lauks. Izskaidrojiet PromQL un uzrakstiet, kāpēc šis slieksnis ir saprātīgs.
3) PromQL vaicājuma rakstīšana/deklarēšana:
Uzrakstiet PromQL vaicājumu, kas mēra: [EX. 5xxxxxror rate procents pēdējo 5 minūšu laikā]. Soli pa solim izskaidrojiet vaicājumu. Pēc tam pastāstiet man, kādam jābūt šīs vērtības veselīgajam diapazonam.
4) Informācijas paneļa dizains:
Izveidojiet Grafana informācijas paneli pakalpojumam [SERVICE]: ar kādiem paneļiem man vajadzētu parādīt četrus zelta signālus (latenci, satiksmi, kļūdu, piesātinājumu)? Iesakiet metriku, vizualizācijas veidu un saprātīgu slieksni katram panelim. Mērķis: 10 sekundēs redzēt apsarga veselības stāvokli.
Vāja uzvedne / spēcīga uzvedne
Vājš: "Kas tajā žurnālā ir?" (kam seko 5000 rindiņas neapstrādāta baļķa ar žetoniem tajā)
Rezultāts: jūs nopludināt noslēpumus, un AI sniedz nemērķtiecīgu, virspusēju kopsavilkumu.
Spēcīgs: "Atrodiet atkārtotu kļūdu modeļus un laika intensitāti tālāk esošajā 300 rindiņu maskētā žurnāla piemērā; pastāstiet man visticamāko galveno cēloni un metriku, ko es apskatīšu, lai pārbaudītu. Es izveidoju marķierus <REDACTED>."
Atšķirība: otrā uzvedne sniedz maskētu un koncentrētu piemēru, pieprasot skaidru analīzes rezultātu; Tas ir gan drošs, gan noderīgs.
Biežas kļūdas
- Žurnāla ielīmēšana AI, to neslēpjot. Visizplatītākā noslēpuma/personas datu noplūde.
- Modinātāju iestatīšana visam. Trauksmes nogurums slēpj īstu trauksmi.
- Neiedarbināma trauksme. Tas ir brīdinājuma troksnis, ar kuru neviens neko nevar darīt.
- AI sliekšņa pieņemšana bez šaubām. Slieksnis ir jāiestata atbilstoši jūsu sistēmas vēsturei.
- Paskatoties tikai uz metriku. Bez žurnāla un pēdām galveno cēloni lielākoties nevar atrast.
- Nav iestatīts modinātāja laiks (par). Īslaicīgas svārstības rada viltus trauksmes.
Rezumējot
Novērojamība; Tā ir spēja izprast sistēmas iekšpusi no ārpuses, izmantojot metriku, žurnālus un pēdas. Četri zelta signāli (latents, satiksme, kļūda, piesātinājums) apkopo vairuma pakalpojumu stāvokli. AI ir ļoti spēcīgs PromQL vaicājumu, trauksmes noteikumu un informācijas paneļu rakstīšanā, kā arī lielu žurnālu gabalu apkopošanā un anomāliju atrašanā. Taču jūsu pienākums ir pārbaudīt trauksmes sliekšņus, salīdzinot ar savas sistēmas vēsturi, nodrošināt, lai trauksmes būtu vērstas uz darbību, un nekad nekoplietot žurnālus, tos neslēpjot.
Lietojumprogrammas uzdevums
Pakalpojumam (vai pakalpojuma paraugam): (1) — ģenerējiet trauksmes kārtulu kļūdu biežumam, izmantojot veidni Trauksmes kārtulas ģenerēšana, un iestatiet ieteikto slieksni uz "cik reizes tas ir aktivizējies pagātnē?" Pārbaudi to ar jautājumu; (2) maskējiet savu žurnāla paraugu un analizējiet to, izmantojot veidni "Žurnāla kopsavilkums"; (3) Ņemiet vērā, kuru metriku apskatīsit, lai apstiprinātu visticamāko cēloni.
kontrolsaraksts
- [ ] Es izvēlējos metriku, ko izsekot, pamatojoties uz četriem zelta signāliem.
- [ ] Es maskēju visus baļķus, ko nodevu AI jutīgo zonu ziņā.
- [ ] Es pārbaudīju, vai katrs trauksmes signāls bija vērsts uz darbību un ir pareizi steidzams.
- [ ] Es pārbaudīju trauksmes sliekšņus, salīdzinot ar savas sistēmas vēsturiskajiem datiem.
- [ ] Es filtrēju momentānās svārstības, pievienojot brīdinājumiem par (ilgumu).
- [ ] Pamatcēlonim kopā izmantoju metriku + žurnālu + izsekošanu.