Take the OpenTelemetry Challenge! ‌🔭‌

[Michal_Gebacki]

Welcome back, Dynatrace Community!

We're happy to kick off the very first Community Challenge of 2026 with a theme that could be heavily familiar for many or the Dynatrace customers. As many of you know, OpenTelemetry, also referred to as OTel, is an open-source framework of tools, APIs, and SDKs that helps to understand software performance and behavior. 

Today we would like you to share with us how did you start OpenTelemetry contribution. Do you have some interesting use cases? Or maybe insightful details of beginnings with being part of the OTel community? Don't hesitate to feature any details as they could be excitingly valuable for others who just like you have just began their OpenTelemetry journey and seek for inspiration, or they're about to do so 👀

Benefits of taking Community Challenges!

👉 Every participant receives a unique "OTel Contributor Badge"

👉 You will also get +100 bonus points for extra activity

👉 Engage with others and have fun!

[AntonPineiro]

Hi,

We are not using OTel yet, but I am interested about this topic.

Best regards

[m3tomlins]

For me, I am a life-long tester - so helping to test early otel collector versions has been great. I use it here in my home lab with the jmeter/k6+influxdb+grafana+rundeck "DIY load testing rig" - mostly regression testing compatibility with thinks like @HenrikRexed's k6 extension or now the native k6-otel capabilities.

One thing to always tell people: you can contribute to open source projects, even if you aren't coding. You can test performance of the components (compare version A to new version B) or even just contribute to documentation for the projects. One new project you see from @Christoph_Neum is the dtcl (https://github.com/dynatrace-oss/dtctl)!

[t_pawlak]

Hi,
My OpenTelemetry journey started in a very practical way — I needed a simple method to collect metrics and logs in places where using native Dynatrace agents wasn’t always possible. OTel quickly proved to be a flexible and lightweight solution that allowed me to send data without heavy changes to the applications.

[Patrick_H]

I had some contact points with OTel - different product ideas we evaluated within Dynatrace in RUM area that were not (or not yet 🤷🏻‍) brought to life, so can't spill the beans here...
But what also has some OTel context in my work is the new request frontent-backend linking in RUM that will be W3C TraceContext based which is compatible to OTel and no longer uses our proprietary X-dyntrace header.

[Julius_Loman]

OpenTelemetry is beginning to resonate with our customers. My experience started already a couple of years back (probably 2021) with initial experiments for extending trace data. Both OpenTelemetry and Dynatrace made a long journey since then.

Most of my experience comes from practical experience on how to properly ingest OTEL data to Dynatrace for existing customers or how to fill the tracing gaps with OneAgents when Dynatrace lacks support for particular technology. The most common cases are API gateways (Gravitee, AXWAY, WSO2, krakend).

Some of the lessons learned are shared here in the community, for example, Gravitee. Axway has a "community" support, I recently forked to improve the OTEL support, mostly to align to OTEL semantics so that the data can be easily processed in Dynatrace.  (no PR yet, it is undergoing testing), @Michal_Gebacki is this a contribution? 😀

Also, kudos to Dynatrace for the recent OTEL - related improvement with SDv2. This starts to make things much easier. OTEL is a continuous journey of learning and improvement.

[DanielS]

In 2022, I began working on sending OpenTelemetry (OTel) data from MuleSoft to Dynatrace in order to introduce trace data.

[ftmazzone]

We began using OpenTelemetry in 2023 to monitor Ruby application as it was not possible to auto-instrument the applications. Now we use it too for sending custom metrics and traces to Dynatrace.
We did not have much issues except with converting Prometheus metrics to Dynatrace metrics as not all formats were supported. Following the costs/permissions for each metrics is also a challenge as you need to have the right dimensions.

[medd]

Last summer dynatrace managed did not support node 24, we used Opentelemetry to get metrics

[AntonioSousa]

Started looking carefully into OTel in 2020. At the time, I had the privilege to start working with @pdeodato

Since then, we (and our clients) have implemented some particularly interesting use cases. In reality, you can use OTel (traces) in use cases that are not immediately associated with OTel.

Will try to get authorization to post here some interesting example 🙂

[AntonioSousa]

One interesting use case about OTel traces is completely unrelated to the usual distributed tracing.
In this case, it's the representation of a traceroute. For each hop, a span:

Please notice they are out-of-order, but that's related to how Dynatrace orders spans...

[Julius_Loman]

Seems you only set trace-id. Can't you set the parent ID too when you generate your spans? This will ensure proper ordering.

[AntonioSousa]

Good idea. Will have to try it!
Hops are independent of each other, and due to how traceroute works (good link here), values can get messy. For the above example, I edited the image to show how it should be represented, and as can be seen, traceroute hops are really not like normal service invocations 🤣

[Malaik]

Yes
We impleneted an Opentelemetry with one of the most important application in the bank.

But honestly, need to spend more time to know how it works exactly.

Regards,

[Mike_L]

Most recently I've been in discussions on how to merge data from OTel with extension assets, which is an interesting topic. Before that my team contributed the official netflow receiver to OTel, which was a long journey with a successful result.

[Kenny_Gillette]

Just getting into this while support a client of mine.  Definitely still learning on what can be done.

[SG88]

Not really an OTel contribution as such, but an extension of an existing tool in order to allow GitHub actions to be sent as traces to a few more destinations compared to the original action it's based on:

https://github.com/marketplace/actions/otlp-githubaction-exporter

We're starting to use OTel more, now we can't install the agent on our new website platform, so hoping to figure out some useful tweaks for getting the data into dynatrace and using it.

Next target is going to be setting up front end instrumentation, followed by figuring out how to make the external calls show up as separate services in dynatrace......so we can then tag them with ownership data and link them to alerting profiles.

[gopher]

I've been looking and using OTEL for a good couple of years.  it is slowly moving from infancy into maturity.  I still think it's somewhere in it's teens, but almost getting there. 

You need to remember that it is just a mechanism to extract data from your platform, in itself it is not a solution. 

Mostly I have been using it for vendor agnostic capabilities around tracing, logging and metrics.
creating a Telemetry as a Service solution.  The goal here is remove vendor lock in and put vendors on a level playing field.   Whichever vendor can best use, present and analyse the data wins.    

Being able to switch vendors at a whim, puts them on the same playing field and forces them to back up what the sales teams are shoveling. 

OTEL collectors are moving Infront of where the active gates are and their capabilities, so wouldn't be surprised if this is the way forward for Dynatrace as well. 

[PacoPorro]

My initial motivation to work with OpenTelemetry came from the need to instrument an API Manager from WSO2. At that stage, traces where not connected: I needed a reliable way to stich the traces from WSO2 .

To accelerate this, I based my implementation on the work already done by our teammate Thomas, who had created an integration for the WSO2 API Manager with Dynatrace: 👉 https://github.com/tbrandl-dynatrace/wso2-apimanager-dynatrace
At that time, traces in the Otel traces project was OpenTracing