Как я поднял мониторинг инфраструктуры за 3 часа
10 минут
29 января 2026
Кейс junior DevOps без героизма и магии
Контекст: «у нас нет мониторинга, но он нужен вчера»
История довольно банальная.
Небольшая команда, несколько сервисов, часть в Docker, часть просто на VM. Прод падает редко, но каждый раз — внезапно. Причина стандартная: «а кто его знает, что там было».
В какой-то момент это всех достало, и мне прилетела задача:
«Подними базовый мониторинг. Не идеальный, просто чтобы видеть, что происходит».
Я тогда был junior DevOps. Без иллюзий, без архитектурных амбиций и без времени.
Ограничения были жёсткие:
  • времени — пара часов
  • бюджета — 0
  • доступ — обычный VPS + Docker
  • цель — CPU / память / диск / контейнеры / алерты
Никакого SRE, SLO и observability-манифестов. Просто — чтобы не гадать после падения.
Что хотелось получить в итоге
Минимальный набор, без фанатизма:
  • загрузка CPU
  • память
  • диск (и чтобы не заканчивался внезапно)
  • что происходит с Docker-контейнерами
  • алерт, если всё совсем плохо
Главное требование — быстро и воспроизводимо. Если завтра скажут «давай на стейдже так же», я должен повторить без боли.
Почему не Zabbix и не «что-то попроще»
Первой мыслью был Zabbix. Он умеет всё, шаблонов море, enterprise-стандарт и так далее.
Но если честно — я бы не уложился во время.
Zabbix хорош, когда:
  • инфраструктура уже устоявшаяся
  • есть время на шаблоны, хосты, авто-дискавери
  • нужен контроль всего и сразу
У меня была другая задача: “сделать, чтобы заработало сегодня”.
Netdata я тоже смотрел, но:
  • алерты там на старте довольно условные
  • контейнеры видно, но кастомизировать тяжеловато
  • хотелось чего-то более «стандартного»
В итоге выбор был очевиден и скучен:
Prometheus + Grafana + node_exporter + cAdvisor
Да, банально. Зато разворачивается за 15 минут, много кто работал и умеет, да и развивать в последующем труда не составит.
Вступите в DevOps-сообщество и ускорьте путь к ЗП 200к +
Каждую неделю — разборы собеседований, подборки вакансий, созвоны с профи и разборы карьерных маршрутов. Всё в Telegram — бесплатно.
Архитектура «на коленке»
Вся схема выглядела так:
  • отдельная VM под мониторинг
  • всё в docker-compose
  • никаких TLS, auth и high availability
  • алерты — хоть куда-нибудь (для начала)
Схема максимально простая — и в этом её плюс.
Поднимаем стек (docker-compose)
Я сразу пошёл по пути «один compose — всё сразу».
version: "3.8"

services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus:/etc/prometheus
      - prom_data:/prometheus
    ports:
      - "9090:9090"
    restart: unless-stopped

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - graf_data:/var/lib/grafana
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter
    network_mode: host
    pid: host
    restart: unless-stopped

  cadvisor:
    image: gcr.io/cadvisor/cadvisor
    privileged: true
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker:/var/lib/docker:ro

volumes:
  prom_data:
  graf_data:
ничего необычного:
Node Exporter работает в режиме host network — это необходимо сбора метрик системы без изоляции в контейнере.
cAdvisor запущен с флагом privileged и монтирует системные директории в read-only режиме. Это дает доступ к информации о всех запущенных контейнерах и их ресурсах.
Именованные volumes (prom_data,graf_data) для сохранности данных Prometheus и настроек Grafana при перезапуске контейнеров.
Запуск:
docker-compose up -d 
Через пару минут:
  • Prometheus доступен
  • Grafana открывается
  • экспортеры отвечают
Уже на этом этапе становится спокойнее.
Prometheus: минимум конфига
Конфиг был максимально короткий.
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: node
    static_configs:
      - targets: ["MONITORING_HOST_IP:9100"]

  - job_name: cadvisor
    static_configs:
      - targets: ["localhost:8080"]
Без relabel, без service discovery, без Kubernetes-магии.
Я специально не усложнял: если сейчас не понятно — через месяц будет ещё хуже.
Grafana: никаких кликов вручную
Одна из распространенных ошибок, которую я видел у коллег при работе с grafana — “настроили Grafana руками, а потом забыли, как”. Я решил пойти другим путем.
Первым делом добавил Prometheus как datasource.
Дальше — дашборды. Вместо рисования панелей с нуля импортировал готовые из Grafana Community:
  • Node Exporter Full — для метрик хоста
  • Docker Container & Host Metrics — для контейнеров через cAdvisor
Через 10 минут у меня уже были:
  • CPU по ядрам
  • Память и swap
  • Дисковое пространство
  • Контейнеры с детализацией по потреблению ресурсов
Не идеально, местами избыточно, но наглядно.
Первые грабли (куда без них)
1. Контейнеры «что-то жрут», но непонятно кто
После запуска cAdvisor столкнулся с классической проблемой — данных слишком много. Графики показывают десятки метрик по каждому контейнеру, но первые 10 минут я просто смотрел на них и не мог понять:
  • Это нормальное потребление или проблема?
  • Сколько вообще "много" для этого контейнера?
  • Кто конкретно сейчас жрёт ресурсы?
Решение оказалось банальным — упростить дашборд
  • вынести top-контейнеры по CPU и памяти
  • убрать всё лишнее
Мониторинг — это не про "показать всё возможное", а про быстрые ответы на конкретные вопросы. Если не понятно, зачем метрика на дашборде — её можно убрать.
2. Диск внезапно почти закончился
Самое смешное — первая реальная польза от мониторинга пришла не через алерты и не через сложные метрики. Я просто открыл дашборд Node Exporter и увидел:
  • Диск заполнен на 85%
  • Логи занимают вагон места
  • Ротация не настроена
До этого момента я даже не думал проверять место на диске. Без мониторинга эта проблема всплыла бы ровно в тот момент, когда место закончилось окончательно — скорее всего, в самое неподходящее время.
Сообщество, в котором DevOps становятся профессионалами
Это больше, чем просто чат — это точка входа в профессию. Участники сообщества делятся опытом прохождения собеседований, дают фидбек на резюме, обсуждают рабочие кейсы, делятся инсайтами, где и как ищут работу, что спрашивают на интервью и какие инструменты реально применяют. Регулярные созвоны с опытными DevOps-специалистами, доступ к подборкам слитых курсов — всё это поможет вам прокачаться быстрее и чувствовать, что вы не один на этом пути. Бесплатно.
Алерты: чтобы мониторинг не был телевизором
Мониторинг без алертов — это просто красивые графики. Чтобы система действительно работала, добавил базовые правила алертинга в Prometheus.
Я начал с двух правил:
  • Сервис недоступен
  • Диск занят на >90%
Конфигурация в prometheus/alerts.yml:
groups:
  - name: base
    rules:
      - alert: TargetDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical

      - alert: DiskAlmostFull
        expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.1
        for: 10m
        labels:
          severity: warning
Без сложных порогов, без "умных" условий, без многоуровневой логики. Принцип простой:
лучше ложный алерт днём, чем сюрприз ночью.
Что получилось через 3 часа
В итоге имею рабочий стек мониторинга, который:
  • Показывает состояние хост-системы
  • Видно метрики всех Docker-контейнеров
  • Есть базовые алерты при проблемах
  • Всё поднимается одной командой
  • Легко переносится на другие стенды
Это не enterprise-решение с распределённым хранением метрик и сложными SLA. Но это реальный шаг от "ничего не видим" к "понимаем, что происходит".
Главные выводы (как для junior)
  1. Мониторинг — это не про инструменты, а про вопросы Если ты не знаешь, что хочешь увидеть — Grafana не поможет. Инструменты — это только средство для ответов.
  2. Лучше простой мониторинг сегодня, чем идеальный никогда За 3 часа можно сделать работающую систему, которая уже даёт пользу. За неделю размышлений о "правильной архитектуре" — можно не сделать вообще ничего. Начни с базы, улучшай по мере необходимости.
  3. Готовые дашборды — это нормально Не нужно рисовать панели с нуля, если есть проверенные community-решения. Сначала — просто видеть что происходит, кастомизация придет позже.
  4. Первый эффект почти всегда неожиданный Я ждал проблем с CPU или памятью контейнеров, а первым делом обнаружил заполненный диск. Мониторинг показывает не то, что ты ожидаешь увидеть, а то, что на самом деле происходит.
В этой статье разбираем самые опасные команды в Linux и DevOps-инструментах, которые могут случайно повредить систему или удалить важные данные. Покажем, как они работают, чем рискуете при их запуске — и какие есть безопасные альтернативы. Подойдёт тем, кто хочет автоматизировать без страха всё сломать.
Что бы я сделал дальше (если было бы время)
  • Алерты по памяти и CPU
  • Централизованное логирование, хотя бы ELK/Loki для агрегации логов из контейнеров
  • Нормальную доставку алертов
  • Разделение prod / stage
  1. Но это уже следующий уровень.
Вместо заключения
Этот кейс не про героизм и не про "я всё знаю". Это про нормальную инженерную работу: взял задачу, разобрался, сделал минимально работающее решение, получил результат.
Если ты junior и тебе дали задачу
"подними мониторинг"
Не надо сразу думать про идеальную архитектуру, high availability и продвинутую обработку метрик.
Начни с простого:
  1. Что я хочу видеть?
  2. Какие инструменты для этого подходят?
  3. Как быстро это поднять?
  4. Принцип один: лучше видеть хоть что-то, чем ничего.
Telegram-бот с плюшками
Если вы готовитесь к переходу в DevOps — этот бот станет вашей отправной точкой.
Здесь не общие рекомендации из блогов, а выжимка из реального опыта: вопросы с реальных собеседований, шаблоны ответов, разборы типичных ошибок и то, что действительно спрашивают в компаниях.
Бот регулярно пополняется новыми материалами — от подборок актуальных вакансий и инсайтов от специалистов до ссылок на полезные курсы и ресурсы.
А также комьюнити, которое помогает ускорить рост: опытные инженеры, живые обсуждения и поддержка на каждом этапе перехода в DevOps.
Бесплатно и без спама.

Истории успеха

Семен
27 лет
Устроился на 250 тыс. ₽
Все супер, спустя 3 месяца вышел на работу почти без начального уровня знаний. После обучения также есть поддержка, чтобы освоиться на рабочем месте. На обучении обсуждаются все основные моменты профессии, но чтобы быть опытным специалистом в своем деле, надо помимо обучения также читать и выполнять задания дополнительно, тогда все будет супер.
Профессионалы своего дела. Создали огромную базу по DevOps с нуля и чаты для учеников на 500+ человек. Ребята устраивают открытые встречи, готовы ответить на каждый вопрос, который был не понятен. В итоге нашёл проект, на котором можно прокачать скилы и за который неплохо платят. Очень рекомендую!
Илья
23 года
Устроился на 220 тыс. ₽
Максим
33 года
Устроился на 215 тыс. ₽
До GigaDevOps я только начинал разбираться в теме и не представлял, как перейти в DevOps самостоятельно. С менторами получилось выстроить понятный путь: от базовых вещей вроде Linux и сетей до Docker, Kubernetes, Terraform и облаков.
Что получилось по итогам:
  • разобрался в ключевых технологиях DevOps
  • прошёл несколько подготовительных собеседований
  • получил реальные предложения от компаний
  • понял, как применять знания в проектах
  • получил сопровождение после выхода на работу
Егор
19 лет
Устроился на 230 тыс. ₽
Я выбрал Гигадевопс для обучения и подготовки к собеседованиям на DevOps, и это оказалось одним из лучших решений в моей карьере.
Что я имею в итоге:
  • офер на 230к
  • с нулевых знаний до результата 3,5 месяца
  • готовое резюме и легенда
  • реактивная поддержка менторов после устройства
P.S.
Отдельное спасибо Антону и Саше за психологический коучинг
Часто спрашивают:
Вопрос:
Можно ли войти в DevOps без технического образования?
Ответ:
— Да, если Вы готовы учиться и мыслить как инженер.
Вопрос:
Сколько времени потребуется, чтобы выйти на зарплату от 200 000 ₽?
Ответ:
— Обычно от 6 до 9 месяцев при фокусе и поддержке.
Вопрос:
Чем DevOps отличается от системного администратора?
Ответ:
— DevOps не просто поддерживает. Он автоматизирует, оптимизирует и выстраивает процессы под весь цикл разработки.