Log Insight: Ingestion API versus Syslog Protocol Part 2/2

In my last post, I talked about the differences between how events are displayed over the syslog protocol, which has a strict format structure, and the ingestion API, which sends events as-is. In this post, I would like to talk about the differences between using the syslog protocol versus the ingestion API when it comes to the Log Insight agent and the Log Insight forwarder.

not_equal_to_u2260_icon_256x256

Agent

The Log Insight agent defaults to the cfapi (i.e. ingestion API) to send events. With the cfapi, events are sent in their original format to Log Insight. Events sent over the cfapi do not have to follow the guidelines of a syslog event and are not modified to comply with the syslog RFC. In addition to the event, the cfapi provides the ability to pass metadata with the event that gets added as static fields to the event in Log Insight. This metadata is similar to the metadata provided by the syslog protocol, but provides even more information including filepath and any configured tags.

It is important to note that when the agent is configured to use the syslog protocol static fields, such as filepath and configured tags, are treated in a different way. Since the syslog protocol does not understand the Log Insight notion of static fields, but adding more information to events can be important, another way to send metadata information is needed. To handle this, the Log Insight agent adds metadata to the STRUCTURED-DATA section of the syslog events per syslog RFC 5424.

As an example, let’s say I have the following log message:

The log message was written to /var/log/apache2/access.log. I would like to collect this log and add a tag where product=apache. To do this, my Log Insight agent configuration would look like the following:

Note that in addition to the tag, the agent also supplies the filepath as a tag as well. If I configure the Log Insight agent to use the syslog protocol then the event will look like the following on the destination logging device:

Notice the section in bold, which represents STRUCTURED-DATA the agent has added to apply metadata while conforming with the syslog RFC. Now, it is clearly easy to remove tags in the configuration to prevent that information from being passed, but how do you delete metadata that the agent sets automatically like filepath? Well, the agent provides an exclude_fields option. As such, you could change your agent configuration to:

With the above configuration, events sent over the syslog protocol will not contain any STRUCTURED-DATA information:

Forwarder

The forwarder behaves similar to agents in that it supports both the ingestion API and syslog protocols. In addition, the forwarder leveraging the ingestion API allows for tags to be passed as metadata. The forwarder leveraging the syslog protocol does not support tags today, however when the syslog protocol is used with the forwarder, STRUCTURED-DATA will be forwarded in three specific cases:

  1. For any tags sent by an agent over the ingestion API
  2. For vR Ops inventory mapping static fields
  3. To indicate the source of syslog events — only if vR Ops inventory fields exist

For example, here is an example forwarded event that contains all cases 2 and 3 listed above:

Note there is no way to prevent STRUCTURED-DATA from being forwarded today — like was demonstrated in the agent section above — if any of the three cases above are met.

Summary

As you can see, there are subtle differences between the cfapi and syslog protocols when it comes to the agent and/or forwarders in Log Insight. Careful consideration should be taken to leverage these features properly within your environment. Whenever possible, the Log Insight ingestion API should be used. If the syslog protocol needs to be used, the configuration should be validated for the most optimal experience.

© 2015, Steve Flanders. All rights reserved.

Leave a Reply