Hi, I am looking for some solution how to find in Splunk scheduled searches not used for several weeks by users or apps (for example user left and search is not checked). I tried to focus to audit logs for non ad hoc searches and rest API saved searches but I wasn't able to find some meaningful result for it
If scheduled search is not being run it's typically due to one of two reasons:
1) it's disabled so it's not being scheduled
2) it's skipped due to SH(C) overload
If I remember correctly, there could be some other rarer reasons typically connected with role capabilities (I think if a user created a scheduled search and then was revoked the schedule_search it could cause some problems or if the owner of the scheduled search was deleted and the search was orphaned).
So you can either check which of your searches are disabled, which were skipped and alternatively you can check scheduler log for searches actually run and compare this list with the list of defined searches.
Hi,
this is opposite situation. I am looking to identify old saved searches scheduled, running and consume resources but don't return results for several weeks (they are broken or incorrect) or nobody checked them (user left, and let search scheduled).
I tried rest API but range is short and index=_audit savedsearch_name!="" to find these searches but it looks quite hard to identify if search is really broken or not used by user or app for longer time
You can extend this search from _audit index to find those searches that have result_count=0.
But to be fully honest, it seems like a case of underdocumenticitis - when you have no control over what your users do and have no documentation for it. And that's the root cause of your problem.
Hi
one more reason. When user has removed (e.g. from AD/LDAP and splunk use those as authentication) then those searches are skipped as there are no identity to grant access etc. But you will get information on messages for that. There is also link for those to e.g. reassign those to someone else.
Settings -> All configurations -> Reassign KOs.
r. Ismo