To EC or not to EC.......good question. In general, almost every QRadar installation could use the increased efficiency by pre-processing the data on the EC before handing to the EP. The work-time-cost to implement an EC is what QRadar admins need to look at.
* Adding an EC to an EP does not remove the EC function from the EP, but it does off-load most of the hard work of collecting and parsing. thus freeing up resources on the EP.
* The EPS is not limited to 15K on the EC, but is enforced by the EP licensing. You can build a bigger than appliance to handle up to 40K.
* Moves the TCP connection limit to the EC from the EP, allowing more overall TCP connections per EP
I am sure there are more benefits. Since the change in QRadar licensing with the "appliance licensing" moved to the overall cost, adding a virtual EC is very little additional cost, other than the IBM/real/virtual server and the time/effort to learn/cfg/implement.
Since you are growing fast, I would recommend one or more ECs as a low cost method to extend the existing QRadar EP workload.
Just my 2 cents;
JW
EC function from Brian Coache Overview PPT
– Collects and parses events on a remote site, stores events temporarily, and forwards events (based on a policy) to an upstream Event Processor 16XX or All-in-1 31XX for analysis, correlation, and storage
– Software Supports up to 40K EPS but no license associated, and standard 1501 appliance should be limited to 15K EPS for best performance. EPS enforced by the license at the upstream Event Processor or AIO.
------------------------------
John Wyckoff
QRadar Dude (Ex-BigFixer)
IBMer (twice, with stints at Intel and Novell)
Located in New England, cover North America
802-825-5863
Farm website -
http://www.3sheepstothewind.com------------------------------
Original Message:
Sent: Wed January 15, 2020 02:14 AM
From: Matthew Hodulik
Subject: To add or not a new EventCollector 1599
A 15XX Event Collector (in your case, a 1599 Event Collector virtualized) can provide significant processing relief for an upstream 16XX Event Processor (in your case a 1699 Event Processor). The 15XX Event Collector provides:
1. For syslog or streamed event data: the 15XX will provide pre-parsing of the event data thereby relieving the 16XX from identifying the log source, and parsing the data. This could be upwards of 25-30% of processing offloaded to the 15XX EC. (Note: mileage will vary, and the figures aren't guaranteed).
2. For log sources that are "pull", such MSRPC or JDBC, the 15XX Event Collector will handle all of the session creation, polling, and of course pre-parsing.
This is one of several architectural patterns that 15XX Event Collectors are used for. Please note that a physical 1501 Event Collector has a hard limit of 15K EPS, and given you are already at 15K EPS with your license, you may push into needing two 1599 Event Collectors quickly. As always, do some testing. I hope this helps.
------------------------------
Matthew Hodulik
Security Architect and QRadar Technical Specialist
IBM
Michigan
Original Message:
Sent: Tue January 14, 2020 12:03 PM
From: Hemant Kumar
Subject: To add or not a new EventCollector 1599
Hi all,
Here is our current deployment:
1 - 3199 AIO virtual
1- 1699 EP virtual
1- 1799 FP virtual
Current EPS license is of 15K and plan to increase to 30K this year.
- Is it recommended to spinup a separate EC (probably 1599) so the current EP's performance doesn't take a hit as the EPS volume grows?
- Can we use current deployment and scale upto 30K without compromising on EP performance?
Thanks in advance,
------------------------------
KH
------------------------------