-
-
Notifications
You must be signed in to change notification settings - Fork 503
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 child_spans for Sidekiq Queue instrumentation #2403
Add child_spans for Sidekiq Queue instrumentation #2403
Conversation
cd35fcf
to
787436b
Compare
ac46c1b
to
4e505f6
Compare
Oh wow, exactly what I was looking for 😅 🙌 can we somehow help to get this shipped? 💪 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! 🙇🏻 Would you be able to add some basic specs for this too?
@solnic I've added two basic specs. |
@solnic After looking at these, I think queue.process may actually replace |
Looks like it needs a changelog too |
04750fa
to
af385ba
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2403 +/- ##
=======================================
Coverage 98.15% 98.16%
=======================================
Files 126 126
Lines 4728 4741 +13
=======================================
+ Hits 4641 4654 +13
Misses 87 87
|
I've been testing this out and I don't see queue.sidekiq/queue.process. This is what I see instead: |
Thanks for adding the specs. I think it would be good to use timecop there actually. |
You're right! I changed that after my comment, before your review here: I'll have a look at the other comments as soon as possible. |
@solnic I have updated PR with feedback adjusted! Edit: I see specs are broken. I'll look into that as well! |
9aaf80b
to
671dd65
Compare
@solnic The specs failing seems related to sidekiq/sidekiq#6430 - Was able to reproduce locally, after clearing Lock file and bundle install again. Somewhat unrelated to this PR, although it's noisy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job thank you!
Please update to the latest master. I just checked locally and it passes. Once CI is green I'll merge it in. |
d3a7219
to
265307a
Compare
@solnic Done! |
🙌 Thanks everyone! This is such a great feature. |
@@ -223,7 +223,7 @@ def retry_last_failed_job | |||
expect(transaction.contexts.dig(:trace, :trace_id)).to be_a(String) | |||
expect(transaction.contexts.dig(:trace, :span_id)).to be_a(String) | |||
expect(transaction.contexts.dig(:trace, :status)).to eq("ok") | |||
expect(transaction.contexts.dig(:trace, :op)).to eq("queue.sidekiq") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frederikspang Did this break sampling? In the docs you show that you can do
case op
when /sidekiq/
0.01
[...]
But this is always set to queue.process
now so we are sampling a lot more than we should which is costing us money...
Was this intentional or am I misunderstanding something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is very much not intentional. I will submit a PR for docs as well. I was unaware of this example being there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we've been running out of performance traces more often recently and were confused what had happened. And then I found that our sampler was not running correctly :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this is not all about the docs. It's like a public API and can't just be changed like this without proper deprecations etc. It must be costing your customers a lot of money in both extra Sentry charges as well as debugging time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get what you're saying - Except it's not my customers. I've done this as OSS contribution to help the Sentry Ruby SDK conform to the guidelines and "predefined operations" as defined by the Sentry core system - ie making the Queues
page work properly for Sidekiq jobs.
Deprecating and semantic versioning of what goes into what release version is very not much my job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha I thought you worked for Sentry :)
Sorry if my tone was harsh, I didn’t mean to offend. I know mistakes can be made.
My message was more directed to Sentry the business.
Also the feature is great and many thanks for implementing it! 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Linuus I'm one of the maintainers and I approved this PR. It didn't occur to me that transaction's op should be treated as a public interface here. Thanks for bringing this up and I'm very sorry that it caused such issues for you. I updated both the CHANGELOG and the release page with a warning that explains this change.
Implements #2322 for Sidekiq.
Description
Adds support for Sentry Queues page (With predefined span
op
names)https://docs.sentry.io/platforms/ruby/guides/sidekiq/tracing/instrumentation/custom-instrumentation/queues-module/