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. > > I suspect your bigger problem will be devices that don't send their > timezone as part of their syslog message. up until a couple of years > ago > when they new RFC came out, the RFC for syslog said that the > timestamp did > not have a timezone, and even today, most systems don't send a > timezone in > their syslog messages. I must admit, have not started sending logs from "other" devices except for a token windows server and it looks fine. Considering the template is only breaking up the date component and not looking at time or timezone, I'm -) reasonably confidant. But I heed your warnings. > > 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. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
