MonitorWare Knowledge Base

The "last message repeated n times" feature will go away in future versions. Thus, we are now looking at who is actually using this feature and for what reason. If you would like us to keep it, please tell us in this thread why it is important for you.

If you would like to enable the repeated message reduction feature, use $RepeatedMsgReduction to turn it on:

$RepeatedMsgReduction on

If you do that, please post here why it is important to you - otherwise it won't work in future releases!

For additional information, please also see this mailing list thread: http://lists.adiscon.net/pipermail/rsys ... 00603.html

Thanks,
Rainer

• Pulling out your Hair?
• Wasting Time and Money?
• Deadline Approaching?

Dear Rainer, thank you for great software!

please don`t remove this feature! some buggy wifi access point (manufactured by Dlink) very like to send hundreds of identical messages sometimes.
we have only ~50 devices in network and receive 1-2k of duplicated messages every day

sorry for bad english

Hi, good work,

I'd like to have the possibility to use this option in future. As developer from time to time it's possible that new software is putting messages repeatedly.
It is good to have a feature like $RepeatedMsgReduction to let the user/admin manage the amount of messages written to file.
If it was possible to set this config for every message file independently, this was the ultimate effort.

Thanks debaba

Hi, thanks for the feedback. The current thinking is a bit into a different direction: I am currently thinking about rate-limiting the inputs, so that when too many messages occur, the input is put to a hold (or duplicate messages are consolidated here). Of course, nothing is fixed yet. So I would be interested in your use case for this per-action handling.

Thanks,
Rainer

Hi,
I use this feature as an overload protection.
An example: I use init as a watchdog to keep SSH tunnels alive. If the connection to a host is lost init tries to reconnect 5 times then sleeps for 30 seconds. This kind of network failure may last for hours so I can save a lot of space (80%) with this feature.

I'd prefer dedupe over a rate limit. Rate limit to me implies that a new and unique message could be blocked because of a storm of trivia. If rate limiting is added, please allow each severity (and maybe facility) to have "override" settings. I may not mind "info" from "local4" being throttled, but I'd always want "err"'s from "kernel".

Please don't remove the feature. We should find out the main problem first, It might be happened by accident or mistake. But for me it is working fine. And this feature is useful for developer, so keep it, please.

In a software package I work on, we are considering replacing the internal logging subsystem we have currently with syslog calls. Our thinking was that we would install rsyslog (or syslog-ng, but rsyslog is the current favorite) along with our package when setting up a new installation. In part, this would be to lighten our load in terms of the code we maintain (i.e., greatly reducing the logging subsystem) but it's also partly because of features like "Last message repeated..."

We look at our log files to help us troubleshoot problems at customer sites. Each log message either contributes information to the troubleshooting effort or it's noise that makes it harder to see what's actually going on. Since failure modes are not predictable, it's always possible, even with the most careful crafting of outgoing log messages, to get storm conditions in which the same message is sent over and over. While we try to avoid such situations, when they happen, it's much more helpful to see "Last message repeated 10000 times" rather than 10000 occurrences of the message.

Thanks for reading...
Tom

The statement "last message repeated 4 times" on its own is not very useful. It would be more useful if you added "last message repeated 4 times" to the end of the message that was repeated. Then programs like fail2ban could use pattern matching to ban bad IP addresses.

Thanks
Allan