An 18-Widget SOC Dashboard That Takes Five Minutes to Load
A SOC manager dashboard has 18 widgets. Each widget is backed by its own AQL query over the last 30 days, and the dashboard refresh interval is 5 minutes. About 40 analysts keep the dashboard open all day. Loading the dashboard takes 3-5 minutes; Ariel CPU rises sharply every 5 minutes; analysts complain that the page is stale by the time it loads. The widgets include: top 10 source IPs by denied firewall events, daily offense counts, a world map of failed logins, a table of the last 50 offenses, and a 30-day unique destination count per subnet. The QRadar deployment handles 45,000 EPS and already runs 120 scheduled reports. The SOC has three shifts and uses the dashboard for shift handover, so the last 8 hours and the last 30 days are both important.
1. Diagnose the main causes of the dashboard slowness.
Read the worked answer
Three compounding causes:
- Search volume. 18 widgets x 40 analysts x every 5 minutes is up to 14,400 Ariel searches per day, each over 30 days of raw events. Dashboard widgets are not shared; each user's open dashboard runs its own searches.
- Time range versus data. 30 days over 45,000 EPS is enormous, especially for the map and the unique-destination widget, which require scanning and grouping raw events. The 7-day flow retention means some widgets may return incomplete data or fall back to events.
- No caching or pre-aggregation. If the widgets are raw AQL over events, every refresh recomputes from scratch. The 120 scheduled reports compete for the same Ariel resources.
Secondary: a 5-minute refresh is faster than 30-day widgets can meaningfully change, and the 'last 50 offenses' table is cheap but still refreshes with the rest. The stale page is a symptom: the dashboard is queuing behind its own searches, so users see results from the previous cycle.
2. Redesign the dashboard for the same audience while preserving the key operational metrics.
Read the worked answer
Split by time horizon and pre-aggregate.
- Last 8 hours / shift handover: top source IPs by denied firewall events (last 1 hour, flows), last 50 offenses (offense table, not AQL over events), open high-magnitude offenses by assignee, failed-login map (last 1 hour, aggregated).
- Daily trend: offense counts by day (offense data, not events), top rules by offense count.
- 30-day: move to scheduled, cached reports or reference sets, not live widgets.
Mechanics:
- Reduce to 6-8 widgets and remove duplicate views.
- Set refresh to 15-30 minutes for 24-hour widgets and manual refresh for 30-day widgets.
- Use saved searches with caching where the widget supports it, and schedule heavy ones off-peak.
- Replace the 30-day unique-destination widget with a daily reference-set count (next task).
- Use role-based dashboards so not all 40 analysts run the same 18 searches.
Target: dashboard load under 30 seconds and a predictable Ariel load profile.
3. The manager insists on a 30-day unique destination count per subnet. How do you deliver that without a 30-day raw-event widget?
Read the worked answer
Do not run a 30-day COUNT DISTINCT over raw events on every refresh. Options:
- Daily rollup via rule/reference set: a scheduled AQL job or rule computes unique destinations per subnet for the previous day and writes the count into a reference map keyed by date and subnet. The widget reads the reference map, which is tiny and fast, and you also get a historical series.
- Scheduled report to a lookup: run the 30-day distinct count once nightly off-peak, export to a CSV/reference map, and have the dashboard display the latest value with an as-of timestamp.
- If flows suffice: 7-day flow retention cannot cover 30 days, so this only works for a 7-day variant; label it clearly.
- If a proxy is acceptable: show 'unique destinations seen today' plus a 30-day trend of daily counts, which is more actionable than a single 30-day number.
Document the as-of time on the widget; a cached 30-day number presented as real-time is worse than a slower accurate one.