Мониторинг без драмы: Prometheus и Grafana для одного разработчика

Когда я в одиночку поддерживаю пет-проект или небольшой внутренний сервис, соблазн пропустить мониторинг велик — кажется, что можно просто посмотреть логи, если что-то сломается. На практике так и происходит: что-то ломается, а узнаёшь об этом от пользователя, а не от системы. После пары таких случаев я всегда настраиваю минимальный мониторинг ещё до того, как сервис уходит в прод.

Минимальный набор, который реально нужен

Мне не нужен полноценный observability-стек с распределённой трассировкой для проекта на одного человека. Нужны три вещи: метрики (Prometheus), визуализация (Grafana) и алерты в удобный канал — у меня это Telegram-бот.

Экспортёр метрик поднимается вместе с приложением почти без усилий — в большинстве современных фреймворков это одна строка middleware. Дальше Prometheus раз в пятнадцать секунд опрашивает /metrics и складывает историю.

Какие метрики действительно важны

Я обычно начинаю с четырёх «золотых сигналов»: задержка ответа, трафик, количество ошибок и насыщение ресурсов (CPU, память, диск). Это покрывает подавляющее большинство реальных проблем без необходимости придумывать что-то экзотическое с первого дня.

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

Алерты, на которые действительно стоит просыпаться

Главная ошибка, которую я допускал раньше — заводил алерт на всё подряд, включая события, которые ни на что не влияют. Результат предсказуем: уведомления в Telegram превращаются в шум, который начинаешь игнорировать, а вместе с шумом пропускаешь и действительно важный сигнал.

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

Стоит ли овчинка выделки для маленького проекта

Настройка минимального стека занимает вечер. За три года эксплуатации нескольких небольших сервисов этот вечер окупился десятки раз — каждый раз, когда алерт приходил до того, как проблему заметили пользователи, а не после. Для меня это достаточный аргумент настраивать мониторинг всегда, даже для проекта, которым пользуются пять человек.