Хабр·Russia·Friday, September 18, 2026 at 01:29 PM

Эволюция пайплайна метрик: как менялась архитектура с ростом нагрузки

Translate

rusboy_habr5 минут назад

Привет, Хабр! Я Руслан Боярский, SRE в Т-Банке, отвечаю за надежность платформы Sage и принимаю активное участие в ее развитии. Sage — это платформа наблюдаемости, где мы собираем телеметрию. И я регулярно убеждаюсь, что в ИТ мы не можем существовать без метрик.

В статье рассказываю о том, как с ростом нагрузки более чем в 100 раз может меняться и развиваться система мониторинга, подходы в командах, да и в целом сами команды. Покажу ключевые эпохи развития нашей подсистемы метрик. В каждой эпохе дам контекст, архитектуру, профиль нагрузки.

А еще опишу проблемы, с которыми можно столкнуться, и расскажу, как мы их решали. Попутно будет пара историй про инциденты. Поехали.

Метрики везде

Наблюдаемость, мониторинг и алертирование наших приложений строятся на метриках. С другой стороны, мы даем пользователям воспользоваться поиском и процессингом над этой телеметрией. У нас ежедневно более 7 000 уникальных пользователей, более 19 тысяч активных алертов, плюс наши данные активно используют другие продукты компании.

Данные собраны по результатам исследований в 2024 году

Телеметрия прекрасно живет до тех пор, пока мы не получаем первый ложный алерт. Тогда мы теряемся, перестаем понимать, что происходит. Вдвойне обидно, если понимаем, что алерт был ложным, из-за того, что шатает систему мониторинга. Причины шатания могут быть самыми разными, в том числе система может быть банально перегружена.

Во всей ИТ-индустрии есть явный тренд на рост объема собираемой телеметрии. И в этих условиях нам надо как-то уметь выживать.

2019: начало импортозамещения

2019 — время, когда в T-Банке активно применялся продукт Splunk. Мы использовали его для бизнес-мониторинга, собирали все логики, которые были в компании. Все отмечали, насколько функционален язык поисковых запросов в Splunk.

Но в 2019 году Splunk ушел из России и к лету инсталляция Splunk в T-Банке должна была превратиться в тыкву. Компания решила вложиться в свою платформу наблюдаемости.

Так появился Sage и началась эпоха импортозамещения в T-Банке. В эту эпоху интересен в первую очередь поиск. Мы вложились в поисковый движок Mage, который решает две задачи:

дать пользователям удобный и знакомый язык запросов;
скрыть внутрянку от внешнего пользователя.

Схема организации поиска в Sage в 2019 году

Чтобы сделать язык удобным и знакомым нашим пользователям, мы вдохновляемся синтаксисом Splunk и берем оттуда идеи.

Один и тот же запрос к данным, написанным на MageQL и на языке Splunk

Из этой эпохи мы получили два ключевых артефакта:

фасад над слоем баз данных;
MageQL, который упрощает миграцию пользователей со Splunk.

Язык MageQL очень похож на синтаксис языка Splunk: мы легко и безболезненно переводим пользователей со Splunk на нашу систему. Настолько легко, что на одной конференции по ИБ мы предложили тестовое задание на MageQL, и участники, заведомо знавшие только Splunk, с ним справились.

Все это время метрик пока не существует в Sage, а на уровне компании они собираются с помощью Nagios, Zabbix. Локально где-то в командах появляется Prometheus.

2020: контекст

Двадцатый год — время, когда в Sage появляются первые метрики. В компании наблюдается спрос на мониторинг приложений со сбором метрик с них. На уровне компании есть четкое понимание, что нужен некий единый подход к работе с метриками как сервисом.

Параллельно где-то существует отдел DevOps и развивает первую версию центрального хранилища для метрик. Строят они его на базе Prometheus и Grafana. В этом же году происходит трансформация отдела DevOps и логическое продолжение этой истории переходит к нам. Мы начинаем встраивать в наш продукт Grafana, и подсистема метрик тоже становится частью Sage.

Перед нами стоят три задачи.

Быстро и оперативно собрать мониторинг и дать нашим пользователям работать с данными из нашего Sage.

Мы берем за основу компоненты Prometheus: базу данных временных рядов из Prometheus, механизм скрейпинга сбора метрик с таргетов и движок алертирования. Это правило алертирования плюс доставка пейджей клиентам и пользователям. Дополнительно мы расширяем инсталляцию и к каждому Prometheus добавляем внешнее хранилище метрик — VictoriaMetrics Single.

Вся подсистема метрик в 2020 году работает на виртуальных машинах. Хранилище у нас коммунальное. Временные ряды храним с интервалом 30 секунд, а срок хранения — до 30 дней.

Пайплайн записи метрик выглядит так: есть два дата-центра, в каждом из которых — по своему экземпляру Prometheus. Один из них Primary, другой — Standby. Между ними появляется consul, который отслеживает работоспособность Primary Prometheus и в случае его отказа выполняет failover на Standby. Еще задача consul — знать обо всех таргетах, с которых необходимо будет собирать метрики. Оба Prometheus в один момент ходят к этому консулу, забирают список таргетов и параллельно опрашивают все источники с метриками.

В это время мы храним метрики максимум 7 дней. Чтобы увеличить срок хранения с 7 до 30 дней, настраиваем внешнее хранилище для Prometheus в виде VictoriaMetrics Single.

Поиск по метрикам — вторая задача. У нас уже есть поисковый движок Mage, который пока работает только с логами. Каждый поисковый запрос, который попадает в поисковый движок, перенаправляется на Primary VictoriaMetrics Single.

Чтобы пользователи могли делать запросы на метрики, мы расширяем язык MageQL и добавляем в него поддержку MetricsQL/PromQL.

Пример на нашем языке запросов на данные по метрике up

Возможность использовать дашборды в Grafana — третья задача. К тем типам клиентов, что у нас уже были, добавляется еще один тип — Grafana. Мы реализуем свой Data-Source -плагин для Grafana, который поддерживает из коробки язык запросов MageQL. В итоге наши клиенты смогли использовать все возможности Grafana-дашбордов для построения своей аналитики.

Профиль нагрузки. На весь Sage был входящий поток точек около ста тысяч в секунду. Это совсем немного, а таргетов всего три тысячи.

Из всей эпохи мы делаем выводы:

Prometheus — классный инструмент, чтобы стартануть, и у него очень большой объем компонент. Мы быстро собрали механизмы скрейпинга с приложений за счет компонент экосистемы Prometheus.
Для хранения метрик больше чем 7 дней подключаем VictoriaMetrics Single как внешнее хранилище к нашему Prometheus.

2021—2022: распространение экспертизы SRE

Мониторинг приложения, дежурство, реагирование — для всего этого требуются метрики. В компании появляются первые K8S-кластеры как сервис, и туда заезжают первые приложения. В эту эпоху все осознают, что дешевле хранить метрики, чем логи. Поэтому Sage раздает меньше квот на логи и предлагает пользователям альтернативу — переходить на метрики, которые заменяют логи в мониторинге приложений. Для нас это означает рост количества метрик, а с ними и задач.

Дыры в метриках — первая проблема. Дыры возникают, когда мы выводим ноду Prometheus либо VictoriaMetrics Single на работу и возвращаем обратно. Пока она отсутствовала, не было и метрик, и откуда их взять, тоже было непонятно.

Чтобы решить проблему дыр с выводом нод на работы, мы добавляем по второй реплике VictoriaMetrics Single в каждом дата-центре.

Тянутый кластер — вторая проблема. В схеме с двумя Prometheus, которые разбиты на разные дата-центры, мы имеем такую штуку, как тянутый кластер. Что случится, если трактор порвет кабель между дата-центрами, как себя поведут эти Prometheus — абсолютно непонятно.

Чтобы решить проблему с тянутым кластером между дата-центрами, мы начинаем следовать принципу Data per Data Center, либо Data Gravity (альтернативное название). Принцип гласит: где данные появились, там они должны жить и там же они умирают. Для нас это означает, что инсталляция Sage должна собирать метрики только с тех приложений, которые хостятся в одном с ней дата-центре.

Скрейпинг, алертирование в текущей схеме — третья, довольно важная и критичная проблема. Он не масштабируется, а нас это не устраивает, потому что мы ожидаем роста количества пользователей в системе.

Коммунальное хранилище — четвертая проблема. Пока пул пользователей маленький, это не так страшно, но, когда количество пользователей растет, начинается борьба за ресурсы. Это надо как-то разруливать, нас это не устраивает.

Мы переезжаем на VictoriaMetrics Single именно как на базу данных. Теперь у нас для хранения используется только VictoriaMetrics Single. Time Series по-прежнему храним с интервалом 30 секунд со сроком хранения до 30 дней. Переезжаем с виртуальных машин на железные серверы. Да, мы уперлись в лимиты по ресурсам виртуальных машин, поэтому закидались железом: больше, еще больше ресурсов.

Посмотрим на пайплайн записи метрик. Мы вкладываемся в развитие Metrics Collector, который в эти годы поддерживает только скрейпинг, и так решаем проблему именно масштабирования скрейпинга. Metrics Collector работает в режиме кластера, он знает обо всех таргетах, с которых необходимо собирать данные. При этом каждая нода в кластере разбирает определенный пул таргетов и параллельно обслуживает только свой кусочек, свои таргеты, которые забрала на себя. Все метрики, которые собирает Metrics Collector, складываются в Кафку, и, с другой стороны, мы вычитываем из этой Кафки собранные метрики и кладем каждую из них в каждую реплику.

Теперь в обеих репликах появляется метрика, по которой мы понимаем, что происходит с каждой записью. Эта же метрика позволяет нам мониторить сам пайплайн.

Но есть другие интеграции, есть прямые писатели. Это те, кто имеет доступ к нашей базе напрямую. О некоторых мы знаем, это ребята из K8s-рантайма: они поднимают у себя vmagent и собирают метрики со своих системных подов, пользовательских подов и пулят к нам в базу данных. Но есть неизвестные прямые писатели, которые живут какой-то своей жизнью и дают нам какую-то нагрузку. Мы абсолютно не имеем понятия какую.

База у нас коммунальная, значит, ресурсы общие и надо как-то распределять их на пользователей. В эту эпоху мы вкладываемся и в тему квотирования: получаем возможность указать пользователям лимит на количество временных рядов, которые мы будем забирать во время скрейпинга. На стороне vmagent в K8s мы настраиваем лимиты по 5 000 на каждый пользовательский под. Прямую запись мы не видим и не квотируем.

В эту эпоху жизнь нам преподносит первый урок. У нас есть одна-единственная Кафка для двух подсистем, подсистемы логов и подсистемы метрик. Все работает хорошо, пока Кафка вдруг не перестает отвечать. Накануне был вечер пятницы и в подсистему логов сделали релиз. В этом релизе поменялась логика, и в шареной Кафке стали бесконечно появляться новые топики. Она сколько-то терпела, а потом перестала отдавать сигналы и закономерно загнулась.

Из этой истории мы поняли, что нам нужна вторая Кафка для подсистемы метрик. Разворачиваем ее, она живет там своей жизнью.

Есть более важный урок всей эпохи — стратегическое решение: надо снижать связность между подсистемами внутри Sage. Ведь пользователи остались и без логов, и без метрик. У них мог быть свой инцидент, мог банк гореть огнем, а они ничего не видели. Мы такого в рамках платформы наблюдаемости допустить не можем.

В поиске появляется новый вид клиентов — Alerting Engine, наш компонент, который решает задачу масштабирования алертирования и поддерживает язык MageQL из коробки. Каждый поисковый запрос, который прилетает в Mage, одновременно направляется во все известные нашему поисковому движку дата-центры.

В дата-центре запрос оказывается либо на первой, либо на второй реплике случайным образом. Mage дожидается ответа из каждого дата-центра, формирует один агрегированный респонс и отправляет его нашему клиенту.

Чтобы пользователь мог настраивать вид пост-агрегации результатов из разных дата-центров, мы расширяем функциональность языка и даем возможность добавить правило пост-агрегации в рамках дата-центра.

Профиль нагрузки в эту эпоху — это стабильный поток, при котором мы не шатаемся, не падаем, все прекрасно.

В 2022 году я как раз прихожу в команду Sage SRE и первое, что слышу: «Эластик шатает, Кафку пошатывает, а вот VictoriaMetrics Single живет, и мы о ней почти ничего не знаем, она нас не беспокоит».

Мы теперь можем выводить хотя бы одну реплику VictoriaMetrics Single на работу и при этом не влиять на наших пользователей. Мы научились не терять собранные метрики, копим лаг на Кафке в случае сбоя на базе, когда база восстанавливается, мы вычитываем этот лаг и записываем в базу.

В эту эпоху мы осознаем, что весь банк пользуется Sage и пользователи уже полагаются на то, что мы работаем стабильно. Когда нам плохо, плохо им. Это большой вызов, мы должны все лучше и лучше, стабильнее работать в будущем. И не допускать простоев.

2023 — наши дни: Kubernetes

В это время в компании активно распространяется K8s as-a-Service. Платформа становится базовой, в нее заезжает все больше и больше приложений. В компании появляются новые aaS-решения, которые используют данные Sage для своих сценариев и целей.

Появляется capacity management, и ребятам уже требуются данные не за 30 дней, как мы хранили, а за полгода и год. Плюс компания вводит новые мощности и Sage появляется в новых дата-центрах.

В эту эпоху происходит еще один важный момент: у нас огромная команда разработки, которая делится на подкоманды, каждая из которых теперь развивает свою подсистему метрик. В общем, закон Конвея в силе.

Что до сих пор создает проблемы:

1. У нас все еще есть прямые писатели, которые пишут базу данных. Мы их поток не видим. Однажды VictoriaMetrics Single начала по каким-то причинам медленнее отвечать, и мы начали копить лаг. Все это стало влиять на пользователей.

Через какое-то время поняли, что причина в прямых писателях, которых мы не видим. А когда мы научились видеть их поток, стали искать, как давно это продолжается. И тут выяснили, что теперь уже нам самим нужны метрики, чтобы мы могли видеть тренды и понимать, когда что-то поменялось в нашей системе.

2. При деградации системы мы начинаем копить лаг в Кафку. И при текущей схеме наши пользователи ждут, пока мы восстановим базу данных и откачаем этот лаг. У нас база может простаивать 20 минут, пока мы ее оживляем, и наши пользователи все это время находятся без метрики. Это плохо для платформы наблюдаемости.

3. Мы масштабируемся — добавляем железо, ресурсов, — но нам не хватает. Планируем учиться масштабироваться другим способом — горизонтально. Поэтому в эту эпоху мы переезжаем с VictoriaMetrics Single на кластерную VictoriaMetrics, которая из коробки позволяет нам масштабировать все ее компоненты: vmstorage, vmselect и vminsert.

В то же время в каждом дата-центре мы разворачиваем по две инсталляции кластерной VictoriaMetrics. Первая — для краткосрочного хранения временных рядов метрик: это 30 дней с интервалом 30 секунд. А вторая инсталляция кластерной VictoriaMetrics в каждом дата-центре — для долгосрочного хранения метрик. Это временные ряды с интервалом 5 минут и сроком хранения до одного года.

В эту эпоху мы развиваем Metrics Collector: помимо того что он теперь умеет скрейпать, мы его обучаем и имплементируем в нем протокол remote write. Всех прямых писателей, которые раньше писали в базу данных напрямую, теперь направляем в Metrics Collector. Это позволит нам не беспокоиться за базу данных. Мы знаем, что никто сбоку по секрету не придет и не начнет ее шатать. Каждую собранную в Metrics Collector метрику мы пишем сначала в краткосрочные хранилища и сразу же дублируем в долгосрочные.

Вроде выглядит круто. Но что будет, если база начнет деградировать на запись, начнет медленнее отвечать? Либо вдруг придет поток метрик от клиентов, которого мы не ожидали, — будет резкий всплеск? Для таких случаев на Metrics Collector реализован механизм отложенной записи, который базируется на Кафке. Метрики из отложенной записи догружаются в базу после ее стабилизации.

В эту эпоху у нас появляются новые дата-центры. И весь пайплайн записи мы дублируем в каждом дата-центре.

Дело в том, что пайплайн записи, процессы записи специфичны в каждом дата-центре. Чтобы понять, чей поток метрик идет по протоколу remote write, мы требуем от наших пользователей токен для аутентификации. В токене есть поле client ID, по которому мы всегда сможем сопоставить, кто это пришел, чей поток это был, почему он резко вскочил и что с ним происходит.

Байки с прода

Шумный сосед первый. У нас есть много пользователей — коммунальных хранилищ, — и много пользователей заливают в нас метрики. Среди них может появиться клиент, который вдруг поменял что-то в своем потоке, из-за чего в нем стало больше уникальных метрик с точки зрения базы данных.

Самый простой базовый пример. Есть мега-нагруженный сервис, который обслуживает 5 млн RPS в секунду, и на каждый реквест есть свой ID. И мы решили по каждому реквесту с этим ID собрать метрику — она будет уникальной. Это положит базу данных временных рядов, просто убьет. Процесс появления таких уникальных метрик называется «взрыв кардинальности от одного клиента».

Мы можем блокировать подозрительный поток по client ID: увидели аномалию, выставили флажок в Metrics Collector, заблокировали. Либо, если поток вырос, но база пока терпит, мы связываемся с клиентом и выясняем, что случилось и как убрать лишние метрики.

Для отлова взрывов кардинальности в Sage есть компонент anomaly analyzer.

Шумный сосед второй. Был клиент, который ежедневно с 9 до 18 часов увеличивал поток своих уникальных метрик. А потом к концу дня они падали. Он не клал базу, но вводил кучу новых уникальных метрик, которые влияли на перегруженность базы данных. Этим клиентом был маленький K8S-кластер, в котором собирались метрики из каждого пода и содержали уникальный идентификатор. Мы связались с дежурной командой клиента — они срезали большую часть своих метрик: уменьшили количество уникальных метрик почти на 100 млн. Есть метрика Charn Rate, она показывает объем уникальных новых временных рядов для базы данных.

Деградация записи — когда вдруг увеличивается время вставки данных в базу данных в VictoriaMetrics, что приводит к тому, что мы копим лаг на Кафках. Кластерная VictoriaMetrics — уникальная база данных, надо понимать, что время вставки во всю базу данных равно времени вставки в самый медленный storage внутри нее. Именно на базе этого нюанса как раз все триггеры дальше расписаны.

Мы выводим storage на работу, и весь поток, который шел на этот storage, по этому hash ring переходит на следующий storage в списке. Там появляются 2 потока, и все, что добавляется, — новое для этого storage. Если он находится в перегруженном состоянии, весь новый поток ему надо будет переварить. А вставка данных в storage — это очень медленная операция.

Залипание storage. В основном наблюдали на docker: storage может внезапно потерять сеть, потом оживает в зомбическом состоянии: ожил, мы даже с него скрейпали немножко метрик, потом опять умер. И в таком состоянии пребывает: то появился, то пропал, то появился, то пропал. Решения мы пока не нашли. Единственное, что мы здесь сделали, — перевезли с docker на systemd, но не помогло. Пока у нас открытый вопрос, как это чинить.

Маленькие storage лучше, чем большие, — базовая рекомендация ребят из Виктории. У нас до версии 1.93 VictoriaMetrics повторялась ситуация: раз в месяц в 7 утра происходил сброс кэшей на всех storage в кластере. Это приводило к тому, что все данные, которые летели в storage, вдруг становились новыми. Storage начинал их медленно вставлять, а скорость, естественно, деградировала. Все, что у нас есть, — базовая рекомендация.

Появляются новые aaS-интеграции с теми клиентами, что у нас уже были, и эти интеграции создают дополнительную поисковую нагрузку. Каждый поисковый запрос в этой эпохе, который долетает до нашего движка, проверяется на период, за который нужны данные. Если до 14 дней, мы направляем запрос в краткосрочное хранилище. Если запросу нужны данные за более долгий период, мы отправляем его в долгосрочное хранилище.

По профилю нагрузки в эту эпоху мы достигли 15 млн входящих точек в секунду на весь Sage. И в самом нагруженном кластере VictoriaMetrics нагрузка — 4,5 млн входящего потока точек в секунду. Таргетов 100 тысяч, из них метрики 30 тысяч таргетов попадают к нам по протоколу пул-модели, скрейпингу, а оставшиеся 70 тысяч — по протоколу remote write. Поисковых запросов 1 200 против 100 ранее

Получили метрики за год. По этим метрикам мы можем строить тренды. По этим данным мы можем прогнозировать нагрузку на Metrics Collectors, например, или на базы данных, и пользователи теперь могут планировать масштабирование компонентов. Со storage для долгосрочного хранения есть нюанс: мы использовали HDD-диски. Это рабочая идея, но помним, что это HDD и надо поглядывать за IO wait.

Пример, как мы вводили один из новых дата-центров и как менялась метрика byte in в нашем Metrics Collector для протокола remoute write за полгода

Закрыли прямую запись в базу данных. Теперь в Metrics Collector есть отложенная запись, он отдает приоритет свежему потоку пользовательских метрик, и, если база деградировала и восстановилась, свежие метрики будут попадать в нее первыми. Пользователи смогут быстрее реагировать на свои инциденты. Мы можем вывести как минимум один storage на работу без влияния на пользователей.

Подводим итоги всех эпох

Выросли по нагрузке на два порядка. За четыре года мы выросли по нагрузке больше чем в 100 раз. От цифр на весь входящий поток точек в Sage, именно от 100 тысяч в секунду, и с сроком хранения только на Prometheus, в случае Prometheus от 7 дней, до 15 млн в секунду, и срок хранения у нас вырос уже до одного года.

Добились надежности 99,6—99,8%. Поиск по метрикам — 99,8%, запись по метрикам в разрезе дата-центров — от 99,6 до 3,9%.

Мы столкнулись с базой данных Prometheus, которая считается стандартом, но нам не хватило этой базы для хранения данных. Поэтому мы перешли на VictoriaMetrics Single и позднее — на VictoriaMetrics Cluster. VictoriaMetrics Single удобна, если мы знаем объем нагрузки и он постоянный: масштабироваться можно только вертикально. Если нагрузка неизвестна, тогда выбор — VictoriaMetrics Cluster и возможность всегда докинуть новые storage, когда это нужно.

У VictoriaMetrics качественный саппорт и читабельный код, который можно запустить и продебажить на ноутбуке, как поведет себя база. У нас есть несколько кейсов, когда мы продебажили, нашли проблему после очередного релиза и обратились в саппорт VictoriaMetrics, и уже ребята из саппорта починили проблемы в очередном релизе.

Если строим такую систему заново, важны такие моменты:

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

Банк растет. Инфраструктуры и приложений будет все больше и больше. И нам надо уметь хранить еще больше метрик.

Оптимизируем хранение. Сделали мультикластерную инсталляцию VictoriaMetrics в каждом дата-центре. Например, у нас есть дата-центр, там два экземпляра кластеров VictoriaMetrics, а мы хотим пять.

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

А еще у нас есть позитивный эксперимент с коллокейшеном баз данных. Мы на одном физическом сервере разворачиваем storage в vmstorage и elastic data node. Внедрили в прод и сэкономили на новом железе.

Хочу поблагодарить всех причастных, кто помог мне собрать и поднять артефакты разных эпох. Для нас это было настоящее путешествие в прошлое.

Что еще произошло с 2024 года:

Запустили пайплайн записи метрик в K8s — теперь тратим значительно меньше времени на обслуживание, релизы и масштабирование.
Сделали подсчет кардинальности потока метрик на основе HLL, с его помощью можно быстрее выявлять шумных клиентов и ограничивать их поток.
Запустили отдельное приложение для обслуживания пайплайна записи метрик. Скрепинг-таргеты, recording rules, квоты — все управляется через единый сервис.
Плотно поработали с opscost, внедрили автоматику по реконсайлу VictoriaMetrics Cluster, на базе собственной разработки Zefir Platform для Stateful без куба. Это позволило нам “по Yaml” легко менять конфигурацию кластера и создавать новые кластера, развернутые на железе или виртуальных машинах. А еще теперь каждый новый компонент автоматически ставиться на мониторинг.

Полезные материалы:

Как мы внедряли SLO в платформу, которая отвечает за наблюдаемость в банке

Связанные доклады:

1. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны / Роман Щербаков (Т-Банк)

2. Почему для SRE важно уметь читать код / Максим Ванюшкин (Тинькофф)

3. DevOps-эры в Тинькофф: культура, люди, инструменты / Станислав Халуп

VictoriaMetrics:

1. Доклад OSMC 2022 | VictoriaMetrics: scaling to 100 million metrics per second

2. Доклад Writing a TSDB from Scratch: Performance Optimization

3. Статья How VictoriaMetrics makes instant snapshots for multi-terabyte time series data

4. Статья How to reduce expenses on monitoring: Swapping in VictoriaMetrics for Prometheus

5. Статья Grafana Mimir and VictoriaMetrics: performance tests