accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Remove tracer service (not instrumentation)
Date Fri, 16 Mar 2018 23:15:20 GMT
I think I'm in agreement with this subset of Mikes.

I like the idea long-term. The tracing service is "add-on", and can live 
outside Accumulo.

I don't like the idea of moving the code out and taking away code which 
is functional today. I am +1 on the idea of building the same 
functionality outside of the core product. I am -1 on removing the 
functionality in the core product until the replacement is ready (e.g. 
clear docs for users covering how they get back to "normal").

On 3/16/18 6:49 PM, Michael Wall wrote:
> 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
View raw message