Added SpanReceiver for Zipkin and now trace entries make more sense. Thanks,
On Fri, Feb 28, 2020 at 10:30 PM Christopher <ctubb...@apache.org> wrote: > The tracing in Accumulo is instrumented using HTrace. You can > configure any HTrace sink for collecting the trace information. The > built-in one that writes to an Accumulo table (called > "ZooTraceClient") is the default, but you can easily change this by > editing the configuration property for "trace.span.receivers". > > The built-in default trace sink was designed to emit data to an > Accumulo table by sending it first to a separate tracer service that > behaves as an Accumulo client and writes data back to a table. This > trace data can then be read and interpreted by the Accumulo monitor. > It may not be easy to read/interpret without using the monitor, as the > schema is not well-documented (and possibly not stable between > versions). > > Although it might be suitable for some modest needs, I don't > personally recommend using the the built-in default trace sink if you > are serious about tracing, and instead would advise you to use a more > well-tested and stable trace sink service for HTrace, perhaps one that > is designed specifically for that purpose. Others on the project may > have a different opinion. > > On Fri, Feb 28, 2020 at 6:44 PM mhd wrk <mhdwrkoff...@gmail.com> wrote: > > > > Hi, > > > > Our Accumulo deployment uses custom Authenticator and Authorizer and > also attaches few custom filters/iterators to tables during scan time. The > challenge is that we are seeing very slow response when loading the table > inside a spark shell and doing a simple count. > > I was thinking of adding logs to all our custom components to collect > metrics then I came across Accumulo Tracer which seems, somehow, targets > the same concerns but requires its own custom coding and also, so far, I > don't find the content of the trace table very easy to read/interpret. > > > > Any suggestions/recommendations? > > > > Thanks, >
