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 <trk...@gmail.com> wrote: > I like this idea. > > On Fri, Mar 16, 2018 at 5: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? > > >
