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

Logs, log levels #797

Merged
merged 17 commits into from
Aug 8, 2024
Merged

Logs, log levels #797

merged 17 commits into from
Aug 8, 2024

Conversation

volovyks
Copy link
Collaborator

@volovyks volovyks commented Aug 2, 2024

Logs are opinionated. I want us to start discussing how, where, and what we are logging.

@volovyks volovyks requested a review from ChaoticTempest August 2, 2024 20:36
chain-signatures/node/src/indexer.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/mesh/connection.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/mesh/connection.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/mesh/connection.rs Show resolved Hide resolved
chain-signatures/node/src/rpc_client.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/mesh/connection.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@ppca ppca left a comment

Choose a reason for hiding this comment

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

I'd say we should bring "received a new message" from tracing back to debug, but that is indeed spammy. But we kinda need a way to figure out if a node is able to receive messages and was receiving messages.

chain-signatures/node/src/indexer.rs Outdated Show resolved Hide resolved
@volovyks
Copy link
Collaborator Author

volovyks commented Aug 5, 2024

@ppca @ChaoticTempest Overall, I think we should be looser with debug logs. They should give as full understanding of what is going on in our system, not just the "highlights". Info is for highlights, it should work fine once we have log filtering.

@volovyks volovyks requested review from ChaoticTempest and ppca August 6, 2024 10:43
@volovyks
Copy link
Collaborator Author

volovyks commented Aug 6, 2024

@ppca @ChaoticTempest I've added more logs, and removed or moved some of them. Changed log levels, and now we should be able to use them in GCP.

@volovyks volovyks changed the title Indexer and other logs Logs, log levels Aug 6, 2024
@volovyks volovyks requested a review from DavidM-D August 6, 2024 17:16
@ppca
Copy link
Contributor

ppca commented Aug 7, 2024

Adding logs look good to me. But we still need to enable toggling for this to work in GCP? If you want to see these logs now without the work of enabling toggle, all the trace!("") won't show up in GCP FYI.

@volovyks
Copy link
Collaborator Author

volovyks commented Aug 7, 2024

@ppca are you talking about this #803 ?

chain-signatures/node/src/mesh/connection.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/mesh/mod.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/protocol/message.rs Outdated Show resolved Hide resolved
chain-signatures/node/src/protocol/mod.rs Outdated Show resolved Hide resolved
@@ -304,7 +315,7 @@ impl MpcSignProtocol {
let from_state = format!("{state}");
state = match state.advance(&mut self, contract_state).await {
Ok(state) => {
tracing::debug!("advance ok: {from_state} => {state}");
tracing::trace!("advance ok: {from_state} => {state}");
Copy link
Member

Choose a reason for hiding this comment

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

not sure if @ppca will like this because it might not be visible that we're advancing states in our normal debug logs

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've made it trace because it is too spammy. We should fix it later with logging spans.

self.gc
.retain(|_, instant| instant.elapsed() < Duration::from_millis(cfg.garbage_timeout));
let removed = before.saturating_sub(self.gc.len());
if removed > 0 {
tracing::warn!("garbage collected {} presignatures", removed);
Copy link
Member

Choose a reason for hiding this comment

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

I wouldn't say this is a warning though, since this is purely informational where warning should be reserved for logs that should close to never happen. So it should be info instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think we should minimize the number of garbage collections since it is a waste and an indicator that our system is not efficient.

Copy link
Member

Choose a reason for hiding this comment

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

I think you're misunderstanding what garbage collection is. Garbage collections happens no matter what, as in every single triple, presignature and signature will eventually be garbage collected and this will always be called. It is our way to keep tally of what IDs to keep around until messages stop from other protocol that linger behind or are delayed due to restarts or other misc behaviors

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

kk, I got it
what I meant is that we should keep track of gcd triples, pre-signatures that were not used for any reason

Comment on lines -130 to +135
crate::metrics::NUM_SIGN_REQUESTS_MINE
.with_label_values(&[my_account_id.as_str()])
.inc();
if is_mine {
crate::metrics::NUM_SIGN_REQUESTS_MINE
.with_label_values(&[my_account_id.as_str()])
.inc();
}
Copy link
Member

Choose a reason for hiding this comment

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

Not sure if this is correct. @ppca is this the right metric for MINE sign requests or does this include requests that we are a part of the signer subset?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is an intentional change. I believe that it is more important now to have a metric for the proposer of the signature. But we can have both. Also, "MINE" semantics is closer to me=proposer.

Comment on lines 205 to 207
tracing::warn!("signature protocol timed out completely");
return Err(ProtocolError::Other(
anyhow::anyhow!("signature protocol timeout completely").into(),
anyhow::anyhow!("signature protocol timed out completely").into(),
Copy link
Member

Choose a reason for hiding this comment

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

I wouldn't rename it timed out because it's much easier to search for timeout even though timed out is more grammatically correct

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe, but we have a lot of "timed out" logs. We should unify it all.

self.completed.retain(|_, timestamp| {
timestamp.elapsed() < Duration::from_millis(cfg.signature.garbage_timeout)
});
let garbage_collected = before.saturating_sub(self.completed.len());
if garbage_collected > 0 {
tracing::warn!(
Copy link
Member

Choose a reason for hiding this comment

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

same here with this garbage collection

self.gc.retain(|_, timestamp| {
timestamp.elapsed() < Duration::from_millis(cfg.garbage_timeout)
});
let garbage_collected = before.saturating_sub(self.gc.len());
if garbage_collected > 0 {
tracing::warn!("garbage collected {} triples", garbage_collected);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
tracing::warn!("garbage collected {} triples", garbage_collected);
tracing::info!("garbage collected {} triples", garbage_collected);

@volovyks volovyks requested a review from ChaoticTempest August 7, 2024 10:21
@volovyks volovyks merged commit 805c9be into develop Aug 8, 2024
3 checks passed
@volovyks volovyks deleted the serhii/more-logs branch August 8, 2024 09:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants