Context
A machine records local events, yet the central search tool shows nothing new. Rsyslog forwarding contains several boundaries: rule matching, an output action, any action queue, transport authentication and collector ingestion. A successful TCP connection proves only part of that path.
Prepare the sender and collector identifiers, rsyslog versions, approved port, certificate names and expected destination index. Use a unique harmless marker instead of a production message containing personal data. Confirm the support team can inspect both ends or has a named collector owner; sender-only evidence cannot establish ingestion success.
Inspect the complete forwarding path
- Read the specific ruleset and forwarding action. Confirm that the test event reaches this action and is not discarded or rerouted earlier. Run
rsyslogd -N1to validate configuration syntax using the distribution's installed binary. Syntax success does not validate certificate trust, collector availability or matching business events. - Review transport settings together. The upstream
omfwddocumentation distinguishes the stream driver from its mode: selecting a TLS-capable driver alone is not sufficient to enable TLS. Compare the configured authentication mode, trusted CA and permitted peer name with the intended collector certificate. Do not replace peer verification with anonymous transport merely to clear an error. - Inspect per-action queue configuration and any available internal statistics. A forwarding action can be suspended while local logging still works. Determine whether its queue is memory-only or disk-assisted, where spool files belong and what happens when the configured capacity is reached. Filesystem availability and queue sizing are separate from certificate correctness.
- Send one unique marker through the approved logging facility, then ask the collector owner to locate the same marker in receiver and ingestion evidence. Record timestamps and the intended index. Allow for the pipeline's documented processing delay, but do not assume an unbounded delay means delivery will eventually occur.
An illustrative certificate mismatch
In an illustrative estate, a collector is replaced behind the same address, but its certificate presents a different name. Sender-side actions repeatedly suspend and retry. The queue grows while local system logging continues normally. A healthy local logfile and a reachable port would both be misleading acceptance checks for this incident.
| Evidence | Next inspection | Meaning |
|---|---|---|
| Local marker absent | Input and ruleset routing | Event never reached forwarding |
| TLS peer verification fails | CA chain and permitted peer | Authentication boundary |
| Queue grows during suspension | Action errors and spool capacity | Delivery is deferred locally |
| Receiver has marker, index does not | Collector parsing and routing | Downstream ingestion boundary |
Correct and prove delivery
Restore the demonstrated trust, route or collector configuration through its owner. Preserve queue contents and understand replay behavior before restarting or moving spool files. Rsyslog queueing can improve decoupling, but a queue is not an unlimited retention system and does not by itself promise an end-to-end delivery guarantee.
Repeat the marker test and confirm the queue drains without recurring suspension. Verify both a current event and an older queued event when applicable. Check for duplicates in the collector so downstream users understand the observed delivery behavior during recovery.
Maintain a logging procedure
Monitor action suspension, queue occupancy, spool-space pressure and collector freshness separately. Document certificate renewal ownership and the expected peer identity. Retain a marker-test procedure, escalation contact and queue-handling precautions in the logging SOP. Clouvenix Linux administration can help connect sender configuration with collector acceptance evidence.