Why does the Frontend Observability docs suggest not using frontend tracing if your API is already instrumented?

Grafana Cloud
,
1

I’m implementing Grafana Cloud into our platform, and I’m at the point of setting up the Frontend Observability product for our web client and Tempo tracing for our API. I’m trying to piece together tracing, how to implement it, and I came across something I found surprising.

I noticed in the Frontend Observability docs that it says we shouldn’t use tracing in the frontend if we already have an API that is instrumented.

Do not use tracing:

  • If you don’t have a good reason to enable it.
  • If your application has an instrumented API. In this case, you can also disable only the fetch tracing instrumentation.
  • If you are not interested in tracing the user interactions, for example, clicks. In this case, you can also disable only the user interaction instrumentation.

But the Faro Web SDK docs provide a compelling reason to use tracing both in the frontend and backend:

  • Full stack tracing: Grafana Faro Web SDK can integrate with OpenTelemetry’s JavaScript library to capture frontend activity as traces and propagate tracing context to enable tight correlation with backend transactions. Combined with tracing in your service layer, it creates a big picture of the causes and the effects of user interaction in your web application and the backend services.

Can someone help me understand the first recommendation to not implement tracing in both the frontend and backend?

And also, why is telling me that “… you can also disable only the fetch tracing instrumentation”? Is it saying I can disable tracing in the frontend by disabling the fetch tracing instrumentation?

1 Like
2

Hi @Dylan123,

Thank you for your questions. I hope my answers can provide some clarity.

Can someone help me understand the first recommendation to not implement tracing in both the frontend and backend?

  1. This recommendation specifically refers to web client instrumentation and doesn’t apply to the backend.
  2. The Web-Tracing instrumentation utilizes OpenTelemetry.js under the hood, which has a substantial bundle size thus is significantly increasing the bundle size of the Web-SDK. Also this instrumentation generates data in the native otel format, which results in larger beacon payloads.

why is telling me that “… you can also disable only the fetch tracing instrumentation”? Is it saying I can disable tracing in the frontend by disabling the fetch tracing instrumentation?

  • This statement is in reference to the following suggestion: “If your application already has an instrumented API.” In this context, it means that if you have already instrumented the browser’s fetch API in a different manner. it’s advisable to disable the fetch tracing instrumentation to not unnecessarily waste client-side resources, reduce beacon payload sizes, and to prevent redundant tracking of the same data.

Cheers,
Macro

2 Likes
3

Wow, that was a really good clarification for me. Thank you!

To repeat it back and see if I’m getting it, it’s saying if frontend’s API client is already instrumented, which is specifically talking about code on the frontend, and if we’re still going to be using Faro Web SDK, that we should disable Faro’s fetch tracing instrumentation. Because then it would be double instrumented, so to speak, which is unnecessary and probably harmful.

I think I got caught up on “… your application has an instrumented API…” because from my perspective, my “application” is the both frontend and backend. And when I think of my app’s API, I think of our API that we are definitely going to be using Tempo traces with. Considering that will be instrumented, I think, why are they recommending we don’t also use traces on the frontend?

Thanks again for clearing this up for me Marco.

4

Hi @Dylan123
anytime and please keep asking questions.

To repeat it back and see if I’m getting…
Yes exactly.
In this case, when we talk about APIs, we mean the browsers APIs.
But yes I can understand that this can cause confusion. We maybe should update the wording in the docs.

One additional thing for clarification:
Faro has two different ways to instrument the fetch and xhr APIs.

  • One way is by using the Web-tracing package which uses otel under the hood
  • The other way is Faros’ own fetch and xhr instrumentation which are currently available as experimental packages. Currently these do not add a traceId to requests which will change soon. After that they will soon become stable packages.

Cheers,
Marco