syslog-ng users often face the challenge of not being able to send logs over the network from one syslog-ng instance to another. There can be many reasons for this; some are independent from syslog-ng, while others are related to the syslog-ng configuration.
When Red Hat Enterprise Linux 7 was released, there was a surge in complaints because both SELinux and iptables rules, by default, prevent network connections to and from syslog-ng. Once people got used to the “secure by default” nature of RHEL 7, these complaints became rare.
Another source of confusion comes from the abundance of syslog-ng configuration possibilities. It can be hard to debug side effects when you configure one type of destination on the client and a different type of source on the server. Some combinations of sources and destination configurations result in parts of log messages going through, just not in the expected form. In other cases, logging doesn’t work at all.
Here is an example of what you see in /var/log/messages when the syslog() destination (using the RFC5424 protocol) is used for sending a log message, but the receiving end uses the tcp() source (using good old RFC3164):
Jan 25 10:12:35 172.16.146.1 125 <38>1 2017-01-25T10:12:35+01:00 linux-cr5i sshd 7619 - - Accepted keyboard-interactive/pam for root from ::1 port 49452 ssh2 Jan 25 10:12:35 172.16.146.1 121 <86>1 2017-01-25T10:12:35+01:00 linux-cr5i sshd 7619 - - pam_unix(sshd:session): session opened for user root by (uid=0)
As the messages arrive in an unexpected format, they are not parsed but appended as is after the current time and source IP address.
To make your life easier, we added a table to the syslog-ng documentation that shows which settings work, which might work, and which do not work at all, along with some explanations. Read more about syslog-ng destinations and sources that match .
If you use matching destinations and sources, but something is still not right, check our generic syslog-ng troubleshooting tips .