On Thu, 24 Nov 2011, Alexandre Chapellon wrote:
I quickly read the rfc3164 and found this:" ... For implementers that do choose to construct syslog messages with the RECOMMENDED format, the following guidance is offered. If the originally formed message has a TIMESTAMP in the HEADER part, then it SHOULD be the local time of the device within its timezone... "So I guess the timezone of the device is not store in the syslog message by itself. Right?
correct.
Is there a way to include the local timezonein the header? or at least in the message? (I would really prefer in the header)
you can't do it with the RFC3164 format, I belive that the latest RFC does have a timestamp format that includes the timezone, but I don't think that it's a good idea to use local time in any case.
I think you are far better off running your servers (and the timestamps on the logs) on UTC. This not only avoids the problems of "where is this server located, so what time zone is it in", but it also doesn't have daylight savings time changes (with all the related problems of jobs running multiple times or not at all)
When my company first setup servers across the country, I raised a fuss against running them on the local timezone and instead we ran all servers on the timezone of our first datacenter. 13 years later the company still hasn't changed this and twice a year there is a special maintinance to make sure that all products that have been deployed work properly after the timezone changes. Several years ago the Security systems (which I moved on to manage) all got changed to run UTC, initially as an accident (a new OS upgrade didn't set the timezone), and I have seen the side-by-side comparison, it works _MUCH_ better to have the systems on UTC. I've found that the problem of 'midnight' being either 4pm or 5pm pacific time just really doesn't matter.
David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/
