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

[WIP] Synchronous Gauge #2341

Closed
wants to merge 16 commits into from
Closed

[WIP] Synchronous Gauge #2341

wants to merge 16 commits into from

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Sep 28, 2023

Fixes #2279 , #2155

Changes

Please provide a brief description of the changes here.

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 September 28, 2023 07:16
@lalitb lalitb marked this pull request as draft September 28, 2023 07:16
@codecov
Copy link

codecov bot commented Sep 29, 2023

Codecov Report

Merging #2341 (1248928) into main (cb603ad) will decrease coverage by 0.39%.
The diff coverage is 55.69%.

❗ Current head 1248928 differs from pull request most recent head 272f30f. Consider uploading reports for the commit 272f30f to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2341      +/-   ##
==========================================
- Coverage   87.41%   87.02%   -0.39%     
==========================================
  Files         199      199              
  Lines        6028     6036       +8     
==========================================
- Hits         5269     5252      -17     
- Misses        759      784      +25     
Files Coverage Δ
api/include/opentelemetry/metrics/meter.h 100.00% <ø> (ø)
api/include/opentelemetry/metrics/noop.h 41.18% <ø> (+3.93%) ⬆️
...i/include/opentelemetry/metrics/sync_instruments.h 100.00% <100.00%> (ø)
sdk/include/opentelemetry/sdk/metrics/meter.h 57.15% <ø> (ø)
...clude/opentelemetry/sdk/metrics/sync_instruments.h 100.00% <ø> (+19.52%) ⬆️
sdk/src/metrics/meter.cc 61.45% <100.00%> (ø)
...etry/sdk/metrics/aggregation/default_aggregation.h 70.13% <0.00%> (ø)
sdk/src/metrics/sync_instruments.cc 65.84% <53.09%> (-13.05%) ⬇️

... and 14 files with indirect coverage changes

Comment on lines 22 to 24
#if OPENTELEMETRY_ABI_VERSION_NO >= 2
kGauge,
#endif
Copy link
Member

@marcalff marcalff Sep 29, 2023

Choose a reason for hiding this comment

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

The SDK can implement more features like kGauge even when these are not reachable from ABI v1, because there is no CreateIntGauge() virtual method in the API for ABI V1.

So, it should be just fine to always declare kGauge here, without if OPENTELEMETRY_ABI_VERSION_NO >= 2.

Ideally, in the SDK, testing for OPENTELEMETRY_ABI_VERSION_NO should be only needed when overriding a virtual method, limiting the amount of ifdef to a minimum.

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. Have removed the OPENTELEMETRY_ABI_VERSION_NO from SDK where possible.

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we append kGuage at the end of the enum so other values are still backward compatible?

Comment on lines 261 to 294
/**
* Record a value
*
* @param value The increment amount. MUST be non-negative.
*/
virtual void Record(T value) noexcept = 0;

/**
* Record a value
*
* @param value The increment amount. MUST be non-negative.
* @param context The explicit context to associate with this measurement.
*/
virtual void Record(T value, const context::Context &context) noexcept = 0;

/**
* Record a value with a set of attributes.
*
* @param value The increment amount. MUST be non-negative.
* @param attributes A set of attributes to associate with the value.
*/

virtual void Record(T value, const common::KeyValueIterable &attributes) noexcept = 0;

/**
* Record a value with a set of attributes.
*
* @param value The increment amount. MUST be non-negative.
* @param attributes A set of attributes to associate with the value.
* @param context The explicit context to associate with this measurement.
*/
virtual void Record(T value,
const common::KeyValueIterable &attributes,
const context::Context &context) noexcept = 0;
Copy link
Member

@marcalff marcalff Sep 29, 2023

Choose a reason for hiding this comment

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

Here there are 4 virtual methods for the ABI, with different parameters combinations.

An alternative is to define only one virtual method for the ABI, accepting pointers instead of references:

  virtual void Record(T value,
                      const common::KeyValueIterable *attributes,
                      const context::Context *context) noexcept = 0;

and then have all the API helpers invoke this unique entry point, passing nullptr for optional parameters.

We can still have a helper like:

  void Record(T value,
                      const common::KeyValueIterable &attributes,
                      const context::Context &context) {
    this->Record(value, &attributes, &context);
  }

so that user code pass references as usual.

Making a clear distinction between the ABI (the virtual method) and the API helpers (non virtual) will help,
because it is then easier to decide if a change is a breaking change or not.

Changes to the unique ABI virtual method is a breaking change.

Changes to the plenty of API helpers accepting combinations of parameters is not breaking the ABI,
as it always forwards to the same prototype.

Copy link
Member Author

@lalitb lalitb Sep 29, 2023

Choose a reason for hiding this comment

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

A much cleaner method! Thanks for suggesting. I saw this approach in the GetMeter() PR but overlooked adding it here. Done now :)

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 taking on the implementation for Gauge.

A few early comments.

@lalitb
Copy link
Member Author

lalitb commented Sep 29, 2023

Thanks for taking on the implementation for Gauge.

A few early comments.

Thanks for the comments. Need to add unit-tests before making it ready now.

<< instrument_descriptor_.name_);
return;
}
return storage_->RecordLong(value, *attributes, *context);
Copy link
Member

Choose a reason for hiding this comment

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

Keep in mind attributes and context can be nullptr here.

Call the proper RecordLong() method, and/or use:

auto context = opentelemetry::context::Context{};

/**
* Creates a Gauge with the passed characteristics and returns a
* unique_ptr to that Gauge
* @since ABI_VERSION 2
Copy link
Contributor

Choose a reason for hiding this comment

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

Align with below @param?

}
InstrumentDescriptor instrument_descriptor = {
std::string{name.data(), name.size()}, std::string{description.data(), description.size()},
std::string{unit.data(), unit.size()}, InstrumentType::kGauge, InstrumentValueType::kLong};
Copy link

Choose a reason for hiding this comment

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

there's a small bug here, the instrument value type should be kDouble

@lalitb
Copy link
Member Author

lalitb commented Feb 21, 2024

closing as there needs a design change. Will raise a new PR.

@lalitb lalitb closed this Feb 21, 2024
@yuma-m
Copy link

yuma-m commented Jul 30, 2024

closing as there needs a design change. Will raise a new PR.

Hello @lalitb, Do you have any plan or timeline to add synchronous gauge support for OpenTelemetry SDK C++?

@lalitb
Copy link
Member Author

lalitb commented Aug 2, 2024

Hello @lalitb, Do you have any plan or timeline to add synchronous gauge support for OpenTelemetry SDK C++?

Sorry, no timeline yet. It may take a couple of months for me to get back to it. If someone picks it up meanwhile, it would be great.

@yuma-m
Copy link

yuma-m commented Aug 4, 2024

Sorry, no timeline yet. It may take a couple of months for me to get back to it. If someone picks it up meanwhile, it would be great.

@lalitb, Thank you for your answer, got it. As you've closed this as there needs a design change, are there any design documents to refer to?

@lalitb lalitb mentioned this pull request Aug 26, 2024
3 tasks
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.

Add Synchronous Gauge instrument to the metrics API/SDK
5 participants