Мониторинг сети в Zabbix: от офисного порта до провайдера

Когда интернет нестабилен, Zabbix помогает увидеть, где начинается проблема: в офисном шлюзе, на порту маршрутизатора или за пределами сети. Я покажу, как сопоставить SNMP-счётчики, ICMP-проверки и время жалоб, чтобы передать провайдеру проверяемые данные без ложных выводов.

Что графики Zabbix говорят о сбое связи

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

Провайдер контролирует свои узлы, а мы — участок сети и услугу, которыми пользуемся. Эти точки наблюдения не совпадают полностью. В Zabbix полезно собирать доступность узлов, задержку, потери ICMP, состояние WAN-интерфейса и счётчики ошибок. Но график сам по себе не устанавливает виновника и не заменяет договорный акт. График не нотариус. Для обращения нужны период наблюдения, точки измерения, значения показателей и повторяемость симптома.

Я отделяю наблюдение от вывода. «С внешней точки не пришёл ответ ICMP» — проверяемая запись; «провайдер виноват» — гипотеза, которую нужно сопоставить с данными роутера, коммутатора и условиями договора. В этом и польза мониторинга: не выиграть спор одной картинкой, а сузить место поиска и быстрее задать технически точный вопрос.

Если сеть отвечает, а конкретная программа всё равно не работает, я отделяю уровень соединения от уровня сервиса. Проверка ICMP до узла может быть успешной при проблеме DNS, веб-приложения или авторизации. Для таких случаев нужен отдельный прикладной контроль, если он доступен и уместен. И наоборот, сбой одного сервиса нельзя описывать как полный обрыв интернета. В журнале я записываю наблюдаемый симптом, а не подменяю его диагнозом.

• Записывайте время жалобы и интервал сбоя
• Отмечайте точку, с которой идёт проверка
• Сопоставляйте ICMP с состоянием интерфейсов

Архитектура: где ставить контрольные точки

Для небольшой сети я начинаю с трёх уровней: локальный шлюз, интерфейс роутера в сторону оператора и несколько внешних узлов, которые важны для работы. Коммутатор добавляет сведения о внутреннем uplink и портах. Zabbix может получать SNMP-данные от сетевого оборудования без установки агента на сам коммутатор или роутер; агент нужен там, где его поддерживает операционная система устройства. Это разные способы сбора, и подменять один другим не надо.

Место, откуда выполняется проверка, тоже часть схемы. Если Zabbix server или proxy стоит внутри офиса, его ICMP-проверка проходит через локальную сеть и офисный маршрутизатор. Такой результат описывает путь именно с этой точки. Для филиала я отдельно указываю, какой proxy для филиала опрашивает оборудование и какой узел проверяет доступность внешних ресурсов. Иначе два графика с одинаковой подписью могут измерять разные маршруты.

SNMP-опрос Zabbix выполняется по UDP. Поэтому до настройки я проверяю, что между сервером или proxy мониторинга и устройством разрешён нужный обмен, а доступ к управлению ограничен сетью администрирования. Контрольные внешние узлы выбираю не по принципу «любой известный адрес»: нужны стабильные цели, доступность которых согласована с задачей. Один отвечающий сайт не доказывает исправность всех сервисов, как и один молчащий узел не доказывает отказ всей линии.

До опроса полезно зафиксировать назначение каждого хоста и интерфейса: имя устройства, роль в схеме, место расположения и точку управления. На одном маршрутизаторе бывают физические, логические и резервные интерфейсы; если добавить всё подряд и не объяснить их роль, график будет выглядеть насыщенным, но не отвечать на вопрос об участке отказа. Я начинаю с интерфейсов, связанных с маршрутом критичных рабочих сервисов, а затем расширяю карту там, где данные действительно помогают разбору.

• Шлюз офиса
• WAN-интерфейс маршрутизатора
• Внутренний uplink коммутатора
• Несколько значимых внешних точек

Как настроить SNMP без догадок

Перед добавлением хоста я выясняю, какие версии SNMP поддерживает конкретная модель и прошивка. В Zabbix создаю интерфейс SNMP с адресом устройства, версией и соответствующими учётными данными. Для SNMPv2c задаётся community string; она не шифрует SNMP-обмен. Если обе стороны поддерживают SNMPv3, я выбираю уровень AuthPriv: он включает проверку подлинности и защиту содержимого сообщений. Доступ на чтение, отдельные учётные данные и ограничение источника опроса важнее, чем красивое имя хоста.

Сначала проверяю ответ устройства утилитой snmpwalk с того же Zabbix server или proxy, который будет собирать данные. Затем проверяю, что доступны нужные таблицы и объектные идентификаторы, а индекс интерфейса соответствует реальному порту. На этом этапе часто проявляются неверная версия протокола, права только на часть MIB или несоответствие шаблона модели; отдельно полезно разобрать, почему бывает неполный сбор SNMP. Zabbix прямо рекомендует проверять совместимость шаблона с устройством; названия и набор элементов нельзя переносить между вендорами на веру.

Для трафика я ищу в IF-MIB счётчики ifHCInOctets и ifHCOutOctets, если устройство их отдаёт. Это 64-битные счётчики принятых и отправленных байтов на интерфейсе. ifInErrors и ifOutErrors показывают ошибки интерфейса, но не являются универсальным счётчиком CRC: для CRC производитель может использовать отдельную таблицу. Поэтому я не объявляю кабель неисправным по одному агрегированному числу, а сверяю рост ошибок с портом, временем и данными соседнего оборудования.

Учётные данные не включаю в команды для общего доступа, тикеты и скриншоты. Для SNMPv2c использую отдельную community с правами чтения, не оставляю встроенное значение по умолчанию и ограничиваю источник опроса. Для SNMPv3 фиксирую выбранный security level и параметры, которые поддерживают обе стороны: совместимость алгоритмов зависит от устройства и используемой сборки net-snmp. После смены реквизитов обновляю их в Zabbix и сразу проверяю сбор, а не жду отчёта от дежурного.

• Проверьте поддержку SNMP на устройстве
• Ограничьте доступ источником мониторинга
• Сверьте индекс интерфейса с портом
• Проверьте состав шаблона до включения

ICMP: измеряем доступность и потери

В Zabbix ICMP-проверки относятся к простым проверкам: для них не нужен Zabbix agent на целевом устройстве. Штатные ключи позволяют разделить три показателя: icmpping проверяет доступность по ping, icmppingloss возвращает долю потерянных пакетов в процентах, а icmppingsec измеряет время ответа в секундах. Проверку выполняет server или proxy, используя fping; если элемент не получает значения, я проверяю также наличие и работоспособность этой утилиты на узле опроса.

Я не задаю один процент потерь или одну задержку как универсальную границу аварии. Сначала собираю нормальный профиль линии, учитываю требования приложений и условия SLA, а уже затем подбираю окно и пороги триггера. Значение ICMP описывает ответы на ICMP-пакеты к выбранной цели; оно не равно автоматически потерям в голосовом вызове, передаче файлов или конкретном приложении. Некоторые точки могут отвечать иначе, чем пользовательский сервис.

Проверяю путь несколькими целями и сравниваю их с офисным шлюзом. Если шлюз недоступен одновременно с внешними адресами, сначала исследую локальную сеть и маршрутизатор. Если шлюз отвечает, а проблемы видны до нескольких внешних целей, это повод расширить диагностику на WAN-интерфейс и передать оператору временную шкалу наблюдений. Это направление расследования, а не готовый вердикт: ICMP и трассировка помогают увидеть симптом, но не раскрывают все причины потерь.

Задержку разбираю вместе с потерями. В Zabbix среднее время ответа по icmppingsec рассчитывается по полученным ответам: потерянные пакеты и тайм-ауты в расчёт не входят. Поэтому отдельно проверяю icmppingloss; график задержки сам по себе может показывать только удачные ответы и скрыть, что часть измерений пропала. Я смотрю на оба показателя за один интервал, а не трактую ровную линию времени ответа как отсутствие потерь.

• icmpping — доступность
• icmppingloss — потерянные пакеты
• icmppingsec — время ответа

Загрузка портов и ошибки интерфейсов

Счётчики octets накапливаются, а не показывают скорость сами по себе. Чтобы получить изменение трафика за интервал, Zabbix или шаблон должен обработать разницу между последовательными значениями. На скоростных интерфейсах я предпочитаю ifHCInOctets и ifHCOutOctets: IF-MIB определяет их как Counter64, 64-битные версии счётчиков ifInOctets и ifOutOctets. Это снижает риск неверного расчёта на загруженном канале из-за слишком быстрого переполнения короткого счётчика.

WAN-порт роутера сравниваю с внутренними uplink-интерфейсами, но не складываю их механически. Один и тот же поток может пройти через несколько портов и попасть в сумму повторно; направления приёма и передачи тоже нужно учитывать отдельно. Для оценки заполнения канала сверяю скорость интерфейса и тарифную полосу, а не делаю вывод по цвету графика. Если счётчики обнулились после перезапуска устройства, изменение между точками нельзя трактовать как обычный трафик.

Рост ошибок на конкретном порту — повод проверить физическое соединение, настройки и состояние обоих концов линии. Он не отвечает сам по себе на вопрос, где находится причина: порт может считать ошибки по-разному, а часть диагностических метрик бывает только в таблицах производителя. И ещё одно ограничение: суммарный SNMP-счётчик uplink не называет пользователя или приложение, создавшее нагрузку. Для такой детализации нужен отдельный источник данных, а не обещание, что график порта всё расскажет.

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

• Смотрите входящий и исходящий трафик отдельно
• Сравнивайте счётчики на обоих концах
• Проверяйте сбросы и перезапуски интерфейса
• Не ищите пользователя по сумме uplink

Триггеры и уведомления без лишнего шума

После сбора данных настраиваю триггеры по тому, что нужно заметить: пропала ли доступность точки, ухудшились ли потери, выросли ли ошибки интерфейса. В выражениях Zabbix доступны агрегирующие функции avg() и max(), чтобы оценивать окно наблюдений, а не реагировать на каждое единичное значение. Окно, порог и длительность выбираю по истории и требованиям сервиса. Готового числа, одинаково правильного для любого офиса и любого договора, нет.

В событии полезны имя хоста и интерфейса, точка проверки, время начала, текущее значение и выбранный порог. Добавляю уведомление ответственному через настроенный media type и отдельно проверяю его доставку тестовым событием. Канал оповещения должен быть доступен дежурному, а не только автору настройки. После восстановления отправляю отдельное сообщение, иначе переписка быстро превращается в ленту, из которой непонятно, закончился сбой или нет.

Я разделяю проблему и восстановление, назначаю ответственного и не поднимаю тревогу по параметру, который никто не проверяет. Если после теста приходят повторные ложные сигналы, корректирую порог по данным, а не отключаю триггер целиком. Так мониторинг остаётся рабочим журналом событий. Без этого Zabbix действительно может стать ещё одной системой, которая громко сообщает, что её никто не слушает.

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

• Настройте окно по истории показателя
• Проверьте доставку тестового уведомления
• Добавьте сообщение о восстановлении

Разбор для условного бюро на 23 рабочих места

Для условного архитектурного бюро «Линия горизонта» из 23 рабочих мест я бы начал не с заявления провайдеру, а с карты измерений. В неё вошли бы шлюз офиса, WAN-интерфейс роутера, uplink коммутатора и внешние точки, нужные сотрудникам. Отдельно записал бы, кто и откуда делает каждую проверку. Число рабочих мест само по себе не определяет, сколько нужно серверов Zabbix: решение зависит от частоты опроса, числа элементов, хранения истории и доступной инфраструктуры.

При жалобе на медленную работу я сопоставляю время обращения с графиками ICMP и SNMP за тот же интервал. Сначала выясняю, затронуты ли шлюз и внутренние порты; затем смотрю состояние WAN и несколько внешних направлений. Если есть только задержка до одного узла, проверяю доступность других точек. Если растут ошибки на интерфейсе, сохраняю показатели обоих концов линии. Такая последовательность не приписывает проблему провайдеру заранее и не отправляет инженера менять кабель по догадке.

В обращение оператору прикладываю период, место замера, конкретные метрики и короткое описание повторяющегося симптома. Графики Zabbix помогают восстановить хронологию и поддержать разговор цифрами, но окончательные выводы зависят от дополнительных проверок и договора. Я сохраняю историю дольше, чем длится обычный цикл разбора обращений, и проверяю синхронизацию времени между узлами. Такой подход помогает готовить разбор аварии провайдера по наблюдениям, а не по памяти. Иначе точные графики легко разъедутся с журналом оператора на часы и потеряют часть пользы.

Перед отправкой проверяю, что график не раскрывает учётные данные SNMP или лишние сведения о внутренней сети. В обращении достаточно указать точку наблюдения, имя интерфейса, период и значения до, во время и после симптома; community string и ключи SNMPv3 туда не относятся. Если оператору нужны дополнительные сведения, передаю их отдельно по согласованному защищённому каналу. Выгрузку истории храню внутри инфраструктуры по принятому порядку доступа.

• Укажите точку и источник каждого замера
• Сведите события к одной временной шкале
• Сохраните исходные метрики для обращения

Частые вопросы