Alert Structure
Anomaly detection — create alerts for your extension metrics
Dynatrace has two alert systems. Classic metric events (Gen2) and Gen3 Davis anomaly detectors. Both work with extensions, but anomaly detectors are more powerful.
Gen3: Davis Anomaly Detectors (Recommended)
Model Best For Extension Example
────────────────────── ────────────────────────── ──────────────────────────
Static Threshold Known limits CPU > 90%, temp > 80°C
Auto-Adaptive Dynamic baselines Traffic patterns
Seasonal Baseline Daily/weekly patterns Business-hour traffic
🛠 Try it: Ctrl+K → "Anomaly detectors" → Create new → Use your extension metric: timeseries avg(com.dynatrace.extension.my-ext.cpu), interval:1m
Alert Naming Convention
[P1] Device Type — What's Wrong (Critical)
[P3] Device Type — What's Wrong (Warning)
Examples:
[P1] Cisco Catalyst — CPU Critical (>90%)
[P3] Cisco Catalyst — CPU Warning (>75%)
[P1] FortiSwitch — Interface Down
[P1] F5 BIG-IP — Pool Member Unavailable
Building an Alert Package
For a production extension, create alerts in pairs (P1 critical + P3 warning):
Metric P3 Warning P1 Critical
────────────────────────────────── ──────────── ────────────
CPU usage > 75% > 90%
Memory usage > 80% > 95%
Temperature > 70°C > 80°C
Interface error rate > 1% > 5%
Interface utilization > 80% > 95%
Disk usage > 80% > 90%
⚠️ Always set alertOnMissingData: false for extension alerts. Devices go offline for maintenance — you don't want false alerts.
Bundled Alerts
Include alert definitions in your extension package:
# extension.yaml
alerts:
- path: alerts/high-cpu.json
- path: alerts/high-memory.json
// alerts/high-cpu.json
{
"name": "[P1] {device.name} — CPU Critical",
"metricId": "com.dynatrace.extension.my-ext.cpu",
"threshold": 90,
"alertCondition": "ABOVE",
"samples": 5,
"violatingSamples": 3,
"dealertingSamples": 5
}