Hmm. No, not doing anything with transforms.
On the UF, the monitor stanza looks like:
[monitor:///var/something/something/]
sourcetype = syslog
whitelist = /syslog_\d{8}$
recursive = true
index = index_for_that_syslog_stuff
ignoreOlderThan = 90d
So the sourcetype is getting set there.
I started wondering how it actually does figure out the hostname. Rather than say, using the local hostname where the source file lives.
I did not write this stuff, but the UF deployment also has a props.conf and a transforms.conf. The props.conf is for other sourcetypes, none of which would match syslog and then of course, nothing in transforms would match that either. And really, because this isn't the parsing layer, I think a lot of this is just ignored anyway.
This leads me to think that something is grabbing that syslog sourcetype and picking out the field after the date and taking it as the hostname.
FYI, the filename is .../syslog_YYYYMMDD
I looked on the indexer and the closest things that match either the sourcetype or the source are
[delayedrule::syslog] -- built-in but should only be called if the sourcetype isn't set
[source::....syslog] -- from Splunk_TA_nix's props.conf, doesn't match and doesn't set TZ
[source::.../syslog(.\d+)?] -- built-in, doesn't match filename
[syslog] -- from Splunk_TA_nix's props.conf, doesn't set TZ and host:: should take precendence, no?
[syslog] does have some host-related transforms, but they're all "REPORT"
I was primarily looking for a source:: stanza that might override any host:: TZ I'd set. It's my assumption that all 3 (source, host, sourcetype) are merged in that sequence such that any TZ settings I had for host are then merged "down" to sourcetype.
Still rather befuddled. The btool output definitely shows me the correct TZ for that host in props.conf on one of the indexers.
Thanks
... View more