Yunit 7 / 12

Pagsusuri at Pagmamasid ng Log

Mga nadagdag:

  • Kakayahang mag-summarize ng malalaking log dump sa pamamagitan ng pag-mask at pag-filter sa mga ito sa AI at gumawa ng timeline
  • Ang kakayahang suriin ang mga ugnayan sa oras na itinatag ng AI bilang mga hypotheses, hindi sanhi
  • Kakayahang patunayan ang root cause hypothesis na may mga sukatan at code at maghanda ng postmortem sketch

Kapag ang isang software ay tumatakbo sa produksyon (live na kapaligiran), tanging mga bakas, sukatan at log (mga linya ng log na may tatak ng oras na ginawa ng application habang ito ay tumatakbo) ang magsasabi sa iyo kung ano ang ginagawa nito. Ang pagkuha ng isang makabuluhang signal mula sa libu-libo, minsan milyon-milyon, ng mga linya ng log sa panahon ng isang outage ay ang pinaka-nakababahalang at oras-kritikal na sandali ng isang pagtugon sa insidente. Dito, maaaring maging katulong ang AI, nagbubuod ng napakalaking text, nag-extract ng mga pattern, at bumubuo ng mga hypotheses — hangga't nirerespeto mo ang mga limitasyon sa privacy at pag-verify.

Sa unit na ito, natututo kaming gumamit ng AI sa konteksto ng observability — ang kakayahang maunawaan ang panloob na estado ng isang system sa pamamagitan ng pagtingin sa mga panlabas na output nito: pagkuha ng kahulugan mula sa ingay ng log, pagtatatag ng timeline ng isang bug, paghahanap ng mga umuulit na pattern, at pag-draft ng postmortem. Kritikal na babala sa harap: ang mga raw production log ay kadalasang naglalaman ng personal na data at mga lihim; Ang basta-basta na paglalagay sa kanila sa isang AI tool ay isang seryosong paglabag.

Bakit Mahirap ang Mga Log, Bakit Nakatutulong ang AI?

Mahirap ang mga log sa tatlong dahilan: volume (masyadong marami), ingay (maraming linya ang hindi nauugnay), at kalat (isang kaganapan ay nakakalat sa mga log ng iba't ibang serbisyo). Ang mata ng tao ay napapagod sa pile na ito at hindi nakuha ang mahalagang linya.

Ang AI ay mahusay sa pagbubuod ng malalaking bloke ng teksto, pagbibilang ng mga umuulit na pattern, at pagtatanong "ano ang nagbago bago ang pagsabog ng mga error?" Ito ay makapangyarihan sa pagtatatag ng mga relasyon sa oras tulad ng Gayunpaman, mayroong dalawang limitasyon. Ang una ay ang window ng konteksto: limitado ang dami ng mga log na maaari mong ilagay sa isang modelo, kaya kailangan mo munang mag-filter at mag-sample. Pangalawa, pagpapatunay: Ang AI na nagsasabing "narito ang ugat na sanhi" ay isang hypothesis; Huwag gumawa ng desisyon nang hindi kinukumpirma ito gamit ang mga sukatan at code.

Babala: Maaaring naglalaman ang mga raw na log ng produksyon ng IP address, email, token, session ID at kung minsan ay bukas na lihim. I-mask sila bago i-feed sa AI, o gumamit lang ng mga tool na inaprubahan ng enterprise, data-secured. Pinalalim namin ang paksang ito sa unit 10.

Hakbang sa Hakbang: Mula Log hanggang Root Cause

  1. Paliitin ang window ng oras. Tukuyin ang mga minuto kung kailan nagsimula ang kaganapan; Suriin ang window na iyon, hindi ang buong araw.
  2. Salain ang ingay. Tanggalin ang mga kilalang paulit-ulit, hindi nakakapinsalang mga linya; Tumutok sa error (ERROR), babala (WARN) at sa unang sandali ng paglihis.
  3. I-mask ang sensitibong data. Linisin ang personal na data at mga lihim bago ibigay ang mga ito sa AI.
  4. Gumawa ng buod at timeline. Hilingin sa AI na ibuod ang kaganapan sa isang kronolohiya ("una ito, pagkatapos ay").
  5. Patunayan ang hypothesis gamit ang mga sukatan at code. Ang dahilan na itinuro ng AI; Kumpirmahin gamit ang dashboard, nauugnay na code at timeline ng deployment, kung naaangkop.
  6. Isulat ang natutunan. Gumawa ng postmortem sketch at maglista ng mga preventive action.

Tatlong Mini Case

Case 1 — 40,000 na linya na na-summarize sa loob ng 5 minuto. Ang isang serbisyo sa pagbabayad ay nag-ulat ng paulit-ulit na error sa loob ng 12 minuto. Ang koponan ay nagpakain ng may-katuturang 20 minutong window ng mga naka-mask na log (humigit-kumulang 40,000 linya, na-sample) sa AI ​​at bumuo ng isang timeline. Ipinakita ng modelo na ang pagsabog ng error ay kasabay ng sandali kung kailan tumaas ang oras ng pagtugon ng isang dependency service mula 200 ms hanggang 8 segundo. Kinumpirma ito ng team sa dashboard at pinaliit ang dahilan sa loob ng 10 minuto.

Kaso 2 — Mapanlinlang na ugnayan. Sa isa pang insidente, sinisi ito ng AI sa pagsasabing ang mga error ay nangyayari "sa parehong oras" bilang isang cron (naka-iskedyul na gawain) na tumatakbo. Nang suriin ng koponan ang mga sukatan, nakita nilang natapos na talaga ang cron bago ang kaganapan; Ang ugnayan ay nagkataon lamang. Ang tunay na dahilan ay isang memory leak. Aralin: Ang ugnayan ng oras na itinatag ng AI ay isang palatandaan, hindi ebidensya.

Kaso 3 — Pinabilis ang postmortem. Pagkatapos ng isang outage, ipinadala ng team ang (masked) na transcript ng mensahe at timeline mula sa channel ng kaganapan patungo sa AI ​​at ginawa itong postmortem sketch: buod, epekto, timeline, ugat na sanhi, mga aksyon. Itinama ng editor ng tao ang mga katotohanan at nagtalaga ng mga may-ari ng aksyon. Ang dokumento, na karaniwang tumatagal ng 2 oras, ay nakumpleto sa humigit-kumulang 40 minuto na may mas pare-parehong istraktura.

Apat na Nakokopyang Template

Buod ng log at timeline (na may masked log):

Nasa ibaba ang window ng kaganapan ng naka-mask na log ng produksyon.1) Ibuhos ang kaganapan sa isang kronolohikal na timeline (markahan ang sandali ng unang paglihis).2) Bilangin at pangkatin ang pinakamadalas na umuulit na mga uri ng error/babala.3) "Ano ang nagbago kanina?" Ilista ang mga kaganapan ng kandidato para sa tanong. Ito ay mga hypotheses; Markahan ito bilang "dapat ma-verify". {{mga log}}

Pagkuha ng pattern ng error:

Maghanap ng mga umuulit na pattern ng error sa mga linya ng log na ito. Para sa bawat pattern: sample na linya (masked), tinantyang pinagmulan at posibleng kahulugan. Mangolekta ng mga bihirang ngunit kritikal na solong error sa isang hiwalay na listahan ng "pansin."{{logs}}

Structured query/pagbuo ng filter:

Para sa {{log tool: grep/jq/Kibana KQL/CloudWatch Insights}}, sumulat ng query na nakakatugon sa sumusunod na kundisyon: {{e.g. 5xx error sa huling 15 min, hindi kasama ang user X}}.Ipaliwanag ang query; Tiyaking hindi ka gumagawa ng mga domain name, magtanong kung hindi ka sigurado.

Postmortem sketch:

Sumulat ng postmortem sketch mula sa sumusunod (masked) na timeline ng kaganapan: Buod / Epekto (tagal, apektado ng user) / Timeline / Root cause / Ano ang naging maayos / Mga Pagkilos (iwang blangko ang field ng may-ari para sa bawat isa). HUWAG gumamit ng pananalitang nag-aakusa; Maging makatotohanan at maagap.{{timeline}}

Mahinang prompt / Malakas na prompt

Mahina: "Tingnan mo itong mga tala, ano ang mali?" (Raw log ng buong araw, na may personal na data, hindi naka-target.)
Strong: "Sa ibaba ay ang naka-mask na log ng produksyon mula 14:02–14:20 (na-filter hanggang 5xxs). Sa window na ito, hanapin ang sandali kung kailan nagsimula ang error, bilangin ang pinakamadalas na uri ng error, at ilista ang mga deviation na lumitaw sa 60 segundo kaagad bago ang pagsabog; markahan silang lahat bilang 'hypothesis na ma-verify'."

Napakahusay na bersyon; Pinaliit nito ang window ng oras, sinasala at tinatakpan ang log, nagtatanong ng malinaw na tanong, at itinatatag mula sa simula na ang output ay isang hypothesis.

Paghanap

Malakas ang AI

Limitasyon / pagpapatunay

Malaking buod ng log

Oo, mabilis

Maaaring magkaroon ng sampling loss

Pagtatatag ng isang relasyon sa oras

bumubuo ng mga pahiwatig

Kaugnayan ≠ sanhi

Pagbuo ng query/filter

magandang draft

Totoo ba ang mga domain name?

Postmortem sketch

Istruktura at wika

Ang mga kaso ay nakumpirma ng tao

Ang Kaugnayan ay Hindi Dahilan

Ang pinakakaraniwang pitfall sa pagsusuri ng log ay ang "nangyari ito nang sabay-sabay, kaya't" kamalian. Nahuhulog ang AI sa bitag na ito nang kasingdali, kung hindi man mas madali, kaysa sa mga tao; dahil sa tingin nito ang simultaneity sa text ay isang malakas na signal. Upang masabi na ang isang kaganapan ay talagang humahantong sa isa pa; timing, mekanismo at, kung maaari, kailangan ang repeatability. Para sa bawat pag-aangkin ng sanhi na itinatag ng AI, itatanong namin "ano pang ebidensya ang nagpapatunay nito?" Subukan ito sa tanong.

Tip: Kapag nagla-log in sa AI, sa halip na isang text dump, kung maaari, mag-print muna ng query/filter at patakbuhin ito sa iyong sasakyan; Sa ganitong paraan pareho mong binabawasan ang sensitibong data at ihihiwalay ang window ng konteksto ng modelo sa mga talagang mahahalagang row.

Mga karaniwang pagkakamali

  • Pag-paste ng hilaw, hindi nakatatak na log. Pagbubunyag ng personal na data at mga lihim; isang malubhang paglabag sa privacy.
  • Pagbibigay ng buong araw nang sabay-sabay. Lumampas ito sa window ng konteksto, ang signal ay nalunod sa ingay.
  • Napagkakamalang ugnayan para sa sanhi. Ang relasyon sa oras na itinatag ng AI ay isang palatandaan, hindi katibayan.
  • Umaasa sa isang query na may gawa-gawang domain name. Maaaring magmungkahi ang modelo ng pangalan ng field ng log na hindi umiiral; i-verify gamit ang eskematiko.
  • Pag-publish ng postmortem nang hindi ito bini-verify. Ang mga katotohanan at bilang ng epekto ay dapat na kumpirmahin ng tao.

Sa buod

Ang AI ay isang makapangyarihang tool para matalo ang dami at ingay sa pagsusuri ng log: pagbubuod ng malalaking transcript, pagtatatag ng mga timeline, pagkuha ng mga pattern, at paghahanda ng mga postmortem sketch. Ngunit tandaan ang tatlong limitasyon: huwag mag-export ng sensitibong data nang hindi ito tinatakpan, i-filter at i-sample ito upang umangkop sa window ng konteksto, at i-verify ang bawat claim sa sanhi ng mga ito gamit ang mga sukatan at code. Ang ugnayan ay hindi sanhi; Nagbibigay ang AI ng mga pahiwatig, gagawin mo ang desisyon nang may ebidensya.

Gawain ng aplikasyon

Pumili ng 15–20 minutong window mula sa isang event o log ng environment ng pagsubok na mayroon ka. Itago muna ang personal na data at mga lihim (o gumawa ng synthetic log). Pagkatapos ay mag-extract ng kronolohiya at pinakamadalas na uri ng error mula sa AI gamit ang template na "buod ng log at timeline". Subukang i-verify ang root cause hypothesis na iniharap ng AI gamit ang isang sukatan o piraso ng code na mayroon ka: tumagal ba ang hypothesis, o ito ba ay isang mapanlinlang na ugnayan? Isulat ang iyong natuklasan sa isang pangungusap.

checklist

  • [ ] Tinatakpan ko ang personal na data at mga lihim bago ibigay ang log sa AI.
  • [ ] Binabawasan ko ang pagsusuri sa isang makitid na window ng oras at filter.
  • [ ] Nakikita ko ang mga ugnayan sa oras na itinatag ng AI bilang mga hypotheses, hindi causality.
  • [ ] Bine-verify ko ang root cause claim gamit ang mga sukatan at code.
  • [ ] Kinukumpirma ko na ang mga domain name ng mga query/filter na nabuo ko ay totoo.
  • [ ] Tao kong pinatutunayan ang mga katotohanan at numero sa postmortem sketch.