feat: add logger to have better experience with work on app about core HOT 12 CLOSED

@dstpierre If you don't have any questions I can start implementing it)

from core.

@dstpierre Sorry for misunderstanding.
And yes lumberjack has default value.
So we will use that)

from core.

Hey @dstpierre can you review my pr?

from core.

Some questions / thoughts to keep in mind:

1. We need to stay backward compatible, so we'll need to have strong default when this get into production for version that will not change their config.
2. I can see some devs wanting to have multi-output, we'll need a good way to configure this.
3. What will be the strategy for replacing the current fmt.Println / log.Println with the new logger, is this part of this change?

I like to hdea of using APP_ENV with nice development defaults. I was looking at zerolog which says their "pretty" output isn't optimal, so this should only be enabled for APP_ENV=dev.

I'd like to discuss a bit regarding how one would configure this. As you explore which library you'd recommend, let us know what kind of options we have for non-console log (files, external services, etc).

Ideally I'd not want to add a hard dependency on a self-hosted log analysis. But we could certainly propose decent options.

from core.

What will be the strategy for replacing the current fmt.Println / log.Println with the new logger?

While watching the project I see that "fmt.Println / log.Println/ log.Fatal etc" doesn't happen very often.
So I guess that it won't be a problem to replace it manually.

Is this part of this change?

Yes sure.

I'd like to discuss a bit regarding how one would configure this. As you explore which library you'd recommend, let us know what kind of options we have for non-console log (files, external services, etc).

I don't know how to do this with "zerolog" because I have never worked with it.
But I know that "zap" logger has a built-in caller to write logs into the file and console at the same time.
Ex:

from core.

Multiple log output with zerolog.

So far I'd see the defaults behavior being:

APP_ENV=dev -> Use a "pretty" log output for all levels (debug, info, etc)

LOG_CONSOLE_LEVEL -> could be use to specify the minimum log level is wanted. For instance, LOG_CONSOLE_LEVEL=error would not includes trace,debug,info and warning level: https://github.com/rs/zerolog#setting-global-log-level

LOG_FILENAME -> if set, write logs to console and this file.

Now, should we think about monitoring size of this file? Who's responsible to clean this file?

How one ship this file to a 3rd party log analytics (self-hosted or paid).

Once we figure out the above, I think it'll be ready for implementation.

from core.

Now, should we think about monitoring size of this file? Who's responsible to clean this file?

It's not a problem we'll use "log rotation" with "lumberjack" + "zerolog".

How one ship this file to a 3rd party log analytics (self-hosted or paid).

Hmm. I don't expect to do this but probably in this part of the issue, it'll be manually working.
Maybe later we can do something better

from core.

"lumberjack" + "zerolog".

For example, it'll delete a log file after a certain period or when the file size equal to some value

from core.

Can you answer these questions?

• How many days do you want to keep old log files?
• How much max file size in MB do you want to see?
• How many backups of log files do you want to see?

from core.

How many days do you want to keep old log files?

I'd say a sane default would be 14 days to 30 days. Since the goal is most certainly to "ship" those log files somewhere else.

How much max file size in MB do you want to see?

I'd say 150-250 MB is probably an acceptable default. Rough questions I'd say, it's very situational.

How many backups of log files do you want to see?

Something like 3-7? I honestly don't know.

Does the library you're planning to use for log rotation suggests "fit-all" defaults?

from core.

Does the library you're planning to use for log rotation suggests "fit-all" defaults?

What do you mean while saying "fit-all defaults"?

If you talk about "defaults" from yesterday's message #44 (comment). The answer will be yes

from core.

@VladPetriv I'm just saying that I do not have hard specifics personally regarding log rotation, so if lumberjack has sane defaults, we should use that also by defaults.

from core.