dogstatsd-ruby 5.0.1 → 5.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +86 -0
- data/lib/datadog/statsd.rb +4 -1
- data/lib/datadog/statsd/sender.rb +2 -1
- data/lib/datadog/statsd/version.rb +1 -1
- metadata +5 -5
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 264d78a169508453151e7a5c3260c2299ad05c727dc9c72cfa52f8be721809d0
|
4
|
+
data.tar.gz: 8e0726168a20f7efcb2bdcf72ab3d748184cd652de4fd25871f9fdf676020baf
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 1875c615a043db68c69d855af2b454e45ef41af1d7e1f726a6067c35e260eb0dbc9b706a0588608e31bd5087e500b1b77b1b604f3dc22750f1376b6583b78c9a
|
7
|
+
data.tar.gz: 36f60d62312f6844efa9ce1b53a86cde380140582e009b5e5bf07d3a4a859e4d762e92a2ebcfe38a668145255f82f72c84504caabb93f25475e895a5166a9969
|
data/README.md
CHANGED
@@ -24,15 +24,49 @@ require 'datadog/statsd'
|
|
24
24
|
|
25
25
|
# Create a DogStatsD client instance.
|
26
26
|
statsd = Datadog::Statsd.new('localhost', 8125)
|
27
|
+
...
|
28
|
+
# release resources used by the client instance
|
29
|
+
statsd.close()
|
27
30
|
```
|
28
31
|
Or if you want to connect over Unix Domain Socket:
|
29
32
|
```ruby
|
30
33
|
# Connection over Unix Domain Socket
|
31
34
|
statsd = Datadog::Statsd.new(socket_path: '/path/to/socket/file')
|
35
|
+
...
|
36
|
+
# release resources used by the client instance
|
37
|
+
statsd.close()
|
32
38
|
```
|
33
39
|
|
34
40
|
Find a list of all the available options for your DogStatsD Client in the [DogStatsD-ruby rubydoc](https://www.rubydoc.info/github/DataDog/dogstatsd-ruby/master/Datadog/Statsd) or in the [Datadog public DogStatsD documentation](https://docs.datadoghq.com/developers/dogstatsd/?tab=ruby#client-instantiation-parameters).
|
35
41
|
|
42
|
+
### Migrating from v4.x to v5.x
|
43
|
+
|
44
|
+
If you are already using DogStatsD-ruby v4.x and you want to migrate to a version v5.x, the major
|
45
|
+
change concerning you is the new threading model (please see section Threading model):
|
46
|
+
|
47
|
+
In practice, it means two things:
|
48
|
+
|
49
|
+
1. Now that the client is buffering metrics before sending them, you have to manually
|
50
|
+
call the method `Datadog::Statsd#flush` if you want to force the sending of metrics. Note that the companion thread will automatically flush the buffered metrics if the buffer gets full or when you are closing the instance.
|
51
|
+
|
52
|
+
2. You have to make sure you are either:
|
53
|
+
|
54
|
+
* using singletons instances of the DogStatsD client and not allocating one each time you need one, letting the buffering mechanism flush metrics, or,
|
55
|
+
* properly closing your DogStatsD client instance when it is not needed anymore using the method `Datadog::Statsd#close` to release the resources used by the instance and to close the socket
|
56
|
+
|
57
|
+
### v5.x Common Pitfalls
|
58
|
+
|
59
|
+
Version v5.x of `dogstatsd-ruby` is using a companion thread for preemptive flushing, it brings better performances for application having a high-throughput of statsd metrics, but it comes with new pitfalls:
|
60
|
+
|
61
|
+
* Applications forking after having created the dogstatsd instance: forking a process can't duplicate the existing threads, meaning that one of the processes won't have a companion thread to flush the metrics and will lead to missing metrics.
|
62
|
+
* Applications creating a lot of different instances of the client without closing them: it is important to close the instance to free the thread and the socket it is using or it will lead to thread leaks.
|
63
|
+
|
64
|
+
If you are using [Sidekiq](https://github.com/mperham/sidekiq), please make sure to close the client instances that are instantiated. [See this example on using DogStatsD-ruby v5.x with Sidekiq](https://github.com/DataDog/dogstatsd-ruby/blob/master/examples/sidekiq_example.rb).
|
65
|
+
|
66
|
+
If you are using [Puma](https://github.com/puma/puma) or [Unicorn](https://yhbt.net/unicorn.git), please make sure to create the instance of DogStatsD in the workers, not in the main process before it forks to create its workers. See [this comment for more details](https://github.com/DataDog/dogstatsd-ruby/issues/179#issuecomment-845570345).
|
67
|
+
|
68
|
+
Applications that are in these situations and can't apply these recommendations should pin dogstatsd-ruby v4.x using `gem 'dogstatsd-ruby', '~> 4.0'`. Note that v4.x will continue to be maintained until a future v5.x version can more easily fit these use cases.
|
69
|
+
|
36
70
|
### Origin detection over UDP
|
37
71
|
|
38
72
|
Origin detection is a method to detect which pod DogStatsD packets are coming from in order to add the pod's tags to the tag list.
|
@@ -84,6 +118,58 @@ size should be used, you can set it with the parameter `buffer_max_payload_size`
|
|
84
118
|
statsd = Datadog::Statsd.new('localhost', 8125, buffer_max_payload_size: 4096)
|
85
119
|
```
|
86
120
|
|
121
|
+
## Threading model
|
122
|
+
|
123
|
+
On versions greater than 5.0, we changed the threading model of the library so that one instance of `Datadog::Statsd` could be shared between threads and so that the writes in the socket are non blocking.
|
124
|
+
|
125
|
+
When you instantiate a `Datadog::Statsd`, a companion thread is spawned. This thread will be called the Sender thread, as it is modeled by the [Sender](../lib/datadog/statsd/sender.rb) class.
|
126
|
+
|
127
|
+
This thread is stopped when you close the statsd client (`Datadog::Statsd#close`). It also means that allocating a lot of statsd clients without closing them properly when not used anymore
|
128
|
+
could lead to a thread leak (even though they will be sleeping, blocked on IO).
|
129
|
+
The communication between the current thread is managed through a standard Ruby Queue.
|
130
|
+
|
131
|
+
The sender thread has the following logic (Code present in the method `Datadog::Statsd::Sender#send_loop`):
|
132
|
+
|
133
|
+
```
|
134
|
+
while the sender message queue is not closed do
|
135
|
+
read message from sender message queue
|
136
|
+
|
137
|
+
if message is a Control message to flush
|
138
|
+
flush buffer in connection
|
139
|
+
else if message is a Control message to synchronize
|
140
|
+
synchronize with calling thread
|
141
|
+
else
|
142
|
+
add message to the buffer
|
143
|
+
end
|
144
|
+
end while
|
145
|
+
```
|
146
|
+
|
147
|
+
Most of the time, the sender thread is blocked and sleeping when doing a blocking read from the sender message queue.
|
148
|
+
|
149
|
+
We can see that there is 3 different kind of messages:
|
150
|
+
|
151
|
+
* a control message to flush the buffer in the connection
|
152
|
+
* a control message to synchronize any thread with the sender thread
|
153
|
+
* a message to append to the buffer
|
154
|
+
|
155
|
+
There is also an implicit message which is closing the queue as it will stop blocking read from the message queue (if happening) and thus, stop the sender thread.
|
156
|
+
|
157
|
+
### Usual workflow
|
158
|
+
|
159
|
+
You push metrics to the statsd client which writes them quickly to the sender message queue. The sender thread receives those message, buffers them and flushes them to the connection when the buffer limit is reached.
|
160
|
+
|
161
|
+
### Flushing
|
162
|
+
|
163
|
+
When calling a flush, a specific control message (the `:flush` symbol) is sent to the sender thread. When finding it, it flushes its internal buffer into the connection.
|
164
|
+
|
165
|
+
### Rendez-vous
|
166
|
+
|
167
|
+
It is possible to ensure a message has been consumed by the sender thread and written to the buffer by simply calling a rendez-vous right after. This is done when you are doing a synchronized flush (calling `Datadog::Statsd#flush` with the `sync: true` option).
|
168
|
+
|
169
|
+
This means the current thread is going to sleep and wait for a Queue which is given to the sender thread. When the sender thread reads this queue from its own message queue, it puts a placeholder message in it so that it wakes up the calling thread.
|
170
|
+
|
171
|
+
This is useful when closing the application or when checking unit tests.
|
172
|
+
|
87
173
|
## Credits
|
88
174
|
|
89
175
|
dogstatsd-ruby is forked from Rein Henrichs [original Statsd
|
data/lib/datadog/statsd.rb
CHANGED
@@ -320,7 +320,10 @@ module Datadog
|
|
320
320
|
end
|
321
321
|
|
322
322
|
# Close the underlying socket
|
323
|
-
|
323
|
+
#
|
324
|
+
# @param [Boolean, true] flush Should we flush the metrics before closing
|
325
|
+
def close(flush: true)
|
326
|
+
flush(sync: true) if flush
|
324
327
|
forwarder.close
|
325
328
|
end
|
326
329
|
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: dogstatsd-ruby
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 5.0
|
4
|
+
version: 5.1.0
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Rein Henrichs
|
@@ -9,7 +9,7 @@ authors:
|
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date: 2021-
|
12
|
+
date: 2021-06-17 00:00:00.000000000 Z
|
13
13
|
dependencies: []
|
14
14
|
description: A Ruby DogStatsd client
|
15
15
|
email: code@datadoghq.com
|
@@ -41,9 +41,9 @@ licenses:
|
|
41
41
|
- MIT
|
42
42
|
metadata:
|
43
43
|
bug_tracker_uri: https://github.com/DataDog/dogstatsd-ruby/issues
|
44
|
-
changelog_uri: https://github.com/DataDog/dogstatsd-ruby/blob/v5.0
|
45
|
-
documentation_uri: https://www.rubydoc.info/gems/dogstatsd-ruby/5.0
|
46
|
-
source_code_uri: https://github.com/DataDog/dogstatsd-ruby/tree/v5.0
|
44
|
+
changelog_uri: https://github.com/DataDog/dogstatsd-ruby/blob/v5.1.0/CHANGELOG.md
|
45
|
+
documentation_uri: https://www.rubydoc.info/gems/dogstatsd-ruby/5.1.0
|
46
|
+
source_code_uri: https://github.com/DataDog/dogstatsd-ruby/tree/v5.1.0
|
47
47
|
post_install_message:
|
48
48
|
rdoc_options: []
|
49
49
|
require_paths:
|