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

feat: more server metrics #3975

Merged
merged 1 commit into from
Dec 24, 2023
Merged

feat: more server metrics #3975

merged 1 commit into from
Dec 24, 2023

Conversation

douglaz
Copy link
Contributor

@douglaz douglaz commented Dec 19, 2023

No description provided.

Copy link

codecov bot commented Dec 19, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (05a8497) 56.96% compared to head (6252157) 57.08%.

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.
📢 Have feedback on the report? Share it here.

@@ -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,
Copy link
Contributor

@dpc dpc Dec 20, 2023

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?

Copy link
Contributor Author

@douglaz douglaz Dec 20, 2023

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.

Copy link
Contributor Author

@douglaz douglaz Dec 20, 2023

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

Copy link
Contributor

@dpc dpc Dec 20, 2023

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?

Copy link
Contributor Author

@douglaz douglaz Dec 20, 2023

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@douglaz douglaz Dec 21, 2023

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

Copy link
Contributor

Choose a reason for hiding this comment

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

TIL.

Copy link
Contributor

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).

Copy link
Contributor

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.

@douglaz douglaz force-pushed the more_metrics branch 2 times, most recently from 938fdd1 to a7ea1ad Compare December 20, 2023 15:28
dpc
dpc previously approved these changes Dec 21, 2023
@dpc dpc enabled auto-merge December 21, 2023 01:00
Copy link
Contributor

@elsirion elsirion left a 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?

modules/fedimint-mint-server/src/lib.rs Show resolved Hide resolved
modules/fedimint-mint-server/src/lib.rs Outdated Show resolved Hide resolved
@dpc
Copy link
Contributor

dpc commented Dec 21, 2023

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.

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 process_input could take an extra argument.

@elsirion

@elsirion
Copy link
Contributor

Would it make sense to add another method to the trait for "this thing was already accepted"

That would be a lot of API surface only for metrics 😕 this would need to be implemented for inputs+outputs in ServerModule + IServerModule.

Copy link
Contributor

@elsirion elsirion left a 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 {
Copy link
Contributor

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 🧠 .

@dpc dpc added this pull request to the merge queue Dec 24, 2023
@dpc
Copy link
Contributor

dpc commented Dec 24, 2023

he double-counting would likely have been caught by a test.

Bugs in metrics are kind of whateva, :D IMO, and they are a PITA to test because they use global counter.

Merged via the queue into fedimint:master with commit c64aa0e Dec 24, 2023
20 checks passed
@fedimint-backports
Copy link

Backport failed for releases/v0.2, because it was unable to cherry-pick the commit(s).

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

@github-actions github-actions bot mentioned this pull request Dec 24, 2023
@douglaz douglaz deleted the more_metrics branch December 26, 2023 04:00
@douglaz douglaz restored the more_metrics branch December 26, 2023 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants