github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-06-28 03:01:21 -04:00
Code Issues Projects Releases Packages Wiki Activity

Converts logging README format to be compatible with new docs system (#91958)

Browse source 
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This commit is contained in:
Christiane (Tina) Heiligers 2021-02-22 13:14:24 -07:00 • committed by GitHub
parent 581a8862ea
commit a2be28019c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 55 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

2
dev_docs/kibana_platform_plugin_intro.mdx
View file

@ -69,7 +69,7 @@ We will continue to focus on adding clarity around these types of services and w
### Core services
Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
routing, application registration, and notifications. The Core platform is not a plugin itself, although
routing, application registration, notifications and <DocLink id="kibCoreLogging" text="logging"/>. The Core platform is not a plugin itself, although
there are some plugins that provide platform functionality. We call these <DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>.
### Platform plugins

2
src/core/README.md
View file

@ -29,7 +29,7 @@ rules tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that
by the "legacy" Kibana may be rejected by the `core` now.
### Logging
`core` has its own [logging system](./server/logging/README.md) and will output log records directly (e.g. to file or terminal) when configured. When no
`core` has its own [logging system](./server/logging/README.mdx) and will output log records directly (e.g. to file or terminal) when configured. When no
specific configuration is provided, logs are forwarded to the "legacy" Kibana so that they look the same as the rest of the
log records throughout Kibana.

15
src/core/server/logging/README.md → src/core/server/logging/README.mdx
View file

@ -1,3 +1,13 @@
---
id: kibCoreLogging
slug: /kibana-dev-docs/services/logging
title: Logging system
image: https://source.unsplash.com/400x175/?Logging
summary: Core logging contains the system and service for Kibana logs.
date: 2020-12-02
tags: ['kibana','dev', 'contributor', 'api docs']
---
# Logging
- [Loggers, Appenders and Layouts](#loggers-appenders-and-layouts)
- [Logger hierarchy](#logger-hierarchy)
@ -43,7 +53,8 @@ fully configured.
Developer can configure _log level_ and _appenders_ that should be used within particular context name. 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
__Note:__
In the current implementation log messages are only forwarded to appenders configured for a particular logger
context name 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`.
@ -51,7 +62,9 @@ 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.