
Show HN: Appdash, an open-source perf tracing suite - slimsag
https://sourcegraph.com/blog/117580140734/
======
slimsag
Hi all, my name is Stephen Gutekanst and I'm the primary developers working on
Appdash at Sourcegraph.

I'll be available throughout the rest of the day to answer questions you might
have, I'd also love to hear thoughts on how it can be adapted to fit your
needs! :)

------
shurcooL
I haven't used Appdash in any of my projects yet, but I have seen it used and
it is neat.

I'm curious how it compares against other similar solutions, can you describe
that a little? Is there anything else that's similar? What are the pros/cons
of Appdash?

~~~
slimsag
The awesome news is that all of the software I'm going to mention all uses
almost identical terminology, which originates from Google's Dapper[1].

\- Dapper itself is a closed-source and internal Google project, so you and I
can't make use of it.

\- There is something called AppNeta (previously named Tracelytics), a paid
service, I haven't ever used it but it was on HN a while back. [2]

\- Most notably is Twitter's Zipkin[3], which is what the rest of my comment
will make comparison of (but take note I haven't used Zipkin extensively, I've
only researched it).

Zipkin is written in Scala, and Appdash in Go. Depending on which you're
familiar with might make your decision between the two easier. A language you
know and love goes a long way for hacking on a project.

On a user-interface side; they're both pretty similar. I think Zipkin is
getting an aggregated data view sometime soon, but Appdash already has an
extensive one with several different viewing modes (see screenshots in [4]).

I don't know Scala too well and couldn't determine during my research how
extendable Zipkin is -- but Appdash was designed from the ground up with
interfaces providing core logic: this means you can swap out where the traces
get stored (in memory, evicted after a certain time, in a database, your own
custom implementation, etc), define your own event types with their own meta-
data associated with them (an HTTP event has headers, an SQL event has the
literal query that was run, your own type could have anything you want, etc).

Appdash has a Python support library so you can generate traces from Python
applications, too. This works because it uses Protobuf for communication. We
hope support for more languages might be contributed. IIRC Zipkin uses Apache
Thrift for communication, but doesn't officially support integration with
other languages via libraries.

A really useful feature of Appdash that I think Zipkin doesn't have is the
ability to import and export single or multiple traces as JSON from the UI.
You can literally copy+paste traces to co-workers, etc, and they can load them
up in their own Appdash instance to analyze them if they want.

Perhaps missed among all my discussion of HTTP-esque-tracing-systems is that
Appdash is really suitable for analyzing the performance of any application at
a high-level (i.e. not micro-benchmarks). If you can time something, want to
log something, or have something important with a timestamp on it -- you can
just give it to Appdash and it'll display it in a nice UI for you.

[1]
[http://research.google.com/pubs/pub36356.html](http://research.google.com/pubs/pub36356.html)

[2]
[https://news.ycombinator.com/item?id=3197490](https://news.ycombinator.com/item?id=3197490)

[3] [http://twitter.github.io/zipkin/](http://twitter.github.io/zipkin/)

[4]
[https://github.com/sourcegraph/appdash/pull/58](https://github.com/sourcegraph/appdash/pull/58)

~~~
shurcooL
Thanks for the detailed reply, that really answers my question.

