Лёгкий агент передаёт метрики и сигналы безопасности по взаимному TLS. Servers Sentinel оценивает каждый хост, шлёт оповещения в привычные каналы и отмечает подбор паролей в момент начала атаки.
Первый сервер бесплатно. Без карты, установка одной строкой.
Для смешанных парков Windows и Linux
Пока дашборд обновится, инциденту уже час. Servers Sentinel закрывает этот разрыв.
Хост перестаёт отвечать, и никто не замечает, пока не заметит пользователь. Мониторинг не должен зависеть от того, кто смотрит на экран.
У каждого инструмента свой ящик. Сигналы рассыпаны по почте, чатам и вебхукам, пока их не перестают читать.
Подбор паролей по RDP и SSH идёт часами, прежде чем всплывёт при разборе логов. Он должен появляться за секунды.
Пороги, заданные по серверам, расходятся со временем. Один дефолт должен каскадироваться, а хост - переопределять только нужное.
Servers Sentinel собирает метрики локально, передаёт их по взаимному TLS и сводит в единую оценку здоровья и понятный алерт. Глобальные шаблоны каскадируются на все серверы; любой хост переопределяет ключ, не ломая дефолт.
Ничего не нужно компилировать и открывать входящие порты. Всё работает исходящим по TLS.
Зарегистрируйте хост в панели и получите команду установки одной строкой с коротким токеном подключения.
Скрипт определяет ОС и архитектуру, ставит агент как службу и подключает его по mTLS.
CPU, память, диск и сеть приходят по расписанию. Каждый хост получает живую оценку здоровья.
Правила бьют в почту, Telegram, Slack или вебхук. Брутфорс детектируется на агенте и отмечается мгновенно.
Основной цикл уже сегодня; безопасность, диски и базы спроектированы как подключаемые модули.
CPU, память, диск и сеть по каждому хосту - как временные ряды и спарклайны, читаемые с одного взгляда.
Глобальные шаблоны задают дефолты; сервер переопределяет только нужные ключи. Переопределения каскадируются, а не форкаются.
У каждого агента клиентский сертификат. Приём взаимно аутентифицирован, поэтому утёкший токен сам по себе ничего не открывает.
Агент локально следит за аутентификацией RDP и SSH и сообщает об активной атаке с топом IP-источников.
Каждый хост сводится к одной оценке 0-100, и парк из сотен сам сортируется по тому, что требует внимания.
Почта, Telegram, Slack и вебхуки. Добавьте канал, отправьте тест и направьте на него правила.
Пользователи, команды и роли (наблюдатель, оператор, админ) изолируют парк каждого клиента за одним входом.
Один протокол для юнита systemd на Linux и службы Windows, на amd64, arm64 и 386.
Старт бесплатно на одном сервере. Оплата по числу хостов, помесячно или за год.
Зарегистрируйтесь и наблюдайте за всем парком: история метрик, uptime- и API-проверки, уведомления в Telegram и отчёты. По окончании ничего не спишется - аккаунт вернётся на Free, мониторинг одного сервера продолжит работать.
Сервис Servers Sentinel предоставляется ООО «Файл Мастер» согласно тарифам по договору-оферте.
Пятнадцать ситуаций, в которых незнание того, что происходит с сервером, перестаёт быть приемлемым риском. Если вы узнаёте в одной из них своё хозяйство - пробел уже есть, просто он вам пока ничего не стоил.
Первая группа - про то, что остаётся незамеченным. Ни в одной из этих ситуаций нет халатности: так бывает, когда число машин перерастает то количество, которое человек способен держать в голове, - а это у большинства команд около четырёх.
Машина перестала отчитываться. Её мог перезагрузить гипервизор, она могла потерять маршрут, упереться в память или просто быть выключенной тем, кто наводил порядок в стойке. Об этом ничего не сообщает: отсутствующий сервер не порождает ошибок, а тишина - ровно то, что производит и здоровый.
Вся проблема в промежутке между отказом и звонком. Он обычно измеряется часами, обнаруживает его всегда самый неподходящий человек, и к этому моменту вопрос уже не в том, что сломалось, а в том, почему никто не знал.
Переполнение диска - самая предсказуемая авария из всех. Логи растут, копия записалась дважды, временная таблица не убралась, и кривая свободного места уже две недели указывает на один и тот же день.
Это же и авария, восстановление после которой обходится дороже всего: база, у которой кончилось место посреди записи, останавливается не вежливо. Разница между предупреждением на 80 % и вызовом на 100 % - это разница между двухминутной уборкой и восстановлением из вчерашней резервной копии.
Утечки памяти, исчерпание пула соединений, очередь, которая разбирается всё медленнее, сертификат, до истечения которого месяц, - ничто из этого не является событием. Это наклоны, а наклон невидим для того, кто смотрит только на текущее значение.
Без истории не с чем сравнивать. У вопроса «70 % памяти - это для этого хоста нормально?» нет ответа, если никто не записывал, что такое норма, - а записывать нужно было до того, как кому-то пришло в голову спросить.
Большинство реальных хозяйств смешанные: пара Windows-серверов под учётную систему и файловое хранилище, несколько Linux-машин под сайт и базу, возможно, что-нибудь на ARM в удалённой точке. У каждой платформы свои родные инструменты, и друг с другом они не разговаривают.
Поэтому картину собирают вручную, в голове того, кто сегодня на смене, из консоли служб, SSH-сессии и панели хостера. И собирают её только тогда, когда кто-то пошёл смотреть, то есть уже после того, как что-то пошло не так.
Сервер в офисе, два у хостера, три в одном облаке, один в другом из-за незаконченной миграции и коробка в филиале, поставленная ещё до прихода нынешней команды. У каждого своё адресное пространство, свой способ доступа и свой владелец.
Единой консоли, которая охватывала бы их все, нет, потому что покупали их не как одно целое. Нужно одно место, которое относится к ним как к одному хозяйству независимо от того, где физически стоит каждый.
Вторая группа - про расстояние между «это можно было обнаружить» и «кто-то на это среагировал». Большинство болезненных инцидентов всё это время были видны в логе; сбой произошёл на последних метрах, между машиной и живым человеком.
Одна система шлёт почту, другая пишет в чат, третья дёргает вебхук, хостер присылает SMS, а программа резервного копирования кладёт отчёт в папку, которую никто не открывал с момента настройки.
Ничто не связывается воедино. Один и тот же инцидент порождает четыре уведомления с четырьмя разными названиями в четырёх местах, а работа по осознанию того, что это один инцидент, достаётся тому, кто случайно смотрел в нужное окно.
Ненастроенный мониторинг оповещает непрерывно: всплеск процессора во время ночного задания, диск, пересекающий порог, который он пересекает каждую неделю, служба, перезапускающаяся так, как и было задумано. Люди очень быстро усваивают, что это можно пропускать, - и они правы ровно до того дня, когда нельзя.
Как только канал приучил своих читателей его пролистывать, добавление новых оповещений делает хуже, а не лучше. Полезная метрика - не сколько всего обнаружено, а сколько дошло до человека, который после этого что-то сделал.
Небольшие и средние команды не держат график дежурств. Человек, который знает системы, спит, летит в самолёте или в отпуске, а инцидента это не волнует. Значит, всё должно быть понятно тому, кто реально доступен, - включая того, кто ничего из этого не строил.
Отсюда жёсткое требование к тому, что должно быть написано в оповещении. «db-01 CPU 96 %» в три ночи ничего не говорит человеку, который никогда не заходил на db-01; разницу между починкой и обзвоном делают контекст - что происходило рядом и как выглядит норма.
Каждый сервер настраивали руками, в разное время, разные люди и с разным представлением о том, ради чего стоит будить человека. Через два года ни одна пара машин не совпадает, никто не помнит, почему у одной 85 %, а у другой 95 %, а поменять всё - значит обойти всё.
Хозяйству нужно другое: одно значение по умолчанию, которое распространяется всюду, и переопределения на уровне хоста, видимые именно как переопределения, - чтобы отклонение было осознанным решением, которое можно пересмотреть, а не случайностью истории.
Открытый порт RDP или SSH атакуют непрерывно, а удачно подобранный пароль выглядит в журнале почти в точности как обычный вход. Свидетельства есть - рост числа отказов, незнакомый источник, первый в истории успешный вход из новой страны, - но только в виде строк в файле, который никто не читает ежедневно.
Значит, обнаружение должна делать машина, а не человек раз в квартал. Значение имеет окно между первой попыткой и первым успехом, и оно обычно измеряется часами.
Третья группа - про момент, когда ответ нужен кому-то за пределами технической команды. Доступность, история инцидентов и подтверждение того, что за системами следили, либо существуют как запись, либо не существуют вовсе: задним числом их не восстановить по памяти.
Как только доступность вписана в соглашение, она перестаёт быть ощущением и становится числом, которое нужно предъявлять ежемесячно, защищать при споре и считать каждый раз одинаково. «Насколько мы знаем, всё работало» - это не измерение.
Запись защищает и в обратную сторону. Большинство споров о доступности - это споры о том, чья это была вина, и хронология, показывающая, что хост был здоров, пока лежал канал самого заказчика, заканчивает разговор быстрее любых аргументов.
Анкеты киберстрахования, проверки поставщиков и регуляторные требования к платёжным и персональным данным спрашивают вариации одного и того же: откуда вы знаете, что ваши системы работают как задумано, и как вы узнали бы, что это не так.
Нужно не название инструмента. Нужны свидетельства того, что наблюдение было непрерывным весь проверяемый период, что оповещения уходили туда, где их читал человек, и что инциденты фиксировались, а не запоминались.
Сервисные компании, приходящие системные администраторы и небольшие ИТ-фирмы ведут десятки машин у разных компаний, у разных провайдеров и в разных сетевых схемах. У каждого заказчика свой график работы, своя терпимость к простою и своё представление о том, что считать срочным.
Настраивать каждую вручную не масштабируется - как и узнавать о проблеме только по звонку клиента. Такому хозяйству нужен один базовый набор правил, применённый везде, исключения на уровне заказчика там, где он действительно отличается, и одна стена, где видно всё сразу.
Какая машина важна, как на ней выглядит нормальная нагрузка, какое оповещение можно спокойно игнорировать, почему тот порог подняли в марте - ничего из этого нигде не записано. Это носит в себе тот, кто всё настраивал, и это уходит вместе с ним.
Передача дел превращается в археологию, а первые месяцы в новых руках уходят на переоткрытие того, что годом раньше прекрасно знали. История и конфигурация, живущие вне человека, - единственная защита от этого.
Наблюдение не бесплатно с точки зрения риска. Всё, что снимает метрики с каждой вашей машины, по определению имеет опору на каждой вашей машине, - и при этом доступно снаружи, потому что в этом и смысл.
Поэтому вопрос о том, как следят за парком, - это ещё и вопрос об этом канале: кто может с ним говорить, какую личность доказывает каждая сторона, что происходит с данными в пути и не отдаст ли скомпрометированная консоль всё хозяйство целиком. Спросить об этом до установки чего бы то ни было совершенно уместно.
Да. Агент читает только локальные метрики и собственные логи аутентификации и соединяется исходящим по TLS. Он не открывает входящих портов и не имеет наступательных функций.
Да. Один протокол управляет юнитом systemd на Linux и службой Windows, на amd64, arm64 и 386. Установщик сам определяет платформу.
Каждый агент подключается с клиентским сертификатом и передаёт данные по взаимному TLS. Токен подключения короткоживущий и не позволяет выдать себя за уже подключённый хост.
Глобальные шаблоны задаются один раз. Сервер переопределяет отдельные ключи; переопределения каскадируются поверх дефолтов, а не заменяют их, поэтому изменение шаблона доходит до каждого хоста.
Да. Панель поставляется стеком docker-compose за Traefik с Postgres (TimescaleDB опционально). См. руководство по деплою в репозитории.
Агент локально следит за аутентификацией RDP и SSH, поэтому отмечает активный подбор паролей и топ IP-источников за секунды, ещё до обновления панели.
С Servers Sentinel я устанавливаю агент как systemd-unit или службу Windows, подключаю его исходящим каналом mTLS и вижу последнюю телеметрию и оценку здоровья хоста. Я задаю правило на отсутствие данных, направляю уведомление в почту, Telegram, Slack или webhook и проверяю тестовый разрыв; один сервер могу держать на бесплатном тарифе с email-оповещениями.
Бесплатно без Servers Sentinel я запускаю blackbox_exporter/Prometheus или cron-проверку ping/TCP с другой площадки, храню last_seen и отправляю алерт через Alertmanager. Я отдельно проверяю сам мониторинг внешним dead-man switch, задаю задержку под нормальную перезагрузку и документирую владельца хоста; иначе пропажа системы мониторинга выглядит как зелёное состояние.
С Servers Sentinel я собираю занятое и свободное место каждого filesystem как временной ряд, задаю общий порог и отдельное переопределение для конкретного тома, а уведомление отправляю до критического значения. Я смотрю скорость роста рядом с текущим процентом, проверяю inode на Linux и оставляю запас, достаточный для WAL/журнала и аварийной операции.
Бесплатно я ставлю node_exporter/windows_exporter с Prometheus и Alertmanager либо запускаю df/Get-Volume по cron/Task Scheduler. Я предупреждаю одновременно по проценту и абсолютным гигабайтам, добавляю rate/predict_linear для горизонта 24–72 часа, настраиваю logrotate/retention и тестирую алерт искусственным заполнением некритичного тома.
С Servers Sentinel я храню ряды CPU, памяти, диска и сети, сравниваю хост с его собственной историей и свожу текущее состояние в оценку 0–100. Я задаю длительность условия, чтобы не реагировать на минутный пик, и создаю отдельные uptime/TLS/API-проверки там, где важен срок сертификата или ответ приложения.
Бесплатно я разворачиваю Prometheus, exporters и Grafana, задаю recording rules для baseline и алерты по устойчивому росту, а сертификаты проверяю blackbox_exporter. Я храню минимум несколько недель данных, отмечаю deploy/maintenance на графиках и использую rate/deriv только для подходящих метрик; поддержку TSDB и правил выполняю сам.
С Servers Sentinel я использую один протокол для службы Windows и systemd-агента на amd64, arm64 и 386, получаю одинаковые базовые метрики и одну оценку здоровья. Я сохраняю платформенные различия в переопределениях, но сортирую весь парк по риску и передаю телеметрию исходящим mTLS без открытия входящего порта агента.
Бесплатно я объединяю windows_exporter и node_exporter в одном Prometheus, нормализую labels host/client/os и строю общий Grafana dashboard. Я сопоставляю Windows Event Forwarding и syslog/Loki по UTC, описываю разные пороги для ОС как code и проверяю, что обновление exporter не меняет названия метрик без миграции правил.
С Servers Sentinel я устанавливаю агент на каждом хосте; он сам инициирует исходящее соединение и аутентифицируется клиентским сертификатом mTLS. Я присваиваю метки площадки и владельца, вижу все хосты в одной консоли и задаю правила глобально с точечными переопределениями, не строя входящий маршрут до каждой машины.
Бесплатно я соединяю площадки WireGuard и опрашиваю exporters центральным Prometheus либо использую remote_write/агенты, которые отправляют метрики наружу. Я ограничиваю ACL только адресом коллектора, защищаю TLS-сертификатами, буферизую данные при разрыве и мониторю сам VPN; проектирование сети и ротацию ключей выполняю самостоятельно.
С Servers Sentinel я создаю каналы email, Telegram, Slack или webhook в одной консоли, отправляю тест и направляю на них правила по нужным хостам. Я использую единые названия и контекст хоста, чтобы оператор видел метрику, порог и время, а не собирал инцидент из четырёх независимых писем.
Бесплатно я направляю Prometheus Alertmanager в один шлюз уведомлений, задаю group_by, group_wait, repeat_interval и inhibition, а источникам оставляю ссылку на один runbook. Я нормализую labels severity/service/owner и проверяю маршруты тестовыми алертами; SMS и внешние провайдеры могут оставаться платными даже при бесплатном ПО.
С Servers Sentinel я задаю глобальные пороги, длительность условия и точечные исключения для хостов, где норма отличается, а затем направляю уровни серьёзности в разные каналы. Я использую оценку здоровья для приоритета, тестирую правило и пересматриваю алерты, по которым никто не выполнил действие.
Бесплатно я веду каталог алертов с владельцем и runbook, применяю for в Prometheus, группировку и inhibition в Alertmanager, а плановые работы закрываю silence с автоматическим окончанием. Я измеряю число уведомлений, подтверждений и повторов, удаляю неactionable-сигналы и не маскирую шум простым повышением всех порогов.
С Servers Sentinel я разделяю severity и каналы, добавляю к имени хоста роль/клиента и настраиваю правило только после устойчивого нарушения. Я проверяю сообщение тестом, оставляю ссылку на runbook в webhook-получателе и использую график метрики/оценку здоровья, чтобы дежурный отличил разовый пик от деградации.
Бесплатно я строю расписание маршрутизации Alertmanager, критические события отправляю в звонок/чат через доступный шлюз, остальные - в дневную очередь. Я пишу runbook из трёх действий, владельца и критерия эскалации, добавляю dashboard link и регулярно провожу учебный алерт; бесплатность канала звонков зависит от выбранного сервиса.
С Servers Sentinel я задаю глобальный шаблон конфигурации, а на конкретном сервере переопределяю только нужный ключ; переопределение каскадируется поверх дефолта, а не копирует весь конфиг. Я вижу отклонение как исключение, меняю общий порог один раз и проверяю, какие хосты сознательно остались на другом значении.
Бесплатно я храню Prometheus rules и inventory-параметры в Git, генерирую правила Jsonnet/Ansible и требую review с причиной и сроком исключения. Я запускаю CI-проверку синтаксиса, diff развёрнутой конфигурации и отчёт по overrides; без такой дисциплины даже бесплатный стек быстро возвращается к ручному дрейфу.
С Servers Sentinel я включаю локальный детект аутентификации: агент на Windows или Linux считает события RDP/SSH и передаёт активную атаку с топом IP-источников. Я направляю правило в оперативный канал и сопоставляю один источник между хостами; функция детекта доступна на соответствующем платном или пробном плане.
Бесплатно я собираю Windows 4625 и sshd Failed password в Wazuh/Elastic или Loki, создаю корреляцию по source_ip за скользящее окно и алерт на последующий успешный 4624/Accepted. Я синхронизирую время через NTP, нормализую IPv4/IPv6 и исключаю тестовые сканеры; бесплатный путь требует отдельного коллектора и поддержки правил.
С Servers Sentinel я создаю TCP/TLS/API-проверки с внешней точки, храню историю результатов и отделяю недоступность приложения от пропажи агентской телеметрии. Я задаю SLO, фиксирую maintenance и формирую периодический отчёт с временными границами; перед подписанием согласую с заказчиком интервал, регионы проверки и правила исключений.
Бесплатно я разворачиваю blackbox_exporter и Prometheus вне контролируемой площадки, считаю availability как successful probes/expected probes и храню Alertmanager events. Я отмечаю maintenance в отдельном журнале, синхронизирую UTC и генерирую отчёт Grafana; одна точка проверки не доказывает глобальную доступность, поэтому при необходимости добавляю независимый probe.
С Servers Sentinel я сохраняю историю метрик, uptime-проверок, настроек правил, каналов и событий, а журнал аудита использую для изменений владельцев и политики на подходящем плане. Я выгружаю отчёт за точный период, прикладываю тест доставки и объясняю mTLS-идентичность агентов; отсутствие данных отмечаю как разрыв наблюдения, а не как норму.
Бесплатно я храню Prometheus/Loki/Wazuh на защищённом сервере с backup, конфигурацию и approvals - в Git, а инциденты - в ticket-системе. Я ежемесячно фиксирую coverage, gaps, тест алерта и список исключений, подписываю отчёт и ограничиваю доступ; сам инструмент без процедуры закрытия не является доказательством контроля.
С Servers Sentinel я разделяю парк по командам/арендаторам, назначаю роли viewer, operator и admin и применяю базовые шаблоны с исключениями клиента. Я сортирую все хосты по оценке здоровья, направляю уведомления владельцу и использую Business/self-hosted вариант там, где нужны изоляция и неограниченный парк.
Бесплатно я разворачиваю отдельные Prometheus tenancy/инстансы или изолирую данные строгими labels и ACL в Grafana, секреты клиентов храню в разных vault. Я генерирую конфигурацию из inventory, маршрутизирую Alertmanager по tenant/owner и тестирую запрет перекрёстного доступа; безопасная мультиарендность требует больше работы, чем один общий dashboard.
С Servers Sentinel я подписываю хосты по роли и владельцу, сохраняю ряды метрик, глобальные шаблоны и явные переопределения, а каналы связываю с ответственными. Я использую историю как baseline, документирую причину нестандартного порога рядом с change process и выдаю новому оператору роль только для просмотра до передачи полномочий.
Бесплатно я веду inventory и runbooks в Git, добавляю dashboard links, owner, dependencies и rationale каждого override, а изменения принимаю через pull request. Я храню Grafana/Prometheus provisioning как код, отмечаю deploy/maintenance и раз в квартал провожу передачу инцидента другому сотруднику; без организационной практики графики сами знания не сохранят.
С Servers Sentinel я использую исходящее соединение по взаимному TLS: каждый агент получает клиентский сертификат, а короткоживущий токен подключения не заменяет уже выданную идентичность. Я проверяю права службы, список собираемых метрик и логов, отключаю ненужные действия, разворачиваю пилот на одном хосте и контролирую отзыв сертификата при удалении сервера.
Бесплатно я ставлю node_exporter/windows_exporter под отдельной непривилегированной учётной записью, слушаю только localhost/VPN и ограничиваю collector-набор. Я защищаю scrape TLS/mTLS или сетевыми ACL, подписываю пакеты, фиксирую версии, сканирую обновления и не включаю textfile scripts с записью из недоверенных источников; управление конфигурацией отделяю от мониторинга.
Три вопроса, на которые стоит получить ответ до того, как ставить на боевые серверы что-либо с правами администратора.
Servers Sentinel пишет Виктор Г. Бобров, ведущий специалист по безопасности серверов в Recovery Toolbox: 20+ лет в системной разработке и безопасности, сертификаты Microsoft MCSD/MCDBA. Расчёт health score, правила оповещений и документация на этом сайте - его работа, опубликованная под его именем, а не под безымянным брендом. Документация →
Поставщик - File Master LLC, компания, зарегистрированная в Болгарии (ЕС): Bulstat/VAT 180842207, офис в Варне, доступна по телефону и почте. Платежи проводит PayPro Global как merchant of record; оферта, политика конфиденциальности и соглашение об обработке данных опубликованы полностью, а не в пересказе. Условия использования · Приватность · DPA
Агент читает локальные метрики и журнал аутентификации своего же хоста и отдаёт их наружу по взаимному TLS. Он не открывает входящих портов и не имеет канала удалённых команд: снаружи ему нельзя приказать что-либо выполнить на вашем сервере. Каждый агент проходит энролмент с клиентским сертификатом, а токен энролмента короткоживущий - украденный не позволит выдать себя за уже подключённый хост. Саму панель можно поднять на своём железе: она поставляется как docker-compose-стек. Установка агента →
Мониторинг парка серверов - не самостоятельная тема: он лежит между платформами, за которыми следит, инструментами, которые были до него, и стандартами, по которым сервер оценивают. Ниже - источники, которые определяют каждое из этих понятий.
Ссылки ведут на сами источники: Wikidata там, где у сущности есть идентификатор, и первоисточник там, где его нет.
Контакты Recovery Toolbox и File Master LLC, а также профиль Виктора Г. Боброва, ведущего специалиста компании по безопасности.
File Master LLC - юридическое лицо, которое стоит за онлайн-сервисами и программными продуктами Recovery Toolbox.
File Master LLC разрабатывает и поддерживает онлайн-сервисы и программные продукты Recovery Toolbox для восстановления повреждённых файлов, баз данных и почтовых форматов. Компания создаёт практичные инструменты восстановления для пользователей, ИТ-специалистов и бизнеса, которым нужно вернуть доступ к повреждённым данным.
Мы будем рады вашим замечаниям и предложениям. Пожалуйста, присылайте отзывы о сайте по электронной почте: webmaster@recoverytoolbox.com
Специалист по безопасности серверов · 20+ лет в системной разработке и безопасности
Виктор Г. Бобров отвечает за безопасность в File Master LLC / Recovery Toolbox. Он определяет, за чем Servers Sentinel следит в парке серверов: health score по метрикам хоста, брутфорс в журналах аутентификации, отклонение конфигурации от требований CIS и оповещения, которые должны сработать раньше, чем администратор заметит проблему.
Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.
Добавьте хост, запустите одну строку и увидите метрики за минуту. Первый сервер бесплатно.
