ddtrace 0.4.1 → 0.4.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.yardopts +5 -1
- data/docs/{index.rdoc → GettingStarted.md} +104 -108
- data/lib/ddtrace/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 76d73e549b6967c251ed2a24da73b2745be09bab
|
|
4
|
+
data.tar.gz: d277e842f72258951601bccb39922a5159df6c3c
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 0b4f2105c282e56f3e7ec30bba4b728b57ef934f7479f9308aee09eb4e8ad936cd5ff64ae7073892f09ef24b0867c71e158aceb1f93348c32639c8360b24193b
|
|
7
|
+
data.tar.gz: 6f1c67ab6bafc6d2e94e436a21cca2d0a4c5b220c8acfe3fcb0255f09c08efe02e86d13fd69d8d97c9c90b6eec024375702103a39323d43df2e5e637aa546d9d
|
data/.yardopts
CHANGED
|
@@ -1,40 +1,40 @@
|
|
|
1
|
-
|
|
1
|
+
# Datadog Trace Client
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
``ddtrace`` is Datadog’s tracing client for Ruby. It is used to trace requests as they flow across web servers,
|
|
4
4
|
databases and microservices so that developers have great visiblity into bottlenecks and troublesome requests.
|
|
5
5
|
|
|
6
|
-
|
|
6
|
+
## Install the gem
|
|
7
7
|
|
|
8
|
-
Install the tracing client, adding the following gem in your
|
|
8
|
+
Install the tracing client, adding the following gem in your ``Gemfile``:
|
|
9
9
|
|
|
10
10
|
source 'https://rubygems.org'
|
|
11
11
|
|
|
12
12
|
# tracing gem
|
|
13
13
|
gem 'ddtrace'
|
|
14
14
|
|
|
15
|
-
If you're not using
|
|
15
|
+
If you're not using ``Bundler`` to manage your dependencies, you can install ``ddtrace`` with:
|
|
16
16
|
|
|
17
17
|
gem install ddtrace
|
|
18
18
|
|
|
19
19
|
We strongly suggest pinning the version of the library you deploy.
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
## Quickstart
|
|
22
22
|
|
|
23
|
-
The easiest way to get started with the tracing client is to instrument your web application.
|
|
23
|
+
The easiest way to get started with the tracing client is to instrument your web application. ``ddtrace`` gem
|
|
24
24
|
provides auto instrumentation for the following web frameworks:
|
|
25
25
|
|
|
26
|
-
*
|
|
27
|
-
*
|
|
26
|
+
* [Ruby on Rails](#label-Ruby+on+Rails)
|
|
27
|
+
* [Sinatra](#label-Sinatra)
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
## Web Frameworks
|
|
30
30
|
|
|
31
|
-
|
|
31
|
+
### Ruby on Rails
|
|
32
32
|
|
|
33
|
-
The
|
|
33
|
+
The Rails integration will trace requests, database calls, templates rendering and cache read/write/delete
|
|
34
34
|
operations. The integration makes use of the Active Support Instrumentation, listening to the Notification API
|
|
35
35
|
so that any operation instrumented by the API is traced.
|
|
36
36
|
|
|
37
|
-
To enable the Rails auto instrumentation, create an initializer file in your
|
|
37
|
+
To enable the Rails auto instrumentation, create an initializer file in your ``config/`` folder:
|
|
38
38
|
|
|
39
39
|
# config/initializers/datadog-tracer.rb
|
|
40
40
|
|
|
@@ -44,11 +44,11 @@ To enable the Rails auto instrumentation, create an initializer file in your +co
|
|
|
44
44
|
default_service: 'my-rails-app'
|
|
45
45
|
}
|
|
46
46
|
|
|
47
|
-
If you're using
|
|
47
|
+
If you're using Rails 3 or higher, your application will be listed as ``my-rails-app`` in your service list.
|
|
48
48
|
|
|
49
|
-
|
|
49
|
+
#### Configure the tracer with initializers
|
|
50
50
|
|
|
51
|
-
All tracing settings are namespaced under the
|
|
51
|
+
All tracing settings are namespaced under the ``Rails.configuration.datadog_tracer`` hash. To change the default behavior
|
|
52
52
|
of the Datadog tracer, you can override the following defaults:
|
|
53
53
|
|
|
54
54
|
# config/initializers/datadog-tracer.rb
|
|
@@ -69,31 +69,31 @@ of the Datadog tracer, you can override the following defaults:
|
|
|
69
69
|
|
|
70
70
|
Available settings are:
|
|
71
71
|
|
|
72
|
-
*
|
|
72
|
+
* ``enabled``: defines if the ``tracer`` is enabled or not. If set to ``false`` the code could be still instrumented
|
|
73
73
|
because of other settings, but no spans are sent to the local trace agent.
|
|
74
|
-
*
|
|
74
|
+
* ``auto_instrument``: if set to +true+ the code will be automatically instrumented. You may change this value
|
|
75
75
|
with a condition, to enable the auto-instrumentation only for particular environments (production, staging, etc...).
|
|
76
|
-
*
|
|
77
|
-
still instrumented but you will not have the detail of low-level
|
|
78
|
-
*
|
|
79
|
-
*
|
|
80
|
-
current adapter name, so if you're using PostgreSQL it will be
|
|
81
|
-
*
|
|
82
|
-
*
|
|
83
|
-
your templates in the
|
|
84
|
-
*
|
|
85
|
-
unless you're already using a different initialized
|
|
86
|
-
*
|
|
87
|
-
*
|
|
88
|
-
*
|
|
89
|
-
|
|
90
|
-
|
|
76
|
+
* ``auto_instrument_redis``: if set to ``true`` Redis calls will be traced as such. Calls to Redis cache may be
|
|
77
|
+
still instrumented but you will not have the detail of low-level Redis calls.
|
|
78
|
+
* ``default_service``: set the service name used when tracing application requests. Defaults to ``rails-app``
|
|
79
|
+
* ``default_database_service``: set the database service name used when tracing database activity. Defaults to the
|
|
80
|
+
current adapter name, so if you're using PostgreSQL it will be ``postgres``.
|
|
81
|
+
* ``default_cache_service``: set the cache service name used when tracing cache activity. Defaults to ``rails-cache``
|
|
82
|
+
* ``template_base_path``: used when the template name is parsed in the auto instrumented code. If you don't store
|
|
83
|
+
your templates in the ``views/`` folder, you may need to change this value
|
|
84
|
+
* ``tracer``: is the global tracer used by the tracing application. Usually you don't need to change that value
|
|
85
|
+
unless you're already using a different initialized ``tracer`` somewhere else
|
|
86
|
+
* ``debug``: set to true to enable debug logging.
|
|
87
|
+
* ``trace_agent_hostname``: set the hostname of the trace agent.
|
|
88
|
+
* ``trace_agent_port``: set the port the trace agent is listening on.
|
|
89
|
+
|
|
90
|
+
### Sinatra
|
|
91
91
|
|
|
92
92
|
The Sinatra integration traces requests and template rendering. The integration is based on the
|
|
93
|
-
|
|
93
|
+
``Datadog::Contrib::Sinatra::Tracer`` extension.
|
|
94
94
|
|
|
95
|
-
To start using the tracing client, make sure you import
|
|
96
|
-
either
|
|
95
|
+
To start using the tracing client, make sure you import ``ddtrace`` and ``ddtrace/contrib/sinatra/tracer`` after
|
|
96
|
+
either ``sinatra`` or ``sinatra/base``:
|
|
97
97
|
|
|
98
98
|
require 'sinatra'
|
|
99
99
|
require 'ddtrace'
|
|
@@ -105,9 +105,9 @@ either +sinatra+ or +sinatra/base+:
|
|
|
105
105
|
|
|
106
106
|
The tracing extension will be automatically activated.
|
|
107
107
|
|
|
108
|
-
|
|
108
|
+
#### Configure the tracer
|
|
109
109
|
|
|
110
|
-
To modify the default configuration, use the
|
|
110
|
+
To modify the default configuration, use the ``settings.datadog_tracer.configure`` method. For example,
|
|
111
111
|
to change the default service name and activate the debug mode:
|
|
112
112
|
|
|
113
113
|
configure do
|
|
@@ -116,20 +116,20 @@ to change the default service name and activate the debug mode:
|
|
|
116
116
|
|
|
117
117
|
Available settings are:
|
|
118
118
|
|
|
119
|
-
*
|
|
119
|
+
* ``enabled``: define if the ``tracer`` is enabled or not. If set to ``false``, the code is still instrumented
|
|
120
120
|
but no spans are sent to the local trace agent.
|
|
121
|
-
*
|
|
122
|
-
*
|
|
121
|
+
* ``default_service``: set the service name used when tracing application requests. Defaults to ``sinatra``
|
|
122
|
+
* ``tracer``: set the tracer to use. Usually you don't need to change that value
|
|
123
123
|
unless you're already using a different initialized tracer somewhere else
|
|
124
|
-
*
|
|
125
|
-
*
|
|
126
|
-
*
|
|
124
|
+
* ``debug``: set to ``true`` to enable debug logging.
|
|
125
|
+
* ``trace_agent_hostname``: set the hostname of the trace agent.
|
|
126
|
+
* ``trace_agent_port``: set the port the trace agent is listening on.
|
|
127
127
|
|
|
128
|
-
|
|
128
|
+
## Other libraries
|
|
129
129
|
|
|
130
|
-
|
|
130
|
+
### Redis
|
|
131
131
|
|
|
132
|
-
The
|
|
132
|
+
The Redis integration will trace simple calls as well as pipelines.
|
|
133
133
|
|
|
134
134
|
require 'redis'
|
|
135
135
|
require 'ddtrace'
|
|
@@ -140,10 +140,10 @@ The \Redis integration will trace simple calls as well as pipelines.
|
|
|
140
140
|
redis = Redis.new
|
|
141
141
|
redis.set 'foo', 'bar' # traced!
|
|
142
142
|
|
|
143
|
-
|
|
143
|
+
### Elastic Search
|
|
144
144
|
|
|
145
|
-
The
|
|
146
|
-
in the
|
|
145
|
+
The Elasticsearch integration will trace any call to ``perform_request``
|
|
146
|
+
in the ``Client`` object:
|
|
147
147
|
|
|
148
148
|
require 'elasticsearch/transport'
|
|
149
149
|
require 'ddtrace'
|
|
@@ -154,14 +154,14 @@ in the \Client object:
|
|
|
154
154
|
client = Elasticsearch::Client.new url: 'http://127.0.0.1:9200'
|
|
155
155
|
response = client.perform_request 'GET', '_cluster/health'
|
|
156
156
|
|
|
157
|
-
Note that if you enable both
|
|
158
|
-
for each call, two spans are created, one for
|
|
159
|
-
This typically happens if you call
|
|
157
|
+
Note that if you enable both Elasticsearch and Net/HTTP integrations then
|
|
158
|
+
for each call, two spans are created, one for Elasctisearch and one for Net/HTTP.
|
|
159
|
+
This typically happens if you call ``patch_all`` to enable all integrations by default.
|
|
160
160
|
|
|
161
|
-
|
|
161
|
+
### Net/HTTP
|
|
162
162
|
|
|
163
|
-
The
|
|
164
|
-
|
|
163
|
+
The Net/HTTP integration will trace any HTTP call using the standard lib
|
|
164
|
+
Net::HTTP module.
|
|
165
165
|
|
|
166
166
|
require 'net/http'
|
|
167
167
|
require 'ddtrace'
|
|
@@ -175,9 +175,9 @@ The \Net/HTTP integration will trace any HTTP call using the standard lib
|
|
|
175
175
|
|
|
176
176
|
content = Net::HTTP.get(URI('http://127.0.0.1/index.html'))
|
|
177
177
|
|
|
178
|
-
|
|
178
|
+
## Advanced usage
|
|
179
179
|
|
|
180
|
-
|
|
180
|
+
### Manual Instrumentation
|
|
181
181
|
|
|
182
182
|
If you aren't using a supported framework instrumentation, you may want to to manually instrument your code.
|
|
183
183
|
Adding tracing to your code is very simple. As an example, let’s imagine we have a web server and we want
|
|
@@ -209,24 +209,24 @@ to trace requests to the home page:
|
|
|
209
209
|
end
|
|
210
210
|
end
|
|
211
211
|
|
|
212
|
-
|
|
212
|
+
### Patching methods
|
|
213
213
|
|
|
214
|
-
Integrations such as
|
|
214
|
+
Integrations such as Redis or Elasticsearch use monkey patching.
|
|
215
215
|
|
|
216
216
|
The available methods are:
|
|
217
217
|
|
|
218
|
-
*
|
|
219
|
-
the key is the name of the module and the value
|
|
220
|
-
a call to
|
|
221
|
-
*
|
|
222
|
-
calls to
|
|
218
|
+
* ``autopatch_modules``: returns a hash of all modules available for monkey patching,
|
|
219
|
+
the key is the name of the module and the value ``true`` or ``false``. If it is ``true``,
|
|
220
|
+
a call to ``patch_all`` will enable the module, if it is ``false``, it will do nothing.
|
|
221
|
+
* ``patch_all``: patches all modules which are supported. Make sure all the necessary
|
|
222
|
+
calls to ``require`` have been done before this is called, else monkey patching will
|
|
223
223
|
not work.
|
|
224
|
-
*
|
|
225
|
-
|
|
226
|
-
*
|
|
227
|
-
by
|
|
228
|
-
*
|
|
229
|
-
correctly patched only if it is in this hash, with a value set to
|
|
224
|
+
* ``patch_module``: patches a single module, regardless of its settings in the
|
|
225
|
+
``autopatch_modules`` list.
|
|
226
|
+
* ``patch``: patches some modules, you should pass a hash like the one returned
|
|
227
|
+
by ``autopatch_modules``
|
|
228
|
+
* ``get_patched_modules``: returns the list of patched modules, a module has been
|
|
229
|
+
correctly patched only if it is in this hash, with a value set to ``true``.
|
|
230
230
|
|
|
231
231
|
Example:
|
|
232
232
|
|
|
@@ -238,36 +238,36 @@ Example:
|
|
|
238
238
|
Datadog::Monkey.patch_all # patch all the available modules
|
|
239
239
|
puts Datadog::Monkey.get_patched_modules # tells wether modules are patched or not
|
|
240
240
|
|
|
241
|
-
It is safe to call
|
|
242
|
-
Make sure the library you want to patch is imported before you call
|
|
243
|
-
In doubt, check with
|
|
241
|
+
It is safe to call ``patch_all``, ``patch_module`` or ``patch`` several times.
|
|
242
|
+
Make sure the library you want to patch is imported before you call ``patch_module``.
|
|
243
|
+
In doubt, check with ``get_patched_modules``.
|
|
244
244
|
Once a module is patched, it is not possible to unpatch it.
|
|
245
245
|
|
|
246
|
-
|
|
246
|
+
### Patch Info (PIN)
|
|
247
247
|
|
|
248
|
-
The Patch Info, AKA
|
|
248
|
+
The Patch Info, AKA ``Pin`` object, gives you control on the integration.
|
|
249
249
|
|
|
250
250
|
It has one class method:
|
|
251
251
|
|
|
252
|
-
*
|
|
253
|
-
object. It is safe to call
|
|
252
|
+
* ``get_from``: returns the Pin object which has been pinned onto some random
|
|
253
|
+
object. It is safe to call ``get_from`` on any object, but it might return ``nil``.
|
|
254
254
|
|
|
255
255
|
Some instance methods:
|
|
256
256
|
|
|
257
|
-
*
|
|
258
|
-
*
|
|
259
|
-
function of
|
|
257
|
+
* ``enabled?``: wether tracing is enabled for this object
|
|
258
|
+
* ``onto``: applies the patch information to some random object. It is the companion
|
|
259
|
+
function of ``get_from``.
|
|
260
260
|
|
|
261
261
|
Accessors:
|
|
262
262
|
|
|
263
|
-
*
|
|
264
|
-
*
|
|
265
|
-
*
|
|
266
|
-
*
|
|
267
|
-
*
|
|
268
|
-
*
|
|
263
|
+
* ``service``: service, you should typically set some meaningful value for this.
|
|
264
|
+
* ``app``: application name
|
|
265
|
+
* ``tags``: optional tags
|
|
266
|
+
* ``app_type``: application type
|
|
267
|
+
* ``name``: span name
|
|
268
|
+
* ``tracer``: the tracer object used for tracing
|
|
269
269
|
|
|
270
|
-
By default, a traced integration such as
|
|
270
|
+
By default, a traced integration such as Redis or Elasticsearch carries a Pin object. Eg:
|
|
271
271
|
|
|
272
272
|
require 'redis'
|
|
273
273
|
require 'ddtrace'
|
|
@@ -303,7 +303,7 @@ You can use this object to instrument your own code:
|
|
|
303
303
|
end
|
|
304
304
|
end
|
|
305
305
|
|
|
306
|
-
|
|
306
|
+
### Debug Mode
|
|
307
307
|
|
|
308
308
|
If you need to check locally what traces and spans are sent after each traced block, you can enable
|
|
309
309
|
a global debug mode for all tracers so that every time a trace is ready to be sent, the content will be
|
|
@@ -329,11 +329,11 @@ for the first time:
|
|
|
329
329
|
Remember that the debug mode may affect your application performance and so it must not be used
|
|
330
330
|
in a production environment.
|
|
331
331
|
|
|
332
|
-
|
|
332
|
+
### Supported Versions
|
|
333
333
|
|
|
334
|
-
|
|
334
|
+
#### Ruby interpreters
|
|
335
335
|
|
|
336
|
-
The
|
|
336
|
+
The Datadog Trace Client has been tested with the following Ruby versions:
|
|
337
337
|
|
|
338
338
|
* Ruby MRI 2.1
|
|
339
339
|
* Ruby MRI 2.2
|
|
@@ -343,32 +343,28 @@ The \Datadog Trace Client has been tested with the following Ruby versions:
|
|
|
343
343
|
|
|
344
344
|
Other versions aren't yet officially supported.
|
|
345
345
|
|
|
346
|
-
|
|
346
|
+
#### Ruby on Rails versions
|
|
347
347
|
|
|
348
348
|
The supported versions are:
|
|
349
349
|
|
|
350
|
-
*
|
|
351
|
-
*
|
|
352
|
-
*
|
|
350
|
+
* Rails 3.2 (MRI interpreter, JRuby is experimental)
|
|
351
|
+
* Rails 4.2 (MRI interpreter, JRuby is experimental)
|
|
352
|
+
* Rails 5.0 (MRI interpreter)
|
|
353
353
|
|
|
354
354
|
The currently supported web server are:
|
|
355
355
|
* Puma 2.16+ and 3.6+
|
|
356
356
|
* Unicorn 4.8+ and 5.1+
|
|
357
357
|
* Passenger 5.0+
|
|
358
358
|
|
|
359
|
-
|
|
359
|
+
#### Sinatra versions
|
|
360
360
|
|
|
361
361
|
Currently we are supporting Sinatra >= 1.4.0.
|
|
362
362
|
|
|
363
|
-
|
|
363
|
+
### Glossary
|
|
364
364
|
|
|
365
|
-
|
|
366
|
-
|
|
367
|
-
|
|
368
|
-
|
|
369
|
-
|
|
370
|
-
|
|
371
|
-
+/user/home+ rather than <tt>/user/home?id=123456789</tt>.
|
|
372
|
-
|
|
373
|
-
[Span] A span tracks a unit of work in a service, like querying a database or rendering a template. Spans are associated
|
|
374
|
-
with a service and optionally a resource. Spans have names, start times, durations and optional tags.
|
|
365
|
+
* ``Service``: The name of a set of processes that do the same job. Some examples are ``datadog-web-app`` or ``datadog-metrics-db``.
|
|
366
|
+
* ``Resource``: A particular query to a service. For a web application, some examples might be a URL stem like ``/user/home`` or a
|
|
367
|
+
handler function like ``web.user.home``. For a SQL database, a resource would be the SQL of the query itself like ``select * from users where id = ?``.
|
|
368
|
+
You can track thousands (not millions or billions) of unique resources per services, so prefer resources like ``/user/home`` rather than ``/user/home?id=123456789``.
|
|
369
|
+
* ``Span``: A span tracks a unit of work in a service, like querying a database or rendering a template. Spans are associated
|
|
370
|
+
with a service and optionally a resource. Spans have names, start times, durations and optional tags.
|
data/lib/ddtrace/version.rb
CHANGED
metadata
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: ddtrace
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 0.4.
|
|
4
|
+
version: 0.4.2
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Datadog, Inc.
|
|
@@ -116,7 +116,7 @@ files:
|
|
|
116
116
|
- circle.yml
|
|
117
117
|
- ddtrace.gemspec
|
|
118
118
|
- docker-compose.yml
|
|
119
|
-
- docs/
|
|
119
|
+
- docs/GettingStarted.md
|
|
120
120
|
- gemfiles/contrib.gemfile
|
|
121
121
|
- gemfiles/rails3_mysql2.gemfile
|
|
122
122
|
- gemfiles/rails3_postgres.gemfile
|