Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add oban measurements to span #212

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

brentjr
Copy link

@brentjr brentjr commented Oct 7, 2023

Adds measurements from oban as attributes on the span.

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 7, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

@tsloughter
Copy link
Member

I think this looks right.

Curious why you chose microseconds? Is that based on other libraries or semantic conventions?

@brentjr
Copy link
Author

brentjr commented Oct 13, 2023

Curious why you chose microseconds? Is that based on other libraries or semantic conventions?

@tsloughter yeah that is a good question, i do not have any super strong reason for that. i just noticed it's the default in some of the other libs and it's what is used by the defauly oban telemetry logger as well. i could also make it configurable if that is preferred

@bryannaegele
Copy link
Collaborator

Curious why you chose microseconds? Is that based on other libraries or semantic conventions?

@tsloughter yeah that is a good question, i do not have any super strong reason for that. i just noticed it's the default in some of the other libs and it's what is used by the defauly oban telemetry logger as well. i could also make it configurable if that is preferred

Ecto is doing this but it's also user configurable. Are these measurements just passing the ecto times or calculating its own?

@brentjr
Copy link
Author

brentjr commented Oct 15, 2023

Curious why you chose microseconds? Is that based on other libraries or semantic conventions?

@tsloughter yeah that is a good question, i do not have any super strong reason for that. i just noticed it's the default in some of the other libs and it's what is used by the defauly oban telemetry logger as well. i could also make it configurable if that is preferred

Ecto is doing this but it's also user configurable. Are these measurements just passing the ecto times or calculating its own?

these are not using ecto times but times calculated by oban. duration is the amount of time the oban job takes to execute and queue_time is the amount of time the job was waiting before being picked up. i modified the time units to be configurable to match how opentelemetry_ecto handles things

@brentjr
Copy link
Author

brentjr commented Oct 25, 2023

@tsloughter @bryannaegele can you take another look at this when you have a chance?

@tsloughter
Copy link
Member

Hey, sorry, I should have replied earlier. I'm unsure about making time unit configurable (too bad Ecto did). It'd be better to just use a consistent time unit (not only across these libs but also whatever is used across otel languages) in my opinion.

If there isn't a consistent unit already used for span attributes that becomes more difficult but if its configurable then we can't undo it later while we can always switch to configurable without it being a breaking change.

Not blocking this on that opinion, but its my hesitation.

This reverts commit ea864d1.
@brentjr
Copy link
Author

brentjr commented Oct 26, 2023

If there isn't a consistent unit already used for span attributes that becomes more difficult but if its configurable then we can't undo it later while we can always switch to configurable without it being a breaking change.

@tsloughter that's fair, i dont have any strong opinion on this so i reverted that change. microseconds seems to be used frequently, i dont think there is any specific pattern around that though


defp set_measurements_attributes(%{duration: duration, queue_time: queue_time}) do
OpenTelemetry.Tracer.set_attributes(%{
:"messaging.oban.duration_us" => System.convert_time_unit(duration, :native, :microsecond),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsloughter based on you slack question about not extending semcon namespaces, do you think we should look at merging this and then do a single pass fixing that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better if we don't add any that are incorrect.

So switching this to oban.messaging... is needed.

There really needs to be some semconv for jobs libraries instead of just using messaging. I've seen this same thing in other languages, like Ruby's que.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. There's just other attributes with the issue so didn't want to end up with mixed naming

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote we keep it as is in this PR and normalize all of it in another one prior to cutting a release.

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

Successfully merging this pull request may close these issues.

3 participants