Metric Events → Anomaly Detectors

Metric Events → Davis Anomaly Detectors

Gen2 used metric events (builtin:anomaly-detection.metric-events) for custom alerting. Gen3 replaces them with Davis anomaly detectors (builtin:davis.anomaly-detectors) — DQL-powered, more flexible, and integrated with the Davis AI engine.

Side-by-Side

GEN2 Metric Event                       GEN3 Anomaly Detector
──────────────────────────────────────  ──────────────────────────────────────
Metric selector expression              DQL timeseries query
Static threshold only                   3 models: Static, AutoAdaptive, Seasonal
Fixed sliding window                    Configurable samples + window
Management zone scoping                 DQL filter scoping
Event type: CUSTOM_ALERT only           Event type: configurable
No DQL in alert definition              Full DQL query power

Creating an Anomaly Detector

// Settings API: POST /platform/classic/environment-api/v2/settings/objects
[{
  "schemaId": "builtin:davis.anomaly-detectors",
  "scope": "environment",
  "value": {
    "enabled": true,
    "title": "[P1] High CPU Usage",
    "source": "my-toolkit",
    "analyzer": {
      "name": "dt.statistics.ui.anomaly_detection.StaticThresholdAnomalyDetectionAnalyzer",
      "input": [
        {"key": "query", "value": "timeseries avg(dt.host.cpu.usage), interval:1m"},
        {"key": "threshold", "value": "90"},
        {"key": "alertCondition", "value": "ABOVE"},
        {"key": "violatingSamples", "value": "3"},
        {"key": "slidingWindow", "value": "5"},
        {"key": "dealertingSamples", "value": "5"},
        {"key": "alertOnMissingData", "value": "false"}
      ]
    },
    "eventTemplate": {
      "properties": [
        {"key": "event.name", "value": "[P1] High CPU Usage"},
        {"key": "event.type", "value": "CUSTOM_ALERT"}
      ]
    }
  }
}]

Three Analyzer Models

Model                   Use Case                    How It Works
──────────────────────  ──────────────────────────  ──────────────────────────
StaticThreshold         Fixed thresholds (CPU>90%)  Compares against a number
AutoAdaptive            Baseline deviations         Learns normal, alerts on change
SeasonalBaseline        Predictable patterns        Accounts for daily/weekly cycles

Key Rules

• Query MUST use interval:1m
• Always set alertOnMissingData: false (unless you want alerts when data stops)
• Use [P1] or [P3] prefix in title for priority
• Set dealertingSamples: 5 to avoid flapping

Alerting Profiles → Workflows

Gen2 used alerting profiles to filter which problems trigger notifications, and problem notifications to send emails/Slack/etc. Gen3 replaces both with Workflows.

GEN2 Flow                               GEN3 Flow
──────────────────────────────────────  ──────────────────────────────────────
Problem detected                        Problem detected
  → Alerting profile filters              → Workflow trigger (Davis problem)
    → Problem notification sends            → DQL task (enrich context)
      → Email/Slack/webhook                   → JS task (format message)
                                                → Email/Slack/Jira action

Workflows are far more powerful — you can add DQL queries, JavaScript logic, conditional branching, and multiple notification channels in a single workflow.