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(storage): add metrics for iter_log #16658

Merged
merged 7 commits into from May 20, 2024
Merged

feat(storage): add metrics for iter_log #16658

merged 7 commits into from May 20, 2024

Conversation

wenym1
Copy link
Contributor

@wenym1 wenym1 commented May 9, 2024

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Add metrics for iter_log in MonitoredStateStore.

The code of MonitoredStateStoreIter is refactored so that we can reuse most monitoring code of iter. Besides the original metric of iter, we also add counter to measure the number of insert, update delete in iter_log value.

A metrics that monitoring existing concurrent iter is added by the way in this PR.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

@wenym1 wenym1 requested review from hzxa21, Li0k and xxhZs May 9, 2024 08:58
Copy link
Collaborator

@hzxa21 hzxa21 left a comment

Choose a reason for hiding this comment

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

Rest LGTM

);

let iter_in_progress_counts = register_guarded_int_gauge_vec_with_registry!(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Prior to this PR, this is protected via RelabeledCounterVec but this PR removes it. Is this expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The corresponding metrics of iter_in_process_counts in this PR is iter_counts, which is still protected by RelabeledCounterVec.

This is actually newly added metrics that monitors existing on going iterators of each table. Not sure if we should expose it in per table granularity to observe the existing number of iterators of each table.

)
.unwrap();

let iter_log_op_type_counts = register_guarded_int_counter_vec_with_registry!(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we want to expose this metric in per table granularity by default? If not, we can use RelabeledCounterVec.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Only the tables that call iter_log will create a new label on this metrics, which is expected to be few, with just mv tables that enable log store. So I think it's fine to expose the metrics in per table granularity so that we can get more insights about the log table.

@wenym1 wenym1 enabled auto-merge May 20, 2024 09:13
@wenym1 wenym1 added this pull request to the merge queue May 20, 2024
Merged via the queue into main with commit de86f94 May 20, 2024
27 of 28 checks passed
@wenym1 wenym1 deleted the yiming/iter-log-metrics branch May 20, 2024 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants