Skip to content

Latest commit

 

History

History
43 lines (32 loc) · 4.05 KB

LOGGING.md

File metadata and controls

43 lines (32 loc) · 4.05 KB
Raw

DecaLog have the ability to log WordPress events.

It can log events to fill an events log, to record a crash report, to send an alert or to allow debugging in console.

Whatever the destination of the event, the process is always the same: DecaLog will first capture events generated by the core of WordPress and themes / plugins; it will then enrich these events with many details regarding their triggering before passing them to loggers. At this point, it is the responsibility of each logger that receives an event to record it - with its own level of detail - or to discard it.

Anatomy of an event

An event is mainly composed of:

  • A channel, which is the type of "execution pipe" that triggered the event. It can take the following values: CLI (command-line interface), CRON (cron job), AJAX (Ajax request), XMLRPC (XML-RPC request), API (Rest API request), FEED (Atom/RDF/RSS feed), WBACK (site backend), WFRONT (site frontend).
  • A level, which represents the severity of the event. This level is set by the listener, regarding what triggered the event. It can take the following values (from the lowest severity to the highest severity): DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
  • A timestamp, which is the time when event was triggered.
  • A versioned source, which is the component or the subsystem where the event is triggered. It may be things like PHP/7.2 or WordPress/5.2.2 and so on...
  • The class of the source, which can take the following values: core, plugin, theme, library, db, php.
  • A message in plain text. It is always in English: messages are not localized.
  • A numerical code, which may be everything which makes sense regarding the event (an error code, for instance).

Depending on each loggers type or settings, an event may contain many other fields which are automatically detected and filled by DecaLog. For example, an event may contain a trace ID, a user name, etc.

Conventions

An event respects some rules and adheres to some standards:

Levels

In order to be similar to other log management systems and to maintain consistency between all the DecaLog listeners, the levels are used as follows:

  • DEBUG - Only used for events related to application/system debugging. Must not concern standard, important or critical events. Ex.: "Plugin table xxx updated.", "Textdomain yyy loaded.".
  • INFO - Simple informational messages which can be forgotten. Ex.: "User xxx is logged-out.", "New comment on post yyy.".
  • NOTICE - Normal but significant conditions. Ex.: "The configuration of plugin xxx was modified.", "The database is 70% full.".
  • WARNING - A significant condition indicating a situation that may lead to an error if recurring or if no action is taken. Ex.: "Page not found.", "Comment flood triggered.".
  • ERROR - Minor operating error which requires investigation and preventive treatment. Ex.: "The file could not be opened.", "The feature could not be loaded.".
  • CRITICAL - Operating error which requires investigation and corrective treatment. Ex.: "Uncaught Exception!", "Database error in query xxx.".
  • ALERT - Major operating error which requires immediate corrective treatment. Ex.: "The WordPress database is corrupted.".
  • EMERGENCY - A panic condition (unusable system). Ex.: "The WordPress database is down.", "Parse error: syntax error, unexpected 'if' (T_IF).".

Codes

If the event relate to a HTTP condition, the code should be, as much as possible, the HTTP response code.

The code 0 means: "unknown", "not significant" or "not an error".

Messages

The first 30-40 characters of the message allow the user to understand, at a glance, what the message is.

Typical events sent by DecaLog and visualized in Datadog

Typical events sent by DecaLog and visualized in Datadog