Do you want to know how your log messages arrived to syslog-ng? The new $TRANSPORT macro provides you with part of the answer. It shows you the protocol variant for network sources, or the kind of local source used.
Before you begin
You need a sufficiently recent syslog-ng version to use the $TRANSPORT macro. It was originally introduced in syslog-ng 4.5.0 for network sources, then version 4.7.1 introduced support for local log sources. If syslog-ng is not recent enough on your host, check https://syslog-ng.org/3rd-party-binaries/ for the availability of up-to-date third-party packages.
Testing
For testing, I used a very simple configuration on my openSUSE system, in which I created a config under the /etc/syslog-ng/conf.d directory:
source s_net {tcp(port(514));};
destination d_json {file("/var/log/json" template("$(format-json --scope rfc5424 --scope dot-nv-pairs
--rekey .* --shift 1 --scope nv-pairs
--exclude DATE @timestamp=${ISODATE})\n\n")
);};
log {source(src); source(s_net); destination(d_json);};
This opens a TCP port using the RFC 3164 syslog protocol, and it creates a file destination with JSON formatting. This way, you can see all name-value pairs related to a log message, including the value of the $TRANSPORT macro. The log path connects the freshly created network source and the local log source (its name might be different on your host) to the file destination.
After reloading the syslog-ng configuration, you can begin testing. I used the logger command in both cases. First:
logger bla
This sends a log to the systemd journal, which is read by syslog-ng. Here is the resulting log:
{"journald":{"_UID":"0","_TRANSPORT":"syslog","_SYSTEMD_USER_UNIT":"vte-spawn-a112c345-1f0d-4c95-b9ea-2809e66e648d.scope","_SYSTEMD_USER_SLICE":"app-org.gnome.Terminal.slice","_SYSTEMD_UNIT":"user@1000.service","_SYSTEMD_SLICE":"user-1000.slice","_SYSTEMD_OWNER_UID":"1000","_SYSTEMD_INVOCATION_ID":"62ae9a791eca4fc28b00fcc2148f55b2","_SYSTEMD_CGROUP":"/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-a112c345-1f0d-4c95-b9ea-2809e66e648d.scope","_SOURCE_REALTIME_TIMESTAMP":"1716554521908053","_SELINUX_CONTEXT":"unconfined\n","_PID":"13647","_MACHINE_ID":"380a2d3efc074a248776bb753b0c8327","_HOSTNAME":"czplaptop","_GID":"0","_COMM":"logger","_CAP_EFFECTIVE":"1ffffffffff","_BOOT_ID":"25b40a0c79e845a5823d0aa752990b10","_AUDIT_SESSION":"2","_AUDIT_LOGINUID":"1000","SYSLOG_TIMESTAMP":"May 24 14:42:01 ","SYSLOG_IDENTIFIER":"root","SYSLOG_FACILITY":"1","PRIORITY":"5","MESSAGE":"bla"},"TRANSPORT":"local+journal","SOURCE":"src","PROGRAM":"root","PRIORITY":"notice","PID":"13647","MESSAGE":"bla","HOST_FROM":"czplaptop","HOST":"czplaptop","FACILITY":"user","@timestamp":"2024-05-24T14:42:01+02:00"}
It is a long log message with many name-value pairs. The relevant one from our point of view is
"TRANSPORT":"local+journal"
As you can see, it was collected from a local log source, and it is from systemd journald.
logger --rfc3164 -P 514 -n 127.0.0.1 bla
The second log message was also generated using logger, but the message was sent over the network using the legacy syslog protocol to port 514 on localhost. The resulting log message is considerably shorter, so I do not have to show you the $TRANSPORT macro separately:
{"TRANSPORT":"rfc3164+tcp","SOURCE":"s_net","PROGRAM":"bla","PRIORITY":"notice","MSGFORMAT":"rfc3164","MESSAGE":"","LEGACY_MSGHDR":"bla","HOST_FROM":"localhost","HOST":"localhost","FACILITY":"user","@timestamp":"2024-05-24T14:52:16+02:00"}
What is next?
Of course, in this simple configuration, the content of the $SOURCE macro also identifies the source perfectly well. However, in a real-life configuration, you will most likely have multiple source drivers in a single source. Being able to see the mode of transport still allows you to decide how much you trust a log message coming through that source. UDP can be spoofed (just think of syslog-ng’s very own source spoofing for UDP), while TLS makes logs more reliable.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.