> Also, I'd prefer the log specify the time zone it thinks it's in, rather than just convert to UTC automatically.

But my computer thinks it's clock is in UTC, and it only converts to a timezone for human readable dates.

This.

UTC is not only unambiguous, but on some systems measurably faster to capture.

My experience has taught me to work in UTC everywhere possible, local time is typically only relevant for direct human interaction.

A caveat here as well is you also need to make sure your various clocks in the data center are synched. This is one of those common but overlooked scenarios which lead to hilarious discussions about latency when really there was just a clock synch problem. Additionally the fallacies of distributed computing come into play here (namely, transport cost is 0) so you need to take extra care when looking at measurements across different systems and machines. Even machines in the same data center. The pipe that you are communicating across could be oversubscribed for example.

Yes. But you get all those problems plus more, if you convert to local time first.

Thanks for the feedback. I'm with you on the milliseconds and threads bits. As for hostname / version... how are you getting those into your logs? I've found having version in the logs very useful (and wished I had it when it wasn't there).

Couldn't you output the host and version at the beginning of the log? Any tool that transforms the logs (splicing together logs from different servers) should include these bits in it's output.

Also, why don't you use a sortable form for time? (With the most significant parts first.)

My issue with host and version at the beginning of the log is that they'll roll away when your logs rotate. If you've got a service that's rarely taken down, anything written to the front of the logs is likely long gone by the time you have a problem. That said, there may be a better way to handle these two. I certainly don't like repeating information if it's not necessary.

You could just print the version, etc. again when logrotate sends your daemon a SIGHUP.

Ahh... never thought of doing that. I like it.

> I certainly don't like repeating information if it's not necessary.

On what grounds?

I don't think outputting the version is overkill at all. It's much easier and simpler to deal with it this way. Probably the nanosecond business is very much overkill, that only matters for a smaller subset of problem domains.

Whether the version is overkill depends on the frequency of version changes. If you're doing careful corporate releases with staging and QA on a two-month basis, it's definitely overkill - if you're doing continuous deployment with several releases daily and different systems running different versions concurrently, it's probably valuable.