Splunk Search
Highlighted

Timecharts and how to avoid "no results found inspect"

Contributor

I'm trying to avoid "no results found. inspect" message when my query returns 0 value. I just want an empty chart to keep my dashboard uniform. I've checked online for a solution but everything but i've tried doesn't work.

Here is where I'm at but it is still showing the "no results found. inspect"

MESSAGE=* | append [|eval MESSAGE="Test" | eval MESSAGE=0 | where count==0] | stats c(MESSAGE) | timechart count by MESSAGE

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Champion

Is the question.

・It requires a search statement.
append [|eval MESSAGE="Test" | eval MESSAGE=0・・・
->[search XXXX|eval MESSA

・The result is all MESSAGE = 0.
eval MESSAGE="Test" | eval MESSAGE=0
->eval MESSAGE=0

・The output will be one record.
stats c(MESSAGE)
(ex.)
c(MESSAGE)
-----------
123

・It can not be a timechart because there is no "_time".
| timechart count by MESSAGE

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

SplunkTrust
SplunkTrust

Try this

your base search | your timechart commnad | appendpipe [stats count | eval NoResult=""  | where count=0 | fields - count]

View solution in original post

Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Contributor

This suggestion is great - however, when drilling down I've been struggling with "PARSER: Applying intentions failed Drilldown error: unable to drill down from append

Here's the current CISCO query i'm using...

...| eval Time=time | convert ctime(Time) | rex "(?i)^([^:]*:){8}(?<CISCOMESSAGE>.*)$" | eval HOSTMESSAGE=host+CISCO_MESSAGE | timechart span=2m count by HOSTMESSAGE limit=12 | appendpipe [stats count | eval NoResult="" | where count=0 | fields - count]

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

SplunkTrust
SplunkTrust

It could be due to the fact that you're drilling down on extracted/calculated field (HOSTMESSAGE). Since you're using custom field for drill-down, I believe you should use your own drill-down search. Something like this

<table>
<search>
....
<drilldown>
<link>
<![CDATA[search?q=<<PutYourURLEncoded Query here>>
e.g. search?q=search%20index%3Dyourindexname%20sourcetype%3Dyoursourcetype
]]>
</link>
</drilldown>
</table>
0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Path Finder

Another way to avoid no result on timechart is to search a big range and limit result is using “sort -time | head n”. Example:
`index="*" | timechart count(dst) as Destinations span=10m | sort -
time | head 6`
If you need to get the timechart of the past hour, we can search the hole day (or another time that we know that is at least one event), and them limit using head.
In this case the "head 6" is the same of 60 minutes, because our span is 10 minutes.

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Contributor

Careful with index=*. In my experience, 24 hours should be the maximum. And even with 1 hour time range, if you have large amount of indexed data, as in my company, your search will retrieve more than 10 billions events. This method will take a long time to complete and be way too expensive in Splunk resources.

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

SplunkTrust
SplunkTrust

Also, it would give false results if the data in not available for the selected time range. (If I requested the data for 8:00AM to 9:00AM, I don't want to see data for 6:00AM to 7:00AM).

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Path Finder

You won't get false results because head will limit only the lastest events (even if there no results on desired range). You want 8 to 9? So search 1 to 9, or past 24h and use head to take only the last events based on your span.

0 Karma
Highlighted

Re: Timecharts and how to avoid "no results found inspect"

Path Finder

I know index=* is waste of processing. Was just an example. My suggestion is most useful If you have regular events and don't care to wait some more seconds on your query.

0 Karma