Releases: DataDog/dd-trace-rb
1.12.0
Highlights
Remote configuration
-
We fixed an issue with Passlist.
-
We have added support for Custom In-App Waf Rules
-
In previous versions, there was an issue with identifying the service name correctly. Everything, by default now should work as expected.
Mounted applications
- Appsec now supports mounted apps. That means you can instrument multiple services with appsec.
Using the example of a Sinatra app mounted as part of a Rails application, you can now instrument both with AppSec. The configuration below should work now.
require 'datadog/appsec'
Datadog.configure do |c|
c.appsec.enabled = true
c.appsec.instrument :rails
c.appsec.instrument :sinatra
end
Added
- Profiling: Add support for profiling Ruby 3.3.0-preview1 (#2860)
- Appsec: Appsec support nested apps (#2836)
- Appsec: Appsec add support for custom rules (#2856)
- Appsec: Update appsec static rules to 1.7.0 version (#2869)
- Appsec: Tag AppSec on Rack top-level span (#2858)
- Profiling: Implement "no signals" workaround and enable CPU Profiling 2.0 for all customers (#2873)
- Ci: Update CI Visibility spec (#2874)
- Appsec: Added missing waf addresses to request operation (#2883)
Changed
- Tracing: Consistent APM Span tags for AWS SDK Requests (#2730)
- Tracing: Change default
service_name
values Part 2 (#2765) - Profiling: Bump debase-ruby_core_source dependency to 3.2.1 (#2875)
Fixed
- Telemetry: Disable for non-HTTP agent connection (#2815)
- Tracing: Fix circular requires (#2826)
- Tracing: Update comment about Datadog::Tracing::Distributed::Ext to correct modules (#2840)
- Appsec: Check if
:appsec
setting is present before accessing it in remote component (#2854) - Telemetry: Do not send Dependency
hash
whenversion
is present (#2855) - Core: Fix symbol configuration for
env
andservice
(#2864) - Tracing: Fix sql comment propagation
full
mode when tracing is disabled (#2866) - Appsec: Use relative URI for server.request.uri.raw (#2890)
Read the full changeset and the release milestone.
1.11.1
1.11.0
Highlights
Remote Configuration
The Remote Configuration feature is now in General Availability.
What to expect from Remote Configuration?
ASM can now receive live updates via Remote Configuration, such as:
- protection rules, including request blocking
- IP and path passlists
- IP and user denylists
Remote Configuration will be progressively expanded to support other Datadog products such as APM.
How to configure Remote Configuration?
- Make sure ASM is enabled (see our documentation)
- Upgrade the Datadog agent to 7.42.0 or above (7.43.0 or above recommended)
- Configure the agent to allow Remote Configuration via e.g the environment variable
DD_REMOTE_CONFIGURATION_ENABLED=true
To opt out of Remote Configuration, it can be done via either the environment variable DD_REMOTE_CONFIGURATION_ENABLED=false
or Datadog.configure { |c| c.remote.enabled = false }
.
Read more about Remote Configuration in our documentation
Ruby CPU Profiling 2.0
The new CPU Profiling 2.0 feature is now in General Availability.
What to expect from Ruby CPU Profiling 2.0?
- Finer-grained profiling data due to our sampling engine rewritten in C+Rust. The profiler will be able to run more often and get more information while keeping the same 2% overhead target you're used to, and with a lower impact on latency. Especially when looking at the "Code Hotspots" panel for a distributed trace, expect more and finer grained profiles.
- Thread id information now includes the operating system thread id for Ruby 3.1+, so you'll be able to correlate your thread information when looking at other system monitoring tools
- Thread names are now collected and you're able to filter your profiles by these names
- The profiler now exposes a
Datadog::Profiling.allocation_count
API that can be used to measure how many objects were allocated in parts of your application - Experimental support for capturing CPU and Wall-time spent doing Garbage Collection. This is disabled by default as we're still improving the performance of this feature and fixing a few incompatibilities with Ruby Ractors. You can enable it by adding
DD_PROFILING_FORCE_ENABLE_GC=true
orc.profiling.advanced.force_enable_gc_profiling = true
to the instructions seen above.
...with more and faster improvements to come soon!
If you're using the profiler, the new feature will be automatically enabled, except in the following cases:
- When running on Ruby 2.5 and below
- When the
mysql2
orrugged
gems are installed
Known issues:
-
Rare incompatibilities with native extensions/libraries.
Ruby CPU Profiling 2.0 gathers profiling data by sending SIGPROF unix signals to Ruby applications. This is a common approach used by many other profilers, and it may cause system calls performed by native extensions/libraries to be interrupted with an EINTR error code (reference).
Most native extensions/libraries are unaffected by this issue, but we know that the
mysql2
andrugged
gems can trigger these issues (details). When either of these gems is detected, the new feature is not enabled.We expect these occurrences to be rare, and will be working to both improve the ecosystem as well as to deploy countermeasures in the profiler itself to avoid triggering these issues.
-
Ruby 2.5 and below are missing an API that allows the profiler to detect the currently-active Ruby thread. We plan to ship a workaround for this issue soon.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection is incompatible with Ractors due to Ruby upstream bugs (https://bugs.ruby-lang.org/issues/18464 and https://bugs.ruby-lang.org/issues/19112). We plan to work with the Ruby developers to incorporate fixes for these issues.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection can cause a lot of overhead in Ruby applications with high object allocation rates.
Telemetry
The Telemetry feature is now in General Availability and enabled by default. It will allow Datadog to provide more efficient support.
Added
- Add remote configuration, enabled by default (#2674, #2678, #2686, #2687, #2688, #2689, #2696, #2705, #2731, #2732, #2733, #2739, #2756, #2769, #2771, #2773, #2789, #2805, #2794)
- AppSec: Add response headers passing to WAF (#2701)
- Tracing: Distributed tracing for Sidekiq (#2513)
- Tracing: Add Roda integration (#2368)
- Profiling: Support disabling endpoint names collection in new profiler (#2698)
- Tracing: Support Sidekiq 7 (#2810)
- Core: Add support for Unix Domain Socket (UDS) configuration via
DD_TRACE_AGENT_URL
(#2806) - Core: Enable Telemetry by default (#2762)
Changed
- Core: Allow
1
as true value in environment variables (#2710) - Profiling: Enable CPU Profiling 2.0 by default (#2702)
- Tracing: Improve controller instrumentation and deprecate option
exception_controller
(#2726) - Tracing: Implement Span Attribute Schema Environment Variable (#2727)
- Tracing: Change default
service_name
values (gated by feature flag) (#2760)
Fixed
- Bug: Tracing: Fix w3c propagation special character handling (#2720)
- Performance: Tracing: Use
+@
instead ofdup
for duplicating strings (#2704) - Profiling: Avoid triggering allocation sampling during sampling (#2690)
- Integrations: Tracing: Fix Rails < 3 conditional check in Utils#railtie_supported? (#2695)
- Profiling: Do not auto-enable new profiler when rugged gem is detected (#2741)
- Tracing: Fix using SemanticLogger#log(severity, message, progname) (#2748) (@rqz13)
- Profiling: Improve detection of mysql2 gem incompatibilities with profiler (#2770)
- AppSec: Remove check for
::Rack::Request.instance_methods.include?(:each_header)
at load time (#2778) - Tracing: Fix quadratic backtracking on invalid URI (#2788)
- Community: Correctly set mutex (#2757) (@ixti)
Read the full changeset and the release milestone.
1.11.0.beta1
As of ddtrace 1.11.0.beta1, the Remote Configuration feature is now in public beta.
What to expect from Ruby Remote Configuration?
ASM can now receive live updates via Remote Configuration, such as:
- protection rules
- IP and path passlists
- IP and user denylists
How to enable?
- Make sure ASM is enabled (see our documentation)
- Configure the agent to allow Remote Configuration via e.g the environment variable
DD_REMOTE_CONFIGURATION_ENABLED=true
- Configure your app to start using Remote Configuration via either the environment variable
DD_REMOTE_CONFIGURATION_ENABLED=true
orDatadog.configure { |c| c.remote.enabled = true }
As of ddtrace 1.11.0.beta1, the new CPU Profiling 2.0 feature is now in General Availability.((Click to expand for details))
What to expect from Ruby CPU Profiling 2.0?
- Finer-grained profiling data due to our sampling engine rewritten in C+Rust. The profiler will be able to run more often and get more information while keeping the same 2% overhead target you're used to, and with a lower impact on latency. Especially when looking at the "Code Hotspots" panel for a distributed trace, expect more and finer grained profiles.
- Thread id information now includes the operating system thread id for Ruby 3.1+, so you'll be able to correlate your thread information when looking at other system monitoring tools
- Thread names are now collected and you're able to filter your profiles by these names
- The profiler now exposes a
Datadog::Profiling.allocation_count
API that can be used to measure how many objects were allocated in parts of your application - Experimental support for capturing CPU and Wall-time spent doing Garbage Collection. This is disabled by default as we're still improving the performance of this feature and fixing a few incompatibilities with Ruby Ractors. You can enable it by adding
DD_PROFILING_FORCE_ENABLE_GC=true
orc.profiling.advanced.force_enable_gc_profiling = true
to the instructions seen above.
...with more and faster improvements to come soon!
If you're using the profiler, the new feature will be automatically enabled, except in the following cases:
- When running on Ruby 2.5 and below
- When the
mysql2
orrugged
gems are installed
Known issues:
-
Rare incompatibilities with native extensions/libraries.
Ruby CPU Profiling 2.0 gathers profiling data by sending SIGPROF unix signals to Ruby applications. This is a common approach used by many other profilers, and it may cause system calls performed by native extensions/libraries to be interrupted with an EINTR error code (reference).
Most native extensions/libraries are unaffected by this issue, but we know that the
mysql2
andrugged
gems can trigger these issues (details). When either of these gems is detected, the new feature is not enabled.We expect these occurrences to be rare, and will be working to both improve the ecosystem as well as to deploy countermeasures in the profiler itself to avoid triggering these issues.
-
Ruby 2.5 and below are missing an API that allows the profiler to detect the currently-active Ruby thread. We plan to ship a workaround for this issue soon.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection is incompatible with Ractors due to Ruby upstream bugs (https://bugs.ruby-lang.org/issues/18464 and https://bugs.ruby-lang.org/issues/19112). We plan to work with the Ruby developers to incorporate fixes for these issues.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection can cause a lot of overhead in Ruby applications with high object allocation rates.
Added
- Add remote configuration beta, disabled by default (#2674, #2678, #2686, #2687, #2688, #2689, #2696, #2705, #2731, #2732, #2733, #2739, #2756, #2769, #2771, #2773, #2789)
- AppSec: Add response headers passing to WAF (#2701)
- Tracing: Distributed tracing for Sidekiq (#2513)
- Tracing: Add Roda integration (#2368)
- Profiling: Support disabling endpoint names collection in new profiler (#2698)
Changed
- Core: Allow
1
as true value in environment variables (#2710) - Profiling: Enable CPU Profiling 2.0 by default (#2702)
- Tracing: Improve controller instrumentation and deprecate option
exception_controller
(#2726) - Tracing: Implement Span Attribute Schema Environment Variable (#2727)
Fixed
- Bug: Tracing: Fix w3c propagation special character handling (#2720)
- Performance: Tracing: Use
+@
instead ofdup
for duplicating strings (#2704) - Profiling: Avoid triggering allocation sampling during sampling (#2690)
- Integrations: Tracing: Fix Rails < 3 conditional check in Utils#railtie_supported? (#2695)
- Profiling: Do not auto-enable new profiler when rugged gem is detected (#2741)
- Tracing: Fix using SemanticLogger#log(severity, message, progname) (#2748) (@rqz13)
- Profiling: Improve detection of mysql2 gem incompatibilities with profiler (#2770)
- AppSec: Remove check for
::Rack::Request.instance_methods.include?(:each_header)
at load time (#2778) - Tracing: Fix quadratic backtracking on invalid URI (#2788)
Read the full changeset and the release milestone.
1.10.1
Fixed
- CI: Update TeamCity environment variable support (#2668)
- Core: Fix spurious dependency on AppSec when loading CI with
require 'datadog/ci'
(#2679) - Core: Allow multiple headers and multiple IPs per header for client IP (#2665)
- AppSec: prevent side-effect on AppSec login event tracking method arguments (#2663)
Read the full changeset and the release milestone.
1.10.0
The release of ddtrace 1.10.0 now supports Ruby 3.2 and 128-bit trace id.
Furthermore, CPU Profiling 2.0 is now in opt-in (that is, disabled by default) beta 3. (Click to expand for details)
You can enable it:
- Using an environment variable by setting
DD_PROFILING_FORCE_ENABLE_NEW=true
- Or via code by adding to your
Datadog.configure
block:
Datadog.configure do |c|
# ... existing configuration ...
c.profiling.advanced.force_enable_new_profiler = true
end
What to expect from Ruby CPU Profiling 2.0 beta 3?
- Finer-grained profiling data due to our sampling engine rewritten in C+Rust. The profiler will be able to run more often and get more information while keeping the same 2% overhead target you're used to, and with a lower impact on latency. Especially when looking at the "Code Hotspots" panel for a distributed trace, expect more and finer grained profiles.
- Thread id information now includes the operating system thread id for Ruby 3.1+, so you'll be able to correlate your thread information when looking at other system monitoring tools
- Thread names are now collected and you're able to filter your profiles by these names
- The profiler now exposes a
Datadog::Profiling.allocation_count
API that can be used to measure how many objects were allocated in parts of your application - Experimental support for capturing CPU and Wall-time spent doing Garbage Collection. This is disabled by default as we're still improving the performance of this feature and fixing a few incompatibilities with Ruby Ractors. You can enable it by adding
DD_PROFILING_FORCE_ENABLE_GC=true
orc.profiling.advanced.force_enable_gc_profiling = true
to the instructions seen above.
...with more and faster improvements to come soon!
Give it a try, and we'd love to hear your feedback. Below, you'll find a list of known issues that we're still looking into.
Known issues:
-
Rare incompatibilities with native extensions/libraries.
Ruby CPU Profiling 2.0 gathers profiling data by sending SIGPROF unix signals to Ruby applications. This is a common approach used by many other profilers, and it may cause system calls performed by native extensions/libraries to be interrupted with an EINTR error code (reference).
Most native extensions/libraries are unaffected by this issue, but we know of at least one case: when using the
mysql2
gem together with versions of libmysqlclient older than 8.0.0 this can lead to failed database requests (reference). The affected libmysqlclient version is known to be present on Ubuntu 18.04, but not 20.04 and later releases.We expect these occurrences to be rare, and will be working to both improve the ecosystem as well as to deploy countermeasures in the profiler itself to avoid triggering these issues.
-
Ruby 2.5 and below are missing an API that allows the profiler to detect the currently-active Ruby thread. We have deployed a workaround, but suspect that it may lead to crashes in extremely rare situations. We are still researching a solution for this issue and do not plan on rolling out CPU Profiling 2.0 automatically to Ruby 2.5 and below applications until it is fixed.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection is incompatible with Ractors due to Ruby upstream bugs (https://bugs.ruby-lang.org/issues/18464 and https://bugs.ruby-lang.org/issues/19112). We plan to work with the Ruby developers to incorporate fixes for these issues.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection can cause a lot of overhead in Ruby applications with high object allocation rates. We will be fixing this soon!
Added
- Support Ruby 3.2 (#2601)
- Publish init container image (beta) for
dd-trace-rb
injection through K8s admission controller (#2606) - Tracing: Support 128 bits trace id (#2543)
- Tracing: Add tags to integrations (
que
/racecar
/resque
/shoryken
/sneakers
/qless
/delayed_job
/kafka
/sidekiq
/dalli
/presto
/elasticsearch
) (#2619, #2613 , #2608, #2590) - Appsec: Introduce
AppSec::Instrumentation::Gateway::Argument
(#2648) - Appsec: Block request when user ID matches rules (#2642)
- Appsec: Block request base on response addresses matches (#2605)
- Appsec: Allow to set user id denylist (#2612)
- Profiling: Show profiler overhead in flamegraph for CPU Profiling 2.0 (#2607)
- Profiling: Add support for allocation samples to
ThreadContext
(#2657) - Profiling: Exclude disabled profiling sample value types from output (#2634)
- Profiling: Extend stack collector to be able to record the alloc-samples metric (#2618)
- Profiling: Add
Profiling.allocation_count
API for new profiler (#2635)
Changed
- Tracing:
rack
instrumentation counts time spent in queue as part of thehttp_server.queue
span (#2591) (@agrobbin) - Appsec: Update waf ruleset to 1.5.2 (#2662, #2659, #2598)
- Appsec: Update
libddwaf
version to 1.6.2.0.0 (#2614) - Profiling: Upgrade profiler to use
libdatadog
v2.0.0 (#2599) - Profiling: Remove support for profiling Ruby 2.2 (#2592)
Fixed
- Fix broken Ruby VM statistics for Ruby 3.2 (#2600)
- Tracing: Fix 'uninitialized constant GRPC::Interceptor' with
gapic-common
gem (#2649) - Appsec: Make sure to assign a valid processor to appsec component (#2637)
- Profiling: Fix profiler not adding the "In native code" placeholder (#2594)
- Fix profiler detection for google-protobuf installation (#2595)
Read the full changeset and the release milestone
1.9.0
As of ddtrace 1.9.0, CPU Profiling 2.0 is now in opt-in (that is, disabled by default) beta 2. (Click to expand for details)
You can enable it:- Using an environment variable by setting
DD_PROFILING_FORCE_ENABLE_NEW=true
- Or via code by adding to your
Datadog.configure
block:
Datadog.configure do |c|
# ... existing configuration ...
c.profiling.advanced.force_enable_new_profiler = true
end
What to expect from Ruby CPU Profiling 2.0 beta 2?
- Finer-grained profiling data due to our sampling engine rewritten in C+Rust. The profiler will be able to run more often and get more information while keeping the same 2% overhead target you're used to, and with a lower impact on latency. Especially when looking at the "Code Hotspots" panel for a distributed trace, expect more and finer grained profiles.
- Thread id information now includes the operating system thread id for Ruby 3.1+, so you'll be able to correlate your thread information when looking at other system monitoring tools
- Thread names are now collected and you're able to filter your profiles by these names
- Experimental support for capturing CPU and Wall-time spent doing Garbage Collection. This is disabled by default as we're still improving the performance of this feature and fixing a few incompatibilities with Ruby Ractors. You can enable it by adding
DD_PROFILING_FORCE_ENABLE_GC=true
orc.profiling.advanced.force_enable_gc_profiling = true
to the instructions seen above.
...with more and faster improvements to come in early 2023!
Give it a try, and we'd love to hear your feedback. Below, you'll find a list of known issues that we're still looking into.
Known issues:
-
Profiling CPU-time overhead is not shown in flamegraphs (unlike with the existing profiler). We will be fixing this soon!
-
Rare incompatibilities with native extensions/libraries.
Ruby CPU Profiling 2.0 gathers profiling data by sending SIGPROF unix signals to Ruby applications. This is a common approach used by many other profilers, and it may cause system calls performed by native extensions/libraries to be interrupted with an EINTR error code (reference).
Most native extensions/libraries are unaffected by this issue, but we know of at least one case: when using the
mysql2
gem together with versions of libmysqlclient older than 8.0.0 this can lead to failed database requests (reference). The affected libmysqlclient version is known to be present on Ubuntu 18.04, but not 20.04 and later releases.
We expect these occurrences to be rare, and will be working to both improve the ecosystem as well as to deploy countermeasures in the profiler itself to avoid triggering these issues. -
Ruby 2.5 and below are missing an API that allows the profiler to detect the currently-active Ruby thread. We have deployed a workaround, but suspect that it may lead to crashes in extremely rare situations. We are still researching a solution for this issue and do not plan on rolling out CPU Profiling 2.0 automatically to Ruby 2.5 and below applications until it is fixed.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection is incompatible with Ractors due to Ruby upstream bugs (https://bugs.ruby-lang.org/issues/18464 and https://bugs.ruby-lang.org/issues/19112). We plan to work with the Ruby developers to incorporate fixes for these issues.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection can cause a lot of overhead in Ruby applications with high object allocation rates. We will be fixing this soon!
Added
- Tracing: Add
Stripe
instrumentation (#2557) - Tracing: Add configurable response codes considered as errors for
Net/HTTP
,httprb
andhttpclient
(#2501, #2576)(@caramcc) - Tracing: Flexible header matching for HTTP propagator (#2504)
- Tracing:
OpenTelemetry
Traces support (#2496) - Tracing: W3C: Propagate unknown values as-is (#2485)
- AppSec: Add event kit API (#2512)
- Profiling: Allow profiler development on arm64 macOS (#2573)
- Core: Add
profiling_enabled
state to environment logger output (#2541) - Core: Add 'type' to
OptionDefinition
(#2493) - Allow
debase-ruby_core_source
3.2.0 to be used (#2526)
Changed
- Profiling: Upgrade to
libdatadog
to1.0.1.1.0
(#2530) - Appsec: Update appsec rules
1.4.3
(#2580) - Ci: Update CI Visibility metadata extraction (#2586)
Fixed
- Profiling: Fix wrong
libdatadog
version being picked during profiler build (#2531) - Tracing: Support
PG
calls with a block (#2522) - Ci: Fix error in
teamcity
env vars (#2562)
Read the full changeset and the release milestone
1.8.0
Happy holidays! This release includes two big items we're pretty excited about and want to call out explicitly:
-
CPU Profiling 2.0 is now in beta! (Click to expand for details)
As of ddtrace 1.8.0, CPU Profiling 2.0 is now in opt-in (that is, disabled by default) public beta.
You can enable it:
- Using an environment variable by setting
DD_PROFILING_FORCE_ENABLE_NEW=true
- Or via code by adding to your
Datadog.configure
block:
Datadog.configure do |c| # … existing configuration … c.profiling.advanced.force_enable_new_profiler = true end
What to expect from Ruby CPU Profiling 2.0 beta?
- Finer-grained profiling data due to our sampling engine rewritten in C+Rust. The profiler will be able to run more often and get more information while keeping the same 2% overhead target you’re used to, and with a lower impact on latency. Especially when looking at the “Code Hotspots” panel for a distributed trace, expect more and finer grained profiles.
- Thread id information now includes the operating system thread id for Ruby 3.1+, so you’ll be able to correlate your thread information when looking at other system monitoring tools
- Thread names are now collected and you’ll be able to filter your profiles by these names
- Experimental support for capturing CPU and Wall-time spent doing Garbage Collection. This is disabled by default as we’re still improving the performance of this feature and fixing a few incompatibilities with Ruby Ractors. You can enable it by adding
DD_PROFILING_FORCE_ENABLE_GC=true
orc.profiling.advanced.force_enable_gc_profiling = true
to the instructions seen above.
…with more and faster improvements to come in early 2023!
Give it a try, and we’d love to hear your feedback. Do note that while in beta, we don’t recommend using Ruby CPU Profiling 2.0 in production environments. Below, you’ll find a list of known issues that we’re still looking into.
Known issues:
-
Profiling CPU-time overhead is not shown in flamegraphs (unlike with the existing profiler). We will be fixing this soon!
-
Rare incompatibilities with native extensions/libraries.
Ruby CPU Profiling 2.0 gathers profiling data by sending SIGPROF unix signals to Ruby applications. This is a common approach used by many other profilers, and it may cause system calls performed by native extensions/libraries to be interrupted with an EINTR error code (reference).
Most native extensions/libraries are unaffected by this issue, but we know of at least one case: when using the
mysql2
gem together with versions of libmysqlclient older than 8.0.0 this can lead to failed database requests (reference). The affected libmysqlclient version is known to be present on Ubuntu 18.04, but not 20.04 and later releases.We expect these occurrences to be rare, and will be working to both improve the ecosystem as well as to deploy countermeasures in the profiler itself to avoid triggering these issues.
-
Ruby 2.5 and below are missing an API that allows the profiler to detect the currently-active Ruby thread. We have deployed a workaround, but suspect that it may lead to crashes in extremely rare situations. We are still researching a solution for this issue and do not plan on rolling out CPU Profiling 2.0 automatically to Ruby 2.5 and below applications until it is fixed.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection is incompatible with Ractors due to Ruby upstream bugs (https://bugs.ruby-lang.org/issues/18464 and https://bugs.ruby-lang.org/issues/19112). We plan to work with the Ruby developers to incorporate fixes for these issues.
-
The disabled-by-default experimental support for capturing CPU and Wall-time spent doing Garbage Collection can cause a lot of overhead in Ruby applications with high object allocation rates. We will be fixing this soon!
- Using an environment variable by setting
-
redis
5 instrumentation upgrade notes
redis
5 instrumentation upgrade notes
dd-trace-rb officially supports redis
5 instrumentation. When upgrading redis
gem to 5.x and with configuration per instance, change your code by passing {custom: datadog: { … }}
tags during redis instantiation.
Before redis 5
customer_cache = Redis.new
invoice_cache = Redis.new
Datadog.configure_onto(customer_cache, service_name: 'customer-cache')
Datadog.configure_onto(invoice_cache, service_name: 'invoice-cache')
customer_cache.get(...)
invoice_cache.get(...)
After upgrading to redis 5.x
customer_cache = Redis.new(custom: { datadog: { service_name: 'custom-cache' } })
invoice_cache = Redis.new(custom: { datadog: { service_name: 'invoice-cache' } })
customer_cache.get(...)
invoice_cache.get(...)
More improvements
Added
- Core: Profiling: [PROF-6559] Mark Ruby CPU Profiling 2.0 as being in beta (#2489)
- Tracing: Attempt to parse future version of TraceContext (#2473)
- Tracing: Add DD_TRACE_PROPAGATION_STYLE option (#2466)
- Integrations: Tracing: SQL comment propagation full mode with traceparent (#2464)
- Integrations: Tracing: Wire W3C propagator to HTTP & gRPC propagation (#2458)
- Integrations: Tracing: Auto-instrumentation with service_name from environmental variable (#2455)
- Core: Integrations: Tracing: Deprecation notice for B3 propagation configuration (#2454)
- Tracing: Add W3C Trace Context propagator (#2451)
- Integrations: Tracing: Redis 5 Instrumentation (#2428)
Changed
- Tracing: Changes
error.msg
toerror.message
for UNC (#2469) - Tracing: Semicolons not allowed in 'origin' (#2461)
- Core: Dev/refactor: Tracing: Dev/internal: Move Utils#next_id and constants to Tracing::Utils (#2463)
- Core: Dev/refactor: Tracing: Dev/internal: Move Tracing config settings from Core to Tracing (#2459)
- Core: Dev/refactor: Tracing: Dev/internal: Move Tracing diagnostic code from Core to Tracing (#2453)
Fixed
- Integrations: Tracing: Improve redis integration patching (#2470)
- Tracing: Extra testing from W3C spec (#2460)
Read the full changeset and the release milestone.
1.7.0
Added
- Integrations: Support que 2 (#2382) (@danhodge)
- Tracing: Unified tagging
span.kind
asserver
andclient
(#2365) - Tracing: Adds
span.kind
tag forkafka
,sidekiq
,racecar
,que
,shoryuken
,sneakers
, andresque
(#2420, #2419, #2413, #2394) - Tracing: Adds
span.kind
with valuesproducer
andconsumer
fordelayed_job
(#2393) - Tracing: Adds
span.kind
asclient
forredis
(#2392) - Appsec: Pass HTTP client IP to WAF (#2316)
- Unified tagging
process_id
(#2276)
Changed
- Allow
debase-ruby_core_source
0.10.18 to be used (#2435) - Update AppSec ruleset to v1.4.2 (#2390)
- Refactored clearing of profile data after Ruby app forks (#2362, #2367)
- Tracing: Move distributed propagation to Contrib (#2352)
Fixed
- Fix ddtrace installation issue when users have CI=true (#2378)
Read the full changeset and the release milestone.
1.6.1
Changed
- Limit
redis
version support to less than 5
Fixed
- [redis]: Fix frozen input for
Redis.new(...)
Read the full changeset and the release milestone.