Skip to content

Feature request/proposal: Make extensible how arguments are traced#135

Closed
ulissesalmeida wants to merge 1 commit intomarcdel:mainfrom
ulissesalmeida:ua-telemetry-traceable
Closed

Feature request/proposal: Make extensible how arguments are traced#135
ulissesalmeida wants to merge 1 commit intomarcdel:mainfrom
ulissesalmeida:ua-telemetry-traceable

Conversation

@ulissesalmeida
Copy link
Copy Markdown

@ulissesalmeida ulissesalmeida commented Oct 20, 2023

Hi, here where where I work we caught ourselves repeating the same
metadata when tracing some arguments. For example:

@trace with_span("work.do", include: [[:user, :id], [:user, :country]])

We found ourselves wanting some data structures to be reported consistenly
in the same shape. If we don't want "user's id" be traced anymore, we would like
to change in a single place.

So we caught ourselves in our app writing functions like:

defmodule User do
# ...
 def otlp_attributes(user) do
   [
     {"user.id", user.id},
     {"user.country", user.country}
   ]
 end
end

Then in places we want to trace:

  Tracer.set_attributes(User.otlp_attributes(user))

Ideally, I think we would be awesome if we could just:

  @trace with_span("work.do", include: [:user])

And the library would know how to convert that. But how?

Elixir protocols might be a good solution for data!

The user of the library could define how they want to report common
data structures, then the OpenTelemetryLibraryDecorator knowing that data
has implementation, uses it. Otherwise, just retrieve default implementation
(for backwards-compatiblity.)

What do you think about this feature? I personally think it would be very
useful.

I happy to change the protocol name and function interface for something
that would make more sense if you're interested in adding this feature.

Hi, here where where I work we caught ourselves repeating the same
metadata when tracing some arguments. For example:

```elixir
@trace with_span("work.do", include: [[:user, :id], [:user, :country]])
```

We found ourselves wanting some data structures to be reported consistenly
in the same. If we don't want "user's id" be traced anymore, we would like
to change in a single place.

So we caught ourselves in our app writing functions like:

```elixir
defmodule User do
 def otlp_attributes(user) do
   [
     {"user.id", user.id},
     {"user.country", user.country}
   ]
 end
end
```

Then in places we want to trace:

```elixir
  Tracer.set_attributes(User.otlp_attributes(user))
```

Ideally, I think we would be awesome if we could just:

```elixir
  @trace with_span("work.do", include: [:user])
```

And the library would know how to convert that. But how?

Elixir protocols might be a good solution for data!

The user of the library could define how they want to report common
data structures, then the OpenTelemetryLibraryDecorator knowing that data
has implementation, uses it. Otherwise, just retrieve default implementation
(for backwards-compatiblity.)

What do you think about this feature? I personally think it would be very
useful.

I happy to change the protocol name and function interface for something
that would make more sense if you're interested in adding this feature.
@marcdel
Copy link
Copy Markdown
Owner

marcdel commented Oct 20, 2023

Hell yeah. I've been noodling on this and came up with almost the exact same solution in our app at work (I think I like your interface better though). I'll take a closer look this weekend, but in general I'm down for this approach.

Tangentially, I've been looking into what it would take to get trace level attributes working in the Erlang otel implementation, because I think that's the root of most of the pain I've been feeling around this. I want to set some common attributes at the root level and have them propagate into all of the child spans.

@ulissesalmeida
Copy link
Copy Markdown
Author

@marcdel Good to know! Let me know if I can be any help, like adjusting something, writing docs. Or fell free to adjust/continue in a way that makes more sense.

@ktayah
Copy link
Copy Markdown

ktayah commented Oct 21, 2023

@ulissesalmeida @marcdel Hello, I actually needed similar functionality for our application at work and implemented similar changes as well funny enough. Looks like we all had the same thought:
#131

@jeffdeville
Copy link
Copy Markdown

FWIW, once we merged @ulissesalmeida's into our branch, the tests all remained green, so we're using it now.

@ulissesalmeida
Copy link
Copy Markdown
Author

We don't need this anymore thanks to the O11y.SpanAttributes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants