Clean up and improve logs

[romac]

See: #1538

---

PR author checklist:

• Added changelog entry, using unclog.
• Added tests: integration (for Hermes) or unit/mock tests (for modules).
• Linked to GitHub issue.
• Updated code comments and documentation (e.g., docs/).
• Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

• Reviewed Files changed in the GitHub PR explorer.
• Manually tested (in case integration/unit/mock tests are absent).

[ljoss17]

Many CLI have a debug log which contains all the options given, but not all of them have this log.
Should we have this log for every CLI or remove it from every CLI ? I do not see a case where this log is very useful, so I tend to be of the opinion to remove it from the CLIs.
https://github.com/informalsystems/ibc-rs/blob/romac/cleanup-logs/relayer-cli/src/commands/query/client.rs#L122-L124

[romac]

I do not see a case where this log is very useful, so I tend to be of the opinion to remove it from the CLIs.

Agreed!

[seanchen1991]

Let's add some more docs, but other than that, looks good to me 🙂

[seanchen1991]

Can we document this function? Some questions that I think would be helpful for the docs to answer:

1. Do the metrics get sent to both the source and destination? Only one of them? In which situations?
2. A brief description of each of the metrics that are sent based on the IbcEvent variant in the match.

[ljoss17]

The idea for these metrics is the following:

• These metrics count the number of SendPacket, WriteAcknowledgement and TimeoutPacket events observed by the supervisor.
• In order to make it easier to see the duality SendPacket/WriteAcknowledgement or SendPacket/TimeoutPacket, the WriteAcknowledgement and TimeoutPacket will have the destination chain labelled as the source as these events are being "sent back" to the chain which submitted the corresponding SendPacket event.

So a SendPacket event from ibc-0 will increment the send_packet_events{chain="ibc-0",channel="channel-0",counterparty="ibc-1",port="transfer"} and the returning WriteAcknowledgment event will increment the acknowledgement_events{chain="ibc-0",channel="channel-0",counterparty="ibc-1",port="transfer”}.

But I realise that this might cause confusion. I can update it to label the chain and counterparty to be the submitting and receiving chains for the isolated events. Meaning the new send/acknowledgement/timeout events metrics label would have:

• chain is always the chain that submits the event
• counterparty is always the chain that will receive the packet generated from the event

Instead of being the submitting and receiving chain for the whole transfer. Current send/acknowledgement/timeout events metrics label is:

• chain being the chain that sends the SendPacket event and receives the corresponding WriteAcknowledgment, TimeoutPacket events
• counterparty being the chain that receives the SendPacket event and sends the WriteAcknowledgment, TimeoutPacket events

What do you think?

[seanchen1991]

chain is always the chain that submits the event
counterparty is always the chain that will receive the packet generated from the event

I agree that labeling these in absolute terms, instead of relative terms, is probably a bit easier to parse 🙂