[Gluster-devel] Gluster Components Tracing: Update

Sridhar Seshasayee sseshasa at redhat.com
Thu Oct 25 05:35:29 UTC 2018


*Status update for Glusterd2 tracing:*For those not aware, opencenus-go
library is being used for tracing in Glusterd2. For additional details on
its usage in Glusterd2 see this PR (
https://github.com/gluster/glusterd2/pull/1149)

Status as of last week:

   - PRs raised for volume start/stop and snapshot create/delete commands
   (https://github.com/gluster/glusterd2/issues/1254)

Plans for next week:

   - Add tracing instrumentation for volume option set and volume expand
   commands.
   - Come up with plans and approach for dynamically enabling and disabling
   tracing.
   - Start looking at deployment of Jaeger service with GCS.


*Status update for GlusterFS tracing:*

   - Opentracing-c API is available but there's no adoption as of now.
   - No C client tracers at this point i.e. No Jaeger C client plugin but
   C++ Jaeger client plugin is available.
   - Tried evaluating Zipkin C tracer but it doesn't build due to various
   interdependencies. Again it's not adopted as far as I know.

Options:
1. Write a C++ to C bridge to call the Jaeger tracers' client APIs
   OR
2. Write a C to C++ bridge over the opentracing-cpp library so that linking
with existing C++ tracers is easy and allows tracers to be used as plugins.

Option 1 is less appealing as

   -  it ties GlusterFS to a single tracer,
   -  any changes to Jaeger cpp code/api may break the C bridge and may
   involve re-work.

Option 2 appears to provide more value as

   - Opentracing-cpp is stable and is being adopted unlike opentracing-c
   which has no adoption currently.
   - Any existing tracers (Jaeger, Zipkin etc.) written in C++ may be used
   interchangeably as plugins.
   - Only API level changes will affect the C++ bridge code and is less
   disruptive.

But option 2 needs development time and this is to be determined.
Currently in discussion with opentracing community on the best way
forward.

Brief Illustration of proposed tracing stack:
+------------------------------------+
|          GlusterFS Code            |
+------------------------------------+
|      GlusterFS tracing library     |
| (syntactic sugars/plugin control)  | --> to be implemented (option 2
above)
|     (improved tracing model)       |
+------------------------------------+
|  Pure OpenTracing versioned API    | --> stable version available in cpp
+------------------------------------+
|          Tracer plugins            |
|       (Jaeger/Zipkin etc.)         | --> stable version available in cpp
+------------------------------------+

Any feedback is appreciated.

-Sridhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20181025/e3fb1f2b/attachment.html>


More information about the Gluster-devel mailing list