From dev-return-19639-archive-asf-public=cust-asf.ponee.io@accumulo.apache.org Sat Mar 17 00:15:25 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 97606180608 for ; Sat, 17 Mar 2018 00:15:24 +0100 (CET) Received: (qmail 44717 invoked by uid 500); 16 Mar 2018 23:15:23 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 44703 invoked by uid 99); 16 Mar 2018 23:15:23 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Mar 2018 23:15:23 +0000 Received: from hw13390.local (outbound.hortonworks.com [192.175.27.2]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 34C041BB7 for ; Fri, 16 Mar 2018 23:15:21 +0000 (UTC) Subject: Re: [DISCUSS] Remove tracer service (not instrumentation) To: dev@accumulo.apache.org References: From: Josh Elser Message-ID: <697dca6a-4160-2afd-212b-7ded280291ed@apache.org> Date: Fri, 16 Mar 2018 19:15:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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 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 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 wrote: >>>> >>>>> 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? >>>>>> >>>>> >>>> >>> >> >