Forward rsyslog messages over TCP to a specific port

In rsyslog's legacy syntax, *.* @@127.0.0.1:5000 forwards all facilities and severities over TCP to port 5000. A single @ selects UDP. For a new configuration, an explicit forwarding action makes queue and retry settings easier to review.

Loopback means the sender's own network namespace. Use the receiver's real hostname or address when it is another machine or container.

Configure the sender

Add a forwarding action to the sender's normal ruleset:

action(type="omfwd"
       target="127.0.0.1"
       port="5000"
       protocol="tcp"
       queue.type="LinkedList"
       queue.filename="forward5000"
       queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

Set the global work directory to a writable persistent location, commonly /var/spool/rsyslog, if it is not already configured. The queue filename enables disk assistance; the example's capacity is a budget to size for your outage window. It is not unlimited storage.

Unlike legacy queue directives placed after a forwarding rule, the action parameters above unambiguously belong to that action. See the omfwd reference.

Give received messages a separate route

On a local receiver, use an input-bound ruleset:

module(load="imtcp")

ruleset(name="received5000") {
    action(type="omfile" file="/var/log/received-5000.log")
}

input(type="imtcp"
      address="127.0.0.1"
      port="5000"
      ruleset="received5000")

If the sender and receiver are the same daemon, this separate ruleset prevents incoming messages from passing through the general forwarding rule again and creating a loop. For a remote receiver, change the bind address deliberately and allow TCP 5000 only from intended senders.

Verify receipt, not just a connection

On each affected host:

sudo rsyslogd -N1
sudo systemctl restart rsyslog.service

Then generate a distinctive message on the sender:

logger -t forwarding-test 'TCP port 5000 delivery test'
sudo tail -F /var/log/received-5000.log

Read the file on the receiver. If the destination is DataKit's log listener, use its actual address, port, and framing/parser configuration, then inspect the event in Guance.

TCP provides ordered transport and retransmission; it does not by itself acknowledge durable processing by the destination. Test disconnection, queue exhaustion, and recovery for the guarantees you need. Consider RELP when application-level acknowledgements are required and both endpoints support it. TLS is a separate configuration requirement for authenticated, encrypted transport.

To forward only one application, wrap the action in a condition such as if ($programname == "myapp") then { ... }, replacing the ellipsis with the complete action. Avoid overlapping routes that unintentionally send the same event twice.