VictoriaMetrics - створення найкращого віддаленого сховища для Прометея

Усім привіт! Тут засновники VictoriaMetrics:

  • валяла
  • hagen1778
  • тенмози

Ми раді пролити трохи світла на VictoriaMetrics.

Трохи історії

Ми почали використовувати Прометей та Графану два роки тому. Це було подихом свіжого повітря порівняно із Zabbix. Тепер розробники можуть розкидати довільні показники навколо свого коду, створювати власні панелі інструментів у Графані та контролювати їхні додатки без виділених sysadmins / DevOps.

Кількість унікальних показників, зібраних нашим екземпляром Прометей, швидко зросла з кількох сотень до більш ніж 300 К за півроку. Під час зростання ми перейшли на Прометей 2.0, оскільки Прометей до 2.0 став занадто повільним для наших метричних обсягів. Але у нового Прометея було кілька питань:

  • Це було не так швидко для діапазонів запитів, що перевищували кілька днів. Ми використовували такі діапазони для довгострокових тенденцій та інформаційних панелей планування потужностей.
  • Він почав їсти багато місця для зберігання після поступового збільшення утримання від 15 днів до року за замовчуванням.
  • Незрозуміло, як запобігти втраті даних Prometheus у разі збоїв пам’яті. Ми закінчуємо двома окремими екземплярами Прометея, які викреслюють один і той же набір цілей (він же пара HA). Це подвоїло наші витрати на моніторинг.

Ми почали вивчати можливі рішення та виявили, що Прометей підтримує віддалене зберігання. Але всі існуючі рішення були незадовільними через різні причини:

  • Складна установка та неміцна робота.
  • Повідомляються про збої та втрату даних.
  • Повільність.
  • Нульова або неоптимальна масштабованість.

У той же час ми успішно використовували ClickHouse для зберігання та аналізу величезних потоків подій - до 300 мільярдів подій на день. Ми були вражені оперативною простотою, швидкістю запиту та рівнем стиснення його двигуна таблиці MergeTree.

Наш досвід роботи з ClickHouse був настільки чудовий, тому ми відкривали для нього наступні проекти:

  • clickhouse-grafana - джерело даних Grafana для ClickHouse.
  • chproxy - балансир завантаження та проксі-кешування для ClickHouse.
  • chclient - швидкий клієнт Go для ClickHouse.

Ми намагалися використовувати ClickHouse як віддалене сховище для Прометея. Початкові результати були чудовими - ClickHouse зміг сканувати мільярди точок даних в секунду на одному сервері. На жаль, ми не змогли знайти хорошого рішення для створення ефективного індексу етикеток Прометея.

Тоді з’явилася божевільна ідея - давайте створимо власну TSDB з такими вимогами:

  • Ефективний індекс для міток Prometheus aka тегів Metrics 2.0, який легко зберігає і запитує мільярди різних міток.
  • Швидка швидкість запитів на великих діапазонах дат, велика кількість унікальних показників та величезна кількість точок даних.
  • Добре стискає сховище, тому на обмеженому просторі диска може зберігатися більше даних.
  • Прості та швидкі резервні копії в Інтернеті, схожі на FREEZE PARTITION у ClickHouse.

Прообраз цього TSDB був багатообіцяючим, тому я (валяла) залишив свою роботу у VertaMedia і почав працювати над TSDB повним робочим часом. Пізніше TSDB отримав приємну назву - VictoriaMetrics.

Технічні деталі

VictoriaMetrics написана на Go. Go було вибрано з наступних причин:

  • Багато існуючих рішень TSDB написані на Go - Prometheus, InfluxDB, Thanos, M3, Cortex тощо. Це натякає на Go дуже добре для написання TSDB.
  • Я маю гарний досвід роботи в Go. Дивіться мої репости на GitHub.
  • Я автор Fasthttp, тому я знаю, як писати ефективні програми в Go.

Зберігання VictoriaMetrics побудовано з нуля, використовуючи ідеї таблиці двигуна MergeTree Clickhouse:

  • Зберігайте окремо назви тимчасових журналів, часові позначки та значення (він же стовпчиковий сховище). Це прискорює запити, скануючи лише необхідні стовпці.
  • Зберігати кожен стовпець у структурі даних, аналогічному дереву злиття, структурованому журналом (LSM). Це зменшує випадкові введення-виведення при додаванні / скануванні відсортованих значень порівняно з B-деревоподібними структурами даних. Це прискорює зберігання на жорстких дисках. Файли LSM незмінні. Це спрощує створення швидких знімків та резервного копіювання. У LSM є недолік порівняно з B-деревом - збережені дані переписуються кілька разів, коли менші файли об’єднуються у більші файли. Це витрачає пропускну здатність диска, але практика ClickHouse показує, що це досить добре.
  • Обробляйте дані в шматках, які відповідають кешу CPU. Це максимізує продуктивність процесора, оскільки він не чекає даних із повільної оперативної пам’яті. Докладніше див. Номери затримки, які повинен знати кожен програміст.

Спочатку індекс для етикеток Prometheus був побудований поверх порту LevelDB в Go. Пізніше я спробував замінити його на більш ефективну альтернативу - RocksDB. Але це не було успішним через високі накладні витрати, які потрібно платити за кожну відскановану етикетку. Врешті-решт LevelDB був замінений на власну структуру даних - mergeset. Ця структура даних спеціально оптимізована для індексу міток Прометея.

mergeset має такі відмінності порівняно з LevelDB:

  • Він працює лише на клавішах. Це не знає цінностей.
  • Він має нижчу посилення запису.
  • Він швидше шукає багато упорядкованих клавіш.
  • Він краще стискає клавіші, тому їм потрібно менше місця для зберігання.
  • Він надає миттєві знімки даних та просте резервне копіювання.
  • Він використовує ідеї від двигуна таблиці MergeTree ClickHouse.

Ми плануємо найближчим часом створити об'єднання з відкритим кодом, щоб інші могли отримати від цього користь.

Спочатку VictoriaMetrics була рішенням з одним сервером. Пізніше це було перетворено на кластерне рішення. Під час трансформації одна служба була розділена на три служби:

  • vmstorage - зберігає метричні значення, отримані від vminsert, повертає необроблені метричні значення для запитів з vmselect.
  • vminsert - приймає метричні значення через API Prometheus remote_write і відправляє їх у vmstorage.
  • vmselect - реалізує API запитів Prometheus. Вилучає необроблені дані з vmstorage.

Розщеплення дає такі переваги:

  • Кожна служба може масштабуватись незалежно.
  • Кожна служба може працювати на апаратному забезпеченні, ідеально оптимізованому для потреб сервісу.
  • Важкі вставки не заважають важким вибору.
  • Помилки в vminsert не порушують vmselect і навпаки.
  • Краща довговічність vmstorage, оскільки вона вивантажує складну логіку запиту на vmselect.

Зараз VictoriaMetrics працює в Google Cloud. Ми використовуємо інфраструктуру як кодовий підхід для управління ресурсами та забезпечення їх через диспетчер розгортання.

Двигун запиту

Спочатку vmselect надав Prometheus віддаленого читання API. Але це було неоптимально, оскільки API вимагав перенесення всіх необроблених точок даних до Прометея для кожного запиту. Наприклад, якщо Prometheus будує відповідь на 1К метриках з 10K точок даних кожен, то vmselect повинен надіслати 1K * 10K = 10М точок даних до Прометея на кожен запит. Це марна трата виїзду і грошей. Тож пізніше API віддаленого зчитування було замінено на механізм запитів, повністю сумісний з PromQL.

Система запитів підтримує додаткові функції, спрямовані на спрощення складних запитів. Нижче наведено кілька прикладів:

  • З шаблонами, що нагадують загальні вирази таблиці:
З (
      commonFilters = {job = ~ "$ job", instance = ~ "$ instance"}
  ) node_filesystem_size_bytes {commonFilters} / node_filesystem_avail_bytes {commonFilters}

Дізнайтеся більше про шаблони ЗІ та пограйте з ними на майданчику шаблонів.

  • Багато корисних функцій. Наприклад, функція об'єднання для комбінування результатів запитів:
союз (
    node_filesystem_size_bytes,
    node_filesystem_avail_bytes,
)

Повний перелік додаткових функцій доступний тут.

Факти виконання

  • Початкові тести показують, що VictoriaMetrics використовує на 10 разів менше місця для зберігання порівняно з Prometheus 2.0–0.4 байтів на точку даних проти 4 байтів на точку даних у нашому випадку. Точка даних є (часова мітка, метричне значення).
  • Один сервіс vmstorage приймає до 4 мільйонів точок даних в секунду на сервері 8xCPU.
  • Один сервіс vmselect сканує до 500 мільйонів точок даних в секунду на сервері 8xCPU.
  • VictoriaMetrics використовує в 70 разів менше місця для зберігання даних порівняно з TimescaleDB на тестових даних з Benchmark Suite Time Time - 250 МБ проти 18 ГБ. Дані тестів складаються з 1B точок даних - див. Опис TSBS на GitHub.
  • Є приміщення для підвищення продуктивності. Всі сервіси VictoriaMetrics оснащені обробником pprof, тому ми готові настроїти їх продуктивність на виробничому навантаженні.

Особливості VictoriaMetrics

  • Підтримує повний PromQL плюс розширений PromQL з шаблонами З. Розширений PromQL можна спробувати на майданчику Графана.
  • Просте налаштування - просто скопіюйте і вставте наданий URL-адресу віддаленого запису в конфігурацію Prometheus.
  • Зниження експлуатаційних витрат. Прометей може бути перетворений на послугу без громадянства після включення віддаленого запису в VictoriaMetrics.
  • Доступний широкий діапазон термінів утримання - від 1 місяця до 5 років.
  • Вставте масштаби продуктивності до мільйонів метричних значень в секунду.
  • Виберіть масштаби продуктивності до мільярдів метричних значень в секунду.
  • Шкала зберігання до трильйонів метричних значень і мільйонів унікальних метрик (так само висока кардинальність).
  • Забезпечує глобальний перегляд запитів для довільної кількості різних примірників Прометея, якщо вони використовують ту саму URL-адресу віддаленого написання.

Хто може отримати вигоду від VictoriaMetrics?

  • Той, хто використовує Прометей. Просто встановіть VictoriaMetrics як віддалене сховище і перестаньте турбуватися про локальні оперативні проблеми зберігання, такі як резервне копіювання, реплікація, планування потужностей та інші труднощі з обслуговування.
  • Користувачі, що розгортають Прометей у Кубернеті. В даний час таким користувачам слід ретельно керувати стійкими томами для локального зберігання Prometheus. Зазвичай вони встановлюють Прометей як надзвичайний додаток, який може обмежувати Кубернетів у прийнятті планових рішень. Просто використовуйте VictoriaMetrics як віддалене сховище і запускайте Prometheus як додаток без громадянства.
  • Користувачі з багатьма різними екземплярами Prometheus, розташованими в різних мережах / центрах обробки даних. VictoriaMetrics забезпечує глобальний перегляд запитів у всіх випадках Прометея.

Особливості майбутнього

У майбутньому ми плануємо реалізувати такі функції:

  • Автоматичне зниження старого даних.
  • Останні значення для заданих фільтрів міток.
  • Лічильники за вікном за часом.

Висновок

Ми впевнені, що VictoriaMetrics стане найкращим віддаленим сховищем для Прометея.

Продовжуйте її досліджувати. Прочитайте FAQ. Зареєструйтесь на майданчику VictoriaMetrics, використовуйте його як пробне віддалене сховище для своїх примірників Prometheus. Це абсолютно безпечно, оскільки Прометей продовжує записувати дані у місцевий сховище поряд із віддаленим сховищем, тому ваші локальні дані не втрачаються при включенні віддаленого зберігання. Детальнішу інформацію див. У розділі Швидкий старт.

Редагуйте інформаційні панелі та графіки на майданчику Графана. Цей майданчик використовує джерело даних VictoriaMetrics, що вказує на внутрішні показники ігрового майданчика VictoriaMetrics, тому всі функції від Extended PromQL є тут.

Виробництво VictoriaMetrics буде доступне незабаром. Будьте в курсі та поширюйте слово про це!

Оновлення: зображення Docker із односерверною програмою VictoriaMetrics доступні тут. Якщо вам не подобається Docker, просто використовуйте відповідні статичні двійкові файли.

Update2: Прочитайте нашу нову публікацію - Показники TSDB з високою кардинальністю: VictoriaMetrics проти TimescaleDB проти InfluxDB.

Update3: VictoriaMetrics зараз є відкритим кодом!

Приєднуйтесь до нашої спільноти Slack та читайте наші щотижневі теми Faun ⬇

Якщо ця публікація була корисною, будь ласка, натисніть кнопку нижче кілька разів, щоб показати вашу підтримку автору! ⬇