Customising Rack instrumentation inside a Grape service about opentelemetry-ruby-contrib HOT 6 OPEN

cc: @muripic

from opentelemetry-ruby-contrib.

What is the current sentiment of forwarding config options?

If grape is taking responsibility for installing rack instrumentation, can we also supply rack config opts through grape?

Possible no code change alternatively, have you tried configuring rack via env vars? If the env vars are present at install time it should still apply them whether its the SDK installing it or grape.

from opentelemetry-ruby-contrib.

@robertlaurin Yes, using envars is the most reliable way to configure the app but we do not do a good job of documenting how to customize the instrumentations using envars on opentelemetry.io. It is centered around using the DSL to accomplish this and it is very surprising to experience Rack configurations being ignored when configured manually.

Using "nested" configurations becomes complicated in applications where you have multiple frameworks involved all trying to configure the Rack instrumentation, including auto-inserting the Rack middleware.

In my case, the ActionPack and Sinatra instrumentation compete with each other in the GitHub monolith to insert the Rack middleware. I have a hack here to have Sinatra disable Rack installation so I have a PR here to actually optionally disable the installation:

#1019

This has come up several times before and it may be resolved by either introducing some sort of dependency tree or ordering in the Registry to ensure no matter the order you declare the instrumentations in the DSL, the registry installs them in the appropriate order with the correct configuration options.

from opentelemetry-ruby-contrib.

@arielvalentin a similar change to the grape instrumentation would also help my use case as we're often mounting Grape within rails. I can see about raising a PR for this.

from opentelemetry-ruby-contrib.