Re: [DISCUSS] OpenTelemetry for Zookeeper?
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 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 > > > > > > > >
Re: [DISCUSS] OpenTelemetry for Zookeeper?
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 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 > > > >
[DISCUSS] OpenTelemetry for Zookeeper?
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
