Nami abdi Anton Baderin. Abdi damel di Pusat Téknologi Luhur sareng ngalakukeun administrasi sistem. Sabulan katukang, konperénsi perusahaan kami réngsé, dimana kami ngabagi pangalaman akumulasi sareng komunitas IT kota urang. Kuring ngobrol ngeunaan ngawaskeun aplikasi wéb. Bahanna dimaksudkeun pikeun tingkat SMP atanapi tengah, anu henteu ngawangun prosés ieu ti mimiti.
Batu dasar anu aya dina sistem ngawaskeun nyaéta ngarengsekeun masalah bisnis. Ngawaskeun demi ngawaskeun teu aya kapentingan saha waé. Naon anu dipikahoyong bisnis? Janten sadayana tiasa dianggo gancang sareng tanpa kasalahan. Usaha hoyong proaktif, ku kituna urang sorangan ngaidentipikasi masalah dina jasa sareng ngalereskeunana gancang-gancang. Ieu, kanyataanna, mangrupikeun masalah anu ku kuring direngsekeun sadayana taun ka tukang dina proyék pikeun salah sahiji konsumén urang.
Ngeunaan proyék nu
Proyék nyaéta salah sahiji program kasatiaan panggedéna di nagara éta. Kami ngabantosan ranté ritel ningkatkeun frékuénsi penjualan ngalangkungan sababaraha alat pamasaran sapertos kartu bonus. Dina total, proyék éta kalebet 14 aplikasi anu dijalankeun dina sapuluh server.
Salila prosés wawancara, kuring sababaraha kali perhatikeun yén admin henteu salawasna ngadeukeutan ngawaskeun aplikasi wéb kalayan leres: seueur anu masih fokus kana métrik sistem operasi sareng aya kalana ngawas jasa.
Dina hal kuring, sistem ngawaskeun palanggan sateuacana dumasar kana Icinga. Éta henteu ngabéréskeun masalah di luhur ku cara naon waé. Sering klien sorangan informed kami ngeunaan masalah, sarta leuwih sering ti moal, urang ngan saukur teu boga cukup data pikeun meunangkeun ka handap alesan.
Sajaba ti éta, aya pamahaman jelas ngeunaan futility ngembangkeun salajengna na. Jigana jalma anu wawuh jeung Icinga bakal ngarti kuring. Janten, kami mutuskeun pikeun ngadesain deui sistem ngawaskeun aplikasi wéb pikeun proyék éta.
Prometheus
Kami milih Prometheus dumasar kana tilu indikator utama:
- Sajumlah ageung métrik anu sayogi. Di urang aya 60 rébu di antarana. Tangtosna, éta patut dicatet yén kami henteu nganggo seuseueurna aranjeunna (sigana sakitar 95%). Di sisi séjén, aranjeunna sadayana relatif murah. Pikeun urang, ieu ekstrim sejenna dibandingkeun jeung Icinga saméméhna dipaké. Dina éta, nambihan métrik mangrupikeun nyeri anu khusus: anu tos aya mahal (ngan tingali kodeu sumber tina plugin naon waé). Sakur plugin mangrupikeun naskah dina Bash atanapi Python, peluncuran anu mahal tina segi sumber daya anu dikonsumsi.
- Sistim ieu meakeun jumlah relatif leutik sumberdaya. 600 MB RAM, 15% tina hiji inti sareng sababaraha belasan IOPS cekap pikeun sadaya métrik urang. Tangtosna, anjeun kedah ngajalankeun métrik ékspor, tapi aranjeunna sadayana ditulis dina Go sareng ogé henteu lapar pisan. Ku teu sangka dina realities modern ieu masalah.
- Nyadiakeun kamampuhan pikeun migrasi ka Kubernetes. Mertimbangkeun rencana palanggan, pilihanna écés.
Elk
Saméméhna, urang teu ngumpulkeun atawa ngolah log. Kakurangan jelas ka sarerea. Kami milih ELK sabab kami parantos gaduh pangalaman sareng sistem ieu. Kami ngan ukur nyimpen log aplikasi di dinya. Kriteria pilihan utama nyaéta milarian téks lengkep sareng lajuna.
Сlickhouse
Mimitina, pilihanna murag dina InfluxDB. Kami sadar kabutuhan pikeun ngumpulkeun log Nginx, statistik tina pg_stat_statements, sareng nyimpen data sajarah Prometheus. Kami henteu resep Influx sabab périodik mimiti meakeun mémori anu ageung sareng nabrak. Salaku tambahan, kuring hoyong ngagolongkeun patarosan ku remote_addr, tapi ngagolongkeun dina DBMS ieu ngan ukur ku tag. Tag mahal (memori), jumlahna terbatas sacara syarat.
Urang ngamimitian milarian deui. Anu diperyogikeun nyaéta database analitik kalayan konsumsi sumberdaya minimal, langkung saé kalayan komprési data dina disk.
Clickhouse nyumponan sadaya kriteria ieu, sareng kami henteu kantos kuciwa kana pilihan urang. Kami henteu nyerat jumlah data anu luar biasa kana éta (jumlah sisipan ngan ukur lima rébu per menit).
NewRelic
NewRelic sajarahna parantos aya sareng kami sabab éta pilihan palanggan. Kami nganggo éta salaku APM.
Zabbix
Kami nganggo Zabbix sacara éksklusif pikeun ngawas Kotak Hideung tina rupa-rupa API.
Nangtukeun Pendekatan Ngawaskeun
Kami hoyong ngabubarkeun tugas sareng ku kituna sistematis pendekatan pikeun ngawaskeun.
Jang ngalampahkeun ieu, kuring ngabagi sistem kami kana tingkat ieu:
- hardware jeung VMS;
- sistem operasi;
- jasa sistem, tumpukan software;
- aplikasi;
- logika bisnis.
Naha pendekatan ieu merenah:
- urang terang saha anu tanggung jawab pikeun padamelan unggal tingkat sareng, dumasar kana ieu, urang tiasa ngirim panggeuing;
- urang tiasa nganggo struktur nalika suppressing panggeuing - bakal aneh mun ngirim waspada ngeunaan unavailability database nalika mesin virtual sakabéhna teu sadia.
Kusabab tugas urang pikeun ngaidentipikasi palanggaran dina operasi sistem, urang kudu di unggal tingkat nyorot hiji set tangtu metrics nu patut nengetan nalika nulis aturan alerting. Salajengna, hayu urang ngaliwatan tingkat "VMS", "Sistem operasi" jeung "System services, software tumpukan".
Mesin virtual
Hosting nyayogikeun kami prosésor, disk, mémori sareng jaringan. Sareng urang ngagaduhan masalah sareng dua anu munggaran. Janten, métrik:
CPU dipaling waktos - mun anjeun meuli mesin virtual on Amazon (t2.micro, contona), anjeun kudu ngarti yén anjeun teu disadiakeun hiji sakabéh inti processor, tapi ngan hiji kuota waktu na. Sareng nalika anjeun béakna, prosésor bakal dicabut tina anjeun.
Métrik ieu ngamungkinkeun anjeun pikeun ngalacak momen sapertos kitu sareng nyandak kaputusan. Contona, éta perlu nyandak hiji tarif fatter atawa ngadistribusikaeun ngolah tugas tukang sarta requests API ka server béda?
IOPS + CPU iowait waktos - pikeun sababaraha alesan, loba awan hostings dosa ku teu nyadiakeun cukup IOPS. Sumawona, jadwal sareng IOPS rendah sanés argumen pikeun aranjeunna. Ku alatan éta, éta patut ngumpulkeun CPU iowait. Kalayan sapasang grafik ieu - kalayan IOPS rendah sareng ngantosan I / O tinggi - anjeun parantos tiasa ngobrol sareng hosting sareng ngabéréskeun masalah.
sistem operasi
Métrik sistem operasi:
- jumlah memori sadia dina%;
- aktivitas pamakéan swap: vmstat swapin, swapout;
- Jumlah inode anu sayogi sareng rohangan bébas dina sistem file dina%
- beban rata;
- Jumlah sambungan dina kaayaan dua;
- conntrack tabel fullness;
- Kualitas jaringan tiasa diawaskeun nganggo utilitas ss, pakét iproute2 - kéngingkeun indikator sambungan RTT tina kaluaranna sareng ngagolongkeunana ku port dest.
Ogé di tingkat sistem operasi urang gaduh éntitas sapertos prosés. Penting pikeun ngaidentipikasi dina sistem sakumpulan prosés anu maénkeun peran penting dina operasina. Upami, contona, anjeun gaduh sababaraha pgpools, maka anjeun kedah ngumpulkeun inpormasi masing-masing.
Susunan métrik nyaéta kieu:
- CPUs;
- memori utamana nyicingan;
- IO - preferably dina IOPS;
- FileFd - kabuka sareng wates;
- gagal kaca signifikan - ku cara kieu anjeun bisa ngarti prosés naon keur swapped.
Kami nyebarkeun sadaya ngawaskeun di Docker, sareng kami nganggo Advisor pikeun ngumpulkeun data métrik. Dina mesin séjén kami nganggo prosés-éksportir.
jasa Sistim, tumpukan software
Unggal aplikasi gaduh spésifikna sorangan, sareng sesah pikeun milih sakumpulan métrik anu khusus.
Set universal nyaéta:
- laju pamundut;
- jumlah kasalahan;
- latén;
- jenuh.
Conto ngawaskeun anu paling narik dina tingkat ieu nyaéta Nginx sareng PostgreSQL.
Ladenan anu paling dimuat dina sistem kami nyaéta pangkalan data. Baheula, urang mindeng ngalaman masalah figuring kaluar naon database ieu lakukeun.
Urang nempo beban tinggi dina disk, tapi log slow teu bener nembongkeun nanaon. Urang direngsekeun masalah ieu ngagunakeun pg_stat_statements, pintonan nu ngumpulkeun statistik query.
Sakitu anu peryogi ku admin.
Kami ngawangun grafik kagiatan maca sareng nyerat pamundut:
Sagalana basajan tur jelas, unggal pamundut boga warna sorangan.
Conto anu sami anu pikaresepeun nyaéta log Nginx. Teu heran sababaraha urang parse aranjeunna atanapi nyebatkeun aranjeunna dina daptar kedah-kudu. Format standar henteu pisan informatif sareng kedah dilegakeun.
Pribadi, abdi nambihan request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Urang plot waktu respon jeung jumlah kasalahan:
Kami ngawangun grafik waktos réspon sareng jumlah kasalahan. Inget? Naha kuring ngobrol ngeunaan tugas bisnis? Pikeun gancang sarta tanpa kasalahan? Kami parantos nutupan masalah ieu ku dua bagan. Sareng anjeun parantos tiasa nyauran pangurus anu tugasna nganggo aranjeunna.
Tapi hiji deui masalah tetep - pikeun mastikeun ngaleungitkeun gancang tina sabab kajadian.
Resolusi kajadian
Sakabéh prosés tina ngaidentipikasi dugi ka ngarengsekeun masalah tiasa dibagi kana sababaraha léngkah:
- ngaidentipikasi masalah;
- béwara ka pangurus tugas;
- respon kana hiji kajadian;
- ngaleungitkeun sabab.
Kadé urang kedah ngalakukeun ieu gancang-gancang. Sareng upami dina tahapan ngaidentipikasi masalah sareng ngirim béwara, urang moal tiasa nampi seueur waktos - dua menit bakal diséépkeun dina hal naon waé, teras anu saterasna mangrupikeun lapangan anu teu dibajak pikeun perbaikan.
Bayangkeun waé telepon patugas patugas hurung. Naon anu bakal anjeunna laksanakeun? Néangan jawaban kana patarosan - naon peupeus, dimana eta peupeus, kumaha carana meta? Ieu kumaha urang ngajawab patarosan ieu:
Urang ngan saukur ngalebetkeun sadaya inpormasi ieu dina téks béwara, masihan tautan ka halaman wiki anu ngajelaskeun kumaha carana ngabales masalah ieu, kumaha cara ngabéréskeunana sareng ningkatkeunana.
Kuring masih teu ngomong nanaon ngeunaan lapisan aplikasi tur logika bisnis. Hanjakalna, aplikasi kami henteu acan nerapkeun koléksi métrik. Hiji-hijina sumber inpormasi tina tingkat ieu nyaéta log.
Sababaraha titik.
Kahiji, nulis log terstruktur. Henteu kedah ngalebetkeun kontéks dina téks pesen. Hal ieu ngajadikeun aranjeunna hésé pikeun grup jeung analisa. Logstash peryogi waktos anu lami pikeun normalisasi sadayana ieu.
Bréh, ngagunakeun tingkat severity bener. Unggal basa boga standar sorangan. Pribadi, kuring ngabédakeun opat tingkat:
- euweuh kasalahan;
- kasalahan sisi klien;
- kasalahan aya di sisi urang, urang teu leungit duit, urang teu nanggung resiko;
- Kasalahan aya di pihak urang, urang leungit duit.
Hayu atuh nyimpulkeun. Anjeun kedah nyobian ngawangun ngawaskeun dumasar kana logika bisnis. Coba ngawas aplikasi éta sorangan sareng beroperasi kalayan métrik sapertos jumlah penjualan, jumlah pendaptaran pangguna énggal, jumlah pangguna anu ayeuna aktip, sareng saterasna.
Upami sadayana usaha anjeun mangrupikeun hiji tombol dina browser, anjeun kedah ngawas naha éta ngaklik sareng jalanna leres. Kabéh sésana teu masalah.
Upami anjeun teu acan gaduh ieu, anjeun tiasa nyobian ngiringan dina log aplikasi, log Nginx, sareng saterasna, sapertos anu urang lakukeun. Anjeun kedah sacaket mungkin ka aplikasi.
Métrik sistem operasi tangtu penting, tapi bisnis henteu kabetot dina éta, kami henteu mayar kanggo aranjeunna.
sumber: www.habr.com