Hello,
When I stream UDP data to Splunk using a script to pipe Apache access logs via scripts. The splunk server combines all of the session log data into one entry instead of separate entries, example entry:
4/20/11
11:42:06.000 AM
access_log[25674]: IP="172.168.5.4" HH="www.someweb.com" US=97947 RQ="GET / HTTP/1.1" ST=200 SZ=9102 CON="-" REF="-" UA="ELinks/0.11.1 (textmode; Linux; 237x50-2)" PHP_TIME=90289
access_log[25675]: IP="172.168.5.4" HH="www.someweb.com" US=46385 RQ="GET /home/ HTTP/1.1" ST=200 SZ=9563 CON="-" REF="http://www.someweb.com/" UA="ELinks/0.11.1 (textmode; Linux; 237x50-2)" PHP_TIME=39386
access_log[25673]: IP="172.168.5.4" HH="www.someweb.com" US=44823 RQ="GET /family/ HTTP/1.1" ST=200 SZ=9335 CON="-" REF="http://www.someweb.com/someweb-home/" UA="ELinks/0.11.1 (textmode; Linux; 237x50-2)" PHP_TIME=36921
access_log[25679]: IP="172.168.5.4" HH="www.someweb.com" US=60747 RQ="GET /how_3391681_handle-unruly-children.html HTTP/1.1" ST=200 SZ=12685 CON="-" REF="http://www.someweb.com/someweb-family/" UA="ELinks/0.11.1 (textmode; Linux; 237x50-2)" PHP_TIME=53606
This is a simple perl script I'm using to stream Apache access logs via named pipe:
#!/usr/bin/perl
use IO::Socket;
my $server = $ARGV[0];
my $protocol = $ARGV[1];
my $port = $ARGV[2];
my $socket = IO::Socket::INET->new(PeerAddr => $server, PeerPort => $port, Proto => "$protocol", Type => SOCK_DGRAM);
$| = 1;
while ( <STDIN> ) {
chomp $_;
print $socket "$_\n";
}
In the apache config:
CustomLog "| /usr/local/bin/apache_pipe.pl 172.16.5.55 udp 4444" combine
When streaming UDP data, do the splunk servers need a special char or signal to indicate the line is finished and to add a new entry?
Splunk breaks on linebreaks by default. This is defined using the LINE_BREAKER
directive in props.conf. However, there's also a directive BREAK_ONLY_BEFORE_DATE
that tells Splunk not to break until it finds a timestamp. This defaults to true.
Because of this, and because the events in your log do not have individual timestamps, Splunk won't break them up into individual events. There are two solutions to this that I can think of:
BREAK_ONLY_BEFORE_DATE
to false in props.conf. This should make Splunk rely only on the defined LINE_BREAKER
for breaking events, and take the time that it received the event as timestamp. The drawback is that you won't know when the event was actually generated, so if you import old logs into Splunk you will get incorrect timestamps.Thanks! This is excellent
Splunk breaks on linebreaks by default. This is defined using the LINE_BREAKER
directive in props.conf. However, there's also a directive BREAK_ONLY_BEFORE_DATE
that tells Splunk not to break until it finds a timestamp. This defaults to true.
Because of this, and because the events in your log do not have individual timestamps, Splunk won't break them up into individual events. There are two solutions to this that I can think of:
BREAK_ONLY_BEFORE_DATE
to false in props.conf. This should make Splunk rely only on the defined LINE_BREAKER
for breaking events, and take the time that it received the event as timestamp. The drawback is that you won't know when the event was actually generated, so if you import old logs into Splunk you will get incorrect timestamps.Splunk does have a default LINE_BREAKER setting which defaults to ([\r\n]+) however SHOULD_LINEMERGE is "True" by default which enables the BREAK_ONLY_BEFORE_DATE, BREAK_ONLY_BEFORE, MUST_BREAK_AFTER, ... settings. Setting SHOULD_LINEMERGE = false disables those settings and uses the default LINE_BREAKER.
I would recommend setting up the "SHOULD_LINEMERGE = false" property via props.conf. For instance:
##props.conf
[<your_sourcetype>]
SHOULD_LINEMERGE = false
#DATETIME_CONFIG = CURRENT
This should tell Splunk to treat your data as single line events. On a separate note, I would recommend ensuring that each of your log entries has a date and timestamp. This will ensure that Splunk can properly extract an _time field for your events. If this is not possible you should set DATETIME_CONFIG = CURRENT
as well. This will tell Splunk to take _time
as your index time (_indextime
).
See also: props.conf.spec