Bugungi kunda, monolit koddan tashqari, bizning loyihamiz o'nlab mikroservislarni o'z ichiga oladi. Ularning har biri nazoratni talab qiladi. DevOps muhandislari yordamida bunday miqyosda buni qilish muammoli. Biz ishlab chiquvchilar uchun xizmat sifatida ishlaydigan monitoring tizimini ishlab chiqdik. Ular mustaqil ravishda monitoring tizimiga o'lchovlarni yozishlari, ulardan foydalanishlari, ular asosida asboblar panelini qurishlari va chegara qiymatlariga erishilganda ishga tushiriladigan ogohlantirishlarni qo'shishlari mumkin. DevOps muhandislari uchun faqat infratuzilma va hujjatlar.
Bu post bizning suhbatimning stenogrammasi RIT++ da. Ko'pchilik bizdan hisobotlarning matnli versiyalarini u yerdan qilishimizni so'rashdi. Agar siz konferentsiyada bo'lgan bo'lsangiz yoki videoni tomosha qilgan bo'lsangiz, yangi hech narsa topa olmaysiz. Va hamma - mushukka xush kelibsiz. Men sizga qanday qilib bunday tizimga kelganimizni, u qanday ishlashini va uni qanday yangilashni rejalashtirayotganimizni aytib beraman.
O'tmish: sxemalar va rejalar
Hozirgi monitoring tizimiga qanday etib keldik? Bu savolga javob berish uchun siz 2015 yilga borishingiz kerak. O'shanda u shunday ko'rinardi:
Bizda kuzatuv uchun mas'ul bo'lgan 24 ta tugun bor edi. Turli xil tojlar, skriptlar, demonlarning butun to'plami mavjud bo'lib, ular qandaydir tarzda nimanidir kuzatadi, xabarlar yuboradi va funktsiyalarni bajaradi. Biz qanchalik uzoqqa borsak, bunday tizimning hayotiyligi shunchalik past bo'ladi deb o'ylagandik. Uni ishlab chiqishning ma'nosi yo'q: bu juda og'ir.
Biz saqlab qoladigan va rivojlantiradigan va tark etadigan monitoring elementlarini tanlashga qaror qildik. Ulardan 19 tasi bor edi. Faqat grafitlar, agregatorlar va asboblar paneli sifatida Grafana qolgan. Ammo yangi tizim qanday ko'rinishga ega bo'ladi? Mana bunday:
Bizda o'lchovlarni saqlash joyi bor: bu grafitlar, ular tezkor SSD drayverlarga asoslanadi, bu o'lchovlar uchun ma'lum agregatorlar. Keyingi - asboblar panelini ko'rsatish uchun Grafana va ogohlantirish uchun Moira. Shuningdek, biz anomaliyalarni qidirish tizimini ishlab chiqmoqchi edik.
Standart: Monitoring 2.0
Rejalar 2015-yilda shunday ko‘rinish oldi. Lekin biz nafaqat infratuzilma va xizmatni, balki buning uchun hujjatlarni ham tayyorlashimiz kerak edi. Biz o'zimiz uchun korporativ standartni ishlab chiqdik, biz uni monitoring 2.0 deb ataymiz. Tizimga qanday talablar qo'yildi?
- doimiy mavjudligi;
- ko'rsatkichlarni saqlash oralig'i = 10 soniya;
- ko'rsatkichlar va asboblar panelini tizimli saqlash;
- SLA > 99,99%
- UDP (!) orqali voqea ko'rsatkichlarini to'plash.
Bizga UDP kerak edi, chunki bizda ko'rsatkichlarni yaratadigan katta trafik oqimi va hodisalar mavjud. Agar ularning barchasini birdaniga grafitga yozsangiz, xotira qulab tushadi. Biz barcha ko'rsatkichlar uchun birinchi darajali prefikslarni ham tanladik.
Prefikslarning har biri o'ziga xos xususiyatga ega. Serverlar, tarmoqlar, konteynerlar, resurslar, ilovalar va boshqalar uchun ko'rsatkichlar mavjud. Aniq, qat'iy, terilgan filtrlash amalga oshirildi, bu erda biz birinchi darajali ko'rsatkichlarni qabul qilamiz va qolganlarini shunchaki tashlab qo'yamiz. Biz ushbu tizimni 2015 yilda shunday rejalashtirgan edik. Hozir nima bor?
Mavjud: monitoring komponentlarining o'zaro ta'siri diagrammasi
Avvalo, biz ilovalarni kuzatamiz: bizning PHP kodimiz, ilovalarimiz va mikroservislarimiz - qisqasi, ishlab chiquvchilarimiz yozgan hamma narsa. Barcha ilovalar ko'rsatkichlarni UDP orqali Brubeck agregatoriga yuboradi (statsd, C tilida qayta yozilgan). Bu sintetik sinovlarda eng tezkor bo'lib chiqdi. Va u allaqachon yig'ilgan ko'rsatkichlarni TCP orqali Graphite-ga yuboradi.
U taymerlar deb ataladigan ko'rsatkichlarga ega. Bu juda qulay narsa. Misol uchun, har bir foydalanuvchining xizmatga ulanishi uchun siz Brubekka javob vaqti ko'rsatilgan ko'rsatkichni yuborasiz. Bir million javob keldi, ammo agregator faqat 10 ko'rsatkichni qaytardi. Sizda kelganlar soni, maksimal, minimal va o'rtacha javob vaqti, mediana va 4 foiz bor. Keyin ma'lumotlar Graphite-ga o'tkaziladi va biz hammasini jonli ko'ramiz.
Shuningdek, bizda apparat, dasturiy ta'minot, tizim ko'rsatkichlari va eski Munin monitoring tizimi (u biz uchun 2015 yilgacha ishlagan) bo'yicha ko'rsatkichlar uchun jamlanma mavjud. Biz bularning barchasini C daemon CollectD orqali to'playmiz (uning ichiga turli xil plaginlar o'rnatilgan, u o'rnatilgan xost tizimining barcha resurslarini so'rashi mumkin, faqat konfiguratsiyada ma'lumotlarni qaerga yozishni ko'rsating) va u orqali Graphite-ga ma'lumotlarni yozing. Bundan tashqari, u python plaginlari va qobiq skriptlarini qo'llab-quvvatlaydi, shuning uchun siz o'zingizning shaxsiy echimlaringizni yozishingiz mumkin: CollectD bu ma'lumotlarni mahalliy yoki masofaviy xostdan (Curlni nazarda tutgan holda) yig'adi va Graphite-ga yuboradi.
Keyin biz to'plagan barcha ko'rsatkichlarni Carbon-c-relay-ga yuboramiz. Bu Graphite-dan Carbon Relay yechimi, C-da o'zgartirilgan. Bu biz agregatorlarimizdan yuboradigan barcha ko'rsatkichlarni to'playdigan va ularni tugunlarga yo'naltiradigan marshrutizator. Shuningdek, marshrutlash bosqichida u ko'rsatkichlarning haqiqiyligini tekshiradi. Birinchidan, ular men ilgari ko'rsatgan prefiks sxemasiga mos kelishi kerak, ikkinchidan, ular grafit uchun amal qiladi. Aks holda ular tushib ketadi.
Keyin Carbon-c-relay ko'rsatkichlarni Grafit klasteriga yuboradi. Biz ko'rsatkichlarning asosiy xotirasi sifatida Go'da qayta yozilgan Carbon-keshdan foydalanamiz. Go-carbon, ko'p ish zarralari tufayli, Carbon-keshdan ancha ustundir. U ma'lumotlarni oladi va shivirlash paketi (standart, python tilida yozilgan) yordamida disklarga yozadi. Saqlashlarimizdagi ma'lumotlarni o'qish uchun biz Graphite API-dan foydalanamiz. Bu standart Graphite WEB-dan ancha tezroq. Keyinchalik ma'lumotlar bilan nima sodir bo'ladi?
Ular Grafanaga boradilar. Biz grafit klasterlarimizdan maʼlumotlarning asosiy manbai sifatida foydalanamiz, shuningdek, Grafana oʻlchovlarni koʻrsatish va asboblar panelini yaratish uchun veb-interfeys sifatida mavjud. Har bir xizmat uchun ishlab chiquvchilar o'zlarining boshqaruv panelini yaratadilar. Keyin ular o'zlarining ilovalaridan yozgan ko'rsatkichlarini ko'rsatadigan grafiklarni tuzadilar. Grafanadan tashqari bizda SLAM ham mavjud. Bu grafit ma'lumotlari asosida SLAni hisoblaydigan piton iblis. Aytganimdek, bizda bir necha o'nlab mikroservislar mavjud, ularning har biri o'z talablariga ega. SLAM-dan foydalanib, biz hujjatlarga o'tamiz va uni Graphite-dagi narsalar bilan taqqoslaymiz va talablar bizning xizmatlarning mavjudligiga qanchalik mos kelishini taqqoslaymiz.
Keling, davom etaylik: ogohlantirish. U kuchli tizim - Moira yordamida tashkil etilgan. U mustaqil, chunki kaput ostida o'zining Grafiti bor. Python va Go-da yozilgan "Kontur" SKB yigitlari tomonidan ishlab chiqilgan, butunlay ochiq manba. Moira grafitlarga kiradigan bir xil oqimni oladi. Agar biron-bir sababga ko'ra xotirangiz o'chib qolsa, ogohlantirishingiz hali ham ishlaydi.
Biz Moira-ni Kubernetes-da joylashtirdik; u asosiy ma'lumotlar bazasi sifatida Redis serverlari klasteridan foydalanadi. Natijada nosozliklarga chidamli tizim paydo bo'ldi. U ko'rsatkichlar oqimini triggerlar ro'yxati bilan taqqoslaydi: agar unda eslatmalar bo'lmasa, u ko'rsatkichni tushiradi. Shunday qilib, u daqiqada gigabayt ko'rsatkichlarni hazm qila oladi.
Shuningdek, biz unga korporativ LDAP-ni biriktirdik, uning yordamida korporativ tizimning har bir foydalanuvchisi mavjud (yoki yangi yaratilgan) triggerlar asosida o'zlari uchun bildirishnomalarni yaratishi mumkin. Moira grafitni o'z ichiga olganligi sababli, u uning barcha xususiyatlarini qo'llab-quvvatlaydi. Shunday qilib, siz avval chiziqni olib, Grafana-ga ko'chirasiz. Grafiklarda ma'lumotlar qanday ko'rsatilishini ko'ring. Va keyin siz xuddi shu qatorni olib, Moiraga ko'chirasiz. Siz uni chegaralar bilan osib qo'yasiz va chiqishda ogohlantirish olasiz. Bularning barchasini amalga oshirish uchun sizga maxsus bilim kerak emas. Moira SMS, elektron pochta, Jira, Slack orqali ogohlantirishi mumkin ... Bundan tashqari, maxsus skriptlarning bajarilishini qo'llab-quvvatlaydi. U bilan trigger sodir bo'lganda va u maxsus skript yoki binarga obuna bo'lsa, u uni ishga tushiradi va JSONni ushbu ikkilik uchun stdinga yuboradi. Shunga ko'ra, dasturingiz uni tahlil qilishi kerak. Ushbu JSON bilan nima qilish sizga bog'liq. Xohlasangiz Telegramga yuboring, hohlasangiz Jirada topshiriqlarni oching, nima qilsangiz qiling.
Shuningdek, ogohlantirish uchun o'z ishlanmamizdan foydalanamiz - Imagotag. Odatda do'konlarda elektron narx belgilari uchun ishlatiladigan panelni ehtiyojlarimizga moslashtirdik. Biz unga Moiradan triggerlarni olib keldik. Bu ular qanday holatda va qachon paydo bo'lganligini ko'rsatadi. Ba'zi ishlab chiquvchilar ushbu panel foydasiga Slack va elektron pochta xabarnomalaridan voz kechishdi.
Biz ilg'or kompaniya bo'lganimiz sababli, biz ushbu tizimda Kubernetesni ham kuzatib bordik. Biz uni Heapster yordamida tizimga kiritdik, biz uni klasterga o'rnatdik, u ma'lumotlarni to'playdi va Graphite-ga yuboradi. Natijada, diagramma quyidagicha ko'rinadi:
Monitoring komponentlari
Bu erda biz ushbu vazifa uchun foydalangan komponentlarga havolalar ro'yxati. Ularning barchasi ochiq manba hisoblanadi.
Grafit:
- ketuvchi uglerod:
- shivirlab:
- grafit-api:
Karbon-c-rele:
Brubek:
Yig'ilgan:
Moira:
Grafana:
Ustun:
Статистика
Va bu erda tizim biz uchun qanday ishlashi haqida ba'zi raqamlar.
Agregator (brubeck)
Ko'rsatkichlar soni: ~300 000/sek
Grafitga o'lchovlarni yuborish oralig'i: 30 sek
Server resurslaridan foydalanish: ~ 6% CPU (to'liq huquqli serverlar haqida gapiramiz); ~ 1 Gb operativ xotira; ~3 Mbit/s LAN
Grafit (go-uglerod)
Ko'rsatkichlar soni: ~ 1 / min
Ko'rsatkichlarni yangilash oralig'i: 30 sek
Ko'rsatkichlarni saqlash sxemasi: 30 soniya 35 d, 5 min 90 kun, 10 min 365 d (uzoq vaqt davomida xizmat bilan nima sodir bo'lishini tushunish imkonini beradi)
Server resurslaridan foydalanish: ~10% CPU; ~ 20 Gb operativ xotira; ~30 Mbit/s LAN
Moslashuvchanlik
Biz Avito kompaniyasida monitoring xizmatimizdagi moslashuvchanlikni qadrlaymiz. Nega u aslida shunday bo'lib chiqdi? Birinchidan, uning tarkibiy qismlari bir-birini almashtiradi: komponentlarning o'zlari ham, ularning versiyalari ham. Ikkinchidan, qo'llab-quvvatlash. Butun loyiha ochiq manba bo'lgani uchun siz kodni o'zingiz tahrirlashingiz, o'zgartirishlar kiritishingiz va qutidan tashqarida mavjud bo'lmagan funktsiyalarni amalga oshirishingiz mumkin. Juda keng tarqalgan steklardan foydalaniladi, asosan Go va Python, shuning uchun bu juda oddiy bajariladi.
Mana, haqiqiy muammoning misoli. Grafitdagi ko'rsatkich fayldir. Uning nomi bor. Fayl nomi = metrik nomi. Va u erga borishning yo'li bor. Linuxda fayl nomlari 255 belgi bilan cheklangan. Va bizda ("ichki mijozlar" sifatida) ma'lumotlar bazasi bo'limidan yigitlar bor. Ular bizga: “Biz SQL so'rovlarimizni kuzatib borishni xohlaymiz. Va ular 255 belgi emas, balki har biri 8 MB. Biz ularni Grafana'da ko'rsatishni, ushbu so'rovning parametrlarini ko'rishni xohlaymiz va bundan ham yaxshisi, biz bunday so'rovlarning yuqori qismini ko'rishni xohlaymiz. Haqiqiy vaqtda ko'rsatilsa, juda yaxshi bo'ladi. Ularni ogohlantirish holatiga qo'yish juda zo'r bo'lardi. ”
Misol sifatida SQL so'rovi olingan
Biz Redis serverini o'rnatamiz va Postgres-ga o'tadigan va u erdan barcha ma'lumotlarni olib, Graphite-ga o'lchovlarni yuboradigan Collectd plaginlarimizdan foydalanamiz. Lekin biz metrik nomini xeshlar bilan almashtiramiz. Biz bir vaqtning o'zida bir xil xeshni Redis-ga kalit sifatida va butun SQL so'rovini qiymat sifatida yuboramiz. Biz qilishimiz kerak bo'lgan narsa - Grafana Redis-ga borib, bu ma'lumotni olishi mumkinligiga ishonch hosil qilish. Biz Graphite API-ni ochmoqdamiz, chunki... bu barcha monitoring komponentlarining grafit bilan o'zaro ta'siri uchun asosiy interfeys va biz u erda aliasByHash() deb nomlangan yangi funktsiyani kiritamiz - Grafana'dan biz metrikaning nomini olamiz va uni Redis-ga kalit sifatida so'rovda ishlatamiz. javob biz kalitning qiymatini olamiz, bu bizning "SQL so'rovimiz" " Shunday qilib, biz Grafana'da SQL so'rovining displeyini ko'rsatdik, uni nazariy jihatdan u erda ko'rsatish mumkin emas edi va undagi statistika (qo'ng'iroqlar, qatorlar, jami_vaqt, ...).
natijalar
Mavjudligi. Bizning monitoring xizmatimiz har qanday dastur va har qanday koddan 24/7 mavjud. Agar sizda saqlash vositalaridan foydalanish imkoningiz bo'lsa, xizmatga ma'lumotlarni yozishingiz mumkin. Til muhim emas, qarorlar muhim emas. Siz faqat rozetkani qanday ochishni bilishingiz kerak, u erda metrikani qo'ying va rozetkani yopishingiz kerak.
Ishonchlilik. Barcha komponentlar nosozliklarga chidamli va yuklarimizni yaxshi ushlab turadi.
Kirish uchun past to'siq. Ushbu tizimdan foydalanish uchun Grafana-da dasturlash tillarini va so'rovlarni o'rganishingiz shart emas. Ilovangizni oching, unga Graphite-ga o'lchovlarni yuboradigan rozetkani kiriting, uni yoping, Grafana-ni oching, u erda asboblar panelini yarating va Moira orqali bildirishnomalarni qabul qilib, o'lchovlaringizning xatti-harakatlariga qarang.
Mustaqillik. Bularning barchasini DevOps muhandislari yordamisiz o'zingiz qilishingiz mumkin. Va bu afzallik, chunki siz hozirda loyihangizni kuzatishingiz mumkin, siz hech kimdan so'rashingiz shart emas - ishni boshlash yoki o'zgartirish kiritish.
Biz nimaga intilyapmiz?
Quyida sanab o'tilganlarning barchasi shunchaki mavhum fikrlar emas, balki hech bo'lmaganda birinchi qadamlar qo'yilgan narsadir.
- Anomaliya detektori. Biz Graphite omborlarimizga o'tadigan va har bir ko'rsatkichni turli xil algoritmlar yordamida tekshiradigan xizmat yaratmoqchimiz. Biz ko'rmoqchi bo'lgan algoritmlar allaqachon mavjud, ma'lumotlar mavjud, biz u bilan qanday ishlashni bilamiz.
- Metadata. Bizda ko'plab xizmatlar mavjud, ular vaqt o'tishi bilan o'zgaradi, xuddi ular bilan ishlaydigan odamlar kabi. Doimiy ravishda hujjatlarni qo'lda saqlash variant emas. Shuning uchun biz endi metama'lumotlarni mikroservislarimizga joylashtirmoqdamiz. Unda uni kim ishlab chiqqani, u o'zaro aloqada bo'lgan tillar, SLA talablari, bildirishnomalar qaerga va kimga yuborilishi kerakligi ko'rsatilgan. Xizmatni tarqatishda barcha ob'ekt ma'lumotlari mustaqil ravishda yaratiladi. Natijada siz ikkita havolaga ega bo'lasiz - biri triggerlarga, ikkinchisi Grafana-dagi asboblar paneliga.
- Har bir uyda monitoring. Biz barcha ishlab chiquvchilar bunday tizimdan foydalanishlari kerak deb hisoblaymiz. Bunday holda siz doimo sizning tirbandligingiz qayerda ekanligini, u bilan nima sodir bo'lishini, qayerga tushishini, uning zaif tomonlarini tushunasiz. Agar, masalan, biror narsa kelib xizmatingizni buzsa, siz bu haqda menejer qo'ng'irog'i paytida emas, balki ogohlantirishdan bilib olasiz va siz darhol eng so'nggi jurnallarni ochib, u erda nima bo'lganini ko'rishingiz mumkin.
- Yuqori samaradorlik. Bizning loyihamiz doimiy ravishda o'sib bormoqda va bugungi kunda u daqiqada 2 000 000 metrik qiymatni qayta ishlaydi. Bir yil oldin bu ko'rsatkich 500 000 edi.Va o'sish davom etmoqda va bu bir muncha vaqt o'tgach Graphite (shivirlash) disk quyi tizimini og'ir yuklay boshlaydi. Yuqorida aytib o'tganimdek, ushbu monitoring tizimi tarkibiy qismlarning almashinuvi tufayli juda universaldir. Kimdir Graphite uchun maxsus infratuzilmasini saqlab turadi va doimiy ravishda kengaytiradi, lekin biz boshqa yo'ldan borishga qaror qildik: foydalaning ko'rsatkichlarimiz uchun ombor sifatida. Ushbu o'tish deyarli yakunlandi va yaqin orada men sizga bu qanday amalga oshirilganini batafsil aytib beraman: qanday qiyinchiliklar bo'lgan va ular qanday yengilgan, migratsiya jarayoni qanday o'tgan, men bog'lovchi sifatida tanlangan komponentlarni va ularning konfiguratsiyasini tasvirlab beraman.
E'tiboringiz uchun rahmat! Mavzu bo'yicha savollaringizni bering, men bu erda yoki keyingi postlarda javob berishga harakat qilaman. Ehtimol, kimdir shunga o'xshash monitoring tizimini yaratish yoki shunga o'xshash vaziyatda Clickhouse-ga o'tish tajribasiga ega - buni sharhlarda baham ko'ring.
Manba: www.habr.com