Post Syndicated from Patrik Uytterhoeven original https://blog.zabbix.com/the-evolution-of-an-snmp-auto-discovery-tool/33123/
Buckle up for the story of how we went from drowning in snmpwalk output to building a device-centric path toward Zabbix 7 walk-based templates.
The original problem
Every monitoring engineer knows this moment.
You get a new device on the network – a firewall, a NAS, a UPS, a switch from a vendor you have not standardized yet. You open the Zabbix template list. Nothing matches. You download the vendor MIB bundle. It is enormous. You run snmpwalk. The output is thousands of lines.
And then the real work begins: figuring out what any of it means for monitoring.
Not “what OIDs exist.” That part is usually easy. The hard part is deciding which of those OIDs deserve a place in a production template and which ones will create noise, duplicate data, or a discovery rule that walks itself into a timeout.
That was the problem we set out to solve. Not “discover SNMP.” SNMP already does that generously. We wanted to shorten the path from first walk to a usable Zabbix template , without pretending that automation can replace judgment.
That journey became snmp-scanner: a Node.js tool with a web UI that walks SNMP devices, analyzes OID structure, matches a built-in device knowledge base, and exports Zabbix 7 walk-based templates.
“Starting point — one walk, full visibility.”
The Scan tab: host, SNMP version, walk progress streaming in real time.
First goal: find interesting OIDs
Our first instinct was the obvious one: automate OID discovery with a one-click tool.
If we could programmatically surface “interesting” objects, we would save hours of manual grep through walk files. Early versions of the tool focused on exactly that:
- Determine the enterprise number: from sysObjectID
- Detect the vendor: from enterprise ID, sysDescr, and catalog metadata
- Collect MIB modules: parse vendor .mib files or resolve names via snmptranslate
- Select candidates: scalars, table columns, and table roots that looked monitorable
This worked better than expected…at first.
Enterprise detection and vendor matching gave us a foothold. MIB import filled in symbols and labels. Table analysis separated scalars from indexed structures. For the first time, a walk did not feel like a wall of numbers.
But we were solving the wrong headline problem.
Pipeline overview
The real problem was never finding OIDs
Here is what changed the direction of the project:
Finding OIDs is easy. Knowing which ones matter is hard.
A typical enterprise walk on a network or storage device surfaces far more data than any sane monitoring template should contain. Most of it falls into categories that look important until you try to operationalize them:
- Configuration objects: useful for inventory, rarely for alerting
- Diagnostic and debug counters: interesting in a lab, noisy in production
- Counters without operational meaning: they increment, but nobody knows what to do when they change
- Duplicates: the same concept exposed under multiple OIDs or table shapes
- Hundreds of tables: many with one row, odd indexing, or no stable discovery key
We learned this the hard way.
Early exports produced templates with hundreds of items. Discovery rules timed out. LLD macros did not line up with index columns. Items had technically correct OIDs and practically useless names.
The tool was good at discovery. It was not yet good at curation.
That distinction became the core design principle: Show the full walk. Curate the selection.
The catalog suggests; the engineer decides. Nothing is hidden. But not everything is auto-selected.
Adding the context
Once we accepted that OID discovery was only step one, the tool had to answer harder questions about each candidate we scanned:
| Question | Why it matters |
| Is this a metric? | Suitable for graphs and trends |
| Is this a status? | Better as a trigger or valuemap |
| Is this a table? | Candidate for LLD |
| Can this become walk-based LLD? | Zabbix 7 pattern: one master walk, dependent discovery |
| Does it have trigger potential? | Or is it inventory-only noise? |
This is where snmp-scanner grew beyond a walk viewer.
OID analysis classifies scalars vs tables and samples row data. Table recipes handle known shapes like IF-MIB and ENTITY-MIB where generic parsing fails.
Item policies apply global rules for types, units, and preprocessing. LLD macro logic derives {#SNMPINDEX} and optional display macros from INDEX columns and name/descr fields.
Walk eligibility checks became equally important. A table with 4,000 rows and 12 selected columns is not just “discoverable”, it may be too large to walk safely. The tool now estimates varbind counts and applies caps, with UI feedback on skipped tables before you export.
For Zabbix specifically, we committed early to walk-based discovery. In Zabbix 7, dependent discovery rules fed by a preprocessing chain on a master SNMP walk, rather than multiplying standalone SNMP items for every column.
That choice trades template complexity during authoring for runtime efficiency and consistency, but only if you select the right tables and columns.
Scalars and LLD tables side by side, with catalog match banner and suggestion badges.
“Full walk visible, curated selection highlighted.”
Template tab with walk limit banner showing skipped tables and row caps.
“Discovery is not the same as walk eligibility.”
Learning from existing monitoring systems
Raw MIB files tell you what a vendor defined. They do not tell you what operators monitor.
So we looked elsewhere — not for runtime dependencies, but for domain knowledge.
Zabbix official and community templates became our primary enrichment source. At dev time, we parse template YAML and merge metadata by OID into device bundles: item keys, preprocessing steps, trigger prototypes, valuemaps. Nothing is fetched from Zabbix at scan time, the knowledge is versioned in git and shipped with the tool.
Based on opensource info from other vendors we have build our own OS detection model, a large, battle-tested map of sysObjectID prefixes, sysDescr patterns, and device fingerprints as a hint layer for catalog matching. Think of it as: “Thousands of deployments already classified this shape of device.”
The same principle applies to historical ingest from other monitoring tool profiles: provenance and cross-source agreement matter more than any single vendor tree.
The insight worth stealing is this: Existing monitoring projects are a knowledge base of what humans already decided was worth watching.
MIB import answers “what exists.” Monitoring templates answer “what people actually use.”
Our ingest priority today reflects that:
- Zabbix templates → curation + keys + triggers
- SNMP walks → evidence a binding works on this device
- OID catalog → identity (symbol, label, MIB module)
- MIB parse → candidates only!! never auto-recommended alone!!
Our Knowledge layers
From OIDs to metrics: the bigger redesign
The next bottleneck was semantic, not technical.
The same monitoring meaning : CPU utilization, disk SMART, interface traffic, appeared under different OIDs across vendors, templates, and MIB modules.
We had parallel structures: integration presets, OID catalogs, monitoring profiles, suggestion categories, and OID-keyed scoring. No shared identity for “what this measures.”
So we are migrating now toward a device-centric knowledge model:
- A metric is the monitoring meaning (cpu_utilization, disk_smart, if_in_octets).
- A binding is how that metric appears on a specific product.
- OID identity stays global and device files reference it.
Scoring is deliberately split into three layers:
| Layer | Question | Stored in git? |
| monitoring_value | How important is this metric? | Yes |
| binding_confidence | Does this binding work on this device? | No — scan evidence |
| effective_score | What to highlight or auto-select now? | No — runtime only |
Device match score and metric rank must never be merged. Picking the right Cisco switch model is a different problem from ranking which metrics belong in the template.
We also consolidated roughly 830 legacy integration presets into enterprise-scoped device bundles. Native curated bundles where possible, consolidated drafts where not. While keeping backward compatibility through a virtual adapter layer.
Feature → Metric panel with monitoring value, tier, and effective score.
“The unit of curation is the metric, not the OID.”
Lessons learned
These are the lessons we wish we had written on the wall on day one.
Lesson 1: Most SNMP data is not useful monitoring data
A complete walk is a complete inventory of what the agent exposes. A good template is a subset chosen for operability. Confusing the two is how you get 500-item templates that nobody maintains.
Lesson 2: Device classification matters more than OID discovery
Knowing that you are on a QNAP QTS 5 box, a Cisco IOS-XE switch, or a NetApp FAS filer narrows the candidate set more than any generic “interesting OID” heuristic. Match rules on sysObjectID, sysDescr, and enterprise ID outperform symbol pattern matching alone.
Lesson 3: Tables are often more valuable than scalar objects
Scalars give you hostname and uptime. Tables give you interfaces, disks, sensors, fans, and power supplies, the structures that LLD was invented for. Table root detection, index handling, and walk recipes deserved more engineering time than scalar picking.
Lesson 4: Generating everything creates unusable templates
Our first “success” metric was item count. Our useful metric is maintainable item count. We now enforce a template safe auto-select policy: hard caps on auto-selected items, MIB drafts never auto-selected, and progressive learning only after repeated user selection.
Lesson 5: Good filtering is more important than good discovery
Discovery tells you what is there. Filtering tells you what belongs in production. Global deny lists, device-class suggestions, monitoring value tiers, and walk size limits are not afterthoughts, they are the product.
Lesson 6: Existing monitoring projects contain valuable domain knowledge
MIBs are necessary. Templates are opinionated. The combination is template wisdom plus walk evidence plus MIB identity, …. this beats any single source.
What our snmp-scanner does today
If you want the concrete picture, here is the current workflow:
- Scan the device (SNMPv2c/v3) or import an existing walk file
- Analyze OID structure — scalars, tables, row samples
- Match a device bundle from the catalog (~830 device lines, consolidating toward native bundles)
- Pre-select metrics via three layers: universal defaults, device preset, heuristic suggestions
- Edit the discovery profile in the UI — toggle selection, adjust macros, review walk limits
- Export a Zabbix 7 YAML template and import it via the API
Key properties:
- Full walk, curated selection: nothing is hidden
- JSON knowledge in git: no runtime database, no live fetch from external repos
- Walk-based LLD: for Zabbix 7
- MIB import: for OID identity; MIB-to-device drafts for candidate bundles (curator-reviewed before promotion)
- Metric-keyed learning: repeated user selections influence runtime ranking, not git, until a maintainer promotes them
- Regression fixtures: pipeline changes tested against anonymized walks (NetApp, Palo Alto, Cisco, and others) without live SNMP
The tool serves two audiences at once: engineers who need to explore and debug a walk, and engineers who need to ship a template faster on a known device class.
Generated Zabbix template preview + successful API import.
“From walk to imported template in one session.”
Where we are today
We are past the “find OIDs” phase and deep into the “govern automation” phase.
Recent work focuses on controlled auto-selection: first scan respects only git-curated default_selected bindings; repeat scans can soft auto-select when community learning and effective score cross thresholds, always within template-safe caps. MIB-derived drafts stay in candidate scope until a human promotes them.
The catalog is mid-migration: legacy integration JSON is being retired in favor of canonical devices/*.json bundles, with synthesis for backward compatibility. OID catalog data is sharded for scale. OS detection and Zabbix enrichment sit alongside native bundles for vendors we have walked and curated end to end like Cisco, QNAP, NetApp, Palo Alto, Eaton, F5, and others.
We are honest about what automation does not do: it does not replace template design judgment. It compresses the tedious middle — walk parsing, naming, table detection, preset matching, and first-draft item structure.
What’s next
The roadmap follows the same principle: more intelligence, more guardrails.
Better trigger generation: Merge more trigger prototype semantics from Zabbix source templates; improve scalar and table-level trigger exports beyond uptime-style defaults.
Smarter metric classification: Expand the metric registry and feature taxonomy (cpu, memory, disk_health, interface, psu, …). Derive tiers from monitoring_value instead of parallel scoring systems. Formalize binding lifecycle: candidate → known_good → recommended → blocked.
AI-assisted monitoring recommendations: The idea is that it can serve likely as a ranking and review accelerator, not as an autonomous template author. The hard constraints, walk size, trigger sanity, device class, duplicate detection, are structural. AI can help classify ambiguous symbols or propose metric mappings for curator review; it should not bypass the evidence ladder from walk → template → recommended.
Operational polish: Per-table-type walk limits (interfaces vs routing vs ARP), SNMP trap / notification support, and a clearer “promote this scan selection to catalog” path in the UI.
Closing thought
SNMP auto-discovery sounds like a search problem. In practice, it is a curation problem wrapped in a classification problem, wrapped in a template ergonomics problem.
We started by trying to find interesting OIDs. We stayed useful when we admitted that interesting ≠ monitorable, and built a system that respects both the completeness of the walk and the discipline of the template.
If you are staring at a fresh snmpwalk output and a missing Zabbix template, you are not failing at SNMP. You are at the exact step where domain knowledge matters most.
SNMP auto-discovery is not a discovery problem. It is a curation problem built on top of classification and domain knowledge.
This is where our tool helps us, with the walk visible, the candidates ranked, and the path to a Zabbix 7 template shorter than an afternoon of manual OID archaeology.
If you need assistance with the migration or want to ensure best practices for scaling and optimizing Zabbix, don’t hesitate to reach out to OICTS. We are a Zabbix Premium Partner operating globally, with offices in the USA, UK, the Netherlands, and Belgium, and we’re ready to help you every step of the way.
The post The Evolution of an SNMP Auto-Discovery Tool appeared first on Zabbix Blog.