Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[7.x] [core-docs] Edits core-intro section for the new docs system (#93540) #93629

Merged
merged 1 commit into from
Mar 4, 2021
Merged

[7.x] [core-docs] Edits core-intro section for the new docs system (#93540) #93629

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 2 additions & 16 deletions dev_docs/kibana_server_core_components.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,30 +1,16 @@
---
id: kibServerAndCoreComponents
slug: /kibana-dev-docs/core-intro
title: Core components
title: Kibana Server and Core components
summary: An introduction to the Kibana server and core components.
date: 2021-02-26
tags: ['kibana','onboarding', 'dev', 'architecture']
---

Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of.

## Integration with the "legacy" Kibana

Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it.
Kibana is started using existing "legacy" CLI that bootstraps `core` which in turn creates the "legacy" Kibana server.
At the moment `core` manages HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server
will hit HTTP server exposed by the `core` first and it will decide whether request can be solely handled by the new
platform or request should be proxied to the "legacy" Kibana. This setup allows `core` to gradually introduce any "pre-route"
processing logic, expose new routes or replace old ones handled by the "legacy" Kibana currently.

Once config has been loaded and some of its parts were validated by the `core` it's passed to the "legacy" Kibana where
it will be additionally validated so that we can make config validation stricter with the new config validation system.
Even though the new validation system provided by the `core` is also based on Joi internally it is complemented with custom
rules tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that config values that were previously accepted
by the "legacy" Kibana may be rejected by the `core` now.

### Logging
`core` has its own <DocLink id="kibCoreLogging" text="logging system"/> 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.

<DocBadgeComingSoon tipTitle="Other core components" tipContent="I will be content on the other components offered by core">Other components</DocBadgeComingSoon>