[go: nahoru, domu]

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

feat(bigtable): logging for bulk apply throttling #13488

Merged
merged 2 commits into from
Jan 22, 2024

Conversation

dbolduc
Copy link
Member
@dbolduc dbolduc commented Jan 19, 2024

Fixes #13487


This change is Reviewable

@product-auto-label product-auto-label bot added the api: bigtable Issues related to the Bigtable API. label Jan 19, 2024
Copy link
codecov bot commented Jan 19, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (272adef) 93.13% compared to head (f014ac3) 93.14%.
Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #13488   +/-   ##
=======================================
  Coverage   93.13%   93.14%           
=======================================
  Files        2185     2185           
  Lines      190474   190501   +27     
=======================================
+ Hits       177407   177436   +29     
+ Misses      13067    13065    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member
@scotthart scotthart left a comment

Choose a reason for hiding this comment

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

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @dbolduc)

@dbolduc dbolduc merged commit 2a36014 into googleapis:main Jan 22, 2024
61 checks passed
@dbolduc dbolduc deleted the bigtable-logging-throttling branch January 22, 2024 20:29
if (internal::Contains(options.get<TracingComponentsOption>(), "rpc")) {
sleeper = [sleeper = std::move(sleeper)](duration d) {
if (d != duration::zero()) {
GCP_LOG(DEBUG) << "Throttling BulkApply for " << absl::FromChrono(d);

Choose a reason for hiding this comment

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

I think ideally we would have a callback here so we can capture time sleeping to report at a higher level then actual library (or expose an accessor for this information).

Copy link
Member Author
@dbolduc dbolduc Jan 26, 2024

Choose a reason for hiding this comment

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

Ok. We left the option to enable mutation throttling as experimental, so we can change it to better support your use case.

So logging is not enough observability? Does your application want to make real time decisions based on the throttling?

It would be easy enough to take some object from the application and hold it in the limiter. We will just need to decide what that object is. Let's continue the discussion internally.

namespace google::cloud::bigtable::experimental {
struct BulkApplyThrottlingConfig {
  // TODO : what goes in here? e.g. a callback?
  std::function<void(std::chrono::system_clock::duration)> callback_ = [] (auto d) {};
};

struct BulkApplyThrottlingOption {
  using Type = BulkApplyThrottlingConfig;
};
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: bigtable Issues related to the Bigtable API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Logging for Bigtable mutation throttling
3 participants