SRE (Site Reliability Engineering) minangka pendekatan kanggo njamin kasedhiyan proyek web. Iki dianggep minangka kerangka kanggo DevOps lan ngobrol babagan carane entuk sukses ing ngetrapake praktik DevOps. Terjemahan ing artikel iki Bab 6 Monitoring Sistem Distribusi buku Site Reliability Engineering saka Google. Aku nyiapake terjemahan iki dhewe lan ngandelake pengalamanku dhewe kanggo mangerteni proses ngawasi. Ing saluran telegram @monitorim_it и blog ing Sedheng Aku uga nerbitake link menyang terjemahan Bab 4 saka buku sing padha babagan tujuan tingkat layanan.

Terjemahan dening kucing. Seneng maca!

Tim SRE Google duwe prinsip dhasar lan praktik paling apik kanggo nggawe sistem pemantauan lan kabar sing sukses. Bab iki menehi tuntunan babagan masalah apa sing bisa ditemoni pengunjung kaca web lan cara ngatasi masalah sing nggawe kaca web angel ditampilake.

Definisi

Ora ana kosakata siji sing digunakake kanggo ngrembug topik sing ana gandhengane karo pemantauan. Malah ing Google, istilah ing ngisor iki ora umum digunakake, nanging kita bakal nampilake interpretasi sing paling umum.

Ngawasi

Koleksi, pangolahan, agregasi lan tampilan data kuantitatif ing wektu nyata babagan sistem: jumlah panjalukan lan jinis panjalukan, jumlah kesalahan lan jinis kesalahan, wektu pangolahan panjalukan lan wektu aktif server.

Pemantauan kothak putih

Ngawasi adhedhasar metrik sing ditampilake dening komponen sistem internal, kalebu log, metrik profil Mesin Virtual Java, utawa metrik panangan HTTP sing ngasilake statistik internal.

Ngawasi kothak ireng

Nguji prilaku aplikasi saka sudut pandang pangguna.

Dashboard

Antarmuka (biasane web) sing nyedhiyakake ringkesan indikator kesehatan utama layanan. Dashboard bisa uga duwe saringan, kemampuan kanggo milih indikator sing ditampilake, lsp. Antarmuka dirancang kanggo ngenali indikator sing paling penting kanggo pangguna. Dashboard uga bisa nampilake informasi kanggo staf dhukungan teknis: antrian panjalukan, dhaptar kesalahan prioritas dhuwur, lan insinyur sing ditugasake kanggo area tanggung jawab tartamtu.

Tandha (kabar)

Kabar sing dimaksudake kanggo ditampa dening wong liwat email utawa cara liyane, sing bisa uga dipicu dening kesalahan utawa nambah antrian panyuwunan. Kabar diklasifikasikake minangka: tiket, tandha email lan pesen pesen cepet.

Root sabab

Cacat piranti lunak utawa kesalahan manungsa sing, yen wis didandani, ora bakal kedadeyan maneh. Masalah kasebut bisa uga duwe sawetara panyebab utama: otomatisasi proses sing ora cukup, cacat piranti lunak, elaborasi logika aplikasi sing ora cukup. Saben faktor kasebut bisa dadi sababe, lan saben faktor kasebut kudu diilangi.

Node lan mesin (simpul lan mesin)

Istilah sing bisa diijolake kanggo ngrujuk marang siji conto aplikasi sing mlaku ing server fisik, mesin virtual, utawa wadhah. Siji mesin bisa dadi tuan rumah sawetara layanan. Layanan bisa:

• disambungake kanggo saben liyane: contone, server caching lan server web;
• layanan sing ora ana hubungane ing piranti keras: contone, gudang kode lan tuntunan kanggo sistem konfigurasi, kayata Wayang utawa sirah.

push

Sembarang owah-owahan ing konfigurasi piranti lunak.

Napa perlu ngawasi?

Ana sawetara alasan kenapa aplikasi kudu dipantau:

Analisis tren jangka panjang

Sepira gedhene database lan sepira cepet tuwuh? Kepiye jumlah pangguna saben dina ganti?

Perbandingan kinerja

Apa panjaluk luwih cepet ing Acme Bucket of Bytes 2.72 dibandhingake Ajax DB 3.14? Pinten luwih apik yen panjalukan di-cache sawise munculé simpul tambahan? Apa situs mlaku luwih alon dibandhingake minggu kepungkur?

Tandha (kabar)

Ana sing rusak lan ana sing kudu ndandani. Utawa soko bakal break rauh lan wong kudu mriksa enggal.

Nggawe dashboard

Dashboards kudu njawab pitakonan dhasar lan kalebu soko saka "4 sinyal emas" - telat (latensi), lalu lintas (lalu lintas), kesalahan (kesalahan) lan ukuran beban (saturasi).

Nindakake analisis retrospektif (debugging)

Tundha pangolahan panjalukan saya tambah, nanging apa maneh kedadeyan ing wektu sing padha?
Sistem ngawasi migunani minangka sumber data kanggo sistem intelijen bisnis lan kanggo nggampangake analisis insiden keamanan. Amarga buku iki fokus ing bidang teknik sing SRE duwe keahlian, kita ora bakal ngrembug babagan teknik pemantauan ing kene.

Pemantauan lan tandha ngidini sistem ngandhani yen wis rusak utawa bakal rusak. Nalika sistem ora bisa kanthi otomatis ndandani dhewe, kita pengin manungsa nganalisa tandha, nemtokake manawa masalah kasebut isih aktif, ngrampungake, lan nemtokake sababe. Yen sampeyan ora audit komponen sistem, sampeyan ora bakal nampa tandha mung amarga "soko misale jek sing sethitik aneh."

Mbebani wong kanthi kabar minangka panggunaan wektu karyawan sing cukup larang. Yen karyawan lagi kerja, tandha bakal ngganggu proses kerja. Yen pegawe ana ing omah, tandha bakal ngganggu wektu pribadi lan bisa uga turu. Nalika tandha kedadean kerep banget, karyawan ngecek, mateni, utawa nglirwakake tandha mlebu. Saka wektu kanggo wektu padha nglirwakake tandha nyata, kang masked dening acara gangguan. Gangguan layanan bisa tahan suwe amarga kedadeyan gangguan nyegah masalah kasebut supaya bisa didiagnosis lan didandani kanthi cepet. Sistem peringatan sing efektif duwe rasio sinyal-kanggo-noise sing apik.

Nyetel pangarepan sing cukup kanggo sistem ngawasi

Nyiyapake ngawasi kanggo aplikasi sing rumit minangka tugas teknik sing rumit. Malah kanthi prasarana koleksi, tampilan, lan alat sing penting, tim Google SRE saka 10-12 anggota biasane kalebu siji utawa loro wong sing tujuane utamane yaiku mbangun lan njaga sistem pemantauan. Jumlah iki saya suda sajrone wektu nalika kita nggabungake lan fokus ing infrastruktur pemantauan, nanging saben tim SRE biasane duwe paling ora siji wong sing khusus kanggo ngawasi. Kita kudu ngomong sing nalika ngawasi sistem dashboards cukup menarik kanggo dipikir, tim SRE kasebut kanthi teliti, supaya kahanan sing mbutuhake wong kanggo ndeleng ing layar kanggo ngawasi masalah.

Sakabèhé, Google wis pindhah menyang sistem pemantauan sing prasaja lan cepet kanthi alat analisis sawise-kasunyatan sing optimal. Kita ngindhari sistem "sihir" sing nyoba prédhiksi ambang utawa kanthi otomatis ndeteksi sababe. Sensor sing ndeteksi isi sing ora disengaja ing panjalukan pangguna pungkasan mung minangka conto kontra; Anggere sensor iki tetep prasaja, padha bisa cepet ndeteksi nimbulaké anomali serius. Format liyane kanggo nggunakake data pemantauan, kayata perencanaan kapasitas utawa prakiraan lalu lintas, luwih rumit. Observasi sajrone wektu sing suwe banget (sasi utawa taun) kanthi tingkat sampling sing sithik (jam utawa dina) bakal mbukak tren jangka panjang.

Tim Google SRE wis sukses campuran karo hierarki dependensi sing kompleks. Kita arang nggunakake aturan kaya "yen aku ngerti yen database alon, aku njaluk tandha yen database alon, yen ora, aku njaluk tandha yen situs alon." Aturan adhedhasar dependensi biasane nuduhake bagean sing ora bisa diganti saka sistem kita, kayata sistem kanggo nyaring lalu lintas pangguna menyang pusat data. Contone, "yen nyaring lalu lintas menyang pusat data dikonfigurasi, aja menehi tandha babagan keterlambatan ing proses panjalukan pangguna" minangka aturan umum kanggo tandha saka pusat data. Sawetara tim ing Google ndhukung hierarki dependensi rumit amarga infrastruktur kita duwe tingkat refactoring sing terus-terusan.

Sawetara gagasan sing diterangake ing bab iki isih relevan: tansah ana kesempatan kanggo mindhah luwih cepet saka gejala menyang sabab, utamane ing sistem sing terus ganti. Mulane, nalika bab iki njlentrehake sawetara tujuan kanggo sistem ngawasi lan carane entuk gol kasebut, penting yen sistem ngawasi prasaja lan bisa dingerteni kabeh wong ing tim.

Kajaba iku, kanggo njaga tingkat gangguan lan tingkat sinyal dhuwur, pendekatan kanggo ngawasi aset sing diwaspadai kudu gampang banget lan dipercaya. Aturan sing ngasilake bebaya kanggo wong kudu gampang dingerteni lan menehi masalah sing jelas.

Gejala versus sabab

Sistem pemantauan sampeyan kudu mangsuli rong pitakon: "apa sing rusak" lan "kok rusak."
"Apa pecah" ngomong babagan gejala kasebut, lan "kenapa pecah" ngomong babagan sababe. Tabel ing ngisor iki nuduhake conto sambungan kasebut.

Gejala
Alesan

Njupuk HTTP Error 500 utawa 404
Server database nolak sambungan

Respon server alon
Panggunaan CPU dhuwur utawa kabel Ethernet sing rusak

Pangguna ing Antartika ora nampa GIF kucing
CDN sampeyan sengit karo ilmuwan lan kucing, mula sawetara alamat IP wis diselehake ing daftar ireng

Konten pribadi wis kasedhiya saka ngendi wae
Rollout rilis piranti lunak anyar nggawe firewall lali kabeh ACL lan ngidini kabeh wong mlebu

"Apa" lan "kok" sawetara saka pamblokiran bangunan paling penting kanggo nggawe sistem ngawasi apik karo sinyal maksimum lan gangguan minimal.

Kothak ireng vs kothak putih

Kita gabungke ngawasi White-box ekstensif karo ngawasi Black-box andhap asor kanggo metrik kritis. Cara paling gampang kanggo mbandhingake Black-box menyang White-box yaiku Black-box fokus ing gejala lan reaktif tinimbang ngawasi proaktif: "sistem ora bisa digunakake kanthi bener saiki." Kothak putih gumantung marang kemampuan verifikasi internal sistem: log acara utawa server web. Mangkono, White-box ngidini sampeyan ndeteksi masalah sing bakal teka, kesalahan sing katon minangka panyuwunan maneh, lsp.

Elinga yen ing sistem multi-lapisan, gejala ing area tanggung jawab insinyur minangka gejala ing area tanggung jawab insinyur liyane. Contone, kinerja database wis suda. Maca database alon minangka gejala saka database SRE sing ndeteksi. Nanging, kanggo SRE ngarep-mburi ngamati situs web alon, sabab saka database alon padha maca database alon. Mulane, ngawasi kothak putih kadhangkala fokus ing gejala lan kadhangkala fokus sabab, gumantung saka jembare.

Nalika ngumpulake telemetri kanggo debugging, ngawasi White-box dibutuhake. Yen server web alon-alon nanggapi pitakon database, sampeyan kudu ngerti sepira cepet server web komunikasi karo database lan sepira cepet nanggapi. Yen ora, sampeyan ora bakal bisa mbedakake antarane server database alon lan masalah jaringan antarane server web lan database.

Pemantauan kothak ireng nduweni kaluwihan utama nalika ngirim tandha: sampeyan bakal micu kabar menyang panampa nalika masalah wis nyebabake gejala nyata. Ing sisih liya, ngawasi ora ana gunane kanggo masalah Black-box sing durung muncul nanging wis cedhak.

Papat sinyal emas

Papat sinyal pemantauan emas yaiku latensi, lalu lintas, kesalahan, lan jenuh. Yen sampeyan mung bisa ngukur papat metrik sistem pangguna, fokus ing papat kasebut.

Tundha

Wektu sing dibutuhake kanggo ngolah panjaluk kasebut. Penting kanggo mbedakake antarane latensi panjalukan sing sukses lan ora kasil. Contone, kesalahan HTTP 500 sing disebabake kelangan sambungan menyang database utawa backend liyane bisa didiagnosis kanthi cepet, nanging kesalahan HTTP 500 bisa uga nuduhake panjaluk sing gagal. Nemtokake pengaruh kesalahan 500 ing latensi sakabèhé bisa nyebabake kesimpulan sing salah. Ing tangan liyane, kesalahan alon malah kesalahan cepet! Mulane, penting kanggo ngawasi latensi kesalahan tinimbang mung nyaring kesalahan.

lalu lintas

Jumlah panjalukan menyang sistem sampeyan diukur ing metrik sistem tingkat dhuwur. Kanggo layanan web, pangukuran iki biasane nuduhake jumlah panjalukan HTTP per detik, dibagi karo sifat panjalukan (contone, isi statis utawa dinamis). Kanggo sistem streaming audio, pangukuran iki bisa fokus ing kacepetan I/O jaringan utawa jumlah sesi simultan. Kanggo sistem panyimpenan nilai kunci, pangukuran iki bisa dadi transaksi utawa asil panelusuran per detik.

Kasalahan

Iki minangka tingkat panjaluk sing gagal sing eksplisit (contone HTTP 500), implisit (contone HTTP 200 nanging digabungake karo konten sing ora sah) utawa kebijakan (contone "Yen sampeyan nanggapi respon sajrone sedetik, siji detik minangka kesalahan"). Yen kode respon HTTP ora cukup kanggo nyatakake kabeh kondisi gagal, protokol sekunder (internal) bisa uga dibutuhake kanggo ndeteksi kegagalan parsial. Ngawasi kabeh panjalukan sing gagal bisa uga ora informatif, dene tes sistem end-to-end bakal mbantu ndeteksi manawa sampeyan ngolah konten sing salah.

Kejenuhan

Metrik nuduhake sepira intensif layanan sampeyan digunakake. Iki ukuran ngawasi sistem sing ngenali sumber daya sing paling diwatesi (Contone, ing sistem memori-diwatesi, nuduhake memori, ing I / O-sistem, nuduhake nomer aku / Os). Elinga yen akeh sistem ngrusak kinerja sadurunge tekan 100% pemanfaatan, supaya duwe tujuan pemanfaatan penting.

Ing sistem sing rumit, saturasi bisa dilengkapi karo pangukuran beban tingkat sing luwih dhuwur: apa layanan sampeyan bisa nangani lalu lintas kaping pindho kanthi bener, mung nangani lalu lintas 10% luwih akeh, utawa nangani lalu lintas sing luwih sithik tinimbang saiki? Kanggo layanan prasaja sing ora duwe paramèter sing ngganti kerumitan panjalukan (Contone, "Aku ora menehi apa-apa" utawa "Aku butuh integer monotoni tunggal unik"), sing arang ngganti konfigurasi, Nilai test mbukak statis bisa cukup. Nanging, kaya sing wis dibahas ing paragraf sadurunge, umume layanan kudu nggunakake sinyal ora langsung kayata panggunaan CPU utawa bandwidth jaringan, sing duwe wates ndhuwur sing dikenal. Nambah latensi asring dadi indikator jenuh. Ngukur wektu nanggepi persentil kaping 99 ing jendhela cilik (contone, siji menit) bisa menehi sinyal kejenuhan sing awal banget.

Pungkasan, jenuh uga digandhengake karo prediksi babagan kejenuhan sing bakal teka, contone: "Katon database sampeyan bakal ngisi hard drive sajrone 4 jam."

Yen sampeyan ngukur kabeh papat sinyal emas lan nalika ana masalah karo salah siji metrik (utawa, ing kasus kejenuhan, masalah cedhak), sampeyan menehi tandha wong, layanan sampeyan bakal luwih utawa kurang dijamin dening ngawasi.

Kuwatir babagan "buntut" (utawa instrumentasi lan kinerja)

Nalika nggawe sistem ngawasi saka awal, ana godaan kanggo ngembangake sistem adhedhasar nilai rata-rata: latensi rata-rata, panggunaan CPU rata-rata simpul, utawa kepenuhan database rata-rata. Bebaya saka rong conto pungkasan wis jelas: prosesor lan basis data dibuwang kanthi cara sing ora bisa ditebak. Padha ditrapake kanggo wektu tundha. Yen sampeyan mbukak layanan web kanthi latensi rata-rata 100ms kanthi 1000 panjalukan per detik, 1% panjalukan bisa njupuk 5 detik. Yen pangguna gumantung ing macem-macem layanan web kasebut, persentil kaping 99 saka siji mburi bisa gampang dadi wektu respon median saka frontend.

Cara paling gampang kanggo mbedakake antarane panjaluk rata-rata alon lan buntut sing alon banget yaiku ngumpulake pangukuran panjalukan sing ditulis ing statistik (alat sing apik kanggo ditampilake yaiku histogram) tinimbang latensi sing nyata: pira panjaluk sing dilayani layanan sing njupuk antarane 0 ms lan 10 ms, antarane 10 ms lan 30 ms, antarane 30 ms lan 100 ms, antarane 100 ms lan 300 ms, etc. Ngembangake wates histogram kira-kira eksponensial (kanthi faktor kira-kira 3) asring cara prasaja kanggo nggambarake distribusi saka panjalukan.

Milih tingkat rinci sing cocog kanggo pangukuran

Unsur sing beda saka sistem kudu diukur ing tingkat rinci sing beda. Tuladhane:

• Ngawasi panggunaan CPU sajrone sawetara wektu ora bakal nuduhake lonjakan jangka panjang sing nyebabake latensi dhuwur.
• Ing sisih liya, kanggo layanan web sing nargetake ora luwih saka 9 jam downtime saben taun (99,9% uptime taunan), mriksa respon HTTP 200 luwih saka sepisan utawa kaping pindho saben menit bisa uga ora perlu.
• Kajaba iku, mriksa papan hard drive kanggo kasedhiyan 99,9% luwih saka sapisan saben 1-2 menit mbokmenawa ora perlu.

Ati-ati babagan carane sampeyan nggawe granularitas pangukuran sampeyan. Ngumpulake beban CPU sapisan saben detik bisa nyedhiyakake data sing menarik, nanging pangukuran sing kerep banget bisa larang banget kanggo ngumpulake, nyimpen, lan nganalisa. Yen gol ngawasi mbutuhake granularitas sing dhuwur lan ora mbutuhake respon sing dhuwur, sampeyan bisa nyuda biaya kasebut kanthi nyetel koleksi metrik ing server banjur nyetel sistem eksternal kanggo ngumpulake lan nglumpukake metrik kasebut. Apa sampeyan bisa:

1. Ukur beban CPU saben detik.
2. Ngurangi rincian nganti 5%.
3. Metrik agregat saben menit.

Strategi iki bakal ngidini sampeyan ngumpulake data kanthi granularitas sing dhuwur tanpa mbutuhake analisis lan overhead panyimpenan sing dhuwur.

Minangka prasaja sabisa, nanging ora luwih prasaja

Overlay saka syarat sing beda ing ndhuwur saben liyane bisa nyebabake sistem pemantauan sing rumit banget. Contone, sistem sampeyan bisa uga duwe unsur rumit ing ngisor iki:

• Tandha miturut ambang sing beda kanggo latensi pangolahan panjalukan, ing persentil sing beda, kanggo kabeh jinis indikator sing beda.
• Nulis kode tambahan kanggo ndeteksi lan ngenali bisa nimbulaké.
• Nggawe dashboard sing gegandhengan kanggo saben panyebab masalah.

Sumber komplikasi potensial ora bakal ana pungkasane. Kaya kabeh sistem piranti lunak, ngawasi bisa dadi rumit nganti dadi rapuh lan angel diganti lan dijaga.

Mula, desain sistem pemantauan sampeyan supaya bisa disederhanakake. Nalika milih apa sing kudu dilacak, elinga ing ngisor iki:

• Aturan sing paling kerep nyekel kedadeyan nyata kudu prasaja, bisa diprediksi lan bisa dipercaya.
• Konfigurasi kanggo ngumpulake data, agregasi, lan tandha sing jarang ditindakake (contone, kurang saka seprapat kanggo sawetara tim SRE) kudu dibusak.
• Metrik sing diklumpukake nanging ora ditampilake ing dashboard pratinjau utawa digunakake dening tandha apa wae minangka calon sing bakal dibusak.

Ing Google, koleksi metrik dhasar lan agregasi, digabungake karo tandha lan dasbor, bisa uga minangka sistem sing relatif mandiri (sistem pemantauan Google bener-bener dipérang dadi sawetara subsistem, nanging wong biasane ngerti kabeh aspek subsistem kasebut). Bisa uga nggodho kanggo nggabungake pemantauan karo teknik liyane kanggo mriksa sistem sing kompleks: profil sistem sing rinci, proses debugging, rincian nelusuri babagan pengecualian utawa kegagalan, tes muatan, koleksi lan analisis log, utawa inspeksi lalu lintas. Nalika umume perkara kasebut duwe persamaan karo pemantauan dhasar, campuran kasebut bakal ngasilake asil sing akeh banget lan nggawe sistem sing rumit lan rapuh. Kaya ing pirang-pirang aspek pangembangan piranti lunak, ndhukung sistem sing beda-beda kanthi titik integrasi sing jelas, prasaja, lan ora ana gandhengane minangka strategi paling apik (contone, nggunakake API web kanggo njupuk data agregat ing format sing bisa tetep konsisten sajrone wektu sing suwe. ).

Nyambungake Prinsip Bebarengan

Prinsip-prinsip sing dibahas ing bab iki bisa digabung dadi filosofi ngawasi lan menehi tandha sing disetujoni lan ditindakake dening tim Google SRE. Adhering kanggo filosofi ngawasi iki seng di pengeni, iku titik wiwitan apik kanggo nggawe utawa mbenakake metodologi alerting, lan bisa mbantu takon pitakonan tengen fungsi operasi, preduli saka ukuran organisasi utawa kerumitan layanan utawa sistem.

Nalika nggawe aturan ngawasi lan menehi tandha, takon pitakonan ing ngisor iki bisa mbantu sampeyan ngindhari positip palsu lan tandha sing ora perlu:

• Apa aturan iki ndeteksi kahanan sistem sing ora bisa dideteksi sing penting, nelpon kanggo tumindak, lan mesthi mengaruhi pangguna?
• Apa aku bisa nglirwakake bebaya iki yen ngerti iku entheng? Nalika lan ngapa aku bisa nglirwakake bebaya iki lan kepiye carane bisa nyegah skenario iki?
• Apa tandha iki tegese pangguna kena pengaruh negatif? Apa ana kahanan sing pangguna ora kena pengaruh negatif, kayata liwat nyaring lalu lintas utawa nalika nggunakake sistem tes sing tandha kudu disaring?
• Apa aku bisa tumindak kanggo nanggepi tandha iki? Apa langkah-langkah kasebut penting utawa bisa ngenteni nganti esuk? Apa tumindak bisa otomatis kanthi aman? Apa tumindak iki bakal dadi solusi jangka panjang utawa solusi jangka pendek?
• Sawetara wong entuk pirang-pirang tandha kanggo masalah iki, mula apa ana cara kanggo nyuda jumlah tandha?

Pitakonan iki nggambarake filosofi dhasar babagan tandha lan sistem peringatan:

• Saben ana tandha mlebu, aku kudu langsung nanggepi. Aku bisa nanggepi cepet kaping pirang-pirang dina sadurunge kesel.
• Saben tandha kudu cocog.
• Saben respon kanggo tandha kudu mbutuhake campur tangan manungsa. Yen kabar bisa diproses kanthi otomatis, mesthine ora teka.
• Tandha kudu babagan masalah utawa acara anyar sing durung ana sadurunge.

Pendekatan iki blurs beda tartamtu: yen tandha nglegakake papat kahanan sadurungé, iku ora Matter apa tandha dikirim saka Putih-kothak utawa Black-Box sistem ngawasi. Pendekatan iki uga nguatake beda-beda tartamtu: luwih becik nglampahi gaweyan luwih akeh kanggo ngenali gejala tinimbang panyebab; nalika nerangake nimbulaké, sampeyan mung kudu padha sumelang ing bab nimbulaké ono.

Pemantauan jangka panjang

Ing lingkungan produktivitas saiki, sistem ngawasi ngawasi sistem produksi sing terus berkembang kanthi arsitektur piranti lunak, karakteristik beban kerja, lan target kinerja. Tandha sing saiki angel diotomatisasi bisa dadi umum, bisa uga kudu ditangani. Ing titik iki, wong kudu nemokake lan ngilangi panyebab masalah kasebut; yen resolusi kuwi ora bisa, respon kanggo tandha mbutuhake otomatis lengkap.

Penting yen keputusan ngawasi digawe kanthi tujuan jangka panjang. Saben tandha sing mlaku dina iki ngganggu wong kanggo nambah sistem sesuk, mula asring ana pangurangan kasedhiyan utawa kinerja sistem produktif kanggo wektu sing dibutuhake kanggo nambah sistem pemantauan ing jangka panjang. Ayo goleki rong conto kanggo nggambarake fenomena iki.

Bigtable SRE: A Tale of Over-Alert

Infrastruktur internal Google biasane diwenehake lan diukur miturut tingkat layanan (SLO). Akeh taun kepungkur, layanan Bigtable SLO adhedhasar kinerja rata-rata transaksi sintetik simulasi klien urip. Amarga masalah ing Bigtable lan tingkat tumpukan panyimpenan sing luwih murah, kinerja rata-rata didorong dening buntut "gedhe": 5% pitakon sing paling awon asring luwih alon tinimbang liyane.

Kabar email dikirim nalika ambang SLO wis nyedhaki, lan tandha utusan dikirim nalika SLO ngluwihi. Loro-lorone jinis tandha dikirim cukup asring, nggunakake wektu teknik sing ora bisa ditampa: tim kasebut ngentekake wektu akeh kanggo ngurutake tandha-tandha kanggo nemokake sawetara sing bener-bener relevan. Kita asring ora kejawab masalah sing bener-bener mengaruhi pangguna amarga mung sawetara tandha kanggo masalah khusus kasebut. Akeh tandha sing ora penting amarga masalah sing bisa dingerteni ing infrastruktur lan diproses kanthi standar, utawa ora diproses.

Kanggo ngatasi kahanan kasebut, tim njupuk pendekatan telung cabang: Nalika kerja keras kanggo ningkatake kinerja Bigtable, kita sementara nyetel target SLO dadi persentil kaping 75 kanggo latensi respon pitakon. Kita uga mateni tandha email amarga ana akeh sing ora bisa nggunakake wektu kanggo diagnosa.

Strategi iki ngidini kita kamar ambegan kanggo miwiti ndandani masalah long-term ing Bigtable lan lapisan ngisor saka tumpukan panyimpenan, tinimbang terus-terusan ndandani masalah taktik. Insinyur bisa nindakake karya tanpa dibombardir kanthi tandha. Pungkasane, nundha sementara proses tandha ngidini kita nambah kualitas layanan.

Gmail: Bisa Diprediksi, Tanggapan Manungsa Algoritma

Ing wiwitan, Gmail dibangun ing sistem manajemen proses Workqueue sing diowahi sing dirancang kanggo ngolah potongan indeks telusuran. Workqueue diadaptasi kanggo proses sing dawa lan banjur ditrapake ing Gmail, nanging sawetara kewan omo ing kode panjadwal opaque mbuktekaken angel banget kanggo ndandani.

Ing wektu iku, pemantauan Gmail wis kabentuk supaya tandha bakal dipicu nalika tugas individu dibatalake nggunakake Workqueue. Pendekatan iki ora becik, amarga sanajan ing wektu iku, Gmail nindakake pirang-pirang ewu tugas, sing saben-saben diwenehake menyang bagian sekedhik saka persen pangguna. Kita prihatin banget babagan nyedhiyakake pangguna Gmail kanthi pengalaman pangguna sing apik, nanging nangani akeh tandha ora bisa digayuh.

Kanggo ngatasi masalah iki, Gmail SRE nggawe alat kanggo mbantu debug panjadwal kanthi paling apik kanggo nyilikake pengaruhe marang pangguna. Tim kasebut duwe sawetara diskusi babagan apa mung ngotomatisasi kabeh siklus saka panemuan masalah liwat remediasi nganti solusi jangka panjang ditemokake, nanging ana sing kuwatir yen solusi kasebut bakal tundha kanggo ngrampungake masalah kasebut.

Ketegangan iki umum ing tim lan asring nggambarake kekurangan kapercayan babagan disiplin diri: nalika sawetara anggota tim pengin menehi wektu kanggo ndandani sing bener, wong liya kuwatir yen perbaikan pungkasan bakal dilalekake lan perbaikan sementara bakal ditindakake ing salawas-lawase. Masalah iki kudu digatekake amarga gampang banget kanggo ndandani masalah kanggo sementara tinimbang nggawe kahanan permanen. Manajer lan staf teknis nduweni peran penting kanggo ngleksanakake perbaikan jangka panjang, ndhukung lan menehi prioritas perbaikan jangka panjang sanajan sawise "nyeri" awal suda.

Tandha reguler, bola-bali lan respon algoritma kudu dadi gendera abang. Wegah tim sampeyan kanggo ngotomatisasi tandha iki tegese tim ora yakin manawa bisa dipercaya algoritma kasebut. Iki minangka masalah serius sing kudu ditanggulangi.

jangka panjang

Tema umum nyambungake conto Bigtable lan Gmail: kompetisi antarane kasedhiyan jangka pendek lan jangka panjang. Asring, gaweyan kuwat bisa bantuan sistem pecah entuk kasedhiyan dhuwur, nanging dalan iki biasane short-urip, fraught karo burnout tim lan katergantungan ing nomer cilik saka anggota tim heroik padha.

Dikontrol, nyuda kasedhiyan jangka pendek asring nglarani, nanging sacara strategis penting kanggo stabilitas sistem jangka panjang. Penting ora kanggo ndeleng saben tandha ing isolasi, nanging kanggo nimbang apa tingkat sakabèhé saka volume tandha ndadékaké menyang sehat, sistem diakses mlaku karo tim sregep lan prognosis sarujuk. Kita nganalisa statistik frekuensi tandha (biasane ditulis minangka kedadeyan saben shift, ing ngendi kedadeyan bisa dumadi saka pirang-pirang insiden sing gegandhengan) ing laporan saben wulan menyang manajemen, ngidini para pembuat keputusan duwe tampilan sing terus-terusan babagan beban sistem tandha lan kesehatan tim sakabèhé.

kesimpulan

Path kanggo ngawasi sehat lan waspada iku prasaja lan cetha. Fokus ing gejala masalah sing micu tandha, lan ngawasi sabab serves minangka bantuan kanggo masalah debugging. Gejala ngawasi luwih gampang yen sampeyan ana ing tumpukan sing sampeyan kontrol, sanajan ngawasi beban lan kinerja database kudu ditindakake langsung ing database kasebut. Kabar email nduweni kegunaan sing winates banget lan cenderung gampang dadi gangguan; tinimbang, sampeyan kudu nggunakake dashboard sing ngawasi kabeh masalah saiki sing micu tandha email. Dashboard uga bisa dipasangake karo log acara kanggo nganalisa korélasi historis.

Ing jangka panjang, perlu kanggo nggayuh rotasi tandha sing sukses babagan gejala lan masalah nyata sing bakal ditindakake, nyesuekake tujuan kanggo mesthekake yen pemantauan ndhukung diagnosis kanthi cepet.

Matur nuwun kanggo maca terjemahan nganti pungkasan. Langganan saluran telegram babagan pemantauan @monitorim_it и blog ing Sedheng.

Source: www.habr.com