APM integrations#
Connect the monitoring you already run, so a load test can be read beside what the application itself was doing.
Which providers#
| Provider | What it reads |
|---|---|
| Dynatrace | Services and their response time, failures and CPU |
| AppDynamics | Business transaction response time, calls and errors |
| Datadog | Service latency, request counts and errors |
| New Relic | Response time, throughput and error rate, queried with NRQL |
| AWS CloudWatch | Metrics for load balancers, instances and services |
| Azure Application Insights | Requests, dependencies, exceptions and counters |
Adding a connection#
APM Tools → Add connection on the provider you use. Each asks only for what it needs — an environment address and a token, a controller and an account, a region and a key pair.
A read-only credential is enough and is what you should use. JMXPress only reads.
What happens to the credential#
- It is sealed with a key held on the server, outside the database row.
- It is never sent back to a browser. The page shows which secrets are set, not their values, so editing a connection never requires the stored credential to be sent out and back.
- It does not appear in logs, reports, generated test plans or any test artefact.
- Leaving a secret box empty when editing means "unchanged".
See Security practices.
Choosing what to watch#
Open a connection's monitoring page.
- What to watch — the service, application or resource.
- Metrics — which of its metrics to chart. Select all takes everything the provider offers for that resource.
- Time range — from five minutes to thirty days, or a custom window. The default is the last hour.
- Auto-refresh — off by default, and bounded below by the provider's own sensible floor.
The charts can be maximised, zoomed into by dragging across them, compared with each other, downloaded as CSV or PNG, and switched between line, area and bar.
Saved dashboards#
Arrange the metrics you want, then Save as… and give it a name.
A saved dashboard can be chosen on the Run page before a test starts, which is what makes a run's monitoring repeatable: the same metrics, for every run of that test.
Monitoring a run#
On the Run page, switch on Collect APM metrics while this test runs and choose the connection, and optionally a saved dashboard.
While the test runs you see the figures live; see Live results. When it finishes, the metrics for the run's own window are collected and stored with it.
The window asked for is slightly wider than the run itself at both ends, because a metric is a bucket and a run that began at 10:00:30 would otherwise lose the bucket it started in.
The run's APM report#
A monitored run keeps its figures. Open the run and choose its APM metrics report to see what the application was doing, charted, for that execution.
A collection can end in one of several states, and the report says which:
| State | What it means |
|---|---|
| Collected | Figures were stored |
| Empty | The provider answered with nothing for that window |
| Failed | The provider could not be read; the reason is shown |
| Abandoned | The collection never finished — JMXPress stopped before the test did |
How long the figures are kept#
Set per installation, in [retention]:
| Setting | Default | |
|---|---|---|
apm_days | 90 | How long collected monitoring is kept |
apm_abandon_hours | 24 | When an unfinished collection is called abandoned |
Both can be set to 0 to keep things indefinitely. A run still in progress is never touched by either.
Careful These figures are the only copy. Providers discard fine-grained data after days, so a report older than your retention window cannot be rebuilt by asking the provider again.