-
Notifications
You must be signed in to change notification settings - Fork 17
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
adjust log levels and remove tracing::trace!() #879
Conversation
@@ -146,7 +146,7 @@ impl Indexer { | |||
block_height: BlockHeight, | |||
gcp: &GcpService, | |||
) -> Result<(), DatastoreStorageError> { | |||
tracing::trace!(block_height, "update_block_height"); | |||
tracing::debug!(block_height, "update_block_height"); |
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 looks like this and many other logs do not have a span. Do we want to add it everywhere and in the indexer in particular?
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 going to have a target in the log to filter on. We don't use span at all.
if uncompacted > 0 { | ||
tracing::debug!( | ||
tracing::info!( | ||
uncompacted, | ||
compacted, | ||
"{from:?} sent messages in {:?};", |
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.
how come this is now info? Do you think it's important to surface this info? This is going to spam a lot
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.
Yeah this helps to know if messages were successfully sent, what spams is "sending encrypted", this one is much better
loop { | ||
let msg_result = self.receiver.try_recv(); | ||
match msg_result { | ||
Ok(msg) => { | ||
tracing::trace!("received a new message"); | ||
tracing::debug!("received a new message"); |
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 vote to get rid of this log actually. Does not add much value because we're supposed to always be receiving messages. And this is going to show per protocol message which can be in the millions
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.
nah. Actually when things get stuck, we start "no new message received". And it helps to know if it's the node not receiving anything or it not doing anything
queue.push(msg); | ||
} | ||
Err(TryRecvError::Empty) => { | ||
tracing::trace!("no new messages received"); | ||
tracing::debug!("no new messages received"); |
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.
Same with this one. If anything we should have a message that shows how many messages we received in this loop
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.
same with above
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.
so this is for every triple/presignature/signature message, so it's better just to keep tally of how many messages we received instead of just printing the same message on every message. We'd still be able to understand that the node is receiving messages
gcp has no log level for trace!, so I changed trace!() to debug() or info().
I've also gone thru all the log messages and adjusted some of their levels so debug would be the lowest priority, info being somewhat important, and warn being alerting