-
Notifications
You must be signed in to change notification settings - Fork 112
feat(ethexe): Metrics
#5034
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
base: master
Are you sure you want to change the base?
feat(ethexe): Metrics
#5034
Conversation
Changed Files
|
Summary of ChangesHello @ecol-master, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly upgrades the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a comprehensive metrics system using the metrics and metrics-exporter-prometheus crates, replacing a custom Prometheus integration. Key changes include adding new metric dependencies across Cargo.lock and Cargo.toml files, defining specific metric structs (Metrics, RpcApiMetrics, InjectedApiMetrics, BlockApiMetrics) with Counter and Gauge types for various services (compute, RPC), and integrating these metrics into the CodesSubService, PrepareSubService, and RPC InjectedApi. The previous PrometheusService logic for collecting and exposing metrics has been refactored to leverage the new metrics-exporter-prometheus for HTTP exposition, removing the PrometheusEvent and associated manual metric updates. A new test case for send_tx was added. Review comments highlight a critical regression in injected_sendTransaction where the original transaction processing logic was commented out, leaving only a metric increment and an Accept return, which needs to be restored. Additionally, a TODO comment regarding casting validated_codes.len() to u32 for a Gauge metric was noted, with a suggestion to cast to f64 to prevent potential data loss from truncation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a comprehensive metrics system to ethexe using the metrics crate, which is a significant improvement for observability. The implementation is well-structured, with metrics definitions co-located with their respective services. The prometheus service has been refactored to use metrics-exporter-prometheus, which is a great move towards using standard libraries and simplifying the codebase. The identified minor issue regarding a potential panic in a utility function has been retained as it does not contradict any existing rules. Overall, this is a high-quality contribution.
| std::time::SystemTime::now() | ||
| .duration_since(std::time::UNIX_EPOCH) | ||
| .expect("Correct timestamp") | ||
| .as_secs() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of .expect() here could cause the service to panic if the system clock is set to a time before the UNIX epoch. While this is a rare condition, it's better to handle it gracefully in a long-running service. Consider using unwrap_or_default() to default to a duration of zero in this edge case. This would prevent a panic and simply result in a zero-latency metric for that event.
| std::time::SystemTime::now() | |
| .duration_since(std::time::UNIX_EPOCH) | |
| .expect("Correct timestamp") | |
| .as_secs() | |
| std::time::SystemTime::now() | |
| .duration_since(std::time::UNIX_EPOCH) | |
| .unwrap_or_default() | |
| .as_secs() |
dcab501 to
b4e1cc1
Compare
@grishasobol @breathx @ark0f