1.6 Logging

Most programming contexts in Rails (models, controllers, view templates) have a logger attribute, which holds a reference to a logger conforming to the interface of Log4r or the default Ruby 1.8+ Logger class.
For other cases, the Rails.logger method references a logger that you can use anywhere.

The standard logger’s severities are :

• debug: Use the debug level to capture data and application state useful for debugging problems later on. This level is not usually captured in production logs.
• info: Use info level to capture informational messages. I like to use this log level for time-stamping non-ohrdinary events tat are still within the bounds of good application behavior.
• warn: Use the warn level to capture things that are out of the ordinary and might be worth investigating. Sometimes I’ll throw in a logged warning when guard clauses in my code keep a client from doing something they weren’t supposed to do.
• error: Use the error log level to capture information about error conditions that don’t require a server restart.
• fatal: The worst-case imaginable has happened—your application is now dead and manual intervention is
  necessary to restart it.

1.6.1 Rails Log Files

The log folder of your Rails application holds three log files corresponding to each of the standardenvironments. Log files can grow very large over time. A rake task is provided for easily clearing the log files:

$ rake log:clear # Truncates all *.log files in log/ to zero bytes

The contents of log/development.log are very useful while you’re working. Many Rails coders leave a
terminal window open with a continuous tail of the development log open while they’re coding:

$ tail -f log/development.log

  Article Load (0.2ms)  SELECT "articles".* FROM "articles" WHERE
    "articles"."id" = $1 LIMIT 1  [["id", "1"]]

This is a list of all the data items contained in that chunk of log output:

• The controller and action that were invoked
• The remote IP address of the computer making the request
• A timestamp indicating when the request happened
• The session ID associated with the request
• The hash of parameters associated with the request
• Database request information including the time and the SQL statement executed
• Query cache hit info including time and the SQL statement triggering results from the cache instead of
  a roundtrip to the database
• Rendering information for each template involved in rendering the view output and time consumed by
  each
• Total time used in completing the request with corresponding request-per-second figures
• Analysis of the time spent in database operations versus rendering
• The HTTP status code and URL of the response sent back to the client

1.6.2 Tagged Logging

Log files can contain an extensive amounts of information, making tracking down issues or particular requestsdifficult. To alleviate this issue, Rails 3.2 introduced the ability to tag your log messages.

The easiest way to include extra “tagged” information in your logs, is to include methods which respond to the request object to the config.log_tags configuration setting.
For example, setting config.log_tags to include :subdomain:

config.log_tags = [:subdomain]
# result in subdomain of a request being prefixed with square brackets to each log message
> [admin] Started GET "/articles" for 127.0.0.1 at 2013-02-01 11:49:09 -0500

1.6.3 Log File Analysis

• Performance: One of the more obvious analyses would be a study of the performance of your application. The faster your requests execute, the more requests you can serve with a given Rails process. That’s why performance figures are often expressed in terms of requests per second. Find the queries and rendering sections that are taking a long time and figure out why.
  It’s important to realize that the times reported by the logger are not super-accurate. In fact, they’re wrong more often than not, if simply for the reason that it’s very difficult to measure the timing of something from within itself. Add up the percentage of rendering and database times for any given request and it will not always be close to 100%.
  However, despite not being accurate in a purely objective sense, the reported times are perfect for making subjective comparisons within the same application. They give you a way of gauging whether an action is taking longer than it used to, or whether it is relatively faster or slower than another action, and so on.

• SQL queries: Active Record not behaving as expected? The fact that SQL generated by Active Record is logged can often help you debug problems caused by complicated queries.

• Identification of N+1 select problems: Whenever you are displaying a record along with an associated collection of records, there’s a chance that you will have a so-called N+1 select problem. You’ll recognize the problem by a series of many SELECT statements, with the only difference being the value of the primary key.

1.6.3.1 Rails::Subscriber.colorize_logging

Tells Rails whether to use ANSI codes to colorize the logging statements. The colors make it much easier to read the logs (except on Windows) and may complicate matters if you use software like syslog. Defaults to true. Change to false if you view your logs with software that doesn’t understand the ANSI color codes.