Versions Compared

Old Version 1

changes.mady.by.user Former user

Saved on

compared with

New Version 2

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Log Levels

The levels to be used are described in the following table, in order of decreasing verbosity and increasing severity.

Level

Description

PRI_ DEBUG

Developer message messages needed only when debugging code. May include recording of such things as entry and exit from methods
or internal branch tracking. Should
This level should never be required by end users.

PRI_ INFO

Informational message used to trace system inputs and actions. Significant actions in the execution of some activity;
for example, the receipt of a message or an important decision in its disposition.
This level should be sufficient for an administrator or support person to determine what occured in the system when debugging a configuration or interoperability problem in the field.

PRI_ NOTICE

Normal but significant events. Events that are expected but provide important context, such as service restarts and reloading configuration files.
This is the default logging level, and generally logging should always include at least these messages.

PRI_ WARNING

Conditions that imply that some failure is possible, but not certain. Generally, external inputs that are not as expected and possibly invalid. Especially useful in low level routines that are going to return an error that may be recoverable by the caller.

PRI_ ERR

An unexpected condition likely to cause an end-user visibile visible failure.
This level should be used whenever an error response is being sent outside the system to provide a record of the internal data that are important to understanding it.

PRI_ CRIT

Endangers service operation beyond the current operation.
MUST be logged prior to any 'assert', or when exiting for any abnormal reason.

PRI_ ALERT

Fault to be communicated to operations.
Should be replaced by usage of the new Alarm subsystem.

PRI_ EMERG

System is unusable.

...

Should be replaced with CRIT.

Log Formats

Log files should be written so that each log entry follows these rules:

  • Log entries are only text data. UTF-8 is allowed, ASCII is preferred, binary data is forbidden.
  • Never log any security-critical values (passwords, keys, system secrets)
  • The beginning of the entry must be an ISO format date/time stamp inside double quotes to six decimal places, followed by a colon. If the available time precision is less than six decimal places, pad with zeros. The timestamp must be in Universal Time (UTC) not local system time. Using this prefix allows cutting timeslices out of logs, and doing sort/merge operations on them.
    Panel

    "yyyy-mm-ddThh:MM:ss.ffffffZ":

  • An entry is a single line of text. Newline characters, backslash, and double quotes in the log text must be escaped by preceding them with a backslash.

Libraries

Code written for the sipXecs project should use logging libraries from the project: the OsSysLog class (in sipXportLib) for C++, and the TBD class (in sipXcommons) for Java.

Where possible