Advanced Deployments - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 335

If your syslog events are important to you, it is worth the trouble to at least
use a native syslog receiver on the same hardware, but you should ideally
use separate hardware.
Using a native syslog receiver
The best practice is to use a standalone syslog receiver to write events to
disk. Examples of syslog receivers include syslog-ng or rsyslog . Splunk
is then configured to monitor the directories written by the syslog receiver.
Ideally, the syslog receiver should be configured to write one file or
directory per host. inputs.conf can then be configured to use host_
segment or host_regex to set the value of host . This configuration
has the advantage that props.conf stanzas can be applied by host ,
for instance, setting TZ by hostname pattern. This is not possible if host
is parsed out of the log messages, as is commonly the case with syslog.
The advantages of a standalone process include:
• A standalone process has no other tasks to accomplish and is more likely to
have the processor time to retrieve events from the kernel buffers before data
is pushed out of the buffer
• The interim files act as a buffer so that, in the case of a Splunk slowdown or
outage, events are not lost
• The syslog data is on disk, so it can be archived independently or queried
with other scripts, as appropriate
• If a file is written for each host, the hostname can be extracted from the path
to the file, and different parsing rules (for instance time zone) can be applied
at that time
A small installation would look like the following figure: