accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Kurc <>
Subject Re: [DISCUSS] Remove tracer service (not instrumentation)
Date Fri, 16 Mar 2018 22:17:21 GMT
I like this idea.

On Fri, Mar 16, 2018 at 5:09 PM, Christopher <> 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?

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