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 <ctubb...@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? >
