The future of latency profiling in Go • Hacker News Board

Re: The future of latency profiling in Go

#11

Post by tonyhb » Tue, Jul 25, 2017, 3:13 AM UTC

mmclean wrote: post #8

PM for tracing at Google here. As the blog post mentioned, we're collaborating with partners on a common RPC context proposal for tracing systems [1]. Some of the major contributors are currently on vacation, but there'll be be another round of comments and updates once they get back. We're also working with the same partners on a project called Census - a set of tracing instrumentation libraries that all vendors can…

What's the difference between this and opentracing? AFAIK opentracing is built by the people who created Dapper at Google, and the project also has a set of standards for HTTP transport.

Re: The future of latency profiling in Go

#12

Post by dmead » Tue, Jul 25, 2017, 3:14 AM UTC

mmclean wrote: post #8

PM for tracing at Google here. As the blog post mentioned, we're collaborating with partners on a common RPC context proposal for tracing systems [1]. Some of the major contributors are currently on vacation, but there'll be be another round of comments and updates once they get back. We're also working with the same partners on a project called Census - a set of tracing instrumentation libraries that all vendors can…

not having a tool like jvisualvm frustrates me.

Re: The future of latency profiling in Go

#13

Post by mmclean » Tue, Jul 25, 2017, 5:33 AM UTC

tonyhb wrote: post #11

mmclean wrote: post #8

PM for tracing at Google here. As the blog post mentioned, we're collaborating with partners on a common RPC context proposal for tracing systems [1]. Some of the major contributors are currently on vacation, but there'll be be another round of comments and updates once they get back. We're also working with the same partners on a project called Census - a set of tracing instrumentation libraries that all vendors can…

What's the difference between this and opentracing? AFAIK opentracing is built by the people who created Dapper at Google, and the project also has a set of standards for HTTP transport.

They're different in scope and goals. Census is composed of a context propagation format (which the blog post mentioned), a single distribution of language-specific libraries that include instrumentation hooks for popular web / RPC frameworks and metrics + trace exporters for various backends, and an optional agent that you can run locally to view metrics and RPC stats.

Re: The future of latency profiling in Go

#14

Post by easytiger » Tue, Jul 25, 2017, 7:11 AM UTC

what is the latency caused by the call to trace the latency?

Re: The future of latency profiling in Go

#15

Post by jeffrand » Tue, Jul 25, 2017, 12:17 PM UTC

frik wrote: post #3

tonyhb wrote: post #2

Using Opentracing and uber's Jaeger client is awesome. It's easy to implement, and Jaeger provides multiple different mechanisms for sampling traces (always on, guaranteed throughput etc.). It's awesome to be able to see a UI giving you diagrams like this: https://www.dropbox.com/s/b2uhx77urpnuk9g/Screenshot%202017-... for your API. Definitely would recommend - it beats old-school log tracing.

Do I miss anything? OpenTracing mentions "A vendor-neutral open standard for distributed tracing." It reads like it's for implementors - is it useable stand alone + Jaeger as UI? How can it be used - can you point me to a tutorial/blog post?

Before Jaeger was out I started using this, although I'm considering switching over to using Jaeger: https://github.com/opentracing/opentracing-go

It should be pretty clear how to use it once you read through the examples.

Jaeger requires using Cassandra as a datastore (for now), which isn't easily supported at my company, so I went with Zipkin and used MySQL as a datastore.