RouterOS logging is a little routing engine of its own: events are tagged with topics, and rules send matching topics to actions — the memory ring, disk, or a remote syslog server. Master that one model and you can log exactly what you want, where it survives. Miss it and you'll wonder why the log is empty after a reboot, or why your flash is dying. The Cisco twin is Cisco IOS: Syslog & Logging; for metrics see MikroTik + Prometheus.
Three nouns run RouterOS logging. A topic is what the message is about — firewall, dhcp, system, error, account. An action is where a message goes — the built-in memory (a RAM ring buffer), disk, echo (console), or a remote syslog target you define. A rule (/system logging) ties a set of topics to one action.
The defaults log almost everything to memory, which vanishes on reboot and holds only a few hundred lines. For anything you need to keep — security events, an audit trail, the evidence after an incident — you add a remote action and route the topics you care about to it. That, plus not killing your flash, is the whole job.
01
Everything starts here. Look at what RouterOS already logs, then understand that each line is a topic set routed to an action by a rule.
# See the shipped rules: info/error/warning/critical → memory, etc. [admin@edge] > /system/logging/print [admin@edge] > /system/logging/action/print # memory, disk, echo, remote # Logs are stamped in local time — sync the clock or the timeline lies. [admin@edge] > /system/clock/set time-zone-name=Europe/Athens [admin@edge] > /system/ntp/client/set enabled=yes servers=10.0.0.1
If your NTP server is configured as a hostname and your resolver is down (or you've just moved upstream DNS to DoH, which needs a valid clock), the clock never syncs and every log line carries the wrong time — or 1970. Point /system/ntp/client at an IP, or add a /ip/dns/static entry for the NTP host, so time sync doesn't depend on name resolution. Confirm with /system/ntp/client/print showing status: synchronized.
02
Define a remote action, then add rules routing the topics you want to keep. This is the one change that turns volatile RAM logs into a durable record.
# 1. Define WHERE: a remote syslog target, sourced from a stable IP. [admin@edge] > /system/logging/action add name=remote target=remote \ remote=10.0.0.5 remote-port=514 src-address=10.0.0.1 \ bsd-syslog=yes syslog-facility=local0 # 2. Route WHAT: send the topics worth keeping to that action. [admin@edge] > /system/logging add topics=info action=remote [admin@edge] > /system/logging add topics=error,warning,critical action=remote [admin@edge] > /system/logging add topics=account action=remote # logins / logouts
Topics combine, and a leading ! excludes. topics=firewall,!debug means "firewall events, but not the debug-level ones." That's how you log all firewall drops to the collector without the per-packet debug flood. Keep the memory action for live troubleshooting (/log/print follow) and the remote action for the durable, filtered record — the same split as a Cisco local buffer plus a collector.
03
A drop rule is silent unless you ask it to log. Add log=yes with a prefix, and those events flow into the firewall topic — and on to your collector.
# Tag logged hits with a prefix so the collector can filter/alert on it. [admin@edge] > /ip/firewall/filter add chain=input action=drop \ in-interface-list=WAN log=yes log-prefix="WAN-DROP:" # Route the firewall topic (minus debug noise) to the remote collector. [admin@edge] > /system/logging add topics=firewall,!debug action=remote
Put log=yes on a high-traffic accept rule (or a port-scanned WAN drop) and RouterOS generates a log line per packet — thousands a second under a scan. That floods the memory ring (evicting everything useful), hammers a disk action, and can saturate the syslog link. Log decisions, not traffic: drops and rejects, new connections (connection-state=new), and auth events — never an established-traffic accept. If you need volume accounting, that's a job for metrics, not syslog.
04
The two ways RouterOS logging quietly fails: the disk action wears out flash, and the memory action silently overwrites itself. Know which action persists and which doesn't.
| Action | Behaviour & caution |
|---|---|
| memory | RAM ring, lines= cap; fast, lost on reboot, overwrites oldest silently |
| disk | Persists reboots, but writes wear NAND flash — don't point verbose topics here on a routerboard |
| remote | UDP/514 by default — fire-and-forget, no delivery guarantee, spoofable |
| echo | Console/terminal only; for live watching, not retention |
# Give memory a bigger ring for live troubleshooting. [admin@edge] > /system/logging/action/set memory memory-lines=2000 # If you MUST log to disk, cap files and stop-on-full to limit writes. [admin@edge] > /system/logging/action/set disk disk-lines-per-file=5000 \ disk-file-count=4 disk-stop-on-full=no # Better: keep retention off-box on the collector, disk only as a buffer.
05
[admin@edge] > /system/logging/print # rules: topics→action [admin@edge] > /log/print where topics~"firewall" # filter live log [admin@edge] > /log/print follow where topics~"account" [admin@edge] > /system/ntp/client/print # status: synchronized # On the collector: tcpdump udp port 514 — confirm lines actually arrive.
Takeaways
remote action and route the topics you need to keep, or they're gone at the next reboot.! — topics=firewall,!debug — and log firewall decisions, never established traffic.Default MikroTik logging keeps a few hundred lines in RAM and loses them the moment it matters. I set up topic-routed remote logging across RouterOS fleets — firewall decisions, auth events, config changes, shipped to your collector and correlated with the rest of the network. Let's make yours durable.
Book a Discovery Call →