[BUG] snmp_exporter: "expected a sequence, got 12" when scraping MikroTik module 'mikrotik' #1515
Description
Context
- Rocky Linux 9 with Prometheus and SNMP Exporter
- SeLinux : Permissive ( for testing)
- Rocky Linux IP : 192.168.100.56
- Mikrotik IP : 192.168.100.102
- snmp_exporter, version 0.29.0
- Mikrotik Info detail :
[admin@MikroTik] > /system routerboard print routerboard: yes board-name: hAP ac^2 model: RBD52G-5HacD2HnD revision: r3 firmware-type: ipq4000L factory-firmware: 6.49.17 current-firmware: 6.49.17 upgrade-firmware: 6.49.17
Summary
When integrating a MikroTik device with Prometheus using snmp_exporter (module generated from MIKROTIK-MIB), the target becomes unreachable in Prometheus UI (status = DOWN), and the exporter logs the following error:
time=2025-10-13T13:49:30.516Z level=INFO source=collector.go:367 msg="Error scraping target" auth=snmpv3 target=192.168.100.102 source_address="" worker=0 module=mikrotik err="error walking target 192.168.100.102: error in unmarshalResponse: expected a sequence when unmarshalling a VB, got 12"
For context, when I checked the Prometheus web UI, the target state was “down”, or missing metrics.
The snmp_exporter process itself was still running fine — no crash, just erroring out on that module.
Reproduction steps
- Generate
snmp.ymlusing the Prometheus snmp_exportergeneratorand the official MIKROTIK-MIB. - Configure a
mikrotikmodule on prometheus (SNMPv3 authPriv). - Add target
192.168.100.102(MikroTik RouterOS) to Prometheus. (withmikrotikmodule) - Observe that:
- In Prometheus web UI, the target appears DOWN.
snmp_exporterlogs the unmarshalResponse error above.
Note: Using simpler modules such as if_mib or system works correctly; no errors are observed with these modules.
Observations (snmpwalk)
When testing directly with snmpwalk:
snmpwalk -v3 -l authPriv -u ASCMonitoring -a SHA -A <AUTH> -x AES -X <PRIV> 192.168.100.102 1.3.6.1.4.1.14988
I get mixed results:
- Under
.1.3.6.1.4.1.14988.1.1.1.3.1.*→ ✅ values returned (Strings, Integers, Counters) - Under
.1.3.6.1.4.1.14988.1.1.1.1.1.*→ ❌ all return “No Such Object available on this agent at this OID”
Example:
=== Test of 1.3.6.1.4.1.14988.1.1.1.1.1.1 ===
SNMPv2-SMI::enterprises.14988.1.1.1.1.1.1 = No Such Object available on this agent at this OID
...
=== Test of 1.3.6.1.4.1.14988.1.1.1.3.1.4 ===
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.4.1 = STRING: "MikroTik-D08A32"
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.4.2 = STRING: "MikroTik-Test"
Potential Solution / Workaround 💡
After some experimentation, I found that modifying the mikrotik module in snmp.yml seems to allow the exporter to scrape the device without triggering the unmarshalResponse error.
Specifically, replacing the original walk entries:
walk:
- 1.3.6.1.2.1.31.1.1.1.1
- 1.3.6.1.4.1.14988with
walk:
- 1.3.6.1.2.1.31.1.1.1.1
- 1.3.6.1.4.1.14988.1.1.1.3.1
appears to resolve the issue on my MikroTik device (RouterOS).
Explanation:
The original 1.3.6.1.4.1.14988 subtree includes some OIDs that are not implemented on this RouterOS version, leading to No Such Object responses and the unmarshal error.
Using 1.3.6.1.4.1.14988.1.1.1.3.1 restricts the walk to the subtrees that actually exist on the device, matching what snmpwalk returns successfully.
Note:
This is a device-specific workaround — the correct solution may involve updating the generator or handling non-existent OIDs gracefully in snmp_exporter.
I can confirm that after this change, the Prometheus target shows as UP and metrics under the mikrotik module are collected properly.Not all metrics but it's "working".