Представьте: пятница, вечер, вы уже мысленно с бокалом чего-то крепкого и вкусного наслаждаетесь прокрастинацией. Ничего не предвещало беды, но жизни любого администратора наступает момент, когда нужно поиграть в игру "Угадай на каком этаже пропал интернет". И что бы победить непредсказуемость сетевых устройств, умные люди придумали Grafana для визуализации различных метрик, и различные экспортеры этих метрик. В данной статье рассмотрим экспортёр метрик MKTXP, который настраивается в 2 кнопки.

https://github.com/akpw/mktxp?tab=readme-ov-file

MKTXP
MKTXP

Краткий обзор инструментов

MikroTik API

Решение для взаимодействия с RouterOS с целью сбора информации, настройки конфигурации и управления маршрутизатором. API полностью повторяет синтаксис интерфейса командной строки (CLI).

MKTXP

Для тех, кто не хочет писать скрипты вручную, есть MKTXP — решение для экспорта метрик из RouterOS в Prometheus.

Prometheus

Prometheus — от метрик к пониманию. Он собирает метрики, хранит их, умеет работать с временными рядами и отправлять алерты, если что-то идёт не так.

Grafana

Grafana — мощный инструмент визуализации данных и мониторинга, который позволяет анализировать и представлять информацию из различных источников данных в реальном времени. Он создаёт графики, диаграммы, панели мониторинга и оповещения, а также выполняет анализ данных и отчетность.

Схема взаимодействия компонентов
- MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana

Конфигурация MikroTik

Включаем API, создаем пользователя и группу для MKTXP.

/ip service enable api-ssl
/user group add name=monitoring policy=api,read
/user add name=mktxp group=monitoring password=mktxp_password

Подготовка сервера Ubuntu 22.04

Обновялемся и устанавливаем Docker

apt update && apt upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

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

Установка и настройка MKTXP

В деплое MKTXP ничего сложного
Создаём рабочую директорию для MKTXP и файлы конфигурации

mkdir -p mktxp/conf
cd mktxp
nano conf/mktxp.conf
nano conf/_mktxp.conf
nano docker-compose.yml

Пример конфигурации:
mktxp.conf: - в данном файле описываются эндпоинты и экспортируемые метрики

[MikroTik1]
    
    hostname = 192.168.50.1 # IP роутера который будем мониторить

[default]

    enabled = True          # turns metrics collection for this RouterOS device on / off
    hostname = localhost    # RouterOS IP address
    port = 8729             # RouterOS IP Port
    
    username = mktxp     # RouterOS user, needs to have 'read' and 'api' permissions
    password = mktxp
    
    use_ssl = True                  # enables connection via API-SSL servis
    no_ssl_certificate = True       # enables API_SSL connect without router SSL certificate
    ssl_certificate_verify = False  # turns SSL certificate verification on / off   
    plaintext_login = True          # for legacy RouterOS versions below 6.43 use False

    installed_packages = True       # Installed packages
    dhcp = True                     # DHCP general metrics
    dhcp_lease = True               # DHCP lease metrics

    connections = True              # IP connections metrics
    connection_stats = True         # Open IP connections metrics 

    interface = True                # Interfaces traffic metrics
    
    route = True                    # IPv4 Routes metrics
    pool = True                     # IPv4 Pool metrics
    firewall = True                 # IPv4 Firewall rules traffic metrics
    neighbor = True                 # IPv4 Reachable Neighbors
    dns = True                      # DNS stats

    ipv6_route = False              # IPv6 Routes metrics    
    ipv6_pool = False               # IPv6 Pool metrics
    ipv6_firewall = False           # IPv6 Firewall rules traffic metrics
    ipv6_neighbor = False           # IPv6 Reachable Neighbors

    poe = True                      # POE metrics
    monitor = True                  # Interface monitor metrics
    netwatch = True                 # Netwatch metrics
    public_ip = True                # Public IP metrics
    wireless = True                 # WLAN general metrics
    wireless_clients = True         # WLAN clients metrics
    capsman = True                  # CAPsMAN general metrics
    capsman_clients = True          # CAPsMAN clients metrics

    eoip = False                    # EoIP status metrics
    gre = True                      # GRE status metrics
    ipip = False                    # IPIP status metrics
    lte = False                     # LTE signal and status metrics (requires additional 'test' permission policy on RouterOS v6)
    ipsec = True                    # IPSec active peer metrics
    switch_port = True              # Switch Port metrics

    kid_control_assigned = True    # Allow Kid Control metrics for connected devices with assigned users
    kid_control_dynamic = True     # Allow Kid Control metrics for all connected devices, including those without assigned user

    user = True                     # Active Users metrics
    queue = True                    # Queues metrics

    bgp = True                      # BGP sessions metrics
    routing_stats = True            # Routing process stats
    certificate = True              # Certificates metrics
    
    remote_dhcp_entry = None        # An MKTXP entry to provide for remote DHCP info / resolution
    remote_capsman_entry = None     # An MKTXP entry to provide for remote capsman info 

    use_comments_over_names = True  # when available, forces using comments over the interfaces names
    check_for_updates = True        # check for available ROS updates
```

_mktxp.conf: - в данном файле опысывается конфигурация экспортера MKTXP

[MKTXP]
    listen = '0.0.0.0:49090'         # Space separated list of socket addresses to listen to, both IPV4 and IPV6
    socket_timeout = 5
    
    initial_delay_on_failure = 120
    max_delay_on_failure = 900
    delay_inc_div = 5

    bandwidth = False                # Turns metrics bandwidth metrics collection on / off    
    bandwidth_test_interval = 600    # Interval for collecting bandwidth metrics
    minimal_collect_interval = 5     # Minimal metric collection interval

    verbose_mode = True             # Set it on for troubleshooting

    fetch_routers_in_parallel = False   # Fetching metrics from multiple routers in parallel / sequentially 
    max_worker_threads = 5              # Max number of worker threads that can fetch routers (parallel fetch only)
    max_scrape_duration = 30            # Max duration of individual routers' metrics collection (parallel fetch only)
    total_max_scrape_duration = 90      # Max overall duration of all metrics collection (parallel fetch only)

    compact_default_conf_values = False  # Compact mktxp.conf, so only specific values are kept on the individual routers' level

docker-compose.yml:

services:
  mktxp:
    container_name: mktxp
    image: ghcr.io/akpw/mktxp:latest
    user: root
    volumes:
      - './conf/:/root/mktxp/'
    ports:
      - "49090:49090"
    restart: unless-stopped  

Запускаем контейнер с экспортером docker compose up -d

Установка и конфигурация Prometheus + Grafana

Создаём рабочую директорию и файлы конфигурации:

mkdir -p grafana/grafana
mkdir grafana/prometheus
cd grafana
nano docker-compose.yml

docker-compose.yml:

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=30d'
    restart: always

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - ./grafana/grafana:/etc/grafana/provisioning
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    ports:
      - "3000:3000"
    depends_on:
      - prometheus
    restart: always

volumes:
  prometheus_data:
  grafana_data:
nano prometheus/prometheus.yml

prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'grafana'
    static_configs:
      - targets: ['grafana:3000']
 
  - job_name: 'mktxp'
    static_configs:
      - targets: ['localhost:49090']
docker compose up -d

Теперь можем авторизоваться в Grafana по адресу server-ip:3000.

Авторизация в Grafana
Авторизация в Grafana

DaДобавляем Data Source:

  • Connection -> Data sources -> Add data source.

  • Выбираем Prometheus и указываем URL http://prometheus:9090.

  • Сохраняем и тестируем подключение кнопкой Save & test.

Data source
Data source

Теперь когда у нас добавлен источник для данных, осталось добавить Dashboard для мониторинга MikroTIk.

Импорт Dashboard:

  • Переходим в Dashboard -> Import.

  • Указываем ссылку на официальный дашборд MKTXP.

  • Нажимаем Load, выбираем источник данных Prometheus и импортируем.

  • После чего мы должны увидеть метрики с нашего роутера.

MKTXP Dashboard
MKTXP Dashboard

Заключение

Использование MKTXP в связке с Prometheus и Grafana позволяет построить довольно гибкую систему мониторинга MikroTik. Простота установки и конфигурации делает это решение доступным даже для администраторов с базовыми знаниями. Это решение даёт возможность вытаскивать множество различных данных из RouterOS "из коробки". Ведь в нашей не простой работе, чем меньше аварий, тем больше времени остаётся на кофебрейки и просмотр мемов, и конечно же просмотр статей на хабре :)

Комментарии (11)


  1. aborouhin
    30.12.2024 16:10

    Долго пытался вспомнить, почему в итоге отказался от mktxp.... то ли метрик каких-то не хватило, то ли баг поймал. Не вспомнил :( Но в итоге перешёл на SNMP и snmp-exporter, благо последний для разных других железок всё равно нужен. Поскольку не вспомнил про конкретные фатальные недостатки mktxp, то не буду говорить, что мой вариант лучше - просто скажу, что есть и такой способ тоже.


  1. izuru_hitachi
    30.12.2024 16:10

    Лично у меня микроты мониторятся заббиксом по SNMP, мне этого более чем хватает. Особенно на 7 версии заббикса...

    Смысл городить связку MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana, когда достаточно SNMP ⟶ Zabbix? Для мониторинга доступности микротов, заббикса хватает с головой.

    Ну можно ещё экспорт данных в графану настроить, по желанию, для красоты.


    1. m1skam
      30.12.2024 16:10

      /sarcasm-on

      Смысл городить связку SNMP ⟶ Zabbix, когда связки SNMP ⟶ "любимая технология" достаточно, ведь у меня все работает на "любимой технологии" и мне этого более чем хватает.

      /sarcasm-off

      Zabbix отличное решение на своем месте и для своих задач, но не нужно утверждать, что все сетевые железки должны мониториться только им, просто потому что кому то "хватает". Лично мне не хватает и в моем окружении они мониторятся связкой SNMP - snmp-exporter - prometheus - mimir - grafana, у меня свои задачи и Zabbix мне в них не поможет.


    1. sunatchi Автор
      30.12.2024 16:10

      Подход с заббиксом и SNMP действительно надёжное решение, особенно если вся линия поддержки опирается в основном на его данные, но связка MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana тоже имеет место быть, так как даёт больше гибкости. Например, некоторые метрики недоступны через SNMP, ввиду того, что мы будем упираться в возможности OID (например, мониторинг DHCP — leases, pool, PPP, Hotspot — users, sessions, или Firewall — количество соединений по каждому правилу), а через API они легко тянутся. К тому же API позволяет опрашивать устройства чаще, чем SNMP.
      В конечном итоге выбор инструмента зависит от ваших требований к мониторингу, ведь как говорится, важен не инструмент, а результат, который он приносит.


    1. Grand_piano
      30.12.2024 16:10

      Да не только доступности. Zabbix 6-7 + универсальный шаблон под Микроты, закрывают процентов 98 от потребностей. Остальное довешиваем руками. Если уж совсем дело швах, но тогда вполне можно начать мониторить другие метрики так или иначе связанные с целью. Хотя по опыту тяжело себе представляю, что в Микроте по SNMP нельзя вытащить. У них одно из лучших покрытий в индустрии SNMP метриками своего железа. D-link до сих пор к этому не может даже близко подойти. Про Cisco молчу, там всё не так плохо, как у D-LINK, но тоже случаются необъяснимости.


  1. Grand_piano
    30.12.2024 16:10

    Читаю и понимаю, что если у человека есть молоток, то всё вокруг становится гвоздями. Ребята, мониторить сетевое оборудование инструментами, которые создавались не совсем для этого (Prometheus).... Да можно конечно, но это не гвоздь, это шуруп.... SNMP+ZABBIX более чем закрывает эту проблематику + прекрасно реализованные алерты Zabbbix. Хочется красоты - да не вопрос, накрутите Grafana. Но зачем такая избыточность, сложность. Ужас конечно. Молодцы что справляетесь, плохо что таким образом.

    С совы сыпятся перья, но вы упорно тянете её на глобус DevOps. Мониторинг инфраструктуры через экспортеры.... Ну ок, что тут скажешь.


    1. sunatchi Автор
      30.12.2024 16:10

      Спасибо за мнение! улыбнуло)
      SNMP + Zabbix действительно отлично закрывает большинство задач и проверено временем. Но, как говорится, "кому шашечки, а кому ехать" :)
      Prometheus, конечно, изначально заточен под мониторинг сервисов и приложений, а не сетевого железа. Однако, когда в инфраструктуре уже крутится Prometheus, добавление MKTXP или подобных экспортеров – это скорее путь наименьшего сопротивления, чем попытка забить шуруп молотком. Так же выше я описал в комментарии, что по API мы получим больше метрик, может кому-то необходимо визуализировать правила по firewall, или мониторить dB кажного Wi-Fi клиента.
      С другой стороны, SNMP и Zabbix прекрасно справляются с задачами мониторинга железа. особенно когда дело касается базовых метрик и алертов.Тут согласен, что прямые инструменты проще и надёжнее.
      В общем, это как спорить, что лучше – отвертка или шуруповёрт. Оба крутят, просто с разной скоростью и удобством :)


      1. sirmax123
        30.12.2024 16:10

        Для уровней клиентов есть автодискавери в заббиксе, все можно.

        Но самый правильный ответ на вопрос «а чего прометей» это да, банально, он уже есть, а мы хотим один мониторинг

        Ps

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

        Jmx через экспортер кстати тоже работает лучше чем встроенный в хаббикс.


  1. radiolok
    30.12.2024 16:10

    О, а это мысль. спасибо. А то намедни обнаружил, что у меня аплинк до провайдера поднят на 100мбит вместо 1гбит. А я все ркн винил :D Оказалось в этажном щите КЗ на одной из пар - как кстати такие фейлы такое мониторить вообще? Линк поднят, ошибок в логах нету.. а autonegotiation отключать не хочется.


    1. scarab
      30.12.2024 16:10

      Изменение режима работы интерфейса даже стандартным темплейтом заббикса отслеживается.

      Ну а первоначальное значение - кто ж, кроме Вас, его знать должен? Просто в интерфейсе видно.


  1. Antra
    30.12.2024 16:10

    Можно ли узнать все доступные метрики? В частности, меня интересуют графики скорости на туннелях Wireguard и Zerotier.