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
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

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

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...