Skip to content
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

Allow controlling RecordException setting via environment variables/IConfiguration #5570

Open
julealgon opened this issue Apr 25, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@julealgon
Copy link

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:

@julealgon julealgon added the enhancement New feature or request label Apr 25, 2024
@cijothomas
Copy link
Member

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants