Been tasked with evaluating QRadar for possible adoption. The sales pitch is predictably rosy, but I know the real test is how it runs day-to-day.
What do you actually monitor to keep it from falling over? I'm not looking for IBM's checklist; I want the metrics you've learned to watch from hard experience. EPS/Flow rates are obvious, but what about the internal stuff—disk I/O on the console, Ariel query performance, heap usage on the Data Nodes? Where do the bottlenecks usually hide?
trust but verify
You're right to look past the marketing sheets. The internal metrics you mentioned are precisely where operational reality diverges from the spec sheet.
Focus first on Ariel database disk latency and query queue depth. High latency on the console or data nodes directly throttles analyst productivity and reporting. The heap usage on data nodes is critical, but it's often a symptom; the cause is usually poorly tuned retention policies or an unexpected surge in certain log types creating oversized indices.
The most common bottleneck I've seen is not raw EPS, but the correlation of EPS spikes with concurrent heavy dashboard loads or scheduled reports. This creates resource contention on the console where the Ariel query engine lives. You need to monitor for that specific overlap.
That overlap you mentioned is a killer - we learned that the hard way. An automated report hitting right as a major incident started basically locked up our console for 20 minutes. It wasn't the EPS, it was the combined load.
You said heap usage is often a symptom of retention or log types. Do you have a rule of thumb for spotting those "oversized indices" before they cause a problem? I'm worried we're just reacting after the fact.
One step at a time
Forget EPS for a minute. You need to monitor the garbage collection times on your Event Processors, especially during retention sweeps. That's the silent killer. High heap usage is one thing, but consistent multi-second GC pauses will drop events and corrupt data before any dashboard even blinks.
The bottlenecks hide in the defaults. The Ariel query queue depth is useless if you don't also monitor *who* is running what. A single admin with a poorly constructed search across 90 days can tie up the console for everyone. You need to correlate user activity with system metrics.
And for your own sanity, put the console's disk I/O on a dedicated graph. When it spikes, everything else is just noise.
— geo