Nyereség:
- Képes megérteni a megfigyelhetőség három pillérét (metrika, naplózás, nyomkövetés) és a négy aranyjelet, és a mesterséges intelligencia képes PromQL lekérdezéseket, riasztási szabályokat és műszerfalakat generálni
- Képes a riasztások kimerültségének megelőzésére azáltal, hogy a riasztásokat cselekvés-orientáltan és a megfelelő sürgősségi szinten tartja, és teszteli a küszöbértékeket a saját rendszere előzményadataihoz képest
- Képes a magánélet és a titkos szivárgás megakadályozására az érzékeny területek elfedésével, mielőtt a naplókat mesterséges intelligenciának adná
Bár úgy tűnik, hogy egy rendszer működik, belülről lehet, hogy haldoklik: a memória lassan megtelik, a válaszidők nőnek, a hibaarány növekszik. Ezt csak úgy lehet észrevenni, ha folyamatosan figyeljük a rendszert. Egy fejlettebb fogalom a megfigyelhetőség: az a képesség, hogy megértsük, mi történik a rendszerben a külső jelek alapján. A megfigyelhetőségnek három pillére van, és a DevOps professzionális mindhármat használja:
- Metrika: Időben mért numerikus értékek – CPU-használat, kérések száma, válaszidő, hibaarány. "Mennyi?" válaszol a kérdésre.
- Napló: A rendszer által előállított szöveges eseményrekordok – "felhasználó bejelentkezett", "adatbáziskapcsolat megszakadt". – Mi történt pontosan? válaszol a kérdésre.
- Nyomkövetés: Az útvonal, amelyet a kérés követ, miközben a rendszeren belül a szolgáltatástól a szolgáltatásig halad, és az egyes lépések időtartama. – Hol itt a lassúság? válaszol a kérdésre.
Leggyakoribb eszközök: Prometheus a metrikákhoz, Grafana a vizualizációhoz, Loki/ELK a naplóhoz, Jaeger/OpenTelemetry a nyomkövetéshez. Az AI nagyon jártas a lekérdezési nyelvek (különösen a Prometheus PromQL), a riasztási szabályok és a műszerfal konfigurációk megírásában ezekhez az eszközökhöz. A mesterséges intelligencia is itt a legerősebb: a naplók és mutatók nagy darabjainak összegzése, valamint az anomáliák megjelölése.
Tisztázzuk egy mondatban a különbséget a megfigyelés és a megfigyelhetőség között: a monitorozás olyan kérdéseket tesz fel, amelyeket már ismer (“A CPU 90% felett van?”); A megfigyelhetőség az, hogy olyan kérdéseket tehet fel, amelyeket még nem tudott ("miért csak egy bizonyos ügyfélnél fordul elő ez a furcsa lassúság egy bizonyos időpontban?"). A modern rendszerek annyira összetettek, hogy nem lehet előre megjósolni a meghibásodás minden módját; Ezért kritikussá válik a gazdag metrikák, naplók és nyomok összegyűjtésének, majd azok mélyreható lekérdezésének képessége – vagyis a megfigyelhetőség. A mesterséges intelligencia itt lép életbe a „korábban ismeretlen kérdés” megválaszolásakor: gyorsan átvizsgálja a birtokában lévő nyers adatokat, mintákat és anomáliákat javasol, és ezeknek a nyomoknak ellenőrzésével eljut a kiváltó okhoz.
Lépésről lépésre: mit és hogyan figyeljünk?
- Válassza ki a megfelelő mutatókat. Az iparban "négy arany jelzést" vesznek alapul: késleltetést, forgalom, hibák, telítettség – az erőforrás mennyire tele van. Ezek összefoglalják a legtöbb szolgáltatás állapotát.
- Gyűjtse össze a mutatókat. Hagyja, hogy az alkalmazás mutasson egy végpontot, amelyet a Prometheus tud olvasni.
- Állítsa be a műszerfalakat. Vizualizálja ezeket a mutatókat a Grafanában.
- Írjon riasztási szabályokat. Ki kap figyelmeztetést egy küszöbérték túllépésére és hogyan?
- A naplók központosítása. Tegye az összes szolgáltatásnaplót kereshetővé egy helyen.
- Csökkentse a zajt. A túl sok riasztás „éber fáradtságot” okoz; A fontos riasztás eltűnik.
Tipp: A jó riasztás két dologgal találkozik: használható és kellően sürgős. Valakit hajnali 3-kor felébresztő riasztásnak valóban éjszakai beavatkozásra van szüksége. Ne ébresszen fel senkit olyasmire, ami önmagában nem igényel cselekvést, például "CPU 70%"; jelenítse meg a táblán.
Hogyan írjunk riasztási szabályt?
A riasztás három összetevőből áll: állapot (mely mutató melyik küszöböt lépi túl és mennyi ideig), időtartam („5 percig”, hogy elkerülje a pillanatnyi ingadozások kiváltását) és fontosság/művelet (kinek, melyik csatornán keresztül). A mesterséges intelligencia mesterien hozza létre ezt a hármat a megfelelő kontextusban. Például a „kritikus riasztás, ha a hibaarány meghaladja az 5%-ot 5 percen keresztül” lefordítása PromQL-be, a másodperc töredéke az AI-nak, de Ön dönti el, hogy a küszöb megfelelő-e a rendszer számára.
Figyelem: Az AI által javasolt riasztási küszöbértékek általános feltételezések. A rendszer normál terhelése, toleranciája és munkaterhelése eltérő. Mielőtt küszöbértéket állítana be közvetlenül a gyártási folyamatba, nézze meg az előzményadatokat, és kérdezze meg: "hányszor váltották ki ezt a küszöbértéket a múltban, ezek közül hány volt valódi probléma?" Válaszolj a kérdésre.
Napló adatvédelem: kritikus figyelmeztetés
A rönkök a leggyakrabban figyelmen kívül hagyott szivárgásforrások. Egy naplósor véletlenül tartalmazhat jelszót, hitelkártyaszámot vagy személyes adatokat (a KVKK/GDPR alatt). Amikor naplókat illeszt be egy AI-ba elemzés céljából:
- Maszkolja az érzékeny területeket. Cserélje ki az olyan értékeket, mint a token, jelszó, e-mail cím, azonosítószám a <REDACTED>-re.
- Mondjon példákat, ne mindet. Egymillió sor helyett gyakran elég néhány száz reprezentatív sor.
- Válasszon intézmény által jóváhagyott járművet. Különösen a termelési naplókhoz használjon olyan eszközt, amelynek adatai nem kerülnek oktatásra.
Négy arany jelzés és riasztóasztal
jelet
által mérve
Példa riasztási küszöbértékre
sürgősség
késleltetés
válaszidő
p95 > 800 ms, 5 perc
magas
forgalom
Kérés/mp
Hirtelen 300%-os növekedés/csökkenés
közepes
Hiba
Sikertelen kérések aránya
> 5%, 5 perc
kritikus
Telítettség
erőforrás-kihasználtság
lemez > 85%
magas
három mini tok
1. eset – 400 sor napló összefoglalva 30 másodpercben. Egy szolgáltatás lelassult. A mérnök átadta a maszkolt 400 sornyi naplót az MI-nek, és azt mondta: „Összefoglalja az ismétlődő hibamintákat és az időintenzitást”. Az AI kimutatta, hogy egy adott külső API-hívás 30 másodpercenként időtúllépést jelent. A kiváltó ok 30 másodpercen belül megtalálható; A naplók kézi beolvasása fél órát vesz igénybe.
2. eset – a riasztó fáradtsága megoldva. Az egyik csapat napi 200 riasztást kapott, és figyelmen kívül hagyta őket – egészen addig, amíg egy valódi kimaradási riasztást is figyelmen kívül hagytak. Adja meg az AI-nak az összes riasztási szabályt, és kérdezze meg, hogy "melyek nem alkalmazhatók, és melyek kombinálhatók?" – kérdezték. A riasztások száma napi 12-re csökkent; Most már minden riasztást komolyan vettek.
3. eset – rossz küszöböt korán észleltek. YZ a "Figyelmeztetés, ha 95%-ban megtelt" javasolta a lemezt. A mérnök megvizsgálta az előzményadatokat: amint a lemez elérte a 95%-ot, kevés idő maradt a beavatkozásra. 80%-ra csökkentette a küszöböt, és hozzáadott egy második riasztást a „növekedési ütem” alapján. Az ellenőrzés megakadályozta a tényleges éjféli kiesést.
Négy másolható sablon
1) Napló összesítése (maszkolt):
Elemezze az alábbi naplópéldát (az érzékeny értékeket a <REDACTED> funkcióval maszkoltam). Adja meg: (1) ismétlődő hibaminták, (2) időbeli koncentráció, (3) legvalószínűbb kiváltó ok és (4) 3 mérőszám, amelyet ellenőrizni fogok. Napló: [LINES]
2) Riasztási szabály generálása:
Írjon riasztási szabályt a Prometheus/Alertmanager számára: [SEVERITY] riasztás generálása, ha a [THRESHOLD] meghaladja a [METRIC][DURATION] értéket. A szabálynak műveletorientáltnak kell lennie, és tartalmaznia kell egy megjegyzést és a runbook hivatkozási mezőt. Magyarázza el a PromQL-t, és írja le, miért ésszerű ez a küszöb.
3) PromQL lekérdezés írása/deklarálása:
Írjon egy PromQL-lekérdezést, amely méri: [EX. 5xxhibaarány százalékos az elmúlt 5 percben]. Magyarázza el a lekérdezést lépésről lépésre. Akkor mondja meg, mi legyen ennek az értéknek az egészséges tartománya.
4) A műszerfal kialakítása:
Grafana műszerfal tervezése a [SERVICE] számára: mely paneleken jelenítsem meg a négy aranyjelet (latencia, forgalom, hiba, telítettség)? Javasoljon metrikát, megjelenítési típust és ésszerű küszöbértéket minden panelhez. Cél: egy őr egészségi állapotának megtekintése 10 másodpercen belül.
Gyenge felszólítás / Erős felszólítás
Gyenge: "Mi van abban a naplóban?" (amit 5000 sor nyers napló követ, benne jelzők)
Eredmény: kiszivárogtatja a titkokat, és az AI céltalan, felületes összefoglalót ad.
Erős: "Keresse meg az ismétlődő hibamintákat és az időintenzitást az alábbi, 300 soros maszkolt naplópéldában; mondja meg a legvalószínűbb kiváltó okot és azokat a mutatókat, amelyeket ellenőrizni fogok. A tokeneket <REDACTED> készítettem."
Különbség: a második prompt maszkos és fókuszált példát ad, egyértelmű elemzési kimenetet kérve; Egyszerre biztonságos és hasznos.
Gyakori hibák
- A napló beillesztése az AI-ba maszkolás nélkül. A leggyakoribb titkos/személyes adatszivárgás.
- Riasztás beállítása mindenre. A riasztó fáradtság valódi riasztást temet el.
- Nem működő riasztás. Ez egy figyelmeztető zaj, ami ellen senki nem tehet semmit.
- Kérdés nélkül elfogadja az AI küszöbét. A küszöböt a rendszer előzményeinek megfelelően kell beállítani.
- Csak nézzük a mérőszámot. Napló és nyomkövetés nélkül a kiváltó ok legtöbbször nem található meg.
- Nem állít be ébresztési időt (for). A pillanatnyi ingadozások téves riasztásokat eredményeznek.
Összefoglalva
Megfigyelhetőség; Ez az a képesség, hogy a rendszer belsejét kívülről metrikák, naplók és nyomok segítségével megértsük. A négy aranyjel (latencia, forgalom, hiba, telítettség) összefoglalja a legtöbb szolgáltatás állapotát. A mesterséges intelligencia nagyon hatékony a PromQL lekérdezések, riasztási szabályok és irányítópultok írásában, valamint a naplók nagy darabjainak összefoglalásában és az anomáliák megtalálásában. De az Ön felelőssége, hogy ellenőrizze a riasztási küszöbértékeket a saját rendszere előzményei alapján, hogy a riasztásokat cselekvés-orientáltan tartsa, és soha ne ossza meg a naplókat azok elfedése nélkül.
Pályázati feladat
Szolgáltatáshoz (vagy mintaszolgáltatáshoz): (1) Készítsen riasztási szabályt a hibaarányhoz a "Riasztási szabály létrehozása" sablonnal, és állítsa be a javasolt küszöbértéket a "hányszor váltotta ki a múltban?" Teszteld a kérdéssel; (2) maszkolja le a meglévő naplómintát, és elemezze azt a „Napló összegzése” sablonnal; (3) Jegyezze fel, melyik mérőszámot fogja megvizsgálni a legvalószínűbb kiváltó ok megerősítéséhez.
ellenőrző lista
- [ ] Négy aranyjel alapján választottam ki a követendő mérőszámokat.
- [ ] Az összes naplót, amelyet az AI-nak adtam, elfedtem az érzékeny területek tekintetében.
- [ ] Ellenőriztem, hogy minden riasztás cselekvés-orientált és megfelelő sürgős volt-e.
- [ ] Teszteltem a riasztási küszöbértékeket a rendszerem előzményadataihoz képest.
- [ ] A pillanatnyi ingadozásokat úgy szűrtem ki, hogy a riasztásokhoz hozzáadtam a for (duration) értéket.
- [ ] A metrikát + log + nyomkövetést együtt használtam a kiváltó ok miatt.