Frontend O11y / APM mapping: Allow overriding the service name through the Faro SDK

[cedricziel]

Description

As a user of Frontend O11y and Application O11y in Grafana Cloud, i would like to override the service name
for a subset of telemetry as the user progresses through the UX.

Example:

• User lands on the login page, the telemetry should be mapped to the login service
• User progresses through the app, goes to checkout, the associated telemetry should be associated with the checkout service
• User manages their newsletter preferences, associated telemetry should be tagged with the profile service name

The override should be persisted in the user session to allow maximum flexibility.

Proposed solution

Leverage the setView API and allow to override the context.

Example:

setView('login', {'service_override': 'login'});

# all telemety generated herafter, will be transmitted with a service_override meta that the cloud receiver can use

setView('checkout', {'service_override': 'checkout'});

Context

[Catchpowle]

@cedricziel I think this would work great for us, but could I just clarify that this would apply both to the Span created when using the Tracing Instrumentation with Faro and the standard session-related logs, such as errors?

My only other thought was whether you'd want to provide a more generic solution for adding/overriding attributes as part of this API, but for us, I think this would be enough as it is.

If we wanted to add/update more attributes, they'd likely be to add info such as the name of the owning team, which can be derived by knowing the service name anyway. Therefore, having a service_override meta set here would mean we'd be able to make use of it in the onBeforeSend hook for any other service-related attribute modification we might want, as far as I understand. 🙂

[cedricziel]

I think this would work great for us, but could I just clarify that this would apply both to the Span created when using the Tracing Instrumentation with Faro and the standard session-related logs, such as errors?

The traces will have the updated service.name attribute, yes. We should probably think about enabling overrides for service.namespace and service.version as well.

In my book the conversion here would be done by us in cloud (overriding the service.name attribute) and it would apply to all signals produced after the sdk method call.

[cedricziel]

Therefore, having a service_override meta set here would mean we'd be able to make use of it in the onBeforeSend hook for any other service-related attribute modification we might want, as far as I understand. 🙂

Yes - you can use that hook to inspect the full structure and make decisions based on it

[Catchpowle]

@cedricziel This all sounds good, thank you for prioritising it!