Live data from Hacker News

Jaeger – A Distributed Tracing System

github.com

51–60 of 66 posts

Re: Jaeger – A Distributed Tracing System

#51
post #48

Earlier quoted context omitted.

I see Zipkin is a Java app, without sounding like I’m hating on a language for no reason here - but I wonder if it’s awfully heavy and slow to launch like so most other java apps? By comparison I’d expect a tracer written in Go would be significantly more efficient.

Does slow startup time matter for services that are supposed to be running continuously in a cluster environment? I have no doubt that a Go tracer would start orders of magnitudes faster than a Java one (especially if it pulls in spring or other web-related dependencies for the zipkin UI) but I think it is irrelevant.

Java/Maven/Gradle built applications don't pull in dependencies at startup time, they pull them in at build time.

While the JVM takes relatively long to boot up, I have various Spring Boot applications in production that startup in as much as 4 seconds, usually below 20 seconds

Java isn't as slow as people think anymore, especially since Java 7.

Also, Java remains a language running Java bytecode in a Virtual Machine, not a language running machine code... This obviously makes it very powerful and portable, yet a bit slower than C, C++ or Go.

Re: Jaeger – A Distributed Tracing System

#52
post #3

I've been using Jaeger for a few months now and it performs really well. I even wrote a custom tracer for an unsupported language and it was relatively straight forward. There are a few things I wish it did, but they are all on the roadmap: http://jaeger.readthedocs.io/en/latest/roadmap/

Can you share that custom tracer? I'd be interested in seeing that.

Re: Jaeger – A Distributed Tracing System

#53
post #5

I don't like the name. For those who don't know german, Jaeger is "Jäger" is hunter/ranger. A somewhat neutral term in itself but there is also a slight, somewhat remote connection towards some part of the history ("Jagdstaffel" and what not). I have absolutely no idea if this has anything to do with it, mind you - but since the main authors appear to be in the USA, I find that very awkward. Why not just stick to som…

Totally should have gone with meister for the name instead.

which means "master" in English and then you end up in the master/slave discussion...

Re: Jaeger – A Distributed Tracing System

#54

Earlier quoted context omitted.

Yes, OpenTracing is an API, with bindings currently available in 9 languages. Please take a look. http://opentracing.io/

Only the semantics and libraries implementing them are there. The wire format is not specified, which is a pretty annoying problem to deal with.

There are discussions about it happening. If you haven't yet, join the community and make your opinion heard :)

Re: Jaeger – A Distributed Tracing System

#55
post #4

Neat! I was looking into tracing solutions for our k8s cluster the other day and was going to look into setting up Zipkin. Now I'll this to my list of tools to evaluate. I found this blog post by uber informative https://eng.uber.com/distributed-tracing/ so maybe there is no need to even setting up Zipkin and just start with Jaegar?

If you want to trace applications deployed on Kubernetes, you might benefit from Jaeger's Kubernetes templates: https://github.com/jaegertracing/jaeger-kubernetes

Re: Jaeger – A Distributed Tracing System

#56

How is this different from e.g. AppDynamics or Dynatrace for example? Technically speaking, not free/commercial. From the documentation it doesn't look like much, except probably the biggest downside is that you have to add your instrumentation points manually? i.e. there is code change required.

Jaeger is just the concrete implementation. OpenTracing is what you should think about using when writing your application. That said, you could benefit from automatic instrumentation via OpenTracing framework integration libraries (JAX-RS, Servlets, ...). Or use the Java Agent. But in the end, I think there is value in manually instrumenting your code, specially around your business transactions. This way, you can monitor your business metrics, instead of "http requests" or "cpu load".

Re: Jaeger – A Distributed Tracing System

#57
post #14

I'm disappointed that all of the open-source tracing systems have adopted the Dapper [0] model. It's understandable why: it's extremely simple to implement, as it handles scaling challenges by doing client-side sampling. A bit of background about how Dapper-style distributed tracing works. Things typically start with an RPC call of some kind (typically from an external source like a public load balancer). At that poi…

This might be interesting to you:

https://github.com/jaegertracing/jaeger/issues/425

The Dapper model is interesting, but Jaeger is not 100% based on that.

Re: Jaeger – A Distributed Tracing System

#58
post #2

I recently used Jaeger to visualize what my distributed system is doing. Got it done in about 2 hours; pretty pleased with that. Jaeger is visually pleasing, available via docker and just worked for me.

Would you be interested in writing a guest blog post about it?

Re: Jaeger – A Distributed Tracing System

#59
post #3

I've been using Jaeger for a few months now and it performs really well. I even wrote a custom tracer for an unsupported language and it was relatively straight forward. There are a few things I wish it did, but they are all on the roadmap: http://jaeger.readthedocs.io/en/latest/roadmap/

If you are interested in contributing it to the jaegertracing GitHub repository, I'm sure the Jaeger community would welcome it :)

Re: Jaeger – A Distributed Tracing System

#60

Earlier quoted context omitted.

Yes, OpenTracing is an API, with bindings currently available in 9 languages. Please take a look. http://opentracing.io/

Only the semantics and libraries implementing them are there. The wire format is not specified, which is a pretty annoying problem to deal with.

It's weird for most people. We're used to cross-language wire protocols. OpenTracing is different.

An analogy is SLF4J for Java logging. All libraries, etc use the same interface and the final user determines the backend: java.util, Logback. This makes sense if you have many authors of libraries with a cross-cutting concern.

This really makes OpenTracing half a dozen different standards, one per language, with common semantics.

Should it be about a wire protocol instead? Discussion at https://github.com/opentracing/specification/issues/34

Post reply on HN