Skip to content

[SDK] Implement spec: MetricFilter #3235

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

Merged
merged 5 commits into from
Mar 11, 2025

Conversation

IcySteam
Copy link
Contributor

@IcySteam IcySteam commented Jan 9, 2025

Fixes #2447

Changes

This PR implements the MetricFilter spec in opentelemetry-cpp.

For significant contributions please make sure you have completed the following items:

  • CHANGELOG.md updated for non-trivial changes
  • Unit tests have been added
  • Changes in public API reviewed
    • MetricProducer::MetricProducer
    • MetricCollector::MetricCollector
    • MeterContext::AddMetricReader
    • MeterProvider::AddMetricReader

@IcySteam IcySteam requested a review from a team as a code owner January 9, 2025 11:15
Copy link

linux-foundation-easycla bot commented Jan 9, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

Copy link

netlify bot commented Jan 9, 2025

Deploy Preview for opentelemetry-cpp-api-docs canceled.

Name Link
🔨 Latest commit 8d47981
🔍 Latest deploy log https://app.netlify.com/sites/opentelemetry-cpp-api-docs/deploys/67d0b52ec5a8e40009fd0e8d

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 3 times, most recently from bbd4ca5 to 9e8e4b7 Compare January 9, 2025 11:54
@marcalff marcalff added the pr:waiting-on-cla Waiting on CLA label Jan 9, 2025
@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 4 times, most recently from d6f5504 to 1473ebe Compare January 11, 2025 16:49
@marcalff
Copy link
Member

@IcySteam

Thanks for the PR.

Please remember to sign the EasyCLA, so this PR can be processed.

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 3 times, most recently from e0d8498 to 9c3f930 Compare January 12, 2025 10:38
Copy link

codecov bot commented Jan 12, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.49%. Comparing base (64a74bf) to head (8d47981).
Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3235      +/-   ##
==========================================
+ Coverage   89.41%   89.49%   +0.08%     
==========================================
  Files         207      208       +1     
  Lines        6458     6497      +39     
==========================================
+ Hits         5774     5814      +40     
+ Misses        684      683       -1     
Files with missing lines Coverage Δ
...e/opentelemetry/sdk/metrics/export/metric_filter.h 100.00% <100.00%> (ø)
...opentelemetry/sdk/metrics/export/metric_producer.h 100.00% <100.00%> (ø)
...opentelemetry/sdk/metrics/state/metric_collector.h 100.00% <ø> (ø)
sdk/src/metrics/meter_context.cc 77.34% <100.00%> (ø)
sdk/src/metrics/meter_provider.cc 87.18% <100.00%> (ø)
sdk/src/metrics/state/metric_collector.cc 93.23% <100.00%> (+6.13%) ⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 3 times, most recently from a36ed14 to a4384fa Compare January 13, 2025 16:08
@marcalff marcalff removed the pr:waiting-on-cla Waiting on CLA label Jan 13, 2025
@lalitb
Copy link
Member

lalitb commented Jan 16, 2025

@IcySteam Thanks for the PR. I believe you are working to get the CLA signed, as the PR can't be reviewed without that.

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from a4384fa to 4bff481 Compare January 17, 2025 18:45
@IcySteam
Copy link
Contributor Author

Thanks for the reminder @marcalff and @lalitb, CLA signing should be all done now.

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from 4bff481 to 7b19eb4 Compare January 18, 2025 05:50
Copy link
Member

@marcalff marcalff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, and for signing the CLA.

Before looking in more details at the code,
please see some preliminary comments below.

There should be no changes in third_party/opentelemetry-proto.

Please make sure to initialize and update git submodules in your branch.

Please check the "include-what-you-use" build in CI for warnings,
and fix the code to resolve them.

There should be no more warnings in the PR compared to the main branch.

More comments to follow.

@marcalff marcalff self-assigned this Jan 22, 2025
@lalitb lalitb self-assigned this Jan 24, 2025
void AddMetricReader(std::shared_ptr<MetricReader> reader) noexcept;
std::shared_ptr<MetricCollector> AddMetricReader(
std::shared_ptr<MetricReader> reader,
std::unique_ptr<MetricFilter> metric_filter = nullptr) noexcept;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was righty pointed out by @marcalff in community meeting - does this method need to return shared_ptr?

Copy link
Member

@lalitb lalitb Jan 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IcySteam It looks like you've now changed it to return a weak_ptr. Sorry I was not clear earlier, the question was—why does this method need to return anything at all?

Copy link
Contributor Author

@IcySteam IcySteam Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lalitb Returning the MetricCollector created by the MeterContext does seem like one of the only few ways to access the MetricCollector, as it is needed by MetricCollectorTest. Extending MetricCollector with a test class is also potentially viable, but that would require changing some of MetricCollector's private members to protected (or a friend class). What are your thoughts on writing proper tests in this case?

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 2 times, most recently from 72cbd97 to de7b80e Compare January 29, 2025 04:43
@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from de7b80e to 0421775 Compare February 3, 2025 15:09
@IcySteam
Copy link
Contributor Author

IcySteam commented Feb 4, 2025

@lalitb Thanks for approving the CI workflows as always; for some reason, cmake.dll.test still fails due to apparently -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed. Is this a bug with the CI workflow, since nothing I changed in this PR should affect it? How could I fix this?

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from ca24682 to 0c944f1 Compare February 11, 2025 05:43
@IcySteam
Copy link
Contributor Author

Hi @lalitb, I've pushed another commit which uses a MetricCollectorTest friend class instead of changing MeterContext's AddMetricReader. PTAL

@lalitb
Copy link
Member

lalitb commented Feb 11, 2025

Hi @lalitb, I've pushed another commit which uses a MetricCollectorTest friend class instead of changing MeterContext's AddMetricReader. PTAL

Thanks @IcySteam can you also resolve the conflict, so that CI can be triggered. I will be reviewing it during this week.

@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch 2 times, most recently from eea4047 to 8fa2622 Compare February 14, 2025 04:31
@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from 8fa2622 to 8dd3291 Compare February 19, 2025 05:03
@IcySteam IcySteam force-pushed the otel-metricfilter-fn branch from 8dd3291 to 085ad96 Compare March 3, 2025 02:36
@IcySteam
Copy link
Contributor Author

IcySteam commented Mar 3, 2025

Hi @lalitb, I've resolved the merge conflicts from the latest upstream changes. Have you had the chance to review the PR yet? Thanks.

@lalitb
Copy link
Member

lalitb commented Mar 4, 2025

Hi @lalitb, I've resolved the merge conflicts from the latest upstream changes. Have you had the chance to review the PR yet? Thanks.

Thanks @IcySteam. Couldn't review it for other priorities, will do it this week.

auto context = std::shared_ptr<MeterContext>(new MeterContext(ViewRegistryFactory::Create()));
auto scope = InstrumentationScope::Create("CollectWithMetricFilterTestMetricTest1");
auto meter = std::shared_ptr<Meter>(new Meter(context, std::move(scope)));
context->AddMeter(meter);
Copy link
Member

@lalitb lalitb Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit - there can be a helper method to create Meter, and used across tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment; since context and meter are directly needed by the test code below, creating a helper method here to create meter might not simplify much. We could use a common meter between test cases, but that would require us to make sure there are no duplicate instrument names. Do you think it would be better if we used a common meter?

Copy link
Member

@lalitb lalitb Mar 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I believe we can leave it as for now, and can improve later.

if (attributes_filter_result == MetricFilter::AttributesFilterResult::kAccept)
{
filtered_point_data_attrs.emplace_back(std::move(point_data_attr));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we reuse the existing vector by filtering in-place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could reuse the existing metric.point_data_attr_ here by deleting the filtered entries from it, but I think in this case it would be slower than creating a new vector and std::moveing the wanted entries to it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. This looks good.

Copy link
Member

@lalitb lalitb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for implementing this.

Copy link
Member

@marcalff marcalff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the feature.

@marcalff marcalff merged commit dee5b0b into open-telemetry:main Mar 11, 2025
58 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SDK] Add predicate to MetricReader and MetricProducer
3 participants