opentracing/opentracing-javascript

How do I trace requests from the browser?

gioragutt opened this issue · 4 comments

gioragutt commented

I'm writing here because I've looked at most of the available options, and want to make sure I don't miss anything before I start implementing stuff on my own.

We use jaeger for tracing, and I've done all the work on the backend to write traces to jaeger.

Problem is I want the traces to start in the client side, and I can't seem to make anything work. I'm trying methods for both jaeger and zipkin since jaeger has translation layer for zipkin.

Jaeger

  • The "official" browser bindings don't really exist, they're WIP, and work on them stopped long ago.
  • I've looked into open-telemetry, and the jaeger exporter needs stuff from node to work, making it impossible to use in the browser.

Zipkin

  • I've tried using the zipkin-js lib, but it too wants stuff from node (node-fetch and os to name what my webpack shouts at me).
  • Like with jaeger, the zipkin open telemetry exporter also requires stuff from node.

Is there any working way to trace with jaeger/zipkin from a browser?

Currently as I see, my options are to implement some kind of proxy myself, or to use the OpenTelemetry Collector.

Would appreciate help 🙏🏻

paprickar commented

Hey @gioragutt

I am stuck with the same question I would be very happy if you could share your findings or how you decided to move forward.

austinlparker commented

My 0.02 would be to use opentelemetry-web and proxy OTLP to jaeger via an OpenTelemetry Collector.

gioragutt commented

Hey guys, I've come to use zipkin-javascript-opentracing, and configured jaeger, and my backend services, to accept the zipkin format.

I'll explain more once Bayren finishes raping Barcelona 🤦🏻‍♂️

gioragutt commented

So, I'm not in front of source code, but I might as well share.

What I ended up doing was using zipkin-javascript-opentracing. The typing provided in @types is pretty awful, so I had to write my own in a .d.ts.

My goal is to write a library for angular, which would work with the built in HttpClient and the HttpInterceptor middleware infrastructure to make tracing automatic, and allow whatever means of customization needed.

Since I end up sending zipkin headers, I had to change my backend tracing library to accept zipkin headers.

I'm using Java, so it was pretty easy. All I had to do was make my initialization code use Configuration.fromEnv() to initialize the Tracer, and this in turn allowed me to use the JAEGER_PROPAGATION environment variable.

It took some time to get things to work, considering zipkin-javascript-opentracing doesn't follow the opentracing Tracer api completely, but things end up working... well, good enough.

I would definitely prefer having native bindings for jaeger, since it would work out of the box, and follow all the best practices.

Another caveat that I noticed and is worth mentioning - I'm not sure if it's the zipkin format not supporting logs, or just zipkin-javascript-opentracing, but all the things I log end up becoming tags when viewed in the jaeger ui.

@austinlparker I'm not really aware of all the details of opentelemetry, just like really high-level stuff, but it might be a good solution. Regardless, setting up Opentelemetry is also an operational overhead, which is not my to carry (but of the DevOps team). I provided the simplest solution I could find, which would contain as little hacks as possible.

If the need will rise to improve the tracing, my successors (considering I'll be leaving the company soon), will hopefully be able to carry out the changes.