Getting Data In

Why is host override in inputs.conf not working when it's IP?

meet_vadaria
Engager

I have remote servers dropping logs to a syslog server where I have a Splunk forwarder configured to push it to Splunk.

Remote servers are collecting logs at /var/log/rsyslog//syslog

In input.conf, I am using host_segment = 4 to override host field to remote server's hostname. It's working fine for most of the remote servers.

I have a special case where my remote server is creating a log directory with IP instead of hostname as /var/log/rsyslog//syslog.

I was assuming inputs.conf would still extract IP and use it to override host field, but it didn't work as expected. Somehow, my Splunk forwarder is not doing that, and it's using the default host, which is Splunk forwarder's hostname. It's not able to override hostname with .

I also tried with transforms.conf and props.conf. that didn't work as well. following are my configs.

inputs.conf

Monitor everything from rsyslog directory
[monitor:///var/log/rsyslog/*/syslog]
disabled = false
followTail=0
host_segment = 4
blacklist = \.(gz)$
sourcetype = syslog
source=/var/log/syslog

transforms.conf

[syslog]
DEST_KEY = MetaData:Host
REGEX = \s(\w*)$
FORMAT = host::$1

props.conf

[source::../syslog]
TRANSFORMS-hostname = syslog
0 Karma
1 Solution

FrankVl
Ultra Champion

When using sourcetype syslog, you get hostname extraction from the logs 'for free' based on below config in etc/system/default/props.conf

[syslog]
TRANSFORMS = syslog-host

What I guess is happening:

  • setting source=/var/log/syslogactually breaks the host_segment setting (not sure about this, but it would explain the rest of the behavior)
  • as a result, all hosts get the default host value of the forwarder itself
  • thanks to syslog host extraction from the raw event, you still get the hostname for those machines that properly log their hostname
  • when the folder is showing an IP that probably indicates that host is not logging its name in the syslog header, which means the syslog hostname extraction fails and you keep the default host value of the forwarder

What exactly is the idea behind that transforms you have defined? The way you wrote this, it takes the last word of the event (since you do not define a SOURCE_KEY, it will work on _raw) and put that in the host field. It is probably a good thing you made a mistake in how you wrote [source::../syslog] (looks like you missed 1 . ), otherwise that transforms would have made quite a mess.

So to solve it:

  • Remove that TRANSFORMS-hostname = syslog (or explain us what you want to do with that, so we can help you write it properly)
  • Add TRANSFORMS = to your props.conf under [syslog] to disable the default syslog host extraction
  • Remove source=/var/log/syslog (I expect the host_segment will then start functioning correctly)

View solution in original post

0 Karma

FrankVl
Ultra Champion

When using sourcetype syslog, you get hostname extraction from the logs 'for free' based on below config in etc/system/default/props.conf

[syslog]
TRANSFORMS = syslog-host

What I guess is happening:

  • setting source=/var/log/syslogactually breaks the host_segment setting (not sure about this, but it would explain the rest of the behavior)
  • as a result, all hosts get the default host value of the forwarder itself
  • thanks to syslog host extraction from the raw event, you still get the hostname for those machines that properly log their hostname
  • when the folder is showing an IP that probably indicates that host is not logging its name in the syslog header, which means the syslog hostname extraction fails and you keep the default host value of the forwarder

What exactly is the idea behind that transforms you have defined? The way you wrote this, it takes the last word of the event (since you do not define a SOURCE_KEY, it will work on _raw) and put that in the host field. It is probably a good thing you made a mistake in how you wrote [source::../syslog] (looks like you missed 1 . ), otherwise that transforms would have made quite a mess.

So to solve it:

  • Remove that TRANSFORMS-hostname = syslog (or explain us what you want to do with that, so we can help you write it properly)
  • Add TRANSFORMS = to your props.conf under [syslog] to disable the default syslog host extraction
  • Remove source=/var/log/syslog (I expect the host_segment will then start functioning correctly)
0 Karma

meet_vadaria
Engager

Okay, You are right. Thanks for this but not done yet 🙂 My syslog location in splunk forwarder is /var/log/rsyslog/%year%/%month%/%date%/%host%/syslog which I don't want to get on splunk as source. I want to override it to /var/log/syslog so I can have common source for all hosts.
How do I override source?

thanks again.

0 Karma

FrankVl
Ultra Champion

I would highly recommend keeping all that detail, as it can be very useful when troubleshooting problems with your syslog data to know which exact file the data came from. If you really still want to do it, I see you have a separate question raised on that already, so I'll reply to that.

0 Karma

prakash007
Builder

well, you don't need to explicitly specify source=/var/log/syslog in your inputs, your monitor path with be the source in this case.(eg.: source=/var/log/rsyslog/(ip or hostname)/syslog)

since sourcetype=syslog is a pre-trained sourceytpe within Splunk, you might have to check if any configs are overriding your configs..

./splunk btool props list --debug <sourcetype>
./splunk btool props list --debug syslog

checkout this splunk blog for reference...

https://www.splunk.com/blog/2008/04/16/overriding-default-syslog-host-extraction.html

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In November, the Splunk Threat Research Team had one release of new security content via the Enterprise ...

Index This | Divide 100 by half. What do you get?

November 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...

Stay Connected: Your Guide to December Tech Talks, Office Hours, and Webinars!

❄️ Celebrate the season with our December lineup of Community Office Hours, Tech Talks, and Webinars! ...