Chat now with support
Chat with Support

syslog-ng Premium Edition 6.0.17 - Administration Guide

Preface Chapter 1. Introduction to syslog-ng Chapter 2. The concepts of syslog-ng Chapter 3. Installing syslog-ng Chapter 4. The syslog-ng PE quick-start guide Chapter 5. The syslog-ng PE configuration file Chapter 6. Collecting log messages — sources and source drivers Chapter 7. Sending and storing log messages — destinations and destination drivers Chapter 8. Routing messages: log paths, reliability, and filters Chapter 9. Global options of syslog-ng PE Chapter 10. TLS-encrypted message transfer Chapter 11. FIPS-compliant syslog-ng Chapter 12.  Reliable Log Transfer Protocol™ Chapter 13. Reliability and minimizing the loss of log messages Chapter 14. Manipulating messages Chapter 15. Parsing and segmenting structured messages Chapter 16. Processing message content with a pattern database Chapter 17. Statistics and metrics of syslog-ng Chapter 18. Multithreading and scaling in syslog-ng PE Chapter 19. Troubleshooting syslog-ng Chapter 20. Best practices and examples

Flow control, normal disk buffering, no RLTP™

Flow control, normal disk buffering, no RLTP

How it works: 

  1. syslog-ng PE puts messages into the disk buffer (set via disk-buf-size()) when the destination becomes unavailable or when it is not able to process logs as fast as they arrive through the sources.

  2. When the disk buffer is full, syslog-ng PE puts messages into the memory buffer (set via mem-buf-length()). When the memory buffer gets full too, then syslog-ng PE stops the source (flow-control mechanism).

Figure 13.2. Flow control, normal disk buffering, no RLTP

Flow control, normal disk buffering, no RLTP™

How to set key parameters: 

Set flags(flow-control) in the log path.

The memory buffer must be large enough to store the incoming messages of every source:

mem-buf-length() > sum of log-iw-size() of sources connected to this destination

Configure disk buffering. For details, see Example 13.1, “Example configuration of normal disk-based buffering”.

Example 13.1. Example configuration of normal disk-based buffering

disk-buffer(
    mem-buf-length(20000) # storing 20000 messages in memory, sum log-iw-size of sources should be less than 20000 to use flow-control
    disk-buf-size(2147483648) # storing 2 GB of messages on disk
    reliable(no)
)

Benefits: 

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 in combination with disk buffering, messages that have been written to the disk buffer and/or the memory buffer are considered delivered. When the memory buffer becomes full, syslog-ng PE stops reading messages from the configured sources. This means that no log messages get lost.

  • Message loss outside of syslog-ng PE: The greatest advantage of this configuration over when no disk buffering is used at all is that when the log-iw-size() control window is full, the flow-control mechanism stops reading logs from the sources much later. This is because when it is not possible to send logs directly to the destinations, they are first written to the disk and then the memory buffer. It is only after both the disk buffer and the memory buffer have been filled to their full capacity that the sources are stopped. This enables you to minimize the loss of log messages during peak hours or when the network is temporarily down.

  • Message loss when syslog-ng PE is stopped or restarted: When syslog-ng is stopped or restarted, the contents of the memory buffer and the disk buffer are flushed to disk, meaning that no log loss occurs.

    NOTE:

    In rare cases, the buffers stored on the disk can become corrupted, in which case syslog-ng PE may not able to process all the logs stored in the disk buffer.

Drawbacks: 

One drawback of using disk buffering is that the processing of log messages by syslog-ng PE is slower.

This configuration does not provide protection against the loss of log messages in the following situations:

  • TCP error: In the case of a TCP connection, when messages are sent from the destination drivers to the destination servers, messages are written to the TCP socket. The TCP socket sends an acknowledgement to the destination drivers once it has successfully processed messages. A message is considered "delivered" when no error occurs during the process of writing the data to the socket, and the acknowledgement is received. Note, however, that if something goes wrong after messages have been successfully written to the TCP socket, log messages can still get lost. Also note that TCP errors can occur on both the source and the destination side, and both can cause the loss of log messages.

  • When syslog-ng PE is not able to operate normally (for example, when syslog-ng PE crashes due to some unforeseen event): Log messages that were in the output buffer when the issue occurred get lost because those messages are stored in the memory.

Flow control, reliable disk buffering, no RLTP™

Flow control, reliable disk buffering, no RLTP

How it works: 

syslog-ng puts messages into the disk buffer, until disk-buffer size reaches disk-buf-size(). Above that size, flow control is triggered. syslog-ng PE completely stops reading incoming messages from the source, making the control window (governed by log_iw_size()) fill up and blocking the sources.

In this configuration, log messages are stored on the disk (and not in the memory), which increases reliability.

Figure 13.3. Flow control, reliable disk buffering, no RLTP

Flow control, reliable disk buffering, no RLTP™

How to set key parameters: 

Set flags(flow-control) in the log path.

Configure disk buffering. For details, see Example 13.2, “Example configuration of reliable disk-based buffering”.

Example 13.2. Example configuration of reliable disk-based buffering

disk-buffer(
    mem-buf-size(10485760) # storing 10 MB of messages in memory and on disk
    disk-buf-size(2147483648) # storing 2 GB of messages only on disk
    reliable(yes)
)

Benefits: 

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 in combination with disk buffering, those messages are considered delivered that have been written to the disk buffer. As soon as the disk buffer is full, syslog-ng PE stops reading messages. This means that no log messages get lost.

  • Message loss outside of syslog-ng PE: One of the advantages of this configuration over when no disk buffering is used at all is that when the log-iw-size() control window is full, the flow-control mechanism stops reading logs from the sources much later. This is because when it is not possible to send logs directly to the destinations, they are written to the disk. It is only after the disk buffer has been filled to its full capacity that the sources are stopped. This enables you to minimize the loss of log messages during peak hours or when the network is temporarily down.

  • Message loss when syslog-ng PE is stopped or restarted: When syslog-ng is stopped or restarted, the contents of the disk buffer do not get lost, greatly increasing reliability.

    Also note that the memory buffer is only used as a cache in this configuration. Any data stored in the memory has already been written to the disk buffer, which, again, results in more reliability.

    NOTE:

    In rare scenarios, the buffers stored on the disk can become corrupted, in which case syslog-ng PE may not able to process all the logs stored in the disk buffer.

  • When syslog-ng PE is not able to operate normally (for example, when syslog-ng PE crashes due to some unforeseen event): No messages get lost because the disk buffer is persistent and when the disk buffer is full, syslog-ng PE stops reading messages from the sources. When syslog-ng PE is restarted after a crash, it automatically recovers any unsent messages from the disk buffer and the output buffer. After the restart, syslog-ng PE sends the saved messages to the destination.

Drawbacks: 

One drawback of using reliable disk buffering is that the processing of log messages by syslog-ng PE is slower than when messages are stored in the output buffer only, or when using normal disk buffering.

This configuration does not provide protection against the loss of log messages in the following situations:

  • TCP error: In the case of a TCP connection, when messages are sent from the destination drivers to the destination servers, messages are written to the TCP socket. The TCP socket sends an acknowledgement to the destination drivers once it has successfully processed messages. A message is considered "delivered" when no error occurs during the process of writing the data to the socket, and the acknowledgement is received. Note, however, that if something goes wrong after messages have been successfully written to the TCP socket, log messages can still get lost. Also note that TCP errors can occur on both the source and the destination side, and both can cause the loss of log messages.

Flow control, reliable disk buffering, RLTP™

Flow control, reliable disk buffering, RLTP

How it works: 

NOTE:

The example presented here is set in a client-relay-server scenario.

  1. The sender sends messages in batches (set via flush-lines()).

  2. The relay writes messages to the disk buffer.

  3. Once messages have been written to the disk buffer, the relay returns an acknowledgement to the client.

  4. The relay sends messages to the server in batches (set via flush-lines()).

  5. When the server has successfully received and processed the messages in the batch, it sends an acknowledgement of the processed messages to the relay.

    It is only at this point that the relay removes log messages from the disk buffer because this is when logs are considered "delivered" to the server.

    After receiving the acknowledgement, the sender sends another batch of messages.

This configuration gives you the greatest degree of protection against log message loss. RLTP™ provides acknowledgement about the successful processing of log messages at the level of the application layer. Even if the reception of log messages has been acknowledged by TCP at the transport layer, log messages are considered delievered only when the syslog-ng PE application has received an acknowledgement from the other syslog-ng PE instance about the successful delivery of log messages.

This mechanism guarantees that log messages are not lost between the client and the relay, or between the relay and the server, or on the relay itself. To minimize the risk of message loss on the client or the server, use flow control and reliable disk buffering.

Figure 13.4. Flow control, reliable disk buffering, RLTP

Flow control, reliable disk buffering, RLTP™

How to set key parameters: 

Set flags(flow-control) in the log path.

Configure disk buffering. For details, see Example 13.3, “Example configuration of reliable disk-based buffering”.

Example 13.3. Example configuration of reliable disk-based buffering

disk-buffer(
    mem-buf-size(10485760) # storing 10 MB of messages in memory and on disk
    disk-buf-size(2147483648) # storing 2 GB of messages only in disk
    reliable(yes)
)

Enable RLTP™ by setting transport(rltp). For details, see the section called “RLTP™ options”.

Benefits: 

  • Unreachable destination server(s): Only as many incoming log messages are read as can be "delivered". When flow control is used in combination with reliable disk buffering and RLTP™, those messages are considered delivered by the very first source driver that have been written to the disk buffer. syslog-ng PE will not read new messages until the previous batch has been written to the disk buffer.

  • TCP error: In the case of a TCP connection, when messages are sent from the destination drivers to the destination servers, messages are written to the TCP socket. The TCP socket sends an acknowledgement to the destination drivers once it has successfully processed messages. However, while the acknowledge messages sent by the TCP socket implement flow control at the transport layer, RLTP™ introduces flow control at the application layer. This means that log messages are only considered delivered, when the RLTP™ acknowledge message is returned at the level of the syslog-ng application. That is to say, when a TCP error occurs, messages that have been written to the disk buffer do not get lost.

  • Message loss outside of syslog-ng PE: One of the advantages of this configuration over when no disk buffering is used at all is that when the log-iw-size() control window is full, the flow-control mechanism stops reading logs from the sources much later. This is because when it is not possible to send logs directly to the destinations, they are written to the disk. It is only after the disk buffer has been filled to its full capacity that the sources are stopped. This enables you to minimize the loss of log messages during peak hours or when the network is temporarily down.

  • Message loss when syslog-ng PE is stopped or restarted: When syslog-ng is stopped or restarted, the contents of the disk buffer do not get lost, greatly increasing reliability.

    Also note that the memory buffer is only used as a cache in this configuration. Any data stored in the memory has already been written to the disk buffer, which, again, results in more reliability.

    NOTE:

    In rare scenarios, the buffers stored on the disk can become corrupted, in which case syslog-ng PE may not able to process all the logs stored in the disk buffer.

  • When syslog-ng PE is not able to operate normally (for example, when syslog-ng PE crashes due to some unforeseen event): No messages get lost because the disk buffer is persistent and when the disk buffer is full, syslog-ng PE stops reading messages from the sources. When syslog-ng PE is restarted after a crash, it automatically recovers any unsent messages from the disk buffer and the output buffer. After the restart, syslog-ng PE sends the saved messages to the destination.

Drawbacks: 

This configuration results in the slowest processing time out of all the options described in this chapter.

Deciding which loss prevention mechanism to apply

Choosing the ideal configuration for your environment may not always be a starightforward decision. Depending on your use case, it is worth considering which outcome is more desirable (with the following points representing the two opposite ends of the spectrum):

  • an application that does not slow down or stop — at the price of losing logs

  • no log messages get lost — at the price of a slower application or an application that stops (temporarily)

TIP:

If your application sends its logs through a blocking I/O socket and you prefer not to slow down or stop the application when log messages are arriving in volumes greater than syslog-ng PE is able to process, then consider turning flow control off on the client side. This way, you will not be using the whole application-client-server chain at full capacity, and yet still be able to spot the loss of application log messages at the beginning of the chain already, in the internal logs of the client.

Related Documents