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(metrics): add internal latency of actors, MVs and sinks #19639

Merged
merged 8 commits into from
Dec 3, 2024

Conversation

fuyufjh
Copy link
Member

@fuyufjh fuyufjh commented Dec 2, 2024

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

What's changed and what's your intention?

This PR resolves #18114, and also introduced an actor-level metrics for #19619.

New panel in DEV dashabord:

image image

New panel in USER dashabord:

image

Note there are 2 metrics for each sink - "output" means reading from log store, while "enqueue" means writing into log store.

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.

@graphite-app graphite-app bot requested a review from a team December 2, 2024 09:15
Copy link
Member

@xxchan xxchan left a comment

Choose a reason for hiding this comment

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

Looks great! Should we cherry-pick?

@@ -744,6 +744,26 @@ def section_streaming(outer_panels):
),
],
),
panels.timeseries_latency(
"Latency of Materialize Views & Sinks",
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be easier to interpret than the epoch one. Should we add it to dev dashboard also? (Actually I've never checked user dashboard before... 🤪)

Copy link
Member Author

@fuyufjh fuyufjh Dec 3, 2024

Choose a reason for hiding this comment

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

Dev dashboard shows epoch instead of latency. The latency is actually calculated by timestamp(<epoch_metrics>) - <epoch_metrics>, which is not very accurate. Thus I think, with a deeper understanding of RisingWave, showing epoch would be better.

Comment on lines +1135 to +1136
"The current epoch that the Materialize Executors are processing. If an MV's epoch is far behind the others, "
"it's very likely to be the performance bottleneck",
Copy link
Member

@xxchan xxchan Dec 2, 2024

Choose a reason for hiding this comment

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

BTW, if an upstream MV is blocked, then all downstream MVs will have epoch lag? (Therefore we can't locate the root cause from this metrics alone) 🤔

Besides, backpressure may also affect upstream MV's epoch...?

Copy link
Member

Choose a reason for hiding this comment

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

I found you once raised the idea to show the epoch on DAG. 🤔

#13481 (comment)

@fuyufjh fuyufjh added this pull request to the merge queue Dec 3, 2024
@fuyufjh
Copy link
Member Author

fuyufjh commented Dec 3, 2024

Looks great! Should we cherry-pick?

Do you mean check-pick to 2.1? Normally it will be shipped at 2.2, which sounds good to me

@xxchan
Copy link
Member

xxchan commented Dec 3, 2024

Yes to 2.1. Since this may help troubleshooting incl. oncall, I feel it may be good to make it available eaelier...

Merged via the queue into main with commit a41866f Dec 3, 2024
29 of 30 checks passed
@fuyufjh fuyufjh deleted the eric/add_mv_sink_latency_metrics branch December 3, 2024 07:40
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.

feat: metrics for each MV/Sink's latency
3 participants