Splunk Search

click data point in chart when lines overlap

swazimodo
Path Finder

I have a chart in a dashboard with multiple lines showing different error types over time. The lines often overlap and if you want to click on a data point you do not have a way to chose which line it is selecting. Clicking on the legend does a search for that entire date range. It would be nice if this just brought that line to the top so you could click a single spot.

Is there anyway to make this work a little easier? I do not want to unstack these into separate charts as then I'll not be able to have a complete summary on one screen.

Tags (2)
0 Karma

to4kawa
Ultra Champion
<form>
  <label>chart test</label>
  <search id="chart_base">
    <query>| makeresults count=2
| streamstats count
| eval _time=if(count=2,relative_time(_time,"-2d@d"),relative_time(_time,"-1d@d"))
| makecontinuous span=10s _time
| eval error_type="error_".(random() % 9 + 1)
| streamstats count
| eval count = count % 2
| where count=1
| eventstats first(_time) as start last(_time) as end
</query>
    <earliest>0</earliest>
    <sampleRatio>1</sampleRatio>
  </search>
  <fieldset submitButton="false"></fieldset>
   <row>
    <panel>
      <html depends="$alwaysHideCSSStyle$">
         <style>
           #resized_ms div[data-component="splunk-core:/splunkjs/mvc/components/MultiDropdown"],
              width: 400px !important;
              margin-right: auto !important;
           }
         </style>
      </html>
    </panel>
  </row>
  <row>
    <panel>
      <input type="multiselect" token="error" id="resized_ms">
        <label>error_type</label>
        <fieldForLabel>error_type</fieldForLabel>
        <fieldForValue>error_type</fieldForValue>
        <search base="chart_base">
          <query>| stats count by error_type
| table error_type</query>
        </search>
        <default>error_1,error_2,error_3,error_4,error_6,error_5,error_8,error_7,error_9</default>
        <delimiter> OR </delimiter>
        <valuePrefix>error_type=</valuePrefix>
        <suffix> _time >= $selection_earliest$  _time <= $selection_latest$</suffix>
      </input>
    </panel>
  </row>
  <row>
    <panel>
      <chart>
        <search base="chart_base">
          <query>
            |search $error$ 
| timechart span=1h count by error_type
</query>
        </search>
        <selection>
          <set token="selection_earliest">$start$</set>
          <set token="selection_latest">$end$</set>
        </selection>
        <option name="charting.chart">line</option>
        <option name="charting.legend.mode">standard</option>
        <option name="charting.legend.placement">top</option>
        <option name="charting.lineWidth">2</option>
        <option name="height">400</option>
      </chart>
    </panel>
  </row>
</form>

I tried making it, but maybe you need a reset function.

0 Karma

efavreau
Motivator

Click and drag on the chart to zoom in on an area, It does not generate a new search. It becomes easier to click on the exact spot on the line you need.

###

If this reply helps you, an upvote would be appreciated.

swazimodo
Path Finder

That definitly helps but does not fix the issue if they exactly overlap. Which is common when using timespan for low numbers of events.

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Event Series: Telemetry Pipeline Management

Balancing Scale and Spend: Gaining Control Over High-Volume Metrics in Splunk Observability Cloud As ...

Kick the Tires Before You Commit: A Hands-On Tour of the Splunk Observability Cloud ...

Evaluating an enterprise observability platform usually goes like this: fill out a form, get a free trial with ...

Deep insights, no barriers: Splunk Observability Cloud Free Edition

As software delivery cycles continue to accelerate, observability shouldn’t be a luxury — it should be a ...