LibreNMS - Auswertung nicht vollständig?

[tiermutter]

root@librenms:~# snmpwalk -v3 xxxxxx 10.13.12.5 .1.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6

iso.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.1 = INTEGER: 46

iso.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.2 = INTEGER: 39

iso.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.3 = INTEGER: 28

iso.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.4 = INTEGER: 29

iso.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.5 = INTEGER: 26

root@librenms:~# snmpwalk -v3 -xxxxxx 10.13.12.5 .1.3.6.1.4.1.55062.1.10.2.1.8

iso.3.6.1.4.1.55062.1.10.2.1.8.1 = INTEGER: 46

iso.3.6.1.4.1.55062.1.10.2.1.8.2 = INTEGER: 39

iso.3.6.1.4.1.55062.1.10.2.1.8.3 = INTEGER: 28

iso.3.6.1.4.1.55062.1.10.2.1.8.4 = INTEGER: 29

iso.3.6.1.4.1.55062.1.10.2.1.8.5 = INTEGER: 26

 

[blurrrr]

Über die Custom-OID bekomme ich sie dann aber rein, nur eben nicht über den gewohnten Weg

Hast Du die Datei-Berechtigungen mal bereinigt (hatte ich vorher schon mal erwähnt)?

 

[tiermutter]

Hm, konnte ich jetzt nix zu finden... Wo war das bzw. was genau meinst du?

 

[blurrrr]

Ab "Ganz vergessen: Nicht vergessen!"
https://forum.heimnetz.de/threads/librenms-auswertung-nicht-vollstaendig.531/post-7586

 

[blurrrr]

Kleine Korrektur: Laut Hersteller-Anleitung:

chown -R librenms:librenms /opt/librenms
chmod 771 /opt/librenms
setfacl -d -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache/ /opt/librenms/storage/
setfacl -R -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache/ /opt/librenms/storage/

 

[tiermutter]

Das hatte ich dann wohl falsch verstanden... Hab ich mal gemacht. Nach erneutem discover und poll aber keine Änderung.

 

[blurrrr]

Nach erneutem discover und poll aber keine Änderung.

Was Du hoffentlich mit dem User librenms ausgeführt hast?

 

[tiermutter]

Jap. Schon immer. Wobei sich "immer" auf diesen Sachverhalt hier bezieht, vorher brauchte ich das nicht
Korrektur habe ich auch nochmal drübergehauen... Nix.

 

[blurrrr]

Kannst natürlich auch mal in die snmpd.conf auf der QNAP schauen, vielleicht bringt Dir das ja neue Erkenntnisse

 

[tiermutter]

Bestimmt... Ich werde sie morgen mal verschlingen

 

[rednag]

Kannst natürlich auch mal in die snmpd.conf auf der QNAP schauen, vielleicht bringt Dir das ja neue Erkenntnisse

Deren Aussagekraft hält sich aber auch stark in Grenzen....

[admin@TS-253B .config]# cat snmpd.conf
sysName TS-253B
syscontact ""
syslocation ""
agentAddress udp:161,udp6:161
rocommunity monitoring
rocommunity6 monitoring

 

[blurrrr]

Bringt natürlich total was, wenn es nicht vom betroffenen System kommt... Das was dort steht, sieht aber soweit in Ordnung aus. Hätte auch sein können, dass nur bestimmte Dinge zur Abfrage erlaubt sind, dann hätte man noch gezielt OIDs erlauben können (vgl. man snmpd.conf).

Ich bin übrigens nach wie vor dafür - da die OIDs entsprechende Werte bei Abfrage ausgeben - dass man mit dem Debug-Switch die Discovery- und Poller-Ausgaben mal in eine Datei schreibt...

 

[tiermutter]

Done. Im Anhang die zensierten (pers. Daten, v6, SN, ...) Logs. Erwartungsgemäß kann ich nicht viel damit anfangen

Woher kommt eigentlich die MIB in LibreNMS unter /opt/librenms/mibs/qnap ? Diese weicht deutlich von der ab, die ich vom QNAP heruntergeladen habe und gibt den Fehler aus, dass ein enterprise statement fehlt.
Tatsächlich fehlt unter /enterprises die ID .1.3.6.1.4.1.55062 ("qnap").

Achja:

# cat /etc/config/snmpd.conf
syscontact ""
syslocation ""
agentAddress udp:161,udp6:161
rocommunity ""
rocommunity6 ""
rouser xxxxxx noauth

 

[rednag]

Bin zwar darüber nicht ganz so im Bilde, aber es scheint schon zumindest so, daß die Temperaturen abefragt und übermittelt werden.

'customoid_id' => 2,
'device_id' => 4,
'customoid_descr' => 'Temperature Disk 1',
'customoid_deleted' => 0,
'customoid_current' => 38.0,
'customoid_prev' => 37.0,
'customoid_oid' => '.1.3.6.1.4.1.55062.1.10.2.1.8.1',
'customoid_datatype' => 'GAUGE',
'customoid_unit' => '°C',
'customoid_divisor' => 1,
'customoid_multiplier' => 1,
'customoid_limit' => NULL,
'customoid_limit_warn' => NULL,
'customoid_limit_low' => NULL,
'customoid_limit_low_warn' => NULL,
'customoid_alert' => 0,
'customoid_passed' => 1,
'lastupdate' => '2022-04-28 06:10:13',
'user_func' => NULL,
)
SNMP[[0;36m'/usr/bin/snmpget' '-v3' '-l' 'noAuthNoPriv' '-n' "" '-u' 'USER' '-Oqv' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/qnap' 'udp:HOSTNAME:161' '.1.3.6.1.4.1.55062.1.10.2.1.8.1'[0m]
38

Custom OID Temperature Disk 1: 38 °C
RRD[[0;32mupdate /opt/librenms/rrd/10.13.12.5/customoid-Temperature_Disk_1.rrd N:38[0m]
SQL[[1;33mUPDATE `customoids` set `customoid_current`=?,`lastupdate`=NOW(),`customoid_prev`=? WHERE `customoid_id` = ? [0;33m[38,38,2][0m 3.97ms]

 

[tiermutter]

Das sind die Custom OIDs die ich angelegt habe.
Also ja, sie werden abgefragt, an der Stelle aber nur weil ich es manuell erzwinge. Das stellt sich optisch dann auch anders dar, als es sonst üblich ist:

 

[blurrrr]

Woher kommt eigentlich die MIB in LibreNMS unter /opt/librenms/mibs/qnap

Die ist standardmässig drin.

Temperature: SNMP[[0;36m'/usr/bin/snmpbulkwalk' '-v3' '-l' 'noAuthNoPriv' '-n' "" '-u' 'USER' '-Osqn' '-m' 'LM-SENSORS-MIB' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/qnap' 'udp:HOSTNAME:161' 'lmTempSensorsDevice'[0m]
.*.4.1.2*.1.2 No Such Object available on this agent at this OID

Invalid snmp_walk() data = .1.3.6.1.4.1.2021.13.16.2.1.2 No Such Object available on this agent at this OID

Wo nix ist, kann auch nix abgegrabbelt werden... Der Rest danach sieht normal aus:

Dynamic Discovery (temperature):
array (
'options' =>
array (
'skip_values' => -1,
),
'data' =>
array (
0 =>
array (
'oid' => 'enclosureTable',
'value' => 'enclosureSystemTemp',
'num_oid' => '.1.3.6.1.4.1.24681.1.4.1.1.1.1.1.2.1.7.{{ $index }}',
'descr' => 'Enclosure {{ $enclosureID }}',
'index' => 'enclosureSystemTemp.{{ $index }}',
'group' => 'System',
),
1 =>
array (
'oid' => 'cpuTemp',
'value' => 'cpuTemp',
'num_oid' => '.1.3.6.1.4.1.24681.1.4.1.1.1.1.4.2.{{ $index }}',
'descr' => 'CPU',
'index' => 'cpuTemp.{{ $index }}',
'group' => 'System',
),
2 =>
array (
'oid' => 'systemPowerTable',
'value' => 'systemPowerTemp',
'num_oid' => '.1.3.6.1.4.1.24681.1.4.1.1.1.1.3.2.1.6.{{ $index }}',
'descr' => 'Enclosure {{ $systemPowerEnclosureID }} PSU {{ $systemPowerID}}',
'index' => 'systemPowerTemp.{{ $index }}',
'group' => 'System',
),
3 =>
array (
'oid' => 'diskTable',
'value' => 'diskTemperture',
'num_oid' => '.1.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.{{ $index }}',
'descr' => 'Disk {{ $index }} {{ $diskModel }}',
'index' => 'diskTemperture.{{ $index }}',
'group' => 'Disks enclosure {{ $diskEnclosureID }}',
),
),
)
Data enclosureTable:
array (
)
Data cpuTemp:
array (
)
Data systemPowerTable:
array (
)
Data diskTable:
array (
)
array (
)
SQL[[1;33mSELECT * FROM sensors AS S, devices AS D WHERE S.sensor_class=? AND S.device_id = D.device_id AND D.device_id = ? AND S.poller_type = ? [0;33m["temperature",4,"snmp"][0m 1.36ms]

Keine Ahnung, ob ich es schon erwähnt habe, aber in die qnap.yaml kannste natürlich auch mal reinschauen (aber die, die unter .../discovery/ liegt.... "find / -name qnap.yaml"). Dort siehst Du, welche OID wofür abgefragt wird.

 

[tiermutter]

Wo nix ist, kann auch nix abgegrabbelt werden...

.1.3.6.1.4.1.2021.13.16 gibt es bereits nicht. Und wie kommt er auf die Idee dort zu suchen?

Dort siehst Du, welche OID wofür abgefragt wird.

Ahja...

emperature:
            options:
                skip_values: -1
            data:
                -
                    oid: enclosureTable
                    value: enclosureSystemTemp
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.1.2.1.7.{{ $index }}'
                    descr: 'Enclosure {{ $enclosureID }}'
                    index: 'enclosureSystemTemp.{{ $index }}'
                    group: 'System'
                -
                    oid: cpuTemp
                    value: cpuTemp
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.4.2.{{ $index }}'
                    descr: 'CPU'
                    index: 'cpuTemp.{{ $index }}'
                    group: 'System'
                -
                    oid: systemPowerTable
                    value: systemPowerTemp
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.3.2.1.6.{{ $index }}'
                    descr: 'Enclosure {{ $systemPowerEnclosureID }} PSU {{ $systemPowerID}}'
                    index: 'systemPowerTemp.{{ $index }}'
                    group: 'System'
                -
                    oid: diskTable
                    value: diskTemperture
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.6.{{ $index }}'
                    descr: 'Disk {{ $index }} {{ $diskModel }}'
                    index: 'diskTemperture.{{ $index }}'
                    group: 'Disks enclosure {{ $diskEnclosureID }}'
        fanspeed:
            options:
                skip_values: -1
            data:
                -
                    oid: systemFan2Table
                    value: systemFanSpeed
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.2.2.1.5.{{ $index }}'
                    descr: 'FAN {{ $index }}'
                    index: 'systemFanSpeed.{{ $index }}'
                    group: 'System enclosure {{ $systemFanEnclosureID }}'
                -
                    oid: systemPowerTable
                    value: systemPowerFanSpeed
                    num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.3.2.1.5.{{ $index }}'
                    descr: 'PSU {{ $systemPowerID }}'
                    index: 'systemPowerFanSpeed.{{ $index }}'
                    group: 'Power enclosure {{ $systemPowerEnclosureID }}'

Und dann erneut die Frage: Wie kommt er auf dieses schmale Brett? Dort gibt es nichts.
.1.3.6.1.4.1.24681.1.2.5 oder .1.3.6.1.4.1.55062.1.12.10 sind die CPU Temperatur....

 

[tiermutter]

Hmmm....

state:
data:
-
oid: systemHdTable
value: hdStatus
num_oid: '.1.3.6.1.4.1.24681.1.2.11.1.4.{{ $index }}'
descr: 'Disk {{ $index }}'
index: 'hdStatus.{{ $index }}'
group: 'Disk Status'
state_name: hdStatus
states:
- { value: 0, generic: 0, graph: 0, descr: 'Ready' }
- { value: -5, generic: 3, graph: 0, descr: 'No Disk' }
- { value: -6, generic: 2, graph: 0, descr: 'Invalid' }
- { value: -9, generic: 2, graph: 0, descr: 'RW Error' }
- { value: -4, generic: 3, graph: 0, descr: 'Unknown' }
-
oid: diskTable
value: diskSmartInfo
num_oid: '.1.3.6.1.4.1.24681.1.4.1.1.1.1.5.2.1.5.{{ $index }}'
descr: 'Disk {{ $index }}'
index: 'diskSmartInfo.{{ $index }}'
group: 'Disk S.M.A.R.T. enclosure {{ $diskEnclosureID }}'
state_name: diskSmartInfo
states:
- { value: 2, generic: 2, graph: 0, descr: 'Abnormal' }
- { value: 1, generic: 1, graph: 0, descr: 'Warning' }
- { value: 0, generic: 0, graph: 0, descr: 'Good' }
- { value: -1, generic: 2, graph: 0, descr: 'Error' }


Die grüne OID ist die einzig plausible in dem ganzen Ding. Alle anderen mit den vielen Einsen gibt es gar nicht.

 

[blurrrr]

Mach Dir ne Backup-Copy und schreib es ggf. testhalber in der YAML um

 

[tiermutter]

Morgen...
Jetzt ist computer freie Zeit im Garten angesagt...