About TheWoodRanger

TheWoodRanger · ‎08-25-2025

To add to @aberkow 's answer - throttling is a mechanism to interrupt the alert actions attached to the search object, meaning throttling rules are applied after a search completes: Search completes > Check Alert conditions > Run alert actions if condition is true When the `sendResultToTicket` command is within the SPL of the search, throttling configurations aren't considered at all, you'd need to incorporate logic that avoids executing that command if the ticket already exists, etc. For your case, you'd need to set up `sendResultToTicket` as an alert action itself that executes on each result in order to utilize throttling (pointed to specific fields) as a means to avoid running the same action on the same set of result fields. To update his answer a bit, the other way is to use in-SPL deduplication/throttling logic. You can preserve the original output by using appendpipe instead of filtering all the results matching the lookup. Appendpipe runs a subsearch on the current results in a nested scope, which lets you run commands and filter without affecting the outer search results (appendpipe results will be appended if you don't end with `| where false()` ) I also changed the filter subsearch to use stats values() instead of a | table output to avoid subsearch limits of 50k. blah blah ... | eval field1=fieldx.last_report_time | table field1 field2 field3, field4, ticket | appendpipe [| search NOT ticket IN [ | inputlookup ticketCsv.csv | search <desired condition, ie status="Open"> | stats values(ticket) AS ticketIDsToFilter | rename ticketIDsToFilter AS search | eval search = "(\"" . mvjoin(search, "\", \"") . "\")" ] | sendResultToTicket | outputlookup append=t ticketCsv.csv | where false() ]

TheWoodRanger · ‎08-14-2025

The Check Point App for Splunk (https://splunkbase.splunk.com/app/4293) was recently updated on June 9th, 2025 after a 4 year gap, making it Splunk Cloud compatible. There are no release notes added, no updated information on the app listing page, and Checkpoint documentation related to Splunk onboarding has not been modified, still reflecting app v1.0.0 from 2018 and the usage of the log exporter for a version of Checkpoint firewall that's EOL. The Splunk Addon for Checkpoint Log Exporter (https://splunkbase.splunk.com/app/5478) was last updated February 2024. There's significant inconsistencies between the field extractions, eventtype definitions and tag assignments, and general transforms configured between these two apps.. the hope was that a proper update to the Checkpoint app would make it the "correct" one to use, but it does not incorporate many of the configs found in the Log Exporter TA, and vice versa. Has anyone sorted out a unified approach to this mess? Validated which configurations should be applied for data exported via the log exporter over syslog? ie, the definitions for the "network" tag to populate the Network Traffic DMA are significantly different: # Splunk Addon for Checkpoint Log Exporter snippet from eventtypes.conf for "network" tag: [cp_network_communicate] search = (sourcetype=cp_log OR sourcetype=cp_log:syslog) AND (((proto=* OR nat_rulenum=*) OR (product="URL Filtering" AND conn_direction=*)) NOT (product="Anti Phishing" OR product="Anti-Spam and Email Security" OR product="DLP" OR alert=* OR malware_action=* OR protection_name=* OR file_name=* OR auth_method=* OR event_name="IP sweep from external network")) #tags = network communicate [cp_change_network] search = (sourcetype=cp_log OR sourcetype=cp_log:syslog) AND internal_ca="VPN certificate created" #tags = change network # Check point App for Splunk snippet from eventtypes.conf for "network" tag: [Network_Sessions] search = (sourcetype=cp_log AND ((product="*VPN*" OR product="*Mobile*") OR (fw_subproduct="*VPN*"))) [Network_Traffic] search = (sourcetype=cp_log AND product="*Firewall*" AND NOT fw_subproduct="*VPN*")

TheWoodRanger · ‎10-11-2024

Excited for this one! Great functionality and extremely useful. Shame I haven't seen this mentioned in any communications I'm receiving from Splunk side.

TheWoodRanger · ‎04-06-2023

Bumping this post - with the newer ACS app management libraries, pushing apps from an orchestration utility like Ansible to SplCloud is becoming more accessible and pervasive - these apps must be pushed with /default/ consolidated configurations, so this conflict of permissions + the user's local version precedence behavior is a concern. @ianpearl As a workaround to your problem, I would try running a API call for the affected /local/ savedsearch object path to either update the sharing ("separating" the local and default versions again) or to delete the object for that specific path. Try looking at the output of: `| rest /servicesNS/-/-/configs/conf-savedsearches splunk_server=local | search title="<search title>" | table title, id, eai:acl.removable, eai:acl.owner` to see whether there are multiple results returned - indicating two distinct "id" references. Splunk is supposed to be designed in a way that won't allow duplicate id values for a given object - it's why I can create a duplicated object name that's private, but I can't share it globally if there's another one already shared globally (confirmed behavior on a field alias object in v9.0.4) Theoretically, there should be a unique ID route to the "local" version of that object, likely something like: https://.../servicesNS/appname/USER/saved/searches/<search name> which you could make an API call to for removal without touching the /default/ version.

TheWoodRanger · ‎06-23-2022

After install of a new Enterprise 9.0 instance, there's a lot of new logging appearing in _internal. Notably, this log line is being generated every 15 seconds and there's no clear indication in documentation how to disable it. 2022-06-23 09:25:05,957 INFO [assist::supervisor_modular_input.py] [context] [build_supervisor_secrets] [4932] Secret load failed, key=tenant_id, error=[HTTP 404] https://127.0.0.1:8090/servicesNS/nobody/splunk_assist/storage/passwords/tenant_id?output_mode=json source = D:\Splunk\var\log\splunk\splunk_assist_supervisor_modular_input.log sourcetype = splunk_assist_uiassets_modular_input.log* This is a substantial increase in overall volume of logs with "error" in them, not to mention the rest of the logging related to these new "assist supervisor" processes. splunkd.log is flooded with messages from instance_id_modular_input.py executing. The Splunk Assist documentation (https://docs.splunk.com/Documentation/Splunk/9.0.0/DMC/AssistIntro) has no information on how to adjust the log level or disable specific components. This is on an instance *without* a Splunk Assist activation code installed, meaning this is generating at this volume out-of-box. It's incredibly frustrating that searching this log file name "splunk_assist_uiassets_modular_input.log" returns 0 results in all of Splunk Docs. How is this useful if there's no information on what to do with it, and why am I paying more for Cloud Compute to ingest all this additional volume without any instruction for how to configure it? Any assistance in finding relevant documentation would be appreciated. Edit: There's a new .conf file for this - assist.conf - that is completely undocumented. Nothing in the configuration file reference doc page. https://docs.splunk.com/Documentation/Splunk/9.0.0/Admin/assistconf The inputs generating all this extra logging are located in $SPLUNK_HOME/etc/apps/splunk_assist Until more information becomes available, I've disabled them: [supervisor_modular_input://default] disabled = 1 [instance_id_modular_input://default] disabled = 1 [uiassets_modular_input://default] disabled = 1 [selfupdate_modular_input://default] disabled = 1

TheWoodRanger · ‎05-19-2021

You have to understand the behavior of a multivalue field; the MV field itself is essentially always treated as an array of strings: ["val1", "val2", "val3"] so even in the example you noted where you mvexpand it out, running mvsort on the final product after you condense it again will sort it back to lexographic ordering. Given that, you have to build a solution with lexographic sorting in mind. First, I want to note that the more densely packed you get with nested evals, the more likely it is to break over time as the underlying search core engine may change. I've seen this happen, so better to split it apart into multiple evals than aim to run it all at once, since it allows Splunk to handle memory transition better that way anyways. That said, here's your solution: | makeresults | fields - _time | eval number_list = split("4,3,2,1,7,2,21,9,12,19,7",",") | eval number_list_ordered = mvmap( mvsort(mvmap(mvdedup(number_list), len(number_list) . "-" . number_list)), substr(number_list, 3) ) This will work for up to 9 character length values in a MV, and uses TWO cascading mvmap() functions to attach a number representing the length of the given value to the value itself, which makes the lexographic sorting work as we want it to.To illustrate the steps: | makeresults | fields - _time | eval number_list = split("4,3,2,1,7,2,21,9,12,19,7",",") | eval number_list_2 = mvdedup(number_list) | eval number_list_3 = mvmap(number_list_2, len(number_list_2) . "-" . number_list_2) | eval number_list_4 = mvsort(number_list_3) | eval number_list_final = mvmap(number_list_4, substr(number_list_4, 3)) Make sure to upvote.

TheWoodRanger · ‎07-23-2020

Heyo! Stumbled across this thread and thought I'd offer up an easier alternative than using the internal or metrics logging, if you've got privileges to hit the REST endpoints. You can also use this to output the captain info via SPL: | rest /services/shcluster/status splunk_server=local Which outputs the captain information in the captain.* fields. We use `splunk_server=local` to avoid trying to query other SHC / IDX members for captain info (which will throw errors), since we only need information from the SH we're running it on. See: https://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTcluster#shcluster.2Fstatus

TheWoodRanger · ‎07-15-2020

Got a random notification for this thread and realized I knew more than I did then.. You're absolutely correct here. The `provenance` field gathered from _introspection enables you to fit where the search was initiated from! Here's a generalized introspection search for everyone: index=_introspection sourcetype=splunk_resource_usage component=PerProcess data.search_props.sid::* data.search_props.role="head" | fields _time, data.*, host | eval label = if(isnotnull('data.search_props.label'), 'data.search_props.label', "") | eval provenance = if(isnotnull('data.search_props.provenance'), 'data.search_props.provenance', "unknown") | eval read_mb = 'data.read_mb' | eval written_mb = 'data.written_mb' | eval process = 'data.process' | eval pid = 'data.pid' | eval elapsed = 'data.elapsed' | eval mem_used = 'data.mem_used' | eval mem = 'data.mem' | eval pct_memory = 'data.pct_memory' | eval pct_cpu = 'data.pct_cpu' | eval sid = 'data.search_props.sid' | eval app = 'data.search_props.app' | eval label = 'data.search_props.label' | eval type = 'data.search_props.type' | eval mode = 'data.search_props.mode' | eval user = 'data.search_props.user' | eval role = 'data.search_props.role' | fields _time, host, process, pid, elapsed, mem_used, mem, pct_memory, pct_cpu, sid, app, label, type, mode, user, label, provenance, read_mb, written_mb | stats latest(*) AS * BY sid

TheWoodRanger · ‎04-18-2017

After experiencing this problem myself, I discovered the answer. When a dashboard, written in SimpleXML format, invokes a tag without an id value specified, Splunk automatically uses this "search5"/"search6"/"search7" default string value as the name of the search when logging in _audit. I don't know what factors into the actual different in numbers, but when I added id values to a dashboard that didn't have them, the new ID's showed up in the logging in the same place that the "search5" type values did. I don't have an answer for how to appropriately deal with the problem that this results in, namely that you can't differentiate searches that are all falling under these default values. It's rough to consider trying to force everyone that created dashboards to assign ID values to all of their searches. Splunk!!! Give us a way to break out these searches more effectively, namely even include the dashboard view they're being run in so we have a way of isolating them! Answer/guidance needed.

TheWoodRanger · ‎07-20-2016

,The "delete" command just makes the events unsearchable, it doesn't remove them from the Summary Index. If space is an issue, be wary of this as the size of the index will still include all of the events deleted using | delete "Using the delete command marks all of the events returned by the search as deleted. Subsequent searches do not return the marked events. No user, not even a user with admin permissions, is able to view this data after deletion. The delete command does not reclaim disk space."

Posts	10
Solutions	0
Karma Given	11
Karma Received	6
Member Since	‎03-18-2016

Online Status	Offline
Date Last Visited	‎08-26-2025 09:28 AM

Check Point App vs Log Exporter TA

New Splunk Assist Logging is Undocumented

Re: How does throttle work

Check Point App vs Log Exporter TA

Re: Exporting Splunk Apps

Re: fixing locked knowledge object local/default c...

New Splunk Assist Logging is Undocumented

Re: tonumber for numerical rather than lexigraphic...

Re: What are my options to track the captain switc...

Re: I see a list of generic names under "savedsear...

Re: I see a list of generic names under "savedsear...

Re: I have a saved search scheduled to write to a ...

Join the Conversation