feature/add_logging_mechanism -> release/v0.4.50#241
feature/add_logging_mechanism -> release/v0.4.50#241asmodat wants to merge 9 commits intorelease/v0.4.50from
Conversation
…tions with defaults for interx setup
…d interx/block.go
…version printing issues"
…y and maintainability
There was a problem hiding this comment.
Function CustomLogger rely on env variable PrintLogs. We use CLI. So it's better pass arg from a flag.
If there is a default behavior we should explicitly show it. In this case it should be:
var printLogs bool = falseWe should also handle the error if logger is not initiated correctly as it's crucial part of the app. I would suggest to return error as well. Please keep in mind that the code will run in a container from SCRATCH without actual shell to interact with.
| success, err, statusCode := common.MakeTendermintRPCRequest(rpcAddr, "/block", fmt.Sprintf("height=%s", height)) | ||
|
|
||
| if err != nil { | ||
| log.CustomLogger().Error(" `queryBlockByHeightOrHashHandle` failed to execute.", |
There was a problem hiding this comment.
On each call you initialize the new logger. Wouldn't it better to init the logger once and share it between packages?
| var log = logrus.New() | ||
|
|
||
| // Monitor will continuously collect system information | ||
| func Monitor(interval time.Duration) { |
There was a problem hiding this comment.
There is no point to track this data within application. We can use dedicated tools from host side to benchmark the performance. This data can't be accurate due to unknown nature of environment where application is running in.
| "github.com/sirupsen/logrus" | ||
| ) | ||
|
|
||
| var logger = logrus.New() |
There was a problem hiding this comment.
We should stick to the one logging mechanic. If it's cosmos logger - let's be consistent and proceed with it.
3 participants
No description provided.