Description
When we first built the Instrumentation API, tracing was (and often still is!) on the forefront of developers' minds. Over time, it becomes more apparent that not all instrumentation is concerned with tracing. Some instrumentations only want to measure something...and some other instrumentations might only want to log a thing or emit an event when something interesting happens.
The latter is especially true in the client/mobile world. At the time of this writing, Android is using an odd mix of zero-duration spans serving as events and fledgling events (based on LogRecord). This isn't great, and an improved Instrumentation API could help to facilitate improvements here.
As evidence that the Instrumentation API is primarily concerned with tracing, take the example of the primary instrumentation API class: Instrumenter (link). The javadoc reads as though it encompasses all manner of instrumenting:
The {@link Instrumenter} encapsulates the entire logic for gathering telemetry [snip]
...but the builder() requires a SpanNameExtractor and assumes that all telemetry will have a span name! Furthermore, there are no methods dealing with logs nor events, and the metrics support is also minimal (geared at measuring tracing "operations" [like requests] and supportability metrics).
I haven't given this topic too much though and don't have a design approach yet. I think it would be great for us to begin thinking about what an extension/expansion of the instrumentation API might be -- and one that helps instrumentation authors (in the web/mobile space and beyond) to easily create non-tracing instrumentation that is implemented with consistency.