Kita mikir babagan nggawe sistem pemantauan ing tahap nggawe tim produk. Dadi jelas manawa bisnis kita - eksploitasi - ora kalebu ing tim kasebut. Kok ngono?
Kasunyatane, kabeh tim kita dibangun ing babagan sistem informasi individu, layanan mikro lan ngarep, saengga tim kasebut ora bisa ndeleng kesehatan sakabèhé saka kabèh sistem kanthi wutuh. Contone, padha ora ngerti carane sawetara bagean cilik ing backend jero mengaruhi mburi ngarep. Ruang lingkup kapentingan diwatesi karo sistem sing digabungake karo sistem kasebut. Yen tim lan layanan A meh ora ana hubungane karo layanan B, mula layanan kasebut meh ora katon ing tim kasebut.
Tim kita, kanthi cara, nggarap sistem sing banget terintegrasi karo siji liyane: ana akeh sambungan ing antarane, iki minangka infrastruktur sing gedhe banget. Lan operasi toko online gumantung ing kabeh sistem kasebut (sing kita duwe, kanthi cara, nomer ageng).
Dadi, departemen kita ora kalebu tim apa wae, nanging dumunung ing sisih pinggir. Ing kabeh crita iki, tugas kita yaiku mangertos kanthi lengkap babagan cara kerja sistem informasi, fungsi, integrasi, piranti lunak, jaringan, hardware, lan kepiye kabeh iki disambungake.
Platform ing ngendi toko online kita beroperasi katon kaya iki:
- ngarep
- kantor tengah
- kantor maneh
Ora ketompo carane akeh kita pengin, iku ora kelakon sing kabeh sistem bisa lancar lan flawlessly. Intine, maneh, yaiku jumlah sistem lan integrasi - kanthi kaya kita, sawetara kedadeyan ora bisa dihindari, sanajan kualitas tes. Kajaba iku, ing sistem sing kapisah lan babagan integrasi. Lan sampeyan kudu ngawasi kahanan kabeh platform kanthi lengkap, lan ora mung bagean individu.
Saenipun, pemantauan kesehatan ing saindenging platform kudu otomatis. Lan kita teka kanggo ngawasi minangka bagean sing ora bisa dihindari saka proses iki. Wiwitane, dibangun mung kanggo bagean ngarep, nalika spesialis jaringan, administrator piranti lunak lan hardware duwe lan isih duwe sistem pemantauan lapisan-by-layer dhewe. Kabeh wong-wong iki mung ngetutake pemantauan ing tingkat dhewe; ora ana sing duwe pangerten sing komprehensif.
Contone, yen mesin virtual kacilakan, umume mung administrator sing tanggung jawab kanggo hardware lan mesin virtual sing ngerti babagan iki. Ing kasus kaya mengkono, tim garis ngarep weruh kasunyatan banget saka kacilakan aplikasi, nanging ora duwe data babagan kacilakan mesin virtual. Lan administrator bisa ngerti sapa pelanggan lan duwe gagasan kasar babagan apa sing lagi ditindakake ing mesin virtual iki, yen ana sawetara proyek gedhe. Dheweke paling ora ngerti babagan bocah cilik. Ing kasus apa wae, administrator kudu pindhah menyang pemilik lan takon apa sing ana ing mesin iki, apa sing kudu dipulihake lan apa sing kudu diganti. Lan yen ana sing serius banget, mula dheweke mlaku-mlaku - amarga ora ana sing ndeleng sistem kasebut kanthi wutuh.
Pungkasane, crita sing beda-beda kasebut mengaruhi kabeh frontend, pangguna lan fungsi bisnis inti - sales online. Amarga kita dudu bagean saka tim, nanging melu operasi kabeh aplikasi e-dagang minangka bagean saka toko online, kita njupuk tugas nggawe sistem pemantauan lengkap kanggo platform e-dagang.
Struktur sistem lan tumpukan
Kita miwiti kanthi ngenali sawetara lapisan pemantauan kanggo sistem kita, ing ngendi kita kudu ngumpulake metrik. Lan kabeh iki kudu digabung, yaiku sing ditindakake ing tahap pertama. Saiki ing tahap iki, kita ngrampungake koleksi metrik kanthi kualitas paling dhuwur ing kabeh lapisan supaya bisa nggawe korélasi lan ngerti kepiye sistem pengaruhe.
Kurang ngawasi lengkap ing tahap wiwitan peluncuran aplikasi (wiwit kita miwiti mbangun nalika umume sistem produksi) nyebabake kasunyatan manawa kita duwe utang teknis sing signifikan kanggo nyiyapake pemantauan kabeh platform. Kita ora bisa fokus kanggo nyetel ngawasi siji IS lan ngawasi kanthi rinci, amarga sistem liyane bakal ditinggal tanpa ngawasi sawetara wektu. Kanggo ngatasi masalah iki, kita nemtokake dhaptar metrik sing paling perlu kanggo ngevaluasi kahanan sistem informasi kanthi lapisan lan wiwit ngleksanakake.
Mulane, padha mutusaké kanggo mangan gajah ing bagean.
Sistem kita kalebu:
- hardware;
- sistem operasi;
- piranti lunak;
- bagean UI ing aplikasi ngawasi;
- metrik bisnis;
- aplikasi integrasi;
- keamanan informasi;
- jaringan;
- imbangan lalu lintas.
Ing tengah sistem iki ngawasi dhewe. Kanggo umume ngerti kahanan kabeh sistem, sampeyan kudu ngerti apa sing kedadeyan karo aplikasi ing kabeh lapisan kasebut lan ing kabeh set aplikasi.
Dadi, babagan tumpukan.
Kita nggunakake piranti lunak open source. Ing tengah kita duwe Zabbix, sing digunakake utamane minangka sistem tandha. Saben uwong ngerti yen iku becik kanggo ngawasi infrastruktur. Apa tegese iki? Persis metrik tingkat rendah sing saben perusahaan sing njaga pusat data dhewe (lan Sportmaster duwe pusat data dhewe) - suhu server, status memori, serangan, metrik piranti jaringan.
Kita wis nggabungake Zabbix karo Telegram messenger lan Microsoft Teams, sing aktif digunakake ing tim. Zabbix nyakup lapisan jaringan nyata, hardware lan sawetara piranti lunak, nanging dudu panacea. We enrich data iki saka sawetara layanan liyane. Contone, ing tingkat hardware, kita langsung nyambung liwat API menyang sistem virtualisasi lan ngumpulake data.
Apa maneh. Saliyane Zabbix, kita nggunakake Prometheus, sing ngidini kita ngawasi metrik ing aplikasi lingkungan dinamis. Tegese, kita bisa nampa metrik aplikasi liwat titik pungkasan HTTP lan ora kuwatir babagan metrik sing bakal dimuat lan sing ora. Adhedhasar data kasebut, pitakon analitis bisa dikembangake.
Sumber data kanggo lapisan liyane, contone, metrik bisnis, dipérang dadi telung komponen.
Kaping pisanan, iki minangka sistem bisnis eksternal, Google Analytics, kita ngumpulake metrik saka log. Saka wong-wong mau, kita entuk data babagan pangguna aktif, konversi lan kabeh sing ana gandhengane karo bisnis. Kapindho, iki minangka sistem pemantauan UI. Iku kudu diterangake ing liyane rinci.
Biyen, kita miwiti tes manual lan dadi tes otomatis babagan fungsi lan integrasi. Saka iki kita digawe ngawasi, mung ninggalake fungsi utama, lan gumantung ing spidol minangka stabil sabisa lan ora ngganti asring liwat wektu.
Struktur tim anyar tegese kabeh aktivitas aplikasi diwatesi ing tim produk, mula kita mandheg nindakake tes murni. Nanging, kita nggawe pemantauan UI saka tes, ditulis ing Jawa, Selenium lan Jenkins (digunakake minangka sistem kanggo ngetokake lan ngasilake laporan).
Kita duwe akeh tes, nanging pungkasane kita mutusake menyang dalan utama, metrik tingkat paling dhuwur. Lan yen kita duwe akeh tes khusus, bakal angel supaya data tetep anyar. Saben rilis sabanjure bakal ngrusak kabeh sistem, lan kabeh sing bakal ditindakake yaiku ndandani. Mula, kita fokus ing perkara-perkara dhasar sing arang banget diganti, lan kita mung ngawasi.
Pungkasan, kaping telu, sumber data yaiku sistem logging terpusat. Kita nggunakake Elastic Stack kanggo log, banjur kita bisa narik data iki menyang sistem ngawasi kanggo metrik bisnis. Saliyane kabeh iki, kita duwe layanan Monitoring API dhewe, ditulis ing Python, sing takon layanan apa wae liwat API lan ngumpulake data saka wong-wong mau menyang Zabbix.
Atribut pemantauan liyane sing penting yaiku visualisasi. Kita adhedhasar Grafana. Iki minangka sistem visualisasi liyane sing ngidini sampeyan nggambarake metrik saka macem-macem sumber data ing dashboard. Kita bisa ngumpulake metrik tingkat paling dhuwur kanggo toko online, contone, jumlah pesenan sing diselehake ing jam pungkasan saka DBMS, metrik kinerja kanggo OS sing toko online iki mlaku saka Zabbix, lan metrik kanggo aplikasi iki. saka Prometheus. Lan kabeh iki bakal ana ing siji dashboard. Cetha lan bisa diakses.
Ayo kula nyathet babagan keamanan - saiki kita ngrampungake sistem kasebut, sing bakal digabungake karo sistem pemantauan global. Miturut pendapat saya, masalah utama sing diadhepi e-commerce ing bidang keamanan informasi ana hubungane karo bot, parser lan brute force. Kita kudu ngati-ati babagan iki, amarga kabeh iki bisa mengaruhi operasi aplikasi lan reputasi kita saka sudut pandang bisnis. Lan kanthi tumpukan sing dipilih, kita kasil nutupi tugas kasebut.
Titik penting liyane yaiku lapisan aplikasi dirakit dening Prometheus. Dheweke uga digabungake karo Zabbix. Lan kita uga duwe sitespeed, layanan sing ngidini kita ndeleng paramèter kayata kacepetan loading kaca, bottlenecks, rendering kaca, skrip loading, lan liya-liyane, uga API terintegrasi. Dadi metrik kita diklumpukake ing Zabbix, lan kanthi mangkono, kita uga waspada saka kana. Kabeh tandha saiki dikirim menyang cara ngirim utama (saiki email lan telegram, MS Teams uga bubar disambungake). Ana rencana kanggo nganyarke alerting menyang negara kasebut yen bot cerdas bisa digunakake minangka layanan lan nyedhiyakake informasi pemantauan kanggo kabeh tim produk sing kasengsem.
Kanggo kita, metrik penting ora mung kanggo sistem informasi individu, nanging uga metrik umum kanggo kabeh infrastruktur sing digunakake aplikasi: klompok server fisik sing digunakake mesin virtual, penyeimbang lalu lintas, Penyeimbang Beban Jaringan, jaringan kasebut, panggunaan saluran komunikasi. . Plus metrik kanggo pusat data kita dhewe (kita duwe sawetara lan infrastruktur cukup gedhe).
Kauntungan saka sistem pemantauan kita yaiku kanthi bantuan kita bisa ndeleng status kesehatan kabeh sistem lan bisa ngevaluasi pengaruhe ing saben liyane lan sumber daya sing dienggo bareng. Lan pungkasane, ngidini kita melu perencanaan sumber daya, sing uga dadi tanggung jawab kita. Kita ngatur sumber daya server - blumbang ing e-commerce, komisi lan decommission peralatan anyar, tuku peralatan anyar tambahan, nindakake audit saka sumber daya, etc. Saben taun, tim ngrancang proyek anyar, ngembangake sistem, lan penting kanggo nyedhiyakake sumber daya.
Lan kanthi bantuan metrik, kita ndeleng tren konsumsi sumber daya dening sistem informasi kita. Lan adhedhasar wong-wong mau, kita bisa ngrancang apa wae. Ing tingkat virtualisasi, kita ngumpulake data lan ndeleng informasi babagan jumlah sumber daya sing kasedhiya dening pusat data. Lan wis ana ing tengah data sampeyan bisa ndeleng daur ulang, distribusi nyata, lan konsumsi sumber daya. Kajaba iku, karo server mandiri lan mesin virtual lan klompok server fisik sing kabeh mesin virtual iki muter kanthi kuat.
Prospek
Saiki kita duwe inti sistem kanthi lengkap, nanging isih akeh perkara sing kudu digarap. Paling ora, iki minangka lapisan keamanan informasi, nanging uga penting kanggo nggayuh jaringan, ngembangake alerting lan ngrampungake masalah korélasi. Kita duwe akeh lapisan lan sistem, lan ing saben lapisan ana luwih akeh metrik. Pranyata dadi matryoshka kanggo gelar matryoshka.
Tugas kita yaiku nggawe tandha sing bener. Contone, yen ana masalah karo hardware, maneh, karo mesin virtual, lan ana aplikasi penting, lan layanan ora digawe serep ing sembarang cara. Kita ngerteni manawa mesin virtual wis mati. Banjur metrik bisnis bakal menehi tandha: pangguna wis ilang nang endi wae, ora ana konversi, UI ing antarmuka ora kasedhiya, piranti lunak lan layanan uga wis mati.
Ing kahanan iki, kita bakal nampa spam saka tandha, lan iki ora pas karo format sistem ngawasi sing tepat. Pitakonan korélasi muncul. Mulane, saenipun, sistem ngawasi kita kudu ngomong: "Guys, mesin fisik sampeyan wis mati, lan bebarengan karo aplikasi iki lan metrik iki,"Kanthi bantuan siji tandha, tinimbang nesu bombarding kita karo atus tandha. Sampeyan kudu nglaporake perkara utama - sababe, sing mbantu ngilangi masalah kanthi cepet amarga lokalisasi.
Sistem kabar lan pangolahan tandha dibangun ing sekitar layanan hotline XNUMX jam. Kabeh tandha sing dianggep kudu disedhiyakake lan kalebu ing daftar priksa dikirim ing kana. Saben tandha kudu duwe katrangan: apa sing kedadeyan, apa tegese, apa sing kena pengaruh. Lan uga link menyang dashboard lan instruksi babagan apa sing kudu ditindakake ing kasus iki.
Iki kabeh babagan syarat kanggo mbangun tandha. Banjur kahanan bisa berkembang ing rong arah - ana masalah lan kudu ditanggulangi, utawa ana kegagalan ing sistem pemantauan. Nanging ing kasus apa wae, sampeyan kudu pindhah lan ngerteni.
Rata-rata, saiki kita nampa kira-kira satus tandha saben dina, kanthi nyathet kasunyatan manawa korélasi tandha durung dikonfigurasi kanthi bener. Lan yen kita kudu nindakake karya technical, lan kita meksa mateni soko, nomer mundhak Ngartekno.
Saliyane ngawasi sistem sing kita operate lan ngumpulake metrik sing dianggep penting ing sisih kita, sistem ngawasi ngidini kita ngumpulake data kanggo tim produk. Bisa pengaruhe komposisi metrik ing sistem informasi sing kita monitor.
Kolega kita bisa teka lan njaluk nambah sawetara metrik sing bakal migunani kanggo kita lan tim. Utawa, contone, tim bisa uga ora duwe metrik dhasar sing cukup; dheweke kudu nglacak sawetara metrik tartamtu. Ing Grafana, kita nggawe papan kanggo saben tim lan menehi hak admin. Uga, yen tim butuh dashboard, nanging dheweke ora bisa / ora ngerti carane nindakake, kita nulungi dheweke.
Amarga kita ana ing njaba aliran penciptaan nilai tim, rilis lan rencana, kita mboko sithik entuk kesimpulan manawa rilis kabeh sistem lancar lan bisa diluncurake saben dina tanpa koordinasi karo kita. Lan iku penting kanggo kita ngawasi release iki, amarga padha duweni potensi mengaruhi operasi saka aplikasi lan break soko, lan iki kritis. Kanggo ngatur rilis, kita nggunakake Bamboo, saka ngendi kita nampa data liwat API lan bisa ndeleng rilis sing wis dirilis ing sistem informasi lan statuse. Lan sing paling penting yaiku ing wektu apa. Kita superimpose spidol release ing metrik kritis utama, kang visual banget indikatif ing cilik saka masalah.
Kanthi cara iki kita bisa ndeleng korélasi antara rilis anyar lan masalah sing muncul. Ide utama yaiku kanggo mangerteni carane sistem bisa digunakake ing kabeh lapisan, kanthi cepet lokalake masalah lan ndandani kanthi cepet. Sawise kabeh, asring kedadeyan sing paling akeh wektu ora ngrampungake masalah, nanging nggoleki sababe.
Lan ing wilayah iki ing mangsa ngarep kita pengin fokus ing proactivity. Saenipun, aku pengin ngerti babagan masalah sing nyedhaki sadurunge, lan ora sawise kasunyatan, supaya aku bisa nyegah tinimbang ngatasi. Kadhangkala weker palsu saka sistem ngawasi kedadeyan, amarga kesalahan manungsa lan amarga owah-owahan ing aplikasi. Lan kita nggarap iki, debug, lan nyoba ngelingake pangguna sing nggunakake karo kita babagan iki sadurunge manipulasi sistem pemantauan , utawa nindakake aktivitas kasebut ing jendela teknis.
Dadi, sistem kasebut wis diluncurake lan wis sukses wiwit wiwitan musim semi ... lan nuduhake bathi sing nyata banget. Mesthi, iki dudu versi pungkasan; kita bakal ngenalake akeh fitur sing luwih migunani. Nanging saiki, kanthi akeh integrasi lan aplikasi, otomatisasi pemantauan pancen ora bisa dihindari.
Yen sampeyan uga ngawasi proyek gedhe kanthi jumlah integrasi sing signifikan, tulisake ing komentar apa peluru perak sing ditemokake kanggo iki.
Source: www.habr.com