Install
$ agentstack add skill-dynatrace-dynatrace-for-ai-dt-obs-predictive-analytics ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Predictive Analytics Skill
Forecast resource saturation, detect trends, analyze anomalies, and characterize signal behavior using DQL and Dynatrace analyzer tools.
Analysis Disciplines
| # | Discipline | Use when … | |---|------------|-----------| | 1 | Forecast and Prediction | Predicting future metric values for capacity planning, cost estimation, or proactive alerting | | 2 | Detecting Changes | A metric shifted — find when the character of the signal changed, regardless of whether it crossed a limit | | 3 | Detecting Violations | A metric is currently out of bounds — find entities that exceed or fall below an acceptable range | | 4 | Timeseries Characteristics | Characterizing 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?"
| Question | Tool | Why | |----------|------|-----| | "Did this metric change in the last N hours?" | timeseries-novelty-detection | Detects 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_VALUES | Finds 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_VALUES | Pinpoints the onset of a directional shift | | "Which hosts are currently above 90% CPU?" | static-threshold-analyzer | Known fixed limit — fire alerts when exceeded | Can also be done with standard DQL queries, but the tool provides built-in violation counting, sliding window and alerting logic | | "Which services are currently above their usual load?" | adaptive-anomaly-detector | Learns the normal distribution from the data and flags sustained threshold violations | | "Which services are high right now vs. their weekly pattern?" | seasonal-baseline-anomaly-detector | Accounts for time-of-day/day-of-week patterns before deciding what is anomalous |
Decision rule in plain language
- Use
timeseries-novelty-detectionwhen 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, orstatic) 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:
| Column | Content | |--------|---------| | Rank | 🥇 🥈 🥉 ordered by urgency or magnitude | | Signal / Entity | Metric name and entity or dimension | | Last Actual | Most recent non-null value from the historical series | | Forecast | Point forecast at the end of the horizon | | Range | Lower – Upper confidence band at the same horizon point | | Trend | % change from Last Actual to Forecast: 🔴 >+20% / 🟠 +5–20% / 🟢 ±5% stable / 🔵 −5–20% declining / ⚫ 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
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:
metrics from: now() - 1h
| filter contains(metric.key, "cpu")
| summarize count(), by: {metric.key}
| sort `count()` desc
Reference Guides
references/forecasting-analyzer.md—timeseries-forecasttool:
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-detectiontool: spike, drop, step change,
trend onset, and variability change detection; all novelty types; parameter reference; worked examples
references/trend-detection.md—timeseries-novelty-detectionfor trend onset and change points;
week-over-week joins; growth rate and acceleration detection
Related Skills
- dt-dql-essentials — DQL syntax,
timeseriescommand 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 & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Dynatrace
- Source: Dynatrace/dynatrace-for-ai
- License: Apache-2.0
- Homepage: https://www.dynatrace.com
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.