Investigate vizceral output #1416

adriancole opened this Issue Nov 22, 2016 · 5 comments


None yet

4 participants


Vizceral is a streaming aggregation tool similar to the service dependency graph we have now (but more pretty and powerful).

There've been a few look into this. I played around with it a bit, toying with a custom version of our dependency graph linker or using jq to translate stored traces. I also thought maybe this could be done online with a custom kafka or elasticsearch 5 pipeline. Or maybe something in-between, like a 1 minute interval hack of our spark job. There's also rumors of a spark alternative to normal zipkin collector (ahem @mansu ahem :) )

Here is a summary of notes last time this came up, when I chatted with @tramchamploo

so just to play with things you could use dependency linker like the zipkin-dependencies job does, except windowed into minute, not days. Use the zipkin api and GET /api/v1/traces with a timestamp and lookback of your choosing (ex 1 minute). With a custom linker, you can emit vizceral data directly or into a new index for the experiment, like zipkin-vizceral-yyyy-MM-dd-HHmm. In other words, it is like the existing spark job, but writing vizceral format and much more frequently.

To dig deeper, you'd want to some "partition" vs a "grouping" command like a groupBy, in order to group the traces into minutes.. so like before this flatMap here: This would be the thing that buckets traces into epoch minutes.

In order to get the service relationships, you need to walk the trace tree. To generate the tree you need to merge multiple documents (which consitute a trace), to tell which pieces are a client or server call. This is what the DependencyLinker does.

So basically, by bucketing offline data into 1 minute intervals (based on the root span's timestamp), you can get pretty good feedback. It will be mostly correct as traces are less duration than a minute. By using the api and a variation of our linker, you'd get a good head start which can of course be refactored later if/when a real-time ingestion pipeline exists.

mansu commented Nov 22, 2016

@adriancole We used the open source spark job to get a dependency graph and visualized it with vizceral. It was a very good visualization. But the data quality can be improved. We will try to open source this also.


I'm very interested in this. I was hoping to be able to do some of this using SQS/SNS/Kinesis for reading the data in realtime instead of doing windows from the database

tramchamploo commented Dec 26, 2016 edited

Working on integration between vizceral and zipkin. I've added a new api like /vizceral which simply query all traces in the last few seconds and use DependencyLinker to link them. Tried to set the limit to Integer.MAX_VALUE in order to retrieve traces as much as possible to get a full dependency graph. But ES won't allow that, throwing too_many_clauses: maxClauseCount is set to 1024
    at$Builder.add( ~[lucene-core-5.5.2.jar!/:5.5.2 8e5d40b22a3968df065dfc078ef81cbb031f0e4a - sarowe - 2016-06-21 11:38:23]
    at org.elasticsearch.index.query.TermsQueryParser.parse( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.index.query.QueryParseContext.parseInnerQuery( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.index.query.IndexQueryParserService.innerParse( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.index.query.IndexQueryParserService.parse( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.index.query.IndexQueryParserService.parse( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at$SearchQueryTransportHandler.messageReceived( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at$SearchQueryTransportHandler.messageReceived( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.transport.TransportRequestHandler.messageReceived( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.doRun( ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at ~[elasticsearch-2.4.1.jar!/:2.4.1]
    at java.util.concurrent.ThreadPoolExecutor.runWorker( ~[na:1.8.0_91]
    at java.util.concurrent.ThreadPoolExecutor$ ~[na:1.8.0_91]
    at [na:1.8.0_91]

Anyone have any ideas?

mansu commented Dec 26, 2016

/cc @naoman

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment