How the Splunk platform handles syslog data over the UDP network protocol

If you run Splunk Cloud Platform, you can configure the Splunk universal forwarder to listen on a User Datagram Protocol (UDP) network port and forward that data to your Splunk Cloud Platform deployment.

Splunk Enterprise indexers can act as syslog servers that handle incoming data streams that comply with the syslog messaging standard. Splunk Enterprise can also act as a syslog message sender. Splunk Cloud Platform cannot send syslog messages, nor can it move messages from one device to another.

How the Splunk platform handles syslog inputs

When you configure a UDP network input to listen to a syslog-standard data stream on Splunk Enterprise or the universal forwarder, any syslog events that arrive through the input receive a timestamp and connected host field. The platform prepends these fields to each event before it indexes them. When you configure a universal forwarder to send data to Splunk Cloud Platform, Splunk Cloud Platform indexes the fields as it receives them from the universal forwarder.

The Splunk platform does not modify Transmission Control Protocol (TCP) network packets in this fashion. If you send syslog data over TCP, the platform does not strip priority information from the events. It does, however, prepend a host name and timestamp to the event unless you configure it not to. One TCP source stream will be assigned to one data pipeline and any others, so you should adjust for scalability.

How Splunk Enterprise handles syslog outputs

The follow section applies to Splunk Enterprise only. Neither Splunk Cloud Platform nor the universal forwarder has the capability to forward events to another syslog server.

Splunk Enterprise can forward events to another syslog server. When it does, it prepends the priority information to the event so that the downstream syslog server can translate the events properly.

When the event reaches the downstream syslog server, that machine prepends a timestamp, priority, and connected host name, which is the Splunk Enterprise instance, to the event.

You can also prepend a timestamp and host name to the event at the time you forward the event to the syslog server. You do this as part of modifying the data as it leaves the Splunk Enterprise instance.

For information on configuring routing, filtering, and usage of source types, see Route and filter data in the Splunk Enterprise Forwarding Data manual and the props.conf spec file in the Admin Manual.

How Splunk Enterprise moves syslog events when you configure it to use syslog source type

The following section applies to Splunk Enterprise only. Splunk Cloud Platform isn't able to send syslog events to another downstream syslog server.

The following diagram shows how Splunk Enterprise moves two syslog messages from one syslog server to another. In the diagram, Splunk Enterprise listens on a UDP network port and indexes incoming events. On the other side, the same instance forwards events to a third-party syslog server.

In the diagram, Message A originates as a syslog event and Message B originates as a similar event that does not have priority information associated with it. Upon receipt, Splunk Enterprise tags the events with a timestamp and the host that generated the event.

If you configured the instance as a forwarder, Splunk Enterprise then transforms the events by adding a priority header that you specify in the outputs.conf file before it forwards the events on to the syslog server. Once they arrive at the syslog server, that server prepends the timestamp and host data to the events as it received them from the Splunk Enterprise instance.

How Splunk Enterprise moves syslog events when you configure a custom source type

The following section applies to Splunk Enterprise only. Splunk Cloud Platform isn't able to move syslog events.

In this diagram, Splunk Enterprise has been configured to use a non-syslog source type. The initial Messages A and B are identical to the first example. In this example, Splunk Enterprise prepends the event with an originating host name or IP address.

How Splunk Enterprise moves syslog events when you configure it with a timestamp

The following section applies to Splunk Enterprise only. Splunk Cloud Platform isn't able to move syslog events.

You can also configure Splunk Enterprise to add timestamps to syslog events when you forward those events. You could add a timestamp to the events when you don't want the downstream server to add its own timestamp.

The following diagram shows the required attribute and depicts how Splunk Enterprise deals with the data. The initial Messages A and B are identical to the first and second examples. Splunk Enterprise prepends the events with a timestamp and an originating host name or IP address.

Caveats to using Splunk Enterprise as a syslog server or message sender

The following section applies to Splunk Enterprise only. Splunk Cloud Platform isn't able to be used as a syslog server or message sender.

While you can configure Splunk Enterprise to receive syslog events directly, refrain from doing so for the following reasons:

• Splunk best practice involves setting up a separate machine that runs a syslog service to handle syslog tasks.
• The Splunk platform modifies syslog data by default as part of the indexing process. It assigns a timestamp and a host to the event.
• Syslog data streams to only one Splunk Enterprise instance in this scenario. In a deployment with multiple indexers, you must perform additional work to distribute the streams across those indexers
• If Splunk Enterprise or fails for any reason, any syslog messages that arrive during the downtime can be irrecoverably lost.

Don't substitute Splunk Enterprise for a syslog server in regular use unless you have no other options.

If you must retain raw syslog data, such as when a data retention policy requires access to untouched events, consider using a tool such as syslog-ng to simultaneously save the raw data to a log file and forward those events to your Splunk Enterprise instance. These tools give you the advantage of indexing the log file later if you want.