MonitorWare Knowledge Base

How can I setup a rsyslog infrastructure that insures messages are forwarded to a remote server and that messages exceeding 1024 bytes are treated as a single long message?

I know that rsyslog v3 has a feature that attempts to retry sending messages if the remote server is unavailable. However, I am uncertain on how a standard rsyslog installation handles messages that exceed the 1024 byte limit. Section 6.1 of RFC 3164 () state the following:

1. "syslog message receivers must not malfunction upon the receipt of packets where the message length is greater than 1024 bytes."
2. "Devices MUST NOT retransmit messages whose received length exceeds 1024 bytes"

I intend to setup both device and collector with rsyslog v3 and would like assurance that it will always treat long messages as long messages rather than truncated or double messages.

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

The default limit is 2K for messages. If that is not sufficient, you need to change the #define MAXLINE inside the sources and recompile.

To transfer messages reliable, use this guide: http://www.rsyslog.com/doc-rsyslog_reli ... rding.html

BUT: use RELP instead of plain tcp, else you *have* reliability problems on the wire.

Thanks for the reply Rainer!

Message limit is 2K? I take it that limit is the one used by Rsyslog rather than the actual protocol specification, correct?

How does rsyslog react whenever it receives messages that are more than 2K? Does it truncate them? Does it deny them? Does it deliver them in fragments? Does it deliver it whole?

Thanks once again for your assistance!

It's a rsyslog limit (we simply ignore the dumb 1K limit...).

If it is over MAXLINE, things will go wrong. I do not commit to any specific way of going wrong (though there is one ). If you expect more than MAXLINE, increase it

Thanks for the assistance Rainer! I agree that 1K is ridiculous, too.

One thing I did not mention: If you like to make sure that a message is not longer than n (e.g. n=2048), you can limit the size with the property replacer (inside the template). That would be %msg:1:2048% instead of %msg%. So you get truncation for oversize messages and thus a well-defined behavior.

Thanks for the tip; I remember seeing that feature while looking up property options. Though my concern about the message length stemmed from the RFC stating that receivers must not retransmit messages that exceed 1024. I was concerned whether rsyslog itself decides, "Wow, this is larger than 1024, so I am going to truncate it even before I make it available for processing by selectors."

hehe - in all I've done I've always ignored that 1K by default I worked hard to remove that limit from the upcoming syslog RFC series. Now, 2K is the bare minimum, with 8K recommended and much more permitted. Over time, rsyslog will get a dynamic limit, at least settable via the config file. For now, you need to modify the source because of some legacy code stemming back to sysklogd

Rainer