Skip to content

how to map declarative config properties #14144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions docs/misc/declarative-configuration/config.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# This file serves as a specification how to map properties from the existing config properties
# to the declarative configuration format.
# This list does not contain all properties, but those that
# are different from what the config bridge already does.

# Based on https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml

# Re-use this flag to disable the Agent/Spring starter as well as the SDK.
disabled: false # was: "otel.javaagent.enabled"
# Re-use this flag from the SDK: if value is "debug", we trigger the behavior of "otel.javaagent.debug"
log_level: info # was: "otel.javaagent.debug"
instrumentation/development:
# nothing changes here - just for reference
general:
peer:
service_mapping: # was "otel.instrumentation.common.peer-service-mapping"
- peer: 1.2.3.4
service: FooService
- peer: 2.3.4.5
service: BarService
http:
# should be added to https://github.com/open-telemetry/opentelemetry-configuration/blob/c205770a956713e512eddb056570a99737e3383a/examples/kitchen-sink.yaml#L872
known-methods: # was "otel.instrumentation.http.known-methods"
- GET
- POST
- PUT
- DELETE
- PATCH
- HEAD
- OPTIONS
client:
request_captured_headers: # was otel.instrumentation.http.client.capture-request-headers
- Content-Type
- Accept
response_captured_headers: # was otel.instrumentation.http.client.capture-response-headers
- Content-Type
- Content-Encoding
server:
request_captured_headers: # was otel.instrumentation.http.server.capture-request-headers
- Content-Type
- Accept
response_captured_headers: # was otel.instrumentation.http.server.capture-response-headers
- Content-Type
- Content-Encoding
java:
agent:
# Also map all other properties with the "otel.javaagent." prefix the same way,
# unless specified otherwise.
# See https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/14132
exclude-class-loaders: # was "otel.javaagent.exclude-class-loaders"
- a
- b
common:
db-statement-sanitizer:
enabled: true # already exists - just for reference
thread_details:
enabled: true # was "otel.javaagent.add-thread-details" = "true"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively: spans: enabled: true

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a good question

honestly I wonder how useful this instrumentation is, and whether we should disable it by default in 3.0 @laurit?

I guess my preference would be

  • disabled by default
  • enabled applies to both spans and logs (but not metrics due to high cardinality)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could apply this new semantic also to the spring starter where this feature is added without declarative config in #14117

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The semantic conventions recommend setting these attributes. Comments in open-telemetry/opentelemetry-specification#788 list some potential usages. It is difficult to predict when which attributes could be valuable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@trask agreed to check with sem conv

logging:
application:
logs-buffer-max-records: 1000 # can only be used with "type: application"
type: application or simple # was "otel.javaagent.logging"
Loading