The observability post got logs and flow off the box. This gets you the other half — time-series metrics and dashboards. RouterOS doesn't speak Prometheus natively, so you bolt on an exporter that reads the API and turns it into metrics — and the neat part is you can run that exporter in a container on the router itself.
SNMP graphing is fine until you want per-interface, per-queue, per-DHCP-lease, per-BGP-session detail with real dashboards and alerting. That's the Prometheus + Grafana stack: Prometheus scrapes numeric metrics on an interval and stores them as time series; Grafana draws them. RouterOS has no native Prometheus endpoint, so the missing piece is an exporter — a small program that logs into the RouterOS API, pulls the stats, and republishes them at a /metrics URL Prometheus understands. The popular one is mktxp, which exposes far more than SNMP ever did.
Two ways to run the exporter: on your monitoring host (simplest), or — the elegant option — in a container on the router itself. Either way this extends Observability from "logs and flow" to "metrics and dashboards," and it leans on a properly locked-down API, so it also exercises the hardening post.
api-ssl, restricted to the scraper01
The exporter only reads. Give it its own least-privilege account over the encrypted API, restricted to the scraper's address — never your admin login.
# A group that can read + use the API and nothing else. > /user group add name=prom policy=read,api,winbox,!write,!policy,!ftp > /user add name=mktxp group=prom password="read-only-secret" # Expose the ENCRYPTED api only, to the monitoring host only. > /ip service set api-ssl address=10.10.99.10/32 certificate=api-cert disabled=no > /ip service disable api # kill plaintext api
A monitoring integration that holds full admin credentials is a liability — if the metrics host is compromised, so is every router. The read-only, API-only, source-restricted account limits the blast radius to "an attacker can read stats," which is the correct trade. This is the same discipline as the SNMPv3-not-v2c argument in Observability: monitoring should never be a privilege-escalation path.
02
mktxp connects to the API, collects a broad set of RouterOS metrics, and serves them at :49090/metrics. Point it at each router in a small config file.
[CoreRTR] hostname = 10.10.0.1 port = 8729 # api-ssl username = mktxp password = read-only-secret use_ssl = True dhcp = True # lease counts pool = True interface = True # per-interface traffic/errors firewall = True bgp = True # session state, prefixes queue = True # per-queue bytes/drops $ mktxp export # serves metrics on :49090/metrics # Run it on the monitoring host, or in a container on the router # (a veth + this config baked into the image) per the containers post.
03
Add a scrape job pointing at the exporter. Prometheus polls it on your interval and stores every series.
scrape_configs: - job_name: 'mikrotik' static_configs: - targets: ['127.0.0.1:49090'] # the mktxp exporter scrape_interval: 30s # Confirm the target is UP in the Prometheus UI (Status -> Targets), # then try a query, e.g. rate of interface bytes: rate(mktxp_interface_tx_byte{name="ether1"}[5m])
04
Add Prometheus as a data source, import a ready-made mktxp dashboard, then wire alerts on the metrics that actually page you at 2am.
# 1. Add data source: Prometheus, URL http://prometheus:9090 # 2. Import the community mktxp dashboard (Dashboards -> Import -> ID). # 3. Alert rules worth having from day one: - BGP session down: mktxp_bgp_session_state != 1 - WAN interface down: mktxp_interface_running{name="ether1"} == 0 - Disk/CPU pressure: mktxp_system_cpu_load > 90 for 5m - Queue drops rising: rate(mktxp_queue_dropped[5m]) > 0
Because Prometheus scrapes by target, adding routers is just more entries in mktxp.conf — the Cisco boxes can sit on the same Grafana via SNMP or their own exporter, so a mixed estate lands on one dashboard. Metrics (this post) + logs and flow together are the full observability picture: metrics tell you that something changed and when, logs and flow tell you what. Wire the alerts before you need them, not after the outage.
Takeaways
/metrics.api-ssl — monitoring must never hold admin creds.NOCTIS builds Prometheus + Grafana monitoring for MikroTik and Cisco estates across Crete — real dashboards, sensible alerts, and metrics that catch the problem before the guests do.
Book a Discovery Call →