On 2/19/2018 9:26 AM, deoren wrote:
On 2/19/2018 8:52 AM, Graham Leggett via rsyslog wrote:
Hi all,
I have a number of java services that include support for logging to
syslog, but unfortunately they can only log by sending udp packets to
port 514.
This is not in itself a problem, however these services have no stable
predictable behaviour when it comes to hostname handling, and so we
have some logging “localhost”, others logging the shortname, and there
is no practical way for us to fix this.
rsyslog supports using a lookup table and also supports reloading that
lookup table upon receiving a HUP signal.
I briefly fought the battle you described before giving up and building
a JSON file that mapped known hostnames to IPs (or vice versa I guess)
so that I could have stable results.
I can't say whether this is the better approach or whether having
complete A/PTR records for those devices is the better approach, but I
opted for the JSON file as it seemed a simpler option. Mid to long term
I have the option of generating the file from a database and then
passing rsyslog SIGHUP to use the new file.
Doc:
http://www.rsyslog.com/doc/v8-stable/configuration/lookup_tables.html
> What I need to do is configure rsyslogd to, when it receives messages
from localhost port 514 (only only this), override the hostname being
forwarded and set that hostname to the FQDN of the rsyslogd machine.
Note: I've not had to do this specific step, but if I had to configure
the system to receive 514/udp from remote systems and 514/udp from the
local system I might try to configure as separate inputs and then attach
a ruleset to the 127.0.0.1:514/udp input just for messages that you
planned to rewrite. I don't know if there is a performance gain either
way, but using a UNIX socket might allow for larger message passing (I
don't know this, but I would suspect this to be true and then
double-check to be sure).
> Does rsyslogd have any functionaly to rewrite log entries as they go
past?
>
> Given that these messages are forwarded upstream (and therefore the
FQDN matters), I am assuming the template functionality is no going to
work for us?
From what I understand, templates are used to control the format for
output. When forwarding messages, that is considered output so templates
are available to modify the outgoing content to suit your needs.
Other may have better advice, but here is what I would attempt:
For example, take the standard forwarding template ("ForwardFormat",
RFC3164):
template(name="ForwardFormat" type="list") {
constant(value="<")
property(name="pri")
constant(value=">")
property(name="timestamp" dateFormat="rfc3339")
constant(value=" ")
property(name="hostname")
constant(value=" ")
property(name="syslogtag" position.from="1" position.to="32")
property(name="msg" spifno1stsp="on" )
property(name="msg")
}
Here the hostname property is being referenced. You could hard-code a
value to use in its place (in which case property(name="hostname") would
become constant(value="MyIntendedNameHere")) or reference a local
variable or JSON message property built elsewhere in your configuration.
You'd then apply this template to your outgoing/forwarded messages.
Note:
Some of my earlier response alluded to %HOSTNAME% containing values
based on DNS-lookups. I mentally mixed up %HOSTNAME% and %FROMHOST% when
I responded.
My remarks regarding a lookup table are still relevant if you're dealing
with systems that provide unreliable data in the hostname field of
generated messages and need to override the provided value with stable
values that you define.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
