Comments 23
Долго пытался вспомнить, почему в итоге отказался от mktxp.... то ли метрик каких-то не хватило, то ли баг поймал. Не вспомнил :( Но в итоге перешёл на SNMP и snmp-exporter, благо последний для разных других железок всё равно нужен. Поскольку не вспомнил про конкретные фатальные недостатки mktxp, то не буду говорить, что мой вариант лучше - просто скажу, что есть и такой способ тоже.
Лично у меня микроты мониторятся заббиксом по SNMP, мне этого более чем хватает. Особенно на 7 версии заббикса...
Смысл городить связку MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana, когда достаточно SNMP ⟶ Zabbix? Для мониторинга доступности микротов, заббикса хватает с головой.
Ну можно ещё экспорт данных в графану настроить, по желанию, для красоты.
/sarcasm-on
Смысл городить связку SNMP ⟶ Zabbix, когда связки SNMP ⟶ "любимая технология" достаточно, ведь у меня все работает на "любимой технологии" и мне этого более чем хватает.
/sarcasm-off
Zabbix отличное решение на своем месте и для своих задач, но не нужно утверждать, что все сетевые железки должны мониториться только им, просто потому что кому то "хватает". Лично мне не хватает и в моем окружении они мониторятся связкой SNMP - snmp-exporter - prometheus - mimir - grafana, у меня свои задачи и Zabbix мне в них не поможет.
Подход с заббиксом и SNMP действительно надёжное решение, особенно если вся линия поддержки опирается в основном на его данные, но связка MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana тоже имеет место быть, так как даёт больше гибкости. Например, некоторые метрики недоступны через SNMP, ввиду того, что мы будем упираться в возможности OID (например, мониторинг DHCP — leases, pool, PPP, Hotspot — users, sessions, или Firewall — количество соединений по каждому правилу), а через API они легко тянутся. К тому же API позволяет опрашивать устройства чаще, чем SNMP.
В конечном итоге выбор инструмента зависит от ваших требований к мониторингу, ведь как говорится, важен не инструмент, а результат, который он приносит.
Да не только доступности. Zabbix 6-7 + универсальный шаблон под Микроты, закрывают процентов 98 от потребностей. Остальное довешиваем руками. Если уж совсем дело швах, но тогда вполне можно начать мониторить другие метрики так или иначе связанные с целью. Хотя по опыту тяжело себе представляю, что в Микроте по SNMP нельзя вытащить. У них одно из лучших покрытий в индустрии SNMP метриками своего железа. D-link до сих пор к этому не может даже близко подойти. Про Cisco молчу, там всё не так плохо, как у D-LINK, но тоже случаются необъяснимости.
Читаю и понимаю, что если у человека есть молоток, то всё вокруг становится гвоздями. Ребята, мониторить сетевое оборудование инструментами, которые создавались не совсем для этого (Prometheus).... Да можно конечно, но это не гвоздь, это шуруп.... SNMP+ZABBIX более чем закрывает эту проблематику + прекрасно реализованные алерты Zabbbix. Хочется красоты - да не вопрос, накрутите Grafana. Но зачем такая избыточность, сложность. Ужас конечно. Молодцы что справляетесь, плохо что таким образом.
С совы сыпятся перья, но вы упорно тянете её на глобус DevOps. Мониторинг инфраструктуры через экспортеры.... Ну ок, что тут скажешь.
Спасибо за мнение! улыбнуло)
SNMP + Zabbix действительно отлично закрывает большинство задач и проверено временем. Но, как говорится, "кому шашечки, а кому ехать" :)
Prometheus, конечно, изначально заточен под мониторинг сервисов и приложений, а не сетевого железа. Однако, когда в инфраструктуре уже крутится Prometheus, добавление MKTXP или подобных экспортеров – это скорее путь наименьшего сопротивления, чем попытка забить шуруп молотком. Так же выше я описал в комментарии, что по API мы получим больше метрик, может кому-то необходимо визуализировать правила по firewall, или мониторить dB кажного Wi-Fi клиента.
С другой стороны, SNMP и Zabbix прекрасно справляются с задачами мониторинга железа. особенно когда дело касается базовых метрик и алертов.Тут согласен, что прямые инструменты проще и надёжнее.
В общем, это как спорить, что лучше – отвертка или шуруповёрт. Оба крутят, просто с разной скоростью и удобством :)
Для уровней клиентов есть автодискавери в заббиксе, все можно.
Но самый правильный ответ на вопрос «а чего прометей» это да, банально, он уже есть, а мы хотим один мониторинг
Ps
Заббикс лет сто как умеет читать метрики с экспортеров прометея, из коробки. Я решал строго обратную задачу, к заббиксу крутил метрики которые отдавал экспортер встроенный в приложение
Jmx через экспортер кстати тоже работает лучше чем встроенный в хаббикс.
О, а это мысль. спасибо. А то намедни обнаружил, что у меня аплинк до провайдера поднят на 100мбит вместо 1гбит. А я все ркн винил :D Оказалось в этажном щите КЗ на одной из пар - как кстати такие фейлы такое мониторить вообще? Линк поднят, ошибок в логах нету.. а autonegotiation отключать не хочется.
Можно ли узнать все доступные метрики? В частности, меня интересуют графики скорости на туннелях Wireguard и Zerotier.
Странность заметил. Несмотря на строчку ниже, метка name складывается из имени интерфейса и комментария.
use_comments_over_names = False # when available, forces using comments over the interfaces names
Можно ли только имя интерфейса оставлять?
В Prometheus через relabel_configs тоже не получилось убрать. Но там может сам начудил - метку заменять на статику "xxx" могу, а вот "xxx${1}yyy" выдает "xxxyyy", т.е. группа не распознается.
Так что пока тупо комментарии у интерфейсов убрал. Но хочется красивого решения.
Чтобы собрать часть метки (например, только имя интерфейса), нужно настроить relabel_configs
в конфиге прометеуса. Если не ошибаюсь можно попробовать так:
relabel_configs:
- source_labels: [__name__]
regex: ".*_(.+)_.*"
target_label: "interface"
replacement: "${1}"
Спасибо, но что-то не получается у меня. Может regexp у меня неправильный. Раньше всегда VictoriaMetrics пользовался, а тут решил, что больше мне не требуется поддержка графита с инфлюксом и поставил стагндартый prometheгs..
Впрочем, вроде как и само заработало - интерфейс отдается без комментария, как я и хотел... (так что в этот раз я пробовал из "eth1-vlan3" вытащить eth1).
У меня удалось запустить mktxp
когда прокинул/смонтировал кастомные конфиги в по следующим путям:
/home/mktxp/mktxp/mktxp.conf
/home/mktxp/mktxp/_mktxp.conf
на конфиги приведенные в статье
День добрый.
Собрал по вышеуказанной инструкции. Все собралось и все запустилось но на графике ничего нет. Сплошные N/A или NoData. Куда копать - не понятно. Собрал по ссылке с GitHub - заработало, но есть одно большое НО: тот микрот, который был добавлен при сборке - все отображается, а вот как добавить остальные - не понятно. Как ни старался - не получилось. Либо описание не полное, либо лыжи не едут.
Добрый день, проверьте поступают ли данные от экспортера в прометеус.
Остальные устройства можно добавить так:
[MikroTik1]
hostname = 192.168.50.1 # IP роутера который будем мониторить
[MikroTik2]
hostname = 192.168.50.2 # IP роутера который будем мониторить
[MikroTik3]
и т.д.
[default]
# Стандарный конфиг
Приветствую!
Если бы, еще как понимать как " проверьте поступают ли данные от экспортера в прометеус "?
Да и вообще, совсем не понятно как искать проблему или собирать логи. Если честно, с докером не очень дружу, но видя что происходит, понимаю что он тут не причем. Ведь все контейнеры собрались и запустились. Сразу что показалось странным, MKTXP не цеплялся к микроту. Логин и пароль проверил по 5 раз. Ноль. В коннекшенах на микроте вижу что MKTXP пытается общаться с микротом и тот даже что-то отвечает. Но микрот говорит что к нему пользователь MKTXP не подключен.
Здравствуйте. У меня появилась вот такая ошибка. Подскажите пожалуйста где я накосячил?)))

Подскажите как исправить эту ошибку?

C RouterOS 6 завелся только с версией mktxp:1.2.8. Но теперь Prometheus сыпет сообщение, о дублирования временных меток ?
Мониторинг сетевого оборудования MikroTik с использованием MikroTik API, MKTXP, Prometheus и Grafana