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 SDK: View API #1110

Merged
merged 28 commits into from
Dec 27, 2021
Merged

Metrics SDK: View API #1110

merged 28 commits into from
Dec 27, 2021

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Dec 3, 2021

Fixes #1088

Changes

  • Implements View API: View, View Registry, InstrumentSelector, MeterSelector
  • Placeholder for Aggregator and Aggregation.

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

@lalitb lalitb requested a review from a team December 3, 2021 08:37
@lalitb lalitb marked this pull request as draft December 3, 2021 08:37
@codecov
Copy link

codecov bot commented Dec 6, 2021

Codecov Report

Merging #1110 (5e14816) into main (de276f5) will decrease coverage by 0.11%.
The diff coverage is 88.33%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1110      +/-   ##
==========================================
- Coverage   93.36%   93.26%   -0.10%     
==========================================
  Files         165      173       +8     
  Lines        6233     6362     +129     
==========================================
+ Hits         5819     5933     +114     
- Misses        414      429      +15     
Impacted Files Coverage Δ
...ntelemetry/sdk/metrics/view/attributes_processor.h 0.00% <0.00%> (ø)
...clude/opentelemetry/sdk/metrics/view/aggregation.h 33.34% <33.34%> (ø)
sdk/include/opentelemetry/sdk/metrics/view/view.h 63.64% <63.64%> (ø)
...include/opentelemetry/sdk/metrics/view/predicate.h 72.73% <72.73%> (ø)
...opentelemetry/sdk/metrics/view/predicate_factory.h 77.78% <77.78%> (ø)
...ude/opentelemetry/sdk/metrics/view/view_registry.h 93.55% <93.55%> (ø)
...entelemetry/sdk/metrics/view/instrument_selector.h 100.00% <100.00%> (ø)
...de/opentelemetry/sdk/metrics/view/meter_selector.h 100.00% <100.00%> (ø)
sdk/src/metrics/meter_context.cc 40.00% <100.00%> (ø)
sdk/src/metrics/meter_provider.cc 78.79% <100.00%> (+0.67%) ⬆️
... and 4 more

@lalitb lalitb marked this pull request as ready for review December 8, 2021 21:07
@lalitb lalitb changed the title [WIP] Metrics SDK: View API Metrics SDK: View API Dec 8, 2021
@lalitb lalitb mentioned this pull request Dec 10, 2021
3 tasks
@lalitb
Copy link
Member Author

lalitb commented Dec 13, 2021

@jsuereth - As @reyang is on vacation this month, would need your help on reviewing this. This is still not the final code and will change as we progress further on Aggregation and Aggregator APIs.

# if HAVE_WORKING_REGEX
return std::regex_match(str.data(), reg_key_);
# else
return false; // not supported
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like this should fail in some fashion.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this will be supported eventually. For now, we can add the LOG_ERROR to log the error while returning false.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added LOG_ERROR. Let me know if you have a better way to fail. This will eventually return a default View. We don't throw exceptions in sdk. Let me know if you have a better way to fail.

Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

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

Overall looks great!

  • One major comment on default view name/description (the default metric from an instrument with new view is its "natural" aggregation (marked TODO) and the instrument name/description)
  • A couple questions/nits that can get resolved as implementation/benchmarking land to think about.


class DefaultAttributesProcessor : public AttributesProcessor
{
MetricAttributes process(
Copy link
Contributor

Choose a reason for hiding this comment

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

IIUC - by necessity, this API will need to take in an Iterator and return a concrete object. It's likely this would get used on the "hot path" of metrics. Does it make sense to have this API work only against AttributeMap, that way in the event you're just passing it through, there isn't a sort + unique step (I forget the details of attribute map).

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, your understanding is correct here. The metrics API takes non-owning KeyValueIterable object as here, and the plan is to make a copy of this only when required in hot-path. Attribute-processor could be one of the places to create a copy in case of passthrough.

Copy link
Contributor

Choose a reason for hiding this comment

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

I expect this to (commonly) be a passthrough case. Can deal with it after initial implementation :)

public:
PatternPredicate(opentelemetry::nostd::string_view pattern) : reg_key_{pattern.data()}
{
if (pattern == "*")
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think you need to support * in all your predicates. You could have ONE predicate which is the "star" predicate and then a "predicate factory" that returns either a new PatternPredicate or MatchEverything predicate, if you wanted.

Only commenting because I noticed this logic duplicate in the "ExactPredicate" code as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. Will change accordingly.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is changed now.

// return default view if none found;
if (!found)
{
static View view(kDefaultViewName, kDefaultViewDescription);
Copy link
Contributor

Choose a reason for hiding this comment

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

[blocking] The default name and description should come from the instrument descriptor's name/description.

Copy link
Member Author

@lalitb lalitb Dec 15, 2021

Choose a reason for hiding this comment

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

Should we instead return default view ( with empty name and description ) as done in Java here ? This will allow us to return a default static immutable object always when a view is not found.

Copy link
Member Author

Choose a reason for hiding this comment

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

Have made changes as per my suggestion above. Let me know if that works.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I see, you're planning to then select the name of the metric by checking for empty description or empty name.

I understand wanting to keep this static. You'll need to either use Java's "MetricDescriptor" trick to figure out what to name the underlying metric, or keep this logic elsewhere.

That's entirely reasonable to do, but remember you'll still be instantiating something to remember the name/description of the resulting metric. For C++ it may be easier to do so view the View object, but you can decide once you work on the "storage" aspect of views :)

// return default view if none found;
if (!found)
{
static View view("");
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this still pull name/description from the instrument?

@lalitb lalitb merged commit 09fb4e0 into open-telemetry:main Dec 27, 2021
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.

Metrics SDK : Add Views
3 participants