Log Insight has supported event forwarding since 3.0. Given the syslog RFC, it was common for Log Insight to add a prefix to log events it forwarded. An option exists in 4.6 to change this behavior. Read on to learn more!
Let’s start withe problem statement. When you configure Log Insight to send events over the syslog protocol then Log Insight follows the syslog RFCs. Per the syslog RFC, if the syslog prefix is missing then it MUST be added. Trying to determine whether the prefix exists or not is really expensive so to adhere to the syslog RFCs, Log Insight adds a prefix to all events it forwards over the syslog protocol.
NOTE: This is not unique to Log Insight. For example, rsyslog does the exact same thing.
Let’s use an example to make this more clear. Assume you have the following event path: ESXi over syslog > LI forwarder over CFAPI > LI cluster over syslog > third-party destination. Assume the ESXi log event is the following:
At the third-party destination, the event will look like the following:
As you can see, a prefix has been added as per the syslog RFC. While this does ensure the event sent is RFC compliant it does result in the original event, which in this case was already RFC compliant, to be changed, which may cause issues for the third-party system receiving the event.
In order to better support third-party destinations, Log Insight 4.6 offers the ability to forward events in raw format:
Raw format is the same as syslog except it does not ensure syslog RFC compliance and just forwards the event the way it was received. This is confirmed, but the “i%#8221; dialog:
If this option were selected in the LI cluster example above then the third-party destination would receive the same event that LI did.
This feature is another example of you asked, Log Insight listened. With better support for third-party destinations, it is now easier than ever to integrate Log Insight into your environment. Will you be using this new feature?
© 2018, Steve Flanders. All rights reserved.