Alter log level in Production?

Hey there!

I’m currently trying to debug some slow queries that are only happening in environments which run in production mode. I noticed that the log level appears to be hardcoded in production mode (code reference) with no way to directly configure it. I’d like to change this log level to debug (at least temporarily) so I can see more information; is there a way to accomplish this?

I tried some pretty hacky workarounds which involved changing the log level during runtime with the Rails console, but none of the hacks resulted in DB queries showing up in the debug logs (if I manually did debug logs with Rails.logger.debug in the Rails console those did show up after the hacks, though).

Thanks!

P.S. Just to soothe any potential worries about my comment above about issues that only happen in production environments, I’m using Discourse in a quite non-standard way that involves a large number of categories; the issues I’m facing probably aren’t faced by any other Discourse instances. :slight_smile:

3 Likes

This has been foxing me recently.

image

I have confirmed I have log level info, yet no amount of:

Rails.logger.info "blah blah blah"

shows up and /errors stubbornly stcks to warn - what am I missing?

Anyone have a solution to this?

It’s very frustrating

image

… yet I cannot see Info level logging in /logs!

Toggling “info” does nothing:

image

Not sure how we are supposed to diagnose certain kinds of issues that only occur in Production without this … :sweat_smile:

What is blocking info level logs?

More things I’ve tried:

  • I’ve checked production.log and the info logs I want are there!
  • I’ve looked at the output of Logster.config on rails console and it’s not obviously useful.
  • ditto /vendor/bundle/ruby/3.2.0/gems/logster-2.19.1/lib/logster/configuration.rb

So I’m still at a loss why the info level logs are not showing in /logs

Clearly something is filtering out the info level logs between production.log and Logster.

https://github.com/search?q=repo%3Adiscourse%2Fdiscourse%20Logger%3A%3AWARN&type=code

2 Likes

If I understand things correctly it’s suppressing info and debug in production mode by design. Blaming logster/lib/logster/rails/railtie.rb at main · discourse/logster · GitHub

store.level = Logger::Severity::WARN if Rails.env.production?

From a blog post

In production mode it aggregates similar errors by fingerprinting backtraces listening for warnings/errors and fatal messages. The intention is to display a list of open application problems that can somehow be resolved.

In development mode it provides a full fire-hose of all logs produced by Rails. (debug and up). This has significant advantages over console as you have proper access to backtraces for every log line.

2 Likes

Thanks.

Makes sense for the mainstream case.

However, that seems unreasonably restrictive and should be configurable for special circumstances?

That includes the times you have edge cases in Production you wish to investigate.

1 Like