opentelemetry-examples VS opentelemetry-demo

We focused on the observability ecosystem and took the time to interact with our friends from Lightstep, New Relic, Honeycomb, Dynatrace, Instana, and many more. With that in mind, keep an eye out for more integrations coming to Tracetest!

Lightstep bills itself as a platform for the reliability of cloud-native applications. The people behind Lightstep co-founded OpenTelemetry and OpenTracing, which gives them a unique perspective on the use cases of distributed tracing and the value of having a vendor-neutral tracing data format.

In the last 5 to 10 years, new Observability vendors have entered the market, including Honeycomb, Instana, Lightstep and Datadog. Similarly, traditional APM vendors such as Dynatrace, AppDynamics, and New Relic, as well as SIEM (and log management) vendors such as Splunk and Sumo Logic, have joined them in the Observability space too. Finally you also have major cloud providers such as AWS with their own observability solution. Each of them is attempting to address the observability issues that modern architecture presents by using Logs, Metrics, Traces, and Events.

I spent Day 2 at the Colony Club to attend OTel Unplugged. This event was sponsored by Lightstep, Honeycomb, New Relic, Splunk, Dynatrace, Crowdstrike, and NGINX. I came into the event not knowing what to expect. I can sometimes clamp up when I’m around folks that I don’t know, but because I was helping with the event check-in, I got to say hello to a number of the attendees, which helped break the ice. And it turns out that there were a lot of names that I recognized from my work in the OTel community, and it was nice to connect in person with folks whom I’d only previously met through Slack or Zoom.

The example in this tutorial can be found in the lightstep/opentelemetry-examples repo. We will be working with three main files:

Note how we don’t have to set a LS_ACCESS_TOKEN, since that’s already configured in the Collector’s config.yml file. Just make sure that you have a running OTel Collector instance!

Note: If you’re looking for full code listings, don’t panic! You see them in the Lightstep OTel examples repository.

Here is a typical trace from the OpenTelemetry demo project.

# test suite based on https://github.com/open-telemetry/opentelemetry-demo/tree/main/test/tracetesting/frontend-service type: Test spec: id: frontend-view-cart name: 'Frontend: View cart' description: Simulate a user viewing the shopping cart trigger: type: http httpRequest: url: http://${var:FRONTEND_ADDR}/api/cart?userId=2491f868-88f1-4345-8836-d5d8511a9f83 method: GET headers: - key: Content-Type value: application/json specs: - name: It called the frontend with success selector: span[tracetest.span.type="general" name="Tracetest trigger"] assertions: - attr:tracetest.response.status = 200 - name: It retrieved the cart items correctly selector: span[name="oteldemo.CartService/GetCart"] assertions: - attr:rpc.grpc.status_code = 0

Contributing to the OpenTelemetry Demo is a great way to get involved and showcase your skills in the OpenTelemetry community. It's a real-world example of OpenTelemetry in action, and by actively contributing, you enhance your understanding and improve the project's quality.

Trace-based testing added to OpenTelemetry Demo

Examples and the tutorial in this blog post use the OpenTelemetry Astronomy Shop Demo to show what you can do with OpenTelemetry and New Relic. This application is built and maintained by the OpenTelemetry open-source community, and it provides a real-world example of a distributed application that’s been instrumented with OpenTelemetry. In the Deploying the OpenTelemetry Astronomy Shop demo app section, you’ll have an opportunity to get hands-on experience spinning up your own version of this application. You’ll learn how to:

Take this https://github.com/open-telemetry/opentelemetry-demo

I mean, you really just need experience instrumenting apps and tinkering with them to play with OTEL. https://github.com/open-telemetry/opentelemetry-demo is a good start. You can modify the collector to point to any backend of your choice.

I got to play around with these newer features last December, after a months-long hiatus, and it was really cool to see the evolution of the product. If you follow my work, you’ll know that I play in both the Kubernetes and Nomad worlds. Today, I’ll be taking you on a quick little guided tour of Tracetest, using Traces from the OpenTelemetry Demo App to give you a feel for how it works. The whole setup will be running on HashiCorp Nomad. \

​ By having an observability infrastructure gather information about a set of API/microservices, we can have a concise view of the operation of these services and start thinking in an observability-driven way to test your software. ​ Tracetest can help. When given an API endpoint, Tracetest checks observability traces to see if this API is behaving as intended. ​ For example, let’s try to test an OpenTelemetry Astronomy Store which has the exact same use cases that we want to check. ​ To test the "Add product to the shopping cart" task, we can create a test, define a URL and payload in the trigger section that we send to the Cart API and use the specs to define our assertions, checking if the API was called with the correct Product ID and if this product was persisted correctly. ​

In my latest Nomadification Project (TM), I got the OpenTelemetry Demo App to run on Nomad (with HashiQube, of course). To do this, I used the OpenTelemetry Demo App Helm Chart as my guide. In doing this, and other Nomadifications, I realized that I’ve never gone through the process of explaining the conversion process from Kubernetes manifests to Nomad jobspecs.