Short answer
There is no universal concurrent request count that triggers adaptive sampling on a given CPU core count. In OneAgent 1.239, the onset is not a fixed request threshold; it depends on host cores, per-request cost, thread-pool behavior, GC, agent-side queues, and the sampling defaults for that deployment. A measurable latency spike under high concurrency is more likely instrumentation overhead, agent contention, or a version-specific issue than adaptive sampling itself. Treat sampling as a suspect to isolate, not a confirmed cause.
What is well established
Adaptive sampling is designed to reduce tracing overhead as load rises. It changes what is captured; it should not normally add long blocking delays to application threads. The mechanism is described as driven by thread-contention detection, which means the trigger is a load or contention signal, not a simple request counter. Because defaults and thresholds vary by environment and version, no one can state “X concurrent requests on Y cores” without measurement on that host.
How to find the onset for your host
- Fix the baseline: same application build, same OneAgent version, same host core count, same workload mix. Ramp concurrency in steps and record p50/p95/p99 application latency plus agent CPU and memory.
- Run an A/B test: adaptive sampling enabled vs disabled, or OneAgent detached in staging if that is safe. If the spike disappears only when adaptive sampling is disabled, sampling or instrumentation is implicated. If it disappears only when the agent is detached, general instrumentation is implicated. If it persists, investigate JVM, GC, thread pools, locks, and downstream dependencies.
- Separate application response time from Dynatrace trace ingestion or processing. Agent-side ingestion latency points to different remediation than application thread latency.
- Inspect OneAgent logs and Dynatrace self-monitoring during the spike for sampling decisions, queue saturation, or deferred/dropped data. Correlate spike timing with agent CPU and memory on the host.
- If sampling is implicated, adjust configuration per vendor guidance, update or patch OneAgent, or temporarily exclude high-volume endpoints. Validate with before/after measurements under the same concurrency.
adaptiveSamplingMinInterval
The exact key, default, and semantics for adaptiveSamplingMinInterval cannot be confirmed for OneAgent 1.239 without the version's configuration reference. If your deployment exposes it, it most plausibly controls how often sampling decisions are reevaluated or the minimum interval between them. Changing it shifts latency onset indirectly by changing agent work per request or time window; it does not create a fixed request-count threshold. Verify against your version's documentation and test in staging before changing production.
1.239 vs later releases
Differences in concurrency sensitivity between OneAgent 1.239 and later releases cannot be confirmed from general knowledge. Sampling defaults, thresholds, and defects are release-specific. Check Dynatrace release notes and support knowledge base for 1.239 known issues, and reproduce in staging with the same version and concurrency profile before assuming a regression or a fix.
One missing detail
The detail that changes the next step is whether the spike is measured in application response time or in Dynatrace trace ingestion/processing. If it is application response time, focus on thread contention and agent instrumentation overhead. If it is ingestion or processing latency, focus on agent queues, self-monitoring, and backend ingestion limits.
Do not disable OneAgent in production without change control; you may lose observability during the incident. Correlation does not prove causation, and high concurrency can expose unrelated bottlenecks.
dynatrace