VictoriaMetrics - bu vaqt seriyasi ko'rinishida ma'lumotlarni saqlash va qayta ishlash uchun tezkor va kengaytiriladigan DBMS (yozuv vaqtdan va shu vaqtga to'g'ri keladigan qiymatlar to'plamidan iborat, masalan, sensorlar yoki sensorlar holatini davriy so'rov qilish orqali olingan. ko'rsatkichlar to'plami).
Mening ismim Kolobaev Pavel. DevOps, SRE, LeroyMerlin, hamma narsa kodga o'xshaydi - barchasi biz haqimizda: men va boshqa LeroyMerlin xodimlari haqida.
OpenStack-ga asoslangan bulut mavjud. Texnik radarga kichik havola mavjud.
U Kubernetes apparatida, shuningdek, OpenStack va logging uchun barcha tegishli xizmatlarda qurilgan.
Bu biz ishlab chiqishda bo'lgan sxema. Bularning barchasini ishlab chiqayotganimizda, bizda K8s klasterining o'zida ma'lumotlarni saqlaydigan Prometey operatori bor edi. U avtomatik ravishda tozalanishi kerak bo'lgan narsalarni topadi va qo'pol qilib aytganda, oyoqlari ostiga qo'yadi.
Biz barcha ma'lumotlarni Kubernetes klasteridan tashqariga ko'chirishimiz kerak bo'ladi, chunki agar biror narsa sodir bo'lsa, biz nima va qaerda ekanligini tushunishimiz kerak.
Birinchi yechim shundaki, biz uchinchi tomon Prometeyiga ega bo'lganimizda, federatsiya mexanizmi orqali Kubernetes klasteriga borganimizda federatsiyadan foydalanamiz.
Ammo bu erda kichik muammolar mavjud. Bizning holatlarimizda muammolar bizda 250 000 ko'rsatkichga ega bo'lganida boshlandi va 400 000 ko'rsatkichlar mavjud bo'lganda, biz bunday ishlay olmasligimizni tushundik. Biz scrape_timeout vaqtini 25 soniyagacha oshirdik.
Nega buni qilishimiz kerak edi? Prometey to'siq boshidan taym-autni hisoblashni boshlaydi. Ma'lumotlar hali ham oqayotgani muhim emas. Agar ushbu belgilangan vaqt oralig'ida ma'lumotlar birlashtirilmasa va sessiya http orqali yopilmasa, u holda sessiya muvaffaqiyatsiz deb hisoblanadi va ma'lumotlar Prometeyning o'ziga tushmaydi.
Ba'zi ma'lumotlar etishmayotganda biz oladigan grafiklar bilan hamma tanish. Jadvallar yirtilgan va biz bundan mamnun emasmiz.
Keyingi variant - bir xil federatsiya mexanizmi orqali ikki xil Prometeyga asoslangan sharding.
Masalan, ularni olib, nomlari bilan ajratib oling. Bu ham ishlatilishi mumkin, lekin biz davom etishga qaror qildik.
Endi biz bu parchalarni qandaydir tarzda qayta ishlashimiz kerak. Shard maydoniga boradigan va ma'lumotlarni ko'paytiradigan promxy-ni olishingiz mumkin. U bitta kirish nuqtasi sifatida ikkita parcha bilan ishlaydi. Buni promxy orqali amalga oshirish mumkin, ammo bu hali ham juda qiyin.
Birinchi variant - biz federatsiya mexanizmidan voz kechmoqchimiz, chunki u juda sekin.
Prometey ishlab chiquvchilari aniq aytishadi: "Bolalar, boshqa TimescaleDB dan foydalaning, chunki biz o'lchovlarni uzoq muddatli saqlashni qo'llab-quvvatlamaymiz." Bu ularning vazifasi emas.
Biz hamma narsani bir joyda saqlamaslik uchun biz hali ham tashqarida tushirishimiz kerak bo'lgan qog'ozga yozamiz.
Ikkinchi kamchilik - xotira iste'moli. Ha, tushunaman, ko'pchilik 2020 yilda bir necha gigabayt xotira bir tiyin turadi, deb aytishadi, lekin baribir.
Endi bizda ishlab chiqaruvchi va ishlab chiqarish muhiti mavjud. Ishlab chiqaruvchida bu 9 350 ko'rsatkich uchun taxminan 000 gigabaytni tashkil qiladi. Ishlab chiqarishda u 14 gigabayt va 780 000 ko'rsatkichdan bir oz ko'proq. Shu bilan birga, bizning saqlash vaqtimiz atigi 30 daqiqa. Bu yomon. Va endi men sababini tushuntiraman.
Biz hisob-kitob qilamiz, ya'ni bir yarim million o'lchov bilan va biz allaqachon ularga yaqinlashamiz, dizayn bosqichida biz 35-37 gigabayt xotiraga ega bo'lamiz. Ammo allaqachon 4 million ko'rsatkich taxminan 90 gigabayt xotirani talab qiladi. Ya'ni, u Prometey ishlab chiquvchilari tomonidan taqdim etilgan formuladan foydalangan holda hisoblab chiqilgan. Biz korrelyatsiyani ko'rib chiqdik va faqat monitoring uchun server uchun bir necha million to'lashni xohlamasligimizni tushundik.
Biz nafaqat mashinalar sonini ko'paytiramiz, balki virtual mashinalarni ham kuzatib boramiz. Shuning uchun, virtual mashinalar qancha ko'p bo'lsa, har xil turdagi ko'rsatkichlar shunchalik ko'p bo'ladi va hokazo. Biz o'lchovlar bo'yicha klasterimizning alohida o'sishiga ega bo'lamiz.
Disk maydoni bilan bu erda hamma narsa unchalik yomon emas, lekin men uni yaxshilashni xohlayman. Biz 15 kun ichida jami 120 gigabayt oldik, ulardan 100 tasi siqilgan ma'lumotlar, 20 tasi siqilmagan ma'lumotlar, lekin biz har doim kamroq istaymiz.
Shunga ko'ra, biz yana bir narsani yozamiz - bu biz hali ham tejashni xohlaydigan katta resurslar iste'moli, chunki biz monitoring klasterimiz OpenStack-ni boshqaradigan klasterimizga qaraganda ko'proq resurslarni iste'mol qilishini xohlamaymiz.
Biz o'zimiz uchun aniqlagan Prometeyning yana bir kamchiligi bor, bu hech bo'lmaganda qandaydir xotira cheklovidir. Prometey bilan bu erda hamma narsa yomonroq, chunki unda bunday burilishlar umuman yo'q. Docker-da cheklovdan foydalanish ham variant emas. Agar to'satdan sizning RAF tushib qolsa va 20-30 gigabayt bo'lsa, unda ko'tarilish uchun juda uzoq vaqt kerak bo'ladi.
Bu Prometey bizga mos kelmasligining yana bir sababi, ya'ni biz xotira sarfini cheklay olmaymiz.
Bunday sxemani o'ylab topish mumkin edi. HA klasterini tashkil qilish uchun bizga ushbu sxema kerak. Bizning ko'rsatkichlarimiz har doim va hamma joyda mavjud bo'lishini xohlaymiz, hatto ushbu ko'rsatkichlarni saqlaydigan server ishdan chiqqan bo'lsa ham. Shunday qilib, biz bunday sxemani qurishimiz kerak bo'ladi.
Ushbu sxemada aytilishicha, bizda parchalarning takrorlanishi va shunga mos ravishda iste'mol qilingan resurslar xarajatlarining takrorlanishi bo'ladi. Uni deyarli gorizontal ravishda o'lchash mumkin, ammo shunga qaramay, resurs iste'moli do'zaxli bo'ladi.
Kamchiliklar biz ularni o'zimiz uchun yozgan shaklda:
- Koʻrsatkichlarni tashqaridan yuklashni talab qiladi.
- Yuqori resurs iste'moli.
- Xotira sarfini cheklashning hech qanday usuli yo'q.
- HAni murakkab va resurs talab qiladigan amalga oshirish.
O'zimiz uchun biz Prometeydan saqlash joyi sifatida uzoqlashishga qaror qildik.
Biz o'zimizga kerak bo'lgan qo'shimcha talablarni aniqladik. Bu:
- Bu promql qo'llab-quvvatlashi, chunki Prometey uchun juda ko'p narsalar allaqachon yozilgan: so'rovlar, ogohlantirishlar.
- Va keyin bizda Grafana bor, u allaqachon Prometey uchun backend sifatida xuddi shu tarzda yozilgan. Men asboblar panelini qayta yozishni xohlamayman.
- Biz oddiy HA arxitekturasini qurmoqchimiz.
- Biz har qanday resurslarni iste'mol qilishni kamaytirmoqchimiz.
- Yana bir kichik nuance bor. Biz bulutli o'lchovlarni yig'ish tizimlarining har xil turlaridan foydalana olmaymiz. Ushbu ko'rsatkichlarga nima tushishini hali bilmaymiz. Va u erda hamma narsa uchishi mumkinligi sababli, biz o'zimizni mahalliy joylashtirish bilan cheklashimiz kerak.
Tanlov kam edi. Biz tajribamiz bo'lgan hamma narsani to'pladik. Biz integratsiya bo'limidagi Prometey sahifasiga qaradik, bir qancha maqolalarni o'qib chiqdik va u erda nima borligini ko'rdik. Va o'zimiz uchun biz ViktoriyaMetricsni Prometey o'rniga tanladik.
Nega? Chunki:
- promql biladi.
- Modulli arxitektura mavjud.
- Grafana-ga o'zgartirish kiritishni talab qilmaydi.
- Va eng muhimi, biz kompaniyamizda o'lchovlarni saqlashni xizmat sifatida taqdim etamiz, shuning uchun biz foydalanuvchilar klasterning barcha resurslaridan cheklangan tarzda foydalanishlari uchun har xil turdagi cheklovlarni oldindan ko'rib chiqamiz, chunki imkoniyat bor u ko'p ijaraga beriladi.
Keling, birinchi taqqoslashni qilaylik. Biz bir xil Prometeyni klaster ichida olamiz, tashqi Prometey unga boradi. RemoteWrite VictoriaMetrics orqali qo'shing.
Men darhol rezervlash qilaman, bu erda biz VictoriaMetrics-dan protsessor iste'molini biroz oshirdik. VictoriaMetrics wiki sizga qaysi parametrlar eng yaxshi ekanligini aytib beradi. Biz ularni tekshirdik. Ular CPU iste'molini juda yaxshi kamaytirdilar.
Bizning holatlarimizda Kubernetes klasterida joylashgan Prometeyning xotira iste'moli sezilarli darajada oshmadi.
Biz bir xil ma'lumotlarning ikkita ma'lumot manbasini solishtiramiz. Prometeyda biz bir xil etishmayotgan ma'lumotlarni ko'ramiz. VictoriaMetrics-da hamma narsa yaxshi.
Disk maydoni sinov natijalari. Biz Prometeyda jami 120 gigabayt oldik. VictoriaMetrics-da biz allaqachon kuniga 4 gigabayt olamiz. Biz Prometeyda ko'rganimizdan biroz boshqacha mexanizm mavjud. Ya'ni, ma'lumotlar allaqachon bir kunda, yarim soat ichida juda yaxshi siqilgan. Keyinchalik ma'lumotlar hali ham yo'qolishiga qaramay, ular bir kunda, yarim soat ichida yaxshi yig'ib olindi. Natijada biz diskda bo'sh joyni tejadik.
Shuningdek, biz xotira resurslari sarfini tejaymiz. Sinov paytida biz Prometeyni virtual mashinada o'rnatdik - 8 yadro, 24 gigabayt. Prometey deyarli hamma narsani eydi. U OOM Killerga yiqildi. Shu bilan birga, unga atigi 900 000 faol ko'rsatkichlar quyilgan. Bu soniyada taxminan 25 000-27 000 ko'rsatkich.
Biz VictoriaMetrics dasturini 8 gigabayt operativ xotiraga ega ikki yadroli virtual mashinada ishga tushirdik. Biz VictoriaMetrics-ni 8 GB hajmli mashinada bir nechta narsalar bilan o'ynab, yaxshi ishlashiga erishdik. Oxir-oqibat, biz uni 7 gigabaytgacha ushlab turdik. Shu bilan birga, kontentni etkazib berish tezligi, ya'ni o'lchovlar Prometeynikidan ham yuqori edi.
Prometeyga nisbatan protsessor ancha yaxshilandi. Bu erda Prometey 2,5 yadroni, VictoriaMetrics esa faqat 0,25 yadroni iste'mol qiladi. Boshida - 0,5 yadro. U birlashganda, u bir yadroga etadi, lekin bu juda kam uchraydi.
Bizning holatlarimizda tanlov aniq sabablarga ko'ra VictoriaMetrics-ga tushdi; biz pulni tejashni xohladik va biz shunday qildik.
Keling, ikkita nuqtani darhol kesib o'tamiz - ko'rsatkichlarni yuklash va resurslarning yuqori iste'moli. Va biz faqat o'zimiz uchun qolgan ikkita nuqtani hal qilishimiz kerak.
Bu erda men darhol rezervatsiya qilaman, biz VictoriaMetricsni o'lchovlarni saqlash joyi sifatida ko'rib chiqamiz. Ammo biz VictoriaMetrics-ni butun Leroy uchun saqlash sifatida taqdim etishimiz sababli, biz ushbu klasterdan foydalanadiganlarni bizga bermasliklari uchun cheklashimiz kerak.
Vaqt, ma'lumotlar hajmi va bajarilish vaqti bo'yicha cheklash imkonini beruvchi ajoyib parametr mavjud.
Xotira iste'molini cheklash imkonini beruvchi ajoyib variant ham mavjud, shu bilan biz normal ishlash tezligini va etarli resurslarni iste'mol qilishimizga imkon beradigan muvozanatni topishimiz mumkin.
Minus yana bir nuqta, ya'ni nuqtani kesib tashlang - siz xotira sarfini cheklay olmaysiz.
Birinchi iteratsiyalarda biz VictoriaMetrics Single Node-ni sinab ko'rdik. Keyinchalik VictoriaMetrics Cluster Versionga o'tamiz.
Bu erda VictoriaMetrics-dagi turli xizmatlarni ular nimada ishlashi va qanday resurslarni iste'mol qilishiga qarab ajratish uchun bepul qo'limiz bor. Bu juda moslashuvchan va qulay yechim. Biz buni o'zimizda ishlatganmiz.
VictoriaMetrics Cluster Versionning asosiy komponentlari vmstsorage hisoblanadi. Ularning soni N bo'lishi mumkin. Bizning holatlarimizda hozirgacha ulardan 2 tasi bor.
Va vminsert mavjud. Bu proksi-server bo'lib, u bizga quyidagilarga imkon beradi: biz aytgan barcha xotiralar o'rtasida shardingni tashkil qilish va u replikatsiyaga ham ruxsat beradi, ya'ni sizda ham sharding, ham replika bo'ladi.
Vminsert Prometeydan OpenTSDB, Graphite, InfluxDB va remoteWrite protokollarini qo'llab-quvvatlaydi.
Vmselect ham mavjud. Uning asosiy vazifasi vmstorage-ga o'tish, ulardan ma'lumotlarni olish, ushbu ma'lumotlarni nusxalash va mijozga berishdir.
Vmagent degan ajoyib narsa bor. Biz uni juda yaxshi ko'ramiz. Bu sizga Prometeyga o'xshab sozlash imkonini beradi va hamma narsani xuddi Prometey kabi bajarishga imkon beradi. Ya'ni, u turli ob'ektlar va xizmatlardan o'lchovlarni to'playdi va ularni vminsertga yuboradi. Keyin hamma narsa sizga bog'liq.
Yana bir ajoyib xizmat vmalert bo'lib, u sizga VictoriaMetrics-dan backend sifatida foydalanish, vminsert-dan qayta ishlangan ma'lumotlarni olish va uni vmselect-ga yuborish imkonini beradi. U ogohlantirishlarning o'zini, shuningdek, qoidalarni qayta ishlaydi. Ogohlantirishlar bo'lsa, biz ogohlantirishni alertmanager orqali olamiz.
wmauth komponenti mavjud. Biz uni klasterlarning ko'p ijaraga olish versiyasi uchun avtorizatsiya tizimi sifatida ishlatishimiz yoki foydalanmasligimiz mumkin (biz bu haqda hali qaror qilganimiz yo'q). U Prometey uchun remoteWrite-ni qo'llab-quvvatlaydi va siz yozishingiz mumkin bo'lgan yoki yoza olmaydigan url, to'g'rirog'i uning ikkinchi qismi asosida avtorizatsiya qilishi mumkin.
Bundan tashqari, vmbackup, vmrestore mavjud. Bu, aslida, barcha ma'lumotlarni qayta tiklash va zaxiralashdir. S3, GCS, faylni bajarishi mumkin.
Klasterimizning birinchi iteratsiyasi karantin davrida amalga oshirildi. O'sha paytda hech qanday replika yo'q edi, shuning uchun bizning iteratsiyamiz ikki xil va mustaqil klasterdan iborat bo'lib, ularda biz remoteWrite orqali ma'lumot oldik.
Bu erda men VictoriaMetrics Single Node-dan VictoriaMetrics Cluster Version-ga o'tganimizda, biz hali ham bir xil iste'mol qilingan resurslar bilan qoldik, ya'ni asosiysi xotira. Bizning ma'lumotlarimiz, ya'ni resurslarni iste'mol qilish taxminan shunday taqsimlangan.
Bu yerda nusxa allaqachon qo'shilgan. Biz bularning barchasini nisbatan katta klasterga birlashtirdik. Bizning barcha ma'lumotlarimiz ajratilgan va takrorlangan.
Butun klasterda N ta kirish nuqtasi mavjud, ya'ni Prometey HAPROXY orqali ma'lumotlarni qo'shishi mumkin. Mana bizda kirish nuqtasi bor. Va ushbu kirish nuqtasi orqali siz Grafana'dan kirishingiz mumkin.
Bizning holatda, HAPROXY bu klaster ichidagi proksi-serverlarni tanlash, kiritish va boshqa xizmatlarni tanlaydigan yagona portdir. Bizning holatlarimizda bitta manzilni belgilashning iloji yo'q edi, biz bir nechta kirish nuqtalarini yaratishimiz kerak edi, chunki VictoriaMetrics klasteri ishlaydigan virtual mashinalar bir xil bulut provayderining turli zonalarida joylashgan, ya'ni bizning bulut ichida emas, balki tashqarida. .
Bizda ogohlantirish bor. Biz undan foydalanamiz. Biz Prometeydan alertmanagerdan foydalanamiz. Biz Opsgenie va Telegram’dan ogohlantirishlarni yetkazib berish kanali sifatida foydalanamiz. Telegramda ular ishlab chiqaruvchidan, ehtimol ishlab chiqarishdan nimadir, lekin asosan muhandislar uchun zarur bo'lgan statistik narsalarni kiritishadi. Va Opsgenie juda muhim. Bu qo'ng'iroqlar, hodisalarni boshqarish.
Abadiy savol: "Monitoringni kim nazorat qiladi?" Bizning holatda, monitoring o'zini o'zi monitoring qiladi, chunki biz har bir tugunda vmagent dan foydalanamiz. Va bizning tugunlarimiz bir xil provayderning turli ma'lumotlar markazlari bo'ylab taqsimlanganligi sababli, har bir ma'lumot markazining o'z kanali bor, ular mustaqildir va bo'lingan miya kelgan taqdirda ham biz ogohlantirishlarni olamiz. Ha, ular ko'proq bo'ladi, lekin hech bo'lmagandan ko'ra ko'proq ogohlantirish olish yaxshiroqdir.
Ro'yxatimizni HA dasturi bilan yakunlaymiz.
Bundan tashqari, VictoriaMetrics hamjamiyati bilan muloqot qilish tajribasini ta'kidlamoqchiman. Bu juda ijobiy chiqdi. Yigitlar javob berishadi. Ular taklif qilingan har bir ishni chuqur o'rganishga harakat qilishadi.
Men GitHub-da muammolarni boshladim. Ular juda tez hal qilindi. To'liq yopilmagan yana bir nechta muammolar mavjud, ammo men koddan bu yo'nalishda ish olib borilayotganini allaqachon ko'rishim mumkin.
Takrorlash paytida men uchun asosiy og'riq, agar men tugunni o'chirib qo'ysam, birinchi 30 soniya davomida vminsert hech qanday backend yo'qligini tushunolmasligi edi. Bu endi qaror qilindi. Va tom ma'noda bir yoki ikki soniya ichida ma'lumotlar qolgan barcha tugunlardan olinadi va so'rov ushbu etishmayotgan tugunni kutishni to'xtatadi.
Bir paytlar biz VictoriaMetricsni VictoriaMetrics operatori bo'lishini xohladik. Biz uni kutdik. Endi biz VictoriaMetrics operatori uchun barcha oldindan hisoblash qoidalarini va hokazolarni olishi uchun tizimni faol ravishda qurmoqdamiz. Prometey, chunki biz Prometey operatori bilan kelgan qoidalardan juda faol foydalanmoqdamiz.
Klasterni joriy qilishni takomillashtirish bo'yicha takliflar mavjud. Men ularni yuqorida aytib o'tdim.
Va men, albatta, kamaytirmoqchiman. Bizning holatlarimizda namunani pasaytirish faqat tendentsiyalarni ko'rish uchun kerak bo'ladi. Taxminan aytganda, kun davomida men uchun bitta ko'rsatkich etarli. Bu tendentsiyalar bir yil, uch, besh, o'n yil davomida kerak. Va bitta metrik qiymat juda etarli.
- Biz Prometeydan foydalanganda ba'zi hamkasblarimiz kabi og'riqni bilamiz.
- Biz o'zimiz uchun VictoriaMetrics-ni tanladik.
- U vertikal va gorizontal ravishda juda yaxshi o'lchaydi.
- Biz turli komponentlarni klasterdagi turli sonli tugunlarga tarqatishimiz, ularni xotira bilan cheklashimiz, xotira qo'shishimiz va h.k.
Biz VictoriaMetrics-ni uyda ishlatamiz, chunki u bizga juda yoqdi. Bu nima bo'lgan va nima bo'lgan.
VictoriaMetrics suhbati uchun bir nechta QR kodlari, mening kontaktlarim, LeroyMerlin texnik radarlari.
Manba: www.habr.com