whitelist and blacklist combination for inputs.conf

[koshyk]

A quite tricky scenario for us in inputs.conf for one of the app. We have multiple directory structure within /var/log but for this purpose, let's assume three files (but different files are present).

/var/log/abc.log
/var/log/audit/audit.log
/var/log/syslog/514/xyz.log

We need
APP1 to monitor files in /var/log/ but NOT from /var/log/syslog/
APP2 to monitor files in /var/log/syslog/ (Technically we have multiple apps to read various devices. So app2 is multiple)

I've read: http://docs.splunk.com/Documentation/Splunk/6.3.2/Data/Whitelistorblacklistspecificincomingdata

Combination1

#does NOT work. No data comes from /var/log/audit
# APP1: 
[monitor:///var/log]
recursive = false 
[monitor:///var/log/audit]
recursive = false
# APP2
[monitor:///var/log/syslog]
recursive = true

Combination2

# does NOT work. 
# APP1
[monitor:///var/log]
recursive = false
blacklist =(syslog)
# APP2
[monitor:///var/log/syslog]
recursive = true

Any other ideas to do blacklist/whitelist combination for inputs.conf ?

[anthonymelita · Accepted solution]

Google brought me here while searching "inputs.conf whitelist blacklist". I realize this is two years old, but the answer is that inputs.conf is read from top to bottom. So your recursive=false is preventing the second stanza from working.
If the inputs were changed to put the top level directory below the subdirectory, it should work:

# APP1
 [monitor:///var/log/audit]
 recursive = false

 # APP2
 [monitor:///var/log/syslog]
 recursive = true

#APP1
 [monitor:///var/log]
 recursive = false 

[koshyk]

seems sensible approach. Wished Splunk had put this in documentation about the "top to bottom" approach in case of contradiction

[ddrillic]

I would avoid using the recursive = false option.

Gave grief to our fellows - Bug in Universal Forwarder? inputs.conf monitor and recursive = false