ddtrace 0.4.1 → 0.4.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 72729f2159c8955311ce44e2f616f76dad528f3e
-  data.tar.gz: b29b89057f37fdc35e2e3c94155a4929997fb437
+  metadata.gz: 76d73e549b6967c251ed2a24da73b2745be09bab
+  data.tar.gz: d277e842f72258951601bccb39922a5159df6c3c
 SHA512:
-  metadata.gz: 27b419978a59a4e55d637f0a9d03a288c9e0d7869bf2c02a6265ba75bc3579ea051fa62ff6c1d48b0f69420b99e9b4387c51833849361a505c99b71d008b8f01
-  data.tar.gz: 679a3d8bcc5a4f46e59565da6f5f61c23501a4905c7adaae522b507059ea2c1b7ec9601e69772f4ea3e93db196185df04a635393b2eb1fab465bcc542a748afd
+  metadata.gz: 0b4f2105c282e56f3e7ec30bba4b728b57ef934f7479f9308aee09eb4e8ad936cd5ff64ae7073892f09ef24b0867c71e158aceb1f93348c32639c8360b24193b
+  data.tar.gz: 6f1c67ab6bafc6d2e94e436a21cca2d0a4c5b220c8acfe3fcb0255f09c08efe02e86d13fd69d8d97c9c90b6eec024375702103a39323d43df2e5e637aa546d9d

data/.yardopts

@@ -1 +1,5 @@
---readme docs/index.rdoc
+--readme docs/GettingStarted.md
+--main docs/GettingStarted.md
+-
+docs/GettingStarted.md
+LICENSE

data/docs/{index.rdoc → GettingStarted.md}

@@ -1,40 +1,40 @@
-= \Datadog Trace Client
+# Datadog Trace Client
 
-_ddtrace_ is Datadog’s tracing client for Ruby. It is used to trace requests as they flow across web servers,
+``ddtrace`` is Datadog’s tracing client for Ruby. It is used to trace requests as they flow across web servers,
 databases and microservices so that developers have great visiblity into bottlenecks and troublesome requests.
 
-== Install the gem
+## Install the gem
 
-Install the tracing client, adding the following gem in your +Gemfile+:
+Install the tracing client, adding the following gem in your ``Gemfile``:
 
     source 'https://rubygems.org'
 
     # tracing gem
     gem 'ddtrace'
 
-If you're not using +Bundler+ to manage your dependencies, you can install +ddtrace+ with:
+If you're not using ``Bundler`` to manage your dependencies, you can install ``ddtrace`` with:
 
     gem install ddtrace
 
 We strongly suggest pinning the version of the library you deploy.
 
-== Quickstart
+## Quickstart
 
-The easiest way to get started with the tracing client is to instrument your web application. +ddtrace+ gem
+The easiest way to get started with the tracing client is to instrument your web application. ``ddtrace`` gem
 provides auto instrumentation for the following web frameworks:
 
-* {Ruby on Rails}[#label-Ruby+on+Rails]
-* {Sinatra}[#label-Sinatra]
+* [Ruby on Rails](#label-Ruby+on+Rails)
+* [Sinatra](#label-Sinatra)
 
-== Web Frameworks
+## Web Frameworks
 
-=== Ruby on \Rails
+### Ruby on Rails
 
-The \Rails integration will trace requests, database calls, templates rendering and cache read/write/delete
+The Rails integration will trace requests, database calls, templates rendering and cache read/write/delete
 operations. The integration makes use of the Active Support Instrumentation, listening to the Notification API
 so that any operation instrumented by the API is traced.
 
-To enable the Rails auto instrumentation, create an initializer file in your +config/+ folder:
+To enable the Rails auto instrumentation, create an initializer file in your ``config/`` folder:
 
     # config/initializers/datadog-tracer.rb
 
@@ -44,11 +44,11 @@ To enable the Rails auto instrumentation, create an initializer file in your +co
       default_service: 'my-rails-app'
     }
 
-If you're using \Rails 3 or higher, your application will be listed as +my-rails-app+ in your service list.
+If you're using Rails 3 or higher, your application will be listed as ``my-rails-app`` in your service list.
 
-==== Configure the tracer with initializers
+#### Configure the tracer with initializers
 
-All tracing settings are namespaced under the +Rails.configuration.datadog_tracer+ hash. To change the default behavior
+All tracing settings are namespaced under the ``Rails.configuration.datadog_tracer`` hash. To change the default behavior
 of the Datadog tracer, you can override the following defaults:
 
     # config/initializers/datadog-tracer.rb
@@ -69,31 +69,31 @@ of the Datadog tracer, you can override the following defaults:
 
 Available settings are:
 
-* +enabled+: defines if the +tracer+ is enabled or not. If set to +false+ the code could be still instrumented
+* ``enabled``: defines if the ``tracer`` is enabled or not. If set to ``false`` the code could be still instrumented
   because of other settings, but no spans are sent to the local trace agent.
-* +auto_instrument+: if set to +true+ the code will be automatically instrumented. You may change this value
+* ``auto_instrument``: if set to +true+ the code will be automatically instrumented. You may change this value
   with a condition, to enable the auto-instrumentation only for particular environments (production, staging, etc...).
-* +auto_instrument_redis+: if set to +true+ \Redis calls will be traced as such. Calls to Redis cache may be
-  still instrumented but you will not have the detail of low-level \Redis calls.
-* +default_service+: set the service name used when tracing application requests. Defaults to +rails-app+
-* +default_database_service+: set the database service name used when tracing database activity. Defaults to the
-  current adapter name, so if you're using PostgreSQL it will be +postgres+.
-* +default_cache_service+: set the cache service name used when tracing cache activity. Defaults to +rails-cache+
-* +template_base_path+: used when the template name is parsed in the auto instrumented code. If you don't store
-  your templates in the +views/+ folder, you may need to change this value
-* +tracer+: is the global tracer used by the tracing application. Usually you don't need to change that value
-  unless you're already using a different initialized +tracer+ somewhere else
-* +debug+: set to true to enable debug logging.
-* +trace_agent_hostname+: set the hostname of the trace agent.
-* +trace_agent_port+: set the port the trace agent is listening on.
-
-=== Sinatra
+* ``auto_instrument_redis``: if set to ``true`` Redis calls will be traced as such. Calls to Redis cache may be
+  still instrumented but you will not have the detail of low-level Redis calls.
+* ``default_service``: set the service name used when tracing application requests. Defaults to ``rails-app``
+* ``default_database_service``: set the database service name used when tracing database activity. Defaults to the
+  current adapter name, so if you're using PostgreSQL it will be ``postgres``.
+* ``default_cache_service``: set the cache service name used when tracing cache activity. Defaults to ``rails-cache``
+* ``template_base_path``: used when the template name is parsed in the auto instrumented code. If you don't store
+  your templates in the ``views/`` folder, you may need to change this value
+* ``tracer``: is the global tracer used by the tracing application. Usually you don't need to change that value
+  unless you're already using a different initialized ``tracer`` somewhere else
+* ``debug``: set to true to enable debug logging.
+* ``trace_agent_hostname``: set the hostname of the trace agent.
+* ``trace_agent_port``: set the port the trace agent is listening on.
+
+### Sinatra
 
 The Sinatra integration traces requests and template rendering. The integration is based on the
-+Datadog::Contrib::Sinatra::Tracer+ extension.
+``Datadog::Contrib::Sinatra::Tracer`` extension.
 
-To start using the tracing client, make sure you import +ddtrace+ and +ddtrace/contrib/sinatra/tracer+ after
-either +sinatra+ or +sinatra/base+:
+To start using the tracing client, make sure you import ``ddtrace`` and ``ddtrace/contrib/sinatra/tracer`` after
+either ``sinatra`` or ``sinatra/base``:
 
     require 'sinatra'
     require 'ddtrace'
@@ -105,9 +105,9 @@ either +sinatra+ or +sinatra/base+:
 
 The tracing extension will be automatically activated.
 
-==== Configure the tracer
+#### Configure the tracer
 
-To modify the default configuration, use the +settings.datadog_tracer.configure+ method. For example,
+To modify the default configuration, use the ``settings.datadog_tracer.configure`` method. For example,
 to change the default service name and activate the debug mode:
 
     configure do
@@ -116,20 +116,20 @@ to change the default service name and activate the debug mode:
 
 Available settings are:
 
-* +enabled+: define if the +tracer+ is enabled or not. If set to +false+, the code is still instrumented
+* ``enabled``: define if the ``tracer`` is enabled or not. If set to ``false``, the code is still instrumented
   but no spans are sent to the local trace agent.
-* +default_service+: set the service name used when tracing application requests. Defaults to +sinatra+
-* +tracer+: set the tracer to use. Usually you don't need to change that value
+* ``default_service``: set the service name used when tracing application requests. Defaults to ``sinatra``
+* ``tracer``: set the tracer to use. Usually you don't need to change that value
   unless you're already using a different initialized tracer somewhere else
-* +debug+: set to +true+ to enable debug logging.
-* +trace_agent_hostname+: set the hostname of the trace agent.
-* +trace_agent_port+: set the port the trace agent is listening on.
+* ``debug``: set to ``true`` to enable debug logging.
+* ``trace_agent_hostname``: set the hostname of the trace agent.
+* ``trace_agent_port``: set the port the trace agent is listening on.
 
-== Other libraries
+## Other libraries
 
-=== Redis
+### Redis
 
-The \Redis integration will trace simple calls as well as pipelines.
+The Redis integration will trace simple calls as well as pipelines.
 
     require 'redis'
     require 'ddtrace'
@@ -140,10 +140,10 @@ The \Redis integration will trace simple calls as well as pipelines.
     redis = Redis.new
     redis.set 'foo', 'bar' # traced!
 
-=== Elastic Search
+### Elastic Search
 
-The \Elasticsearch integration will trace any call to \perform_request
-in the \Client object:
+The Elasticsearch integration will trace any call to ``perform_request``
+in the ``Client`` object:
 
     require 'elasticsearch/transport'
     require 'ddtrace'
@@ -154,14 +154,14 @@ in the \Client object:
     client = Elasticsearch::Client.new url: 'http://127.0.0.1:9200'
     response = client.perform_request 'GET', '_cluster/health'
 
-Note that if you enable both \Elasticsearch and \Net/HTTP integrations then
-for each call, two spans are created, one for \Elasctisearch and one for \Net/HTTP.
-This typically happens if you call \patch_all to enable all integrations by default.
+Note that if you enable both Elasticsearch and Net/HTTP integrations then
+for each call, two spans are created, one for Elasctisearch and one for Net/HTTP.
+This typically happens if you call ``patch_all`` to enable all integrations by default.
 
-=== Net/HTTP
+### Net/HTTP
 
-The \Net/HTTP integration will trace any HTTP call using the standard lib
-\Net::HTTP module.
+The Net/HTTP integration will trace any HTTP call using the standard lib
+Net::HTTP module.
 
     require 'net/http'
     require 'ddtrace'
@@ -175,9 +175,9 @@ The \Net/HTTP integration will trace any HTTP call using the standard lib
 
     content = Net::HTTP.get(URI('http://127.0.0.1/index.html'))
 
-== Advanced usage
+## Advanced usage
 
-=== Manual Instrumentation
+### Manual Instrumentation
 
 If you aren't using a supported framework instrumentation, you may want to to manually instrument your code.
 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:
       end
     end
 
-=== Patching methods
+### Patching methods
 
-Integrations such as \Redis or \Elasticsearch use monkey patching.
+Integrations such as Redis or Elasticsearch use monkey patching.
 
 The available methods are:
 
-* +autopatch_modules+: returns a \Hash of all modules available for monkey patching,
-  the key is the name of the module and the value \true or \false. If it is \true,
-  a call to \patch_all will enable the module, if it is \false, it will do nothing.
-* +patch_all+: patches all modules which are supported. Make sure all the necessary
-  calls to \require have been done before this is called, else monkey patching will
+* ``autopatch_modules``: returns a hash of all modules available for monkey patching,
+  the key is the name of the module and the value ``true`` or ``false``. If it is ``true``,
+  a call to ``patch_all`` will enable the module, if it is ``false``, it will do nothing.
+* ``patch_all``: patches all modules which are supported. Make sure all the necessary
+  calls to ``require`` have been done before this is called, else monkey patching will
   not work.
-* +patch_module+: patches a single module, regardless of its settings in the
-  \autopatch_modules list.
-* +patch+: patches some modules, you should pass a hash like the one returned
-  by \autopatch_modules
-* +get_patched_modules+: returns the list of patched modules, a module has been
-  correctly patched only if it is in this hash, with a value set to \true.
+* ``patch_module``: patches a single module, regardless of its settings in the
+  ``autopatch_modules`` list.
+* ``patch``: patches some modules, you should pass a hash like the one returned
+  by ``autopatch_modules``
+* ``get_patched_modules``: returns the list of patched modules, a module has been
+  correctly patched only if it is in this hash, with a value set to ``true``.
 
 Example:
 
@@ -238,36 +238,36 @@ Example:
     Datadog::Monkey.patch_all                                # patch all the available modules
     puts Datadog::Monkey.get_patched_modules                 # tells wether modules are patched or not
 
-It is safe to call \patch_all, \patch_module or \patch several times.
-Make sure the library you want to patch is imported before you call \patch_module.
-In doubt, check with \get_patched_modules.
+It is safe to call ``patch_all``, ``patch_module`` or ``patch`` several times.
+Make sure the library you want to patch is imported before you call ``patch_module``.
+In doubt, check with ``get_patched_modules``.
 Once a module is patched, it is not possible to unpatch it.
 
-=== Patch Info (PIN)
+### Patch Info (PIN)
 
-The Patch Info, AKA \Pin object, gives you control on the integration.
+The Patch Info, AKA ``Pin`` object, gives you control on the integration.
 
 It has one class method:
 
-* +get_from+: returns the Pin object which has been pinned onto some random
-  object. It is safe to call \get_from on any object, but it might return \nil.
+* ``get_from``: returns the Pin object which has been pinned onto some random
+  object. It is safe to call ``get_from`` on any object, but it might return ``nil``.
 
 Some instance methods:
 
-* +enabled?+: wether tracing is enabled for this object
-* +onto+: applies the patch information to some random object. It is the companion
-  function of \get_from.
+* ``enabled?``: wether tracing is enabled for this object
+* ``onto``: applies the patch information to some random object. It is the companion
+  function of ``get_from``.
 
 Accessors:
 
-* +service+: service, you should typically set some meaningful value for this.
-* +app+: application name
-* +tags+: optional tags
-* +app_type+: application type
-* +name+: span name
-* +tracer+: the tracer object used for tracing
+* ``service``: service, you should typically set some meaningful value for this.
+* ``app``: application name
+* ``tags``: optional tags
+* ``app_type``: application type
+* ``name``: span name
+* ``tracer``: the tracer object used for tracing
 
-By default, a traced integration such as \Redis or \Elasticsearch carries a \Pin object. Eg:
+By default, a traced integration such as Redis or Elasticsearch carries a Pin object. Eg:
 
     require 'redis'
     require 'ddtrace'
@@ -303,7 +303,7 @@ You can use this object to instrument your own code:
       end
     end
 
-=== Debug Mode
+### Debug Mode
 
 If you need to check locally what traces and spans are sent after each traced block, you can enable
 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:
 Remember that the debug mode may affect your application performance and so it must not be used
 in a production environment.
 
-=== Supported Versions
+### Supported Versions
 
-==== Ruby interpreters
+#### Ruby interpreters
 
-The \Datadog Trace Client has been tested with the following Ruby versions:
+The Datadog Trace Client has been tested with the following Ruby versions:
 
 * Ruby MRI 2.1
 * Ruby MRI 2.2
@@ -343,32 +343,28 @@ The \Datadog Trace Client has been tested with the following Ruby versions:
 
 Other versions aren't yet officially supported.
 
-==== Ruby on Rails versions
+#### Ruby on Rails versions
 
 The supported versions are:
 
-* \Rails 3.2 (MRI interpreter, JRuby is experimental)
-* \Rails 4.2 (MRI interpreter, JRuby is experimental)
-* \Rails 5.0 (MRI interpreter)
+* Rails 3.2 (MRI interpreter, JRuby is experimental)
+* Rails 4.2 (MRI interpreter, JRuby is experimental)
+* Rails 5.0 (MRI interpreter)
 
 The currently supported web server are:
 * Puma 2.16+ and 3.6+
 * Unicorn 4.8+ and 5.1+
 * Passenger 5.0+
 
-==== Sinatra versions
+#### Sinatra versions
 
 Currently we are supporting Sinatra >= 1.4.0.
 
-=== Glossary
+### Glossary
 
-[Service] The name of a set of processes that do the same job. Some examples are +datadog-web-app+ or +datadog-metrics-db+.
-
-[Resource] A particular query to a service. For a web application, some examples might be a URL stem like +/user/home+ or a
-           handler function like +web.user.home+. For a SQL database, a resource would be the SQL of the query itself like
-           <tt>select * from users where id = ?</tt>.
-           You can track thousands (not millions or billions) of unique resources per services, so prefer resources like
-           +/user/home+ rather than <tt>/user/home?id=123456789</tt>.
-
-[Span] A span tracks a unit of work in a service, like querying a database or rendering a template. Spans are associated
-       with a service and optionally a resource. Spans have names, start times, durations and optional tags.
+* ``Service``: The name of a set of processes that do the same job. Some examples are ``datadog-web-app`` or ``datadog-metrics-db``.
+* ``Resource``: A particular query to a service. For a web application, some examples might be a URL stem like ``/user/home`` or a
+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 = ?``.
+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``.
+* ``Span``: A span tracks a unit of work in a service, like querying a database or rendering a template. Spans are associated
+with a service and optionally a resource. Spans have names, start times, durations and optional tags.

data/lib/ddtrace/version.rb

@@ -2,7 +2,7 @@ module Datadog
   module VERSION
     MAJOR = 0
     MINOR = 4
-    PATCH = 1
+    PATCH = 2
 
     STRING = [MAJOR, MINOR, PATCH].compact.join('.')
   end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: ddtrace
 version: !ruby/object:Gem::Version
-  version: 0.4.1
+  version: 0.4.2
 platform: ruby
 authors:
 - Datadog, Inc.
@@ -116,7 +116,7 @@ files:
 - circle.yml
 - ddtrace.gemspec
 - docker-compose.yml
-- docs/index.rdoc
+- docs/GettingStarted.md
 - gemfiles/contrib.gemfile
 - gemfiles/rails3_mysql2.gemfile
 - gemfiles/rails3_postgres.gemfile