<div dir="ltr"><div dir="ltr"><div><u><b>Status update for Glusterd2 tracing:<br></b></u>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 (<a href="https://github.com/gluster/glusterd2/pull/1149">https://github.com/gluster/glusterd2/pull/1149</a>)<br><br><b></b><u><b></b></u>Status as of last week:<br><ul><li>PRs raised for volume start/stop and snapshot create/delete commands   (<a href="https://github.com/gluster/glusterd2/issues/1254">https://github.com/gluster/glusterd2/issues/1254</a>)   <br></li></ul>Plans for next week:<br><ul><li>Add tracing instrumentation for volume option set and volume expand commands.</li><li>Come up with plans and approach for dynamically enabling and disabling tracing.</li><li>Start looking at deployment of Jaeger service with GCS. </li></ul><br><u><b>Status update for GlusterFS tracing:</b></u><br><ul><li>Opentracing-c API is available but there&#39;s no adoption as of now.<br></li><li>No C client tracers at this point i.e. No Jaeger C client plugin but C++ Jaeger client plugin is available.</li><li>Tried evaluating Zipkin C tracer but it doesn&#39;t build due to various interdependencies. Again it&#39;s not adopted as far as I know.<br></li></ul>Options:<br>1. Write a C++ to C bridge to call the Jaeger tracers&#39; client APIs <br>   OR<br>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.<br>   <br>Option 1 is less appealing as <br><ul><li> it ties GlusterFS to a single tracer,</li><li> any changes to Jaeger cpp code/api may break the C bridge and may involve re-work. <br></li></ul>Option 2 appears to provide more value as <br><ul><li>Opentracing-cpp is stable and is being adopted unlike opentracing-c which has no adoption currently.</li><li>Any existing tracers (Jaeger, Zipkin etc.) written in C++ may be used interchangeably as plugins.</li><li>Only API level changes will affect the C++ bridge code and is less disruptive.<br></li></ul>But option 2 needs development time and this is to be determined.<br>Currently in discussion with opentracing community on the best way forward.  <br><br>Brief Illustration of proposed tracing stack:<br><font size="1"><span style="font-family:monospace,monospace">+------------------------------------+<br>|          GlusterFS Code            |<br>+------------------------------------+<br>|      GlusterFS tracing library     |<br>| (syntactic sugars/plugin control)  | --&gt; to be implemented (option 2 above)<br>|     (improved tracing model)       |<br>+------------------------------------+<br>|  Pure OpenTracing versioned API    | --&gt; stable version available in cpp<br>+------------------------------------+<br>|          Tracer plugins            |<br>|       (Jaeger/Zipkin etc.)         | --&gt; stable version available in cpp<br>+------------------------------------+<br><br></span></font></div><div><font size="1"><span style="font-family:monospace,monospace"><font size="2"><font face="arial,helvetica,sans-serif">Any feedback is appreciated.</font></font><br><br></span></font></div><div><font size="1"><span style="font-family:monospace,monospace"><font size="2"><font face="arial,helvetica,sans-serif">-Sridhar<br><br></font></font></span></font></div></div></div>