ddtrace 1.0.0 → 1.9.0

data/.gitignore

@@ -1,70 +0,0 @@
-*.gem
-*.rbc
-*.swp
-*.nix
-*.vim
-/.config
-/coverage/
-/InstalledFiles
-/pkg/
-/spec/reports/
-/spec/examples.txt
-/test/tmp/
-/test/version_tmp/
-/tmp/
-/log/
-TODO
-
-# Used by dotenv library to load environment variables.
-# .env
-
-## Specific to RubyMotion:
-.dat*
-.repl_history
-build/
-*.bridgesupport
-build-iPhoneOS/
-build-iPhoneSimulator/
-
-## Specific to RubyMotion (use of CocoaPods):
-#
-# We recommend against adding the Pods directory to your .gitignore. However
-# you should judge for yourself, the pros and cons are mentioned at:
-# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
-#
-# vendor/Pods/
-
-## Documentation cache and generated files:
-/.yardoc/
-/_yardoc/
-/doc/
-/rdoc/
-/html/
-
-## Environment normalization:
-/.bundle/
-/vendor/bundle
-/lib/bundler/man/
-
-# for a library or gem, you might want to ignore these files since the code is
-# intended to run in multiple environments; otherwise, check them in:
-.ruby-version
-.ruby-gemset
-
-# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
-.rvmrc
-# Ignore local variables
-.envrc
-
-# lock files
-Gemfile.lock
-
-# bundle config
-gemfiles/.bundle
-
-# Native extension binaries
-lib/*.bundle
-lib/*.so
-
-# Extra file kept by sorbet for debugging usage, as documented in https://sorbet.org/docs/adopting#step-6-source-control
-sorbet/rbi/hidden-definitions/errors.txt

data/CONTRIBUTING.md

@@ -1,81 +0,0 @@
-# Contributing
-
-Community contributions to the Datadog tracing library for Ruby are welcome! See below for some basic guidelines.
-
-## Want to request a new feature?
-
-Many great ideas for new features come from the community, and we'd be happy to consider yours!
-
-To share your request, you can [open a Github issue](https://github.com/DataDog/dd-trace-rb/issues/new) with the details about what you'd like to see. At a minimum, please provide:
-
- - The goal of the new feature
- - A description of how it might be used or behave
- - Links to any important resources (e.g. Github repos, websites, screenshots, specifications, diagrams)
-
-Additionally, if you can, include:
-
- - A description of how it could be accomplished
- - Code snippets that might demonstrate its use or implementation
- - Screenshots or mockups that visually demonstrate the feature
- - Links to similar features that would serve as a good comparison
- - (Any other details that would be useful for implementing this feature!)
-
-## Found a bug?
-
-For any urgent matters (such as outages) or issues concerning the Datadog service or UI, contact our support team via https://docs.datadoghq.com/help/ for direct, faster assistance.
-
-You may submit bug reports concerning the Datadog tracing library for Ruby by [opening a Github issue](https://github.com/DataDog/dd-trace-rb/issues/new). At a minimum, please provide:
-
- - A description of the problem
- - Steps to reproduce
- - Expected behavior
- - Actual behavior
- - Errors (with stack traces) or warnings received
- - Any details you can share about your configuration including:
-    - Ruby version & platform
-    - `ddtrace` version
-    - Versions of any other relevant gems (or a `Gemfile.lock` if available)
-    - Any configuration settings for the trace library (e.g. `initializers/datadog.rb`)
-
-If at all possible, also provide:
-
- - Logs (from the tracer/application/agent) or other diagnostics
- - Screenshots, links, or other visual aids that are publicly accessible
- - Code sample or test that reproduces the problem
- - An explanation of what causes the bug and/or how it can be fixed
-
-Reports that include rich detail are better, and ones with code that reproduce the bug are best.
-
-## Have a patch?
-
-We welcome code contributions to the library, which you can [submit as a pull request](https://github.com/DataDog/dd-trace-rb/pull/new/master). To create a pull request:
-
-1. **Fork the repository** from https://github.com/DataDog/dd-trace-rb
-2. **Make any changes** for your patch.
-3. **Write tests** that demonstrate how the feature works or how the bug is fixed.
-4. **Update any documentation** such as `docs/GettingStarted.md`, especially for new features.
-5. **Submit the pull request** from your fork back to the latest revision of the `master` branch on https://github.com/DataDog/dd-trace-rb.
-
-The pull request will be run through our CI pipeline, and a project member will review the changes with you. At a minimum, to be accepted and merged, pull requests must:
-
- - Have a stated goal and detailed description of the changes made
- - Include thorough test coverage and documentation, where applicable
- - Pass all tests and code quality checks (linting/coverage/benchmarks) on CI
- - Receive at least one approval from a project member with push permissions
-
-We also recommend that you share in your description:
-
- - Any motivations or intent for the contribution
- - Links to any issues/pull requests it might be related to
- - Links to any webpages or other external resources that might be related to the change
- - Screenshots, code samples, or other visual aids that demonstrate the changes or how they are implemented
- - Benchmarks if the feature is anticipated to have performance implications
- - Any limitations, constraints or risks that are important to consider
-
-For more information on common topics such as debugging locally, or how to write new integrations, check out [our development guide](https://github.com/DataDog/dd-trace-rb/blob/master/docs/DevelopmentGuide.md). If at any point you have a question or need assistance with your pull request, feel free to mention a project member! We're always happy to help contributors with their pull requests.
-
-## Final word
-
-Many thanks to all of our contributors, and looking forward to seeing you on Github! :tada:
-
- - Datadog Ruby APM Team

data/ddtrace.gemspec

@@ -1,59 +0,0 @@
-# coding: utf-8
-
-lib = File.expand_path('../lib', __FILE__)
-$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
-require 'ddtrace/version'
-
-Gem::Specification.new do |spec|
-  spec.name                  = 'ddtrace'
-  spec.version               = DDTrace::VERSION::STRING
-  spec.required_ruby_version = [">= #{DDTrace::VERSION::MINIMUM_RUBY_VERSION}", "< #{DDTrace::VERSION::MAXIMUM_RUBY_VERSION}"]
-  spec.required_rubygems_version = '>= 2.0.0'
-  spec.authors               = ['Datadog, Inc.']
-  spec.email                 = ['dev@datadoghq.com']
-
-  spec.summary     = 'Datadog tracing code for your Ruby applications'
-  spec.description = <<-EOS.gsub(/^[\s]+/, '')
-    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.
-  EOS
-
-  spec.homepage = 'https://github.com/DataDog/dd-trace-rb'
-  spec.license  = 'BSD-3-Clause'
-
-  if spec.respond_to?(:metadata)
-    spec.metadata['allowed_push_host'] = 'https://rubygems.org'
-  else
-    raise 'RubyGems 2.0 or newer is required to protect against public gem pushes.'
-  end
-
-  spec.files =
-    `git ls-files -z`
-    .split("\x0")
-    .reject { |f| f.match(%r{^(test|spec|features|[.]circleci|[.]github|[.]dd-ci|benchmarks|gemfiles|integration|tasks|sorbet|yard)/}) }
-    .reject do |f|
-      ['.dockerignore', '.env', '.gitattributes', '.gitlab-ci.yml', '.rspec', '.rubocop.yml',
-       '.rubocop_todo.yml', '.simplecov', 'Appraisals', 'Gemfile', 'Rakefile', 'docker-compose.yml', '.pryrc', '.yardopts'].include?(f)
-    end
-  spec.executables   = ['ddtracerb']
-  spec.require_paths = ['lib']
-
-  if RUBY_VERSION >= '2.2.0'
-    spec.add_dependency 'msgpack'
-  else
-    # msgpack 1.4 fails for Ruby 2.1: https://github.com/msgpack/msgpack-ruby/issues/205
-    spec.add_dependency 'msgpack', '< 1.4'
-  end
-
-  # Used by the profiler native extension to support older Rubies (see NativeExtensionDesign.md for notes)
-  #
-  # Because we only use this for older Rubies, and we consider it "feature-complete" for those older Rubies,
-  # we're pinning it at the latest available version and will manually bump the dependency as needed.
-  spec.add_dependency 'debase-ruby_core_source', '<= 0.10.15'
-
-  # Used by appsec
-  spec.add_dependency 'libddwaf', '~> 1.3.0.0.0.a'
-
-  spec.extensions = ['ext/ddtrace_profiling_native_extension/extconf.rb']
-end

data/docs/AutoInstrumentation.md

@@ -1,36 +0,0 @@
-# Auto Instrumentation
-
-`ddtrace` can automatically instrument all available libraries, without requiring the manual setup of each one.
-
-## Rails
-
-Add the following to your `Gemfile`/`gems.rb` file:
-
-```ruby
-source 'https://rubygems.org'
-gem 'ddtrace', require: 'ddtrace/auto_instrument'
-```
-
-## Ruby
-
-Require `'ddtrace/auto_instrument'` after all gems that you'd like to instrument have been loaded:
-
-```ruby
-# Example libraries with supported integrations
-require 'sinatra'
-require 'faraday'
-require 'redis'
-
-require 'ddtrace/auto_instrument'
-```
-
-## Additional configuration
-
-You can reconfigure, override, or disable any specific integration settings by adding
-a [`Datadog.configure`](GettingStarted.md#integration-instrumentation) call after `ddtrace/auto_instrument` is activated.
-
-## Custom integrations
-
-Custom integrations that want to support auto instrumentation need to be registered
-(e.g. invoke their {Datadog::Tracing::Contrib::Registerable::ClassMethods#register_as} method) before
-the tracer requires `'ddtrace/auto_instrument'`.

data/docs/Deprecation.md

@@ -1,8 +0,0 @@
-# Deprecation
-
-Deprecated API objects are scheduled to be **removed in the next major version release**.
-
-Deprecated objects can still be safely used until the next major version.
-
-Objects will receive the deprecation tag in a minor version release,
-allowing for deprecation warnings to be surfaced to users before the next major release.

data/docs/DevelopmentGuide.md

@@ -1,259 +0,0 @@
-# Developing
-
-This guide covers some of the common how-tos and technical reference material for developing changes within the trace library.
-
-## Table of Contents
-
- - [Setting up](#setting-up)
- - [Testing](#testing)
-     - [Writing tests](#writing-tests)
-     - [Running tests](#running-tests)
-     - [Checking code quality](#checking-code-quality)
-     - [Running benchmarks](#running-benchmarks)
-     - [Type checking](#type-checking)
- - [Appendix](#appendix)
-     - [Writing new integrations](#writing-new-integrations)
-     - [Custom transport adapters](#custom-transport-adapters)
-
-## Setting up
-
-*NOTE: To test locally, you must have `Docker` and `Docker Compose` installed. See the [Docker documentation](https://docs.docker.com/compose/install/) for details.*
-
-The trace library uses Docker Compose to create a Ruby environment to develop and test within, as well as containers for any dependencies that might be necessary for certain kinds of tests.
-
-To start a development environment, choose a target Ruby version then run the following:
-
-```
-# In the root directory of the project...
-cd ~/dd-trace-rb
-
-# Create and start a Ruby 2.3 test environment with its dependencies
-docker-compose run --rm tracer-2.3 /bin/bash
-
-# Then inside the container (e.g. `root@2a73c6d8673e:/app`)...
-# Install the library dependencies
-bundle install
-
-# Install build targets
-appraisal install
-```
-
-Then within this container you can [run tests](#running-tests), or [run code quality checks](#checking-code-quality).
-
-## Testing
-
-The test suite uses [RSpec](https://rspec.info/) tests to verify the correctness of both the core trace library and its integrations.
-
-### Writing tests
-
-New tests should be written as RSpec tests in the `spec/ddtrace` folder. Test files should generally mirror the structure of `lib`.
-
-All changes should be covered by a corresponding RSpec tests. Unit tests are preferred, and integration tests are accepted where appropriate (e.g. acceptance tests, verifying compatibility with datastores, etc) but should be kept to a minimum.
-
-**Considerations for CI**
-
-All tests should run in CI. When adding new `spec.rb` files, you may need to add a test task to ensure your test file is run in CI.
-
- - Ensure that there is a corresponding Rake task defined in `Rakefile` under the the `spec` namespace, whose pattern matches your test file.
- - Verify the Rake task is configured to run for the appropriate Ruby runtimes in the `ci` Rake task.
-
-### Running tests
-
-Simplest way to run tests is to run `bundle exec rake ci`, which will run the entire test suite, just as CI does.
-
-**For the core library**
-
-Run the tests for the core library with:
-
-```
-$ bundle exec rake spec:main
-```
-
-**For integrations**
-
-Integrations which interact with dependencies not listed in the `ddtrace` gemspec will need to load these dependencies to run their tests.
-
-To do so, load the dependencies using [Appraisal](https://github.com/thoughtbot/appraisal). You can see a list of available appraisals with `bundle exec appraisal list`, or examine the `Appraisals` file.
-
-Then to run tests, prefix the test commain with the appraisal. For example:
-
-```
-# Runs tests for Rails 3.2 + Postgres
-$ bundle exec appraisal rails32-postgres spec:rails
-# Runs tests for Redis
-$ bundle exec appraisal contrib rake spec:redis
-```
-
-**Passing arguments to tests**
-
-When running RSpec tests, you may pass additional args as parameters to the Rake task. For example:
-
-```
-# Runs Redis tests with seed 1234
-$ bundle exec appraisal contrib rake spec:redis'[--seed,1234]'
-```
-
-This can be useful for replicating conditions from CI or isolating certain tests.
-
-**Checking test coverage**
-
-You can check test code coverage by creating a report _after_ running a test suite:
-```
-# Run the desired test suite
-$ bundle exec appraisal contrib rake spec:redis
-# Generate report for the suite executed
-$ bundle exec rake coverage:report
-```
-
-A webpage will be generated at `coverage/report/index.html` with the resulting report.
-
-Because you are likely not running all tests locally, your report will contain partial coverage results.
-You *must* check the CI step `coverage` for the complete test coverage report, ensuring coverage is not
-decreased.
-
-**Ensuring tests don't leak resources**
-
-Tests execution can create resources that are hard to track: threads, sockets, files, etc. Because these resources can come
-from the both the test setup as well as the code under test, making sure all resources are properly disposed is important
-to prevent the application from inadvertently creating cumulative resources during its execution.
-
-When running tests that utilize threads, you might see an error message similar to this one:
-
-```
-Test leaked 1 thread: "Datadog::Workers::AsyncTransport integration tests"
-Ensure all threads are terminated when test finishes:
-1: #<Thread:0x00007fcbc99863d0 /Users/marco.costa/work/dd-trace-rb/spec/spec_helper.rb:145 sleep> (Thread)
-Thread Creation Site:
-        ./dd-trace-rb/spec/ddtrace/workers_integration_spec.rb:245:in 'new'
-        ./dd-trace-rb/spec/ddtrace/workers_integration_spec.rb:245:in 'block (4 levels) in <top (required)>'
-Thread Backtrace:
-        ./dd-trace-rb/spec/ddtrace/workers_integration_spec.rb:262:in 'sleep'
-        .dd-trace-rb/spec/ddtrace/workers_integration_spec.rb:262:in 'block (5 levels) in <top (required)>'
-        ./dd-trace-rb/spec/spec_helper.rb:147:in 'block in initialize'
-```
-
-This means that this test did not finish all threads by the time the test had finished. In this case, the thread
-creation can be traced to `workers_integration_spec.rb:245:in 'new'`. The thread itself is sleeping at `workers_integration_spec.rb:262:in 'sleep'`.
-
-The actionable in this case would be to ensure that the thread created in `workers_integration_spec.rb:245` is properly terminated by invoking `Thread#join` during the test tear down, which will wait for the thread to finish before returning.
-
-Depending on the situation, the thread in question might need to be forced to terminate. It's recommended to have a mechanism in place to terminate it (a shared variable that changes value when the thread should exit), but as a last resort, `Thread#terminate` forces the thread to finish. Keep in mind that regardless of the termination method, `Thread#join` must be called to ensure that the thread has completely finished its shutdown process.
-
-### Checking code quality
-
-**Linting**
-
-The trace library uses Rubocop to enforce [code style](https://github.com/bbatsov/ruby-style-guide) and quality. To check, run:
-
-```
-$ bundle exec rake rubocop
-```
-
-### Running benchmarks
-
-If your changes can have a measurable performance impact, we recommend running our benchmark suite:
-
-```
-$ bundle exec rake spec:benchmark
-```
-
-Results are printed to STDOUT as well as written to the `./tmp/benchmark/` directory.
-
-## Type checking
-
-This library uses the [Sorbet](https://sorbet.org/) type checker. Sorbet can be run with `bundle exec srb tc` (or `bundle exec rake
-typecheck`). There's also Language Server Protocol support, if your editor supports it.
-
-Type checking can be controlled on a file-by-file manner, using a `# typed: ...` comment. The default (when none is provided) is assuming `# typed: false`.
-
-Things to note:
-
-* For compatibility with older Rubies, we use Sorbet but do not yet allow type annotations in the codebase. If Sorbet is blocking you, feel free to use `# typed: false` or `# typed: ignore` with a quick note on why this was needed. In many cases, Sorbet can typecheck a file correctly with no extra type annotations.
-
-* Most integration-specific code will reference optional external dependencies which Sorbet cannot see into. You'll probably need to use `# typed: false` or `# typed: ignore`  for those files as well.
-
-## Appendix
-
-### Writing new integrations
-
-Integrations are extensions to the trace library that add support for external dependencies (gems); they typically add auto-instrumentation to popular gems and frameworks. You will find many of our integrations in the `contrib` folder.
-
-Some general guidelines for adding new integrations:
-
- - An integration can either be added directly to `dd-trace-rb`, or developed as its own gem that depends on `ddtrace`.
- - Integrations should implement the configuration API for easy, consistent implementation. (See existing integrations as examples of this.)
- - All new integrations require documentation, unit/integration tests written in RSpec, and passing CI builds.
- - It's highly encouraged to share screenshots or other demos of how the new integration looks and works.
-
-To get started quickly, it's perfectly fine to copy-paste an existing integration to use as a template, then modify it to match your needs. This is usually the fastest, easiest way to bootstrap a new integration and makes the time-to-first-trace often very quick, usually less than an hour if it's a simple implementation.
-
-Once you have it working in your application, you can [add unit tests](#writing-tests), [run them locally](#running-tests), and [check for code quality](#checking-code-quality) using Docker Compose.
-
-Then [open a pull request](../CONTRIBUTING.md#have-a-patch) and be sure to add the following to the description:
-
- - [Documentation](./GettingStarted.md) for the integration, including versions supported.
- - Links to the repository/website of the library being integrated
- - Screenshots showing a sample trace
- - Any additional code snippets, sample apps, benchmarks, or other resources that demonstrate its implementation are a huge plus!
-
-### Custom transport adapters
-
-The tracer can be configured with transports that customize how data is sent and where it is sent to. This is done through the use of adapters: classes that receive generic requests, process them, and return appropriate responses.
-
-#### Developing HTTP transport adapters
-
-To create a custom HTTP adapter, define a class that responds to `call(env)` which returns a kind of `Datadog::Transport::Response`:
-
-```ruby
-require 'ddtrace/transport/response'
-
-class CustomAdapter
-  # Sends HTTP request
-  # env: Datadog::Transport::HTTP::Env
-  def call(env)
-    # Add custom code here to send data.
-    # Then return a Response object.
-    Response.new
-  end
-
-  class Response
-    include Datadog::Transport::Response
-
-    # Implement the following methods as appropriate
-    # for your adapter.
-
-    # Return a String
-    def payload; end
-
-    # Return true/false
-    # Return nil if it does not apply
-    def ok?; end
-    def unsupported?; end
-    def not_found?; end
-    def client_error?; end
-    def server_error?; end
-    def internal_error?; end
-  end
-end
-```
-
-Optionally, you can register the adapter as a well-known type:
-
-```ruby
-Datadog::Transport::HTTP::Builder::REGISTRY.set(CustomAdapter, :custom)
-```
-
-Then pass an adapter instance to the tracer configuration:
-
-```ruby
-Datadog.configure do |c|
-  c.tracing.transport_options = proc { |t|
-    # By name
-    t.adapter :custom
-
-    # By instance
-    custom_adapter = CustomAdapter.new
-    t.adapter custom_adapter
-  }
-end
-```