Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

Log Level Guidelines

pervazea edited this page Aug 10, 2018 · 1 revision

When adding debug log messages to the system, please adhere to the following guidelines.

Choosing the right log level

Error

An error or failure from which the system can not recover. The system may continue to operate but failure is imminent. Immediate attention is required of the operator.

Warning

Something unexpected has been detected such as an unexpected event or configuration error. The system may continue to operate, but failure due to addition actions is possible.

Info

Information that is generally useful to the operator, e.g. system initialization complete, system shutdown requested etc.

Debug

Information for system developers. Debug information will most likely consist:

  • Potential errors. Recording data and return values associated with unexpected paths through the code.

Trace

Information allowing system developers to follow the actual execution path through the code. Tracing will generate significant volumes of output, recording normal control flow through the system.

What to log

When implementing log points, sufficient information should be included to properly understand the log message. Examples follow:

LOG_DEBUG("Index %u already exists!"...)

  • The information logged is incomplete. It is not possible to identify which operation, or alternatively to which database table the operation applies.
  • The message is logging

Better would be:

LOG_DEBUG("Index creation failed (error %d). Index %s, Table %s, Database %s exists", ...)

  • The specific error code is recorded
  • More context is recorded, in human friendly form rather than internal, numeric ids

LOG_DEBUG("Tuple count: %lu", tuple_count);

  • Possibly this should be LOG_TRACE. It is recording what appears to be a perfectly normal, routine event.

LOG_DEBUG("Added a foreign key constraint toward sink table %s",...)

  • This should probably be LOG_TRACE
  • Information should be logged about the foreign key. Which key cannot be determined from this message.
  • The database (holding the table) should be recorded.