Zabbix: что мониторить в первую очередь для гарантированной доступности

Мониторинг инфраструктуры — это не просто сбор статистики, а способ предсказать проблемы до того, как они повлияют на бизнес-процессы. Система Zabbix обладает огромным количеством встроенных шаблонов и возможностей, но новички часто теряются, пытаясь включить сбор абсолютно всех метрик сразу. Это приводит к перегрузке базы данных, ложным срабатываниям и, как следствие, к игнорированию настоящих инцидентов.

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

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

Критическая доступность и загрузка хоста

Первым и самым очевидным показателем является сам факт жизни сервера. Если агент Zabbix перестает отвечать, вы теряете всю информацию о системе. Стандартный элемент данных zabbix[ping] или проверка доступности по ICMP — это база, но её недостаточно для полноценного контроля. Необходимо отслеживать время отклика (latency) и процент потерянных пакетов, так как рост задержек часто предшествует полному отказу сети.

Второй уровень проверки — это статус самого агента. Если процесс zabbix_agentd упал или завис, сервер может быть онлайн, но вы ничего о нем не узнаете. Ключевые метрики здесь включают agent.ping и agent.version. Отслеживание версии агента также важно для контроля актуальности ПО и выявления уязвимостей в старых сборках.

⚠️ Внимание: Настраивайте триггеры на временной лаг. Если вы получите алерт на каждую секунду потери связи, вы быстро выгорите от шума. Используйте функцию nodata() с разумным интервалом (например, 5 минут), чтобы отсечь кратковременные скачки сети.

Загрузка процессора (CPU) — это следующий критический параметр. Высокая загрузка ядра может указывать на DDoS-атаку, бесконечный цикл в коде или нехватку ресурсов. В Zabbix важно различать метрики system.cpu.util[,idle] и system.cpu.util[,system]. Низкий процент idle (простой) в сочетании с высоким system часто говорит о проблемах на уровне драйверов или ядра ОС, а не приложения.

Не забывайте также про угол загрузки (load average). Для Linux это количество процессов в очереди. Если load average превышает количество ядер процессора на протяжении длительного времени, система начинает тормозить. Здесь важно учитывать контекст: для веб-сервера кратковременный пик — норма, для базы данных — уже повод для тревоги.

Состояние оперативной памяти и своп

Нехватка оперативной памяти (RAM) — одна из самых частых причин краха критически важных сервисов. Обзор памяти должен включать не только общий доступный объем, но и детализацию по кэшам и буферам. В Linux свободная память часто используется под кэш файловых систем, поэтому низкий показатель vm.memory.available не всегда означает проблему, если кэш велик.

Гораздо опаснее использование swap-пространства. Если система начинает активно обращаться к диску для подкачки памяти, производительность падает на порядки. Своп должен использоваться крайне редко или не использоваться вовсе в продакшн-средах. Триггер на рост использования swap должен срабатывать мгновенно, так как это верный признак того, что сервер не справляется с текущей нагрузкой.

• 🔍 Отслеживайте vm.memory.utilization в процентах от общей суммы доступной памяти.
• 🛑 Настройте алерт при использовании swap более 5-10% для баз данных.
• 📉 Мониторьте page faults (сбои страниц), так как их резкий рост предвещает проблемы с памятью.

Существует нюанс, который часто упускают: утечки памяти в приложениях. Процесс может постепенно потреблять все больше RAM, не освобождая её. Динамический мониторинг потребления памяти отдельными процессами (например, Java-приложениями или базами данных) позволяет выявить такую утечку на ранней стадии. Это особенно актуально для контейнеризированных сред, где лимиты памяти могут быть жестко ограничены.

⚠️ Внимание: Значение free памяти в Linux не является показателем доступности. Система агрессивно использует свободную память для кэширования. Всегда ориентируйтесь на параметр available, который учитывает reclaim-память.

Дисковое пространство и здоровье хранилищ

Заполнение дискового пространства — классическая причина остановки работы сервисов. Базы данных перестают писать транзакции, логи перестают крутиться, а система может стать полностью неработоспособной. Мониторинг свободного места (vfs.fs.size[,free]) должен быть настроен на нескольких уровнях: предупреждение при заполнении 80% и критический алерт при 90-95%.

Однако просто знать процент заполненности недостаточно. Необходимо отслеживать Inodes (индексы). На серверах с миллионами мелких файлов может закончиться не место на диске, а количество доступных Inodes. Система при этом покажет, что дисковое пространство свободно, но создать новый файл будет невозможно. Это частая проблема веб-серверов и почтовых шлюзов.

Здоровье самих накопителей также требует внимания. Используйте S.M.A.R.T. атрибуты для отслеживания деградирующих дисков. Параметры Reallocated_Sector_Ct или Current_Pending_Sector могут указать на скорый физический отказ диска задолго до того, как он перестанет работать. В Zabbix это настраивается через активные элементы или внешние скрипты, читающие вывод утилиты smartctl.

Метрика	Описание	Рекомендуемый порог срабатывания
vfs.fs.size[/,pused]	Процент использования корневого раздела	> 85% (Warning), > 95% (Critical)
smartctl[device,Reallocated_Sector_Ct]	Количество переназначенных секторов	> 0 (любое значение — критично)
vfs.fs.inode[/,pused]	Процент использования Inodes	> 90% (Warning)
disk.read.bytes	Скорость чтения с диска	Аномальный скачок или падение до 0

Важно также отслеживать задержки ввода-вывода (I/O latency). Медленные диски могут стать "узким горлышком" даже при наличии свободного места. Если сервер выполняет операции записи медленно, базы данных начнут выдавать таймауты. Мониторинг I/O wait в метриках процессора и специфические задержки чтения/записи помогают выявить эту проблему раньше, чем пользователи начнут жаловаться на скорость.

Сетевая активность и пропускная способность

Сеть — это артерии вашей инфраструктуры. Проблемы здесь могут проявляться по-разному: от полной потери связи до деградации качества обслуживания. Мониторинг интерфейсов должен включать использование полосы пропускания (utilization), количество ошибок (errors) и отброшенных пакетов (drops). Резкий рост ошибок CRC часто указывает на проблемы с кабелем или сетевой картой.

Отдельное внимание стоит уделить количеству активных сетевых соединений. Для веб-серверов и балансировщиков нагрузки этот показатель критичен. Если количество established соединений резко падает, возможно, сервис упал. Если оно резко растет — возможна атака. Метрики net.tcp.listen и net.tcp.service помогают понять, слушает ли порт нужный сервис.

Не забывайте про DNS. Если система не может разрешить доменные имена, многие внутренние процессы остановятся. Проверка времени отклика DNS-серверов и корректности ответов — важный элемент здоровья сети. Используйте функцию net.dns.record в Zabbix для периодической проверки резольверов.

• 📡 Следите за packet loss между ключевыми узлами сети.
• 🔥 Отслеживайте перегрузку интерфейсов (процент использования > 80%).
• 🛡️ Мониторьте количество новых соединений в секунду для защиты от DDoS.

Иногда проблема не в пропускной способности, а в конфигурации маршрутизации или MTU. Если пакеты слишком большие и попадают в фрагментацию, это снижает производительность. Хотя Zabbix не может напрямую диагностировать MTU, косвенно это проявляется в росте количества переотправленных пакетов и увеличении задержек на определенных участках сети.

Как настроить мониторинг эластичности сети?Для облачных сред с динамическими IP используйте Zabbix Proxy или HTTP-агенты, которые опрашивают облачные API для получения метрик новых инстансов. Это позволяет автоматически добавлять в мониторинг новые серверы без ручной настройки агентов.-->

Специфические метрики приложений и сервисов

Общие метрики ОС важны, но истинное состояние системы определяется работой бизнес-приложений. Мониторинг баз данных (PostgreSQL, MySQL, Redis) должен включать количество активных соединений, время выполнения запросов и размер буферных пулов. Если база данных начинает долго отвечать, это влияет на весь фронтенд.

Для веб-серверов (Nginx, Apache) критичны показатели worker processes, время ответа (response time) и количество ошибок 5xx. Если сервер возвращает ошибки, значит, он не может обработать запрос. HTTP-агент в Zabbix позволяет проверять доступность страниц и время загрузки, имитируя поведение реального пользователя.

Контейнеризация добавляет слой сложности. В Docker или Kubernetes нужно мониторить не только контейнер, но и узел, на котором он запущен. Ресурсы контейнеров часто ограничены лимитами (cgroups), и выход за эти пределы приводит к принудительному завершению процесса (OOM Kill). Отслеживайте метрики docker.container.cpu и docker.container.memory для каждого важного контейнера.