Closed afonsojramos closed 2 years ago
@aquelemiguel @joao-conde do you already have any preference over any logging framework?
@afonsojramos nope, up to you. Do some due diligence and present some of your preferred choices.
But this one seems official: https://github.com/rust-lang/log Its part of the rust-lang organization itself.
Will do! The official log
crate is a red herring, since it is only a facade. Most loggers that I listed actually implement said facade.
Ah, I see. All of these sound good:
But what stops me from using these macros?
But what stops me from using these macros?
Nothing 😅
I think the lib we choose should cover the following: 1 - be as simple as possible, guaranteeing the next 2 - having simple functions/macros to output text at multiple levels (info debug error) 3 - being able to control where to send the logs through env vars (console, file, both, etc)
These properties allow us to set debug variables like LEVEL=DEBUG
and LOG=CONSOLE
for local development and debugging or LEVEL=ERROR
and LOG=FILE
for our deployment.
This ended up being something that is not needed as the overhead is too much for little benefit since we can simply run docker logs
to check out the logs of the container.
I raised this issue because I was passing without my knowledge, due to lazydocker
's defaults, the flag --since=60m
, which would block me from seeing a lot of logs.
Rationale
When we have a deployed Parrot it is very useful to have logs in a file. I have actually had an occasion where the deployed parrot crashed for no reason in specific, and even after accessing the container logs I could not see anything. This would be solved by logging stuff into a file.
Description
Implement an in-house logger/a logging framework.
Reference
Logging crates