VictoriaMetrics — швидка та масштабована СУБД для зберігання та обробки даних у формі часового ряду (запис утворює час і набір відповідних цьому часу значень, наприклад, отриманих через періодичне опитування стану датчиків або збирання метрик).
Мене звуть Колобаєв Павло. DevOps, SRE, LeroyMerlin, все як код – це все про нас: про мене та інших співробітників LeroyMerlin.
Є хмара на базі OpenStack. Там невелике посилання на техрадар.
Побудовано воно на базі заліза Kubernetes, а також на всіх супутніх сервісах OpenStack та логування.
Ось така схема у нас була на розробці. Коли ми все це розробляли, у нас був оператор Prometheus, який зберігав дані всередині самого кластера K8s. Він автоматично знаходить те, що потрібно відшкрябати і складає собі під ноги, грубо кажучи.
Всі дані нам потрібно буде винести за межі кластера Kubernetes, тому що якщо щось трапиться, ми повинні розуміти, що і де.
Перше рішення – ми використовуємо federation, коли ми є сторонній Prometheus, коли ми ходимо в кластер Kubernetes через механізм federation.
Але тут виходять невеликі проблеми. У нашому випадку проблеми почалися, коли ми мали 250 000 метрик, а коли стало 400 000 метрик, зрозуміли, що так працювати не можемо. Ми збільшили scrape_timeout до 25 секунд.
Чому це нам довелося зробити? Prometheus починає відраховувати час тайм-ауту з моменту забору. І не важливо, що дані все ще ллються. Якщо за цей вказаний проміжок часу дані не злилися і сесія не буде закрита по http, то вважається, що сесія провальна та дані не потрапляють до самої Prometheus.
Всі знайомі графіки, які ми отримуємо, коли частина даних відсутні. Графіки рвані і нас це не влаштовує.
Наступний варіант – це шардування на основі двох різних Prometheus через той самий механізм federation.
Наприклад, просто взяти і на ім'я їх відшардувати. Це можна також використати, але ми вирішили рухатися далі.
Нам доведеться тепер ці шарди якось обробляти. Можна взяти promxy, що сходить в область шарда, мультиплікує дані. Він працює з двома шардами як із єдиною точкою входу. Таке можна реалізувати через promxy, але надто поки що складно.
Перший варіант – ми хочемо відмовитись від механізму federation, тому що він дуже повільний.
Розробники 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 тут все набагато гірше, тому що у нього взагалі таких крутилок немає. Використовувати обмеження у докері також не варіант. Якщо раптом у вас RAF упав і там 20-30 гігабайт, то підніматися він буде дуже довго.
Це ще одна причина, чому нам не підходить Prometheus, тобто не можна обмежити споживання пам'яті.
Можна було б вийти на таку схему. Ця схема нам потрібна у тому, щоб організувати HA кластер. Ми хочемо, щоб наші метрики були доступні завжди і скрізь навіть при падінні сервера, який зберігає ці метрики. І цим нам доведеться ось таку схему побудувати.
Ця схема каже, що у нас буде дублювання шардів, а, відповідно, і дублювання витрат ресурсів, що споживаються. Її можна майже горизонтально масштабувати, але споживання ресурсів буде пекельне.
Недоліки по порядку в тому вигляді, в якому ми їх виписали:
- Потрібне вивантаження метрик назовні.
- Велике споживання ресурсів.
- Не можна обмежити споживання пам'яті.
- Складна та ресурсомістка реалізація HA.
Для себе ми вирішили, що ми йдемо від Prometheus як від сховища.
Ми визначили для себе ще додаткові вимоги, які нам потрібні. Це:
- Це підтримка promql, тому що вже багато всього написано під Prometheus: запити, алерти.
- І далі у нас є Grafana, яка вже так само написана під Prometheus як бекенд. Не хочеться листувати дашборди.
- Ми хочемо збудувати нормальну HA архітектуру.
- Ми хочемо зменшити споживання будь-яких ресурсів.
- Є ще маленький нюанс. Ми не можемо використовувати різноманітні cloud системи збору метрик. Ми не знаємо, що в нас полетить у ці метрики поки що. І оскільки туди може відлетіти все, що завгодно, нам доводиться обмежуватись локальним розміщенням.
Вибір був невеликий. Ми зібрали все, чому ми мали досвід. Подивилися на сторінку Prometheus у розділі integration, прочитали купу статей, подивилися, що взагалі є. І для себе ми вибрали VictoriaMetrics як заміну Prometheus.
Чому? Тому що:
- Вміє promql.
- Існує модульна архітектура.
- Не потребує змін у Grafana.
- І найголовніше – ми, можливо, надаватимемо сховище метрик усередині своєї компанії як сервіс, тому ми заздалегідь дивимося у бік обмеження різного роду, щоб користувачі могли у якомусь обмеженому вигляді використовувати всі ресурси кластера, тому що є шанс, що він буде Multitenancy.
Робимо перші порівняння. Ми беремо той же Prometheus всередині кластера, до нього ходить зовнішній Prometheus. Додаємо через remoteWrite VictoriaMetrics.
Відразу зазначу, що ось тут ми зловили невелике збільшення споживання CPU з боку VictoriaMetrics. На VictoriaMetrics Wiki написано, які параметри краще підходять. Ми їх перевірили. Вони дуже добре зменшили споживання саме з 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 – це vmstsorage. Їх може бути N-кількість. У нашому випадку поки що їх 2.
І є vminsert. Це проксі-сервер, який дозволяє нам: влаштувати шардування між усіма storages, про які ми йому розповіли, і він дозволяє ще репліку, тобто у вас буде і шардування, і репліка.
Vminsert підтримує протоколи OpenTSDB, Graphite, InfluxDB і remoteWrite від Prometheus.
Є ще vmselect. Його основне завдання – це сходити у vmstorage, отримати від них дані, дедуплікувати ці дані та віддати клієнту.
Є чудова штука як vmagent. Нам дуже подобається вона. Вона дозволяє конфігурувати так само як Prometheus і при цьому робити все так само як Prometheus. Т. е. він збирає з різних сутностей, сервісів метрики і відправляє їх у vminsert. Далі все вже залежить від вас.
Ще один чудовий сервіс - це vmalert, який дозволяє як бекенд використовувати VictoriaMetrics, отримувати від vminsert і відправляти в vmselect оброблені дані. Обробляє він самі аллерти, а також керівні правила. У разі алертів ми отримуємо алерт через alertmanager.
Є компонент wmauth. Він у нас буде, можливо, використовуватися, а, можливо, і ні (ми ще не визначися з цим) як система авторизації при multitenancy версії кластерів. Він підтримує remoteWrite для Prometheus і може авторизуватися на основі url, а точніше другої його частини, куди вам можна чи не можна писати.
Є ще vmbackup, vmrestore. Це, по суті, відновлення та бекап всіх даних. Вміє S3, GCS, файл.
Першу ітерацію нашого кластера було зроблено під час карантину. На той момент не було репліки, тому наша ітерація являла собою два різні та незалежні кластери, в які через remoteWrite ми отримували дані.
Тут обмовлюся, що, коли ми переходили з VictoriaMetrics Single Node на VictoriaMetrics Cluster Version, ми так само залишилися в тих же споживаних ресурсах, тобто основна - це пам'ять. Приблизно в такий спосіб розподілилися наші дані, тобто споживання ресурсів.
Тут уже було додано репліку. Ми поєднали все це в один відносно великий кластер. Всі дані у нас шардуються, так і реплікуються.
У всього кластера є N точок входу, тобто Prometheus може додавати дані через HAPROXY. Ось у нас ця точка входу. І через цю точку входу можна заходити з Grafana.
У нашому випадку HAPROXY – це єдиний порт, який проксіює select, insert та інші послуги всередину цього кластера. У нашому випадку не можна було зробити одну адресу, нам довелося зробити кілька точок входу, тому що самі віртуалки, на яких крутиться VictoriaMetrics-кластер, знаходяться у нас у різних зонах одного хмарного провайдера, тобто не всередині нашої хмари, а зовні.
У нас є аллертинг. Ми його використовуємо. Ми використовуємо alertmanager від Prometheus. Ми як канал доставки алертів використовуємо Opsgenie і Telegram. У Telegram сиплються від dev, можливо, щось від prod, але більше щось таке статистичне, потрібне інженерам. А Opsgenie – critical. Це дзвінки, керування інцидентами.
Одвічне питання: «Хто ж моніторить моніторинг?». У нашому випадку моніторинг моніторить сам моніторинг, тому що ми використовуємо vmagent на кожній ноді. Оскільки наші ноди рознесені по різних дата-центрах одного провайдера, у кожного дата-центру у нас свій канал, вони незалежні і навіть якщо прийде split brain, то ми все одно отримаємо алерти. Так, їх буде більше, але краще отримати більше алертів, ніж жодного.
Ми закінчуємо наш список із реалізацією HA.
І далі хотів би наголосити на досвіді спілкування з ком'юніті VictoriaMetrics. Воно вийшло дуже позитивним. Хлопці чуйні. Вони намагаються вникнути у кожен кейс, який пропонується.
Я заводив issues на GitHub. Вони дуже швидко були вирішені. Є ще парочка issues, які не до кінця закриті, але я вже за кодом бачу, що робота в цьому напрямку йде.
Основний біль під час ітерацій для мене був у тому, що якщо вирубаю ноду, то перші 30 секунд у мене vminsert не міг зрозуміти, що бекенда немає. Нині це вже вирішено. І буквально за секунду або дві дані забираються вже з усіх нід, що залишилися, і запит перестає чекати ту відсутню ноду.
Ми хотіли в якийсь момент від VictoriaMetrics, щоб це був VictoriaMetrics operator. Ми його дочекалися. Ми зараз в активній побудові обв'язки над VictoriaMetrics operator, щоб взяти всі pre-calculating rules і т. д. Prometheus, тому що ми досить активно використовуємо rules, які йдуть разом із оператором Prometheus.
Є пропозиції щодо покращення кластерної реалізації. Я виклав їх вище.
І ще дуже хочеться downsampling. У нашому випадку downsampling потрібний виключно для переглядів трендів. Грубо кажучи, мені однієї метрики протягом дня вистачить. Ці тренди потрібні на рік, три, п'ять, десять років. І одного значення метрики цілком достатньо.
- Ми пізнали біль, як і деякі наші колеги при використанні Prometheus.
- Ми вибрали для себе VictoriaMetrics.
- Вона досить добре масштабується як вертикально, і горизонтально.
- Ми можемо розносити різні компоненти різну кількість вузлів у кластері, лімітувати їх за обсягом пам'яті, накидати пам'ять тощо.
Ми використовуватимемо VictoriaMetrics, тому що вона нам дуже сподобалася. Ось що було і що сталося.
Пара qr-кодів на чат VictoriaMetrics, мої контакти, техрадар LeroyMerlin.
Джерело: habr.com