Thanks Chris. Unfortunately both ZooKeeper client and server code reside in zookeeper-server Maven project, so I think the separation that you suggest is not feasible at the moment.
Andor On Tue, 2024-01-02 at 21:13 -0500, Christopher wrote: > I think open tracing is a good library to use. Accumulo started using > it > after HTrace went to the attic. Accumulo also uses ZooKeeper. It > remains to > be seen if open telemetry will be stable in the long term, since it > is > relatively new. > > Lots of projects in an application stack may want to use open > telemetry, > but it may be difficult because of dependency hell and class path > issues if > lots of libraries in an application are all using open telemetry, but > using > different incompatible versions. That was certainly a big problem > with > HTrace when Hadoop was using one version and Accumulo was using a > different > version (notably, this problem arose, even though HTrace was > originally > derived from code that started out in Accumulo as "cloudtrace", > because it > was modified to be more general purpose and began being used by > multiple > applications in the application stack). This is not a unique issue, > but > other places where this could be a problem, such as logging, have > well > established solutions, like slf4j. It's not clear to me yet whether > open > telemetry can be relied upon to be stable like that in the long term. > If > zookeeper starts using it, it would be safest to use it only on the > server > code, at least to start, and not require it as a dependency of > zookeeper > client code, to make sure it doesn't conflict with other applications > that > use ZooKeeper. > > If it is used for client code, it should be possible to completely > disable > it with a property so nothing breaks if it is disabled and it is > missing > from the class path, or if a different version that is incompatible > exists > on the class path. That could be hard to do. > > This doesn't mean it shouldn't be done, just that if it is done, > these are > some things to consider to try to avoid potential problems down the > line. > > On Tue, Jan 2, 2024, 10:57 Andor Molnar <an...@apache.org> wrote: > > > Hi all, > > > > Inspired by the following CURATOR ticket I started to think about > > what > > needs to be done for ZooKeeper to support OpenTelemetry. > > > > CURATOR-695 Open Telemetry Tracing Driver [1] > > > > Unfortunately we don't have such generic tracing driver, even > > ZooTrace > > class looks unusable for this use case, but we should be able to > > implement it in a generic fashion. Start the trace in > > PrepRequestProcessor when request comes in and finish it in > > FinalRequestProcessor with adding some in-process events too. > > > > It's never that simple obviously, because, for instance, we also > > need > > to track the failing code paths too, but looks to me a good > > starting > > point and something we should invest into. > > > > Thoughts? > > > > Regards, > > Andor > > > > [1] https://issues.apache.org/jira/browse/CURATOR-695 > > > > > > > >
