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
New metric type gauge supplier #42
Comments
I agree this feature would be useful; I had it implemented in another metrics library some time ago. However I don't think a new metric type is required. I would rather define a standard type Watch = Fn(u64) -> ()
let gauge = metrics.gauge("some_resource");
let watch: Watch = |now| gauge.value(resource.len());
let scheduled_watch = Schedule.watch_every(Duration::from_sec(10), watch);
scheduled_watch.cancel();
bucket.watch_on_flush(watch) Maybe the target metric could be maintained externally to the closure and passed on every invocation, then it could also be used as map key to register / unregister watch on flush. Maybe the Watch signature could include returning a As an extension to this, a dedicated |
Ok, that's also possible, this would be the external implementation I was writing about. I'm starting to work on it. |
- Use `MetricValue` instead of `isize`. - Cancel handle in example. - Configurable thread name.
I have finished proof of concept which works but it is still quite dirty and only for I'm fighting with a generic support for all other types and a scheduling independent to |
I had a quick look at the PR, I will try to find some time to play with it soon so I can give you feedback. I like the |
I like the My colleague showed me today how to ged rid of the |
The current scheduler is very basic and was always intended to be supplanted with a user supplied thread / threadpool in any non-trivial situation. The only thing is I'd be wary of is bringing in any non-optional heavy dependency set, especially Be mindful that the |
The other place where |
- If multiple callbacks are registered under the same conflicting key, only the last one will survive. - It would be especially bad if the callback was re-registered periodically. The memory would increase and even all historical callbacks would be executed during each iteration.
I have managed to remove the I have rethought the idea of If you are ok with the current API and code, there will be two next steps:
|
I'm having a look at your
|
continued:
If you have other ideas, find that my design isn't cutting it, or are just somehow uneasy with this, let me know, and we'll find a way to make this work. This is a valuable feature, which is why I'm raising the bar. I am glad to have someone take interest in this beside me. |
I'm sorry, I had different tasks with higher priority, I will continue probably this week. |
Hi Francis, it's quite difficult to start according to your high level description for me. I have still some difficulties with thinking in Rust and it's compositions, it isn't simple language and the enter barrier is quite high. Can you please write, in a hour, skeleton of traits and API with empty methods to make it clear? I hope a concrete code or at least pseudo-code will significantly help to see all the connections in your design. I don't want to waste my time slot for this by searching proper solutions if you already have the design in your head. |
Sure, I'll try to find some time today or this weekend to do that. |
Ok, finally started to work on it, I'll post a link to my branch soon. |
- Use `MetricValue` instead of `isize`. - Cancel handle in example. - Configurable thread name.
- If multiple callbacks are registered under the same conflicting key, only the last one will survive. - It would be especially bad if the callback was re-registered periodically. The memory would increase and even all historical callbacks would be executed during each iteration.
Here's a tentative PR #50 |
I'm sorry, I don't have any time for this these days. I will continue hopefully in the soon future. |
Addressed in version |
It would be great to have a gauge that is able to call a function to get the value to report. Current gauges use push model, this would be pull. Inspired by https://metrics.dropwizard.io/3.2.3/manual/core.html#gauges.
Use cases:
/proc
filesystemReporting of the application uptime using the existing API:
Proposal for the new API. (Fighting with borrow checker and multi-threading may occur, this is only to get the idea.)
I plan to implement the feature soon either directly to Dipstick or as its extension. If you like it I will be happy to contribute. I have already looked at the code and it would probably require significant internal changes due to the push model in
InputMetric.write()
so I'm asking in advance...The text was updated successfully, but these errors were encountered: