Clever Geek Handbook

Logging rules

When using the journal function, what are the general "rules of thumb"? For example.

  • A message with a rate limit of X to Y messages per time unit Z?
  • Wait for the last success message of type T before writing a "new" error message of the same type?
+2


source to share


6 answers


If you need to unsubscribe from messages, drop the irrelevant ones.

If you're showing an important message, don't bury it in the stream of irrelevant ones.

Make it very cheap to not display a message when this messaging layer is disabled / not needed.



Allows you to discover the current state of the system without having to read every old message.

Control the size of the log files (for example, multiple files instead of one infinite file), be careful about filling up the disk.

Consider using a standard output format / medium (like SNMP, <small>

or NT event log </small>

) that you can view and manage with full featured third party tools.

+1


source


I agree with Jonathon, more context would be helpful. Some things to think about:

  • Will you allow the event to happen if the event log fails? If yes, you have many more options, if not, then you need to make your log the event part of the transactional block when you save the event
  • Will the logs be flushed or are they kept for the life of the system? If so, again you have many options. If not, you want to put them in the database.
  • How much data will there be in the logs? Consider indexing and / or paging a table. Also think about how your logs are accessed. Registration event on parent instead of each child. For example, an accounting journal, with many sub-foods, lists transactions. Instead of logging into the transaction ID that was approved by the transaction, log into the log for the transaction to be approved.


These are just a few questions to think about.

+2


source


  • Print out as much context as possible on failure. Include the largest possible error message. Include the exact location in a program or workflow (for example, "input file error handling line 10029" and "error handling input file")

  • When a DB query crashes, consider a printout of the query text, well formatted (e.g. Sybase errors usually only contain partial mangles query)

  • Use a log function that has good formatting, including the ability to tag INFO / WARN / ERROR (or log message level), for convenience of grepping

  • Use a logger that has a decent timestamp.

  • As you noted, consider volume. Throttle or beam messages.

+1


source


We limit the number of duplicate messages. We use a syslog-like category and priority hierarchy and, by default, only log messages that indicate warnings and above.

If things go south, we can start logging for this component until we resolve it.

+1


source


  • Don't write down passwords!
  • If possible, try to avoid repeating the same message if the error is logged many times until the system recovers from it. Just log something like "error like x, happened n times from timestamp1 to timestamp2".
  • Don't keep your logs permanently, implement rotation policies (may be based on file sizes or time periods).
  • Use different log levels for different situations in a consistent manner.
0


source


Record enough detail about the input events that you can run the exact same sequence of events again during debug / test. However, you must use common sense. Logging every mouse move event is likely to be overkill unless you have reason to believe that the sequence of mouse move events will cause the problem.

0


source






More articles:


All Articles