IBM Security QRadar

Expand all | Collapse all

To add or not a new EventCollector 1599

  • 1.  To add or not a new EventCollector 1599

    Posted Tue January 14, 2020 12:04 PM
    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,


  • 2.  RE: To add or not a new EventCollector 1599

    Posted Wed January 15, 2020 02:15 AM
    Edited by Matthew Hodulik Wed January 15, 2020 02:16 AM
    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

  • 3.  RE: To add or not a new EventCollector 1599

    Posted Fri January 17, 2020 02:28 PM
    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;

    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
    Farm website -