SRE (Sayt ishonchliligi muhandisligi) veb-loyihalarning mavjudligini ta'minlashga qaratilgan yondashuvdir. U DevOps uchun asos hisoblanadi va DevOps amaliyotlarini qo'llashda muvaffaqiyatga qanday erishish mumkinligi haqida gapiradi. Ushbu maqoladagi tarjima kitoblar Google'dan. Men bu tarjimani oʻzim tayyorladim va monitoring jarayonlarini tushunishda oʻz tajribamga tayandim. Telegram kanalida и Shuningdek, men xizmat darajasi maqsadlari haqidagi o'sha kitobning 4-bobi tarjimasiga havolani nashr qildim.
Mushuk tomonidan tarjima. O'qishdan zavqlaning!
Google SRE jamoalari muvaffaqiyatli monitoring va bildirishnoma tizimlarini yaratish uchun asosiy tamoyillar va eng yaxshi amaliyotlarga ega. Ushbu bobda veb-sahifaga tashrif buyuruvchi qanday muammolarga duch kelishi va veb-sahifalarni ko'rsatishni qiyinlashtiradigan muammolarni qanday hal qilish bo'yicha ko'rsatmalar berilgan.
aniqlash
Monitoring bilan bog'liq mavzularni muhokama qilish uchun yagona lug'at mavjud emas. Hatto Google'da ham quyidagi atamalar tez-tez ishlatilmaydi, lekin biz eng keng tarqalgan talqinlarni sanab o'tamiz.
Monitoring
Tizim haqida real vaqt rejimida miqdoriy ma'lumotlarni to'plash, qayta ishlash, yig'ish va ko'rsatish: so'rovlar soni va so'rovlar turlari, xatolar soni va xatolar turlari, so'rovlarni qayta ishlash vaqti va serverning ish vaqti.
Oq quti monitoringi
Ichki tizim komponentlari, jumladan, jurnallar, Java Virtual Machine profillash koʻrsatkichlari yoki ichki statistikani yaratuvchi HTTP ishlov beruvchi koʻrsatkichlari tomonidan koʻrsatilgan koʻrsatkichlarga asoslangan monitoring.
Qora quti monitoringi
Foydalanuvchi nuqtai nazaridan ilova xatti-harakatlarini sinab ko'rish.
Boshqaruv paneli
Xizmatlarning sog'lig'ining asosiy ko'rsatkichlari haqida umumiy ma'lumot beruvchi interfeys (odatda veb). Boshqaruv panelida filtrlar, ko'rsatilgan ko'rsatkichlarni tanlash imkoniyati va boshqalar bo'lishi mumkin. Interfeys foydalanuvchilar uchun eng muhim bo'lgan ko'rsatkichlarni aniqlash uchun mo'ljallangan. Boshqaruv panelida texnik yordam xodimlari uchun ma'lumotlar ham ko'rsatilishi mumkin: so'rovlar navbati, muhim xatolar ro'yxati va ma'lum bir mas'uliyat sohasi uchun tayinlangan muhandis.
Ogohlantirish (xabarnoma)
Xatolar yoki soʻrovlar navbatining koʻpayishi natijasida yuzaga kelishi mumkin boʻlgan elektron pochta yoki boshqa vositalar orqali shaxs tomonidan qabul qilinishi moʻljallangan bildirishnomalar. Bildirishnomalar quyidagilarga bo'linadi: chiptalar, elektron pochta xabarlari va messenjer xabarlari.
Asosiy sabab
Dasturiy ta'minot nuqsoni yoki tuzatilgandan so'ng, boshqa takrorlanmasligi kerak bo'lgan inson xatosi. Muammoning bir nechta asosiy sabablari bo'lishi mumkin: jarayonni avtomatlashtirishning etarli emasligi, dasturiy ta'minotdagi nuqson, dastur mantig'ining etarli darajada ishlab chiqilmaganligi. Ushbu omillarning har biri asosiy sabab bo'lishi mumkin va ularning har birini yo'q qilish kerak.
Tugun va mashina (tugun va mashina)
Jismoniy serverda, virtual mashinada yoki konteynerda ishlaydigan dasturning bitta nusxasiga murojaat qilish uchun almashtiriladigan atamalar. Bitta mashina bir nechta xizmatlarni qabul qilishi mumkin. Xizmatlar quyidagilar bo'lishi mumkin:
- bir-biriga ulangan: masalan, keshlash serveri va veb-server;
- bitta apparat qismidagi bog'liq bo'lmagan xizmatlar: masalan, kodlar ombori va konfiguratsiya tizimi uchun sehrgar, masalan yoki .
Durang
Dasturiy ta'minot konfiguratsiyasidagi har qanday o'zgarishlar.
Nima uchun monitoring kerak?
Ilovalarni nazorat qilishning bir necha sabablari bor:
Uzoq muddatli tendentsiyalarni tahlil qilish
Ma'lumotlar bazasi qanchalik katta va u qanchalik tez o'sib bormoqda? Kunlik foydalanuvchilar soni qanday o'zgaradi?
Ishlashni taqqoslash
Ajax DB 2.72 bilan solishtirganda Acme Bucket of Bytes 3.14 da soʻrovlar tezroqmi? Qo'shimcha tugun paydo bo'lgandan keyin so'rovlar qanchalik yaxshi keshlangan? Sayt o'tgan haftaga nisbatan sekinroq ishlayaptimi?
Ogohlantirish (bildirishnomalar)
Biror narsa buzilgan va kimdir uni tuzatishi kerak. Yoki tez orada biror narsa buziladi va kimdir uni tez orada tekshirishi kerak.
Boshqaruv panellarini yaratish
Boshqaruv paneli asosiy savollarga javob berishi va ulardan biror narsani o'z ichiga olishi kerak — kechikishlar (kechikish), trafik (trafik), xatolar (xatolar) va yuk hajmi (to'yinganlik).
Retrospektiv tahlilni o'tkazish (disk raskadrovka)
So‘rovni ko‘rib chiqish kechikishi oshdi, lekin bir vaqtning o‘zida yana nima sodir bo‘ldi?
Monitoring tizimlari biznes razvedka tizimlari uchun ma'lumotlar manbai sifatida va xavfsizlik hodisalarini tahlil qilishni osonlashtirish uchun foydalidir. Ushbu kitob SRElar tajribaga ega bo'lgan muhandislik sohalariga qaratilganligi sababli, biz bu erda monitoring usullarini muhokama qilmaymiz.
Monitoring va ogohlantirishlar tizimga qachon buzilganligi yoki ishdan chiqishi haqida xabar berish imkonini beradi. Tizim avtomatik ravishda o'zini tiklay olmasa, biz odamdan ogohlantirishni tahlil qilishini, muammo hali ham faolligini aniqlashini, uni hal qilishini va asosiy sababni aniqlashini xohlaymiz. Agar siz tizim komponentlarini tekshirmasangiz, "nimadir bir oz g'alati tuyulganligi" sababli hech qachon ogohlantirish olmaysiz.
Biror kishini bildirishnomalar bilan yuklash - bu xodimning vaqtidan ancha qimmat foydalanish. Agar xodim ishlayotgan bo'lsa, ogohlantirish ish jarayonini to'xtatadi. Agar xodim uyda bo'lsa, ogohlantirish shaxsiy vaqtni va ehtimol uxlashni to'xtatadi. Ogohlantirishlar juda tez-tez sodir bo'lganda, xodimlar ularni ko'zdan kechirishadi, ularni o'chirib qo'yishadi yoki kiruvchi ogohlantirishlarni e'tiborsiz qoldiradilar. Vaqti-vaqti bilan ular shovqin hodisalari bilan niqoblangan haqiqiy ogohlantirishni e'tiborsiz qoldiradilar. Xizmatdagi uzilishlar uzoq vaqt davom etishi mumkin, chunki shovqin hodisalari muammoni tezda aniqlash va tuzatishga to'sqinlik qiladi. Samarali ogohlantirish tizimlari signal-shovqin nisbati yaxshi.
Monitoring tizimi uchun oqilona taxminlarni belgilash
Murakkab dastur uchun monitoringni o'rnatishning o'zi murakkab muhandislik vazifasidir. Toʻplash, koʻrsatish va ogohlantirish vositalarining muhim infratuzilmasi boʻlsa ham, 10–12 aʼzodan iborat Google SRE jamoasi odatda bir yoki ikki kishini oʻz ichiga oladi, ularning asosiy maqsadi monitoring tizimlarini yaratish va ularga xizmat koʻrsatishdir. Biz monitoring infratuzilmasini birlashtirganimiz va markazlashganimiz sababli vaqt o'tishi bilan bu raqam kamaydi, lekin har bir SRE guruhida odatda faqat monitoringga bag'ishlangan kamida bitta odam bor. Aytishimiz kerakki, monitoring tizimining asboblar panelini ko'rish juda qiziq bo'lsa-da, SRE guruhlari muammolarni kuzatish uchun kimdir ekranga qarashni talab qiladigan vaziyatlardan ehtiyotkorlik bilan qochishadi.
Umuman olganda, Google optimal tahlil vositalariga ega oddiy va tezkor monitoring tizimlariga o'tdi. Biz chegaralarni bashorat qilishga yoki asosiy sababni avtomatik ravishda aniqlashga harakat qiladigan "sehrli" tizimlardan qochamiz. Yakuniy foydalanuvchi so'rovlarida ko'zda tutilmagan tarkibni aniqlaydigan sensorlar yagona qarshi misoldir; Ushbu sensorlar oddiy bo'lib qolar ekan, ular jiddiy anomaliyalarning sabablarini tezda aniqlashlari mumkin. Imkoniyatlarni rejalashtirish yoki trafikni bashorat qilish kabi monitoring ma'lumotlaridan foydalanishning boshqa formatlari ancha murakkab. Juda uzoq vaqt davomida (oylar yoki yillar) past namuna olish tezligida (soat yoki kun) kuzatish uzoq muddatli tendentsiyani aniqlaydi.
Google SRE jamoasi murakkab qaramlik ierarxiyasi bilan aralash muvaffaqiyatga erishdi. Biz kamdan-kam hollarda "ma'lumotlar bazasi sekin ekanligini bilsam, ma'lumotlar bazasi sekin ekanligi haqida ogohlantirish olaman, aks holda sayt sekinligi haqida ogohlantirish olaman" kabi qoidalardan foydalanamiz. Tobelikka asoslangan qoidalar odatda tizimimizning o'zgarmas qismlariga, masalan, ma'lumotlar markaziga foydalanuvchi trafigini filtrlash tizimiga ishora qiladi. Misol uchun, "ma'lumotlar markaziga trafikni filtrlash sozlangan bo'lsa, foydalanuvchi so'rovlarini ko'rib chiqishdagi kechikishlar haqida meni ogohlantirmang" ma'lumotlar markazidan ogohlantirishlar uchun umumiy qoidalardan biridir. Google’dagi kam sonli jamoalar murakkab qaramlik ierarxiyasini qo‘llab-quvvatlaydi, chunki bizning infratuzilmamiz doimiy refaktoring tezligiga ega.
Ushbu bobda tasvirlangan g'oyalarning ba'zilari hali ham dolzarbdir: ayniqsa, doimiy o'zgaruvchan tizimlarda simptomdan asosiy sababga tezroq o'tish imkoniyati doimo mavjud. Shu sababli, ushbu bobda monitoring tizimlarining ba'zi maqsadlari va bu maqsadlarga qanday erishish mumkinligi ko'rsatilgan bo'lsa-da, monitoring tizimlari oddiy va jamoadagi hamma uchun tushunarli bo'lishi muhimdir.
Xuddi shunday, shovqin darajasini past va signal darajasini yuqori darajada ushlab turish uchun ogohlantirilgan aktivlarni kuzatish yondashuvlari juda sodda va ishonchli bo'lishi kerak. Odamlar uchun ogohlantirishlarni keltirib chiqaradigan qoidalar tushunarli bo'lishi va aniq muammoni taqdim etishi kerak.
Semptomlar va sabablar
Sizning monitoring tizimingiz ikkita savolga javob berishi kerak: "nima buzildi" va "nima uchun buzildi".
"Nima buzildi" simptom haqida gapiradi va "nima uchun buzildi" sabab haqida gapiradi. Quyidagi jadvalda bunday ulanishlarga misollar keltirilgan.
Semptom
Sabab
HTTP xatosi 500 yoki 404 olinishi
Ma'lumotlar bazasi serverlari ulanishlarni rad etadi
Sekin server javoblari
Yuqori protsessordan foydalanish yoki shikastlangan Ethernet kabeli
Antarktidadagi foydalanuvchilar mushuklarning GIF-fayllarini olishmayapti
Sizning CDN olimlar va mushuklardan nafratlanadi, shuning uchun ba'zi IP manzillar qora ro'yxatga kiritildi
Shaxsiy tarkib hamma joyda mavjud bo'ldi
Yangi dasturiy ta'minotning chiqarilishi xavfsizlik devorini barcha ACL'larni unutib qo'ydi va barchaga kirishga ruxsat berdi
"Nima" va "nima uchun" maksimal signal va minimal shovqin bilan yaxshi monitoring tizimini yaratish uchun eng muhim qurilish bloklari hisoblanadi.
Qora quti va oq quti
Biz keng qamrovli oq quti monitoringini muhim ko'rsatkichlar uchun oddiy qora quti monitoringi bilan birlashtiramiz. Qora qutini Oq qutiga solishtirishning eng oson yo'li shundaki, Qora quti simptomlarga yo'naltirilgan va proaktiv monitoring o'rniga reaktivdir: "tizim hozir to'g'ri ishlamayapti". Oq quti tizimlarning ichki tekshirish imkoniyatlariga bog'liq: hodisalar jurnallari yoki veb-serverlar. Shunday qilib, White-box yaqinlashib kelayotgan muammolarni, so'rovni qayta yuborish kabi ko'rinadigan nosozliklarni va hokazolarni aniqlashga imkon beradi.
E'tibor bering, ko'p qatlamli tizimda bitta muhandisning mas'uliyat sohasidagi simptom boshqa muhandisning mas'uliyat sohasidagi alomatidir. Masalan, ma'lumotlar bazasining ishlashi pasaygan. Ma'lumotlar bazasini sekin o'qish ularni aniqlaydigan SRE ma'lumotlar bazasining alomatidir. Biroq, sekin veb-saytni kuzatuvchi front-end SRE uchun bir xil sekin o'qiladigan ma'lumotlar bazasining sababi sekin ma'lumotlar bazasidir. Shu sababli, oq quti monitoringi qanchalik keng bo'lishiga qarab, ba'zan simptomlarga va ba'zan sabablarga yo'naltirilgan.
Nosozliklarni tuzatish uchun telemetriyani yig'ishda oq quti monitoringi talab qilinadi. Agar veb-serverlar ma'lumotlar bazasi so'rovlariga sekin javob bersa, veb-server ma'lumotlar bazasi bilan qanchalik tez aloqa qilishini va qanchalik tez javob berishini bilishingiz kerak. Aks holda, sekin ma'lumotlar bazasi serveri va veb-server va ma'lumotlar bazasi o'rtasidagi tarmoq muammosini farqlay olmaysiz.
Qora quti monitoringi ogohlantirishlarni yuborishda asosiy afzalliklarga ega: muammo allaqachon haqiqiy alomatlarga olib kelganda, siz qabul qiluvchiga bildirishnomani ishga tushirasiz. Boshqa tomondan, hali paydo bo'lmagan, ammo yaqinlashib kelayotgan Black-box muammosi uchun monitoring foydasiz.
To'rtta oltin signal
To'rtta oltin kuzatuv signallari - kechikish, trafik, xatolar va to'yinganlik. Agar siz faqat to'rtta foydalanuvchi tizimi ko'rsatkichini o'lchashingiz mumkin bo'lsa, ushbu to'rttasiga e'tibor qarating.
Kechiktirish
So'rovni ko'rib chiqish uchun zarur bo'lgan vaqt. Muvaffaqiyatli va muvaffaqiyatsiz so'rovlarning kechikishini farqlash muhimdir. Misol uchun, ma'lumotlar bazasiga yoki boshqa serverga ulanishning yo'qolishi natijasida yuzaga kelgan HTTP 500 xatosi juda tez diagnostika qilinishi mumkin, ammo HTTP 500 xatosi muvaffaqiyatsiz so'rovni ko'rsatishi mumkin. 500 xatoning umumiy kechikishga ta'sirini aniqlash noto'g'ri xulosalarga olib kelishi mumkin. Boshqa tomondan, sekin xato hatto tez xatodir! Shuning uchun, xatolarni filtrlashdan ko'ra, xatolarning kechikishini kuzatish muhimdir.
yo'l harakati
Tizimingizga bo'lgan so'rovlar soni yuqori darajadagi tizim ko'rsatkichlarida o'lchanadi. Veb-xizmat uchun bu o'lchov odatda so'rovlarning tabiatiga (masalan, statik yoki dinamik kontent) bo'lingan soniyada HTTP so'rovlari sonini ifodalaydi. Ovozli oqim tizimi uchun bu o'lchov tarmoqning kirish/chiqarish tezligiga yoki bir vaqtning o'zida seanslar soniga e'tibor qaratishi mumkin. Kalit-qiymatni saqlash tizimi uchun bu o'lchov soniyada tranzaktsiyalar yoki qidiruv natijalari bo'lishi mumkin.
Xatolar
Bu aniq (masalan, HTTP 500), yashirin (masalan, HTTP 200, lekin notoʻgʻri kontent bilan birlashtirilgan) yoki siyosat (masalan, “Agar siz bir soniyada javob olgan boʻlsangiz, har qanday soniya xato”) boʻlgan muvaffaqiyatsiz soʻrovlar tezligi. Agar HTTP javob kodlari barcha nosozlik holatlarini ifodalash uchun etarli bo'lmasa, qisman nosozlikni aniqlash uchun ikkilamchi (ichki) protokollar talab qilinishi mumkin. Bunday noto'g'ri so'rovlarning barchasini kuzatish ma'lumotga ega bo'lmasligi mumkin, ammo oxirigacha tizim testlari siz noto'g'ri kontentga ishlov berayotganingizni aniqlashga yordam beradi.
To'yinganlik
Ko'rsatkich sizning xizmatingiz qanchalik intensiv foydalanilganligini ko'rsatadi. Bu eng ko'p cheklangan resurslarni aniqlaydigan tizim monitoringi o'lchovidir (masalan, xotira cheklangan tizimda, xotirani ko'rsatadi, kiritish/chiqarish bilan cheklangan tizimda, kiritish/chiqarish sonini ko'rsatadi). E'tibor bering, ko'plab tizimlar 100% foydalanishga etmasdan ishlashni pasaytiradi, shuning uchun foydalanish maqsadiga ega bo'lish muhimdir.
Murakkab tizimlarda toʻyinganlik yuqori darajadagi yuk oʻlchovlari bilan toʻldirilishi mumkin: sizning xizmatingiz ikki tomonlama trafikni toʻgʻri bajara oladimi, atigi 10% koʻproq trafikni boshqara oladimi yoki hozirgidan kamroq trafikni boshqara oladimi? So'rovning murakkabligini o'zgartiruvchi parametrlarga ega bo'lmagan (masalan, "Menga hech narsa berma" yoki "Menga yagona monotonik butun son kerak") kamdan-kam hollarda konfiguratsiyani o'zgartiradigan oddiy xizmatlar uchun statik yuk sinov qiymati etarli bo'lishi mumkin. Biroq, oldingi paragrafda muhokama qilinganidek, aksariyat xizmatlar ma'lum yuqori chegaraga ega bo'lgan protsessordan foydalanish yoki tarmoq o'tkazish qobiliyati kabi bilvosita signallardan foydalanishi kerak. Kechikishning ortishi ko'pincha to'yinganlikning etakchi ko'rsatkichidir. Kichkina oynada 99 foizli javob vaqtini o'lchash (masalan, bir daqiqa) to'yinganlikning juda erta signalini berishi mumkin.
Va nihoyat, to'yinganlik yaqinlashib kelayotgan to'yinganlik haqidagi bashoratlar bilan ham bog'liq, masalan: "Ma'lumotlar bazasi qattiq diskingizni 4 soat ichida to'ldiradi."
Agar siz barcha to'rtta oltin signalni o'lchasangiz va ko'rsatkichlardan biri bilan bog'liq muammo (yoki to'yinganlik holatida, yaqin muammo) yuzaga kelganda, siz odamni ogohlantirsangiz, sizning xizmatingiz monitoring bilan ko'proq yoki kamroq qamrab olinadi.
"Quyruq" (yoki asboblar va ishlash) haqida tashvishlanish
Monitoring tizimini noldan yaratishda o'rtacha qiymatlarga asoslangan tizimni ishlab chiqish vasvasasi mavjud: o'rtacha kechikish, tugunlarning o'rtacha protsessor foydalanish yoki o'rtacha ma'lumotlar bazasi to'liqligi. Oxirgi ikkita misolning xavfi aniq: protsessorlar va ma'lumotlar bazalari juda oldindan aytib bo'lmaydigan tarzda yo'q qilinadi. Xuddi shu narsa kechikish uchun ham amal qiladi. Agar siz sekundiga 100 ta soʻrov boʻlgan oʻrtacha kechikish vaqti 1000 ms boʻlgan veb-xizmatni ishga tushirsangiz, soʻrovlarning 1 foizi 5 soniya vaqt olishi mumkin. Agar foydalanuvchilar bir nechta bunday veb-xizmatlarga bog'liq bo'lsa, bitta backendning 99-protsentili osongina frontendning median javob vaqtiga aylanishi mumkin.
Soʻrovlarning sekin oʻrtacha va juda sekin dumini farqlashning eng oddiy usuli bu haqiqiy kechikishlar emas, balki statistik maʼlumotlarda ifodalangan soʻrovlar oʻlchovlarini yigʻishdir (koʻrsatish uchun yaxshi vosita bu gistogrammalardir): xizmat qancha soʻrovga xizmat koʻrsatgan va 0 ms gacha boʻlgan. va 10 ms, 10 ms va 30 ms, 30 ms va 100 ms, 100 ms va 300 ms va hokazo. Gistogramma chegaralarini taxminan eksponent (taxminan 3 faktor bilan) kengaytirish ko'pincha taqsimotni tasavvur qilishning oddiy usuli hisoblanadi. so'rovlar.
O'lchovlar uchun tegishli tafsilotlar darajasini tanlash
Tizimning turli elementlari turli darajadagi tafsilotlarda o'lchanishi kerak. Masalan:
- Muayyan vaqt davomida protsessordan foydalanishni kuzatish yuqori kechikishlarga olib keladigan uzoq muddatli keskinliklarni ko'rsatmaydi.
- Boshqa tomondan, yiliga 9 soatdan ko'p bo'lmagan ish vaqti (yillik ish vaqti 99,9%) uchun veb-xizmat uchun HTTP 200 javobini daqiqada bir yoki ikki martadan ko'proq tekshirish keraksiz tez-tez bo'lishi mumkin.
- Xuddi shunday, qattiq disk maydonining 99,9% mavjudligini har 1-2 daqiqada bir martadan ko'proq tekshirish kerak emas.
O'lchovlaringizning nozikligini qanday tuzayotganingizga e'tibor bering. CPU yukini soniyada bir marta yig'ish qiziqarli ma'lumotlarni taqdim etishi mumkin, ammo bunday tez-tez o'lchovlarni yig'ish, saqlash va tahlil qilish juda qimmatga tushishi mumkin. Agar sizning monitoring maqsadingiz yuqori aniqlikni talab qilsa va yuqori sezgirlikni talab qilmasa, siz serverda o'lchovlar to'plamini o'rnatish va keyin ushbu ko'rsatkichlarni yig'ish va jamlash uchun tashqi tizimni o'rnatish orqali ushbu xarajatlarni kamaytirishingiz mumkin. Bajara olasizmi:
- Har soniyada CPU yukini o'lchang.
- Tafsilotlarni 5% gacha kamaytiring.
- Ko'rsatkichlarni har daqiqada jamlang.
Ushbu strategiya sizga yuqori tahlil va saqlash xarajatlarini talab qilmasdan, yuqori aniqlikda ma'lumotlarni to'plash imkonini beradi.
Iloji boricha sodda, lekin oddiyroq emas
Turli xil talablarning bir-birining ustiga qo'yilishi juda murakkab monitoring tizimiga olib kelishi mumkin. Masalan, tizimingizda quyidagi murakkab elementlar bo'lishi mumkin:
- Har xil ko'rsatkichlarning barcha turlari uchun turli foizlarda, so'rovni qayta ishlash kechikishi uchun turli chegaralarga muvofiq ogohlantirishlar.
- Mumkin bo'lgan sabablarni aniqlash va aniqlash uchun qo'shimcha kod yozish.
- Muammolarning mumkin bo'lgan sabablarining har biri uchun tegishli boshqaruv paneli yarating.
Mumkin bo'lgan asoratlarning manbalari hech qachon tugamaydi. Barcha dasturiy ta'minot tizimlari singari, monitoring ham shunchalik murakkab bo'lib qolishi mumkinki, uni o'zgartirish va saqlash qiyin bo'ladi.
Shuning uchun, monitoring tizimini iloji boricha soddalashtirish uchun loyihalashtiring. Nimani kuzatishni tanlashda quyidagilarni yodda tuting:
- Haqiqiy hodisalarni tez-tez ushlaydigan qoidalar imkon qadar sodda, bashorat qilinadigan va ishonchli bo'lishi kerak.
- Kamdan-kam bajariladigan (masalan, ba'zi SRE guruhlari uchun har chorakda bir martadan kamroq) ma'lumotlarni yig'ish, yig'ish va ogohlantirish uchun konfiguratsiyani olib tashlash kerak.
- To‘plangan, lekin oldindan ko‘rish asboblar panelida ko‘rsatilmagan yoki har qanday ogohlantirish tomonidan ishlatilmaydigan ko‘rsatkichlar o‘chirishga nomzod hisoblanadi.
Google'da asosiy o'lchovlarni yig'ish va yig'ish, ogohlantirishlar va asboblar paneli bilan birgalikda nisbatan mustaqil tizim sifatida yaxshi ishlaydi (Google monitoring tizimi aslida bir nechta quyi tizimlarga bo'lingan, lekin odamlar odatda ushbu quyi tizimlarning barcha jihatlaridan xabardor). Monitoringni murakkab tizimlarni tekshirishning boshqa usullari bilan birlashtirish jozibador bo'lishi mumkin: tizimning batafsil profilini aniqlash, jarayonni tuzatish, istisnolar yoki nosozliklar haqida tafsilotlarni kuzatish, yukni sinovdan o'tkazish, jurnallarni yig'ish va tahlil qilish yoki transport tekshiruvi. Bu narsalarning aksariyati asosiy monitoring bilan umumiy jihatlarga ega bo'lsa-da, ularni aralashtirish juda ko'p natijalarga olib keladi va murakkab va zaif tizimni yaratadi. Dasturiy ta'minotni ishlab chiqishning boshqa ko'plab jihatlarida bo'lgani kabi, aniq, sodda, bo'shashmasdan bog'langan integratsiya nuqtalari bilan turli tizimlarni qo'llab-quvvatlash eng yaxshi strategiyadir (masalan, yig'ilgan ma'lumotlarni uzoq vaqt davomida izchil bo'lib qolishi mumkin bo'lgan formatda olish uchun veb-API-dan foydalanish) ).
Prinsiplarni bir-biriga bog'lash
Ushbu bobda muhokama qilingan tamoyillar Google SRE guruhlari tomonidan ma'qullangan va amal qiladigan monitoring va ogohlantirish falsafasiga birlashtirilishi mumkin. Ushbu monitoring falsafasiga rioya qilish maqsadga muvofiq, ogohlantirish metodologiyangizni yaratish yoki qayta ko'rib chiqish uchun yaxshi boshlanish nuqtasi bo'lib, tashkilotingiz hajmi yoki xizmat yoki tizimning murakkabligidan qat'i nazar, operatsion funksiyangiz haqida to'g'ri savollarni berishga yordam beradi.
Monitoring va ogohlantirish qoidalarini yaratishda quyidagi savollarni berish noto'g'ri ijobiy va keraksiz ogohlantirishlardan qochishingizga yordam beradi:
- Ushbu qoida tizimning shoshilinch, harakatga chaqiruvchi va foydalanuvchiga muqarrar ravishda ta'sir qiladigan boshqa aniqlanmaydigan holatini aniqlaydimi?
- Men bu ogohlantirishni befarq deb bilsam bo'ladimi? Qachon va nima uchun bu ogohlantirishni e'tiborsiz qoldira olaman va bu stsenariydan qanday qochishim mumkin?
- Ushbu ogohlantirish foydalanuvchilarga salbiy ta'sir ko'rsatayotganini anglatadimi? Foydalanuvchilarga salbiy ta'sir ko'rsatmaydigan holatlar mavjudmi, masalan, trafikni filtrlash yoki ogohlantirishlar filtrlanishi kerak bo'lgan test tizimlaridan foydalanishda?
- Ushbu ogohlantirishga javoban chora ko'rishim mumkinmi? Bu choralar shoshilinchmi yoki ertalabgacha kutish mumkinmi? Harakat xavfsiz tarzda avtomatlashtirilishi mumkinmi? Bu harakat uzoq muddatli yechim bo'ladimi yoki qisqa muddatli vaqtinchalik hal bo'ladimi?
- Ba'zi odamlar bu muammo bo'yicha bir nechta ogohlantirishlarni olishmoqda, shuning uchun ogohlantirishlar sonini kamaytirishning yo'li bormi?
Bu savollar ogohlantirishlar va ogohlantirish tizimlarining asosiy falsafasini aks ettiradi:
- Har safar ogohlantirish kelganda, men darhol javob berishim kerak. Men charchaganimdan oldin kuniga bir necha marta shoshilinch reaksiyaga kirishishim mumkin.
- Har bir ogohlantirish tegishli bo'lishi kerak.
- Ogohlantirishga har bir javob inson aralashuvini talab qilishi kerak. Agar bildirishnoma avtomatik ravishda qayta ishlanishi mumkin bo'lsa, u kelmasligi kerak.
- Ogohlantirishlar avval mavjud bo'lmagan yangi muammo yoki hodisa haqida bo'lishi kerak.
Ushbu yondashuv muayyan farqlarni xiralashtiradi: agar ogohlantirish oldingi to'rtta shartga javob bersa, ogohlantirish White-box yoki Black-Box monitoring tizimidan yuborilganmi, muhim emas. Ushbu yondashuv, shuningdek, ma'lum farqlarni kuchaytiradi: sabablarga qaraganda, simptomlarni aniqlashga ko'proq kuch sarflash yaxshiroqdir; sabablari haqida gap ketganda, faqat muqarrar sabablar haqida tashvishlanishingiz kerak.
Uzoq muddatli monitoring
Bugungi mahsuldorlik muhitida monitoring tizimlari o'zgaruvchan dasturiy ta'minot arxitekturasi, ish yuki xususiyatlari va ishlash maqsadlari bilan doimiy rivojlanayotgan ishlab chiqarish tizimini kuzatib boradi. Hozirda avtomatlashtirish qiyin bo'lgan ogohlantirishlar odatiy holga aylanishi mumkin, ehtimol hatto murojaat qilishga arziydi. Shu nuqtada, kimdir muammoning asosiy sabablarini topishi va yo'q qilishi kerak; agar bunday hal qilishning iloji bo'lmasa, ogohlantirishga javob to'liq avtomatlashtirishni talab qiladi.
Monitoring qarorlari uzoq muddatli maqsadlarni hisobga olgan holda qabul qilinishi muhimdir. Bugungi kunda ishlaydigan har bir ogohlantirish odamni ertaga tizimni takomillashtirishdan chalg'itadi, shuning uchun uzoq muddatda monitoring tizimini takomillashtirish uchun zarur bo'lgan vaqt uchun samarali tizimning mavjudligi yoki ishlashi ko'pincha kamayadi. Ushbu hodisani tushuntirish uchun ikkita misolni ko'rib chiqaylik.
Bigtable SRE: Haddan tashqari ogohlantirish haqidagi ertak
Google ichki infratuzilmasi odatda taqdim etiladi va xizmat darajasiga (SLO) nisbatan o'lchanadi. Ko'p yillar oldin Bigtable xizmati SLO jonli mijozni simulyatsiya qiluvchi sintetik tranzaksiyaning o'rtacha ko'rsatkichlariga asoslangan edi. Bigtable’dagi muammolar va saqlash stekining past darajalari tufayli o‘rtacha unumdorlikka “katta” dum sabab bo‘ldi: so‘rovlarning eng yomon 5% ko‘pincha qolganlariga qaraganda ancha sekinroq edi.
SLO chegarasiga yaqinlashganda elektron pochta xabarnomalari yuborildi va SLO o'tib ketganda messenjer ogohlantirishlari yuborildi. Ikkala turdagi ogohlantirishlar juda tez-tez yuborilib, qabul qilib bo'lmaydigan darajada muhandislik vaqtini sarfladi: jamoa haqiqatda tegishli bo'lgan bir nechtasini topish uchun ogohlantirishlarni saralash uchun katta vaqt sarfladi. Biz ko'pincha foydalanuvchilarga ta'sir qiladigan muammoni o'tkazib yubordik, chunki ba'zi ogohlantirishlar aynan shu muammoga tegishli edi. Ko'pgina ogohlantirishlar infratuzilmadagi tushunarli muammolar tufayli shoshilinch emas edi va standart usulda qayta ishlangan yoki umuman qayta ishlanmagan.
Vaziyatni to'g'irlash uchun jamoa uch yo'nalishli yondashuvni qo'lladi: Bigtable ish faoliyatini yaxshilash bo'yicha ko'p mehnat qilar ekanmiz, biz vaqtinchalik o'z SLO maqsadimizni so'rovlarga javob kechikishi uchun 75-protsentil qilib qo'ydik. Shuningdek, biz elektron pochta xabarlarini o'chirib qo'ydik, chunki ularning soni juda ko'p edi, ularni tashxislash uchun vaqt sarflashning iloji yo'q edi.
Ushbu strategiya bizga nafas olish xonasiga doimiy ravishda taktik muammolarni hal qilish o'rniga Bigtable va saqlash stackining pastki qatlamlarida uzoq muddatli muammolarni hal qilishni boshlashga imkon berdi. Muhandislar har doim ogohlantirishlar bilan bombardimon qilinmasdan ishni bajarishlari mumkin edi. Oxir oqibat, ogohlantirishni qayta ishlashni vaqtincha kechiktirish bizga xizmat sifatini yaxshilash imkonini berdi.
Gmail: bashorat qilinadigan, algoritmik inson javoblari
Yaratilishida Gmail o'zgartirilgan Workqueue jarayonini boshqarish tizimiga asoslangan bo'lib, u qidiruv indeksining jarayon bo'laklarini to'plash uchun mo'ljallangan edi. Ish navbati uzoq muddatli jarayonlarga moslashtirildi va keyinchalik Gmail’ga qo‘llanildi, ammo noaniq rejalashtiruvchi kodidagi ba’zi xatolarni tuzatish juda qiyin bo‘ldi.
O'sha paytda Gmail monitoringi shunday tuzilganki, Workqueue yordamida individual topshiriqlar bekor qilinganda ogohlantirishlar paydo bo'ladi. Bunday yondashuv ideal emas edi, chunki o'sha paytda ham Gmail minglab vazifalarni bajargan, ularning har biri bizning foydalanuvchilarning bir foiziga taqdim etilgan. Biz Gmail foydalanuvchilarini yaxshi foydalanuvchi tajribasi bilan ta'minlashdan juda xavotirda edik, ammo ko'plab ogohlantirishlarni ko'rib chiqish imkonsiz edi.
Ushbu muammoni hal qilish uchun Gmail SRE foydalanuvchilarga ta'sirni kamaytirish uchun rejalashtiruvchini iloji boricha tuzatishga yordam beradigan vositani yaratdi. Jamoa muammoni aniqlashdan to tuzatishga qadar uzoq muddatli yechim topilgunga qadar butun tsiklni oddiygina avtomatlashtirish yoki yo'qligini muhokama qilishdi, ammo ba'zilari bunday yechim muammoni haqiqatda hal qilishni kechiktirishidan xavotirda edilar.
Bu keskinlik jamoada keng tarqalgan bo'lib, ko'pincha o'z-o'zini tarbiyalashga bo'lgan ishonchning etishmasligini aks ettiradi: ba'zi jamoa a'zolari to'g'ri tuzatish uchun vaqt ajratishni xohlashsa, boshqalari yakuniy tuzatish unutilib, vaqtinchalik tuzatish abadiy davom etishidan xavotirda. Bu masala e'tiborga loyiqdir, chunki vaziyatni doimiy qilish o'rniga muammolarni vaqtincha hal qilish juda oson. Menejerlar va texnik xodimlar uzoq muddatli tuzatishlarni amalga oshirishda, dastlabki "og'riq" pasayganidan keyin ham potentsial uzoq muddatli tuzatishlarni qo'llab-quvvatlash va ustuvorlik qilishda asosiy rol o'ynaydi.
Muntazam, takrorlanuvchi ogohlantirishlar va algoritmik javoblar qizil bayroq bo'lishi kerak. Sizning jamoangiz ushbu ogohlantirishlarni avtomatlashtirishni istamasligi jamoaning algoritmlarga ishonishiga ishonchi yo'qligini anglatadi. Bu hal qilinishi kerak bo'lgan jiddiy muammo.
Uzoq muddat
Umumiy mavzu Bigtable va Gmail misollarini bog'laydi: qisqa muddatli va uzoq muddatli mavjudlik o'rtasidagi raqobat. Ko'pincha kuchli harakat mo'rt tizimga yuqori darajadagi mavjudlikka erishishga yordam beradi, ammo bu yo'l odatda qisqa muddatli bo'lib, jamoaning charchashi va o'sha qahramon jamoaning oz sonli a'zolariga bog'liq bo'ladi.
Nazorat qilinadigan, qisqa muddatli mavjudlikning qisqarishi ko'pincha og'riqli, ammo tizimning uzoq muddatli barqarorligi uchun strategik ahamiyatga ega. Har bir ogohlantirishni alohida ko'rib chiqmaslik kerak, lekin ogohlantirish hajmining umumiy darajasi sog'lom, to'g'ri foydalanish mumkin bo'lgan jonli jamoa va qulay prognozga ega tizimga olib keladimi yoki yo'qligini hisobga olish kerak. Biz har choraklik hisobotlarda ogohlantirish chastotasi statistikasini (odatda bir smenada sodir bo'lgan hodisalar sifatida ifodalanadi, bunda hodisa bir nechta bog'liq hodisalardan iborat bo'lishi mumkin) tahlil qilamiz, bu esa qaror qabul qiluvchilarga ogohlantirish tizimining yuklanishi va jamoaning umumiy salomatligi haqida doimiy ko'rinishga ega bo'lish imkonini beradi.
xulosa
Sog'lom monitoring va ogohlantirish yo'li oddiy va tushunarli. U ogohlantirishlarni keltirib chiqaradigan muammoning alomatlariga e'tibor qaratadi va sababni kuzatish muammolarni bartaraf etishda yordam beradi. Ma'lumotlar bazasi yuklanishi va ishlashini nazorat qilish to'g'ridan-to'g'ri ma'lumotlar bazasining o'zida amalga oshirilishi kerak bo'lsa-da, siz nazorat qiladigan stekda qanchalik baland bo'lsangiz, simptomlarni kuzatish osonroq bo'ladi. Elektron pochta xabarnomalarining foydaliligi juda cheklangan va ular osongina shovqinga aylanadi; Buning o'rniga, siz elektron pochta ogohlantirishlarini ishga tushiradigan barcha joriy muammolarni kuzatadigan asboblar panelidan foydalanishingiz kerak. Boshqaruv paneli tarixiy korrelyatsiyalarni tahlil qilish uchun voqealar jurnali bilan ham bog'lanishi mumkin.
Uzoq muddatda simptomlar va yaqinlashib kelayotgan real muammolar haqida ogohlantirishlarning muvaffaqiyatli aylanishiga erishish, monitoring tezkor tashxisni qo'llab-quvvatlashini ta'minlash uchun maqsadlarni moslashtirish kerak.
Tarjimani oxirigacha o'qiganingiz uchun rahmat. Monitoring haqida mening telegram kanalimga obuna bo'ling и .
Manba: www.habr.com