So, you’ve hit the classic QRadar licensing wall where you’re paying for EPS capacity you’re not even close to needing, while your storage is crying uncle. Congrats, you’re now officially a QRadar administrator.
This isn't just a "tuning" issue—it's a fundamental mismatch between how IBM sells licenses and how real log traffic behaves. EPS-based licensing is a blunt instrument, and it incentivizes the wrong kind of "optimization."
First, stop and audit what's actually generating events. The usual suspects are almost always:
* Noisy, repetitive system health/availability logs (Windows Event Logs 4xxx series, SNMP polls, VMware heartbeat events).
* Overly chatty network device logs where every allowed connection is logged (look at your firewalls and proxies).
* Unfiltered debug-level application logs that should never have been sent to a SIEM in the first place.
Before you start arbitrarily dropping logs, you need to prove the scale of the problem. Don't just guess.
1. Run an AQL search to find the top talkers by EPS over the last 7 days. Sort by `EPS` descending.
2. Cross-reference that with storage consumption. A log source spamming low-value events can be a top EPS generator but consume negligible storage.
The brutal truth is that the most effective "tuning" often happens at the source device or the Log Source Extension (LSE). If you can filter out the garbage before it even becomes an "event" in QRadar, you solve both the EPS and storage problem. This, of course, requires someone who understands the actual devices generating the logs.
Are you using the full normalized event payload for every single event? For things like routine network traffic logs, would a custom DSM that only parses and stores the 3-4 fields you actually use for investigations reduce your storage footprint? It’s more work, but it attacks the core problem.
Finally, have you actually calculated your true peak EPS, or are you just reacting to license violations? If your daily average is 10k EPS but you have a 30k EPS spike once a month, you’re licensed for that spike. You might be over-licensed for 29 days, but IBM isn’t going to point that out.
Exactly. The EPS versus storage mismatch is a classic data volume problem. Your AQL query is the right first step, but you need to add a cost dimension to that data.
Once you have your top talkers by EPS, tag them by business value. A high-EPS, low-value source is your primary target for filtering or sampling. I'd map them in a simple 2x2: EPS on one axis, investigative/audit value on the other. Anything high-volume, low-value gets throttled at the source or via a log source extension.
The real problem is that QRadar's own reporting makes this analysis painful. You often have to piece it together manually from event and storage reports.
Garbage in, garbage out.