This one of the best tools in your toolbox. Logs are great for both debugging and for application analytics.
For maximum detail, the log level should be set to 'debug'. Rails' development mode, for example, defaults the log level to 'debug'.
In Rails you can enable logs by changing the following configuration in the relevant environment initializer file.
The available log levels in are: :debug, :info, :warn, :error, :fatal, and :unknown.
Rails logs many events (like requests and responses) by default, but this is rarely sufficient for a typical production application. You will need to also log other information that is relevant to your problem or solution. Let’s do this through an example.
I’ve a web application written in Rails which allows users to register with their email addresses. I also have requirement to allow users to register with valid email addresses. To check validity we’ve registered with a third-party email validation service. This validation service provides a REST APIs over HTTP, but does not offer a ruby library to integrate with our Rails application.
Let’s take look at the following code snippet.
It works correctly and validates email address but we don't know what was the response sent by the email validation service was.
We can improve the situation by adding logging statements.
When logging, one must consider storage, security and performance implications, especially when logging to disk. Be cautious about what you log, and how much is being logged.
Using the :debug level will have a greater performance penalty than :fatal, as a far greater number of strings are being evaluated and written to the log output (e.g. disk).
Let's re-use the previous example. In this scenario, let’s assume the ruby client for the email validation service API does not have a logging feature.
Great. Now in production, we discover that users are unable to register because the email validation service is consistently returning an invalid response. How do we examine the response to determine the cause? Let’s look at the following code.
I’ve temporarily (while I’m debugging ruby client) redefined validate method for EmailValidationService in users controller, adding logging feature to ruby client. This way, I should be able to log the response from validation service. This is one of easiest way to add basic debugging support to third-party gems.
Special purpose debugging tools allow for powerful, interactive debugging. There are several popular tools in the space, with a great deal of material on their respective sites. Here are three popular debuggers:
Better Errors : https://github.com/charliesome/better_errors
Byebug : https://github.com/deivid-rodriguez/byebug
Pry-debugger : https://github.com/nixme/pry-debugger
Sumit is an engineer at C42 Engineering. If you liked this post, please consider...