Мониторинг uptime и серверов на open-source: от одного VPS до небольшого парка

Чтобы мониторить uptime и состояние серверов, достаточно развернуть один self-hosted инструмент для проверки доступности, один для метрик хоста и, при необходимости, систему алертов. Ниже описан порядок действий: от одного VPS до небольшого парка серверов. Все инструменты перечислены в каталоге Stackora, их лицензии и публикаторы указаны в карточках.

Шаг 1. Определите, что именно вы мониторите

Разделите задачу на три слоя:

Доступность снаружи: отвечает ли сайт или API, валиден ли SSL-сертификат.
Состояние хоста: CPU, память, диск, сеть, контейнеры.
Реакция на инциденты: кто получает уведомление и где публикуется статус.

Для каждого слоя выберите отдельный инструмент. Один универсальный сервис обычно закрывает только часть задач.

Шаг 2. Настройте проверку доступности

Для внешней проверки подойдет Uptime Kuma, self-hosted инструмент с лицензией MIT и большим числом звезд на GitHub. Разверните его на отдельной машине, чтобы мониторинг не падал вместе с сервисом, который он проверяет.

Если нужны еще и мониторинг SSL и публичная страница статуса, посмотрите Kuvasz, который описывает uptime и SSL-мониторинг, уведомления, status pages, настройку через YAML и REST API. Его лицензия AGPL-3.0.

Что добавить в первую очередь

HTTP-проверку главной страницы и ключевого эндпоинта API.
Проверку срока действия SSL-сертификата.
Один канал уведомлений, который вы реально читаете.

Шаг 3. Добавьте метрики хоста

На каждом сервере поставьте Beszel: легковесный self-hosted инструмент с историческими метриками, статистикой Docker-контейнеров и настраиваемыми алертами, лицензия MIT. Он подходит для одного VPS и остается простым при росте числа машин.

Для разового разбора ситуации на сервере удобен Glances: CLI-инструмент с веб-интерфейсом и REST API, показывающий CPU, память, диск, сеть и контейнеры. Его описание в каталоге называет его альтернативой top и htop.

Шаг 4. Выберите способ статуса для пользователей

Если клиентам нужна страница статуса и история инцидентов, рассмотрите OpenStatus: open-source статус-страница, управление инцидентами и uptime-мониторинг, лицензия AGPL-3.0. Он закрывает задачу коммуникации, а не замеров сервера.

Шаг 5. Масштабируйтесь на небольшой парк

Когда серверов становится несколько, проверки и метрики нужно собирать централизованно. Здесь помогает Nightingale: self-hosted алертинг для метрик, логов и баз данных, с лицензией Apache-2.0. В описании указаны встроенный AI-агент и MCP-сервер.

Для диагностики узких мест в коде, когда метрики хоста уже показали проблему, используйте Pyroscope: платформа непрерывного профилирования с лицензией AGPL-3.0, которая помогает найти проблему вплоть до строки кода.

Порядок расширения

Один VPS: Uptime Kuma плюс Beszel.
Несколько серверов: добавляется центральный алертинг, например Nightingale.
Публичные сервисы: добавляется статус-страница, например OpenStatus или status pages Kuvasz.
Проблемы производительности приложения: добавляется профилирование.

Шаг 6. Проверьте алерты

После настройки вызовите искусственный сбой: остановите тестовый контейнер или закройте порт. Убедитесь, что уведомление пришло в нужный канал и что после восстановления приходит сигнал о возврате в норму. Без этой проверки мониторинг часто оказывается тихим там, где он нужнее всего.

Шаг 7. Дополнительные инструменты

Если нужна общая картина происшествий, посмотрите worldmonitor: дашборд ситуационной осведомленности с агрегацией новостей и отслеживанием инфраструктуры, лицензия AGPL-3.0. Это инструмент другого класса, поэтому для мониторинга собственных серверов он обычно не заменяет перечисленные выше.

Категории для поиска альтернатив: Observability, Web Apps, Developer Tools. Инструменты для агентов с доступом к метрикам собраны в разделе MCP servers.