[browser] Logging Service

[joshdover]

A full-featured logger in frontend code would go a long way to support debugging issues for customer support as well as any audit logging feature that we may consider in the future.

Desired features:

• Log levels
• Pluggable outputs, including the ability to push logs to the backend to be recorded by the server's log output
• Similar or identical interface to the server side logger

We should be able to largely reuse the server-side implementation of a log4j 2-like logging system that makes use of layouts and appenders to format log outputs. Indeed, the actual implementation of this system on the frontend could be as simple as a in-memory buffer that flushes these logs to the backend, delegating the appender and layout logic to the existing backend logging service. There may need to be some exceptions for this, to log to the web console, for instance.

Subtasks:

• Implement base browser-side logging system #144107
• Implement a full-feature browser-side logger #144276

[elasticmachine]

Pinging @elastic/kibana-platform

[joshdover]

@eliperelman Removed you since we're not working on this yet.

[pgayvallet]

Quick thoughts:

We should be able to largely reuse the server-side implementation of a log4j 2-like logging system

The API at least should be consistent, yes

indeed, the actual implementation of this system on the frontend could be as simple as a in-memory buffer that flushes these logs to the backend, delegating the appender and layout logic to the existing backend logging service

• I think we want actual appenders on the client side. One appender would be console which would log to the browser console, another one would be to-server, which would actually send to a specific core endpoint which would log to server logs? Or maybe being able to switch between output to console (dev/debug) or to server (prod) is enough?

• (If we choose to have actual appenders on the client-side) Not sure if we want the same granularity on appenders that we have on the backend. Maybe being able to choose between console, to-server (or other) for the whole client-side logging is enough? Or maybe we want to be able to specify per-context appenders like on the backend?

[mshustov]

Re-open, as we still need it.
Another use-case for the client-side logging system is to improve the Observability of Kibana client-side logic. At the moment, plugins do not use any debug log messages to avoid implementation details leaking outside of Kibana. Client-side logic may help Support and Dev teams to debug problems by catching more runtime details.

[pgayvallet]

imho we should start this as soon as possible. Having an initial implementation that just fallback to console (and eventually to no-op in production mode) would allow plugins to plug themselves to it. We could then change the implementation later if we want to, without changing the public API of the service.

[tsullivan]

I'm highly in favor of this. There is a standard of using the toasts service to show an error when something goes wrong, but this often does not show low-level details about the error. the addError method of the service accepts an Error object parameter, but this does not work well if the actual error object is a custom class that extends Error.

In addition to having the error toasts in the UI, it would be helpful to also log the error object in a way that can be explored better. I think we should try to build that habit.

[cjcenizal]

the addError method of the service accepts an Error object parameter, but this does not work well if the actual error object is a custom class that extends Error.

@tsullivan You might want to check out #104235 for some thoughts I've had on this subject. There are links to related issues which you might also find relevant.

[dokmic]

@elastic/kibana-core Here (#133546) is another use case for the client-side logger. We need this to help other teams find places where they use deprecated functions or wrong parameters.

Currently, we have a wrapper around the built-in console, but it would be handy to have a fully functional logger service with namespaces/scopes and with support of the logging options from kibana.yaml.

While discovering a solution, I found a couple of places in Kibana doing the same thing as we ended up implementing. My guess is that the longer we don't have a default implementation, the more technical debt we get.

[pgayvallet]

My opinion didn't change since last year:

imho we should start this as soon as possible. Having an initial implementation that just fallback to console (and eventually to no-op in production mode) would allow plugins to plug themselves to it.

@lukeelmers should we prioritize this one?

[afharo]

FWIW, here's a very basic implementation we already had to implement in a core service: https://github.com/elastic/kibana/blob/main/packages/core/analytics/core-analytics-browser-internal/src/logger.ts

[lukeelmers]

@lukeelmers should we prioritize this one?

I think it's worth trying to prioritize, even if we are only starting with a simple wrapper around console so that we can get plugins using it while we sort out our plans for the rest. I'll add it to our list to discuss.

[lukeelmers]

Discussed as a team today, and agreed we will keep the scope of this issue to the following:

• create a client-side logger interface that wraps console
• client-side interface should match what we expose on the server
• expose client side logging service via PluginInitializerContext
• for now it will just log the message to the console, probably needing to prepend the message with the logger context since we won't have layouts/appenders on the client for now
• since this will likely increase the volume of logs to the console, we'll may want to disable logs in production
  • maybe only allow logging at info/warning & above
  • consider if there's a way to measure browser log volume in CI (will check with ops team)

[pgayvallet]

#144107 introduces the base implementation as described in this comment and has been merged. #144276 has been created as follow-up for the full featured implementation.

[pgayvallet]

#144276 is the main issue to keep track of the work for the browser-side logging system now. I will close this one.