Conversation
| @@ -866,7 +892,7 @@ otel.exporter.otlp.metrics.temporality.preference OTEL_EXPORTER_OTLP_METRICS_TEM | |||
| SettingCategory.INSTRUMENTATION)); | |||
|
|
|||
| // DB statement sanitization | |||
| // https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#db-statement-sanitization | |||
| // https://opentelemetry.io/docs/zero-code/java/agent/instrumentation/#db-statement-sanitization | |||
There was a problem hiding this comment.
There are probably other pages that have changed. I think we should try to tackle this in a subsequent PR.
| .component("Apache Kafka Connect API", "2.6 and higher") | ||
| // https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/kafka/kafka-clients/kafka-clients-2.6/library/README.md | ||
| // these metrics are created by kafka, we only collect these as otel metrics | ||
| .customMetric( |
There was a problem hiding this comment.
Upstream metadata doesn't include these. The exact metrics you'll get depends on the kafka client version. I think the plan is to disable the kafka metrics by default in the next major release.
| @@ -4528,12 +2249,12 @@ Map<String, Object> build() { | |||
| if (!metrics.isEmpty()) { | |||
| signals.add(Collections.singletonMap("metrics", metrics)); | |||
| } | |||
| if (!dependencies.isEmpty()) { | |||
There was a problem hiding this comment.
we never add dependencies to the instrumentations (I believe resource providers use this) so removed it
robsunday
left a comment
robsunday
left a comment
There was a problem hiding this comment.
There are lots of changes hard to validate manually, but it looks good with few small comments.
| metadata = yaml.load(inputStream); | ||
| } | ||
|
|
||
| if (!"0.5".equals(metadata.get("file_format").toString())) { |
There was a problem hiding this comment.
Any chance it can be 0.5.1, which in theory should be backward compatible with 0.5 ?
There was a problem hiding this comment.
Not really. When the format changes we expect to manually validate that the new version is fine.
| @@ -4238,6 +2061,11 @@ private static Map<String, Object> setting( | |||
| String defaultValue, | |||
| SettingType type, | |||
| SettingCategory category) { | |||
| if ("otel.instrumentation.spring-batch.item.enabled".equals(property)) { | |||
| // SplunkConfiguration overrides the default value of this settings to true | |||
There was a problem hiding this comment.
That is not the case for declarative config. It must be placed in yaml explcitly.
Also there is otel.instrumentation.spring-batch.enabled as well defaulting for env var config schema to true
There was a problem hiding this comment.
That is not the case for declarative config. It must be placed in yaml explcitly.
It is fine. This option was added for a certain customer that is not a customer any more. We can disable it by default in the next major release.
Also there is otel.instrumentation.spring-batch.enabled as well defaulting for env var config schema to true
This is a bit annoying. Upstream metadata has a disabled_by_default tag. Perhaps we should append This instrumentation is disabled by default. to the description of the disabled instrumentations.
2 participants
Use https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/instrumentation-list.yaml to generate instrumentation metadata. Move instrumentation settings under instrumentations like in dotnet. See https://help.splunk.com/en/splunk-observability-cloud/manage-data/available-data-sources/supported-integrations-in-splunk-observability-cloud/apm-instrumentation/instrument-a-.net-application/requirements and https://help.splunk.com/en/splunk-observability-cloud/manage-data/available-data-sources/supported-integrations-in-splunk-observability-cloud/apm-instrumentation/instrument-a-java-application/requirements
Due to the way upstream metadata is structured when different versions of the framework have different instrumentations we'll list them all. Known issues in upstream metadata are
otel.instrumentation.servlet.capture-request-parameters, probably should beotel.instrumentation.servlet.experimental.capture-request-parametersAt least we don't have to manually keep this up to date any more.