VictoriaMetrics е брз и скалабилен DBMS за складирање и обработка на податоци во форма на временска серија (записот се состои од време и збир на вредности што одговараат на ова време, на пример, добиени преку периодично испитување на статусот на сензорите или збирка на метрика).
Јас се викам Колобаев Павел. DevOps, SRE, LeroyMerlin, сè е како код - сè е за нас: за мене и за другите вработени во LeroyMerlin.
Постои облак базиран на OpenStack. Има мала врска до техничкиот радар.
Изграден е на хардверот Kubernetes, како и на сите поврзани услуги за OpenStack и логирање.
Ова е шемата што ја имавме во развој. Кога го развивавме сето ова, имавме оператор Prometheus кој чуваше податоци во самиот кластер K8s. Тој автоматски го наоѓа она што треба да се исчисти и го става под нозете, грубо кажано.
Ќе треба да ги преместиме сите податоци надвор од кластерот Kubernetes, бидејќи ако нешто се случи, треба да разбереме што и каде.
Првото решение е да користиме федерација кога имаме прометеј од трета страна, кога одиме во кластерот Кубернетес преку механизмот на федерација.
Но, тука има некои мали проблеми. Во нашиот случај, проблемите започнаа кога имавме 250 метрика, а кога имаше 000 метрика, сфативме дека не можеме да работиме така. Го зголемивме scrape_timeout на 400 секунди.
Зошто моравме да го направиме ова? Прометеј почнува да го брои тајмаутот од почетокот на оградата. Не е важно што податоците сè уште течат. Доколку во овој одреден временски период податоците не се спојат и сесијата не се затвори преку http, тогаш сесијата се смета дека е неуспешна и податоците не влегуваат во самиот Прометеј.
На сите им се познати графиконите што ги добиваме кога недостасуваат некои податоци. Распоредот е скинат и не сме задоволни со ова.
Следната опција е сердинг врз основа на два различни Прометеј преку ист механизам за федерација.
На пример, само земете ги и исечете ги по име. Ова исто така може да се искористи, но решивме да продолжиме понатаму.
Сега ќе треба некако да ги обработиме овие фрагменти. Може да земете promxy, кој оди во делот за фрагменти и ги множи податоците. Работи со две парчиња како единствена влезна точка. Ова може да се имплементира преку промкси, но сепак е премногу тешко.
Првата опција е дека сакаме да го напуштиме механизмот на федерацијата бидејќи е многу бавен.
Програмерите на Prometheus јасно велат: „Момци, користете различен TimescaleDB бидејќи нема да поддржуваме долгорочно складирање на метрика“. Ова не е нивна задача.
Запишуваме на парче хартија што треба уште да го растовараме надвор, за да не складираме сè на едно место.
Вториот недостаток е потрошувачката на меморија. Да, разбирам дека многумина ќе речат дека во 2020 година пар гигабајти меморија чини еден денар, но сепак.
Сега имаме развојна и прод околина. Во dev тоа е околу 9 гигабајти за 350 метрика. Во продукција, тоа е 000 гигабајти и нешто повеќе од 14 метрика. Во исто време, нашето време на задржување е само 780 минути. Ова е лошо. И сега ќе објаснам зошто.
Правиме пресметка, односно со милион и пол метрика и веќе сме блиску до нив, во фазата на дизајнирање добиваме 35-37 гигабајти меморија. Но, веќе 4 милиони метрика бараат околу 90 гигабајти меморија. Тоа е, тоа беше пресметано користејќи ја формулата обезбедена од програмерите на Прометеј. Ја разгледавме корелацијата и сфативме дека не сакаме да платиме неколку милиони за сервер само за следење.
Не само што ќе го зголемиме бројот на машини, туку ги следиме и самите виртуелни машини. Затоа, колку повеќе виртуелни машини, толку повеќе метрика од различни видови итн. Ќе имаме посебен раст на нашиот кластер во однос на метриката.
Со простор на дискот, не е сè толку лошо овде, но би сакал да го подобрам. Добивме вкупно 15 гигабајти за 120 дена, од кои 100 се компресирани податоци, 20 се некомпресирани податоци, но секогаш сакаме помалку.
Според тоа, запишуваме уште една точка - ова е голема потрошувачка на ресурси, која сè уште сакаме да ја зачуваме, бидејќи не сакаме нашиот кластер за следење да троши повеќе ресурси од нашиот кластер, кој управува со OpenStack.
Има уште еден недостаток на Прометеј, кој сами го идентификувавме, ова е барем некакво ограничување на меморијата. Кај Прометеј, овде сè е многу полошо, бидејќи воопшто нема такви пресврти. Користењето ограничување во docker исто така не е опција. Ако одеднаш ви падна RAF и има 20-30 гигабајти, тогаш ќе треба многу долго време да се крене.
Ова е уште една причина зошто Прометеј не ни е соодветен, односно не можеме да ја ограничиме потрошувачката на меморија.
Би било можно да се излезе со таква шема. Оваа шема ни треба за да организираме кластер за HA. Сакаме нашите метрики да бидат достапни секогаш и секаде, дури и ако серверот што ги складира овие метрики падне. И така ќе треба да изградиме таква шема.
Оваа шема вели дека ќе имаме дуплирање на парчиња и, соодветно, дуплирање на трошоците за потрошените ресурси. Може да се скалира речиси хоризонтално, но сепак потрошувачката на ресурси ќе биде пеколна.
Недостатоци по редослед во форма во која самите ги запишавме:
- Бара надворешно поставување метрика.
- Висока потрошувачка на ресурси.
- Не постои начин да се ограничи потрошувачката на меморија.
- Комплексна и интензивна за ресурси имплементација на ХА.
За себе решивме дека се оддалечуваме од Прометеј како складиште.
Утврдивме дополнителни барања за себе кои ни се потребни. Ова:
- Ова е поддршка за promql, бидејќи за Прометеј веќе се напишани многу работи: прашања, предупредувања.
- И тогаш ја имаме Графана, која веќе на ист начин е напишана за Прометеј како бекенд. Не сакам да ги препишувам контролните табли.
- Сакаме да изградиме нормална HA архитектура.
- Сакаме да ја намалиме потрошувачката на какви било ресурси.
- Постои уште една мала нијанса. Не можеме да користиме различни типови системи за собирање метрика на облак. Сè уште не знаеме што ќе спаѓа во овие метрики. И бидејќи сè може да лета таму, мораме да се ограничиме на локалното поставување.
Имаше мал избор. Собравме се што имавме искуство. Ја погледнавме страницата Прометеј во делот за интеграција, прочитавме еден куп написи и видовме што има таму. И за себе ја избравме Викторија Метрикс како замена за Прометеј.
Зошто? Бидејќи:
- Може да прави promql.
- Постои модуларна архитектура.
- Не бара промени во Grafana.
- И што е најважно, веројатно ќе обезбедиме складирање на метрика во нашата компанија како услуга, така што однапред гледаме кон ограничувања од различни видови за да можат корисниците да ги користат сите ресурси на кластерот на некој ограничен начин, бидејќи има шанса дека тоа ќе мултитана.
Да ја направиме првата споредба. Го земаме истиот Прометеј внатре во кластерот, надворешен Прометеј оди до него. Додајте преку далечинскоWrite VictoriaMetrics.
Веднаш ќе направам резервација дека овде забележавме мало зголемување на потрошувачката на процесорот од VictoriaMetrics. Викито на VictoriaMetrics ви кажува кои параметри се најдобри. Ги проверивме. Многу добро ја намалија потрошувачката на процесорот.
Во нашиот случај, потрошувачката на меморија на Prometheus, која се наоѓа во кластерот Kubernetes, не се зголеми значително.
Споредуваме два извори на податоци со исти податоци. Во Прометеј ги гледаме истите податоци што недостасуваат. Сè е во ред во VictoriaMetrics.
Резултати од тестот за простор на дискот. Ние во Прометеј добивме вкупно 120 гигабајти. Во VictoriaMetrics веќе добиваме 4 гигабајти дневно. Има малку поинаков механизам од она што сме навикнати да го гледаме кај Прометеј. Односно, податоците се веќе доста добро компресирани за еден ден, за половина час. Тие веќе се добро собрани за еден ден, за половина час, и покрај тоа што податоците сепак ќе бидат изгубени подоцна. Како резултат на тоа, заштедивме простор на дискот.
Заштедуваме и на потрошувачката на мемориски ресурси. За време на тестирањето, го имавме Prometheus распореден на виртуелна машина - 8 јадра, 24 гигабајти. Прометеј јаде речиси сè. Тој падна на ООМ убиец. Во исто време, во него беа истурени само 900 активни метрики. Ова е околу 000-25 метрика во секунда.
Ја работевме VictoriaMetrics на виртуелна машина со две јадра со 8 гигабајти RAM меморија. Успеавме да ја натераме VictoriaMetrics да работи добро со тоа што се зафативме со неколку работи на машина од 8 GB. На крајот го задржавме на 7 гигабајти. Во исто време, брзината на испорака на содржината, т.е. метриката, беше дури и поголема од онаа на Прометеј.
Процесорот стана многу подобар во споредба со Прометеј. Овде Prometheus троши 2,5 јадра, а VictoriaMetrics само 0,25 јадра. На почеток - 0,5 јадра. Како што се спојува, достигнува едно јадро, но ова е исклучително, исклучително ретко.
Во нашиот случај, изборот падна на VictoriaMetrics од очигледни причини; сакавме да заштедиме пари и го направивме.
Ајде веднаш да прецртаме две точки - поставување на метрика и голема потрошувачка на ресурси. И само треба да одлучиме две точки кои ни остануваат уште за нас.
Еве веднаш ќе направам резервација, ВикторијаМетрикс ја сметаме за складирање на метрика. Но, бидејќи најверојатно ќе обезбедиме VictoriaMetrics како складиште за целиот Лерој, треба да ги ограничиме оние што ќе го користат овој кластер за да не ни го дадат.
Има прекрасен параметар кој ви овозможува да се ограничите по време, по обем на податоци и по време на извршување.
Постои и одлична опција која ни овозможува да ја ограничиме потрошувачката на меморија, со што можеме да го најдеме самиот баланс што ќе ни овозможи да добиеме нормална работна брзина и соодветна потрошувачка на ресурси.
Минус уште една точка, односно пречкртајте ја точката - не можете да ја ограничите потрошувачката на меморија.
Во првите повторувања, го тестиравме VictoriaMetrics Single Node. Следно, преминуваме кон верзијата на кластерот VictoriaMetrics.
Овде имаме слободна рака да одвоиме различни услуги во VictoriaMetrics во зависност од тоа на што ќе работат и кои ресурси ќе ги трошат. Ова е многу флексибилно и практично решение. Го искористивме ова на себе.
Главните компоненти на верзијата на кластерот VictoriaMetrics се vmstsorage. Може да има N број од нив. Во нашиот случај досега има 2 од нив.
И таму е vminsert. Ова е прокси-сервер кој ни овозможува: да организираме раздвојување помеѓу сите складишта за кои кажавме, а исто така дозволува реплика, односно ќе имате и раздвојување и реплика.
Vminsert поддржува OpenTSDB, Graphite, InfluxDB и remoteWrite протоколи од Prometheus.
Постои и vmselect. Неговата главна задача е да отиде во vmstorage, да прима податоци од нив, да ги дедупликира овие податоци и да му ги даде на клиентот.
Постои една прекрасна работа наречена vmagent. Навистина ни се допаѓа. Ви овозможува да конфигурирате точно како Прометеј и сепак да правите сè токму како Прометеј. Односно, собира метрика од различни ентитети и услуги и ги испраќа до vminsert. Тогаш сè зависи од вас.
Друга одлична услуга е vmalert, која ви овозможува да користите VictoriaMetrics како заднина, да примате обработени податоци од vminsert и да ги испраќате до vmselect. Ги обработува самите предупредувања, како и правилата. Во случај на предупредувања, предупредувањето го добиваме преку alertmanager.
Постои wmauth компонента. Можеме или не (сè уште не сме одлучиле за ова) да го користиме како систем за овластување за верзијата на кластерите за повеќенаемни. Поддржува remoteWrite за Prometheus и може да авторизира врз основа на URL-то, поточно вториот дел од него, каде што можете или не можете да пишувате.
Има и vmbackup, vmrestore. Ова е, во суштина, реставрација и резервна копија на сите податоци. Може да прави S3, GCS, датотека.
Првата итерација на нашиот кластер беше направена за време на карантин. Во тоа време, немаше реплика, па нашата итерација се состоеше од два различни и независни кластери во кои примавме податоци преку remoteWrite.
Овде ќе направам резервација дека кога се префрливме од VictoriaMetrics Single Node во VictoriaMetrics Cluster Version, сепак останавме со истите потрошени ресурси, односно главната е меморијата. Отприлика вака беа дистрибуирани нашите податоци, односно потрошувачката на ресурси.
Овде веќе е додадена реплика. Сето ова го комбиниравме во еден релативно голем кластер. Сите наши податоци се и разделени и реплицирани.
Целиот кластер има N влезни точки, т.е. Прометеј може да додава податоци преку HAPROXY. Овде ја имаме оваа влезна точка. И преку оваа влезна точка можете да се најавите од Графана.
Во нашиот случај, HAPROXY е единствената порта што проксите ги избираат, вметнуваат и други услуги во овој кластер. Во нашиот случај, беше невозможно да се направи една адреса; моравме да направиме неколку влезни точки, бидејќи самите виртуелни машини на кои работи кластерот VictoriaMetrics се наоѓаат во различни зони на истиот провајдер на облак, т.е. не внатре во нашиот облак, туку надвор .
Имаме предупредување. Ние го користиме. Ние користиме alertmanager од Прометеј. Ги користиме Opsgenie и Telegram како канал за испорака на предупредувања. Во Телеграм се влеваат од dev, можеби нешто од прод, но најмногу нешто статистички, потребно на инженерите. А Опсгени е критична. Тоа се повици, управување со инциденти.
Вечното прашање: „Кој го следи мониторингот? Во нашиот случај, мониторингот го следи самиот мониторинг, бидејќи користиме vmagent на секој јазол. И бидејќи нашите јазли се дистрибуираат низ различни центри за податоци на истиот провајдер, секој центар за податоци има свој канал, тие се независни, па дури и ако пристигне поделен мозок, ние сепак ќе добиваме предупредувања. Да, ќе ги има повеќе, но подобро е да добивате повеќе предупредувања отколку ниеден.
Ја завршуваме нашата листа со имплементација на HA.
И понатаму би сакал да го забележам искуството од комуникацијата со заедницата на VictoriaMetrics. Испадна многу позитивно. Момците реагираат. Тие се обидуваат да навлезат во секој случај што се нуди.
Почнав проблеми на GitHub. Тие беа решени многу брзо. Има уште неколку прашања кои не се целосно затворени, но од кодот веќе можам да видам дека се работи во оваа насока.
Главната болка за мене за време на повторувањата беше тоа што ако исклучам јазол, тогаш во првите 30 секунди vminsert не може да разбере дека нема заднина. Ова сега е решено. И буквално за секунда или две, податоците се земаат од сите преостанати јазли, а барањето престанува да го чека тој јазол што недостасува.
Во одреден момент сакавме VictoriaMetrics да биде оператор на VictoriaMetrics. Го чекавме. Сега активно градиме рамка за операторот VictoriaMetrics да ги преземе сите правила за претходно пресметување итн. Prometheus, бидејќи доста активно ги користиме правилата што доаѓаат со операторот Prometheus.
Има предлози за подобрување на имплементацијата на кластерот. Ги наведов погоре.
И навистина сакам да симнам примерок. Во нашиот случај, намалувањето на примерокот е потребно исклучиво за трендовите на гледање. Грубо кажано, една метрика ми е доволна во текот на денот. Овие трендови се потребни за една година, три, пет, десет години. И една метричка вредност е сосема доволна.
- Знаеме болка, како и некои наши колеги, кога го користиме Прометеј.
- Ние ја избравме VictoriaMetrics за себе.
- Добро се скали и вертикално и хоризонтално.
- Можеме да дистрибуираме различни компоненти на различен број јазли во кластерот, да ги ограничиме по меморија, да додаваме меморија итн.
Дома ќе користиме VictoriaMetrics затоа што навистина ни се допадна. Ова беше и што стана.
Неколку QR кодови за разговор на VictoriaMetrics, мои контакти, технички радар на LeroyMerlin.
Извор: www.habr.com