b24fdf5d3f
## Summary This PR is part of the Kibana Sustainable Architecture effort. The goal is to start categorising Kibana packages into _generic platform_ (`group: "platform"`) vs _solution-specific_. ``` group?: 'search' | 'security' | 'observability' | 'platform' visibility?: 'private' | 'shared' ``` Uncategorised modules are considered to be `group: 'common', visibility: 'shared'` by default. We want to prevent code from solution A to depend on code from solution B. Thus, the rules are pretty simple: * Modules can only depend on: * Modules in the same group * OR modules with 'shared' visibility * Modules in `'observability', 'security', 'search'` groups are mandatorily `visibility: "private"`. Long term, the goal is to re-organise packages into dedicated folders, e.g.: ``` x-pack/platform/plugins/private x-pack/observability/packages ``` For this first wave, we have categorised packages that seem "straightforward": * Any packages that have: * at least one dependant module * all dependants belong to the same group * Categorise all Core packages: * `@kbn/core-...-internal` => _platform/private_ * everything else => _platform/shared_ * Categorise as _platform/shared_ those packages that: * Have at least one dependant in the _platform_ group. * Don't have any `devOnly: true` dependants. ### What we ask from you, as CODEOWNERS of the _package manifests_, is that you confirm that the categorisation is correct: * `group: "platform", visibility: "private"` if it's a package that should only be used from platform code, not from any solution code. It will be loaded systematically in all serverless flavors, but solution plugins and packages won't be able to `import` from it. * `group: "platform", visibility: "shared"` if it's a package that can be consumed by both platform and solutions code. It will be loaded systematically in all serverless flavors, and anybody can import / use code from it. * `group: "observability" | "security" | "search", visibility: "private"` if it's a package that is intented to be used exclusively from a given solution. It won't be accessible nor loaded from other solutions nor platform code. Please refer to [#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E) for any related questions. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| src | ||
| index.ts | ||
| jest.config.js | ||
| kibana.jsonc | ||
| package.json | ||
| 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.