On Wed, 20 Jul 2011, Rodney McKee wrote:
David,
----- Original Message -----
On Wed, 20 Jul 2011, Rodney McKee wrote:
Collecting logs from multiple timezones and rotating on a central
log server with a template like:
$template
DAILYSYSLOG,"/var/log/logdir/%$YEAR%/%$MONTH%/%$DAY%/%HOSTNAME%/messages.log"
means that logs from each timezone still get rotated at midnight on
the localhost, would something like the following work to rotate
logs for each timezones change of day
$template
TEST,"/var/log/logdir/%TIMESTAMP:1:4:date-rfc3339%/%TIMESTAMP:6:7:date-rfc3339%/%TIMESTAMP:9:10:date-rfc3339%/%HOSTNAME%/messages.log"
or would it cause other issues like excessive load etc or some
other unforeseen issue. I guess it the date format gets screwed it
could have some impact.
I would be surprised if the difference in format made much of a
difference
in load, unless you are dealing with very high traffic volumes.
I suspect once we start collecting our full application logs the traffic WILL
be high, that's a bridge yet to be crossed.
by high I am talking about tens of thousands of logs per second.
If you are getting log volumes that high, you probably don't want to use
dynafiles, no matter what the timestamp version.
At my company, we decided that the the timezone for all the servers
in the
company should be the same, no matter where in the world the system
happened to live right now. In retrospect we should have gone one
step
further and set everything to GMT to completely avoid daylight
savings
headaches. But as we've purchased competitors over the years and seen
them
with different time zones on different servers in different offices
(or
worse, different time zones on different servers in the same office,
because the people connecting to that server were expected to be in a
particular timezone), the value of keeping every system we manage on
the
same timezone setting has been shown to be a _very_ good idea.
if you want to disply different times to the users, have your
application
adjust the time (and then it can adjust it based on where the user
is, not
where the server is)
Interesting approach, comes back to good application developers in most
cases I'm sure. We see similar issues but it's sorta locked in now.
even if you have this problem now, make a big stink about the problems it
causes and get the fix on the roadmap for the next release.
if you think about it, with the Internet, what are the odds that the only
people who are hitting your server live in the same timezone that the
server happens to be in. at $work, we provide services for Credit Unions,
and even the smallest Credit Union has people who joined when they were
local, but have since moved away. These people really are happier with the
ability to set the timezone to where they live.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
