SNMP collection shouldn't require a side quest.
Getting SNMP data into Elasticsearch unlocks rich visibility into your network — interface utilization, routing health, L2 forwarding, and more. The path there involves a few familiar steps: choosing which MIBs to walk, mapping OIDs to human-readable field names, configuring SNMP v2c or v3 authentication, accommodating vendor-specific MIB extensions, and tuning the pipeline to gracefully handle device timeouts across large inventories. With a solid template in place, what used to be a bespoke Logstash project becomes a repeatable, shareable setup that any engineer on the team can pick up and extend.
The plugin includes a Logstash pipeline template that handles the common cases out of the box. It walks IF-MIB (interface counters and status), IP-MIB (ARP tables and IP address assignments), BRIDGE-MIB (MAC address forwarding tables), BGP4-MIB (BGP peer sessions), and OSPF-MIB (OSPF neighbor adjacencies) per target device on a configurable poll interval. You add your device list and authentication details, start Logstash, and data begins flowing into Elasticsearch.
The template also handles the operational annoyances that trip people up: poll timeouts, missing OID branches on devices that don't support a given MIB, and batching walks across large device inventories.
Structuring SNMP data in Elasticsearch: schema design
Once SNMP data lands in Elasticsearch, the next problem is structure. Interface counters like ifInOctets and ifOperStatus map to ECS concepts reasonably well. They're host-level metrics with direct equivalents in host.network.* fields. But the data network engineers actually need for troubleshooting is relational, and this plugin offers a way to view those relationships.
A BGP peer session has a state, a remote AS number, an uptime, and an update count. An OSPF adjacency has a neighbor router ID, an area, a priority, and a state machine position. A MAC table entry records which physical switch port a given MAC address was learned on. None of these have ECS field definitions, and stuffing them into generic event.* or observer.* fields loses the semantic meaning that makes the data useful.
The plugin takes an opinionated approach: use ECS where it fits, extend with clear namespaces where it doesn't. Interface data maps to ECS-aligned fields. Routing protocol and L2 forwarding data goes into purpose-built namespaces (bgp_peer.*, ospf_neighbor.*, arp.*, mac_table.*) with field names that match the concepts operators already think in. If you know what bgpPeerState means on a router CLI, bgp_peer.state in Elasticsearch is immediately familiar. If you already collect SNMP data in a homegrown schema, the plugin's templates and ingest pipeline will complement it rather than replace it. The new fields are additive, so you can adopt them at your own pace!
| Data Type | Key Fields | ECS Namespace |
|---|---|---|
| BGP Peer Session | State, Remote AS, Uptime, Update Count | bgp_peer.* |
| OSPF Adjacency | Neighbor Router ID, Area, Priority, State | ospf_neighbor.* |
| MAC Table Entry | Switch Port, Learned MAC Address | mac_table.* |
| ARP Entry | IP-to-MAC Mapping | arp_table.* |
An ingest pipeline (snmp-device-enrichment) handles classification at index time. It parses each device's sysDescr string to assign a normalized device.type (router, switch, firewall, access point) and device.vendor, so every downstream consumer (dashboards, ES|QL queries, alerting rules, the topology view) gets consistent device metadata without custom parsing. The pipeline recognizes common vendors out of the box and is extensible for environments with less common hardware.
The result is SNMP data you can query like any other structured data in Elasticsearch. "Show me every BGP session not in Established state" is a filter, not a regex exercise. "Which Cisco switches have interfaces that are admin-up but oper-down" is a KQL query, not a script.
Visualising SNMP network topology in Kibana
Dashboards excel at answering "what are the numbers?" A topological view answers a complementary question: "what's connected to what?" Network engineers think in topology: upstream and downstream relationships, path diversity, and blast radius of a link failure. A spatial, graph-based view brings that mental model directly into Kibana, sitting alongside the charts and data tables operators already rely on.
The plugin adds an interactive topology graph to Kibana's Observability navigation. It reads the structured SNMP data from Elasticsearch, builds an adjacency graph from ARP, MAC table, BGP, and OSPF relationships, and renders it as a force-directed layout you can zoom, pan, and rearrange. Nodes are devices, edges are discovered relationships, and clicking any device opens a flyout with its interface table, ARP neighbors, and routing protocol sessions.
How do you set up SNMP network topology monitoring in Kibana?
The plugin is nearly ready to go out of the box, only a few assets need installation. Here's what the setup looks like:
-
Install the plugin zip on a self-managed Kibana instance (
bin/kibana-plugin install file:///path/to/networkTopology-<version>.zip). -
Apply the index templates and ingest pipeline. Click through the template installation in the plugin's Setup tab. A few button clicks and the schema is in place.
-
Deploy the Logstash pipeline. Add your device targets, authentication details, or other configuration to the included template and start it. If you're using Logstash Centralized Pipeline Management, push it from Kibana, no SSH required.
Data hits Elasticsearch on the next poll cycle, the ingest pipeline classifies and enriches them, and the topology view populates. Start to finish, you're looking at minutes, not hours or days of trial and error.
A sample data generator is included for teams that want to evaluate the plugin before connecting to live infrastructure; spin up the Docker Compose dev environment and explore the full feature set with a realistic multi-site network.