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

Metrics: FilteringAttributesProcessor has no effect #2468

Closed
duncanpo opened this issue Dec 21, 2023 · 0 comments · Fixed by #2472
Closed

Metrics: FilteringAttributesProcessor has no effect #2468

duncanpo opened this issue Dec 21, 2023 · 0 comments · Fixed by #2472
Assignees
Labels
bug Something isn't working triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@duncanpo
Copy link

Describe your environment
I am using Windows, and building with Visual Studio 2019

Steps to reproduce
This issue can be reproduced by making some small changes to the "metrics_simple" example. Replace the files examples/metrics_simple/metrics_ostream.cc and examples/common/metrics_foo_library/foo_library.cc with the attached version. The new files simply add a FilteringAttributesProcessor to the counter View, which should filter out one of the two attributes. Build the example and run.

What is the expected behavior?
I expect to see only the "Group" attribute in the output, as "Subgroup" attribute should have been dropped.

What is the actual behavior?
I see both "Group" and "Subgroup" attributes in the output, which is the same output if I have not included the FilteringAttributesProcessor.

Additional context
I looked into the code. The problem seems to be in sdk/metrics/state/sync_metric_storage.h, in functions RecordLong and RecordDouble. The attribute processor is only used when generating the hash, which seems insufficient. Later on, in the call to GetOrSetDefault, the unfiltered attributes are used. This seems to override any effect of the attribute processor.

foo_library.cc.txt
metrics_ostream.cc.txt

@duncanpo duncanpo added the bug Something isn't working label Dec 21, 2023
@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Dec 21, 2023
@lalitb lalitb self-assigned this Dec 21, 2023
@marcalff marcalff added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants