dd-trace-rb VS tracetest

This action starts two Ruby on Rails APIs, one instrumented with ddtrace and another with OpenTelemetry SDK, both connecting to an OpenTelemetry Collector that sends data to Jaeger:

Thing is, once you have 1) and 2), the added complexity of bringing in, integrating, and writing for a different tool to achieve 3) begins to make little sense, when you can just go along and do it just as well in rspec anyway... It's a matter of balance and heavily depends on the project.

> if you're still at Datadog

As a matter of fact I am. Feel free to shoot me an email.

    curl -s https://github.com/DataDog/dd-trace-rb/commit/176c642ca73679cabc5fa1a113bc9b600aa04dcd.patch | grep '^From:'

> For myself, I'm fine with the typing being in a separate .rbs file

We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].

[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig

[1]: https://github.com/tpope/vim-projectionist

Thanks! I'll pass it on to the team :D

I've got to say, the folks at Intercom made it particularly fun. They were sending us traces and graphs from their internal systems when we trying to figure out some issues with them (e.g. we ran into this datadog context problem: https://github.com/DataDog/dd-trace-rb/issues/1389)

The example sources used in this article and setup instructions are available in the Tracetest GitHub repository.

View the full sample code for the observability stack you'll build, here.

For this article, I’ll show a simplified version of the code, to show how we can trigger an LLM task, expose it via API and then instrument it. You can see the complete source code, here.

Last, but not least, do you want to learn more about Tracetest and what it brings to the table? Check the docs and try it out by signing up today!

Each one of these APIs has their code specified inside our source code on GitHub (here) inside the services folder. You can run them together using Docker Compose along with a Tracetest Agent, which we will use to test these services with the following command:

See the full code for the example app you’ll build in the GitHub repo, here.

To avoid asking the PaymentReceiverAPIfor notifications, you model two endpoints: ReceivePayment to receive payments and NotifyPayment to emit these notifications. You can specify it with the following protobuf file (full example here):

Check out this example in a code sample, here on GitHub. There’s a runnable sample app you can start with Docker Compose to see it for yourself. Here’s what the trace will look like without the noisy fs and net events.

The example sources used in this article and setup instructions are available in the Tracetest GitHub repository.

Code Example