Мониторинг/логирование: стартовая конфигурация

Коротко. Мониторинг отвечает на вопрос «что происходит с системой прямо сейчас» (метрики), логирование — «что именно случилось и почему» (события). Базовый стек новичка: Prometheus + Grafana для метрик и централизованный сбор логов. Плюс алерты, чтобы узнавать о проблеме раньше пользователей.

Зачем это нужно

Без наблюдаемости вы узнаёте о падении от разгневанных пользователей. Мониторинг и логи дают: раннее обнаружение проблем, быструю диагностику причины и данные для оптимизации. Это часть культуры надёжности (SRE).

Мониторинг и метрики

Метрика — числовой показатель во времени (загрузка CPU, память, число запросов, задержка). Классика «золотых сигналов»:

• Latency — время ответа.
• Traffic — нагрузка (запросы в секунду).
• Errors — доля ошибок.
• Saturation — насыщенность ресурсов (CPU, память, диск).

Инструменты: Prometheus собирает метрики, Grafana строит дашборды.

Логирование

• ✅ Пишите структурированные логи (JSON), а не сплошной текст — их проще искать.
• ✅ Указывайте уровень: DEBUG, INFO, WARN, ERROR.
• ✅ Централизуйте сбор (например, стек Loki/ELK), чтобы искать по всем сервисам сразу.
• ❌ Не логируйте секреты и персональные данные.

Три столпа наблюдаемости

В индустрии наблюдаемость раскладывают на три вида сигналов, и полезно понимать разницу: метрики — агрегированные числа для трендов и алертов (дёшево хранить, но не расскажут детали); логи — подробные записи событий для разбора конкретного случая; трейсы — путь одного запроса через все сервисы, незаменим в микросервисах, чтобы понять, где именно тормозит. Джуну достаточно уверенно владеть первыми двумя и знать, что трейсы существуют и зачем.

Алерты

Алерт — автоматическое уведомление, когда метрика вышла за порог (например, ошибки больше 5% или диск заполнен на 90%). Правила:

• Алертить на симптомы (пользователю плохо), а не на каждую мелочь.
• Меньше шума — иначе на алерты перестают реагировать.
• Каждый алерт должен требовать действия.

С чего начать на своём проекте

Теорию быстрее всего закрепить руками: задеплойте свой сервис на VPS, поднимите рядом Prometheus и Grafana в Docker, соберите базовые метрики (CPU, память, число запросов, задержка) и сделайте один дашборд. Добавьте один осмысленный алерт — например, на рост доли ошибок. Этого мини-проекта достаточно и для понимания темы, и чтобы показать наблюдаемость в портфолио DevOps.

Метрики, логи, алерты

Метрики — «что происходит» (RPS, latency, error rate). Логи — «почему у этого запроса». Алерты — «разбуди человека». На старте: healthcheck, базовые метрики процесса, structured logs, один алерт на error rate/5xx. Без dashboards-Zoo и 100 алертов, которые все mute.

Правило: алерт = действие runbook. Иначе on-call выгорит. После VPS/Docker это следующий зрелый шаг: деплой, DevOps.

Golden signals

Latency, traffic, errors, saturation — базовая рамка. На учебном сервисе: latency p95, RPS, %5xx, CPU/RAM. Алерт на error budget проще, чем 20 raw-метрик. Логи — JSON, correlation id, без паролей в plain text.

Следующий шаг в DevOps

Примените идеи из «Мониторинг/логирование: стартовая конфигурация» к своему учебному проекту или к одной вакансии на этой неделе. Поднимите один сервис в Docker, прогоните простой CI, задеплойте на VPS или в песочницу. База: Docker, GitHub Actions, VPS. Полный маршрут — DevOps старт, обзор роли — DevOps на уровне джуна.

Проверьте, что алерт приходит

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

По теме: VPS, DevOps, Docker, GitHub Actions, профессии.

Проверьте, что проект можно перенести и восстановить

После первого запуска попробуйте перенести проект на другой сервер и восстановить его из резервной копии. Проверьте базу, файлы и действия пользователя. Так станет видно, какие зависимости вы забыли при первом деплое.

Частые вопросы

С чего начать новичку?
Поднимите Prometheus + Grafana для одного сервиса и сделайте дашборд с CPU, памятью и числом запросов. Этого достаточно для понимания.

Чем метрики отличаются от логов?
Метрики — агрегированные числа во времени (тренды), логи — детальные записи событий (разбор конкретного случая). Нужны оба.

Нужно ли это джуну DevOps?
Базово — да. Понимание «золотых сигналов» и умение читать дашборд ждут даже на входе.

Материал «Мониторинг/логирование: стартовая конфигурация» имеет смысл только вместе с практикой: один артефакт в git на этой неделе важнее десяти вкладок с теорией. Если застряли на выборе роли — начните с профессий и одной вакансии-ориентира.