-
Notifications
You must be signed in to change notification settings - Fork 210
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: more server metrics #3975
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3975 +/- ##
==========================================
+ Coverage 56.96% 57.08% +0.11%
==========================================
Files 193 193
Lines 43228 43326 +98
==========================================
+ Hits 24624 24731 +107
+ Misses 18604 18595 -9 ☔ View full report in Codecov by Sentry. |
@@ -85,7 +85,19 @@ lazy_static! { | |||
"contracts::FundedContract::Outgoing" | |||
)) | |||
.unwrap(); | |||
static ref AMOUNTS_BUCKETS_SATS: Vec<f64> = vec![0.0, 0.5, 1.0, 1000.0]; | |||
static ref AMOUNTS_BUCKETS_SATS: Vec<f64> = vec![ | |||
0.0, |
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.
Isn't 0.0 useless? Only things lower or equal than zero would fall into this bucket, which seems impossible/unlikely and not very useful?
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's one way to track what's zero. Some fees will be zero.
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.
One example where the zero makes it clear what's happening:
mint_redeemed_ecash_sats_bucket{le="0"} 0
mint_redeemed_ecash_sats_bucket{le="0.5"} 678
mint_redeemed_ecash_sats_bucket{le="1"} 722
mint_redeemed_ecash_fees_sats_bucket{le="0"} 756
mint_redeemed_ecash_fees_sats_bucket{le="0.5"} 756
mint_redeemed_ecash_fees_sats_bucket{le="1"} 756
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.
I don't get it. We don't even have fees for ecash/consensus txes, do we? And peg-in/peg-outs must have non-zero fees?
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 seems we do have fees for ecash transactions. Lightning fees could also be zero.
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 seems we do have fees for ecash transactions
WAT? How? Why I don't know about it.
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.
fee: self.cfg.consensus.fee_consensus.note_spend_abs, |
/// Fees charged for ecash transactions |
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.
TIL.
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.
Yep, every module could charge fees in theory. In practice we don't do it since it would massively complicate the client (especially for e-cash). It would be easy to get scenarios where coin selection runs into loops where adding/removing e-cash makes adding/removing more e-cash necessary because of fees.
Note: these fees are a separate concept from withdraw or LN fees, they'd be going to guardians (well, technically the federation would just become overcollateralized since there is no way to withdraw them).
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 easy to get scenarios where coin selection runs into loops where adding/removing e-cash makes adding/removing more e-cash necessary because of fees.
I don't think hitting this would be common. It is exactly like in Bitcoin - not really a problem people complain about. A bit of looping, and tiny overpaying fees should do.
IMO, the bigger issue the whole new aspect of "guardians making money". We have no affordances for it, no means for them to do anything useful with it (withdraw or e.g. contribute to peg-outs, or something), etc.
938fdd1
to
a7ea1ad
Compare
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 just occurred to me that process_input/output
is called twice for every input/output: once to verify the tx on submission and another time to process after consensus has been achieved. This would lead to double-counting of most metrics in this PR.
A potential solution for that might be registering on_commit
hooks with the database transaction which only run if the fedimint tx is processed successfully.
Do we already have metrics for accepted vs. rejected transactions btw?
Would it make sense to add another method to the trait for "this thing was already accepted". We could make it have a default no-op impl, so it wouldn't even break anything. We wouldn't even give a handle to the db, so it would be limited to diagnostics. Alternatively the existing |
That would be a lot of API surface only for metrics 😕 this would need to be implemented for inputs+outputs in |
a7ea1ad
to
6252157
Compare
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.
Looks good to me now, but we should get into the habit of testing our PRs. The double-counting would likely have been caught by a test.
updated_contract_account: ContractAccount, | ||
dbtx: &mut DatabaseTransaction<'_>, | ||
) { | ||
dbtx.on_commit(move || match updated_contract_account.contract { |
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.
Oh, I forgot we have this. So good. Very smart. Much 🧠 .
Bugs in metrics are kind of whateva, :D IMO, and they are a PITA to test because they use global counter. |
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin releases/v0.2
git worktree add -d .worktree/backport-3975-to-releases/v0.2 origin/releases/v0.2
cd .worktree/backport-3975-to-releases/v0.2
git switch --create backport-3975-to-releases/v0.2
git cherry-pick -x 62521575788147153abdd8248de417de74d5ee7a |
No description provided.