Hi Robert,
For myself, I didn’t use the zipkin myself too much, although our testers and
infrastructure teams used the traces heavily while doing system and integration
testing. These traces helped find some performance issues between web front
ends and various services tracing the amount of time each level of a request
required. The extra level of span traces were particularly useful to one of the
teams tracking down a slow-down with one of the backend services
Request tracing would be a boon to anyone trying to find issues with a system.
Linking the full trace with an ID would make issue and performance tracking
much easier.
Regarding the number of headers in zipkin, I didn’t work on that aspect so I
can’t speak confidently on the number and type. I only had to change my Spring
configuration to pull in the definitions defined by one of the other teams.
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
[Description: Description: Description: cid:image001.png@01CA1F1F.CBC93990]
From: Robert Coup [mailto:robert.c...@koordinates.com]
Sent: Friday, March 18, 2016 9:33 AM
To: Chris Snider <chris.sni...@issinc.com>
Cc: Andrea Aime <andrea.a...@geo-solutions.it>;
geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Request IDs
Hi Chris,
On 18 March 2016 at 14:35, Chris Snider
<chris.sni...@issinc.com<mailto:chris.sni...@issinc.com>> wrote:
For our application stack, we use Zipkin with a backing Cassandra store in a
Docker environment. This also uses a custom httpclient that is integrated into
the various levels of the app stack and service implementations. Zipkin adds a
custom header that is tracked through the calls.
Looks like Zipkin is a more advanced approach along the same lines. From what I
can tell from a quick read it uses 3-5 headers?
X-B3-TraceId: overall trace id
X-B3-SpanId: id for current step/component in a graph of services
X-B3-ParentSpanId: SpanId from any parent component/step
X-B3-Flags & X-B3-Sampled: track "debug" requests and whether additional
performance sampling is requested
Each ID is 64bits hex-encoded (ie. half the length of a UUID)
Does that sound about right?
I'm not overly keen to add such a complex implementation -- would what's
currently be proposed be useful for you? Do your team find the ability to trace
requests helpful?
https://brandur.org/request-ids discusses a similar pattern as I've proposed,
though each step (eg. frontend, GeoServer, WPS task, cascaded WFS, database)
would all generate their own UUIDs then append them together.
Cheers,
Rob :)
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
