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

> A combination of Zabbix + Claude compared with Asama AI & scored on Infrastructure State, Detection and Remediation Capability.

- URL: https://blog.asama.ai/blog/01-asama-vs-zabbixclaude/
- Published: 2026-08-08
- Tags: Articles

## Executive summary

Wiring Claude to Zabbix through its API or an MCP server is the best-value upgrade available to a monitoring stack today. It costs almost nothing, takes an afternoon, and **nearly triples Zabbix's detection score, from 0.8 to 2.3 out of 4**. Anyone running Zabbix and not trying this is leaving something on the table.

It also proves a point worth seeing on your own fleet.

| | Zabbix alone   | Zabbix + Claude   | Asama   |
|---|---|---|---|
| **Infrastructure State** | 1.4   | **1.8**   | **4.0** |
| **Detection** | 0.8  | **2.3**   | **4.0** |
| **Remediation** | 0.3   | **1.3**   | **4.0** |

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

Look at which axis moved. Detection climbed nine points; infrastructure state climbed two, all of it in one component. **Adding a frontier model does not add a layer, a data class or a vendor.** It reasons brilliantly over whatever Zabbix already collected, and Zabbix collects behaviour rather than state. The reasoning layer has become cheap. It cannot buy you a substrate.

---

## 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**: no model can correlate across a layer that was never captured, or plan against state that was 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 + Claude 2, Asama 4

Unchanged from Zabbix alone. The pairing reaches the guest OS by agent, network devices by SNMP, hypervisors by built-in collector, and management-controller sensors by IPMI. Claude reads what the collectors return; it deploys none of its own. BIOS configuration, kernel parameters and modules, firmware as comparable state, link state and accelerator error counters are still 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.

**The gap costs you:** you can ask the smartest available model about a BIOS setting it has no data on, and it will tell you it has no data on it.

### Depth - Zabbix + Claude 2, Asama 4

Unchanged. Zabbix detects events and holds live telemetry; Claude reads both, and a model reading a store adds no class of data to it. There is still no golden baseline against which a machine's configuration can be compared, so level 3 is out of reach.

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.

**The gap costs you:** "is this machine configured correctly" remains a question with no data behind it, however well it is phrased.

### Normalisation - Zabbix + Claude 1, Asama 4

Claude can interpret a vendor-specific value at query time, which feels like normalisation and is not. Nothing is normalised in the store: two vendors' power metrics remain two unrelated series, and the translation happens fresh each time somebody asks. Level 2 requires it in the substrate.

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:** cross-vendor comparison is possible per question and impossible per fleet. You cannot ask "which of my 900 machines look wrong" of a substrate that has no common vocabulary.

### Topology - Zabbix + Claude 1, Asama 4

Unchanged. Zabbix's trigger dependencies and service trees, authored by your team, are the whole relationship model. Claude can infer a dependency mid-conversation, but nothing persists, so the next question starts from the same declared edges.

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 re-derived from scratch every time somebody asks, and only for the part of the estate they thought to mention.

### History - Zabbix + Claude 3, Asama 4

**The one component the pairing genuinely lifts, and by two levels.** Zabbix retains the raw series and events; Claude makes them searchable conversationally, so an engineer no longer needs the exact item key and time window to get an answer. That is a real change in how usable years of retained data are.

Asama goes one further: prior faults, RMA history and firmware and configuration changes for the node and its cohort are surfaced into the diagnosis without being asked.

**The gap costs you:** level 3 still depends on somebody knowing to ask. The fault that two sibling nodes hit in March surfaces only if March occurs to you.

---

## 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 + Claude 1, Asama 4

Unchanged, and this is the component people expect Claude to fix. It does not. Zabbix still fires when a fixed limit somebody chose is crossed, at or after impact. Claude is invoked after something fires; it does not sit in the collection path deciding what counts as a symptom.

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:** everything Zabbix was blind to, the pairing is still blind to. A drive three times slower than its neighbours since installation produces no alert for Claude to reason about. Typical fleets carry roughly 65 silently degraded servers per 1,000 for exactly this reason.

### Correlation - Zabbix + Claude 3, Asama 4

**The big win, worth two levels on the weighted component.** Asked why forty alerts fired, Claude searches everything Zabbix holds, assembles the relevant series, events and history into one case, and hands back a coherent narrative. Genuine level 3 work, and why the pairing scores 2.3 rather than 0.8.

Two things keep it off level 4. It is pull-based, so somebody has to ask, whereas level 4 assembles the chain as the incident forms. And the chain can only span what Zabbix collected, which stops at the OS.

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:** the case is assembled beautifully from the wrong half of the stack. When the cause is a firmware level or a driver version, no amount of reasoning over metrics will name it.

### Root cause and evidence - Zabbix + Claude 3, Asama 4

Also a real gain, from zero. Claude offers several probable causes and shows the evidence for each from what Zabbix holds, which is exactly [level 3 on the ladder](https://blog.asama.ai/blog/four-levels-of-detection-maturity). It hedges honestly rather than asserting, which is the correct behaviour given its inputs.

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:** several hypotheses is where a good engineer starts, not where they finish. Choosing between them, and ruling out the ones the data cannot settle, is still your night.

### Learning - Zabbix + Claude 1, Asama 4

Unchanged, and the pairing's sharpest limitation. Nothing persists between sessions: the investigation you ran on Tuesday teaches the system nothing about the identical fault on Thursday, and a colleague asking next month starts from the same blank context. Zabbix's acknowledgments remain the only record.

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:** you are renting reasoning by the question rather than accumulating it. Every incident costs full price.

---

## 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 + Claude 2, Asama 4

Up two from Zabbix alone. Claude produces a procedure for the pattern it diagnosed rather than generic advice, clearing level 1 comfortably. It stops at 2 because level 3 requires mapping a diagnosed problem into a maintained procedure library, and there is no library. Claude writes the steps fresh each time, from general knowledge rather than your estate's history.

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:** a plausible procedure written by a model that cannot see the node's firmware level is exactly the failure mode to worry about. Industry experience puts roughly 18 percent of manual fixes at the wrong procedure for the hardware state.

### Act - Zabbix + Claude 1, Asama 4

Zabbix executes a single remote command over the agent, SSH or IPMI, and Claude can select which one. Smarter selection, unchanged execution: no sequencing, no branching on outcome, 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, and now nobody is quite sure who chose it.

### Verification - Zabbix + Claude 1, Asama 4

Unchanged. The command returns an exit status, which tells you it ran rather than that the fault is gone. Asked whether it worked, Claude re-reads the same metrics, which is the same evidence twice.

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 + Claude 0, Asama 4

A genuine zero, and the same session-boundary problem as detection learning. Nothing about a resolution is retained in a form the next incident can use.

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

**The gap costs you:** the lesson leaves with the conversation, which is a shorter life than leaving with the engineer.

---

## Placement

Among the 24 platforms and combinations we have scored, Zabbix with Claude sits mid-field on detection at 2.3: ahead of ManageEngine OpManager, SolarWinds and Dell AIOps on a mixed fleet, behind LogicMonitor with Edwin at 2.7. That an afternoon of API wiring reaches parity with platforms costing hundreds of dollars per device per year is the most interesting fact in the comparison set.

Swap Claude for an agentic AI SRE such as Cleric or Resolve and the pairing reaches 2.7 on detection and 2.3 on remediation, because those agents query the target on demand and retain what they learn. Same collector, better reasoning layer, and **still stuck at 2.0 on Infrastructure State**, because none of them adds a layer or a data class.

The framework is ours, and every anchor above is published so you can re-score any cell. Across 50-plus induced failures on Dell, HPE and Lenovo hardware, Asama's detection took 8 to 50 seconds.

---

## Conclusion

Do this. If you run Zabbix, wire a model to it. A level and a half of detection for an afternoon's work is the best return available anywhere in this market, and nothing below argues against it.

Then look at which components moved. **Correlation and root cause went up, over the same data.** Symptom detection did not, because the model does not decide what counts as a symptom. Breadth, depth, normalisation and topology did not, because a model reading a store does not add to it. Learning did not, because nothing persists past the conversation.

**That is the shape of the ceiling.** You have hired a superb analyst and sat them in front of the same four screens. They read those screens faster than your engineers and are exactly as blind to what is not on them. A drive slow since installation, a server back from repair with its settings reset, a link renegotiated to a lower generation: none appears on the screens, so the analyst never mentions them.

**The choice is not which reasoning layer to buy.** They are becoming commodities and cheap ones. It is whether the thing they reason over knows what your machines are supposed to be.

**Settle it on your own fleet.** Keep Zabbix and Claude running, put a second system beside them read-only for a month, and measure two things: detections neither raised, especially configuration drift and pre-threshold degradation; and how many investigations began by re-establishing context an earlier conversation had already worked out.

*Zabbix material is drawn from public documentation and aggregated user reviews. The pairing is scored as commonly deployed, with Claude reading Zabbix through its API or an MCP server and no persistent store of its own. Current as of July 2026.*