Monitoring o'likmi? - Yashasin monitoring

2008 yildan beri kompaniyamiz asosan infratuzilmani boshqarish va veb-loyihalarni kechayu kunduz texnik qo'llab-quvvatlash bilan shug'ullanadi: bizda 400 dan ortiq mijozlar mavjud, bu Rossiya elektron tijoratining taxminan 15% ni tashkil qiladi. Shunga ko'ra, juda xilma-xil arxitektura qo'llab-quvvatlanadi. Agar biror narsa tushib qolsa, biz uni 15 daqiqa ichida tuzatishimiz shart. Ammo baxtsiz hodisa sodir bo'lganligini tushunish uchun siz loyihani kuzatib borishingiz va hodisalarga javob berishingiz kerak. Buni qanday qilish kerak?

To'g'ri monitoring tizimini tashkil etishda muammo bor deb hisoblayman. Agar muammo bo'lmaganida, mening nutqim bitta tezisdan iborat bo'lar edi: "Iltimos, Prometey + Grafana va 1, 2, 3 plaginlarini o'rnating." Afsuski, u endi bunday ishlamaydi. Va asosiy muammo shundaki, har bir kishi dasturiy ta'minot komponentlari nuqtai nazaridan 2008 yilda mavjud bo'lgan narsaga ishonishda davom etmoqda.

Monitoring tizimini tashkil qilish masalasiga kelsak, shuni aytishga jur'at etgan bo'lardimki... malakali monitoringga ega bo'lgan loyihalar mavjud emas. Vaziyat shu qadar yomonki, agar biror narsa tushib qolsa, u e'tiborga olinmaslik xavfi bor - axir, hamma "hamma narsa nazorat ostida" ekanligiga amin.
Ehtimol, hamma narsa kuzatilmoqda. Lekin qanday?

Biz hammamiz quyidagi kabi voqeaga duch keldik: ma'lum bir devops, ma'lum bir administrator ishlayapti, ishlab chiqish guruhi ularga kelib, "biz ozod bo'ldik, endi kuzating" deydi. Nimani kuzating? U qanday ishlaydi?

KELISHDIKMI. Biz eski uslubni kuzatamiz. Va u allaqachon o'zgarib bormoqda va siz C xizmati bilan o'zaro aloqada bo'lgan B xizmatiga aylangan A xizmatini kuzatganingiz ma'lum bo'ldi. Ammo ishlab chiqish guruhi sizga: "Dasturni o'rnating, u hamma narsani kuzatishi kerak!"

Xo'sh, nima o'zgardi? - Hammasi o'zgardi!

2008 yil Hammasi ajoyib

Bir nechta ishlab chiquvchilar, bitta server, bitta ma'lumotlar bazasi serveri mavjud. Hammasi shu yerdan ketadi. Bizda ba'zi ma'lumotlar bor, biz zabbix, Nagios, kaktuslarni o'rnatamiz. Va keyin biz CPU, disk ishlashi va disk maydoni haqida aniq ogohlantirishlarni o'rnatamiz. Shuningdek, biz sayt javob berishini va buyurtmalar ma'lumotlar bazasiga kelishini ta'minlash uchun bir nechta qo'lda tekshiruvlarni amalga oshiramiz. Va bu - biz ko'proq yoki kamroq himoyalanganmiz.

Agar biz administratorning monitoringni ta'minlash uchun qilgan ish hajmini solishtirsak, u holda uning 98% avtomatik edi: monitoringni amalga oshiruvchi shaxs Zabbixni qanday o'rnatishni, uni qanday sozlashni va ogohlantirishlarni sozlashni tushunishi kerak. Va 2% - tashqi tekshiruvlar uchun: sayt javob beradi va ma'lumotlar bazasiga so'rov yuboradi, yangi buyurtmalar kelgan.

2010 yil Yuk ortib bormoqda

Biz qidiruv tizimini qo'shib, Internetni kengaytirishni boshlaymiz. Biz mahsulot katalogida barcha mahsulotlar borligiga ishonch hosil qilishni istaymiz. Va bu mahsulot qidirish ishlaydi. Ma'lumotlar bazasi ishlayotgani, buyurtmalar berilayotganligi, sayt tashqaridan javob berishi va ikkita serverdan javob berishi va foydalanuvchi boshqa serverga balanslanganda saytdan chiqarib yuborilmasligi va hokazo. Ko'proq ob'ektlar mavjud.

Bundan tashqari, infratuzilma bilan bog'liq bo'lgan ob'ekt hali ham menejer boshida eng katta bo'lib qolmoqda. Hali ham miyamda shunday fikr borki, monitoringni amalga oshiruvchi odam zabbixni o'rnatadigan va uni sozlashi mumkin.

Shu bilan birga, tashqi tekshiruvlar o'tkazish, qidiruv indekslari so'rovlari skriptlari to'plamini yaratish, indekslash jarayonida qidiruv o'zgarishini tekshirish uchun skriptlar to'plami, tovarlarning o'tkazilganligini tekshiradigan skriptlar to'plamini yaratish ustida ish olib borilmoqda. yetkazib berish xizmati va boshqalar. va h.k.

Eslatma: Men "skriptlar to'plami" ni 3 marta yozdim. Ya'ni, monitoring uchun mas'ul shaxs endi oddiygina zabbixni o'rnatadigan odam emas. Bu kodlashni boshlagan odam. Ammo jamoaning fikrida hali hech narsa o'zgargani yo'q.

Ammo dunyo o‘zgarmoqda, tobora murakkablashib bormoqda. Virtualizatsiya qatlami va bir nechta yangi tizimlar qo'shildi. Ular bir-birlari bilan muloqot qilishni boshlaydilar. Kim aytdi "mikroservislarning hidi?" Ammo har bir xizmat alohida veb-saytga o'xshaydi. Biz unga murojaat qilishimiz va u kerakli ma'lumotlarni taqdim etishini va o'z-o'zidan ishlashini tushunishimiz mumkin. Va agar siz 5-7-10 yil davomida ishlab chiqilayotgan loyihada doimiy ishtirok etuvchi ma'mur bo'lsangiz, bu bilimlar to'planadi: yangi daraja paydo bo'ladi - siz buni tushundingiz, boshqa daraja paydo bo'ladi - siz buni angladingiz ...

Ammo kamdan-kam odam loyihaga 10 yil davomida hamrohlik qiladi.

Monitoringmanning rezyumesi

Aytaylik, siz zudlik bilan 20 ta dasturchini yollagan, 15 ta mikroservis yozgan yangi startapga keldingiz va siz administratorsiz, unga: “CI/CD yarating. Iltimos." Siz CI/CD-ni yaratdingiz va birdan eshitasiz: “Bizga ilova qanday ishlashini tushunmasdan “kub”da ishlab chiqarish bilan ishlash qiyin. Xuddi shu "kub" da bizni qum qutisi qiling.
Siz bu kubda qum qutisini yaratasiz. Ular darhol sizga aytadilar: "Biz ishlab chiqarishdan har kuni yangilanadigan sahna ma'lumotlar bazasini xohlaymiz, shunda biz u ma'lumotlar bazasida ishlashini tushunamiz, lekin shu bilan birga ishlab chiqarish ma'lumotlar bazasini buzmaydi."

Siz bularning barchasida yashaysiz. Chiqarilishidan oldin 2 hafta qoldi, ular sizga aytadilar: "Endi bularning barchasini kuzatib boramiz ..." Ya'ni. klaster infratuzilmasini monitoring qilish, mikroservis arxitekturasini kuzatish, tashqi xizmatlar bilan ishlashni kuzatish...

Va mening hamkasblarim odatdagi sxemani boshlaridan chiqarib, shunday deyishadi: “Xo'sh, bu erda hamma narsa aniq! Bularning barchasini kuzatib turadigan dasturni o'rnating." Ha, ha: Prometey + Grafana + plaginlari.
Va ular: "Sizda ikki hafta bor, hamma narsa xavfsiz ekanligiga ishonch hosil qiling."

Biz ko'rib turgan ko'plab loyihalarda monitoring uchun bir kishi ajratilgan. Tasavvur qiling-a, biz 2 hafta davomida monitoring qilish uchun odamni yollamoqchimiz va biz unga rezyume yozamiz. Hozirgacha aytganlarimizni hisobga olsak, bu odam qanday ko'nikmalarga ega bo'lishi kerak?

• U temir infratuzilmasining ishlashining monitoringi va o'ziga xos xususiyatlarini tushunishi kerak.
• U Kubernetes monitoringining o'ziga xos xususiyatlarini tushunishi kerak (va hamma "kub" ga o'tishni xohlaydi, chunki siz hamma narsadan mavhum bo'lishingiz, yashirishingiz mumkin, chunki administrator qolganlari bilan shug'ullanadi) - o'zini, uning infratuzilmasini va ilovalarni qanday kuzatishni tushunishi kerak. ichida.
• U xizmatlar bir-biri bilan maxsus usullarda aloqa qilishini tushunishi va xizmatlarning bir-biri bilan o'zaro ta'sirining o'ziga xos xususiyatlarini bilishi kerak. Ba'zi xizmatlar sinxron aloqa qiladigan loyihani ko'rish juda mumkin, chunki boshqa yo'l yo'q. Masalan, backend REST orqali, gRPC orqali katalog xizmatiga o'tadi, mahsulotlar ro'yxatini oladi va uni qaytarib beradi. Bu yerda kuta olmaysiz. Va boshqa xizmatlar bilan u asinxron ishlaydi. Buyurtmani yetkazib berish xizmatiga o'tkazing, xat yuboring va hokazo.
  Siz bularning barchasidan allaqachon suzgandirsiz? Buni kuzatib turishi kerak bo'lgan admin esa battar sarosimaga tushdi.
• U to'g'ri rejalashtirish va rejalashtirish qobiliyatiga ega bo'lishi kerak - ish tobora kuchayib boraveradi.
• Shuning uchun u qanday qilib maxsus nazorat qilishni tushunish uchun yaratilgan xizmatdan strategiya yaratishi kerak. U loyiha arxitekturasini va uning rivojlanishini tushunishi + ishlab chiqishda qo'llaniladigan texnologiyalarni tushunishi kerak.

Mutlaqo oddiy holatni eslaylik: ba'zi xizmatlar PHPda, ba'zi xizmatlar Go'da, ba'zi xizmatlar JSda. Ular qandaydir tarzda bir-birlari bilan ishlashadi. “Mikroservis” atamasi aynan shu yerdan kelib chiqadi: ishlab chiquvchilar loyihani bir butun sifatida tushuna olmaydigan juda ko'p individual tizimlar mavjud. Jamoaning bir qismi JS-da o'z-o'zidan ishlaydigan xizmatlarni yozadi va tizimning qolgan qismi qanday ishlashini bilmaydi. Boshqa qismi Python-da xizmatlarni yozadi va boshqa xizmatlar qanday ishlashiga xalaqit bermaydi; ular o'z hududida izolyatsiya qilingan. Uchinchisi, PHP yoki boshqa biror narsada xizmatlar yozish.
Bu 20 kishining barchasi 15 ta xizmatga bo'lingan va bularning barchasini tushunishi kerak bo'lgan faqat bitta admin bor. STOP! biz faqat tizimni 15 ta mikroservisga ajratdik, chunki 20 kishi butun tizimni tushuna olmaydi.

Ammo buni qandaydir tarzda kuzatib borish kerak ...

Natija qanday? Natijada, butun ishlab chiquvchilar jamoasi tushunolmaydigan hamma narsani o'ylab topadigan bitta odam bor va shu bilan birga u biz yuqorida ko'rsatgan narsalarni bilishi va qila olishi kerak - apparat infratuzilmasi, Kubernetes infratuzilmasi va boshqalar.

Nima deyman... Xyuston, bizda muammolar bor.

Zamonaviy dasturiy ta'minot loyihasini monitoring qilish o'z-o'zidan dasturiy loyihadir

Monitoring dasturiy ta'minot degan noto'g'ri e'tiqoddan biz mo''jizalarga ishonch hosil qilamiz. Ammo mo''jizalar, afsuski, sodir bo'lmaydi. Siz zabbixni o'rnatolmaysiz va hamma narsa ishlashini kutasiz. Grafana-ni o'rnatish va hamma narsa yaxshi bo'ladi deb umid qilishdan foyda yo'q. Ko'p vaqt xizmatlarning ishlashini va ularning bir-biri bilan o'zaro ta'sirini tekshirishni tashkil etishga, tashqi tizimlar qanday ishlashini tekshirishga sarflanadi. Aslida, vaqtning 90% skript yozishga emas, balki dasturiy ta'minotni ishlab chiqishga sarflanadi. Va u bilan loyihaning ishini tushunadigan jamoa shug'ullanishi kerak.
Agar bu vaziyatda bir kishi kuzatuvga tashlansa, falokat yuz beradi. Hamma joyda sodir bo'ladigan narsa.

Masalan, Kafka orqali bir-biri bilan aloqa qiladigan bir nechta xizmatlar mavjud. Buyurtma keldi, biz Kafkaga buyurtma haqida xabar yubordik. Buyurtma haqidagi ma'lumotlarni tinglaydigan va tovarlarni jo'natadigan xizmat mavjud. Buyurtma haqidagi ma'lumotlarni tinglaydigan va foydalanuvchiga xat yuboradigan xizmat mavjud. Va keyin yana bir nechta xizmatlar paydo bo'ladi va biz chalkashib keta boshlaymiz.

Va agar siz buni administrator va ishlab chiquvchilarga chiqarilishiga qisqa vaqt qolgan bosqichda bersangiz, odam ushbu protokolni tushunishi kerak bo'ladi. Bular. Bunday miqyosdagi loyiha ko'p vaqtni oladi va bu tizimni ishlab chiqishda hisobga olinishi kerak.
Ammo ko'pincha, ayniqsa startaplarda biz monitoring qanday kechikishini ko'ramiz. “Endi biz kontseptsiya isbotini yaratamiz, biz u bilan ishga tushamiz, u yiqilib tushsin - biz qurbon qilishga tayyormiz. Keyin hammasini kuzatib boramiz”. Loyiha pul ishlashni boshlaganida (yoki bo'lsa), biznes yanada ko'proq xususiyatlarni qo'shishni xohlaydi - chunki u ishlay boshlagan, shuning uchun uni yanada kengaytirish kerak! Va siz birinchi navbatda oldingi hamma narsani kuzatishingiz kerak bo'lgan nuqtadasiz, bu vaqtning 1% emas, balki ko'proq vaqtni oladi. Aytgancha, ishlab chiquvchilar monitoring uchun kerak bo'ladi va ularga yangi xususiyatlarda ishlashga ruxsat berish osonroq. Natijada, yangi xususiyatlar yoziladi, hamma narsa buziladi va siz cheksiz boshi berk ko'chadasiz.

Xo'sh, loyihani boshidan qanday kuzatib borish kerak va agar siz nazorat qilinishi kerak bo'lgan loyihani olsangiz, nima qilish kerak, lekin qaerdan boshlashni bilmasangiz?

Birinchidan, siz rejalashtirishingiz kerak.

Lirik chekinish: ko'pincha ular infratuzilma monitoringi bilan boshlanadi. Masalan, bizda Kubernetes bor. Keling, Grafana bilan Prometeyni o'rnatish, "kub" ni kuzatish uchun plaginlarni o'rnatishdan boshlaylik. Nafaqat ishlab chiquvchilar, balki ma'murlar ham bunday baxtsiz amaliyotga ega: "Biz ushbu plaginni o'rnatamiz, lekin plagin buni qanday qilishni biladi." Odamlar muhim harakatlardan ko'ra oddiy va tushunarli narsalardan boshlashni yaxshi ko'radilar. Va infratuzilma monitoringi oson.

Birinchidan, nimani va qanday kuzatishni xohlayotganingizni hal qiling va keyin vositani tanlang, chunki boshqa odamlar siz uchun o'ylay olmaydi. Va ular kerakmi? Boshqa odamlar universal tizim haqida o'ylashdi - yoki bu plagin yozilganda umuman o'ylamagan. Va bu plaginning 5 ming foydalanuvchisi bo'lganligi uning hech qanday foydasi borligini anglatmaydi. Ehtimol, siz 5001-chi bo'lasiz, chunki u erda ilgari 5000 kishi bo'lgan.

Agar siz infratuzilmani kuzatishni boshlasangiz va ilovangizning orqa qismi javob berishni to‘xtatsa, barcha foydalanuvchilar mobil ilova bilan aloqani yo‘qotadilar. Xato paydo bo'ladi. Ular sizning oldingizga kelib, “Ilova ishlamayapti, bu yerda nima qilyapsan?” deyishadi. - "Biz kuzatyapmiz." - "Agar ilova ishlamayotganini ko'rmasangiz, qanday nazorat qilasiz?!"

1. Menimcha, siz kuzatuvni foydalanuvchining kirish nuqtasidan boshlashingiz kerak. Agar foydalanuvchi dastur ishlayotganini ko'rmasa, bu hammasi, bu muvaffaqiyatsizlik. Va monitoring tizimi bu haqda birinchi navbatda ogohlantirishi kerak.
2. Va shundan keyingina biz infratuzilmani kuzatishimiz mumkin. Yoki buni parallel ravishda bajaring. Infratuzilma bilan bu osonroq - bu erda biz zabbixni o'rnatishimiz mumkin.
3. Va endi narsalar ishlamayotgan joyni tushunish uchun dasturning ildizlariga o'tishingiz kerak.

Mening asosiy fikrim shundan iboratki, monitoring rivojlanish jarayoni bilan parallel ravishda olib borilishi kerak. Agar siz monitoring guruhini boshqa vazifalarga (CI/CD yaratish, sandboxing, infratuzilmani qayta tashkil etish) chalg'itsangiz, monitoring ortda qola boshlaydi va siz hech qachon rivojlanishga erisha olmaysiz (yoki ertami-kechmi uni to'xtatishingiz kerak bo'ladi).

Hammasi darajalar bo'yicha

Men monitoring tizimini tashkil etishni shunday ko'raman.

1) Ilova darajasi:

• dastur biznes mantig'ini kuzatish;
• xizmatlarning sog'liqni saqlash ko'rsatkichlarini monitoring qilish;
• integratsiya monitoringi.

2) Infratuzilma darajasi:

• orkestr darajasini kuzatish;
• tizim dasturiy ta'minoti monitoringi;
• temir darajasini kuzatish.

3) Yana dastur darajasi - lekin muhandislik mahsuloti sifatida:

• ilovalar jurnallarini yig'ish va monitoring qilish;
• APM;
• kuzatish.

4) Ogohlantirish:

• ogohlantirish tizimini tashkil etish;
• navbatchilik tizimini tashkil etish;
• hodisalarni qayta ishlash uchun "bilimlar bazasi" va ish jarayonini tashkil etish.

Muhim: biz ogohlantirishga keyin emas, balki darhol erishamiz! Monitoringni boshlash va "keyinchalik" kim ogohlantirishlarni olishini aniqlashning hojati yo'q. Axir, monitoringning vazifasi nimadan iborat: tizimning qayerida nimadir noto'g'ri ishlayotganini tushunish va bu haqda kerakli odamlarga xabar berish. Agar siz buni oxirigacha qoldirsangiz, to'g'ri odamlar nimadir noto'g'ri ketayotganini faqat "biz uchun hech narsa ishlamayapti" deb bilishadi.

Ilova qatlami - Biznes mantiq monitoringi

Bu erda biz dasturning foydalanuvchi uchun ishlashini tekshirish haqida gapiramiz.

Ushbu daraja rivojlanish bosqichida amalga oshirilishi kerak. Misol uchun, bizda shartli Prometey bor: u tekshiruvlarni amalga oshiradigan serverga boradi, oxirgi nuqtani tortadi va oxirgi nuqta APIni tekshiradi.

Ko'pincha sayt ishlayotganiga ishonch hosil qilish uchun bosh sahifani kuzatish so'ralganda, dasturchilar API ishlayotganiga ishonch hosil qilish uchun har safar tortilishi mumkin bo'lgan dastani beradi. Va hozirda dasturchilar /api/test/helloworld ni olib yozadilar
Hamma narsa ishlayotganiga ishonch hosil qilishning yagona yo'li? - Yo'q!

• Bunday tekshiruvlarni yaratish asosan ishlab chiquvchilarning vazifasidir. Birlik testlari kodni yozadigan dasturchilar tomonidan yozilishi kerak. Agar siz uni administratorga topshirsangiz, "Do'stim, bu erda barcha 25 funksiya uchun API protokollari ro'yxati bor, iltimos, hammasini kuzatib boring!" - hech narsa chiqmaydi.
• Agar siz "salom dunyo" ni chop qilsangiz, hech kim API ishlashi kerakligini va ishlashini bilmaydi. Har bir API o'zgarishi cheklarning o'zgarishiga olib kelishi kerak.
• Agar sizda allaqachon bunday muammo bo'lsa, xususiyatlarni to'xtating va ushbu cheklarni yozadigan yoki yo'qotishlarni qabul qiladigan ishlab chiquvchilarni ajrating, hech narsa tekshirilmaganligini va muvaffaqiyatsiz bo'lishini qabul qiling.

Texnik maslahatlar:

• Tekshirishlarni tashkil qilish uchun tashqi serverni tashkil qilganingizga ishonch hosil qiling - loyihangiz tashqi dunyo uchun ochiq ekanligiga ishonch hosil qilishingiz kerak.
• Nafaqat alohida so'nggi nuqtalar emas, balki butun API protokoli bo'ylab tekshirishlarni tashkil qiling.
• Sinov natijalari bilan prometey-so'nggi nuqta yarating.

Ilova qatlami - salomatlik ko'rsatkichlari monitoringi

Endi biz xizmatlarning tashqi sog'liqni saqlash ko'rsatkichlari haqida gapiramiz.

Biz ilovaning barcha "tutqichlarini" tashqi monitoring tizimidan chaqiradigan tashqi tekshiruvlar yordamida kuzatishga qaror qildik. Ammo bu foydalanuvchi "ko'radigan" "tutqichlar". Biz xizmatlarimizning o'zi ishlashiga ishonch hosil qilishni istaymiz. Bu erda hikoya yaxshiroq: K8s sog'lig'ini tekshirishga ega, shuning uchun hech bo'lmaganda "kub" ning o'zi xizmat ishlayotganiga ishonch hosil qilishi mumkin. Lekin men ko'rgan cheklarning yarmi bir xil bosma "salom dunyo". Bular. Shunday qilib, u ishga tushirilgandan keyin bir marta tortadi, u hamma narsa yaxshi, deb javob berdi - hammasi. Xizmat, agar u o'zining API-ni taqdim etsa, xuddi shu API uchun juda ko'p kirish nuqtalariga ega, ular ham kuzatilishi kerak, chunki biz uning ishlashini bilmoqchimiz. Va biz uni allaqachon ichkarida kuzatmoqdamiz.

Buni texnik jihatdan qanday qilib to'g'ri amalga oshirish kerak: har bir xizmat o'zining joriy ishlashi haqida so'nggi nuqtani ko'rsatadi va Grafana (yoki boshqa har qanday dastur) grafiklarida biz barcha xizmatlarning holatini ko'ramiz.

• Har bir API o'zgarishi cheklarning o'zgarishiga olib kelishi kerak.
• Salomatlik ko'rsatkichlari bilan darhol yangi xizmat yarating.
• Administrator ishlab chiquvchilarga kelib, "hamma narsani tushunishim uchun menga bir nechta xususiyatlarni qo'shing va bu haqda monitoring tizimimga ma'lumot qo'shing" deb so'rashi mumkin. Ammo ishlab chiquvchilar odatda: "Biz chiqishdan ikki hafta oldin hech narsa qo'shmaymiz" deb javob berishadi.
  Rivojlanish menejerlari bunday yo'qotishlar bo'lishini bilishsin, rivojlanish menejerlari rahbariyatiga ham xabar bering. Chunki hamma narsa tushib ketganda, kimdir hali ham qo'ng'iroq qiladi va "doimiy ravishda tushib ketayotgan xizmatni" kuzatishni talab qiladi (c)
• Aytgancha, Grafana uchun plaginlarni yozish uchun ishlab chiquvchilarni ajrating - bu administratorlar uchun yaxshi yordam bo'ladi.

Ilova qatlami - Integratsiya monitoringi

Integratsiya monitoringi biznes uchun muhim tizimlar o'rtasidagi aloqalarni kuzatishga qaratilgan.

Misol uchun, bir-biri bilan aloqa qiladigan 15 ta xizmat mavjud. Bular endi alohida saytlar emas. Bular. biz xizmatni o'z-o'zidan tortib ololmaymiz, /helloworld-ni olamiz va xizmat ishlayotganini tushunamiz. Buyurtma beruvchi veb-xizmati buyurtma haqidagi ma'lumotlarni avtobusga yuborishi kerakligi sababli - avtobusdan ombor xizmati ushbu xabarni qabul qilishi va u bilan yanada ishlashi kerak. Va elektron pochtani tarqatish xizmati buni qandaydir tarzda qayta ishlashi kerak va hokazo.

Shunga ko'ra, biz har bir alohida xizmatga murojaat qilsak, hammasi ishlayotganini tushunolmaymiz. Chunki bizda ma'lum bir avtobus bor, u orqali hamma narsa aloqa qiladi va o'zaro ta'sir qiladi.
Shu sababli, ushbu bosqich boshqa xizmatlar bilan o'zaro ta'sir qilish uchun xizmatlarni sinovdan o'tkazish bosqichini belgilashi kerak. Xabar brokerini kuzatish orqali aloqa monitoringini tashkil qilish mumkin emas. Agar ma'lumotlarni chiqaradigan xizmat va uni qabul qiladigan xizmat mavjud bo'lsa, brokerni kuzatishda biz faqat u yoqdan bu yoqqa uchadigan ma'lumotlarni ko'ramiz. Agar biz qandaydir tarzda ushbu ma'lumotlarning o'zaro ta'sirini ichki nazorat qilishga muvaffaq bo'lsak ham - ma'lum bir ishlab chiqaruvchi ma'lumotlarni joylashtiradi, kimdir uni o'qiydi, bu oqim Kafkaga borishda davom etadi - agar bitta xizmat xabarni bitta versiyada yuborsa, bu bizga ma'lumot bermaydi. , lekin boshqa xizmat bu versiyani kutmagan va uni o'tkazib yuborgan. Biz bu haqda bilmaymiz, chunki xizmatlar bizga hamma narsa ishlayotganini aytadi.

Men nima qilishni tavsiya qilaman:

• Sinxron aloqa uchun: oxirgi nuqta tegishli xizmatlarga so'rovlar yuboradi. Bular. biz ushbu so'nggi nuqtani olamiz, xizmat ichidagi skriptni tortamiz, u barcha nuqtalarga o'tadi va "Men u erga tortib olaman va u erga tortib olaman, u erga tortib olaman ..."
• Asinxron aloqa uchun: kiruvchi xabarlar - oxirgi nuqta sinov xabarlari uchun avtobusni tekshiradi va ishlov berish holatini ko'rsatadi.
• Asinxron aloqa uchun: chiquvchi xabarlar - oxirgi nuqta sinov xabarlarini avtobusga yuboradi.

Odatdagidek: bizda ma'lumotlarni avtobusga tashlaydigan xizmat mavjud. Biz ushbu xizmatga keldik va uning integratsiya salomatligi haqida bizga xabar berishingizni so'raymiz. Va agar xizmat boshqa joyda (WebApp) xabar ishlab chiqarishi kerak bo'lsa, u ushbu sinov xabarini ishlab chiqaradi. Agar biz Buyurtmani qayta ishlash tomonida xizmatni ishga tushirsak, u birinchi navbatda mustaqil ravishda nima joylashtirishi mumkinligini e'lon qiladi va agar ba'zi bog'liq narsalar mavjud bo'lsa, u avtobusdan test xabarlari to'plamini o'qiydi, ularni qayta ishlashini, hisobot berishini tushunadi va , agar kerak bo'lsa, ularni boshqa joyga qo'ying va bu haqda u aytadi - hammasi yaxshi, men tirikman.

Ko'pincha biz "buni jangovar ma'lumotlarda qanday sinab ko'rishimiz mumkin?" Degan savolni eshitamiz. Misol uchun, biz bir xil buyurtma xizmati haqida gapiramiz. Buyurtma tovarlar hisobdan chiqarilgan omborga xabarlar yuboradi: biz buni jangovar ma'lumotlarda sinab ko'ra olmaymiz, chunki "mening tovarlarim hisobdan chiqariladi!" Yechim: Ushbu testni boshidanoq rejalashtiring. Sizda masxara qiladigan birlik testlari ham bor. Shunday qilib, biznesning ishlashiga zarar keltirmaydigan aloqa kanaliga ega bo'lgan chuqurroq darajada qiling.

Infratuzilma darajasi

Infratuzilma monitoringi uzoq vaqtdan beri o'zini monitoring deb hisoblangan narsadir.

• Infratuzilma monitoringi alohida jarayon sifatida ishga tushirilishi mumkin va kerak.
• Agar chindan ham xohlasangiz ham, ishlayotgan loyihada infratuzilma monitoringini boshlamasligingiz kerak. Bu barcha devoplar uchun og'riqdir. "Avval men klasterni kuzataman, infratuzilmani kuzataman" - ya'ni. Birinchidan, u quyida nima yotganini kuzatib boradi, lekin ilovaga kirmaydi. Chunki dastur devoplar uchun tushunarsiz narsa. Bu unga sizdirilgan va u qanday ishlashini tushunmaydi. Lekin u infratuzilmani tushunadi va undan boshlaydi. Lekin yo'q - har doim birinchi navbatda dasturni kuzatib borishingiz kerak.
• Ogohlantirishlar soni bilan haddan oshib ketmang. Zamonaviy tizimlarning murakkabligini hisobga olsak, ogohlantirishlar doimiy ravishda uchib turadi va siz qandaydir tarzda bu ogohlantirishlar to'plami bilan yashashingiz kerak. Va qo'ng'iroq qiluvchi yuzlab keyingi ogohlantirishlarni ko'rib chiqib, "men bu haqda o'ylashni xohlamayman" deb qaror qiladi. Ogohlantirishlar faqat muhim narsalar haqida xabar berishi kerak.

Biznes birligi sifatida dastur darajasi

Asosiy fikrlar:

• ELK. Bu sanoat standarti. Agar biron sababga ko'ra siz jurnallarni jamlamasangiz, darhol buni boshlang.
• APM. Tashqi APMlar ilova monitoringini tezda yopish usuli sifatida (NewRelic, BlackFire, Datadog). Hech bo'lmaganda qandaydir tarzda siz bilan nima sodir bo'layotganini tushunish uchun ushbu narsani vaqtincha o'rnatishingiz mumkin.
• Kuzatish. O'nlab mikroservislarda siz hamma narsani kuzatib borishingiz kerak, chunki so'rov endi o'z-o'zidan yashamaydi. Keyinchalik qo'shish juda qiyin, shuning uchun rivojlanishda kuzatuvni darhol rejalashtirish yaxshidir - bu ishlab chiquvchilarning ishi va yordami. Agar siz hali uni amalga oshirmagan bo'lsangiz, uni amalga oshiring! Jaeger/Zipkinga qarang

Ogohlantirish

• Xabar berish tizimini tashkil etish: bir nechta narsalarni kuzatish sharoitida bildirishnomalarni yuborishning yagona tizimi bo'lishi kerak. Grafana'da mumkin. G'arbda hamma PagerDuty-dan foydalanadi. Ogohlantirishlar aniq bo'lishi kerak (masalan, ular qaerdan kelgan ...). Va bildirishnomalarning umuman qabul qilinishini nazorat qilish tavsiya etiladi
• Navbatchilik tizimini tashkil etish: ogohlantirishlar hammaga yuborilmasligi kerak (yoki hamma olomonda reaksiyaga kirishadi yoki hech kim javob bermaydi). Ishlab chiquvchilar ham qo'ng'iroq qilishlari kerak: mas'uliyat sohalarini aniq belgilab qo'ying, aniq ko'rsatmalar bering va dushanba va chorshanba kunlari kimga qo'ng'iroq qilishni va seshanba va juma kunlari kimga qo'ng'iroq qilishni yozing (aks holda ular hatto shaharda ham hech kimga qo'ng'iroq qilmaydilar. katta muammo bo'lgan voqea - ular sizni uyg'otishdan yoki bezovta qilishdan qo'rqishadi: odamlar odatda boshqa odamlarga qo'ng'iroq qilishni va uyg'otishni yoqtirmaydilar, ayniqsa kechasi). Va yordam so'rash qobiliyatsizlik ko'rsatkichi emasligini tushuntiring ("Men yordam so'rayman, bu men yomon ishchiman"), yordam so'rovlarini rag'batlantiring.
• "Bilimlar bazasi" ni tashkil etish va hodisani qayta ishlash bo'yicha ish jarayoni: har bir jiddiy hodisa uchun o'limdan keyingi o'limni rejalashtirish va vaqtinchalik chora sifatida hodisani hal qiladigan harakatlar qayd etilishi kerak. Va takroriy ogohlantirishlar gunoh ekanligini odat qiling; ular kod yoki infratuzilma ishlarida aniqlanishi kerak.

Texnologiya to'plami

Tasavvur qilaylik, bizning stekimiz quyidagicha:

• ma'lumotlar yig'ish - Prometey + Grafana;
• jurnalni tahlil qilish - ELK;
• APM yoki Tracing uchun - Jaeger (Zipkin).

Variantlarni tanlash muhim emas. Chunki agar boshida siz tizimni qanday kuzatishni tushungan bo'lsangiz va rejani yozgan bo'lsangiz, unda siz o'zingizning talablaringizga mos keladigan vositalarni tanlashni boshlaysiz. Savol shundaki, siz birinchi navbatda nimani kuzatishni tanladingiz. Chunki boshida tanlagan vositangiz sizning talablaringizga umuman mos kelmasligi mumkin.

Men so'nggi paytlarda hamma joyda ko'rgan bir nechta texnik fikrlar:

Prometeyni Kubernetes ichiga itarib yuborishmoqda - buni kim o'ylab topdi?! Agar klasteringiz qulab tushsa, nima qilasiz? Agar sizning ichingizda murakkab klaster bo'lsa, unda klaster ichida qandaydir monitoring tizimi bo'lishi kerak, ba'zilari esa klaster ichidan ma'lumotlarni to'playdigan tashqarida.

Klaster ichida biz jurnallar va boshqa narsalarni yig'amiz. Ammo monitoring tizimi tashqarida bo'lishi kerak. Ko'pincha, Promtheus o'rnatilgan klasterda, shuningdek, saytning ishlashini tashqi tekshirishni amalga oshiradigan tizimlar mavjud. Agar tashqi dunyo bilan aloqalaringiz uzilib qolsa va dastur ishlamasa-chi? Ma'lum bo'lishicha, ichkarida hamma narsa yaxshi, lekin bu foydalanuvchilar uchun ishlarni osonlashtirmaydi.

topilmalar

• Rivojlanishni monitoring qilish kommunal xizmatlarni o'rnatish emas, balki dasturiy mahsulotni ishlab chiqishdir. Bugungi monitoringning 98% kodlashdan iborat. Xizmatlarni kodlash, tashqi tekshiruvlarni kodlash, tashqi xizmatlarni tekshirish va bu hammasi.
• Dasturchilarning vaqtini monitoring qilish uchun sarflamang: bu ularning ishining 30 foizini olishi mumkin, ammo bunga arziydi.
• Devops, biror narsani kuzata olmasligingizdan xavotir olmang, chunki ba'zi narsalar butunlay boshqacha fikrlash tarzidir. Siz dasturchi emas edingiz va monitoring ishi aynan ularning ishi.
• Agar loyiha allaqachon ishlayotgan bo'lsa va nazorat qilinmasa (va siz menejer bo'lsangiz), monitoring uchun resurslarni ajrating.
• Agar mahsulot allaqachon ishlab chiqarilgan bo'lsa va siz "monitoringni o'rnatish" kerak bo'lgan devops bo'lsangiz - bularning barchasi haqida men nima yozganimni rahbariyatga tushuntirishga harakat qiling.

Bu Saint Highload++ konferensiyasidagi hisobotning kengaytirilgan versiyasi.

Agar siz mening g'oyalarim va fikrlarim va tegishli mavzular bilan qiziqsangiz, bu erda mumkin kanalni o'qing 🙂

Manba: www.habr.com