I've got a rails 3.1 app deployed on Heroku Cedar. I'm having a problem with the logging. The default rails logs are working just fine, but when I do something like:
logger.info "log this message"
In my controller, Heroku doesn't log anything. When I deploy my app I see the heroku message "Injecting rails_log_stdout" so I think calling the logger should work just fine. Puts statements end up in my logs. I've also tried other log levels like logger.error. Nothing works. Has anyone else seen this?
MBHNYC's answer works great, but it makes it difficult to change the log level in different environments without changing the code. You can use this code in your environments/production.rb to honor an environment variable as well as have a reasonable default:
# https://github.com/ryanb/cancan/issues/511
config.logger = Logger.new(STDOUT)
config.logger.level = Logger.const_get((ENV["LOG_LEVEL"] || "INFO").upcase)
Use this command to set a different log level:
heroku config:set LOG_LEVEL=error
I was just having the same issue, solved by using the technique here:
https://github.com/ryanb/cancan/issues/511
Basically, you need to specify the logger outputs to STDOUT, some gems interfere with the logger and seem to hijack the functionality (cancan in my case).
For the click lazy, just put this in environments/production.rb
config.logger = Logger.new(STDOUT)
config.log_level = :info
As of the moment, it looks like heroku injects these two plugins when building the slug:
rails_log_stdout - https://github.com/ddollar/rails_log_stdout
rails3_server_static_assets - https://github.com/pedro/rails3_serve_static_assets
Anything sent to the pre-existing Rails logger will be discarded and will not be visible in logs. Just adding this for completeness for anyone else who ends up here.
The problem, as #MBHNYC correctly addressed, is that your logs are not going to STDOUT.
Instead of configuring manually all that stuff, Heroku provides a gem that does this all for you.
Just put
gem 'rails_12factor', group: :production
in your Gemfile, bundle, and that's it!
NOTE: This works both for Rails 3 and 4.
Source: Rails 4 on Heroku
Related
I am using Bluemix Ruby buildpack out of the box.
I add some puts lines in my main *.rb file but nothing appears when tailing logs:
cf logs myapp
Searching the docs, I found this post at developerWorks where it is recommended to set runtime into development mode.
I have tried with:
cf set-env myapp RAILS_ENV development
and also adding to the code:
ENV['RAILS_ENV'] = 'development'
but nothing appears in the logs.
Also tried Sinatra options (after changing the code) with same results:
set :environment, :development
set :logging, true
An interesting thing, is that if I stop the app, then all my puts appears after the stacktrace of the FATAL SignalException: SIGTERM error. It seems like a buffer flush contention or anything like that?
Any advice? Thanks!
You can add the following line to your config.ru file. This will disable buffering to stdout and allows your puts commands to stdout to appear correctly in the log output.
$stdout.sync = true
See the answer at What STDOUT.sync = true means? for more details about how puts buffers.
Not Sure but have you tried the following links
https://developer.ibm.com/answers/questions/21548/debugging-a-ruby-app-in-bluemix-with-puts-or-print-statements-written-to-the-log-is-it-possible.html
http://www.ibm.com/developerworks/aix/library/au-unix-commandline/
I have a Ruby on Rails 3.2 application which runs on Heroku. I'm using RSpec for my test suite.
When I started, I just used statements such as
p "Order completed at #{Time.now.to_s}"
to generate logs. I did this because Heroku uses its magical jiggery-pokery to divert all logs to STDOUT anyways.
However, my test suite prints all kinds of logs to STDOUT now, and it is very distracting. I would like those logs to appear when the application is deployed to Heroku, but I don't want to see them on my STDOUT output along with my RSpec output.
Is there a way to divert STDOUT to a file such as log/test.log, or alternatively, use a logging API which will do what I want?
I'm not intimately familiar with the particularities of Heroku's implementation, but you should be able to choose your own file for logging without problem. If they made logging to a file impossible I would be incredibly surprised. You can define your logger in environment.rb differently for prod (ie Heroku) and dev with something like the following in the appropriate conditional:
Rails.logger = Logger.new(STDOUT)
Rails.logger = Log4r::Logger.new("Application Log")
or in your Initializer like so:
config.logger = Logger.new(STDOUT)
config.logger = Log4r::Logger.new("Application Log")
Note that you have lots of options for your logger, for example you can use Log4r instead of the built-in logger.
Check out the RoR Debugging Guide for more
Make sure you include the gem only in your production group to avoid this issue.
group :production do
gem 'rails_12factor'
end
So, I want to have completely custom logging for my sinatra application, but I can't seem to disable the Rack::CommonLogger.
As per the sinatra docs all I should need to do is add the following line (tried setting it to false as well):
set :logging, nil
to my configuration. This does not work however, and I still receive the Apache-like log messages in my terminal. So the only solution I've found so far is to monkey patch the damn thing.
module Rack
class CommonLogger
def call(env)
# do nothing
#app.call(env)
end
end
end
Anyone got any ideas if it's possible to disable this without restorting to such matters?
I monkey patched the log(env, status, header, began_at) function, which is what gets called by rack to produce the apache style logs. We use jruby with logback so we have no use for all the custom logging that seems to pervade the ruby ecosystem. I suspect fishwife is initalizing the CommonLogger, which might explain why all my attempts to disable it or to configure it with a custom logger fail. Probably puma does something similar. I actually had two instances at one point. One logging with my custom logger (yay) and another one still doing its silly puts statements on stderr. I must say, I'm pretty appalled with the logging hacks in the rack ecosystem. Seems somebody needs a big cluebat to their heads.
Anyway, putting this in our config.ru works for us:
module Rack
class CommonLogger
def log(env, status, header, began_at)
# make rack STFU; our logging middleware takes care of this
end
end
end
In addition to that, I wrote my own logging middleware that uses slf4j with a proper MDC so we get more meaningful request logging.
Puma adds logging middleware to your app if you are in development mode and haven’t set the --quiet option.
To stop Puma logging in development, pass the -q or --quiet option on the command line:
puma -p 3001 -q
or if you are using a Puma config file, add quiet to it.
Rack includes a few middlewares by default when you rackup your application. It is defined in this file.
By default, as you mention, the logging middleware is enabled.
To disable it, just pass the option --quiet to rackup:
rackup --quiet
And the default loggin middleware will not be enabled.
Then, you can enable your own logging middleware without pollution by the default logger (named CommonLogger).
You can also add #\ --quiet to the top of your config.ru file to avoir always typing --quiet, but this behaviour is now deprecated.
It's probably not Sinatra what is writing to STDOUT or STDERR, but your webserver. Puma can be started with -q (quiet) option as noted by #matt. When using webrick make sure the AccessLog configuration variable is an empty array, otherwise it will also be logged on your standard output.
Disabling echo from webrick
This is one of the top results. So this probably more of a message to my future self the next time I'm annoyed to death about sinatra/puma not shutting up. But to actually get a silent start up:
class MyApp < Sinatra::Base
configure do
set :server, :puma
set :quiet, true
set :server_settings, Silent: true
end
end
I have been using Thin to run my ruby Sinatra applications but I am now switching over to Puma. Thin creates its own log log/thin.log which I use. I noticed that Puma doesn't produce a log file (not that I can see). I have tried googling for documentation around this but not really found anything.
I was wondering if/how you can specify a log path in Puma.
Any help would be much appreciated.
Alex
Check the example config.rb as recommended on the repo's README.
As shown there:
# Redirect STDOUT and STDERR to files specified. The 3rd parameter
# (“append”) specifies whether the output is appended, the default is “false”.
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr'
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr', true
I recently brought delayed_job into my Rails 3.1.3 app. In development
everything is fine. I even staged my DJ release on the same VPS as my
production app using the same production application server (Thin),
and everything was fine. Once I released to production, however, all
hell broke loose: none of the jobs were entered into the jobs table
correctly, and I started seeing the following in the logs for all
processed jobs:
2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)]
NilClass# completed after 0.0151
2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)] 1
jobs processed at 15.9666 j/s, 0 failed ...
NilClass and no method name? Certainly not correct. So I looked at the
serialized handler on the job in the DB and saw:
"--- !ruby/object:Delayed::PerformableMethod\nattributes:\n id: 13\n
event_id: 26\n name: memememe\n api_key: !!null \n"
No indication of a class or method name. And when I load the YAML into
an object and call #object on the resulting PerformableMethod I get
nil. For kicks I then fired up the console on the broken production
app and delayed the same job. This time the handler looked like:
"--- !ruby/object:Delayed::PerformableMethod\nobject: !ruby/
ActiveRecord:Domain\n attributes:\n id: 13\n event_id: 26\n
name: memememe\n api_key: !!null \nmethod_name: :create_a\nargs: []
\n"
And sure enough, that job runs fine. Puzzled, I then recalled reading
something about DJ not playing nice with Thin. So, I tried Unicorn and
was sad to see the same result. Hours of research later and I think
this has something to do with how the app server is loading the YAML
libraries Psych and Syck and DJ's interaction with them. I cannot,
however, pin down exactly what is wrong.
Note that I'm running delayed_job 3.0.1 official, but have tried upgrading to
the master branch and have even tried downgrading to 2.1.4.
Here are some notable differences between my stage and production
setups:
In stage I run 1 Thin server on a TCP port -- no web proxy in front
In production I run 2+ Thin servers and proxy to them with Nginx.
They talk over a UNIX socket
When I tried unicorn it was 1 app server proxied to by Nginx over a
UNIX socket
Could the web proxying/Nginx have something to do with it? Please, any insight is greatly appreciated. I've spent a lot of time
integrating delayed_job and would hate to have to shelve the work or, worse,
toss it. Thanks for reading.
I fixed this by not using #delay. Instead I replaced all of my "model.delay.method" code with custom jobs. Doing so works like a charm, and is ultimately more flexible. This fix works fine with Thin. I haven't tested with Unicorn.
I'm running into a similar problem with rails 3.0.10 and dj 2.1.4, it's most certainly a different yaml library being loaded when running from console vs from the app server; thin, unicorn, nginx. I'll share any solution I come up with
Ok so removing these lines from config/boot.rb fixed this issue for me.
require 'yaml'
YAML::ENGINE.yamler = 'syck'
This had been placed there to fix an YAML parsing error, forcing YAML to use 'syck'. Removing this required me to fix the underlying issues with the .yml files. More on this here
Now my delayed job record handlers match between those created via the server (unicorn in my case) and the console. Both my server and delayed job workers are kicked off within bundler
Unicorn
cd #{rails_root} && bundle exec unicorn_rails -c #{rails_root}/config/unicorn.rb -E #{rails_env} -D"
DJ
export LANG=en_US.utf8; export GEM_HOME=/data/reception/current/vendor/bundle/ruby/1.9.1; cd #{rail
s_root}; /usr/bin/ruby1.9.1 /data/reception/current/script/delayed_job start staging