# IBM QRadar Deployment & Components — Console, Processors, Data Nodes & Sizing Source: https://ai.techclick.in/blog_ibm_qradar_deployment_components Markdown: https://ai.techclick.in/blog_ibm_qradar_deployment_components.md Publisher: Techclick Infosec Pvt Ltd A practical 2026 guide to IBM QRadar deployment: all-in-one vs distributed, Console, Event Processor, Flow Processor, Data Node, App Host, and EPS/FPM sizing and licensing explained clearly. IBM QRadar Deployment & Components — Console, Processors, Data Nodes & Sizing student learning map A visual study map for IBM QRadar Deployment & Components — Console, Processors, Data Nodes & Sizing showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP IBM QRadar Deployment & Components — Console,... IBM · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Two topologies — all-in-one vs... 4. Practice ② Core components — what each one... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people hear 'QRadar' and picture a single SIEM appliance that does everything in one box. That picture works for a lab — it fails you in a real environment and in an interview. QRadar is a distributed SIEM platform : one central Console that holds configuration, offenses and the license pool, plus a fleet of specialised appliances — Event Processors for correlation, Event Collectors for log ingestion, Flow Processors for NetFlow/sFlow, Data Nodes for extra storage, and an App Host for extensions. You scale each layer independently, and your EPS/FPM licence is distributed across the pool — not hard-wired to one box. Understanding that architecture is what lets you size it right, troubleshoot capacity problems, and answer any deployment question in an interview. ## ① Two topologies — all-in-one vs distributed QRadar supports two core deployment models. In the all-in-one model, every component — Console, Event Processor, Flow Processor, and the correlation engine — runs on a single host. This suits labs, proof-of-concepts, and small environments where a single appliance can handle the expected EPS and FPM load without dedicated hardware for each role. The distributed model separates roles across multiple appliances. The Console manages configuration and offenses while Event Processors, Flow Processors, Data Nodes and the App Host each run on dedicated hardware. This lets you scale each layer independently: add another Event Processor when EPS grows, add Data Nodes when storage fills, and keep the Console responsive because it is not also grinding through correlation. IBM recommends the distributed model for any production deployment that expects significant log volumes, multiple data sources, or high availability requirements. The transition from all-in-one to distributed is supported but requires planning, so it is worth designing distributed from day one if growth is expected. Figure 1 — All-in-One vs Distributed QRadar The all-in-one fits labs and small sites; distributed is recommended for any production deployment with growth plans. - All-in-One vs Distributed QRadar All-in-One Console + EP + FP on one host Simpler to set up and manage EPS/FPM limited to one appliance Good for labs and small sites Distributed Console, EP, FP on separate hosts Scale each role independently Add Data Nodes for storage on Recommended for production The all-in-one fits labs and small sites; distributed is recommended for any production deployment with growth plans. Quick check · Q1 of 10 · Understand Which QRadar deployment model is recommended for production environments that expect growth? a) All-in-one, because one appliance is simpler to manage b) Distributed, so each component scales independently c) Cloud-only — on-premises is deprecated d) A Flow Processor running as the Console Correct: b. The distributed model lets you add Event Processors for EPS, Data Nodes for storage, and Flow Processors for FPM independently. The all-in-one hits a ceiling when any one dimension grows. 👉 So far: QRadar runs all-in-one (one host, all roles) or distributed (separate Console, EPs, FPs, Data Nodes, App Host). Distributed is recommended for any production site expecting growth. ## ② Core components — what each one owns Every QRadar deployment is built from a fixed set of roles. The Console is the web UI and management brain: it holds the global configuration, the offense queue, reporting, user management and the license pool. There is exactly one Console per QRadar deployment. The Event Processor (EP) receives normalised events from Event Collectors, runs correlation rules (the Rules Engine and Magistrate), and stores events in its local Ariel data store. You add EPs to scale EPS throughput. ### The supporting cast The Event Collector (EC) sits closest to log sources — it collects raw events from DSMs (device support modules), normalises them and forwards to an EP. An EC inherits the EPS allocation of its parent EP. The Flow Processor (FP) does the same for network flow data (NetFlow, sFlow, J-Flow), producing QRadar flows and counting FPM. The Data Node extends storage and search capacity for an EP — it does not process events itself but lets one EP manage a much larger Ariel data store, useful when retention windows grow. Finally the App Host runs QRadar applications (QRadar Advisor with Watson, User Behavior Analytics, etc.) in Docker containers, isolated from the Console so that an expensive app does not steal Console CPU. Figure 2 — QRadar Console at the centre The Console is the single management brain; all other components register to it and report offenses, events and flow data. QRadar Console at the centre Console Config + Offenses + Pool Event Processor Event Collector Flow Processor Data Node App Host The Console is the single management brain; all other components register to it and report offenses, events and flow data. 🖥️ Console tap to flip The single management brain — holds global config, the offense queue, user management, reporting and the EPS/FPM license pool. One per deployment. ⚙️ Event Processor tap to flip Receives normalised events from Event Collectors, runs the Rules Engine and Magistrate for correlation, and stores events in the local Ariel data store. Scale by adding more EPs. 💾 Data Node tap to flip Extends the Ariel storage and search capacity of an Event Processor. Does not process events itself — purely adds disk and index capacity so one EP can hold months of raw data. 📦 App Host tap to flip Runs QRadar apps (Advisor with Watson, UBA, etc.) in Docker containers, isolated from the Console so heavy analytics workloads don't starve the management UI. Name every component in one breath In an interview, walk through the component stack in order: Console (management + license pool) → Event Collector (parse + normalise) → Event Processor (correlate + store in Ariel) → Flow Processor (NetFlow/sFlow) → Data Node (extra Ariel storage) → App Host (Docker apps). That single sequence covers 90% of QRadar architecture questions. Quick check · Q2 of 10 · Remember An Event Collector sits between which two components in a distributed QRadar deployment? a) The Data Node and the App Host b) The Console and the Magistrate c) The log source and the Event Processor d) The Flow Processor and the Console Correct: c. The Event Collector receives raw events from log sources, normalises them with DSMs, and forwards them to its parent Event Processor for correlation and Ariel storage. 👉 So far: Console = management + offense + license pool (one per deployment). Event Collector = parse raw logs. Event Processor = correlate + Ariel store. Flow Processor = NetFlow/FPM. Data Node = extra Ariel storage. App Host = Docker apps. ## ③ EPS & FPM — measuring and licensing throughput EPS (Events Per Second) and FPM (Flows Per Minute) are the two currency units of QRadar licensing and capacity. IBM licenses QRadar by these rates: the base licence starts at 100 EPS and 15,000 FPM; additional EPS must be purchased in multiples of 100 and additional FPM in multiples of 5,000. The Console holds the total licensed EPS and FPM as a license pool . You then allocate slices of that pool to individual Event Processors and Flow Processors through the Admin > License Pool Management screen. An Event Collector inherits the allocation of its parent EP — it does not have its own separate slice. If any processor's allocated EPS is exceeded, QRadar throttles incoming events on that processor to protect stability. There are two licence models: the Usage Model (pay for EPS + FPM rates) and the Enterprise Model which licenses by Managed Virtual Servers (MVS) instead of raw rates. Most on-premises deployments use the Usage Model. For QRadar on Cloud, IBM manages the pool automatically. Always monitor the License Pool Management console for over-allocation warnings before they become dropped-event problems. Figure 3 — QRadar license pool — how EPS flows The Console holds the total licensed EPS; each Event Processor draws an allocated slice; Event Collectors inherit from their parent EP. QRadar license pool — how EPS flows Console Holds total licensed EPS + FPM pool Event Processors Each allocated a slice of the pool (multiples of 100 EPS) Event Collectors Inherit EPS from parent EP — no separate allocation The Console holds the total licensed EPS; each Event Processor draws an allocated slice; Event Collectors inherit from their parent EP. Sizing to average EPS, not peak EPS The most common QRadar deployment mistake is buying EPS based on average log rates. Authentication storms, vulnerability scans and batch log shippers can spike 3–5× above average. Always add at least 20% headroom above expected peak EPS — and monitor License Pool Management weekly, not just at deployment. ### ▶ Watch a firewall syslog become a QRadar offense Step through the full event path from raw UDP syslog to analyst-ready offense. Then press Break it to see the classic EPS throttle failure. ① Log Source A perimeter firewall sends a syslog (UDP 514) to the QRadar Event Collector for its network segment. ▼ ② Event Collector The EC loads the Cisco ASA DSM, parses the raw syslog, normalises it into QRadar's Common Event Format, and forwards to the parent Event Processor. ▼ ③ Event Processor The EP stores the event in its Ariel data store and passes it through the Rules Engine. A custom rule fires: 10 firewall denies from the same source IP in 5 minutes. ▼ ④ Console + Offense The Magistrate creates a new offense on the Console — 'Multiple firewall denies from 10.1.2.3' — with a magnitude score and a link to the correlated events for analyst triage. Press Play to step through the healthy event-to-offense path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A QRadar deployment has 500 licensed EPS. How must that capacity be distributed to additional Event Processors? a) In multiples of 50 EPS per processor b) In multiples of 100 EPS per processor, managed from the license pool c) Each processor gets an equal share automatically d) EPS is not allocated per processor — it is global Correct: b. IBM requires EPS allocations in multiples of 100. The Console's License Pool Management screen is where you manually slice the pool across processors. Event Collectors inherit from their parent EP. 👉 So far: EPS and FPM are the licensing currency. The Console holds the pool; allocate EPS in multiples of 100 and FPM in multiples of 5,000 to each processor. Event Collectors inherit EPS from their parent EP. ## ④ Sizing & the end-to-end event path A raw syslog from a firewall travels like this: the log source sends UDP/TCP syslog to an Event Collector . The EC loads the matching DSM, parses and normalises the event into QRadar's Common Event Format, then forwards it to its parent Event Processor . The EP stores the event in its local Ariel database, passes it through the Rules Engine for real-time correlation, and if a rule fires, the Magistrate creates or updates an offense and sends it to the Console for analyst review. ### Sizing rules of thumb Size Event Processors for peak EPS with at least 20% headroom — bursts (authentication storms, vulnerability scans) can spike 3–5× the average. A single EP appliance can handle tens of thousands of EPS at high spec; check the IBM Hardware Guide for the exact model capacities. Add Data Nodes when 90-day retention on raw events exceeds the EP's internal disk. Add an App Host before installing more than one or two QRadar applications to keep Console performance stable. For the Flow side, size Flow Processors for peak FPM at the network boundary — NetFlow can generate far more FPM than logs generate EPS in a traffic-heavy environment. Figure 4 — End-to-end event path in QRadar A raw log travels from the source through the Event Collector and Event Processor before offenses reach the Console. End-to-end event path in QRadar Log Source firewall / server / app Event Collector parse + normalise DSM Event Processor Ariel store + Rules Magistrate create / update offense Console analyst triage + reports A raw log travels from the source through the Event Collector and Event Processor before offenses reach the Console. Priya at a Mumbai bank faces this QRadar starts dropping events during morning trading hours. The license pool management page shows the main Event Processor is at 100% of its 500 EPS allocation, and the EPS or FPM license pool over-allocated alert fires. Likely cause The EP's EPS allocation matches the average load, not peak load. Trading system log bursts during market open spike EPS 3–4× above average, exceeding the allocation and triggering QRadar's throttle. Diagnosis Check Admin > License Pool Management — the EP shows Allocated EPS = 500, Current EPS = 500 with an over-allocation warning. The System Notifications tab confirms events are being throttled. Admin ▸ License Pool Management ▸ Event Processor row ▸ Allocated EPS column Fix Either purchase additional EPS capacity and increase the EP's allocation, or deploy a second Event Processor and split the log sources between them to bring each EP within its allocation at peak. Set the allocation with 20% headroom above expected peak. Verify Monitor for one full trading day. License Pool Management should show current EPS comfortably below allocated EPS at peak, and the over-allocation System Notification should not fire. Check the System Notifications tab first Before blaming a rule or a log source for missing events, check Admin > System Notifications. QRadar posts explicit alerts for over-allocated EPS/FPM, throttled Event Collectors, and Data Node storage warnings. One read of that screen answers most 'where did my events go?' tickets without any deep-dive. Quick check · Q4 of 10 · Analyze An analyst notices the Console is slow and apps are crashing. The most likely root cause is… a) The Data Node is full b) The Event Collector has no DSMs loaded c) QRadar applications are running on the Console instead of an App Host d) The Flow Processor is over-allocated on FPM Correct: c. QRadar apps run in Docker containers. Without an App Host they run on the Console, consuming its CPU and memory. The fix is to deploy an App Host appliance and move the apps there. 👉 So far: Raw log → Event Collector (DSM parse) → Event Processor (Rules Engine + Ariel) → Magistrate (offense) → Console (analyst triage). Size for peak EPS + 20% headroom; add Data Nodes for retention, App Host for extensions. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between all-in-one and distributed QRadar? What does the QRadar Console do? What is a Data Node and when do you need one? How does EPS licensing work in QRadar? What does the App Host do in QRadar? How should I size a new QRadar Event Processor? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember How many QRadar Consoles can exist in a single QRadar deployment? a) One Console per Event Processor b) Exactly one Console per deployment c) Up to four in a distributed setup d) As many as the license allows Correct: b. QRadar always has exactly one Console per deployment. It is the single management brain holding the license pool, offense queue and global configuration. Adding more EPs does not add more Consoles. Q6 · Understand Which QRadar component stores normalised events and runs the Rules Engine for real-time correlation? a) The App Host b) The Event Collector c) The Data Node d) The Event Processor Correct: d. The Event Processor receives normalised events from Event Collectors, runs the Rules Engine and Magistrate for real-time correlation, and stores events in the local Ariel data store. The Event Collector only parses and normalises; the Data Node only adds storage. Q7 · Apply Your QRadar EP's Ariel disk fills up before the required 90-day retention window. What is the correct fix? a) Add one or more Data Nodes to extend the EP's Ariel storage b) Increase EPS allocation in the license pool c) Add an App Host to free Console memory d) Deploy a second Event Collector to reduce log volume Correct: a. Data Nodes extend the Ariel storage and search capacity of an Event Processor. Adding Data Nodes lets one EP hold longer retention windows without replacing the EP. App Host, EPS allocation, and Event Collectors do not address disk storage. Q8 · Analyze FPM consumption is spiking above the licensed limit during business hours. Which component should you examine first? a) The Event Processor's Rules Engine b) The Console's offense queue c) The Flow Processor and its FPM allocation in the license pool d) The App Host Docker containers Correct: c. FPM (Flows Per Minute) is processed by Flow Processors and allocated from the Console's FPM pool. Check the Flow Processor's current FPM vs its pool allocation in Admin > License Pool Management. If it is over-allocated, flows will be dropped. Q9 · Evaluate An interviewer asks how to scale QRadar to handle double the current EPS. Best answer? a) Replace the all-in-one with a larger all-in-one b) Add a Data Node to the existing Event Processor c) Add an Event Processor, allocate additional EPS from the license pool, and distribute log sources across both EPs d) Increase the Console disk size Correct: c. You scale QRadar EPS by adding Event Processors and distributing log source traffic across them, then allocating the pool's EPS to each EP in the License Pool Management console. Data Nodes add storage, not EPS capacity. The Console's disk is unrelated to EPS throughput. Q10 · Evaluate What is the strongest reason to deploy an App Host before installing multiple QRadar applications? a) Apps require an App Host to access network flows b) Without an App Host, apps run on the Console and compete for its CPU and memory, causing UI slowdowns c) IBM does not support apps without an App Host licence d) Data Nodes cannot be indexed without an App Host Correct: b. Without an App Host, QRadar applications run as Docker containers on the Console itself, competing with management, offense processing and reporting for CPU and memory. This causes Console slowdowns and app crashes. An App Host isolates app workloads so the Console stays responsive. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the difference between an Event Collector and an Event Processor in QRadar? Then compare with the expert version. Compare with expert answer Expert version: The Event Collector is the ingestion edge: it sits close to log sources, loads DSMs to parse and normalise raw events into QRadar's Common Event Format, and forwards the structured events upstream. The Event Processor is the correlation engine: it receives those normalised events, stores them in the Ariel data store, runs the Rules Engine for real-time pattern matching, and hands matched events to the Magistrate to create or update offenses on the Console. The EC normalises; the EP correlates. You can have many ECs feeding one EP, or spread ECs across network segments to reduce WAN traffic before correlation. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on IBM QRadar at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Console The single management appliance per QRadar deployment — holds global configuration, the offense queue, user management, reporting and the EPS/FPM license pool. Event Processor (EP) The correlation engine that receives normalised events, runs the Rules Engine and Magistrate, and stores events in the local Ariel data store. Add EPs to scale EPS. Event Collector (EC) Sits close to log sources; loads DSMs to parse and normalise raw events, then forwards them to the parent Event Processor. Inherits EPS allocation from its EP. Flow Processor (FP) Processes network flow records (NetFlow, sFlow, J-Flow) and produces QRadar flows, measured in FPM (Flows Per Minute). Data Node Extends the Ariel storage and search capacity of an Event Processor. Does not process or correlate events — purely adds disk and index space for longer retention. App Host Runs QRadar applications in Docker containers, isolated from the Console so that analytics workloads (Advisor, UBA, etc.) do not compete for Console CPU. EPS (Events Per Second) The licensed rate at which QRadar ingests, normalises and correlates events. Base licence is 100 EPS; additional EPS purchased in multiples of 100. FPM (Flows Per Minute) The licensed rate at which QRadar processes network flow records. Base licence is 15,000 FPM; additional FPM purchased in multiples of 5,000. Ariel QRadar's proprietary time-series data store used by Event Processors to hold raw and normalised events for search and correlation. Data Nodes extend its capacity. License Pool Management The Admin console screen where the Console's total licensed EPS and FPM are sliced and allocated to individual Event Processors and Flow Processors. #### 📚 Sources IBM — QRadar Security Intelligence Platform overview and components . ibm.com/docs/en/qsip/7.5 - IBM — QRadar 7.5 Architecture and Deployment Guide . ibm.com/docs/en/SS42VS_7.5/pdf/b_siem_deployment.pdf - IBM — Distributing event and flow capacity (License Pool Management) . ibm.com/docs/en/qsip/7.5.0?topic=management-distributing-event-flow-capacity - IBM Support — QRadar: About EPS & FPM Limits and throttling behaviour . ibm.com/support/pages/qradar-about-eps-fpm-limits - IBM Support — QRadar Data Gateway and Event Collector hardware capabilities EPS/FPM threshold enforcement . ibm.com/support/pages/qradar-data-gateway-and-event-collector-hardware-capabilities-epsfpm-threshold-enforcement - ScienceSoft — IBM QRadar SIEM deployment case study for a 4 million subscriber telecom provider . scnsoft.com/case-studies/ibm-qradar-siem-deployment ### What's next? Got the deployment picture? Next, go deep on QRadar offenses — how the Rules Engine correlates raw events into actionable offenses, how the Magistrate ranks them by magnitude, and how analysts triage them from the Offenses tab. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt