Metadata - ability to have multiple classifications #14508
Conversation
github-actions
bot
added
the
test native
...tation-docs/src/main/java/io/opentelemetry/instrumentation/docs/InstrumentationAnalyzer.java
Outdated
Show resolved
Hide resolved
...cs/src/main/java/io/opentelemetry/instrumentation/docs/internal/InstrumentationMetadata.java
Outdated
Show resolved
Hide resolved
| automatically configures the instrumentation provided by the Couchbase library. | ||
| classification: | ||
| - library | ||
| - configuration |
There was a problem hiding this comment.
I think it does more than configuration, more like it automatically injects couchbase's instrumentation?
There was a problem hiding this comment.
I was bucketing all instrumentations that the agent just sets up and bootstraps in some way as "configuration", but I think you are right that it's not a very good description for these.
Brainstorming some other ideas we could use for instrumentations where we shade the upstreams and register them with the agent:
- bridge (maybe a little too general, but could work)
- native-bridge (I worry the word "native" might be ambiguous)
- injecter (feels ambiguous since most of our instrumentations use byte code injection)
- wrapper
- adapter
- upstream-adapter
I think my personal preference is "upstream-adapter" or just "adapter". I like the former since it highlights that the upstream is involved. I am open to more ideas though!
| description: This instrumentation enables context propagation for the Azure Core library, it does not emit any telemetry on its own. | ||
| classification: | ||
| - library | ||
| - propagator |
There was a problem hiding this comment.
this is similar to couchbase, where it injects Azure Core's OpenTelemetry instrumentation
…mentation into expand-classifications
|
decided to go in a different direction for this |
2 participants
Part of #13468
Closes #14247
As discussed in a SIG meeting a while back, instrumentations can fall under multiple "classifications" (I imagine this terminology may evolve more in the future). This PR adds the ability to support multiple classifications in a module's
metadata.yamlfile, and then outputs the new classifications into theinstrumentation-list.yamlfile.We currently structure the
instrumentation-list.yamlfile with 3 top level classifications that the instrumentations are grouped under:library,customandinternal, so I did not include those 3 in each module's resulting classification list. I plan to revisit this file's overall hierarchy in a followup PR where we flatten it and just include all categories in the list, removing the 3 top level ones.There are a lot of changed files in this PR, but most of them are the metadata files. All modules that I updated with the new categories were instrumentations that I had already documented and had previously created the
metadata.yamlfiles for. I can break all those out into a separate PR for easier reviewing if we want.