VictoriaMetrics — быстрая и масштабируемая СУБД для хранения и обработки данных в виде временного ряда (запись состоит из времени и набора значений, соответствующих этому времени, например, полученных путем периодического опроса состояния датчиков или сбор показателей).
Меня зовут Колобаев Павел.
DevOps, SRE, LeroyMerlin, всё как код — всё о нас: обо мне и о других сотрудниках LeroyMerlin. 
https://bit.ly/3jf1fIK Есть облако на базе OpenStack. Есть небольшая ссылка на технический радар.
Он построен на железе и Kubernetes, а также на всех сопутствующих сервисах для OpenStack и логирования.
Вот такая схема у нас была в разработке.
Когда мы все это разрабатывали, у нас был оператор «Прометей», который хранил данные внутри самого кластера K8s. Он автоматически находит то, что нужно соскоблить, и кладет под ноги, грубо говоря.
Нам нужно будет вынести все данные за пределы кластера Kubernetes, потому что в случае чего нам нужно понимать, что и где.
Первое решение — мы используем федерацию, когда у нас есть сторонний Prometheus, когда мы заходим в кластер Kubernetes через механизм федерации.
Но здесь есть небольшие проблемы.
В нашем случае проблемы начались, когда у нас было 250 000 метрик, а когда стало 400 000 метрик, мы поняли, что так работать нельзя.
Мы увеличили Scrape_timeout до 25 секунд. Почему нам пришлось это сделать? Прометей начинает отсчитывать таймаут от начала забора.
Неважно, что данные все еще передаются.
Если за этот указанный период времени данные не сливаются и сессия не закрывается по http, то сессия считается неудавшейся и данные не попадают в сам Прометей.
Всем знакомы графики, которые мы получаем, когда не хватает некоторых данных.
Графики рвутся и нас это не устраивает. 
Следующий вариант — шардинг на основе двух разных Prometheus через один и тот же механизм федерации.
Например, просто возьмите их и шардируйте по имени.
Это тоже можно использовать, но мы решили пойти дальше.
Нам теперь придется как-то обрабатывать эти осколки.
Можно взять промкси, который ходит в область шарда и перемножает данные.
Он работает с двумя шардами как с одной точкой входа.
Это можно реализовать через промкси, но это пока слишком сложно.
Первый вариант – мы хотим отказаться от механизма федерации, потому что он очень медленный.
Разработчики Prometheus четко говорят: «Ребята, используйте другую TimescaleDB, потому что мы не будем поддерживать долгосрочное хранение метрик».
Это не их задача.
Записываем на листке бумаги, что нам еще нужно выгрузить на улицу, чтобы не хранить все в одном месте.
Второй недостаток — потребление памяти.
Да, я понимаю, что многие скажут, что в 2020 году пара гигабайт памяти стоит копейки, но всё же.
Теперь у нас есть среда разработки и производства.
В dev это около 9 гигабайт на 350 000 метрик.
В проде это 14 гигабайт и чуть больше 780 000 метрик.
При этом наше время удержания составляет всего 30 минут. Это плохо.
И сейчас я объясню почему.
Делаем расчет, то есть с полутора миллионами метрик, и уже близки к ним, на этапе проектирования получаем 35-37 гигабайт памяти.
Но уже 4 миллиона метрик требуют около 90 гигабайт памяти.
То есть оно было рассчитано по формуле, предоставленной разработчиками «Прометея».
Мы посмотрели на корреляцию и поняли, что не хотим платить пару миллионов за сервер только для мониторинга.
Мы не только увеличим количество машин, но и будем следить за самими виртуальными машинами.
Поэтому чем больше виртуальных машин, тем больше метрик разного рода и т. д. У нас будет особый рост нашего кластера по метрикам.
С дисковым пространством здесь не все так плохо, но хотелось бы его улучшить.
Всего мы получили 120 гигабайт за 15 дней, из них 100 — сжатые данные, 20 — несжатые данные, но нам всегда хочется меньше.
Соответственно, записываем еще один момент — это большое потребление ресурсов, которое мы все-таки хотим сэкономить, поскольку не хотим, чтобы наш кластер мониторинга потреблял больше ресурсов, чем наш кластер, который управляет OpenStack. 
Есть еще один недостаток Прометея, который мы для себя выявили, это как минимум какое-то ограничение памяти.
С Прометеем здесь все гораздо хуже, потому что таких поворотов у него вообще нет. Использование ограничения в докере также не вариант. Если вдруг у вас РАФ упал и там гигабайт 20-30, то подниматься будет очень долго.
Это еще одна причина, по которой Прометей нам не подходит, т.е.
мы не можем ограничить потребление памяти.
Можно было бы придумать такую схему.
Эта схема нам нужна для того, чтобы организовать HA-кластер.
Мы хотим, чтобы наши метрики были доступны всегда и везде, даже если сервер, на котором эти метрики хранятся, выйдет из строя.
И таким образом нам придется построить такую схему.
Эта схема говорит о том, что у нас будет дублирование шардов, и соответственно дублирование затрат потребляемых ресурсов.
Его можно масштабировать практически по горизонтали, но всё равно потребление ресурсов будет адским.
Недостатки по порядку в том виде, в котором мы их для себя записали:
- Требуется загрузка показателей извне.
- Высокое потребление ресурсов.
- Нет возможности ограничить потребление памяти.
- Сложная и ресурсоемкая реализация HA.
Для себя мы решили, что отходим от «Прометея» как хранилища.
Мы определили для себя дополнительные требования, которые нам необходимы.
Этот:
- Это поддержка promql, потому что для Прометея уже много чего написано: запросы, оповещения.
- А еще у нас есть Grafana, которая уже точно так же написана для Prometheus как бэкенд. Я не хочу переписывать дашборды.
- Мы хотим построить нормальную HA-архитектуру.
- Мы хотим сократить потребление любых ресурсов.
- Есть еще один небольшой нюанс.
Мы не можем использовать различные типы систем сбора облачных метрик.
Мы пока не знаем, что попадет в эти метрики.
А поскольку там может летать что угодно, то приходится ограничиться локальным размещением.
Выбор был небольшой.
Мы собрали все, с чем имели опыт. Мы заглянули на страницу Прометея в разделе интеграция, прочитали кучу статей и увидели, что там есть.
А для себя мы выбрали VictoriaMetrics в качестве замены Прометею.
Почему? Потому что:
- Знает promql.
- Имеется модульная архитектура.
- Не требует изменений в Grafana.
- И самое главное, вероятно, мы будем предоставлять хранение метрик внутри нашей компании как услугу, поэтому мы заранее смотрим на ограничения различного рода, чтобы пользователи могли каким-то ограниченным образом использовать все ресурсы кластера, потому что есть шанс что он будет многопользовательским.
Проведем первое сравнение.
Берем тот же Прометей внутри кластера, к нему идет внешний Прометей.
Добавляем через RemoteWrite VictoriaMetrics. 
Сразу оговорюсь, что здесь мы уловили небольшое увеличение потребления процессора от VictoriaMetrics. Вики VictoriaMetrics подскажет вам, какие параметры лучше всего.
Мы их проверили.
Они очень хорошо снизили потребление процессора.
В нашем случае немного увеличилось потребление памяти Prometheus, который находится в кластере Kubernetes. 
Мы сравниваем два источника данных с одними и теми же данными.
В Прометее мы видим те же недостающие данные.
В VictoriaMetrics все хорошо.
Результаты теста дискового пространства.
Мы в Прометее всего получили 120 гигабайт. В VictoriaMetrics мы уже получаем 4 гигабайта в день.
Здесь немного другой механизм, чем тот, который мы привыкли видеть в «Прометее».
То есть данные уже достаточно хорошо сжимаются за сутки, за полчаса.
Они уже хорошо пожаты за день, за полчаса, несмотря на то, что данные потом все равно потеряются.
В результате мы сэкономили место на диске.
Также мы экономим на потреблении ресурсов памяти.
На момент тестирования у нас на виртуальной машине был развернут Прометей — 8 ядер, 24 гигабайта.
Прометей ест почти все.
Он упал на OOM Killer. При этом в него было залито всего 900 000 активных метрик.
Это примерно 25 000-27 000 метрик в секунду.
Мы запускали VictoriaMetrics на двухъядерной виртуальной машине с 8 гигабайтами оперативной памяти.
Нам удалось заставить VictoriaMetrics работать хорошо, повозившись с некоторыми вещами на машине с 8 ГБ памяти.
В итоге мы сохранили его до 7 гигабайт. При этом скорость доставки контента, то есть метрик, была даже выше, чем у Прометея.
Процессор стал намного лучше по сравнению с Прометеем.
Здесь Prometheus потребляет 2,5 ядра, а VictoriaMetrics — всего 0,25 ядра.
На старте - 0,5 ядра.
При слиянии он достигает одного ядра, но это бывает крайне, крайне редко.
В нашем случае выбор пал на VictoriaMetrics по понятным причинам; мы хотели сэкономить, и мы это сделали.
Сразу вычеркнем два пункта — выгрузка метрик и большое потребление ресурсов.
И нам осталось только решить два пункта, которые у нас еще остались за собой.
Тут сразу оговорюсь, мы рассматриваем VictoriaMetrics как хранилище метрик.
Но поскольку мы, скорее всего, предоставим VictoriaMetrics в качестве хранилища для всего Лероя, нам нужно ограничить тех, кто будет использовать этот кластер, чтобы они нам его не отдавали.
Есть замечательный параметр, который позволяет ограничивать по времени, по объёму данных и по времени выполнения.
Также есть отличный вариант, позволяющий ограничить потребление памяти, тем самым мы сможем найти тот самый баланс, который позволит нам получить нормальную скорость работы и адекватное потребление ресурсов.
Минус еще один балл, т.е.
зачеркните пункт — нельзя ограничивать потребление памяти.
В первых итерациях мы тестировали единый узел 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. 
Есть компонент vmauth. Мы можем, а можем и нет (пока с этим не определились) использовать его как систему авторизации для мультиарендной версии кластеров.
Он поддерживает RemoteWrite для Prometheus и может авторизоваться на основе url, а точнее второй его части, куда можно или нельзя писать.
Еще есть vmbackup, vmrestore. По сути, это восстановление и резервное копирование всех данных.
Может делать S3, GCS, файл.
Первая итерация нашего кластера была сделана во время карантина.
На тот момент реплики не было, поэтому наша итерация состояла из двух разных и независимых кластеров, в которые мы получали данные через RemoteWrite. 
Здесь оговорюсь, что когда мы перешли с VictoriaMetrics Single Node на VictoriaMetrics Cluster Version, мы всё равно остались с теми же потребляемыми ресурсами, т.е.
основным из них является память.
Примерно так распределились наши данные, т. е.
потребление ресурсов.
Реплика уже добавлена сюда.
Мы объединили все это в один относительно большой кластер.
Все наши данные сегментированы и реплицируются.
Весь кластер имеет N точек входа, что означает, что Prometheus может добавлять данные через HAPROXY. Вот эта точка входа у нас есть.
И через эту точку входа можно авторизоваться из Grafana. 
В нашем случае HAPROXY — единственный порт, который проксирует выбор, вставку и другие сервисы внутри этого кластера.
В нашем случае сделать один адрес было невозможно; нам пришлось сделать несколько точек входа, потому что сами виртуальные машины, на которых работает кластер VictoriaMetrics, находятся в разных зонах одного и того же облачного провайдера, т.е.
не внутри нашего облака, а снаружи.
У нас есть оповещение.
Мы используем это.
Мы используем alertmanager от Prometheus. Мы используем Opsgenie и Telegram в качестве канала доставки оповещений.
В Телеграм сыпятся с дев, может что-то с прода, но в основном что-то статистическое, нужное инженерам.
И Opsgenie имеет решающее значение.
Это звонки, управление инцидентами.
Вечный вопрос: «Кто следит за мониторингомЭ» В нашем случае мониторинг контролирует сам мониторинг, потому что мы используем vmagent на каждом узле.
А поскольку наши ноды распределены по разным дата-центрам одного и того же провайдера, каждый дата-центр имеет свой канал, они независимы, и даже если прилетит разделенный мозг, мы все равно будем получать оповещения.
Да, их будет больше, но лучше получать больше оповещений, чем ничего.
Мы заканчиваем наш список реализацией HA. 
И далее хотелось бы отметить опыт общения с сообществом VictoriaMetrics. Вышло очень позитивно.
Ребята отзывчивые.
Они стараются вникнуть в каждый предлагаемый случай.
Я начал проблемы на GitHub. Они были решены очень быстро.
Есть еще пара вопросов, которые не закрыты полностью, но я уже по коду вижу, что работа в этом направлении ведется.
Главной болью для меня во время итераций было то, что если я отключал ноду, то первые 30 секунд vminsert не мог понять, что бэкенда нет. Теперь это решено.
И буквально через секунду-две данные забираются со всех остальных узлов, и запрос перестает ждать тот недостающий узел.
В какой-то момент мы хотели, чтобы VictoriaMetrics стала оператором VictoriaMetrics. Мы ждали его.
Сейчас мы активно создаем фреймворк для оператора VictoriaMetrics, который будет принимать все правила предварительного расчета и т. д. Prometheus, потому что мы достаточно активно используем правила, которые идут вместе с оператором Prometheus. Есть предложения по улучшению реализации кластера.
Я изложил их выше.
И мне очень хочется понизить дискретизацию.
В нашем случае даунсемплинг нужен исключительно для просмотра трендов.
Грубо говоря, мне достаточно одной метрики в течение дня.
Эти тенденции нужны на год, три, пять, десять лет. И одного значения метрики вполне достаточно.
- Мы, как и некоторые наши коллеги, испытывали боль при использовании Prometheus.
- Мы выбрали для себя VictoriaMetrics.
- Он довольно хорошо масштабируется как по вертикали, так и по горизонтали.
- Мы можем распределять разные компоненты по разному количеству узлов кластера, ограничивать их по памяти, добавлять память и т. д.
Это то, что было и что стало.
https://t.me/VictoriaMetrics_ru1 Пара QR-кодов для чата VictoriaMetrics, мои контакты, технический радар LeroyMerlin.
Теги: #ИТ-инфраструктура #Системное администрирование #DevOps #Визуализация данных #prometheus #метрики #PromQL #VictoriaMetrics
-
Современный Подход К Патентной Защите
19 Oct, 24 -
О Пузыре Ашманова («Правилах Предателей»)
19 Oct, 24 -
Сплоченность В Корпоративных Приложениях
19 Oct, 24
