Obervability
Services AudiTrace Resources▾ Contact
Book a free audit
Audit domain · 3 checks

Dynatrace topology audit: entity detection quality and entity explosion

Three checks on the entity model — process-group detection rules producing duplicates, service naming that multiplies entities per deployment, and the growth rate of the entity count itself.
Book a free audit All 71 checks

What these checks read

Detection rules

Custom process-group and service detection rules, and where they overlap or contradict the defaults.

Entity growth

How the entity count is moving over time, and which detection rule is driving it.

Naming quality

Names carrying build numbers, pod hashes or timestamps — the signature of an entity created fresh on every deploy.

Why it matters

Entity explosion is a slow failure. Each deploy creates a handful of new entities instead of updating the existing ones, dashboards keep working, and a year later a service has 400 historical versions, Davis has no continuity to reason over, and every query is slower than it should be.
The cause is almost always a detection or naming rule that includes something ephemeral. These checks find the rule rather than the symptom: which rule produced the duplicates, how many entities it has created, and what the naming would be without the ephemeral component.
This is also the domain that most often explains a Davis problem that "came out of nowhere". Root-cause attribution depends on entity continuity; break the continuity and the analysis degrades quietly rather than erroring.

Questions we get about this domain

Is a high entity count always a problem?

No — large estates legitimately have large entity counts. The finding is about growth that a detection rule is manufacturing: entities that represent the same thing before and after a deploy. That distinction is what the check reports.

Can you fix the detection rules for us?

Not as part of the audit, which is read-only by design. Rule changes are an implementation engagement, and they need a change window because they rewrite how history joins up.

The other audit domains

Nineteen domains, 71 checks, one read-only run. Each domain is a page.
FinOps Where the money goes, and what is recoverable Kubernetes Cluster coverage, versions, recurring failures Alerting Whether an incident would actually reach a human Audit log Who changed what, when, and outside business hours Coverage What is monitored, what only looks monitored RUM Real-user monitoring reach and privacy settings Grail Buckets, retention, annualized storage cost Pipelines Ingest processing, masking, drop rules Synthetic Synthetic monitors that pass, fail, or never run Topology Entity detection quality and entity explosion OpenTelemetry OTel sources and dual instrumentation Security Token scopes, expiry, dormant credentials Workflows Automation that fails or never fires Bizevents Business event provider hygiene Dashboards Dashboard inventory Davis Root-cause attribution rate OpenPipeline Route and pipeline resolution SLO SLO definitions that break on re-detection Tagging Environment tagging convention

See what this domain finds on your own tenant.

One read-only run covers all nineteen domains. You keep the report either way.
Book a free audit See how AudiTrace works

Find out what your Obervability is actually doing.

An audit takes one run. The findings take one meeting. What you do with them is up to you.
Certified Dynatrace experts
+1
Send
Obervability
Dynatrace implementation, managed services and support. Every finding comes with the source behind it.
Services
Services AudiTrace Case study
Guides
Dynatrace audit Dynatrace cost optimization Audit case study Articles
Reach us
© 2026 Obervability · All rights reserved.
Privacy Terms of use Accessibility