Skip to content
Notifications
Clear all

Complete newbie here - where do I start with dashboard creation in ES?

6 Posts
6 Users
0 Reactions
13 Views
(@emilyl2)
Reputable Member
Joined: 2 months ago
Posts: 219
Topic starter   [#25960]

Hi everyone! I just joined a team that uses Splunk ES, and I’ve been asked to help with dashboards. I’m coming from a basic customer support ticketing background, so this is pretty new to me.

I’ve seen the existing dashboards in ES, but I'm not sure where to begin building my own. Should I start with the built-in dashboards and modify them, or is it better to build from scratch? Are there any key resources or guides you'd recommend for someone with no prior Splunk dashboard experience? I'm especially interested in tracking customer success metrics and support ticket escalations.



   
Quote
(@cloud_cost_watcher)
Honorable Member
Joined: 7 months ago
Posts: 386
 

Welcome. Since you're coming from a support ticketing background, I'd suggest you start by modifying an existing, simple dashboard. Building from scratch requires more familiarity with SPL and data models.

For your metrics on customer success and escalations, first identify which ES data models your team is already using for ITSI or service monitoring. That's your foundation. The Splunk docs have a "Dashboard Examples" section, but the "Splunk Dashboard Studio" user guide is more practical for beginners.

A common mistake is creating dashboards that query too much data, which can get expensive. Always check the time range and use data model acceleration where possible.


CloudCostHawk


   
ReplyQuote
(@emmaf)
Reputable Member
Joined: 3 months ago
Posts: 297
 

Yes, modifying an existing dashboard is the perfect way to get your bearings, and I totally agree with starting there. It lets you see how SPL searches are structured visually without the blank-page pressure.

That said, I'd add one practical caveat about the "Splunk Dashboard Studio" user guide they mentioned. While it's great for modern layout, make sure you're actually looking at an ES dashboard that uses it. A lot of older, but still very functional, ES dashboards are built with Simple XML. The editing experience is a bit different, so you don't want to open the wrong guide and get confused.

Your point on cost is so critical for a newbie. A quick tip on that - when you're modifying a panel, always run the search standalone first and look at the "Statistics" tab to see the event count and scan time. It's a real eye-opener for understanding impact.


If it's not measurable, it's not marketing.


   
ReplyQuote
(@carlam)
Reputable Member
Joined: 3 months ago
Posts: 234
 

Modifying existing dashboards is definitely the best path, especially for your support ticket use case. I'd go one step further and pick a dashboard that's already tracking something similar, like a service health or incident overview. That way the data model and SPL structure will be closer to what you need.

One question to ask your team: how are your customer success metrics actually logged? Are they in your ticketing system's data, or is it a separate source? That'll determine which ES data model you should be building on.

Also, when you run those test searches to check event count, keep an eye on the time picker. A dashboard defaulting to "All time" can cause performance pain. Setting a sane default like "Last 7 days" for your modified version is a good early win.


Benchmarking my way to better decisions


   
ReplyQuote
(@datadog)
Reputable Member
Joined: 3 months ago
Posts: 365
 

Good point on picking a similar dashboard for the data model. That saves hours of trial and error.

But don't just copy the SPL. Check the data model's acceleration status first. An unaccelerated model will kill dashboard load times for your team. Run this:

`| `datamodel`
| search datamodel=
| stats count`

If the count is low or the search is slow, you need to get acceleration turned on before you build anything.


Metrics don't lie.


   
ReplyQuote
(@brianc)
Reputable Member
Joined: 3 months ago
Posts: 268
 

Welcome aboard! Coming from support ticketing, you've got a great head start because you already understand the metrics you need to track. That's half the battle.

I'd strongly echo the advice to start by modifying a built-in dashboard. For your specific interest in escalations, go straight to the "Incident Review" or "Notable Events" dashboards that come with ES. Open one up, save a copy with a new name, and start swapping out fields. Look for panels showing ticket status or priority - that's your template. Change the search to filter for your escalation status field instead, and you're already 80% there.

The one thing I'd add from my own painful learning experience: before you get lost in the visuals, spend an afternoon mapping your ticketing data fields to the ES Common Information Model, especially the "Change Analysis" or "ITSI" data models if you have them. If a "ticket_priority" field in your logs maps to a standard field like "urgency" in the model, your searches become reusable and way faster. The ES app already has searches built to use those standard fields, so your modifications will click into place.


customer first


   
ReplyQuote