accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wall <mjw...@gmail.com>
Subject Re: [DISCUSS] Remove tracer service (not instrumentation)
Date Fri, 16 Mar 2018 22:49:48 GMT
Yeah, I get it.  That should have said "without a working example
alternative".  Something to make it as easy as possible for someone
currently using tracing to not loose functionality.

Thanks

On Fri, Mar 16, 2018, 18:38 Christopher <ctubbsii@apache.org> wrote:

> The alternative is to configure any of the other HTrace sinks which are
> available. The current code for Accumulo's tracer service could even be
> forked and supported as a separate sink to optionally use (but as I said in
> my original email, I think it'd be better to encourage contribution to
> other presentation projects to use Accumulo as a backing store).
>
> On Fri, Mar 16, 2018 at 6:34 PM Michael Wall <mjwall@apache.org> wrote:
>
> > I am in favor of removing the tracer ui from the monitor and the tracer
> > service that stores the spans in Accumulo.  I worry about doing so with a
> > working alternative though.
> >
> > On Fri, Mar 16, 2018 at 6:25 PM Mike Drob <mdrob@apache.org> wrote:
> >
> > > Do we have a migration story ready to go for folks that are used to
> > seeing
> > > traces on the monitor?
> > >
> > > On Fri, Mar 16, 2018 at 5:17 PM, Tony Kurc <trkurc@gmail.com> wrote:
> > >
> > > > I like this idea.
> > > >
> > > > On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ctubbsii@apache.org>
> > > wrote:
> > > >
> > > > > Devs,
> > > > >
> > > > > (This discussion is somewhat of a spinoff of our previous recent
> > > > > conversation about HTrace, but I'd like to narrow the discussion
to
> > one
> > > > > specific topic regarding our tracer service.)
> > > > >
> > > > > I'd like to remove Accumulo's tracer service and corresponding
> > > > > presentations in the monitor for 2.0.
> > > > >
> > > > > The tracer service currently acts as a sink for the traces from
> > > Accumulo.
> > > > >
> > > > > While there is interest in tracing Accumulo, and Accumulo may
> itself
> > be
> > > > > suitable (with the right schema) for storing traces, I do not think
> > > > acting
> > > > > as a "trace sink" is really the kind of thing we should be doing
as
> > > part
> > > > of
> > > > > Accumulo's out-of-the-box core functionality.
> > > > >
> > > > > Also, the presentation and search capabilities of the traces found
> in
> > > the
> > > > > trace table (by convention, and assumed by the monitor) is far from
> > an
> > > > > ideal presentation of this data, and I don't think the Accumulo
> > project
> > > > > should continue maintaining that inside the core project's monitor,
> > > > either.
> > > > >
> > > > > I think we should encourage interested volunteers to contribute to
> > > other
> > > > > trace presentation software (wherever they may exist) any necessary
> > > > > "backing store" implementation based on Accumulo.
> > > > >
> > > > > None of this would remove tracing instrumentation from Accumulo...
> it
> > > > would
> > > > > just require users interested in trace data from Accumulo to
> > configure
> > > an
> > > > > appropriate sink to collect that data in some other integrated
> > > component
> > > > of
> > > > > their overall architecture.
> > > > >
> > > > > Decoupling the integrated trace sink from the instrumentation in
> > > Accumulo
> > > > > like this could even be a step towards providing support for
> multiple
> > > > > different tracing libraries. (I guess we could do this now, but it
> > > would
> > > > be
> > > > > easier if we were not also trying to provide a sink implementation
> > for
> > > > one
> > > > > specific version of one specific instrumentation library.)
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message