Цена мониторинга: платить за сервис или поднять своё

MAATRIX

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

За что вы платите в SaaS-мониторинге и что не входит в подписку

Коммерческие сервисы мониторинга (сюда попадают и внешние сторожа доступности, и полноценные APM/метрик-платформы) почти всегда считают цену по одной или нескольким осям: число проверяемых хостов, число собираемых метрик, частота опроса (checks per minute), объём хранимых логов/трасс, срок хранения истории. Чем гуще сеть проверок и чем длиннее ретеншн — тем дороже план, и рост здесь почти всегда ступенчатый: как только вы вылезаете за лимит тарифа, вас перекидывает на следующий, который стоит не на 10%, а зачастую в полтора-два раза дороже.

В подписку входит:

• Готовая инфраструктура сбора и хранения — вам не нужно думать о дисках под временные ряды.
• Обновления и патчи безопасности самого стека мониторинга — это забота вендора.
• Часто — встроенные интеграции с алертами (Slack, Telegram, PagerDuty, email) без дополнительной настройки вебхуков.
• SLA на доступность самого сервиса мониторинга — то есть теоретическую гарантию, что мониторинг не упадёт вместе с тем, что он проверяет.

Не входит почти никогда:

• Гибкость дашбордов и запросов — вы работаете в рамках того, что придумал вендор.
• Свобода хранить историю метрик сколько угодно — обычно ретеншн ограничен тарифом, а расширение стоит отдельно.
• Контроль над тем, где физически лежат ваши данные о нагрузке серверов — для инфраструктуры с чувствительными данными это иногда критично.

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

Из чего складывается цена self-hosted стека

Self-hosted вариант — обычно связка вроде Prometheus и Grafana для метрик, Zabbix для более тяжёлого мониторинга парка серверов, или Uptime Kuma для простой внешней проверки доступности. Разница с SaaS в том, что здесь цена не растёт со ступеньками по числу хостов — она почти вся приходится на старте и потом растёт медленно и предсказуемо, пока вы не упрётесь в мощность железа.

Три статьи расходов:

1. Сервер под сам стек мониторинга. Фиксированная ежемесячная цена VPS — не зависит от того, сколько хостов вы наблюдаете, пока хватает CPU/RAM/диска. Небольшой стек Prometheus+Grafana на десяток серверов спокойно работает на паре ядер и 2-4 ГБ RAM; на сотню хостов и больше нужен уже отдельный сервер с заметным запасом по диску под историю.
2. Время на первичную настройку. Установка Prometheus, Grafana, node_exporter, первых дашбордов и алертов — это часы, не минуты. Если делать по шагам (мы разбирали процесс в статье про установку Grafana и Prometheus на Ubuntu 24.04), на базовый рабочий стек уходит от нескольких часов до рабочего дня — в зависимости от того, сколько экспортёров и правил алертинга нужно.
3. Время на постоянную поддержку. Это самая недооценённая статья расходов. Сюда входят: обновление версий (Prometheus и Grafana выпускают релизы с уязвимостями и breaking changes), ротация и бэкап конфигов, разбор упавших алертов из-за некорректных правил, а главное — борьба с ростом объёма метрик со временем.

Рост объёма метрик — отдельная головная боль. Каждый новый сервис, под, контейнер добавляет временные ряды; ретеншн в 30-90 дней на растущей инфраструктуре легко удваивает потребность в дисковом пространстве за полгода-год. С логами то же самое, только острее — там счёт может идти на десятки гигабайт в сутки уже на средней нагрузке (мы разбирали, откуда берётся расход памяти под это, в статье сколько RAM нужно для Grafana Loki). Если не заложить это заранее, диск self-hosted сервера мониторинга кончается внезапно — и мониторинг молчит именно тогда, когда должен был предупредить.

Методика точки безубыточности по числу хостов

Идея простая: у SaaS цена растёт линейно (или ступенчато) с числом хостов/метрик, у self-hosted — почти горизонтальная линия (цена сервера) плюс пологий наклон (время на поддержку, переведённое в деньги через вашу ставку часа). Точка пересечения этих двух линий — и есть порог, после которого self-hosted выгоднее по чистым деньгам.

Формула на пальцах:

Цена_SaaS(N) = N × P_host + доп_метрики + доп_ретеншн
Цена_self(N) = C_server + T_setup / M + T_support × H

Где:

• N — число отслеживаемых хостов/сервисов.
• P_host — цена SaaS за один хост в месяц (или эквивалент из вашего тарифа: цена за N метрик, за checks per minute).
• C_server — фиксированная месячная стоимость сервера под стек мониторинга (не зависит от N, пока хватает мощности).
• T_setup — часы на первичную настройку, размазанные на M месяцев амортизации (обычно 12-24).
• T_support — часы на поддержку в месяц (обновления, разбор инцидентов, донастройка при росте).
• H — ваша internal-ставка часа (даже если это ваше собственное время, а не наёмного сотрудника — оценивайте его не в ноль, иначе сравнение нечестное).

Точка безубыточности по N — это N, при котором Цена_SaaS(N) = Цена_self(N). Дальше алгебра тривиальна: подставляете свои P_host, C_server, T_support, H — и получаете конкретное число хостов, специфичное для вашей ситуации. Важный нюанс: T_support сам растёт с N (больше хостов — больше правил алертинга, больше шума, больше времени на разбор), поэтому кривая self-hosted не идеально горизонтальна, а слабо выпуклая вверх. На малых N это почти не заметно, но при переходе от «десятка серверов» к «сотне» экономия на человеко-часах может съесть часть выигрыша по железу.

Пример расчёта на условных числах

Ниже — иллюстративный расчёт с округлёнными для наглядности значениями, не тарифами конкретного вендора. Подставьте свои цифры вместо этих, смысл в структуре расчёта, а не в конкретных суммах:

При таком наборе переменных типичная картина выглядит так: на 5-10 хостах SaaS почти всегда дешевле — фиксированные издержки self-hosted (сервер + время на настройку) размазываются на слишком малое N, чтобы обогнать. Где-то в диапазоне 20-40 хостов линии обычно пересекаются — точное число зависит от вашего P_host и вашей ставки часа, поэтому не воспринимайте диапазон как универсальный порог, посчитайте свой. После пересечения self-hosted дешевле, и разрыв растёт вместе с N, потому что C_server почти не меняется, пока сервер справляется с нагрузкой, а SaaS продолжает расти линейно или ступенчато.

Практический вывод из методики: если у вас 5-10 серверов — не тратьте время на self-hosted, разница в деньгах не окупит вечера настройки и последующей поддержки. Если у вас счёт от SaaS уже трёхзначный в месяц и продолжает расти с каждым новым сервером — посчитайте по формуле выше, вы почти наверняка уже прошли точку безубыточности.

Скрытые издержки self-hosted, которые не входят в формулу выше

Формула даёт финансовую точку пересечения, но не учитывает то, что сложно перевести в часы напрямую:

• Деградация со временем, а не разово. Стек, который отлично работал на 10 хостах, начинает тормозить на 50 — запросы к Prometheus становятся медленнее, дашборды Grafana подгружаются дольше, а правила алертинга, писанные под меньший масштаб, начинают шуметь или, наоборот, замолкать. Это не разовая настройка, а постоянный процесс подстройки под растущую инфраструктуру.
• Единая точка отказа своей же системы. Если сервер мониторинга — один, и на нём и Prometheus, и Grafana, и Alertmanager, то его собственный отказ (диск, память, сеть) останавливает вообще весь мониторинг разом. У SaaS эта проблема физически вынесена на инфраструктуру вендора.
• Дрейф конфигурации. Экспортёры, которые вы ставили полгода назад, требуют версии, несовместимые с текущим Prometheus; кто-то руками поправил правило алертинга и не закоммитил изменение — такие мелочи копятся и превращают систему в непрозрачную для нового человека в команде.
• Человеческий фактор ключевого держателя знаний. Если стек настраивал один инженер и он ушёл или в отпуске, а что-то сломалось — разбираться придётся с нуля по чужим следам. У SaaS эта проблема снята: там кто-то другой отвечает за доступность сервиса как продукта.

Ни один из этих пунктов не исключает self-hosted как решение — но их стоит закладывать в T_support с запасом, а не оптимистично.

Нефинансовые факторы: скорость, надёжность, доверие

Даже если чистая математика на стороне self-hosted, есть аргументы не про деньги:

• Скорость внедрения. SaaS обычно поднимается за минуты — зарегистрировались, добавили хост, получили алерт. Self-hosted стек, даже по готовому руководству, — это часы на настройку и ещё какое-то время на то, чтобы довести правила алертинга до состояния «не шумит и не молчит». Если мониторинг нужен вчера — это весомый довод в пользу SaaS независимо от долгосрочной экономики.
• Надёжность самого мониторинга как сервиса. У серьёзного SaaS-провайдера обычно распределённая инфраструктура, дежурная команда и SLA на доступность продукта. Ваш self-hosted сервер мониторинга — это ещё один сервер, который тоже может упасть, зависнуть, кончиться местом на диске. Разница качественная: у SaaS есть кто-то, чья работа — следить, чтобы система слежения работала. У self-hosted это по умолчанию никто, пока вы не выстроите это сами.
• Порог входа команды. SaaS с готовым интерфейсом проще передать новому сотруднику: зашёл, увидел дашборд, всё понятно. Self-hosted стек Prometheus/Grafana/Zabbix требует объяснить архитектуру, конфиги, правила — и это тоже время, которое стоит денег, просто не попадает явной строкой в расчёт выше.

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

Кто мониторит мониторинг: главный риск self-hosted схемы

Это вопрос, который редко задают до того, как self-hosted стек падает в первый раз. Если весь мониторинг живёт на одном сервере и этот сервер уходит в offline — метрики перестают собираться, алерты не приходят, а самое неприятное — вы можете не узнать об этом ни от кого, потому что система, которая должна была сообщить о проблеме, и есть проблема.

Практические способы закрыть эту дыру, от простого к сложному:

1. Внешний дешёвый сторож поверх основного стека. Отдельный лёгкий сервис — да, это уже второй мониторинг, но минимальный: например, Uptime Kuma на отдельном небольшом VPS, который раз в минуту стучится к вашему Prometheus/Grafana и шлёт алерт, если те не отвечают. Дёшево, потому что второй сервер маленький и не хранит историю метрик — только проверяет доступность.
2. Dead man's switch на критичные процессы. Для задач, которые должны выполняться регулярно (бэкапы, синхронизация, сама проверка живости мониторинга), полезен внешний сервис, который ждёт периодического пинга и бьёт тревогу при его отсутствии — это уже вынесено за пределы вашей инфраструктуры и не зависит от неё.
3. Географически разнесённый второй узел. Если критичность высокая — второй сервер мониторинга в другой локации, который проверяет и целевую инфраструктуру, и первый сервер мониторинга. Дороже, но закрывает и падение сервера, и падение дата-центра целиком.
4. Гибридная схема. Свой стек для полноты метрик и истории плюс дешёвый внешний SaaS-чекер только на «жив ли сервер мониторинга» — по деньгам это копейки по сравнению с полноценной подпиской, а разрыв «мониторинг молчал месяц» закрывает почти полностью.

Смысл всех вариантов один: self-hosted мониторинг не может быть единственной точкой правды о себе самом. Хотя бы минимальный внешний контур обязателен, и его стоимость нужно закладывать в C_server из методики выше — иначе сравнение с SaaS получается нечестным: там надёжность инфраструктуры уже включена в цену, а здесь её ещё предстоит купить отдельно.

Частые вопросы