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::StoreHeadersto store theX-Request-Idheader and make it globally available in your application throughServicelog.headers.Servicelog::ShoryukenStoreHeadersto store the ID of background jobs into theX-Request-Idheader requests from within those jobs and make it globally available in your application throughServicelog.headers.Servicelog::RequestIdwhich is similar toActionDispatch::RequestIdbut 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]
endAvailabale 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
endThe 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
endShoryuken 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.