Pipeline Troubleshooting¶
Guidelines and common checks for diagnosing problems in rsyslog log pipelines. Covers syntax validation, module loading, parse errors, and queue behavior.
Overview¶
Even well-structured log pipelines can misbehave — messages may stop flowing, queues can fill up, or transforms might silently fail. This page explains a quick, repeatable process to identify and fix issues in rsyslog configurations that use the log pipeline model.
flowchart LR
I["Input"]:::input --> R["Ruleset"]:::ruleset --> A["Action"]:::action
classDef input fill:#d5e8d4,stroke:#82b366;
classDef ruleset fill:#dae8fc,stroke:#6c8ebf;
classDef action fill:#ffe6cc,stroke:#d79b00;
%% visually shows that problems can occur at any stage
Typical symptoms¶
Messages received but not written to output files.
High CPU usage or large backlog in queues.
JSON transformation results missing or empty.
Duplicate or reordered messages in outputs.
Unexpected stop in forwarding (e.g., network blockages).
Basic validation steps¶
Check configuration syntax - Run
rsyslogd -N1before restarting to confirm there are no syntax errors. - Verify that all required modules load (look formodule '...' loadedin startup logs).Inspect message content - Add a temporary debug action to see the processed fields:
action(type="omfile" file="/tmp/debug" template="RSYSLOG_DebugFormat")
Compare property values (e.g.,
$msg,$!structured) with expectations.
Verify parsing success - When using
mmjsonparseor similar modules, check the variable$parsesuccess. - Example guard condition:if $parsesuccess != "OK" then action(type="omfile" file="/var/log/parsefail.log")
Monitor queues - Use
impstatsto emit queue statistics and verify flow between stages. - Look for largesizeorenqueuedvalues — these indicate bottlenecks.
Common causes and fixes¶
Problem |
Typical solution |
|---|---|
Module not loaded |
Add |
JSON parsing fails |
Use |
Output file empty |
Check |
Queue never drains |
Tune |
Duplicate logs |
Ensure only one ruleset receives input |
Remote forwarding stopped |
Verify network reachability or RELP retry |
Advanced diagnostics¶
Increase debug level Start rsyslog manually with
rsyslogd -dnto trace the processing flow.Use impstats for performance tuning Enable periodic statistics to monitor queue backlog, action latencies, and thread counts.
Isolate a stage Comment out actions or parsers to test where the flow breaks.
Check permissions Ensure rsyslog has write access to output directories.
Best practices¶
Validate changes with
rsyslogd -N1before deploying to production.Keep
impstatsenabled in complex deployments.Always gate expensive transforms (e.g., JSON parsing) with success checks.
Use short, dedicated queues for slow destinations.
Conclusion¶
Troubleshooting a log pipeline means following the data path — from input, through ruleset logic, to output actions. By validating configuration, verifying queues, and monitoring parser status, you can quickly pinpoint where logs stop and restore normal flow.
See also¶
Support: rsyslog Assistant | GitHub Discussions | GitHub Issues: rsyslog source project
Contributing: Source & docs: rsyslog source project
© 2008–2025 Rainer Gerhards and others. Licensed under the Apache License 2.0.