The OpenTelemetry Demo is an excellent way to show the value of OpenTelemetry (OTel). Tyk has successfully used it internally to demonstrate why it was necessary for the Tyk API Gateway to have instrumentation for OpenTelemetry. To walk you through how to get started with OTel, Juliano Costa, Developer Advocate at Datadog and CNCF Ambassador, has shared his experience below.
In this blog, we cover:
- The signals you can capture with OTel
- What you can do with the OTel Collector – and why
- How to use the OTel Demo to understand the power of OpenTelemetry
Read on for our top takeaways or click the link above to watch the video of Juliano talking through the OTel Demo.
How to use the OpenTelemetry Demo to get started with OTel
You can visit the Tyk Learning Centre for a detailed look at what OpenTelemetry is. In brief, it solves the problem of 10-15 years ago, where organisations relied on a component from a third-party or an open source tool to collect and provide their telemetry data. The vendor or tool would use a proprietary protocol to send the data from your application to their backend. If you wanted to change the vendor or tool, the process was invariably painful.
OpenTelemetry has emerged as the standard to solve this. Now applications can produce data via the OpenTelemtery protocol, which almost all modern vendors support. It means you can instrument your application with OpenTelemetry and simply point it at the vendor of your choice – or use a collector, if you prefer.
This is ideal for anyone doing a proof of concept and evaluating tools. You can simply send the data to three different vendors and analyse what you’re getting from your telemetry data and what value each vendor provides.
Which signals can you capture with OTel?
You can use OTel to capture traces, metrics and logs.
Traces
Traces are requests in your application that do a whole bunch of operations. Grouped together, we call these operations a span. An example is when an ecommerce customer clicks on ‘place order’ and triggers the frontend calling the checkout service, the checkout service calling the cart service and so on.
Traces mean you can see everything that happens from the start of a transaction to the end of it, making error spotting much easier.
Metrics
OpenTelemetry provides metrics in context. Combined with traces, this is really powerful because you can see the state of your application at the time of each transaction. So, if there is an issue, you can see what was going on in the underlying system.
You can use OpenTelemetry to create custom metrics that relate to your business and to your applications – metrics that it wasn’t previously possible to auto-instrument.
Logs
If you’ve ever written a hello world app, you know about logs. They record the date, where things happened, the severity, which service is producing the log and the log itself.
OTel takes logs to the next level by adding context, allowing correlation with trace IDs. This is a gamechanger for rapid troubleshooting.
Profiling
In addition to traces, metrics and logs, profiling is the fourth OTel signal. Work is still underway on this, with the OTel project still growing and adding new signals and new telemetry data.
What is the OTel Collector?
We mentioned using a collector above. The OTel Collector is a vendor-agnostic way of receiving, processing and exporting telemetry data. It allows you to define which type of data you receive. One example of this in action is using a collector to clean up personally identifiable information (PII) and remove sensitive data. Another is creating metrics out of spans before sending the data to your backend – or, using the exporter, to multiple backends. You can also configure the pipelines for traces, metrics and logs and define the formats you want to receive and send metrics in.
How to use the OTel Demo
The OTel Demo has three goals:
- To enable vendors to test their solution on OpenTelemetry
- To onboard new people by demonstrating how OTel works
- To test OpenTelemetry releases (every language has its own release cycle, with every version updated in the demo to see if it breaks anything or produces unexpected changes)
OTel has grown to incorporate 12 different languages so far. It has Kafka, Envoy Proxy in front of it and all the services are instrumented with OpenTelemetry.
The OTel Demo is easy to run. Simply go to the OpenTelemetry Demo in GitHub, clone the repo and run it with Make or Docker. Make start or Docker compose up to start all the services you need to run the OTel Demo.
When you start the project, you get a frontend app that’s reactive, which sends data to Jaegar (traces) and Grafana (metrics and logs – called OTel span events) by default. You can also point your data to Datadog to see all your services, looking at metrics, distributed tracing and more with different views, where you can see correlations happening.
You can also look at the code itself in the OTel Demo. It’s a mono repo with all the services under src. This is where you can look at what you’re doing and how you’re instrumenting it.
Let’s take Java as an example. You can simply fetch the Java agent from the OpenTelemetry releases and be done. It will auto-instrument your libraries and dependencies.
You can then add manual instrumentation, such as adding business attributes to your spans (OTel won’t know what’s important to your specific organisation, so you can build this in after the auto-instrumentation). You can query the attributes you add in Jaeger or Datadog (for instance). It means you can see what’s happening in the code and how that’s landing in the platforms you want to test.
You can also see the OTel Connector in the demo, where you define receivers, exporters, processors, connectors and pipelines. For an easier life, vendors can add their own specificities, with many having already done so – you can see these in the repo and select the one you want.
Another useful resource is the OTel Collector contrib repo, which has all the vendor-specific data and logic you could need.
Key takeaways
With OTel, we finally have a standard for telemetry data; one that’s all about correlation. It’s not just about instrumenting your code and getting the data but letting you experience the real power of your telemetry. If you’re ready to see this for yourself, the OTel Demo is the place to start.
Remember you can also leverage the power of OTel with Tyk Gateway, to enhance your API monitoring with end-to-end tracing.
