Capturing input from @jackshirazi around scope information:

Having all of the fields from the InstrumentationScopeInfo object available to be able to re-construct it is useful because it is used as the key in a map to the tracer, and if you want to let users dynamically adjust the scope, that's how they would access it.

Update on the current state of things:

• Automated target version discovery for both javaagent and library instrumentation types
• Instrumentation classification via metadata.yaml
• Whether instrumentation is disabled by default via metadata.yaml
• Starting to add some basic descriptions (see stats on coverage below)
• Starting to document configuration options (see stats on coverage below)

Total Modules: 252
By classification:
	library: 226
	custom: 5
	internal: 21
metadata.yaml contents:
	descriptions: 12 (4.76%)
	configurations: 5 (1.98%)

Work in flight:

I am working through each module adding descriptions and configurations manually, while in parallel investigating ways we might be able to do some of this programmatically.

I am also still experimenting with using test runs in order to attain emitted span and metric data.

adding a note that @laurit brought up here about certain modules containing multiple instrumentations:

An alternative to this would be to allow metadata.yaml to describe multiple instrumentations. I guess it is tricky, in some cases one module contains multiple instrumentation modules that operate separately like here the jdbc and datasource instrumentation or kafka and kafka-metrics while in other cases multiple modules could be merged like opensearch-rest-1.0 and opensearch-rest-3.0.

I think it does probably make sense to consider further breaking down the modules to not just differentiate by file structure, but to also be able to break down further by InstrumentationModule classes and use those to identify each instrumentation. And then the metadata.yaml might need a way to specify attributes that apply to specific instrumentations within a module.

Identifying modules that could be merged will need further thought.

I will start experimenting

Capturing some notes from the discussion at todays SIG meeting:

• We should target eventually publishing this information (or parts of it) to the registry in opentelemetry.io, this will allow embedding the information in other areas in the site (there is an existing example within the "instrumentation ecosystem" page)
• This system doesn't do a good job at documenting and covering native instrumentation.
  • What native instrumentation emits can be a moving target
  • We do already have some native instrumentation wired up in test modules that we run tests against, and we can collect and document that telemetry information.
• This automated system could be used to validate documentation and identify drift, but the final documentation should be managed and maintained by humans.
  • The documentation could initially be bootstrapped with a one time automated generation and then continually updated/validated going forward
• Declarative configuration project is doing something where they are trying to track information about the various types associated with the data model. They want to be able to generate yaml based on code, and then markdown based on yaml.
• If we were to embed information into the code, how could that work? annotations?
• We still have some instrumentations that are outliers in some ways, there are instrumentations with more than one InstrumentationModule (jdbc), or some instrumentations that are split across modules but represent the same thing.
  • We could incorporate some context about these outliers into the instrumentation analyzer code and handle them accordingly if needed

Making note that @zeitlinger had a question about the spring starter configuration metadata file:

do you have an idea if we can also generate the spring metadata out of this?

I am adding an item to this issue to investigate how this system might be able to integrate with managing and/or documenting those configuration options as well.