Don't create a chained search with no transforming command if your goal is simply to optimise editing of the same search string - base searches are not intended to be used as simply a large internal data store of raw data that other searches use. These will not perform well and also have data size limitations. A little more convoluted is to do it by having a base search that constructs the search string you want and you can then use the result of that calculated search in your other searches, like this { "title": "Example DS", "description": "", "inputs": { "input_RFDATAAt": { "options": { "token": "token2" }, "title": "Field 2", "type": "input.text" }, "input_gwpzfltt": { "options": { "token": "token3" }, "title": "Field 3", "type": "input.text" }, "input_yn3wY65y": { "options": { "token": "token1" }, "title": "Field 1", "type": "input.text" } }, "defaults": { "dataSources": { "ds.search": { "options": { "queryParameters": {} } }, "ds.spl2": { "options": { "queryParameters": {} } } }, "visualizations": { "global": { "showProgressBar": true } } }, "visualizations": { "viz_LR1HiTkj": { "dataSources": { "primary": "ds_5kovgazS" }, "description": "This waits for all field filters to be entered then calculates the constructed search", "eventHandlers": [ { "options": { "newTab": false, "type": "auto" }, "type": "drilldown.linkToSearch" } ], "options": { "showInternalFields": false }, "title": "Background search that calculates base string", "type": "splunk.table" }, "viz_ee6deRfB": { "dataSources": { "primary": "ds_OydjwvQS" }, "description": "This search is the main search using the evaluated string", "eventHandlers": [ { "options": { "newTab": false, "type": "auto" }, "type": "drilldown.linkToSearch" } ], "options": { "showInternalFields": false }, "title": "Result of search for $search_string_creator:result.search_string$", "type": "splunk.table" } }, "dataSources": { "ds_5kovgazS": { "name": "search_string_creator", "options": { "enableSmartSources": true, "query": "| makeresults\n| eval search_string=printf(\"index=%s field1=%s field2=%s field3=%s\", \"index1\", $token1|s$, $token2|s$, $token3|s$)" }, "type": "ds.search" }, "ds_OydjwvQS": { "name": "Table search", "options": { "query": "$search_string_creator:result.search_string$", "queryParameters": { "earliest": "-h@h", "latest": "@h", "sampleRatio": 1 } }, "type": "ds.search" } }, "layout": { "globalInputs": [], "layoutDefinitions": { "layout_1": { "options": { "display": "auto", "height": 837, "width": 1440 }, "structure": [ { "item": "input_yn3wY65y", "position": { "h": 82, "w": 198, "x": 0, "y": 0 }, "type": "input" }, { "item": "input_RFDATAAt", "position": { "h": 82, "w": 198, "x": 198, "y": 0 }, "type": "input" }, { "item": "input_gwpzfltt", "position": { "h": 82, "w": 198, "x": 396, "y": 0 }, "type": "input" }, { "item": "viz_LR1HiTkj", "position": { "h": 250, "w": 1440, "x": 0, "y": 82 }, "type": "block" }, { "item": "viz_ee6deRfB", "position": { "h": 250, "w": 1440, "x": 0, "y": 332 }, "type": "block" } ], "type": "absolute" } }, "options": {}, "tabs": { "items": [ { "label": "New tab", "layoutId": "layout_1" } ] } }, "applicationProperties": { "hideEdit": false, "hideExport": false } } The first table search simple waits for all filters to be selected and it then calculates the table field "search_string". After that search completes, you can reference $search_string_creator:result.search_string$ to get the value of the string. It's a bit of a hack, but it means that all you need to modify is the printf statement to construct your search if you change your filters.   ... View more

Here's a small example that creates 2 dummy tickets per day for 30 days and it shows the calendar and supports drilldown. The table below uses the search from the timechart (created as a base search) from the ticket search to just find the tickets on that clicked day. It then transposes the table and shows the tickets and drilldown can then be done on those tickets. Hope this is useful <dashboard version="1.1" theme="light"> <label>calendar_test</label> <row> <panel> <viz type="calendar_app.calendar"> <search id="base_calendar_data"> <query> | makeresults count=60 | streamstats c | eval _time=now() - (floor(c / 2) * 86400) | eval ticket="JIRA".(random() % 10000000 + 1000000) | timechart span=1d limit=0 count by ticket </query> <earliest>-30d</earliest> <latest>now</latest> <sampleRatio>1</sampleRatio> </search> <option name="calendar_app.calendar.calendarView">month</option> <option name="calendar_app.calendar.defaultDate">last</option> <option name="calendar_app.calendar.showWeekNumbers">false</option> <option name="calendar_app.calendar.showWeekends">true</option> <option name="drilldown">all</option> <option name="height">644</option> <option name="trellis.enabled">0</option> <option name="trellis.scales.shared">1</option> <option name="trellis.size">medium</option> <drilldown> <set token="tok_day">$click.value$</set> <eval token="tok_date">strftime($click.value$, "%F")</eval> </drilldown> </viz> <table depends="$tok_day$"> <title>Tickets raised on $tok_date$ - select a ticket to go to the JIRA site</title> <search base="base_calendar_data"> <query> | where _time>=$tok_day$ AND _time&lt;=$tok_day$ | transpose 0 column_name=ticket | where 'row 1'>0 AND !match(ticket, "^_") | fields ticket </query> </search> <drilldown> <link target="_blank">https://www.google.com?q=$click.value$</link> </drilldown> </table> </panel> </row> </dashboard>   ... View more

An alternative would be to use the existing epoch value given from the calendar drilldown and open a new search showing a table of tickets matching that _time value when the ticket is clicked and then have a second layer drilldown from the table to the URL, which would be very easy. You can make that second table small and you can make it only conditionally visible using "depends="$token$" construct in your XML.   ... View more

The calendar app does not support any kind of drilldown tokens other than the basic $click.*$ tokens. You'd have to modify the Javascript to be able to do that. Depending on how your data is and the amount of data you need to show, you could look at two other apps that do support a lot of customisation, firstly the event timeline https://splunkbase.splunk.com/app/4370 The author is an active developer. That type of view may or may not work for you. The other is Number Set, again by a very active developer https://splunkbase.splunk.com/app/6915 This is not specifically time based, but you can position the 'values' at fixed positions in a grid, so you could make it work, again depending on the volume of tickets you are talking about.     ... View more

Create an app of your own and add any images you want to the appserver/static folder of your app. You can You can then upload your app to Cloud and then from any app, you can reference those images inside <html> panels in your dashboard like this. <html> <h1>The image below is of a small bell</h1> <img src="/static/app/my_images/bell.svg">Bell</img> </html> In the above example, my_images is the name of an app you can create. If you've never made your own app, you just need to tar up a folder structure where the following directories sit under your app name (my_images in the example below). You only need the minimum of attributes to make your own app, this should suffice. appserver/static/* bin default/app.conf metadata/default.meta where you put all the images you want in appserer/static, and your app.conf should be something like [install] build = 1783395636 is_configured = 0 [ui] is_visible = 1 label = My Images [launcher] author = Me description = Contains images I want to use in dashboards version = 1.0.0 [id] name = my_images version = 1.0.0 [package] id = my_images check_for_updates = 0 NB: id and name MUST match the folder structure. default.meta should contain at least the following which will allow everyone to see the images [] access = read : [ * ], write : [ admin, sc_admin, power ] export = system  Hope this helps. ... View more

Yes, there was a guy on Slack search-help recently, with a search that had an rt-15m@m, but his search wasn't working properly. He removed it and it worked. In 8.4/8.5 you can no longer enter rt in those fields, so I am guessing that existing searches are not removing any previous rt settings on upgrade. ... View more

I don't believe ES now supports real time windows for detections. Note that real time scheduling is different to an 'rt' time window, which you can no longer use in the earliest/latest definitions. Generally rolling window searches are achieved using the streamstats command https://help.splunk.com/en/splunk-enterprise/search/spl-search-reference/10.4/search-commands/streamstats Consider this example that looks to report on users in the _audit index that are seen more than 100 times in a minute. ``` This looks at a 2 minute window from -3 to -1 minutes ``` index=_audit earliest=-3m@m latest=-1m@m ``` This counts the 1 minute sliding window of events by user ``` | streamstats time_window=1m count by user ``` This works out what our search window is | addinfo ``` and now we filter for those counts that exceed the threshold and fall with the last minute of that 2 minute window ``` | where count > 100 AND _time > relative_time(info_max_time, "-1m@m") ``` Now summarise the output where count is the biggest number of hits for the user and max(_time) is the last event found for that user ``` | stats max(count) as count max(_time) as _time by user You would schedule this to run every minute and the search then looks at a 2 minute historical window. It needs to use the longer window so that it can count the sliding window from the previous minute, e.g. -02:30 to -01:30. See this link for what 'real time' and 'continuous scheduling are https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/10.4/report-management/configure-the-priority-of-scheduled-reports     ... View more

The term "summary" in summary indexes does not make it a different type of index, it is like any other index, but the term typically refers to a concept of summarising raw events in some way, so that you can more rapidly get the results from the summary rather than performing the original search. To give an example, imagine you have an index that gets ~1,000,000 events per minute and you need to be able to regularly look at a count of event per minute over one hour.  If you made a scheduled search that ean every minute that did this index=bla | bin _time span=1m | stats count by _time and you made your search save it to a summary index, then it would write one event to that summary each minute, so after running that search from 7am each minute, after 5 minutes you would end up with the following 5 events in the "summary" index. 2026-07-07 07:00 1000123 2026-07-07 07:01 260543 2026-07-07 07:02 1100481 2026-07-07 07:03 450987 2026-07-07 07:04 996392 If you have a dashboard that wants to display a timechart with the count of event per minute over a 24h period, you would haver to read an enormous number of event (24*60*~1million), whereas you would only have to read 1440 event from your summary index to generate the same timechart, because your scheduled search has already aggregated those per minute counters for you. So, as you can see, what goes into summary indexes is totally up to you, it can be done through a scheduled saved search or you can manually use the | collect SPL command, which is effectively what is used behind the scenes by the search scheduler to write your data to the summary. So, to try to answer your (3), look at the search you are running that shows 311 events, look at (I assume) the saved search that is running to generate the results that are written to the summary index and you will see why they differ. Hope this helps   ... View more

That Titanic meme is great - never seen it before. There is a Camden active in Slack DS who seems reasonably interested in hearing ideas and use cases. I recently sent him an app of blocking stuff we do in XML that does not yet port to DS, primarily around interactivity/tokens. The team have made massive strides with it in the last year or so, but it's still not for me... ... View more

I'm another advocate for XML over DS. It still has a greater ability to style display elements than DS using CSS. Token interaction is better in XML, especially if you plug in a tiny piece of JS into your app, which then allows token management through <button> elements in <html> panels. Although DS does have conditional token handling so can model XML's depends= and rejects= constructs, it doesn't have this flexibility. Sure you can add pretty pictures in DS that make it look appealing, but for any kind of interactive dashboard, XML is probably superior (for the time being).   ... View more

If you get 3 rows and you want to trigger on 100 rows, then just set the trigger condition   ... View more

Are you talking about search execution time when you say "response"? Your comment here does not address the questions asked by others trying to help with your question, so it's difficult to give you meaningful help. If this is page loads, how have you measured this? If this is Splunk search executions, have you compared total server search load between the two environments to see if the upgraded server is performing more searches? Have you looked at individual search jobs to see if the data volume being searched in the upgraded version is comparable with the pre-upgrade? At the moment your question is like asking "why is my new car slower than my old car". Not enough information to make helpful suggestions.  Please give more detail.   ... View more

Note that my assumptions are that you don't already have any field extractions being done automatically. If you already have a field called 'id' then you don't need to do the rex command. ... View more

There are various ways to do this. Firstly if you are running a search every 15 minutes and looking at a 15 minute window in the past, the this simple search will count any occurence of id > 3 within that time period. your base search Event failed validation | rex field=_raw "id=\"(?<id>[^\"]*)" | stats count by id | where count>3 This assumes that the search criteria looks for that message signature and that the field _raw contains the data as shown However if this is about creating an alert, then that search is not helpful for the case when 2 errors occur in minutes 14 and 2 in minutes 16 if the search is searching 0-14 and 15-29. In that case, you can run the alert once per minute and look back at the previous 15 minutes, note that for alerts you would probably want to look a little behind the just the previous 15, i.e.  earliest=-17m@m latest=-2m@m  if the alert is then scheduled to run every 1 minute, you would configure it to fire once per result and to enable throttling and set the field to be id and the interval 15 minutes, so that the same id does not trigger each time the search runs for the next 15 minutes. This example search you can paste into your search to see the effect - it just creates some random messages based on your example and does the search above. | makeresults | eval events=split( "Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975946M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975936M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975926M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975916M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975996M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975986M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975976M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975966M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975956M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975946M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975946M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975936M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975916M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975996M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975986M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975976M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975966M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975956M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975946M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975936M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975926M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975916M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975996M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975986M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975976M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975966M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ] Event failed validation. Errors: Client=users; Message=com.xxx.base.exception.HttpErrorException: retry fails.. check log for more information webhooks | \"Notification Message\"=[ id=\"WH-96D975956M839252X-52N249868M7084734\"; resource_type=\"USER-PROFILE\"; ]", " ") | mvexpand events | rename events as _raw | streamstats c | eval _time=now() - (c * 30) | fields _time _raw ``` Test data is created above ``` | rex field=_raw "id=\"(?<id>[^\"]*)" | stats count by id | where count>3    ... View more

It's hard to provide a solution without a good level of detail. What fields are available? Can you post a redacted if necessary screen shot of your data, because the detail is important. ... View more

In your earlier post when you said you are using  | sort -time if that is exactly what you used then unless you have a field called time (as opposed to Splunk's _time)  then you are not sorting anything. You may also be better to use | transaction ID startswith="message=Faulted" endswith="message=Completed" if message is the field containing what you are basing the transaction on. Hhowever, transaction is not always the best command to use as it can give wrong or no results, depending on your data size. This is particularly important when not using maxspan to limit what data you are searching and the number of events you have. Also note that you should use  | sort 0 _time otherwise it will truncate data.   ... View more

@mvannini Following on from my previous comment about misplacement of your depends="$token$" pattern. Your entire dashboard is broken from this point of view. If you create fields in section 1-4 after you fill the last field the new entry is written to the lookup, because the button SALVA E INVIA CAB is ONLY affecting the display of the table. You will see if you run | inputlookup cab_requests_lookup on its own the new row is written before you click the button. If you then change a single field, a new CAB is written. Every time you want to control changes to the lookup, you have to make the <search> dependent on the token and NOT the table.   ... View more

One thing that stands out is your deduplication of the CAB table.  In this search (line 462) <table depends="$run_dedup$"> <search> <query>| inputlookup cab_requests_lookup | dedup cab_id | outputlookup cab_requests_lookup</query> <done> <unset token="run_dedup"></unset> </done> </search> </table> your <table> has a depends statement, but that will NOT stop the search from running, so the first thing that happens when you load the dashboard, is that you totally rewrite the KV store and this happens while the other searches are running, so there is a concurrency issue going on in the KV store reading the data in your base search as well as re-writing it in the above. You should make the <search> dependent on the token, i.e. <search depends="$run_dedup$"> or you could do it this way <table depends="$never_show$"> <search> <query>| inputlookup cab_requests_lookup | ``` $run_dedup$ ``` dedup cab_id | outputlookup cab_requests_lookup</query> <done> <unset token="run_dedup"></unset> </done> </search> </table> which embeds the token in a comment in the SPL itself, which will then cause the search to run each time the token is set and it never shows the table. I believe that is what you want given the input at 7A. At the moment, you see nothing when the table loads, but the kv is rewritten, then if you select the clean option in 7A, you will see the table appear then disappear when the search runs again. I only tested this with a CSV, not KV store, but can't reproduce the duplicate searches seen by @ITWhisperer  That may play into why the searches are running more than once, I am not sure how the KV store handles concurrent read/write on the lookup, but change that and see how that affects things.   ... View more

@mvannini Can you paste the XML? There are so many reasons why a dashboard can be slow, so without knowing where to start, it's hard to diagnose. Are you using base searches. What is the data size you are searching. If you look at the job inspector for a slow search what does it tell you The volume of tokens is not necessarily a problem, I have some dashboards that use a large number and they perform perfectly ok (>300). Paste the XML using the code block so we can try to help. ... View more

Rich's search is good, you can add | rex field=provenance "UI:[Dd]ashboard:(?<dashboard_name>.*") to get the dashboard name from the provenance field. Note that XML dashboards have capital D for dashboard, whereas Studio dashboards have lower case d. Note that you will have an audit trail entry for every search run by that dashboard. ... View more

That's interesting, and as @PickleRick says, not good for the reasons stated. There is a cost of ingesting _raw data, which if you are licenced on ingest volume, you would see if you populate the _raw with all the data, but at the moment, you are incurring storage costs with extra indexed fields. You have lost flexibility with the current approach, and I don't quite get the OTEL engineer's comments. If the lack of _raw is a problem, you could rebuild it to some extent, but the best solution would be to ensure the body has what you need. ... View more

I may have misunderstood your requirement, if I read it again, then you can still do it like this index=id [ | inputlookup id.csv | eval earliest=strptime(time, "%d.%m.%Y") | rename id as ID_index | fields ID_index earliest ``` This subsearch creates the search string ((ID_index="1111" earliest=time_1) OR (ID_index="2222" earliest=time_2)) ``` ] ``` Calculate the counts ``` | stats count by ID_index ``` Now fetch the limit ``` | lookup id.csv id as ID_index OUTPUT limit ``` And determine if threshold exceeded ``` | eval msg=if(count>limit, "limit exceeded", "under limit") Same principle as the other comment, but using the fixed index and field comparison. ... View more

You can do with with a subsearch like this [ | inputlookup id.csv | eval earliest=strptime(time, "%d.%m.%Y") | rename id as index | fields index earliest ] | stats count by index | lookup id.csv id as index OUTPUT limit | eval msg=if(count>limit, "limit exceeded", "under limit") The subsearch creates the search string which will look something like this ( ( index="1111" earliest=time) OR ( index="2222" earliest=time) ) and then you can do a stats count/lookup and produce the table. If the time interval is always the same for each index you could use tstats which would be faster, but it doesn't support multiple time ranges.   ... View more

I'm not sure I fully understand what you mean when you describe the event has having no "meaningful" _raw, but which has fields. That would imply that the _raw has been redacted during ingestion but fields have perhaps then been indexed, perhaps using INGEST EVAL. I was going to suggest using TERM(my_term) to search for terms you want, i.e.  index=bla TERM(term) but that's effectively searching _raw which you say you don't have. Do you know how this data is being ingested? If someone has done some optimisation to remove _raw in the process of ingestion and you need it back, perhaps you need to discuss with your admins. Otherwise, if there is no _raw, you can't easily search for terms efficiently anywhere. You could do index=bla ``` Loop through every field doing a per field match against search_regex ``` | foreach * [ eval match=max(match, if(match('<<FIELD>>', "search_regex"), 1, 0)) ] | where match=1 but this, like using fieldsummary, will be pretty inefficient, as you're getting all events from the index and then filtering. If your set of fields is static, you could create a macro, e.g.  `search_all_fields(term)` and then in the macro expand out the field list so you have field1=$term$ OR field2=$term$ OR field3=$term$... and if you do actually have indexed fields, you could use the index field notation as field1::$term$ If you do index=bla on its own, what do you see? Can you look at the source for that - i.e. don't use table just look at the events and in the Event Actions dropdown for the event, select show source.   ... View more