Naha monitoring maot? - Pangimeutan hirup panjang

Kusabab 2008, parusahaan urang geus utamana kalibet dina manajemen infrastruktur sarta rojongan teknis round-the-jam pikeun proyék-proyék web: urang boga leuwih ti 400 klien, nu kira 15% tina e-commerce Rusia. Sasuai, arsitéktur pisan rupa-rupa dirojong. Lamun aya nu ragrag, urang wajib ngalereskeun eta dina 15 menit. Tapi pikeun ngarti yén kacilakaan parantos kajantenan, anjeun kedah ngawas proyék sareng ngabales kajadian. Kumaha carana ngalakukeun ieu?

Kuring yakin yén aya masalah dina pangatur sistem monitoring ditangtoskeun. Upami teu aya masalah, maka pidato kuring bakal diwangun ku hiji skripsi: "Mangga pasang Prometheus + Grafana sareng plugins 1, 2, 3." Hanjakal, éta henteu jalan deui. Jeung masalah utama nyaeta dulur terus yakin kana hal anu eksis di 2008, dina hal komponén software.

Ngeunaan organisasi sistem ngawaskeun, abdi bakal Modal disebutkeun yen ... proyék kalawan monitoring kompeten teu aya. Sareng kaayaanna parah pisan upami aya anu ragrag, aya résiko anu bakal teu diémutan - saatosna, sadayana yakin yén "sadayana diawaskeun."
Sugan sagalana keur diawaskeun. Tapi kumaha?

Urang sadaya parantos mendakan carita sapertos kieu: devops tangtu, admin tangtu berpungsi, tim pangembangan datang ka aranjeunna sareng nyarios - "kami dileupaskeun, ayeuna monitor." Monitor naon? Kumaha gawéna?

OKÉ. Urang ngawas cara baheula. Sareng parantos robih, sareng tétéla anjeun ngawaskeun jasa A, anu janten jasa B, anu berinteraksi sareng jasa C. Tapi tim pamekar nyarioskeun ka anjeun: "Pasang parangkat lunak, éta kedah ngawas sadayana!"

Janten naon anu parantos robih? - Sagalana geus robah!

2008 Sagalana geus rupa

Aya sababaraha pamekar, hiji server, hiji server database. Éta sadayana angkat ti dieu. Simkuring gaduh sababaraha émbaran, urang install zabbix, Nagios, cacti. Teras we nyetél panggeuing anu jelas dina CPU, operasi disk, sareng rohangan disk. Urang ogé ngalakukeun sababaraha cék manual pikeun mastikeun yén situs ngaréspon sareng pesenan parantos sumping dina pangkalan data. Sareng éta - kami langkung atanapi kirang dilindungi.

Upami urang ngabandingkeun jumlah padamelan anu dilakukeun ku administrator teras nyayogikeun monitoring, maka 98% tina éta otomatis: jalma anu ngawaskeun kedah ngartos kumaha masang Zabbix, kumaha ngonpigurasikeunana sareng ngonpigurasikeun panggeuing. Jeung 2% - pikeun cék éksternal: yén situs responds sarta nyieun pamundut ka database, yén pesenan anyar geus anjog.

2010 Beungbeuratna beuki nambahan

Kami ngamimitian skala wéb, nambihan mesin pencari. Kami hoyong mastikeun yén katalog produk ngandung sadaya produk. Jeung nu pilarian produk jalan. Éta database berpungsi, éta pesenan keur dijieun, éta situs responds externally sarta responds ti dua server na pamaké teu ditajong kaluar tina situs bari eta rebalanced kana server sejen, jsb. Aya deui éntitas.

Leuwih ti éta, éntitas pakait sareng infrastruktur masih tetep pangbadagna dina sirah manajer urang. Masih aya ide dina sirah kuring yén jalma anu ngawaskeun nyaéta jalma anu bakal masang zabbix sareng tiasa ngonpigurasikeunana.

Tapi dina waktos anu sami, padamelan muncul dina ngalaksanakeun pamariksaan éksternal, dina nyiptakeun sakumpulan skrip query indexer milarian, sakumpulan skrip pikeun mariksa yén pamilarian parobihan salami prosés indexing, sakumpulan skrip anu pariksa yén barang ditransferkeun ka jasa pangiriman, jsb. teras salajengna.

Catetan: Kuring nulis "sakumpulan naskah" 3 kali. Hartina, jalma anu tanggung jawab pikeun ngawaskeun henteu deui anu ngan saukur masang zabbix. Ieu jalma anu ngamimitian coding. Tapi teu aya anu robih dina pikiran tim.

Tapi dunya robih, janten langkung rumit. Lapisan virtualisasi sareng sababaraha sistem anyar ditambahkeun. Aranjeunna ngawitan interaksi saling. Anu nyarios "bau sapertos microservices?" Tapi unggal jasa tetep katingali sapertos halaman wéb masing-masing. Urang tiasa giliran éta sareng ngartos yén éta nyayogikeun inpormasi anu diperyogikeun sareng jalanna nyalira. Sareng upami anjeun administrator anu terus-terusan aub dina proyék anu parantos ngembangkeun 5-7-10 taun, pangaweruh ieu ngumpulkeun: tingkat anyar muncul - anjeun sadar, tingkat anu sanés muncul - anjeun sadar ...

Tapi jarang aya anu ngiringan proyék salami 10 taun.

neruskeun Monitoringman urang

Anggap anjeun sumping ka ngamimitian anyar anu langsung nyéwa 20 pamekar, nyerat 15 microservices, sareng anjeun mangrupikeun admin anu nyarios: "Ngawangun CI / CD. Punten." Anjeun geus diwangun CI / CD sarta ujug-ujug anjeun ngadangu: "Hésé pikeun urang gawé bareng produksi dina" kubus ", tanpa ngarti kumaha aplikasi bakal dianggo dina. Jieun kami sandbox dina sarua "kubus".
Anjeun nyieun sandbox dina kubus ieu. Aranjeunna langsung nyarios ka anjeun: "Kami hoyong pangkalan data panggung anu diropéa unggal dinten tina produksi, supados urang ngartos yén éta tiasa dianggo dina pangkalan data, tapi dina waktos anu sami henteu ngarusak database produksi."

Anjeun hirup dina sakabéh ieu. Aya 2 minggu ditinggalkeun saméméh release, aranjeunna ngabejaan Anjeun: "Ayeuna hayu urang ngawas sadayana ieu ..." Maksudna. monitor infrastruktur klaster, monitor arsitéktur microservice, monitor gawé kalawan jasa éksternal ...

Sareng kolega kuring nyandak skéma anu biasa tina sirahna sareng ucapkeun: "Nya, sadayana jelas di dieu! Pasang program anu bakal ngawas sadayana ieu. ” Leres, leres: Prometheus + Grafana + plugins.
Sareng aranjeunna nambihan: "Anjeun gaduh dua minggu, pastikeun sadayana aman."

Dina seueur proyék anu urang tingali, hiji jalma dialokasikeun pikeun ngawaskeun. Bayangkeun yén urang hoyong nyewa jalma pikeun ngawaskeun 2 minggu, sareng urang nyerat resume pikeun anjeunna. Kaahlian naon anu kedah dipibanda ku jalma ieu, tinangtu sadayana anu urang nyarioskeun dugi ka ayeuna?

• Anjeunna kedah ngartos ngawaskeun sareng spésifikasi operasi infrastruktur beusi.
• Anjeunna kedah ngartos spésifik ngawaskeun Kubernetes (sareng sadayana hoyong angkat ka "kubus", sabab anjeun tiasa abstrak tina sadayana, nyumput, sabab admin bakal ngurus sésana) - sorangan, infrastrukturna, sareng ngartos kumaha ngawas aplikasi. jero.
• Anjeunna kedah ngartos yén jasa saling komunikasi dina cara anu khusus, sareng terang spésifik kumaha jasa saling berinteraksi. Ieu rada mungkin ningali hiji proyék dimana sababaraha layanan komunikasi sinkron, sabab euweuh jalan séjén. Contona, backend nu mana via REST, via gRPC kana layanan katalog, narima daptar produk na mulih deui. Anjeun teu tiasa ngantosan di dieu. Sareng sareng jasa anu sanés tiasa dianggo asynchronously. Mindahkeun pesenan ka layanan pangiriman, ngirim surat, jsb.
  Anjeun meureun geus swam tina sagala ieu? Sareng admin, anu kedah ngawas ieu, janten langkung bingung.
• Anjeunna kedah tiasa ngarencanakeun sareng ngarencanakeun anu leres - sabab padamelan janten langkung seueur.
• Ku alatan éta, anjeunna kedah nyiptakeun strategi tina jasa anu diciptakeun pikeun ngartos kumaha ngawaskeunana sacara khusus. Anjeunna peryogi pamahaman arsitéktur proyék sareng pangembanganana + pamahaman téknologi anu dianggo dina pangwangunan.

Hayu urang émut kasus anu normal pisan: sababaraha jasa aya dina PHP, sababaraha jasa aya dina Go, sababaraha jasa aya dina JS. Aranjeunna kumaha bae gawéna saling. Ieu tempat istilah "microservice" asalna tina: aya kitu loba sistem individu nu pamekar teu bisa ngarti proyék sakabéhna. Hiji bagian tina tim nyerat jasa dina JS anu tiasa dianggo nyalira sareng henteu terang kumaha sesa sistem jalanna. Bagian anu sanésna nyerat jasa dina Python sareng henteu ngaganggu kumaha jasa anu sanés dianggo; aranjeunna terasing di daérahna sorangan. Anu katilu nyaéta nyerat jasa dina PHP atanapi anu sanés.
Sadayana 20 jalma ieu dibagi kana 15 jasa, sareng ngan ukur hiji admin anu kedah ngartos sadayana ieu. Eureun! urang ngan ngabagi sistem kana 15 microservices sabab 20 jalma teu bisa ngarti sakabeh sistem.

Tapi kudu diawaskeun kumaha bae...

Kumaha hasilna? Hasilna, aya hiji jalma anu datang nepi ka sagalana yén sakabéh tim pamekar teu bisa ngarti, sarta dina waktos anu sareng anjeunna ogé kudu nyaho tur bisa ngalakukeun naon urang dituduhkeun di luhur - infrastruktur hardware, infrastruktur Kubernetes, jsb.

Naon anu kuring tiasa nyarios ... Houston, urang gaduh masalah.

Ngawaskeun proyék parangkat lunak modéren mangrupikeun proyék parangkat lunak nyalira

Tina kapercayaan palsu yén ngawaskeun mangrupikeun parangkat lunak, urang ngembangkeun kapercayaan kana mujijat. Tapi keajaiban, sayangna, henteu kajantenan. Anjeun teu bisa install zabbix sarta nyangka sagalana jalan. Teu aya gunana pikeun masang Grafana sareng ngarepkeun sadayana bakal ok. Kalolobaan waktu bakal spent dina pangatur cék tina operasi jasa jeung interaksi maranéhanana saling, mariksa kumaha sistem éksternal jalan. Nyatana, 90% waktos bakal dianggo sanés pikeun nyerat naskah, tapi pikeun ngembangkeun parangkat lunak. Sareng éta kedah diurus ku tim anu ngartos padamelan proyék éta.
Lamun dina kaayaan ieu hiji jalma dialungkeun kana monitoring, mangka musibah bakal kajadian. Anu lumangsung di mana-mana.

Contona, aya sababaraha layanan nu saling komunikasi via Kafka. Pesenan sumping, kami ngirim pesen ngeunaan pesenan ka Kafka. Aya jasa anu ngadangukeun inpormasi ngeunaan pesenan sareng ngirimkeun barang. Aya jasa anu ngadangukeun inpormasi ngeunaan pesenan sareng ngirim surat ka pangguna. Teras kebat langkung seueur jasa muncul, sareng urang mimiti bingung.

Sareng upami anjeun ogé masihan ieu ka admin sareng pamekar di panggung nalika aya waktos anu sakedap sateuacan dileupaskeun, jalma éta kedah ngartos sadayana protokol ieu. Jelema. Proyék skala ieu butuh waktos anu ageung, sareng ieu kedah dipertimbangkeun kana pamekaran sistem.
Tapi sering pisan, khususna dina ngamimitian, urang ningali kumaha ngawaskeun ditunda dugi ka engké. "Ayeuna urang bakal ngadamel Bukti Konsep, urang bakal ngajalankeun kalawan eta, hayu eta ragrag - kami siap kurban. Teras urang bakal ngawas sadayana. ” Nalika (atanapi upami) proyék mimiti ngahasilkeun artos, usahana hoyong nambihan langkung seueur fitur - sabab parantos ngamimitian damel, janten kedah digulung deui! Sareng anjeun dina titik dimana anjeun kedah ngawas sadayana sateuacana, anu henteu nyandak 1% waktos, tapi seueur deui. Ku jalan kitu, pamekar bakal diperlukeun pikeun ngawaskeun, sarta leuwih gampang pikeun ngidinan aranjeunna dianggo dina fitur anyar. Hasilna, fitur anyar ditulis, sagalana bakal ngaco, jeung anjeun dina deadlock sajajalan.

Janten kumaha ngawas proyék mimitian ti mimiti, sareng naon anu kudu dilakukeun upami anjeun kéngingkeun proyék anu kedah diawaskeun, tapi anjeun henteu terang dimana ngamimitian?

Kahiji, anjeun kudu rencanana.

Digression liris: sering pisan aranjeunna dimimitian ku ngawaskeun infrastruktur. Contona, urang boga Kubernetes. Hayu urang mimitian ku masang Prometheus sareng Grafana, masang plugins pikeun ngawaskeun "kubus". Henteu ngan ukur pangembang, tapi ogé pangurus ngagaduhan prakték malang: "Kami bakal masang plugin ieu, tapi plugin sigana terang kumaha ngalakukeunana." Jalma resep dimimitian ku basajan tur lugas, tinimbang ku lampah penting. Sareng ngawaskeun infrastruktur gampang.

Mimiti, mutuskeun naon sareng kumaha anjeun hoyong ngawas, teras pilih alat, sabab jalma sanés henteu tiasa mikirkeun anjeun. Sareng kedah aranjeunna? jalma séjén mikir sorangan, ngeunaan sistem universal - atawa teu sangka lamun plugin ieu ditulis. Sareng kusabab plugin ieu ngagaduhan 5 sarébu pangguna sanés hartosna éta aya gunana. Panginten anjeun bakal janten anu ka-5001 kusabab parantos aya 5000 urang sateuacanna.

Upami anjeun ngamimitian ngawaskeun infrastruktur sareng bagian tukang aplikasi anjeun lirén ngaréspon, sadaya pangguna bakal kaleungitan sambungan sareng aplikasi sélulér. Kasalahan bakal muncul. Aranjeunna bakal datang ka anjeun sareng nyarios "Aplikasi henteu jalan, naon anu anjeun lakukeun di dieu?" - "Kami ngawaskeun." - "Kumaha anjeun ngawas upami anjeun henteu ningali yén aplikasina henteu jalan?!"

1. Kuring yakin yén anjeun kedah ngamimitian ngawaskeun persis tina titik éntri pangguna. Upami pangguna henteu ningali yén aplikasina berpungsi, éta waé, éta gagal. Sareng sistem ngawaskeun kedah ngingetkeun ngeunaan ieu heula.
2. Sarta ngan lajeng urang tiasa ngawas infrastruktur. Atawa ngalakukeun eta dina paralel. Éta langkung gampang kalayan infrastruktur - di dieu urang tungtungna tiasa masang zabbix.
3. Sareng ayeuna anjeun kedah angkat ka akar aplikasi pikeun ngartos dimana hal-hal henteu jalan.

Gagasan utama kuring nyaéta ngawaskeun kedah paralel sareng prosés pangwangunan. Upami anjeun ngaganggu tim ngawaskeun pikeun tugas-tugas sanés (nyieun CI / CD, sandboxing, reorganisasi infrastruktur), ngawaskeun bakal mimiti katinggaleun sareng anjeun moal kantos ngiringan pangwangunan (atanapi engké atanapi engké anjeun kedah ngeureunkeunana).

Sagalana ku tingkat

Ieu kumaha kuring ningali organisasi sistem ngawaskeun.

1) Tingkat aplikasi:

• ngawaskeun logika bisnis aplikasi;
• ngawaskeun métrik kaséhatan jasa;
• ngawaskeun integrasi.

2) Tingkat Infrastruktur:

• pangawasan tingkat orkestrasi;
• ngawaskeun software sistem;
• ngawas tingkat beusi.

3) Deui tingkat aplikasi - tapi salaku produk rékayasa:

• ngumpulkeun sareng ngawaskeun log aplikasi;
• APM;
• nyukcruk.

4) Waspada:

• organisasi sistem peringatan;
• organisasi sistem tugas;
• organisasi "dasar pangaweruh" sareng alur kerja pikeun ngolah kajadian.

penting: urang meunang ka waspada teu sanggeus, tapi langsung! Teu kedah ngaluncurkeun monitoring sareng "kumaha engké" terang saha anu bakal nampi panggeuing. Barina ogé, naon tugas ngawaskeun: ngartos dimana dina sistem aya anu salah, sareng ngantepkeun jalma anu leres terang ngeunaan éta. Upami anjeun ngantepkeun ieu dugi ka tungtungna, maka jalma anu leres bakal terang yén aya anu salah ngan ukur ku nyauran "henteu aya anu tiasa dianggo pikeun urang."

Lapisan Aplikasi - Pangimeutan Logika Usaha

Di dieu urang ngobrol ngeunaan mariksa kanyataan yén aplikasi dianggo pikeun pangguna.

Tingkat ieu kedah dilakukeun salami fase pangwangunan. Contona, urang boga Prometheus kondisional: eta mana anu ka server nu ngalakukeun cék, narik titik tungtung, sarta titik tungtung balik sarta pariksa API.

Nalika sering dipenta pikeun ngawas halaman bumi pikeun mastikeun situsna berpungsi, programer masihan cecekelan anu tiasa ditarik unggal waktos aranjeunna kedah mastikeun yén API damel. Sareng programer ayeuna masih nyandak sareng nyerat /api/test/helloworld
Hiji-hijina jalan pikeun mastikeun sagalana jalan? - Henteu!

• Nyiptakeun cek sapertos kitu mangrupikeun tugas pamekar. Tes Unit kudu ditulis ku programer nu nulis kode. Kusabab upami anjeun ngabocorkeun ka admin, "Sobat, ieu daptar protokol API pikeun sadaya 25 fungsi, mangga monitor sadayana!" - nanaon bakal jalan kaluar.
• Upami anjeun nyitak "halo dunya", moal aya anu terang yén API kedah sareng jalanna. Unggal parobahan API kudu ngakibatkeun parobahan dina cék.
• Upami anjeun parantos ngagaduhan masalah sapertos kitu, ngeureunkeun fitur sareng alokasi pamekar anu bakal nyerat cek ieu, atanapi nampi karugian, nampi yén teu aya anu dipariksa sareng bakal gagal.

Tips Téknis:

• Pastikeun pikeun ngatur hiji server éksternal pikeun ngatur cék - Anjeun kudu mastikeun yén proyék anjeun bisa diasupan ka dunya luar.
• Atur cék dina sakabéh protokol API, sanés ngan ukur titik tungtung individu.
• Jieun prometheus-tungtung kalawan hasil tés.

Lapisan aplikasi - ngawaskeun métrik kaséhatan

Ayeuna urang ngobrol ngeunaan métrik kaséhatan éksternal jasa.

Urang mutuskeun yén urang ngawas sagala "handles" tina aplikasi ngagunakeun cék éksternal, nu urang nelepon ti sistem ngawaskeun éksternal. Tapi ieu téh "handles" nu pamaké "ningali". Kami hoyong mastikeun yén jasa kami tiasa dianggo. Aya carita hadé di dieu: K8s boga cék kaséhatan, ku kituna sahenteuna "kubus" sorangan bisa yakin yén layanan nu jalan. Tapi satengah tina cék Kuring geus katempo téh print sarua "halo dunya". Jelema. Janten anjeunna narik sakali saatos nyebarkeun, anjeunna ngawaler yén sadayana henteu kunanaon - éta waé. Sareng jasa éta, upami éta nyayogikeun API sorangan, ngagaduhan sajumlah ageung titik éntri pikeun API anu sami, anu ogé kedah diawaskeun, sabab kami hoyong terang yén éta tiasa dianggo. Sareng kami parantos ngawaskeunana di jero.

Kumaha cara nerapkeun ieu sacara téknis anu leres: unggal jasa ngungkabkeun titik akhir ngeunaan pagelaran ayeuna, sareng dina grafik Grafana (atanapi aplikasi anu sanés) urang ningali status sadaya jasa.

• Unggal parobahan API kudu ngakibatkeun parobahan dina cék.
• Jieun layanan anyar langsung kalayan métrik kaséhatan.
• Admin tiasa sumping ka pamekar sareng naroskeun "tambahkeun kuring sababaraha fitur supados kuring ngartos sadayana sareng nambihan inpormasi ngeunaan ieu kana sistem ngawaskeun kuring." Tapi pamekar biasana ngajawab, "Kami moal nambihan nanaon dua minggu sateuacan dileupaskeun."
  Sangkan para manajer pangembangan terang yén bakal aya karugian sapertos kitu, terangkeun ogé manajemén manajer pangembangan ogé. Kusabab nalika sagalana ragrag, batur masih bakal nelepon jeung nungtut pikeun ngawas "layanan terus ragrag" (c)
• Ku jalan kitu, allocate pamekar nulis plugins pikeun Grafana - ieu bakal jadi pitulung alus keur admins.

Lapisan Aplikasi - Pangimeutan Integrasi

Pemantauan integrasi museurkeun kana ngawas komunikasi antara sistem kritis-bisnis.

Contona, aya 15 jasa anu saling komunikasi. Ieu henteu deui situs anu misah. Jelema. urang teu bisa narik layanan dina sorangan, meunang / helloworld tur ngartos yen jasa ngajalankeun. Kusabab jasa wéb pesenan kedah ngirim inpormasi ngeunaan pesenan ka beus - tina beus, jasa gudang kedah nampi pesen ieu sareng damel sareng salajengna. Sareng jasa distribusi email kedah ngolah ieu kumaha waé, jsb.

Sasuai, urang teu bisa ngarti, poking di unggal jasa individu, yén éta kabéh jalan. Kusabab urang boga beus tangtu ngaliwatan nu sagalana communicates sarta interaksi.
Ku alatan éta, tahap ieu kedah nyirian tahapan nguji jasa pikeun interaksi sareng jasa anu sanés. Teu mungkin pikeun ngatur ngawas komunikasi ku ngawas calo pesen. Upami aya jasa anu ngaluarkeun data sareng jasa anu nampi éta, nalika ngawas calo kami ngan ukur ningali data anu ngalayang ti sisi ka sisi. Sanaos urang kumaha waé tiasa ngawas interaksi data ieu sacara internal - yén produsén anu tangtu ngirimkeun data, aya anu macana, aliran ieu terus ka Kafka - ieu tetep moal masihan kami inpormasi upami hiji jasa ngirim pesen dina hiji versi. , tapi jasa anu sanés henteu nyangka versi ieu sareng ngaluncurkeunana. Kami moal terang ngeunaan ieu, sabab jasa bakal nyarios yén sadayana berpungsi.

Anu kuring nyarankeun lakukeun:

• Pikeun komunikasi sinkron: titik tungtung ngajadikeun requests ka jasa patali. Jelema. urang nyandak titik tungtung ieu, tarik naskah jero layanan, nu mana ka sadaya titik sarta nyebutkeun "Kuring bisa narik aya, jeung narik aya, abdi tiasa narik aya ..."
• Pikeun komunikasi asinkron: pesen asup - titik tungtung mariksa beus pikeun pesen tés sareng ningalikeun status pamrosésan.
• Pikeun komunikasi asynchronous: pesen kaluar - titik ahir ngirim pesen test ka beus.

Salaku biasana kajadian: urang boga layanan nu throws data kana beus. Kami sumping ka jasa ieu sareng naroskeun anjeun nyarioskeun ngeunaan kaséhatan integrasina. Sareng upami jasa kedah ngahasilkeun pesen dimana waé (WebApp), maka éta bakal ngahasilkeun pesen tés ieu. Sareng upami urang ngajalankeun jasa dina sisi OrderProcessing, éta mimitina ngeposkeun naon anu tiasa dipasang mandiri, sareng upami aya sababaraha hal anu gumantung, maka éta maca sakumpulan pesen tés tina beus, ngartos yén éta tiasa ngolah, ngalaporkeun sareng , lamun perlu, masangkeun aranjeunna salajengna, sarta ngeunaan ieu manéhna nyebutkeun - sagalana is ok, Abdi hirup.

Sering pisan urang ngadangu patarosan "kumaha urang tiasa nguji ieu dina data tempur?" Salaku conto, urang ngobrol ngeunaan jasa pesenan anu sami. Pesenan ngirim pesen ka gudang dimana barang-barangna dihapus: kami henteu tiasa nguji ieu dina data tempur, sabab "barang kuring bakal dihapus!" Solusi: Rencanana sadayana tés ieu di awal. Anjeun oge gaduh tés Unit nu nyieun mocks. Janten, lakukeun dina tingkat anu langkung jero dimana anjeun gaduh saluran komunikasi anu henteu ngabahayakeun operasi bisnis.

Tingkat Infrastruktur

Ngawaskeun infrastruktur mangrupikeun hal anu parantos lami dianggap ngawaskeun sorangan.

• Ngawaskeun infrastruktur tiasa sareng kedah diluncurkeun salaku prosés anu misah.
• Anjeun teu kedah mimitian ku ngawaskeun infrastruktur dina proyék jalan, sanajan anjeun rék. Ieu nyeri pikeun sakabéh devops. "Mimiti kuring gé ngawas kluster, abdi gé ngawas infrastruktur" - i.e. Kahiji, éta bakal ngawas naon perenahna di handap, tapi moal lebet kana aplikasi. Kusabab aplikasi mangrupa hal anu teu kaharti pikeun devops. Éta bocor ka anjeunna, sareng anjeunna henteu ngartos kumaha jalanna. Tapi anjeunna ngartos infrastruktur sareng mimitian ku éta. Tapi henteu - anjeun kedah ngawas aplikasi heula.
• Ulah kaleuleuwihi ku jumlah panggeuing. Tempo pajeulitna sistem modern, ngabejaan terus ngalayang, sarta anjeun kudu kumaha bae hirup kalawan kebat ieu ngabejaan. Sareng jalma anu nelepon, saatos ningali saratus panggeuing salajengna, bakal mutuskeun "Kuring henteu hoyong mikirkeun éta." Tanda ngan kedah ngabéjaan ngeunaan hal-hal kritis.

Tingkat aplikasi salaku unit bisnis

Poin konci:

• ELK. Ieu standar industri. Upami kusabab sababaraha alesan anjeun henteu ngahijikeun log, mimitian lakukeun langsung.
• APM. APMs éksternal salaku cara pikeun nutup gancang ngawaskeun aplikasi (NewRelic, BlackFire, Datadog). Anjeun tiasa masang hal ieu samentawis pikeun sahenteuna kumaha waé ngartos naon anu lumangsung sareng anjeun.
• Nyukcruk. Dina puluhan microservices, Anjeun kudu ngalacak sagalana, sabab pamundut teh euweuh hirup sorangan. Hésé pisan pikeun nambihan engké, janten langkung saé pikeun ngajadwalkeun ngalacak dina pangwangunan - ieu mangrupikeun padamelan sareng utilitas pamekar. Upami anjeun henteu acan ngalaksanakeunana, laksanakeun! Tempo Jaeger / Zipkin

Waspada

• Organisasi sistem bewara: dina kaayaan ngawaskeun sababaraha hal, kedah aya sistem anu ngahijikeun pikeun ngirim bewara. Anjeun tiasa di Grafana. Di Jabar, sadayana nganggo PagerDuty. Tanda kudu jelas (misalna ti mana asalna...). Sareng disarankeun pikeun ngontrol yén béwara ditampi pisan
• Organisasi sistem tugas: panggeuing henteu kedah dikirim ka sadayana (boh sadayana bakal ngaréaksikeun dina riungan, atanapi teu aya anu ngaréaksikeun). Pamekar ogé kedah oncall: pastikeun pikeun nangtukeun wewengkon tanggung jawab, nyieun parentah jelas jeung nulis dina eta saha persis nelepon dina Senén jeung Rebo, sarta saha nu nelepon dina Salasa jeung Jumaah (lamun teu nelepon saha wae sanajan dina kajadian tina masalah badag - aranjeunna bakal sieun hudang anjeun atanapi ngaganggu: jalma umumna teu resep nelepon jeung hudangkeun batur, utamana peuting). Sareng ngajelaskeun yén nyuhunkeun bantosan sanés mangrupikeun indikator henteu mampuh ("Kuring nyuhunkeun bantosan, éta hartosna kuring pagawé anu goréng"), ajak nyuhunkeun bantosan.
• Organisasi "dasar pangaweruh" sareng alur kerja pikeun ngolah kajadian: pikeun unggal kajadian anu serius, post-mortem kedah direncanakeun, sareng salaku ukuran samentawis, tindakan anu bakal ngabéréskeun kajadian éta kedah dirékam. Jeung jadikeun prakték yén ngulang ngageter téh dosa; aranjeunna kedah dilereskeun dina kode atanapi karya infrastruktur.

Téknologi tumpukan

Hayu urang ngabayangkeun yén tumpukan kami nyaéta kieu:

• ngumpulkeun data - Prometheus + Grafana;
• analisis log - ELK;
• pikeun APM atanapi Tracing - Jaeger (Zipkin).

Pilihan pilihan henteu kritis. Kusabab upami di awal anjeun ngartos kumaha ngawas sistem sareng nyerat rencana, maka anjeun mimiti milih alat anu cocog sareng kabutuhan anjeun. Pertanyaanana nyaéta naon anu anjeun pilih pikeun ngawaskeun heula. Kusabab panginten alat anu anjeun pilih di awal henteu cocog sareng kabutuhan anjeun.

Sababaraha titik téknis anu kuring tingali di mana waé akhir-akhir ieu:

Prometheus didorong ka jero Kubernetes - saha anu ngadamel ieu?! Upami klaster anjeun ngadat, naon anu anjeun laksanakeun? Upami Anjeun gaduh klaster kompléks jero, mangka kudu aya sababaraha jenis sistem ngawaskeun jero kluster, sarta sababaraha luar, nu bakal ngumpulkeun data ti jero kluster.

Di jero kluster kami ngumpulkeun log sareng anu sanésna. Tapi sistem ngawaskeun kedah di luar. Sering pisan, dina klaster dimana aya Promtheus dipasang internal, aya ogé sistem anu ngalakukeun cék éksternal operasi situs urang. Kumaha upami sambungan anjeun ka dunya luar parantos turun sareng aplikasina henteu jalan? Tétéla yén sagalana geus rupa jero, tapi teu nyieun sagala hal gampang pikeun pamaké.

papanggihan

• Pangembangan ngawaskeun sanés pamasangan utilitas, tapi pamekaran produk parangkat lunak. 98% pangawas ayeuna nyaéta coding. Coding dina jasa, coding cék éksternal, mariksa jasa éksternal, sareng éta sadayana.
• Entong miceunan waktos pamekar anjeun pikeun ngawaskeun: éta tiasa nyandak dugi ka 30% tina karyana, tapi éta patut.
• Devops, tong hariwang yén anjeun teu tiasa ngawaskeun hiji hal, sabab sababaraha hal mangrupikeun cara mikir anu béda. Anjeun sanés programer, sareng ngawaskeun padamelan mangrupikeun padamelan na.
• Upami proyekna parantos jalan sareng henteu diawaskeun (sareng anjeun manajer), alokasi sumber daya pikeun ngawaskeun.
• Upami produkna parantos aya dina produksi, sareng anjeun mangrupikeun devops anu dititah "nyetél ngawaskeun" - coba terangkeun ka manajemén naon anu kuring nyerat sadayana ieu.

Ieu pérsi nambahan tina laporan dina konferensi Saint Highload ++.

Upami anjeun resep kana ideu sareng pamikiran kuring ngeunaan éta sareng topik anu aya hubunganana, maka di dieu anjeun tiasa maca saluran 🙂

sumber: www.habr.com