Dt Obs Predictive Analytics

by Dynatrace9529e72715d9Apache-2.0161 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 7 days ago

Predictive analytics for Dynatrace — time series forecasting with the timeseries-forecast tool, capacity saturation planning, trend and anomaly detection across hosts, services, and infrastructure.

Instructions onlyData & Analytics
AI-generated overview

Guides Dynatrace predictive analytics: forecasting, capacity saturation, trend and anomaly detection using DQL and analyzer tools.

What it does
Provides instructions for running predictive analytics on Dynatrace observability data, covering forecasting, change detection, violation detection and timeseries characterization. It explains which analyzer tool to use for each question, gives DQL query patterns for moving averages, saturation risk, days-to-saturation and anomaly scoring, and defines a structured forecast result table with a Key Findings section. It also points to reference guides for forecasting, capacity, anomaly scoring, novelty detection and trend detection.
When to use it
Use it for capacity planning questions such as which hosts will hit 90% CPU, for forecasting service request volume, and for trend, anomaly or baseline questions across hosts, services and infrastructure. It is also meant for deciding whether a metric changed versus is currently out of bounds before setting up alerting.
Requirements
Requires Dynatrace access with the analyzer tools timeseries-forecast, adaptive-anomaly-detector, seasonal-baseline-anomaly-detector, static-threshold-analyzer and timeseries-novelty-detection, plus execute-dql for DQL queries. It ships no scripts; it is instructions plus reference documents.

Predictive Analytics Skill

Forecast resource saturation, detect trends, analyze anomalies, and characterize signal behavior using DQL and Dynatrace analyzer tools.

Analysis Disciplines

#DisciplineUse when …
1Forecast and PredictionPredicting future metric values for capacity planning, cost estimation, or proactive alerting
2Detecting ChangesA metric shifted — find when the character of the signal changed, regardless of whether it crossed a limit
3Detecting ViolationsA metric is currently out of bounds — find entities that exceed or fall below an acceptable range
4Timeseries CharacteristicsCharacterizing a signal's seasonality, noise level, and trend before further analysis

Choosing the Right Detection Tool

The single most important decision: are you asking "did this metric change?" or "is this metric currently wrong?"

QuestionToolWhy
"Did this metric change in the last N hours?"timeseries-novelty-detectionDetects when the signal's character changed (spike, step, trend onset, variability shift) without requiring a known acceptable limit
"Which services spiked or dropped recently?"timeseries-novelty-detection with SPIKE / CHANGE_IN_VALUESFinds the specific entities and timestamps where change occurred; returns empty for stable signals
"When did CPU start trending up?"timeseries-novelty-detection with TREND_IN_VALUESPinpoints the onset of a directional shift
"Which hosts are currently above 90% CPU?"static-threshold-analyzerKnown fixed limit — fire alerts when exceeded
"Which services are currently above their usual load?"adaptive-anomaly-detectorLearns the normal distribution from the data and flags sustained threshold violations
"Which services are high right now vs. their weekly pattern?"seasonal-baseline-anomaly-detectorAccounts for time-of-day/day-of-week patterns before deciding what is anomalous

Decision rule in plain language

  • Use timeseries-novelty-detection when the question contains "changed", "shifted", "spiked", "dropped", "started", "when did", or "did anything unusual happen". The tool answers whether a change occurred and when. It requires no predefined threshold.
  • Use an anomaly detector (adaptive, seasonal, or static) when the question is about ongoing or current state relative to an expected range: "which are highest", "who is violating", "what is above X". These tools count violation samples inside a sliding window — they confirm how long something has been bad, not whether the signal changed.

Pitfall: Running adaptive-anomaly-detector on a broad fleet to answer "which service changed load?" typically flags every service that has any variation, producing low-signal results. Use timeseries-novelty-detection first to identify entities where the load character genuinely shifted, then use the anomaly detectors to measure the severity of those specific signals.

When to Use This Skill

  • Capacity: "Which hosts will hit 90% CPU in the next 30 days?"
  • Forecast: "Forecast service request volume for the next 7 days"
  • Trend: "Is memory usage growing across our Kubernetes nodes?"
  • Anomaly: "Which services have unusual error rates right now?"
  • Baseline: "How does today's traffic compare to last week?"
  • Signal profile: "Is this metric seasonal or trending before I set up alerting?"

Important Constraints

Dynatrace Forecast Analyzer supports univariate forecasting only — predicting one metric based on its own historical values. Multivariate forecasting (using multiple metrics as inputs) requires external tools (Python, R, Azure AutoML).

Tooling Rule: Run analyses using Dynatrace tools: timeseries-forecast, adaptive-anomaly-detector, seasonal-baseline-anomaly-detector, static-threshold-analyzer, and timeseries-novelty-detection. Use execute-dql for DQL queries.

Result Analysis Rule: Always analyse and summarise results directly from the raw tool output. Derive all numbers, trends, and conclusions inline.


Result Presentation Format

Always present forecast results as a structured table:

ColumnContent
Rank🥇 🥈 🥉 ordered by urgency or magnitude
Signal / EntityMetric name and entity or dimension
Last ActualMost recent non-null value from the historical series
ForecastPoint forecast at the end of the horizon
RangeLower – Upper confidence band at the same horizon point
Trend% change from Last Actual to Forecast: 🔴 >+20% / 🟠 +5–20% / 🟢 ±5% stable / 🔵 −5–20% declining / ⚫ <−20% sharp drop
Action✅ No action / ⚠️ Monitor / 🔴 Act now

Always follow the table with a Key Findings section (3–5 bullet points, ranked by priority).


Core DQL Techniques

DQL has no native forecast function. For forward-looking forecasts, use timeseries-forecast (see references/forecasting-analyzer.md).

Key DQL Rules

  1. timeseries returns arrays — one value per time slot per entity
  2. arrayLast(arr) = most recent value; arrayFirst(arr) = oldest
  3. Growth = (arrayLast - arrayFirst) / number_of_intervals
  4. Always filter isNotNull(field) before sorting to avoid null ordering issues
  5. Use toLong() when dividing Long fields to avoid type errors
  6. Use dt.smartscape.* not deprecated dt.entity.* in DQL display fields; use dt.smartscape.* in by:{} grouping clauses for entity-level queries

Standard Query Patterns

Moving Average Trend

dql
timeseries cpu = avg(dt.host.cpu.usage), from: now()-24h, interval: 1h, by: {dt.smartscape.host}| fieldsAdd moving_avg = arrayMovingAvg(cpu, 4)| fieldsAdd current = arrayLast(cpu)| fieldsAdd trend = arrayLast(cpu) - arrayFirst(cpu)| filter isNotNull(current)| sort trend desc| limit 20| fields dt.smartscape.host, current, trend, moving_avg

Saturation Risk Classification

dql
timeseries cpu = avg(dt.host.cpu.usage), from: now()-7d, interval: 1h, by: {dt.smartscape.host}| fieldsAdd p95 = arrayPercentile(cpu, 95)| fieldsAdd saturation_risk = if(p95 > 85, "HIGH", else: if(p95 > 70, "MEDIUM", else: "LOW"))| filter isNotNull(p95)| sort p95 desc| fields dt.smartscape.host, p95, saturation_risk

Days to Saturation Forecast

dql
timeseries cpu = avg(dt.host.cpu.usage), from: now()-30d, interval: 1d, by: {dt.smartscape.host}| fieldsAdd current = arrayLast(cpu)| fieldsAdd daily_growth = (arrayLast(cpu) - arrayFirst(cpu)) / 30| filter isNotNull(current)| fieldsAdd days_to_saturation = if(daily_growth > 0, toLong((90 - current) / daily_growth), else: 9999)| sort days_to_saturation asc| limit 20| fields dt.smartscape.host, current, daily_growth, days_to_saturation

Anomaly Scoring

dql
timeseries cpu = avg(dt.host.cpu.usage), from: now()-24h, interval: 1h, by: {dt.smartscape.host}| fieldsAdd baseline_avg = arrayAvg(cpu)| fieldsAdd current = arrayLast(cpu)| fieldsAdd anomaly_score = if(isNotNull(current) and isNotNull(baseline_avg), abs(current - baseline_avg), else: 0)| sort anomaly_score desc| limit 20| fields dt.smartscape.host, current, baseline_avg, anomaly_score

Metric Discovery

Before forecasting, discover available metrics by keyword:

dql
metrics from: now() - 1h| filter contains(metric.key, "cpu")| summarize count(), by: {metric.key}| sort `count()` desc

Reference Guides

  • references/forecasting-analyzer.md — timeseries-forecast tool: data requirements, parameter reference, interval selection, horizon limits, common pitfalls
  • references/capacity-forecasting.md — CPU/memory/disk/K8s saturation forecasts; multi-resource risk scoring; days-to-saturation DQL patterns
  • references/anomaly-scoring.md — adaptive-anomaly-detector, seasonal-baseline-anomaly-detector, static-threshold-analyzer; DQL deviation scoring
  • references/novelty-detection.md — timeseries-novelty-detection tool: spike, drop, step change, trend onset, and variability change detection; all novelty types; parameter reference; worked examples
  • references/trend-detection.md — timeseries-novelty-detection for trend onset and change points; week-over-week joins; growth rate and acceleration detection

Related Skills

  • dt-dql-essentials — DQL syntax, timeseries command rules, array function reference
  • dt-obs-hosts — Host and process metrics catalog
  • dt-obs-services — Service RED metrics for service-level trend analysis
  • dt-obs-problems — Davis AI problem history for anomaly correlation

Source and attribution

Source:Dynatrace/dynatrace-for-aiinskills/dt-obs-predictive-analyticsat commit9529e72

License: Apache-2.0

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from Dynatrace/dynatrace-for-ai

Dt Setup React Native

Dynatrace

Integrate the Dynatrace React Native Plugin into a React Native or Expo project — dependency setup, dynatrace.config.js, Babel registration, npx instrumentation, navigation tracking, user privacy options, and verification. Handles both bare React Native and Expo (babel-preset-expo) Babel configuration automatically. Trigger: "add Dynatrace to React Native", "React Native plugin setup", "instrument React Native app", "integrate Dynatrace RN", "mobile observability React Native", "react-native-plugin", "dynatrace react native", "add Dynatrace to Expo", "instrument Expo app", "Dynatrace Expo setup". Do NOT use for: querying RN RUM data (use dt-obs-frontends), non-React Native mobile setups, or Dynatrace server-side configuration.

Awaiting classification161updated 7 days ago

Dt Setup Android

Dynatrace

Instruments an existing Android project with the Dynatrace Mobile Agent for basic monitoring.

DevOps & Cloud161updated 7 days ago

Dt Sec Contextualization

Dynatrace

Maps security findings and IoC matches to Dynatrace Smartscape runtime entities and correlates them across entity levels.

Security161updated 7 days ago

Dt Obs Services

Dynatrace

Guides Dynatrace DQL queries for monitoring service performance, RED metrics, service mesh, messaging, and runtime telemetry.

DevOps & Cloud161updated 7 days ago

Dt Obs Logs

Dynatrace

Query, filter and analyze Dynatrace log data with DQL for troubleshooting and monitoring.

Data & Analytics161updated 7 days ago

Dt Obs Log Semantic Mapping

Dynatrace

Suggests and validates Dynatrace semantic dictionary mappings for vendor audit and HTTP log integrations.

Data & Analytics161updated 7 days ago