The end goal is to have separate files on disk for the various services (DHCP, DNS, etc.) including some reasonable level of status messaging, and see only critical / error messages when I look at Logs in WinBox.
That’s definitely not happening here, no matter what I’ve tried. As soon as I add the “logDNS” action into the mix WinBox gets spammed with DNS log messages. Even though I think I have explicitly filtered them.
The problem with that for me is when going full tilt without any filter WinBox (Mac version) crashes and I have to reconnect. I think a couple times ROS has locked up and I’ve had to reboot. (this is a side-project I’be been thinking about for a year or so)
Might set up an Alpine container with rsyslog and see what I can do with that. I know I can put yet another service on my Raspberry Pi, but I’d like to keep this aspect self-contained if I can.
How the topics work is a bit confusing at right. Basically “level” has no specially meaning - topics is more like “tags”, than the syslog-like fields. So levels like “critical” and “debug” are just topics that can be “matched”. There are also “packet” and “raw” that are also level-like things
The 2nd part is there is also the /system/logging/actions… In there you can define a “log destination” to a file. It’s just a destination that you can set based on the “topic matches” to.
Finally, as noted, in winbox the dropdown let you pick which log to see. By default, it “all”. But if you select “memory”, the WinBox looks appear like default.
So if you say topics=dns with a new “action” for it to got a dns log file, you’ll get all levels in file. I would not modify the default. Just add new one each the file-to-topic.
But what I would not do is change the critical and error defaults. If you were working at console, critical message would appear instantly in CLI, which you’d want even with file logging. What you OP photo shows is if there was a “critical” issue with “dns”.
Yeah! I for sure will add “echo” back into the mix once I have a more complete understanding of what’s going on. (which I probably do now) I disabled absolutely everything I could to simplify the config while testing and before posting.
The real problem for me now is that WinBox’s default selection of “all” creates problems given the amount of logging I sometimes experience. (and I’m on a baby home network, not anything serious) As soon as I add DNS, DHCP, Wireless, etc. the volume of log messages becomes such that WinBox can’t handle it.
If WinBox would “remember” the selection I think that would fix things for me. I’d simply have to remember never to open the firehose by selecting “all” and I’d still be able to enjoy the benefit of in-app log viewing. Someday, maybe!
(since the Mac version of WinBox is still labelled “Beta” and there are other similar niceties lacking, I have high hopes this will actually happen — but I’m obviously not holding my breath and frankly I’m just so happy the native Mac version exists I will refrain from raising much fuss beyond this … and FWIW it’s the same way on the iOS app, and in WebFig)
So I think what I’m going to do in the meantime is return my setup to log individual services to their own files, and hope for future WinBox upgrades which I’m sure will be coming with all deliberate speed.
I won’t disagree that Mikrotik’s logging facilities could use a bit of love and refinement,
I think much of your problem related to the overwhelming amount of log messages comes from logging without regard to severity. Debug logs e.g. log absolutely everything. It would be easier to log just the things that are actually somewhat interesting, so e.g. instead of e.g. dns using dns,info or dns,error
That’s exactly the rub — I want to log everything … to a file. Some of those debug messages are pretty useful to have when I’m looking for the source of a problem. If I’m not logging it all the time, I will probably miss something important when I need it.
But I also need the capability of “normal” level logging for routine monitoring.
What I’ve done for the time being is add “! debug” to all the file Actions I’ve defined, and that prevents (at least for now) WinBox from crashing. When I decide I want to see the debug events, I can change the definition appropriately. Not ideal, but I can live with that vs. not seeing what I want to in WinBox.
Some variation of that is probably the best you can do for now.
Just be aware that Mikrotiks use so-called code storage flash, and while it is reliable, writes can be slow and write endurance is limited. Storing detailed logs on a just in case basis is therefore strongly discouraged.
Yeah the selection in top-right corner is the secret to managing it when you have file logging. WinBox “session”/“workspace” remember what you selected there. So if you leave that set to “memory”(or new /system/logging/action like “winbox” where you use topics=!debug,!packet,!raw to go to memory)
Often it’s the packet and raw that get you. Those are topic associated the “debug”, but those often larger protocol dumps – so topics=debug get more than topics=debug,!packet,!raw. Most folk think in terms of linear levels so a “trace” is lower than “debug”, not in RouterOS.
And, also agree it could be improved too… somehow MikroTik found a way to turn logging into a boolean algebra problem.
Good reminder. Luckily I am aware of the semi-precious nature of the flash and I am 100% logging my all files to USB storage. Once I have a handle on what’s actually being logged I’ll be adjusting the line & file counts to give me what I need.
