Logger - setting config :logger, level: :debug in prod env?

[kelvinst]

Thanks for all your points. I agree all of them are a concern you have to have in mind, but I really am trying to measure the pros vs cons, and as I said, I’m really missing some of the info I used to have on rails logger. So here are my points about each of them:

@hauleth

Debug logs can contain private informations that should not be stored in the log system. For example email can be considered PII, which mean that your logs now require to be able to comply with GDPR (assuming you are operating in EU) and you need to provide and remove that informations on request, including historical data.

True, that might be a problem, but solvable by hiding the data like it’s done to passwords on ecto and phoenix debug logs, but in my mind logs are only accessible by us, so we don’t have many problems with that. The biggest issue then would be having to remove the user data from logs when requested, but that is also not impossible, just have to go through log files and delete the data.

@hauleth

Overloading logging system. Debug logs are often defined to be very descriptive and can contain a lot of information, as well as fire quite often. This can overload logger and then cause backends/handlers to just drop them on the flor to prevent system from DoS.

Kinda related to my performance comments: I think the BEAM is reliable enough to trust that if the logger becomes a problem itself, the system will recover from that and we have time to work on a fix for it.

@hauleth

Signal to noise ratio. Debug logs can be quite noisy and can hide important and relevant information in SQL queries and stuff like that.

Agree, there will be a lot of stuff that we are not going to use, and we actually don’t want to use either. But if we go that direction, then some of the info level logs also can be considered noise. I mean, it’s noise because it’s not useful enough to actually get more information about what happened. The thing is that we actually don’t know what will be noise, so I would prefer 10 times to have a lot of noise and some signal between it, than not having signal at all (which happened multiple times for me already)

@hauleth

Network transfer in case of centralised logging systems. Mostly the same points as in 2., but with different place where the slowdown/congestion can happen.

Normally when centralizing logs we still leave the old log files on the server anyway, so I guess we have a backup if that becomes a problem. We can live while solving the problem.