You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The weaver files are newish, so we need to make sure the watcher accounts for when they don't exist and just ignores them and doesn't fail in the event we run a backfill.
We can extend InstrumentationSync to fetch the instrumentation/jmx-metrics/model/*.yaml files at the same ref it already uses for instrumentation-list.yaml, and persist them content-addressed.
Model files change rarely and are identical across most releases, so store them once in a
shared directory at the ecosystem root, with a small per-version index pointing into it:
ecosystem-registry/java/javaagent/
├── jmx/ # shared, content-addressed model store
│ ├── activemq-6c55bb962678.yaml
│ ├── camel-e74b2ed35478.yaml
│ ├── jetty-a3bae406cfcf.yaml
│ ├── jvm-45b20f5f3f0e.yaml
│ ├── manifest-977075160b7e.yaml
│ ├── tomcat-5846db79cc39.yaml
│ └── wildfly-6d2c8fd10301.yaml
├── v2.29.0/
│ └── instrumentation.yaml # no jmx-models.yaml — models don't exist yet
└── v2.30.0/
├── instrumentation.yaml
├── jmx-models.yaml # index for this version
└── library_readmes/
The keys are JMX target systems, not library names. Each model basename matches a value accepted by the otel.jmx.target.system config option, which corresponds to a rule file in instrumentation/jmx-metrics/library/src/main/resources/jmx/rules/. There is exactly one instrumentation here (jmx-metrics); the models describe its target systems.
manifest.yaml is not a model — it is the weaver registry manifest, and it carries the pinned semconv version (semantic-conventions@v1.43.0) that the next phase of this project will need to resolve attribute refs. Store it, but under a separate top-level key so it is never iterated as a target system.
The JMX instrumentation in the java agent now has weaver models with information about the telemetry emitted:
https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/jmx-metrics/model
We should update the https://github.com/open-telemetry/opentelemetry-ecosystem-explorer/tree/main/ecosystem-automation/java-instrumentation-watcher to scrape these, and then we can figure out how we want to use/display it.
The weaver files are newish, so we need to make sure the watcher accounts for when they don't exist and just ignores them and doesn't fail in the event we run a backfill.
We can extend
InstrumentationSyncto fetch theinstrumentation/jmx-metrics/model/*.yamlfiles at the same ref it already uses forinstrumentation-list.yaml, and persist them content-addressed.Model files change rarely and are identical across most releases, so store them once in a
shared directory at the ecosystem root, with a small per-version index pointing into it:
v2.30.0/jmx-models.yaml:Notes on this shape:
otel.jmx.target.systemconfig option, which corresponds to a rule file ininstrumentation/jmx-metrics/library/src/main/resources/jmx/rules/. There is exactly oneinstrumentation here (
jmx-metrics); the models describe its target systems.manifest.yamlis not a model — it is the weaver registry manifest, and it carries the pinned semconv version (semantic-conventions@v1.43.0) that the next phase of this project will need to resolve attributerefs. Store it, but under a separate top-level key so it is never iterated as a target system.library_readmes/. Please land it this way rather than nesting per-version, so the two converge. If Deduplicate readmes in registry #883 lands first, follow whatever helper it introduces.