Мой дэйли дайджест

одно техническое понятие в день

Мониторинг

31 июля 2026 · ~12 мин чтения

концепция devops наблюдение инфраструктура надёжность

Мониторинг

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

История

Слово «monitor» в английском значит «тот, кто напоминает» и «тот, кто
предупреждает» — от латинского monere. В индустриальном смысле мониторинг
как концепция появился задолго до IT: в котельных XIX века были механические
самописцы давления, а в атомной энергетике 1950-х — панели с сотнями стрелок,
которые оператор обходил глазами каждые пять минут.

В компьютерных системах мониторинг начал оформляться в 1970–80-х вместе с
мейнфреймами IBM: программы вроде RMF (Resource Measurement Facility, 1974)
собирали статистику по CPU, памяти и I/O и печатали её на бумажной ленте.
Задача была та же: понять, когда машина захлёбывается, до того как она встанет.

Дальше — несколько важных вех:

Сегодня мониторинг — это индустрия на десятки миллиардов долларов
(Datadog, New Relic, Splunk, Dynatrace — публичные компании) и обязательный
слой любой серьёзной системы.

Что это такое

Мониторинг сводится к очень простой петле, повторяющейся бесконечно:

  1. Измерить что-то в системе (доступность сайта, длину очереди, число
    ошибок в минуту, количество новых заявок).
  2. Сравнить с ожиданием (порог, коридор, историческое среднее).
  3. Уведомить, если результат вышел за рамки.
  4. Запомнить состояние, чтобы в следующей итерации не пропустить
    и не задублировать.

Всё остальное — обвязка вокруг этих четырёх шагов.

Ключевое отличие мониторинга от логирования: логи собирают всё подряд
и читаются постфактум, чтобы понять «что произошло». Мониторинг —
целенаправленный, работает в реальном времени и должен разбудить дежурного,
если норма нарушена. Логи — архив; мониторинг — сигнальная лампа.

Отличие от метрик: метрики — это сырьё (числа во времени: RPS, latency,
CPU). Мониторинг — надстройка, которая интерпретирует эти числа: «если
latency > 500 мс десять минут подряд — паникуем».

Отличие от observability (наблюдаемости): мониторинг отвечает на
известные вопросы («жива ли база?»), observability даёт возможность задать
новый, ещё не сформулированный («почему ровно у половины пользователей из
Германии ошибка 502 в понедельник в 15:47?»). Мониторинг работает на
предопределённых дашбордах; observability — на структурированных событиях,
которые можно фильтровать и группировать произвольно.

Практически: любой рабочий мониторинг сегодня — это связка из агента
(что-то, что измеряет), хранилища временных рядов (TSDB вроде Prometheus,
InfluxDB, VictoriaMetrics), правил (когда бить тревогу) и канала
уведомлений (Telegram, Slack, PagerDuty, SMS).

Аналогии из жизни

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

Где ломается: датчик умеет только орать «дым есть», но не сказать, откуда
он. Точно так же и плохой мониторинг: приходит алерт «CPU 100%», а какой из
двадцати процессов виноват — идти разбираться руками. Настоящий мониторинг
должен присылать не только сигнал, но и контекст.

Медсестра в отделении реанимации обходит палаты, записывает пульс,
давление, сатурацию каждые два часа. Если что-то вылезло за коридор — вызывает
врача. Это тоже мониторинг: регулярный опрос, набор метрик, правило эскалации.

Где ломается: обход раз в два часа — это редкий «сэмплинг». Между обходами
пациент может успеть умереть. Поэтому серьёзные показатели (ЭКГ) снимают
непрерывно. В IT аналог: если ты пингуешь сайт раз в 5 минут, ты гарантированно
пропустишь падение длиной 4 минуты 59 секунд.

Спидометр в машине. Показывает скорость постоянно, а не в моменты,
когда её у тебя спрашивают. Плюс есть сигнальные лампочки: масло, температура,
ремень. Разные метрики — разные способы уведомления: скорость смотришь сам,
про масло тебе говорят.

Где ломается: спидометр не знает, куда ты едешь. Показатель «скорость
80 км/ч» — это норма на трассе и катастрофа во дворе. Хороший мониторинг
знает контекст: «500 запросов в секунду ночью» — норма для одного сервиса и
аномалия для другого.

Как это работает

Возьмём мониторинг веб-сайта — классический пример. Пошагово:

Шаг 1. Сборщик (collector).
Раз в N секунд (обычно 10–60) агент делает HTTP-запрос к твоему сайту:
GET /health или GET /. Записывает три числа: код ответа (200? 500?),
задержку в миллисекундах, размер ответа. Если сервер не ответил вообще —
записывает «timeout».

Шаг 2. Хранилище (TSDB, Time Series Database).
Числа падают в специальную БД для временных рядов. Пример структуры записи:

metric=http_response_time
labels={site="pik.ru", endpoint="/", region="msk"}
timestamp=1738296420
value=234

TSDB (Prometheus, InfluxDB) умеют хранить миллиарды таких точек и быстро
считать по ним агрегации: среднее за минуту, максимум за час, 95-й
перцентиль (значение, ниже которого 95% всех замеров) за сутки.

Перцентили — важный трюк. Среднее по времени отклика обманчиво: если у тебя
99% запросов быстрые, а 1% медленных, среднее скажет «нормально», а 99-й
перцентиль честно покажет, что каждый сотый пользователь ждёт 5 секунд.

Шаг 3. Правила (rules).
Отдельный движок постоянно перечитывает свежие точки и проверяет условия
вида «если за последние 5 минут более 3 замеров с кодом ≥ 500 —
триггер». В Prometheus это язык PromQL:

rate(http_requests_total{status=~"5.."}[5m]) > 0.01

(«доля ошибок 5xx за последние 5 минут больше 1%»).

Шаг 4. Уведомление (alerting).
Триггер попадает в диспетчер (Alertmanager, PagerDuty), тот решает: кому,
куда, с какой срочностью. Умеет группировать («не 500 писем за 500 упавших
проверок, а одно с общим числом»), заглушать по расписанию (maintenance
window), эскалировать (если через 15 минут никто не ответил — звонить второму
дежурному).

Шаг 5. Состояние (state).
Часто пропускают — и зря. Правильный монитор помнит, какие алерты уже
активны, чтобы не слать один и тот же сигнал каждую минуту. И помнит
«точку отсчёта» (offset, cursor, last_id), чтобы после падения самого
монитора продолжить с того же места, а не переиграть всё с нуля.

Если state не сохранён — монитор либо молчит про новые проблемы (потому что
считает, что уже уведомил), либо спамит одинаковыми сообщениями. Это самая
частая ошибка проектирования собственных мониторов, и она у меня вчера
случилась ровно так.

Пуш vs пулл. Есть две философии, кто с кем инициирует общение:

Хорошая практика — использовать оба: пулл для стабильной инфраструктуры,
пуш для эфемерных задач.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Все, кто держит хоть что-то работающее в сети. Порядки величин:

Из моего мира: Marquiz и любая CRM показывают тебе дашборд с воронкой —
это тоже мониторинг, только продуктовый, а не технический.

Альтернативы и конкуренты

Prometheus + Grafana + Alertmanager (open-source, CNCF).
Плюсы: бесплатно, гибко, огромное сообщество, стал стандартом.
Минусы: собирать по частям, кривая входа неделя-две, при больших объёмах
приходится подключать VictoriaMetrics или Thanos.

Datadog (SaaS).
Плюсы: включил и работает, отличный UI, интеграции с 800+ сервисами.
Минусы: дорого при масштабе (счёт может расти с трафиком экспоненциально),
данные ходят наружу.

Zabbix (open-source, венгерская разработка).
Плюсы: одна коробка со всем, отличный для классической enterprise-серверной,
хорошо работает без интернета.
Минусы: устаревший UI, менее удобен для микросервисов и cloud-native.

Nagios / Icinga (open-source, легенда 2000-х).
Плюсы: проверено временем, миллион готовых плагинов.
Минусы: конфиг в текстовых файлах, идеология «up/down», без метрик.

New Relic (SaaS APM).
Плюсы: лучшее в классе application-monitoring, автотрейсинг Java, .NET,
Node.js.
Минусы: цена, лок-ин.

Для маленьких pet-проектов часто вообще достаточно Uptime Kuma —
однофайловый Docker-контейнер, который делает 80% Pingdom бесплатно.

Когда НЕ стоит использовать

Alert fatigue

Главная патология мониторинга — «усталость от алертов». Если система шлёт 200 писем в день, из которых 195 ложных, то настоящую проблему в этом шуме никто не увидит. Правило Google SRE: если алерт не требует вмешательства человека прямо сейчас — это не алерт, а метрика для дашборда. Каждый алерт должен быть actionable.

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера мы с Claude собирали инкрементальный монитор входящих заявок в CRM
для отслеживания спама: пришла заявка → скоринг по признакам подделки yclid,
подозрительным устройствам и таймингам → уведомление в Telegram с
разбором, если что-то не так. Классическая схема из четырёх шагов (измерь →
сравни → уведоми → запомни состояние) — и, конечно, я споткнулся ровно о
шаг «запомни состояние»: файл state записывался только при наличии новых
лидов, из-за чего первая итерация уходила в пустоту и монитор молчал два
часа. Ровно про это предупреждает любой SRE-учебник — и вот теперь я знаю,
почему.

Краткое резюме