[BUG] snmp_exporter: "expected a sequence, got 12" when scraping MikroTik module 'mikrotik'

[Darkfoxjj12]

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

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

1. Generate snmp.yml using the Prometheus snmp_exporter generator and the official MIKROTIK-MIB.
2. Configure a mikrotik module on prometheus (SNMPv3 authPriv).
3. Add target 192.168.100.102 (MikroTik RouterOS) to Prometheus. (with mikrotik module)
4. Observe that:
   • In Prometheus web UI, the target appears DOWN.
   • snmp_exporter logs 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.14988

with

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.