Семь серверов, разнесённых по разным провайдерам, постоянная связь между сервисами и ни одного централизованного мониторинга. Команда IT For Prof строила систему именно в таких условиях — когда падение одного узла за несколько минут превращается в инцидент на всей цепочке.
Вот как мы это решили — без избыточного шума, без пропущенных критических событий и с двумя независимыми каналами доставки алертов.
Что было до: серверы без контроля
Клиент управлял семью серверами: четыре ноды Outline VPN, MTProxy-узел, хост со стеком Matrix (Synapse и сопутствующие контейнеры) и веб-сервисы, включая Matrix-federation на нестандартном порту. Мониторинг либо отсутствовал вовсе, либо сводился к ручной проверке через SSH — зашёл, посмотрел, закрыл. Проблемы обнаруживались не тогда, когда возникали, а когда начинали влиять на пользователей.
Типичная картина: пользователь жалуется, что VPN-нода стала тормозить или Matrix-федерация не идёт; администратор начинает разбираться с уже случившимся инцидентом, а не предотвращать его. Задача была перевернуть эту схему — узнавать о проблеме раньше, чем её заметит кто-либо ещё. Дополнительное требование: шифрование трафика между агентами и сервером — серверы стоят у разных провайдеров, метрики в открытом виде через интернет передавать нельзя.
Что построили: Zabbix 7 с хранилищем на TimescaleDB
Основа системы — Zabbix 7 с поддержкой нативного партиционирования через TimescaleDB. Это расширение PostgreSQL, которое хранит временные ряды метрик в гипертаблицах с автоматическим разбиением по времени. История метрик не превращается в монолитную таблицу на сотни гигабайт — данные живут в управляемых сегментах.
Мы создали 9 гипертаблиц: под тренды, историю значений, историю строк, триггерные события и вспомогательные данные. Каждая таблица настроена с собственным горизонтом хранения и политикой сжатия. Запросы к данным за последние 24 часа работают на порядок быстрее, чем в классической конфигурации PostgreSQL.
Все семь серверов подключены через Zabbix-агентов с 256-битным TLS-PSK шифрованием. Ключи уникальны для каждого хоста — компрометация одного агента не затрагивает остальные. Трафик метрик защищён на транспортном уровне без сторонних VPN-решений.
Три уровня серьёзности и логика задержек
Главная проблема большинства систем мониторинга — шум. Когда алерты приходят по 50 штук в час, их перестают читать. Мы выстроили три уровня серьёзности с разными интервалами ожидания перед срабатыванием.
- Информационный уровень — grace-период 10 минут. Кратковременные всплески метрик, которые сами приходят в норму, не генерируют уведомлений.
- Предупреждение — grace-период 5 минут. Аномалия устойчива, но пока не критична. Администратор получает сигнал и может оценить ситуацию в рабочем режиме.
- Критический уровень — grace-период 2 минуты. Сервис под угрозой. Оповещение уходит немедленно — действовать нужно прямо сейчас.
Такая градация заметно снижает количество ложных срабатываний по сравнению с конфигурацией «алерт на любое отклонение». Администраторы читают каждое уведомление — потому что знают: если пришло, значит важно.
Два независимых канала доставки алертов
Один канал уведомлений — точка отказа. Если мессенджер недоступен — алерт не дойдёт. Мы реализовали параллельную доставку через Telegram и Matrix.
Оба канала работают одновременно и независимо. Telegram — основной: быстрее доставляет, удобнее читать на мобильном. Matrix — резервный: федеративный протокол, работает через собственный сервер, не зависит от внешних сервисов. Алерт уходит в оба канала одновременно. Для каждого уровня серьёзности настроены отдельные шаблоны сообщений: критический алерт содержит имя хоста, описание проблемы, текущее значение метрики и время первого срабатывания.
Кому нужна такая схема
Распределённый мониторинг с шифрованием и двойными алертами оправдан, когда серверов больше трёх и они физически разделены. Один сервер с Zabbix без TLS и с одним каналом алертов достаточен для небольшого офиса. Но как только инфраструктура выходит за пределы одной площадки, риски растут непропорционально.
- Серверы у нескольких разных провайдеров или физически удалены друг от друга
- Удалённые объекты: офисы, склады, точки присутствия
- Требования к шифрованию трафика по внутренней политике безопасности
- Команды без выделенного дежурного — алерты должны доходить надёжно
- Инфраструктура с историей метрик более полугода — TimescaleDB даёт выигрыш с первого же месяца
Схема масштабируется горизонтально: добавить ещё десять серверов — это настройка агентов и новые PSK-ключи, архитектура не меняется.
Что изменилось после запуска
После запуска система начала ловить отклонения, на которые раньше никто не смотрел: предупреждения о приближающемся истечении TLS-сертификатов на доменах клиента, замедление в очереди Matrix-федерации, нетипичный рост числа активных Outline-ключей. Параллельная доставка алертов оправдала себя сразу: даже когда прямая отправка в Telegram была нестабильна, Matrix-канал стабильно доставлял уведомления через свой Synapse-хоумсервер.
Схема воспроизводима на любой инфраструктуре с Zabbix 7 и PostgreSQL. Семь серверов — это не предел: та же архитектура масштабируется на десятки и сотни узлов без принципиальных изменений.