-
Notifications
You must be signed in to change notification settings - Fork 329
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
Structured logs for relayer logic #1491
Conversation
This was inspired from commit b63335b (see rpc.rs therein).
Just examine the hash map, do not allocate any copies.
Co-authored-by: Mikhail Zabaluev <mikhail@informal.systems>
Add tracking_id method to use in tracing instead. Also, use less cryptic span names in send_messages_*.
Make the tracking ID construction parameter generic to accept any Into<String> parameter.
Identify TrackedMsgs batches for creating channels and connections with the specific message that is used.
Use the `odata` key in tracing.
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, but I've made some changes that may need another look.
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.
Thanks for the adjustments Mikhail! I think we should just adjust a bit the tracking id
s, because they can make the output lines very long -- I left suggestions for that.
Can we also signal the changes in the changelog? https://github.com/informalsystems/ibc-rs/blob/master/CONTRIBUTING.md#examples
@@ -1111,7 +1112,7 @@ impl ChainEndpoint for CosmosSdkChain { | |||
) -> Result<Vec<Response>, Error> { | |||
crate::time!("send_messages_and_wait_check_tx"); | |||
|
|||
let span = span!(Level::DEBUG, "send", id = %tracked_msgs); | |||
let span = span!(Level::DEBUG, "send_tx_check", id = %tracked_msgs.tracking_id()); |
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.
Thanks, this is clearer!
@@ -828,7 +828,7 @@ impl<ChainA: ChainHandle, ChainB: ChainHandle> Connection<ChainA, ChainB> { | |||
.map_err(|e| ConnectionError::chain_query(self.dst_chain().id(), e))?; | |||
let client_msgs = self.build_update_client_on_src(src_client_target_height)?; | |||
|
|||
let tm = TrackedMsgs::new(client_msgs, "create connection"); | |||
let tm = TrackedMsgs::new(client_msgs, "update client on source for ConnectionOpenTry"); |
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 can't think of a shorter way to formulate this without losing context. I guess we can keep it as it is.
The operation name is usually enough.
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.
Once we do the release (merge #1712), let's merge this. Thanks Mikhail!
Post-merge artifact that might need our attention: when we encounter an account sequence number mismatch error, we see the following error message missing any tracking id:
|
The task lifetime is better tracked with a tracing span, which also reduces code repetition in tracking macros by putting in the task name once.
spawn_background_task receives a Span constructed by the caller. This allows embedding contextual information for the task, which is used to reduce repetition in logging macros for the workers.
4f67e34
to
d1ae093
Compare
span!( | ||
tracing::Level::ERROR, | ||
"DetectMisbehaviorWorker", | ||
client = %client.id, | ||
src_chain = %client.src_chain.id(), | ||
dst_chain = %client.dst_chain.id(), | ||
), |
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 is a bit more repetitive than the previous approach, but this allows filtering logs by any of the individual ID fields.
If this level of detail is not desirable, we could implement tracing::Value
on the objects that were logged with Display
(removing the issue of implementing a general-purpose formatting trait just for logging purposes), and resurrect the previous compact string representation.
let _span = span!( | ||
tracing::Level::DEBUG, | ||
"DetectMisbehaviorFirstCheck", | ||
client = %client.id, | ||
src_chain = %client.src_chain.id(), | ||
dst_chain = %client.dst_chain.id(), | ||
) |
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 could be folded into the "DetectMisbehaviorWorker" span below, but I thought it would be useful to distinguish these contexts since the other one is performed in a background worker task.
With spans injecting all of the information that was formatted using the RelayPath Display impl, this is redundant.
For the batch worker tasks, we should have a span with the task name and other details, so the top-level span is not needed. For other supervisor tasks, the span name is shortened.
We have the span now, these are redundant and bad style.
Mikhail and I had one more sync. session on this PR and we're both in agreement that this is ready for merging. It's a great first step in making the relayer's logs less grating on the eyes (and the codebase more idiomatic). The last nit is the changelog. Cool stuff. |
* Printing tx hashes from SendPacket events. This was inspired from commit b63335b (see rpc.rs therein). * log the tx hashes in ibc_channel event SendPacket * Redo displaying for `OperationalData` Add `OperationalInfo` that can hold the displayable data on the batch, either borrowed or owned with transforming from first to the other. Implement `Display` on the `OperationalInfo` instead of `OperationalData` for clarity. * Improve logging of operational data Use the `odata` key in tracing. * Use a tracing span for task log messages The task lifetime is better tracked with a tracing span, which also reduces code repetition in tracking macros by putting in the task name once. spawn_background_task receives a Span constructed by the caller. This allows embedding contextual information for the task, which is used to reduce repetition in logging macros for the workers. * Erase Display impl on RelayPath, use spans instead With spans injecting all of the information that was formatted using the RelayPath Display impl, this is redundant. * Erase [rest] prefixes from log messages We have the span now, these are redundant and bad style. Co-authored-by: Mikhail Zabaluev <mikhail@informal.systems>
Closes: #1537
Description
For contributor use:
unclog
.docs/
) and code comments.Files changed
in the Github PR explorer.