What is the future of APM in Go?

Elastic Observability APM
,
1

I have seen the blog post Migrating from Elastic’s Go APM agent to OpenTelemetry Go SDK where they talk about the benefits of migrating to OTel Go SDK.

  • What about the negatives?
  • Does OTel Go SDK support compressed spans, central configuration, etc?
  • Are we going to lose all the benefits that are included with Elastic's Go APM agent?
  • Does Go also going to get EDOT?
2

Martin,

These questions are all very broad, and I'd encourage you to start looking into how OpenTelemetry works, especially since it's quickly becoming an industry standard.

Does Go also going to get EDOT?

Not at this point. We may provide our own instrumentations at some point, but due to the static nature of Go (imports), we won't be providing a distribution for now.

Are we going to lose all the benefits that are included with Elastic's Go APM agent?

No. Most of the things that the Go APM agent currently does are also handled by OpenTelemetry Go.
There are some differences, and things that otel doesn't do, but there are also things it does and we don't.

Does OTel Go SDK support compressed spans, central configuration, etc?

Unfortunately, compressed spans if the missing thing in OTel compared to our own agents at this point. There hasn't been any discussion in OpenTelemetry about a similar feature at the moment. But we are aware of the need.

If by central configuration, you mean the Elastic Agent, that's not really an agent thing. But our agent is in the process of fully supporting OpenTelemetry.
If you mean the environment variables that allow configuring the SDK, yes, OpenTelemetry does that obviously. The variables aren't the same as with our agent though.

What about the negatives?

This is a very broad one to answer, and I've kind of touched it above.
The main fear we're hearing is about our support for OpenTelemetry, and whether we will be able to fix customer issues if they arise.

Our engineering team is committed not only to using and providing OpenTelemetry, but also contributing to it (I am a maintainer of the Go SDK). So we're not just there to benefit from free software. We're investing in it, and helping it evolve the right way.

That takes time, but we believe observability as a whole (not just for elastic) will highly benefit from it.
While we get there, our APM Agent is indeed in "maintenance mode", but it's not going anywhere either. If OpenTelemetry still doesn't work out for you, you can keep using our agent, with or without the provided bridge.

1 Like
3

Thank you for the reply Damien.

I had a look at the OpenTelemetry Go agent and it seems solid just the instrumentation libraries seems a bit all over the place so I would stay with the Elastic Agent for now.

I am aware of the opentelemetry-go-contrib repository and hoping it will get more instrumentations in the future.

What I like the most about Elastic Agent is that it comes with instrumentation libraries out of the box.

The compressed spans are nice to have especially when we have like 100 redis calls in one trace.

By central configuration I meant that I can change some properties of an agent remotely in Kibana (eg. enable,disable recording, exclude urls, etc). Maybe you can create an agent that would listen to those remote changes and would configure the OTel agent on the fly.

I have been using Elastic APM since it was introduced and I like how the Go agent is so simple to use out of the box.