Hello, I put this request just for remainder as i already started a topic in general ROS.
My request is to conform Mikrotik log to RFC3164 so i can view the various messages correctly stored with their severity
many thanks
Alessandro

we have never said it's compliant to any standards, and unfortunately - right now we don't plan to make it so. it works with syslog tools already, so there is very little reason to adjust it.

Which one does it work with, if it isn`t compliant with RFCs.

all syslog tools out there!

for example with this one: http://www.kiwisyslog.com/index.php

the RFC compatibilty just ensures some grouping of message types, if you don't need that - no problem.

It is important to have this feature, e.g this way I send all cisco logs to a specific file by configuring syslog like this,

# CISCO Log
local6.* -/var/log/router.log

and setting the logging facility on the router (local6 on this case)

Or I can send firewall logs to a specific file, authentication to another etc. Large net mgmt tools rely on this hugely and I believe that mt users don`t use them so that`s why there`s no motivation to comply to rfc`s!

they are using dude

Hello all and thanks Normis for the reply.
I try to explain WHY I need this feature:
I am using syslog-ng on linux that stores all the messages in a Mysql database for all NASes and devices capable of producing such kind of log.
I have an automated script that in case of a critical error sends an sms to me. Other systems have the logs that are RFC compatible ( one of them is M0N0WALL ) I have all it's log correctly stored into my database with the correct severity. This feature is also useful for future batch processing for statistical purpose.
Hope my explanation was clear and excuse my poor english.
Many thanks and regards
Alessandro

I would also like to see RoS conform to the syslog RFC. I just replaced a Cisco router with one based on RoS. The swap was uneventful, apart from the fact the syslog messages from RoS are not being recognized by my syslog server.

I know there are "syslog" servers that run on port 514 and can handle arbitrarily formatted messages, but I'd rather just use the syslog server I have running. It already handles a variety of other network clients, so I'm not inclined to mess with it for this one special case. And it's not like the change is particular difficult -- it's just a few extra bytes in each message and one or two configurable parameters.

And by the way, the swap from Cisco to RoS really was straightforward -- congrats on putting together a great product!

Hope maybe Mikrotik is reconsidering more RFC formatting/conformance since these posts many years ago. I think remote logging and log analysis tools have become quite popular and it would be nice if Mikrotik devices were plug-and-play.

The #1 request from me would be to at least to encode SEVERITY level according to standards. So is info/warning/critical, for example, stripped in remote logging messages? I have not wiresharked to confirm this is not being passed but I would hope that my remote log server would interpret if it is. The wiki says logs are RFC 3164 but it is not coming through with simple configuration and I have selected BSD format option.

BSD option enables some options for facility and severity level but it seems like it might just allow defaults of those? Is the workaround for PRI to setup different remote logging actions for each priority, and then for every topic (or at least the main ones) to have separate rules for each topic + severity level (and + facility) you want to use? If so, adding more more info to documentation would be helpful.

And is "topic" also stripped? That would be helpful to add to the remote log output, even just in MSG rather than delineated field.

One other difficulty I have is that some MT logging is formatting events across multiple messages... basically using new messages as line feeds. So these messages do NOT have their proper context unless viewed in sequence and not really interrupted by other logs (and actually, other services on the device can also generate messages that interrupt the formatting).

For example, it is critical to view the following messages in sequence or you cannot associate messages with an interface. As such, while the formatting appears "tidy" in the device, it is NOT tidy by message logging standards and for remote logging servers. (ALSO NOTE: timestamp as shown here IS NOT SUFFICIENT TO RECONSTRUCT THE ORDER which can make the logging useless/unreliable!)

11:31:34 route,debug,event Interface change
11:31:34 route,debug,event interface=host1
11:31:34 route,debug,event status=UP,RUNNING
11:31:34 route,debug,event mtu=1500
11:31:34 route,debug,event Interface change
11:31:34 route,debug,event interface=host2
11:31:34 route,debug,event status=UP,RUNNING
11:31:34 route,debug,event mtu=1500
11:31:34 route,debug,event Interface change
11:31:34 route,debug,event interface=host3
11:31:34 route,debug,event status=UP,RUNNING
11:31:34 route,debug,event mtu=1500

Without sequencing information these message can easily lose context and usefulness. But it seems better to simply output a single line for each of the above then no sequencing is needed.

11:31:34 route,debug,event Interface change interface=host1 status=UP,RUNNING mtu=1500
11:31:34 route,debug,event Interface change interface=host2 status=UP,RUNNING mtu=1500
11:31:34 route,debug,event Interface change interface=host3 status=UP,RUNNING mtu=1500

Well I tried the "workaround" that I was guessing at above and it didn't work like I thought it might.

(1) set a new logging action called "remoteWarning" for remote server and set to BSD option enabled, facility: syslog, and for severity I tried to set to warning and then I tried debug
(2) set log rules for ROUTE and STP to above action

My remote log server is not reflecting any severity settings, so I guess I need to get out wireshark and check.

I thought this setup might allow me to redirect logs into another severity than initially set for the message (for example, set all route messages to WARNING when output to this logging action)