sar: машина времени из коробки для мониторинга системы Linux
Начнём с инструмента, который, скорее всего, уже стоит у тебя в системе и про который многие забывают. Пакет sysstat и его утилита sar - это исторические метрики прямо из коробки, без всякого облака и агентов. Фишка в том, что фоновый сборщик sadc по расписанию пишет бинарные снимки состояния системы. В современных дистрибутивах сбор запускает таймер systemd (sysstat-collect.timer), который по умолчанию срабатывает раз в 10 минут, плюс суточный sysstat-summary. Старые системы делали то же через cron. Важная деталь на 2026: путь к данным зависит от семейства дистрибутива. В Debian/Ubuntu/Astra Linux файлы лежат в /var/log/sysstat/ и называются saYYYYMMDD (или saDD), в RHEL/Fedora/RED OS - в /var/log/sa/ с именем saDD, где DD это день месяца. Запомни этот нюанс, иначе будешь искать файл не там.
Сначала поставь и включи сбор, если ещё не:
Код: Выделить всё
sudo apt install sysstat # Debian/Ubuntu/Astra Linux
sudo dnf install sysstat # RHEL/Fedora/RED OS
# включить периодический сбор (Debian-семейство)
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
# проверить, что таймер тикает
systemctl list-timers | grep sysstat
Теперь смотрим, что было. Загрузка процессора за сегодня:
Код: Выделить всё
$ sar -u
12:00:01 CPU %user %nice %system %iowait %steal %idle
12:10:01 all 8.12 0.00 3.40 12.55 0.00 75.93
12:20:01 all 7.80 0.00 3.21 41.02 0.00 47.97
Память и обмен с диском - флаг -r, дисковый ввод-вывод поблочно - -b, по устройствам с очередью и временем отклика - -d, а для мониторинга сети Linux пригодится -n DEV:
Код: Выделить всё
$ sar -n DEV
12:10:01 IFACE rxpck/s txpck/s rxkB/s txkB/s %ifutil
12:10:01 eth0 1850.4 1602.1 980.55 1420.33 11.50
А теперь главный трюк sar в Linux - чтение вчерашнего файла для разбора ночного инцидента. Допустим, упало в районе трёх ночи 12-го числа (Debian-путь):
Код: Выделить всё
$ sar -u -f /var/log/sysstat/sa12 -s 03:00:00 -e 04:00:00
# на RHEL/RED OS файл лежит в /var/log/sa/sa12
Современный стек: Prometheus, node_exporter и Grafana
sar хорош, но он живёт на одном хосте и показывает текст. Когда серверов больше одного и хочется видеть весь парк в одном месте с графиками и алертами - приходит связка Prometheus + node_exporter + Grafana. Это де-факто стандарт на 2026. Разделим роли, чтобы не путаться.
- node_exporter - маленький агент от команды Prometheus (актуальная версия линейки 1.11.x на 2026). Ставишь на хост, он слушает порт 9100 и на /metrics отдаёт несколько сотен метрик про железо и ОС: CPU, память, диски, сеть, файловые системы. Сам ничего не хранит - только отдаёт срез здесь и сейчас.
- Prometheus - сервер, который по расписанию опрашивает (scrape) эти /metrics со всех хостов и складывает в свою time-series базу (TSDB). Это хранилище истории.
- Grafana - рисовалка. Берёт данные из Prometheus и строит дашборды. Готовый дашборд Node Exporter Full (id 1860) импортируется за минуту и закрывает 90% потребностей.
Проверить агента после установки можно просто curl-ом:
Код: Выделить всё
$ curl -s localhost:9100/metrics | grep node_cpu_seconds_total
node_cpu_seconds_total{cpu="0",mode="idle"} 184320.5
node_cpu_seconds_total{cpu="0",mode="user"} 4210.8
node_cpu_seconds_total{cpu="0",mode="iowait"} 980.3
Код: Выделить всё
100 * (1 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])))
Что вообще собирать, чтобы не утонуть? Держись методики USE для каждого ресурса (CPU, память, диск, сеть):
- Utilization - насколько ресурс занят (загрузка CPU, заполненность диска, использование полосы сети).
- Saturation - есть ли очередь, насыщение (load average, длина очереди к диску, использование свопа, PSI - pressure stall information из /proc/pressure, которую node_exporter тоже отдаёт).
- Errors - счётчики ошибок (дропы пакетов, ошибки диска, OOM-килы).
Zabbix, netdata и алерты: что выбрать для мониторинга
Prometheus - не единственный путь. Zabbix - классика мониторинга серверов в наших краях, особенно в энтерпрайзе и госсекторе (и на Astra Linux он ставится штатно из репозиториев; на 2026 актуальны LTS-ветки 7.0 и выше). Архитектура другая: на хост ставится zabbix-agent2 (порт 10050), а центральный zabbix-server сам ходит к агентам и кладёт всё в SQL-базу. Из коробки идёт веб-интерфейс, готовые шаблоны Linux by Zabbix agent, встроенные триггеры и оповещения. Если нужен мониторинг Linux вместе с сетевым оборудованием по SNMP, инвентаризацией, low-level discovery и правами доступа в одной коробке - Zabbix силён. Prometheus же берёт гибкостью PromQL и pull-моделью под динамические среды (Kubernetes, автоскейлинг).
Когда нужен дашборд прямо сейчас и без возни - бери netdata. Одна команда, и через минуту на порту 19999 крутится живой дашборд с секундным разрешением, причём netdata уже умеет eBPF-плагин и сам подсвечивает аномалии:
Код: Выделить всё
$ sudo apt install netdata # или официальный установщик kickstart.sh
# открой http://IP-сервера:19999
И самое важное - алерты. Графики, на которые никто не смотрит, бесполезны. Настрой оповещения именно на насыщение и ошибки, а не на каждый чих. Базовый набор, который реально будит по делу: диск заполнен больше 90% (а лучше алертить по прогнозу - predict_linear в PromQL предскажет, что место кончится через 4 часа), node_filesystem_readonly стал 1, %iowait стабильно высокий, load average выше числа ядер, своп активно используется, растут дропы и ошибки на сетевом интерфейсе, был OOM-кил. В Prometheus за маршрутизацию, группировку и подавление дублей отвечает Alertmanager (он шлёт в Telegram, почту, PagerDuty), сами правила пишутся как PromQL-выражения с порогом. В Zabbix это триггеры и actions. Правило простое: алерт должен означать иди чини, иначе на него перестанут реагировать - это называется alert fatigue.
Типичные грабли
- Смотреть на counter как на готовое значение. node_cpu_seconds_total надо оборачивать в rate() (или irate для коротких всплесков), иначе видишь бессмысленные растущие числа.
- Думать, что node_exporter что-то хранит. Нет - он только отдаёт срез здесь и сейчас. Историю держит Prometheus.
- Путать MemFree и MemAvailable. MemFree почти всегда мал, потому что Linux занимает свободную память под кэш. Реальный показатель свободы - node_memory_MemAvailable_bytes.
- Забыть включить сбор sysstat и обнаружить пустой /var/log/sysstat именно тогда, когда история нужнее всего. И искать sa-файлы не в том каталоге (Debian против RHEL).
- Алертить на загрузку (utilization), а не на насыщение. 100% CPU при пустой очереди - это нормальная полезная работа, а вот растущая очередь (load average, PSI) - уже боль.
- Открыть node_exporter и zabbix-agent наружу в интернет без файрвола. Порты 9100 и 10050 закрывай, отдавай только своему серверу мониторинга (bind на внутренний адрес или правило nftables/iptables).
- Поставь sysstat, включи сбор, проверь systemctl list-timers | grep sysstat, подожди и выполни sar -u, sar -r, sar -n DEV. Найди в выводе %iowait и rxkB/s.
- Прочитай файл за вчера: sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d) -s 03:00:00 -e 04:00:00 (на RHEL/RED OS путь /var/log/sa). Поймёшь, как разбирать прошлый инцидент.
- Установи netdata, открой :19999 и понаблюдай метрики в реальном времени, пока в другом терминале гонишь нагрузку: dd if=/dev/zero of=/tmp/big bs=1M count=4096 oflag=direct - смотри, как взлетает iowait.
- Поставь node_exporter, проверь curl -s localhost:9100/metrics, найди node_memory_MemAvailable_bytes, node_filesystem_avail_bytes и node_filesystem_readonly. Сравни MemFree и MemAvailable - почувствуй разницу.
- Где sar хранит исторические данные (с поправкой на семейство дистрибутива) и как прочитать загрузку CPU за конкретный прошлый день и час?
- Что означает суффикс _total в имени метрики node_exporter, чем counter отличается от gauge и почему counter оборачивают в rate()?
- Чем роли node_exporter, Prometheus и Grafana отличаются друг от друга, и что такое Grafana Alloy на 2026?
- Что по методике USE важнее ставить в алерты - utilization или saturation, и почему?
Непрерывный мониторинг - это про то, чтобы знать о проблеме раньше пользователя и иметь историю для разбора. sar даёт историю из коробки на одном хосте (помни про разные пути: /var/log/sysstat в Debian/Astra и /var/log/sa в RHEL/RED OS). Prometheus + node_exporter + Grafana - стандарт для парка серверов на 2026: агент отдаёт срез, сервер хранит в TSDB, Grafana рисует; современная альтернатива агенту - Grafana Alloy на базе OpenTelemetry. Zabbix - крепкая классика с агентом и сервером, netdata - живой дашборд одной командой. Различай counter и gauge, оборачивай счётчики в rate(), смотри MemAvailable вместо MemFree. Меряй по USE, алерти на насыщение и ошибки (а не на каждую цифру) - и не утонешь в графиках.
