syslog events received by TIBCO LogLogic LMI must be delimited with a \n to be correctly processed
Article ID: KB0077095
Updated On:
| Products | Versions |
|---|---|
| TIBCO LogLogic Enterprise Virtual Appliance | all versions up to 6.2.1 |
Description
The UDP syslog protocol only sends 1 syslog message per packet however TCP syslog supports multiple events per packet. Third-party syslog collectors typically support 2 methods of delimiting events:
1. using the \n character and
2. using a feature called octet-framing.
Octet framing involves prefixing the message size (in bytes) to the beginning of each message in front of the syslog priority value.
The most popular delimiter method is to use the \n (newline) character between messages. This is also the only method that LogLogic LMI uses for all versions up to 6.2.1. When events are received from a log source the engine_tcpcollector process will continue reading data from the TCP buffer until it encounters the \n character. Until the \n character is processed engine_tcpcollector will combine all the data it receives from a given log source into a single message; this is true even if the events are delimited using \r instead of \n. But the message will not be flushed to disk (i.e. written to the BFQ in /loglogic/data/vol1) until either the max TCP syslog message size is reached or the \n is processed. This can result in very large messages that take a very long time to be written to disk compared to when they were originally sent because the max message size limit will be the only criteria that will be eventually satisfied for delimiting the events. Note that these events will not be reflected anywhere else either. They will not be considered unapproved nor will they be listed under the Recent messages tab on the Log Source Status page but a packet capture indeed confirms that LMI is receiving the data. The default limit for message size is 64k unless users are on a version where LMI supports jumbo messages and have it enabled (disabled by default). The jumbo message feature supports events up to 1MB in size.
The situation described above where the events cannot be found anywhere other than a packet capture can occur if you have a syslog-ng instance configured to send events to LMI but have the octet-framing feature enabled within syslog-ng or if you have custom scripts that send events to LMI that are designed to delimit each event with a \r instead of \n.
1. using the \n character and
2. using a feature called octet-framing.
Octet framing involves prefixing the message size (in bytes) to the beginning of each message in front of the syslog priority value.
The most popular delimiter method is to use the \n (newline) character between messages. This is also the only method that LogLogic LMI uses for all versions up to 6.2.1. When events are received from a log source the engine_tcpcollector process will continue reading data from the TCP buffer until it encounters the \n character. Until the \n character is processed engine_tcpcollector will combine all the data it receives from a given log source into a single message; this is true even if the events are delimited using \r instead of \n. But the message will not be flushed to disk (i.e. written to the BFQ in /loglogic/data/vol1) until either the max TCP syslog message size is reached or the \n is processed. This can result in very large messages that take a very long time to be written to disk compared to when they were originally sent because the max message size limit will be the only criteria that will be eventually satisfied for delimiting the events. Note that these events will not be reflected anywhere else either. They will not be considered unapproved nor will they be listed under the Recent messages tab on the Log Source Status page but a packet capture indeed confirms that LMI is receiving the data. The default limit for message size is 64k unless users are on a version where LMI supports jumbo messages and have it enabled (disabled by default). The jumbo message feature supports events up to 1MB in size.
The situation described above where the events cannot be found anywhere other than a packet capture can occur if you have a syslog-ng instance configured to send events to LMI but have the octet-framing feature enabled within syslog-ng or if you have custom scripts that send events to LMI that are designed to delimit each event with a \r instead of \n.
Issue/Introduction
This article describes how syslog events must be formatted in order to be correctly processed by LogLogic LMI.
Resolution
In both of those situations, the resolution is essentially the same. Syslog-ng will need its configuration changed to have octet-framing disabled. For custom scripts that use \r (or nothing at all), they will need to be modified to use \n instead.
Additional Information
See article 000040504 for additional requirements concerning the syslog header when using custom scripts.
Feedback
Yes
No
Powered by
