Mga nadagdag:
- Kakayahang maunawaan ang tatlong haligi ng observability (metric, log, trace) at ang apat na gintong signal at magkaroon ng artificial intelligence na bumubuo ng mga query sa PromQL, mga panuntunan sa alarma at mga dashboard
- Kakayahang maiwasan ang pagkapagod ng alarma sa pamamagitan ng pagpapanatiling nakatuon sa pagkilos ang mga alarma at nasa tamang pagkamadalian at pagsubok ng mga limitasyon laban sa makasaysayang data ng iyong sariling system
- Kakayahang maiwasan ang privacy at lihim na pagtagas sa pamamagitan ng pag-mask sa mga sensitibong lugar bago ibigay ang mga log sa artificial intelligence
Bagama't mukhang gumagana ang isang system, maaaring ito ay namamatay sa loob: dahan-dahang napupuno ang memorya, tumataas ang mga oras ng pagtugon, tumataas ang rate ng error. Ang tanging paraan upang mapansin ito ay ang patuloy na pagsubaybay sa system. Ang isang mas advanced na konsepto ay ang pagmamasid: ang kakayahang maunawaan kung ano ang nangyayari sa loob ng system sa pamamagitan ng pagtingin sa mga panlabas na palatandaan nito. Mayroong tatlong mga haligi ng pagmamasid, at ginagamit ng propesyonal na DevOps ang tatlo:
- Sukatan: Mga numerong halaga na sinusukat sa paglipas ng panahon — Paggamit ng CPU, bilang ng mga kahilingan, oras ng pagtugon, rate ng error. "Magkano?" sumasagot sa tanong.
- Log: Mga text record ng kaganapan na ginawa ng system—"naka-log in ang user", "nawala ang koneksyon sa database". "Ano ba talaga ang nangyari?" sumasagot sa tanong.
- Trace: Ang landas na sinusundan ng isang kahilingan habang dumadaan mula sa serbisyo patungo sa serbisyo sa loob ng system at ang tagal ng bawat hakbang. "Nasaan ang bagal?" sumasagot sa tanong.
Mga pinakakaraniwang tool: Prometheus para sa mga sukatan, Grafana para sa visualization, Loki/ELK para sa log, Jaeger/OpenTelemetry para sa bakas. Ang AI ay napakahusay sa pagsulat ng mga wika ng query (lalo na ng Prometheus' PromQL), mga panuntunan sa alarma, at mga pagsasaayos ng dashboard para sa mga tool na ito. Dito rin nasa pinakamalakas ang AI: pagbubuod ng malalaking tipak ng mga log at sukatan at pag-flag ng mga anomalya.
Linawin natin ang pagkakaiba sa pagitan ng pagsubaybay at obserbasyon sa isang pangungusap: ang pagsubaybay ay nagtatanong ng mga tanong na alam mo na (“Lampas ba sa 90% ang CPU?”); Ang observability ay ang makapagtanong ng mga tanong na hindi mo pa alam ("bakit ang kakaibang kabagalan na ito ay nangyayari lamang para sa isang partikular na customer sa isang partikular na oras?"). Ang mga modernong sistema ay napakasalimuot na hindi mo mahuhulaan ang lahat ng mga paraan ng kabiguan; Samakatuwid, ang kakayahang mangolekta ng mga rich metric, log, at trace at pagkatapos ay i-query ang mga ito nang malalim — ibig sabihin, observability — ay nagiging kritikal. Dito pumapasok ang AI kapag sinasagot ang "dating hindi kilalang tanong": mabilis nitong sinusuri ang hilaw na data na mayroon ka, nagmumungkahi ng mga pattern at anomalya, at makakarating ka sa ugat sa pamamagitan ng pag-verify sa mga pahiwatig na ito.
Hakbang-hakbang: ano at paano susubaybayan?
- Piliin ang mga tamang sukatan. Sa industriya, ang "apat na gintong signal" ay kinuha bilang batayan: latency, trapiko, mga error, saturation — kung gaano kapuno ang mapagkukunan. Ang mga ito ay nagbubuod sa kalusugan ng karamihan sa mga serbisyo.
- Kolektahin ang mga sukatan. Hayaang magpakita ang application ng isang endpoint na mababasa ni Prometheus.
- Mag-set up ng mga dashboard. I-visualize ang mga sukatang ito sa Grafana.
- Sumulat ng mga panuntunan sa alarma. Sino ang babalaan kapag nalampasan ang isang limitasyon at paano?
- Isentro ang mga log. Gawing mahahanap ang lahat ng mga log ng serbisyo sa isang lugar.
- Bawasan ang ingay. Masyadong maraming alarma ay lumilikha ng "alerto pagkapagod"; Nawawala ang mahalagang alarma.
Tip: Ang isang magandang alarma ay nakakatugon sa dalawang bagay: ito ay naaaksyunan at may tamang pagkaapurahan. Ang isang alarma na gumising sa isang tao sa 3am ay dapat na isang bagay na talagang nangangailangan ng interbensyon sa gabi. Huwag gisingin ang sinuman para sa isang bagay na hindi nangangailangan ng pagkilos sa sarili nitong, tulad ng "CPU 70%"; ipakita ito sa pisara.
Paano magsulat ng isang panuntunan sa alarma?
Ang isang alerto ay binubuo ng tatlong bahagi: kundisyon (kung aling sukatan ang lumampas sa aling threshold at kung gaano katagal), tagal ("para sa 5 minuto" upang maiwasan ang pag-trigger ng mga panandaliang pagbabago), at kahalagahan/aksyon (kanino, sa pamamagitan ng channel). Mahusay na itinatag ng AI ang tatlong ito nang may tamang konteksto. Halimbawa, ang pagsasalin ng panuntunan tulad ng "kritikal na alarma kung ang rate ng error ay lumampas sa 5% sa loob ng 5 minuto" sa PromQL ay isang split-second na gawain para sa AI — ngunit magpapasya ka kung ang threshold ay tama para sa iyong system.
Babala: Ang mga limitasyon ng alarma na iminungkahi ng AI ay mga pangkalahatang pagpapalagay. Ang normal na pag-load, pagpapaubaya, at epekto sa trabaho ng iyong system ay iba. Bago ka direktang maglagay ng threshold sa prod, titingnan mo ang iyong makasaysayang data at itanong "ilang beses na-trigger ang threshold na ito sa nakaraan, ilan sa mga iyon ang totoong problema?" Sagutin ang tanong.
Privacy ng log: kritikal na babala
Ang mga log ay ang pinakamadalas na napapansing pinagmumulan ng mga pagtagas. Maaaring hindi sinasadyang maglaman ng password, numero ng credit card, o personal na data ang isang log line (sa ilalim ng KVKK/GDPR). Kapag nag-paste ng mga log sa isang AI para sa pagsusuri:
- I-mask ang mga sensitibong lugar. Palitan ang mga value gaya ng token, password, email, ID number ng <REDACTED>.
- Magbigay ng mga halimbawa, hindi lahat. Sa halip na isang milyong linya, kadalasan ay sapat na ang ilang daang mga linyang kinatawan.
- Pumili ng sasakyang inaprubahan ng institusyon. Lalo na para sa mga log ng produksyon, gumamit ng tool na ang data ay hindi napupunta sa pagsasanay.
Apat na gintong signal at alarm table
hudyat
sinusukat ng
Halimbawa ng alarm threshold
pagmamadali
latency
oras ng pagtugon
p95 > 800 ms, 5 min
mataas
trapiko
Kahilingan/seg
Biglang 300% na pagtaas/pagbaba
daluyan
Error
Nabigong rate ng kahilingan
> 5%, 5 min
kritikal
Saturation
occupancy ng mapagkukunan
Disk > 85%
mataas
tatlong mini case
Case 1 — 400 linya ng log na na-summarized sa loob ng 30 segundo. Bumagal ang isang serbisyo. Ibinigay ng inhinyero ang nakamaskara na 400 linya ng log sa AI at sinabing, "ibuod ang mga umuulit na pattern ng error at tindi ng oras." Ipinakita ng AI na ang isang partikular na panlabas na tawag sa API ay nag-time out bawat 30 segundo. Nahanap ang ugat na sanhi sa loob ng 30 segundo; Ang manu-manong pag-scan ng mga log ay tatagal ng kalahating oras.
Kaso 2 — nalutas ang pagkapagod ng alarma. Ang isang koponan ay tumatanggap ng 200 alarma sa isang araw at binabalewala ang lahat ng ito — hanggang sa ang isang tunay na alarma sa pagkawala ay napapansin din. Ibigay sa AI ang lahat ng alituntunin ng alerto at itanong "alin ang hindi naaaksyunan at alin ang maaaring pagsamahin?" tanong nila. Ang bilang ng mga alarma ay bumaba sa 12 bawat araw; Ang bawat alarma ay siniseryoso na ngayon.
Kaso 3 — maagang nahuli ang maling threshold. Iminungkahi ni YZ ang "Babala kapag 95% puno" para sa disk. Ang inhinyero ay tumingin sa makasaysayang data: sa sandaling ang disk ay umabot sa 95% nagkaroon ng kaunting oras para sa interbensyon. Ibinaba nito ang threshold sa 80% at nagdagdag ng pangalawang alarma batay sa "rate ng paglago." Napigilan ng pag-verify ang isang aktwal na midnight outage.
Apat na maaaring kopyahin na mga template
1) Pagbubuod ng log (nakamaskara):
Suriin ang halimbawa ng log sa ibaba (Ibinalik ko ang mga sensitibong halaga sa <REDACTED>). Bigyan mo ako ng: (1) umuulit na mga pattern ng error, (2) konsentrasyon sa paglipas ng panahon, (3) malamang na ugat, at (4) 3 sukatan na titingnan ko para ma-verify. Log: [LINES]
2) Pagbuo ng panuntunan ng alarm:
Sumulat ng panuntunan sa alarma para sa Prometheus/Alertmanager: Bumuo ng [SEVERITY] alarm kung ang [THRESHOLD] ay lumampas sa [METRIC][DURATION]. Ang panuntunan ay dapat na nakatuon sa pagkilos at may kasamang anotasyon at field ng link ng runbook. Ipaliwanag ang PromQL at isulat kung bakit makatwiran ang threshold na ito.
3) Pagsusulat/pagdedeklara ng query sa PromQL:
Sumulat ng isang query sa PromQL na sumusukat sa: [EX. 5xxerror rate percentage sa huling 5 minuto]. Ipaliwanag ang query nang hakbang-hakbang. Pagkatapos ay sabihin sa akin kung ano dapat ang malusog na hanay para sa halagang ito.
4) Disenyo ng dashboard:
Magdisenyo ng Grafana dashboard para sa [SERVICE]: sa aling mga panel ko dapat ipakita ang apat na gintong signal(latency, traffic, error, saturation)? Magmungkahi ng sukatan, uri ng visualization at makatwirang threshold para sa bawat panel. Layunin: upang makita ang kalagayan ng kalusugan ng isang guwardiya sa loob ng 10 segundo.
Mahinang prompt / Malakas na prompt
Mahina: "Ano ang nasa log na iyon?" (sinusundan ng 5000 linya ng raw log, mga token sa loob nito)
Resulta: naglalabas ka ng mga lihim at ang AI ay nagbibigay ng hindi naka-target, mababaw na buod.
Strong: "Hanapin ang mga umuulit na pattern ng error at intensity ng oras sa 300-line masked log na halimbawa sa ibaba; sabihin sa akin ang pinaka-malamang na ugat na sanhi at ang mga sukatan na titingnan ko para ma-verify. Ginawa ko ang mga token na <REDACTED>."
Pagkakaiba: ang pangalawang prompt ay nagbibigay ng nakamaskara at nakatutok na halimbawa, na humihingi ng malinaw na pagsusuri na output; Ito ay parehong ligtas at kapaki-pakinabang.
Mga karaniwang pagkakamali
- I-paste ang log sa AI nang hindi tinatakpan ito. Ang pinakakaraniwang lihim/personal na pagtagas ng data.
- Pagtatakda ng mga alarma para sa lahat. Ang pagkapagod ng alarma ay bumabaon ng tunay na alarma.
- Hindi naaaksyunan na alarma. Ito ay babala na ingay na walang magagawa.
- Pagtanggap sa threshold ng AI nang walang tanong. Ang threshold ay dapat itakda ayon sa kasaysayan ng iyong system.
- Nakatingin lang sa sukatan. Kung walang log at bakas, ang ugat na sanhi ay hindi mahahanap sa halos lahat ng oras.
- Hindi nagtatakda ng oras ng alarma (para sa). Ang mga panandaliang pagbabagu-bago ay gumagawa ng mga maling alarma.
Sa buod
Pagmamasid; Ito ay ang kakayahang maunawaan ang loob ng system mula sa labas gamit ang mga sukatan, log at bakas. Ang apat na gintong signal (latency, traffic, error, saturation) ay nagbubuod sa kalusugan ng karamihan sa mga serbisyo. Napakalakas ng AI sa pagsulat ng mga query sa PromQL, mga panuntunan sa alarma at mga dashboard, at sa pagbubuod ng malalaking piraso ng mga log at paghahanap ng mga anomalya. Ngunit responsibilidad mong i-verify ang mga limitasyon ng alarma laban sa kasaysayan ng sarili mong system, panatilihing nakatuon sa pagkilos ang mga alarma, at huwag kailanman magbahagi ng mga log nang hindi tinatakpan ang mga ito.
Gawain ng aplikasyon
Para sa isang serbisyo (o isang sample na serbisyo): (1) Gumawa ng panuntunan sa alarma para sa rate ng error gamit ang template na "Pagbuo ng panuntunan ng alarm" at itakda ang iminungkahing threshold sa "ilang beses na itong nag-trigger sa nakaraan?" Subukan ito sa tanong; (2) i-mask ang isang log sample na mayroon ka at ipasuri ito gamit ang template na "Log summarization"; (3) tandaan kung aling sukatan ang iyong titingnan upang kumpirmahin ang pinaka-malamang na sanhi.
checklist
- [ ] Pinili ko ang mga sukatan na susubaybayan batay sa apat na gintong signal.
- [ ] Tinakpan ko ang lahat ng mga log na ibinigay ko sa AI sa mga tuntunin ng mga sensitibong lugar.
- [ ] Na-verify ko na ang bawat alarma ay nakatuon sa pagkilos at sa tamang pagkaapurahan.
- [ ] Sinubukan ko ang mga limitasyon ng alarma laban sa makasaysayang data ng aking system.
- [ ] Na-filter ko ang mga agarang pagbabago sa pamamagitan ng pagdaragdag ng (tagal) sa mga alarma.
- [ ] Gumamit ako ng metric + log + trace nang magkasama para sa root cause.