МДК.02.02 «Сетевое администрирование»

ЛЕКЦИЯ

Инструменты мониторинга: встроенные средства операционных систем, агенты мониторинга, интеграция с централизованными системами

Специальность 09.02.06 «Сетевое и системное администрирование»

Объём: 2 академических часа (90 минут)

Примечание об оформлении

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

План чтения лекции (90 минут)

1. Введение: зачем нужен мониторинг

1.1. Мониторинг и диагностика: в чём разница

Диагностика отвечает на вопрос «почему сломалось?» — её запускают, когда проблема уже есть. Мониторинг отвечает на вопрос «что происходит?» — он работает постоянно и предупреждает заранее. Администратор, у которого есть мониторинг, узнаёт об отказе из оповещения системы; администратор без мониторинга узнаёт об отказе из жалобы пользователя — и обычно на 20–40 минут позже.

Мониторинг решает четыре задачи:

• заметить проблему раньше пользователя — администратор должен узнать об отказе из системы мониторинга, а не из звонка;
• иметь историю — график загрузки процессора за неделю отвечает на вопрос «система всегда тормозила или начала тормозить вчера?»;
• планировать ресурсы — если диск заполнен на 90 % и растёт на 2 % в неделю, у администратора есть время на плановую закупку, а не на аварийное спасение;
• обосновывать SLA — доступность «99,9 %» не является обещанием, а является измеренным фактом, который доказывают данными мониторинга.

Полный цикл мониторинга выглядит так: наблюдение → обнаружение (порог сработал) → реакция (оповещение и действия) → анализ (почему произошло) → профилактика (чтобы не повторилось). Каждый разрыв в этом цикле означает длительный простой: нет наблюдения — проблема не видна; нет обнаружения — нет оповещения; нет анализа — авария повторится.

1.2. Три уровня инструментов мониторинга

Всё многообразие инструментов мониторинга удобно рассматривать как три уровня. Первый — встроенные средства ОС: то, что есть «из коробки», чтобы взглянуть на систему здесь и сейчас. Второй — агенты мониторинга: программы-сборщики, устанавливаемые на наблюдаемую машину, чтобы забирать с неё подробные метрики. Третий — централизованные системы: серверы, которые собирают данные с сотен узлов, хранят историю, рисуют графики и рассылают оповещения.

Ключевая идея: эти уровни не конкурируют, а дополняют друг друга. Встроенные средства — это «фонарик», агенты — «датчики», централизованная система — «пульт охраны».

Рис. 1. Три уровня инструментов мониторинга

2. Встроенные средства операционных систем

2.1. Для чего они годятся и для чего нет

Встроенные инструменты отвечают на вопросы «что происходит прямо сейчас?» и «что происходило за последний час?». Они идеальны для оперативной диагностики: завис сервис, «пропал интернет», «тормозит компьютер». Но у них есть фундаментальное ограничение: они не накапливают долгую историю и не предупреждают — пока администратор сам не смотрит в окно, данные не записываются, а оповещений не приходит. Поэтому встроенные средства выступают инструментом первого касания, а хранение истории отдают централизованным системам. Исключения, которые всё же умеют в историю, — perfmon с настроенным набором сборщиков в Windows и пакет sysstat (sar) в Linux.

2.2. Встроенные средства Windows 10/11

2.2.1. Диспетчер задач

Первый инструмент любого администратора (Ctrl+Shift+Esc). Вкладка «Производительность» показывает загрузку CPU, памяти, диска и сетевых адаптеров в реальном времени; вкладка «Процессы» — кто именно потребляет ресурсы. Полезные приёмы: сортировка процессов по столбцам «Сеть» и «Диск» мгновенно выделяет «виновника»; график сетевого адаптера показывает фактическую пропускную способность — это первое, куда смотреть при жалобе «сеть тормозит»; во вкладке «Автозагрузка» видно, что стартует вместе с системой — частая причина медленной загрузки ПК.

2.2.2. Монитор ресурсов

Запуск: Win+R → resmon. Это «Диспетчер задач на стероидах». Вкладка «Сеть» показывает по каждому процессу скорость передачи и список сетевых соединений с адресами и портами — именно здесь быстро находится процесс, который «съедает канал». Вкладка «Диск» показывает очередь запросов и время отклика диска; вкладка «ЦП» — удобное дерево потоков. Для администратора важна привычка: сначала Диспетчер задач (общая картина), потом Монитор ресурсов (детали по процессу).

2.2.3. Монитор производительности (perfmon)

Запуск: perfmon /res или perfmon. Накопитель метрик со счётчиками производительности (Performance Counters). Позволяет настроить сбор конкретных счётчиков в журнал и просматривать график за длительный период. Типовые счётчики, которые стоит знать наизусть:

\\PhysicalDisk(_Total)\% Idle Time          — простой диска (меньше 20 % — диск занят)
\\PhysicalDisk(_Total)\Avg. Disk Queue Length — очередь запросов к диску
\\Memory\\Available MBytes                  — свободная память, МБ
\\Network Interface(*)\\Bytes Total/sec     — суммарный трафик интерфейса
\\Processor(_Total)\\% Processor Time       — загрузка CPU

Нюанс: на русскоязычной системе имена счётчиков локализованы («Физический диск», «Память»), на английской — как в списке выше. Счётчики — основа агентной модели Windows: почти всё, что умеет perfmon, могут читать и внешние системы мониторинга.

2.2.4. PowerShell

Командная сборка тех же метрик — удобна для скриптов и проверки «руками»:

Get-NetAdapterStatistics              # байты, пакеты, ошибки, дропы
Get-Counter '\Network Interface(*)\Bytes Total/sec'
Test-Connection ya.ru -Count 4        # RTT и потери
netstat -ano                          # соединения и порты с PID процессов
Get-Process | Sort-Object CPU -Descending | Select-Object -First 5
Get-Service | Where-Object Status -ne 'Running'

2.2.5. Просмотр событий

Запуск: eventvwr.msc. Журналы ОС: System (сбои служб и устройств), Application (ошибки программ), Security (входы и аудит). Централизованные системы мониторинга умеют забирать отсюда конкретные события по номеру (Event ID). Стоит запомнить:

• 41 (Kernel-Power) — внезапная перезагрузка, обычно по питанию (без записи «чистого» завершения перед ней);
• 6008 — незапланированное выключение системы;
• 7031 и 7034 — аварийное завершение службы (какой именно — в тексте события);
• 4227 (TCP/IP) — исчерпание динамических портов: классическая причина «сеть периодически отваливается» на нагруженных серверах.

2.3. Встроенные средства Linux

2.3.1. top и htop

top — стандартный монитор процессов, есть в каждом дистрибутиве. Главная строка — load average: средняя нагрузка за 1, 5 и 15 минут. Правило-ориентир: нагрузка, равная числу ядер CPU, — предел нормы; load 8 на четырёхъядерной машине означает очередь задач. htop (нужно установить) удобнее: цветной интерфейс, дерево процессов (F5), сортировка (F6), завершение процесса (F9), мышь. При диагностике обращайте внимание на строку wa (iowait) в top: высокий iowait означает, что процессы ждут диск.

2.3.2. Память и диски

free -h        # доступная память (смотреть строку available, не free!)
df -h          # заполнение файловых систем
du -sh /var/log/* | sort -h | tail   # кто съел место на диске
vmstat 2 5     # CPU, память, swap и ввод-вывод в динамике
iostat -x 2 3  # очереди и утилизация дисков

Классическая ошибка новичка — пугаться строки free в выводе free: Linux отдаёт незанятую память под кэш, и она мгновенно вернётся приложениям. Реально смотреть available: если она близка к нулю — памяти действительно не хватает.

2.3.3. Сеть

ip -s link show ens33    # счётчики интерфейса: errors, dropped, overrun
ss -s                    # сводка соединений
ss -t                    # TCP-соединения
sar -n DEV 1 5           # трафик интерфейсов, 5 отсчётов с шагом 1 с
sar -n DEV -f /var/log/sysstat/sa29   # история за 29-е число

2.3.4. Журналы

journalctl -xe                      # последние события с пояснениями
journalctl -u nginx.service         # журнал конкретной службы
journalctl --since "1 hour ago" -p err   # ошибки за последний час
dmesg | tail -30                    # сообщения ядра

Важная деталь: sar из пакета sysstat — это встроенный механизм с элементами накопления. При установленной службе сбора он пишет статистику в файлы /var/log/sysstat/ и позволяет смотреть нагрузку за прошлые дни. Это редкий случай, когда встроенное средство умеет в историю.

2.4. Таблица соответствия «Windows ↔ Linux»

2.5. Практический сценарий: «тормозит 1С»

Типовая жалоба пользователя. Алгоритм действий администратора на Windows:

1. Диспетчер задач: кто грузит процессор, диск, сеть? Сортировка по столбцам.
2. resmon: очередь диска и время его отклика; какой процесс читает/пишет.
3. Если «виновник» не найден — perfmon: счётчики за день, когда началось замедление (сопоставляем с началом рабочего дня, бэкапом, обновлением).
4. eventvwr: ошибки в момент начала торможения (сбой службы, отказ диска).

В Linux последовательность та же другими инструментами: top (кто грузит) → iostat -x и vmstat (диск и ввод-вывод) → sar с историей за прошлые дни → journalctl (ошибки в момент сбоя).

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

Демонстрационные материалы к разделам 1–2

— Монитор ресурсов Windows (remontka.pro, VK Видео) — обзор resmon: вкладки ЦП, память, диск, сеть.

— Используем монитор ресурсов Windows (remontka.pro, статья) — текстовая версия с примерами экранов.

— top vs htop: в чём разница (Linux Handbook, статья) — сравнение мониторов, горячие клавиши.

3. Агенты мониторинга

3.1. Что такое агент

Агент — небольшая служба, устанавливаемая на наблюдаемую систему. Она по расписанию собирает метрики (CPU, память, диски, службы, логи, пользовательские проверки) и отдаёт их серверу мониторинга — по запросу сервера или сама, по своей инициативе.

Чем агент лучше опроса «снаружи» (например, обычного ICMP-пинга по сети):

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

Активные и пассивные проверки: активный агент сам подключается к серверу и отправляет данные (удобно, когда узел за NAT или брандмауэром — сервер может не видеть агента, а агент сервер — видит); пассивный агент ждёт запроса сервера (проще контролировать со стороны сервера). В Zabbix агент умеет оба режима одновременно.

3.2. Push и Pull: два способа доставки метрик

Все способы сбора данных делятся на две модели. В pull-модели сервер сам опрашивает узлы (Zabbix-сервер опрашивает агента, Prometheus опрашивает экспортеры). В push-модели источник сам отправляет данные (активный агент, SNMP trap, Telegraf). У каждой модели свои сильные стороны:

3.3. Zabbix Agent 2

Классика учебного курса. Агент открывает порт 10050 (пассивные проверки), сервер обращается к нему за метриками; в активном режиме агент сам шлёт данные на сервер (порт 10051). Agent 2 написан на Go, имеет модульную архитектуру и встроенные плагины (Docker, PostgreSQL, MySQL). Установка на Ubuntu:

sudo apt install zabbix-agent2
sudo systemctl enable --now zabbix-agent2

Основные параметры конфигурации /etc/zabbix/zabbix_agent2.conf:

Server=192.168.1.10        # пассивные проверки: кто может опрашивать
ServerActive=192.168.1.10  # активные проверки: куда отправлять
Hostname=srv1              # имя узла, зарегистрированное на сервере

Ключевые пользовательские элементы данных — через ключи:

system.cpu.util            # загрузка CPU, %
vm.memory.size[pavailable] # доступная память, %
vfs.fs.size[/,pfree]       # свободное место на диске, %
net.if.in[ens33]           # входящий трафик интерфейса, байт/с
proc.num[nginx]            # число процессов nginx

Сильная сторона агента — пользовательские проверки (UserParameter): администратор описывает свою метрику одной строкой в конфигурации, и сервер начинает её собирать:

UserParameter=custom.backup.status, cat /var/log/backup/last.status

После этой строки элемент данных custom.backup.status возвращает содержимое файла статуса резервного копирования — так мониторят то, о чём разработчик Zabbix знать не мог.

Специфика Windows: многие метрики агентам доступны через счётчики производительности (perfmon) и WMI — агент лишь «воплощает» их в элементы данных. Сам Zabbix Agent существует и для Windows и ставится как служба.

3.4. Экспортеры Prometheus

Промышленная пара Prometheus — node_exporter: экспортер слушает порт 9100 и отдаёт метрики по HTTP в формате Prometheus; сервер сам опрашивает узлы (pull-модель). Аналогично устроен windows_exporter (порт 9182) — метрики Windows-машин, и mysqld_exporter — метрики СУБД. Минимум для запуска node_exporter:

curl -LO https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-*.tar.gz
tar xzf node_exporter-*.tar.gz && cd node_exporter-*/
./node_exporter --web.listen-address=:9100
curl -s http://localhost:9100/metrics | head    # проверка: поток метрик

В боевом окружении экспортер оформляют службой systemd. Telegraf — универсальный агент-сборщик с сотнями входных плагинов: он умеет читать и счётчики Windows, и SNMP, и логи, и писать данные сразу в несколько хранилищ (Prometheus, InfluxDB).

3.5. SNMP — «агент без установки»

Большинство сетевых устройств (коммутаторы, маршрутизаторы, МФУ, ИБП, камеры) имеют встроенный SNMP-агент — на них нельзя ничего поставить, но метрики собирать можно. Сервер мониторинга опрашивает устройство по UDP/161 и получает счётчики интерфейсов, температуры, состояния питания. Версии протокола:

• SNMP v1/v2c — простые, защита — community-строка («пароль») в открытом виде; стандартное значение public менять обязательно;
• SNMP v3 — аутентификация и шифрование, обязателен там, где безопасность важна.

Метрики в SNMP адресуются числовыми идентификаторами — OID; словарь «OID → человеческое имя» называют MIB. Примеры опроса:

snmpwalk -v2c -c public 192.168.1.1 ifName       # имена интерфейсов
snmpwalk -v2c -c public 192.168.1.1 ifInOctets   # входящие байты по интерфейсам

3.6. Как выбрать способ сбора

Демонстрационные материалы к разделу 3

— Установка Zabbix Agent 6.2 на Ubuntu 22.04 (Rutube, 12+) — пошаговая установка и подключение агента к серверу.

— Zabbix с нуля #3: установка Zabbix 7.4 на Ubuntu 24.04 (Rutube) — полный стек сервера: PostgreSQL, Nginx, Agent 2.

4. Интеграция с централизованными системами

4.1. Архитектура централизованного мониторинга

Централизованная система — это сервер (или кластер), который выполняет пять функций: собирает данные (опрос по сети и через агенты); хранит метрики в базе с историей на недели и месяцы; оценивает — сравнивает значения с порогами и порождает события и триггеры; оповещает — доставляет события администратору; визуализирует — графики, дашборды, карты инфраструктуры. Типовая схема потока данных показана на рис. 2.

Рис. 2. Поток данных в централизованной системе мониторинга

4.2. Zabbix

Стандарт учебных курсов и самый распространённый open-source мониторинг в России. Компоненты: сервер Zabbix (сбор и оценка), агенты на узлах, веб-интерфейс, база данных (MySQL, PostgreSQL, TimescaleDB для больших объёмов). Zabbix proxy — промежуточный сборщик для филиалов: он собирает данные с локальных узлов и передаёт их серверу, когда прямая связь между филиалом и центром нестабильна.

Шаблоны — готовые наборы элементов данных и триггеров: подключили шаблон к узлу — и мониторинг заработал. Пример шаблона из нашей лабораторной работы № 8 — ICMP Ping: три проверки (доступность icmpping, потери icmpingloss, задержка icmppingsec) и готовый триггер «узел недоступен». Пример пользовательского триггера:

{pc1:icmppingsec.avg(5m)}>100   # средняя задержка до узла за 5 минут превысила 100 мс

4.3. Prometheus + Grafana

Современный стек: Prometheus собирает метрики pull-ом, хранит их в базе временных рядов (TSDB) и умеет вычислять выражения на языке PromQL; Grafana строит поверх дашборды. Де-факто стандарт для контейнеров и облаков. Минимальная конфигурация сбора:

scrape_configs:
 - job_name: 'linux-servers'
   static_configs:
     - targets: ['192.168.1.11:9100', '192.168.1.12:9100']

В Grafana источник данных Prometheus подключается в настройках; готовые дашборды импортируются по номеру (например, Node Exporter Full, ID 1860). Оповещения в этом стеке выносит отдельный компонент — Alertmanager: он группирует, глушит (silence) и маршрутизирует алерты. В 2025 году в Prometheus добавлен прямой режим отбора метрик из Zabbix — возможны гибридные схемы.

4.4. Nagios/Icinga и коммерческие решения

Nagios — исторический «дедушка» мониторинга: проверяет состояния по расписанию через плагины, гибкая система расширений. Icinga — его современный преемник. Часто встречается в компаниях, поддерживающих старую инфраструктуру. PRTG и облачные решения — коммерческий сегмент: студент должен понимать, что интерфейсы меняются, а принципы (метрика — порог — триггер — оповещение) — неизменны.

4.5. Сравнение централизованных систем

4.6. Протоколы интеграции: чем агент «говорит» с сервером

Принцип выбора: нет «лучшего протокола» — есть подходящий к типу узла. Коммутатор мониторится по SNMP, потому что на него не поставить агент; Windows-машина — агентом, потому что SNMP не увидит состояние службы; передача в syslog идёт сама, без опроса.

4.7. Пороги, триггеры, эскалации

Язык централизованных систем (рис. 3):

• элемент данных (item) — единица метрики: «загрузка CPU», «ping узла, мс»;
• порог (threshold) — граница нормы: «CPU > 90 %», «потери пакетов > 2 %»;
• триггер — правило, срабатывающее при нарушении порога: {узел:system.cpu.util.avg(5m)}>90;
• оповещение (alert) — доставка события администратору по каналу;
• эскалация — если через 30 минут событие не закрыто, уведомляется следующий уровень: старший администратор или дежурная смена.

Рис. 3. Цепочка реакции системы мониторинга

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

• усреднение по времени: триггер на avg(5m), а не на last() — разовый скачок не породит алерт;
• уровни важности: информация, предупреждение, средняя, высокая, чрезвычайная — не всё должно будить дежурного ночью;
• интервал повторного уведомления и «залечивание» (recovery): алерт должен и закрываться сам, когда показатель вернулся в норму.

4.8. Сквозной кейс

Учебная сеть: сервер srv1 (Linux), рабочая станция pc1 (Windows), коммутатор sw1. Полный цикл настройки:

5. На srv1 установлен Zabbix Agent 2, созданы элементы данных по ключам из раздела 3.3; сервер опрашивает агент по порту 10050.
6. pc1 мониторится без агента: шаблон ICMP Ping — доступность, потери, RTT (тот же приём, что в лабораторной работе № 8).
7. sw1 мониторится по SNMP v2c: трафик портов и число ошибок на интерфейсах.
8. Триггеры: «pc1 недоступен 3 минуты» → оповещение в Telegram; «srv1: корневой раздел заполнен на 90 %» → оповещение и эскалация через час.
9. Когда алерт сработал, администратор разбирается встроенными средствами: resmon на pc1, sar на srv1 — то есть второй уровень помогает третьему.

Этот кейс показывает полный цикл: сбор — транспорт — хранение — пороги — оповещение — диагностика.

Демонстрационные материалы к разделу 4

— Linux: настройка мониторинга за 15 минут с Grafana и Prometheus (VK Видео) — связка Prometheus + node_exporter + Grafana от нуля.

— Grafana + Prometheus за 5 минут (Rutube, DevOps & DIY) — развёртывание стека скриптом, обзор метрик и дашбордов.

— Курс Zabbix: установка Zabbix 7.2 на Ubuntu 24.04 (Rutube) — академичный курс: три варианта установки, конфигурация Nginx.

— Настройка SNMPv3 в Zabbix 7 (Rutube, LinuxHELP) — аутентификация и шифрование SNMP, работа со snmpwalk и шаблонами.

— Мониторинг MikroTik через SNMP в Zabbix (Rutube) — метрики устройства и карта сети с связями.

— Zabbix: проверка доступности ICMP Ping (Rutube) — безагентный контроль узла, знакомый по ЛР № 8.

5. Выводы лекции

10. Мониторинг строится из трёх уровней: встроенные средства ОС — для оперативной диагностики «здесь и сейчас»; агенты — для глубокого сбора метрик с узла; централизованные системы — для истории, порогов и оповещений на весь парк машин.
11. Встроенные средства Windows (Диспетчер задач, resmon, perfmon, eventvwr, PowerShell) и Linux (top, ip -s, ss, sar, journalctl) дают одну и ту же информацию разными способами — грамотный администратор владеет обеими ветками.
12. Агент отличается от внешнего опроса глубиной (видит внутреннее состояние узла) и надёжностью (позволяет отличить «отказ узла» от «отказа сети»).
13. Способ доставки метрик выбирают по топологии: за NAT работает push (активный агент), в открытой сети уместен pull (экспортеры Prometheus).
14. Протоколы интеграции подбираются по типу узла: SNMP — для сетевого оборудования, агенты — для серверов, ICMP — для базовой проверки доступности, IPMI — для аппаратных датчиков.
15. Язык централизованных систем — «метрика → порог → триггер → оповещение → эскалация». Настройка порогов — это баланс: грубые пороги пропускают аварии, чувствительные «замыливают» внимание дежурных.

6. Контрольные вопросы

16. Назовите три уровня инструментов мониторинга и главную функцию каждого.
17. Чем мониторинг отличается от диагностики? Кто раньше узнает об отказе — администратор с мониторингом или без него?
18. Чем Монитор ресурсов (resmon) отличается от Диспетчера задач? В какой ситуации resmon незаменим?
19. Почему данные sar доступны за прошлые дни, а большинство встроенных инструментов этого не умеют? Какое исключение есть в Windows?
20. Что означает строка available в выводе free и почему не следует пугаться маленького значения free?
21. Что такое агент мониторинга? Приведите два преимущества агента перед внешним опросом по сети.
22. Чем активная проверка агента отличается от пассивной? Какая удобнее, когда узел находится за NAT?
23. По каким портам работает Zabbix Agent 2? Почему коммутатор обычно мониторят без агента?
24. Чем отличается SNMP v2c от SNMP v3? Зачем менять стандартную community-строку?
25. Перечислите звенья цепочки «метрика → … → оповещение» и объясните, что такое эскалация.
26. Что такое «дребезг оповещений» и какими тремя приёмами его снижают?
27. Какие номера событий в журнале System указывают на внезапную перезагрузку и на сбой службы?

7. Рекомендуемые источники

— Документация Zabbix (на русском) — концепции, агенты, шаблоны, триггеры.

— Документация Prometheus — экспортеры, конфигурация, PromQL.

— Документация Grafana — источники данных, дашборды, оповещения.

— Введение в мониторинг серверов с Prometheus и Grafana (Хабр) — практический обзор стека.

— Что такое SLA, и сколько стоит девятка в аптайме (Хабр) — как мониторинг связан с SLA и доступностью.