kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Default new apps to tag logs with request_id

Browse source 
In high volume applications it can be very difficult to figure out what is happening in logs because each request is not easily identified. For example 3 requests could look something like this:

```
Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:21 +0000
  Rendered welcome/index.html.erb within layouts/application (0.1ms)
Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:22 +0000
Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:23 +0000
  Rendered welcome/index.html.erb within layouts/application (0.1ms)
Processing by WelcomeController#index as HTML
Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
Processing by WelcomeController#index as HTML
  Rendered welcome/index.html.erb within layouts/application (0.1ms)
Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
  Processing by WelcomeController#index as HTML
Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
```

The `:request_id` log tag ensures that each request is tagged with a unique identifier. While they are still interleaved it is possible to figure out which lines belong to which requests. Like:

```
[c6034478-4026-4ded-9e3c-088c76d056f1] Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:21 +0000
[c6034478-4026-4ded-9e3c-088c76d056f1]  Rendered welcome/index.html.erb within layouts/application (0.1ms)
[abuqw781-5026-6ded-7e2v-788c7md0L6fQ] Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:22 +0000
[acfab2a7-f1b7-4e15-8bf6-cdaa008d102c] Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:23 +0000
[abuqw781-5026-6ded-7e2v-788c7md0L6fQ]  Rendered welcome/index.html.erb within layouts/application (0.1ms)
[c6034478-4026-4ded-9e3c-088c76d056f1] Processing by WelcomeController#index as HTML
[c6034478-4026-4ded-9e3c-088c76d056f1] Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
[abuqw781-5026-6ded-7e2v-788c7md0L6fQ] Processing by WelcomeController#index as HTML
[abuqw781-5026-6ded-7e2v-788c7md0L6fQ]  Rendered welcome/index.html.erb within layouts/application (0.1ms)
[abuqw781-5026-6ded-7e2v-788c7md0L6fQ] Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
[acfab2a7-f1b7-4e15-8bf6-cdaa008d102c]  Processing by WelcomeController#index as HTML
[acfab2a7-f1b7-4e15-8bf6-cdaa008d102c] Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
```

Now if you have the logs and you find this unique ID you can filter to only look at information from that request. So a filtered log output would be very clear:

```
[c6034478-4026-4ded-9e3c-088c76d056f1] Started GET "/" for 72.48.77.213 at 2016-01-06 20:30:21 +0000
[c6034478-4026-4ded-9e3c-088c76d056f1]  Rendered welcome/index.html.erb within layouts/application (0.1ms)
[c6034478-4026-4ded-9e3c-088c76d056f1] Processing by WelcomeController#index as HTML
[c6034478-4026-4ded-9e3c-088c76d056f1] Completed 200 OK in 5ms (Views: 3.8ms | ActiveRecord: 0.0ms)
```

In addition to this benefit the `:request_id` can be set via the `X-Request-ID` header so that the same request could be traced between multiple components. For example a request comes in Nginx (or another load balancer) could assign a request id. As the load balancer processes the request I can log using that id, then when the request is passed on to Rails, the same id is used. That way if a problem is determined to be not caused in Rails it could be traced back to other components with the same ID. You can set a value in nginx for example using something like this:

```
  location / {
      proxy_pass http://upstream;
      proxy_set_header X-Request-Id $pid-$msec-$remote_addr-$request_length;
  }
# http://stackoverflow.com/questions/17748735/setting-a-trace-id-in-nginx-load-balancer
```

Heroku sets this header value so problems like timeouts that are logged by like router can be traced back to specific request within the application.

Whether you are using components that are setting request ID or not, all production applications can benefit from the additional debugging information of having a unique identifier for all requests. This change will only affect new applications, anyone can opt out by commenting or removing the line in `config/production.rb`.
This commit is contained in:
schneems 2016-01-06 15:04:36 -06:00
parent 6a42f0093e
commit 81d3bec460
2 changed files with 19 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
railties/lib/rails/generators/rails/app/templates/config/environments/production.rb.tt
View file

@ -54,7 +54,7 @@ Rails.application.configure do
config.log_level = :debug
# Prepend all log lines with the following tags.
# config.log_tags = [ :subdomain, :request_id ]
config.log_tags = [ :request_id ]
# Use a different logger for distributed setups.
# require 'syslog/logger'

18
railties/test/application/configuration_test.rb
View file

@ -79,6 +79,24 @@ module ApplicationTests
end
end
test "By default logs tags are not set in development" do
restore_default_config
with_rails_env "development" do
app 'development'
assert Rails.application.config.log_tags.blank?
end
end
test "By default logs are tagged with :request_id in production" do
restore_default_config
with_rails_env "production" do
app 'production'
assert_equal [:request_id], Rails.application.config.log_tags
end
end
test "lib dir is on LOAD_PATH during config" do
app_file 'lib/my_logger.rb', <<-RUBY
require "logger"