We have a single inputs.conf stanza that sends the data from "targetLog.log" to a different indexer, "indexerB", than everything else being sent from that forwarder. When the app is enabled, the Universal Forwarder (UF) also sends its internal logs to that same indexer. It should *only* be sending data from "targetLog.log" and not the internal logs. When I found out, I attempted to force the internal logs to only be sent to the correct indexers, "indexerA", through the props.conf and transforms.conf. That didn't seem to work either, even though they're supposed to override the inputs.conf which overrides the outputs.conf. Why would it *still* send the internal logs to indexerB even when I've specifically told it not to? I don't have direct access to the UF, so certain methods of troubleshooting prove challenging.
inputs.conf
[monitor://targetLog.log]
disabled = 0
index = dest_index
sourcetype = dest_sourcetype
_TCP_ROUTING = indexerB:9997
props.conf
[source::*/var/log/splunk/*.log]
TRANSFORMS-linux_internal_logs_to_indexerA = internal_logs_to_indexerA
[source::*\\var\\log\\splunk\\*.log]
TRANSFORMS-windows_internal_logs_to_indexerA = internal_logs_to_indexerA
transforms.conf
[internal_logs_to_indexerA]
SOURCE_KEY = _MetaData:Index
REGEX = _.*
DEST_KEY = _TCP_ROUTING
FORMAT = indexerA:9997
At this point, I have no idea what's going on to cause it or if it's even preventable. I tried pushing a custom app to retrieve btool info, but then I had to deal with Splunk not properly parsing the data. It'd merge the output from one command but wouldn't do it for others. I'd have separate events for each line and wouldn't be able to tell which line went to which stanza, *even* though I specified "SHOULD_LINEMERGE = true". That's a problem in and of itself that I don't have time to mess with right now.
Anyone have any thoughts on why it would still send the internal logs when 1) I *only* told it to forward data from targetLog.log, and 2) I've even specifically told it *not* to forward the internal logs?
↧