Мониторинг: что/куда/зачем?

Привет, %username%! Поговорим о такой безумно важной вещи как мониторинг! Постараемся ответить на некоторые вопросы связанные с мониторингом инфраструктуры и приложений.

🔄 Обновлено 2026-05-15: тело поста оставлено без изменений — модели push/pull, алерты и этапы зрелости мониторинга по-прежнему актуальны. В конце добавил раздел «Observability 2.0»: что появилось в стеке за 5 лет (OpenTelemetry, eBPF, SLO, VictoriaMetrics/Loki/Tempo/Pyroscope).

Определения#

Для начала определимся что есть что:

• Мониторинг инфраструктуры – это сбор метрик описывающих состояние вашей IT-инфраструктуры;
• Метрика – это конкретная характеристика, показывающая текущее состояние по определенному параметру (пример: количество одновременных подключений);
• Сервер мониторинга – ПО, которое выполняет агрегацию, хранение, пересчет данных по метрикам;
• Агент мониторинга – ПО, которое выполняет сбор метрик с хоста, который подлежит мониторингу, а так же отправку данных на сервер мониторинга;

Вроде бы всё довольно просто выглядит: мониторинг – это сбор показателей системы (инфраструктуры) в реальном времени (ровно на столько, на сколько это возможно - об этом чуть ниже).

Инструменты#

На рынке уже давно устоялись такие замечательные инструементы как Zabbix , Prometheus , Nagios , OpenNMS , Cacti , Netdata . Обзор данных продуктов я делать не буду, т.к. этой информации предостаточно на просторах паутины. Главное что необходимо знать о системах мониторинга, это то как они работают (в общих чертах).

Модели работы#

Собственно две основные (ибо кмк являются уже стандартом де-факто для всей отрасли) системы мониторинга – Zabbix и Prometheus – могут работать в двух режимах (по двум моделям): Push и Pull.

• Push-модель – когда сервер мониторинга ожидает подключений от агентов для получения метрик;
• Pull-модель – когда сервер мониторинга сам подключается к агентам мониторинга и забирает данные;

Все довольно просто: выбор модели работы необходимо делать исходя из того, чего вы хотите и что вы можете. Например (пусть будет Zabbix):

У вас есть 10 серверов в приватной сети и без белых IP, а так же отсутствует возможность настроить хоть какой-то NAT (пробросить порты до агентов). А сервер мониторинга у вас отдельный (пусть стоит где-то у хостера) и он не имеет прямой связи с данными 10-ю серверами, которые вы хотите мониторить.

В данном кейсе ваш выбор очевидет – вам подходит только Push-модель. Вам необходимо будет добавить все хосты в мониторинг, указать им в качестве IP тот адрес который они имеют в приватной сети, порт оставить по дефолту, а в качестве шаблонов выбирать те, которые используют активного агента. В этом случае у вас будет агент подключаться к серверу и отдавать метрики.

Данную схему можно немного доработать – у Zabbix есть такая вещь как Zabbix-Proxy , а у Prometheus – Pushgateway . Данные сервисы в некоторых ситуациях помогут исправить картину мира. Например:

Возьмем ту же картину мира, что и в прошлом примере, и добавим туда еще один сервер, на котором развернем Zabbix-Proxy, а хосты в самом Zabbix (в веб-интерфейсе), привязываем к Zabbix-Proxy. После чего можем привязывать шаблоны с обычными агентами.

Что мониторить?#

Теперь попробуем определиться что именно мы хотим мониторить? Какие метрики нам нужны? Тут все так же просто – начнем по порядку снизу вверх:

• Аппаратные метрики – все то, на чем крутится ваша ОСь (даже если у вас виртуализация – собрайте метрики виртуализации);
• Метрики ОС – чем занимается ваша ОСь (CPU/RAM/Disks/Network);
• Метрики сервисов – метрики всего того, что обеспечивает доступность приложения (Nginx/Apache/Redis/MySQL/PostgreSQL);
• Метрики приложения – все метрики вашего приложения (тот же PHP/NodeJS). Сразу оговорюсь - тут без ваших разработчиков никак. Пусть дают конкретные ручки, которые будет дергать мониторинг. А сразу имеет смысл мониторить количество запущенных процессов (Кэп), количество потребляемой процессом памяти (мы так узнали, что у нас текла NodeJS по памяти, а пока разрабы не придумали как решить проблему - мы рестартовали демон каждые 20-30 минут);
• Метрики смежных сервисов – метрики всего того, с чем взаимодействует ваше приложение (внешние/внутренние интеграции - сторонние API, 1C);

Собственно говоря список не такой уж и большой, но при желании его так же можно расширять под себя и пихать туда всё, что захочется видеть.

Как часто собирать метрики?#

Я выше упомянул о том, что такое мониториг, а так же сказал, что он должен быть real time ровно на столько, на сколько это возможно реализовать. В чем собственно проблема, может спросить абсолютно любой. А проблема довольно простая и очевидная. Я как админ хочу знать, что моя инфратруктура жива и с ней все в порядке. Любой неочень разраб, да и недалекий начальник - а-ля бигбосс - скажет: а давай собирать метрики раз в секунду! С одной стороны это выглядит вполне логично! И в идеальном мире я бы так и делал, но как всегда есть одно “НО”.

Начну с примера: у нас есть средний сайтик средней компании со средней посещаемостью 10 человек в месяц. Этот сайтик показывает картинку с котиком, каждый раз разную как только любой пользователь открывает главную страничку сайта. Пусть у нас будет средний PHP+MySQL+Nginx. Все это добро крутится на простеньком сервере (не будем называть характеристики для упрощения картины мира).

Мы преспокойно можем дергать с него метрики раз в секунду. Нагрузки как таковой нету, а следовательно сервер бОльшую часть времени занят ничем. Только вот незадача: наши шикарные маркетологи/пиращики/продажники (я не разбираюсь в сортах не технического персонала, так что извиняйте) ударно поработали и вот у нас на сайт стало прилетать 100k хомячков в час. И вот теперь нам категорически важно получать данные как можно оперативнее, только вот очередное “НО” выходит на сцену.

Мы, как было сказано бигбоссом, настроили сбор метрик раз в секунду. Метрики к нам в мониторинг летят и в целом все не плохо, только мы видим по мониторингу что наш “агент мониторинга” жрет приличное количество ресурсов (CPU/RAM/Disk IO/Network in/out). Вот прям неприлично много, а еще хомячки начали жаловаться, что котиков не видят (а мы как компания получаем за это денег). Из чего мы делаем вывод: наш сервер занят не работой (не добычей бабла), а сбором метрик о своем состоянии.

Вот тут-то мы и начинаем крутить параметры частоты опроса метрик. Где это действительно важно/нужно оставляем 1s, а там где и потерпеть можно – ставим 1/2/5/10m.

Собственно вывод из этого простой: частота сбора метрик – это баланс между актуальностью информации и нагрузкой на систему.

Алерты#

Я в своей практике не первый раз сталкиваюсь с ситуацией, когда есть мониторинг, а вот алерты от него присылаются на email. А как не многие знают, в доставке сообщений электронной почты могут быть задержки до нескольких суток.

Как следствие, первое что я делаю – настраиваю алерты по “более оперативным” каналам (читай телеграм). Некоторые компании используют свои внутренние порталы на базе того же “Битрикс24”, но как правило этот портал стоит в офисе и в случае падения интернета в офисе никто об это не узнает вовремя.

Алерты это в принципе хорошо и важно, без этого никак. Но вот когда их становится категорически много (на одной из прошлых работ Zabbix генерировал от 3k до 12k алертов за сутки), то люди (белковые ублюдки) могут проглядеть/пропустить/пролюбить/не заметить важное сообщение от мониторинга, а следовательно не среагировать вовремя на факап, прод ляжет, админу прилетит пистон, он с горя напьётся и уволится.

Суть алертов должна сводиться к тому, что на них должны реагировать. Как следствие: алертить надо о том, на что требуется сиюминутная реакция.

Полезные видосы по теме:

1. UPTIMEDAY 2017-04-08 - Илья Аблеев / Badoo - Как устроен мониторинг в Badoo - YouTube
2. Автодискавери в мониторинге: как надёжно обеспечить полноту мониторинга // Николай Сивко, okmeter.io - YouTube
3. UPTIMEDAY 2017-04-08 - Николай Сивко / Okmeter - Типовое внедрение мониторинга - YouTube

Вывод: о том, на что надо реагировать здесь и сейчас кричим “Алярма!”, в остальных случаях просто держим “лампочку” горящей на дашборде.

Итого#

А итоги тут довольно простые: мониторинг дело индивидуальное, важное и не очень сложное. Многие компании проходят в плане мониторинга через следующие этапы:

• Нет мониторинга;
• nodeping/worldping (доступность сайтиков снаружи – из тырнета);
• Базовый мониторинг инфраструктуры (CPU/RAM/Disk space/etc);
• Мониторинг приложения (как себя чувствует приложение в конкретный промежуток времени);
• Перенасыщение метриками (собираются абсолютно все метрики, которые можно собрать/придумать);
• Чистка алертов/метрик (когда админы начинают спать по 2-3 часа в сутки - начинают думать о чем можно не кричать, а что и вовсе не надо);

Observability 2.0: что появилось за 5 лет#

Пост написан в октябре 2020-го. Базовые модели работы — push/pull, иерархия алертов, путь компании от «нет мониторинга» до «слишком много метрик» — остались ровно теми же. А вот стек, на котором это всё крутится, изменился ощутимо.

Три кита превратились в пять#

Раньше говорили: metrics + logs + traces. К 2026-му в это уравнение прочно добавились ещё два слагаемых:

• Continuous profiling — постоянный сбор CPU/heap-профилей в проде, чтобы видеть, что грузит сервис прямо сейчас. Инструменты: Pyroscope (в составе Grafana Labs), Parca , Polar Signals .
• Events — связные бизнес-события и системные изменения (деплои, фича-флаги, изменение конфига) как отдельный сорт сигналов. Помогает коррелировать «у нас всё лежит» с «вот деплой 5 минут назад».

OpenTelemetry как стандарт#

Главная история последних лет в наблюдаемости — это OpenTelemetry (OTel). Vendor-agnostic стандарт для сбора и передачи метрик, логов и трейсов. Универсальный SDK для приложений и универсальный коллектор (otel-collector), который умеет принимать данные в OTLP-формате и отправлять куда угодно: Prometheus-совместимый стор, Tempo/Jaeger, Loki, S3, vendor SaaS.

Что это даёт практически: ты больше не зависишь от выбора бэкенда. Сегодня у тебя VictoriaMetrics, завтра Mimir, послезавтра Datadog — приложение пишет в OTel, всё остальное прокидывается коллектором без правки кода.

eBPF-based observability#

Параллельно с OTel выросло целое поколение инструментов, которые наблюдают за системой на уровне ядра через eBPF, без необходимости вшивать SDK в приложения. Это особенно ценно для legacy-сервисов и сторонних бинарей. Известные примеры:

• Pixie — мгновенная observability для Kubernetes без инструментирования;
• Cilium Hubble — observability сетевого трафика в k8s;
• Parca — continuous profiling через eBPF;
• Coroot — APM без агентов в приложении.

SLO/SLI как первый класс#

В исходном посте я писал «алертить надо о том, на что требуется сиюминутная реакция». В 2026-м это правило формализовали в SLO-подход: алертим не «CPU выше 80%», а «error budget на текущий период исчерпан на N% быстрее, чем должен». Это убирает алерт-фатигу за счёт того, что симптомы (latency, error rate) важнее причин (CPU/RAM).

Подробнее — в моём свежем посте SLO как чертёж архитектуры и Burn rate — не скорость, а ускорение .

Современный open-source-стек#

Если в 2020-м для self-hosted я говорил «Zabbix + Prometheus», то сейчас типичный набор выглядит примерно так:

Zabbix всё ещё отлично подходит для классического infra-monitoring (особенно физика, сеть, BMC/IPMI) и в 7.0 серьёзно подтянул API и интеграцию с TimescaleDB.

TL;DR апдейта#

Базовые принципы наблюдаемости не изменились. Изменилось три вещи:

1. OTel стандартизировал, как приложения отдают сигналы;
2. eBPF сделал возможным наблюдать без инструментирования;
3. SLO дал способ алертить по симптомам, а не по причинам.

Если переезжать сегодня — двигайся в сторону этих трёх.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.