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:
Status update for GlusterFS tracing:
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
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
+------------------------------------+
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)
- 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.
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.
- 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.
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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
