Mailing List Archive

Guaranteed message delivery
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
there is no content in your message that I can see.

garanteed delivery can be a tricky thing, in part it depends on your definition
of guaranteed.

rsyslog uses queues in ram by default, so if a system crashes, the contents of
those queues are lost. Assuming you aren't talking about that and are instead
talking about the normal case of being resiliant in the face of network
problems, rsyslog has RELP available (reliable event logging protocol). This
does application layer acks so the message is close to guaranteed (there is one
known failure condition, but so far nobody has cared about it enough to
contribute or sponsor a fix for it)

both normal TCP and UDP log delivery have failure modes that can cause
substantial message loss.

David Lang
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
There is also one additional caveat. Just because the delivery is
reliable at particular stage of transport, doesn't mean that the whole
path is guaranteed.

Let's consider a situation

source -> syslog -> rsyslog collector -> RELP -> rsyslog forwarder ->
RELP -> central rsyslog log gatherer

The initial syslog deliver is of course not reliable at all but we all
know it. But even though we employ RELP between each pair of rsyslog
components even if we have resilient queues, just because the forwarder
ACK-ed the delivery from the collector, it doesn't mean that the event
has been delivered to the central gatherer. In fact it could have been
queued on the forwarder, then the system might have crashed and the
filesystem could have been lost. So this "reliability" is highly
dependent on your definition, your needs and the money you're willing to
spend to assure it ;-)

On 17.12.2021 17:45, David Lang via rsyslog wrote:
> there is no content in your message that I can see.
>
> garanteed delivery can be a tricky thing, in part it depends on your
> definition of guaranteed.
>
> rsyslog uses queues in ram by default, so if a system crashes, the
> contents of those queues are lost. Assuming you aren't talking about
> that and are instead talking about the normal case of being resiliant
> in the face of network problems, rsyslog has RELP available (reliable
> event logging protocol). This does application layer acks so the
> message is close to guaranteed (there is one known failure condition,
> but so far nobody has cared about it enough to contribute or sponsor a
> fix for it)
>
> both normal TCP and UDP log delivery have failure modes that can cause
> substantial message loss.
>
> David Lang
> _______________________________________________
> rsyslog mailing list
> https://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.
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
yep, I've been looking for a round toit for years to write an article 'how to
(deliberatly) lose logs with rsyslog' to cover how to make your logs reliable
and how to define when you are going to throw away logs (if your log can't be
written, would you rather lose a log or have your service that's writing the log
stop?)

David Lang


On Sat, 18 Dec 2021, Mariusz Kruk via rsyslog wrote:

> Date: Sat, 18 Dec 2021 14:43:28 +0100
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog@lists.adiscon.com
> Cc: Mariusz Kruk <kruk@epsilon.eu.org>
> Subject: Re: [rsyslog] Guaranteed message delivery
>
> There is also one additional caveat. Just because the delivery is reliable at
> particular stage of transport, doesn't mean that the whole path is
> guaranteed.
>
> Let's consider a situation
>
> source -> syslog -> rsyslog collector -> RELP -> rsyslog forwarder -> RELP ->
> central rsyslog log gatherer
>
> The initial syslog deliver is of course not reliable at all but we all know
> it. But even though we employ RELP between each pair of rsyslog components
> even if we have resilient queues, just because the forwarder ACK-ed the
> delivery from the collector, it doesn't mean that the event has been
> delivered to the central gatherer. In fact it could have been queued on the
> forwarder, then the system might have crashed and the filesystem could have
> been lost. So this "reliability" is highly dependent on your definition, your
> needs and the money you're willing to spend to assure it ;-)
>
> On 17.12.2021 17:45, David Lang via rsyslog wrote:
>> there is no content in your message that I can see.
>>
>> garanteed delivery can be a tricky thing, in part it depends on your
>> definition of guaranteed.
>>
>> rsyslog uses queues in ram by default, so if a system crashes, the contents
>> of those queues are lost. Assuming you aren't talking about that and are
>> instead talking about the normal case of being resiliant in the face of
>> network problems, rsyslog has RELP available (reliable event logging
>> protocol). This does application layer acks so the message is close to
>> guaranteed (there is one known failure condition, but so far nobody has
>> cared about it enough to contribute or sponsor a fix for it)
>>
>> both normal TCP and UDP log delivery have failure modes that can cause
>> substantial message loss.
>>
>> David Lang
>> _______________________________________________
>> rsyslog mailing list
>> https://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.
> _______________________________________________
> rsyslog mailing list
> https://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.
>
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
once again there is no content in your message (HTML or plain text)

full message with headers below.

David Lang

On Thu, 23 Dec 2021, ILRed via rsyslog wrote:

> Return-Path: <rsyslog-bounces@lists.adiscon.com>
> Received: from mail.lang.hm ([10.0.0.1])
> by asgard (Cyrus v2.2.13-Debian-2.2.13-19ubuntu4) with LMTPA;
> Thu, 23 Dec 2021 05:09:02 -0800
> X-Sieve: CMU Sieve 2.2
> Received: from vservermail2.adiscon.com (vservermail2.adiscon.com
> [116.203.48.54])
> by mail.lang.hm (Postfix) with ESMTP id B3E231187C0
> for <david@lang.hm>; Thu, 23 Dec 2021 05:09:02 -0800 (PST)
> Received: from vservermail2.adiscon.com (localhost [127.0.0.1])
> by vservermail2.adiscon.com (Postfix) with ESMTP id EC1189CAC9;
> Thu, 23 Dec 2021 14:08:55 +0100 (CET)
> X-Original-To: rsyslog@lists.adiscon.com
> Delivered-To: rsyslog@lists.adiscon.com
> Received: from forward500j.mail.yandex.net (forward500j.mail.yandex.net
> [5.45.198.250])
> by vservermail2.adiscon.com (Postfix) with ESMTPS id 044619CAC6
> for <rsyslog@lists.adiscon.com>; Thu, 23 Dec 2021 14:08:53 +0100 (CET)
> Received: from sas1-f3a441df9f84.qloud-c.yandex.net
> (sas1-f3a441df9f84.qloud-c.yandex.net
> [IPv6:2a02:6b8:c14:2726:0:640:f3a4:41df])
> by forward500j.mail.yandex.net (Yandex) with ESMTP id A90226CB6BCC
> for <rsyslog@lists.adiscon.com>; Thu, 23 Dec 2021 16:08:52 +0300 (MSK)
> Received: from 2a02:6b8:c08:b987:0:640:c6c5:9be5
> (2a02:6b8:c08:b987:0:640:c6c5:9be5 [2a02:6b8:c08:b987:0:640:c6c5:9be5])
> by sas1-f3a441df9f84.qloud-c.yandex.net (mxback/Yandex) with HTTP id
> p8jcpo0e1qM1-8qem9Gpu; Thu, 23 Dec 2021 16:08:52 +0300
> X-Yandex-Fwd: 1
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
> t=1640264932; bh=8IxdyeyUF6+qxzer8/tzAcOqPRP3y3TEBLtNZZ5ice8=;
> h=References:Date:Message-Id:Subject:In-Reply-To:To:From;
> b=o+E0VC7ucMTbKeA8k6y08U9qbI9x3t4h5bkefwmQJ+EgFK/eeiXnpAv3Fee8iPLOw
> fp2zrxb+pSm84JeLpbPk2ogRHbU/Ou64gUIWPWhPDiu6lFzmkdl+e3TMNYusjVQj3B
> oZ2cevEEFt0eDIaNJqvJfDHT9boWdP9sRo4pHOz0=
> Authentication-Results: sas1-f3a441df9f84.qloud-c.yandex.net;
> dkim=pass header.i=@yandex.ru
> Received: by sas2-c6c59be58cac.qloud-c.yandex.net with HTTP;
> Thu, 23 Dec 2021 16:08:51 +0300
> Envelope-From: ilred@yandex.ru
> To: rsyslog-users <rsyslog@lists.adiscon.com>
> In-Reply-To: <18123nr1-rq74-qs78-r226-54r42ss8p07n@ynat.uz>
> References: <1412931639745725@mail.yandex.ru>
> <o46n897-p459-1snn-2p8s-1pq2569457pp@ynat.uz>
> <83bb5a05-e23c-9037-b4ca-80f361aaa3ed@epsilon.eu.org>
> <18123nr1-rq74-qs78-r226-54r42ss8p07n@ynat.uz>
> X-Mailer: Yamail [ http://yandex.ru ] 5.0
> Date: Thu, 23 Dec 2021 16:08:51 +0300
> Message-Id: <219011640264658@mail.yandex.ru>
> MIME-Version: 1.0
> X-Content-Filtered-By: Mailman/MimeDel 2.1.23
> Subject: Re: [rsyslog] Guaranteed message delivery
> X-BeenThere: rsyslog@lists.adiscon.com
> X-Mailman-Version: 2.1.23
> Precedence: list
> List-Id: rsyslog-users <rsyslog.lists.adiscon.com>
> List-Unsubscribe: <https://lists.adiscon.net/mailman/options/rsyslog>,
> <mailto:rsyslog-request@lists.adiscon.com?subject=unsubscribe>
> List-Post: <mailto:rsyslog@lists.adiscon.com>
> List-Help: <mailto:rsyslog-request@lists.adiscon.com?subject=help>
> List-Subscribe: <https://lists.adiscon.net/mailman/listinfo/rsyslog>,
> <mailto:rsyslog-request@lists.adiscon.com?subject=subscribe>
> From: ILRed via rsyslog <rsyslog@lists.adiscon.com>
> Reply-To: rsyslog-users <rsyslog@lists.adiscon.com>
> Cc: ILRed <ilred@yandex.ru>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Errors-To: rsyslog-bounces@lists.adiscon.com
> Sender: "rsyslog" <rsyslog-bounces@lists.adiscon.com>
>
>
> _______________________________________________
> rsyslog mailing list
> https://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.
>
_______________________________________________
rsyslog mailing list
https://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.
Guaranteed message delivery [ In reply to ]
Hello to all.
I am sending it from another mailbox, as there were problems with reading
the letter.
I am trying to set up a rsyslog so that the message is not lost when
transmitted over the network using the RELP protocol.

Server settings:

module(load="imrelp")
> input(type="imrelp" port="20514")


Client settings:

module(load="omrelp")

*.* action(type="omrelp" Target="192.168.0.100" Port="20514"

queue.type="LinkedList" queue.size="10000"
> queue.filename="q_sendToLogserver" queue.highwatermark="9000"

queue.lowwatermark="50" queue.maxdiskspace="500m" queue.saveOnShutdown="on"
> action.resumeRetryCount="-1"
> action.reportSuspension="on" action.reportSuspensionContinuation="on"
> action.resumeInterval="10")


Messages are lost if the server is disconnected from the network and the
client's PC is rebooted. Enabling the saveOnShutdown option should prevent
the loss of messages, but it doesn't.
Is it possible to configure the client so that messages are not lost in
this case?
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
Apart from all the obvious stuff about reliablility that we wrote
earlier, your config creates a memory queue. It only writes to disk in
case of overfilling the memory queue (if the queue grows over the
queue.highwatermark size). So in a typical case, the queue is stored in
memory and if the process is killed, the queue contents are lost.

The saveonshutdown option indeed should cause the rsyslog daemon to
write the queue contents to the disk and reload them on restart but it
all depends on how the process is being shut down and whether the
rsyslogd process is actually able to create and write the buffer files
(there are several factors that can prevent it - selinux, directory
permissions, the process can be killed with SIGKILL).

Memory-based disk-assisted queues are memory-bound so they are prone to
message loss in case of the process crash. If you want "extreme"
reliability, you should use disk-based queues but be aware that they
offer much lower performance.

On 24.12.2021 10:23, Dmitrii Chernov via rsyslog wrote:
> Hello to all.
> I am sending it from another mailbox, as there were problems with reading
> the letter.
> I am trying to set up a rsyslog so that the message is not lost when
> transmitted over the network using the RELP protocol.
>
> Server settings:
>
> module(load="imrelp")
>> input(type="imrelp" port="20514")
>
> Client settings:
>
> module(load="omrelp")
>
> *.* action(type="omrelp" Target="192.168.0.100" Port="20514"
>
> queue.type="LinkedList" queue.size="10000"
>> queue.filename="q_sendToLogserver" queue.highwatermark="9000"
> queue.lowwatermark="50" queue.maxdiskspace="500m" queue.saveOnShutdown="on"
>> action.resumeRetryCount="-1"
>> action.reportSuspension="on" action.reportSuspensionContinuation="on"
>> action.resumeInterval="10")
>
> Messages are lost if the server is disconnected from the network and the
> client's PC is rebooted. Enabling the saveOnShutdown option should prevent
> the loss of messages, but it doesn't.
> Is it possible to configure the client so that messages are not lost in
> this case?
> _______________________________________________
> rsyslog mailing list
> https://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.
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
the save on shutdown is at least partially defeated on many distros in that the
shutdown process only gives rsyslog a few seconds to shutdown gracefully (saving
the queue) and then does a kil -9 on it (there is a systemd config to change
this timeing)

disk queues are safer, but in my tests were slower by a factor of ~100x (and
that was using a $5k PCI based SSD)

David Lang

On Sun, 26 Dec 2021, Mariusz Kruk via rsyslog wrote:

> Date: Sun, 26 Dec 2021 15:41:08 +0100
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog@lists.adiscon.com
> Cc: Mariusz Kruk <kruk@epsilon.eu.org>
> Subject: Re: [rsyslog] Guaranteed message delivery
>
> Apart from all the obvious stuff about reliablility that we wrote earlier,
> your config creates a memory queue. It only writes to disk in case of
> overfilling the memory queue (if the queue grows over the queue.highwatermark
> size). So in a typical case, the queue is stored in memory and if the process
> is killed, the queue contents are lost.
>
> The saveonshutdown option indeed should cause the rsyslog daemon to write the
> queue contents to the disk and reload them on restart but it all depends on
> how the process is being shut down and whether the rsyslogd process is
> actually able to create and write the buffer files (there are several factors
> that can prevent it - selinux, directory permissions, the process can be
> killed with SIGKILL).
>
> Memory-based disk-assisted queues are memory-bound so they are prone to
> message loss in case of the process crash. If you want "extreme" reliability,
> you should use disk-based queues but be aware that they offer much lower
> performance.
>
> On 24.12.2021 10:23, Dmitrii Chernov via rsyslog wrote:
>> Hello to all.
>> I am sending it from another mailbox, as there were problems with reading
>> the letter.
>> I am trying to set up a rsyslog so that the message is not lost when
>> transmitted over the network using the RELP protocol.
>>
>> Server settings:
>>
>> module(load="imrelp")
>>> input(type="imrelp" port="20514")
>>
>> Client settings:
>>
>> module(load="omrelp")
>>
>> *.* action(type="omrelp" Target="192.168.0.100" Port="20514"
>>
>> queue.type="LinkedList" queue.size="10000"
>>> queue.filename="q_sendToLogserver" queue.highwatermark="9000"
>> queue.lowwatermark="50" queue.maxdiskspace="500m" queue.saveOnShutdown="on"
>>> action.resumeRetryCount="-1"
>>> action.reportSuspension="on" action.reportSuspensionContinuation="on"
>>> action.resumeInterval="10")
>>
>> Messages are lost if the server is disconnected from the network and the
>> client's PC is rebooted. Enabling the saveOnShutdown option should prevent
>> the loss of messages, but it doesn't.
>> Is it possible to configure the client so that messages are not lost in
>> this case?
>> _______________________________________________
>> rsyslog mailing list
>> https://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.
> _______________________________________________
> rsyslog mailing list
> https://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.
>
_______________________________________________
rsyslog mailing list
https://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.
Re: Guaranteed message delivery [ In reply to ]
That's true. It's typical for distro-based services to be prepared for
"normal" use cases.

Since I often use a second instance of rsyslogd process - separate from
the main distro-provided one, running with separate user and so on - I
have my own unit file which waits up to a minute or so before sigkill.

In case of a need for "extreme" reliability without the performance
penalty, I think I'd go for memory backed queue but I'd also add
secondary action to write an event locally to a file. This way if an
event wasn't delivered, it could be re-read from the file manually.

On 26.12.2021 18:30, David Lang via rsyslog wrote:
> the save on shutdown is at least partially defeated on many distros in
> that the shutdown process only gives rsyslog a few seconds to shutdown
> gracefully (saving the queue) and then does a kil -9 on it (there is a
> systemd config to change this timeing)
>
> disk queues are safer, but in my tests were slower by a factor of
> ~100x (and that was using a $5k PCI based SSD)
>
> David Lang
>
>  On Sun, 26 Dec 2021, Mariusz Kruk via rsyslog wrote:
>
>> Date: Sun, 26 Dec 2021 15:41:08 +0100
>> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
>> To: rsyslog@lists.adiscon.com
>> Cc: Mariusz Kruk <kruk@epsilon.eu.org>
>> Subject: Re: [rsyslog] Guaranteed message delivery
>>
>> Apart from all the obvious stuff about reliablility that we wrote
>> earlier, your config creates a memory queue. It only writes to disk
>> in case of overfilling the memory queue (if the queue grows over the
>> queue.highwatermark size). So in a typical case, the queue is stored
>> in memory and if the process is killed, the queue contents are lost.
>>
>> The saveonshutdown option indeed should cause the rsyslog daemon to
>> write the queue contents to the disk and reload them on restart but
>> it all depends on how the process is being shut down and whether the
>> rsyslogd process is actually able to create and write the buffer
>> files (there are several factors that can prevent it - selinux,
>> directory permissions, the process can be killed with SIGKILL).
>>
>> Memory-based disk-assisted queues are memory-bound so they are prone
>> to message loss in case of the process crash. If you want "extreme"
>> reliability, you should use disk-based queues but be aware that they
>> offer much lower performance.
>>
>> On 24.12.2021 10:23, Dmitrii Chernov via rsyslog wrote:
>>> Hello to all.
>>> I am sending it from another mailbox, as there were problems with
>>> reading
>>> the letter.
>>> I am trying to set up a rsyslog so that the message is not lost when
>>> transmitted over the network using the RELP protocol.
>>>
>>> Server settings:
>>>
>>> module(load="imrelp")
>>>> input(type="imrelp" port="20514")
>>>
>>> Client settings:
>>>
>>>   module(load="omrelp")
>>>
>>> *.* action(type="omrelp" Target="192.168.0.100" Port="20514"
>>>
>>>   queue.type="LinkedList" queue.size="10000"
>>>> queue.filename="q_sendToLogserver" queue.highwatermark="9000"
>>> queue.lowwatermark="50" queue.maxdiskspace="500m"
>>> queue.saveOnShutdown="on"
>>>> action.resumeRetryCount="-1"
>>>> action.reportSuspension="on" action.reportSuspensionContinuation="on"
>>>> action.resumeInterval="10")
>>>
>>> Messages are lost if the server is disconnected from the network and
>>> the
>>> client's PC is rebooted. Enabling the saveOnShutdown option should
>>> prevent
>>> the loss of messages, but it doesn't.
>>> Is it possible to configure the client so that messages are not lost in
>>> this case?
>>> _______________________________________________
>>> rsyslog mailing list
>>> https://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.
>> _______________________________________________
>> rsyslog mailing list
>> https://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.
>>
> _______________________________________________
> rsyslog mailing list
> https://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.
_______________________________________________
rsyslog mailing list
https://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.