How to share a non expiring search

[jpillai]

Hi All,

Im looking for a way to share a non expiring search with other users. If we use the ''share job" option or just use the URL from address bar - it will get expired once the job expires. But I want to share a link that will not expire.

Of course in such a case the search needs to run again from the users end, but the time stamps and search query are the things I want to share with a link. Is there a way to do this?

[richgalloway]

All searches expire.  The default is 10 minutes, but shared searches are automatically extended to 7 days.  I'm not aware of a way to extend search results past that.

[jpillai]

I think there is a way to increase the default expiry times. But this involves a cost that is the jobs occupies a space in users disk quota. So its probably not a good idea to increase these to huge values both from a user and machine resource perspective.

[isoutamo]

Hi

as @richgalloway already said normal TTL for queries is 10min and you could extend it and give permission to your search with Job -> Edit Job Settings ... Max values is 7day which should be enough long time for debug and resolve issues. And if it didn't enough for you, just run your search again and then extend it again to 7 days.

If you want to extend that default 10min TTL you can do it with https://docs.splunk.com/Documentation/Splunk/latest/Admin/Limitsconf#TTL. You must remember that this is global attribute and it affects for all. You could increase the value of "ttl" 

ttl = <integer>
* How long, in seconds, the search artifacts should be stored on disk after
  the job completes. The ttl is computed relative to the modtime of the
  status.csv file of the job, if the file exists, or the modtime of the
  artifact directory for the search job.
* If a job is being actively viewed in the Splunk UI then the modtime of
  the status.csv file is constantly updated such that the reaper does not
  remove the job from underneath.
* Default: 600 (10 minutes)

BUT as it said, it keeps those search jobs files on disk until that time has past. In active systems with lot of users this means quite much disk space under /opt/splunk/var on SH side which of course affect your system performance.

Personally I keep that TTL in quite small value, usually default and if/when needed extend TTL for individual search TTL only.

There is also undocumented (mainly for internal debug purpose) noop command which you could use on SPL to extend TTL for individual search. 

index = _internal
| noop set_ttl = 18000
| head 1

Above noop extend TTL to 5h for this job instead of normal 10min.

r. Ismo

[yuanliu]

You can always specify time window in search itself. (earliest, latest, etc.)  See Time modifiers.

As to "share job", Saved search aka "Report" might be a viable alternative.  After your search launches, you can "Save as" and select Report to give it a name.

[jpillai]

Our specific requirement is to have links to share with others, say while troubleshooting an issue, which can then be used even after weeks to come back to the same exact search result. So creating a report doesnt make sense in this case.

Also, after running searches using UI, its hard to add 'earliest and latest'  manually every time you want to share it with the correct formatting of time. Most users dont know this or wouldnt find it easy I think.

[yuanliu]

---

Our specific requirement is to have links to share with others, say while troubleshooting an issue, which can then be used even after weeks to come back to the same exact search result. So creating a report doesnt make sense in this case.

---

To have something available weeks after is exactly what report is for.  You don't want to force people to create their own bookmark for such purposes.  And there is absolutely no need to instruct future users to enter them manually. (In fact, the best report is where you disallow time picker.)

The point is, you CAN reproduce search results years after if your saved search contains the same time window as your original search.  Have you read the document I linked?  Say, I want people to search the following

index=_internal
| timechart span=2h count by sourcetype
``` data emulation 2 ```
| addtotals
| delta "Total" as _delta
| foreach * Total
    [eval <<FIELD>> = if(-_delta > Total, null(), '<<FIELD>>')]

for the past 2 days, where "past 2 days" is merely a reference to my search time.  You probably recognize that you don't need any precision in this time period. (I'll demonstrate more precise requirements later.)  So, say I am searching at 1015 Zulu time of 2023-09-13.  It is perhaps sufficient to pass 1000 Zulu time for future users. (Or 1100 as chances may suit.)  I can save the search as

index=_internal earliest=09/11/2023:10:00:00 latest=09/13/2023:10:00:00
| timechart span=2h count by sourcetype
``` data emulation 2 ```
| addtotals
| delta "Total" as _delta
| foreach * Total
    [eval <<FIELD>> = if(-_delta > Total, null(), '<<FIELD>>')]

If you want to be more precise, you can always specify time with more precision.

You can do this by looking at your watch, or you can get it from Splunk.  For example, I want

index=_internal
| stats count by sourcetype

for a certain period that I am searching for.  I can do

index=_internal
| stats count by sourcetype
| addinfo
| fields - info_s*

This gives me

sourcetype	count	info_max_time	info_min_time
dbx_health_metrics	8220	1694583382.000	1694579760.000
dbx_server	2	1694583382.000	1694579760.000
splunk_python	76	1694583382.000	1694579760.000
splunk_search_messages	2	1694583382.000	1694579760.000
splunk_web_access	5	1694583382.000	1694579760.000
splunk_web_service	15	1694583382.000	1694579760.000
splunkd	32275	1694583382.000	1694579760.000
splunkd_access	824	1694583382.000	1694579760.000
splunkd_ui_access	619	1694583382.000	1694579760.000

I just put info_min_time and info_max_time back.

index=_internal earliest=1694579760.000 latest=1694583382.000
| stats count by sourcetype

(They happen to be the past 4 hours.)  As I said, if I want to know what happened in the past four hours tonight, this search will always give me the same output whether I do it tomorrow or a year after.  And I never have to write a memo to myself about when I did this search, nor do I need to use time selector again.