Positive lookahead wastes resources.  Over millions of events, those extra cycles add up to excess SVC consumption.  This works better LINE_BREAKER = ([\r\n]+)Running ... View more

It's not that simple and we don't have enough information.  Have a conversation with your Splunk account team and they will be able to give you the answer that fits your environment. ... View more

Subsearches are performed first, before the main search executes.  That's why there's nothing for the lookup command to find. ... View more

What you're trying to do seems like overkill for a data dictionary.  It also ignores queries contained in saved searches.  I don't see how parsing search queries helps build a data dictionary; although I can see how it might show what data people are searching for. When I work with my customers to build data dictionaries, we use nightly scheduled searches to pull lists of sources and sourcetypes from the indexes.  Using the tstats command makes this fast and lightweight. | tstats count where index=* by index,sourcetype | outputlookup DD_sourcetypes.csv.gz Once the lookup file is created, you can use it to build your Data Dictionary dashboard. Don't forget to add logic that trims the lookup file or else it might grow forever. ... View more

1. This information is available from the eai:acl.app and label fields, respectively. 2. Not all panels have a name.  To get the names, parse the eai:data field and pull out the dashboard.row.panel.title and form.row.panel.title elements. | rest splunk_server=local /servicesNS/-/-/data/ui/views | fields eai:acl.app label eai:data | rename eai:* as * | spath input=data | rename dashboard.* as *, form.* as * | fields acl.app label row.panel.title Note that this SPL works only with Simple XML dashboards.  That's because Dashboard Studio uses a very different name scheme for elements and because the spath command fails on DS dashboards because it contains JSON nested within XML. 3. This is tricky because base searches can exist both within and without a panel.  Also, you'll probably want to retrieve the earliest and latest elements for each query. 4. This is in the row.panel.search.query and row.panel.*.search.query elements, however, not all panels have a query. 5. This is another tricky bit.  The data returned above will be multi-valued since there may be many elements with the same name ("row.panel.table.search.query", for example).  Mapping a panel name to its query will be a challenge. If you still want to attempt this (and, like @ITWhisperer , I wonder about the utility of this), then consider using Python instead of SPL to do it. Depending on the use case, it may be possible to get much of the same information from Splunk's internal logs.  Tell us more about the use case so we might offer other solutions. ... View more

Have you tried fixing the inputs.conf error to see if that makes a difference? ... View more

It may help to enumerate the data fields rather than have Splunk extract them from the input file.  Use the FIELD_NAMES setting to do that.  See https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.0/configuration-file-reference/10.0.2-configuration-file-reference/props.conf#:~:text=set)%3A%20not%20set-,FIELD_NAMES,-%3D%20%5B%20%3Cstring%3E%2C...%2C%20%3Cstring%3E%5D%0A*%20Some ... View more

Contact your Splunk account team.  They will look at your Splunk usage and will be able to determine if you can save any money by switching to workload pricing. ... View more

TIME_PREFIX is the wrong setting to use for CSV files.  Use TIMESTAMP_FIELDS, instead. Also, the TIME_FORMAT setting should be "%Y-%m-%d %H:%M:%S to pick the time as well as the date of the events. ... View more

Make sure you installed a Splunk package that is compatible with your platform (Windows, ARM, etc). ... View more

Deployment Servers (DS) do not process data.  They're only for managing forwarders.  The forwarders contact the DS, get a list of apps, then download and install them.  Typically, one of those apps contains an outputs.conf file that tells the forwarder how to connect to Splunk Cloud (including the required certificate). All forwarders *should* send their data directly to Splunk Cloud.  In some circumstances, however, it may be necessary to send the data to an intermediate forwarder (IF) that then sends it to Splunk Cloud.  The IF should NOT be the DS. Contact Splunk Support by phone or via the support portal. ... View more

Access to splunkd.log is available to anyone whose role gives them access to the _internal index.  The TA's logs should be in the same index. If you don't have access, contact your Splunk Admin. ... View more

It depends on what data you're trying to get from AWS to Splunk Cloud.  Splunkbase has add-ons for CloudWatch, CloudTrail, GuardDuty, and others.  You probably should look at the Splunk Add-on for Amazon Web Services (https://splunkbase.splunk.com/app/1876) first, however. ... View more

This is incorrect. Retention is based on the _time field.  While this is lightly documented (if at all), I have personal experience to confirm it.  I've seen several customers have buckets that didn't freeze on schedule because they contained events with _time values in the future (2034, in some cases).  Despite the fact that those events were indexed 30-180 days ago, the bucket was not frozen because the latest event in the bucket had a _time field several years from now. ... View more

The first thing to do is determine *why* the searches are being skipped.  Then you can take corrective measures and avoid having to worry about replays. The most common causes of skipped searches are 1) too many searches running at the same time; and 2) searches not completing before the next scheduled run-time.  The Monitoring Console will list skip searches and the reason(s) for the skips. To correct the first issue, examine the schedules of each search and ensure they are evenly distributed around the clock (as much as is practical, at least).  It's very common for the majority of searches to run at top of each hour.  To avoid that, look for cron schedules that start with "0" or "*". To correct the second issue, examine the search to see why it is slow.  It's possible the SPL could be made more efficient, or perhaps it's searching too much data or too large of a time window.  If the search cannot be improved then change the schedule so it runs less often. Finally, consider running the searches on a continuous schedule.  That prevents them from being skipped.  See https://help.splunk.com/en/splunk-enterprise-security-7/tutorials-and-use-cases/7.3/correlation-search-tutorial/part-4-schedule-the-correlation-search ... View more

The eval of expandedvalues is failing because the replace function cannot accept a multi-value argument. @ITWhisperer provided the solution before I could. ... View more

By default, the inputlookup command reads the entire lookup file and ignores the time picker.  If you create a lookup definition for the file and select the "Configure time-based lookup" option then Splunk should honor the time picker when reading the file. The where command should work if the _time field exists in the lookup file and the value is a Unix epoch.  See this posting for more: https://community.splunk.com/t5/Splunk-Search/How-to-query-a-lookup-table-based-on-time/m-p/488934 ... View more

Have you confirmed the date_hour field is present in the events and that it has values 0-23?  If it is not present or doesn't have the expected values then it will have to be extracted manually, like this: index=endpoint_ms_winevents sourcetype=XmlWinEventLog user=TESTER EventID=4624 OR EventID=4634 earliest=-7d@d latest=now | eval date_hour=strftime(_time, "%H") | where date_hour >= 2 | stats earliest_time(_time) AS Login, latest_time(_time) AS Shutdown by user src_ip | convert ctime(Login) ctime(Shutdown) | table Login Shutdown src_ip user | sort Login ... View more

1) Assuming the date_hour field is automatically extracted from the event (it usually is), you should be able to use that to filter out events occurring between midnight and 2am. index=endpoint_ms_winevents sourcetype=XmlWinEventLog user=TESTER EventID=4624 OR EventID=4634 earliest=-7d@d latest=now | where date_hour >= 2 | stats earliest_time(_time) AS Login, latest_time(_time) AS Shutdown by user src_ip | convert ctime(Login) ctime(Shutdown) | table Login Shutdown src_ip user | sort Login 2) Filter out events where the username ends with '$'. Those are computer processes signing in rather than individuals. ... View more

It sounds like some of the data in the lookup file is confusing the SPL parser.  When you run the subsearch by itself with format, does the output look like valid SPL? | inputlookup ip_test.csv | fields src | format ... View more

1) A "dev guy" should not be sending anything to a data/inputs endpoint - only the services/collector endpoints.   2) Use the services/collector/raw/1.0 endpoint if you need props and transforms to process your data.  Use the services/collector/event/1.0?auto_extract_timestamp=true endpoint if you only need the timestamp extracted. ... View more