Dynatrace Professional cheat sheet

Davis AI separates deterministic causation (root-cause analysis over the Smartscape topology) from probabilistic prediction (anomaly detection via adaptive baselines), so an AI answer should state which engine produced it.

Davis anomaly detection learns a per-metric baseline that follows daily and weekly seasonality; a violation is a deviation from that baseline, not a fixed threshold breach.

Frequent issue detection groups recurring events into a single problem pattern with a confidence score; low-confidence patterns stay as events rather than becoming problems.

Predictive alerting extrapolates a metric trend to forecast a threshold breach before it occurs; it complements, and does not replace, static alerting profiles.

AIOps answers are explainable by design: each root-cause candidate lists the affected entities, the evidence events, and the Smartscape relationships traversed.

Davis CoPilot is an assistant layer over Grail and Davis; it generates DQL queries and explanations, and its outputs should be validated against the underlying data.

Entity-model context matters: the same metric on a host, a process, and a service is a different timeseries; anomaly detection is scoped per entity and per dimension.

AutomationEngine workflows can act on Davis problems (for example remediation runbooks), turning detection into closed-loop response without human triage for known patterns.

The service is the primary unit of analysis; a service is a logical grouping of process groups that expose the same endpoint, and requests are traced across service boundaries.

PurePath captures a single distributed trace with method-level timing; distributed tracing stitches spans across services and processes into one end-to-end view.

Key metrics per service: response time (with percentile distribution), throughput (requests per minute), failure rate, and the service-level error budget derived from SLOs.

Backend vs. frontend split: backend services are instrumented via OneAgent; frontend (RUM) data arrives from JavaScript beacons and Real User Monitoring.

Multidimensional analysis uses request attributes (for example HTTP method, URI, or custom attributes) to slice response time and failure rate without new instrumentation.

A service-level objective defines a target (for example 99.9% of requests under 500 ms); an error budget is the permitted shortfall, and burn rate measures how fast it is consumed.

Failure detection distinguishes exceptions, HTTP 5xx codes, and timeouts; each has its own rate and is aggregated into the service failure rate.

Smartscape maps the dependency graph (host to process to service to downstream service) so that a downstream degradation can be attributed to an upstream caller.

Runtime vulnerability analytics evaluates third-party libraries actually loaded at runtime, so a vulnerable dependency that is never loaded is not reported as an active risk.

Runtime application protection detects attacks (for example SQL injection, command injection, SSRF) at the process level and can block them in-line without a WAF.

Attack evidence is tied to the exact code location and the request that triggered it, which yields a reproducible trace rather than a signature alert.

Security problems are scored by Davis risk assessment combining vulnerability severity (CVSS), exposure (public vs. internal), and data assets touched.

Software composition analysis covers open-source libraries; the runtime view is authoritative for what is deployed, while the build-time view catches what is not yet running.

Vulnerability lifecycle states (open, resolved, muted) must be managed; muting requires a documented justification and a review date.

Third-party and first-party code are distinguished; first-party vulnerabilities come from custom code and are attributed to the responsible team via ownership metadata.

Attack blocking policies are scoped per process group and per environment, so production can enforce while lower environments only detect.

Business events are ingested as Grail records (bizevents) and can be queried with DQL; they carry a business context (order ID, customer, amount) alongside technical identifiers.

Business events are captured via OneAgent (HTTP capture rules), the ingest API, or OpenPipeline, and are not tied to a single host lifetime.

Business metrics are derived from bizevents by aggregation (for example count of orders per minute, sum of revenue) and can feed SLOs and dashboards.

A business flow links a user journey across services; each step is a business event, and the flow's conversion rate is the fraction of journeys that complete all steps.

Segmenting business metrics by customer tier or region requires that the attribute be present on the event; missing attributes silently drop the segment.

Business observability complements technical SLOs: a service can be technically healthy while a business KPI (for example checkout conversion) degrades.

Dashboards combine business events with infrastructure and application data in the same Grail query, enabling correlation of a KPI drop with a deployment or incident.

Data retention and cost: bizevents have their own bucket retention; high-cardinality attributes increase storage and query cost and should be bounded.

Real User Monitoring (RUM) captures actual user sessions via JavaScript beacons; Synthetic monitoring executes scripted checks from controlled locations on a schedule.

Core Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift); INP replaced FID as the responsiveness metric.

Apdex is a user-satisfaction index: (satisfied + tolerating/2) / total, where thresholds are configurable per application.

Session replay reconstructs the user's interaction sequence; it is privacy-sensitive and requires masking of personal data before capture.

User action naming and JavaScript frameworks: RUM detects XHR/fetch calls, route changes, and errors; custom actions can be defined for business-critical flows.

Synthetic monitors can be single-URL, browser-based (scripted click paths), or API checks; they detect availability and performance regressions independent of real traffic.

Geographic and browser segmentation of RUM data reveals experience gaps that aggregate metrics hide; mobile vs. desktop and network type are standard dimensions.

Frontend errors are grouped by type and stack trace; a JavaScript error's impact is measured by the number of affected user sessions, not raw occurrence count.

OneAgent deploys per host (full-stack, infrastructure-only, or discovery) and collects host, process, and network metrics; the deployment mode determines which signals are available.

Host metrics include CPU (user/system/iowait), memory (used, available, page faults), disk (IOPS, latency, queue depth), and network (throughput, errors, retransmits).

Process group detection groups identical processes across hosts; process group instances are the individual processes on specific hosts.

The Smartscape topology is refreshed continuously and models hosts, processes, services, and their dependencies; it is the basis for root-cause traversal.

Kubernetes observability: OneAgent Operator (or the cloud-native full-stack injection) instruments pods; Kubernetes events, node conditions, and workload metrics are correlated with application data.

Cloud infrastructure (AWS, Azure, GCP) is monitored via cloud integrations that pull metrics and metadata; the entity model maps cloud resources to Dynatrace entities.

Maintenance windows suppress alerting during planned changes; they should be scoped to the affected entities and time range.

Network zones and host groups control data routing and configuration scope; a host group is the primary configuration unit for OneAgent settings.

Logs are stored in Grail and queried with DQL; the query pipeline is fetch, filter, summarize, and the result is a tabular record set.

DQL operators: fetch (select the data source), filter (predicate), summarize (aggregation by group), sort, limit, and fieldsAdd/fieldsRemove for projection.

Log ingestion methods: OneAgent log ingestion (auto-detected log files), the Log ingest API, and cloud log forwarders; ingestion rules control parsing and enrichment.

Log processing rules extract attributes (for example severity, service) from raw lines; extracted attributes become queryable dimensions and enable log-to-trace correlation.

Logs can be correlated with traces and metrics via trace ID and entity identifiers; a log record carries the entity it belongs to when ingestion rules resolve it.

Retention is bucket-based; long-term retention costs more, and query performance depends on the time range and the bucket's indexing.

Pattern detection groups similar log lines into a log pattern; anomaly detection on log volume or error rate can trigger problems.

Sensitive data redaction must happen at ingestion; once stored in Grail, redaction requires reprocessing and is not retroactive for already-ingested records.

Release monitoring tracks a deployment across environments; a release is a versioned set of changes, and its health is measured by error rate and response time against the pre-deployment baseline.

Deployment events (from CI/CD, Kubernetes, or the events API) are correlated with service behavior to attribute a regression to a specific release.

SLOs and error budgets gate releases: a burn-rate alert during a rollout signals a bad deployment before users report it.

Progressive delivery (canary, blue/green) is validated by comparing the new version's metrics against the baseline version's metrics on the same service.

Pipeline observability: build and deployment telemetry can be ingested as events and visualized alongside runtime health, closing the loop from commit to production.

Change tracking records configuration and code changes; Davis uses change events as candidate causes during root-cause analysis.

Environment and management zones isolate production from staging in dashboards and alerting profiles, preventing cross-environment noise.

Automatic release validation compares key metrics over a defined window; a failed validation should trigger rollback automation rather than manual inspection.

Threat observability extends security analytics beyond detection to continuous visibility of attack surface, exposure, and attacker behavior across runtime.

Attack detection signals (for example process injection, privilege escalation, suspicious network connections) are correlated with vulnerability context to produce a threat score.

Threat observability consumes the same entity model as application observability, so an attack can be traced to the host, process, and service it targets.

Indicators of compromise (IOCs) and behavioral detections differ: IOCs are signatures, behavioral detections model attacker techniques (for example MITRE ATT&CK mapping).

Security problems are prioritized by exploitability and business impact; a critical CVSS score on an unreachable internal service ranks below a medium score on an internet-facing one.

Detection coverage should be measured against the attack surface: unmonitored hosts are blind spots, and infrastructure-only OneAgent deployment limits runtime security depth.

Threat events feed dashboards and SLO-like security objectives; mean time to detect and mean time to respond are the key operational metrics.

Forensics requires retained telemetry: process, network, and log data must be retained long enough to reconstruct an incident timeline after detection.