Introduce instrumentation for all Elasticsearch HTTP requests
This introduces the same pattern of instrumentation [we use for Redis](https://gitlab.com/gitlab-org/gitlab/-/blob/b16db2726d7b429d740ef3642dda13b528fc4fda/lib/gitlab/instrumentation/redis.rb). This MR also adds the instrumentation details to sidekiq logs like we do with Redis. This instruments at the lowest level by instrumenting the elasticsearch-transport gem which is used by the elasticsearch-rails gem and elasticsearch-api gem which are the higher level abstractions used by GitLab. This has been tested to log requests coming from both places. Other options considered for this solution involved following a similar pattern to https://github.com/elastic/elasticsearch-rails/blob/1c3226d8186af6e8446fa5091f5b27760c29f896/elasticsearch-rails/lib/elasticsearch/rails/instrumentation/log_subscriber.rb which would extend the log subscriber pattern to be more than just searches in the context of the elasticsearch-rails gem but this seemed more convoluted than the approach I took since it requires monkey patching to publish a message then a separate class to subscribe and store those messages and so the pattern didn't seem to be beneficial unless you plan to have multiple subscribers. Additionally I considered using Faraday middleware to track this since the Elasticsearch gem uses Faraday by default but again I opted not to do that since it seemed trickier to manipulate the client config following https://github.com/elastic/elasticsearch-ruby/tree/master/elasticsearch-transport#transport-implementations and implement the required middleware etc. than just prepending the method following the same pattern as Redis.
Showing
Please register or sign in to comment