You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2018/03/16 21:09:33 UTC
[DISCUSS] Remove tracer service (not instrumentation)
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?
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Billie Rinaldi <bi...@gmail.com>.
I am +0 for this proposal and agree that putting it in a separate repo
would be preferable to dropping it. I tend to think that a better eventual
home for the Accumulo span receiver would be in HTrace itself -- that would
solve a lot of our version compatibility issues. That said, I wanted to
mention a few things we should keep in mind during this process.
- The Accumulo span receiver and the tracing display in the monitor have
been tweaked to handle the volume of traces produced by HDFS. Specifically,
the span receiver is configured by default to drop spans of length 0ms, and
the monitor page is able to display children of those spans in a useful
way. I don't know how other tracing backends and UIs would deal with this.
- For systems that produce a large amount / high rate of tracing data,
Accumulo may be the only viable storage for traces.
- One advantage of Accumulo's tracing system is that it is on by default.
On Fri, Mar 16, 2018 at 2:09 PM, Christopher <ct...@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?
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Tony Kurc <tr...@gmail.com>.
Christopher hit the nail on the head.
Based on my comments, what I didn't say explicitly what was more valuable -
the instrumentation or the tracing service. My opinion is that there are
other tracing backends (
http://opentracing.io/documentation/pages/supported-tracers.html) and if it
was possible to send to any or all of these would serve my needs. This
implied to me that the instrumentation was more valuable.
On Sat, Mar 17, 2018 at 3:52 PM, Christopher <ct...@apache.org> wrote:
> If you're talking about Tony's user testimony, he already indicated in this
> thread approval of this proposal prior to any mention of another repo. My
> understanding (perhaps he can clarify here) is that his primary concern was
> keeping the instrumentation and the ability to send to another sink. That's
> what led to me discussing removal of this subset, instead of the full
> removal mentioned in the previous thread.
>
> I'm fine with moving things to a separate repo, if that's in demand (can
> help with that, too, but no guarantees on how much time I can devote to
> it). One thing I think we definitely should do, is shift focus in our core
> docs away from our specific tracing sink, and more towards the fact that
> the sink is configurable and ours is only one possible. Of course, our
> Accumulo-backed sink can have its own documentation. My hope long term,
> though, is that other trace sink systems will implement their own
> Accumulo-backed implementation, if that's something users really want.
>
> On Sat, Mar 17, 2018, 15:05 Josh Elser <el...@apache.org> wrote:
>
> > That was my expectation on how it would work
> >
> > My +1 was the idea of moving the Tracer to a separate service and having
> > clear instructions for how users get back to the current functionality
> > (how these two repositories get deployed), *before* it's removed from
> > core Accumulo.
> >
> > This is because of the very clear testimony from a user about useful the
> > feature was to them.
> >
> > On 3/16/18 7:36 PM, Christopher wrote:
> > > Would you both (Michael and Josh) be okay with moving it to a separate
> > repo
> > > within the Accumulo project rather than ripping it out and leaving it
> > only
> > > buried in git history?
> > >
> > > On Fri, Mar 16, 2018 at 7:15 PM Josh Elser <el...@apache.org> wrote:
> > >
> > >> 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 <ct...@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 <mj...@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 <md...@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 <tr...@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?
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Christopher <ct...@apache.org>.
If you're talking about Tony's user testimony, he already indicated in this
thread approval of this proposal prior to any mention of another repo. My
understanding (perhaps he can clarify here) is that his primary concern was
keeping the instrumentation and the ability to send to another sink. That's
what led to me discussing removal of this subset, instead of the full
removal mentioned in the previous thread.
I'm fine with moving things to a separate repo, if that's in demand (can
help with that, too, but no guarantees on how much time I can devote to
it). One thing I think we definitely should do, is shift focus in our core
docs away from our specific tracing sink, and more towards the fact that
the sink is configurable and ours is only one possible. Of course, our
Accumulo-backed sink can have its own documentation. My hope long term,
though, is that other trace sink systems will implement their own
Accumulo-backed implementation, if that's something users really want.
On Sat, Mar 17, 2018, 15:05 Josh Elser <el...@apache.org> wrote:
> That was my expectation on how it would work
>
> My +1 was the idea of moving the Tracer to a separate service and having
> clear instructions for how users get back to the current functionality
> (how these two repositories get deployed), *before* it's removed from
> core Accumulo.
>
> This is because of the very clear testimony from a user about useful the
> feature was to them.
>
> On 3/16/18 7:36 PM, Christopher wrote:
> > Would you both (Michael and Josh) be okay with moving it to a separate
> repo
> > within the Accumulo project rather than ripping it out and leaving it
> only
> > buried in git history?
> >
> > On Fri, Mar 16, 2018 at 7:15 PM Josh Elser <el...@apache.org> wrote:
> >
> >> 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 <ct...@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 <mj...@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 <md...@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 <tr...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> I like this idea.
> >>>>>>>
> >>>>>>> On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Josh Elser <el...@apache.org>.
That was my expectation on how it would work
My +1 was the idea of moving the Tracer to a separate service and having
clear instructions for how users get back to the current functionality
(how these two repositories get deployed), *before* it's removed from
core Accumulo.
This is because of the very clear testimony from a user about useful the
feature was to them.
On 3/16/18 7:36 PM, Christopher wrote:
> Would you both (Michael and Josh) be okay with moving it to a separate repo
> within the Accumulo project rather than ripping it out and leaving it only
> buried in git history?
>
> On Fri, Mar 16, 2018 at 7:15 PM Josh Elser <el...@apache.org> wrote:
>
>> 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 <ct...@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 <mj...@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 <md...@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 <tr...@gmail.com> wrote:
>>>>>>
>>>>>>> I like this idea.
>>>>>>>
>>>>>>> On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Christopher <ct...@apache.org>.
Would you both (Michael and Josh) be okay with moving it to a separate repo
within the Accumulo project rather than ripping it out and leaving it only
buried in git history?
On Fri, Mar 16, 2018 at 7:15 PM Josh Elser <el...@apache.org> wrote:
> 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 <ct...@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 <mj...@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 <md...@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 <tr...@gmail.com> wrote:
> >>>>
> >>>>> I like this idea.
> >>>>>
> >>>>> On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Josh Elser <el...@apache.org>.
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 <ct...@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 <mj...@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 <md...@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 <tr...@gmail.com> wrote:
>>>>
>>>>> I like this idea.
>>>>>
>>>>> On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Michael Wall <mj...@gmail.com>.
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 <ct...@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 <mj...@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 <md...@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 <tr...@gmail.com> wrote:
> > >
> > > > I like this idea.
> > > >
> > > > On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Christopher <ct...@apache.org>.
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 <mj...@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 <md...@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 <tr...@gmail.com> wrote:
> >
> > > I like this idea.
> > >
> > > On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> > > >
> > >
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Michael Wall <mj...@apache.org>.
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 <md...@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 <tr...@gmail.com> wrote:
>
> > I like this idea.
> >
> > On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> > >
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Christopher <ct...@apache.org>.
Nothing is "ready to go". We've barely started the discussion.
Is there a story you'd like to see?
On Fri, Mar 16, 2018 at 6:25 PM Mike Drob <md...@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 <tr...@gmail.com> wrote:
>
> > I like this idea.
> >
> > On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> > >
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Mike Drob <md...@apache.org>.
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 <tr...@gmail.com> wrote:
> I like this idea.
>
> On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
> >
>
Re: [DISCUSS] Remove tracer service (not instrumentation)
Posted by Tony Kurc <tr...@gmail.com>.
I like this idea.
On Fri, Mar 16, 2018 at 5:09 PM, Christopher <ct...@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?
>