Dashboards & Visualizations

Why are the colors in my Single Value visualization incorrect?

Contributor

I have a search that sometimes provides no results, but I want to show the 0 not "no results" so I appendcols at the end with a check for empty. This is on a single Value panel where you can choose the color options, I have it so if it is 0 it is green. The panel though is red which is my criteria for 10 and above.

|inputlookup report.csv 
| rename u_wifi_mac_address as Mac_Address 
| search Mac_Address="00-AB-CD-EF-00-11" 
| stats count by Mac_Address 
| stats sum(count) as Generic_Mac
| table Generic_Mac
| appendpipe 
    [ stats count 
    | where count==0]

Ideas what I could be doing wrong?

0 Karma
1 Solution

SplunkTrust
SplunkTrust

You are doing WWWAAAYYY too much work.

In order: You can add a search criterion onto inputlookup. There is no point in renaming a field you are not going to be using. There is only one field output from the final stats, so the table command is redundant. The second stats should give you your zero if nothing was returned, so the append was unneeded.

Update - One more item suggested in @niketnilay's answer... removed the redundant by u_wifi_mac_address clause, because the last stats command proves you only care about how many records total are returned, so even if you had multiple macs selected, you wouldn't need to aggregate them separately.

One suggestion: always rename count, because it can end up confusing the programmer in later aggregate commands.

This should give you your answer, including zeroes.

 | inputlookup report.csv WHERE u_wifi_mac_address="00-AB-CD-EF-00-11" 
 | stats count as reccount
 | stats sum(reccount) as Generic_Mac

View solution in original post

SplunkTrust
SplunkTrust

I agree to @DalJeanis' point that there are a lot of pipe's in the search which are not even being used. I will however, add that since you are anyways filtering to single MAC address, you do not require by u_wifi_mac_address clause in your first stats. Since your stats count gives only one row, you don't need separate stats sum which will give same result.

Here is a different approach to handle No results found in Simple XML using tokens, job.resultCount and result.<fieldname>

<search>
   <query>
     |inputlookup report.csv where u_wifi_mac_address="00-AB-CD-EF-00-11" 
     | stats count as Generic_Mac
  </query>
  <done>
     <condition match="$job.resultCount$==0">
         <set token="tokGenMacCount">0</set>
     </condition>
     <condition>
         <eval token="tokGenMacCount">if(isnull($result.Generic_Mac$),0,$result.Generic_Mac$)</eval>
     </condition>
  </done>
</search>
<row>
   <panel>
      <single>
          <search>
              <query>| makeresults
              | eval GenericMac=$tokGenMacCount$
              | table GenericMac
              </query>
          </search>
      </single>
   </panel>

PS: I have added eval as an additional check which is not required in this case. So you can also use set directly in second condition block instead of eval:

<set token="tokGenMacCount">$result.Generic_Mac$</set>

Refer to Null Search Swapper example in Splunk 6.x Dashboard Example App from Splunkbase.

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"

SplunkTrust
SplunkTrust

You are doing WWWAAAYYY too much work.

In order: You can add a search criterion onto inputlookup. There is no point in renaming a field you are not going to be using. There is only one field output from the final stats, so the table command is redundant. The second stats should give you your zero if nothing was returned, so the append was unneeded.

Update - One more item suggested in @niketnilay's answer... removed the redundant by u_wifi_mac_address clause, because the last stats command proves you only care about how many records total are returned, so even if you had multiple macs selected, you wouldn't need to aggregate them separately.

One suggestion: always rename count, because it can end up confusing the programmer in later aggregate commands.

This should give you your answer, including zeroes.

 | inputlookup report.csv WHERE u_wifi_mac_address="00-AB-CD-EF-00-11" 
 | stats count as reccount
 | stats sum(reccount) as Generic_Mac

View solution in original post

Contributor

Looking at this then looking back at what I had... I am ashamed, thank you for the help!

0 Karma

SplunkTrust
SplunkTrust

Heh. Don't ever be ashamed of learning something.

It takes a lot of practice to learn to fix code by taking away, rather than by adding. @woodcock is a master at this stuff, and just like you he focused on the one change you asked for, rather than the underlying structural issues.

Also, it's SO much easier to identify such issues in OTHER PEOPLE's code than in your own. I have some REALLY ugly code in production... yesterday I spent hours reworking something where in different modules I had chosen different (arbitrary) methods and field names. As a result of the refactoring, they all output the same fields, capitalized the same way, and where the field means the same thing.

Just like in fiction writing, a certain amount of coding in splunk is "throat-clearing", where you are not sure precisely what you are trying to write. After you've got the purpose and requirements nailed down, then it can be good to step back and say, "how would I write this from scratch?"

0 Karma

Esteemed Legend

Add this instead of your appendpipe stuff:

| streamstats count AS _serial
| append [|makeresults | eval _serial=-1 | fields - _time]
| eventstats count
| eval count = count - 1
| search (count>0 AND _serial!=-1) OR (count=0 AND _serial=-1)
| table *
0 Karma

SplunkTrust
SplunkTrust

@woodcock - in this case, a correct answer on how to polish the deck chairs. Most of the original search was unneeded for the purpose.

0 Karma

Esteemed Legend

This actually was pretty hard to accomplish; I jumped in thinking that it would be simple and it was pretty complex (and, IMHO, totally unnecessary).

SplunkTrust
SplunkTrust

Yep, I've found it's often easier to rewrite the OP's posted base search rather than try to solder on another sprocket to the end of it.

0 Karma

Esteemed Legend

So you get credit for answering the question that he didn't ask!

0 Karma