Identify the Wazuh queue before changing event capacity

Bottom line: Locate the queue and event population before choosing a capacity setting. Keep secure agent input, remote syslog and the analysis event categories explicit in the investigation.

Source fact: documented behavior

The Queuing mechanisms guide limits queue_rd to agent events with a secure connection and explicitly excludes remote syslog events from that queue setting.

The analysis engine separates incoming events into category queues with individually configurable processing threads.

Its analysis statistics expose received or dropped events by type, and the guide directs persistent internal-option overrides to local_internal_options.conf to survive upgrades.

What the source does not establish

This article chooses the documented Wazuh queue and observation point. It does not supply a universal queue size, guarantee zero event loss or approve deleting buffered events to make an incident appear resolved.

Applicability questions

• Did the affected events arrive through an agent or remote syslog?
• Which daemon and event category show the drop evidence?
• What measurements distinguish input congestion from analysis pressure?
• Where will a reviewed override be retained across upgrades?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends matching each proposed queue change to a named input path and measured drop category before tuning it.

1. Choose one actual affected source and document its delivery path into Wazuh. Record the event type and the daemon evidence that identifies the bottleneck. If the source is remote syslog, reject a worksheet that proposes changing the secure-agent queue merely because both kinds of events reach the same server. Keep the input classification visible beside the proposed setting.
2. Capture a baseline from the supported daemon statistics and identify the specific analysis category if processing drops are involved. Have the server operator propose a bounded adjustment to that category rather than enlarging every queue together. Record the resource allowance and observation interval as deployment decisions; do not borrow the source’s example values as a guaranteed capacity for an unrelated workload.
3. Place approved persistent overrides in the documented local override location and retain the previous configuration. Change one investigated cause at a time, then repeat the same representative event workload. If a different stage becomes constrained, reopen the diagnosis rather than increasing additional limits without measurements. Preserve pending events through the established recovery process instead of discarding them to reduce a displayed queue.

Verification and evidence

Proposed verification: compare secure-agent and remote-syslog case records, then ask a reviewer to map each to the applicable communication setting before any change. For an approved isolated workload, retain before-and-after daemon statistics, event-category counts and actual delivery observations at the intended destination.

Reconcile a smaller queue display with the received and dropped-event evidence; do not accept the display alone as proof of recovery. Record which override file contains the change and how it will be checked after a later upgrade. No event flood, capacity benchmark or queue tuning was performed for this article, and the proposed cases establish no general throughput promise.

Official references

• Queuing mechanisms — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.