Uptime Kuma или Zabbix: какой мониторинг нужен небольшой компании

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

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

• Последствие отказа. Запишите, какая работа останавливается: продажа, доступ к документам или получение заявок. Укажите рабочее время и допустимый срок реакции.

• Признак работы. Определите, что проверка действительно видит: страницу входа, ответ приложения, доступность файла или состояние сервера.

• Ответственные. Владелец сервиса знает последствия для бизнеса, администратор устраняет причину. Укажите контакты обоих рядом с проверкой, даже если это разные люди.

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

Uptime Kuma проверяет HTTP, TCP, DNS и другие признаки доступности. HTTP позволяет проверить ответ сайта; TCP — установить соединение с портом; DNS — получить адрес по имени. Для HTTP можно проверять содержимое ответа, а не только успешный код.

Такой набор удобен для небольшого числа сервисов с одним администратором. Но доступный порт не подтверждает выполнение задачи: приложение может принять соединение и показать ошибку. Выбирайте проверку, которая соответствует нужному действию, и называйте её точно.

В Zabbix задают, что измерять, когда считать ситуацию проблемой и что делать дальше — например, отправить сообщение. Агент, протокол SNMP и готовые шаблоны помогают получать данные о дисках, процессах и сетевом оборудовании.

Zabbix полезен для поиска внутренних причин и наблюдения за ростом нагрузки. Uptime Kuma распространяется по лицензии MIT, Zabbix 7.0 — по AGPLv3. Конкретные показатели и пороги всё равно нужно подбирать для своей версии, оборудования и задач.

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

• Точное название. Если проверяется только страница входа, назовите монитор именно так. Не обещайте проверку всей CRM по одному ответу этой страницы.

• Ограниченный доступ. Для проверки входа используйте согласованный технический способ или отдельную ограниченную учётную запись. Не передавайте пароль администратора ради искусственной проверки.

• Независимое наблюдение. Разместите хотя бы одну проверку вне основного сервера. Если приложение и его монитор остановятся вместе, внутренний монитор не сможет отправить сообщение.

Внешняя проверка заметит недоступность, но может не объяснить причину. Для диска, памяти и процессов добавляйте Zabbix по конкретной потребности. Назначьте владельца показателя, укажите задержку, число подтверждений, сигнал восстановления и время планового обслуживания.

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

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

• Подтвердить проблему. Проверьте наблюдаемый симптом и связанные сервисы. Если несколько проверок зависят от одного хоста, свяжите их с одной основной проблемой.

• Сохранить признаки. Пока доступны журналы и показатели ресурсов, сохраните нужные сведения. Перезапуск может помочь временно, но сам по себе не объясняет причину.

• Сообщить о восстановлении. Проверьте рабочее действие пользователя после исправления и обновите статус. У сообщения должны быть имя сервиса, симптом и ссылка на порядок действий.

Порог свободного места выбирайте по объёму, скорости роста и времени на очистку или расширение. Сообщение «диск занят на 85%» не даёт этого контекста. Один и тот же процент может требовать разных действий на разных серверах.

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

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

Регулярно пересматривайте адреса после переносов, сертификаты и время обслуживания. Иначе снятый сервис продолжит создавать шум, а новый останется без наблюдения. После двух недель работы разберите ложные сигналы и пропуски до добавления новых проверок.

Расширяйте Zabbix, когда причины повторяющихся отказов приходится искать вручную, растёт парк оборудования или нужно планировать ресурсы. Сформулируйте один вопрос, на который текущие проверки не отвечают. Добавьте показатели, которые помогут ответить на него и изменить действия администратора.

Можно оставить Kuma для внешней доступности и использовать Zabbix для внутренних причин, если команда готова поддерживать оба набора. Выбор двух систем должен решать рабочую задачу. Для пяти адресов без потребности во внутренних показателях достаточно начать с понятных проверок доступности.