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(udf): add udf metrics to embeded udf, refactor external udf metrics. #15506

Merged
merged 4 commits into from
Mar 7, 2024

Conversation

yufansong
Copy link
Member

@yufansong yufansong commented Mar 7, 2024

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

What's changed and what's your intention?

  1. Extract the UDF metrics into a higher layer.
  2. Then metrics can work for every kinds of the udf
  3. The external UDF call logic is little complicated. But we decide to count each trigger as only one call. Event it actually do several call, we can still infer this info from the latency metrics.
  4. For embeded udf call, the link label will be empty ``. Show in following example, the first three record udf is external udf, the last one are embeded udf:
  5. Also add language labels: wasm, javascript, python, external, for example, the first three is external, the last one is javascript
    image

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.

@yufansong yufansong changed the title Feature(udf): add udf metrics to embeded udf, refactor user-host udf metrics. feat(udf): add udf metrics to embeded udf, refactor external udf metrics. Mar 7, 2024
Copy link
Contributor

@wangrunji0408 wangrunji0408 left a comment

Choose a reason for hiding this comment

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

LGTM!

we decide to count each trigger as only one call. Event it actually do several call, we can still infer this info from the latency metrics.

Actually I am a little worried about one case. When always_retry_on_network_error is enabled, the call may be retrying forever. In this case we will no longer see any UDF metrics, although error messages can still be seen in the log. Not sure if this would have any impact on diagnosing UDF problems. cc @kwannoel

@@ -17,7 +17,8 @@

mod error;
mod external;
mod metrics;
pub mod metrics;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this module can be moved to expr/core now.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let me hold this first, I am thinking if we add some specific for in-flight udf, the metrics mod should better stay here. After solve this problem, I can move it in other PR.

Comment on lines 149 to 120
// batch query does not have a fragment_id
let fragment_id = FRAGMENT_ID::try_with(ToOwned::to_owned).unwrap_or(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment should be moved together.

UdfImpl::External(client) => client.get_addr(),
_ => "",
};
let labels: &[&str; 3] = &[addr, &self.identifier, fragment_id.as_str()];
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think if we add language to the labels?

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, I can add it.

@kwannoel
Copy link
Contributor

kwannoel commented Mar 7, 2024

LGTM!

we decide to count each trigger as only one call. Event it actually do several call, we can still infer this info from the latency metrics.

Actually I am a little worried about one case. When always_retry_on_network_error is enabled, the call may be retrying forever. In this case we will no longer see any UDF metrics, although error messages can still be seen in the log. Not sure if this would have any impact on diagnosing UDF problems. cc @kwannoel

Hmm could we have a way to track in-flight UDF calls? So if the number stays high for a long time, we know the udf server has issues.

@yufansong
Copy link
Member Author

LGTM!

we decide to count each trigger as only one call. Event it actually do several call, we can still infer this info from the latency metrics.

Actually I am a little worried about one case. When always_retry_on_network_error is enabled, the call may be retrying forever. In this case we will no longer see any UDF metrics, although error messages can still be seen in the log. Not sure if this would have any impact on diagnosing UDF problems. cc @kwannoel

Hmm could we have a way to track in-flight UDF calls? So if the number stays high for a long time, we know the udf server has issues.

Maybe I can add only udf failure count for always_retry_on_network_error, then we can see the udf count of failure

@yufansong yufansong added this pull request to the merge queue Mar 7, 2024
Merged via the queue into main with commit 3a2e574 Mar 7, 2024
26 of 27 checks passed
@yufansong yufansong deleted the yufan/udf-metrics-refactor branch March 7, 2024 08:22
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.

3 participants