Key concepts

While sampling and distributed tracing will help you understand where time in spent, it might not be enough to figure out *why *it is spent in these layers. For instance, if you’ve been able to figure out that most of the time is being spent in the database layer, it could be very useful to know which SQL statement(s) are responsible for the slow response times.

This is what object inspections can do for you.

Activating an existing capture tracer

The approach used is similar to what we’ve covered in the Distributed Tracing section. We’ll activate a tracer and assign it to target classes which will be candidates for instrumentation, just like in the case of any other subscription.

Here’s our config file for the SQL tracer example:

 <subscriptions>
    <io.djigger.monitoring.java.instrumentation.subscription.RegexSubscription>
        <classNamePattern>
            <pattern>.*SQLTracerTest</pattern>
            <flags>0</flags>
        </classNamePattern>
        <methodNamePattern>
            <pattern>.*</pattern>
            <flags>0</flags>
        </methodNamePattern>
        <tagEvent>true</tagEvent>
    </io.djigger.monitoring.java.instrumentation.subscription.RegexSubscription>
    <io.djigger.monitoring.java.instrumentation.subscription.SQLConnectionTracer/>
    <io.djigger.monitoring.java.instrumentation.subscription.SQLStatementTracer/>
    <io.djigger.monitoring.java.instrumentation.subscription.SQLPreparedStatementTracer/>
</subscriptions>

Creating your own capture tracers

Using the SQLConnection tracer as an example, we’ll use javaassist to inspect the arguments of methods *prepareStatement() and prepareCall()* and we’ll attach the data to the corresponding instrumentation event and send the resulting information back to the collector.

Please refer to the SQLConnectionTracer class for more details on how to implement object inspection and capture.

Demo

Once an object capture tracer is activated, the corresponding data will simply be displayed in the Data column of the event.

After starting your collector, run the SQLTracerTest example, fire a search over the last 5 minutes, and you should start seeing SQL-related events with the associated query in the Data column: