A competent monitoring system tells you "CPU is high." A competent diagnostic system also tells you why it's high and what to do about it. This post breaks down the logic behind WAP's diagnostic analysis — from cross-referencing multiple signals, to ranking root causes, to handing you a recommendation you can act on immediately.
Suggestion: check this node's disk queue depth, or temporarily lower its read traffic weight
Diagnosis can be triggered from a lot of different entry points — a slow query crossing its threshold, an unusual resource swing, an alert breaching its limit. Whichever door it comes through, WAP kicks off the same analysis pipeline: never satisfied with just "what happened," always pushing on to "what does this actually mean."
A single query or a batch exceeding the latency threshold is the most common diagnostic trigger.
CPU, memory, or disk I/O suddenly deviating from its historical baseline.
Any monitoring metric that trips an alert threshold automatically comes with a diagnosis attached.
Oplog lag climbing sharply in a short window is often the surface symptom of something deeper.
A single slow query, on its own, tells you almost nothing about whether the root cause is a missing index, lock contention, or a disk bottleneck. WAP's diagnostic analysis pulls signals from multiple dimensions at once and only reaches a conclusion after cross-referencing them — here's exactly what each signal contributes.
Records exactly which query, how long it took, and how many documents it scanned — the "scene of the incident."
Reveals whether the query actually ran as a collection scan or an index scan, and whether it hit the expected index.
Whether CPU, memory, or disk I/O also spiked in the same window — separating "the query itself" from "not enough resources."
Whether a parameter, version, or index was recently touched — a lot of root causes trace back to "someone changed this yesterday."
Whether this same pattern has happened before, and what the root cause and fix were that time.
Multiple signals often point toward more than one plausible cause. WAP doesn't hand you a "suspect list" and walk away — it ranks causes by how strongly the signals actually correlate, putting the one most worth checking first at the top.
Confidence isn't a number pulled out of thin air: whether signals appeared in sync, whether this same pattern has historically led to the same outcome, and whether other obviously unrelated factors can be ruled out — all of that gets weighed in.
Finding the root cause is only half the job. WAP's diagnostic analysis always lands on a specific, actionable recommendation — not a pile of correlated data dumped on you to figure out yourself.
Cross-referencing signals, ranking root causes, handing over a fix — this pipeline wasn't built for one specific failure mode. It's general-purpose logic. Here are a few of the scenarios it handles most often.
Typical cause: a missing index, or a compound index in the wrong field order
Typical cause: a long-running transaction holding a lock, blocking everything behind it
Typical cause: connection pool sized too small, or clients not releasing connections properly
Typical cause: a disk I/O bottleneck, or a network partition between nodes
Typical cause: the working set has outgrown available cache, hit rate falling sharply
Typical cause: a poorly chosen shard key concentrating writes onto a single shard
From cross-referencing signals to a recommendation you can act on — the whole point of WAP's diagnostic analysis is shrinking the distance between spotting a problem and actually fixing it.