If you have a microservice infrastructure and services are growing everywhere you will release challenges as soon as more service are interconnected and you need to figure out problems.
For this issue the X-Request-Id
HTTP header was introduced. In Rails the ActionDispatch::RequestId
creates a unique ID for each request if not already defined by the X-Request-Id
header. Unfortunatelly if your service connects to another service the passing over of this unique id is not in the scope of the ActionDispatch::RequestId
middleware.
For that issue Servicelog helps you to use the same X-Request-Id
for multiple requests.
Add this line to your application's Gemfile:
gem 'servicelog', git: 'https://github.com/volcanic-uk/servicelog.git', tag: 'v0.0.1'
then execute:
$ bundle install
Next, you need to run the generator:
$ rails generate servicelog:install
The generator will install an initializer which describes Servicelog's configuration options.
By default Servicelog introduces two new middlewares and deletes the ActionDispatch::RequestId
. The middlewares introduced by Servicelog are:
Servicelog::StoreHeaders
to store theX-Request-Id
header and make it globally available in your application throughServicelog.headers
.Servicelog::ShoryukenStoreHeaders
to store the ID of background jobs into theX-Request-Id
header requests from within those jobs and make it globally available in your application throughServicelog.headers
.Servicelog::RequestId
which is similar toActionDispatch::RequestId
but it takes the incomingX-Request-Id
(up to 6 callers) and append a new ID to it, this allows to log a unique request on the back server but also see the calling server ID.
Catching and creating a unique request ID is great, but to really take advantage of the correlation in a service based architecture you'll need to pass the X-Request-Id
on each request to the next service. It is up to you to ensure that all the requests in your service send the correct X-Request-Id
to the next service, although Servicelog provides a common list of adapters to override the base class and ensure the X-Request-Id
is sent.
The adapters
setting allows you to specify which adapters you want to use to send the X-Request-Id
in each request.
By default the adapters
setting is set to []
- You can change it in your initializer:
Servicelog.configure do |config|
config.adapters = %i[activeresource httparty]
end
Availabale adapters:
activeresource
- https://github.com/rails/activeresourcehttparty
- https://github.com/jnunemaker/httparty
You can prefix a request using the prefix
configuration, by default the prefix
setting is set to nil
- You can change it in your initializer:
Servicelog.configure do |config|
config.prefix = :name
end
The ShoryukenStoreHeaders
middleware is executed whenever a background job is started, then it grabs the message ID and adds it to the X-Request-Id
header. This way the job ID is sent with each HTTP request made from inside the job.
It works for both Active Job
and Shoryuken::Worker
.
To register to Rails:
Edit/Create config/initializers/00_shoryuken.rb
:
Shoryuken.configure_server do |config|
{ other code... }
config.server_middleware do |chain|
chain.add Servicelog::ShoryukenStoreHeaders
end
end
Shoryuken middleware documentation link here.
After checking out the repo, run bin/setup
to install dependencies. Then, run rake test
to run the tests. You can also run bin/console
for an interactive prompt that will allow you to experiment.
To install this gem onto your local machine, run bundle exec rake install
. To release a new version, update the version number in version.rb
, and then run bundle exec rake release
, which will create a git tag for the version, push git commits and tags, and push the .gem
file to rubygems.org.
Bug reports and pull requests are welcome on GitHub at https://github.com/volcanic-uk/servicelog. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
The gem is available as open source under the terms of the MIT License.
Everyone interacting in the Servicelog project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.