Voitot:
- Kyky ymmärtää kolmea havaittavuuden pilaria (metriikka, loki, jäljitys) ja neljä kultaista signaalia ja saada tekoäly generoimaan PromQL-kyselyitä, hälytyssääntöjä ja kojetauluja
- Kyky estää hälytysten väsymistä pitämällä hälytykset toimintakeskeisinä ja oikealla kiireellisyydellä sekä testaamalla kynnysarvoja oman järjestelmäsi historiatietoihin nähden
- Kyky estää yksityisyyttä ja salaisia vuotoja peittämällä herkät alueet ennen kuin annat lokit tekoälylle
Vaikka järjestelmä saattaa näyttää toimivan, se saattaa kuolla sisällä: muisti täyttyy hitaasti, vasteajat kasvavat, virheprosentti hiipii. Ainoa tapa huomata tämä on seurata järjestelmää jatkuvasti. Edistyneempi käsite on havaittavuus: kyky ymmärtää, mitä järjestelmän sisällä tapahtuu, katsomalla sen ulkoisia merkkejä. Havainnoitavuuden pilaria on kolme, ja DevOps-ammattilainen käyttää kaikkia kolmea:
- Metriikka: Numeeriset arvot ajan mittaan mitattuna — suorittimen käyttö, pyyntöjen määrä, vasteaika, virheprosentti. "Kuinka paljon?" vastaa kysymykseen.
- Loki: Järjestelmän tuottamat tekstitapahtumatietueet - "käyttäjä kirjautunut sisään", "tietokantayhteys katkennut". "Mitä oikein tapahtui?" vastaa kysymykseen.
- Jäljitys: Polku, jota pyyntö seuraa siirrettäessä palvelusta palveluun järjestelmän sisällä ja kunkin vaiheen kesto. "Missä on hitaus?" vastaa kysymykseen.
Yleisimmät työkalut: Prometheus mittauksiin, Grafana visualisointiin, Loki/ELK lokiin, Jaeger/OpenTelemetry jäljitykseen. Tekoäly on erittäin taitava kirjoittamaan näiden työkalujen kyselykielet (erityisesti Prometheusin PromQL), hälytyssäännöt ja kojelautakonfiguraatiot. Siellä tekoäly on myös vahvimmillaan: se tekee yhteenvedon suurista lokien ja mittareiden paloista ja ilmoittaa poikkeavuuksista.
Selvitetään tarkkailun ja havainnoinnin ero yhdellä lauseella: valvonta on jo tuttujen kysymysten esittämistä ("Onko CPU yli 90%?"); havaittavuus on kykyä esittää kysymyksiä, joita et jo tiennyt ("miksi tämä outo hitaus tapahtuu vain tietylle asiakkaalle tiettyyn aikaan?"). Nykyaikaiset järjestelmät ovat niin monimutkaisia, että et voi ennustaa kaikkia vikoja; Siksi kyvystä kerätä monipuolisia mittareita, lokeja ja jälkiä ja sitten tehdä niistä perusteellinen kysely – eli havaittavuus – tulee kriittiseksi. Tässä tekoäly tulee esille vastattaessa "aiemmin tuntemattomaan kysymykseen": se skannaa nopeasti saamasi raakadatan, ehdottaa malleja ja poikkeavuuksia, ja pääset perimmäiseen syyyn tarkistamalla nämä vihjeet.
Askel askeleelta: mitä ja miten seurata?
- Valitse oikeat mittarit. Alan perustana ovat "neljä kultaista signaalia": latenssi, liikenne, virheet, kylläisyys - kuinka täynnä resurssi on. Nämä tiivistävät useimpien palveluiden terveyden.
- Kerää mittareita. Anna sovelluksen esittää päätepiste, jonka Prometheus voi lukea.
- Määritä kojelautat. Visualisoi nämä tiedot Grafanassa.
- Kirjoita hälytyssäännöt. Ketä varoitetaan kynnyksen ylittymisestä ja miten?
- Keskitä lokit. Tee kaikista palvelulokeista haettavissa yhdestä paikasta.
- Vähennä melua. Liian paljon hälytyksiä aiheuttaa "valppausväsymystä"; Tärkeä hälytys katoaa.
Vinkki: Hyvä hälytys kohtaa kaksi asiaa: se on toimiva ja sillä on oikea kiire. Hälytyksen, joka herättää jonkun klo 3.00, täytyy olla jotain, joka todella vaatii yöaikaan puuttumista. Älä herätä ketään sellaiseen, joka ei vaadi toimia sellaisenaan, kuten "CPU 70%"; näytä se taululle.
Kuinka kirjoittaa hälytyssääntö?
Hälytys koostuu kolmesta osasta: tila (mikä mittari ylittää minkä kynnyksen ja kuinka kauan), kesto (”5 minuuttia”, jotta vältytään hetkellisten heilahteluilta) ja tärkeys/toiminto (kenelle, minkä kanavan kautta). Tekoäly luo mestarillisesti nämä kolme oikeaan kontekstiin. Esimerkiksi säännön, kuten "kriittinen hälytys, jos virheprosentti ylittää 5 % 5 minuutin ajan" kääntäminen PromQL:ksi on tekoälylle sekunnin murto-osa, mutta sinä päätät, onko kynnys oikea järjestelmällesi.
Varoitus: AI:n ehdottamat hälytyskynnykset ovat yleisiä oletuksia. Järjestelmäsi normaali kuormitus, toleranssi ja työn vaikutus ovat erilaisia. Ennen kuin asetat kynnyksen suoraan tuotantoon, katsot historiallisia tietojasi ja kysyt "kuinka monta kertaa tämä kynnys on laukaissut aiemmin, kuinka monta näistä oli todellisia ongelmia?" Vastaa kysymykseen.
Lokin tietosuoja: kriittinen varoitus
Tukit ovat yleisimmin huomiotta jätetty vuotojen lähde. Lokirivi voi vahingossa sisältää salasanan, luottokortin numeron tai henkilökohtaisia tietoja (HIKK/GDPR:n alla). Kun liität lokeja tekoälyyn analysointia varten:
- Maski herkät alueet. Korvaa arvot, kuten tunnus, salasana, sähköpostiosoite, tunnusnumero <REDACTED>:llä.
- Anna esimerkkejä, älä kaikkia. Miljoonan rivin sijaan riittää usein muutama sata edustavaa riviä.
- Valitse laitoksen hyväksymä ajoneuvo. Käytä erityisesti tuotantolokeissa työkalua, jonka tiedot eivät mene koulutukseen.
Neljä kultaista signaalia ja hälytyspöytää
signaali
mitattuna
Esimerkki hälytysrajasta
kiireellisyys
latenssi
vasteaika
p95 > 800 ms, 5 min
korkea
liikennettä
Pyyntö/sek
Äkillinen 300 % nousu/lasku
keskikokoinen
Virhe
Epäonnistuneet pyynnöt
> 5 %, 5 min
kriittinen
Kylläisyys
resurssien käyttöaste
levy > 85 %
korkea
kolme minilaukkua
Tapaus 1 – 400 lokiriviä yhteenvetona 30 sekunnissa. Palvelu oli hidastunut. Insinööri antoi naamioidut 400 lokiriviä tekoälylle ja sanoi: "Tee yhteenveto toistuvista virhekuvioista ja ajan intensiteetistä." Tekoäly osoitti, että tietty ulkoinen API-kutsu aikakatkaisee 30 sekunnin välein. Perimmäinen syy löytyi 30 sekunnissa; Lokien manuaalinen skannaus kestäisi puoli tuntia.
Tapaus 2 – hälyttimen väsymys ratkaistu. Yksi tiimi sai 200 hälytystä päivässä ja jätti ne kaikki huomiotta – kunnes myös todellinen katkoshälytys jäi huomiotta. Anna tekoälylle kaikki hälytyssäännöt ja kysy "mitkä niistä eivät ole toimivia ja mitkä voidaan yhdistää?" he kysyivät. Hälytysten määrä väheni 12:een päivässä; Jokainen hälytys otettiin nyt vakavasti.
Tapaus 3 – väärä kynnys havaittiin aikaisin. YZ ehdotti "Varoita, kun 95% täynnä" levylle. Insinööri katsoi historiallisia tietoja: kun levy saavutti 95 %, puuttumiseen oli vähän aikaa. Se alensi kynnystä 80 prosenttiin ja lisäsi toisen hälytyksen "kasvuvauhtiin". Vahvistus esti todellisen keskiyön katkoksen.
Neljä kopioitavaa mallia
1) Lokin yhteenveto (naamioitu):
Analysoi alla olevaa lokiesimerkkiä (peilin herkät arvot <REDACTED>:lla). Kerro minulle: (1) toistuvat virhemallit, (2) keskittyminen ajan mittaan, (3) todennäköisin syy ja (4) 3 mittaria, joita tarkastelen varmistaakseni. Loki: [LINES]
2) Hälytyssäännön luominen:
Kirjoita hälytyssääntö Prometheus/Alertmanagerille: Luo [VAKAVUUS]-hälytys, jos [THRESHOLD] ylittää [METRIC][KESTO]. Säännön tulee olla toimintasuuntautunut ja sisältää huomautus- ja runbook-linkkikenttä. Selitä PromQL ja kirjoita, miksi tämä kynnys on kohtuullinen.
3) PromQL-kyselyn kirjoittaminen/ilmoittaminen:
Kirjoita PromQL-kysely, joka mittaa: [EX. 5xx-virheprosenttiprosentti viimeisen 5 minuutin aikana]. Selitä kysely vaihe vaiheelta. Kerro sitten minulle, mikä tämän arvon terveellinen vaihteluväli pitäisi olla.
4) Kojelaudan suunnittelu:
Suunnittele Grafana-kojelauta [SERVICE]:lle: millä paneeleilla minun pitäisi näyttää neljä kultaista signaalia (latenssi, liikenne, virhe, kylläisyys)? Ehdota mittaria, visualisointityyppiä ja kohtuullista kynnysarvoa kullekin paneelille. Tarkoitus: nähdä vartijan terveydentila 10 sekunnissa.
Heikko kehote / Vahva kehote
Heikko: "Mitä siinä lokissa on?" (seuraa 5000 riviä raakatukkia, rahakkeita siinä)
Tulos: vuodat salaisuuksia ja tekoäly antaa kohdistamattoman, pinnallisen yhteenvedon.
Vahva: "Etsi toistuvia virhekuvioita ja ajan intensiteettiä alla olevasta 300-rivisen peitetyn lokin esimerkistä; kerro minulle todennäköisin perimmäinen syy ja mittarit, joita tarkastelen varmistaakseni. Tein tunnukset <REDACTED>."
Ero: toinen kehote antaa peitetyn ja kohdistetun esimerkin, jossa pyydetään selkeää analyysitulosta; Se on sekä turvallista että hyödyllistä.
Yleisiä virheitä
- Lokin liittäminen tekoälyyn peittämättä sitä. Yleisin salaisuus/henkilötietojen vuoto.
- Hälytysten asettaminen kaikkeen. Hälytysväsymys peittää todellisen hälytyksen.
- Toimimaton hälytys. Se on varoitusääni, jolle kukaan ei voi tehdä mitään.
- Tekoälyn kynnyksen hyväksyminen epäilemättä. Kynnys tulee asettaa järjestelmäsi historian mukaan.
- Katson vain mittaria. Ilman lokia ja jälkiä perimmäistä syytä ei useimmiten löydy.
- Hälytysaikaa ei ole asetettu (for). Hetkelliset vaihtelut aiheuttavat vääriä hälytyksiä.
Yhteenvetona
Havaittavuus; Se on kyky ymmärtää järjestelmän sisäpuolta ulkopuolelta mittareiden, lokien ja jälkien avulla. Neljä kultaista signaalia (latenssi, liikenne, virhe, kylläisyys) kuvaavat useimpien palveluiden kunnon. Tekoäly on erittäin tehokas kirjoittamaan PromQL-kyselyitä, hälytyssääntöjä ja kojetauluja sekä tekemään yhteenvetoja suurista lokipaloista ja löytämään poikkeavuuksia. Mutta sinun vastuullasi on tarkistaa hälytyskynnykset oman järjestelmäsi historiaa vastaan, pitää hälytykset toimintalähtöisinä etkä koskaan jaa lokeja peittämättä niitä.
Sovellustehtävä
Palvelua (tai esimerkkipalvelua) varten: (1) Luo hälytyssääntö virhesuhteelle "Hälytyssäännön luominen" -mallilla ja aseta ehdotetuksi kynnysarvoksi "Kuinka monta kertaa se on lauennut aiemmin?" Testaa sitä kysymyksellä; (2) peittää olemassa oleva lokinäyte ja analysoida se "Lokin yhteenveto" -mallin avulla; (3) pane merkille, mitä mittaria tarkastelet todennäköisimmän perimmäisen syyn vahvistamiseksi.
tarkistuslista
- [ ] Valitsin seurattavat mittarit neljän kultaisen signaalin perusteella.
- [ ] Peittelin kaikki tekoälylle antamani lokit herkkien alueiden osalta.
- [ ] Varmistin, että jokainen hälytys oli toimintalähtöinen ja oikea kiireellinen.
- [ ] Testasin hälytysrajat järjestelmäni historiatietoihin nähden.
- [ ] Suodatin hetkelliset vaihtelut lisäämällä (kesto) hälytyksiin.
- [ ] Käytin metriikkaa + lokia + jäljitystä yhdessä perussyyn vuoksi.