It is indeed not possible to filter the messages on their way to be logged by contents, nor to tell the processes generating them (dhcp, wireless in your case) to filter them by some parameters of the object being processed. You can only filter them when watching the log.
Or send your log to syslog [action=remote] (you can add a Prefix also)
(eg DUDE has syslog functionality and Syslog Rules that filter on source and Regexp content)
(this filtered syslog content can be logged as log topic “dude”)
I’ve played with the Dude, and I have Splunk set up, but I continue to find value at looking at the log in Winbox. Neither of those solutions fully replace evening the information gathering slash monitoring that is available “manually” via Winbox.
You don’t need DUDE client to setup and look at DUDE. You do this in Winbox (or even webfig)
DUDE menu en Syslog Rules setup for DUDE are also in Winbox
Just as the LOG is in Winbox, including it’s filters when displaying.
Having a hard time getting Dude’s syslog filtering (using Syslog Rules) to work.
Using /system/logging, without an entry that includes certain topics with an action of DUDELOG, the only entries in the dude log are dude-generated entries such as “syslog: Service ssh on 192.168.2.5 is now down (timeout)”
But, when I include an entry in /system/logging such as “Topics: info” “Action: dudelog” then all info topic events show up in the dude log, regardless of a syslog rule such as the regexp “drop” fule shown:
.
.
Did you send anything to the syslog server (DUDE) ? Seems like you did not
DUDE set to active? (well actually we do not use any other element of DUDE, only it’s syslog function)
Topic DUDE in the Sytem Logging rules should show the loggings sent to the syslog server
(typical action for sending loggings is called “Remote” (sending to port 514) at the sender device)
The dudelog action is only for putting the syslog gathered information in a separate buffer.
It’s writing the dudelog buffer. If you add other topics, like local info, to the dudelog buffer they will also be there without passing the syslog filter.
You can select what buffer is shown in Logging: eg dudelog, memory, all … selection in that upper right field, now set as “dudelog”
Use buffer selection “All” for combining buffer dudelog and buffer memory in the LOg display
This port 514 must be allowed to receive (use chain input) by the firewall (is typical allowed for interfaces that are member of the LAN-interfacelist) on the DUDE running RoS device
Then after the firewall it passes the syslog filter: a combination of sender IP address and RegExp (IP and RegExp can be empty, and can be negated.)
Sending to your own could be done via 127.0.0.1 IP address (Input to this IP is not allowed in the firewall by default!)
So again:
topic has no filters, action can be memory or remote (and other)
remote will send to syslog server (DUDE)
syslog server has filters (syslog rules) and result is topic Dude
topic dude can have some action, like memory or here split in a separate buffer dudelog
logs can be in separate buffers according to System Logging action setting, at least with the “disk type” action. Name of the task is name of the buffer
disk? Is “files”. In Ros7 can be disk in RAM also (tmpfs) (This avoids burning too much to flash.)
At this time, I am only trying to get certain log messages from the same device (and ax3) running the Dude server.
Dude is running.
With /system/logging set to send log items with topic “info” logs to the action “dudelog,” I see all such log entries in the ax3’s log (using the . That is, the System Rules are ignored when I change to the buffer “dudelog.”
Send the logs to DUDE with action “remote” as you do now send them to action “dudelog”, forget action dudelog, you don’t need it.
Make another log entry for the logs now with topic DUDE, and send that to memory buffer, with action “memory”
Topic "X" -> action "remote"
Syslog rules as filter on those X topic logs
Extra logging action for Topic "dude" -> action "memory"
Only logging for topic X , that passes the filter , will show up in the memory log
The whole dudelog construction is only if you want to have this in a separate log buffer.
