The symptoms can vary, typically dropped events or events sent to storage. Example logs for dropped events:

[ecs-ep.ecs-ep] [5bbe913a-55e2-494e-b712-4a0ecf0ec78e/SequentialEventDispatcher] com.q1labs.sem.monitors.ECSQueueMonitor: [WARN] [NOT:0060005100][x.x.x.x/- -] [-/- -]ECS Queue Monitor has detected a total of 10228 dropped event(s).  1252 event(s) were dropped in the last 60 seconds. EP Queues: 1252 dropped event(s). MPC Queues: 0 dropped event(s).

Example logs for stored events:

[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=<hostname>:ecs-ep/EP/Processor2]] com.q1labs.semsources.cre.CRE: [WARN] [NOT:0080004101][x.x.x.x/- -] [-/- -]Custom Rule Engine has sent a total of 787911838 event(s) directly to storage. 99125 event(s) were sent in the last 60 seconds.  Queue is at 100 percent capacity.

The PIPELINE STATUS messages in the /var/log/qradar.log file indicate the state of the queues of the pipeline, and provides insight into portions of the pipeline that require attention.

[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=<hostname>:ecs-ep/EP/Processor2]] 
com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO]  ---- PIPELINE STATUS -- Initiated From: EPCRE

[ecs-ec-ingress.ecs-ec-ingress] [Syslog UDP receiver (port 514)] com.q1labs.sem.monitors.PipelineStatusMonitor:
com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO]  ---- PIPELINE STATUS -- Initiated From: SyslogSource

The cause can be determined based on the part of the pipeline shown after the Initiated From, field. Common values include:

1. DSMFilter
   • Data is normalized incorrectly (i.e. Parse a Linux PAM log as a Unity One event).
   • Expensive custom properties with Parse in Advanced (Optimized) enabled.
   • Incorrect configuration of a log source causing parsing or normalization to take a long time.
   • Expensive Log Source Extension being used.
   • Ingesting partial events. This typically happens when the payload size is not large enough and the log source is sending half of an event from the same log source identifier. Ensuring that all payloads are complete is important.

2. TrafficAnalysis
   • Data is coming from a device that is not easy to identify, likely a mis-configured log source.
   • An unknown log source that QRadar does not support (or a subset of logs we don't) causing all of our auto-detection to take a long time.

3.  EPCRE
   • Some rule or rules might not be well constructed and are therefore expensive on the engine.
   • Payload-related rule tests might also be expensive and cause performance degradation.

Use the following command to simplify the output:

grep -i 'Pipeline' /var/log/qradar.log | sed -s 's/::fff.*-]//' | less

A sample output would look like this:

[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=jpsjc-jsa3.jnpr.net:ecs-ep/EP/Processor2]] com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] ----	PIPELINE STATUS -- Initiated From: EPCRE
[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=jpsjc-jsa3.jnpr.net:ecs-ep/EP/Processor2]] com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] EC_Ingress	(Filters: 0.00 pc) (Queues: 0.00 pc) (Sources: 0.00 pc)
[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=jpsjc-jsa3.jnpr.net:ecs-ep/EP/Processor2]] com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] EC	(Filters: 0.00 pc) (Queues: 0.00 pc) (Sources: 0.00 pc)
[ecs-ep.ecs-ep] [[type=com.eventgnosis.system.ThreadedEventProcessor][parent=jpsjc-jsa3.jnpr.net:ecs-ep/EP/Processor2]] com.q1labs.sem.monitors.PipelineStatusMonitor: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] EP	(Filters: 55.55 pc) (Queues: 6.73 pc) (Sources: 0.00 pc)

In this case, the Filter: CRE EP queue is at 100%, which would mean that the Custom Rule engine is struggling to cope with the load, likely due to expensive rules.

The expensive rules can be found by following the KB article : https://supportportal.juniper.net/s/article/STRM-Events-dropped-in-the-Custom-Rule-Engine-CRE.

Created KB article

24/11/2025: Minor edits