Для двух-трёх сервисов не обязательно начинать с огромной системы мониторинга. Для начала достаточно понять, работает ли сервис для пользователя, есть ли ошибки и хватает ли ресурсов.
Доступность снаружи
Проверка systemctl is-active сообщает только о состоянии процесса. HTTP-приложение может быть запущено, но возвращать ошибку. Поэтому проверяйте пользовательский URL по HTTPS и сохраняйте время ответа, статус и результат проверки сертификата.
Журналы ошибок
В systemd удобно читать последние строки:
journalctl -u your-service --since -1h --no-pager
Для контейнера:
docker logs --since 1h --tail 200 your-container
Не храните пароли, токены доступа и персональные данные в журналах. Настройте ограничение объёма логов, чтобы один шумный процесс не заполнил системный диск.
Ресурсы и тенденции
df -h
free -h
uptime
Эти команды дают быструю картину диска, памяти и нагрузки. Для длительного наблюдения используйте метрики с историей, чтобы замечать тренды, а не только пики.
Оповещения должны вести к действию
Хорошее уведомление отвечает на вопросы: какой сервис недоступен, когда началась проблема и где посмотреть детали. Аварийные сигналы лучше отправлять через независимый канал, который продолжит работать при падении проверяемого сервера.
Метрики полезны не количеством графиков, а тем, насколько быстрее они помогают понять и устранить проблему.