Skip to content

Graphing

Graphing is a tool to monitor various RouterOS parameters over time and display collected data in visual graphs. This feature enables network administrators to track performance metrics, identify trends, and troubleshoot issues based on historical data.

The Graphing tool can display graphics for:

  • Resource usage: CPU utilization, memory consumption, and disk space usage
  • Interface traffic: Bandwidth usage passed through network interfaces
  • Queue traffic: Traffic passed through simple queues with QoS applied

Graphing consists of two main components. The first component collects and stores performance data at regular intervals. The second component serves as a web interface that renders the collected data into visual graphs accessible through a web browser.

To access the graphs, navigate to http://[Router_IP_address]/graphs/ in your web browser. The interface displays all enabled graphs organized by category, allowing you to select and view specific metrics over customizable time periods.

Access graphing data through the built-in web server by visiting http://[router_ip]/graphs/. The page refreshes automatically according to the configured refresh interval (default: 300 seconds).

From the WebFig interface, locate the menu icon (≡) in the top right corner and select “graphs” from the navigation menu.

WinBox provides a dedicated graphing window accessible through Tools → Graphing. Double-click on any enabled entry to view its graphs. The WinBox interface displays the same information as the web interface but within the native application.

RouterOS graphing uses RRDtool to generate static PNG graph images. Each graph is available in four time ranges: daily (last 24 hours), weekly (last 7 days), monthly (last 30 days), and yearly (last 365 days).

The graphing system is configured under /tool graphing. By default, graphing is disabled on all devices. Enable specific graphing categories by configuring their respective submenus.

/tool graphing
PropertyDescriptionDefault
store-everyHow often to write collected data to system drive (24hours, 5min, hour)5min
page-refreshHow often the graph page auto-refreshes in seconds (or ‘never’)300

Enable graphing with hourly data storage and a 60-second page refresh:

/tool graphing
set store-every=hour page-refresh=60

The store-every parameter controls data resolution and storage requirements. More frequent storage (5min) provides higher resolution but consumes more storage space. Less frequent storage (hour or 24hours) reduces storage needs but provides less granular historical data.

Interface graphing monitors bandwidth utilization for specified network interfaces. This feature helps identify traffic patterns, detect bandwidth congestion, and monitor network utilization trends.

/tool graphing interface
PropertyDescriptionDefault
allow-addressIP address range from which graphing information is accessible (IP/IPv6 prefix)0.0.0.0/0
commentDescription of the graphing entry(none)
disabledWhether the graphing entry is active (yes, no)no
interfaceInterface to monitor (all, or specific interface name)all
store-on-diskWhether to store collected data on system drive (yes, no)yes

Monitor all interfaces with unrestricted access:

/tool graphing interface
add interface=all

Monitor a specific interface with restricted access:

/tool graphing interface
add interface=ether1 allow-address=192.168.88.0/24

Monitor multiple specific interfaces:

/tool graphing interface
add interface=ether1
add interface=ether2
add interface=sfp-sfpplus1

Disable storage for memory-constrained devices:

/tool graphing interface
set [find] store-on-disk=no

The interface parameter accepts either all to monitor every interface on the router, or a specific interface name to limit monitoring to that interface. When monitoring all interfaces, each interface generates a separate graph.

Access control via allow-address restricts which clients can view the graphs. Set this to specific subnets or individual IP addresses to prevent unauthorized access to performance data.

Queue graphing monitors traffic that passes through simple queues. This feature is useful for tracking bandwidth consumption per queue, verifying QoS policies, and identifying traffic patterns for specific clients or services.

/tool graphing queue
PropertyDescriptionDefault
allow-addressIP address range from which graphing information is accessible0.0.0.0/0
allow-targetAllow access from queue’s target-address (yes, no)yes
commentDescription of the graphing entry(none)
disabledWhether the graphing entry is active (yes, no)no
simple-queueQueue to monitor (all, or specific queue name)all
store-on-diskWhether to store collected data on system drive (yes, no)yes

Monitor all queues:

/tool graphing queue
add simple-queue=all

Monitor a specific queue:

/tool graphing queue
add simple-queue=LAN_Clients

Restrict access to internal network only:

/tool graphing queue
add simple-queue=all allow-address=192.168.88.0/24 allow-target=no

If a simple queue has target-address set to 0.0.0.0/0 (all addresses), clients can access queue graphs even when allow-address is configured for a specific subnet. This occurs because queue graphs are accessible by default from the queue’s target address. Set allow-target=no to prevent this behavior:

/tool graphing queue
add simple-queue=all allow-target=no

Resource graphing monitors system resource utilization including CPU, memory, and disk usage. This feature is essential for capacity planning, performance troubleshooting, and identifying resource exhaustion before it causes service disruption.

/tool graphing resource

The resource graphing feature tracks the following metrics:

  • CPU usage: Percentage of processor utilization over time
  • Memory usage: RAM consumption including used, free, and cached memory
  • Disk usage: Storage utilization for system partitions and mounted volumes
PropertyDescriptionDefault
allow-addressIP address range from which graphing information is accessible0.0.0.0/0
commentDescription of the graphing entry(none)
disabledWhether the graphing entry is active (yes, no)no
store-on-diskWhether to store collected data on system drive (yes, no)yes

Enable resource monitoring:

/tool graphing resource
add

Restrict access to management network:

/tool graphing resource
add allow-address=10.0.0.0/8

Disable disk storage for devices with limited flash memory:

/tool graphing resource
set [find] store-on-disk=no

Enable all graphing features with appropriate access controls:

/tool graphing
set store-every=5min page-refresh=300
/tool graphing interface
add interface=all allow-address=192.168.88.0/24
/tool graphing queue
add simple-queue=all allow-address=192.168.88.0/24 allow-target=no
/tool graphing resource
add allow-address=192.168.88.0/24

Monitor traffic on specific VLAN interfaces while excluding physical interfaces:

/tool graphing interface
add disabled=yes interface=all
add interface=vlan10
add interface=vlan20
add interface=vlan30

Monitor bandwidth usage for a guest network queue with restricted access:

/tool graphing queue
add simple-queue=Guest-Network allow-address=192.168.100.0/24

Configure graphing for devices with limited storage:

/tool graphing
set store-every=hour
/tool graphing interface
add interface=all store-on-disk=no
/tool graphing queue
add simple-queue=all store-on-disk=no
/tool graphing resource
add store-on-disk=no
  1. Open a web browser and navigate to http://[router_ip]/graphs/
  2. Select the graph category (Interfaces, Queues, or Resources)
  3. Choose the specific interface, queue, or resource to view
  4. Use the time range selector to adjust the displayed period
  • Time range: Each graph is shown in four views — daily (last 24 hours), weekly, monthly, and yearly
  • Refresh interval: Configured via page-refresh property (default: 300 seconds)
  1. Open WinBox and connect to the router
  2. Navigate to Tools → Graphing
  3. The window displays all enabled graphing entries
  4. Double-click an entry to view its graphs
  5. Use the toolbar to adjust time ranges and refresh settings

Limitations Compared to External Monitoring

Section titled “Limitations Compared to External Monitoring”

RouterOS graphing is a lightweight, zero-dependency solution for visualizing router-local metrics. For many small deployments it is sufficient, but it has meaningful constraints when compared with dedicated monitoring stacks.

  • Single-router visibility (no multi-device correlation)
  • Three metric types: interfaces, simple queues, and system resources
  • Four fixed time ranges: daily, weekly, monthly, yearly
  • Data stored locally on the router; accessible via HTTP only
  • No alerting, thresholds, or notification delivery
CapabilityRouterOS GraphingSNMP + Zabbix / PRTGThe Dude
Multi-deviceSingle router onlyUnlimited devicesLAN-discovered devices
Metric coverageCPU, RAM, disk, interfaces, queuesAny OID; custom MIBs; agent itemsSNMP + Dude probes
AlertingNoneFull: email, SMS, webhooks, escalationBasic triggers and notifications
RetentionFixed (up to 1 year via RRD)Configurable; months to yearsConfigurable
Custom dashboardsNoneAdvanced (Grafana, built-in)Basic
InstallationNone (built-in)Requires dedicated serverWindows app or CHR
Suitable forQuick per-router visibilityProduction NOC monitoringSmall/medium MikroTik networks

Use built-in graphing when:

  • You need a quick snapshot of one router’s health without installing anything
  • The deployment is a single router or very small network
  • Storage or server resources are unavailable for an external stack
  • You want a sanity check on traffic trends without SNMP configuration

Use SNMP-based monitoring (Zabbix, PRTG, Grafana/InfluxDB) when:

  • You manage multiple routers or a mixed-vendor network
  • You need alerting, on-call escalation, or SLA reporting
  • Long-term trending and capacity planning are required
  • You need metrics beyond what graphing exposes (BGP prefixes, OSPF adjacency, hardware sensors on supported devices)

Use The Dude when:

  • Your network is predominantly MikroTik
  • You want auto-discovery and topology maps
  • A lightweight Windows-based NMS is acceptable
  • You do not need the scalability of a full SNMP stack