Представьте: пятница, вечер, вы уже мысленно с бокалом чего-то крепкого и вкусного наслаждаетесь прокрастинацией. Ничего не предвещало беды, но жизни любого администратора наступает момент, когда нужно поиграть в игру "Угадай на каком этаже пропал интернет". И что бы победить непредсказуемость сетевых устройств, умные люди придумали Grafana для визуализации различных метрик, и различные экспортеры этих метрик. В данной статье рассмотрим экспортёр метрик MKTXP, который настраивается в 2 кнопки.
https://github.com/akpw/mktxp?tab=readme-ov-file
Краткий обзор инструментов
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
.
DaДобавляем Data Source:
Connection -> Data sources -> Add data source.
Выбираем Prometheus и указываем URL
http://prometheus:9090
.Сохраняем и тестируем подключение кнопкой Save & test.
Теперь когда у нас добавлен источник для данных, осталось добавить Dashboard для мониторинга MikroTIk.
Импорт Dashboard:
Переходим в Dashboard -> Import.
Указываем ссылку на официальный дашборд MKTXP.
Нажимаем Load, выбираем источник данных Prometheus и импортируем.
После чего мы должны увидеть метрики с нашего роутера.
Заключение
Использование MKTXP в связке с Prometheus и Grafana позволяет построить довольно гибкую систему мониторинга MikroTik. Простота установки и конфигурации делает это решение доступным даже для администраторов с базовыми знаниями. Это решение даёт возможность вытаскивать множество различных данных из RouterOS "из коробки". Ведь в нашей не простой работе, чем меньше аварий, тем больше времени остаётся на кофебрейки и просмотр мемов, и конечно же просмотр статей на хабре :)
Комментарии (11)
izuru_hitachi
30.12.2024 16:10Лично у меня микроты мониторятся заббиксом по SNMP, мне этого более чем хватает. Особенно на 7 версии заббикса...
Смысл городить связку MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana, когда достаточно SNMP ⟶ Zabbix? Для мониторинга доступности микротов, заббикса хватает с головой.
Ну можно ещё экспорт данных в графану настроить, по желанию, для красоты.
m1skam
30.12.2024 16:10/sarcasm-on
Смысл городить связку SNMP ⟶ Zabbix, когда связки SNMP ⟶ "любимая технология" достаточно, ведь у меня все работает на "любимой технологии" и мне этого более чем хватает.
/sarcasm-off
Zabbix отличное решение на своем месте и для своих задач, но не нужно утверждать, что все сетевые железки должны мониториться только им, просто потому что кому то "хватает". Лично мне не хватает и в моем окружении они мониторятся связкой SNMP - snmp-exporter - prometheus - mimir - grafana, у меня свои задачи и Zabbix мне в них не поможет.
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.
В конечном итоге выбор инструмента зависит от ваших требований к мониторингу, ведь как говорится, важен не инструмент, а результат, который он приносит.
Grand_piano
30.12.2024 16:10Да не только доступности. Zabbix 6-7 + универсальный шаблон под Микроты, закрывают процентов 98 от потребностей. Остальное довешиваем руками. Если уж совсем дело швах, но тогда вполне можно начать мониторить другие метрики так или иначе связанные с целью. Хотя по опыту тяжело себе представляю, что в Микроте по SNMP нельзя вытащить. У них одно из лучших покрытий в индустрии SNMP метриками своего железа. D-link до сих пор к этому не может даже близко подойти. Про Cisco молчу, там всё не так плохо, как у D-LINK, но тоже случаются необъяснимости.
Grand_piano
30.12.2024 16:10Читаю и понимаю, что если у человека есть молоток, то всё вокруг становится гвоздями. Ребята, мониторить сетевое оборудование инструментами, которые создавались не совсем для этого (Prometheus).... Да можно конечно, но это не гвоздь, это шуруп.... SNMP+ZABBIX более чем закрывает эту проблематику + прекрасно реализованные алерты Zabbbix. Хочется красоты - да не вопрос, накрутите Grafana. Но зачем такая избыточность, сложность. Ужас конечно. Молодцы что справляетесь, плохо что таким образом.
С совы сыпятся перья, но вы упорно тянете её на глобус DevOps. Мониторинг инфраструктуры через экспортеры.... Ну ок, что тут скажешь.
sunatchi Автор
30.12.2024 16:10Спасибо за мнение! улыбнуло)
SNMP + Zabbix действительно отлично закрывает большинство задач и проверено временем. Но, как говорится, "кому шашечки, а кому ехать" :)
Prometheus, конечно, изначально заточен под мониторинг сервисов и приложений, а не сетевого железа. Однако, когда в инфраструктуре уже крутится Prometheus, добавление MKTXP или подобных экспортеров – это скорее путь наименьшего сопротивления, чем попытка забить шуруп молотком. Так же выше я описал в комментарии, что по API мы получим больше метрик, может кому-то необходимо визуализировать правила по firewall, или мониторить dB кажного Wi-Fi клиента.
С другой стороны, SNMP и Zabbix прекрасно справляются с задачами мониторинга железа. особенно когда дело касается базовых метрик и алертов.Тут согласен, что прямые инструменты проще и надёжнее.
В общем, это как спорить, что лучше – отвертка или шуруповёрт. Оба крутят, просто с разной скоростью и удобством :)sirmax123
30.12.2024 16:10Для уровней клиентов есть автодискавери в заббиксе, все можно.
Но самый правильный ответ на вопрос «а чего прометей» это да, банально, он уже есть, а мы хотим один мониторинг
Ps
Заббикс лет сто как умеет читать метрики с экспортеров прометея, из коробки. Я решал строго обратную задачу, к заббиксу крутил метрики которые отдавал экспортер встроенный в приложение
Jmx через экспортер кстати тоже работает лучше чем встроенный в хаббикс.
radiolok
30.12.2024 16:10О, а это мысль. спасибо. А то намедни обнаружил, что у меня аплинк до провайдера поднят на 100мбит вместо 1гбит. А я все ркн винил :D Оказалось в этажном щите КЗ на одной из пар - как кстати такие фейлы такое мониторить вообще? Линк поднят, ошибок в логах нету.. а autonegotiation отключать не хочется.
scarab
30.12.2024 16:10Изменение режима работы интерфейса даже стандартным темплейтом заббикса отслеживается.
Ну а первоначальное значение - кто ж, кроме Вас, его знать должен? Просто в интерфейсе видно.
Antra
30.12.2024 16:10Можно ли узнать все доступные метрики? В частности, меня интересуют графики скорости на туннелях Wireguard и Zerotier.
aborouhin
Долго пытался вспомнить, почему в итоге отказался от mktxp.... то ли метрик каких-то не хватило, то ли баг поймал. Не вспомнил :( Но в итоге перешёл на SNMP и snmp-exporter, благо последний для разных других железок всё равно нужен. Поскольку не вспомнил про конкретные фатальные недостатки mktxp, то не буду говорить, что мой вариант лучше - просто скажу, что есть и такой способ тоже.