You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The docs currently suggest that the way to start using UDS instead of UDP for statsd communication is to call datadog.initialize(statsd_socket_path='/some/path')
While this does change the socket to communicate over UDS, there are two issues here.
Any consumers of the global datadog.statsd object will be sending over UDP before this initialize call is run. Not that big of a deal as you shouldn't be sending metrics before running initialize but it's a bit confusing
The larger issue - because initialize() does not re-run DogStatsd's __init__(), changing from UDP to UDS does not cause the telemetry tags to be reset, so the telemetry still suggests you're sending over UDP even though you aren't. It also does not reset the _max_payload_size for the DogStatsd object, so the optimal payload length for UDS is never set which is highly sub-optimal.
To Reproduce
In a new python app, call datadog.initialize and pass a valid statsd_socket_path
Check the reported metric datadog.dogstatsd.client.metrics and observe that this metric will still report for your host exclusively with client_transport:udp
Expected behavior
When changing to UDS, the telemetry tags should reflect this, and the proper payload length should be set.
Environment and Versions (please complete the following information):
datadogpy v 0.44.0
Python 3.10
Additional context
As a hacky method of solving this, prior to running datadog.initialize(), we run datadog.statsd.__init__(statsd_socket_path='/some/path') and that reinitializes things properly. Almost seems as if the statsd global should be initialized in datadog's initialization instead of at import time by DogStatsd?
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.
If you would like this issue to remain open:
Verify that you can still reproduce the issue in the latest version of this project.
Comment that the issue is still reproducible and include updated details requested in the issue template.
Describe the bug
The docs currently suggest that the way to start using UDS instead of UDP for statsd communication is to call
datadog.initialize(statsd_socket_path='/some/path')
While this does change the socket to communicate over UDS, there are two issues here.
datadog.statsd
object will be sending over UDP before this initialize call is run. Not that big of a deal as you shouldn't be sending metrics before running initialize but it's a bit confusinginitialize()
does not re-run DogStatsd's__init__()
, changing from UDP to UDS does not cause the telemetry tags to be reset, so the telemetry still suggests you're sending over UDP even though you aren't. It also does not reset the_max_payload_size
for the DogStatsd object, so the optimal payload length for UDS is never set which is highly sub-optimal.To Reproduce
datadog.initialize
and pass a valid statsd_socket_pathdatadog.dogstatsd.client.metrics
and observe that this metric will still report for your host exclusively withclient_transport:udp
Expected behavior
When changing to UDS, the telemetry tags should reflect this, and the proper payload length should be set.
Environment and Versions (please complete the following information):
datadogpy v 0.44.0
Python 3.10
Additional context
As a hacky method of solving this, prior to running
datadog.initialize()
, we rundatadog.statsd.__init__(statsd_socket_path='/some/path')
and that reinitializes things properly. Almost seems as if the statsd global should be initialized in datadog's initialization instead of at import time by DogStatsd?The text was updated successfully, but these errors were encountered: