Apa monitoring mati? - Monitoring urip

Wiwit 2008, perusahaan kita utamane melu manajemen infrastruktur lan dhukungan teknis saben jam kanggo proyek web: kita duwe luwih saka 400 klien, yaiku udakara 15% e-commerce Rusia. Patut, arsitektur banget macem-macem didhukung. Yen ana sing tiba, kita kudu ndandani sajrone 15 menit. Nanging kanggo mangerteni yen kacilakan wis kedadeyan, sampeyan kudu ngawasi proyek kasebut lan nanggapi kedadeyan kasebut. Carane nindakake iki?

Aku pracaya yen ana masalah kanggo ngatur sistem ngawasi sing tepat. Yen ora ana alangan, pidatoku bakal kalebu siji skripsi: "Mangga instal Prometheus + Grafana lan plugins 1, 2, 3." Sayange, ora bisa kaya ngono maneh. Lan masalah utama iku saben wong terus pracaya soko sing ana ing 2008, ing syarat-syarat komponen lunak.

Babagan organisasi sistem pemantauan, aku bakal ujar manawa ... proyek kanthi pemantauan sing kompeten ora ana. Lan kahanan kasebut ala banget yen ana sing tiba, ana risiko sing ora dingerteni - sawise kabeh, kabeh wong yakin yen "kabeh dipantau."
Mbok menawa kabeh lagi diawasi. Nanging carane?

Kita kabeh wis nemoni crita kaya ing ngisor iki: devops tartamtu, admin tartamtu digunakake, tim pangembangan teka lan ujar - "kita dibebasake, saiki monitor." Monitor apa? Cara kerjane?

OK. Kita ngawasi cara lawas. Lan wis ganti, lan ternyata sampeyan ngawasi layanan A, sing dadi layanan B, sing sesambungan karo layanan C. Nanging tim pangembangan ngandhani: "Instal piranti lunak, kudu ngawasi kabeh!"

Dadi apa sing wis diganti? - Kabeh wis diganti!

2008 Kabeh apik

Ana sawetara pangembang, siji server, siji server database. Iku kabeh dadi saka kene. Kita duwe sawetara informasi, kita nginstal zabbix, Nagios, cacti. Banjur kita nyetel tandha cetha ing CPU, ing operasi disk, lan ing papan disk. Kita uga nindakake sawetara mriksa manual kanggo mesthekake yen situs kasebut nanggapi lan pesenan wis teka ing database. Lan iku - kita luwih utawa kurang dilindhungi.

Yen kita mbandhingake jumlah karya sing ditindakake dening administrator kanggo ngawasi, mula 98% kanthi otomatis: wong sing ngawasi kudu ngerti carane nginstal Zabbix, carane ngatur lan ngatur tandha. Lan 2% - kanggo mriksa eksternal: yen situs kasebut nanggapi lan nggawe panjaluk menyang database, pesenan anyar wis teka.

2010 Beban tambah akeh

Kita miwiti skala web, nambah mesin telusur. Kita pengin nggawe manawa katalog produk ngemot kabeh produk. Lan panelusuran produk kasebut bisa digunakake. Sing database bisa digunakake, sing pesenan lagi digawe, sing situs nanggapi externally lan nanggapi saka loro server lan pangguna ora kicked metu saka situs nalika iku rebalanced menyang server liyane, etc. Ana entitas liyane.

Kajaba iku, entitas sing ana gandhengane karo infrastruktur isih tetep paling gedhe ing kepala manajer. Isih ana gagasan ing sirahku yen wong sing ngawasi yaiku wong sing bakal nginstal zabbix lan bisa ngatur.

Nanging ing wektu sing padha, karya katon kanggo nganakake pamriksan eksternal, nggawe sakumpulan skrip pitakon indeksasi telusuran, sakumpulan skrip kanggo mriksa manawa telusuran diganti sajrone proses indeksasi, sakumpulan skrip sing mriksa manawa barang ditransfer menyang layanan pangiriman, lsp. lan liya-liyane.

Cathetan: Aku nulis "sakumpulan skrip" kaping 3. Tegese, wong sing tanggung jawab kanggo ngawasi ora mung sing nginstal zabbix. Iki wong sing miwiti coding. Nanging durung ana owah-owahan ing pikirane tim.

Nanging jagad iki saya ganti, dadi saya rumit. Lapisan virtualisasi lan sawetara sistem anyar ditambahake. Dheweke wiwit sesambungan karo saben liyane. Sapa sing ujar "mambu kaya layanan mikro?" Nanging saben layanan isih katon kaya situs web kanthi individu. Kita bisa nguripake lan ngerti sing menehi informasi sing perlu lan bisa ing dhewe. Lan yen sampeyan minangka administrator sing terus-terusan melu proyek sing wis dikembangake sajrone 5-7-10 taun, kawruh iki akumulasi: level anyar katon - sampeyan ngerti, level liyane katon - sampeyan ngerti ...

Nanging arang banget ana sing ngancani proyek sajrone 10 taun.

Resume Monitoringman

Upamane sampeyan teka ing wiwitan anyar sing langsung nyewa pangembang 20, nulis 15 layanan mikro, lan sampeyan dadi admin sing dikandhani: "Mbangun CI / CD. Mangga." Sampeyan wis dibangun CI / CD lan dumadakan krungu: "Iku angel kanggo kita bisa karo produksi ing" kotak ", tanpa ngerti carane aplikasi bakal bisa ing. Nggawe kita kothak wedhi ing padha "kubus".
Sampeyan nggawe kothak wedhi ing kubus iki. Dheweke langsung ngandhani: "Kita pengin database panggung sing dianyari saben dina saka produksi, supaya kita ngerti yen bisa digunakake ing database, nanging ing wektu sing padha ora ngrusak database produksi."

Sampeyan manggon ing kabeh iki. Ana 2 minggu sadurunge rilis, dheweke ngandhani: "Saiki ayo ngawasi kabeh iki ..." Yaiku. ngawasi infrastruktur kluster, ngawasi arsitektur layanan mikro, ngawasi karya karo layanan eksternal...

Lan kanca-kancaku njupuk skema sing biasane metu saka sirahe lan ujar: "Inggih, kabeh wis jelas! Instal program sing bakal ngawasi kabeh iki. Ya, ya: Prometheus + Grafana + plugins.
Lan dheweke nambah: "Sampeyan duwe rong minggu, priksa manawa kabeh aman."

Ing pirang-pirang proyek sing kita deleng, siji wong diparengake kanggo ngawasi. Mbayangno yen kita pengin nyewa wong kanggo ngawasi 2 minggu, lan kita nulis resume kanggo dheweke. Katrampilan apa sing kudu diduweni wong iki, amarga kabeh sing wis kita ucapake nganti saiki?

• Dheweke kudu ngerti pemantauan lan spesifik operasi infrastruktur wesi.
• Dheweke kudu ngerti spesifik ngawasi Kubernetes (lan kabeh wong pengin pindhah menyang "kubus", amarga sampeyan bisa abstrak saka kabeh, ndhelikake, amarga admin bakal ngatasi liyane) - dhewe, infrastruktur, lan ngerti carane ngawasi aplikasi. ing njero.
• Dheweke kudu ngerti manawa layanan komunikasi karo saben liyane kanthi cara khusus, lan ngerti spesifik babagan cara layanan sesambungan. Sampeyan cukup bisa ndeleng proyek ing ngendi sawetara layanan komunikasi bebarengan, amarga ora ana cara liya. Contone, backend liwat REST, liwat gRPC menyang layanan katalog, nampa dhaptar produk lan bali maneh. Sampeyan ora bisa ngenteni kene. Lan karo layanan liyane, kerjane ora sinkron. Transfer pesenan menyang layanan pangiriman, ngirim layang, lsp.
  Sampeyan mbokmenawa wis nglangi saka kabeh iki? Lan admin sing kudu ngawasi iki malah tambah bingung.
• Dheweke kudu bisa ngrancang lan ngrancang kanthi bener - amarga karya kasebut saya tambah akeh.
• Mula, dheweke kudu nggawe strategi saka layanan sing digawe kanggo ngerti carane ngawasi kanthi khusus. Dheweke butuh pangerten babagan arsitektur proyek lan pangembangane + pangerten babagan teknologi sing digunakake ing pangembangan.

Ayo elinga kasus sing pancen normal: sawetara layanan ana ing PHP, sawetara layanan ana ing Go, sawetara layanan ana ing JS. Padha piye wae bisa karo saben liyane. Iki asale saka istilah "layanan mikro": ana akeh sistem individu sing pangembang ora bisa ngerti proyek kasebut kanthi wutuh. Siji bagean saka tim nulis layanan ing JS sing bisa digunakake dhewe lan ora ngerti cara kerjane sistem liyane. Sisih liyane nulis layanan ing Python lan ora ngganggu cara kerja layanan liyane; padha diisolasi ing wilayahe dhewe. Sing nomer telu yaiku layanan nulis ing PHP utawa liya-liyane.
Kabeh 20 wong iki dipérang dadi 15 layanan, lan mung siji admin sing kudu ngerti kabeh iki. mandeg! kita mung pamisah sistem dadi 15 microservices amarga 20 wong ora bisa ngerti kabeh sistem.

Nanging kudu dipantau piye wae...

Apa asile? Akibaté, ana siji wong sing nerangake kabeh sing kabeh tim pangembang ora bisa ngerti, lan ing wektu sing padha uga kudu ngerti lan bisa nindakake apa sing wis dituduhake ing ndhuwur - infrastruktur hardware, infrastruktur Kubernetes, etc.

Apa aku bisa ngomong ... Houston, kita duwe masalah.

Ngawasi proyek piranti lunak modern minangka proyek piranti lunak dhewe

Saka kapercayan palsu manawa ngawasi minangka piranti lunak, kita ngembangake kapercayan babagan mukjijat. Nanging mukjijat, sayangé, ora kelakon. Sampeyan ora bisa nginstal zabbix lan nyana kabeh bisa. Ora ana gunane nginstal Grafana lan ngarep-arep kabeh bakal ok. Umume wektu bakal ditindakake kanggo ngatur mriksa operasi layanan lan interaksi karo saben liyane, mriksa cara kerja sistem eksternal. Nyatane, 90% wektu bakal digunakake ora kanggo nulis skrip, nanging kanggo ngembangake piranti lunak. Lan kudu ditangani dening tim sing ngerti karya proyek kasebut.
Yen ing kahanan iki siji wong dibuwang ing pengawasan, banjur bilai bakal kelakon. Sing kedadeyan ing endi wae.

Contone, ana sawetara layanan sing komunikasi karo siji liyane liwat Kafka. Pesen wis teka, kita ngirim pesen babagan pesenan menyang Kafka. Ana layanan sing ngrungokake informasi babagan pesenan lan ngirim barang. Ana layanan sing ngrungokake informasi babagan pesenan lan ngirim layang menyang pangguna. Lan banjur akeh layanan katon, lan kita wiwit bingung.

Lan yen sampeyan uga menehi iki menyang admin lan pangembang ing tataran nalika ana wektu cendhak sadurunge release, wong kudu ngerti kabeh protokol iki. Sing. Proyek kanthi skala iki mbutuhake wektu sing akeh, lan iki kudu ditrapake ing pangembangan sistem.
Nanging asring banget, utamane ing wiwitan, kita ndeleng kepiye ngawasi ditundha nganti mengko. "Saiki kita bakal nggawe Bukti Konsep, bakal diluncurake, ayo tiba - kita siyap kurban. Banjur kita bakal ngawasi kabeh. Nalika (utawa yen) proyek kasebut wiwit entuk dhuwit, bisnis kasebut pengin nambah luwih akeh fitur - amarga wis diwiwiti, mula kudu diluncurake maneh! Lan sampeyan ana ing titik sampeyan kudu ngawasi kabeh sadurunge, sing ora njupuk 1% wektu, nanging luwih akeh. Lan kanthi mangkono, pangembang bakal dibutuhake kanggo ngawasi, lan luwih gampang supaya bisa nggarap fitur-fitur anyar. Akibaté, fitur anyar ditulis, kabeh bakal ngaco munggah, lan sampeyan ana ing deadlock telas.

Dadi carane ngawasi proyek diwiwiti saka wiwitan, lan apa sing kudu ditindakake yen sampeyan entuk proyek sing kudu dipantau, nanging sampeyan ora ngerti arep miwiti saka ngendi?

Pisanan, sampeyan kudu ngrancang.

Digression lirik: asring banget diwiwiti kanthi pemantauan infrastruktur. Contone, kita duwe Kubernetes. Ayo miwiti kanthi nginstal Prometheus karo Grafana, nginstal plugin kanggo ngawasi "kubus". Ora mung pangembang, nanging uga pangurus duwe praktik apes: "Kita bakal nginstal plugin iki, nanging plugin kasebut bisa uga ngerti carane nindakake." Wong seneng miwiti kanthi prasaja lan langsung, tinimbang tumindak sing penting. Lan ngawasi infrastruktur gampang.

Pisanan, mutusake apa lan carane sampeyan pengin ngawasi, banjur pilih alat, amarga wong liya ora bisa mikir sampeyan. Lan kudu padha? Wong liya mikir babagan sistem universal - utawa ora mikir nalika plugin iki ditulis. Lan mung amarga plugin iki duwe 5 ewu pangguna ora ateges ana gunane. Mbok menawa sampeyan bakal dadi 5001 mung amarga wis ana 5000 wong sadurunge.

Yen sampeyan miwiti ngawasi infrastruktur lan mburi aplikasi sampeyan mandheg nanggapi, kabeh pangguna bakal kelangan sambungan karo aplikasi seluler. Ana kesalahan bakal katon. Dheweke bakal teka lan ujar "Aplikasi ora bisa digunakake, apa sing sampeyan lakoni ing kene?" - "Kita ngawasi." - "Kepiye sampeyan ngawasi yen sampeyan ora weruh yen aplikasi ora bisa digunakake?!"

1. Aku yakin sampeyan kudu miwiti ngawasi persis saka titik entri pangguna. Yen pangguna ora weruh manawa aplikasi kasebut bisa digunakake, mula iku gagal. Lan sistem ngawasi kudu ngelingake babagan iki dhisik.
2. Lan mung banjur kita bisa ngawasi infrastruktur. Utawa nindakaken ing podo karo. Luwih gampang karo infrastruktur - ing kene pungkasane bisa nginstal zabbix.
3. Lan saiki sampeyan kudu pindhah menyang werna saka aplikasi kanggo ngerti ngendi iku ora bisa digunakake.

Ide utamaku yaiku ngawasi kudu sejajar karo proses pangembangan. Yen sampeyan ngganggu tim ngawasi kanggo tugas liyane (nggawe CI / CD, sandboxing, reorganisasi infrastruktur), ngawasi bakal wiwit lag lan sampeyan ora bakal bisa nyusul pembangunan (utawa cepet utawa mengko sampeyan kudu mungkasi).

Kabeh kanthi tingkat

Iki carane aku ndeleng organisasi saka sistem ngawasi.

1) Tingkat aplikasi:

• ngawasi logika bisnis aplikasi;
• ngawasi metrik layanan kesehatan;
• ngawasi integrasi.

2) Tingkat Infrastruktur:

• ngawasi tingkat orkestrasi;
• ngawasi piranti lunak sistem;
• monitoring kadar besi.

3) Maneh tingkat aplikasi - nanging minangka produk teknik:

• ngumpulake lan ngawasi log aplikasi;
• APM;
• nglacak.

4) Awas:

• organisasi sistem peringatan;
• organisasi saka sistem tugas;
• organisasi "basis kawruh" lan alur kerja kanggo pangolahan kedadeyan.

penting: kita njaluk tandha ora sawise, nanging langsung! Ora perlu kanggo miwiti ngawasi lan "kowe mengko" nemtokake sapa sing bakal nampa tandha. Sawise kabeh, apa tugas ngawasi: kanggo mangerteni ing ngendi sistem ana sing salah, lan supaya wong sing bener ngerti babagan iki. Yen sampeyan ninggalake iki nganti pungkasan, wong sing bener bakal ngerti yen ana sing salah mung kanthi nyebut "ora ana sing bisa digunakake kanggo kita."

Lapisan Aplikasi - Pemantauan Logika Bisnis

Ing kene kita ngomong babagan mriksa kasunyatan manawa aplikasi kasebut bisa digunakake kanggo pangguna.

Tahap iki kudu ditindakake sajrone tahap pangembangan. Contone, kita duwe Prometheus saratipun: iku menyang server sing nindakake mriksa, narik endpoint, lan endpoint dadi lan mriksa API.

Nalika asring dijaluk ngawasi kaca ngarep kanggo mesthekake situs kasebut bisa digunakake, programer menehi gagang sing bisa ditarik saben-saben kudu mesthekake yen API bisa digunakake. Lan programer saiki isih njupuk lan nulis /api/test/helloworld
Cara mung kanggo mesthekake yen kabeh bisa digunakake? - Ora!

• Nggawe mriksa kuwi ateges tugas pangembang. Tes unit kudu ditulis dening programer sing nulis kode kasebut. Amarga yen sampeyan bocor menyang admin, "Wah, iki dhaptar protokol API kanggo kabeh 25 fungsi, mangga ngawasi kabeh!" - ora bakal bisa.
• Yen sampeyan nyithak "hello world", ora ana sing bakal ngerti yen API kudu lan bisa digunakake. Saben owah-owahan API kudu mimpin kanggo owah-owahan ing mriksa.
• Yen sampeyan wis duwe masalah kaya mengkono, mungkasi fitur lan nyedhiakke pangembang sing bakal nulis mriksa iki, utawa nampa losses, nampa ora ana sing dicenthang lan bakal gagal.

Tips teknis:

• Priksa manawa sampeyan ngatur server eksternal kanggo ngatur pamriksa - sampeyan kudu yakin manawa proyek sampeyan bisa diakses ing jagad njaba.
• Atur pamriksa ing kabeh protokol API, ora mung titik pungkasan individu.
• Nggawe prometheus-endpoint karo asil test.

Lapisan aplikasi - pemantauan metrik kesehatan

Saiki kita ngomong babagan metrik layanan kesehatan eksternal.

Kita mutusake yen kita ngawasi kabeh "nangani" aplikasi kasebut nggunakake pamriksa eksternal, sing diarani saka sistem pemantauan eksternal. Nanging iki minangka "ngalahake" sing "dideleng" pangguna. Kita pengin mesthekake yen layanan kita dhewe bisa digunakake. Ana crita sing luwih apik ing kene: K8 duwe pemeriksaan kesehatan, supaya paling ora "kubus" dhewe bisa yakin yen layanan kasebut bisa digunakake. Nanging setengah saka mriksa aku wis katon padha print "hello donya". Sing. Dadi dheweke narik sepisan sawise nyebarake, dheweke mangsuli manawa kabeh apik - kabeh. Lan layanan kasebut, yen nyedhiyakake API dhewe, duwe akeh titik entri kanggo API sing padha, sing uga kudu dipantau, amarga kita pengin ngerti kerjane. Lan kita wis ngawasi ing njero.

Cara ngleksanakake iki kanthi teknis kanthi bener: saben layanan nyedhiyakake titik pungkasan babagan kinerja saiki, lan ing grafik Grafana (utawa aplikasi liyane) kita ndeleng status kabeh layanan.

• Saben owah-owahan API kudu mimpin kanggo owah-owahan ing mriksa.
• Gawe layanan anyar langsung nganggo metrik kesehatan.
• Admin bisa teka menyang pangembang lan takon "Tambahake sawetara fitur supaya aku ngerti kabeh lan nambah informasi babagan iki menyang sistem pemantauanku." Nanging pangembang biasane mangsuli, "Kita ora bakal nambah apa-apa rong minggu sadurunge rilis."
  Supaya manajer pangembangan ngerti manawa bakal ana kerugian, supaya manajemen manajer pangembangan uga ngerti. Amarga nalika kabeh tiba, wong isih bakal nelpon lan njaluk ngawasi "layanan sing terus-terusan tiba" (c)
• Miturut cara, alokasi pangembang kanggo nulis plugin kanggo Grafana - iki bakal dadi pitulung sing apik kanggo admin.

Lapisan Aplikasi - Pemantauan Integrasi

Pemantauan integrasi fokus ing ngawasi komunikasi antarane sistem bisnis-kritis.

Contone, ana 15 layanan sing komunikasi karo saben liyane. Iki ora ana maneh situs sing kapisah. Sing. kita ora bisa narik layanan ing dhewe, njaluk / helloworld lan ngerti sing layanan mlaku. Amarga layanan web pesenan kudu ngirim informasi babagan pesenan menyang bis - saka bis, layanan gudang kudu nampa pesen iki lan nggarap luwih lanjut. Lan layanan distribusi email kudu ngolah iki, lsp.

Patut, kita ora bisa ngerti, poking ing saben layanan individu, iku kabeh bisa. Amarga kita duwe bis tartamtu sing kabeh komunikasi lan interaksi.
Mula, tahap iki kudu menehi tandha tataran layanan tes kanggo interaksi karo layanan liyane. Ora mungkin ngatur pemantauan komunikasi kanthi ngawasi broker pesen. Yen ana layanan sing ngetokake data lan layanan sing nampa, nalika ngawasi broker kita mung bakal weruh data sing mabur saka sisih menyang sisih. Sanajan kita bisa ngawasi interaksi data kasebut sacara internal - manawa produser tartamtu ngirim data kasebut, ana sing maca, aliran iki terus menyang Kafka - iki isih ora bakal menehi informasi yen siji layanan ngirim pesen ing siji versi. , nanging layanan liyane ora nyana versi iki lan Mlayu. Kita ora bakal ngerti babagan iki, amarga layanan kasebut bakal ngandhani yen kabeh bisa digunakake.

Apa sing dakkarepake:

• Kanggo komunikasi sinkron: titik pungkasan nggawe panjalukan kanggo layanan sing gegandhengan. Sing. kita njupuk titik pungkasan iki, narik script nang layanan, kang menyang kabeh TCTerms lan ngandika "Aku bisa narik ana, lan narik ana, Aku bisa narik ana ..."
• Kanggo komunikasi asinkron: pesen mlebu - titik pungkasan mriksa bus kanggo pesen tes lan nampilake status pangolahan.
• Kanggo komunikasi asinkron: pesen metu - titik pungkasan ngirim pesen tes menyang bis.

Kaya biasane: kita duwe layanan sing mbuwang data menyang bis. Kita teka ing layanan iki lan njaluk sampeyan ngandhani babagan kesehatan integrasi. Lan yen layanan kasebut kudu ngasilake pesen ing endi wae (WebApp), mula bakal ngasilake pesen tes iki. Lan yen kita mbukak layanan ing sisih OrderProcessing, iku pisanan ngirim apa bisa ngirim sawijining, lan yen ana sawetara iku gumantung, banjur maca pesawat saka pesen test saka bis, mangertos sing bisa ngolah, laporan lan , yen perlu, ngirim wong luwih, lan bab iki ngandika - kabeh iku ok, Aku urip.

Asring banget kita krungu pitakonan "kepiye bisa nyoba iki ing data pertempuran?" Contone, kita ngomong babagan layanan pesenan sing padha. Pesenan kasebut ngirim pesen menyang gudang ing ngendi barang kasebut dicopot: kita ora bisa nyoba iki ing data pertempuran, amarga "barangku bakal dibusak!" Solusi: Rencanakake kabeh tes iki ing wiwitan. Sampeyan uga duwe tes unit sing nggawe moyoki. Dadi, tindakake ing tingkat sing luwih jero ing ngendi sampeyan duwe saluran komunikasi sing ora ngrusak operasi bisnis.

Lapisan infrastruktur

Pemantauan infrastruktur minangka perkara sing wis suwe dianggep ngawasi dhewe.

• Pemantauan infrastruktur bisa lan kudu diluncurake minangka proses sing kapisah.
• Sampeyan ora kudu miwiti ngawasi infrastruktur ing proyek sing mlaku, sanajan sampeyan pengin. Iki pain kanggo kabeh devops. "Pisanan aku bakal ngawasi kluster, aku bakal ngawasi infrastruktur" - i.e. Pisanan, bakal ngawasi apa sing ana ing ngisor iki, nanging ora bakal mlebu ing aplikasi kasebut. Amarga aplikasi kasebut minangka perkara sing ora bisa dingerteni kanggo devops. Iki bocor kanggo dheweke, lan dheweke ora ngerti cara kerjane. Lan dheweke ngerti infrastruktur kasebut lan diwiwiti. Nanging ora - sampeyan kudu ngawasi aplikasi kasebut dhisik.
• Aja ngluwihi jumlah tandha. Ngelingi kerumitan sistem modern, tandha tansah mabur, lan sampeyan kudu piye wae manggon karo tandha iki. Lan wong sing nelpon, sawise ndeleng atusan tandha sabanjure, bakal mutusake "Aku ora pengin mikir babagan iki." Tandha mung kudu menehi kabar babagan perkara kritis.

Tingkat aplikasi minangka unit bisnis

Poin utama:

• ELK. Iki minangka standar industri. Yen ana alesan sampeyan ora nglumpukake log, wiwiti langsung.
• APM. APM eksternal minangka cara kanggo nutup ngawasi aplikasi kanthi cepet (NewRelic, BlackFire, Datadog). Sampeyan bisa nginstal bab iki sauntara kanggo ing paling piye wae ngerti apa mengkono karo sampeyan.
• nglacak. Ing puluhan layanan mikro, sampeyan kudu nglacak kabeh, amarga panjaluk kasebut ora urip maneh. Iku angel banget kanggo nambah mengko, dadi luwih apik kanggo langsung gawe jadwal nelusuri ing pembangunan - iki karya lan sarana pangembang. Yen sampeyan durung ngleksanakake, ngleksanakake! Waca Jaeger / Zipkin

Waspada

• Organisasi sistem kabar: ing kahanan ngawasi akeh perkara, kudu ana sistem terpadu kanggo ngirim kabar. Sampeyan bisa ing Grafana. Ing Kulon, kabeh wong nggunakake PagerDuty. Tandha kudu cetha (umpamane saka ngendi asale ...). Lan disaranake kanggo ngontrol manawa kabar ditampa
• Organisasi sistem tugas: tandha ora kudu dikirim menyang kabeh wong (kabeh wong bakal nanggepi wong akeh, utawa ora ana sing bakal nanggepi). Pangembang uga kudu oncall: dadi manawa kanggo netepake wilayah tanggung jawab, nggawe instruksi sing cetha lan nulis ing iku sing persis kanggo nelpon ing dina Senin lan Rebo, lan sing nelpon ing dina Selasa lan ana (yen ora bakal nelpon sapa malah ing kedadeyan masalah gedhe - dheweke bakal wedi tangi utawa ngganggu: umume wong ora seneng nelpon lan nggugah wong liya, utamane ing wayah wengi). Lan nerangake yen njaluk bantuan ora minangka indikator saka incompetence ("Aku njaluk tulung, tegese aku buruh sing ala"), nyengkuyung panyuwunan kanggo bantuan.
• Organisasi "basis kawruh" lan alur kerja kanggo pangolahan insiden: kanggo saben kedadeyan serius, post-mortem kudu direncanakake, lan minangka langkah sementara, tindakan sing bakal ngrampungake kedadeyan kasebut kudu direkam. Lan nggawe laku sing bola tandha iku dosa; padha kudu didandani ing kode utawa karya infrastruktur.

Teknologi tumpukan

Ayo mbayangno tumpukan kita kaya ing ngisor iki:

• koleksi data - Prometheus + Grafana;
• analisis log - ELK;
• kanggo APM utawa Tracing - Jaeger (Zipkin).

Pilihan saka opsi ora kritis. Amarga yen ing wiwitan sampeyan ngerti carane ngawasi sistem lan nulis rencana, mula sampeyan kudu milih alat sing cocog karo kabutuhan sampeyan. Pitakonan yaiku apa sing sampeyan pilih kanggo ngawasi ing wiwitan. Amarga mbok menawa alat sing sampeyan pilih ing wiwitan ora cocog karo kabutuhan sampeyan.

Sawetara poin teknis sing dakdeleng ing endi wae akhir-akhir iki:

Prometheus didorong menyang Kubernetes - sapa sing nggawe iki?! Yen kluster sampeyan nabrak, apa sing bakal sampeyan lakoni? Yen sampeyan duwe cluster Komplek nang, banjur kudu ana sawetara jenis sistem ngawasi nang kluster, lan sawetara njaba, kang bakal ngumpulake data saka njero kluster.

Ing kluster kita ngumpulake log lan liya-liyane. Nanging sistem ngawasi kudu njaba. Asring banget, ing kluster sing ana Promtheus sing diinstal ing njero, ana uga sistem sing nindakake pamriksa eksternal saka operasi situs kasebut. Kepiye yen sambungan sampeyan menyang jagad njaba wis mudhun lan aplikasi ora bisa digunakake? Pranyata kabeh iku apik nang, nanging ora nggawe samubarang luwih gampang kanggo pangguna.

temonan

• Pangembangan ngawasi dudu instalasi utilitas, nanging pangembangan produk piranti lunak. 98% pemantauan saiki yaiku coding. Coding ing layanan, coding mriksa eksternal, mriksa layanan eksternal, lan kabeh.
• Aja mbuwang wektu pangembang kanggo ngawasi: bisa njupuk nganti 30% saka karya, nanging worth iku.
• Devops, aja kuwatir yen sampeyan ora bisa ngawasi apa-apa, amarga sawetara perkara iku cara mikir sing beda. Sampeyan dudu programmer, lan kerja ngawasi pancen tugase.
• Yen proyek wis mlaku lan ora dipantau (lan sampeyan dadi manajer), alokasi sumber daya kanggo ngawasi.
• Yen produk wis ana ing produksi, lan sampeyan minangka devops sing didhawuhi "nyiyapake ngawasi" - coba jelasake menyang manajemen babagan apa sing dakcritakake.

Iki minangka versi lengkap saka laporan ing konferensi Saint Highload ++.

Yen sampeyan kasengsem karo gagasan lan pikiranku lan topik sing gegandhengan, mula sampeyan bisa maca saluran 🙂

Source: www.habr.com