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.