cAdvisor vs node_exporter vs Netdata в 2026: что выбрать для метрик и мониторинга Linux и Docker

Если вы строите мониторинг вокруг метрик и Prometheus, выбор агента почти всегда сводится к простому вопросу: «Мне нужны метрики хоста, контейнеров или быстрый интерактивный обзор прямо сейчас?». В 2026 году связка cAdvisor, node_exporter и Netdata всё ещё встречается чаще всего, но эти инструменты закрывают разные уровни и редко взаимозаменяемы.

Ниже — практичное сравнение: что именно измеряет каждый агент, как он “видит” Docker, где пригодится PromQL, какие подводные камни есть на Linux (cgroups v2, rootless-контейнеры, overlay/volumes, кардинальность), и как собрать из этого устойчивую схему под реальные требования.

Коротко: что делает каждый инструмент

cAdvisor — источник метрик уровня контейнеров. Он читает cgroups и данные контейнерного runtime и отдаёт метрики по HTTP в формате Prometheus. Ценность cAdvisor — детализация по контейнерам: CPU/память/сеть/FS, часто с разрезом по интерфейсам и устройствам.

node_exporter — источник метрик уровня Linux-хоста. Он не про контейнеры, а про сервер: CPU, load, RAM, swap, файловые системы, диски, сеть, системные счётчики ядра. Это база для алертов «сервер умирает» и для SLO на уровне узла.

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

Практическое правило: node_exporter отвечает на вопрос «что с Linux-хостом», cAdvisor — «что с контейнерами», Netdata — «почему именно сейчас всё стало плохо».

Сравнение по задачам: какой результат вам нужен

1) Алерты и SLO на уровне сервера (Linux monitoring)

Если цель — стабильный и предсказуемый мониторинг Linux (место на диске, inode, iowait, сетевые ошибки, давление памяти), node_exporter почти всегда основной источник метрик.

Сильные стороны node_exporter:

• минимум магии и «внезапных» лейблов;
• много готовых правил алертов и дашбордов;
• низкие накладные расходы;
• удобно писать алерты и SLO через PromQL.

Ограничения:

• контейнеры видны только косвенно (через суммарные ресурсы хоста);
• прикладные метрики требуют отдельных экспортеров (например, для веб-сервера или СУБД).

2) Наблюдаемость контейнеров (Docker metrics): кто съел CPU и память

Когда боль в том, что «всё в контейнерах» и нужно видеть расход ресурсов по каждому контейнеру, cAdvisor обычно ставят рядом с runtime и подключают к Prometheus отдельным target.

Сильные стороны cAdvisor:

• фокус на container-level метриках и cgroups;
• высокая детализация по контейнерам;
• удобная база для алертов вида «контейнер X ушёл в лимит»;
• в большинстве окружений быстро даёт пользу без долгой настройки.

Ограничения и нюансы:

• метрики хоста покрывает хуже (и это нормально — не его задача);
• в связках runtime + cgroups v2 возможны отличия в путях cgroup и именах контейнеров;
• часть метрик по файловым системам требует осторожной интерпретации в overlay/volume сценариях.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

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

3) Быстрая диагностика инцидента: «что происходит прямо сейчас»

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

Сильные стороны Netdata:

• очень быстрый time-to-value: поставили — и уже есть графики;
• автообнаружение сервисов и контейнеров в типичных окружениях;
• подходит для первичного RCA, когда нужно за 5–15 минут понять направление поиска.

Ограничения:

• для крупных установок важно заранее продумать, где хранить историю (иначе локальная ретенция быстро станет узким местом);
• как «основной» источник метрик под PromQL-алерты его используют реже, чем связку Prometheus + экспортеры;
• компонентов и настроек обычно больше, чем у node_exporter.

Матрица выбора (2026): кто выигрывает в каком сценарии

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

• Нужны базовые метрики Linux + надёжные алерты через PromQL → node_exporter.
• Нужны Docker metrics по каждому контейнеру → cAdvisor (обычно в паре с node_exporter).
• Нужна визуальная диагностика и корреляции без долгой настройки → Netdata (как дополнительный слой).
• Один сервер, мало времени, «поставил и смотришь» → Netdata; но сразу подумайте о ретенции и месте под историю.
• Много серверов, стандартизированный стек, IaC, строгие алерты → node_exporter + cAdvisor + Prometheus/Grafana (Netdata точечно).

Как метрики будут выглядеть в Prometheus и как жить с PromQL

Выбор агента определяет не только набор метрик, но и «модель» лейблов, стабильность временных рядов и сложность алертов. Это особенно заметно на контейнерных метриках.

node_exporter: предсказуемые имена и минимальная кардинальность

У node_exporter метрики обычно стабильны и узнаваемы: node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_filesystem_avail_bytes, node_disk_io_time_seconds_total. Для linux monitoring это «классика»: легко найти готовые правила и сопоставить их с тем, что вы видите на хосте.

Типичные PromQL-паттерны (на уровне идеи):

• CPU busy по хосту: агрегация по ядрам с исключением mode="idle";
• диск почти заполнен: отношение avail к size с фильтрацией по fstype;
• сеть: rate ошибок/дропов по интерфейсу;
• IO saturation: производные метрик времени занятости устройства и очереди.

cAdvisor: контейнерные лейблы — это сила и боль одновременно

cAdvisor даёт контейнерные метрики с лейблами контейнера и образа, иногда с метками окружения (например, если runtime прокидывает labels). В PromQL вы почти всегда будете группировать по «идентификатору контейнера» и фильтровать лишнее (служебные, pause, короткоживущие).

На что смотреть в 2026 году:

• Стабильность идентификатора. Имена контейнеров меняются при пересоздании, поэтому для алертов и дашбордов лучше опираться на устойчивые labels (например, service/role/env), которые вы задаёте сами.
• Кардинальность. Чем больше контейнеров и чем чаще они пересоздаются, тем больше временных рядов в Prometheus, и тем дороже хранение/запросы.
• CPU «в секундах». Как правило, используют rate по container_cpu_usage_seconds_total и трактуют результат как «ядра» по смыслу, а затем сравнивают с лимитами.

Если вы строите централизованный мониторинг на отдельной машине/инстансе, полезно заранее понять, выдержит ли хранилище вашу кардинальность. В этом контексте пригодится отдельная статья про развёртывание хранилища метрик на сервере: VictoriaMetrics на одном узле для метрик и алертов.

Netdata: «живьём» смотреть удобно, стратегию экспорта продумайте заранее

Netdata умеет экспортировать метрики наружу, но в реальных схемах важно определиться с ролью: вы хотите Netdata как основной источник метрик для Prometheus или как автономный слой диагностики на ноде.

Если у вас уже есть Prometheus-экосистема, часто выигрывает схема:

• node_exporter и cAdvisor — «канонические» источники метрик под PromQL и алертинг;
• Netdata — инструмент для быстрого RCA и просмотра корреляций на проблемной ноде.

Так вы не смешиваете разные модели метрик и держите алерты на предсказуемых сериях.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Если мониторинг нужен для небольшого проекта без сложной инфраструктуры, иногда логично начать с базового виртуального хостинга, а метрики и алерты вынести во внешнюю систему. Для контейнерных платформ и Prometheus-стека чаще удобнее отдельный сервер под мониторинг.

Docker metrics на практике: почему часто ставят и cAdvisor, и node_exporter

Типовая ошибка — пытаться заменить node_exporter cAdvisor-ом или наоборот. На реальном проде эти инструменты закрывают разные уровни наблюдаемости.

Что вы не получите из cAdvisor (или получите хуже)

Даже если cAdvisor показывает CPU/память «в целом», для мониторинга Linux обычно нужны метрики:

• inode и детали по файловым системам хоста (отдельно от overlay контейнеров);
• детальная телеметрия дисков и блочных устройств (насыщение, ошибки);
• сетевые ошибки на уровне интерфейсов и стек TCP;
• ядро/VM-метрики, включая memory pressure в зависимости от набора коллекторов и версии ядра.

Это территория node_exporter.

Что вы не получите из node_exporter

node_exporter не знает, какой контейнер создал нагрузку. Он покажет, что CPU загружен или память заканчивается, но не даст разрез «по контейнерам» без дополнительных источников.

Поэтому комбинация node_exporter + cAdvisor остаётся самой практичной для Docker-хостов, где Prometheus — источник правды.

Нюансы 2026 года: cgroups v2, rootless и кардинальность метрик

cgroups v2 и контейнерные рантаймы

cgroups v2 стал нормой во многих дистрибутивах. Это хорошо для управления ресурсами, но в мониторинге есть следствия: меняются пути cgroup, иногда отличаются детали агрегации, а «старые» дашборды могут требовать адаптации. Перед раскаткой на весь парк проверьте метрики и дашборды на вашей ОС и вашем ядре.

Rootless-контейнеры

Rootless-режим усложняет сбор container-level метрик «снаружи», потому что часть информации ограничена правами, namespaces и особенностями runtime. В таких сценариях node_exporter остаётся полезным для хоста, но для cAdvisor может потребоваться аккуратная настройка доступа к нужным путям cgroup и сокетам runtime (в зависимости от модели запуска).

Кардинальность и стоимость Prometheus

Главный операционный риск при активном сборе Docker metrics — кардинальность (количество временных рядов). На хосте, где контейнеры часто пересоздаются, вы можете получить:

• рост числа series из-за уникальных имён и ID контейнеров;
• нагрузку на Prometheus и проблемы с ретенцией;
• шумные алерты из-за «одноразовых» контейнеров.

Практика: стандартизируйте labels (service/role/env), фильтруйте лишние контейнеры, не собирайте «всё подряд», если это не нужно для решений и алертов.

Типовые схемы внедрения: от простого к устойчивому

Схема A: одна нода и быстрый старт

Netdata как быстрый обзор состояния. Подходит для одиночного сервера или когда мониторинг нужен «вчера», а централизованный Prometheus ещё не поднят.

Схема B: стандарт для Docker-хоста с Prometheus

node_exporter для метрик хоста + cAdvisor для метрик контейнеров. Это даёт понятные серии для PromQL и предсказуемый алертинг. Netdata можно держать опционально для оперативной диагностики.

Схема C: много нод, строгие алерты, контроль кардинальности

Централизованный сбор в Prometheus или совместимое хранилище, алерты по node_exporter/cAdvisor, отдельные решения для высококардинальных метрик при необходимости. Netdata — точечно на ключевых узлах или по требованию дежурной смены.

Если у вас контейнеры общаются с внешним миром и приходится разбирать сетевые инциденты «почему пропало», полезно держать под рукой разбор практик фильтрации и правил на Linux: Docker и firewall: iptables vs nftables без сюрпризов.

Практический чек-лист выбора

1. Стек вокруг Prometheus и PromQL? Начинайте с node_exporter, для контейнеров добавляйте cAdvisor.

2. Нужно видеть контейнеры по сервисам, а не по случайным именам? Сразу продумайте labels и правила агрегации.

3. Нужна «живая» диагностика на ноде без подготовки дашбордов? Добавьте Netdata как инструмент RCA.

4. Есть ограничения по ресурсам? node_exporter обычно самый лёгкий; cAdvisor и Netdata требуют чуть больше внимания к нагрузке.

5. Нужна история и отчёты? Делайте централизованное хранилище метрик, а локальные панели оставляйте как дополнение.

Итоги: что выбирать в 2026

Для зрелого мониторинга Linux и предсказуемого алертинга node_exporter остаётся базовым кирпичом. Для container-level наблюдаемости и Docker metrics по каждому контейнеру добавляйте cAdvisor. Для быстрых ответов «что происходит прямо сейчас» и первичного RCA на конкретной ноде Netdata отлично дополняет связку.

Главная мысль: не пытайтесь заставить один инструмент закрыть все уровни. Разделите задачи (хост, контейнеры, диагностика), и тогда метрики станут управляемой системой, где алерты и графики отвечают на конкретные вопросы, а не добавляют шум.

Если вы разворачиваете мониторинг на отдельном сервере под инфраструктуру и приложения, проще всего начать с нормальной базы: выделенный VDS под Prometheus и хранилище метрик и отдельные targets на узлах.