# Peer comparison is the baseline: what cohorts catch, and the faults they miss (Solution Landscape 1/4) > Why comparing each node with its peers catches degradation that thresholds miss, the cohort-wide faults it cannot see, and the four comparisons that cover them. - URL: https://blog.asama.ai/blog/issue-11-asama-peer-comparison-is-the-baseline/ - Author: Jain Johny - Published: 2026-03-18 - Tags: Frameworks Peer comparison judges a node against its cohort: servers with the same hardware model and firmware, running the same kind of workload. It catches what fixed thresholds miss: a node that is degrading while it is still inside every limit. It cannot see a fault the whole cohort shares, such as a bad firmware build rolled out to every node, so it works alongside a spec (the golden config), vendor advisories and each node's own history. Most infrastructure monitoring is built around thresholds. CPU above 90%. Disk latency above 50ms. Error rate above 1%. These numbers are set during deployment, informed by vendor recommendations and operational experience, and treated as the boundary between normal and abnormal. The problem is not that thresholds are wrong. It is that they are static, and infrastructure degradation is relative. A CPU that has been running at 85% utilisation for six months is behaving normally. A CPU that jumps from 40% to 85% utilisation under identical workload conditions is telling you something has changed. > "Threshold monitoring asks: has this metric crossed a line? Peer comparison asks: is this node behaving differently from identical nodes under similar conditions? The second question can flag a problem while the first still sees nothing." --- ## The two monitoring models compared | Threshold-based monitoring | Peer-relative anomaly detection | | :--- | :--- | | Fires when a metric crosses a predefined line | Fires when a node deviates from its cohort | | Requires engineers to anticipate every failure mode | Can flag failure modes nobody wrote a rule for | | Same threshold for every node regardless of workload | Context-aware comparison against similar hardware and workload | | Misses [gradual degradation that stays below the line](https://blog.asama.ai/blog/issue-01-asama-uptime-is-not-reliability) | Can flag degradation while it is still below the line | | False positives increase as fleets diversify | Needs cohorts that are large and alike enough to compare | --- ## What peer comparison actually catches Peer comparison is particularly powerful for the class of problems that threshold monitoring is worst at: gradual degradation that stays below the alert line but is clearly anomalous when compared to cohort behaviour. --- > ### Storage degradation > > **What changes** > A disk begins trending 20% higher read latency than [every other disk in its cohort](https://blog.asama.ai/blog/issue-06-asama-what-smart-data-isnt-telling-you) under the same workload. > > **Threshold monitoring** > No alert. Absolute latency still below threshold. > > **Peer comparison** > Flags the disk once the gap persists, because the deviation itself is the signal. --- > ### CPU performance drift > > **What changes** > CPU frequency on a node runs consistently lower than identical nodes under the same workload. > > **Likely causes** > [BIOS power profile mismatch](https://blog.asama.ai/blog/issue-10-asama-the-firmware-layer-nobody-owns), thermal throttling, firmware drift. > > **Why peer comparison matters** > The degradation is visible only relative to cohort behaviour. --- > ### Firmware drift > > **What changes** > A BIOS parameter [differs from the rest of the cohort after maintenance](https://blog.asama.ai/blog/issue-02-asama-config-drift-is-the-silent-killer). > > **Threshold monitoring** > No threshold breached. > > **Peer comparison** > Detects the node as operationally divergent from the fleet baseline. If the whole cohort took the same update, peers cannot show it; the golden config can, and so can each node's own history. --- ## What peer comparison misses Peers agree when they are all wrong together. A bad firmware build pushed to every node in a cohort, a procurement batch that shares a defect, or a slow change that moves the whole fleet at once leaves no node standing out. Peers also have to be real peers. Two nodes of the same model on different firmware, or running different jobs, are not comparable, and a cohort of three can name the odd one out but cannot tell a fault from ordinary spread. [Clustering](https://blog.asama.ai/blog/clustering-for-infrastructure-observability) helps find which nodes belong together. --- ## Four comparisons, not one | Compare each node against | What it catches | What it misses | | :--- | :--- | :--- | | **Its spec: the golden config for its cohort** | Settings and versions that drifted, even when every peer drifted with them | Faults in a node that matches its spec, and a spec that is itself wrong, such as a bad build written into it | | **Vendor advisories (CVE and errata)** | Firmware and microcode with known defects | Defects nobody has published | | **Its peers** | A node behaving differently from identical nodes under the same workload | Faults the whole cohort shares | | **Its own history** | A change in this node's behaviour, even when its peers changed with it | A node that has been off since the day it was racked, or drift slow enough to be learned as normal | Each comparison covers some of the others' blind spots, but not all of them. A defect a whole batch has carried since delivery, with no advisory yet, matches its spec, its peers and its own history; only a test against the vendor's rated figures, such as [burn-in at bring-up](https://blog.asama.ai/blog/issue-08-asama-bring-up-is-where-schedules-go-to-die), shows it. That is where fixed limits still earn their place, and why neither thresholds nor peers are enough on their own. --- ## From Asama > ### Cohorts built from hardware, firmware and workload > > Asama's anomaly detection is designed around peer-relative comparison. > > Every node is designed to be compared continuously against its cohort, grouped by: > > - Hardware model > - Firmware version > - Workload profile > - Environmental behaviour > > Deviations are designed to be scored by confidence before surfacing, so that what reaches you is signal, not noise. --- ## Food for thought > What percentage of your current alerts fire on threshold breaches, and what would you miss with only thresholds, or with only peer comparison? **Update, October 2026.** Asama's detection now compares every node four ways: against its cohort's golden config, against vendor advisories (CVE and errata), against its peers and against its own learned baseline. Peer groups are built on SKU, firmware, workload regime and age together, so two nodes of the same model on different firmware are not peers. Asama's fleet observations put about 65 servers in every 1,000 in a silently degraded state that no threshold sees. Fleet visibility is generally available, detection has been validated, and investigation and remediation are expanding. To see which of your nodes have drifted from their cohort, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.