Getting Data In

Heavy forwarder filters

apezuela
Explorer

Hi,

I want to filter some events in my heavy forwarder device. I want discart events what contain "PIX" but it is not filtering anything.

I modified follow files:

$SPLUNK_HOME/etc/system/local/inputs.conf

[monitor:///var/log/PIX515]
blacklist = \.(gz)
disabled = false
followTail = 0
host = password.enagas.eng
sourcetype = network_devices

$SPLUNK_HOME/etc/system/local/props.conf

[source:://var/log/REDES]
TRANSFORMS-null= setnull

$SPLUNK_HOME/etc/system/local/transforms.conf

[setnull]
REGEX = .*PIX-1.*
DEST_KEY = queue
FORMAT = nullQueue

How can I know what is happening?


UPDATE:

Hi,

I did a mistake, my configuration is:

$SPLUNK_HOME/etc/system/local/inputs.conf

[monitor:///var/log/REDES]
blacklist = \.(gz) 
disabled = false 
followTail = 0 
host = password.enagas.eng
sourcetype = network_devices

$SPLUNK_HOME/etc/system/local/props.conf

[source:://var/log/REDES]
TRANSFORMS-null= setnull

I chose that sourcetype because I am doing testing with configuration.

Your suggestion is to changed in props.conf

[source:://var/log/REDES] to [sourcetype::network_devices]


UPDATE2:

I rewrote my configuration, but it still not working:

$SPLUNK_HOME/etc/system/local/inputs.conf

[monitor:///var/log/REDES]
blacklist = \.(gz) 
disabled = false 
followTail = 0 
host = password.enagas.eng
sourcetype = cisco

$SPLUNK_HOME/etc/system/local/props.conf

[cisco]
TRANSFORMS-null= setnull

$SPLUNK_HOME/etc/system/local/transforms.conf

[setnull]
REGEX = .*PIX-1.*
DEST_KEY = queue
FORMAT = nullQueue

I want filter next log message:

Mar 19 16:48:11 72.16.30.100 %PIX-1-106021: Deny UDP reverse path check from

0 Karma

kristian_kolb
Ultra Champion

Do you have the correct props.conf stanza? (i.e. source:://var/log/REDES)? It seems to differ from the path in the monitor in inputs.conf.

It is probably a good idea to make use of the sourcetype, rather than the source attribute - but perhaps you've been using the network_devices sourcetype for totally different types of log as well.

Usually, a sourcetype should describe an event format, which so that all those things like field extractions can be made simpler. Grouping by function is better to do on the index level (i.e. separate indexes for network, web, windows_events etc etc. That approach allows you to set access restrictions easier as well...


UPDATE:

Four small things;
1) Use the 'code' button that looks like 1010101 when posting example of code that may contain special characters.

2) in props.conf it should be [network_devices]. It's just one of those special things. source and host still requires the :: notation.

3) The idea of using the sourcetype is more of a mindset thing; if you have the same type of log from several different hosts they should have the same sourcetype, as you'll probably want to extract the same fields from them. Having a too wide sourcetype definition will send too many events through unnecessary field extraction regexes that will never match. Having a too narrow sourcetype definition will force you to duplication the extraction configurations.

4) Update your original questions (or answers) rather than creating new ones.

/k

0 Karma

kristian_kolb
Ultra Champion

see updates above

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

[Puzzles] Solve, Learn, Repeat: Matching cron expressions

This puzzle (first published here) is based on matching timestamps to cron expressions.All the timestamps ...

Design, Compete, Win: Submit Your Best Splunk Dashboards for a .conf26 Pass

Hello Splunkers,  We’re excited to kick off a Splunk Dashboard contest! We know that dashboards are a primary ...

May 2026 Splunk Expert Sessions: Security & Observability

Level Up Your Operations: May 2026 Splunk Expert Sessions Whether you are refining your security posture or ...