Jenengku Anton Baderin. Aku kerja ing Pusat Teknologi Tinggi lan nindakake administrasi sistem. Sewulan kepungkur, konferensi perusahaan kita rampung, ing ngendi kita nuduhake pengalaman akumulasi karo komunitas IT ing kutha kita. Aku ngomong babagan ngawasi aplikasi web. Materi kasebut ditrapake kanggo tingkat junior utawa menengah, sing ora mbangun proses iki saka awal.
Watu dhasar sing ndasari sistem pemantauan yaiku ngrampungake masalah bisnis. Ngawasi kanggo ngawasi ora ana kapentingan kanggo sapa wae. Apa sing dikarepake bisnis? Supaya kabeh bisa cepet lan tanpa kesalahan. Bisnis pengin proaktif, supaya kita dhewe ngenali masalah ing layanan lan ndandani kanthi cepet. Iki, nyatane, minangka masalah sing dakrampungake kabeh taun kepungkur ing proyek kanggo salah sawijining pelanggan.
Prakawis proyek
Proyek kasebut minangka salah sawijining program kesetiaan paling gedhe ing negara kasebut. Kita mbantu ranté ritel nambah frekuensi dodolan liwat macem-macem alat marketing kayata kertu bonus. Secara total, proyek kasebut kalebu 14 aplikasi sing mlaku ing sepuluh server.
Sajrone proses wawancara, aku bola-bali weruh manawa admin ora tansah nyedhaki aplikasi web kanthi bener: akeh sing isih fokus ing metrik sistem operasi lan sok-sok ngawasi layanan.
Ing kasusku, sistem ngawasi pelanggan sadurunge adhedhasar Icinga. Ora ngrampungake masalah ing ndhuwur kanthi cara apa wae. Asring klien dhewe ngandhani babagan masalah, lan luwih asring, kita mung ora duwe data sing cukup kanggo ngerteni alasane.
Kajaba iku, ana pangerten sing jelas babagan muspra pangembangan luwih lanjut. Aku sing kenal karo Icinga bakal ngerti aku. Dadi, kita mutusake kanggo ngrancang maneh sistem pemantauan aplikasi web kanggo proyek kasebut.
Prometheus
Kita milih Prometheus adhedhasar telung indikator utama:
- Jumlah metrik sing kasedhiya. Ing kasus kita ana 60 ewu. Mesti wae, iku worth kang lagi nyimak sing kita ora nggunakake akèh-akèhé saka wong-wong mau (mbokmenawa bab 95%). Ing tangan liyane, padha kabeh relatif murah. Kanggo kita, iki minangka ekstrem liyane dibandhingake karo Icinga sing digunakake sadurunge. Ing kono, nambah metrik minangka rasa lara tartamtu: sing ana larang (mung deleng kode sumber plugin apa wae). Sembarang plugin minangka skrip ing Bash utawa Python, sing diluncurake larang babagan sumber daya sing dikonsumsi.
- Sistem iki nggunakake sumber daya sing relatif cilik. 600 MB RAM, 15% saka siji inti lan sawetara rolas IOPS cukup kanggo kabeh metrik kita. Mesthi, sampeyan kudu mbukak eksportir metrik, nanging kabeh ditulis ing Go lan uga ora keluwen banget. Aku ora mikir yen ing kasunyatan modern iki masalah.
- Nyedhiyani kemampuan kanggo pindhah menyang Kubernetes. Ngelingi rencana pelanggan, pilihan kasebut jelas.
ELK
Sadurunge, kita ora ngumpulake utawa ngolah log. Kekurangane jelas kanggo kabeh wong. Kita milih ELK amarga kita wis duwe pengalaman karo sistem iki. Kita mung nyimpen log aplikasi ing kana. Kriteria pilihan utama yaiku panelusuran teks lengkap lan kacepetan.
Сlickhouse
Kaping pisanan, pilihan kasebut tiba ing InfluxDB. Kita nyadari kabutuhan kanggo ngumpulake log Nginx, statistik saka pg_stat_statements, lan nyimpen data historis Prometheus. Kita ora seneng Influx amarga kanthi periodik wiwit ngonsumsi akeh memori lan nabrak. Kajaba iku, aku pengin nglumpukake pitakon kanthi remote_addr, nanging klompok ing DBMS iki mung kanthi tag. Tag larang (memori), nomer kasebut diwatesi kanthi syarat.
Kita miwiti panelusuran maneh. Sing dibutuhake yaiku basis data analitis kanthi konsumsi sumber daya minimal, luwih becik karo kompresi data ing disk.
Clickhouse nyukupi kabeh kritéria kasebut, lan kita ora nate nyesel karo pilihan kita. Kita ora nulis jumlah data sing luar biasa (jumlah sisipan mung kira-kira limang ewu saben menit).
NewRelic
NewRelic wis sejarah karo kita amarga iku pilihan pelanggan. Kita nggunakake minangka APM.
Zabbix
Kita nggunakake Zabbix khusus kanggo ngawasi Black Box saka macem-macem API.
Nemtokake Pendekatan Ngawasi
We wanted kanggo decompose tugas lan kanthi mangkono systematize pendekatan kanggo ngawasi.
Kanggo nindakake iki, aku dibagi sistem kita dadi tingkat ing ngisor iki:
- hardware lan VMS;
- sistem operasi;
- layanan sistem, tumpukan piranti lunak;
- aplikasi;
- logika bisnis.
Napa pendekatan iki trep:
- kita ngerti sing tanggung jawab kanggo karya saben tingkat lan, adhedhasar iki, kita bisa ngirim tandha;
- kita bisa nggunakake struktur nalika suppressing tandha - iku bakal aneh kanggo ngirim tandha bab kasedhiyan database nalika mesin virtual minangka kabèh ora kasedhiya.
Wiwit tugas kita kanggo ngenali pelanggaran ing operasi sistem, kita kudu ing saben tingkat nyorot pesawat tartamtu saka metrik sing worth mbayar manungsa waé kanggo nalika nulis aturan alerting. Sabanjure, ayo pindhah menyang level "VMS", "Sistem operasi" lan "Layanan sistem, tumpukan piranti lunak".
Mesin virtual
Hosting allocates kita prosesor, disk, memori lan jaringan. Lan kita duwe masalah karo loro pisanan. Dadi, metrik:
CPU dicolong wektu - nalika sampeyan tuku mesin virtual ing Amazon (t2.micro, contone,), sampeyan kudu ngerti sing ora diparengake inti prosesor kabeh, nanging mung kuota wektu. Lan yen sampeyan entek, prosesor bakal dijupuk saka sampeyan.
Metrik iki ngidini sampeyan nglacak momen kasebut lan nggawe keputusan. Contone, iku perlu kanggo njupuk tarif fatter utawa disebaraké Processing saka tugas latar mburi lan panjalukan API kanggo server beda?
IOPS + CPU iowait wektu - sakperangan alesan, akeh maya hosting dosa amarga ora nyedhiyani cukup IOPS. Kajaba iku, jadwal kanthi IOPS sing sithik ora dadi argumentasi kanggo dheweke. Mulane, iku worth ngempalaken CPU iowait. Kanthi pasangan grafik iki - kanthi IOPS sing sithik lan ngenteni I / O dhuwur - sampeyan wis bisa ngomong karo hosting lan ngatasi masalah kasebut.
sistem operasi
Metrik sistem operasi:
- jumlah memori sing kasedhiya ing%;
- aktivitas panggunaan swap: vmstat swapin, swapout;
- jumlah inode sing kasedhiya lan ruang kosong ing sistem file ing%
- beban rata-rata;
- nomer sambungan ing negara tw;
- conntrack meja fullness;
- Kualitas jaringan bisa dipantau nggunakake sarana ss, paket iproute2 - entuk indikator sambungan RTT saka output lan klompok kanthi port dest.
Uga ing tingkat sistem operasi kita duwe entitas kaya pangolahan. Penting kanggo ngenali ing sistem sakumpulan pangolahan sing nduweni peran penting ing operasi kasebut. Yen, contone, sampeyan duwe sawetara pgpools, sampeyan kudu ngumpulake informasi kanggo saben wong.
Set metrik kaya ing ngisor iki:
- CPU;
- memori utamané penduduk;
- IO - luwih apik ing IOPS;
- FileFd - mbukak lan watesan;
- gagal kaca sing signifikan - kanthi cara iki sampeyan bisa ngerti proses apa sing diganti.
Kita nyebarake kabeh pemantauan ing Docker, lan nggunakake Advisor kanggo ngumpulake data metrik. Ing mesin liyane kita nggunakake proses-eksportir.
Layanan sistem, tumpukan piranti lunak
Saben aplikasi duwe spesifik dhewe, lan angel nemtokake metrik tartamtu.
Set universal yaiku:
- tingkat panyuwunan;
- nomer kesalahan;
- latensi;
- jenuh
Conto pemantauan sing paling apik ing level iki yaiku Nginx lan PostgreSQL.
Layanan sing paling dimuat ing sistem kita yaiku database. Ing jaman kepungkur, kita kerep ngalami alangan kanggo ngerteni apa sing ditindakake database.
Kita weruh beban dhuwur ing disk, nanging log alon ora nuduhake apa-apa. Kita ngrampungake masalah iki nggunakake pg_stat_statements, tampilan sing ngumpulake statistik pitakon.
Iku kabeh sing dibutuhake admin.
Kita mbangun grafik saka kegiatan maca lan nulis panjalukan:
Kabeh iku prasaja lan cetha, saben panjalukan duwe werna dhewe.
Conto sing padha yaiku log Nginx. Ora nggumunake yen sawetara wong ngurai utawa nyebutake ing dhaptar sing kudu diduweni. Format standar ora banget informatif lan kudu ditambahi.
Secara pribadi, aku nambahake request_time, upstream_response_time, body_bytes_sent, request_length, request_id. We plot wektu respon lan nomer kasalahan:
Kita mbangun grafik wektu nanggepi lan jumlah kesalahan. Eling? Apa aku ngomong babagan tugas bisnis? Kanggo cepet lan tanpa kesalahan? Kita wis ngrampungake masalah kasebut kanthi rong grafik. Lan sampeyan wis bisa nelpon administrator ing tugas nggunakake.
Nanging siji masalah liyane tetep - kanggo mesthekake eliminasi cepet saka nimbulaké saka kedadean.
Resolusi kedadean
Kabeh proses saka ngenali nganti ngrampungake masalah bisa dipérang dadi sawetara langkah:
- ngenali masalah;
- kabar menyang administrator tugas;
- nanggepi kedadeyan;
- eliminasi sabab.
Penting yen kita kudu nindakake iki kanthi cepet. Lan yen ing tahapan ngenali masalah lan ngirim kabar, kita ora bisa entuk akeh wektu - rong menit bakal ditindakake ing kasus apa wae, mula sing sabanjure mung dadi lapangan kanggo perbaikan.
Coba mbayangno telpone petugas muni. Apa sing bakal ditindakake? Goleki jawaban kanggo pitakonan - apa pecah, ngendi pecah, carane nanggepi? Mangkene carane mangsuli pitakon kasebut:
Kita mung nyakup kabeh informasi iki ing teks kabar, menehi link menyang kaca wiki sing nerangake carane nanggapi masalah iki, carane ngatasi lan nambah.
Aku isih durung ngomong apa-apa bab lapisan aplikasi lan logika bisnis. Sayange, aplikasi kita durung ngetrapake koleksi metrik. Siji-sijine sumber informasi saka tingkat kasebut yaiku log.
A saperangan saka TCTerms.
Pisanan, nulis log terstruktur. Ora perlu ngemot konteks ing teks pesen. Iki ndadekake dheweke angel dikelompokake lan dianalisis. Logstash butuh wektu suwe kanggo normalake kabeh iki.
Kapindho, gunakake tingkat keruwetan kanthi bener. Saben basa nduweni standar dhewe-dhewe. Secara pribadi, aku mbedakake papat tingkat:
- ora ana kesalahan;
- kesalahan sisih klien;
- kesalahan ana ing sisih kita, kita ora kelangan dhuwit, kita ora nanggung risiko;
- Kesalahan ana ing sisih kita, kita kelangan dhuwit.
Ayo kula ngringkes. Sampeyan kudu nyoba mbangun pemantauan adhedhasar logika bisnis. Coba ngawasi aplikasi kasebut dhewe lan operate kanthi metrik kayata jumlah dodolan, jumlah registrasi pangguna anyar, jumlah pangguna sing saiki aktif, lan liya-liyane.
Yen kabeh bisnis sampeyan mung siji tombol ing browser, sampeyan kudu ngawasi apa klik lan bisa digunakake kanthi bener. Kabeh liyane ora masalah.
Yen sampeyan ora duwe iki, sampeyan bisa nyoba kanggo nggayuh ing log aplikasi, log Nginx, lan liya-liyane, kaya sing ditindakake. Sampeyan kudu dadi cedhak karo aplikasi sabisa.
Metrik sistem operasi mesthi penting, nanging bisnis ora kasengsem, kita ora dibayar.
Source: www.habr.com