one thing that you could do is to have a lookup table that has a time offset for
each host and then when daylight savings changes, update the table and reload
it.
unfortunantly the libc timezone routines make it _really_ hard to do anything
other than convert from the server local timzeone to GMT and back. They have the
routines internally to make it easy, but have repeatedly refused to make them
available to systems, and nobody wants to re-invent the wheel on this (it's a
maintinence nightmare as timezones are a political issue, not a technical one)
And even this gets hard when you have some logs from a machine in the local
timezone and other logs written by apps using GMT
A SEIM does not solve this, it just fakes it, sometimes with better results,
sometimes with worse results.
David Lang
On Wed, 10 Jun 2020, Mariusz Kruk via rsyslog wrote:
Date: Wed, 10 Jun 2020 15:15:11 +0200
From: Mariusz Kruk via rsyslog <[email protected]>
To: Mariusz Kruk via rsyslog <[email protected]>
Cc: Mariusz Kruk <[email protected]>
Subject: [rsyslog] Dynamic timezone?
Hello there.
I'm fighting with a very annoying issue and ran out of ideas :-)
I'm dealing with a setup in which I forward messages from multiple sources to
a single consumer (siem/log-management/whatever).
The problem is that the logs come from a variety of solutions some of which
log in local timezone and some in UTC. Some of them include timezone info in
the timestamp (and I have no problem with those) but some do not.
I convert $timereported from the message to a epoch timestamp and send it
down the stream along with the source message. If the $timereported contains
TZ info, everything works great. If it doesn't the conversion is done
according to /etc/localtime. Which would be quite OK if not for some legacy
sources reporting in UTC without advertising it in source time string.
I thought about just adding a constant offset on a per-source basis. But that
would work OK... up until next daytime saving change, so I'd chave a skew
+1->+2 or the other way around. For now it seems the most feasible solution
though.
I know it'd be best to set TZ to UTC and make the sources report in UTC but
unfortunately it's not possible.
I've been digging in the docs for last few days but I can't seem to find any
reasonable solution not involving implementing own DST logic in RainerScript
(that would be ridiculous :D).
Any pointers where to look for clues? I think I cannot set timezone
dynamicaly so that rsyslog parses data (or formats time with a given TZ
offset), right?
Best regards,
Mariusz Kruk
_______________________________________________
rsyslog mailing list
https://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.
_______________________________________________
rsyslog mailing list
https://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.
