-
Notifications
You must be signed in to change notification settings - Fork 772
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
Duplicate Log Attribute Keys #4324
Comments
Deduplication is going to be expensive. The OTLP proto does not validate (its basically List and not a Map), so the onus is on the upstream to avoid duplicates.
It is not an oversight, this was considered in the PR itself https://github.com/open-telemetry/opentelemetry-dotnet/pull/3843/files#diff-e28eaa16d5ac47130740a2783c474f316e9a1699aa3ada3a537951246e7cf517R172 Also, scopes is not the only way one can have duplicates. Logger.LogInfo("hello from {fruit} {fruit} {fruit}", "apple", "banana", "mango"); can also cause duplicates. |
@c4brei btw, excellent write up with clear description and repro steps! |
Tagged it for the OTLP Log Exporter stable release milestone. We could end up with not doing anything (and just ask users to not produce duplicate attributes), or provide opt-in mechanism to dedup. |
Thank you for the quick answer :) The mentioned option to deduplicate Attributes would be very helpful. In a larger project it will be difficult to enforce or remind everyone to use attributes with care. |
Some additional ideas that might be helpful when this topic comes around for the stable release Adjust attribute serialization order
Option to disable export of Attributes defined in a LogMessage
|
This defeats the purpose of structured logging by putting everything into a string, so this should be discouraged.! |
…map as opt-in (#3987) Fixes #3931 Per agreement: #3931 (comment) > The SDKs should handle the key-value deduplication by default. It is acceptable to add an option to disable deduplication. Previous PR: #3938 > I think it is fine to do the deduplication anywhere you want as long as externally observable data complies with this document. The main purpose of this PR is to have an agreement for following questions (and update the specification to to make it more clear): 1. Is the deduplication required for all log exporters or only OTLP log exporters? Answer: It is required for all exporters. 2. Can the key-value deduplication for log records be opt-in? Answer: Yes, it is OK as long as it is documented that it can cause problems in case maps duplicated keys are exported. Related to: - open-telemetry/opentelemetry-go#5086 - open-telemetry/opentelemetry-dotnet#4324
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. |
…map as opt-in (open-telemetry#3987) Fixes open-telemetry#3931 Per agreement: open-telemetry#3931 (comment) > The SDKs should handle the key-value deduplication by default. It is acceptable to add an option to disable deduplication. Previous PR: open-telemetry#3938 > I think it is fine to do the deduplication anywhere you want as long as externally observable data complies with this document. The main purpose of this PR is to have an agreement for following questions (and update the specification to to make it more clear): 1. Is the deduplication required for all log exporters or only OTLP log exporters? Answer: It is required for all exporters. 2. Can the key-value deduplication for log records be opt-in? Answer: Yes, it is OK as long as it is documented that it can cause problems in case maps duplicated keys are exported. Related to: - open-telemetry/opentelemetry-go#5086 - open-telemetry/opentelemetry-dotnet#4324
Question
Use Github Discussions.
Currently when using Logging attributes in Scope and LogMessage I observed, that the dotnet exporter exports every attribute not just the latest occurrence.
In this example
fooAttr
is added 3 times to the attribute listOutput of ConsoleLogExporter:
OpenTelemetry Collector receives list with duplicate attribute keys:
This could be an unintentional side effect from the removal of the scope depth prefix (#3843).
It seems that during serialization, first all attributes from the log message then all attributes from the scopes are serialized (beginning with the oldest scope). But no deduplication is done during this process.
The specification describes Log-Attributes to be a 'map<string, any>' where attribute keys are unique (data-model.md). Currently the actual output seems to be only a serialized list.
Is this behavior intended and the specification incomplete or is this behavior a Bug?
Additional Context
Depending on a receiving backend tool the attribute list may be interpreted differently. I.e. in Loki only the last occurrence of an attribute is parsed ->
fooAttr
isdef - scope1
instead ofghi - log msg
Reproduce
Using
net6.0
and the following OpenTelemetry NuGet-PackagesThe text was updated successfully, but these errors were encountered: