Most engineers think…
Most people picture QRadar as 'a SIEM box where logs go in and alerts come out'. That mental model falls apart the moment an interviewer asks you to draw it or scale it.
QRadar is a distributed pipeline. Logs are gathered by an Event Collector, parsed and normalized by DSMs, then run through rules and stored by an Event Processor. Network traffic is turned into flows by QFlow / Flow Collectors and handled by Flow Processors. The Magistrate on the Console correlates rule hits into offenses, and Data Nodes add storage. You can collapse all of that onto one all-in-one appliance, or spread it across many. Knowing which component does what is exactly what lets you size, troubleshoot and explain QRadar.
① What QRadar actually is — a pipeline, not a box
The single most important idea: QRadar is a pipeline that collects, parses, correlates and stores security data — it is not one inline device. Data enters as two kinds: events (logs from firewalls, servers, AD, cloud) and flows (records of network traffic). Both are normalized into a common shape, run through rules, and saved in a searchable store so analysts can investigate.
QRadar ships in two shapes. An all-in-one deployment runs every role on one appliance. A distributed deployment splits the roles across many appliances — separate Collectors, Processors, Data Nodes and a dedicated Console — so you can scale and place collection close to the data. The current classic line is QRadar SIEM 7.5, sitting alongside IBM's newer cloud-native QRadar SIEM and the broader QRadar Suite (SIEM + SOAR + EDR).
Which best describes QRadar's architecture?
② The event path — Collector, DSMs, Processor and the Magistrate
Follow a log end to end. An Event Collector receives raw logs (syslog, WinCollect, APIs), queues them, and hands them to a DSM that parses and normalizes the message into common fields: Event ID, Source IP, Destination IP, Username, Protocol and more. It also coalesces near-identical events to cut volume. The Event Processor then runs the normalized events through the Custom Rules Engine (CRE) and writes them to storage.
Where offenses come from
When rules fire, the Processors send notifications up to the Magistrate (MPC), which lives only on the Console or all-in-one. The Magistrate correlates those hits across all Processors and raises a single offense — the prioritized case an analyst works. In distributed mode the Console does no event/flow processing itself; it is the UI plus the Magistrate.
The web UI for searches, reports and offenses — and the only place the Magistrate runs. In distributed mode it does no event or flow processing itself.
Gathers raw logs and uses a DSM to parse and normalize them into common fields (Source IP, Username, Event ID), then coalesces and forwards.
QFlow turns network traffic into flow records (bytes, packets, ports, duration); the Flow Processor runs flow rules and stores them.
Bolts onto a Processor to add storage and search capacity for the Ariel store, so you scale retention without swapping appliances.
In an interview, separate collection (Event Collector + DSMs, QFlow) from processing (Event/Flow Processors run rules and store) from correlation (the Magistrate on the Console raises offenses). Saying 'the Event Processor stores and the Magistrate correlates' instantly signals you understand the pipeline.
What component parses a raw vendor log into normalized QRadar fields?
③ The flow path — QFlow, Flow Processor, and events vs flows
Network traffic takes a parallel path. QFlow / Flow Collectors read traffic (from a SPAN/mirror or tap, or by ingesting NetFlow/IPFIX/sFlow) and build flow records — who talked to whom, on which ports, for how long, and how many bytes and packets. A Flow Processor processes those flows, runs flow rules, and stores them, the same way the Event Processor handles logs.
The interview line — events vs flows: an event is a point-in-time log of one action (a login, a VPN connect, a deny). A flow is a record of a network session that can last seconds to hours, summarising bytes, packets and ports between two hosts. Events tell you what a device reported; flows tell you what actually moved on the wire — including traffic no device logged.
They are not. An event is a logged action a device reported; a flow is a record of an actual network session (bytes, packets, ports) built by QFlow — including traffic no device ever logged. Always answer with both paths and license each separately (EPS vs FPM).
▶ Watch a firewall login log become an offense
How one raw log travels the QRadar pipeline end-to-end. Press Play for the healthy path, then Break it to see the classic failure.
What is the key difference between an event and a flow?
④ Storage and sizing — Data Nodes, the Ariel store and EPS/FPM
Processors write events and flows to the Ariel time-series store (offenses live in a Postgres database). When you need more retention or faster search, you add Data Nodes: they attach to Processors, take over a share of storage and search, and let you scale capacity without replacing appliances. Searches run over Ariel using AQL (covered in the next lesson).
How it is licensed
Capacity is licensed by throughput: EPS (events per second) for logs and FPM (flows per minute) for flows. Licenses apply to Processors, not Collectors — data is collected anywhere but counted where it is processed. In a distributed estate you pool capacity and distribute it to Processors, adding Processors and Data Nodes as volume grows. The classic mistake is sizing only for today's EPS and ignoring flow volume and retention.
Vikram, a SOC engineer at a Pune fintech, faces this
A new firewall is onboarded, but its logs show up in QRadar as 'Unknown' events with empty Source IP and Username fields, so no rules fire on them.
QRadar has no matching DSM for that firewall's log format, so the events arrive raw and unparsed — nothing is normalized.
Open the Log Activity tab — the events are categorised as Unknown / Stored, not parsed; the log source has no DSM mapping its fields.
Admin ▸ DSM Editor + Log Source Management ▸ Log SourcesInstall or auto-update the correct DSM (or build a custom parser in the DSM Editor) so the fields normalize, then confirm the log source type is set correctly.
Re-check Log Activity: the same logs now show a proper event name, Source IP and Username — and the rules that target them start firing.
Never assume a log source 'is probably fine'. The Log Activity tab shows whether events are normalized or sitting as Unknown. One look tells you if the DSM is doing its job — no guessing about why a rule did not fire.
Your log volume is climbing and searches are slow. What is the right scaling move?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
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.
🧠 In your own words
Type one line: why is QRadar called a pipeline rather than a box? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Console
- The QRadar web UI for searches, reports and offenses, and the only place the Magistrate runs. In distributed mode it does no event/flow processing.
- Event Collector
- Gathers raw logs from sources (syslog, WinCollect, APIs), queues them, applies DSM parsing/normalization and coalescing, then forwards to a Processor.
- Event Processor
- Runs normalized events through the Custom Rules Engine (CRE), executes rule responses, and stores events in the Ariel store.
- QFlow / Flow Collector
- Builds network flow records from traffic (SPAN/tap) or ingested NetFlow/IPFIX/sFlow — bytes, packets, ports and duration per session.
- Flow Processor
- Processes flow records, runs flow rules and stores flows — the flow-side counterpart of the Event Processor.
- Magistrate (MPC)
- The Magistrate Processing Core on the Console; correlates rule hits from all Processors and raises prioritized offenses.
- Data Node
- An appliance that attaches to a Processor to add storage and search capacity for the Ariel store, scaling retention horizontally.
- DSM (Device Support Module)
- A parser for a specific log source format that normalizes raw logs into common QRadar fields like Source IP, Username and Event ID.
- Event vs flow
- An event is a point-in-time logged action; a flow is a record of a network session over time (bytes, packets, ports, duration).
- EPS / FPM
- Licensing throughput metrics — events per second for logs and flows per minute for flows — applied to Processors.
📚 Sources
- IBM Documentation — QRadar events and flows (overview). ibm.com/docs/en/qsip/7.5.0 ▸ overview-qradar-events-flows
- IBM Documentation — QRadar 7.5 Architecture and Deployment Guide (Console, Event/Flow Processors, Magistrate, Data Nodes). ibm.com/docs/en/SS42VS_7.5
- IBM Documentation — Distributing event and flow capacity; EPS and FPM licensing. ibm.com/docs/en/qsip/7.5.0 ▸ management-distributing-event-flow-capacity
- IBM Support — QRadar: About EPS & FPM Limits. ibm.com/support/pages/qradar-about-eps-fpm-limits
- IBM Documentation (DSM) — Introduction to log source management and supported DSMs. ibm.com/docs/en/dsm
- IBM — Cloud-native QRadar SIEM and the QRadar Suite (SIEM + SOAR + EDR). ibm.com/products/qradar-siem
What's next?
Got the architecture? Next, go deep on what QRadar does with all that data: rules and building blocks in the Custom Rules Engine, how offenses get a magnitude, AQL searches over the Ariel store, and User Behavior Analytics (UBA).