-
Notifications
You must be signed in to change notification settings - Fork 562
feat(integrations): Add tracing to DramatiqIntegration #4571
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
Changes from 6 commits
edee89d
5562a9c
863d16b
5674a62
9764f19
7156ac4
39e3a50
a41b477
4746db6
a5e9ad0
1357bea
39d3532
db239dc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,18 +1,34 @@ | ||||||
import json | ||||||
|
||||||
import sentry_sdk | ||||||
from sentry_sdk.integrations import Integration | ||||||
from sentry_sdk.consts import OP, SPANSTATUS | ||||||
from sentry_sdk.api import continue_trace, get_baggage, get_traceparent | ||||||
from sentry_sdk.integrations import Integration, DidNotEnable | ||||||
from sentry_sdk.integrations._wsgi_common import request_body_within_bounds | ||||||
from sentry_sdk.tracing import ( | ||||||
BAGGAGE_HEADER_NAME, | ||||||
SENTRY_TRACE_HEADER_NAME, | ||||||
TransactionSource, | ||||||
) | ||||||
from sentry_sdk.utils import ( | ||||||
AnnotatedValue, | ||||||
capture_internal_exceptions, | ||||||
event_from_exception, | ||||||
ContextVar, | ||||||
HAS_REAL_CONTEXTVARS, | ||||||
CONTEXTVARS_ERROR_MESSAGE, | ||||||
) | ||||||
from typing import TypeVar | ||||||
|
||||||
R = TypeVar("R") | ||||||
|
||||||
from dramatiq.broker import Broker # type: ignore | ||||||
from dramatiq.message import Message # type: ignore | ||||||
from dramatiq.middleware import Middleware, default_middleware # type: ignore | ||||||
from dramatiq.errors import Retry # type: ignore | ||||||
try: | ||||||
from dramatiq.broker import Broker | ||||||
from dramatiq.middleware import Middleware, default_middleware | ||||||
from dramatiq.errors import Retry | ||||||
from dramatiq.message import Message | ||||||
except ImportError: | ||||||
raise DidNotEnable("Dramatiq is not installed") | ||||||
|
||||||
from typing import TYPE_CHECKING | ||||||
|
||||||
|
@@ -38,6 +54,12 @@ class DramatiqIntegration(Integration): | |||||
@staticmethod | ||||||
def setup_once(): | ||||||
# type: () -> None | ||||||
if not HAS_REAL_CONTEXTVARS: | ||||||
raise DidNotEnable( | ||||||
"The dramatiq integration for Sentry requires Python 3.7+ " | ||||||
" or aiocontextvars package." + CONTEXTVARS_ERROR_MESSAGE | ||||||
) | ||||||
|
||||||
_patch_dramatiq_broker() | ||||||
|
||||||
|
||||||
|
@@ -85,50 +107,78 @@ class SentryMiddleware(Middleware): # type: ignore[misc] | |||||
DramatiqIntegration. | ||||||
""" | ||||||
|
||||||
_transaction = ContextVar("_transaction") | ||||||
|
||||||
def before_enqueue(self, broker, message, delay): | ||||||
# type: (Broker, Message[R], int) -> None | ||||||
message.options["sentry_headers"] = { | ||||||
|
message.options["sentry_headers"] = { | |
message.options["_sentry_headers"] = { |
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.
fixed
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.
We still need some sort of scope management in order to make sure the data we collect about tasks is isolated.
The general rule of thumb is: if you start a transaction, you should start it in a new isolation scope. See for example huey.
So we should start an isolation scope right after the initial if integration is None: return
check with
scope = sentry_sdk.isolation_scope()
message._scope_manager = scope
scope.__enter__()
Everything that we do on the scope
later in the function can stay, but it should be done on the isolation scope, not current scope as before.
And finally, we need to __exit__
the saved scope in after_process_message
with message._scope_manager.__exit__(None, None, None)
.
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.
Done.
but please recheck it)
sentrivana marked this conversation as resolved.
Show resolved
Hide resolved
Outdated
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.
The SDK shouldn't set tags on its own (we still do this in a couple places, but are avoiding it for new code)
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'm a little bit confused here. What do you mean exactly by "SDK shouldn't set tags"?
Am I do it wrong now or you wanna say setting tags is only allowed for client's code and no tags allowed in SDK?
I definitely want to set dramatiq_message_id for each task like it happens in celery integration:
message_id is extremely helpful in investigating task failures
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.
setting tags is only allowed for client's code and no tags allowed in SDK?
This. Going forward, we're not setting tags in the SDK. You can still set dramatiq_message_id
with e.g. span.set_data()
and it should be searchable.
Outdated
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.
The origin
looks good, any reason it's commented out?
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.
No reasons. Will fix it. Thanks
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.
Bug: Transaction Initialization Redundancy
The transaction initialization in before_process_message
uses an incorrect pattern. It creates a transaction with continue_trace()
, then passes this existing transaction object to sentry_sdk.start_transaction()
, which is designed to create new transactions. This leads to redundant initialization, a manual transaction.__enter__()
call, and causes the origin
parameter set by continue_trace()
to be lost.
Outdated
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.
Bug: Dramatiq Integration Fails Transaction Initialization
The Dramatiq integration incorrectly initializes transactions. It calls continue_trace()
to create a transaction, then redundantly calls sentry_sdk.start_transaction()
with that same transaction object, and finally manually calls transaction.__enter__()
. This mixed lifecycle management can lead to improper transaction initialization, inconsistent state, or broken distributed tracing.
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.
Please keep this -- it's a fallback in case the integration/the SDK/the client has been deactivated in the meantime. In that case we shouldn't do anything.
We should have this also in the new before_enqueue
.
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.
Done, but I believe it's unnecessary due to this: https://github.com/getsentry/sentry-python/pull/4571/files#diff-2722e3fe31f13ffc24072313765f1fc89f0f0721154b7ca072bb46b1f9573f5bR84
Middleware won't be in use if integration is not enabled
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.
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 think I already may have asked this in an earlier iteration, but do we need the ContextVar here? The scopes themselves are stored in ContextVars and ideally they should govern the reference to the current transaction (this should already be working as long as the transaction/span is correctly set on the scope, which it is as long as you use
start_span/transaction
context manager or just__enter__
directly)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.
It makes sense.
Looks like I really needn't store transaction separately and I can get it directly from scope:
Right? =)
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.
Exactly, that'd be the idea.