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

[SDK] Implement Forceflush for Periodic Metric Reader #2064

Merged
merged 16 commits into from
Mar 27, 2023

Conversation

lalitb
Copy link
Member

@lalitb lalitb commented Mar 16, 2023

Fixes #2056

Changes

As of now, Periodic Metric reader tries to perform one last collection and export during Shutdown. And this fetch fails with warning that the Shutdown is already in progress.

The correct approach should be NOT to do this fetch during shutdown, instead implement PeriodicMetricReader::ForceFlush() method to perform the fetch whenever invoked by application. And then application can just invoke this method before doing the shutdown.

WIP as need to add the unit-tests for this.

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 March 16, 2023 21:47
@codecov
Copy link

codecov bot commented Mar 16, 2023

Codecov Report

Merging #2064 (1b1bce9) into main (380f0f2) will increase coverage by 0.02%.
The diff coverage is 81.40%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2064      +/-   ##
==========================================
+ Coverage   87.17%   87.19%   +0.02%     
==========================================
  Files         166      166              
  Lines        4746     4784      +38     
==========================================
+ Hits         4137     4171      +34     
- Misses        609      613       +4     
Impacted Files Coverage Δ
...metrics/export/periodic_exporting_metric_reader.cc 79.35% <81.40%> (+5.28%) ⬆️

... and 1 file with indirect coverage changes

@lalitb lalitb changed the title [WIP] Implement Forceflush operation for Periodic Metric Reader [WIP] Implement Forceflush for Periodic Metric Reader Mar 17, 2023
@lalitb
Copy link
Member Author

lalitb commented Mar 21, 2023

This is ready for review now.

@lalitb lalitb changed the title [WIP] Implement Forceflush for Periodic Metric Reader [Metrics SDK] Implement Forceflush for Periodic Metric Reader Mar 21, 2023
@lalitb lalitb requested review from ThomsonTan and esigo March 21, 2023 00:30
@lalitb
Copy link
Member Author

lalitb commented Mar 21, 2023

@owent - Once you have time, can you shortly look into the PeriodicMetricReader::ForceFlush(), as the method is inspired from the batch span/log processor method, and you know that part of code better :)

if (result)
{

result = exporter_->ForceFlush(timeout);
Copy link
Member

Choose a reason for hiding this comment

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

Is it better to use timeout_steady if it's greater than zero here? We have already wait some time before and the left timeout should be less.

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 changed it to use timeout_steady now.

@@ -167,10 +167,36 @@ bool PeriodicExportingMetricReader::OnForceFlush(std::chrono::microseconds timeo
}

is_force_flush_notified_.store(false, std::memory_order_release);

if (timeout == std::chrono::steady_clock::duration::zero())
Copy link
Member

Choose a reason for hiding this comment

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

Do we need remove this if branch?It does nothing.

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 removed thanks.

if (timeout_steady <= std::chrono::steady_clock::duration::zero())
{
// forceflush timeout, exporter force-flush won't be triggered.
result = false;
Copy link
Member

Choose a reason for hiding this comment

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

Do we need reset result to false here?I think result will keep false and break the loop above when timeout_steady <= std::chrono::steady_clock::duration::zero().
And if result is true and timeout_steady <= std::chrono::steady_clock::duration::zero(), result will also be set to false below.

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 the while loop for wait_for will break if timeout_steady <= std::chrono::steady_clock::duration::zero() with result as false. Have removed the check. Thanks for noticing.

Copy link
Member

@owent owent left a comment

Choose a reason for hiding this comment

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

LGTM now, thanks.

cv_.wait_for(lk, remaining_wait_interval_ms, [this]() {
if (is_force_wakeup_background_worker_.load(std::memory_order_acquire))
{
is_force_wakeup_background_worker_.store(false, std::memory_order_release);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can store fail then false should be returned?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know if it can ever fail. It's atomic assignment operation so should eventually be successful. Also, this method returns void, not sure how to get any failure status from this method.
Let me know if I am missing something :)

is_force_wakeup_background_worker_.store(false, std::memory_order_release);
return true;
}
if (IsShutdown())
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: return IsShutdown();.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed. thanks

timeout_steady -= std::chrono::steady_clock::now() - start_timepoint;
}

// If it will be already signaled, we must wait util notified.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// If it will be already signaled, we must wait util notified.
// If it will be already signaled, we must wait until notified.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed. thanks.

@esigo esigo added the ok-to-merge The PR is ok to merge (has two approves or raised by a maintainer/approver and has one approve) label Mar 27, 2023
@lalitb lalitb merged commit bd7a3c7 into open-telemetry:main Mar 27, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 27, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Mar 28, 2023
@marcalff marcalff changed the title [Metrics SDK] Implement Forceflush for Periodic Metric Reader [SDK] Implement Forceflush for Periodic Metric Reader Apr 12, 2023
cngzhnp pushed a commit to cngzhnp/opentelemetry-cpp that referenced this pull request Apr 20, 2023
ays7 added a commit to ays7/opentelemetry-cpp that referenced this pull request May 18, 2023
* commit '7887d32da60f54984a597abccbb0c883f3a51649': (82 commits)
  [RELEASE] Release version 1.9.0 (open-telemetry#2091)
  Use sdk_start_ts for MetricData start_ts for instruments having cumulative aggregation temporality. (open-telemetry#2086)
  [SEMANTIC CONVENTIONS] Upgrade to version 1.20.0 (open-telemetry#2088)
  [EXPORTER] Add OTLP HTTP SSL support (open-telemetry#1793)
  Make Windows build environment parallel (open-telemetry#2080)
  make some hints (open-telemetry#2078)
  Make some targets parallel in CI pipeline (open-telemetry#2076)
  [Metrics SDK] Implement Forceflush for Periodic Metric Reader (open-telemetry#2064)
  Upgraded semantic conventions to 1.19.0 (open-telemetry#2017)
  Bump actions/stale from 7 to 8 (open-telemetry#2070)
  Include directory path added for Zipkin exporter example (open-telemetry#2069)
  Ignore more warning of generated protobuf files than not included in `-Wall` and `-Wextra` (open-telemetry#2067)
  Add `ForceFlush` for all `LogRecordExporter`s and `SpanExporter`s. (open-telemetry#2000)
  Remove unused 'alerting' section from prometheus.yml in examples (open-telemetry#2055)
  Clean warnings in ETW exporters (open-telemetry#2063)
  Fix default value of `OPENTELEMETRY_INSTALL_default`. (open-telemetry#2062)
  [EXPORTER] GRPC endpoint scheme should take precedence over OTEL_EXPORTER_OTLP_TRACES_INSECURE (open-telemetry#2060)
  Fix view names in Prometheus example (open-telemetry#2034)
  Fix some docs typo (open-telemetry#2057)
  Checking indices before dereference (open-telemetry#2040)
  ...

# Conflicts:
#	exporters/ostream/CMakeLists.txt
#	sdk/src/metrics/state/metric_collector.cc
#	sdk/src/metrics/state/temporal_metric_storage.cc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ok-to-merge The PR is ok to merge (has two approves or raised by a maintainer/approver and has one approve)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error from Metricreader::Collect at shutdown when using PeriodicExportingMetricReader
4 participants