Replies: 12 comments 25 replies
-
I've tried to keep Sidekiq's logging policy as simple as possible: we log to stdout and we log with the Logger instance found at Sidekiq can't depend on or use any Rails infrastructure but I'm open to improvements which unify Sidekiq and Rails logging. This has been a sore point for many. |
Beta Was this translation helpful? Give feedback.
-
Maybe we should start with a definitive problem. Give us a sample app which shows the undesired behavior, then we'll talk solutions. |
Beta Was this translation helpful? Give feedback.
-
I provided an example use case above. You want a full Rails app which shows the issue? The problem is this:
|
Beta Was this translation helpful? Give feedback.
-
@mperham Ok here you go: https://github.com/key88sf/sidekiq-logging The README describes the expected and actual output. It's a dead simple example app. |
Beta Was this translation helpful? Give feedback.
-
@mperham Hmm, I don't really either 😄 I literally just created a new rails app with If you want, just make a new rails app yourself and the only files I added/changed were the 3 listed in the README at the bottom, plus the |
Beta Was this translation helpful? Give feedback.
-
I see the async output if I use |
Beta Was this translation helpful? Give feedback.
-
Perfect, fixed.
|
Beta Was this translation helpful? Give feedback.
-
Any chance you can release a new version @mperham? This change would really help me. |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm a little confused about the new logging logic. From 90535ab:
My understanding is that it makes However, in our case, we set We're seeing two issues:
My point is that the new logging logic doesn't make sense in all cases, and |
Beta Was this translation helpful? Give feedback.
-
Thank you for your hard work. I have been helped by you and Sidekiq gem for years. I know it's too late as the new version that includes this feature already has been released. Let me tell you one thing. To say the least, this change is not useful. I understand that two different loggers can cause confusion for beginners who don't understand the context of Rails process and Sidekiq process. However, the two loggers have their own roles. I don't think forcing it into one will improve anything. Am I the only one who has this opinion? I'd like to hear the opinions of others too. |
Beta Was this translation helpful? Give feedback.
-
So send a PR?
…On Mon, Nov 22, 2021 at 07:03 Marc-Antoine Leblond ***@***.***> wrote:
Right, it's our choice. But I don't see any downside to make Sidekiq not
crash when Sidekiq.logger == Rails.logger and Rails.logger does not
output to STDOUT.
I'm suggesting something like this:
unless Rails.logger == Sidekiq.logger
||::ActiveSupport::Logger.logger_outputs_to?(::Rails.logger, STDOUT)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5021 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAWXZQUJOYWLVXFKE6PXDUNJLVJANCNFSM5F2ZRYOQ>
.
|
Beta Was this translation helpful? Give feedback.
-
First, I just would like to say thank you as well for providing this feature. While I agree that using stdout for logging when using more modern technologies to deploy rails apps is ideal, sidekiq was created to work within the rails framework and ecosystem, so not using the existing logging system of the framework is problematic since there are usually many other processes already in place to manage the existing framework's log files. Extraneous log files become yet another headache to have to manage. |
Beta Was this translation helpful? Give feedback.
-
I know this has been in various issues previously, but I haven't seen any real solution (please correct me if I'm wrong). What I'd like to do is just be able to call the standard
Rails.logger.warn
from within a Sidekiq job and have it work just like logging works outside of sidekiq -- i.e. it prints the log output BOTH to the sidekiq console, as well as in the{env}.log
file (or even a separate sidekiq.log file if easier).IMO, the problem with trying to have a separate
Sidekiq.logger
call is that you often don't know if your code is actually being called from within a sidekiq job or not, or it may be used both from sidekiq and a regular rails request. For example, a pattern we use looks like this:So the DoSomething generic class really doesn't know if it's being called from a Sidekiq job or just synchronously. Ideally we just want to be able to log from that generic class and have it work the same way regardless.
Beta Was this translation helpful? Give feedback.
All reactions