Configuration for semantic attributes collection

[svrnm]

This is related to #8 (comment). I was thinking about this for a little bit and wanted to propose the following:

One of the key features of the OpenTelemetry spec are the semantic conventions. The semconv comes down to a bunch of attributes for resources, traces, metrics, logs etc. Now some of them have already a comment on their configurability, e.g. the general identity attributes, the http headers, database statement sanitization, etc.

For the otel configuration file I was thinking about a language agnostic way of potentially(!) making all attributes configurable, similar to what the example config.yml already has for resource

sdk:
  metric:

  # Copied from the existing example
  resource:
    attributes:
      service:
        name: !!str "unknown_service"
  trace:
    attributes:
     db:
       statement: 
         sanitized: true
     enduser: disabled
       http:
         request:
           header:
              - content_type
              - x_forwarded_for
              - ...
        response:
           header:
              - my_custom_header

I am not yet 100% satisfied with the layout, since it is extremely complex if attributes have a long namespace and it is also not yet consistent, but I wanted to start with this as a proposal and see what everybody else thinks

[jack-berg]

This is an instrumentation concern rather than an SDK concern.

The SDK is responsible for processing invocations of the APIs by instrumentation. Currently, there's no text in the SDK specifications that would describe how an SDK would handle this type of configuration.

Resource configuration is an exception because the resource is a concept that only appears in the SDK. Instrumentation is never concerned with the resource.

[svrnm]

This is an instrumentation concern rather than an SDK concern.

The SDK is responsible for processing invocations of the APIs by instrumentation. Currently, there's no text in the SDK specifications that would describe how an SDK would handle this type of configuration.

Resource configuration is an exception because the resource is a concept that only appears in the SDK. Instrumentation is never concerned with the resource.

@jack-berg so you suggest to put the trace etc specific things into an instrumentation section, e.g.

sdk:
  # Copied from the existing example
  resource:
    attributes:
      service:
        name: !!str "unknown_service"
instrumentation:
  trace:
    attributes:
     db:
       statement: 
         sanitized: true
     enduser: disabled
       http:
         request:
           header:
              - content_type
              - x_forwarded_for
              - ...
        response:
           header:
              - my_custom_header