This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Make OneAgent feature overrides resilient to Process Group re-detection by supporting stable targeting (service / entity selector / tags) and automatic inheritance to newly detected Process Groups
Summary
Today, OneAgent (OA) feature overrides are configured at the Process Group / service process group level. In dynamic environments (e.g., ECS), Process Groups can be newly detected / re-created due to normal lifecycle changes (task replacement, image update, metadata changes, detection shifts). When this happens, the existing OA feature override does not carry over to the newly detected Process Group. For certain .NET on Linux workloads (method hotspot-related features), losing that override causes the service to be reported unhealthy, which creates a high operational and production risk.
We need Dynatrace to provide a way to target OA feature overrides using stable selectors (service, tags, entity selectors, Kubernetes/ECS attributes, etc.) so that overrides automatically apply to new Process Groups that represent the same logical application.
Problem Statement
We are required to disable specific OA features (e.g., .NET Async Method Hotspots, Capture background CPU method hotspot information, Capture method hotspot information in PurePaths) to maintain correct monitoring/health behavior for some.NET workloads on Linux (Dynatrace documents limitations around method hotspots on Linux for.NET).
Overrides are currently applied at Process Group scope.
When Dynatrace detects a new Process Group for the same application, overrides do not inherit → the application becomes unhealthy (monitoring/health regression) until a human re-applies the override.
Business / Production Impact
Production instability risk: a normal redeploy/scale event can silently remove the needed override.
Operational toil: recurring manual reconfiguration after process group churn.
Monitoring correctness risk: health signals become unreliable, potentially triggering false alerts and/or masking real issues.
Audit/change risk: repeated manual changes increase the likelihood of misconfiguration.
Affected Use Case (Example)
Tech stack: .NET, Linux, ECS deployment model
Two applications require OA feature overrides to avoid health regressions:
Tavisca.Proxy.Api
Tavisca.Configuration.SyncBot.Web
When override is absent → service reported unhealthy.
Current Workaround (Not Sufficient)
Configure OA feature overrides at the Process Group level.
Reapply manually whenever a new Process Group is detected.
This is not reliable in production and does not scale.
