DevOps engineers continuously optimize software delivery, while SRE teams act as the stewards of application reliability, scalability, and top-tier performance. The challenge? These teams require a cutting-edge observability solution, one that encompasses full-stack insights, empowering them to rapidly manage, monitor, and rectify potential disruptions before they culminate into operational challenges.

Observability in our modern distributed software ecosystem goes beyond mere monitoring — it demands limitless data collection, precision in processing, and the correlation of this data into actionable insights. However, the road to achieving this holistic view is paved with obstacles, from navigating version incompatibilities to wrestling with restrictive proprietary code.

Enter OpenTelemetry (OTel), with the following benefits for those who adopt it:

• Escape vendor constraints with OTel, freeing yourself from vendor lock-in and ensuring top-notch observability.
• See the harmony of unified logs, metrics, and traces come together to provide a complete system view.
• Improve your application oversight through richer and enhanced instrumentations.
• Embrace the benefits of backward compatibility to protect your prior instrumentation investments.
• Embark on the OpenTelemetry journey with an easy learning curve, simplifying onboarding and scalability.
• Rely on a proven, future-ready standard to boost your confidence in every investment.

In this blog, we will explore how you can use automatic instrumentation in your Go application using Docker, without the need to refactor any part of your application code. We will use an application called Elastiflix, which helps highlight auto-instrumentation in a simple way.

Application, prerequisites, and config

The application that we use for this blog is called Elastiflix, a movie-streaming application. It consists of several micro-services written in .NET, NodeJS, Go, and Python.

Before we instrument our sample application, we will first need to understand how Elastic can receive the telemetry data.

All of Elastic Observability’s APM capabilities are available with OTel data. Some of these include:

• Service maps
• Service details (latency, throughput, failed transactions)
• Dependencies between services, distributed tracing
• Transactions (traces)
• Machine learning (ML) correlations
• Log correlation

In addition to Elastic’s APM and a unified view of the telemetry data, you will also be able to use Elastic’s powerful machine learning capabilities to reduce the analysis, and alerting to help reduce MTTR.

Prerequisites

• An Elastic Cloud account — sign up now.
• A clone of the Elastiflix demo application, or your own Go application
• Basic understanding of Docker — potentially install Docker Desktop
• Basic understanding of Go

View the example source code

The full source code, including the Dockerfile used in this blog, can be found on GitHub.

The following steps will show you how to instrument this application and run it on the command line or in Docker. If you are interested in a more complete OTel example, take a look at the docker-compose file here, which will bring up the full project.

Step-by-step guide

Step 0. Log in to your Elastic Cloud account

This blog assumes you have an Elastic Cloud account — if not, follow the instructions to get started on Elastic Cloud.

Step 1. Run the Docker Image with auto-instrumentation

We are going to use automatic instrumentation with the Go service from the Elastiflix demo application.

We will be using the following service from Elastiflix:

Elastiflix/go-favorite

Per the OpenTelemetry Automatic Instrumentation for Go documentation, you will configure the application to be auto-instrumented using docker-compose.

As specified in the OTEL Go documentation, we will use environment variables and pass in the configuration values to enable it to connect with Elastic Observability’s APM server.

Because Elastic accepts OTLP natively, we just need to provide the Endpoint and authentication where the OTEL Exporter needs to send the data, as well as some other environment variables.

Getting Elastic Cloud variables You can copy the endpoints and token from Kibana under the path /app/apm/onboarding?agent=openTelemetry.

You will need to copy the following environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS

Update the docker-compose.yml file at the top of the Elastiflix repository, adding a go-auto service and updating the favorite-go one:

  favorite-go:
    build: go-favorite/.
    image: docker.elastic.co/demos/workshop/observability/elastiflix-go-favorite:${ELASTIC_VERSION}-${BUILD_NUMBER}
    depends_on:
      - redis
    networks:
      - app-network
    ports:
      - "5001:5000"
    environment:
      - REDIS_HOST=redis
      - TOGGLE_SERVICE_DELAY=${TOGGLE_SERVICE_DELAY:-0}
      - TOGGLE_CANARY_DELAY=${TOGGLE_CANARY_DELAY:-0}
      - TOGGLE_CANARY_FAILURE=${TOGGLE_CANARY_FAILURE:-0}
    volumes:
      - favorite-go:/app
  go-auto:
    image: otel/autoinstrumentation-go
    privileged: true
    pid: "host"
    networks:
      - app-network
    environment:
      OTEL_EXPORTER_OTLP_ENDPOINT: "REPLACE WITH OTEL_EXPORTER_OTLP_ENDPOINT"
      OTEL_EXPORTER_OTLP_HEADERS: "REPLACE WITH OTEL_EXPORTER_OTLP_HEADERS"
      OTEL_GO_AUTO_TARGET_EXE: "/app/main"
      OTEL_SERVICE_NAME: "go-favorite"
      OTEL_PROPAGATORS: "tracecontext,baggage"
    volumes:
      - favorite-go:/app
      - /proc:/host/proc

And, at the bottom of the file:

volumes:
  favorite-go:
networks:
  app-network:
    driver: bridge

Finally, in the configuration for the main node app, you will want to tell Elastiflix to call the Go favorites app by replacing the line:

environment:
  - API_ENDPOINT_FAVORITES=favorite-java:5000

with:

environment:
  - API_ENDPOINT_FAVORITES=favorite-go:5000

Step 3: Explore traces and logs in Elastic APM

Once you have this up and running, you can ping the endpoint for your instrumented service (in our case, this is /favorites), and you should see the app appear in Elastic APM, as shown below:

It will begin by tracking throughput and latency critical metrics for SREs to pay attention to.

Digging in, we can see an overview of all our Transactions.

And look at specific transactions:

This gives you complete visibility across metrics, and traces!

Summary

With this Dockerfile, you've transformed your simple Go application into one that's automatically instrumented with OpenTelemetry. This will aid greatly in understanding application performance, tracing errors, and gaining insights into how users interact with your software.

Remember, observability is a crucial aspect of modern application development, especially in distributed systems. With tools like OpenTelemetry, understanding complex systems becomes a tad bit easier.

In this blog, we discussed the following:

• How to auto-instrument Go with OpenTelemetry.
• Using standard commands in a Docker file, auto-instrumentation was done efficiently and without adding code in multiple places enabling manageability.
• Using OpenTelemetry and its support for multiple languages, DevOps and SRE teams can auto-instrument their applications with ease gaining immediate insights into the health of the entire application stack and reduce mean time to resolution (MTTR).

Since Elastic can support a mix of methods for ingesting data, whether it be using auto-instrumentation of open-source OpenTelemetry or manual instrumentation with its native APM agents, you can plan your migration to OTel by focusing on a few applications first and then using OpenTelemety across your applications later on in a manner that best fits your business needs.

Developer resources:

• Elastiflix application, a guide to instrument different languages with OpenTelemetry
• Python: Auto-instrumentation, Manual-instrumentation
• Java: Auto-instrumentation, Manual-instrumentation
• Node.js: Auto-instrumentation, Manual-instrumentation
• .NET: Auto-instrumentation, Manual-instrumentation
• Go: Auto-instrumentation Manual-instrumentation
• Best practices for instrumenting OpenTelemetry

General configuration and use case resources:

• Independence with OpenTelemetry on Elastic
• Modern observability and security on Kubernetes with Elastic and OpenTelemetry
• 3 models for logging with OpenTelemetry and Elastic
• Adding free and open Elastic APM as part of your Elastic Observability deployment
• Capturing custom metrics through OpenTelemetry API in code with Elastic
• Future-proof your observability platform with OpenTelemetry and Elastic
• Elastic Observability: Built for open technologies like Kubernetes, OpenTelemetry, Prometheus, Istio, and more

Don’t have an Elastic Cloud account yet? Sign up for Elastic Cloud and try out the auto-instrumentation capabilities that I discussed above. I would be interested in getting your feedback about your experience in gaining visibility into your application stack with Elastic.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all._

When people think about open source, they often picture lines of code, clever algorithms, or maybe a GitHub repo full of issues and pull requests. What can be harder to see is the human side. The people who quietly keep things moving, who make sure contributions land smoothly and help the community grow in a healthy way. That's the work of a maintainer.

Maintainers are more than just code reviewers. They are the stewards of the SIG's (Special Interest Group) health, direction, and community. They balance technical oversight with mentorship, governance with collaboration, and long-term vision with the day-to-day realities of issues and pull requests.

Open Source mentorship

One of the most rewarding parts of being a maintainer is mentorship. Every open source project depends on new contributors stepping in, learning the ropes, and eventually taking on more responsibility themselves. As maintainers, we’re often the first point of contact for someone who’s never contributed to the project before.

Mentorship can look like many different things. Sometimes it’s as simple as leaving a thoughtful code review that doesn’t just point out what’s wrong, but explains why a change matters. Other times, it’s guiding a contributor through their first issue, helping them understand the project’s structure, or showing them how to run tests locally. And every so often, it means stepping back to give someone room to try, even if they don’t get it right the first time.

The goal isn’t just to fix the immediate bug or land the pull request. It's to help contributors feel confident enough to come back again. A healthy project grows by sharing knowledge, not hoarding it. Mentorship is how maintainers make sure today's first-time contributor can become tomorrow's reviewer, and eventually, the next maintainer.

Setting direction and priorities

Another part of being a maintainer is shaping the project's roadmap. Open source moves fast: there are always new ideas, bug reports, and feature requests. Left unchecked, a project can easily become a grab bag of loosely connected changes. Part of our job as maintainers is to make sure the work stays aligned with the bigger picture.

That means asking questions like:

• Does this feature fit with our long-term goals?
• Is now the right time to tackle it?
• Do we have the capacity to maintain it once it’s merged?

Sometimes the answer is "not yet" or even "no", and it’s on us to communicate that clearly while still encouraging contributions.

Roadmapping isn't about dictating every detail. It's about setting priorities together with the community—listening to feedback, balancing what users need today with where the project should be tomorrow, and making tradeoffs that keep the project sustainable.

The roadmap gives everyone a shared sense of direction. Contributors know where their work fits in, users can see what's coming next, and the project as a whole stays focused instead of scattered.

Special Interest Group meetings

One of the maintainer's roles is also to facilitate the frequent meetings that help their SIG communicate and plan its work.

Facilitating a SIG meeting isn’t about running through an agenda like a checklist. It’s about creating space where everyone feels comfortable speaking up, from long-time contributors to someone joining their very first call. That means keeping discussions focused, making sure quieter voices get heard, and helping the group reach consensus without letting debates drag on forever.

There's also a practical side: preparing the agenda ahead of time, documenting decisions so they’re visible to the wider community, and following up on action items afterward.

In many ways, SIG meetings are where the "community" part of open source really comes to life. As maintainers, our role is to guide the conversation, not control it, making sure the project keeps moving forward while staying open and inclusive.

Challenges

Of course, maintaining isn’t all smooth sailing. One of the hardest parts is balancing the constant flow of contributions with the need to keep the codebase healthy. Every pull request represents someone's time and effort, and it’s important to honor that. Yet, at the same time, not every change fits the project's standards or long-term goals. Saying "no" gracefully is just as important as merging a great contribution.

Maintainers also find themselves balancing priorities that go beyond code. Different contributors, and often the companies backing them, come with their own needs and expectations. One team might want a new feature quickly, another might be focused on stability, while the community as a whole still needs clear direction. Managing those competing priorities, and making decisions that serve the project rather than any single interest, is a constant challenge.

Conflicts are another reality. With so many people involved, it's inevitable that disagreements will happen. Sometimes it's about technical design, sometimes about process, and occasionally about interpersonal dynamics. Part of the maintainer role is helping to navigate those moments: keeping discussions respectful, finding common ground, and making sure decisions are made transparently.

And yet, despite the difficulties, the impact of this work is enormous: when maintainers succeed, the entire community thrives.

The importance and impact of Open Source maintainers

When maintainers do their job well, the effects ripple far beyond the codebase. A well-tended project feels reliable and welcoming—contributors know their work will be reviewed thoughtfully, users trust the software to be stable, and the community grows because people want to come back.

Good project maintenance builds momentum. A contributor who feels supported on their first pull request is more likely to return for a second. Clear roadmaps and consistent standards give people confidence that their effort matters and will fit into the bigger picture. And when conflicts are handled with respect and transparency, it reinforces the culture of trust that makes open source sustainable.

The impact goes deeper than just keeping a project alive. Effective maintainers create the conditions for others to succeed. That's the real legacy of this role: not just code, but a thriving ecosystem and community built around it.

Conclusion

Being a maintainer is challenging work, but it’s also some of the most meaningful. It’s about more than merging code. It's about stewardship, mentorship, and creating a community where people feel empowered to contribute. Every healthy open source project owes its success to the care and commitment of its maintainers.

And while the challenges are real, the rewards are just as tangible: the chance to constantly learn, to collaborate on complex problems, and to connect with people from every corner of the world and every kind of background.

OpenTelemetry's maintainers embody this balance every day, helping the project grow while keeping its community strong.

Elastic is strategically standardizing on OTel for observability and security data collection. Additionally, Elastic is committed to working with the OTel community to become the best data collection infrastructure for the observability ecosystem. Elastic is deepening its relationship with OTel beyond the recent contributions of the Elastic Common Schema (ECS) to OpenTelemetry, invokedynamic in the OTel Java agent, and the upcoming profiling agent donation.

Since Elastic version 7.14, Elastic has supported OTel natively by being able to directly ingest OpenTelemetry protocol (OTLP)-based traces, metrics, and logs.

The Go SDK is a bit different from the other language SDKs, as the Go language inherently lacks the dynamicity that would allow building a distribution that is not a fork.

Nevertheless, the absence of a distribution doesn’t mean you shouldn’t use OTel for data collection from Go applications with the Elastic Stack.

Elastic currently has an APM Go agent, but we recommend switching to the OTel Go SDK. In this post, we cover two ways you can do that migration:

• By replacing all telemetry in your application’s code (a “big bang migration”) and shipping the change

• By splitting the migration into atomic changes, to reduce the risk of regressions

A big bang migration

The simplest way to migrate from our APM Go agent to the OTel SDK may be by removing all telemetry provided by the agent and replacing it all with the new one.

Automatic instrumentation

Most of your instrumentation may be provided automatically, as it is part of the frameworks or libraries you are using.

For example, if you use the Elastic Go agent, you may be using our net/http auto instrumentation module like this:

import (
	"net/http"
	"go.elastic.co/apm/module/apmhttp/v2"
)


func handler(w http.ResponseWriter, req *http.Request) {
	fmt.Fprintf(w, "Hello World!")
}

func main() {
	http.ListenAndServe(
                  ":8080",
                  apmhttp.Wrap(http.HandlerFunc(handler)),
	)
}

With OpenTelemetry, you would use the otelhttp module instead:

import (
	"net/http"
	"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
)


func handler(w http.ResponseWriter, req *http.Request) {
	fmt.Fprintf(w, "Hello World!")
}

func main() {
	http.ListenAndServe(
                  ":8080",
                  otelhttp.NewHandler(http.HandlerFunc(handler), "http"),
	)
}

You should perform this same change for every other module you use from our agent.

Manual instrumentation

Your application may also have manual instrumentations, which consist of creating traces and spans directly within your application code by calling the Elastic APM agent API.

You may be creating transactions and spans like this with Elastic’s APM SDK:

import (
	"go.elastic.co/apm/v2"
)

func main() {
       // Create a transaction, and assign it to the context.
       tx :=  apm.DefaultTracer().StartTransaction("GET /", "request")
       defer tx.End()
       ctx = apm.ContextWithTransaction(ctx, tx)

       // Create a span
       span, ctx := apm.StartSpan(ctx, "span")
       defer span.End()
}

OpenTelemetry uses the same API for both transactions and spans — what Elastic considers “transactions” are just considered spans with no parent in OTel (“root spans”).

So, your instrumentation becomes the following:

import (
	"go.opentelemetry.io/otel/trace"
)

func main() {
	tracer := otel.Tracer("my library")

	// Create a root span.
	// It is assigned to the returned context automatically.
	ctx, span := tracer.Start(ctx, "GET /")
	defer span.End()

	// Create a child span (as the context has a parent).
	ctx, span := tracer.Start(ctx, "span")
	defer span.End()
}

With a big bang migration, you will need to migrate everything before shipping it to production. You cannot split the migration into smaller chunks.

For small applications or ones that only use automatic instrumentation, that constraint may be fine. It allows you to quickly validate the migration and move on.

However, if you are working on a complex set of services, a large application, or one with a lot of manual instrumentation, you probably want to be able to ship code multiple times during the migration instead of all at once.

An atomic migration

An atomic migration would be one where you can ship atomic changes gradually and have your application keep working normally. Then, you are able to pull the final plug only at the end, once you are ready to do so.

To help with atomic migrations, we provide a bridge between our APM Go agent and OpenTelemetry.

This bridge allows you to run both our agent and OTel alongside each other and to have instrumentations with both libraries in the same process with the data being transmitted to the same location and in the same format.

You can configure the OTel bridge with our agent like this:

import (
	"go.elastic.co/apm/v2"
	"go.elastic.co/apm/module/apmotel/v2"

	"go.opentelemetry.io/otel"
)

func main() {
	provider, err := apmotel.NewTracerProvider()
	if err != nil {
		log.Fatal(err)
	}
	otel.SetTracerProvider(provider)
}

Once this configuration is set, every span created by OTel will be transmitted to the Elastic APM agent.

With this bridge, you can make your migration much safer with the following process:

• Add the bridge to your application.

• Switch one instrumentation (automatic or manual) from the agent to OpenTelemetry, as you would have done for the big bang migration above but a single one at a time.

• Remove the bridge and our agent, and configure OpenTelemetry to transmit the data via its SDK.

Each of those steps can be a single change within your application and go to production right away.

If any issue arises during the migration process, you should then be able to see it immediately and fix it before moving on.

Observability benefits from building with OTel

As OTel is quickly becoming an industry standard, and Elastic is committed to making it even better, it can be very beneficial to your engineering teams to migrate to it.

In Go, whether you do this through a big bang migration or using Elastic’s OTel bridge, doing so will allow you to benefit from instrumentations maintained by the global community to make your observability even more effective and to better understand what’s happening within your application.

• Check out our code series on how to instrument with OpenTelemetry
• Go manual instrumentation with OpenTelemetry
• Best practices for instrumenting with OpenTelemetry
• Using AI to analyze OpenTelemetry issues

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.