[FileBasedConfiguration] Instrumentation Configuration #4492
Conversation
...emetry.AutoInstrumentation/Configurations/FileBasedConfiguration/SetDocumentConfiguration.cs
Outdated
Show resolved
Hide resolved
...strumentation.Tests/Configurations/FileBased/Files/TestInstrumentationConfigurationFile.yaml
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.AutoInstrumentation/Configurations/FileBasedConfiguration/DotNetTraces.cs
Show resolved
Hide resolved
src/OpenTelemetry.AutoInstrumentation/Configurations/FileBasedConfiguration/DotNetMetrics.cs
Show resolved
Hide resolved
|
|
||
| foreach (var prop in properties) | ||
| { | ||
| var value = prop.GetValue(this); |
There was a problem hiding this comment.
Does this mean that if a user wants to use file-based configuration, they will have to update their file to list every single instrumentation they want to enable? Can we instead add a bool enabled property to each entry, that way individual instrumentations can easily be disabled by setting enabled: false but if an instrumentation is not listed then it's on-by-default? That feels much more user-friendly
There was a problem hiding this comment.
At the moment, it is implemented the same way as propagators and resource detectors, and this approach is compliant with the current specification. I believe we should keep the current approach until the specification changes.
There was a problem hiding this comment.
Yes, agreed that we should align with the specification. Do you have a link to the section describing the structure of those that I could look at?
There was a problem hiding this comment.
Here is spec for detectors https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml#L844
Here is spec for propagators https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml#L541
Here is spec for instrumentations https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml#L902
Created issue for disabled/enabled in spec open-telemetry/opentelemetry-configuration#334
There was a problem hiding this comment.
This behavior, even though it's in agreement with the spec does not seem like the desired behavior to me. In practice, I find that configuration files rarely get updated, and as new features are added they rarely get enabled. In this case I can see someone creating their configuration file with the current set of instrumentations. Then a couple of years later we offer more instrumentations out of the box, and the auto-instrumentation user wonders why they are not seeing that instrumentation being applied (especially if they are using the same or roughly the same configuration file template for all of their services). It's a departure from the behavior of our current environment variable, where if you specify nothing then you get all of the defaults. I'm not sure how to achieve that same behavior with this file based configuration approach.
Is there some way to remain in compliance with the current spec and offer some other experimental config that follows either the presets described in the configuration issue, or the approach used by Java in that issue?
There was a problem hiding this comment.
Besides some small non-blocking comments I wrote, one main question I have is whether we should make users list all integrations they want to use, or make all integrations on by default but configurable with an enabled flag. I'm leaning towards the second one, but I'd like to get your thoughts
|
|
||
| protected override void OnLoadFile(YamlConfiguration configuration) | ||
| { | ||
| EnabledInstrumentations = configuration.InstrumentationDevelopment?.DotNet?.Logs?.GetEnabledInstrumentations() ?? []; |
There was a problem hiding this comment.
I see that you are covering exporters but hte separate PR, but you are missing here posisiblity to enable Log4Net Bridge and incldue formatted message.
There was a problem hiding this comment.
Log4Net bridge added in 65692bc
Formatted message will be included in logger provider configuration PR.
| MetricsEnabled = configuration.GetBool(ConfigurationKeys.Metrics.MetricsEnabled) ?? true; | ||
| } | ||
|
|
||
| protected override void OnLoadFile(YamlConfiguration configuration) |
There was a problem hiding this comment.
Missing possibility to configure additionalSources.
There was a problem hiding this comment.
I think these changes enough for this PR, and additional sources will be added in a separate PR
| InstrumentationOptions = new InstrumentationOptions(configuration); | ||
| } | ||
|
|
||
| protected override void OnLoadFile(YamlConfiguration configuration) |
There was a problem hiding this comment.
missing possibility to set additional sources and legacy sources
There was a problem hiding this comment.
I think these changes enough for this PR, and additional sources will be added in a separate PR
docs/file-based-configuration.md
Outdated
| instrumentation/development: | ||
| dotnet: | ||
| traces: | ||
| aspnet: # ASP.NET (.NET Framework) MVC/WebApi [Framework only] |
There was a problem hiding this comment.
I think that you should put here a name from the config.md tables.
I would like to avoid 2 places to maintain same data.
docs/file-based-configuration.md
Outdated
| # Whether the SQL Client instrumentation can pass SQL statements through the db.statement attribute. Queries might contain sensitive information. If set to false, db.statement is recorded only for executing stored procedures. | ||
| # Not supported on .NET Framework for System.Data.SqlClient. | ||
| # Default is false | ||
| set_db_statement_for_text: false |
There was a problem hiding this comment.
Fixed in ea047c0
4 participants
Why
Towards #4394
Extracted and refactored from #4270
What
File based configuration for Instrumentations
Tests
Ci
Checklist
CHANGELOG.mdis updated.