Dynatrace Associate key terms

A lightweight Dynatrace agent installed on hosts that automatically discovers processes and collects metrics, traces, logs, and events, sending them to the Dynatrace cluster without manual configuration.

A real-time dependency map that automatically discovers and visualizes relationships among applications, services, processes, and hosts, providing the topology used for root-cause analysis.

A data lakehouse that stores logs, traces, events, and metrics in a unified schema and is queried with DQL, enabling fast analytics across observability and security data.

Dynatrace Query Language, used to retrieve, filter, and transform data stored in Grail for notebooks, dashboards, and ad-hoc analysis of logs, traces, events, and metrics.

A causal AI engine that correlates anomalies across the discovered topology, groups them into a single problem, and points to the likely root cause to reduce alert noise.

A Davis-generated alert that groups related anomalies sharing a common root cause, showing the affected entities and impact so teams investigate one event rather than many alerts.

A dynamically learned normal range for a metric or response time, calculated from historical behavior and seasonality, used to judge whether current values are unusual.

A logical grouping of monitored entities, for example by team, application, or environment, used to filter data, scope permissions, and route alerts to the right owners.

Attaching key-value metadata to monitored entities, either automatically through rules, hosts, or cloud tags, or manually, so data can be filtered, grouped, and access-scoped.

A saved, shareable filter over Grail data that narrows analysis by entity, attribute, or time, letting teams focus dashboards and queries on a specific subset.

A Dynatrace component that proxies traffic between OneAgents or remote technologies and the cluster, enabling private connectivity, cloud API monitoring, and fewer inbound firewall rules.

A label assigned to one or more hosts that groups them for configuration such as agent settings, alerting, and maintenance, usually reflecting the host's role.

A monitored entity representing a set of logically related request-handling code, such as a microservice or application tier, measured for response time, failure rate, and throughput.

Dynatrace's end-to-end distributed trace that follows one request through services, processes, and tiers, capturing timing and code-level detail for each segment of the path.

A technique that follows a request across multiple services by propagating trace context, showing each hop's timing and helping teams find where latency or errors begin.

A single timed operation inside a trace, such as a database call or remote invocation, with start time, duration, and attributes describing what happened.

Rules that decide how captured requests are grouped into named service endpoints, so metrics and traces aggregate meaningfully instead of by raw URL.

The ability to break request metrics down by dimensions such as request name, geography, or user action, revealing which subset of traffic is causing degradation.

Settings that define what counts as an error for a service, such as HTTP status codes or exceptions, so failure-rate metrics reflect genuine application problems.

An error thrown during code execution that Dynatrace captures with a stack trace and context, helping developers find the exact method and line responsible.

A monitored physical or virtual machine running an operating system, for which Dynatrace reports CPU, memory, disk, network, and process-level metrics.

A logical grouping of identical process instances that run the same executable and arguments across hosts, used for configuration and aggregated monitoring.

One running process on a specific host that belongs to a process group, representing a concrete instance with its own metrics and events.

A packaged plugin that collects metrics and events from technologies Dynatrace does not monitor natively, such as databases or network devices, typically executed by an ActiveGate.

Monitoring of cluster nodes, pods, workloads, and control-plane components, correlating Kubernetes events with application and infrastructure signals to explain impact.

Monitoring of cloud provider resources such as AWS, Azure, or Google Cloud services through API polling, surfacing metrics, configuration changes, and health without agents on those resources.

Collection and analysis of host and application log files in Grail, with parsing and pattern detection that surfaces errors, security events, and operational anomalies.

Capture of actual user interactions in web and mobile applications, measuring page load, user actions, errors, and geography to understand real-world experience.

Scripted or scheduled tests that simulate user traffic from locations worldwide, such as browser clickpaths or HTTP checks, detecting availability and performance problems even without real users.

A meaningful interaction a user performs in an application, such as a page load or click, which Dynatrace measures for duration, errors, and satisfaction.

A recording of a real user's browser session that replays visual interactions and clicks alongside performance and error data, showing what the user actually experienced.

A small script injected into web pages that captures browser-side performance, errors, and user actions, then sends them to Dynatrace for real user monitoring.

Google-defined user experience metrics, including Largest Contentful Paint and Cumulative Layout Shift, that Dynatrace tracks to show how quickly and stably pages render.

A Dynatrace capability that continuously checks running applications and libraries against vulnerability databases, reporting only components that are actually loaded and exploitable.

Runtime attack detection that inspects incoming requests at the application level and alerts on or blocks attacks such as SQL injection and command injection.

An inventory of the open-source and third-party components and versions used by an application, letting Dynatrace map known vulnerabilities to the code actually deployed.

A security weakness in an external library or dependency used by an application, found by matching the deployed component version against vulnerability feeds.

A malicious request detected by runtime protection, recorded with details such as source, target, and attack type, and linked to the vulnerable code path it targeted.

A grouped security finding that aggregates related vulnerabilities or attacks affecting the same entities, with severity and remediation guidance for triage.