|
Caution:
Note that in earlier versions of syslog-ng Premium Edition, Advanced Log Transfer Protocol is called Reliable Log Transfer Protocol (RLTP). |
The sender and the receiver use ALTP over the network() protocol. Since the tls() option is not configured neither on the sender nor on the receiver, the communication will be unencrypted.
Receiver configuration (syslog-ng PE server):
source s_network_altp { network( ip("127.0.0.1") port("5555") transport(altp) ip-protocol(4) ); };
Sender configuration (syslog-ng PE client):
destination d_network_altp { network( "127.0.0.1" port("5555") transport(altp) ip-protocol(4) ); };
The following example configures a sender and a receiver to communicate using ALTP. Since the tls-required() option is set to optional on the receiver and yes on the sender, and the tls() option is configured, the communication will be TLS-encrypted. For the sender (syslog-ng PE client), reliable disk-buffering is enabled to prevent data loss.
Receiver configuration (syslog-ng PE server):
source s_syslog_altp { syslog( ip("127.0.0.1") port("4444") transport(altp(tls-required(optional))) ip-protocol(4) tls( peer-verify(required-trusted) ca-dir("/var/tmp/client/") key-file("/var/tmp/server/server_priv.key") cert-file("/var/tmp/server/server.crt") ) ); };
Sender configuration (syslog-ng PE client):
destination d_syslog_altp { syslog( "127.0.0.1" port("4444") transport(altp(tls-required(yes))) ip-protocol(4) disk-buffer( mem-buf-size(200000) disk-buf-size(2000000) reliable(yes) ) tls( peer-verify(required-trusted) ca-dir("/var/tmp/server/") key-file("/var/tmp/client/client_priv.key") cert-file("/var/tmp/client/client.crt") ) ); };
Flow control, no disk buffering, no ALTP
Flow control, normal disk buffering, no ALTP
Flow control, reliable disk buffering, no ALTP
Advanced Log Transfer Protocol (ALTP) interacts with flow control and disk buffering to ensure that the loss of log messages is minimized or is prevented completely. This section explains how each loss prevention method contributes to reliability and minimizing log message loss. Flow control, disk buffering, and ALTP are explained in detail elsewhere in the document. In this section, we present a high-level overview of all of these mechanisms and highlight considerations such as:
Each of the following sections discusses a different scenario and uses figures to aid comprehension.
|
NOTE:
Each figure depicts a scenario in which the volume of incoming messages makes it necessary to use all buffers and control windows at maximum capacity. |
Important information:
Any of the mechanisms that syslog-ng PE uses to prevent or minimize the loss of log messages only works if the hardware and operating system work normally. When there is an issue with the hardware or operating system that the application and syslog-ng PE run on, log loss may occur. Issues include operating system crash (for example, kernel panic), memory errors, disk errors, power outage, and so on.
log-iw-size() sets a control window that tracks how many messages syslog-ng PE can accept. Every source has its own control window. If the window gets full, syslog-ng PE stops reading messages from the sources until some messages are successfully sent to the destination(s).
Figure 33: Flow control, no disk buffering, no ALTP
Set flags(flow-control) in the log path.
The output buffer must be large enough to store the incoming messages of every connected source:
log-fifo-size() > sum of log-iw-size() of sources connected to this destination
This configuration minimizes the loss of log messages in the following situations:
Unreachable destination server(s): Only as many incoming log messages are read as can be "delivered". When flow control is used, those messages are considered delivered that have been written to the output buffer. When the output buffer is full, syslog-ng PE stops reading messages from the connected sources. This means that no log messages get lost.
|
NOTE:
In case the application is sending its log messages through a blocking I/O socket, then it is the application that stops sending new log messages and waits until the previous batch has been delivered. If the application is not sending logs through a blocking I/O socket, then it will keep sending messages (regardless of whether or not the previous batch has been delivered), and this can result in the loss of log messages. For example, it is not possible to apply flow control in the case of a UDP source. |
While this configuration gives you the fastest processing time, it has some limitations. It does not provide protection against the loss of log messages in the following situations:
© 2023 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy