Splunk Cloud Platform

Broken Host Lookup gen searches are getting skipped.

kartik
Observer

Hi Team,

We're getting skipped search alerts for all 3  Lookup Gen searches. How we can resolve this?

Even though after disabling those searches we are still getting error for these searches.

Your assistance is greatly appreciated.

Lookup Gen - bh_sourcetype_cachebroken_hostsRelation '' is unknown. (2)none2
Lookup Gen - bh_host_cachebroken_hostsRelation '' is unknown. (2)none2
Lookup Gen - bh_index_cachebroken_hostsRelation '' is unknown. (2)none
Labels (1)
0 Karma

rj_jacobevans
Engager

I am seeing the same thing with a fresh install of v5.0.1 in Splunk Cloud.

Splunk Cloud

Version: 9.2.2403.109

Build: acf4711b7529

 

10-21-2024 16:07:58.193 +0000 INFO  SavedSplunker - savedsearch_id="nobody;broken_hosts;Lookup Gen - bh_host_cache", search_type="scheduled", user="nobody", app="broken_hosts", savedsearch_name="Lookup Gen - bh_host_cache", priority=default, status=skipped, reason="Relation '' is unknown.", scheduled_time=1729526878, window_time=-1, skipped_count=11, filtered_count=0
10-21-2024 12:52:14.196 +0000 INFO  SavedSplunker - savedsearch_id="nobody;broken_hosts;Lookup Gen - bh_sourcetype_cache", search_type="scheduled", user="nobody", app="broken_hosts", savedsearch_name="Lookup Gen - bh_sourcetype_cache", priority=default, status=skipped, reason="Relation '' is unknown.", scheduled_time=1729515134, window_time=-1, skipped_count=10, filtered_count=0
10-21-2024 12:26:30.121 +0000 INFO  SavedSplunker - savedsearch_id="nobody;broken_hosts;Lookup Gen - bh_index_cache", search_type="scheduled", user="nobody", app="broken_hosts", savedsearch_name="Lookup Gen - bh_index_cache", priority=default, status=skipped, reason="Relation '' is unknown.", scheduled_time=1729513590, window_time=-1, skipped_count=10, filtered_count=0

 

 

 Looking at the savedsearches.conf that comes with this version of the app and comparing to the documentation (https://docs.splunk.com/Documentation/Splunk/latest/Admin/Savedsearchesconf), each of these three searches defines "counttype = number of events" but does not define "quantity" or relation.

To fix this in Splunk Enterprise, just remove the config "counttype = number of events" for each search directly in default/savedsearches.conf.

To fix in Splunk Cloud, click Edit > Advanced Edit on each search and change "alert_type" from "number of events" to empty. Keep in mind that the app will need to be completely uninstalled and reinstalled when this is fixed to remove the /local/ versions of the searches.

Cheers,
Jacob

---

If this reply helps you, Karma would be appreciated.

0 Karma

richgalloway
SplunkTrust
SplunkTrust

Usually, a search is skipped because of external factors (no resources), but a search will be skipped if it contains an error or if it's already/still running.  The Monitoring Console or CMC will tell the reason for the skips in the Scheduler Activity dashboard.  Fix the reason and the skips should stop.

---
If this reply helps you, Karma would be appreciated.
0 Karma

kartik
Observer

these searches are showing the reason as "Relation '' is unknown. (2)" . Here I'm unsure what action that i need to perform here.

0 Karma

richgalloway
SplunkTrust
SplunkTrust

That reason is new to me.  The app is supported by the developer.  Their contact info is on the splunkbase page.

---
If this reply helps you, Karma would be appreciated.
0 Karma
Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.
Get Updates on the Splunk Community!

Introduction to Splunk AI

How are you using AI in Splunk? Whether you see AI as a threat or opportunity, AI is here to stay. Lucky for ...

Splunk + ThousandEyes: Correlate frontend, app, and network data to troubleshoot ...

Are you tired of troubleshooting delays caused by siloed frontend, application, and network data? We've got a ...

Maximizing the Value of Splunk ES 8.x

Splunk Enterprise Security (ES) continues to be a leader in the Gartner Magic Quadrant, reflecting its pivotal ...