htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: Tracing a chain of iterators -- htrace 2.04
Date Wed, 19 Aug 2015 06:39:41 GMT
Hi Andrew,

Thanks for posting!

Is the concern just that there would be too many spans if each call to
next() created a span?  Does sampling help address this concern?

You said, "what we'd really want, is to aggregate the time spent in
each call to next for each iterator, and then send the spans at the
end."  But HTrace already does this, right?  Most span receivers will
batch up the spans they receive and send them all in one big batch,
probably "at the end."  What am I missing?

cheers,
Colin


On Tue, Aug 18, 2015 at 3:03 PM, Andrew Mains
<andrew.mains@kontagent.com> wrote:
> Hi all,
>
> This is really more of a "user" question than a "dev" question, but I'm
> posting here since I was unable to find a user list for the project; hope
> that's alright.
>
> I was hoping to get some input on the best way to trace execution through a
> chain of iterators. Specifically, we have a database-like application which
> pipes data through multiple iterators, performing some transformation at
> each step. We'd like insight into how long each step is taking in total for
> a particular request. That is, for a chain of iterators iter_1... iter_i, we
> want the total time spent in each iter_i for that request.
>
> The naive implementation would be to start a span in each call to next, but
> that's far too fine grained, given that we'd be starting a new span for each
> row. What we'd really want, is to aggregate the time spent in each call to
> next for each iterator, and then send the spans at the end. This would
> require implementing a new span subclass, which is a bit tricky to integrate
> at the moment (since it prevents us from using the static helpers in Trace).
>
> Any thoughts on the best way to approach this issue? Is there something I'm
> missing, or some way that we can reframe the problem such that it makes
> sense with what's currently in htrace?
>
> Let me know if there's anything that's unclear, or any further info I can
> provide about our use case.
>
> Thanks for the help!
>
> Andrew

Mime
View raw message