On 10/19/2017 6:58 PM, deoren wrote:
On 10/19/2017 3:12 PM, Rainer Gerhards wrote:
Am 19.10.2017 21:55 schrieb "David Lang" <da...@lang.hm>:
RELP has it's place, but most of the time I'm willing to loose some logs
under rare failure conditions and so haven't bothered to use it.
large maxmessagesize leads to wasted memory in rsyslog, but nothing more
severe than that.
Thanks for confirming. I'll likely go ahead and increase that value to
128K to see if the problem goes away.
if your maxmessagesize was 64k, that should not have been a problem.
Acknowledged. Do you know if all inputs honor the global()
maxmessagesize
value, or only certain ones? Does that value need to be specified
using the
legacy configuration syntax?
That's really a question Rainer will need to answer
In theory "yes", if not, its a bug. I ironed out some of those bugs the
past releases, most notably in imfile. I won't outrule I have overlooked
some.
Rainer
It's far too soon to say that the issue with using RELP has been worked
around (other than using omfwd and imptcp in its place), but I modified
the imprelp input() definition on the receiver to explicitly specify
MaxDataSize="128k" instead of relying on the global parameter
configuration of maxMessageSize="128k".
That seems to have made a difference, but I won't know more until we go
a full day on Friday with heavy activity on the sending system again.
On a related note, I noticed that I enabled Keep Alive for the imrelp
input() definition. Does RELP benefit from enabling Keep Alive? If so,
do you specify it for both imrelp (input) and omrelp (action)?
I noticed that you can configure both ends of the connection when using
plain TCP forwarding (omfwd on sender and imptcp on receiver). Does RELP
not operate that way?
I'm trying to avoid using legacy configuration options where I can, but
just in case the order of the configuration settings matter, I've set
the maxMessageSize global parameter prior to the imrelp module and the
imrelp input.
Illustration:
global (
maxMessageSize="128k"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
workDirectory="/var/spool/rsyslog"
processInternalMessages="off"
parser.permitSlashInProgramName="on"
)
# more config settings here ...
input(
type="imrelp"
port="2514"
KeepAlive="on"
ruleset="receiver-rsyslog-JSON-payload-parsing"
MaxDataSize="128k"
)
Even so, the maxMessageSize paraemter value did not "seem" to apply to
the imrelp input and the client debug log showed repeat retries to send
queued messages.
Since I explicitly configured MaxDataSize on the imrelp input I've not
seen this problem reoccur.
Reading over the documentation for imrelp, I found this:
> MaxDataSize <size_nbr>
> Default is the global message size
>
> Sets the max message size (in bytes) that can be received. Any
messages above this size will be rejected causing the relp client to
reconnect and retry.
The "reconnect and retry" sounds exactly like what I'm experiencing,
though there isn't anything in the non-debug log which indicates that
and I'm not familiar enough with the debug format to be comfortable
saying that what I'm experiencing is exactly what is happening.
This bit gives me the impression that the global() maxMessageSize
parameter is what imrelp uses by default:
> Default is the global message size
Is that true or are those values separate?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
