APM Tools
debt(d7/e3/b5/t4)
Closest to 'only careful code review or runtime testing' (d7). The absence of APM tooling is not something a compiler, linter, or SAST tool catches. The detection_hints list tools like Datadog, New Relic, Dynatrace, Tideways, and Blackfire, but these are the APM tools themselves — they don't detect their own absence. The code_pattern notes 'No APM agent or distributed tracing; performance issues investigated only with logs; no request-level visibility,' which is a gap discovered only through operational review or when production performance issues surface. Automated detection is explicitly marked 'no.'
Closest to 'simple parameterised fix' (e3). The quick_fix states 'Install Datadog or New Relic APM agent for immediate visibility — zero code change required,' which suggests an e1 for the initial install. However, common_mistakes reveal that proper APM usage requires adding custom span names, deployment markers, distributed tracing configuration, and staging environment setup — these collectively push effort to a small but multi-step configuration task across environments, landing at e3.
Closest to 'persistent productivity tax' (b5). APM tooling applies across web and CLI contexts (per applies_to) and touches observability across the entire application lifecycle. Once adopted, it shapes how teams investigate performance, how deployments are tracked, and how distributed services are correlated. The tags (observability, performance, devops) indicate cross-cutting concern. It's not quite b7 (it doesn't shape every code change), but it does impose an ongoing operational tax: agents must be maintained, spans configured, dashboards built, and costs managed across all environments.
Closest to 'minor surprise' (t3), +1 to t4. The misconception states 'APM tools are only for large applications,' which is a moderate but not catastrophic misunderstanding — many competent developers skip APM for smaller apps, missing significant value. The common_mistakes (production-only usage, ignoring distributed tracing, not setting custom spans, no deployment markers) represent gotchas that experienced developers eventually learn but aren't immediately obvious. This goes slightly beyond a single edge case but doesn't contradict how similar tools work elsewhere.
Also Known As
TL;DR
Explanation
APM (Application Performance Monitoring) instruments PHP applications automatically or with minimal code. Features: distributed tracing (track a request across services), flame graphs (visualise which code paths consume time), database query analysis (identify slow queries), error tracking with stack traces, deployment correlation (did this deploy cause a performance regression?), and anomaly detection. PHP agents: Datadog (ddtrace extension), New Relic (newrelic extension), Elastic APM (elastic/apm-agent-php). All use out-of-process agents — minimal PHP overhead. Key metrics: Apdex score, p95/p99 response times, error rate, throughput.
Common Misconception
Why It Matters
Common Mistakes
- APM in production only — run APM in staging to catch regressions before they reach users.
- Ignoring distributed tracing — APM is most valuable when tracing spans across multiple services.
- Not setting custom span names — auto-instrumented spans may be too generic to diagnose issues.
- No deployment markers — APM is useless for regression analysis without knowing when deploys happened.
Code Examples
// No APM — performance investigation is guesswork:
// Users report: site is slow
// Investigation: add echo microtime() throughout code
// Test in staging: different results from production
// Hours later: found slow query by trial and error
// Fix deployed: no confirmation it helped (no baseline metrics)// Datadog APM — automatic instrumentation:
// Install: composer require datadog/dd-trace
// php.ini: extension=ddtrace.so
// Custom span for business context:
use DDTrace\GlobalTracer;
$span = GlobalTracer::get()->startSpan('checkout.calculate-tax');
$span->setTag('order.id', $orderId);
try {
$result = $this->taxCalculator->calculate($order);
} finally {
$span->finish();
}
// Result: flame graph shows checkout.calculate-tax taking 400ms
// Drill down: external API call to tax service is the bottleneck
// Fix: cache tax rates, response time drops to 40ms