Основы мониторинга в DevOps: как настроить Prometheus и внедрить observability

Автор планомерно объясняет, почему health check, возвращающий 200 OK, — это не observability, а самоуспокоение, и зачем нужны метрики, которые показывают динамику, а не только «зелёный/красный». Для тех, кто до сих пор узнаёт о проблемах из тикета пользователя, материал — как холодный душ перед дежурством.

Что там по существу

Текст последовательно разбирает три вещи, которые начинающий девопс обычно путает в первые полгода работы.

Зачем мониторинг, если всё и так работает. Показательный сценарий: логи на сервере растут, место тает, в какой-то момент приложение пытается записать файл и получает No space left on device. Без алертов первый сигнал — гневное сообщение в чате от клиента. С мониторингом — уведомление за часы до инцидента. Банальщина, но именно на ней горят проды у тех, кто «ещё не успел настроить».

Метрика без контекста — цифра в вакууме. 70% RAM сегодня мало что значит. Если вчера было 40%, утром 50%, к вечеру 70% — это уже тренд, а не фон. А 100% CPU на сервере видеообработки — штатный режим. Из этого автор аккуратно выводит простую мысль: смотреть надо не значение, а дельту и соответствие ожидаемому поведению.

Health check vs monitoring vs observability. Health endpoint отвечает на вопрос «живо ли приложение прямо сейчас» и молчит, когда оно живое, но отвечает по 1000 мс. Мониторинг ловит эту деградацию по метрикам. Observability — более широкое понятие: когда вы можете по телеметрии ответить на произвольный вопрос о поведении системы, а не только на заранее зашитые алерты. На проде нужны все три слоя, поодиночке они бесполезны.

Что с этим делать на практике

Если у вас уже стоит Prometheus и Grafana — пройдитесь по списку и честно отметьте, что из этого реально работает, а не «настроено полгода назад и забыто»:

• Есть ли алерт на заполнение диска хотя бы за 6 часов до инцидента? Не «когда кончится», а с запасом.
• Мониторите ли вы свободную память и swap? Утечки обычно видны по графику до того, как OOM-killer начнёт убивать процессы.
• Есть ли дашборд с latency p95/p99, а не только среднее? Среднее время ответа прячет хвост из тяжёлых запросов.
• Разделены ли алерты по severity или у вас единый канал, где «диск заполнен на 85%» приходит с тем же приоритетом, что и пинг из соседнего региона?

Команды для быстрой проверки, что node_exporter вообще что-то отдаёт:

# запустить node_exporter локально
docker run -d -p 9100:9100 \
--name node-exporter \
-v "/proc:/host/proc:ro" \
-v "/sys:/host/sys:ro" \
-v "/:/rootfs:ro" \
prom/node-exporter:v1.8.2 \
--path.procfs=/host/proc \
--path.sysfs=/host/sys \
--collector.filesystem.mount-points-exclude='^/(sys|proc|dev|host|etc)($$|/)'
# проверить, что метрики идут
curl -s localhost:9100/metrics | grep node_cpu_seconds_total | head
# добавить таргет в prometheus.yml
# - job_name: 'node'
# static_configs:
# - targets: ['localhost:9100']

И главное: мониторинг — это не про «поставить Prometheus». Это про алерты, которые будят дежурного в три ночи по делу, а не потому что у вас up == 0 на staging, который вы забыли выключить. Настраивайте тишину по дефолту, шум — по исключению. Иначе через месяц алерты начнут читать как спам, и в момент афарата сигнал потонет в потоке «опять staging моргнул».