VictoriaMetrics и частен облачен мониторинг. Павел Колобаев

VictoriaMetrics е бърза и мащабируема СУБД за съхранение и обработка на данни под формата на времеви серии (записът формира време и набор от стойности, съответстващи на това време, например, получени чрез периодично проучване на състоянието на сензорите или събиране на показатели).

Казвам се Павел Колобаев. DevOps, SRE, LeroyMerlin, всичко е като код - всичко е за нас: за мен и за други служители на LeroyMerlin.

https://bit.ly/3jf1fIK

Има облак, базиран на OpenStack. Има малка връзка към техническия радар.

Той е изграден на базата на Kubernetes желязо, както и на всички свързани услуги с OpenStack и регистриране.

Това е схемата, която имахме в разработка. Когато разработихме всичко това, имахме оператора Prometheus, който съхранява данни в самия клъстер K8s. Той автоматично намира това, което трябва да се изтърка и го слага под краката си, грубо казано.

Ще трябва да преместим всички данни извън клъстера Kubernetes, защото ако нещо се случи, тогава трябва да разберем какво и къде.

Първото решение е да използваме федерация, когато имаме Prometheus от трета страна, когато отидем до клъстера Kubernetes чрез механизма за федерация.

Но тук има някои дребни проблеми. В нашия случай проблемите започнаха, когато имахме 250 000 метрики, а когато станаха 400 000 метрики, осъзнахме, че не можем да работим така. Увеличихме scrape_timeout до 25 секунди.

Защо трябваше да правим това? Prometheus започва да отчита времето за изчакване от началото на момента на вземане. Няма значение, че данните продължават да текат. Ако през този определен период от време данните не са обединени и сесията не е затворена чрез http, тогава се счита, че сесията е неуспешна и данните не попадат в самия Prometheus.

Всеки знае графиките, които получаваме, когато част от данните липсват. Графиката е разкъсана и не сме доволни от нея.

Следващата опция е шардинг, базиран на два различни Prometheus чрез един и същ механизъм за обединяване.

Например, просто вземете и ги разделете по име. Това също може да се използва, но решихме да продължим.

Сега ще трябва по някакъв начин да обработим тези фрагменти. Можете да вземете promxy, който се спуска в областта на шарда, умножава данните. Работи с два шарда като една входна точка. Това може да се реализира чрез promxy, но засега е твърде сложно.

Първият вариант – искаме да се откажем от механизма на федерацията, защото е много бавен.

Разработчиците на Prometheus изрично казват: „Момчета, използвайте друга TimescaleDB, защото няма да поддържаме дългосрочно съхранение на метрики.“ Това не е тяхна задача.

Записваме на лист, че трябва да разтоварим още навън, за да не складираме всичко на едно място.

Вторият недостатък е консумацията на памет. Да, разбирам, че мнозина ще кажат, че през 2020 г. няколко гигабайта памет струват стотинка, но въпреки това.

Сега имаме dev и prod среда. В разработката това е около 9 гигабайта на 350 000 показателя. В прод това са 14 гигабайта с малки 780 000 метрики. В същото време имаме само 30 минути време за задържане. Това е лошо. И сега ще обясня защо.

Правим изчисление, тоест с милион и половина показатели и вече сме близо до тях, на етапа на проектиране получаваме 35-37 гигабайта памет. Но вече с 4 милиона показателя вече са необходими около 90 гигабайта памет. Тоест, изчислено е по формулата, предоставена от разработчиците на Prometheus. Разгледахме корелацията и разбрахме, че не искаме да платим няколко милиона за сървър само за наблюдение.

Ние не само ще увеличим броя на машините, но и наблюдаваме самите виртуални машини. Следователно, колкото повече виртуални машини, толкова повече метрики от различни видове и т.н. Ще имаме специален растеж на нашия клъстер по отношение на метрики.

С дисковото пространство тук не всичко е толкова тъжно, но бих искал да го подобря. Получихме общо 15 гигабайта за 120 дни, от които 100 са компресирани данни, 20 са некомпресирани данни, но винаги искате по-малко.

Съответно записваме още една точка - това е голяма консумация на ресурси, която все още искаме да спестим, защото не искаме нашият мониторингов клъстер да изяжда повече ресурси от нашия клъстер, който управлява OpenStack.

Има още един недостатък на Prometheus, който идентифицирахме за себе си, това е поне някакъв вид ограничение на паметта. С Прометей тук всичко е много по-лошо, защото той изобщо няма такива обрати. Използването на docker limit също не е опция. Ако внезапно вашият RAF падне и има 20-30 гигабайта, тогава ще отнеме много време, за да се повиши.

Това е друга причина, поради която Prometheus не е подходящ за нас, т.е. не можем да ограничим потреблението на памет.

Би било възможно да се измисли такава схема. Нуждаем се от тази схема, за да организираме HA клъстер. Искаме нашите показатели да са достъпни по всяко време и навсякъде, дори ако сървърът, който съхранява тези показатели, се срине. И затова трябва да изградим такава схема.

Тази схема казва, че ще имаме дублиране на шардове и съответно дублиране на разходите за консумирани ресурси. Може да се мащабира почти хоризонтално, но въпреки това консумацията на ресурси ще бъде адска.

Недостатъци по ред, във формата, в която ги написахме за себе си:

• Изисква качване на показатели навън.
• Висока консумация на ресурси.
• Не можете да ограничите потреблението на памет.
• Сложна и ресурсоемка реализация на HA.

За себе си решихме, че се отдалечаваме от Прометей като хранилище.

Набелязахме допълнителни изисквания за себе си, от които се нуждаем. Това:

• Това е поддръжка на promql, защото вече е написано много за Prometheus: заявки, предупреждения.
• И тогава имаме Grafana, който вече е написан по същия начин под Prometheus като бекенд. Не искам да пренаписвам таблата за управление.
• Искаме да изградим нормална HA архитектура.
• Искаме да намалим потреблението на всякакви ресурси.
• Има още един малък нюанс. Не можем да използваме различни видове облачни системи за събиране на показатели. Засега не знаем какво ще влезе в тези показатели. И тъй като всичко може да лети там, трябва да се ограничим до локално разположение.

Изборът беше малък. Събрали сме всичко, с което сме имали опит. Разгледахме страницата на Prometheus в раздела за интеграция, прочетохме куп статии, разгледахме какво е общодостъпно. А за себе си избрахме VictoriaMetrics като заместител на Prometheus.

Защо? защото:

• Възможност за promql.
• Има модулна архитектура.
• Не изисква промени в Grafana.
• И най-важното е, че вероятно ще предоставим съхранение на метрики в рамките на нашата компания като услуга, така че предварително търсим различни видове ограничения, така че потребителите да могат да използват всички ресурси на клъстера по някакъв ограничен начин, защото има шанс че ще multitenancy.

Правим първото сравнение. Взимаме същия Прометей вътре в клъстера, външен Прометей отива при него. Добавяме чрез remoteWrite VictoriaMetrics.

Веднага ще направя резервация, че тук уловихме леко увеличение на потреблението на процесора от VictoriaMetrics. Уикито на VictoriaMetrics казва кои параметри са най-подходящи. Проверихме ги. Те много добре намалиха консумацията на процесора.

В нашия случай консумацията на памет на Prometheus, който се намира в клъстер на Kubernetes, не се е увеличила значително.

Сравняваме два източника на едни и същи данни. В Prometheus виждаме все същите липсващи данни. Във VictoriaMetrics всичко е наред.

Резултати от тестове с дисково пространство. Ние от Prometheus получихме общо 120 гигабайта. В VictoriaMetrics вече получаваме 4 гигабайта на ден. Има малко по-различен механизъм от този, който сте свикнали да виждате в Prometheus. Тоест данните вече са доста добре компресирани за ден, за половин час. Те вече са добре пожънати за един ден, за половин час, въпреки факта, че по-късно данните ще бъдат обединени. В резултат на това спестихме дисково пространство.

Освен това спестяваме от потреблението на ресурси на паметта. По време на тестовете имахме Prometheus, разположен на виртуална машина - 8 ядра, 24 гигабайта. Прометей яде почти всичко. Той падна върху OOM Killer. В същото време в него бяха изсипани само 900 000 активни метрики. Това е около 25 000-27 000 метрики в секунда.

VictoriaMetrics работеше на двуядрена виртуална машина с 8 гигабайта RAM. Успяхме да накараме VictoriaMetrics да работи добре, като променихме някои неща на 8GB машина. В резултат на това останахме в рамките на 7 гигабайта. В същото време получихме скорост на доставка на съдържание, т.е. показатели, дори по-високи от тези на Prometheus.

Процесора е много по-добър от Prometheus. Тук Prometheus консумира 2,5 ядра, а VictoriaMetrics консумира само 0,25 ядра. В началото - 0,5 ядра. Като се слее, стига до едно ядро, но това е изключително, изключително рядко.

В нашия случай изборът падна върху VictoriaMetrics по очевидни причини, искахме да спестим пари и спестихме.

Зачеркваме две точки веднага - това е разтоварването на показателите и голямото потребление на ресурси. И остава да решим две точки, които все пак оставихме за себе си.

Тук ще направя резервация веднага, ние считаме VictoriaMetrics за хранилище на метрики. Но тъй като най-вероятно ще предоставим VictoriaMetrics като хранилище за всички Leroy, трябва да ограничим тези, които ще използват този клъстер, така че да не ни го предоставят.

Има чудесен параметър, който ви позволява да ограничавате по време, по количество данни и по време на изпълнение.

Освен това има отлична опция, която ви позволява да ограничите потреблението на памет, като по този начин можем да намерим самия баланс, който ще ни позволи да постигнем нормална скорост и адекватно потребление на ресурси.

Минус още една точка, тоест зачеркваме точката - не можете да ограничите потреблението на памет.

В първите итерации тествахме единичния възел на VictoriaMetrics. След това преминаваме към клъстерната версия на VictoriaMetrics.

Тук имаме свободни ръце по темата за разделянето на различни услуги във VictoriaMetrics, в зависимост от това какво ще въртят и какви ресурси ще консумират. Това е много гъвкаво и удобно решение. Ние сами сме го използвали.

Основните компоненти на клъстерната версия на VictoriaMetrics са vmstsorage. Може да има N брой. В нашия случай има 2 от тях.

И има vminsert. Това е прокси сървър, който ни позволява да: организираме шардинг между всички хранилища, за които му казахме, и позволява друга реплика, т.е. ще имате както шардинг, така и реплика.

Vminsert поддържа протоколите OpenTSDB, Graphite, InfluxDB и remoteWrite от Prometheus.

Има и vmselect. Основната му задача е да отиде до vmstorage, да получи данни от тях, да дедуплира тези данни и да ги даде на клиента.

Има прекрасно нещо като vmagent. Много я харесваме. Тя ви позволява да конфигурирате точно като Prometheus и пак да правите всичко точно като Prometheus. Тоест, той събира показатели от различни обекти и услуги и ги изпраща на vminsert. След това всичко зависи от вас.

Друга страхотна услуга е vmalert, която ви позволява да използвате VictoriaMetrics като бекенд, да получавате обработени данни от vminsert и да изпращате обработени данни до vmselect. Той обработва самите сигнали, както и правилата. В случай на предупреждения, ние получаваме предупреждение чрез alertmanager.

Има wmauth компонент. Вероятно ще го използваме и може би не (все още не сме решили за това) като система за оторизация за версии на клъстери с множество клиенти. Той поддържа remoteWrite за Prometheus и може да упълномощава на базата на url, или по-скоро втората част от него, където можете или не можете да пишете.

Има и vmbackup, vmrestore. Това всъщност е възстановяването и архивирането на всички данни. Възможност за S3, GCS, файл.

Първата итерация на нашия клъстер беше направена по време на карантина. По това време нямаше реплика, така че нашата итерация се състоеше от два различни и независими клъстера, в които получихме данни чрез remoteWrite.

Тук ще направя уговорката, че когато преминахме от VictoriaMetrics Single Node към VictoriaMetrics Cluster Version, все още останахме на същите консумирани ресурси, т.е. основният е паметта. Приблизително по този начин бяха разпределени нашите данни, т.е. потреблението на ресурси.

Тук вече е добавена реплика. Комбинирахме всичко това в един относително голям клъстер. Всички данни се разделят и репликират.

Целият клъстер има N входни точки, т.е. Prometheus може да добавя данни чрез HAPROXY. Ето нашата входна точка. И през тази входна точка можете да влезете с Grafana.

В нашия случай HAPROXY е единственият порт, който прокси избира, вмъква и други услуги в този клъстер. В нашия случай беше невъзможно да направим един адрес, трябваше да направим няколко входни точки, тъй като самите виртуални машини, на които работи клъстерът VictoriaMetrics, се намират в различни зони на един и същ облачен доставчик, т.е. не в нашия облак , но навън.

Имаме сигнал. Ние го използваме. Ние използваме alertmanager от Prometheus. Използваме Opsgenie и Telegram като канал за доставка на предупреждения. В Telegram се изливат от dev, може би нещо от prod, но по-скоро нещо статистическо, което трябва на инженерите. И Opsgenie е критичен. Това са обаждания, управление на инциденти.

Вековният въпрос: "Кой следи мониторинга?". В нашия случай наблюдението наблюдава самото наблюдение, защото използваме vmagent на всеки възел. И тъй като нашите възли се намират в различни центрове за данни на един и същ доставчик, всеки център за данни има свой собствен канал, те са независими и дори да дойде разделен мозък, пак ще получаваме сигнали. Да, ще има повече от тях, но е по-добре да получавате повече сигнали, отколкото никакви.

Завършваме нашия списък с внедряването на HA.

Освен това бих искал да отбележа опита от общуването с общността на VictoriaMetrics. Оказа се много положително. Момчетата са отзивчиви. Стараят се да вникнат във всеки случай, който се предлага.

Създадох проблеми в GitHub. Те бяха разрешени много бързо. Има още няколко проблема, които не са напълно затворени, но вече виждам от кода, че се работи в тази посока.

Основната болка по време на итерациите за мен беше, че ако отрежа възела, след това за първите 30 секунди vminsert не можеше да разбере, че няма бекенд. Сега вече е решено. И буквално за секунда или две данните се вземат от всички останали възли и заявката спира да чака този липсващ възел.

Искахме в даден момент от VictoriaMetrics да бъде оператор на VictoriaMetrics. Чакахме го. Сега активно изграждаме обвързване върху оператора VictoriaMetrics, за да вземем всички правила за предварително изчисление и т.н. Prometheus, защото доста активно използваме правилата, които идват с оператора Prometheus.

Има предложения за подобряване на изпълнението на клъстера. Очертал съм ги по-горе.

И аз също наистина искам намаляване на дискретизацията. В нашия случай намаляването на дискретизацията е необходимо изключително за гледане на тенденции. Грубо казано, една метрика ми е достатъчна през деня. Тези тенденции са необходими за година, три, пет, десет години. И една метрична стойност е достатъчна.

• Познахме болката, както някои от нашите колеги, докато използвахме Prometheus.
• Ние избрахме VictoriaMetrics за себе си.
• Мащабира се доста добре както вертикално, така и хоризонтално.
• Можем да разпределим различни компоненти на различен брой възли в клъстера, да ги ограничим по отношение на паметта, да добавим памет и т.н.

Вкъщи ще използваме VictoriaMetrics, защото много ни хареса. Ето какво се случи и какво се случи.

https://t.me/VictoriaMetrics_ru1

Няколко qr кода за чат на VictoriaMetrics, моите контакти, технически радар LeroyMerlin.

Източник: www.habr.com