opentelemetry-rails?

[ahayworth]

At GitHub, we have an internal helper gem for OpenTelemetry - and as part of that, it includes a railtie to make setup even simpler for Rails.

1. Is this something that others would want?
2. ...and if so, what parts of setup would you want it to handle?

Personally, I like it (hence why I'm asking). I also think it could be especially valuable when the Logging and Metrics SDKs get further along.

---

For reference, a little bit about how we've implemented our version of an OpenTelemetry railtie. If it's loaded via Bundler, it actually requires zero configuration (and picks sensible defaults for things). But it's otherwise configurable like so:

# in config/application.rb

module MyRailsApp
  class Application < Rails::Application
    # optional - defaults to an OTLP exporter in Rails.env.production; a NoopSpanExporter in test
    # or rails console, or a ConsoleSpanExporter in dev
    config.telemetry.exporter = OpenTelemetry::SDK::Trace::Export::InMemorySpanExporter.new

    # optional - sets the service_name; defaults to guessing based on the module name
    config.telemetry.application_name = "my_fancy_app"

    # optional - sets the OpenTelemetry.logger. By default, re-uses Rails.logger
    config.telemetry.logger = SomeCustomLogger.new

    # optional - hooks up the specified instrumentation libraries (assumes they are already in
    # the Gemfile). The hash value is passed through as instrumentation options.
    config.telemetry.instrumentation = {
      'OpenTelemetry::Instrumentation::Mysql2' => { enable_sql_obfuscation: true },
      'OpenTelemetry::Instrumentation::Redis' => {},
    }
  end
end

[nvolker]

@ahayworth I'm about to start implementing a similar wrapper to what you're describing for our Rails applications.

1. I think this would be great.
2. What you've given as an example looks perfect for our needs. I can circle back to you if the requirements extend past this.

Also, I'm wondering if this Railtie has developed since you posted this in May of 2021?

As a bit of a related side note, I'm looking at storing the trace_id in the RequestStore to be used by other vendors/telemetry.

The reason being is that it would allow us to switch between different visualizers/vendors using a single trace_id to scope on only the telemetry that's relevant to the user during an investigation/debugging session. Have you done something similar here, or do you that it isn't something you've needed?

[ahayworth]

The astounding @arielvalentin actually just merged a minimal railtie last week - see: #1111

That said, I think it is a little less full-featured than what the GitHub internal railtie took care of. However, I no longer work there, and so I can't comment on the precise state of it at the moment. 😢

I would encourage you to implement your own, to meet your needs. One of the things I learned when working on it originally was that it wasn't actually very hard to do, and it's a very powerful way to configure things in the same way across multiple rails apps. We're happy to help out here as you work through it!

---

As a bit of a related side note, I'm looking at storing the trace_id in the RequestStore to be used by other vendors/telemetry.

Interesting - I can't say much one way or the other about it; I haven't tried something like that. But in general I think using the trace_id is a good way to correlate between different telemetry solutions; yes - particularly it's useful to emit in your logs!

That said; as a value for a metric tag ... it would be exceedingly high-cardinality and might be something best avoided in that situation. But, then again, as a tag on an exemplar for metrics ... that is a different story yet again.

Let me know how it goes! I'm curious what you can build with it! :)

[nvolker]

Oh, nice! Will definitely take a look at the Railtie. Fiddling around with my own implementation at the moment now too, and appreciate the advice. For the time being it seems I'm going to be able to create 1/2 helper methods to help me more easily extract and inject the trace_id into our other telemetry (specifically logs and alerts). On the metrics side, I will definitely not be sent through the hexed trace_id as a tag. Wouldn't want our poor little Influxdb database falling over, although it's always a nice excuse to teach people about cardinality 😉

[arielvalentin]

@nvolker The Railtie has not be released yet so if there is any additional functionality you would like we'd appreciate any contributions!

Adding log correlation for Rails would likely be easiest via log_tags or injected by a custom log formatter.

[PedroAugustoRamalhoDuarte]

This is a good ideia. Do you guys already send log with open-temeletry and rails? How can i setup?