В 2025 году «поставить Prometheus и node_exporter» уже не единственный очевидный путь. В инфраструктуре стало больше контейнеров, динамики (service discovery), требований к централизации и к доставке метрик наружу через remote_write. Поэтому вопрос «какой Prometheus agent выбрать» чаще всего упирается не в бренд, а в то, кто будет делать scrape, кто будет отвечать за доставку метрик и кто будет ограничивать кардинальность.
Ниже — практичное сравнение для админов/DevOps/вебмастеров: как эти агенты устроены, как их эксплуатировать через systemd, где они сильны и где добавляют лишнюю сложность.
Что мы сравниваем и по каким критериям
Важно: три решения частично пересекаются, но исторически закрывают разные роли.
node_exporter — специализированный exporter метрик хоста (CPU/RAM/disk/net/fs и системные счетчики ядра).
Grafana Alloy (раньше Grafana Agent) — агент-коллектор: умеет собирать Prometheus-метрики (scrape), применять relabel/фильтры и отправлять дальше по
remote_write(а также может участвовать в логах/трейсах).Telegraf — универсальный агент на плагинах input/output, сильный в «нестандартных» источниках и протоколах.
Критерии, по которым удобно сравнивать:
Совместимость с Prometheus: pull-модель, формат метрик, labels, работа с exporters.
remote_write: насколько просто отправлять метрики в центр/хранилище.Service discovery: как находить targets в динамических средах.
Операционная простота: установка, обновления,
systemd, дебаг.Надёжность: поведение при обрывах сети, очереди, backpressure.
Типовые сценарии: одна VDS, парк серверов, несколько площадок, гибрид.
node_exporter: лучший «датчик» хоста, но не транспорт
node_exporter — по-прежнему стандарт де-факто для метрик Linux-хоста: нагрузка CPU, память, файловые системы, сеть, давление на ресурсы (PSI — если поддерживается ядром и включены нужные коллекторы) и много других сигналов.
Плюсы node_exporter
Минимум движущихся частей: один бинарник, одна задача — отдать метрики по HTTP.
Прозрачность: метрики легко проверить локально; ошибки обычно сводятся к правам, фильтрам ФС и включённым коллекторам.
Экосистема: готовые дашборды/алерты и привычные имена метрик.
Отличная связка с pull: Prometheus управляет частотой scrape и таймаутами.
Минусы node_exporter
Не умеет
remote_write: сам по себе не «доставляет» метрики в центр.Service discovery не его задача: это endpoint, а не управляющий компонент.
Только хост: метрики приложений потребуют дополнительных exporters или другого агента.
Типовая схема
Классика: на каждом сервере работает node_exporter, центральный Prometheus забирает метрики по pull. Если центральному Prometheus «не дотянуться» из-за NAT/изоляции, поверх добавляют компонент, который делает локальный scrape и отправляет данные наружу — и вот здесь появляется Alloy или другой агент с remote_write.
node_exporter отвечает на вопрос «что происходит с сервером», но почти никогда не отвечает на вопрос «как надёжно доставить метрики в централизованное хранилище».
Grafana Alloy (ex Agent): локальный scrape + remote_write и унификация
Если вам нужен «Prometheus agent» в практическом смысле — то есть локально собирать метрики с /metrics (включая node_exporter и exporters приложений) и отправлять их дальше по remote_write — Alloy закрывает эту задачу напрямую.
В эксплуатации это обычно выглядит так: на каждой машине Alloy делает scrape локальных endpoints, применяет relabel/фильтры, буферизует при проблемах сети и отправляет в централизованный backend (Prometheus-совместимое хранилище, агрегатор или кластер метрик).
Плюсы Alloy
remote_write«из коробки»: одна из главных причин ставить Alloy рядом с exporters.Единая точка сбора: можно собирать и
node_exporter, и exporters сервисов, и кастомные/metricsприложений.Гибкий relabeling: удобно нормализовать labels до отправки в центр (особенно если в центре строгие правила кардинальности).
Лучше подходит для «удалённых» хостов: когда центральный pull неудобен (нет входящих соединений, разные сегменты сети).
Минусы и подводные камни
Сложнее, чем node_exporter: появляется конфигурация scrape/relabel/очередей
remote_write, и больше мест для ошибки.Нужна дисциплина по labels: агенту легко «собрать всё подряд», а хранилищу потом тяжело переварить кардинальность.
Миграции и режимы: если вы исторически использовали Grafana Agent, при переходе на Alloy возможна переработка конфигов и подхода.
Минимальные практики, чтобы Alloy не «стрелял в ногу»
Фиксируйте базовые labels (например,
instance,job, окружение) и сразу режьте динамические значения, которые приводят к взрывному росту рядов.Мониторьте очередь и ошибки отправки (метрики самого агента), иначе «тихие» потери при сетевых проблемах обнаружатся слишком поздно.
Разделяйте ответственность: где возможно, оставляйте exporters простыми, а нормализацию делайте в одном месте (агент/центр), чтобы поведение было предсказуемым.
Если вы строите мониторинг для парка серверов на VDS, Alloy часто становится тем самым «локальным сборщиком», который упрощает сетевую политику: наружу ходит только агент, а не центральный Prometheus «везде внутрь».
Telegraf: когда нужно собрать метрики «со всего подряд»
Telegraf не является «Prometheus-native» по философии, но он остаётся сильнейшим вариантом, когда источники метрик нестандартные или Prometheus exporters отсутствуют или неудобны. Его ценность — в огромном каталоге input/output плагинов.
Плюсы Telegraf
Очень много input-плагинов: от системных метрик и процессов до баз, брокеров, SNMP и специфичных демонов.
Гибкие output: можно отправлять данные в разные системы наблюдаемости, а не только в Prometheus-стек.
Удобен в «зоопарке»: когда в инфраструктуре есть legacy, железки, нестандартные протоколы и «сервисы без /metrics».
Минусы в Prometheus-сценарии
Семантика метрик может отличаться: имена/лейблы/единицы измерения не всегда совпадают с ожиданиями Prometheus-экосистемы, поэтому готовые дашборды и алерты часто требуют адаптации.
Лишнее звено, если всё уже на exporters: когда весь стек уже «говорит» на Prometheus, Telegraf может быть избыточным.
Риски кардинальности через теги: любые «динамические» теги легко раздувают число временных рядов.
Service discovery: кто и как «находит» targets
Service discovery критичен там, где targets часто появляются и исчезают: контейнеры, автоскейлинг, ephemeral окружения. Разница по ролям тут принципиальная:
node_exporter ничего «не находит» — это просто endpoint. Discovery делает Prometheus (центральный) или агент рядом.
Alloy может выполнять роль локального Prometheus-agent: находить targets (в зависимости от выбранных механизмов discovery) и отправлять результат по
remote_write.Telegraf чаще живёт в модели «явно перечисли, что опрашивать», хотя автодискавери тоже возможен через плагины и шаблоны.
Если у вас статичный парк серверов — достаточно статических targets. Но если у вас Docker или Kubernetes и частые изменения, зрелый discovery на стороне Prometheus или Alloy обычно экономит много времени и ошибок.
remote_write: когда pull не работает или неудобен
Pull-модель Prometheus идеальна в «плоской» сети, где центральный сервер может ходить на все /metrics. На практике часто мешают:
нет входящих соединений на хосты (NAT, закрытые подсети);
много площадок и регионов;
требование централизовать хранение и доступ;
желание упростить firewall-политику.
В этих сценариях remote_write становится основным транспортом. Тогда расклад простой:
node_exporter не умеет
remote_writeи сам проблему не решает.Alloy — один из самых прямых путей «scrape локально → remote_write в центр».
Telegraf тоже умеет «отправлять дальше», но это может быть другой формат и модель; для Prometheus-стека чаще выбирают путь, максимально близкий к Prometheus.
Если вы дополнительно контролируете доступ к endpoints и панелям мониторинга, часто имеет смысл не забывать про TLS на внешних компонентах и управляемую ротацию сертификатов. Для этого в периметре, где метрики и UI доступны из разных сегментов, могут пригодиться SSL-сертификаты.
systemd и эксплуатация: что проще поддерживать
Операционная простота обычно важнее списка фич: обновить, перезапустить, понять, почему появилась «дыра» в метриках.
node_exporter + systemd
Как правило, это самый простой юнит: один процесс, минимум настроек. Частые проблемы — доступ к отдельным коллекторам, исключения файловых систем и привязка к listen-адресу или порту.
Alloy + systemd
Сложность выше: конфиг, контроль ресурсов, понимание очередей remote_write и поведения при деградации сети. Зато в обмен вы получаете «локальный мозг»: один агент может собрать несколько exporters и /metrics приложений, унифицировать labels и отправить всё в один backend.
Telegraf + systemd
Telegraf обычно стабилен, но конфиги часто «распухают» из-за плагинов. Поддержка множества input’ов — это регулярная работа: обновления, изменения схем метрик, контроль тегов и частот.
Если нужна минимальная сложность — начинайте с node_exporter. Если нужна доставка и унификация — чаще всего уместен Alloy. Если важны интеграции «со всем на свете» — Telegraf часто выигрывает по времени внедрения.
Практические сценарии выбора
Сценарий 1: один сервер или небольшой проект
Если у вас 1–3 сервера и нужна базовая наблюдаемость по хосту, самый быстрый путь — node_exporter + Prometheus (на отдельной машине или на том же хосте).
Alloy имеет смысл добавлять, когда появляется необходимость отправлять метрики в центр по remote_write или когда вы хотите «собрать всё локально» (несколько endpoints на машине) и централизованно нормализовать labels.
Сценарий 2: много VDS, разные сети, нет входящих на хосты
Здесь часто побеждает модель: локальный агент на каждом хосте (Alloy) делает scrape node_exporter и других exporters, а затем отправляет метрики в центр по remote_write.
Если вы поднимаете мониторинг на небольших серверах, полезно держать отдельный чек-лист по настройке и отладке метрик и алертов: Zabbix и Prometheus на небольшой VDS: настройки и подводные камни.
Сценарий 3: нужны метрики не только Linux и приложений, но и «всего остального»
Когда в контуре есть SNMP-устройства, специфические сервисы, legacy middleware или источники, где нет зрелых exporters, Telegraf часто становится «клеем».
Практичный компромисс: хостовые метрики — через node_exporter (как стандарт), нестандартные источники — через Telegraf, а дальше приводите всё к правилам (labels, частоты, агрегации) на стороне хранилища и дашбордов.
Риски и типичные ошибки при внедрении
Кардинальность: динамические labels (например,
user_id, URL с параметрами,request_id) быстро убивают хранилище. Лучше резать и нормализовать на этапе агента (relabel/filters) или ещё раньше — в приложении.Слишком частый scrape: повышает нагрузку и шум. Для хоста часто достаточно 15–30 секунд; для некоторых сервисов — 10–15 секунд, но это зависит от SLO и цены метрик.
«Один агент на всё» без границ: иногда проще оставить node_exporter как базу, а остальное собирать отдельными exporters. Чем больше монолитный агент, тем выше цена ошибки конфигурации.
Нет мониторинга самого мониторинга: агент должен отдавать метрики о своём состоянии (ошибки scrape, ошибки отправки, очереди
remote_write), иначе деградация будет незаметной.
Короткий вывод: что выбрать в 2025
Нужны системные метрики хоста — ставьте node_exporter почти всегда.
Нужен агент, который собирает локально и отправляет в центр по
remote_write— выбирайте Grafana Alloy (а Grafana Agent — там, где он уже внедрён и вы не готовы мигрировать прямо сейчас).Нужны интеграции с нестандартными источниками — Telegraf часто самый быстрый путь, но закладывайте время на нормализацию метрик под Prometheus-экосистему.
В проде чаще всего хорошо работает комбинация: node_exporter на каждом хосте (как базовый датчик) + Alloy как транспорт и агрегация через remote_write (когда pull неудобен). Telegraf добавляйте точечно — там, где он реально экономит недели интеграций.
Если вы строите алерты, которые зависят от дисков и квот, полезно заранее продумать пороги и источники данных: алерты по квотам и заполнению диска для ext4 и xfs.
