Always-On PurePath vs Selective Filtering: Visibility Trade-off for Concurrent Latency

Latency that emerges only when multiple requests execute simultaneously is difficult to isolate in Dynatrace because the evidence required to expose lock contention, thread waits, or downstream serialization lives at the individual request level, while the initial symptom is usually visible only in aggregated service metrics. PurePath tracing provides that request-level path, but enabling broad always-on capture for every concurrent transaction increases storage volume and may introduce OneAgent overhead under high concurrency. Conversely, narrowing capture through attribute or error filters reduces that overhead, yet it risks excluding the exact request that exhibits the concurrency-specific delay.

The unresolved decision is whether to prioritize breadth or selectivity before the latency spike is reproduced. Service-level topology can reveal cascading delays between services under load, but it does not inherently separate resource saturation from application-level concurrency defects, and aggregate response-time percentiles alone cannot prove which concurrent interaction caused the slowdown. Because OneAgent capture limits and overhead thresholds vary by version and host, the safe configuration for one environment may be unsafe in another.

Which documented approach offers the better trade-off for this constraint: broad always-on PurePath capture or selective attribute-based filtering? How should teams validate that the chosen capture policy preserves visibility of rare concurrent requests without introducing agent-induced latency?