VictoriaMetrics - бұл уақыттық қатар түріндегі деректерді сақтауға және өңдеуге арналған жылдам және масштабталатын ДҚБЖ (жазба уақыт пен осы уақытқа сәйкес келетін мәндер жиынтығынан тұрады, мысалы, сенсорлардың немесе датчиктердің күйін мерзімді сұрау арқылы алынған) көрсеткіштер жинағы).
Менің атым Колобаев Павел. DevOps, SRE, LeroyMerlin, бәрі код сияқты - бәрі біз туралы: мен туралы және басқа LeroyMerlin қызметкерлері туралы.
OpenStack негізіндегі бұлт бар. Техникалық радарға шағын сілтеме бар.
Ол Kubernetes аппараттық құралында, сондай-ақ OpenStack және журнал жүргізуге қатысты барлық қызметтерде құрастырылған.
Бұл бізде әзірлеген схема. Осының барлығын әзірлеген кезде бізде K8s кластерінің өзінде деректерді сақтайтын Prometheus операторы болды. Тазалау керек нәрсені автоматты түрде тауып алып, дөрекі айтқанда аяғының астына қояды.
Бізге барлық деректерді Kubernetes кластерінен тыс жылжыту керек болады, өйткені бірдеңе орын алса, нені және қайда екенін түсінуіміз керек.
Бірінші шешім - бізде үшінші тарап Prometheus болғанда, федерация механизмі арқылы Кубернетес кластеріне барғанда федерацияны пайдаланамыз.
Бірақ бұл жерде шағын мәселелер бар. Біздің жағдайда проблемалар бізде 250 000 метрика болған кезде басталды және 400 000 метрика болғанда, біз бұлай жұмыс істей алмайтынымызды түсіндік. Біз scrape_timeout уақытын 25 секундқа дейін арттырдық.
Неліктен біз мұны істеуге мәжбүр болдық? Прометей тайм-аутты санауды қоршаудың басынан бастайды. Деректер әлі де ағып жатқаны маңызды емес. Егер осы көрсетілген уақыт аралығында деректер біріктірілмесе және сеанс http арқылы жабылмаса, сеанс сәтсіз аяқталды деп есептеледі және деректер Prometheus ішіне енбейді.
Кейбір деректер жоқ болған кезде алатын графиктермен бәрі таныс. Кестелер жыртылған, біз бұған риза емеспіз.
Келесі нұсқа - бірдей федерация механизмі арқылы екі түрлі Prometheus негізіндегі бөлшектеу.
Мысалы, оларды алып, атаулары бойынша бөліңіз. Мұны да қолдануға болады, бірақ біз әрі қарай жүруді шештік.
Енді біз бұл сынықтарды қандай да бір жолмен өңдеуіміз керек. Бөлшек аймағына өтіп, деректерді көбейтетін promxy алуға болады. Ол бір кіру нүктесі ретінде екі сынықпен жұмыс істейді. Мұны promxy арқылы жүзеге асыруға болады, бірақ бұл әлі де тым қиын.
Бірінші нұсқа – біз федерация механизмінен бас тартқымыз келеді, себебі ол өте баяу.
Prometheus әзірлеушілері: «Жігіттер, басқа TimescaleDB пайдаланыңыз, өйткені біз метриканың ұзақ мерзімді сақталуына қолдау көрсетпейміз» дейді. Бұл олардың міндеті емес.
Барлығын бір жерде сақтамас үшін сыртқа әлі түсіру керек екенін қағазға жазамыз.
Екінші кемшілік - жадты тұтыну. Иә, мен түсінемін, көптеген адамдар 2020 жылы бірнеше гигабайт жад бір тиын тұрады, бірақ бәрібір.
Қазір бізде әзірлеуші және өндіруші орта бар. Әзірлеуші де ол 9 350 метрика үшін шамамен 000 гигабайтты құрайды. Өндірісте бұл 14 гигабайт және 780 000 метрикадан сәл асады. Бұл ретте біздің сақтау уақытымыз небәрі 30 минутты құрайды. Бұл жаман. Ал енді себебін түсіндіремін.
Біз есептеуді жасаймыз, яғни бір жарым миллион метрикамен және біз оларға жақындап қалдық, жобалау кезеңінде біз 35-37 гигабайт жад аламыз. Бірақ қазірдің өзінде 4 миллион метрика шамамен 90 гигабайт жадты қажет етеді. Яғни, ол Prometheus әзірлеушілері ұсынған формула арқылы есептелді. Біз корреляцияға қарап, тек бақылау үшін серверге бірнеше миллион төлегіміз келмейтінін түсіндік.
Біз машиналар санын көбейтіп қана қоймай, виртуалды машиналарды да бақылаймыз. Сондықтан виртуалды машиналар неғұрлым көп болса, соғұрлым әртүрлі типтегі метрикалар және т.б.. Біздің кластеріміздің метрика тұрғысынан ерекше өсуі болады.
Дискілік кеңістікпен мұнда бәрі соншалықты нашар емес, бірақ мен оны жақсартқым келеді. Біз 15 күнде барлығы 120 гигабайт алдық, оның 100-і қысылған деректер, 20-сы қысылмаған деректер, бірақ біз әрқашан азырақ болғымыз келеді.
Тиісінше, біз тағы бір тармақты жазамыз - бұл біз әлі де үнемдегіміз келетін ресурстардың үлкен тұтынуы, өйткені біз бақылау кластеріміздің OpenStack басқаратын кластерге қарағанда көбірек ресурстарды тұтынғанын қаламаймыз.
Прометейдің тағы бір кемшілігі бар, оны біз өзіміз анықтадық, бұл кем дегенде есте сақтаудың қандай да бір шектеулері. Прометейде бұл жерде бәрі әлдеқайда нашар, өйткені ондай бұрылыстар мүлде жоқ. Докерде шектеуді пайдалану да опция емес. Егер сіздің RAF кенеттен құлап кетсе және 20-30 гигабайт болса, онда оның көтерілуіне өте көп уақыт қажет.
Бұл Прометейдің бізге жарамсыз болуының тағы бір себебі, яғни біз жадты тұтынуды шектей алмаймыз.
Мұндай схеманы ойлап табуға болар еді. HA кластерін ұйымдастыру үшін бізге бұл схема қажет. Біз өлшемдеріміздің әрқашан және барлық жерде қолжетімді болуын қалаймыз, тіпті бұл көрсеткіштерді сақтайтын сервер бұзылса да. Осылайша, біз осындай схеманы құруымыз керек.
Бұл схема бізде сынықтардың қайталануы және, тиісінше, тұтынылатын ресурстардың шығындарының қайталануы болады дейді. Оны дерлік көлденең масштабтауға болады, бірақ соған қарамастан ресурстарды тұтыну тозақ болады.
Кемшіліктер біз оларды өзіміз жазған формада ретімен:
- Көрсеткіштерді сырттан жүктеп салуды талап етеді.
- Жоғары ресурстарды тұтыну.
- Жадты тұтынуды шектеудің ешқандай жолы жоқ.
- ХА-ны кешенді және көп ресурстарды қажет ететін енгізу.
Біз өзіміз үшін Прометейден сақтау орны ретінде көшеміз деп шештік.
Біз өзімізге қажетті қосымша талаптарды анықтадық. Бұл:
- Бұл promql қолдауы, өйткені Прометей үшін көп нәрсе жазылған: сұраулар, ескертулер.
- Ал содан кейін бізде Grafana бар, ол қазірдің өзінде Прометей үшін бэкенд ретінде дәл солай жазылған. Мен бақылау тақталарын қайта жазғым келмейді.
- Біз қалыпты HA архитектурасын құрғымыз келеді.
- Біз кез келген ресурстарды тұтынуды азайтқымыз келеді.
- Тағы бір шағын нюанс бар. Біз бұлттық көрсеткіштерді жинау жүйелерінің әртүрлі түрлерін пайдалана алмаймыз. Біз бұл көрсеткіштерге не кіретінін әлі білмейміз. Ол жерде кез келген нәрсе ұша алатындықтан, біз өзімізді жергілікті орналастырумен шектеуіміз керек.
Таңдау аз болды. Біз тәжірибеміздің бәрін жинадық. Біз интеграция бөліміндегі «Прометей» бетіне қарадық, көптеген мақалаларды оқыдық және онда не бар екенін көрдік. Ал өзіміз үшін Прометейдің орнына VictoriaMetrics таңдадық.
Неліктен? Себебі:
- promql біледі.
- Модульдік архитектурасы бар.
- Grafana-ға өзгертулер енгізуді қажет етпейді.
- Ең бастысы, біз өз компаниямыздағы көрсеткіштерді сақтауды қызмет ретінде қамтамасыз ететін шығармыз, сондықтан пайдаланушылар кластердің барлық ресурстарын шектеулі түрде пайдалана алуы үшін әртүрлі шектеулерді алдын ала қарастырамыз, өйткені мүмкіндік бар. ол көп пәтерлі болады.
Бірінші салыстыруды жасайық. Біз кластердің ішіне бірдей Прометейді аламыз, сыртқы Прометей оған барады. RemoteWrite VictoriaMetrics арқылы қосыңыз.
Мен бірден ескертемін, бұл жерде біз VictoriaMetrics-тен процессорды тұтынудың шамалы өсуін байқадық. VictoriaMetrics вики сізге қай параметрлердің жақсы екенін айтады. Біз оларды тексердік. Олар процессорды тұтынуды өте жақсы азайтты.
Біздің жағдайда Kubernetes кластерінде орналасқан Прометейдің жадты тұтынуы айтарлықтай өскен жоқ.
Бір деректердің екі дерек көзін салыстырамыз. Прометейде біз дәл осындай жетіспейтін деректерді көреміз. VictoriaMetrics-те бәрі жақсы.
Диск кеңістігін тексеру нәтижелері. Біз Прометейде барлығы 120 гигабайт алдық. VictoriaMetrics-те біз күніне 4 гигабайт аламыз. Біз Прометейде көріп үйренгеннен сәл өзгеше механизм бар. Яғни, деректер бір күнде, жарты сағатта жақсы қысылады. Деректер кейінірек жоғалатынына қарамастан, олар бір күнде, жарты сағатта жақсы орылды. Нәтижесінде біз дискілік кеңістікті үнемдедік.
Сондай-ақ жад ресурстарын тұтынуды үнемдейміз. Тестілеу кезінде бізде Prometheus виртуалды машинада орналастырылды - 8 ядро, 24 гигабайт. Прометей барлығын дерлік жейді. Ол OOM Killer-ге құлады. Сонымен бірге оған тек 900 000 белсенді метрика құйылды. Бұл секундына шамамен 25 000-27 000 метрика.
Біз VictoriaMetrics 8 гигабайт жедел жады бар екі ядролы виртуалды машинада іске қостық. Біз VictoriaMetrics-ті 8 ГБ құрылғыда бірнеше нәрселермен айналысу арқылы жақсы жұмыс істей алдық. Соңында біз оны 7 гигабайтқа дейін сақтадық. Сонымен қатар, мазмұнды жеткізу жылдамдығы, яғни метрика Прометейден де жоғары болды.
Прометеймен салыстырғанда процессор әлдеқайда жақсырақ болды. Мұнда Prometheus 2,5 ядроны, ал VictoriaMetrics тек 0,25 ядроны тұтынады. Бастапқыда - 0,5 ядро. Ол біріктірілген кезде бір ядроға жетеді, бірақ бұл өте сирек кездеседі.
Біздің жағдайда таңдау белгілі себептерге байланысты VictoriaMetrics-ке түсті; біз ақша үнемдегіміз келді және біз істедік.
Бірден екі нүктені сызып алайық - көрсеткіштерді жүктеп салу және ресурстарды көп тұтыну. Біз өзімізге әлі қалдырған екі ұпайды шешуіміз керек.
Мұнда мен бірден тапсырыс жасаймын, біз VictoriaMetrics-ті метриканың қоймасы ретінде қарастырамыз. Бірақ біз VictoriaMetrics-ті бүкіл Лерой үшін сақтау ретінде беретіндіктен, біз бұл кластерді пайдаланатындарды бізге бермеу үшін шектеуіміз керек.
Уақыт бойынша, деректер көлемі бойынша және орындалу уақыты бойынша шектеуге мүмкіндік беретін тамаша параметр бар.
Сондай-ақ, жадты тұтынуды шектеуге мүмкіндік беретін тамаша опция бар, осылайша біз қалыпты жұмыс жылдамдығын және жеткілікті ресурстарды тұтынуға мүмкіндік беретін теңгерімді таба аламыз.
Минус тағы бір нүкте, яғни нүктені сызып тастаңыз - жадты тұтынуды шектей алмайсыз.
Бірінші итерацияларда біз VictoriaMetrics бір түйінін сынадық. Әрі қарай VictoriaMetrics кластер нұсқасына көшеміз.
Мұнда VictoriaMetrics-тегі әртүрлі қызметтерді немен жұмыс істейтініне және қандай ресурстарды тұтынатынына байланысты бөлуге еркін қолымыз бар. Бұл өте икемді және ыңғайлы шешім. Біз мұны өзімізде қолдандық.
VictoriaMetrics кластер нұсқасының негізгі құрамдастары vmstsorage болып табылады. Олардың N саны болуы мүмкін. Біздің жағдайда олардың әзірге 2-і бар.
Және vminsert бар. Бұл бізге мүмкіндік беретін прокси-сервер: біз айтқан барлық қоймалар арасында бөлшектеуді ұйымдастыру, сонымен қатар ол репликаға мүмкіндік береді, яғни сізде үзіндіге де, көшірмеге де ие боласыз.
Vminsert Prometheus ұсынған OpenTSDB, Graphite, InfluxDB және remoteWrite протоколдарын қолдайды.
Сондай-ақ vmselect бар. Оның негізгі міндеті - vmstorage-ге өту, олардан деректерді алу, бұл деректерді қайталау және оны клиентке беру.
Vmagent деген керемет нәрсе бар. Біз оны шынымен жақсы көреміз. Ол сізге дәл Прометей сияқты конфигурациялауға және бәрібір Прометей сияқты жасауға мүмкіндік береді. Яғни, ол әртүрлі нысандар мен қызметтерден көрсеткіштерді жинап, оларды vminsert қызметіне жібереді. Сонда бәрі сізге байланысты.
Тағы бір тамаша қызмет - vmalert, ол VictoriaMetrics-ті сервер ретінде пайдалануға, vminsert-тен өңделген деректерді алуға және оны vmselect-ке жіберуге мүмкіндік береді. Ол ескертулердің өзін, сондай-ақ ережелерді өңдейді. Ескертулер болған жағдайда, біз ескертуді alertmanager арқылы аламыз.
wmauth компоненті бар. Біз оны кластерлердің көп жалдау нұсқасы үшін авторизация жүйесі ретінде пайдалана аламыз немесе қолданбауымыз мүмкін (біз бұл туралы әлі шешкен жоқпыз). Ол Prometheus үшін remoteWrite мүмкіндігін қолдайды және url негізінде авторизациялай алады, дәлірек айтсақ, оның сіз жаза алатын немесе жаза алмайтын екінші бөлігі.
Сондай-ақ vmbackup, vmrestore бар. Бұл, шын мәнінде, барлық деректерді қалпына келтіру және сақтық көшірме жасау. S3, GCS, файлды орындай алады.
Біздің кластердің бірінші итерациясы карантин кезінде жасалды. Ол кезде реплика болмады, сондықтан біздің итерациямыз remoteWrite арқылы деректерді алатын екі түрлі және тәуелсіз кластерден тұрды.
Мұнда мен VictoriaMetrics бірыңғай түйінінен VictoriaMetrics кластерлік нұсқасына ауысқан кезде біз бұрынғыдай тұтынылатын ресурстармен қалдық деп ескертемін, яғни негізгісі жад. Біздің деректеріміз, яғни ресурстарды тұтыну шамамен осылай таратылды.
Мұнда көшірме әлдеқашан қосылған. Осының барлығын салыстырмалы түрде үлкен бір кластерге біріктірдік. Біздің барлық деректеріміз ортақ және қайталанады.
Бүкіл кластерде N кіру нүктесі бар, яғни Prometheus деректерді HAPROXY арқылы қоса алады. Міне, бізде бұл кіру нүктесі бар. Осы кіру нүктесі арқылы сіз Grafana жүйесінен кіре аласыз.
Біздің жағдайда, HAPROXY осы кластердің ішіндегі прокси-сервистерді таңдайтын, кірістіретін және басқа қызметтерді жүзеге асыратын жалғыз порт болып табылады. Біздің жағдайда бір мекенжай жасау мүмкін болмады, біз бірнеше кіру нүктелерін жасауымыз керек болды, өйткені VictoriaMetrics кластері жұмыс істейтін виртуалды машиналар бір бұлттық провайдердің әртүрлі аймақтарында орналасқан, яғни біздің бұлттың ішінде емес, сыртында. .
Бізде ескерту бар. Біз оны пайдаланамыз. Біз Prometheus ұсынған ескерту менеджерін қолданамыз. Біз Opsgenie және Telegram-ды ескертуді жеткізу арнасы ретінде қолданамыз. Telegram-да олар әзірлеушіден, мүмкін өнімнен бірдеңе, бірақ көбінесе инженерлерге қажет статистикалық нәрсе. Ал Опсгени сыншыл. Бұл қоңыраулар, оқиғаларды басқару.
Мәңгілік сұрақ: «Мониторингті кім қадағалайды?» Біздің жағдайда, мониторинг өзін бақылауды бақылайды, өйткені біз әрбір түйінде vmagent пайдаланамыз. Біздің түйіндеріміз бір провайдердің әртүрлі деректер орталықтары бойынша таратылғандықтан, әрбір деректер орталығының өз арнасы бар, олар тәуелсіз және бөлінген ми келсе де, біз әлі де ескертулер аламыз. Иә, олардың саны көбірек болады, бірақ жоққа қарағанда көбірек ескерту алған жақсы.
Біз тізімді HA енгізуімен аяқтаймыз.
Әрі қарай VictoriaMetrics қауымдастығымен байланыс тәжірибесін атап өткім келеді. Бұл өте оң болды. Жігіттер жауап береді. Олар ұсынылған әрбір істі зерделеуге тырысады.
Мен GitHub-те мәселелерді бастадым. Олар өте тез шешілді. Толық жабылмаған тағы бірнеше мәселе бар, бірақ мен кодтан осы бағытта жұмыс жүргізіліп жатқанын көремін.
Итерациялар кезінде мен үшін басты ауыртпалық болды, егер мен түйінді өшірсем, онда алғашқы 30 секундта vminsert сервері жоқ екенін түсінбеді. Бұл енді шешілді. Және бір-екі секундта деректер барлық қалған түйіндерден алынады және сұрау сол жетіспейтін түйінді күтуді тоқтатады.
Бір кездері біз VictoriaMetrics-тің VictoriaMetrics операторы болғанын қаладық. Біз оны күттік. Біз қазір VictoriaMetrics операторы үшін барлық алдын ала есептеу ережелерін және т.б. қабылдау үшін құрылымды белсенді түрде жасап жатырмыз. Prometheus, өйткені біз Prometheus операторымен бірге келетін ережелерді белсенді түрде қолданамыз.
Кластерді енгізуді жақсарту бойынша ұсыныстар бар. Мен оларды жоғарыда атап өттім.
Мен шынымен де төмендеткім келеді. Біздің жағдайда төмендетілген іріктеу тек трендтерді көру үшін қажет. Дөрекі сөзбен айтқанда, бір метрика мен үшін күндізгі уақытта жеткілікті. Бұл үрдістер бір жылға, үш, бес, он жылға қажет. Және бір метрикалық мән жеткілікті.
- Біз Прометейді қолданғанда кейбір әріптестеріміз сияқты ауырсынуды білдік.
- Біз VictoriaMetrics-ті өзіміз таңдадық.
- Ол тігінен де, көлденеңінен де жақсы таралады.
- Біз әртүрлі компоненттерді кластердегі түйіндердің әртүрлі сандарына тарата аламыз, оларды жадпен шектей аламыз, жадты қоса аламыз және т.б.
VictoriaMetrics-ті үйде қолданамыз, өйткені ол бізге өте ұнады. Бұл болды және болды.
VictoriaMetrics чатына арналған бірнеше QR коды, менің контактілерім, LeroyMerlin техникалық радары.
Ақпарат көзі: www.habr.com