Rails added “taggedlogging” awhile back, but it’s never seemed like a particularly useful thing to me. I care far more about the log output than a request ID or other data.But the more and more I debug odd edge-cases in other people’s Rails apps, the more I see the need the potential benefits.
“request_id” may be what most people think of with Rails’ tagged logging. Adding this to your production.rb:
Gives you a unique ID for each request:
This can be very handy to use when filtering a noisy log stream. (FYI: logging request ID’s is about to become a default in Rails)
But the full power of this feature is that you can shove whatever data you want in there. UUID, server name, or even a Git SHA.
In a recent Heroku support ticket, a customer mentioned he was using Heroku’s Preboot feature. With Preboot, Heroku will deploy your code to a new dyno, then cut over the requests to it, thus avoiding any request queueing while your app restarts.
The customer wanted to be able to see which version of his code was serving incoming requests at a particular time. This is a great use-case for Rails’ tagged logging, and Heroku’s new “dyno metadata”.
“Dyno metadata” adds a ton of information on your running dyno like: app id, dyno id, release version, and Git SHA. This information is saved as an ENV var for easy reference. Here’s a sampling:
This feature is currently as “Labs” feature, so add it to your app with this command:
You can then pass the ENV["HEROKU_SLUG_COMMIT"] into your Rails’ logging:
Now you’ll know exactly which Git version your app is running. Very handy for Preboot or otherwise! (Alternatively, your might choose to use ENV["HEROKU_RELEASE_VERSION"] instead, since the Git SHA length might be bothersome)
Here’s an example of one of my Heroku apps cutting over from one version of my code to another. Note the change from adc997c to 7be3dfd:
Tagged Logging is an incredibly powerful feature in Rails that gets very little attention. Here’s a few other articles I found that give it a more in-depth explanation. Enjoy!