-
Notifications
You must be signed in to change notification settings - Fork 440
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
[WIP] Synchronous Gauge #2341
Conversation
Codecov Report
Additional details and impacted files@@ 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
|
#if OPENTELEMETRY_ABI_VERSION_NO >= 2 | ||
kGauge, | ||
#endif |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
/** | ||
* 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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this 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.
Thanks for the comments. Need to add unit-tests before making it ready now. |
<< instrument_descriptor_.name_); | ||
return; | ||
} | ||
return storage_->RecordLong(value, *attributes, *context); |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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}; |
There was a problem hiding this comment.
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
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++? |
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? |
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