Pull to refresh

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 сыпет сообщение, о дублирования временных меток ?

Sign up to leave a comment.