VictoriaMetrics для небольшого парка VPS: как выбрать срок хранения и посчитать диск

Десять серверов — число скромное. Его можно пересчитать по пальцам, нарисовать на одной схеме и помнить по именам. Но диск VictoriaMetrics занимают не серверы, а временные ряды, и их количество растёт по собственным законам. Иногда оно почти не зависит от числа машин, а иногда один неудачно выбранный лейбл делает из десяти серверов хозяйство на десятки тысяч наблюдаемых объектов. Поэтому разговор о диске стоит начинать не с вопроса «сколько гигабайт на сервер», а с вопроса «что именно система считает отдельной сущностью».

Что такое один ряд: имя и все метки вместе

Временной ряд в Prometheus-подобной модели определяется именем метрики и полным набором меток. Возьмём метрику node_cpu_seconds_total. Для одного сервера с четырьмя ядрами и восемью режимами процессора (idle, user, system, iowait и другие) это не одна метрика, а тридцать два ряда: каждая пара «ядро — режим» живёт отдельно. Добавьте метку instance, и у каждого сервера получится свой набор из тридцати двух рядов. Ряд {cpu="0", mode="idle", instance="web-1"} и ряд {cpu="0", mode="idle", instance="web-2"} для хранилища — разные объекты со своей историей.

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

Второе следствие менее очевидно. Хранилище платит не за «количество метрик, которые вы придумали», а за количество комбинаций, которые действительно появились. Ряд, в который хоть раз поступила точка, занимает место в индексе и в данных, даже если потом он замолчал.

Как метки множат объём, не добавляя ни одной машины

Покажем это на условном примере; числа здесь иллюстрируют механику, а не описывают чью-то реальную инфраструктуру. Допустим, на каждом из десяти серверов работает веб-приложение, которое отдаёт гистограмму длительности запросов. В гистограмме, скажем, двенадцать корзин (bucket) плюс сумма и счётчик — четырнадцать рядов на один набор остальных меток.

• Метка method принимает четыре значения: GET, POST, PUT, DELETE.
• Метка status — пять классов ответов.
• Метка route — тридцать маршрутов.

Верхняя оценка: 14 × 4 × 5 × 30 = 8 400 рядов на один сервер, или 84 000 на десять. Реальных комбинаций будет меньше, скажем, половина, но порядок понятен. Теперь представим, что разработчик добавил метку user_id или кладёт в route путь вместе с идентификатором: /orders/48213. Серверов по-прежнему десять, а число рядов перестало зависеть от инфраструктуры и стало зависеть от активности пользователей. Это называется высокой кардинальностью, и именно она ломает любые бюджеты «на сервер».

Есть и тонкая разновидность проблемы — churn, то есть оборот рядов. Если метка содержит то, что регулярно меняется (имя пода, идентификатор контейнера, версия релиза, идентификатор сборки), то при каждом перезапуске появляются новые ряды, а старые перестают получать данные. Одновременно активных рядов может быть немного, а за месяц через хранилище пройдут сотни тысяч разных. На VPS с долгоживущими сервисами churn обычно мал, но он появляется там, где вы запускаете контейнеры с динамическими именами или часто выкатываете релизы с версией в метке.

Первый вывод для планирования: прежде чем считать диск, нужно знать, сколько рядов у вас есть сейчас и какие метрики дают больше всего. В документации VictoriaMetrics для одиночного сервера описан cardinality explorer — инструмент, который показывает, какие имена метрик и метки порождают больше всего рядов (описание в документации single-server). Это самый короткий путь от общей тревоги к конкретному виновнику: обычно выясняется, что две-три метрики занимают львиную долю всех рядов, и именно с ними стоит разбираться первыми.

Почему «средний байт на точку» не отвечает на вопрос

В обсуждениях ёмкости часто встречается готовая формула: число рядов × частота опроса × срок хранения × средний размер точки. Формула соблазнительна, потому что ею можно посчитать на салфетке. Беда в том, что последний множитель — не константа. Размер точки после сжатия зависит от характера данных: счётчик, который растёт ровными шагами, сжимается очень хорошо; значение, которое прыгает случайным образом, — заметно хуже; постоянное значение почти ничего не стоит. Кроме того, на диске хранятся не только сами значения, но и индекс рядов, а его размер зависит от числа и длины меток, а не от числа точек.

Поэтому брать чужое число «байт на sample» и умножать — значит доверить бюджет чужому профилю данных. Ваш парк может состоять из ровных счётчиков процессора и сети, а может включать скачущие бизнес-метрики; соотношение окажется другим. Надёжнее измерить собственный профиль и использовать его как коэффициент, понимая, что он справедлив именно для вашего набора метрик на тот период, когда вы его снимали.

Как измерить профиль на собственных данных

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

Рабочая последовательность такая:

1. Зафиксируйте размер каталога данных в начале измерения, например командой du -sh по каталогу хранилища, и запишите дату.
2. Через сутки, трое и неделю снимайте тот же размер. Не доверяйте одной точке: в первые часы хранилище ещё не выровнялось, а фоновые слияния данных периодически меняют картину.
3. Параллельно снимайте по собственным метрикам VictoriaMetrics число принятых за период точек и число активных рядов. Точные имена метрик и запросы возьмите из актуальной документации той версии, которую вы запустили.
4. Разделите прирост диска на число принятых точек. Получится ваш эмпирический коэффициент — не гарантия, а наблюдение для этого набора метрик.

Важная оговорка: прирост за первые дни включает разовые расходы — построение индекса для всех рядов, которые появились впервые. Позже, когда набор рядов стабилизируется, рост становится ровнее и определяется в основном новыми точками. Поэтому полезно смотреть прирост на втором отрезке измерения отдельно от первого: так видно, сколько стоит «знакомство» с рядами и сколько — их ежедневное пополнение.

Расчёт на примере: как получить цифру и как её не переоценить

Продолжим условный пример. Пусть после недели наблюдения вы выяснили: активных рядов около 60 000, интервал сбора 30 секунд, то есть за сутки каждый ряд даёт 2 880 точек. Это 172,8 млн точек в сутки. Допустим, прирост каталога за последние сутки устоявшегося периода составил 0,35 ГБ. Тогда эмпирический коэффициент — примерно 2 байта на точку. Число здесь выдуманное и нужно только для демонстрации хода рассуждения; ваше может оказаться иным, и это нормально.

Дальше можно прикинуть суточный прирост: 0,35 ГБ. За 90 дней получается около 31,5 ГБ, за год — порядка 128 ГБ. Но прежде чем записать это в бюджет, проверьте три вещи.

• Стабильность рядов. Если за неделю число активных рядов росло, экстраполировать нужно растущую величину, а не текущую. Посмотрите динамику, а не только последнее значение.
• Сезонность. В неделю измерения мог не попасть релиз, нагрузочный пик или включение нового сервиса. Разумно добавить поправку на запланированные изменения: новый сервис — это новые ряды, и их число можно оценить заранее по той же логике произведения меток.
• Различие в характере данных. Новые метрики могут сжиматься хуже старых. Если планируется подключить что-то заметно отличающееся по природе, коэффициент придётся пересматривать после недели работы с ним.

Рост не обязан быть линейным. Если вы добавляете серверы, число рядов растёт примерно пропорционально только для метрик без «пользовательских» меток; для остальных зависимость другая. Именно поэтому правильнее считать от числа рядов и частоты, а не от числа машин, и перепроверять коэффициент после существенных изменений в наборе метрик.

Срок хранения: что он означает и чем платит диск

Параметр retentionPeriod задаёт, как долго VictoriaMetrics хранит данные; всё, что старше, удаляется автоматически (документация single-server). Удобно, что чистить ничего вручную не нужно. Неудобно другое: уменьшив срок, вы безвозвратно потеряете старые данные, а увеличив — не получите задним числом то, что уже было удалено. Поэтому срок стоит выбирать не от аппетита, а от вопросов, на которые команда реально будет отвечать.

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

Из таблицы видно главное: короткие вопросы требуют подробности, длинные — только общего контура. Но срок хранения в базовой настройке одинаков для всех рядов, и подробность хранится ровно столько же, сколько и всё остальное. Если вы выбираете срок в год «на всякий случай», то платите диском за год полной детализации тех метрик, которые через месяц никому не нужны в таком виде.

Здесь полезно честно разделить два пути. Первый — выбрать срок под самый длинный вопрос и принять цену. Для небольшого парка это часто разумно: при нескольких десятках гигабайт на год вопрос бюджета снимается простым расчётом. Второй — держать срок покороче, а долгие вопросы обслуживать отдельно: например, заранее считать нужные агрегаты (суточные максимумы, перцентили, свободное место) и хранить их компактным набором. Выбор зависит от того, сколько рядов у вас и во что они обходятся. Нужные механизмы агрегации и экспорта проверяйте в документации вашей версии: сервер поддерживает Prometheus querying API и способы импорта и экспорта временных рядов (документация single-server), на этом можно строить выгрузку нужных данных в отдельное место, но детали настройки зависят от версии и от ваших задач.

Что платит диск, кроме самих точек

Расчёт «точки × коэффициент» описывает установившийся режим. Но на реальном диске есть ещё три статьи расхода, которые легко забыть.

Фоновые слияния данных

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

Перерыв в сборе и последующее восстановление

Если сборщик метрик остановился на несколько часов или сервер с VictoriaMetrics был недоступен, после возвращения возможны разные сценарии: данные могли быть дозаписаны из буфера агента, а могли и потеряться. Если вы дозаливаете пропущенное через импорт, то хранилищу придётся принять большой пакет старых по времени точек за короткий срок, и нагрузка на запись и на диск в этот момент будет выше обычной. То же касается переноса данных с одной машины на другую через экспорт и импорт: на время операции понадобится место и на источнике, и на приёмнике, а иногда и для промежуточного файла выгрузки.

Сам сервер мониторинга

Мониторинг, за которым никто не следит, — это просто диск, который однажды закончится. Документация рекомендует наблюдать и за самой VictoriaMetrics (документация single-server). Практически это означает три алерта: на свободное место с запасом по времени (не «осталось 5%», а «при текущем темпе закончится через две недели»), на резкий рост числа активных рядов и на остановку приёма данных. Первый защищает от заполнения диска, второй ловит новую метку с высокой кардинальностью в день её появления, третий — тихий обрыв сбора.

Запас под эксплуатацию: как его оценить, а не назначить

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

1. Установившиеся данные: суточный прирост по измеренному коэффициенту × срок хранения в днях.
2. Поправка на рост: новые серверы и сервисы, оценённые по числу будущих рядов; отдельно — метрики, которые вы только планируете включить.
3. Рабочее пространство: наблюдаемая амплитуда колебаний размера каталога из-за фоновых слияний, с запасом.
4. Операции: место под выгрузку и возможный повторный импорт после перерыва сбора, если вы собираетесь такие операции выполнять.
5. Система и остальное: операционная система, журналы, другие службы на той же машине.

В нашем условном примере это выглядело бы так: 90 дней по 0,35 ГБ дают около 32 ГБ; добавим сюда ожидаемый рост рядов, допустим, вдвое после подключения новых сервисов — получится порядка 64 ГБ; рабочий запас и операции удвоят потребность до значения, заметно большего самого расчёта данных. Дело не в конкретных цифрах, а в структуре: чистые данные — лишь первая строка в смете.

Если на этом этапе вы видите, что бюджет упирается в размер диска, есть рычаги в порядке «дешёвые — дорогие». Сначала убрать лишние метки и метрики, которые никто не использует (это снижает число рядов и индекс). Затем увеличить интервал сбора для малоподвижных метрик: если значение меняется раз в минуту, опрос каждые пятнадцать секунд только раздувает число точек. После этого сокращать срок. И только потом покупать диск побольше.

Какой диск и какая машина нужны под это

Запись метрик — поток мелких обновлений, а чтение запросами — иногда тяжёлые сканирования за большие интервалы, поэтому быстрый диск здесь полезен, а не декоративен. На VPS MAATRIX используется NVMe-хранилище, доступен root-доступ, а линейка тарифов начинается с конфигурации 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe (Ba) и доходит до 16 vCPU, 32 ГБ и 320 ГБ (Djed); промежуточные — Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) (публичное предложение VPS MAATRIX). Эти цифры описывают ресурсы машины, а не ёмкость мониторинга: сколько рядов и какой срок она вытянет, покажет ваш замер, а не строка в каталоге.

Практически для парка из десяти серверов сначала смотрите на диск и оперативную память: объём данных мы уже оценили, а память влияет на то, насколько комфортно работают запросы и приём рядов, особенно если рядов много. Процессор обычно важнее при тяжёлых запросах по длинным интервалам. Если ваш расчёт показывает, что данные с запасом помещаются в диск небольшой конфигурации, начинайте с неё и следите за метриками самого сервера; если нет — выбирайте ступенью выше. Иметь отдельную машину под мониторинг разумно ещё и потому, что при проблемах на наблюдаемых серверах вы не потеряете и историю, и средство её изучения одновременно. А вот утверждать, что отдельный VPS сам по себе даёт отказоустойчивость мониторингу, нельзя: для этого нужны отдельные меры вроде внешнего контроля доступности и копирования важных данных.

Если вы ещё сомневаетесь, нужна ли вам VictoriaMetrics вместо привычного решения, сопоставьте сценарии в материале VictoriaMetrics вместо Prometheus: когда есть смысл: там разобрано, в каких случаях переезд оправдан.

Как проверить бюджет через месяц

Расчёт — гипотеза, а месяц работы — её проверка. Через четыре недели сопоставьте прогноз с фактом по трём показателям: фактический прирост диска против расчётного, число активных рядов против ожидаемого и амплитуда колебаний свободного места. Если рост рядов опережает прогноз, откройте cardinality explorer и найдите метрики-лидеры: чаще всего причина в одной-двух метках. Если диск растёт медленнее, значит, ваш коэффициент оказался консервативным, и срок хранения можно увеличить — а это приятная корректировка. Если колебания свободного места больше ожидаемых, увеличьте запас до того, как диск упрётся в предел.

Полезная привычка — после каждого значимого изменения (новый сервис, новая метка, смена интервала сбора) заново оценивать число рядов на бумаге, до выкатки. Одно добавленное измерение с тридцатью значениями умножает число рядов соответствующей метрики на тридцать, и лучше узнать об этом из карандашного расчёта, чем из алерта о свободном месте.

Ради какого вопроса всё это хранится

Остаётся самое неудобное: зачем нам вообще эта история? Срок хранения — это не техническая константа, а ответ на вопрос «какое решение мы сможем принять благодаря данным трёхмесячной давности». Если за последний год к метрикам старше двух недель никто не обращался, шесть месяцев хранения — это не осторожность, а привычка, за которую вы платите диском и вниманием. Если, наоборот, каждый квартал вы возвращаетесь к графикам прошлого года, чтобы спланировать ёмкость, то короткий срок обойдётся дороже, чем лишние гигабайты.

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