Нам хотелось этих аккуратных графиков в стиле Checkmate на нашей публичной странице статуса. Чтобы время отклика и ресурсы сервера были прямо рядом с привычными полосами аптайма. И мы совершенно точно не хотели поднимать целое второе приложение мониторинга только ради того, чтобы нарисовать пару линий на экране.
Данные уже были
Самое смешное, что мы поняли: все нужные данные у нас уже есть. Наш Discord-бот и так опрашивает каждый сервис с интервалом в 5 минут. Проба измеряла время отклика на каждом запросе, но потом просто выбрасывала это число и возвращала лишь скромное "online" или "offline". То есть мы буквально вычисляли данные для графика и тут же их удаляли, смешно.
Поэтому правка получилась предельно лёгкой:
- Сохранять задержку, которую проба и так измеряла, вместо того чтобы её выбрасывать.
- Брать CPU / RAM / диск хоста прямо из
/proc(только стандартной библиотекой Linux). - Сохранять обе метрики рядом с существующими записями истории аптайма.
- Рисовать инлайновые SVG-спарклайны прямо на карточках статуса.
Почему не взять Uptime Kuma?
Поймите правильно, инструменты вроде Checkmate или Uptime Kuma отличные, но это полностью отдельные приложения. У них своя база данных, своя авторизация и свой интерфейс. А поскольку мы живём на общем хосте, это просто ещё одна вещь, которую пришлось бы поддерживать и защищать, и вдобавок она не вписалась бы в наш самодельный фронтенд. У нас уже было написано 90 % логики, так зачем добавлять лишний хлам?
Наше новое правило: сначала используй данные, которые у тебя уже есть, и только потом ставь целый новый сервис, чтобы их собирать.
Стек
| Метрика | Источник |
|---|---|
| Время отклика | существующая проба бота (elapsed) |
| CPU / RAM | /proc/stat, /proc/meminfo |
| Диск | shutil.disk_usage |
В итоге ноль новых зависимостей у бота, никаких тяжёлых библиотек для графиков на сайте и никаких новых фоновых сервисов. Просто честное использование чисел, которые мы и так уже собирали.