[EBT] Collect console errors

[afharo]

On the browser side, we'd like to collect the error messages printed in the browser's console.

Note: It may include the events from #140932, so that other issue might not be relevant.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

It may include the events from #140932, so that other issue might not be relevant.

That was my first question 😅

What's the difference between this issue and #140932?

What are 'console errors'? Isn't that precisely uncaught errors and/or unhandled promise rejections? Do you see anything else here?

[afharo]

These might also include actively logged errors via console.error (there are quite a few in Kibana).

[lukeelmers]

Totally agree having this data would be helpful, but curious how if you see this or #140932 relating to the proposal for a browser logging service?

For errors on the server, we don't really need EBT because we already have our server logs which can be analyzed at a large scale via the cloud overview cluster. If we ended up building a browser logging service that shipped logs to the server, we could potentially achieve the same thing (depending on how it was implemented).

So I'm wondering how we should be thinking about the role of EBT in collecting browser console logs vs an official browser logging service. Do we need both, or is one or the other preferable?

[pgayvallet]

These might also include actively logged errors via console.error

++ for focusing on developing the client-side logging service and then collecting such errors from here (Also I'm not sure there's a way to hook into console.error usages that doesn't imply ugly monkey-patching?)

[afharo]

++ to the browser logging service: I think it'll unlock this and other needs we currently have.

It will make it much easier to hook events to that (wether we decide to ship them to the telemetry services or the server, that's up to us) :)

[pgayvallet]

The browser-side logger was implemented in #144107, which may unblock this issue