Deployment operations and service restarts can affect log processing or service availability. Prefer the QRadar UI and the procedure documented for your exact release. Do not run internal deployment scripts or restart QRadar services just because a generic Linux command is available.
1. Understand QRadar deployment types
QRadar saves configuration changes in a staging area. Changes must be deployed before they become active in the production configuration. The deployment method depends on the type of change; a “normal deploy” is commonly used informally to mean the standard Deploy Changes action in the UI.
| Method | Typical use | Operational impact |
|---|---|---|
| Standard deployment | Changes that affect only particular services—for example, certain user, role, or security-profile changes. | Restarts the services directly affected by the changes. |
| Full configuration deployment | Changes that affect the deployment as a whole, such as adding or changing a managed host or restoring a configuration backup. | Rebuilds configuration files across managed hosts and restarts services as required. The impact depends on the change and QRadar release. |
For the supported workflow, open Admin, review the deployment banner and View Details, then choose Deploy Changes or Advanced → Deploy Full Configuration as QRadar recommends. Do not choose a full deployment simply because it sounds more thorough; it can increase service impact and needs a suitable maintenance/change plan.
IBM's documentation notes that deployment behavior and event-collection handling can vary by release and operation. Confirm the expected impact in the documentation that matches the deployed version and monitor the system after the deploy.
2. Be cautious with manual CLI deployments
The original notes mention these commands:
/opt/qradar/bin/local_transformation.sh -l -f
/opt/qradar/upgrade/util/setup/upgrades/do_deployThese are not recommended here as routine deployment commands. IBM Support documents local_transformation.sh for a specific manual configuration-set deployment scenario affecting a malfunctioning managed host, and the note is limited to particular QRadar releases. Internal scripts such as do_deploy can also be version- and context-dependent.
Use the documented UI workflow for ordinary configuration changes. Use a CLI recovery procedure only when the corresponding IBM technote or IBM Support instructs you to, after verifying the exact QRadar version, target host, expected impact, and rollback plan. Avoid copying an internal command from an old article into production without validation.
3. Understand license capacity: EPS and FPM
QRadar's event and flow processing capacity is measured separately:
- Events per second (EPS): the event rate QRadar is licensed and allocated to process.
- Flows per minute (FPM): the flow rate QRadar is licensed and allocated to process.
Events are records produced by systems, applications, security devices, and other log sources. Flows represent network communications aggregated according to flow attributes. They are different telemetry types and consume different capacity allocations.
Both the license pool and hardware limits matter. A license entitlement is not a guarantee that a given appliance can process an unlimited rate; capacity allocations need to align with the appliance role and hardware capability.
Handling sustained rate overload
It is not accurate to say that every EPS/FPM overage immediately drops all excess telemetry. Depending on the type of data and the condition, QRadar may queue data for later processing, which delays event processing and offense generation. Sustained overload can create a growing backlog; flow capacity limits can also produce overflow records that omit some flow detail. Therefore, capacity alerts should be investigated rather than ignored.
A host operating close to its allocated EPS/FPM capacity has less room to absorb bursts. Persistent overload is not solved by increasing queue size alone. Review rates, queue behavior, hardware limits, license allocations, parsing quality, and rules/custom properties that may have changed data volume.
4. Review and allocate licenses
On QRadar SIEM versions with the corresponding interface, use Admin → System and License Management → Licenses → License Pool Management. The exact menu labels can vary by release or deployment model.
- Review the total EPS and FPM available in the shared license pool and the capacity assigned to each host.
- Compare assigned capacity with average and peak rates—not only a single current reading. IBM's documented views include average rates over the past 30 days and host peak rates.
- Check system notifications for events or flows exceeding the allocated limits.
- If capacity is insufficient, review whether the issue is sustained workload, a data spike, a parsing or rule change, hardware capability, allocation imbalance, or a license entitlement gap.
- Change allocations or license keys only through the documented license-management workflow and within hardware and entitlement limits.
To add or update entitlements, follow IBM's steps for uploading the license, allocating it to the appropriate system, and deploying the license change. License expiry can cause capacity-pool deficits and affect access to Log Activity or Network Activity features; do not wait until expiry to validate renewal arrangements.
5. Linux service management with systemctl
Use systemctl for basic service visibility, but do not restart QRadar-managed services just because a unit exists. Follow IBM’s procedure for the installed release before making changes.
# Check HostContext status
systemctl status hostcontext
# Review recent HostContext messages
journalctl -u hostcontext --since "1 hour ago"An enabled unit is configured to start at boot; it does not prove the service is healthy or currently running. Gather status and logs before taking action, and confirm the intended unit name on the appliance.
6. A safe operational workflow
- Record context: QRadar version and fix pack, host role, time of change, and the symptom or reason for maintenance.
- Choose the right deployment: review the deployment banner and QRadar guidance, then use standard or full configuration deployment as appropriate.
- Check service and system state: gather status and time-bounded logs before changing anything.
- Verify capacity: compare actual EPS/FPM trends, allocated capacity, host limits, and system notifications.
- Validate after the change: confirm services are healthy, expected log sources are communicating, new events are searchable, and no new capacity/deployment warnings appeared.
- Document the outcome: record the command or UI workflow used, the evidence collected, the change made, and the verification result.
7. Official references
- IBM: Configuration changes in QRadar
- IBM: Deploying changes
- IBM Support: Specific manual Configurationset deploy scenario using local_transformation.sh
- IBM: QRadar license options and entitlements
- IBM: Event and flow processing capacity
- IBM: Capacity sizing and burst handling
- IBM QRadar Support Tools 101
- IBM Support: QRadar General Health Checklist
Service handling, UI paths, capacity, and licensing depend on QRadar release, host role, and entitlement. Use the documented procedure and an approved change window for operations that can affect ingestion or availability.
For QRadar operations reviews, EPS/FPM allocation, or deployment reliability work, contact me with the deployment topology and current capacity or health indicators.