Gevinster:
- Evne til å forstå de tre pilarene for observerbarhet (metrisk, logg, sporing) og de fire gylne signalene og ha kunstig intelligens generere PromQL-spørringer, alarmregler og dashbord
- Evne til å forhindre alarmtretthet ved å holde alarmer handlingsorienterte og på riktig hastenivå og teste terskler mot ditt eget systems historiske data
- Evne til å forhindre personvern og hemmelig lekkasje ved å maskere sensitive områder før loggene gis til kunstig intelligens
Selv om et system kan se ut til å fungere, kan det være i ferd med å dø innvendig: minnet fylles sakte opp, responstiden øker, feilraten kryper opp. Den eneste måten å legge merke til dette på er å kontinuerlig overvåke systemet. Et mer avansert konsept er observerbarhet: evnen til å forstå hva som foregår inne i systemet ved å se på dets ytre tegn. Det er tre pilarer for observerbarhet, og DevOps-profesjonelle bruker alle tre:
- Beregning: Numeriske verdier målt over tid — CPU-bruk, antall forespørsler, responstid, feilrate. "Hvor mye?" svarer på spørsmålet.
- Logg: Teksthendelsesposter produsert av systemet – "bruker pålogget", "databaseforbindelse tapt". "Hva skjedde egentlig?" svarer på spørsmålet.
- Trace: Banen en forespørsel følger mens den går fra tjeneste til tjeneste i systemet og varigheten av hvert trinn. "Hvor er tregheten?" svarer på spørsmålet.
Mest vanlige verktøy: Prometheus for metrikk, Grafana for visualisering, Loki/ELK for logg, Jaeger/OpenTelemetry for sporing. AI er veldig dyktig til å skrive spørringsspråkene (spesielt Prometheus' PromQL), alarmregler og dashbordkonfigurasjoner for disse verktøyene. Det er også her AI er på sitt sterkeste: oppsummerer store deler av logger og beregninger og flagger anomalier.
La oss klargjøre forskjellen mellom overvåking og observerbarhet i én setning: overvåking er å stille spørsmål du allerede vet ("Er CPU-en forbi 90%?"); observerbarhet er å kunne stille spørsmål du ikke allerede visste ("hvorfor skjer denne rare tregheten bare for en bestemt kunde på et bestemt tidspunkt?"). Moderne systemer er så komplekse at du ikke kan forutsi alle feilmåter; Derfor blir muligheten til å samle inn rike beregninger, logger og spor og deretter spørre dem i dybden – det vil si observerbarhet – kritisk. Det er her AI kommer inn i bildet når du svarer på det "tidligere ukjente spørsmålet": den skanner raskt rådataene du har, foreslår mønstre og anomalier, og du kommer til grunnårsaken ved å verifisere disse ledetrådene.
Trinn for trinn: hva og hvordan overvåke?
- Velg de riktige beregningene. I bransjen er "fire gyldne signaler" tatt som grunnlag: latens, trafikk, feil, metning - hvor full ressursen er. Disse oppsummerer helsen til de fleste tjenester.
- Samle inn beregninger. La applikasjonen presentere et endepunkt som Prometheus kan lese.
- Sett opp dashbord. Visualiser disse beregningene i Grafana.
- Skriv alarmregler. Hvem vil bli advart når en terskel overskrides og hvordan?
- Sentraliser logger. Gjør alle tjenestelogger søkbare på ett sted.
- Reduser støy. For mye alarm skaper "varslingstretthet"; Den viktige alarmen forsvinner.
Tips: En god alarm møter to ting: den er handlingsdyktig og haster riktig. En alarm som vekker noen klokken 03.00 må være noe som faktisk krever inngrep om natten. Ikke vekk noen for noe som ikke krever handling på egen hånd, som "CPU 70%"; vis det på tavlen.
Hvordan skrive en alarmregel?
Et varsel består av tre komponenter: tilstand (hvilken beregning overskrider hvilken terskel og hvor lenge), varighet ("i 5 minutter" for å unngå å utløse momentane svingninger) og viktighet/handling (til hvem, gjennom hvilken kanal). AI etablerer mesterlig disse tre med riktig kontekst. For eksempel, å oversette en regel som "kritisk alarm hvis feilraten overstiger 5 % i 5 minutter" til PromQL er en oppgave på brøkdelen av et sekund for AI - men du bestemmer om terskelen er riktig for systemet ditt.
Forsiktig: Alarmterskelene foreslått av AI er generelle antakelser. Systemets normale belastning, toleranse og arbeidspåvirkning er forskjellige. Før du setter en terskel direkte i prod, ser du på dine historiske data og spør "hvor mange ganger har denne terskelen blitt utløst tidligere, hvor mange av disse var reelle problemer?" Svar på spørsmålet.
Loggpersonvern: kritisk advarsel
Logger er den hyppigst oversett kilden til lekkasjer. En logglinje kan ved et uhell inneholde et passord, et kredittkortnummer eller personlige data (under KVKK/GDPR). Når du limer inn logger i en AI for analyse:
- Mask sensitive områder. Erstatt verdier som token, passord, e-post, ID-nummer med <REDACTED>.
- Gi eksempler, ikke alle. I stedet for en million linjer, er noen hundre representative linjer ofte nok.
- Velg et institusjonsgodkjent kjøretøy. Spesielt for produksjonslogger, bruk et verktøy hvis data ikke går til trening.
Fire gylne signaler og alarmbord
signal
målt etter
Eksempel på alarmterskel
haster
ventetid
responstid
p95 > 800 ms, 5 min
høy
trafikk
Forespørsel/sek
Plutselig 300 % økning/reduksjon
medium
Feil
Mislykket forespørselsfrekvens
> 5 %, 5 min
kritisk
Metning
ressursbelegg
Disk > 85 %
høy
tre minisaker
Tilfelle 1 – 400 linjer med logg oppsummert på 30 sekunder. En tjeneste hadde bremset opp. Ingeniøren ga de maskerte 400 linjene med loggen til AI og sa, "oppsummer de tilbakevendende feilmønstrene og tidsintensiteten." AI viste at et bestemt eksternt API-kall timeout hvert 30. sekund. Grunnårsak funnet på 30 sekunder; Å skanne logger manuelt ville ta en halv time.
Tilfelle 2 — alarmtretthet løst. Ett team mottok 200 alarmer om dagen og ignorerte dem alle – helt til en reell utfallsalarm også ble oversett. Gi AI alle varslingsreglene og spør "hvilke er ikke handlingsdyktige og hvilke kan kombineres?" spurte de. Antall alarmer gikk ned til 12 per dag; Hver alarm ble nå tatt på alvor.
Tilfelle 3 — feil terskel fanget tidlig. YZ foreslo "Advar når 95 % full" for disken. Ingeniøren så på historiske data: når disken nådde 95 % var det lite tid til intervensjon. Den senket terskelen til 80 % og la til en ekstra alarm basert på «veksthastighet». Verifisering forhindret et faktisk midnattsbrudd.
Fire kopierbare maler
1) Loggoppsummering (maskert):
Analyser loggeksemplet nedenfor (jeg maskerte sensitive verdier med <REDACTED>). Gi meg: (1) tilbakevendende feilmønstre, (2) konsentrasjon over tid, (3) mest sannsynlig grunnårsak og (4) 3 beregninger jeg skal se på for å bekrefte. Logg: [LINES]
2) Generering av alarmregel:
Skriv en alarmregel for Prometheus/Alertmanager: Generer [SEVERITY] alarm hvis [THRESHOLD] overskrider [METRIC][DURATION]. Regelen bør være handlingsorientert og inkludere et merknads- og runbook-lenkefelt. Forklar PromQL og skriv hvorfor denne terskelen er rimelig.
3) Skrive/erklære PromQL-spørring:
Skriv en PromQL-spørring som måler: [EX. 5xx feilrate prosent i de siste 5 minuttene]. Forklar spørringen trinn for trinn. Fortell meg deretter hva det sunne området for denne verdien bør være.
4) Dashboarddesign:
Design et Grafana-dashbord for [SERVICE]: med hvilke paneler skal jeg vise de fire gyldne signalene (latens, trafikk, feil, metning)? Foreslå metrikk, visualiseringstype og rimelig terskel for hvert panel. Formål: å se helsestatusen til en vakt på 10 sekunder.
Svak forespørsel / Sterk forespørsel
Svak: "Hva står i den loggen?" (etterfulgt av 5000 linjer med rå logg, tokens i den)
Resultat: du lekker hemmeligheter og AI gir en umålrettet, overfladisk oppsummering.
Sterkt: "Finn tilbakevendende feilmønstre og tidsintensitet i eksemplet med 300-linjers maskert logg nedenfor; fortell meg den mest sannsynlige grunnårsaken og beregningene jeg skal se på for å bekrefte. Jeg har laget tokens <REDACTED>."
Forskjell: den andre ledeteksten gir et maskert og fokusert eksempel, og ber om et tydelig analyseresultat; Det er både trygt og nyttig.
Vanlige feil
- Lim inn loggen i AI uten å maskere den. Den vanligste hemmelige/personlige datalekkasjen.
- Stille inn alarmer for alt. Alarmtretthet begraver ekte alarm.
- Ikke-handlingsbar alarm. Det er varselstøy som ingen kan gjøre noe med.
- Aksepterer terskelen til AI uten spørsmål. Terskelen bør settes i henhold til systemets historikk.
- Bare ser på metrikken. Uten logg og spor kan ikke årsaken finnes mesteparten av tiden.
- Stiller ikke inn et alarmtidspunkt (for). Kortvarige svingninger gir falske alarmer.
Oppsummert
Observerbarhet; Det er evnen til å forstå innsiden av systemet fra utsiden med metrikk, logger og spor. De fire gylne signalene (latens, trafikk, feil, metning) oppsummerer helsen til de fleste tjenester. AI er veldig kraftig til å skrive PromQL-spørringer, alarmregler og dashboards, og til å oppsummere store deler av logger og finne anomalier. Men det er ditt ansvar å verifisere alarmterskler mot ditt eget systems historie, holde alarmer handlingsorienterte og aldri dele logger uten å maskere dem.
Søknadsoppgave
For en tjeneste (eller en eksempeltjeneste): (1) Få en alarmregel generert for feilraten med malen "Alarmregelgenerering" og sett den foreslåtte terskelen til "hvor mange ganger har den utløst tidligere?" Test det med spørsmålet; (2) masker en loggprøve du har og få den analysert med malen "Logg summarization"; (3) legg merke til hvilken beregning du vil se på for å bekrefte den mest sannsynlige grunnårsaken.
sjekkliste
- [ ] Jeg valgte beregningene å spore basert på fire gylne signaler.
- [ ] Jeg maskerte alle loggene jeg ga til AI med tanke på sensitive områder.
- [ ] Jeg bekreftet at hver alarm var handlingsorientert og at den haster riktig.
- [ ] Jeg testet alarmterskelene mot systemets historiske data.
- [ ] Jeg filtrerte øyeblikkelige svingninger ved å legge til for (varighet) til alarmene.
- [ ] Jeg brukte metrikk + log + spor sammen for rotårsak.