Dina iki, saliyane kode monolitik, proyek kita kalebu puluhan layanan mikro. Saben wong kudu dipantau. Nindakake skala kasebut kanthi nggunakake insinyur DevOps dadi masalah. Kita wis ngembangake sistem pemantauan sing bisa digunakake minangka layanan kanggo pangembang. Dheweke bisa nulis metrik kanthi mandiri ing sistem ngawasi, nggunakake, nggawe dashboard adhedhasar, lan masang tandha sing bakal dipicu nalika nilai ambang tekan. Kanggo insinyur DevOps, mung infrastruktur lan dokumentasi.
Kiriman iki minangka transkrip pidato karo kita ing RIT++. Akeh wong sing njaluk kita nggawe versi teks laporan saka kana. Yen sampeyan ana ing konferensi utawa nonton video, sampeyan ora bakal nemokake sing anyar. Lan wong liya - welcome kanggo kucing. Aku bakal pitutur marang kowe carane kita teka menyang sistem kuwi, cara kerjane lan carane kita rencana kanggo nganyari.
Kapungkur: rencana lan rencana
Kepiye carane kita tekan sistem pemantauan saiki? Kanggo njawab pitakonan iki, sampeyan kudu pindhah menyang 2015. Iki kaya sing katon:
Kita duwe sekitar 24 kelenjar sing tanggung jawab kanggo ngawasi. Ana paket lengkap mahkota, skrip, daemon sing beda-beda sing bisa ngawasi, ngirim pesen, lan nindakake fungsi. We panginten sing luwih kita tindak, sistem kuwi bakal kurang sregep. Ora ana gunane kanggo ngembangake: rumit banget.
Kita mutusake kanggo milih unsur ngawasi sing bakal tetep lan dikembangake, lan sing bakal ditinggalake. Ana 19. Mung grafit, aggregator lan Grafana minangka dashboard sing isih ana. Nanging apa sistem anyar bakal katon kaya? Kaya iki:
Kita duwe panyimpenan metrik: iki grafit, sing bakal adhedhasar drive SSD cepet, iki minangka agregator tartamtu kanggo metrik. Sabanjure - Grafana kanggo nampilake dashboard lan Moira kanggo menehi tandha. Kita uga pengin ngembangake sistem kanggo nggoleki anomali.
Standar: Monitoring 2.0
Iki minangka rencana sing katon ing 2015. Nanging kita kudu nyiapake ora mung infrastruktur lan layanan kasebut, nanging uga dokumentasi kasebut. Kita wis ngembangake standar perusahaan kanggo awake dhewe, sing diarani pemantauan 2.0. Apa syarat kanggo sistem kasebut?
- kasedhiyan pancet;
- interval panyimpenan metrik = 10 detik;
- panyimpenan terstruktur saka metrik lan dashboard;
- SLA > 99,99%
- koleksi metrik acara liwat UDP (!).
Kita butuh UDP amarga kita duwe arus lalu lintas lan acara sing akeh sing ngasilake metrik. Yen sampeyan nulis kabeh menyang grafit bebarengan, panyimpenan bakal ambruk. Kita uga milih awalan tingkat pertama kanggo kabeh metrik.
Saben prefiks duwe sawetara properti. Ana metrik kanggo server, jaringan, wadah, sumber daya, aplikasi, lan liya-liyane. Nyaring sing cetha, ketat, diketik wis dileksanakake, ing ngendi kita nampa metrik tingkat pertama lan mung nyelehake liyane. Iki carane kita ngrancang sistem iki ing 2015. Apa ing saiki?
Saiki: diagram interaksi komponen pemantauan
Kaping pisanan, kita ngawasi aplikasi: kode PHP, aplikasi lan layanan mikro - ing cendhak, kabeh sing ditulis pangembang kita. Kabeh aplikasi ngirim metrik liwat UDP menyang agregator Brubeck (statsd, ditulis maneh ing C). Ternyata paling cepet ing tes sintetik. Lan ngirim metrik sing wis dikumpulake menyang Graphite liwat TCP.
Nduwe jinis metrik sing diarani timer. Iki minangka barang sing trep banget. Contone, kanggo saben sambungan pangguna menyang layanan, sampeyan ngirim metrik karo wektu respon kanggo Brubeck. Sejuta tanggapan teka, nanging aggregator mung ngasilake 10 metrik. Sampeyan duwe nomer wong sing teka, maksimum, minimal lan rata-rata wektu nanggepi, median lan 4 persentil. Banjur data ditransfer menyang Graphite lan kita ndeleng kabeh urip.
Kita uga duwe agregasi kanggo metrik babagan hardware, piranti lunak, metrik sistem lan sistem pemantauan Munin lawas (bisa digunakake nganti 2015). Kita ngumpulake kabeh iki liwat daemon C's CollectD (wis ana macem-macem plugin sing beda-beda, bisa polling kabeh sumber daya sistem host sing diinstal, mung nemtokake konfigurasi ing ngendi kanggo nulis data) lan nulis data menyang Graphite liwat. Uga ndhukung plugin python lan skrip cangkang, supaya sampeyan bisa nulis solusi khusus dhewe: CollectD bakal ngumpulake data iki saka host lokal utawa remot (assuming Curl) lan ngirim menyang Graphite.
Banjur kita ngirim kabeh metrik sing diklumpukake menyang Carbon-c-relay. Iki minangka solusi Carbon Relay saka Graphite, sing diowahi ing C. Iki minangka router sing nglumpukake kabeh metrik sing dikirim saka agregator lan ngarahake menyang simpul. Uga ing tataran nuntun, mriksa validitas metrik. Kaping pisanan, dheweke kudu cocog karo skema awalan sing daktuduhake sadurunge lan, nomer loro, sah kanggo grafit. Yen ora, dheweke bakal nyelehake.
Carbon-c-relay banjur ngirim metrik menyang kluster Graphite. Kita nggunakake Carbon-cache, ditulis maneh ing Go, minangka panyimpenan utama metrik. Go-carbon, amarga multithreading sawijining, adoh outperforms Carbon-cache. Iki nampa data lan nulis menyang disk nggunakake paket whisper (standar, ditulis ing python). Kanggo maca data saka panyimpenan, kita nggunakake API Grafit. Iku luwih cepet tinimbang standar Graphite WEB. Apa sing kedadeyan ing data sabanjure?
Dheweke menyang Grafana. Kita nggunakake kluster grafit minangka sumber data utama, plus kita duwe Grafana minangka antarmuka web kanggo nampilake metrik lan mbangun dashboard. Kanggo saben layanan, pangembang nggawe dashboard dhewe. Banjur nggawe grafik adhedhasar, sing nampilake metrik sing ditulis saka aplikasi kasebut. Saliyane Grafana, kita uga duwe SLAM. Iki minangka setan python sing ngitung SLA adhedhasar data saka grafit. Kaya sing wis dakkandhakake, kita duwe sawetara rolas layanan mikro, sing saben duwe syarat dhewe. Nggunakake SLAM, kita pindhah menyang dokumentasi lan mbandhingake karo apa sing ana ing Graphite lan mbandhingake kepiye syarat cocog karo kasedhiyan layanan.
Ayo dadi luwih: waspada. Iki diatur kanthi nggunakake sistem sing kuwat - Moira. Mandiri amarga nduweni Grafit dhewe ing sangisore hood. Dikembangake dening wong lanang saka SKB "Kontur", ditulis nganggo python lan Go, kanthi open source. Moira nampa aliran sing padha karo grafit. Yen ana alesan panyimpenan sampeyan mati, tandha sampeyan isih bisa digunakake.
Kita nyebarake Moira ing Kubernetes; nggunakake kluster server Redis minangka basis data utama. Asil ana sistem fault-tolerant. Iki mbandhingake aliran metrik karo dhaptar pemicu: yen ora ana sing nyebutake, banjur bakal ngeculake metrik kasebut. Dadi bisa nyerna gigabyte metrik saben menit.
Kita uga nempelake LDAP perusahaan, kanthi bantuan saben pangguna sistem perusahaan bisa nggawe kabar kanggo awake dhewe adhedhasar pemicu sing ana (utawa mentas digawe). Wiwit Moira ngemot Graphite, ndhukung kabeh fitur. Dadi, sampeyan kudu njupuk baris lan nyalin menyang Grafana. Deleng carane data ditampilake ing grafik. Banjur sampeyan njupuk baris sing padha lan nyalin menyang Moira. Sampeyan nyumerepi karo watesan lan njaluk tandha ing output. Kanggo nindakake kabeh iki, sampeyan ora mbutuhake kawruh khusus. Moira bisa menehi tandha liwat SMS, email, Jira, Slack ... Uga ndhukung eksekusi skrip khusus. Nalika pemicu kelakon kanggo dheweke, lan dheweke wis langganan script adat utawa binar, dheweke mbukak lan ngirim JSON kanggo stdin kanggo binar iki. Mulane, program sampeyan kudu ngurai. Apa sing bakal sampeyan lakoni karo JSON iki terserah sampeyan. Yen sampeyan pengin, kirim menyang Telegram, yen sampeyan pengin, mbukak tugas ing Jira, apa wae.
Kita uga nggunakake pangembangan dhewe kanggo menehi tandha - Imagotag. Kita adaptasi panel, sing biasane digunakake kanggo tag rega elektronik ing toko, supaya cocog karo kabutuhan. Kita nggawa pemicu saka Moira. Iki nuduhake kahanan apa lan nalika kedadeyan kasebut. Sawetara wong pembangunan ninggalake kabar ing Slack lan email kanggo panel iki.
Ya, amarga kita minangka perusahaan sing progresif, kita uga ngawasi Kubernetes ing sistem iki. We klebu ing sistem nggunakake Heapster, kang diinstal ing kluster, ngumpulake data lan dikirim menyang Graphite. AkibatΓ©, diagram katon kaya iki:
Komponen ngawasi
Punika dhaptar pranala menyang komponen sing digunakake kanggo tugas iki. Kabeh mau open source.
Grafit:
- go-karbon:
- bisik-bisik:
- grafit-api:
Karbon-c-relay:
Brubeck:
Diklumpukake:
Moira:
Grafana:
Heapster:
Π‘ΡΠ°ΡΠΈΡΡΠΈΠΊΠ°
Lan ing ngisor iki sawetara nomer babagan cara sistem bisa digunakake kanggo kita.
Aggregator (brubeck)
Jumlah metrik: ~300/detik
Interval kanggo ngirim metrik menyang Graphite: 30 detik
Panggunaan sumber daya server: ~ 6% CPU (kita ngomong babagan server lengkap); ~ 1 Gb RAM; ~3 Mbps LAN
Grafit (go-carbon)
Jumlah metrik: ~ 1 / min
Interval nganyari metrik: 30 detik
Skema panyimpenan metrik: 30sec 35d, 5min 90d, 10min 365d (menehi pangerten babagan apa sing kedadeyan ing layanan sajrone wektu sing suwe)
Panggunaan sumber daya server: ~ 10% CPU; ~ 20 Gb RAM; ~30 Mbps LAN
Keluwesan
Kita ing Avito pancen ngormati keluwesan ing layanan pemantauan. Yagene dheweke pancen dadi kaya ngene? Kaping pisanan, komponen kasebut bisa diganti: komponen kasebut dhewe lan versi. Kapindho, supportability. Amarga kabeh proyek mbukak sumber, sampeyan bisa nyunting kode dhewe, ngowahi, lan ngleksanakake fungsi sing ora kasedhiya ing kothak kasebut. tumpukan cukup umum digunakake, utamanΓ© Go lan Python, supaya iki rampung cukup prasaja.
Punika conto masalah nyata. Metrik ing Graphite minangka file. Wis jeneng. Jeneng berkas = jeneng metrik. Lan ana cara kanggo njaluk ana. Jeneng berkas ing Linux diwatesi nganti 255 karakter. Lan kita duwe (minangka "pelanggan internal") saka departemen database. Dheweke ngandhani: "Kita pengin ngawasi pitakon SQL kita. Lan padha ora 255 karakter, nanging 8 MB saben. Kita pengin nampilake ing Grafana, ndeleng paramèter kanggo panyuwunan iki, lan luwih apik, kita pengin ndeleng ndhuwur panjaluk kasebut. Iku bakal apik yen ditampilake ing wektu nyata. Iku bakal apik tenan kanggo sijine wong ing tandha.
Conto query SQL dijupuk minangka conto saka
Kita nyiyapake server Redis lan nggunakake plugin Collectd, sing menyang Postgres lan njupuk kabeh data saka kono, ngirim metrik menyang Graphite. Nanging kita ngganti jeneng metrik karo hash. Kita bebarengan ngirim hash sing padha menyang Redis minangka kunci, lan kabeh query SQL minangka nilai. Kabeh sing kudu ditindakake yaiku manawa Grafana bisa menyang Redis lan njupuk informasi kasebut. Kita mbukak API Grafit amarga ... iki antarmuka utama kanggo interaksi kabeh komponen ngawasi karo grafit, lan kita ngetik fungsi anyar ana disebut aliasByHash () - saka Grafana kita njaluk jeneng metrik, lan digunakake ing request kanggo Redis minangka tombol, ing respon kita entuk nilai kunci, yaiku "query SQL" kita. Mangkono, kita ditampilake ing Grafana tampilan query SQL, kang ing teori mokal kanggo ditampilake ing kono, bebarengan karo statistik ing (telpon, larik, total_time, ...).
Hasil
Kasedhiyan Layanan pemantauan kasedhiya 24/7 saka aplikasi lan kode apa wae. Yen sampeyan duwe akses menyang fasilitas panyimpenan, sampeyan bisa nulis data menyang layanan kasebut. Basa ora penting, keputusan ora penting. Sampeyan mung kudu ngerti carane mbukak soket, sijine metrik ana lan nutup soket.
Reliability Kabeh komponen sing fault-tolerant lan nangani kathah kita uga.
Rintangan kurang kanggo mlebu. Kanggo nggunakake sistem iki, sampeyan ora perlu sinau basa pemrograman lan pitakon ing Grafana. Bukak aplikasi sampeyan, ketik soket sing bakal ngirim metrik menyang Graphite, tutup, bukak Grafana, nggawe dashboard ing kana lan deleng prilaku metrik sampeyan, nampa kabar liwat Moira.
kamardikan. Sampeyan bisa nindakake kabeh iki dhewe, tanpa bantuan insinyur DevOps. Lan iki minangka kauntungan, amarga sampeyan bisa ngawasi proyek sampeyan saiki, sampeyan ora kudu takon sapa wae - kanggo miwiti kerja utawa ngganti.
Apa sing kita usahakake?
Kabeh sing kapacak ing ngisor iki ora mung pikiran abstrak, nanging soko sing paling ora langkah pisanan wis ditindakake.
- Detektor anomali. Kita pengin nggawe layanan sing bakal menyang panyimpenan Graphite lan mriksa saben metrik nggunakake macem-macem algoritma. Wis ana algoritma sing pengin dideleng, ana data, kita ngerti cara nggarap.
- Metadata. Kita duwe akeh layanan, padha ganti wektu, kaya wong sing kerja bareng. Terus-terusan njaga dokumentasi kanthi manual ora dadi pilihan. Pramila kita saiki nyisipake metadata menyang layanan mikro kita. Iki nyatakake sapa sing ngembangake, basa sing sesambungan karo, syarat SLA, ing ngendi lan menyang sapa kabar kudu dikirim. Nalika nyebarake layanan, kabeh data entitas digawe kanthi mandiri. AkibatΓ©, sampeyan entuk rong pranala - siji kanggo pemicu, liyane menyang dashboard ing Grafana.
- Ngawasi ing saben omah. Kita yakin manawa kabeh pangembang kudu nggunakake sistem kasebut. Ing kasus iki, sampeyan tansah ngerti ngendi lalu lintas sampeyan, apa sing kedadeyan, ing ngendi tiba, ing ngendi kelemahane. Yen, contone, ana sing teka lan nabrak layanan sampeyan, sampeyan bakal sinau babagan ora sajrone telpon saka manajer, nanging saka tandha, lan sampeyan bisa langsung mbukak log paling anyar lan ndeleng apa sing kedadeyan ing kana.
- Kualitas apik. Proyek kita terus berkembang, lan saiki ngolah udakara 2 nilai metrik saben menit. Setaun kepungkur, angka iki ana 000. Lan wutah terus, lan iki tegese sawise sawetara wektu Graphite (bisikan) bakal miwiti mbukak akeh subsistem disk. Kaya sing wis dakkandhakake, sistem pemantauan iki cukup universal amarga bisa diganti komponen. Ana sing njaga lan terus-terusan ngembangake infrastruktur khusus kanggo Graphite, nanging kita mutusake kanggo pindhah menyang rute sing beda: gunakake minangka gudang kanggo metrik kita. Transisi iki meh rampung, lan rauh aku bakal pitutur marang kowe ing liyane rinci carane iki rampung: apa kangelan ana lan carane padha ditanggulangi, carane proses migrasi tindak, Aku bakal njlèntrèhaké komponen sing dipilih minangka naleni lan konfigurasi.
Matur nuwun kanggo perhatian sampeyan! Takon pitakonan sampeyan babagan topik kasebut, aku bakal nyoba mangsuli ing kene utawa ing kiriman ing ngisor iki. Mbok menawa ana wong sing duwe pengalaman mbangun sistem pemantauan sing padha utawa ngalih menyang Clickhouse ing kahanan sing padha - nuduhake ing komentar.
Source: www.habr.com