Mening ismim Anton Baderin. Men yuqori texnologiyalar markazida ishlayman va tizim boshqaruvi bilan shug'ullanaman. Bir oy oldin bizning korporativ konferentsiyamiz yakunlandi, unda biz to'plangan tajribamizni shahrimiz IT hamjamiyatiga baham ko'rdik. Men veb-ilovalarni monitoring qilish haqida gapirdim. Material bu jarayonni noldan qurmagan kichik yoki o'rta daraja uchun mo'ljallangan edi.
Har qanday monitoring tizimining asosi biznes muammolarini hal qilishdir. Monitoring uchun monitoring hech kimni qiziqtirmaydi. Biznes nimani xohlaydi? Shunday qilib, hamma narsa tez va xatosiz ishlaydi. Korxonalar faol bo'lishni xohlaydi, shunda biz o'zimiz xizmatdagi muammolarni aniqlaymiz va ularni imkon qadar tezroq hal qilamiz. Bu, aslida, men o'tgan yili mijozlarimizdan biri uchun loyihada hal qilgan muammolarim.
Loyiha haqida
Loyiha mamlakatdagi eng yirik sodiqlik dasturlaridan biridir. Biz chakana savdo tarmoqlariga bonus kartalar kabi turli marketing vositalari orqali sotish chastotasini oshirishda yordam beramiz. Umuman olganda, loyiha o'nta serverda ishlaydigan 14 ta ilovani o'z ichiga oladi.
Suhbat jarayonida men administratorlar har doim ham veb-ilovalarni kuzatishga to'g'ri yondashmasligini qayta-qayta payqadim: ko'pchilik hali ham operatsion tizim ko'rsatkichlariga e'tibor qaratadi va vaqti-vaqti bilan xizmatlarni kuzatib boradi.
Mening holatimda, mijozning monitoring tizimi ilgari Icinga-ga asoslangan edi. Yuqoridagi muammolarni hech qanday tarzda hal qilmadi. Ko'pincha mijozning o'zi bizga muammolar haqida xabar bergan va ko'pincha bizda sababni tushunish uchun etarli ma'lumotlar yo'q edi.
Bundan tashqari, uning keyingi rivojlanishining befoydaligi haqida aniq tushuncha mavjud edi. O'ylaymanki, Icinga bilan tanish bo'lganlar meni tushunishadi. Shunday qilib, biz loyiha uchun veb-ilovalarni monitoring qilish tizimini butunlay qayta ishlab chiqishga qaror qildik.
Prometheus
Biz Prometeyni uchta asosiy ko'rsatkich asosida tanladik:
- Ko'p sonli mavjud ko'rsatkichlar. Bizning holatlarimizda ularning 60 mingi bor. Albatta, shuni ta'kidlash kerakki, biz ularning katta qismidan foydalanmaymiz (ehtimol, taxminan 95%). Boshqa tomondan, ularning barchasi nisbatan arzon. Biz uchun bu ilgari ishlatilgan Icinga bilan solishtirganda boshqa ekstremaldir. Unda o'lchovlarni qo'shish alohida og'riq edi: mavjudlari qimmat edi (faqat har qanday plaginning manba kodiga qarang). Har qanday plagin Bash yoki Python-dagi skript edi, uning ishga tushirilishi iste'mol qilinadigan resurslar nuqtai nazaridan qimmat.
- Bu tizim nisbatan kam miqdordagi resurslarni sarflaydi. 600 MB operativ xotira, bitta yadroning 15% va bir necha o'nlab IOPS barcha ko'rsatkichlarimiz uchun etarli. Albatta, siz o'lchovlarni eksport qiluvchilarni ishga tushirishingiz kerak, lekin ularning barchasi Go'da yozilgan va ular juda ham quvvatga muhtoj emas. Zamonaviy haqiqatda bu muammo emas deb o'ylamayman.
- Kubernetesga o'tish imkoniyatini beradi. Mijozning rejalarini inobatga olgan holda, tanlov aniq.
ELK
Ilgari biz jurnallarni yig'masdik yoki qayta ishlamadik. Kamchiliklar hammaga ayon. Biz ELK ni tanladik, chunki bizda bu tizim bilan tajribamiz bor edi. Biz u yerda faqat dastur jurnallarini saqlaymiz. Asosiy tanlov mezonlari to'liq matnli qidiruv va uning tezligi edi.
Slickhouse
Dastlab, tanlov InfluxDB-ga tushdi. Biz Nginx jurnallarini, pg_stat_statements statistikasini yig'ish va Prometey tarixiy ma'lumotlarini saqlash zarurligini tushundik. Influx bizga yoqmadi, chunki u vaqti-vaqti bilan katta hajmdagi xotirani iste'mol qila boshladi va ishdan chiqdi. Bundan tashqari, men so'rovlarni remote_addr bo'yicha guruhlashni xohlardim, lekin bu DBMSda guruhlash faqat teglar bo'yicha. Teglar qimmat (xotira), ularning soni shartli ravishda cheklangan.
Biz yana qidiruvni boshladik. Eng kam resurs iste'moliga ega bo'lgan analitik ma'lumotlar bazasi kerak edi, afzalroq diskda ma'lumotlarni siqish.
Clickhouse ushbu mezonlarning barchasiga javob beradi va biz tanlaganimizdan hech qachon afsuslanmadik. Biz unga juda katta hajmdagi ma'lumotlarni yozmaymiz (qo'shishlar soni daqiqada atigi besh mingtani tashkil qiladi).
NewRelic
NewRelic tarixan biz bilan bo'lgan, chunki bu mijozning tanlovi edi. Biz uni APM sifatida ishlatamiz.
Zabbix
Biz Zabbix-dan faqat turli xil API-larning qora qutisini kuzatish uchun foydalanamiz.
Monitoring yondashuvini aniqlash
Biz vazifani taqsimlashni va shu bilan monitoringga yondashuvni tizimlashtirishni xohladik.
Buning uchun men tizimimizni quyidagi darajalarga ajratdim:
- apparat va VMS;
- operatsion tizim;
- tizim xizmatlari, dasturiy ta'minot to'plami;
- ariza;
- biznes mantig'i.
Nima uchun bu yondashuv qulay:
- biz har bir darajadagi ish uchun kim mas'ul ekanligini bilamiz va shunga asoslanib, biz ogohlantirishlarni yuborishimiz mumkin;
- ogohlantirishlarni bostirishda strukturadan foydalanishimiz mumkin - virtual mashina umuman mavjud bo'lmaganda ma'lumotlar bazasi mavjud emasligi haqida ogohlantirish yuborish g'alati bo'lar edi.
Bizning vazifamiz tizimning ishlashidagi buzilishlarni aniqlash bo'lganligi sababli, biz har bir darajada ogohlantirish qoidalarini yozishda e'tibor berishga arziydigan ma'lum ko'rsatkichlar to'plamini ajratib ko'rsatishimiz kerak. Keyinchalik, "VMS", "Operatsion tizim" va "Tizim xizmatlari, dasturiy ta'minot to'plami" darajalarini ko'rib chiqamiz.
Virtual mashinalar
Xosting bizga protsessor, disk, xotira va tarmoqni ajratadi. Birinchi ikkitasida esa bizda muammolar bor edi. Shunday qilib, ko'rsatkichlar:
CPU o'g'irlangan vaqti - Amazonda virtual mashina sotib olayotganda (masalan, t2.micro), siz butun protsessor yadrosi emas, balki faqat uning vaqt kvotasi ajratilganligini tushunishingiz kerak. Va uni tugatganingizda, protsessor sizdan tortib olinadi.
Ushbu ko'rsatkich sizga bunday daqiqalarni kuzatish va qaror qabul qilish imkonini beradi. Misol uchun, semizroq tarifni olish yoki fon vazifalari va API so'rovlarini qayta ishlashni turli serverlarga tarqatish kerakmi?
IOPS + CPU iowait vaqti - ba'zi sabablarga ko'ra ko'plab bulutli hostinglar etarli IOPS ta'minlamaslik bilan gunoh qiladi. Bundan tashqari, past IOPS bilan jadval ular uchun dalil emas. Shuning uchun CPU iowaitni yig'ishga arziydi. Ushbu juft grafiklar bilan - past IOPS va yuqori kiritish/chiqarish kutish bilan siz allaqachon hosting bilan gaplashib, muammoni hal qilishingiz mumkin.
Operatsion tizim
Operatsion tizim ko'rsatkichlari:
- mavjud xotira miqdori %da;
- svopdan foydalanish faoliyati: vmstat swapin, swapout;
- mavjud inodelar soni va fayl tizimidagi bo'sh joy %da
- o'rtacha yuk;
- tw holatidagi ulanishlar soni;
- jadvalning to'liqligi;
- Tarmoq sifatini ss yordam dasturi, iproute2 to'plami yordamida kuzatish mumkin - uning chiqishidan RTT ulanishlari ko'rsatkichini oling va uni maqsadli port bo'yicha guruhlang.
Shuningdek, operatsion tizim darajasida biz jarayonlar kabi ob'ektga egamiz. Tizimda uning ishlashida muhim rol o'ynaydigan jarayonlar majmuasini aniqlash muhim ahamiyatga ega. Agar, masalan, sizda bir nechta pgpool bo'lsa, ularning har biri uchun ma'lumot to'plashingiz kerak.
Ko'rsatkichlar to'plami quyidagicha:
- MARKAZIY PROTSESSOR;
- xotira birinchi navbatda rezident hisoblanadi;
- IO - afzalroq IOPS da;
- FileFd - ochish va cheklash;
- muhim sahifa xatoliklari - bu orqali siz qaysi jarayon almashtirilayotganini tushunishingiz mumkin.
Biz Docker-da barcha monitoringni o'rnatamiz va o'lchov ma'lumotlarini yig'ish uchun Advisor-dan foydalanamiz. Boshqa mashinalarda biz jarayonni eksport qiluvchidan foydalanamiz.
Tizim xizmatlari, dasturiy ta'minot to'plami
Har bir ilovaning o'ziga xos xususiyatlari bor va aniq ko'rsatkichlar to'plamini ajratib ko'rsatish qiyin.
Universal to'plam:
- so'rov stavkasi;
- xatolar soni;
- kechikish;
- to'yinganlik.
Ushbu darajadagi monitoringning eng yorqin misollari Nginx va PostgreSQLdir.
Bizning tizimimizda eng ko'p yuklangan xizmat bu ma'lumotlar bazasi. Ilgari biz ko'pincha ma'lumotlar bazasi nima qilayotganini aniqlashda qiynalar edik.
Biz disklarda yuqori yukni ko'rdik, lekin sekin jurnallar, albatta, hech narsani ko'rsatmadi. Biz bu muammoni pg_stat_statements, so'rovlar statistikasini to'playdigan ko'rinish yordamida hal qildik.
Bu adminga kerak bo'lgan hamma narsa.
Biz o'qish va yozish so'rovlari faoliyatining grafiklarini tuzamiz:
Hamma narsa oddiy va tushunarli, har bir so'rov o'z rangiga ega.
Xuddi shunday yorqin misol - Nginx jurnallari. Kamdan-kam odamlar ularni tahlil qilishlari yoki bo'lishi kerak bo'lgan narsalar ro'yxatida eslatib o'tishlari ajablanarli emas. Standart format juda informatsion emas va uni kengaytirish kerak.
Shaxsan men so'rov_vaqti, yuqoriga_javob_vaqti, tana_baytlari_sent, so'rov_uzunligi, so'rov_identifikatorini qo'shdim. Biz javob vaqti va xatolar sonini chizamiz:
Biz javob vaqti va xatolar sonining grafiklarini tuzamiz. Esingizdami? Men biznes vazifalari haqida gapirdimmi? Tez va xatosiz? Biz allaqachon bu masalalarni ikkita diagramma bilan yoritgan edik. Va siz ulardan foydalanib allaqachon navbatchi ma'murlarga qo'ng'iroq qilishingiz mumkin.
Ammo yana bir muammo qolmoqda - hodisa sabablarini tezda bartaraf etishni ta'minlash.
Voqealarni hal qilish
Muammoni aniqlashdan to hal qilishgacha bo'lgan butun jarayonni bir necha bosqichlarga bo'lish mumkin:
- muammoni aniqlash;
- navbatchi ma'murga xabar berish;
- voqeaga javob berish;
- sabablarni bartaraf etish.
Buni imkon qadar tezroq qilishimiz muhim. Va agar muammoni aniqlash va bildirishnoma yuborish bosqichlarida biz ko'p vaqtni qo'lga kirita olmasak - har qanday holatda ham ularga ikki daqiqa sarflanadi, keyin keyingilari yaxshilanish uchun shunchaki ishlov berilmagan maydondir.
Tasavvur qilaylik, navbatchining telefoni jiringladi. U nima qiladi? Savollarga javob izlang - nima buzildi, qayerda buzildi, qanday munosabatda bo'lish kerak? Mana bu savollarga qanday javob beramiz:
Biz bu ma'lumotlarning barchasini bildirishnoma matniga qo'shamiz, unga ushbu muammoga qanday javob berish, uni qanday hal qilish va uni kuchaytirishni tasvirlaydigan wiki-sahifaga havola beramiz.
Men hali ham dastur qatlami va biznes mantig'i haqida hech narsa aytmadim. Afsuski, bizning ilovalarimiz ko'rsatkichlar to'plamini hali amalga oshirmaydi. Ushbu darajadagi har qanday ma'lumotning yagona manbai jurnallardir.
Bir nechta nuqta.
Birinchidan, tuzilgan jurnallarni yozing. Xabar matniga kontekstni kiritish shart emas. Bu ularni guruhlash va tahlil qilishni qiyinlashtiradi. Bularning barchasini normallashtirish uchun Logstash uzoq vaqt talab etadi.
Ikkinchidan, jiddiylik darajasini to'g'ri ishlatish. Har bir til o'z standartiga ega. Shaxsan men to'rt darajani ajrataman:
- xato yo'q;
- mijoz tomoni xatosi;
- xato biz tomonda, biz pul yo'qotmaymiz, tavakkal qilmaymiz;
- Xato biz tomonda, biz pul yo'qotamiz.
Xulosa qilib beraman. Siz biznes mantig'iga asoslangan monitoringni qurishga harakat qilishingiz kerak. Ilovaning o'zini kuzatishga harakat qiling va sotuvlar soni, yangi foydalanuvchi ro'yxatga olishlar soni, hozirda faol foydalanuvchilar soni va boshqalar kabi ko'rsatkichlar bilan ishlang.
Agar butun biznesingiz brauzerdagi bitta tugma bo'lsa, uning bosilishi va to'g'ri ishlashini kuzatib borishingiz kerak. Qolganlarning hammasi muhim emas.
Agar sizda bu yo'q bo'lsa, biz qilganidek, uni ilovalar jurnallarida, Nginx jurnallarida va hokazolarda ushlashga harakat qilishingiz mumkin. Ilovaga iloji boricha yaqinroq bo'lishingiz kerak.
Operatsion tizim ko'rsatkichlari, albatta, muhim, lekin biznesni ular qiziqtirmaydi, biz ular uchun haq to'lamaymiz.
Manba: www.habr.com