Hello,
I am about to onboard 1000+ Windows UF. Those have windows event logs going back many years. Is there a way to exclude any windows eventlog older than 7 days from being ingested during the initial onboarding?
For log files there's an option for inputs.conf on the UF, but nothing similar for eventlog?
Kind Regards
Andre
Hi All,
Resurfacing this old thread to post an alternative solution.
This will increase CPU and memory utilization on the forwarder, but we can combine force_local_processing with RULESET to create a forwarder-side ingest action:
# props.conf
[source::WinEventLog:*]
force_local_processing = true
RULESET-winventlog_ignore_older_than = winventlog_ignore_older_than
# transforms.conf
[winventlog_ignore_older_than]
# send events older than 30 days * 86,400 seconds/day = 2,592,000 seconds to nullQueue
INGEST_EVAL = queue=if((time() - _time > 2592000), "nullQueue", queue)
# easier to read but slower
#INGEST_EVAL = queue=if((time() - _time > relative_time(time(), "-30d"), "nullQueue", queue)
STOP_PROCESSING_IF = queue == "nullQueue"This should work on Splunk Universal Forwarder 9.0 or later, but I've only briefly tested 10.4.
Edit: This may only work in 9.2 and later. I no longer use 9.0 or 9.2 and haven't tested them.
It's worth pointing out however that forcing processing on UF-s is a highly unusual scenario and can be very non-obvious to debug by someone later (especially if not properly documented).
I can't speak to customers not documenting their own stuff, but I do think people should use features, however obscure.
One downside: public Splunk consulting documentation implies (and LLMs, if you use them, infer) that RULESET is only supported on heavy forwarders and indexers. It's not true, but if it sounds plausible, folks will accept it as fact and never question it.
Edit: If anyone does try this in a supported environment and encounters problems, I would encourage them to contact Splunk support and get an answer on the record. I sound cavalier, but I'm no more or less conservative than my engagements want me to be.
(Ab ;-))using features is one thing. Maintainability is another. As a fairly experienced admin of various systems, I'm just saying that even though some things can be done, they not necessarily should be done that particular way.
Quick programming example:
a=1
b=2
temp=a
a=b
b=temp
It's fairly understandable what is happening here - you swap values of two variables.
Now do it another way
a=1
b=2
a=a+b
b=a-b
a=a-b
This code snipped does exactly the same thing but is much much less readable
I'm old, too. My kids remind me daily.
Answers is already well served by conforming solutions and generative AI. Witness the ratio of trustee replies to questions and the downtrend in traffic.
I spend my days mired in compliance-ridden, risk-averse systems. My answers here are both an escape and a way to contribute to a community of practitioners I've enjoyed engaging across venues since Splunk 4.
support confirmed - no way to exclude old windows event logs from being imported.
"The Splunk Universal Forwarder's Windows Event Log input doesn't offer a built-in way to filter events based on age during initial data collection. This means you can't directly configure the forwarder to only send events newer than 7 days when it first starts monitoring.
You'll need to use other methods, like filtering at the indexer level or leveraging props/transforms.conf after the data is indexed, to remove older events. Or else take the backup of the event viewer logs which are older than 7 days in the source machine and remove them before onboarding to splunk."
Kind Regards
Andre
Wait a second. You can't use props/transforms after the events have been indexed. You can do that during indexing after initial ingestion by input.
/opt/splunk/bin/splunk btool props list XmlWinEventLog:Security --debug | grep MAX_DAYS_AGO
/opt/splunk/etc/system/local/props.conf MAX_DAYS_AGO = 7
that should work, right? Present on all indexers. All indexers restarted. (Splunk Enterprise 9.4.2)
TIme to log a support call?
Hi @Andre_
As @inventsekar mentioned, you could use MAX_DAYS_AGO as follows:
== props.conf ==
# If within 3 days old.
[WinEventLog]
MAX_DAYS_AGO = 3
[XmlWinEventLog]
MAX_DAYS_AGO = 3This will then only apply to XmlWinEventLog/WinEventLog
🌟 Did this answer help you? If so, please consider:
Your feedback encourages the volunteers in this community to continue contributing
Hello,
so I've created a props.conf on the indexer under the Windows_TA local folder and put his in:
[WinEventLog]
MAX_DAYS_AGO = 7
[XmlWinEventLog]
MAX_DAYS_AGO = 7
onboarded another Windows Server - still ingested windows event logs going back a few years.
Any ideas why that's not working?
Kind Regards
Andre
Hi @Andre_
1) after props.conf 's update/creation, did you restart the splunkd on the indexer?
2) if yes for above, then pls use the btool command to check if the props.conf got applied or not(you can search for splunk btool options here in communities).
if any reply helps you in any way, a karma point / upvote would be helpful for the author, thanks.
I've done a rolling restart of the cluster and checked. Looks like it "should" work but doesn't.
Since then, I tried this approach:
put a "blacklist_all_WinEvent" app on the UF during initial start. Just an inputs.conf that has "blacklist1 = ." for all winevent sources.
let the UF do it's initial thing and an hour later I remove that app from the UF and restart the UF
whilst not optimal, that would do the trick for onboarding existing servers and automating that is easy enough.
Kind Regards
Andre
that does not work, once you remove the blacklist, it ingests the old events.....
trying that now, does it require a restart?
Hi @Andre_
Pls check the MAX_DAYS_AGO option on the props.conf
https://docs.splunk.com/Documentation/Splunk/9.4.2/Admin/Propsconf
MAX_DAYS_AGO = <integer> * The maximum number of days in the past, from the current date as provided by the input layer (For example forwarder current time, or modtime for files), that an extracted date can be valid. * Splunk software still indexes events with dates older than 'MAX_DAYS_AGO' with the timestamp of the last acceptable event. * If no such acceptable event exists, new events with timestamps older than 'MAX_DAYS_AGO' uses the current timestamp. * For example, if MAX_DAYS_AGO = 10, Splunk software applies the timestamp of the last acceptable event to events with extracted timestamps older than 10 days in the past. If no acceptable event exists, Splunk software applies the current timestamp. * If your data is older than 2000 days, increase this setting. * Highest legal value: 10951 (30 years). * Default: 2000 (5.48 years).
MAX_DAYS_AGO doesn't cut it. It will make Splunk still index the events but it will assume that the timestamp parsed from the event was wrong so it would just assume another timestamp (whatever that would effectively be).
@Andre_ What you could to to prevent some data from being indexed could be to add whitelists/blacklists in inputs matching certain timestamp values. That's a relatively ugly solution and is not something to be kept forever but for a start - might be the way to go. Just be careful because you're doing it differently when you're windows logs as "classic" and differently while it's XML.
MAX_DAYS_AGO - I would set this on the indexer? (our setup is UF -> Indexer)
Will that be a global setting for all incoming data?
Kind Regards
Andre
Another option you can consider is to change the destination path for the Windows Event Logs in Event Viewer and configure Splunk to monitor this new location. This approach allows you to start collecting only new events, effectively avoiding the indexing of historical data. Additionally, by using the standard Splunk input settings (without current_only = 1), you ensure that no events are missed during restarts, as Splunk will continue to track and ingest all new events from the updated log file.
Regards,
Prewin
Splunk Enthusiast | Always happy to help! If this answer helped you, please consider marking it as the solution or giving a Karma. Thanks!
Hi Giuseppe,
"ignoreOlderThan" only applies to log files, not windows event logs (like security events, application events, etc)
Kind Regards
Andre