5 ms·

time is expressed in seconds? My computer does about 3 billion things every second. I think milliseconds or preferably microseconds would be much better. Dif

time is expressed in seconds? My computer does about 3 billion things every second. I think milliseconds or preferably microseconds would be much better. Different domains have different needs, though, I'm sure. Also, I'd prefer the log specify the time zone it thinks it's in, rather than just convert to UTC automatically. pid - yes, knowing the process id is good, but knowing the thread is also useful. version - outputting this on every single log line is probably overkill. Ditto for host name.

trotter_cashion 14y ago
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).
- pydave 14y ago
  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.)
  - trotter_cashion 14y ago
    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.
    - nitrogen 14y ago
      You could just print the version, etc. again when logrotate sends your daemon a SIGHUP.
      - trotter_cashion 14y ago
        Ahh... never thought of doing that. I like it.
    - eru 14y ago
      > I certainly don't like repeating information if it's not necessary. On what grounds?
- dinkumthinkum 14y ago
  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.
  - mseebach 14y ago
    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.
eru 14y ago
> 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.
- pacaro 14y ago
  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.
  - cluda01 14y ago
    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.
    - eru 14y ago
      Yes. But you get all those problems plus more, if you convert to local time first.

trotter_cashion 14y ago

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).

pydave 14y ago
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.)
- trotter_cashion 14y ago
  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.
  - nitrogen 14y ago
    You could just print the version, etc. again when logrotate sends your daemon a SIGHUP.
    - trotter_cashion 14y ago
      Ahh... never thought of doing that. I like it.
  - eru 14y ago
    > I certainly don't like repeating information if it's not necessary. On what grounds?
dinkumthinkum 14y ago
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.
- mseebach 14y ago
  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.

eru 14y ago

> 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.

pacaro 14y ago
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.
- cluda01 14y ago
  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.
  - eru 14y ago
    Yes. But you get all those problems plus more, if you convert to local time first.