Information: Forum is in read-only mode
For details and other support options see

Adding FQDN to Linux syslogs

This is the place for you, if you got rsyslog up and running but wonder how to make it do what you want.

Moderator: alorbach

Google Ads

Adding FQDN to Linux syslogs

Postby PCnetMD » Thu Jul 13, 2017 9:37 pm

We have numerous remote sites that are configured identically, for standardization of our systems, including the subnets at each site.
All servers are running custom applications on headless RHEL 6.2, 6.8 and 7.3.
We are collecting syslogs on a central server at each of our remote sites.
We have recently installed T-1 connections to all remote sites and are wanting to forward the syslogs from all of our remote sites to a central syslog repository at our home office.
Our problem is properly separating each sites syslog files from each other so that we can track syslogs back to each site, as necessary.
Each sites syslog server is collecting the logs, but they are only marking each log entry with the simple $hostname associated with each server at each site (i.e. mail1, mail2, ora1 ora2, sql1, sql2, fps1, fps2, etc...)
We want to include each sites local designator into each syslog entry (i.e. atl, den, okc, ind, etc...)
Changing each $hostname to a FQDN (i.e. $hostname.$site.$domain) does not change the servername in the syslog entries, plus it breaks multiple applications.
Is there a simple way insert/concatenate a FQDN into the syslog entries without actually changing each servers $hostname? Can rsyslog, at each site, add/concatenate the $site and $domain names as it forwards the syslogs to the home office repository?
Posts: 4
Joined: Fri Jun 30, 2017 2:14 pm

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Re: Adding FQDN to Linux syslogs

Postby dlang » Fri Jul 14, 2017 12:11 am

you can do a lot with templates and the various variables (including $fromhost on the relays)

What I do is have the relays encapsulate the message it receives in JSON and then add additional metadata (what server was the relay, what time the relay server saw the message, the IP the message came from, etc) and then send it up the line. The central server can then have access to all that metadata as well as the message and simple hostname that was originally used.

As you have noted, using FQDN instead of the simple hostname breaks a bunch of stuff. But with the JSON approach, I can pass the simple message as it was originally sent to the software that needs that, or can send the fqdn if the software wants that.

I also work really hard to make the simple hostnames unique across the enterprise, there is just too much stuff out there that breaks when you start relying on the fqdn being unique instead of the hostname being unique.
Frequent Poster
Posts: 1002
Joined: Mon Sep 15, 2008 7:44 am

Google Ads

Return to Configuration

Who is online

Users browsing this forum: No registered users and 3 guests