Front-end observability configuration

[mcollovati]

There should be a way for the end user to decide what kind of instrumentation should be enabled on the front-end, to prevent huge amounts of data from being collected and to reduce network traffic.

Every supported instrumentation may have specific configurations (for example UserInteraction by default only traces click events, but it can be configured to trace additional events), but as a first step, it may be enough to be able to enable/disable one of the known instrumentation.

Front-end observability settings should be probably configured along with the other Vaadin configurations (e.g. system properties, servlet init parameters, application.properties file, ...) and accessible through the ApplicationConfiguration interface. Settings can then be provided to the ObservabilityClient custom element, and used to register wanted instrumentation modules.

As a side task, it can be investigated if there is any good way to be able to change the configuration at runtime.

[mcollovati]

@tarekoraby, could you please check if there's something to add or change in the above description?

[tarekoraby]

There should be a way for the end user to decide what kind of instrumentation should be enabled on the front-end

I'd say not only what kind of instrumentation, but it should also be possible to prevent client-side instrumentation completely for a certain subset of users.

As a side task, it can be investigated if there is any good way to be able to change the configuration at runtime.

To my mind, this is the main task. We should enable developers to change the configuration (or completely disable frontend o11y for some subset of users) at runtime. To my mind, the only thing that could be statically configurable in application.properties is whether frontend o11y would be disabled for all users. But that would be an extra thing to do as a convenience API since the developer should be able to specify in code not to send the client-side instrumentation to any client.

@Legioth, what do you think?

[Legioth]

I'm also leaning towards the idea of primarily making it possible for application code to define what to collect in any given situation and then as a secondary feature providing shorthands for common configuration alternatives through e.g. application.properties..

[mcollovati]

The simplest way to configure front-end observability at runtime may be to add flags and properties to the ObservabilityClient component and then provide an ObservabilityConfigurer interface with a single configure(ObservabilityClient) method that developers can implement with custom logic. Lookup can be used to get the implementation, so it could be registered according to ServiceLoader specification or, for Spring/CDI project, by providing a bean. Developers should have access to the Vaadin request, since the implementation will be invoked inside an UIInitListener; we may also consider adding VaadinRequest directly to the method signature.

A drawback of this approach is that we provide direct access to the ObservabilityClient component, and a developer can then use Element APIs to do whatever he wants.

To avoid the developer manipulating ObservabilityClient, we may instead create a ObservabilityConfiguration class to activate and configure instrumentation. But this may a bit an overengineered design.

interface ObservabilityClientConfiguration {
    ObservabilityClientConfiguration disable();
    ObservabilityClientConfiguration traceDocumentLoad();
    ObservabilityClientConfiguration traceUserInteraction(String... events);
    ObservabilityClientConfiguration traceLongTasks();
    ObservabilityClientConfiguration traceXMLHttpRequests(String... ignoreUrls);
}

[tarekoraby]

Why should we care if the developer manipulates ObservabilityClient?

[mcollovati]

Why should we care if the developer manipulates ObservabilityClient?

Effectively, probably we should not. In addition, the developer can already get the ObservabilityClient from the UI programmatically, so my concern does not make any sense

[Legioth]

We should give the developer a meaningful API. I see the existence of ObservabilityClient as an implementation detail. If it extends from Component, then it will have methods like getElement or addClassName that don't make any sense from the point of view of configuring observability.

We can still provide access to the implementation detail to allow people to do workarounds but I don't think it makes sense to have it as the primary API.

[mcollovati]

So, it could be a mix of both: a ObservabilityClientConfiguration interface to toggle settings and having the ObservabilityClient implementing it to directly transfer information as component properties,