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

Fix: 1712 - Validate Instrument meta data (name, unit, description) #1713

Merged
merged 11 commits into from
Oct 27, 2022

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Oct 26, 2022

Fixes #1712

Changes

  • Create valid instrument if the meta data is validated
  • Else, create noop-instrument.

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 October 26, 2022 07:00
@codecov
Copy link

codecov bot commented Oct 26, 2022

Codecov Report

Merging #1713 (c5ef46d) into main (e785f5f) will decrease coverage by 0.50%.
The diff coverage is 30.77%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1713      +/-   ##
==========================================
- Coverage   86.28%   85.79%   -0.49%     
==========================================
  Files         169      171       +2     
  Lines        5160     5212      +52     
==========================================
+ Hits         4452     4471      +19     
- Misses        708      741      +33     
Impacted Files Coverage Δ
...include/opentelemetry/sdk/metrics/view/predicate.h 72.73% <ø> (ø)
sdk/src/metrics/meter.cc 45.79% <8.34%> (-10.37%) ⬇️
sdk/include/opentelemetry/sdk/metrics/meter.h 57.15% <57.15%> (ø)
sdk/src/metrics/instrument_metadata_validator.cc 100.00% <100.00%> (ø)
ext/src/http/client/curl/http_client_curl.cc 81.44% <0.00%> (+1.14%) ⬆️

OTEL_INTERNAL_LOG_ERROR("Meter::CreateUInt64Counter - failed. Invalid parameters."
<< name << " " << description << " " << unit);
return nostd::unique_ptr<metrics::Counter<uint64_t>>(
new metrics::NoopCounter<uint64_t>(name, description, unit));
Copy link
Member

Choose a reason for hiding this comment

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

The calling instrumented application will not notice the error if returning a noop counter.

Not crashing now with a noop is not helping.
Instead, bugs will be filed later against opentelemetry-cpp about instrument that produce no data.

How about returning a nullptr, forcing the calling application to do something about it ?

Copy link
Member Author

@lalitb lalitb Oct 26, 2022

Choose a reason for hiding this comment

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

Yes, good point. I too thought about it, but also felt that making critical application crash for some issue in telemetry configuration is not a good idea. We can also be more explicit in error message stating that measurements won't be recorded.

This is also inline with the general error handling guidelines -

Whenever API call returns values that is expected to be non-null value - in case of error in processing logic - SDK MUST return a "no-op" or any other "default" object that was (ideally) pre-allocated and readily available. This way API call sites will not crash on attempts to access methods and properties of a null objects.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the details. Ok with noop then.

@@ -90,6 +90,14 @@
# define OPENTELEMETRY_DEPRECATED_MESSAGE(msg)
#endif

// Regex support
#if (__GNUC__ == 4 && (__GNUC_MINOR__ == 8 || __GNUC_MINOR__ == 9))
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: GNUC_MINOR >= 8?

Copy link
Member Author

Choose a reason for hiding this comment

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

The regex support is partially implemented for gcc 4.8 and gcc 4.9 only. So the existing condition looks good to me.

Copy link
Member Author

@lalitb lalitb Oct 26, 2022

Choose a reason for hiding this comment

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

But yeah, even GNUC_MINOR >= 8 should work fine. But let it be explicit. This was already existing in predicate.h, I just moved it here at common place :)

# if HAVE_WORKING_REGEX
: name_reg_key_{kInstrumentNamePattern}, unit_reg_key_
{
kInstrumentUnitPattern
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this line formatted by clang-format? The format looks a little weird.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah clang-format behaved weirdly here. I have disable the clang-format for this block of code. Looks better now.
Thanks for noticing.

kInstrumentUnitPattern
}
# endif
{}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be put under #else block?

Copy link
Member Author

Choose a reason for hiding this comment

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

no it's fine actually. The part of code was somewhat confusing with clang-format. It should be more clear now.

{
return false;
}
// first char should be alphanumeric
Copy link
Contributor

Choose a reason for hiding this comment

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

First char should be alpha, not alphanumeric?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah good point. fixed the comment.

@@ -52,6 +61,14 @@ nostd::unique_ptr<metrics::Counter<double>> Meter::CreateDoubleCounter(
nostd::string_view description,
nostd::string_view unit) noexcept
{
if (!ValidateInstrument(name, description, unit))
{
OTEL_INTERNAL_LOG_ERROR("Meter::CreateDoubleCounter - failed. Invalid parameters."
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: probably use macro __func__ to avoid hard code function name in string liternal.

Copy link
Member Author

@lalitb lalitb Oct 27, 2022

Choose a reason for hiding this comment

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

yes, probably we can modify OTEL_INTERNAL_* macros to automatically add class and method name to the logs. Will create a separate issue for this.

}
}

TEST(InstrumentMetadataValidator, TestUnit)
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing unit test on description?

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't have any validation checks for the description, so no tests added for it.

@lalitb lalitb merged commit dd7e257 into open-telemetry:main Oct 27, 2022
ays7 added a commit to ays7/opentelemetry-cpp that referenced this pull request Oct 29, 2022
…ad-local-stack

* commit '9acde87b08b225ce511fa8a20c6cba14f2921518': (36 commits)
  Prepare v1.7.0 release with Metrics API/SDK GA. (open-telemetry#1721)
  Fix: 1712 -  Validate Instrument meta data (name, unit, description) (open-telemetry#1713)
  Document libthrift 0.12.0 doesn't work with Jaeger exporter (open-telemetry#1714)
  Fix:1674, Add Monotonic Property to Sum Aggregation, and unit tests for Up Down Counter (open-telemetry#1675)
  [Metrics SDK] Move Metrics Exemplar processing behind feature flag (open-telemetry#1710)
  [Metrics API/SDK] Change Meter API/SDK to return nostd::unique_ptr for Sync Instruments (open-telemetry#1707)
  [Metrics] Switch to explicit 64 bit integers (open-telemetry#1686)
  Add metrics e2e test to asan & tsan CI (open-telemetry#1670)
  Add otlp-grpc example bazel (open-telemetry#1708)
  [Metrics SDK] Add support for Pull Metric Reader (open-telemetry#1701)
  Fix debug log of OTLP HTTP exporter and ES log exporter (open-telemetry#1703)
  [SEMANTIC CONVENTIONS] Upgrade to version 1.14.0 (open-telemetry#1697)
  Fix a potential precision loss on integer in ReservoirCellIndexFor (open-telemetry#1696)
  fix Histogram crash (open-telemetry#1685)
  Fix:1676 Segfault when short export period is used for metrics  (open-telemetry#1682)
  Add timeout support to MeterContext::ForceFlush (open-telemetry#1673)
  Add CMake OTELCPP_MAINTAINER_MODE (open-telemetry#1650)
  [DOCS] - Minor updates to OStream Metrics exporter documentation (open-telemetry#1679)
  Fix:open-telemetry#1575 API Documentation for Metrics SDK and API (open-telemetry#1678)
  Fixes open-telemetry#249 (open-telemetry#1677)
  ...
yxue pushed a commit to yxue/opentelemetry-cpp that referenced this pull request Dec 5, 2022
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] - Validate Instrument meta data (name, unit, description)
3 participants