Calling the Telemetry collector from a SPA

[shaunpearsondev]

I am trying to get telemetry from a react app to show up in the aspire dashboard however I am running into CORS issues

Access to XMLHttpRequest at 'http://localhost:16151/v1/traces' from origin 'https://localhost:5173' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Is there any way to configure the allowed headers so we can send browser telemetry?

[davidfowl]

It’s an interesting scenario for sure but we only support grpc endpoints which don’t work from the browser. I’d also very that most it’ll exporters support this or we might be setting you for failures in deployed environments

[samsp-msft]

It would not be rocket science to include a "proxy" api in the host application that would convert from the http form of OTLP to gRPC and send data to the configured telemetry endpoint.

What format is the react app using for its telemetry data?

[DamianEdwards]

It would not be rocket science to include a "proxy" api in the host application that would convert from the http form of OTLP to gRPC and send data to the configured telemetry endpoint.

If by "host application" you mean the AppHost, wouldn't that lead folks down a path that might not be supported by the target environment (@davidfowl's point). Or did you mean in the ASP.NET Core app "hosting" the SPA?

[samsp-msft]

Whatever is hosting the SPA - so that the SPA can callback to the host and not have to worry about CORS etc. It also solves the problem of gRPC over http etc.

It could be something like app.MapReactTelemetry() the endoint would either:

• make direct OTLP calls based on the environment vars (simpler)
  or
• create its own ILogger/Metrics/ActivitySources for the "client" and translate the data it receives to those datasources. The benefit of the latter is that it would be re-emitted via the .NET OTel infra so would work with whatever telemetry backend the app dev had configured, eg Application Insights. The problem would be to distinguish the client results from the server results. To be cleanest, you would probably want 2 instances of OTel registered with DI and I don't think its designed for multiple instances like that.

[shaunpearsondev]

I have started to look into something like this using https://www.envoyproxy.io/ and https://www.npmjs.com/package/@opentelemetry/instrumentation in the SPA

I managed to get get everything hosted in the APPHost and exposing endpoints that were available as env vars

REACT => ENVOY => OTEL
Envoy - Docker
React app - EXE (https://github.com/dotnet/aspire-samples/tree/main/samples/AspireWithNode)

Envoy was receiving the data but couldnt quite get it to forward to the OTEL endpoint

Will try and get the experiment pushed to a repo if anyone is interested

[samsp-msft]

@JamesNK - what would it take to implement the OTLP/http endpoint in the dashboard? https://github.com/open-telemetry/oteps/blob/main/text/0099-otlp-http.md - its basically the same proto data, but over http/1.1 or h2? The spec says it can even be the same port, disambiguated by http header - can we do that with the standard gRPC support in ASP.NET today?

[davidfowl]

It's not something we should prioritize right now, but @shaunpearsondev please experiment and if you have time to research into what other are doing please let us know.

[wertzui]

Any news on a HTTP endpoint which will allow instrumentation of SPAs?
I'm currently migration everything to Aspire.
Everything in .Net worked just fine, but I want to instrument my Angular Application too.
I'm now at the point that I get everything injected into the Angular App, can setup everything, but I'm now blocked with the same error.

We really need a possibility to see the traces from our SPAs in Aspire to get the full "experience".

[martinjt]

The otel signals default to:

• /v1/traces
• /v1/logs
• /v1/metrics

The frontend could be producing any or all of these signals. Later there will be profiles, and other things, but they all sit under /v1 for HTTP (gRPC is obviously different).

The ingress would do nothing to the request over than routing. In this scenario, the collector can't have auth, since any kind of API key would be pointless as the client would need it, or just hitting the ingress endpoint would add it anyway. For frontend observability, it has to be open and anonymous access, otherwise you can only trace when someone has logged in.

The collector "could" be configured to have a separate receiver for frontend telemetry and backend telemetry, but that's probably beyond the scope of this right now.

[martinjt]

sidenote, if you want frontend, you can't use the ACA managed "collector", since it's not able to be made accessible outside the environment.

[JamesNK]

A publicly exposed collector creates issues around people abusing it. I think you would want to lock it down on the server so only telemetry for certain applications is accepted. For example, an allow list that allows telemetry for the browser app and rejects someone maliciously creating telemetry for a backend app. And should incoming requests require a session key in the cookie or header that the site generates?

There are probably solutions to make this work well, Google Analytics has been around for decades. But I wonder if ingress + collector be hardened enough to make it a secure option?

[wertzui]

How this this handled in Azure Monitor / Application Insights?
When using the official libraries, it will directly connect to a publicly exposed endpoint using a connection string that anyone can read in their browser.

[martinjt]

In those scenarios, where a vendor exposes their backend to the Internet for clientside analytics data, they're built specific for it.

They have:

• throttling
• rate limiting
• burst protection
• behaviour analysis

They're built differently in a lot of ways to the ones where you can trust that the auth is private.

For the dashboard/backend to be public, there will be things like that to consider. It's things that the Clientside SIG in OpenTelemetry are thinking about. The answer will be collector configurations that are hardened.