Why is log management a vital part of Rails application development?
Logging is useful in building, managing and debugging Rails applications. Most logging functionalities are built into the application, and it is fairly simple to find the logs. However, as your applications scale up in volume, it becomes difficult to trace the source of an issue. That’s when you want to implement a cloud based log management system to get a unified view of all logs from your Rails application.
Rails applications create and save logs for each environment separately. You can choose to use the standard logging levels in rails such as Debug, Info, Warn, Error, Unknown and Fatal; or set up custom log statements for most application events. In versions before 4.2, all production logs in Rails were set to the “info” level and logs from all other environments were set to “Debug”. This is not the case anymore, all logs in all environments are set to “Debug,” making log search and analysis more difficult than in earlier versions. This makes log monitoring using an open source and cloud based log management platform practically necessary.
Rails logging then: using Rails Logger
Most Rails developers used the built-in Rails logger for managing their logs. The Rails Logger is part of the active library in Rails, an extension of the logger class, that is a built-in logging library for basic logging of simple applications. Rails classifies logs based on the environment where the event occurs – as development logs, staging logs and production logs. All logs are saved to the log/ directory in the project. The six different log levels that Rails follows by default can be used to squash or raise the visibility into certain log levels. Their usage and uses are tabulated below:
||This is the most detailed log message in Rails. It covers all the information that the team needs to debug any issues in the development and production environments.|
||This covers application operations related to starting and stopping services or application metrics and stats that are configured to log. For instance, response times, input parameter requests, etc.|
||This is a log that indicates that something went wrong in the application and the application recovered from the error. These are errors with some urgency. For instance, if an integrated application parses attributes that are not supported by the Rails application.|
||This refers to errors that lead to an operational failure while the application continues to perform as expected. For instance, a failed transaction or inability to update the database with certain information.|
||This is a log that indicates a crash in the application’s functioning. This log is treated with high priority and a good log management software will provide alerts for these logs.|
||This is a catchall for all logs that cannot be classified under the levels mentioned above.|
The downside of using the Rails logger is the fact that it is too noisy for the development environment. With its messaging running across lines, developers have a tough time deciphering the message and reacting to them.
Rails logging now: using Lograge
Lograge was created to overcome the issues with Rails’ default logging utility. Instead of creating log messages across multiple lines, lograge writes single line log messages with clear and precise information. Lograge is a gem that you can add to the Rails library to convert logs into less human-readable formats, such as JSON, for assimilation and analysis. It also includes logging database events in addition to application logs.
As with other tech stacks, it is necessary to establish some best practices for effectively managing Rails application event logs.
Reduce log bloat: As the logging utility is included in Rails, the volume of logs produced in all your environments can be overwhelming during debugging. Large volumes of logs created also reduce your application’s performance. The best way to reduce log volume would be to record only certain log levels.
Avoid sensitive data: Rails’ inbuilt utility generates logs in plain text, so it is recommended to filter out any sensitive data that may be parsed into the logs. Displaying sensitive data in plain text could leave that information vulnerable to possible malfeasance.
Meaningful logs: Add more context to your logs to make debugging easier. This could be anything from including a detailed timestamp on every event to expected values of parameters.
Log agent friendly format: While Rails’ inbuilt utility renders logs in a readable format, it is not very useful when you wish to implement a log management tool. The best log agents on the market parse JSON versions of logs better. This is easy to achieve in Rails with lograge.
observIQ has a solution in the making
We are working on bridging the logging gaps in Rails applications. Starting this September, you will have a seamless logging experience with observIQ’s robust logging agent ingesting, parsing and auto-indexing logs from every aspect of your Rails application. Stay tuned for more updates related to this. For all other questions, support requests and sales enquiries reach out to our support.