Logs

The built-in receiver

The manager ships its own syslog listener — UDP and TCP, both on port 5514, both enabled by default. Messages are stored and streamed live to the Logs page as they arrive.

TCP is worth choosing when UDP is filtered somewhere in the path, or when you would rather have delivery than speed; RouterOS 7 supports both.

Configuring a device

Nothing is collected until a router is told to send. The Logs page has a Setup Guide that generates the commands with your manager's own address already filled in, and can hand them over as a ready script — use it rather than retyping the shape below:

/system logging action add name=mgr target=remote remote=<MANAGER_IP> remote-port=5514
/system logging add topics=info action=mgr
/system logging add topics=warning action=mgr
/system logging add topics=error action=mgr
/system logging add topics=critical action=mgr

For TCP instead of UDP the action carries remote-protocol=tcp. Which topics you send is your decision — the four above are a reasonable default, and adding more means more volume to store.

Messages appear as they do in the device's own log. The receiver also accepts the RFC3164-style forms, so a device configured the BSD way still lands correctly.

Reading the page

Every line names the router it came from, in its own column between the time and the topics. The name links to that device, and hovering the line spells it out in full together with the exact time and the severity — worth knowing when a fleet's names all begin the same way and the column has to trim them. A line the manager could not attribute reads Unknown with the address it arrived from.

The filters above the stream narrow it by site, by device, by severity, by topic, by text in the message, and by time — either one of the preset ranges or a from/to of your own. They combine, and they apply to entries arriving live as well as to what is already on screen, so a view narrowed to one site stays that way as new lines come in. On an install with a long device list, the box beside the device selector narrows it by name or address, and choosing a site narrows it to that site's routers on its own.

Pause holds the view still while you read something, counting what arrives meanwhile and releasing it when you resume. Auto-scroll keeps you at the newest entry and switches itself off when you scroll away to read, back on when you return to the top. Load older at the foot of the list walks backwards through what is stored.

When a filter matches nothing, the page says so. That is a different message from the empty page you get before any device has been configured to send, which offers the setup guide instead.

How a log finds its device

Incoming messages are matched to a device by any of its interface addresses, collected on each poll — not only by the address you manage it on. That is why a router with several addresses does not need its source address pinned for logs to be attributed correctly.

A device you added by a name rather than an address — an IP/Cloud name, or any other dynamic-DNS name — has that name resolved, and the address it points to is matched as well. A changed address is picked up within two minutes. Where two devices resolve to the same address, which is what happens when several routers sit behind one NAT, their lines are deliberately left unattributed: a log line labelled with the wrong router is worse than one labelled with none.

If nothing matches on address, the manager falls back to the hostname in the message, comparing it against the device's name and its RouterOS identity. That field only exists when the logging action is set to bsd-syslog=yes; with the default format there is no hostname to read.

If entries show up as unknown with a bare IP just after setup, the usual cause is that the manager has not polled that device since, so it does not yet know that address belongs to it. Waiting for a poll normally fixes it; pinning the source address on the logging action fixes it immediately.

Retention

Logs are pruned on two axes so that neither a long quiet period nor one very chatty device fills the database: by age, seven days by default, and by rows per device, ten thousand by default. Both are adjustable in Settings, and either can be overridden for a single device on its own form — useful when one router matters more, or talks far more, than the rest.

Scoped users see the logs of their own sites only, the same as everywhere else.

Exporting logs

To hand logs to someone else, such as your provider or a colleague, set the filters on the Logs page or on a device's Logs tab so they show what you need, then press Export. You can choose between two formats:

• CSV opens in Excel or LibreOffice, one column per field, with both local time and UTC.
• Plain text puts one entry per line, like the device's own log. A short header at the top records the time zone and the filter that was used, so it can be pasted into an email as it is.

The file holds everything the filter matches, not only the rows on screen, oldest first and in your browser's time zone. One export stops at the newest 100,000 entries. When there are more, the page says so, and a narrower time range gets you the older ones.

An export follows the same site access as the page, so a scoped user exports only the logs of their own sites.

What else the log stream feeds

The log receiver is not only a viewer. Repeated failed logins seen in this stream are what the auto-block feature counts, aggregated per source address across the whole fleet — so switching on log collection is also what makes that feature possible. It is opt-in per device and has an audit-only mode; the Security page is where it lives.