Zum Inhalt

MIB-Snippets

Seit v0.19.0

Snippet-Loader, YAML-Format mit name, version, display_name, vendor, oids[], discoveries[].

Während der SNMP-Sensor-Picker universelle MIBs walkt (IF, HOST-RESOURCES, ENTITY-SENSOR, UPS), brauchen Vendor-Spezifika eine eigene Wissensquelle. Diese Wissensquelle ist ein MIB-Snippet — eine YAML-Datei mit OIDs, Status-Mappings und Discovery-Hints.

Snippets sind Daten, nicht Code. Neue Vendoren oder Geräte-Familien können hinzugefügt werden, ohne dass eine neue Vesana-Version released wird.

Warum als YAML

Variante Pro Contra
In den Collector hardcoden Schnell für ersten Wurf Bei jedem Vendor neu kompilieren, Vesana-Releases blocken
Als Daten (YAML) Hot-loadable, von Community erweiterbar, Vendor-spezifische Details ohne Code Etwas Overhead beim Loader

Wir haben uns für YAML entschieden — die Geschwindigkeit hat sich nie als Engpass gezeigt.

Format

Beispiel cisco-envmon.yaml:

name: cisco-envmon
version: 1
display_name: "Cisco Environment Monitoring"
vendor: cisco
description: "Temperatur, Lüfter, Netzteile von Catalyst- und ISR-Geräten."

# Welche Geräte erkennt dieses Snippet
matches:
  sysoid_patterns:
    - "^.1.3.6.1.4.1.9.1\\."           # alle Cisco
  sysdescr_patterns:
    - "Cisco IOS"
    - "Cisco Catalyst"

# Strukturierte OIDs zum Walk
discoveries:
  - id: temperature_sensors
    walk_oid: ".1.3.6.1.4.1.9.9.13.1.3.1"   # ciscoEnvMonTemperatureStatusTable
    columns:
      index:        ".1.3.6.1.4.1.9.9.13.1.3.1.1"  # ciscoEnvMonTemperatureStatusIndex
      description:  ".1.3.6.1.4.1.9.9.13.1.3.1.2"
      value:        ".1.3.6.1.4.1.9.9.13.1.3.1.3"
      threshold:    ".1.3.6.1.4.1.9.9.13.1.3.1.4"
      state:        ".1.3.6.1.4.1.9.9.13.1.3.1.6"
    state_mapping:
      1: OK
      2: WARNING
      3: CRITICAL
      4: CRITICAL
      5: NO_DATA

  - id: fan_sensors
    walk_oid: ".1.3.6.1.4.1.9.9.13.1.4.1"
    ...

  - id: power_supplies
    walk_oid: ".1.3.6.1.4.1.9.9.13.1.5.1"
    ...

Verfügbare Snippets (v0.19.0)

Snippet Vendor Was es abdeckt
cisco-envmon Cisco Temperatur, Lüfter, PSU auf Catalyst/ISR
cisco-stack Cisco Stack-Mitglieder, Master/Backup-Status
aruba-cx HPE Aruba CX CPU, Memory, Sensors
aruba-procurve HPE Aruba ProCurve Switch-Sensoren, PoE
apc-powernet APC Battery, Input/Output, Selftest
dell-idrac Dell PowerEdge iDRAC-Health, PSU, Drives
fortinet-fortigate Fortinet CPU, Sessions, VPN-Tunnel
sonicwall SonicWall Connections, VPN, Failover
synology-storage Synology DSM Volumes, Disks, RAID-State
qnap QNAP QTS Volumes, Disks, Fans
unifi-snmp-light Ubiquiti UniFi basic CPU, Memory, Ports

Snippets liegen in collector/snippets/ im Repo und werden im Collector-Image gebündelt.

Custom-Snippet anlegen

Schritte für eine neue Vendor-Integration:

1 — MIB-Dateien besorgen

Vom Vendor (Cisco-Download, IETF-RFC, etc.). Wir brauchen die OIDs in numerischer Form, nicht in Symbol-Form.

2 — Mit snmpwalk testen

snmpwalk -v 2c -c public 192.168.1.1 .1.3.6.1.4.1.<enterprise>.<...>

Notiere relevante Spalten und Index-Strukturen.

3 — YAML schreiben

Datei in collector/snippets/<vendor>-<thema>.yaml:

name: my-vendor-temp
version: 1
display_name: "MyVendor Temperature"
vendor: my-vendor
description: "Custom Temperature-Sensor-Detection"

matches:
  sysoid_patterns:
    - "^.1.3.6.1.4.1.99999\\."

discoveries:
  - id: temperatures
    walk_oid: ".1.3.6.1.4.1.99999.1.1.1"
    columns:
      index:       ".1.3.6.1.4.1.99999.1.1.1.1"
      name:        ".1.3.6.1.4.1.99999.1.1.1.2"
      value:       ".1.3.6.1.4.1.99999.1.1.1.3"
    default_threshold:
      warn: 60
      crit: 75
    unit: "°C"

4 — Lokal testen

docker compose -f docker-compose.dev.yml restart collector
docker compose -f docker-compose.dev.yml logs collector | grep "Snippet loaded"

Dann in der UI: SNMP-Picker auf einem Gerät mit passender sysOID öffnen — die neuen Sensoren tauchen unter MyVendor Temperature auf.

5 — In Vesana einreichen

Pull-Request gegen collector/snippets/. Sobald gemerged, ist das Snippet im nächsten Collector-Release dabei.

Lade-Reihenfolge

  1. Built-in Snippets aus dem Image
  2. Custom-Snippets aus /etc/vesana-collector/snippets/ (Volume-Mount auf der Collector-VM)
  3. Match-Reihenfolge: spezifischere sysOID-Patterns gewinnen vor generischen

Limitierungen

  • Snippets können nur SNMP-Walks beschreiben — keine SSH-Commands, keine HTTP-API-Calls
  • Komplexe abgeleitete Werte (z. B. CPU-Last als Differenz aus zwei OIDs) brauchen Code im Collector
  • Für Custom-Logik: Monitoring-Scripts (siehe Monitoring → Scripts)

Anschluss