Как я поднял мониторинг инфраструктуры за 3 часа

История довольно банальная.

Небольшая команда, несколько сервисов, часть в Docker, часть просто на VM. Прод падает редко, но каждый раз — внезапно. Причина стандартная: «а кто его знает, что там было».

В какой-то момент это всех достало, и мне прилетела задача:

Я тогда был Junior DevOps. Без иллюзий, без архитектурных амбиций и без времени.

Ограничения были жёсткие:

Никакого SRE, SLO и observability-манифестов. Просто — чтобы не гадать после падения.

Минимальный набор, без фанатизма:

Главное требование — быстро и воспроизводимо. Если завтра скажут «давай на стейдже так же», я должен повторить без боли.

Первой мыслью был Zabbix. Он умеет всё, шаблонов море, enterprise-стандарт и так далее.

Но если честно — я бы не уложился во время.

Zabbix хорош, когда:

У меня была другая задача: “сделать, чтобы заработало сегодня”.

Netdata я тоже смотрел, но:

В итоге выбор был очевиден и скучен:

Prometheus + Grafana + node_exporter + cAdvisor

Да, банально. Зато разворачивается за 15 минут, много кто работал и умеет, да и развивать в последующем труда не составит.

Вся схема выглядела так:

Схема максимально простая — и в этом её плюс.

Я сразу пошёл по пути «один compose — всё сразу».

Ничего необычного:

Node Exporter работает в режиме host network — это необходимо сбора метрик системы без изоляции в контейнере.

cAdvisor запущен с флагом privileged и монтирует системные директории в read-only режиме. Это дает доступ к информации о всех запущенных контейнерах и их ресурсах.

Именованные volumes (prom_data,graf_data) для сохранности данных Prometheus и настроек Grafana при перезапуске контейнеров.

Запуск:

Через пару минут:

Уже на этом этапе становится спокойнее.

Конфиг был максимально короткий.

Без relabel, без service discovery, без Kubernetes-магии.

Я специально не усложнял: если сейчас не понятно — через месяц будет ещё хуже.

Одна из распространенных ошибок, которую я видел у коллег при работе с grafana — “настроили Grafana руками, а потом забыли, как”. Я решил пойти другим путем.

Первым делом добавил Prometheus как datasource.

Дальше — дашборды. Вместо рисования панелей с нуля импортировал готовые из Grafana Community:

Через 10 минут у меня уже были:

Не идеально, местами избыточно, но наглядно.

После запуска cAdvisor столкнулся с классической проблемой — данных слишком много. Графики показывают десятки метрик по каждому контейнеру, но первые 10 минут я просто смотрел на них и не мог понять:

Решение оказалось банальным — упростить дашборд

Мониторинг — это не про "показать всё возможное", а про быстрые ответы на конкретные вопросы. Если не понятно, зачем метрика на дашборде — её можно убрать.

Самое смешное — первая реальная польза от мониторинга пришла не через алерты и не через сложные метрики. Я просто открыл дашборд Node Exporter и увидел:

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

Мониторинг без алертов — это просто красивые графики. Чтобы система действительно работала, добавил базовые правила алертинга в Prometheus.

Я начал с двух правил:

Конфигурация в prometheus/alerts.yml:

Без сложных порогов, без "умных" условий, без многоуровневой логики. Принцип простой:

В итоге имею рабочий стек мониторинга, который:

Это не enterprise-решение с распределённым хранением метрик и сложными SLA. Но это реальный шаг от "ничего не видим" к "понимаем, что происходит".

Но это уже следующий уровень.

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

Начни с простого:

Принцип один: лучше видеть хоть что-то, чем ничего.

Раз в неделю мы проводим бесплатные встречи для начинающих DevOps-инженеров, где обсуждаем собеседования, реальную работу и подводные камни, а также проводим пробные собеседования. #devops

#devops #monitoring #prometheus #docker #infrastructure