Biz mahsulot guruhlarini shakllantirish bosqichida monitoring tizimini yaratish haqida o'yladik. Bizning biznesimiz - ekspluatatsiya - bu jamoalarga kirmasligi aniq bo'ldi. Nega bunday?
Gap shundaki, bizning barcha jamoalarimiz alohida axborot tizimlari, mikroservislar va jabhalar atrofida qurilgan, shuning uchun jamoalar butun tizimning umumiy salomatligini ko'rmaydilar. Masalan, ular chuqur orqa qismdagi ba'zi bir kichik qism old qismga qanday ta'sir qilishini bilmasligi mumkin. Ularning qiziqish doirasi ularning tizimi integratsiyalashgan tizimlar bilan cheklangan. Agar jamoa va uning A xizmati B xizmati bilan deyarli aloqasi bo'lmasa, unda bunday xizmat jamoa uchun deyarli ko'rinmaydi.
Bizning jamoamiz, o'z navbatida, bir-biri bilan juda kuchli integratsiyalashgan tizimlar bilan ishlaydi: ular orasida juda ko'p aloqalar mavjud, bu juda katta infratuzilma. Va onlayn-do'konning ishlashi ushbu tizimlarning barchasiga bog'liq (aytmoqchi, bizda juda ko'p).
Shunday qilib, bizning bo'lim hech qanday jamoaga tegishli emas, balki biroz yon tomonda joylashgan. Ushbu butun hikoyada bizning vazifamiz axborot tizimlari qanday ishlashini, ularning funksionalligi, integratsiyalari, dasturiy ta'minot, tarmoq, apparat vositalari va bularning barchasi bir-biri bilan qanday bog'langanligini har tomonlama tushunishdir.
Bizning onlayn-do'konlarimiz ishlaydigan platforma quyidagicha ko'rinadi:
- front
- o'rta ofis
- orqaga ofisi
Biz qanchalik istamaylik, barcha tizimlar muammosiz va benuqson ishlashi mumkin emas. Gap, yana, tizimlar va integratsiyalarning soni - biznikiga o'xshash narsa bilan, sinov sifatiga qaramay, ba'zi hodisalar muqarrar. Bundan tashqari, alohida tizim doirasida ham, ularning integratsiyasi nuqtai nazaridan ham. Va siz uning har qanday alohida qismini emas, balki butun platformaning holatini har tomonlama kuzatib borishingiz kerak.
Ideal holda, platforma bo'ylab sog'liqni saqlash monitoringi avtomatlashtirilgan bo'lishi kerak. Va biz monitoringga ushbu jarayonning muqarrar qismi sifatida keldik. Dastlab, u faqat oldingi qism uchun qurilgan, tarmoq mutaxassislari, dasturiy ta'minot va apparat ma'murlari esa o'zlarining qatlam-qatlam monitoring tizimlariga ega edilar va hozir ham mavjud. Bu odamlarning barchasi monitoringni faqat o'z darajasida kuzatib borishdi, hech kimda har tomonlama tushuncha yo'q edi.
Misol uchun, agar virtual mashina ishlamay qolsa, aksariyat hollarda bu haqda faqat apparat va virtual mashina uchun mas'ul bo'lgan administrator biladi. Bunday hollarda, oldingi guruh dasturning ishdan chiqishi faktini ko'rdi, ammo virtual mashinaning ishdan chiqishi haqida ma'lumot yo'q edi. Va administrator mijozning kimligini bilishi va ushbu virtual mashinada hozirda nima ishlayotgani haqida taxminiy tasavvurga ega bo'lishi mumkin, agar u qandaydir yirik loyiha bo'lsa. U, ehtimol, kichkintoylar haqida bilmaydi. Har qanday holatda, administrator egasiga borib, ushbu mashinada nima borligini, nimani tiklash kerakligini va nimani o'zgartirish kerakligini so'rashi kerak. Va agar haqiqatan ham jiddiy narsa buzilsa, ular aylana bo'ylab yugura boshladilar - chunki hech kim tizimni bir butun sifatida ko'rmadi.
Oxir oqibat, bunday turli xil voqealar butun frontendga, foydalanuvchilarga va bizning asosiy biznes vazifamiz - onlayn savdoga ta'sir qiladi. Biz jamoaning bir qismi emasmiz, lekin onlayn-do'konning bir qismi sifatida barcha elektron tijorat ilovalari bilan shug'ullanayotganimiz sababli, biz elektron tijorat platformasi uchun keng qamrovli monitoring tizimini yaratish vazifasini oldik.
Tizim tuzilishi va stek
Biz tizimlarimiz uchun bir nechta monitoring qatlamlarini aniqlashdan boshladik, ular ichida ko'rsatkichlarni to'plashimiz kerak. Va bularning barchasini birlashtirish kerak edi, biz birinchi bosqichda shunday qildik. Endi ushbu bosqichda biz korrelyatsiyani o'rnatish va tizimlarning bir-biriga qanday ta'sir qilishini tushunish uchun barcha qatlamlarimiz bo'ylab yuqori sifatli o'lchovlar to'plamini yakunlaymiz.
Ilovalarni ishga tushirishning dastlabki bosqichlarida keng qamrovli monitoringning yo'qligi (biz uni ko'pchilik tizimlar ishlab chiqarilayotgan paytda qurishni boshlaganimizdan beri) butun platformaning monitoringini o'rnatish uchun katta texnik qarzimiz borligiga olib keldi. Biz bitta IS uchun monitoringni o‘rnatish va uning monitoringini batafsil ishlab chiqishga e’tibor qarata olmadik, chunki qolgan tizimlar bir muncha vaqt monitoringsiz qolar edi. Ushbu muammoni hal qilish uchun biz axborot tizimining holatini qatlam bo'yicha baholash uchun eng zarur ko'rsatkichlar ro'yxatini aniqladik va uni amalga oshirishni boshladik.
Shuning uchun ular filni qismlarga bo'lib eyishga qaror qilishdi.
Bizning tizimimiz quyidagilardan iborat:
- apparat;
- operatsion tizim;
- dasturiy ta'minot;
- Monitoring ilovasida UI qismlari;
- biznes ko'rsatkichlari;
- integratsiya dasturlari;
- axborot xavfsizligi;
- tarmoqlar;
- trafik balanslagichi.
Ushbu tizimning markazida o'zini o'zi kuzatib boradi. Butun tizimning holatini umumiy tushunish uchun siz ushbu qatlamlarning barchasida va barcha ilovalar to'plamidagi ilovalar bilan nima sodir bo'layotganini bilishingiz kerak.
Shunday qilib, stack haqida.
Biz ochiq kodli dasturiy ta'minotdan foydalanamiz. Markazda bizda Zabbix mavjud bo'lib, biz asosan ogohlantirish tizimi sifatida foydalanamiz. Bu infratuzilma monitoringi uchun ideal ekanligini hamma biladi. Bu qanday ma'nono bildiradi? Aynan o'z ma'lumotlar markaziga ega bo'lgan har bir kompaniyaning past darajadagi ko'rsatkichlari (va Sportmaster o'z ma'lumotlar markazlariga ega) - server harorati, xotira holati, reyd, tarmoq qurilmasi ko'rsatkichlari.
Biz Zabbix-ni jamoalarda faol foydalaniladigan Telegram messenjeri va Microsoft Teams bilan birlashtirdik. Zabbix haqiqiy tarmoq, apparat va ba'zi dasturiy ta'minot qatlamini qamrab oladi, ammo bu panacea emas. Biz bu maʼlumotlarni baʼzi boshqa xizmatlardan boyitamiz. Masalan, apparat darajasida biz virtualizatsiya tizimimizga API orqali bevosita ulanamiz va ma’lumotlarni yig‘amiz.
Nima yana. Zabbix-ga qo'shimcha ravishda biz Prometeydan foydalanamiz, bu bizga dinamik muhit ilovasida o'lchovlarni kuzatish imkonini beradi. Ya'ni, biz HTTP so'nggi nuqtasi orqali dastur ko'rsatkichlarini olishimiz mumkin va unga qaysi ko'rsatkichlar yuklanishi va qaysi biri yuklanmasligi haqida tashvishlanmaymiz. Ushbu ma'lumotlarga asoslanib, tahliliy so'rovlar ishlab chiqilishi mumkin.
Boshqa qatlamlar uchun ma'lumotlar manbalari, masalan, biznes ko'rsatkichlari, uchta komponentga bo'lingan.
Birinchidan, bu tashqi biznes tizimlari, Google Analytics, biz jurnallardan ko'rsatkichlarni yig'amiz. Ulardan biz faol foydalanuvchilar, konversiyalar va biznes bilan bog'liq boshqa barcha ma'lumotlarni olamiz. Ikkinchidan, bu UI monitoring tizimi. Buni batafsilroq tavsiflash kerak.
Bir vaqtlar biz qo'lda testdan boshladik va u funksionallik va integratsiyaning avtomatik sinovlariga aylandi. Shundan kelib chiqib, biz faqat asosiy funksiyalarni qoldirib, imkon qadar barqaror va vaqt o'tishi bilan tez-tez o'zgarmaydigan markerlarga tayandik.
Jamoaning yangi tuzilishi shuni anglatadiki, barcha dastur faoliyati mahsulot guruhlari bilan chegaralanadi, shuning uchun biz sof sinovni to'xtatdik. Buning o'rniga biz Java, Selenium va Jenkins tillarida yozilgan testlardan UI monitoringini qildik (hisobotlarni ishga tushirish va yaratish uchun tizim sifatida ishlatiladi).
Bizda juda ko'p sinovlar bor edi, lekin oxirida biz asosiy yo'lga, yuqori darajadagi metrikaga borishga qaror qildik. Va agar bizda juda ko'p maxsus testlar bo'lsa, ma'lumotlarni yangilab turish qiyin bo'ladi. Har bir keyingi versiya butun tizimni sezilarli darajada buzadi va biz qiladigan narsa uni tuzatishdir. Shuning uchun biz kamdan-kam o'zgarib turadigan juda fundamental narsalarga e'tibor qaratdik va biz ularni faqat kuzatib boramiz.
Nihoyat, uchinchidan, ma'lumotlar manbai markazlashtirilgan ro'yxatga olish tizimidir. Biz jurnallar uchun Elastic Stack-dan foydalanamiz va keyin bu ma'lumotlarni biznes ko'rsatkichlari uchun monitoring tizimimizga olishimiz mumkin. Bularning barchasiga qo'shimcha ravishda, bizda Python-da yozilgan o'z Monitoring API xizmatimiz bor, u API orqali har qanday xizmatlarga so'rov yuboradi va ulardan Zabbix-ga ma'lumotlarni to'playdi.
Monitoringning yana bir ajralmas atributi vizualizatsiyadir. Bizniki Grafana asosida yaratilgan. U boshqa vizualizatsiya tizimlaridan ajralib turadi, chunki u asboblar panelida turli xil ma'lumotlar manbalaridan ko'rsatkichlarni ko'rish imkonini beradi. Biz onlayn-do'kon uchun yuqori darajadagi ko'rsatkichlarni to'plashimiz mumkin, masalan, ma'lumotlar bazasidan so'nggi soatda berilgan buyurtmalar soni, Zabbix-dan ushbu onlayn-do'kon ishlayotgan OS uchun ishlash ko'rsatkichlari va ushbu ilova misollari uchun ko'rsatkichlar Prometeydan. Va bularning barchasi bitta boshqaruv panelida bo'ladi. Aniq va foydalanish mumkin.
Xavfsizlik haqida eslatib o'tmoqchiman - biz hozirda tizimni yakunlamoqdamiz, uni keyinchalik global monitoring tizimi bilan integratsiya qilamiz. Mening fikrimcha, elektron tijorat axborot xavfsizligi sohasida duch keladigan asosiy muammolar botlar, tahlilchilar va qo'pol kuchlar bilan bog'liq. Biz buni kuzatib borishimiz kerak, chunki bularning barchasi bizning ilovalarimiz ishlashiga ham, biznes nuqtai nazaridan bizning obro'imizga ham jiddiy ta'sir ko'rsatishi mumkin. Va tanlangan stek bilan biz ushbu vazifalarni muvaffaqiyatli bajaramiz.
Yana bir muhim jihat shundaki, dastur qatlami Prometey tomonidan yig'ilgan. Uning o'zi ham Zabbix bilan birlashtirilgan. Shuningdek, bizda sayt tezligi, sahifamizning yuklanish tezligi, qiyinchiliklar, sahifani ko'rsatish, skriptlarni yuklash va hokazo kabi parametrlarni ko'rish imkonini beruvchi xizmat mavjud, u ham API bilan birlashtirilgan. Shunday qilib, bizning ko'rsatkichlarimiz Zabbix-da to'planadi va shunga mos ravishda biz ham u erdan ogohlantiramiz. Hozirda barcha ogohlantirishlar asosiy yuborish usullariga yuboriladi (hozircha bu elektron pochta va telegram, MS Teams ham yaqinda ulangan). Ogohlantirishni aqlli botlar xizmat sifatida ishlaydigan va barcha manfaatdor mahsulot guruhlariga monitoring ma'lumotlarini taqdim etadigan holatga qadar yangilash rejalashtirilmoqda.
Biz uchun ko'rsatkichlar nafaqat individual axborot tizimlari uchun, balki ilovalar foydalanadigan butun infratuzilma uchun umumiy ko'rsatkichlar uchun ham muhimdir: virtual mashinalar ishlaydigan jismoniy serverlar klasterlari, trafik balanslagichlari, tarmoq yukini muvozanatlash moslamalari, tarmoqning o'zi, aloqa kanallaridan foydalanish . O'zimizning ma'lumotlar markazlarimiz uchun ko'rsatkichlar (bizda ulardan bir nechtasi bor va infratuzilma juda katta).
Monitoring tizimimizning afzalliklari shundan iboratki, uning yordamida biz barcha tizimlarning salomatlik holatini ko'ramiz va ularning bir-biriga va umumiy resurslarga ta'sirini baholay olamiz. Va nihoyat, bu bizga resurslarni rejalashtirish bilan shug'ullanish imkonini beradi, bu ham bizning mas'uliyatimizdir. Biz server resurslarini boshqaramiz - elektron tijorat ichidagi hovuz, yangi uskunalarni ishga tushiramiz va o'chirib qo'yamiz, qo'shimcha yangi uskunalar sotib olamiz, resurslardan foydalanish auditini o'tkazamiz va hokazo. Har yili jamoalar yangi loyihalarni rejalashtirishadi, o'z tizimlarini ishlab chiqishadi va biz uchun ularni resurslar bilan ta'minlash muhim.
Ko'rsatkichlar yordamida biz axborot tizimlarimiz tomonidan resurslarni iste'mol qilish tendentsiyasini ko'ramiz. Va ularga asoslanib, biz nimanidir rejalashtirishimiz mumkin. Virtualizatsiya darajasida biz ma'lumotlarni yig'amiz va ma'lumotlar markazi tomonidan mavjud resurslar miqdori to'g'risidagi ma'lumotlarni ko'ramiz. Va allaqachon ma'lumotlar markazi ichida siz resurslarni qayta ishlash, haqiqiy taqsimlash va iste'mol qilishni ko'rishingiz mumkin. Bundan tashqari, mustaqil serverlar va virtual mashinalar va jismoniy serverlar klasterlari bilan, bu virtual mashinalarning barchasi shiddat bilan aylanadi.
istiqbollari
Endi bizda umuman tizimning yadrosi tayyor, lekin hali ustida ishlash kerak bo'lgan ko'p narsalar mavjud. Hech bo'lmaganda, bu axborot xavfsizligi qatlami, ammo tarmoqqa kirish, ogohlantirishni ishlab chiqish va korrelyatsiya muammosini hal qilish ham muhimdir. Bizda ko'plab qatlamlar va tizimlar mavjud va har bir qatlamda yana ko'plab ko'rsatkichlar mavjud. Bu matryoshka darajasidagi matryoshka bo'lib chiqadi.
Bizning vazifamiz oxir-oqibat to'g'ri ogohlantirishlarni qilishdir. Misol uchun, agar apparat bilan bog'liq muammo bo'lsa, yana virtual mashinada va muhim dastur mavjud bo'lsa va xizmat hech qanday tarzda zaxiralanmagan bo'lsa. Biz virtual mashinaning o'lganini bilib oldik. Keyin biznes ko'rsatkichlari sizni ogohlantiradi: foydalanuvchilar biror joyda g'oyib bo'ldi, konvertatsiya yo'q, interfeysdagi UI mavjud emas, dasturiy ta'minot va xizmatlar ham o'lgan.
Bunday vaziyatda biz ogohlantirishlardan spam olamiz va bu endi tegishli monitoring tizimining formatiga mos kelmaydi. Korrelyatsiya haqida savol tug'iladi. Shuning uchun, ideal holda, bizning monitoring tizimimiz: "Yigitlar, sizning jismoniy mashinangiz halok bo'ldi va u bilan birga ushbu ilova va ushbu ko'rsatkichlar", bizni yuzta ogohlantirish bilan jahl bilan bombardimon qilish o'rniga, bitta ogohlantirish yordamida aytishi kerak. U asosiy narsani - sababni xabar qilishi kerak, bu uning lokalizatsiyasi tufayli muammoni tezda bartaraf etishga yordam beradi.
Bizning bildirishnoma tizimimiz va ogohlantirishlarni qayta ishlash tizimi XNUMX soatlik ishonch telefoni xizmati atrofida qurilgan. Majburiy deb hisoblangan va nazorat ro'yxatiga kiritilgan barcha ogohlantirishlar u erga yuboriladi. Har bir ogohlantirish tavsifiga ega bo'lishi kerak: nima sodir bo'ldi, aslida nimani anglatadi, nima ta'sir qiladi. Shuningdek, asboblar paneliga havola va bu holatda nima qilish kerakligi haqida ko'rsatmalar.
Bularning barchasi ogohlantirishni yaratish talablari haqida. Keyin vaziyat ikki yo'nalishda rivojlanishi mumkin - yoki muammo bor va uni hal qilish kerak, yoki monitoring tizimida nosozlik bo'lgan. Lekin har qanday holatda, siz borib, buni aniqlashingiz kerak.
Ogohlantirishlar o'zaro bog'liqligi hali to'g'ri sozlanmaganligini hisobga olsak, hozir biz kuniga o'rtacha yuzga yaqin ogohlantirishlarni olamiz. Va agar biz texnik ishlarni bajarishimiz kerak bo'lsa va biz biror narsani majburan o'chirib qo'ysak, ularning soni sezilarli darajada oshadi.
Biz ishlayotgan tizimlarni kuzatish va biz uchun muhim deb hisoblangan ko'rsatkichlarni to'plashdan tashqari, monitoring tizimi mahsulot guruhlari uchun ma'lumotlarni to'plash imkonini beradi. Ular biz kuzatadigan axborot tizimlaridagi ko'rsatkichlar tarkibiga ta'sir qilishi mumkin.
Bizning hamkasbimiz kelib, biz uchun ham, jamoa uchun ham foydali bo'lgan metrikani qo'shishni so'rashi mumkin. Yoki, masalan, jamoada bizda mavjud bo'lgan asosiy ko'rsatkichlar etarli bo'lmasligi mumkin; ular ba'zi bir aniq ko'rsatkichlarni kuzatishi kerak. Grafana'da biz har bir jamoa uchun joy yaratamiz va administrator huquqlarini beramiz. Bundan tashqari, agar jamoaga asboblar paneli kerak bo'lsa, lekin ularning o'zlari buni qanday qilishni bilmasalar/bilmasalar, biz ularga yordam beramiz.
Biz jamoaning qiymat yaratish, ularni chiqarish va rejalashtirish oqimidan tashqarida bo'lganimiz sababli, biz asta-sekin barcha tizimlarning relizlari muammosiz va biz bilan muvofiqlashtirilmasdan har kuni chiqarilishi mumkin degan xulosaga kelyapmiz. Va biz uchun ushbu nashrlarni kuzatish juda muhim, chunki ular ilovaning ishlashiga ta'sir qilishi va biror narsani buzishi mumkin va bu juda muhim. Relizlarni boshqarish uchun biz API orqali ma'lumotlarni oladigan Bamboo-dan foydalanamiz va qaysi relizlar qaysi axborot tizimlarida chiqarilganligini va ularning holatini ko'rishimiz mumkin. Va eng muhimi, qaysi vaqtda. Biz reliz belgilarini asosiy kritik ko'rsatkichlarga qo'yamiz, bu muammo yuzaga kelganda vizual ravishda juda ko'p.
Shunday qilib, biz yangi nashrlar va paydo bo'lgan muammolar o'rtasidagi bog'liqlikni ko'rishimiz mumkin. Asosiy g'oya tizimning barcha qatlamlarda qanday ishlashini tushunish, muammoni tezda lokalizatsiya qilish va uni tezda tuzatishdir. Axir, ko'pincha shunday bo'ladiki, eng ko'p vaqt talab qiladigan narsa muammoni hal qilish emas, balki sababni izlashdir.
Va bu sohada kelajakda biz faollikka e'tibor qaratmoqchimiz. Ideal holda, men yaqinlashib kelayotgan muammo haqida oldindan bilishni xohlayman, lekin uni hal qilishdan ko'ra, uni oldini olishim mumkin bo'lgandan keyin emas. Ba'zida monitoring tizimining noto'g'ri signallari ham inson xatosi, ham ilovadagi o'zgarishlar tufayli yuzaga keladi.Biz buning ustida ishlaymiz, disk raskadrovka qilamiz va monitoring tizimi bilan har qanday manipulyatsiyadan oldin uni biz bilan ishlatadigan foydalanuvchilarni ogohlantirishga harakat qilamiz. , yoki ushbu faoliyatni texnik oynada bajaring.
Shunday qilib, tizim ishga tushirildi va bahor boshidan buyon muvaffaqiyatli ishlamoqda... va juda real foyda ko'rsatmoqda. Albatta, bu uning yakuniy versiyasi emas; biz ko'plab foydali xususiyatlarni taqdim etamiz. Ammo hozirda juda ko'p integratsiya va ilovalar bilan monitoringni avtomatlashtirish haqiqatdan ham muqarrar.
Agar siz katta miqdordagi integratsiyaga ega yirik loyihalarni ham kuzatsangiz, buning uchun qanday kumush o'q topganingizni izohlarda yozing.
Manba: www.habr.com