GRAYLOG - Chapter 9, Exercise 3 Solution
==========================================================
Fixing a Timing-Out Aggregation

PROBLEM
-------
A wide aggregation on daxtraResource over the last 30 days keeps timing
out. Using this chapter's own material, explain the real fix, and why
it involves a part of the Graylog UI outside the query box itself.

SOLUTION
--------
This chapter established that wide aggregations on a high-cardinality
field like daxtraResource, over 7 or more days, can genuinely time out
rather than complete - daxtraResource has many distinct real values
(per Chapter 2's own real examples), which makes a wide aggregation
across a long time span expensive to compute.

The real fix is narrowing the TIME RANGE, not editing the aggregation
or query text itself. Per Chapter 1's own material, the time range is
set separately, through Graylog's own time-range picker in the UI - it
is not part of the query string at all, so no amount of rewriting the
query text can fix a timeout caused by too wide a time window.

ANSWER: Narrow the time range using Graylog's own time-range picker
(e.g. from 30 days down to a few days), then re-run the same
aggregation - it becomes feasible over a shorter window. This fix lives
in the UI's time-range picker specifically because, as Chapter 1
established, time range was deliberately never part of the query
string to begin with.

----
WHY THIS WORKS AS AN ANSWER

This connects this chapter's own new real gotcha (aggregation timeouts)
back to Chapter 1's own foundational fact about where time range
actually lives - a genuine, useful reminder that the fix for a
performance problem isn't always found in the query box, since Graylog
deliberately keeps time scoping as a separate UI control.