# Asama vs Zabbix : A component-by-component comparison

> Zabbix and Asama scored on Infrastructure State, Detection and Remediation Capability.

- URL: https://blog.asama.ai/blog/01-asama-vs-zabbix/
- Published: 2026-07-24
- Tags: Articles

## Executive summary

Zabbix is an open-source monitoring engine in production use. It collects almost anything, it is free at any host count, and banks, telecoms and governments run it at scale. None of what follows is an argument to rip it out.

It is an argument about where your engineers' hours go.

| |   Zabbix    |   Asama    |
|---|---|---|
| **Infrastructure State** |   **1.4** / 4    |   **4.0** / 4 |
| **Detection** |   **0.8** / 4    |   **4.0** / 4 |
| **Remediation** |   **0.3** / 4    |   **4.0** / 4 |

Every score on this page is out of 4, and every component behind these averages is shown below.

The gap is not about collection. Zabbix collects well. The gap is that it knows what your machines are doing and holds nothing about what they are supposed to be, so every act of comparing, correlating, diagnosing and fixing is performed by a person. That is not a defect. It is the design: the project's stated philosophy is that you supply the failure model. Your detection quality therefore equals the sum of predictions your team wrote down, kept as current as the last time somebody updated them.

---

## The Evaluation Framework

Every component is scored 0 to 4, and the number is the level. As it rises, work moves from your engineers to the product. **L0** not addressed. **L1** raw material. **L2** consolidated, you reason. **L3** reasons within limits. **L4** reasons across the fleet and down the stack, you approve. Set out in full in [the four levels of detection maturity](https://blog.asama.ai/blog/four-levels-of-detection-maturity).

A group's score is the **weighted average of its components**, on the same 0 to 4 scale, with the pivot component counting three times. Every component score is published below, so you can see exactly which cells produced the average and re-score any of them.

And **Infrastructure State bounds both loops from above**: a platform cannot correlate across a layer it never captured, or plan against state it never recorded.

---

## Part 1: Infrastructure State

What the platform knows about your fleet before anything goes wrong.

| Component | L0 | L1 | L2 | L3 | L4 |
|---|---|---|---|---|---|
| **Breadth** | reachability only | major layers, one OEM | major layers, across OEMs | a band of adjacent layers with depth, connected, across OEMs | interconnect and components through firmware, BMC, BIOS, drivers, kernel, OS to hypervisor, across OEMs |
| **Depth** | nothing | detects events | + live telemetry | + clustered inventory and golden baselines held as text | + config and tuning state, multi-vendor, drift classified against an evolving reference |
| **Normalisation** | content written per model | industry-standard formats only: MIB-II, IPMI, Redfish | a few aspects of major components, across OEMs, one layer | the same, across a few layers | every aspect of every component across every layer and OEM; one component is one object |
| **Topology** | a flat list | the relationships you declared | discovered within one domain | discovered across adjacent layers, kept current | live model of assets, layers, change history and dependencies, fleet-wide |
| **History** | current state only | raw series and events; you must know what to query | history plus reporting | indexed and searchable; you must know to ask | prior faults, RMA history and config changes for node and cohort, surfaced into the diagnosis |

### Breadth - Zabbix 2, Asama 4

Zabbix reaches the guest OS by agent, network devices by SNMP, hypervisors by built-in collector, and management-controller sensors by IPMI: several layers across many vendors, collected but not connected. Level 2 rather than 3 because reading a sensor is not reaching below the OS. BIOS configuration, kernel parameters and modules, firmware as comparable state, link state and accelerator error counters are absent at every layer.

Asama covers interconnect and components through firmware and BMC, BIOS, drivers, kernel and OS to the hypervisor, across Dell, HPE, Lenovo, Supermicro and NVIDIA hardware in one model. That full span across OEMs is what level 4 requires.

**The gap costs you:** a fault whose cause sits in a BIOS setting or a driver version never enters Zabbix's picture, so no analysis downstream can recover it.

### Depth - Zabbix 2, Asama 4

Zabbix detects events and holds live telemetry, both excellent, plus host inventory fields. Level 3 needs a golden baseline held as text against which a machine's configuration can be compared; file checksums tell you a file changed, not that a setting is wrong.

Asama holds configuration and tuning state across BIOS, kernel, firmware, drivers and device config for a multi-vendor estate, and classifies drift against a reference that evolves with the fleet rather than one written once.

**The gap costs you:** without a reference, "is this machine configured correctly" is a question nobody can ask the platform.

### Normalisation - Zabbix 1, Asama 4

Zabbix understands MIB-II and IPMI sensor names and nothing about OEM specifics. The community maintains separate templates for different generations of the same server family. Level 2 would need one vendor's power metric and another's mapped onto a single concept, at even one layer.

Asama normalises every aspect of every component across every layer and every OEM, so the drive the kernel enumerates, the drive the controller reports and the entry in the chassis inventory are proven to be one object.

**The gap costs you:** every cross-vendor comparison in a mixed fleet is done by a person who happens to know both vendors.

### Topology - Zabbix 1, Asama 4

Zabbix stores trigger dependencies and service trees, both authored by your team. They are static, carry no configuration state, and decay as the fleet changes. Level 2 would need relationships the platform discovered itself.

Asama maintains a live model of assets, components, layers, change history and dependencies across the fleet, which is what turns "this link is degraded" into "these sixteen nodes are affected".

**The gap costs you:** blast radius is worked out by hand, during the incident, by whoever knows the racks.

### History - Zabbix 1, Asama 4

Zabbix retains raw series and events behind an excellent query interface. Answering a question requires knowing what to query and roughly when. Level 3 would need it indexed and searchable conversationally.

Asama surfaces prior faults, RMA history and firmware and configuration changes for the node and its cohort into the current diagnosis, without being asked.

**The gap costs you:** the fact that two sibling nodes failed the same way in March is available only if somebody remembers March.

---

## Part 2: Detection Capability

From something changing to somebody knowing what is wrong. **Correlation is weighted three times**, because that is where the hours go.

| Component | L0 | L1 | L2 | L3 | L4 |
|---|---|---|---|---|---|
| **Symptom** | stores data; a person notices | a fixed limit somebody chose, crossed at or after impact | the signal's own history: fires when the node departs its own norm | own history qualified by seasonality, change windows, workload phase | the node against comparable nodes under comparable conditions, before any threshold of its own |
| **Correlation (x3)** | every alert stands alone | within one device, or a relationship you declared | unified dashboards, time-window mapping, anomalies vs projections; grouped, not assembled | AI search across tools and domains, assembling the case: scoped logs, change records, impacted config | end-to-end causal chain across the whole stack including BMC, BIOS, firmware, kernel and driver state, on a live topology |
| **Root cause** | nothing; the engineer forms the claim | orders the signals without asserting a cause | orders and selects the signals that bear on this incident | several probable causes, with the evidence for each | evidence for the causal chain, one root cause, a confidence level and the blast radius |
| **Learning** | nothing changes | records acknowledgments and alert volumes, manually | detects patterns from recorded failure confirmations and baselines | incorporates human verdicts into what it detects | live inventory of confirmations and baselines, written back into infrastructure state |

### Symptom detection - Zabbix 1, Asama 4

Zabbix fires when a fixed limit somebody chose is crossed, which is at or after impact. Baseline and forecast functions exist in the trigger language, but nothing runs until an engineer applies it item by item, so as shipped this is level 1.

Asama compares each node against comparable nodes under comparable conditions and fires when it departs the cohort's norm, before it crosses any threshold of its own.

**The gap costs you:** a drive three times slower than its neighbours since installation never departs from its own history. Typical fleets carry roughly 65 silently degraded servers per 1,000 for exactly this reason.

### Correlation - Zabbix 1, Asama 4

Zabbix groups signals along trigger dependencies, maintenance windows and tag rules, all relationships you declared. No discovered topology, no clustering, no evidence assembly.

Asama assembles an end-to-end causal chain across BMC, BIOS, firmware, kernel and driver state on a live topology, across compute, storage and network.

**The gap costs you:** this is the weighted component, and the difference is three levels. Zabbix compresses an alert list; the evidence gathering that consumes the incident is still yours.

### Root cause and evidence - Zabbix 0, Asama 4

Zabbix asserts nothing. Service trees roll up availability, which is a status aggregate rather than a causal ordering, so this is a genuine zero: [below the bottom of the ladder](https://blog.asama.ai/blog/four-levels-of-detection-maturity). Correlating a host symptom with a firmware level, a driver version and a port counter is done by a person opening screens.

Asama presents the evidence for the chain and declares one root cause with a confidence level and the blast radius: which other nodes share the at-risk state.

**The gap costs you:** the longest block of time in an infrastructure incident, every time.

### Learning - Zabbix 1, Asama 4

Zabbix records acknowledgments and top-trigger reports for a person to read and act on. Nothing adjusts itself.

Asama maintains a live inventory of failure confirmations and fleet baselines, and writes expected anomalies back into the infrastructure state so they are recalled during the next investigation.

**The gap costs you:** a trigger tuned last year is a configuration line that ages, not knowledge the platform holds.

---

## Part 3: Remediation Capability

From knowing what is wrong to the fleet being provably healthy. **Plan is weighted three times**, because acting is easy and knowing how to act is the hard part.

| Component | L0 | L1 | L2 | L3 | L4 |
|---|---|---|---|---|---|
| **Plan (x3)** | nothing; the engineer works it out from scratch | suggestions on troubleshooting this kind of issue | predefined runbooks for known patterns, bound to what triggers them | understands the problem and maps it to the matching procedure, with a target outcome | composes the plan at incident time against this node's exact hardware, firmware, BIOS and kernel |
| **Act** | does not execute; notifies, tickets or hands off | executes a single step against the target | multi-step with scheduling, change windows and audit | multi-step with failure handling: halts cleanly, restores a prior state | executes its own plan, staged, rollback pre-computed, maintenance policies honoured |
| **Verification** | nothing; the engineer checks by hand | reports whether the command ran and exited clean | a defined post-change check: compliance re-check, re-scan | re-compares against expected behaviour and state, surfacing degradation | against the pre-incident baseline, re-validated against peers |
| **Learning** | nothing persists | retains a retrospective a person wrote | stores the resolution as retrievable content | surfaces past resolutions inside a new incident of the same class | updates the procedure database so the next plan is better |

### Plan - Zabbix 0, Asama 4

Zabbix ships no procedure content: no runbook library, no generated guidance, no place where a procedure lives as a first-class object. A trigger description can carry a URL to your wiki, which is a hyperlink rather than a plan. Level 1 would need the platform to offer a suggestion.

Asama composes the plan at incident time against that machine's exact hardware, firmware, BIOS and kernel, with rollback computed before execution.

**The gap costs you:** this is the weighted component and Zabbix scores zero on it. Industry experience puts roughly 18 percent of manual fixes at the wrong procedure for the hardware state.

### Act - Zabbix 1, Asama 4

Zabbix genuinely reaches the machine: script actions run on the agent, over SSH or through IPMI, and IPMI power actions change hardware state. That is a real write path, more than several platforms marketing remediation harder can claim. Level 1 because it is a single step, with no sequencing and no reversal.

Asama executes the plan it composed, staged, with rollback pre-computed and maintenance policies honoured; a failure leaves the fleet at the last verified step.

**The gap costs you:** a half-applied change stays half-applied, at 3am.

### Verification - Zabbix 1, Asama 4

Zabbix returns the command's exit status, which tells you it ran rather than that the fault is gone.

Asama compares the node against its pre-incident baseline and re-validates it against its peers before calling the incident closed.

**The gap costs you:** "the alert cleared" is not evidence when the alert could not see the fault in the first place.

### Learning - Zabbix 0, Asama 4

Zabbix acknowledgment text is free-form and unindexed by problem class, so nothing about a resolution is available to the next incident. A genuine zero.

Asama updates its procedure database with every resolution, so the next generated plan is better.

**The gap costs you:** the lesson leaves the building when the engineer who learned it does.

---

## Placement

Against the wider field of 24 platforms and combinations we have scored, Zabbix sits in the bottom quartile on both loops. Pairing it with a reasoning layer changes that materially: with Claude it reaches 2.3 on detection, with an AI SRE agent 2.7, against 0.8 alone. **The ceiling is the substrate, not the intelligence on top of it**, which is the clearest evidence for why Infrastructure State is the axis that matters.

**Two caveats.** The framework is ours, and every anchor above is published so you can re-score any cell. Asama's row is self-assessed apart from one third-party-validated line: detection latency of 8 to 50 seconds across 25 induced-failure scenarios on live multi-vendor fleets.

---

## Conclusion

Zabbix answers one question extremely well: **is this thing up, and is this number above the line I drew?** For twenty years that was the question, and it answers it more cheaply and flexibly than anything on the market.

A modern fleet fails quietly. A drive serves reads three times slower than its neighbours and never crosses a threshold. Servers return from repair with settings reset and pass every health check for days. A link renegotiates to a lower generation and every dashboard stays green. None of those departs from its own history, so nothing built on self-referential thresholds will see them.

**The toil is the cost, and it is invisible.** Before an incident, somebody writes a template per model per layer and rewrites them each hardware generation. During one, a person groups two hundred alerts by reading them. After it, the lesson lives only in the head of whoever handled it. None of that appears on a dashboard and none of it compounds.

**The choice is not which tool collects better.** It is whether your operations improve because your platform learns, or only because your people do.

**Settle it on your own fleet.** Keep Zabbix running, put a second system beside it read-only for a month, and measure three things: detections your stack missed, especially configuration drift; the clock split in two, from alert to assembled evidence and then evidence to cause; and the engineering hours spent on template and trigger maintenance. The two coexist cleanly: Asama reads what Zabbix already collects, and its detections can feed your existing alert pipeline.

*Zabbix material is drawn from public documentation, release notes and aggregated user reviews, current as of July 2026.*