Прямой ответ
Локальный мониторинг поднимается compose-профилем из двух контейнеров: Prometheus (сбор метрик скрейпингом) и Grafana (дашборды) — суммарно 300–700 МБ RAM, что по меркам dev-стека недорого. Ценность в разработке конкретна: вы видите кривые задержек и очередей до прода, учитесь читать метрики своего приложения и приходите в прод-инцидент с привычным инструментом. Состав минимума: Prometheus с конфигом на 3–5 целей (приложение, node_exporter, Redis/Postgres-экспортеры), Grafana с анонимным read-only-доступом, ретеншен данных 7–14 дней — локальная история длиннее не нужна.
Минимальный compose-профиль
prometheus:
image: prom/prometheus:latest
profiles: ["observability"]
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prom-data:/prometheus
command: ["--config.file=/etc/prometheus/prometheus.yml",
"--storage.tsdb.retention.time=14d"]
mem_limit: 512m
grafana:
image: grafana/grafana-oss:latest
profiles: ["observability"]
ports: ["3001:3000"]
mem_limit: 512m
prometheus.yml:
scrape_configs:
- job_name: app
static_configs: [{targets: ["host.docker.internal:8000"]}]
- job_name: node
static_configs: [{targets: ["host.docker.internal:9100"]}]
Профиль observability — паттерн из статьи про Compose-стек: мониторинг поднимается по требованию (docker compose --profile observability up -d), а не висит в памяти постоянно.
Метрики приложения: что экспортировать первым
Библиотеки под языки (prometheus-client для Python, prom-client для Node, micrometer для JVM) дают счётчики почти бесплатно. Первый осмысленный набор — четыре золотых сигнала: latency (гистограмма времени обработки запроса), traffic (счётчик запросов), errors (счётчик 5xx), saturation (очереди/пулы). Типовые ошибки новичка: метрика-гистограмма на каждый чих (кардинальность взрывает память Prometheus — сотни тысяч серий) и лейблы со значениями вроде user_id (та же проблема; правило: лейбл — это измерение с малым числом значений, не идентификатор сущности).
Проверка кардинальности локально: prometheus_tsdb_head_series в Status → Targets/Graph; для dev-стека тысячи серий — норма, сотни тысяч — сигнал пересмотреть лейблы.
Grafana: дашборды без коллекционирования
Практика, экономящая часы: начните с готовых дашбордов grafana.com по ID — node_exporter full (ID 1860), PostgreSQL (9628), Redis (763) — импорт по ID занимает минуту и покрывает инфраструктуру. Для приложения соберите один дашборд на четыре панели (latency p50/p95, RPS, ошибки, saturation) — больше на старте не нужно: дашборды, которые никто не открывает, деградируют незаметно. Алерты в локальной dev-среде обычно избыточны; исключение — учебные сценарии (alerting Prometheus на локальном стенде безопасен и полезен как тренажёр).
Бюджет ресурсов и честные границы
Счёт: Prometheus 200–500 МБ (зависит от числа серий и ретеншена), Grafana 150–300 МБ, экспортеры по 20–50 МБ. На 16 ГБ ноутбуке стек с мониторингом остаётся комфортным; на 8 ГБ — поднимайте профиль только на время отладки. Границы честности: локальный Prometheus не заменяет прод-мониторинг (другие объёмы, алертинг, доступность), и не собирает трейсы — распределённая трассировка (OpenTelemetry/Jaeger) отдельная тема и отдельный гигабайт памяти; в dev её поднимают точечно, когда ищут межсервисные задержки.
Когда локального стека мало и метрики нужны «как в проде» — например, для тестирования алертов и записей (recording rules) — разумнее поднять стенд на сервере или в локальном Kubernetes: кластерные бюджеты разобраны в статье про k3s/minikube/kind.
Что мониторинг даёт именно разработчику
Три сценария из практики. Первый — нагрузочная проверка: прогнали k6-сценарий и сразу видите на графике, где деградация (пул соединений? CPU? очередь?) вместо гаданий по логам. Второй — утечки: process_resident_memory_bytes вашего приложения растёт линейно часами — объективное доказательство для профилирования — инструменты разобраны в статье про профилирование Python-приложений. Третий — привычка к прод-инструментам: PromQL-запросы (histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))) одинаковы на ноутбуке и в проде; написанный локально запрос в инциденте экономит минуты, которых обычно нет.
FAQ
Нужен ли мониторинг в учебном проекте? Как тренажёр — да: экспорт четырёх метрик и один дашборд учат наблюдаемости лучше любых статей. Как обязательная часть — нет: не превращайте pet-проект в инфраструктурный полигон.
Prometheus или VictoriaMetrics локально? Prometheus — стандарт, по нему документация и вакансии; VictoriaMetrics экономнее по ресурсам на больших объёмах, которые локально не возникают. Начинайте с Prometheus.
Сколько места занимает история метрик?
Порядок 1–2 МБ на серию в сутки при дефолтных настройках; типичный dev-стенд с 14-дневным ретеншеном — единицы гигабайт. Контроль — флаг retentions и prometheus_tsdb_storage_blocks_bytes.
Можно ли обойтись без Grafana? Да: Prometheus Expression Browser показывает графики сам, для пары панелей его хватает. Grafana стоит своих 200 МБ, когда дашбордов больше двух-трёх или нужен общий экран для команды.
PromQL: пять запросов, которые окупают установку
Минимальный набор, который стоит выучить на локальном стенде — он же используется в проде. Загрузка CPU машины: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100. Доля ошибок приложения: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])). 95-й перцентиль задержки: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)). Рост памяти процесса (поиск утечки): deriv(process_resident_memory_bytes[30m]) — положительная производная часами и есть объективный признак. Заполнение диска: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100.
Эти пять строк закрывают большинство вопросов «что происходит» и, что важнее, формируют привычку: в прод-инциденте вы не вспоминаете синтаксис, а подставляете свои метрики в знакомые шаблоны. Локальный Prometheus — самый дешёвый тренажёр для этого навыка: сломать нечего, данные свои, эксперименты бесплатны.
Нужны ли алерты на локальном стенде? Для рабочих задач почти нет: вы и так смотрите на графики. Исключение — учебный интерес (настроить alerting-правило и получить срабатывание полезно как тренажёр) и длинные фоновые прогоны: правило «процесс умер» с уведомлением в мессенджер экономит часы ожидания.
Что делать с дашбордами при переезде на новую машину? Экспортируйте JSON дашборда и храните в репозитории проекта рядом с compose-файлом: дашборд — часть инфраструктуры стенда. Импорт на новом месте — одна команда API или клик в интерфейсе.
Стоит ли добавлять Loki для логов? Для локального стека обычно достаточно docker-логов и journalctl; Loki оправдан, если вы сознательно тренируете прод-связку «метрики плюс логи» или логи реально нужны агрегированно по нескольким сервисам. Лишние 200–400 МБ памяти стоят этого только при явной цели.
Как ограничить рост места под метрики, кроме ретеншена? Второй рычаг — число серий: меньше лейблов с высокой кардинальностью, меньше экспортируемых метрик. Проверка статуса TSDB в веб-интерфейсе Prometheus показывает топ серий по объёму — обычно половина места приходится на один неудачный лейбл.
Источники: документация Prometheus (overview, naming), Grafana docs (ссылки в шапке).