[resource host+process] Allow host name and process owner attributes to be excluded
Changes
Process owner and Host name may contain private data, so there has to be a way to not include them as part of the telemetry record.
In order to achieve this, I'm adding an extra parameter to AddHostDetector and AddProcessDetector that allows consumers on the detectors to control whether or not this data will be added to the Resource.
Merge requirement checklist
- [x] CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
- [x] Unit tests added/updated
- [x] Appropriate
CHANGELOG.mdfiles updated for non-trivial changes - [x] Changes in public API reviewed (if applicable)
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 77.03%. Comparing base (
71655ce) to head (99cbf77). Report is 542 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #2084 +/- ##
==========================================
+ Coverage 73.91% 77.03% +3.12%
==========================================
Files 267 5 -262
Lines 9615 135 -9480
==========================================
- Hits 7107 104 -7003
+ Misses 2508 31 -2477
| Flag | Coverage Δ | |
|---|---|---|
| unittests-Resources.Host | 74.79% <100.00%> (?) |
|
| unittests-Resources.Process | 100.00% <100.00%> (?) |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Files with missing lines | Coverage Δ | |
|---|---|---|
| src/OpenTelemetry.Resources.Host/HostDetector.cs | 78.57% <100.00%> (ø) |
|
| ...ry.Resources.Host/HostResourceBuilderExtensions.cs | 100.00% <100.00%> (ø) |
|
| ...OpenTelemetry.Resources.Process/ProcessDetector.cs | 100.00% <100.00%> (ø) |
|
| ...ources.Process/ProcessResourceBuilderExtensions.cs | 100.00% <100.00%> (ø) |
Related: https://github.com/open-telemetry/opentelemetry-specification/issues/4218
Note for myself from https://opentelemetry.io/docs/specs/semconv/general/attribute-requirement-level/#recommended:
Instrumentations SHOULD add the attribute by default if it’s readily available and can be efficiently populated. Instrumentations MAY offer a configuration option to disable Recommended attributes.
Instrumentations that decide not to populate Recommended attributes due to performance, security, privacy, or other consideration by default, SHOULD allow for users to opt-in to emit them as defined for the Opt-In requirement level (if the attributes are logically applicable)
There is couple types of the resources
- Required - always should be available
- Conditionally required - always should be available
- Recommended - it MAY be possibility to opt-out
- Opt-in - it may be possibility to opt-in
Host resource detector sem conv contains 7 recommended and 2 Opt-in attributes. Not all of them are implemented here.
I think that we need better to expose this publicly (not on the merge level, it can be on adding method). Adding ~9 boolean attributes is not good idea IMO.
Maybe we should have
Somethin like:
public static ResourceBuilder AddProcessDetector(this ResourceBuilder builder, IEnumerable<string> optOutAttributes, Enumerable<string> optInAttributes)
or
public static ResourceBuilder AddProcessDetector(this ResourceBuilder builder, IEnumerable<HostOptOutAttribute> optOutAttributes, Enumerable<HostOptInAttribute> optInAttributes)?
If operate on strings - what should happen when someone want to disable Required attribute or is passing attribute not supported by the given resource detectot?
It will be great to give it also possibility to configure it from env vars to make it AutoInstrumentation friendly.
@Kielek Personally I'm not a fan of APIs which rely on magic strings. Could we do something more strongly typed?
public static class HostResourceBuilderExtensions
{
public static ResourceBuilder AddHostDetector(this ResourceBuilder builder) {}
public static ResourceBuilder AddHostDetector(this ResourceBuilder builder, Action<HostResourceOptions> configure) {}
}
public sealed class HostResourceOptions
{
internal HostResourceOptions(IConfiguration configuration)
{
var config = configuration.GetValue("OTEL_DOTNET_HOST_RESOURCE_ATTRIBUTES", (string?)null);
if (config != null)
{
// TODO: Parse config and apply onto bools (somehow)
}
}
#region Recommended (on by default)
public bool IncludeArchitecture { get; set; } = true;
public bool IncludeId { get; set; } = true;
public bool IncludeImageId { get; set; } = true;
public bool IncludeImageName { get; set; } = true;
public bool IncludeImageVersion { get; set; } = true;
public bool IncludeName { get; set; } = true;
public bool IncludeType { get; set; } = true;
#endregion
#region Opt-In (off by default)
public bool IncludeIpAddress { get; set; }
public bool IncludeMacAddress { get; set; }
#endregion
}
@flaviocdc, could you please follow @CodeBlanch description? At least for already implemented resources? Please update also README.md with example how to use this option.
I agree with the idea of using configurations through options. I suggest doing the same for the remaining resources. @flaviocdc, please update comment by adding https://github.com/open-telemetry/opentelemetry-specification/issues/4218
This PR was marked stale due to lack of activity. It will be closed in 7 days.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
Closed as inactive. Feel free to reopen if this PR is still being worked on.