How to choose between APM and an end-to-end monitoring tool

 There was a time when APM was all anyone needed. Older monolithic web services were monitored with application performance monitoring (APM) tools. These tools provide detailed insights into how the web service performs and can alert administrators to potential issues before they become widespread. So APM brought us out of the era of having your users be the first people who noticed a serious problem. Instead, our monitoring tools could tell us trouble was brewing beforehand.

APM tools give insights into key performance indicators such as response time, request volume, error rates, resource utilization, and more. This data can be used to identify problems in code execution, detect memory leaks, or any other issue that may be affecting the web service's performance.

And many teams are still using traditional application monitoring and are very satisfied with the results!

But here are some questions to ask about tools like Scout APM:

1. Are we committed to open standards?

By using open standards, operations engineers can save time and resources by avoiding the need to develop complex proprietary workarounds or bespoke protocols for their systems. Furthermore, open standards provide a well-defined framework within which engineering teams can collaborate on developing better operational processes and systems across multiple organizations or departments within one organization. Standard APM tools transmit data in their own protocols, and the more you have to learn about them the more you're gaining specialized vendor experience rather than open standards. This leads us to the second concern:

2. Are we locked into one vendor?

The recent incident involving DataDog's attempt to quash an OpenTelemetry commit brought up a significant concern about APM vendors. When these vendors claim to 'embrace' open standards, are they really saying we'll consume whatever data you want to send us, you just can't take your data anywhere else.'

These policies remind us a bit of the bad old days of SaaS where removing your data from a CRM or office tool was nearly impossible. How have APM companies gotten away with this for so long? Probably because portability, in this case, isn't really about portability of historical data. Think about it: when migrating monitoring to another service it probably doesn't matter if you bring with you performance data from 2017.

So lock in, in this case, isn't so much about your data being held hostage, and more about the sometimes extreme difficulty of moving to different services.

If you're using an APM tool you really have to agree that you're going to stick with a single tool for a very long time, maybe for years.

3. How monolithic is our architecture?

While APM works well in a monolithic environment, and fine if you have 12 or so different services running, once you go much beyond that you're going to struggle. See 'Your Architecture defines your destiny' later in this piece

4. How much flexibility and customization do you need?

One of the original selling points of APM was a great 'out of the box' experience. When installing Scout APM on a Rails application, you get a great map of your tool within a few hours. But with any APM tool that 'out of the box' experience can start to feel like you're 'boxed in.'

After all, monitoring can do a lot more than finding performance problems. Maybe you'd like to do some security scanning, compliance checks, or gather business intelligence. With a closed source APM tool you'll largely be limited to the uses that the creators of the tool predicted.

With Open Telemetry, most especially with the use of the OpenTelemetry Collector, you can send, format, and view data from your services, no matter what your use case.

Your Architecture defines your destiny

Selecting TelemetryHub (and the underlying OpenTelemetry project that TelemetryHub is built for) is a lot easier if you have a large number of microservices. How many is a large number? By the time you have dozens of microservices, on a multiple of the number of developers on your team, it's time to think about OpenTelemetry.

OpenTelemetryallows us to instrument, monitor, and debug large numbers of microservices in an efficient manner. This is especially important in a distributed system with a large number of services that are communicating with each other. With OpenTelemetry, we can quickly diagnose issues across the services and detect performance bottlenecks. And with TelemetryHub, you can easily view and share the distributed traces that will show you how requests are traveling across your application.

Here's a table of key differences between Scout APM and TelemetryHub

Scout APM	TelemetryHub
Detailed tracing at a rate of 10 per min	Unlimited distributed tracing
Limited to back end monitoring	End to end monitoring (language agnostic) with added insight into your front-end code
Agent instrumentation that covers several of the top backend frameworks	Vendor agnostic, OpenTelemetry projects cover dozens of languages and frameworks
Tail based sampling with probability sampling For efficient, compact footprint data	Advanced filtering that lets you send data you want to see, and filter noise
Error monitoring integrations	Error monitoring consolidation, with all errors standardized with OpenTelemetry
Limited Kubernetes monitoring (only what’s running inside the container	Deep understanding of Kubernetes with the OpenTelemetry K8s project
Custom context is limited, and specific to each agent	Search by custom attributes, and add as many as you like with the OpenTelemetry standards
Links to your log mgmt tool	Correlated Metrics & logs
Developed and maintained by the Scout team you love