Требования к серверу для Zabbix, Prometheus и Loki: расчет

Почему мониторинг и логи начинают тормозить через пару недель

В первые дни после внедрения все обычно выглядит отлично: графики рисуются, алерты приходят, поиск по логам работает. А через 2-4 недели появляются задержки. Чаще всего дело не в том, что инструменты плохие, а в том, что реальная нагрузка оказалась выше той, что была в пилоте.

Главная причина - данные растут не линейно. Сначала подключают базовые хосты и пару дашбордов. Потом добавляются сервисы, команды включают дополнительные экспортеры, появляются новые метки (labels). Каждый такой «небольшой» шаг умножает объем хранения и число операций чтения и записи.

Быстрее всего раздуваются:

• Логи. Включили debug на день и забыли выключить, добавили несколько приложений, и дневной объем легко удваивается.
• Кардинальность метрик. Один неудачный label (user_id, request_id, полный URL) превращает одну метрику в тысячи или миллионы рядов.
• Алерты. Делают много правил без дедупликации и без приглушения по времени. Система чаще пересчитывает правила и пишет события.

Симптомы обычно видны сразу, если знать, куда смотреть. Запросы к графикам и поиску становятся длиннее, особенно «за неделю» или «за месяц». Алерты приходят с задержкой или пачками. Появляются пропуски: у Prometheus это «дыры» на графиках, у Loki - пропавшие промежутки в логах, у Zabbix - рост очередей и запаздывание новых значений.

Отдельная частая причина - диск. Пока данных мало, даже медленный диск «терпит». Когда метрики и логи подрастают, нагрузка превращается в постоянные мелкие записи и чтения, и все упирается в IOPS. CPU и RAM могут быть еще «в зеленой зоне», а система уже ощущается медленной.

Поэтому требования к серверу для Zabbix, Prometheus и Loki нельзя оценивать по ощущениям первой недели. Нужны входные цифры и расчет с запасом, иначе через месяц вы будете не мониторить инфраструктуру, а мониторить мониторинг.

Что именно нагружает сервер в Zabbix, Prometheus и Loki

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

Zabbix. Основная нагрузка рождается на сборе и обработке данных. Каждый опрос агента, SNMP или скрипта запускает цепочку: получить значение, записать историю, пересчитать триггеры, иногда построить тренды (агрегации). Чем короче интервал и чем больше элементов данных, тем выше нагрузка на CPU и диски. А база (часто SQL) активно пишет историю, поэтому задержки диска быстро превращаются в очередь.

Prometheus. Он регулярно скрейпит метрики и хранит их как временные ряды. Главный враг - метки и кардинальность: метрик вроде бы немного, но комбинаций label-ов получается тысячи или миллионы. Это бьет по RAM (индексы и активные серии), по CPU (сжатие, запись блоков, вычисление правил) и по диску (постоянные мелкие записи TSDB).

Loki. Чаще всего упирается в объем логов и характер запросов. Прием логов дает постоянную запись на диск, а запросы «за неделю по всем сервисам» заставляют читать много чанков по времени. Память нужна на индексы и буферы, но узкое место обычно дисковая подсистема и IOPS.

Практическая подсказка: если у вас 200 серверов и вы включили логи приложений в debug, Loki может «положить» диск быстрее, чем Zabbix или Prometheus. А если в Prometheus добавить label вроде request_id, то память уйдет первой, даже при небольшом трафике.

Если грубо разложить по ресурсам:

• CPU: триггеры и правила (Zabbix), обработка серий и запросы (Prometheus), тяжелые поиски по логам (Loki)
• RAM: кардинальность и кеши (Prometheus), кеши БД и очереди (Zabbix), индексы и буферы (Loki)
• Диски: история и индексы (Zabbix), записи TSDB (Prometheus), поток логов и чтение чанков (Loki)

Если планируете держать весь стек на одном сервере, чаще всего выигрывают быстрые SSD и хороший запас RAM. В таких задачах проще жить в классе стоечных серверов, например уровня GSE S200, где легче не упереться в диски и память при росте.

Какие входные данные собрать до расчета

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

1. Инвентаризация целей. Важно не только число серверов, но и все, что становится отдельной целью: ВМ, контейнерные ноды, сетевые устройства, СХД, базы, балансировщики. Отдельно отметьте «шумные» объекты: базы данных, высоконагруженные сервисы, устройства с большим числом интерфейсов.

2. Поток метрик. Для каждого типа хоста зафиксируйте, сколько метрик реально планируете собирать и с каким интервалом. Разница между 15 сек и 60 сек - примерно 4x по точкам. Это сразу увеличивает запись на диск, фоновые компакции и нагрузку на запросы.

3. Поток логов. Нужны приземленные цифры: сколько источников (приложения, nginx, AD, firewall, endpoints), средний размер события и скорость (событий в секунду) в пике. Если данных нет, возьмите пару типичных файлов логов за сутки и посчитайте объем и количество строк в минуту в часы пик.

4. Срок хранения (retention). Задайте отдельно для метрик и логов. Частая практика: метрики держать дольше (6-12 месяцев для трендов), логи короче (7-30 дней), потому что они быстрее «съедают» диск и требуют больше IOPS при поиске.

5. Активность пользователей. Если 1-2 инженера смотрят пару дашбордов, требования одни. Если каждый день идут расследования, частые поиски по логам и сравнение периодов на графиках, нагрузка на CPU и RAM заметно выше.

Если хотите оформить это в короткий чек, достаточно пяти пунктов: цели мониторинга, метрики и интервалы, источники логов и пики, retention (раздельно), активность пользователей.

Интервалы, объемы и retention: где чаще всего ошибаются

Проблемы чаще начинаются не из-за «слабого железа», а из-за завышенных ожиданий к детализации. Чем чаще вы собираете метрики и чем дольше храните историю, тем быстрее растут расходы. Поэтому сначала фиксируют интервалы и retention, и только потом считают CPU, RAM и диски.

Редкий опрос экономит ресурсы, но вы теряете диагностику. Если метрика снимается раз в 5 минут, а инцидент длится 40 секунд, вы можете его не увидеть. С другой стороны, «все по 15 секунд» на сотни хостов создает шум, и данные перестают помогать.

Хорошее правило: короткие интервалы оставляйте там, где важна динамика и где вы действительно будете смотреть график. Обычно 15-30 секунд оправданы для каналов связи, загрузки ключевых узлов, очередей, критичных API и баз данных. Для «состояния сервиса» (up/down), температуры, заполнения дисков и большинства системных метрик чаще хватает 1-5 минут.

Перед тем как ставить короткий интервал, ответьте себе на четыре вопроса:

• Что именно сломается, если я увижу проблему не через 30 секунд, а через 3 минуты?
• Будет ли алерт, и кто его обработает?
• Сколько объектов реально требует такой точности?
• Есть ли смысл уменьшить точность, но увеличить срок хранения?

С логами ошибка еще проще: отправляют «как есть», без фильтрации и лимитов. В итоге Loki хранит тонны однотипных строк (debug, healthcheck, access без пользы), а поиск становится медленным. Часто достаточно заранее отрезать шум (debug в проде, частые 200 OK от балансера), убрать персональные данные и нормализовать поля (уровень, сервис, запрос, код ответа), чтобы снизить объем в разы.

Retention влияет на диски сильнее, чем на CPU. «Еще 30 дней истории» почти всегда означает заметный рост емкости и IOPS. Пример: если сервис генерирует 200 ГБ логов в день, то 7 дней - это около 1.4 ТБ сырого объема, а 30 дней - около 6 ТБ, и это еще до накладных расходов индексов и репликации.

Как CPU, RAM и диски связаны с реальной нагрузкой

В мониторинге важно думать не про «ядра и гигабайты», а про действия, которые система делает каждую секунду. Один и тот же объем данных может «летать» на одном сервере и тормозить на другом из-за того, где появляется узкое место.

CPU уходит на прием данных (ingest), обработку и агрегации, сжатие (особенно заметно в логах) и выполнение запросов, когда открывают дашборды или начинают расследование. Нагрузка редко ровная: днем больше запросов, ночью могут быть пики фоновых задач (переиндексации, компакции, очистки). Если CPU держится на 70-80% почти постоянно, любой всплеск даст очередь.

RAM нужна под кеши и рабочие наборы данных: активные серии метрик, очереди на запись, временные буферы, всплески запросов. Если памяти мало, система чаще ходит на диск, и даже быстрый SSD не спасает тяжелые запросы. Явный признак нехватки RAM - активный своп (его лучше избегать).

Диски определяют, насколько быстро вы можете записывать и читать данные. Для метрик критична стабильная запись. Для логов важны и запись, и чтение, когда ищут по периодам и фильтрам. Здесь решают не только гигабайты, но и IOPS: множество мелких операций быстро «убивают» HDD.

Пошаговый расчет ресурсов для стека мониторинга и логов

Ниже порядок, который дает рабочую оценку до покупки железа и помогает быстро пересчитать sizing при росте.

1. Посчитайте метрики в секунду (MPS) и пики. Для Prometheus это примерно: targets x метрики на target x (1 / scrape interval). Затем умножьте на коэффициент пиков (обычно 1.5-3), если есть автоскейл, ночные джобы, массовые рестарты.

2. Оцените запросы и дашборды. CPU часто «съедают» не сбор, а графики и алерты: частые range-запросы, панели с большим окном (7-30 дней), много пользователей. Если планируются NOC-экраны и постоянные обновления, закладывайте отдельный запас CPU.

3. Прикиньте RAM под активные данные и кеши. Если память «впритык», вы проиграете диску и получите задержки. Для Prometheus и Loki важна RAM под индексы, кеши и горячие чанки. Для Zabbix добавьте память под БД и кеши сервера (history, trend, value cache).

4. Сведите хранение в дневные объемы. Метрики: оцените средний размер одной точки и умножьте на MPS и секунды в дне. Логи: дневной объем в ГБ плюс индекс. Затем умножьте на retention и добавьте место под компакции и временные файлы.

5. Заложите рост и «непредвиденные источники». Минимум 30-50% по CPU/RAM и по диску. Новые сервисы, дополнительные лейблы и всплески логов во время инцидентов появляются всегда.

Если по расчету видно, что основной риск - дисковая нагрузка и память под активные данные, разумнее сразу смотреть сервер с быстрыми SSD и запасом RAM (например, в классе стоечных систем уровня S200 Series), чем пытаться «вытянуть» все на одном большом HDD-массиве.

Расчет дисков: емкость, IOPS и выбор SSD или HDD

Диски - то, на чем чаще всего «умирает» мониторинг через пару недель. Для стека Zabbix/Prometheus/Loki важно не только сколько гигабайт влезет, но и как быстро система сможет писать и читать данные при пиковых запросах.

Емкость: дневной объем и retention

Начните с простого расчета: события (или строки логов) в секунду x средний размер x 86400. Например, 500 строк/с по 300 байт дадут около 13 ГБ в день (без учета сжатия и индексов). Затем умножьте на retention и добавьте запас 30-50% на рост, индексы, временные файлы и «неучтенные» источники.

Держите отдельные оценки для метрик и логов. Метрики обычно компактнее, но любят память и регулярные записи. Логи быстрее «съедают» емкость и часто требуют быстрых чтений при расследованиях.

IOPS: почему чтение иногда важнее записи

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

Если часто ищете по логам и строите дашборды, приоритет - SSD и достаточные IOPS. Если логи пишутся «потоком», а читаются редко, можно думать о более дешевом хранилище, но обычно с ограниченным retention.

RAID влияет и на скорость, и на надежность. Зеркалирование часто помогает с чтением и спасает при отказе диска, а некоторые варианты RAID ухудшают мелкие записи из-за дополнительных операций.

По возможности не складывайте все в один «мешок»: отдельный диск или пул под ОС, отдельный под метрики, отдельный под логи. На одном сервере разнос по пулам особенно важен, чтобы пики логов не душили метрики и интерфейс.

Архитектура: один сервер или разносить по ролям

Один сервер для Zabbix, Prometheus и Loki кажется проще: купить, поставить и обслуживать. На старте это правда удобно, когда источников мало, а retention короткий. Но со временем все компоненты начинают спорить за диск и память, и узкое место проявляется внезапно.

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

Разнос на два узла обычно дает заметный выигрыш уже в «среднем» масштабе. Самое практичное разделение - метрики отдельно, логи отдельно. Метрики (Zabbix + Prometheus) чаще упираются в CPU и RAM при расчете правил и запросах, а Loki почти всегда упирается в диск.

Горизонтальный рост стоит планировать, когда добавлять ресурсы в один сервер становится дорого или неудобно. Признаки: диск постоянно занят, нельзя выделить окно обслуживания без потери данных, рост идет каждый месяц. Тогда проще добавлять узлы по ролям (например, вынести базу Zabbix или выделить отдельный узел под запись логов).

Для бэкапа полезно сохранять то, что сложно восстановить вручную: конфиги, правила алертов, шаблоны, дашборды, базу Zabbix (если критична по истории), параметры парсинга и список источников, плюс проверенный план восстановления на тестовой машине. Полные бэкапы всех логов редко окупаются из-за объема.

Типичные ошибки, из-за которых все начинает тормозить

Проблемы обычно начинаются из-за того, что нагрузку на стек не посчитали заранее. Когда sizing делают «на глаз», через 3-6 недель появляются симптомы: запросы выполняются все дольше, алерты приходят с задержкой, диски внезапно заканчиваются.

Самые частые ошибки:

• Retention ставят «побольше» и не проверяют, сколько места это съест с учетом индексов и роста источников.
• Раздувают кардинальность метрик динамическими метками (user_id, request_id, полный URL, случайные имена контейнеров).
• Собирают логи без фильтрации и лимитов: тащат debug, дублируют одно и то же из нескольких агентов, не ограничивают размер строки и частоту.
• Складывают прод и тест в одно хранилище без квот и правил.
• Не следят за самим мониторингом: нет алертов на заполнение дисков, рост кардинальности, задержку скрейпа, очереди, время запросов.

Простой пример: команда добавила метку path с полным URL и параметрами. В первый день все выглядит нормально, а через неделю количество уникальных рядов растет кратно, Prometheus чаще делает компакции, а запросы «за 7 дней» начинают зависать.

Практичнее сначала ограничить источники и правила (retention, фильтры, квоты), и только потом наращивать ресурсы.

Быстрая проверка после запуска: чеклист на 15 минут

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

Выберите один типичный рабочий час и один пиковый (например, утро понедельника) и проверьте:

• CPU: среднее и пики за сутки. Если в пики вы регулярно видите 80-90% на несколько минут, скоро начнут расти задержки запросов и опоздания алертов.
• RAM и своп. Должен оставаться запас. Активный своп почти всегда означает нехватку RAM или слишком высокую кардинальность и объем.
• Диск: задержки и скорость. Смотрите не только «занятость», но и время отклика диска. Рост задержек на записи быстро ломает Loki и базы под мониторинг.
• Скорость роста данных и прогноз. Зафиксируйте, сколько гигабайт прибавилось за сутки, и умножьте на 90 и 180 дней.
• Алерты и пропуски данных. Проверяйте задержку между событием и уведомлением, а также «дыры» в графиках.

Если нужно быстро собрать базовые цифры, подойдут такие команды:

uptime
free -h
vmstat 1 5
iostat -xz 1 5

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

Пример расчета для средней организации и следующие шаги

Сценарий: 200 серверов (вилка 150-300), несколько критичных систем (БД, шина интеграции, виртуализация) плюс сетевое оборудование. Цель - чтобы стек (Zabbix, Prometheus, Loki) не уперся в ресурсы, когда случится первый инцидент и все одновременно откроют графики и логи.

Реалистичная прикидка для «средней» ИТ: Prometheus держит около 250-400 тысяч активных временных рядов при интервале 30 секунд. Loki принимает в среднем 80-150 ГБ логов в сутки (до сжатия), а во время аварий поток легко растет в 2-3 раза. Retention: метрики 15 дней, логи 7 дней «горячих» (быстрый поиск), дальше - либо удаление, либо перенос в более дешевое хранилище.

Если размещать все на одном узле и хочется предсказуемости, часто стартуют примерно с такой конфигурации:

• 16 vCPU (с запасом под пики запросов и компакшн)
• 64 ГБ RAM
• SSD/NVMe 3-5 ТБ под данные и индексы
• отдельный SSD под ОС и сервисы

Но в реальной эксплуатации чаще выигрывает разделение на два узла: (1) Zabbix + Prometheus, (2) Loki. Так тяжелые запросы по логам и индексы не съедают IOPS у метрик и базы Zabbix.

Запас под рост лучше задавать в понятных цифрах: новые источники (Kubernetes, аудит), рост retention, увеличение кардинальности и числа дашбордов. На практике часто закладывают +30-50% по CPU и диску на год, а по RAM держатся ближе к верхней границе, если планируются новые дашборды и алерты.

Дальше по шагам:

• пилот на 10-20% инфраструктуры на 1-2 недели и замер series count, скорости ingest, прироста объема/сутки
• фиксация SLO для поиска логов и скорости дашбордов, затем корректировка retention и интервалов
• проверка дисков: фактические IOPS и latency в пике и во время компакшна
• решение по масштабированию: второй узел, разнос ролей или HA

Если после пилота видно, что нужен «железный» запас, ECC, много быстрых дисков и внятная поддержка, имеет смысл смотреть в сторону серверов уровня GSE S200. А когда требуется развертывание под ключ (архитектура, отказоустойчивость, поддержка 24/7), можно подключать системного интегратора GSE.kz, чтобы закрыть стык мониторинга, хранения и инфраструктуры без неприятных сюрпризов.