Compile examples of instrumentation and language specific configuration options

[jack-berg]

The file config schema has focussed on configuring SDK instances, but it should be evolvable to include instrumentation concerns, and other language specific configuration concerns.

We should compile some examples so we have an idea of how the file config schema might need to evolve to include these options.

[jack-berg]

Some examples of configuration options for the otel java agent:

Option	Description
otel.instrumentation.common.peer-service-mapping	A map of host names to service names to populate used to populate the peer.service attribute
otel.instrumentation.http.capture-headers.client.request	Request headers to capture on client http requests
otel.instrumentation.http.capture-headers.client.response	Request headers to capture on client http responses
otel.instrumentation.http.capture-headers.server.request	Request headers to capture on server http requests
otel.instrumentation.http.capture-headers.server.response	Request headers to capture on server http responses
otel.instrumentation.common.db-statement-sanitizer.enabled	Whether to sanitize db statements
otel.instrumentation.{instrumentation-module}.enabled	Whether the instrumentation with the name instrumentation-module is enabled. There are many examples of this.
otel.instrumentation.{instrumentation-module}.{feature}	Configuration for a particular feature of instrumentation with name instrumentation-module. E.g. otel.instrumentation.logback-appender.experimental.capture-mdc-attributes configures the set of MDC attributes captured for the logback appender. There are many examples of this.
otel.java.enabled.resource-providers	Set of resource providers enabled. Java has an extension interface to plug in additional providers for resources, which are merged together.
otel.java.disabled.resource-providers	Set of resource providers disabled. Java has an extension interface to plug in additional providers for resources, which are merged together.

[codeboten]

Examples environment variables in python:	Option	Description
OTEL_PYTHON_CONTEXT	allows users to provide an alternative to the runtime context. Defaults to Python's contextvars
OTEL_PYTHON_ID_GENERATOR	allows users to provide an alternative to the id generator. Defaults to random generator.
OTEL_PYTHON_TRACER_PROVIDER	allows users to provide the entry point for loading the tracer provider. If not specified, SDK TracerProvider is used.
OTEL_PYTHON_METER_PROVIDER	allows users to provide the entry point for loading the meter provider. If not specified, SDK MeterProvider is used.
OTEL_PYTHON_LOGGER_PROVIDER	allows users to provide the entry point for loading the log emitter provider. If not specified, SDK LoggerProvider is used.
OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED	allows users to enable/disable the logging SDK auto instrumentation.
OTEL_PYTHON_EXCLUDED_URLS	allows users to exclude URLs across all instrumentations.
OTEL_PYTHON_DJANGO_EXCLUDED_URLS	allows users to exclude URLs for Django instrumentation.
OTEL_PYTHON_DJANGO_TRACED_REQUEST_ATTRS	allows users to extract additional attributes from requests in Django.
OTEL_PYTHON_DISABLED_INSTRUMENTATIONS	allows users to disable instrumentations

[svrnm]

Moving my comment on JMX here, since it seems to be the most fitting place:

JMX Metric Insights comes with a config file that should ideally be part of the overall config file as well. An example from the README:

---
rules:
  - bean: java.lang:type=Threading
    mapping:
      ThreadCount:
        metric: my.own.jvm.thread.count
        type: updowncounter
        desc: The current number of threads
        unit: 1

The Readme also holds a section that describes the config in details.

@PeterF778 & @trask know more about this.

[svrnm]

Moving this one her as well: Some instrumentation settings are language agnostic, right now an example for that is otel.instrumentation.http.capture-headers.<client|server>.<request|response>, but one can think about more:

• General identity attributes has the following statement "SDKs and exporters SHOULD drop these attributes by default and then provide a configuration parameter to turn on retention"
• JS GraphQL Instrumentation Library have configuration options that would also be applicable in other languages implementing GraphQL
• Similar to the HTTP headers other metadata/headers might be set to be collected in an language agnostic manner
• ...

So eventually having a statement on "language agnostic configuration are preferred over language specific configuration" would be great. This of course would eventually require an equivalent to the semantic conventions (or as part of the semconv) how certain collection is configured/enabled.