Post as a guest Name. Email Required, but never shown. The Overflow Blog. Podcast what if you could invest in your favorite developer? Who owns this outage? Building intelligent escalation chains for modern SRE. Featured on Meta. Now live: A fully responsive profile. Reducing the weight of our footer. Linked 1. Related Hot Network Questions.
Question feed. Stack Overflow works best with JavaScript enabled. Accept all cookies Customize settings. Each level defines how much information your application will log:. The debug and info levels log the most information about application behavior, while the higher levels only log warnings or errors.
By default, Rails applications generate logs at the debug level for all environments, including production. A single debug log entry can carry a lot of information:. However, it may be too verbose for production environments. You can adjust the log level for any environment by editing the applicable environment file:. The info log level will still include information about individual requests but will exclude any low-level, diagnostic information:. Both example logs shown above contain information useful for understanding typical application behavior and operations:.
At the debug level, logs contain more diagnostic information, in addition to the data listed above:. The status at the end of each log shows if a request generated either a successful response 2xx , a redirect 3xx , a client error 4xx , or a server error 5xx. A client error can indicate a page in the application is missing, while a server error could mean a server is rebooting or down altogether. If your application generates either a client or server error, you will also see its stack trace in the log so you can more easily find the root cause and resolve the issue:.
When debugging an issue, you can refer to logs in order to understand what is causing unexpected or unwanted behavior in your application.
For example, if you are not seeing the appropriate page for a request then you may see the following error:. The router maps URLs and HTTP requests through the appropriate controller so the application can respond by serving the right web page.
Even in their default format, Rails logs provide information that can be very helpful in troubleshooting common application errors. To collect a greater amount of detail, you can add custom logging for Rails. To further enhance the logs your application generates, you can create customized logs with the ActiveSupport::Logger class. This class is built-in for Rails 5. If you want to log specific attributes about an article when it is selected in the application, you can extend the method to include a custom logging statement:.
The Ruby inspect method prints out all attributes associated with the selected event, including timestamps, ids, and form field values. Now, whenever an article is selected, your application will generate a log similar to this at the debug level:. As with your Rails environments, you can set any log level to your custom logs.
The logger. Both logger. Rails enables you to create any type of log for your application out-of-the-box and set appropriate log levels. In small applications, Rails manages logs well, so you can easily debug issues without the need for third-party libraries. As your application grows, however, you will need to consider how to better manage the volume of logs it generates. Now, why switch from just making a configuration change for this logging?
Why go the route of creating a formatter class? Well, ultimately, based on your needs you may want to throw in some fancier logic in your formatter. Or what severity it is. Using classes makes an easier transition to complex logic for logs. Before we move on to best practices, I want to make one additional note. And I want to reduce confusion where I can.
Okay, so now that we know the basics of our Rails logger, what do we need to know next? Well, how about best practices? As mentioned earlier, we can set different logging levels for each environment. So, when logging messages to yourself or your band of merry developers, make sure to log at the correct level. It will simplify debugging and help reduce log pollution when things are logged at too high a level. Some of you may have noticed we can log in different ways.
For example, we can log message strings:. The two statements seem fairly similar. In contrast, in the first example the application concatenates the string before inspecting whether the log level applies. By default, we typically log into environment-specific log files in our Rails app. However, logging into a server in order to grep or tail a file lacks any real-world usability. We need a way to mine our logs for information as well as stay on top of issues and metrics.
With Retrace, you can consolidate and view logs easily. You can also easily search and filter for logs. And, most interestingly, you can analyze trends in the logs. Installing and configuring Retrace for your Rails app involves just a few steps. Another great feature of the Rails logger involves tags.
Tags help categorize different logs for different use cases. You can tag user-generated request UUIDs, particular logging use cases, or relevant categories based on the code that executes. Why would we want to do this? Well, it will provide an easy way to see all the log messages related to a particular request. This helps tremendously when debugging an issue. And these users may be in different time zones, have different knowledge of the application, or have different skill levels. Additionally, the logs may serve different use cases.
0コメント