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 среда. В dev това е около 9 гигабайта за 350 000 метрики. В prod - 14 гигабайта с малко за 780 000 метрики. При това retention time имаме само 30 минути. Това е лошо. И сега ще обясня защо.

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

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

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

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

Има още един недостатък на Prometheus, който установихме – това е все пак някакво ограничение по памет. С Prometheus тук е много по-лошо, защото той изобщо няма такива настройки. Използването на ограничение в Docker също не е вариант. Ако случайно RAFA падне и там са 20-30 гигабайта, ще отнеме много дълго време да се възстанови.

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

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

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

Недостатъците по реда, по който сме ги записали:

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

Решихме, че се отказваме от Prometheus като хранилище.

Определихме си още допълнителни изисквания, които са ни необходими. Те са:

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

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

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

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

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

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

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

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

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

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

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

Положението с CPU стана значително по-добро спрямо Prometheus. Тук Prometheus изразходва 2,5 ядра, а VictoriaMetrics само 0,25 ядра. На старта – 0,5 ядра. С напредването на обединенията стига до едно ядро, но това се случва изключително рядко.

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

Изключваме веднага две точки – износ на метрики и високото потребление на ресурси. Остават ни да решим две точки, които все още сме оставили за себе си.

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

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

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

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

В началните итерации тествахме VictoriaMetrics Single Node. След това преминаваме към VictoriaMetrics Cluster Version.

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

Основните компоненти на VictoriaMetrics Cluster Version са vmstorage. Може да има N брой. В нашия случай за сега има 2.

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

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

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

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

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

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

Има още vmbackup, vmrestore. Това по същество е възстановяване и резервно копие на всички данни. Поддържа S3, GCS, file.

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

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

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

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

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

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

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

Завършваме нашия списък с реализиране на HA.

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

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

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

В某 момент искахме от VictoriaMetrics да бъде VictoriaMetrics оператор. Изчакахме го. В момента активно изграждаме обвивка над VictoriaMetrics оператора, за да вградим всички предварително изчислени правила и т.н. Prometheus, тъй като активно използваме правилата, които идват с оператора Prometheus.

Има предложения за подобрение на кластерната реализация. Изложих ги по-горе.

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

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

Ще използваме VictoriaMetrics при нас, защото много ни хареса. Ето какво беше и какво стана.

https://t.me/VictoriaMetrics_ru1

Пара qr-кода на чата VictoriaMetrics, моите контакти, техразделът LeroyMerlin.

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