How to add information to the Rails logs

You may not have thought of it this way, but you’ve been working with Rails logs since the first time you entered script/server. All of that information flowing by is the development log. You can find all of it in the log directory of your application, stored in the development.log file. (There are also test.log and production.log files there for use when your application runs in test or development mode, as described in the next chapter.)

While Rails is certainly generous with the information that it sends to the log in development mode, that sheer volume can make it hard to find things. It may also not be sending what you want to see. If you want to send something specific to the log, use the logger object in your model, controller, or view. In a model or controller, this would
look like:

logger.info 'This is a message to send to the log'

while in the view it would look like:

 <% logger.info 'This is a message to send to the log' %>

You can use <%= rather than <% to send the message to both the screen and the logger if you want to combine a visible message with a permanent record:

<%= logger.info 'This is a message for the view and the log' %>

The user would then see “This is a message for the view and the log” on her screen, and it would also be stored in the log file.

One piece of information that is logged and is worth pointing out is timing information. You’ll find lines in the log like:

Completed in 0.01451 (68 reqs/sec) | Rendering: 0.00775 (53%) | DB: 0.00093 (6%) | 200 OK

That tells you how fast the whole thing was completed, how long the view processing took (rendering), and how long the database processing (DB) took. The last entry on the line is the HTTP response. You should note that Rails can probably execute the code much faster when in production; during development, it’s loading, reloading, and logging a lot of extra information.

There may also be times you want to make certain that certain information isn’t logged. This is most important for sensitive information and is easily accomplished with the filter_parameter_logging method:

filter_parameter_logging :password

You can put these calls in the controllers that receive the affected parameters. However, if you want to filter parameters that apply to many controllers (like password data), it’s safest to put these calls in app/controllers/application.rb, where they will apply to all controllers.