Allow controlling `RecordException` setting via environment variables/`IConfiguration`

[julealgon]

Feature Request

Is your feature request related to a problem?

We have several dozen services, most of them leveraging OpenTelemetry.Instrumentation.AspNet, or OpenTelemetry.Instrumentation.AspNetCore or OpenTelemetry.Instrumentation.Http.

In all of those projects, we've had to explicit set RecordException to true for those 3 instrumentations as we want that behavior company wide.

Having to perform this same change in all projects and guarantee that they are all properly synced is a maintenance burden.

Describe the solution you'd like:

I'd like for an external way to configure this particular setting. Similar to the recent queryString redaction change, where the default behavior has been to perform redaction over the values and an environment variable/IConfiguration key can be provided to turn redaction off, I believe it would make complete sense to offer similar configuration capability for the RecordException setting, by providing an environment variable to turn it on (or off) from outside the application.

This would allow us to centralize this behavior in our Azure AppConfiguration instance and automatically apply it to all of our many services in a more robust manner than having to go on each service and perform this change.

Ideally, there would be a "master" variable to control the behavior globally (enable/disable for all instrumentations), and then one variable per instrumentation so that it could be customized fully.

For example:

• OTEL_TRACES_RECORD_EXCEPTION
• OTEL_TRACES_HTTP_SERVER_RECORD_EXCEPTION or
• OTEL_TRACES_ASPNETCORE_RECORD_EXCEPTION or
• OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_RECORD_EXCEPTION

Or anything similar. I assume the name of the environment variable depends on whether or not it is part of the official spec or not? I don't particularly care that much about the name as long as it is consistent.

Describe alternatives you've considered.

We did not consider any alternatives. The only approach today is to set this programmatically, on each instrumentation setup.

Additional Context

I believe there is also an argument of consistency with this. By allowing this setting to be controlled via configuration, we are more in line with other similar settings that can be configured that way. The redaction logic is an example, as is the tracer and tracer parameters which were added recently.

Related:

• [Instrumentation.Http][Instrumentation.AspNetCore] Fix url.full and url.query attribute values #5532
• [Instrumentation.AspNet][Instrumentation.Owin] Redact query parameters opentelemetry-dotnet-contrib#1656
• Support for OTEL_TRACES_SAMPLER and OTEL_TRACES_SAMPLER_ARG #3601

[cijothomas]

Unless we do something OTEL_DOTNET_ something, we need to wait for spec, which has put hold on adding new env variables for now...

[julealgon]

Unless we do something OTEL_DOTNET_ something, we need to wait for spec, which has put hold on adding new env variables for now...

I'd be totally ok with that. We are in a state where changing these later would not incur too much maintenance overhead. Even if its a separate variable one for each instrumentation that supports it.

[github-actions]

This issue was marked stale due to lack of activity and will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. This bot runs once per day.

[julealgon]

This issue was marked stale due to lack of activity and will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. This bot runs once per day.

I still very much need this setting.

[github-actions]

This issue was marked stale due to lack of activity and will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. This bot runs once per day.

[julealgon]

@martincostello / @cijothomas , will the new "declarative configuration" initiative end up being a solution to this?

• https://github.com/open-telemetry/opentelemetry-configuration

My understanding is that this would allow one to configure basically any aspect of OTEL externally, which would invariably include the RecordException setting?

I assume the .NET team would be interested in fully supporting that config spec via equivalent IConfiguration-based settings?

I've not looked too deep into that effort yet so forgive me if these assumptions are not correct.

[cijothomas]

The idea of reporting Exceptions via ActivityEvent/SpanEvent itself might be discouraged in future, and it'll be instead done via OTel Logs/Events. There are some PRs trying to sort this out in the spec/conventions repo.

For .NET, since ILogger can be controlled easily via IConfiguration, this particular issue might become less relevant, once exception reporting moves to ILogger completely.

Not a direct answer to you question, but sharing something closely related to that. (I haven't spend enough time on declarative config to give firm answer related to that, sorry!)

[cijothomas]

open-telemetry/semantic-conventions#3256 active PR on RecordException/related.