The necessity of real-time visibility into network infrastructure cannot be overstated in modern enterprise environments. For administrators managing MikroTik RouterOS ecosystems, the ability to move beyond reactive troubleshooting into proactive, data-driven observability is a critical requirement. Achieving this level of insight requires a sophisticated telemetry pipeline capable of ingesting Simple Network Management Protocol (SNMP) data, processing it through a high-performance time-series database, and visualizing it through an interactive dashboarding engine. This deployment architecture utilizes the industry-standard Prometheus-Grafana-SNMP stack, specifically optimized for MikroTik hardware, to provide a unified view of interface traffic, CPU utilization, memory pressure, and 60GHz wireless link stability.
By implementing a containerized approach—leveraging Docker and Docker Compose—administrators can deploy a reproducible, scalable monitoring blueprint. This stack does not merely report uptime; it enables the detection of subtle performance degradations, such as interface errors or queue buildup, before they escalate into network-wide outages. The integration of the snmp_exporter acts as the vital translation layer, converting the unstructured, request-response nature of SNMP into the pull-based, metric-centric format required by Prometheus.
The Modular Architecture of MikroTik Telemetry
The monitoring ecosystem is comprised of four distinct, interacting layers, each serving a specific role in the lifecycle of a metric. Understanding the relationship between these components is essential for successful deployment and troubleshooting of the telemetry pipeline.
The first layer is the MikroTik RouterOS device itself, acting as the primary data producer. This device holds the raw state information—interface statistics, system uptime, and hardware-level metrics—accessible via the SNMP protocol. Because the device is the source of truth, its configuration (specifically SNMP community strings and versioning) dictates the success of the entire monitoring chain.
The second layer is the snmp_exporter. This component functions as a proxy. Prometheus, being a pull-based system, is not natively designed to "speak" SNMP. The snmp_exporter listens for scrape requests from Prometheus, executes the necessary SNMP GET or WALK operations against the MikroTik target, and transforms the resulting OIDs (Object Identifiers) into a structured format that Prometheus can understand.
The third layer is Prometheus, the time-series database and orchestrator. Prometheus is responsible for the periodic polling of the snmp_exporter. It stores the incoming data points in a high-efficiency format, allowing for complex mathematical queries and long-term trend analysis. It is the engine that calculates rates of change, such as bits-per-second on a specific WAN interface.
The fourth and final layer is Grafana, the visualization engine. Grafana connects to Prometheus as a data source and maps the numeric series to visual elements like time-series graphs, gauges, and heatmaps. It provides the human-readable interface that network engineers use to monitor the health of the network.
| Component | Role | Primary Protocol | Key Configuration Responsibility |
|---|---|---|---|
| MikroTik RouterOS | Data Producer | SNMP (v2c or v3) | SNMP Community, IP Access Lists, v3 Credentials |
snmp_exporter |
Protocol Translator | SNMP to Prometheus Metric | snmp.yml configuration and OID mapping |
| Prometheus | Time-Series Database | HTTP (Scrape) | prometheus.yml target definitions and scrape intervals |
| Grafana | Visualization Layer | HTTP (Query) | Data Source connection and Dashboard JSON imports |
Automated Deployment via Docker-Compose and Bash Orchestration
For rapid deployment, the Grafana-Mikrotik project provides a streamlined orchestration method using a bash-based deployment script. This approach is ideal for engineers who require a "ready to use" blueprint without the manual overhead of configuring each individual container service.
The deployment can be initiated through a single command that pulls the necessary scripts and executes the configuration logic:
curl -fsSL https'://raw.githubusercontent.com/IgorKha/Grafana-Mikrotik/master/run.sh | bash -s -- --config
This automated script performs several critical operations. When the --config flag is passed, the script enters an interactive or automated mode to modify the default Grafana credentials and, more importantly, to inject the MikroTik IP address into the configuration files. This eliminates the need for manual file editing for basic setups.
For those preferring a manual, transparent approach—often necessary when integrating the stack into existing DevOps pipelines—the process involves cloning the repository and managing the services via docker-compose.
The manual deployment workflow is as follows:
Clone the deployment repository to the local host:
git clone https://github.com/IgorKha/Grafana-Mikrotik.git && cd Grafana-MikrotikModify the Prometheus target configuration. The
prometheus/prometheus.ymlfile must be edited to point to the actual IP address of the MikroTik device. Use a text editor likenano:
nano prometheus/prometheus.pyWithin the
prometheus.ymlfile, ensure thetargetssection reflects your hardware:
```yaml
jobname: 'Mikrotik'
staticconfigs:- targets:
- 192.168.88.1 # Replace with your actual SNMP device IP
metricspath: /snmp
params:
module: [mikrotik]
relabelconfigs:
- 192.168.88.1 # Replace with your actual SNMP device IP
- sourcelabels: [address]
targetlabel: _paramtarget - sourcelabels: [paramtarget]
target_label: instance - target_label: address
replacement: localhost:9116 # Points to the SNMP exporter's hostname and port
```
- targets:
Launch the entire stack in detached mode:
docker-compose up -d
Once the containers are operational, the Grafana instance is accessible via a web browser at http://localhost:3000. The default credentials for this specific deployment are:
- Username:
admin - Password:
mikrotik
If these credentials need to be permanently altered, the .env file within the repository must be updated before the containers are restarted.
Advanced SNMP Configuration: Transitioning to SNMPv3 Security
While SNMPv2c is frequently used due to its simplicity, it lacks robust security mechanisms, as it relies on plain-text community strings. For enterprise environments, implementing SNMPv3 is a critical requirement to ensure that network telemetry cannot be intercepted or spoof/spoofed by unauthorized actors.
The following configuration must be applied on the MikroTik terminal to enable authenticated and encrypted SNMPv3 communication. This setup uses MD5 for authentication and DES for encryption, though more robust protocols like SHA and AES are recommended where supported.
On the MikroTik terminal, execute:
/snmp community add addresses=::/0 name=prometheus security=authorized read-access=yes write-access=no authentication-protocol=MD5 encryption-protocol=DES authentication-password=AUTH-PASS encryption-password=ENCR-PASS
To fully integrate the engine-id and location metadata, use the following command:
/snmp set contact=<[email protected]> enabled=yes engine-id=mikrotik location="<location-of-MikroTik>" trap-community=prometheus trap-target=<ip-address-of-Mikrotik> trap-version=3
Note that the addresses parameter should be tightened from ::/0 to the specific IP address of your Prometheus/SNMP exporter server to prevent unauthorized polling from the wider network.
Once the MikroTik side is configured, the snmp_exporter must be updated to handle the v3 handshake. This requires editing the snmp.yml file. The configuration block at the top of the file must be updated to include the version, username, and the specific authentication and privacy keys:
yaml
version: 3
auth:
security_level: authNoPriv
username: prometheus
password: AUTH-PASS
auth_protocol: MD5
priv_protocol: AES
priv_password: ENCR-PASS
context_name: mikrotik
Deep-Level Metric Collection and OID Mapping
The efficacy of a Grafana dashboard is entirely dependent on the depth of the "walk" performed by the SNMP exporter. A shallow walk results in a dashboard that shows only basic uptime, whereas a deep walk allows for the monitoring of complex structures like Simple Queues, interface aliases, and processor loads.
The snmp_exporter utilizes a modules configuration to define which OIDs to poll. A well-configured module for MikroTik should include the following essential branches:
interfaces: For monitoring bandwidth, error rates, and packet drops.mtxrQueueSimpleTable: To track the performance of Queues (Quality of Service).hrProcessorLoad: To monitor CPU utilization across all cores.hrSystemUptimeandhrSystemDate: To track device stability and restarts.hrMemorySizeandhrStorageTable: To monitor RAM and disk/flash utilization.sysUpTimeandsysDescr: For basic system identification.
A sophisticated snmp.yml configuration uses "lookups" to transform cryptic OIDs into human-readable strings. For example, mapping ifIndex to ifAlias or ifDescr ensures that a dashboard shows "WAN_Interface" instead of "Interface 1".
Example of an optimized modules configuration:
yaml
modules:
mikrotik:
walk:
- interfaces
- mtxrQueueSimpleTable
- hrProcessorLoad
- hrSystemUptime
- hrSystemDate
- hrMemorySize
- hrStorageTable
- sysUpTime
- sysDescr
lookups:
- source_indexes: [ifIndex]
lookup: ifAlias
- source_indexes: [ifIndex]
lookup: ifDescr
- source_indexes: [ifIndex]
lookup: 1.3.6.1.2.1.31.1.1.1.1
overrides:
ifAlias:
ignore: true
ifDescr:
ignore: true
ifName:
ignore: true
ifType:
type: EnumAsInfo
Furthermore, advanced users can utilize the get directive to pull specific, high-priority scalars, such as the system description or specific hardware serial numbers, which are essential for inventory management within the dashboard.
Grafana Dashboard Integration and Data Source Configuration
Once the backend (Prometheus and snmp_exporter) is operational, the final step is the configuration of the Grafana frontend. This involves two primary tasks: configuring the Prometheus Data Source and importing the dashboard JSON.
To configure the Data Source:
- Log in to Grafana (default
admin/adminor the configured.envcredentials). - Navigate to the "Settings" menu (represented by a gear icon on the lower left sidebar).
- Select "Data Sources" from the menu.
- Click "Add New Data Source" and choose "Prometheus".
- In the "HTTP" section, enter the URL where Prometheus is listening:
http://localhost:9090. - Scroll to the bottom and click "Save & Test". A green "Success" notification confirms that Grafana can successfully query the Prometheus engine.
For the visualization of metrics, users should utilize pre-built dashboards to avoid the complexity of manual panel creation. Two highly effective dashboard IDs for MikroTik monitoring are:
- Dashboard ID
14420: A comprehensive dashboard specifically designed for MikroTik monitoring, including support for 60GHz (w60G) radio links. - Dashboard ID
11589: A focused monitoring dashboard for MikroTik instances. - Dashboard ID
18460: An alternative specialized dashboard for granular device metrics.
To import these, navigate to the "Dashboards" section in Grafana, click "Import", and enter the Dashboard ID. Once imported, you must ensure the Prometheus data source is correctly mapped to the new dashboard.
Critical Infrastructure Considerations for Linux Deployment
When deploying this stack on a production Ubuntu or Debian-based server, certain system-level configurations are mandatory to ensure the stability of the Grafana service and the accessibility of the dashboard.
If performing a manual installation of Grafana Enterprise instead of using Docker, the following steps are required to ensure the service is properly integrated into the system's init system:
Install required dependencies for font rendering and system stability:
sudo apt-get install -y adduser libfontconfig1Download and install the specific Debian package (e.g., version 9.3.6):
wget https://dl.grafana.com/enterprise/release/grafana-enterprise_9.3.6_amd64.deb
sudo dpkg -i grafana-enterprise_9.3.6_amd64.debEnable the service to start on system boot and verify its status:
sudo systemctl enable --now grafana-server
sudo systemctl status grafana-serverConfigure the Uncomplicated Firewall (UFW) to permit inbound traffic on the Grafana port. Without this step, the dashboard will be inaccessible from external management workstations:
sudo ufw allow 3000
This manual approach is particularly useful when the monitoring server must reside on bare metal or within a non-containerized VM environment, providing more direct control over the underlying OS resources.
Analytical Conclusion
The deployment of a Prometheus-Grafana stack for MikroTik monitoring represents a transition from reactive network administration to a state of continuous observability. By leveraging the snmp_exporter to bridge the gap between SNMP and Prometheus, and utilizing Docker for standardized deployment, organizations can achieve a level of granular visibility that was previously inaccessible to many mid-sized enterprises.
The architecture described herein provides more than just uptime statistics; it offers a window into the deep-level operational health of the network. Through the strategic use of SNMPv3, administrators can protect their telemetry from interception, while the implementation of deep-walk OID mapping allows for the monitoring of critical components like CPU load and interface error rates. Ultimately, the success of this monitoring strategy relies on the meticulous configuration of the snmp.yml and prometheus.yml files, ensuring that the data flowing through the pipeline is both high-fidelity and actionable. As network complexity grows, particularly with the introduction of 60GHz wireless technologies, the ability to ingest and visualize these specialized metrics becomes a fundamental requirement for maintaining high-availability network infrastructure.