Baselines, Anomalies, and the Daily Summary

Darling web dashboard server drill-down for SQL2025 with CPU and memory charts

Staring at charts is a job for people who are already suspicious. This is the machinery for everyone else: baselines learned from your own history, anomaly markers where today diverged from normal, a comparison overlay for “was it like this last week,” a one-row daily roll-up, and an analysis engine that files findings on a schedule so the monitor is reading itself even when you aren’t.

Baseline Bands and Anomaly Markers

The viewer’s per-server Overview is five correlated timeline lanes over the last 24 hours: CPU, total wait, blocking and deadlocks, buffer pool, and file I/O latency. Each lane carries a band of two standard deviations around that server’s own baseline, with anomaly markers where the line left it, and all five share one crosshair, so a spike in one lane lines up against the others. That layout exists because the first question about any spike is “what else moved at the same time.” Baseline aggregates are kept for 35 days, long enough that “normal” means something.

Per-server drill-down with CPU and memory charts from the collected store

The per-server drill-down: the same collected series the baselines are learned from.

Compare Against a Baseline Window

The query grids carry a Compare control that overlays the current window against yesterday, last week, or the same day last week, and flags queries that are new and queries that vanished. “The server is slow and nothing changed” usually loses an argument with that overlay in about thirty seconds.

The Daily Summary

One row per day, per server: total wait time, the top wait type, distinct query count, deadlock and blocking-event and high-CPU-sample counts, collector errors, and an overall health band, with a date picker to walk backward. It’s the “what happened yesterday” answer for the morning you weren’t watching.

The Analysis Engine

Every 30 minutes, per server, the service runs the same inference engine behind the Recommendations tab over the collected data and persists its findings, grouped into incidents: a severity badge, the affected database, the finding, and the reasoning. Cards are advise-only, and each offers an Ask AI button that copies an MCP investigation prompt, so the follow-up lives one paste away in your assistant; findings with a copy-paste remediation also offer Copy Fix. Findings above a severity bar deliver through the normal alert channels with a six-hour per-finding cooldown. A fresh install starts filing findings once it has a day of data to reason over, and the engine’s advice comes from your collected metrics, not a static checklist.

One operational detail that keeps all of this honest: delta collectors re-seed their baselines from the store when the service restarts, so the first collection cycle after a restart produces real deltas instead of a wall of zeros and false anomalies.

PerformanceMonitor on GitHub · monitoring overview