Каждые пару месяцев кто-то из знакомых админов спрашивает: с чего начать мониторинг, если бюджет на коммерческие SIEM и APM-платформы закончился ещё на этапе пилота? Ответ у меня последние годы не меняется: большинство задач закрывают open-source решения, и вопрос только в том, сколько времени вы готовы тратить на их обслуживание. Ниже — семь инструментов, которые я поднимал и на домашнем сервере, и в продовой инфраструктуре среднего бизнеса. Без рейтинга по звёздочкам: это скорее разбор того, что каждый из них реально умеет и в какой момент начинает болеть.
По каким критериям отбирал
- Открытый код и живая разработка: релизы и правки безопасности выходят регулярно, а не раз в пять лет.
- Вменяемая лицензия: продукт можно использовать в коммерческой инфраструктуре без юриста на подхвате.
- Сообщество и готовые шаблоны, правила, дашборды — чтобы не писать всё с нуля.
- Реальный порог входа: инструмент можно поднять на одной VPS, не посвящая этому полжизни.
И сразу договоримся: мониторинг без настроенного алертинга бесполезен. Если уведомления летят в почту, которую никто не читает, вы платите за красивые графики. Поэтому в каждом пункте смотрите не только на функциональность, но и на то, как инструмент сообщает о проблеме.
1. Zabbix — швейцарский нож инфраструктурного мониторинга
Классика, с которой начинают почти все. Агенты для Windows и Linux, SNMP, IPMI, JMX, огромная библиотека шаблонов под железо, СУБД и сетевое оборудование. Есть автообнаружение хостов, триггеры с эскалациями, прокси для распределённых площадок и аутентификация через LDAP или Active Directory.
- Плюсы: покрывает почти всё — от температуры процессора до доступности БД; на 4 vCPU и 8 ГБ RAM спокойно обслуживает пару сотен хостов; документации и русскоязычных гайдов море.
- Минусы: интерфейс из нулевых на любителя; при росте нагрузки приходится думать о партиционировании и шардировании БД; XML-шаблоны местами неочевидны, а из коробки алертов слишком много — их надо чистить руками.
2. Prometheus + Grafana — метрики для контейнеров
Де-факто стандарт в мире Kubernetes и микросервисов. Модель pull: сервер сам опрашивает цели, собирая метрики с экспортеров. Поверх — PromQL, Alertmanager и Grafana, которая превращает числа в понятные дашборды. Есть готовые экспортеры буквально на всё: node_exporter, postgres_exporter, blackbox_exporter для проверок доступности извне.
- Плюсы: лучшая в классе работа с облачной и контейнерной динамикой, service discovery, огромная экосистема.
- Минусы: это не система для логов и не замена Zabbix по глубине инвентаризации. Долгое хранение требует внешнего хранилища вроде Thanos или VictoriaMetrics. И осторожнее с лейблами: если начать пихать в них user_id или request_id, кардинальность убьёт хранилище за неделю.
3. Wazuh — бесплатный SIEM с эндпоинт-агентами
Форк OSSEC, который давно живёт своей жизнью. Агент ставится на Windows, Linux и macOS, а серверная часть на OpenSearch даёт полноценный SIEM: контроль целостности файлов, проверка конфигураций по CIS-бенчмаркам, обнаружение вторжений, маппинг событий на MITRE ATT&CK, корреляция и оповещения.
- Плюсы: функциональность, за которую в коммерции просят деньги за каждую ноду; готовые детект-правила сообщества; нормально дружит с Suricata и Sysmon, принимая их логи.
- Минусы: стек из indexer, server и dashboard прожорлив — на старте я бы закладывал 8–16 ГБ RAM и быстрый диск. Ложных срабатываний много, без тюнинга правило-фильтров вы утонете. Мажорные обновления иногда ломают кастомные правила.
4. Suricata — анализ сетевого трафика
IDS/IPS с многопоточной архитектурой и парсингом протоколов (HTTP, DNS, TLS). Работает на правилах Emerging Threats или на ваших собственных, умеет писать события в формат EVE JSON, который удобно уходит в Wazuh, Graylog или Elastic. В режиме IPS включается через NFQUEUE или AF_PACKET.
- Плюсы: видит то, что не видит хост: сканирования, обращения к известным C2, аномальные DNS-запросы. Легко поднимается на отдельном сетевом сегменте.
- Минусы: правила нужно тюнить под свою сеть, иначе поток алертов деморализует. Трафик внутри TLS 1.3 разбирается только по метаданным. IPS-режим — отдельная зона риска: ошибка в конфиге легко отрезает прод, включайте сначала в режиме обнаружения.
5. Graylog — централизованные логи
Когда хостов больше десяти, логи разъезжаются по машинам и искать в них что-то становится больно. Graylog собирает события по Syslog, GELF и через Sidecar с Windows-станций, прогоняет их через pipelines и extractors, хранит в OpenSearch и даёт нормальный поиск с дашбордами.
- Плюсы: быстрый поиск по логам, гибкие правила нормализации, статусная страница и роли под разные команды. Community-версия закрывает большинство задач.
- Минусы: под капотом три сервиса — MongoDB, OpenSearch и собственно сервер. Ресурсы, порядок обновления и ротация индексов требуют внимания: неправильно настроенная retention-политика однажды съедает диск и кладёт индекс.
6. Greenbone Community Edition (бывший OpenVAS) — сканер уязвимостей
Бесплатная альтернатива коммерческим сканерам: сетевые и аутентифицированные проверки по SSH и SMB, отчёты с оценками CVSS, расписания. Именно аутентифицированные сканы дают реальную картину — какие пакеты и версии стоят на хосте, а не только какие порты открыты.
- Плюсы: понятная цена (ноль) при приличной глубине проверок, регулярно обновляемые feed’ы уязвимостей, экспорт отчётов для аудита.
- Минусы: развёртывание через набор контейнеров до сих пор нетривиально, первичная синхронизация баз занимает часы. Полное сканирование подсети может идти сутки и создавать нагрузку. Ложноположительные результаты встречаются, и их надо проверять руками, а не копировать в отчёт.
7. Uptime Kuma — простой контроль доступности
Инструмент, который я ставлю первым на любом новом контуре. Проверки HTTP(s), TCP, ping, DNS и по ключевому слову на странице, уведомления в Telegram, почту или Matrix, публичная статус-страница для заказчика.
- Плюсы: поднимается в Docker за пять минут, агенты не нужны, интерфейс понятен без чтения документации.
- Минусы: это не мониторинг ресурсов и не замена Zabbix. История метрик примитивная, отказоустойчивость и кластеризация ограничены — для одного инстанса на одном сервере, и не более.
Как собрать из этого рабочий стек
Не пытайтесь внедрить всё семь сразу — это самый быстрый путь к заброшенному проекту. Разумная последовательность такая: сначала Zabbix или Uptime Kuma для доступности и ресурсов, затем Graylog, когда логи перестают помещаться в голове, потом Suricata на периметре и Wazuh на хостах, а сканер уязвимостей — по расписанию, раз в месяц. Prometheus добавляйте, если у вас появились контейнеры и Kubernetes.
И держите в голове главное: ни один open-source инструмент не «защитит сам». Мониторинг — это способ узнать о проблеме раньше, чем о ней узнает заказчик или вымогатель.
Чек-лист перед внедрением
- Определите, что именно хотите видеть: доступность, ресурсы, логи, сетевой трафик или уязвимости. Это разные инструменты, и один их них не заменит.
- Посчитайте ресурсы: SIEM-стек и хранилище метрик требуют RAM и быстрых дисков, а не минимальной VPS.
- Настройте уведомления в канал, где их реально читают, и заранее договоритесь, кто реагирует ночью.
- Прогоните инструмент в режиме наблюдения минимум две недели и почистите ложные срабатывания до того, как включать блокировки.
- Заведите регламент обновлений: open-source означает и вашу ответственность за патчи, а не только бесплатность.
- Проверьте восстановление: резервная копия конфигов и баз мониторинга должна существовать до первого инцидента, а не после.
