David Elner

Thanks for the detailed report @adrys-lab! We'll be happy to take a look at this soon. It may be related to one or two other issues already opened on the...

Metric graphs don't tell the whole story here: because they are computed on a very specific set of dimensions (service, span name, etc), it's very possible the traces are still...

Thanks for the detailed graphs and your continued patience on this one. I want to get to the bottom of it. Looking over your configuration again, there's two things I...

@adrys-lab I keep re-reading these graphs/screenshots, but they are stripped of too much context to make any sense of. :/ We need to filter out the noise and create some...

Ran my end-to-end tests locally. Both ddtrace `0.54.2` & `1.3.0` look correct: 100% traces are sent, received, and displayed on the request graph. I have no reason to suspect the...

@zackse > Can you confirm whether your test apps show the expected/matching counts for metrics as well as traces? Yes, the metrics are correct as well. They are derived from...

@adrys-lab >if service or another TAG/service would have change, we would not see the previous traces before the configuration change. I think there is a case where you would, if...

@zackse I took a bit of time to try to recreate this in our `rails-six` integration app (using Faraday), and was able to reproduce the issue. As you said, it...

@adrys-lab No I don't believe so.

Update: after working more closely with @zackse and his team, we think we've found the issue is related to how sampling is applied to Ruby apps on the receiving end...