-
Notifications
You must be signed in to change notification settings - Fork 40
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
Prometheus telemetry #1526
Prometheus telemetry #1526
Conversation
cf570fb
to
3d6a341
Compare
13a37ac
to
800e22e
Compare
in risc0 adapter, here you can get cycle counts from stats. change return types if you wish, but we need this information. probably the most important telemetry both provers can have. also why don't you have any telemetry implemented for light client prover 😅? let ProveInfo { receipt, stats } =
prover.prove_with_opts(env, &elf, &ProverOpts::groth16())?; |
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.
LGTM small fixes and couple of suggestions
Added... thanks for the hint. |
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.
Good PR. Left some comments as in it's current state. I will re-review once PR is not draft anymore.
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.
can you make telemetry ports of sequencer, fullnode, and prover for mock and regtest different? it causes problems when running different nodes locally.
@@ -716,6 +716,7 @@ dependencies = [ | |||
"bincode", | |||
"borsh", | |||
"hex", | |||
"prometheus-client", |
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.
it would be great if you can guard this dep behind native feature.
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.
With this, do we have to spawn up a prometheus container for working locally?
@@ -127,6 +129,9 @@ pub trait DaService: Send + Sync + 'static { | |||
&self, | |||
sequencer_da_pub_key: &[u8], | |||
) -> Vec<SequencerCommitment>; | |||
|
|||
/// Returns the telemetry targets type for the DA service. | |||
fn telemetry_targets(&self) -> &DaTelemetryTargets; |
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.
This should be native only as well
#[inline] | ||
pub fn duration_to_seconds(d: Duration) -> f64 { | ||
let nanos = f64::from(d.subsec_nanos()) / 1e9; | ||
d.as_secs() as f64 + nanos | ||
} |
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.
IMO nanos is a bit too much precision. We can use micros and just do d.as_micros() as u64
with no overflow no floating point whatsoever.
.get_or_create(&vec![( | ||
"cf_name".to_owned(), | ||
S::COLUMN_FAMILY_NAME.to_owned(), | ||
)]) |
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.
get_or_create is used everywhere in sov-schema-db, but we already know the dbs, and column families. can we somehow create these at the startup as well?
Closing in favor of #1589 1589 |
Description
From the referenced issue, the following was the list of metrics to collect:
All
Sequencer
Full node
Prover(s)
TODO
Linked Issues