tracetest VS community

git clone https://github.com/kubeshop/tracetest.git cd tracetest/examples/tracetest-signoz-pokeshop/ docker compose up --build

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.

Attend SIG meetings to understand ongoing development and decisions. Share what you learn through blogs, demos, or internal talks, and review others' pull requests or mentor newcomers. Contributions that improve usability, documentation, localization, or developer experience have a long-lasting impact even if they are not code-heavy. Community is key.

Okay, but they’re doing it and they have two different implementations they want to converge on. Their proposal https://github.com/open-telemetry/community/blob/main/projec... focuses on instrumentation, they want to scratch their itch.

IMO this boils down how one gets paid to understand or misunderstand something. A telemetry provider/founder is being commoditized by an open specification in which they do not participate in its development -- implied by the post saying the author doesn't know anyone on the spec committee(s). No surprise here.

Of course implementing a spec from the provider point of view can be difficult. And also take a look at all the names of the OTEL community and notice that Sentry is not there: https://github.com/open-telemetry/community/blob/86941073816.... This really isn't news. I'd guess that a Sentry customer should just be able to use the OTEL API and could just configure a proprietary Sentry exporter, for all their compute nodes, if Sentry has some superior way of collecting and managing telemetry.

IMO most library authors do not have to worry about annotation naming or anything like that mentioned in the post. Just use the OTEL API for logs, or use a logging API where there is an OTEL exporter, and whomever is integrating your code will take care of annotating spans. Propagating span IDs is the job of "RPC" libraries, not general code authors. Your URL fetch library should know how to propagate the Span ID provided that it also uses the OTEL API.

It is the same as using something like Docker containers on a serverless platform. You really don't need to know that your code is actually being deployed in Kubernetes. Use the common Docker interface is what matters.

otel is working on their events spec https://github.com/open-telemetry/community/issues/1688

1. Agreed. It's the sink and the house attached to it, and the docs are thin and confusing as a result.

2. I had a similar experience to you. I wanted to implement a simple heartbeat in our app to get an idea of usage numbers. This is surprisingly not possible, which greatly confuses me given the name of the project. The low engagement on my question put me off and I abandoned my OpenTelemetry planning completely. [1][2]

[1] https://github.com/open-telemetry/community/discussions/1598

One of the OpenTelemetry Project's many Special Interest Groups (SIG) is the OpenTelemetry Community Demo SIG which gives support to a set of instrumented backend microservices and a web frontend app that are primarily used to showcase how to instrument a distributed system using OpenTelemetry. The application's main focus is to demonstrate the implementation process to instrument an application no matter what programming language, platform, or operating system your team is using, as well as providing different approaching techniques (automatic and manual instrumentation, metrics, baggage). All of this while following the standards and conventions defined by the official OpenTelemetry Documentation. More about the specific requirements can be found here. At Tracetest, we have always focused on becoming part of and embracing the OpenTelemetry community. One of our goals this summer was to get more involved with a core OpenTelemetry project where we could provide a meaningful contribution. The OTel demo became the best match for achieving that goal as it would not only help the community, but we at Tracetest needed a good example to test and showcase what can be done with our tool. During the version 0.7 project cycle, we created two specific tickets to get us closer to the community and start looking for things to pick up: