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,
