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

Buffered metrics #391

Merged
merged 4 commits into from
Oct 5, 2023
Merged

Buffered metrics #391

merged 4 commits into from
Oct 5, 2023

Conversation

cretz
Copy link
Member

@cretz cretz commented Sep 27, 2023

What was changed

Support for user-retrieved metrics via a buffer

  • Added Rust code to support metric buffer including ensuring the same Python metric/attribute objects are reused
  • Added MetricBuffer, BufferedMetric, and BufferedMetricUpdate to temporalio.runtime

Checklist

  1. Closes [Feature Request] Advanced metrics support #369

@cretz cretz requested a review from a team as a code owner September 27, 2023 15:48
Comment on lines +290 to +293
metrics::MetricValue::String(v) => new_attrs.set_item(kv.key, v),
metrics::MetricValue::Int(v) => new_attrs.set_item(kv.key, v),
metrics::MetricValue::Float(v) => new_attrs.set_item(kv.key, v),
metrics::MetricValue::Bool(v) => new_attrs.set_item(kv.key, v),
Copy link
Member

Choose a reason for hiding this comment

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

You should be able to do this all with one branch like:

metrics::MetricValue::String(v) | metrics::MetricValue::Int(v) | metrics::MetricValue::Float(v) | metrics::MetricValue::Bool(v) => new_attrs.set_item(kv.key, v)

Copy link
Member Author

@cretz cretz Sep 27, 2023

Choose a reason for hiding this comment

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

I had a thing where I had the match just in the value but Rust was struggling to confirm they all impl'd ToPyObject w/out a manual dyn hint. I just figured this was the easiest, but will try to change to that if it works on next commit.

EDIT: Confirmed Rust is not smart enough to do proper inference of v here, you get something like:

294 |                     metrics::MetricValue::String(v) | metrics::MetricValue::Int(v) | metrics::MetricValue::Float(v) | metrics::MetricValue::Bool(v) => new_attrs.set_item(kv.key, v)
    |                                                  -                              ^ expected `String`, found `i64`
    |                                                  |
    |                                                  first introduced with type `std::string::String` here
    |
    = note: in the same arm, a binding must have the same type in all alternatives

Copy link
Member

Choose a reason for hiding this comment

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

Oh, yeah, they'd need to be turned into trait objects. Not worth it.

temporalio/bridge/src/metric.rs Outdated Show resolved Hide resolved
self.runtime
.metrics_call_buffer
.as_ref()
.unwrap()
Copy link
Member

Choose a reason for hiding this comment

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

There's enough unwrapping going on in this callstack it might make sense to just actually have this return a Result

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 considered that, but I decided to trust the caller. In theory the Python code will never call this unless it was setup with a buffer. So there isn't a user-facing failure here that should happen.

Copy link
Member Author

@cretz cretz Sep 28, 2023

Choose a reason for hiding this comment

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

Changed to expect to clarify but I never expect it to panic (or I definitely would return an error to be bubbled out through Python)

and is drained regularly. See :py:class:`MetricBuffer` warning.

Args:
buffer_size: Size of the buffer. Set this to a large value.
Copy link
Member

Choose a reason for hiding this comment

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

Some guidance beyond large is useful here I think

Copy link
Member Author

Choose a reason for hiding this comment

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

Suggestions? I didn't know of a good value so I intentionally didn't set a default. I don't know how frequently updates are emitted to add any more info.

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 added "A value in the tens of thousands or higher is plenty reasonable" but not sure what other guidance I can provide that I don't already with warnings at the class level and elsewhere explaining that frequent draining is required. Suggestions?

Copy link
Member

Choose a reason for hiding this comment

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

I think that's good. 10k ish seems reasonable. It's hard to guess at.

Copy link
Contributor

@mjameswh mjameswh left a comment

Choose a reason for hiding this comment

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

Great! That turns out very clean.

@cretz cretz merged commit d03f356 into temporalio:main Oct 5, 2023
12 checks passed
@cretz cretz deleted the buffered-metrics branch October 5, 2023 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Advanced metrics support
3 participants