IBM Support

QRadar: Impact of Deploy Full Configuration on events, flows, and offenses

Question & Answer


Question

What is the impact of initiating a Deploy Full Configuration on QRadar systems?

Cause

The QRadar Admin tab defines changes that require the type of deployment update required:

  1. Deploy changes - A standard deploy allows QRadar to send updates to all managed hosts without restarting services.
    image-20230921170444-1
  2. Deploy Full Configuration - A full deploy requires services to restart to load configuration changes on all hosts. If you click Deploy Changes and a service restart is required, the system informs you that a service restart is required.
    image-20230921172542-2

Answer

Event and flow collection is handled by the ecs-ec-ingress service, which is not restarted as part of a Deploy Full Configuration action. Ecs-ec-ingress stores data in a buffer, so event and flow collection continues through the Full Deploy action. Full processing of new incoming events and flows occurs after the ecs-ec and ecs-ep services restart where the buffer is handled.

Caveat: While ecs-ec-ingress is not started and buffers flow data, qflow is restarted during a full deploy. QRadar qflow service is the primary component that processes all flow data ingested by QRadar. When qflow service starts all flow data will stop logging and you will observe a system notification about "Dropped a templateless data flow". For more information, see QRadar: Flow notification, "Dropped a templateless or unmarried flow" warning in logs.

After initiating a Deploy Full Configuration action in QRadar 7.3.0 and earlier versions, the system stopped logging events and flows. It also stops firing offenses. This is because the Deploy Full Configuration action involves restarting the ECS service on all systems.

The ECS is made up of two processes: ecs-ec and ecs-ep

  • The ecs-ec process is responsible for event and flow collection. This includes event parsing, traffic analysis, coalescing, and event forwarding. The ecs-ec process can exist on Consoles, Event Processors, Flow Processors, Event Collectors, and Flow Collectors.
  • The ecs-ep process is responsible for the Custom Rules Engine (CRE), event and flow streaming, and storage. The ecs-ep process can exist on Consoles, Event Processors, and Flow Processors, but does not exist on Flow Collectors. The Magistrate is also part of the ecs-ep process and exists on the Console only. The Magistrate is responsible for offense rules, offense management, and offense storage.
Important:  Administrators with strict outage policies are advised to complete deploy changes during a scheduled maintenance window for their organization.
 
When you deploy changes after you restore a configuration backup, you can restart the event collection service now or later. When you choose to restart the service later,QRadar deploys all changes that don't depend on the event collection service, and continues to collect events while the other services restart. The deployment banner continues to show undeployed changes, and the Event collection service must be restarted message is shown when you view the details.


 

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.4.3;7.5.0;and future releases"}]

Document Information

Modified date:
21 September 2023

UID

swg21993267

Page Feedback