oink logs command not working on heroku - ruby-on-rails

I recently started using the oink gem on my heroku app because I noticed a small memory leak with some controller actions. The oink logs command works fine locally but I can't figure out the command to get it to work on my production site.
Here's the command I'm trying:
heroku run oink /log/*
And here's the line from my production.rb file:
config.middleware.use( Oink::Middleware, :logger => Rails.logger )
On my local installation, oink is storing the logs in the /log/oink.log file.

Here's the answer: https://stackoverflow.com/a/14145299/1684322
It is important to use Hodel3000CompliantLogger instead of Rails.logger otherwise oink will fail parsing logfiles. It may also be configured not in config/environments/production.rb but for example in config/initializers/oink.rb
YourApplication::Application.middleware.use( Oink::Middleware, :logger => Hodel3000CompliantLogger.new(STDOUT), :instruments => :memory)
This will make Oink write to default log file which may be later captured by
heroku logs -n500 --app app_name > logfile_for_oink
Or use other log management tool like PaperTrail , or set up syslog drain (rsyslog on another *nix box).
Use oink with --threshold=0 to show all entries

Here is a response from Heroku support:
"In most cases using Oink locally is good enough to understand memory usage issues. Heroku's filesystem is ephemeral and each dyno has its own isolated filesystem, so it's not very practical to write and fetch files. If you can configure Oink to write to stdout or your rails logger its messages should show up in your Heroku logs and you could use a log drain or a log archiving add-on like Papertrail to get a local copy of them."
So it sounds like they are suggesting to use it in development. Or if you can write to stdout and then log drain them yourself into the correct format.
I couldn't figure it out on short notice, so I ended up using the heroku-api gem to automatically restart the app servers every few hours from cron job. This worked as a temporary fix.

Try
heroku run bundle exec oink log/*

To analyse your production logs you'll need to run
heroku run bundle exec oink log/production.log

Related

Rails5 + Passenger + Nginx: logs always go to stdout

I have a Rails 5.0 app running in Passenger with Nginx as the web server.
I can't seem to get the app to output its logs into a file in log/ under the Rails root directory.
RAILS_LOG_TO_STDOUT is NOT set in my environment.
I can confirm that the log file I specify in config/logs/production.rb gets created, but subsequent logger output is not sent to it. My log_level is debug. Instead, the app sends all log output to STDOUT which Passenger dutifully appends to its own log file.
Why?
I figured it out when someone discussing logging for Rails apps mentioned Heroku's rails_12factor gem. I had moved this app from a previous Heroku deployment and didn't realize that gem would capture log output even when not deployed within a Heroku dyno.
The log file is used when the gem is removed.

Is there a way to log commands from Rails console in Heroku?

Hi I am using Heroku and Ruby on Rails. In heroku I can do
heroku run rails c -a app
Which gives me console access, and I can do administrative things like deleting records
I am working in a company setting and I would like to have a log of all commands entered in the console. So if something is wrong, we can audit the logs.
Is there a way to record what is typed in the rails console?
Rails allows you to store the console history but this won't be saved in Heroku, at least not permanently.
In Heroku, when you run heroku run rails console Heroku will create a one-off dyno which will only live as long as the console session. Rails will store the history of commands on the filesystem but once the console is exited the dyno will be cleaned up and the command history file will be deleted along with it.
Rails console is a Railtie and it has some lifecycle hooks, so you could come up with some custom way to persist commands, but there is no built-in way to do it.
Yes, you can now using Heroku's shield private spaces, https://elements.heroku.com/addons/heroku-private-spaces.

How can you see your rails server running on heroku, so you can see full output while sending REST requests?

Typically if you use your localhost, you can just run
rails s
from terminal and then when you hit your webserver, you can see the output.
However, when I run
heroku run rails s
and then I hit my webserver up on heroku, I don't get any output like I do when I "rails s" with localhost.
Is there anyway to achieve this?
If you want to see the live server logs, use this command
heroku logs -t
There are many more options available, look at this answer heroku - how to see all the logs
You can use heroku logs command in terminal to see the log just like you see using rails s command.

check 500 internal server error in production mode in rails 3.2

I have my app in production mode in my linode account and I get in one page a 500 internal server error the message:
We're sorry, but something went wrong.
However in my development environment works fine this page.
How can I debug this error?
How can I see the error origin in my production mode?
I want that rails show errors in production mode.
How can I do it?
Thank you!
If you have access to ssh, log in to your server via ssh and go to your rails log directory, which is inside your rails directory.
Once you are there run the command tail production.log . If this doesn't give you enough information you can also do a tail -n100 production.log (gives you last hundred lines of the production log).
If you have deployed via heroku, then you can access the logs by running heroku logs in your local console. (more information here https://devcenter.heroku.com/articles/logging)
I also find it helpful to use the exception_notification gem https://github.com/rails/exception_notification when running in production, as it emails you a stacktrace when an error occurs. Plenty of others also use Hoptoad (http://hoptoadapp.com/) or Exceptional (http://www.exceptional.io/) however i prefer the simple exception_notification gem.
Also, in some rare occasions when i can't trace the error as a final measure i sometimes open up port 3000 temporarily on the remote server firewall and cd to the rails project and run rails server production with the log level set to debug in config/environments/production.rb so i can see the error in the console, and then close off the port when i have finished.
Hope that helps.
tail -n100 production.log
will only show the last 100 lines of the log file. Just in case you want to see the log running in real time.
use this
tail -1000f log/production.log

Why are certain aspects of my Rails app throwing an exception publicly when I deploy to Heroku?

I am working my way through Michael Hartl's Ruby on Rails Tutorial (on Mac OSX 10.7.2/Ruby 1.9.2/Rails 3.1.1) and just finished Chapter 2, which concludes with deploying a demo twitter app to Heroku.
Everything appears to be working properly when I run the app locally AND I was able to successfully deploy the app to Heroku in some capacity because it is available here: http://rich-twitter-baby.heroku.com/
However, what I can't figure out is why the /users and /microposts pages aren't showing up publicly (with lists of users and microposts respectively) as they do locally. I migrated my database to Heroku and pushed the info up there and everything seemed to work properly, but I get this error message when I try to view the pages publicly.
I've tried running "heroku console" but get this error:
Unable to attach to a dyno to open a console session.
Your application may have crashed.
Check the output of "heroku ps" and "heroku logs" for more information.
And the logs say error H13, while the ps looks like this:
Process State Command
------------ ------------------ ------------------------------
web.1 idle for 1h thin -p $PORT -e $RACK_ENV -R $HER..
Let me know if anyone has any ideas or if more info would help.
Thanks!
I would contact Heroku support on this. Dynos can crash and become 'zombiefied' which means they just sit there idle.
Normally these will clear themselves out within a few hours, but it shouldn't happen that often if at all.
Doing a new deploy will also normally restart everything back to clean.
If it's consistently happening, have you tried spinning up the application locally in production mode to try and reproduce the problem
rails server -e production
, or adding something like the Airbrake add-on to your app to capture the error.
Check your log using
$> heroku logs
At the command line of your development system that you used to push to heroku.
Post the log here if you can't figure it out from that.
I contacted Heroku Support about this issue and it turns out that the answer had to do with which stack my app was being deployed to. I did their workaround and everything is now up and running. Here's the full info from them:
It looks like the problem is that you're using Rails 3.1 and our Bamboo stack; we have full >asset pipeline support on our Cedar stack[1]. Since this is just a demo app, an easy >workaround is to precompile locally and commit the files:
rake assets:precompile
git add -A
git commit -m "precompiling assets"
git push heroku master
To get full asset pipeline support, you need to create your app on the Cedar stack and then >repeat the process you did to get your Bamboo app to work.
[1]: http://devcenter.heroku.com/articles/rails31_heroku_cedar

Resources