[Meta] Logging in the new platform

[kimjoar]

In the new platform we want to make some improvement to logging in Kibana.

First of, we don't want it coupled to the server object like we do today, but to be a separate core "service/feature".

We also want to explore how the logger is configured. Today we have silent, quite, verbose, but I think we should explore something that looks more similar to the ES approach where you specify the log level. (In ES you can also specify log-level per context/namespace, which could be interesting to explore. This might solve the downgrade functionality we have today too.)

It's essential that the logger has no global state. We want no parts of core Kibana to have global state.

We want namespaced loggers, e.g.

const log = logger.get('plugins', 'security');
log.info('hello world');

The logger needs to be (re-)configurable at runtime. And when the config changes I think we shouldn't have to .get a new logger. It's easy to build an api that just changes the logging config internally but still keeps the same ref externally. (I think going the observable route here over-complicates the logging api.)

How do we handle the logger before we've loaded the Kibana config? Do we have a separate config file like ES has, or do we keep logs in memory and then when we've loaded the config and applied the settings we replay the logs? (If loading config fails we can log to stderr or something like that?)

In my PoC I explored having a test helper that collects all logs, so you can snapshot test the log output from running some functionality. (Look at logger in HttpService.test.ts to see how it's used, and an example snapshot). I think this is a very interesting feature in certain locations where the log output itself is part of a feature, like deprecations etc.

Open questions:

• Should we handle log rotation? What does ES do here?
• Multiple transports? e.g. logging to console vs file vs http. What do we need and what do we recommend using Beats for?

(I half-way built a PoC that explores some of this in https://github.com/elastic/kibana/tree/new-platform/platform/logger that can be used for further exploration)

Tasks:

• During transition period logging format should be identical to the one in the current Kibana During transition period logging format should be identical to the one in the current Kibana #13412
• File-based logging should support rotation File-based logging should support rotation #13059
• Log request, response and ops data Log HTTP requests, responses #13241
• Logging should support JSON output Logging should support JSON output #12941
• Improve the way we handle default root logger Improve the way we handle default root logger #13098
• Replace :: logger context separator with more commonly used . Replace :: logger context separator with more commonly used . #13105

[uboness]

Should we handle log rotation? What does ES do here?

absolutely! we should minimize our ask from users to configure to configure/define/run additional services/processes aside of our products to make them production ready. Simply align with how ES's logic here (implementation wise, I believe log4j is responsible for the rotation in ES)

Multiple transports? e.g. logging to console vs file vs http. What do we need and what do we recommend using Beats for?

align with ES here. we should at least have console & file. As for shipping the logs elsewhere (e.g. ES) we need to align it across the stack - we can potentially use file beat to ship the logs and if we do this we'll do it in both ES and Kibana (and LS).

as far as alignment is concerned... it'd be great to also align the message formatting across the products... they should all feel the same.

[kimjoar]

++ great input, @uboness

[kiju98]

Hi, I have a customer who wants the non-JSON output to have date as well as time. Currently we have date in the JSON output only. Will the new logging platform support it?

[azasypkin]

Hi @kiju98,

Yes, default logging format for the new platform includes full date (like in Elasticsearch), e.g.:

[2012-02-01T00:00:00.000Z][DEBUG][context-4] message-4

But since new logging format is a breaking change we aren't sure yet when we'll be able to switch to it.

[kimjoar]

Closing, as we're now tracking the rest in separate issues.