kibana/packages/kbn-logging
Tiago Costa 0eeaafa722
chore(NA): move into single pkg json (#80015)
* chore(NA): update gitignore to include first changes from moving into a single package.json

* chore(NA): update gitignore

* chore(NA): move all the dependencies into the single package.json and apply changes to bootstrap

* chore(NA): fix types problems after the single package json

* chore(NA): include code to find the dependencies used across the code

* chore(NA): introduce pure lockfile for install dependencies on build

* chore(NA): update clean task to not delete anything from xpack node_modules

* chore(NA): update gitignore to remove development temporary rules

* chore(NA): update notice file

* chore(NA): update jest snapshots

* chore(NA): fix whitelisted licenses to include a new specify form of an already included one

* chore(NA): remove check lockfile symlinks from child projects

* chore(NA): fix eslint and add missing declared deps on single pkg json

* chore(NA): correctly update notice

* chore(NA): fix failing jest test for storyshots.test.tsx

* chore(NA): fix cypress multi reporter path

* chore(NA): fix Project tests check

* chore(NA): fix problem with logic to detect used dependes on oss build

* chore(NA): include correct x-pack plugins dep discovery

* chore(NA): discover entries under dynamic requires on vis_type_timelion

* chore(NA): remove canvas

* test(NA): fix jest unit tests

* chore(NA): remove double react declaration from storyshot test file

* chore(NA): try removing isOSS check

* chore(NA): support for plugin development

* chore(NA): update logic to fix unit tests and typechecking

* chore(NA): support to run npm scripts in child kbn projects across all envs

* chore(NA): support github checks reporter on x-pack and remove cpy types as the package correctly provides them

* chore(NA): update cpy version

* chore(NA): include last kbn pm changes

* chore(NA): update style on build_production_projects.ts

* chore(NA): remove any cast fom telemetry opt in stats

* chore(NA): remove del and re-use rm -rf again

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
2020-11-02 21:18:52 +00:00
..
src
package.json chore(NA): move into single pkg json (#80015) 2020-11-02 21:18:52 +00:00
README.md
tsconfig.json

kbn-logging

Base types for the kibana platform logging system.

Note that this package currently only contains logging types. The only concrete implementation is still in core for now.

The way logging works in Kibana is inspired by log4j 2 logging framework used by Elasticsearch. The main idea is to have consistent logging behaviour (configuration, log format etc.) across the entire Elastic Stack where possible.

Loggers, Appenders and Layouts

Kibana logging system has three main components: loggers, appenders and layouts. These components allow us to log messages according to message type and level, and to control how these messages are formatted and where the final logs will be displayed or stored.

Loggers define what logging settings should be applied at the particular context.

Appenders define where log messages are displayed (eg. stdout or console) and stored (eg. file on the disk).

Layouts define how log messages are formatted and what type of information they include.

Logger hierarchy

Every logger has its unique name or context that follows hierarchical naming rule. The logger is considered to be an ancestor of another logger if its name followed by a . is a prefix of the descendant logger name. For example logger with a.b context is an ancestor of logger with a.b.c context. All top-level loggers are descendants of special logger with root context that resides at the top of the logger hierarchy. This logger always exists and fully configured.

Developer can configure log level and appenders that should be used within particular context. If logger configuration specifies only log level then appenders configuration will be inherited from the ancestor logger.

Note: in the current implementation log messages are only forwarded to appenders configured for a particular logger context or to appenders of the closest ancestor if current logger doesn't have any appenders configured. That means that we don't support so called appender additivity when log messages are forwarded to every distinct appender within ancestor chain including root.

Log level

Currently we support the following log levels: all, fatal, error, warn, info, debug, trace, off. Levels are ordered, so all > fatal > error > warn > info > debug > trace > off. A log record is being logged by the logger if its level is higher than or equal to the level of its logger. Otherwise, the log record is ignored.

The all and off levels can be used only in configuration and are just handy shortcuts that allow developer to log every log record or disable logging entirely for the specific context.

Layouts

Every appender should know exactly how to format log messages before they are written to the console or file on the disk. This behaviour is controlled by the layouts and configured through appender.layout configuration property for every custom appender. Currently we don't define any default layout for the custom appenders, so one should always make the choice explicitly.