The Dashboard Nobody Can Open

The panel multiplies two dimensions against a granularity that the time range cannot support:

• Bucket count: 7 days at span=1m = 10,080 buckets per series.
• Series count: BY src_ip over a week of netflow can mean thousands to tens of thousands of distinct sources, each of which becomes its own line and legend entry.

Cost scales roughly as buckets × series, and rendering cost adds on top. Even a fast search cannot make a chart with 10,000 series legible.

Rewrite A - coarser time, bounded series:

index=netflow
| timechart span=1h limit=10 useother=t sum(bytes) BY src_ip

168 buckets, 10 named lines plus an OTHER bucket for the tail. Verify the limit/useother syntax for your version with | timechart help, then confirm the totals still sum to the unfiltered result.

Rewrite B - aggregate first, chart the short list:

index=netflow
| stats sum(bytes) AS bytes BY src_ip
| sort 10 -bytes
| timechart span=1h sum(bytes) BY src_ip

This makes the "top talkers" decision explicit and auditable - you know it is a deliberate top-10, not a rendering accident.

In both cases, span must be chosen from the time range, not hardcoded. A 1-minute span is defensible for a 4-hour incident view; it never is for a week.

top is a convenience command with a default limit=10. It is doing exactly what it was told - the panel silently encodes a business rule ("10 is enough") that no one agreed to.

Fixes, in order of preference:

1. Be explicit: | top limit=25 src_ip. Keep showperc in mind - top emits count and percent by default, and those extra columns sometimes confuse downstream comparisons.
2. Use stats for anything that feeds further logic:

index=netflow | stats count BY src_ip | sort 25 -count

stats has no hidden cap and makes the ordering explicit. Use sort <N> (not sort then head) when you only need the top N.

Verification step: compare | stats dc(src_ip) against the number of rows the panel renders. Any mismatch means a limit is being applied somewhere - in top, in chart/timechart series limits, or in a UI row cap. Make that reconciliation part of the panel review; a truncated panel that "looks fine" is the most common dashboard defect.

It helps when:

• All six panels share the same index, sourcetype, and time range. Here they do - that is six identical 7-day scans collapsed into one.
• Each post-process is a transforming stage (stats, top, timechart) operating on the base result set.
• The base search is restricted to the fields the panels need (| fields _time, src_ip, bytes, dest), which cuts memory and transfer drastically.

It makes things worse when:

• The base search returns far more events than the panels need. A single wide base search can become a memory hog that fails where six narrow searches merely ran slowly.
• Panels need different time ranges or different filters - they must then diverge from the base, which defeats the purpose.
• The base search uses transforming commands; post-process cannot feed off a transformed result set, so the panels break outright.
• One failing panel now takes the whole dashboard down with it.

Recommended path here: fix the two broken panels first (span, limit), narrow the field set, and only then introduce base/post-process - with a | fields whitelist and a test that each post-process matches its standalone equivalent. If the 7-day window is truly the requirement, that is also a strong argument for an accelerated data model plus tstats rather than scanning raw netflow at dashboard load time.