Experimental OpenTracing instrumentation for Cassandra. This work is intended to validate both the new BINARY
format here, and to eventually lead to OT support in the Cassandra server side. Inspiration taken from previous work.
Prior to building this plugin, you will need to do the next steps:
- Get Cassandra and set it up to run it locally.
- Get opentracing-java.
- cd
opentracing-java
andgit fetch origin pull/252/head:binary_format_proposal
to fetch the branch containing the latestBINARY
format support. git checkout binary_format_proposal && mvn clean install
to create the jars foropentracing-api
and the other modules, as well as performing their installation in the local Maven repository. Observe they will be labeled with the 0.31.1-SNAPSHOT version (so no messing up wit the stable 0.31 installation, of any).
Once these steps have been completed, it's time to build and test the plugin:
mvn clean && mvn package
to produce a jar containing both the client call and the server plugin.cp target/opentracing-cassandra-server-0.0.1-SNAPSHOT.jar /your/path/to/apache-cassandra-3.11.2/lib/
to copy the plugin to the Cassandra lib directory.- Copy the
opentracing
jars to the same location (/your/path/to/apache-cassandra-3.11.2/lib/
). That is,opentracing-api/target/opentracing-api-0.31.1-SNAPSHOT.jar
and the others foropentracing-noop
andopentracing-mock
). These are the dependencies of our plugin so we need to have them around. - Start Cassandra specifying our custom tracing class:
JVM_OPTS="-Dcassandra.custom_tracing_class=io.opentracing.contrib.cassandra.OTTracing" bin/cassandra -f
. - Once Cassandra is running locally, from this directory type
mvn exec:java
, which will invoke ourClientCall.main()
code, which will issue a simple query with tracing enabled, and passing a custom payload (containing theSpan
context).
This should show the next lines in the Cassandra terminal:
OTTracing.java:73 - Created Span for 6b71ea80-4a10-11e8-8842-d5881f757428 with parent span id 2
OTTracing.java:116 - Span for session 6b71ea80-4a10-11e8-8842-d5881f757428 got logged = Execute CQL3 query
OTTracing.java:117 - Span for session 6b71ea80-4a10-11e8-8842-d5881f757428 got logged = /127.0.0.1
OTTracing.java:99 - Finished span for 6b71ea80-4a10-11e8-8842-d5881f757428
OTTracing.java:100 - tags = {cassandra.session=6b71ea80-4a10-11e8-8842-d5881f757428, cassandra.elapsed=23087}
This will show the plugin properly managed to extract the payload and use the resulting SpanContext
as parent of our own (with parent span id 2
), new Span
on the server side.
Cassandra supports custom plugins to replace their own tracing layer, through the usage of data contained in a ByteBuffer
object. This happens both in the client and the server (plugin) side:
// Client issuing the request.
tracer.inject(scope.span().context(), Format.Builtin.BINARY, Adapters.injectBinary(stream));
ByteBuffer payload = ByteBuffer.wrap(stream.toByteArray());
// Execute a simple statement and pass a custom payload.
Statement stmt = new SimpleStatement("SELECT * FROM system_schema.keyspaces;");
stmt.enableTracing();
stmt.setOutgoingPayload(singletonMap(OTTracing.OT_TRACE_HEADERS, payload));
// Server
@Override
public UUID newSession(UUID sessionId, TraceType traceType, Map<String, ByteBuffer> customPayload)
{
SpanContext ctx = null;
ByteBuffer buff = customPayload == null ? null : customPayload.get(OT_TRACE_HEADERS);
if (buff != null)
ctx = tracer.extract(Format.Builtin.BINARY, new BinaryAdapter(buff));