5 Application Performance Monitoring Tools and How to Choose One

01

‘The portal is slow’ is not enough to fix it

A customer reports that the portal has become slow since the latest release. The development team opens it and everything looks normal. The server is running, the average response time appears reasonable and nobody can reproduce the problem on demand.

Later, the pattern becomes clearer. Only customers with large case histories are affected. Opening one page triggers a chain of requests, one application service calls another, and a database query repeats for every item in the case. The average hides it because most accounts remain fast.

This is the job of application performance monitoring. It connects the experience somebody had with the request, code path, database work and external services that produced it. A useful investigation should answer who was affected, what became slow, when it changed and which team owns the next action.

The original Raygun roundup that prompted this article was published in 2017 and updated in 2019. The need it described is still real, but the market has moved. Error tracking, real user monitoring, distributed tracing, infrastructure data and profiling now overlap across products. Choosing by an old feature list is likely to create a large bill and a small amount of clarity.

02

APM is more than an uptime check

An uptime monitor can tell you that a page failed to respond. A synthetic test can check whether a planned journey still works from a chosen location. Logs can record individual events. Those are useful signals, but none automatically explains a slow request moving through several services.

OpenTelemetry describes observability through signals such as traces, metrics and logs. A trace follows a request through the system. Each span records one unit of work inside that journey. Metrics summarise behaviour over time, while logs preserve individual events and context. OpenTelemetry provides a vendor neutral way to generate, collect and export those signals, but it is not the system used to store, search and interpret them.

Modern APM products often combine several related capabilities. Real user monitoring shows what happened in a visitor's browser. Error tracking groups exceptions. Distributed tracing follows work across services. Profiling helps reveal where code spends its time. Release markers connect a regression to a deployment. The product names vary, so start with the investigation your team needs to perform rather than the label on the licence.

03

Start with the question the team must answer

The same application can look healthy in one chart and feel painful to the people using it. Averages are particularly good at hiding a slow minority. A page that normally responds in 200 milliseconds but takes eight seconds for one important customer deserves attention even if the overall average barely moves.

Percentiles are more useful for this kind of work. The 95th percentile shows a response time that 95 per cent of requests meet or beat. It exposes the slower edge of normal use without allowing one extreme outlier to dominate the measure. Error rate, throughput and resource use add context, but the service target should still connect to something a customer or member of staff experiences.

The table below turns common complaints into signals a monitoring setup should make visible. It is a better starting point than comparing hundreds of product checkboxes.

04

Five tools worth comparing

The five products below are not a league table. Each can support serious monitoring, but each enters the problem from a slightly different direction. The sensible shortlist depends on the application stack, the systems already in use and the people who will investigate an incident.

Capabilities also change quickly. Treat this comparison as a way to narrow the field, then verify runtime support, data retention, hosting regions, security controls and current pricing with the supplier before committing.

05

1. Raygun connects the affected user to the slow code path

Raygun combines real user monitoring, crash reporting and server side APM. Its current APM documentation includes Apdex scores, percentile response times, request throughput, slow traces, database queries and rules that can highlight patterns such as N plus one queries or an overused API.

That combination suits a team that wants to start with the customer experience and move towards the technical cause. A front end slowdown can be viewed alongside an application trace or error rather than living in an unrelated product.

The important check is runtime support. Raygun's current APM compatibility list is more focused than some wider observability platforms. Confirm that the application language and hosting model are supported before treating the joined experience as a deciding advantage.

06

2. Sentry is strong when errors lead the investigation

Sentry is familiar to many development teams as an error tracking product. Its current trace view connects transactions and spans with issues, profiles and web vitals, while its application metrics add another way to investigate behaviour around a release or incident.

It can be a natural step for a team already using Sentry because the error, release and ownership workflow may already be part of development. Instead of introducing an entirely separate incident tool, the team can extend what it captures and follow an issue into the surrounding trace.

Do not assume that an existing error tracking setup automatically provides complete application monitoring. Check the instrumentation, sampling, retention and plan features needed for the journeys you care about. An error tool only sees what the application sends to it.

07

3. Datadog suits broad and distributed environments

Datadog APM provides distributed tracing and service level views, then connects those traces with infrastructure, logs, database monitoring, real user monitoring, synthetic tests and profiling. That breadth can be valuable when one customer action crosses several services owned by different teams.

The platform also gives teams control over trace ingestion and retention. That is important because a busy distributed system can generate an enormous number of spans. Keeping everything forever is rarely necessary, but sampling without a plan can remove the exact rare failure an engineer needs to inspect.

Datadog is strongest when the organisation will use the joined operational picture. For a smaller application with one development team, the breadth can create more configuration, governance and cost work than the incident really requires.

08

4. New Relic offers a wide route into observability

New Relic's current platform brings together APM agents, transaction traces, database analysis, errors, browser monitoring, infrastructure, logs, dashboards and alerts. It also accepts OpenTelemetry data, which can reduce dependence on one proprietary instrumentation route.

That makes it useful for a mixed estate where several languages and hosting environments need one place for investigation. A team can begin with one important application, then connect the browser, supporting services and infrastructure as the monitoring question expands.

Breadth still needs boundaries. Decide who owns each service, which alerts deserve attention and how long different telemetry should be retained. A large observability platform does not make an unclear operating model clearer by itself.

09

5. Azure Application Insights fits an Azure operating model

Application Insights is the APM capability within Azure Monitor. It provides an application map, live metrics, transaction search, availability checks, failure analysis, performance views, queries, alerts and dashboards. For a business already operating applications in Azure, that can reduce the number of separate platforms the team has to govern.

Microsoft recommends its Azure Monitor OpenTelemetry distribution for supported server side scenarios. Current documentation covers .NET, Java, Node.js and Python, while browser monitoring continues to use a JavaScript SDK rather than OpenTelemetry.

The Azure connection is an advantage when deployments, infrastructure, access and monitoring already live there. It is less persuasive if the application estate is deliberately spread across several clouds and the team wants one vendor neutral operational view.

10

Instrumentation is the decision that lasts longest

The monitoring product may change before the application does. That is why instrumentation deserves as much attention as the dashboard. OpenTelemetry can provide a vendor neutral route for traces, metrics and logs, allowing the application to describe its behaviour in a consistent format and export those signals to a chosen backend.

Vendor neutral does not mean effortless or perfectly portable. Products add their own agents, queries, issue grouping, service models and user experience data. Some features still require proprietary SDKs. The benefit is a cleaner boundary for the core signals, not a promise that every dashboard can be moved unchanged.

Name services, environments and releases consistently. Add business context carefully, such as the type of workflow being processed, without sending personal data or unrestricted identifiers. Good instrumentation makes a request understandable. Poor instrumentation produces millions of spans called request with no clue which customer action they represent.

11

Control data volume before the first surprise bill

APM data can grow quickly. A single web request may create spans for the application, database, cache, queue and several external services. Multiply that by every request, every customer and every environment and the volume becomes a design concern rather than a purchasing detail.

Sampling keeps a proportion of traces instead of every trace. Head based sampling decides early, while tail based approaches can keep traces after seeing whether they were slow or failed. The exact support depends on the collection pipeline and product. The policy should preserve unusual errors and slow journeys while reducing repetitive healthy traffic.

High cardinality data creates another problem. A field such as service name has a manageable number of values. A customer email address has a new value for almost every person and should not be a monitoring label at all. Review which request bodies, query values, headers and user fields are captured, then redact sensitive data before it leaves the application where possible.

Ask each supplier how ingestion, indexed data, users, hosts, sessions and retention affect the bill. Test with representative production volume. A low entry price is not useful if the first busy month changes the economics of keeping enough evidence to investigate an incident.

12

Run a 30 day proof around one customer journey

Do not begin by instrumenting every application the company owns. Pick one journey that matters, such as opening a large customer case, producing a quote or submitting an order. Define the response time and error rate the business considers acceptable, then record a baseline.

Deploy the monitoring tool with clear environment and release tags. Create a controlled slow query or failed dependency in a safe test environment. Confirm that the team can move from the affected page to the trace, find the slow span, see the database or external call, identify the release and reach the owner without assembling evidence from five different screens.

Then test the alert. It should fire when a customer relevant target is breached, not whenever one harmless request has a wobble. Route it to somebody with the authority and information to respond. If every alert is urgent, the team will eventually treat none of them as urgent.

At the end of the proof, review the investigation time, missing context, false alerts, telemetry volume and likely monthly cost. The winning tool is not the one that collected the most data. It is the one that helped the team explain a real problem and decide what to do next.

Application monitoring should shorten the investigation, not decorate it. If a dashboard cannot connect a customer symptom to an owned technical action, it is another screen to maintain rather than an operational improvement.

If an inherited or business critical application is difficult to observe, I can help assess the code, hosting and operational risks, add focused monitoring and put a controlled support plan around it.