Настраиваем Zabbix для мониторинга точек доступа и роутеров Keenetic

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

Чего не хватает во встроенных средствах мониторинга Keenetic RMM?

Любое собственное средство мониторинга покрывает только устройства самого производителя, то есть да, вы можете видеть такие обязательные параметры, как доступность новой прошивки, онлайн-статус роутеров или даже загруженность ресурсов, но как только вы сталкиваетесь с проблемами в сетевой инфраструктуре, вам во-первых сразу нужна детальная статистика по устройствам, во-вторых – вам нужен охват всех сетевых клиентов, включая их метрики и журналы. «Кто что делал в момент сбоя? Какой был трафик по портам и какая загруженность радиоэфира в обед, когда ВКС лагает?». Кроме того, если у вас большой парк устройств разных компаний - вам нужна единая точка мониторинга статуса и событий. Проще говоря, в Keenetic RMM не хватает чего-то такого:

Платформ для мониторинга сегодня очень много: это и Nagios, и Netdata, и стек Grafana/Loki/Prometheus, и конечно же Zabbix, ставший стандатом де-факто для системных администраторов и сетевых инженеров. Все они бесплатные, достаточно стабильные, могут работать локально или в облаке. В данной статье мы рассмотрим интеграцию устройств Keenetic в платформу Zabbix. Будем считать, что данный софт у вас в компании уже установлен (устанавливается за 15 минут отсюда), и нам остаётся просто добавить в него Keenetic.

Включаем SNMP на Кинетиках

Keenetic поддерживает SNMP v1/2c для экспорта системной информации в сторонние сервисы. Пакет «SNMP сервер» устаналивается через Web-интерфейс Keenetic, независимо от того, в каком режиме работает девайс – роутер или точка доступа. Сразу не забудьте включить поддержку SSH протокола, чтобы зайти на Кинетик из терминала и включить службу SNMP в соответствии с инструкцией. И да, будет лучше переименовать имя хоста, чтобы легче было отличать один кинетик от другого в логах, хотя это и не обязательно: точки доступа Voyager уже с завода имеют имя вида Keenetic-XXXX с уникальным номером, но мало ли - вдруг попадётся повторка?

Убедившись, что служба запущена и обрабатывает входящие запросы, переходим к разбору данных, которые можно извлечь по SNMP из Кинетика. В инструкции по ссылке выше подробно описан процесс работы MIB-файлами, содержащими описание получаемых по SNMP метрик. Изучив их, я немного расстроился: самих метрик – очень мало, и большая их часть относится к роутерной части Keenetic, а для Voyager Pro или Orbiter, работающих в режиме точек доступа, не хватает информации об используемых каналах Wi-Fi, уровне сигнала, температуре материнки и числе клиентов на станциях. Из полезного для меня здесь, в общем-то, есть лишь данные о загрузке процессора (моментальной и средней за 1, 5, 15 минут) и объёме памяти. Если вы активно используете роутер как сетевой накопитель (см. нашу статью о настройке NAS на роутере) – вам пригодится экспорт информации о подключенном носителе, который здесь есть.

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

А в следующей таблице приведены наиболее важные OID для средств мониторинга состояния и сбора метрик.

Если вы используете Keenetic в роли NAS:

Не важно, один, два или много кинетиков у вас в компании, начинаем всегда с одного. В логическом представлении Zabbix один и тот же узел можно одновременно мониторить разными способами, поэтому нам сначала надо добавить наш Keenetic, а потом применить к нему разные варианты сбора метрик (т.н. Элементы Данных, или ИД).

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

При создании узла мы указываем его IP-адрес или сетевое имя, и в поле community лучше жёстко прописать название SNMP, даже если у вас дефолтное значение - public. До версии 6.4 в Zabbix можно было удобно импортировать шаблоны, получаемые из MIB файлов с помощью скрипта mib2zabbix, но как это часто бывает, формат шаблонов изменили, а скрипт не переписали, поэтому в версии 6.4 OID-ы придётся ввести вручную.

Итак, добавив первый Keenetic, жмём на ссылку «Элементы данных», а затем в правом верхнем углу «Добавить элемент». Обратите внимание - в этот момент значок SNMP уже должен гореть зелёным рядом с названием узла. Если нет - выясняем, почему у вас не работает SNMP служба (проверяем установку net-snmp на сервере, правила firewall, если устройство находится в другой сети и т.д.).

Выбираем тип «SNMP агент», и теперь нам осталось ввести имя метрики, например «Среднее значение Load Average за последние 15 минут», присвоить ей ID в поле «ключ», например «load_average_15_min» и ввести OID. Обратите внимание на скриншоте сверху знаком вопросика указано опциональное поле заполнения элемента инвентаря. Zabbix поддерживает автоматическое заполнение элементов карточки узла из SNMP данных. Помимо серийников и P/N, туда имеет смысл заносить MAC-адреса устройств, чтобы они всегда были под рукой. Как вы правильно поняли, каждый такой элемент - это отдельный элемент данных и отдельный OID.

После того, как вы настроили импорт метрик, имеет смысл создать триггеры, например чтобы получать уведомление когда загрузка CPU превышает 75% за последние 5 циклов обновления данных. С помощью конструктора регулярных выражений вы можете задавать собственные условия срабатывания тревоги в зависимости от потребностей сети.

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

Настройка сбора логов

Zabbix не имеет встроенного сервера журналов, на который можно было бы транслировать логи с устройств, поэтому нам нужно поднять в сети отдельный Syslog сервер (вот инструкция для установки на Ubuntu), прописать его адрес на всех кинетиках и поставить на этом сервере Zabbix Agent в активном режиме для трансляции собранных журналов уже в саму платформу мониторинга. По собственному опыту рекомендую ставить rsyslog на отдельную виртуалку, т.к. чтобы если вы ошибётесь с logrotate, у вас не забилось всё место на сервере. В нашем примере Syslog сервер имеет адрес 192.168.1.189, его и прописываем в Keenetic.

Устройства Keenetic поддерживают экспорт логов на сервер Syslog без авторизации и только по протоколу UDP, так что если ваш основной Syslog сервер настроен иначе – вы можете просто поднять для Keenetic отдельный экземпляр сервера журналов.

Установка Zabbix агента под вашу ОС, на которой запущен rsyslog, производится по инструкции с официального сайта, ещё рекомендую почитать вот этот мануал. Обратите внимание – после инсталляции агент нужно настроить, добавив в конфиг адрес Zabbix сервера. У меня в примере Zabbix сервер имеет IP адрес 192.168.1.183, и я у себя добавил в /etc/zabbix/zabbix_agentd.conf следующие строки:

Server=192.168.1.183 ListenPort=10050 ListenIP=0.0.0.0 ServerActive=192.168.1.183 Hostname=syslog-server

Для того, чтобы различать «кинетики» в общем потоке журнальной информации, на Syslog сервере имеет смысл выделить для них отдельный шаблон сохранения журналов, добавив в /etc/rsyslog.conf вот это содержание:

$template KEENETIC, "/var/log/keenetic/keenetic.log" if $hostname contains 'Keenetic' then ?KEENETIC

В этом шаблоне мы складываем все логи кинетиков в каталог /var/log/keenetic в отдельный файл keenetic.log, внутри которого каждую точку доступа мы будем различать по её имени хоста.

По умолчанию Keenetic отправляет в журнал все события, такие как подключение клиентов, смена радио диапазона, и прочее. Подробные логи в эпоху больших и быстых SSD – это хорошо, но чтобы не забивалось место на Syslog сервере, включаем ротацию, создав файл /etc/logrotate.d/keenetic.conf и прописав в нём такие настройки:

/var/log/keenetic/*.log { su root syslog weekly olddir /var/log/keenetic/old rotate 7 missingok notifempty create 0777 root root postrotate systemctl restart syslog endscript }

С настройками по умолчанию Zabbix Агент не имеет доступа к файлу журналов – эту проблему можно решать по-разному, но так как у меня Syslog сервер запущен в отдельной виртуалке, я просто ставлю права 0777 на /var/log/keenetic/keenetic.log и запускаю агента от root. Да я знаю, что это может быть небезопасно, но вы у себя можете сделать иначе.

В Zabbix нам нужно добавить новый узел – сервер Syslog, обязательно указав тот же hostname, который прописан в настройках сервера (в нашем примере Hostname=syslog-server). Группу узлов лучше выбирать Linux servers, а шаблон – Zabbix agent (активный).

Теперь нам предстоит выбрать, какие события журналов «Кинетиков» грузить в Zabbix, чтобы не засорять эфир обычными служебными сообщениями типа подключения и отключения клиентов. Обычно для этих целей скрапер логов (узел "сервер Syslog") выбирает из лог-потока только определённые записи, используя регулярные выражения. Большинство рекомендаций содержат примеры для парсинга только строк с содержанием флагов WARNING, ERROR, CRITICAL и FATAL, и жизнь была бы пресной и безвкусной, если бы кинетики помечали свои сообщения в журналах по степени важности, но этого нет, так что придётся настраивать всё самим.

Алгоритм действий простой: моделируем отказ на Keenetic, смотрим сообщение в журнале через его Web-интерфейс и создаём на его базе элемент данных с использованием регулярного выражения. Вот например, когда клиент неправильно вводит пароль от Wi-Fi, в лог файл пишется такое сообщение:

Network::Interface::Mtk::WifiMonitor: "WifiMaster0/AccessPoint1": STA(50:76:af:dd:e2:ad) MIC differs in key handshaking (msg 2 of 4-way)

из которого нам нужно только

MIC differs in key handshaking

Переходим на страницу элементов данных в syslog-сервере (!!!не на кинетике!!!) и теперь создаём элемент, указывая Zabbix агент (активный). В этот момент иконка ZBX должна гореть зелёным, если нет - проверяйте связь с Zabbix агентом, традиционно начиная с Firewall, правильного указания Hostname и конфига агента.

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

log[/var/log/keenetic/keenetic.log, "MIC differs in key handshaking.*",,,,]

На получившийся ЭД ставим триггер с заданной частотой срабатывания. Я для примера настроил три события: неправильный ввод пароля от Wi-Fi, изменение конфигурации точки доступа и перезагрузку после автоматического обновления. Для кинетиков работающих в режиме роутера можно настроить различные события, связанные с VPN или работой других сервисов. Триггер для логов создаётся так же, как для метрик, с той лишь разницей, что регулярное выражение писать не нужно - когда вы нажмёте кнопку "добавить", у вас уже будет список готовых ключей из добавленных вами событий [звучит страшно, но на деле - три клика мышкой].

У Keenetic есть неприятная особенность – вместо повторения одного и того же события, он просто пишет «last message repeated n times», и это плохо, потому что такой подход очень сильно усложняет настройку триггеров по частоте срабатывания. Я надеюсь, что производитель это исправит в будущих версиях прошивки, когда/если у него руки дойдут навести порядок в логах.

Наводим красоту

Если вы дочитали до этого момента, то уже примерно представляете себе, как добавить графики по собранным метрикам: выбираем наш Keenetic Voyager, кликаем на "графики" и просто устанавливаем данные, на которых они строятся.

Не увлекайтесь большим количеством графиков - Zabbix строит их по расписанию, в графическом виде и сильно жрёт при этом ресурсы.

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

В первую очередь, мы добавляем наши кинетики в существующую карту сети и/или создаём для них новую. Zabbix позволяет не просто загружать кастомные иконки устройств в базу, но и использовать разные картинки для разного статуса устройств, чтобы легче было ориентироваться по карте, на каком устройстве проблема или какое временно отключено. Я создал базовый набор иконок для всех типов Keenetic, доступных сегодня, включая розеточный ретранслятор и VoIP шлюз, обзор которого есть у нас на сайте. Скачать набор иконок Keenetic для Zabbix в высоком качестве без регистрации и SMS вы можете по ссылке.

На карте выше у меня сеть на Keenetic с активированным мониторингом через VPN и в локалке. Обратите внимание - в одном окне я сразу вижу статус сетевого коммутатора Zyxel, программного шлюза PFsense, сервера, ИБП, а ещё там есть NAS Synology и пара рабочих станций. Для жёсткого диска, подключенного к Keenetic Giga я создал отдельный узел сети и применил к нему соответствующие метрики.

Создаём шаблон и применяем его к новым точкам доступа

Как вы помните, всё это время мы настраивали только один Keenetic Voyager Pro, расположенный у нас в холле. Пришло время добавить в Zabbix ещё несколько аналогичных точек доступа, и чтобы не настраивать их с нуля, мы создаём шаблон из настроек мониторинга, который потом применим ко вновь прибывшим. Выбираем нашу точку доступа во вкладке «Сбор данных» - «Узлы сети» - «Keenetic Voyager» - «Элементы данных», отмечаем галочками все его родные метрики (кроме тех, что были применены сторонними шаблонами) и жмём вниз кнопку «Копировать».

Здесь я хочу заметить, что у вас в сети могут быть разные Keenetic: ретрансляторы, точки доступа, роутеры, поэтому лучше вместо одного общего шаблона, создать несколько, иначе неработающие триггеры вас замучают. Такие функции как NAS, или скорость трансляции пакетов, выносим в отдельные шаблоны, загрузку памяти и CPU - в свой шаблон, сборку логов - в свой. Аналогично поступаем с триггерами и графиками, после чего на первом устройстве, которое мы настраивали, должны остаться только шаблонны.

Обратите внимание – такие базовые проверки как пингование, в Zabbix встроены и применяются отдельными шаблонами. Их мы дополнительно применяем наряду с нашими шаблонами.

Всё, теперь при установке новых точек доступа, нам будет проще: в web-интерфейсе каждого устройства, включаем SNMP, включаем экспорт в Syslog, добавляем их в Zabbix и применяем ранее настроенный шаблон, на каждое устройство уходит минут по 15. Ну а тем, кто дочитал до этого места, я предлагаю скачать мои шаблоны для Keenetic, которые я использовал в этой статье. Вы можете импортировать их в Zabbix и облегчить процесс настройки.

Способы оповещения о событиях вы без труда настроите самостоятельно: Zabbix умеет и посылать E-Mail, и писать в Discord и Jira, дружит с Telegram и SMS-сервисами - ничего сложного там нет.

Напоследок

Не всегда даже крупные сетевые производители предоставляют в открытом доступе данные для сторонних систем мониторинга. Достаточно часто простые MIB-файлы лежат за тремя стенами регистрации клиента/партнёра/интегратора на корпоративном портале, и так просто их не раздобыть или вообще отсутствуют как класс. С поддержкой SNMP тоже не у всех всё гладко, и хотя этот протокол старый, как кости мамонта, вполне себе случается, что сетевой коммутатор за 1-2K$ может выдавать тайм-аут на запрос по SNMP, возвращая лишь половину коротенького «дерева». Настройки систем мониторинга, дашбордов, парсинга логов – это долгий кропотливый труд, который очень часто бросают на полпути или вообще за него не берутся, вечно откладывая «на потом», но делать это надо.

Компания Keenetic могла бы сильно облегчить жизнь системным администраторам, если бы добавила авторизацию и побольше метрик в SNMP, причесала бы лог-файлы в соответствии с «лучшими практиками», написала бы и выложила на Github шаблоны для современных платформ мониторинга и добавла бы экспортер в Prometheus/Graylog. Но даже с тем что есть сейчас, вы легко можете интегрировать кинетики в вашу корпоративную систему мониторинга.

Михаил Дегтярёв (aka LIKE OFF)
09/11.2023