kelvinst
Logger - setting config :logger, level: :debug in prod env?
Hey guys! Here is something I’m thinking lately: why not setting config :logger, level: :debug in prod env?
The point would be to have more information about errors that happened and are hard to repeat, without having to create a specific new log message, deploy it to prod and crossing your fingers the info would be enough when the error happens again. The biggest con I can see, ofc, is performance. Do any of you use debug logger level in prod? Do we have any benchmark for it? And is that actually a problem for the end users? I mean, IO should not block the request cause the logger is asynchronous, right? I guess it should not impact the request as much in that case right?
I remember setting the log level to debug on other prod envs in Ruby, and acknowledging ruby is a lot slower than Elixir, and even worse, logs on ruby are not asynchronous, I can’t see the point of leaving it on the info level.
Most Liked
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.
- 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.
- Signal to noise ratio. Debug logs can be quite noisy and can hide important and relevant information in SQL queries and stuff like that.
- 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.
hauleth
Until you will have breach, and your logs will be read not only by You.
Then you probably use wrong log level for that data.
Not really. BEAM can actually be a problem there as sending messages to processes is cheap and have negligible backpressure. Unbounded growth of the mailbox can cause VM to OOM and degrade performance of all processes. That is why Elixir, Erlang, and Lager implement some kind of overload protection mechanisms. Additionally that is the reason why Elixir do not encourage people to use “Erlang handlers” instead of “Elixir backends”, as there is no reliable way to have such mechanism in Erlang handlers yet.
Yes, that is why Erlang use notice as a default level, and Elixir currently uses some hacks to work around it for compatibility reasons.
Debug logs are meant for debugging. If you want to have them enabled by default in production, then you have used wrong level in the first place. So you are looking wrong way at the problem - make interesting logs for you use higher log level instead of lowering primary log level.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








