Ariel Valentin

cc: https://github.com/open-telemetry/opentelemetry-ruby-contrib/issues/293

I think that's ok. Low cardinality spans names and high cardinality tags I think is the better way to go. How do others feel? @open-telemetry/ruby-contrib-approvers

Looking at the notification events I see some interesting things at least for ActiveRecord: https://guides.rubyonrails.org/active_support_instrumentation.html#active-record Key | Value | OTel | Description -- | -- | -- | -- :sql...

Perhaps the best way to move forward is to catalog ActiveSupport notifications and create a mapping guide, which may help better inform our decisions: https://docs.google.com/spreadsheets/d/1T7uYBewovl6YGo0uAsvKLLSWO0z_m6-rRJJtzoPb264/edit Here's my 2 cents: I'm...

👋🏼 @jhawthorn The OTel Ruby instrumentation currently relies on monkey patching Rails libraries and I am going to start to work on migrating them to use Active Support Notifications. While...

Hello friends: @robbkidd @robbkidd @chrisholmes @ahayworth I started a bit of an internal refactoring (https://github.com/open-telemetry/opentelemetry-ruby-contrib/pull/641) to see what it would take to separate the logic of payload handling and the...

We have started moving forward with the work here and have completed the migration for `active_job` and `action_pack`. Here is what we have come up with so far: 1. Prefer...

@jhawthorn @bensheldon @composerinteralia I started looking into switching `ActiveRecord` instrumentation to use `sql.active_record` notifications but wanted to highlight what @ahayworth points out in the description of this issue: > `sql.active_record`...

> payload[:name] captures these two. It like won't report 1:1 exactly what otel previously reported, but that may be a good thing (to avoid user confusion in having different things...

I have an anecdote for you. We had been struggling with trying to tune our gateway collectors for a few weeks after we started experimenting with connectors to generate metrics...