Conform attributes to v1.27 semantics for OpentelemetryOban #436

danschultzer · 2024-12-15T15:45:10Z

Stacked on #435 which needs to get in first. Check the latest commit for the changes here.

Follows the guideslines set out in https://github.com/open-telemetry/semantic-conventions/blob/v1.27.0/docs/messaging/messaging-spans.md#destinations

This does introduce a bunch of breaking changes so let me know if backwards compability is required. I can keep the old attributes, but not sure if we should just go with major release instead since there's a lot of things that are different now? Same question as in #430

Changes

messaging.destination -> messaging.consumer.group.name
messaging.destination.kind is removed
Span names {destination} {operation} changed to{operation} {destination}
Span names {plugin} process changed to oban.plugin {plugin}
Span names Oban bulk insert changed to {operation} or {operation} {destination} depending whether all are the same job type

Added

messaging.destination.name (the worker module)
messaging.operation.name
messaging.operation.type
messaging.message.id

There's also more to this to get it to be compliant with 1.27 conventions. A larger one is that we probably need to deal with creation context? https://github.com/open-telemetry/semantic-conventions/blob/v1.27.0/docs/messaging/messaging-spans.md#context-propagation

Related #367

- Use the worker name as the description and transaction name instead of "{worker} process" - Use "queue.process" as the op - this is according to the docs https://develop.sentry.dev/sdk/telemetry/traces/modules/queues/ Maybe this could be improved in the opentelemetry_oban package?

esambo · 2025-01-31T22:18:13Z

Any updates on this one?

epinault · 2025-02-28T16:41:49Z

@danschultzer Hello! need any helps with this? how do we this move forward?

danschultzer · 2025-02-28T21:59:10Z

I don’t think there’s anything you can do @epinault. I’ve been waiting since December for my PRs to be reviewed, but this repo is in low maintenance mode with only one of my PR’s reviewed and merged so far. I doubt this will be reviewed anytime soon. I understand that these PR’s may require considerable time by @bryannaegele and @tsloughter to be addressed, but I’m at a point where I’ll have to fork and release alternative hex package to unblock development at work. I can ping here once rubber meet the road, probably a week or two out.

bryannaegele · 2025-02-28T22:19:27Z

Hey, folks. Just want to clear up that Tristan and I are not the codeowners of all of these libraries. We do not have the time or expertise to do everything. Please feel free to ping the codeowners for respective libraries for assistance. If you want to become an approver, see the contributing guidelines to familiarize yourself with the process.

If the codeowner is unresponsive and you want to take ownership, we can discuss that, but let's start with them.

epinault · 2025-02-28T23:44:18Z

@andrewhr are you still part of the otel project? @indrekj do you need help with maintainers?

dustinfarris · 2025-05-23T05:54:00Z

Hi @indrekj could you take a look at this PR?

indrekj

Hey. Sorry, I'm not really active contributing to opentelemetry any more. I probably should remove myself from the maintainers.

I did go over the PR and it seems to make sense to me. But again, I haven't worked on it quite a while.

tsloughter · 2025-05-23T11:34:44Z

@indrekj thanks for going over the PR anyway. That'd be great if we could keep the maintainers list up to date with those actively working on the applications.

dustinfarris · 2025-05-25T21:56:44Z

@danschultzer can this be marked ready for review?

tsloughter · 2025-05-30T11:48:37Z

Wow, lots of open Oban PRs. We need someone to really maintain the Oban instrumentation library. I am not familiar with either Oban or the messaging semantic conventions so would prefer not to. I don't know if @bryannaegele is even familiar with Oban but seemed to be taking up the work anyway.

It'd be great to find someone familiar with Oban who would want to become familiar with the semconv and take on getting this PRs either feedback, merged or closed.

Miradorn · 2025-06-02T09:37:56Z

FWIW: Not an expert on the otel semantic conventions, but as a user of Oban and OpenTelemetry instrumentation, this looks good to me!

solnic · 2025-06-30T07:32:52Z

Hey folks, we recently added support for OpenTelemetry to the Sentry Elixir SDK and now we'd love to get proper Oban support too. Is there anything we can do to help get this merged and released? 🙂

tsloughter · 2025-06-30T07:42:45Z

@solnic really we need someone to step up as a codeowner to feel confident in merging that they reviewed it fully (not just the code but that it matches the semconv too) since they'll be responsible for reviewing/releasing fixes :).

It is also a draft and has conflicts. So whoever picks it up needs to open a new PR.

I may do the full semconv compare myself since it is getting so many requests for merger but then I can't fix the conflicts and open the PR as I wouldn't be able to +1 it for merger.

grzuy

@danschultzer thanks for working on this!

Trying to provide my 2cents to help with some oban progress.

grzuy · 2025-11-06T14:36:15Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

    [
      event(
-        name: "exception",
+        name: :exception,


This was already fixed separately in #558

grzuy · 2025-11-06T14:36:37Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban/plugin_handler_test.exs

    [
      event(
-        name: "exception",
+        name: :exception,


This was already fixed separately in #558

grzuy · 2025-11-06T14:36:49Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

    [
      event(
-        name: "exception",
+        name: :exception,


This was already fixed separately in #558.

grzuy · 2025-11-06T14:36:54Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

    [
      event(
-        name: "exception",
+        name: :exception,


This was already fixed separately in #558.

grzuy · 2025-11-06T14:37:35Z

instrumentation/opentelemetry_oban/mix.exs

    [
      {:oban, "~> 2.0"},
-      {:opentelemetry_api, "~> 1.2"},
+      {:opentelemetry_api, "~> 1.4"},


Is there a need to further restrict the opentelemetry_api version requirement as part of this?

grzuy · 2025-11-06T14:37:41Z

instrumentation/opentelemetry_oban/mix.exs

-      {:opentelemetry_semantic_conventions, "~> 0.2"},
-      {:opentelemetry, "~> 1.0", only: [:test]},
+      {:opentelemetry_semantic_conventions, "~> 1.27"},
+      {:opentelemetry, "~> 1.4", only: [:test]},


Is there a need to further restrict the opentelemetry version requirement as part of this?

grzuy · 2025-11-06T14:57:14Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

+             "messaging.destination.name": "TestJob",
+             "messaging.consumer.group.name": "events",
+             "messaging.operation.name": :send,
+             "messaging.operation.type": :publish,


I think messaging.operation.type needs to be either send or create in this case?

source: https://opentelemetry.io/docs/specs/semconv/registry/attributes/messaging/#general-messaging-attributes

grzuy · 2025-11-06T15:00:59Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

+             "messaging.system": :oban,
+             "messaging.destination.name": "TestJob",
+             "messaging.consumer.group.name": "events",
+             "messaging.operation.name": :send,


src: https://opentelemetry.io/docs/specs/semconv/registry/attributes/messaging/#general-messaging-attributes

Should the "oban specific" term be insert?

grzuy · 2025-11-06T15:07:37Z

instrumentation/opentelemetry_oban/test/opentelemetry_oban_test.exs

-             "messaging.destination_kind": :queue,
+             "messaging.system": :oban,
+             "messaging.destination.name": "TestJob",
+             "messaging.consumer.group.name": "events",


So this means we're making the interpretation that for the latest "Semantic conventions for messaging spans"

Consumer group => Oban queue
Destination => Oban Worker

right?

For what is worth, this other pull request (https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/528/files#r2500483804) seems to be taking a different approach and keeping the interpretation of "Destination" as the oban queue, like it is right now.

And setting the Oban Worker module atom as the messaging.client.id.

github-actions bot added elixir instrumentation opentelemetry_oban labels Dec 15, 2024

danschultzer changed the title ~~USe v1.27 semantics for OpentelemetryOban~~ Use v1.27 semantics for OpentelemetryOban Dec 15, 2024

danschultzer changed the title ~~Use v1.27 semantics for OpentelemetryOban~~ Switch to v1.27 semantics for OpentelemetryOban Dec 15, 2024

danschultzer mentioned this pull request Dec 19, 2024

Support for Traces/Transactions via Opentelemetry getsentry/sentry-elixir#784

Closed

Update to semantic conventions 1.27

a60f775

danschultzer force-pushed the update-oban-attributes branch 2 times, most recently from 81ac160 to 191b5e9 Compare January 9, 2025 00:20

Conform attributes to semantic conventions 1.27

8d6a9ad

danschultzer force-pushed the update-oban-attributes branch from 191b5e9 to 8d6a9ad Compare January 9, 2025 00:22

danschultzer changed the title ~~Switch to v1.27 semantics for OpentelemetryOban~~ Conform attributes to v1.27 semantics for OpentelemetryOban Jan 9, 2025

esambo mentioned this pull request Jan 29, 2025

opentelemetry_oban needs updating oban-bg/oban#1232

Closed

danschultzer mentioned this pull request Apr 2, 2025

Conform attributes to v1.27 semantics for OpentelemetryOban open-telemetrex/opentelemetrex-erlang-contrib#6

Draft

indrekj approved these changes May 23, 2025

View reviewed changes

solnic mentioned this pull request Jun 30, 2025

Tracing not working in 11.0.1 getsentry/sentry-elixir#919

Closed

grzuy mentioned this pull request Oct 31, 2025

test(oban): fixes failing tests #558

Merged

grzuy reviewed Nov 6, 2025

View reviewed changes

grzuy mentioned this pull request Nov 6, 2025

Update semantic conventions in opentelemetry_oban #528

Open

Conform attributes to v1.27 semantics for OpentelemetryOban #436

Are you sure you want to change the base?

Conform attributes to v1.27 semantics for OpentelemetryOban #436

Uh oh!

Conversation

danschultzer commented Dec 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Added

Uh oh!

esambo commented Jan 31, 2025

Uh oh!

epinault commented Feb 28, 2025

Uh oh!

danschultzer commented Feb 28, 2025

Uh oh!

bryannaegele commented Feb 28, 2025

Uh oh!

epinault commented Feb 28, 2025

Uh oh!

dustinfarris commented May 23, 2025

Uh oh!

indrekj left a comment

Choose a reason for hiding this comment

Uh oh!

tsloughter commented May 23, 2025

Uh oh!

dustinfarris commented May 25, 2025

Uh oh!

tsloughter commented May 30, 2025

Uh oh!

Miradorn commented Jun 2, 2025

Uh oh!

solnic commented Jun 30, 2025

Uh oh!

tsloughter commented Jun 30, 2025

Uh oh!

grzuy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grzuy Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

danschultzer commented Dec 15, 2024 •

edited

Loading

grzuy Nov 6, 2025 •

edited

Loading