Two syslogs inputs cannot run simultaneously

Description

I am running a configuration where I [want to] have two syslog inputs side by side, listening on different ports. Only one of these inputs (seemingly first one listed in the config file) successfully receives events. If I comment out that one, the second one will start receiving events successfully.

When I had all events go to a single port, the daemon easily handled the traffic, so it not starvation/lack of resources type of thing.

PS: this is my config:

input
{
syslog
{
host => "0.0.0.0"
port => 23520
add_field => { "shipper" => "sl" }
severity_labels => [ "panic", "alert", "crit", "err", "warn", "notice", "info", "debug" ]
}

syslog
{
host => "0.0.0.0"
port => 23519
add_field => { "shipper" => "sl" }
tags => [ "ctx" ]
severity_labels => [ "panic", "alert", "crit", "err", "warn", "notice", "info", "debug" ]
}
}

output
{
redis
{
batch => true
batch_events => 25
batch_timeout => 5
data_type => "list"
host => ["localhost"]
key => "logstash"
port => 6379
workers => 4
shuffle_hosts => false
}

##DEBUG
#file
#{

  1. path => "/var/log/logstash/broker/temp.out"
    #}
    }

Gliffy Diagrams

Activity

Show:

TempW May 8, 2014 at 6:10 PM

Ok, I will keep this in mind. I myself have had a few gripes with the input; one problem is that it disassembles the message when it receives it, which makes it inconvenient if I, for example, wanted to back up the original in addition to processing it through various filters. Maybe it's time to do as you say and go back to TCP/UDP.

Jason Kendall May 7, 2014 at 6:39 PM

Thanks for the report, and followup, and closure.

Something you might consiter is using the UDP/TCP inputs instead and manually parsing the syslog data using filters. The problem is, syslog input really likes RFC standard syslog messages. Any deviation and it chokes - With good reason, since it's expecting syslog.

Alas, ALOT of devices may send "SYSLOG" type events, and it's possible one of the devices your using is sending maybe one message that isn't standard causing that listener to die.

If you use the TCP/UDP input, there is options using filters to access only what you need.

TempW May 7, 2014 at 5:21 PM

Hmm, possibly a false alarm: after a restart things started moving from both ports. Possibly this was an issue upstream. I'll resolve for now; if it reoccurs I will reopen.

Sorry for noise.

Cannot Reproduce

Details

Assignee

Reporter

Affects versions

Created May 7, 2014 at 5:04 PM
Updated May 8, 2014 at 6:10 PM
Resolved May 7, 2014 at 5:21 PM