2018-10-17 16:03:51 +00:00
|
|
|
{
|
|
|
|
|
"os": {
|
|
|
|
|
"discovery": {
|
|
|
|
|
"devices": [
|
|
|
|
|
{
|
|
|
|
|
"sysName": "<private>",
|
|
|
|
|
"sysObjectID": ".1.3.6.1.4.1.705.1.2",
|
|
|
|
|
"sysDescr": "MGE Galaxy 7000 UPS 250 kVA",
|
|
|
|
|
"sysContact": "<private>",
|
|
|
|
|
"version": "GDET: BQ-7-AR / DIGIT: EJ-7-AR",
|
|
|
|
|
"hardware": "Galaxy 7000 250000",
|
|
|
|
|
"features": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"os": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"type": "power",
|
2018-10-26 20:05:30 +00:00
|
|
|
"serial": "2Q1L200001",
|
2019-03-12 01:32:30 +00:00
|
|
|
"icon": "apc.svg",
|
|
|
|
|
"location": "<private>"
|
2018-10-17 16:03:51 +00:00
|
|
|
}
|
|
|
|
|
]
|
2021-02-12 01:04:45 +00:00
|
|
|
},
|
|
|
|
|
"poller": "matches discovery"
|
2018-10-17 16:03:51 +00:00
|
|
|
},
|
|
|
|
|
"ports": {
|
|
|
|
|
"discovery": {
|
|
|
|
|
"ports": [
|
|
|
|
|
{
|
|
|
|
|
"port_descr_type": null,
|
|
|
|
|
"port_descr_descr": null,
|
|
|
|
|
"port_descr_circuit": null,
|
|
|
|
|
"port_descr_speed": null,
|
|
|
|
|
"port_descr_notes": null,
|
|
|
|
|
"ifDescr": "lo",
|
2018-12-24 16:29:02 +00:00
|
|
|
"ifName": "lo",
|
2018-10-17 16:03:51 +00:00
|
|
|
"portName": null,
|
|
|
|
|
"ifIndex": 1,
|
|
|
|
|
"ifSpeed": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifSpeed_prev": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifConnectorPresent": null,
|
|
|
|
|
"ifPromiscuousMode": null,
|
2020-01-24 11:58:01 +00:00
|
|
|
"ifOperStatus": "up",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifOperStatus_prev": null,
|
|
|
|
|
"ifAdminStatus": null,
|
|
|
|
|
"ifAdminStatus_prev": null,
|
|
|
|
|
"ifDuplex": null,
|
|
|
|
|
"ifMtu": null,
|
2018-12-12 03:07:56 +00:00
|
|
|
"ifType": "other",
|
2018-12-24 16:29:02 +00:00
|
|
|
"ifAlias": "lo",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifPhysAddress": null,
|
|
|
|
|
"ifHardType": null,
|
|
|
|
|
"ifLastChange": 0,
|
|
|
|
|
"ifVlan": "",
|
|
|
|
|
"ifTrunk": null,
|
|
|
|
|
"counter_in": null,
|
|
|
|
|
"counter_out": null,
|
|
|
|
|
"ignore": 0,
|
|
|
|
|
"disabled": 0,
|
|
|
|
|
"detailed": 0,
|
|
|
|
|
"deleted": 0,
|
|
|
|
|
"pagpOperationMode": null,
|
|
|
|
|
"pagpPortState": null,
|
|
|
|
|
"pagpPartnerDeviceId": null,
|
|
|
|
|
"pagpPartnerLearnMethod": null,
|
|
|
|
|
"pagpPartnerIfIndex": null,
|
|
|
|
|
"pagpPartnerGroupIfIndex": null,
|
|
|
|
|
"pagpPartnerDeviceName": null,
|
|
|
|
|
"pagpEthcOperationMode": null,
|
|
|
|
|
"pagpDeviceId": null,
|
|
|
|
|
"pagpGroupIfIndex": null,
|
|
|
|
|
"ifInUcastPkts": null,
|
|
|
|
|
"ifInUcastPkts_prev": null,
|
|
|
|
|
"ifInUcastPkts_delta": null,
|
|
|
|
|
"ifInUcastPkts_rate": null,
|
|
|
|
|
"ifOutUcastPkts": null,
|
|
|
|
|
"ifOutUcastPkts_prev": null,
|
|
|
|
|
"ifOutUcastPkts_delta": null,
|
|
|
|
|
"ifOutUcastPkts_rate": null,
|
|
|
|
|
"ifInErrors": null,
|
|
|
|
|
"ifInErrors_prev": null,
|
|
|
|
|
"ifInErrors_delta": null,
|
|
|
|
|
"ifInErrors_rate": null,
|
|
|
|
|
"ifOutErrors": null,
|
|
|
|
|
"ifOutErrors_prev": null,
|
|
|
|
|
"ifOutErrors_delta": null,
|
|
|
|
|
"ifOutErrors_rate": null,
|
|
|
|
|
"ifInOctets": null,
|
|
|
|
|
"ifInOctets_prev": null,
|
|
|
|
|
"ifInOctets_delta": null,
|
|
|
|
|
"ifInOctets_rate": null,
|
|
|
|
|
"ifOutOctets": null,
|
|
|
|
|
"ifOutOctets_prev": null,
|
|
|
|
|
"ifOutOctets_delta": null,
|
|
|
|
|
"ifOutOctets_rate": null,
|
|
|
|
|
"poll_prev": null,
|
|
|
|
|
"ifInNUcastPkts": null,
|
|
|
|
|
"ifInNUcastPkts_prev": null,
|
|
|
|
|
"ifInNUcastPkts_delta": null,
|
|
|
|
|
"ifInNUcastPkts_rate": null,
|
|
|
|
|
"ifOutNUcastPkts": null,
|
|
|
|
|
"ifOutNUcastPkts_prev": null,
|
|
|
|
|
"ifOutNUcastPkts_delta": null,
|
|
|
|
|
"ifOutNUcastPkts_rate": null,
|
|
|
|
|
"ifInDiscards": null,
|
|
|
|
|
"ifInDiscards_prev": null,
|
|
|
|
|
"ifInDiscards_delta": null,
|
|
|
|
|
"ifInDiscards_rate": null,
|
|
|
|
|
"ifOutDiscards": null,
|
|
|
|
|
"ifOutDiscards_prev": null,
|
|
|
|
|
"ifOutDiscards_delta": null,
|
|
|
|
|
"ifOutDiscards_rate": null,
|
|
|
|
|
"ifInUnknownProtos": null,
|
|
|
|
|
"ifInUnknownProtos_prev": null,
|
|
|
|
|
"ifInUnknownProtos_delta": null,
|
|
|
|
|
"ifInUnknownProtos_rate": null,
|
|
|
|
|
"ifInBroadcastPkts": null,
|
|
|
|
|
"ifInBroadcastPkts_prev": null,
|
|
|
|
|
"ifInBroadcastPkts_delta": null,
|
|
|
|
|
"ifInBroadcastPkts_rate": null,
|
|
|
|
|
"ifOutBroadcastPkts": null,
|
|
|
|
|
"ifOutBroadcastPkts_prev": null,
|
|
|
|
|
"ifOutBroadcastPkts_delta": null,
|
|
|
|
|
"ifOutBroadcastPkts_rate": null,
|
|
|
|
|
"ifInMulticastPkts": null,
|
|
|
|
|
"ifInMulticastPkts_prev": null,
|
|
|
|
|
"ifInMulticastPkts_delta": null,
|
|
|
|
|
"ifInMulticastPkts_rate": null,
|
|
|
|
|
"ifOutMulticastPkts": null,
|
|
|
|
|
"ifOutMulticastPkts_prev": null,
|
|
|
|
|
"ifOutMulticastPkts_delta": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifOutMulticastPkts_rate": null
|
2018-10-17 16:03:51 +00:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"port_descr_type": null,
|
|
|
|
|
"port_descr_descr": null,
|
|
|
|
|
"port_descr_circuit": null,
|
|
|
|
|
"port_descr_speed": null,
|
|
|
|
|
"port_descr_notes": null,
|
|
|
|
|
"ifDescr": "eth0",
|
2018-12-24 16:29:02 +00:00
|
|
|
"ifName": "eth0",
|
2018-10-17 16:03:51 +00:00
|
|
|
"portName": null,
|
|
|
|
|
"ifIndex": 2,
|
|
|
|
|
"ifSpeed": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifSpeed_prev": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifConnectorPresent": null,
|
|
|
|
|
"ifPromiscuousMode": null,
|
2020-01-24 11:58:01 +00:00
|
|
|
"ifOperStatus": "up",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifOperStatus_prev": null,
|
|
|
|
|
"ifAdminStatus": null,
|
|
|
|
|
"ifAdminStatus_prev": null,
|
|
|
|
|
"ifDuplex": null,
|
|
|
|
|
"ifMtu": null,
|
2018-12-12 03:07:56 +00:00
|
|
|
"ifType": "iso88023Csmacd",
|
2018-12-24 16:29:02 +00:00
|
|
|
"ifAlias": "eth0",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifPhysAddress": null,
|
|
|
|
|
"ifHardType": null,
|
|
|
|
|
"ifLastChange": 0,
|
|
|
|
|
"ifVlan": "",
|
|
|
|
|
"ifTrunk": null,
|
|
|
|
|
"counter_in": null,
|
|
|
|
|
"counter_out": null,
|
|
|
|
|
"ignore": 0,
|
|
|
|
|
"disabled": 0,
|
|
|
|
|
"detailed": 0,
|
|
|
|
|
"deleted": 0,
|
|
|
|
|
"pagpOperationMode": null,
|
|
|
|
|
"pagpPortState": null,
|
|
|
|
|
"pagpPartnerDeviceId": null,
|
|
|
|
|
"pagpPartnerLearnMethod": null,
|
|
|
|
|
"pagpPartnerIfIndex": null,
|
|
|
|
|
"pagpPartnerGroupIfIndex": null,
|
|
|
|
|
"pagpPartnerDeviceName": null,
|
|
|
|
|
"pagpEthcOperationMode": null,
|
|
|
|
|
"pagpDeviceId": null,
|
|
|
|
|
"pagpGroupIfIndex": null,
|
|
|
|
|
"ifInUcastPkts": null,
|
|
|
|
|
"ifInUcastPkts_prev": null,
|
|
|
|
|
"ifInUcastPkts_delta": null,
|
|
|
|
|
"ifInUcastPkts_rate": null,
|
|
|
|
|
"ifOutUcastPkts": null,
|
|
|
|
|
"ifOutUcastPkts_prev": null,
|
|
|
|
|
"ifOutUcastPkts_delta": null,
|
|
|
|
|
"ifOutUcastPkts_rate": null,
|
|
|
|
|
"ifInErrors": null,
|
|
|
|
|
"ifInErrors_prev": null,
|
|
|
|
|
"ifInErrors_delta": null,
|
|
|
|
|
"ifInErrors_rate": null,
|
|
|
|
|
"ifOutErrors": null,
|
|
|
|
|
"ifOutErrors_prev": null,
|
|
|
|
|
"ifOutErrors_delta": null,
|
|
|
|
|
"ifOutErrors_rate": null,
|
|
|
|
|
"ifInOctets": null,
|
|
|
|
|
"ifInOctets_prev": null,
|
|
|
|
|
"ifInOctets_delta": null,
|
|
|
|
|
"ifInOctets_rate": null,
|
|
|
|
|
"ifOutOctets": null,
|
|
|
|
|
"ifOutOctets_prev": null,
|
|
|
|
|
"ifOutOctets_delta": null,
|
|
|
|
|
"ifOutOctets_rate": null,
|
|
|
|
|
"poll_prev": null,
|
|
|
|
|
"ifInNUcastPkts": null,
|
|
|
|
|
"ifInNUcastPkts_prev": null,
|
|
|
|
|
"ifInNUcastPkts_delta": null,
|
|
|
|
|
"ifInNUcastPkts_rate": null,
|
|
|
|
|
"ifOutNUcastPkts": null,
|
|
|
|
|
"ifOutNUcastPkts_prev": null,
|
|
|
|
|
"ifOutNUcastPkts_delta": null,
|
|
|
|
|
"ifOutNUcastPkts_rate": null,
|
|
|
|
|
"ifInDiscards": null,
|
|
|
|
|
"ifInDiscards_prev": null,
|
|
|
|
|
"ifInDiscards_delta": null,
|
|
|
|
|
"ifInDiscards_rate": null,
|
|
|
|
|
"ifOutDiscards": null,
|
|
|
|
|
"ifOutDiscards_prev": null,
|
|
|
|
|
"ifOutDiscards_delta": null,
|
|
|
|
|
"ifOutDiscards_rate": null,
|
|
|
|
|
"ifInUnknownProtos": null,
|
|
|
|
|
"ifInUnknownProtos_prev": null,
|
|
|
|
|
"ifInUnknownProtos_delta": null,
|
|
|
|
|
"ifInUnknownProtos_rate": null,
|
|
|
|
|
"ifInBroadcastPkts": null,
|
|
|
|
|
"ifInBroadcastPkts_prev": null,
|
|
|
|
|
"ifInBroadcastPkts_delta": null,
|
|
|
|
|
"ifInBroadcastPkts_rate": null,
|
|
|
|
|
"ifOutBroadcastPkts": null,
|
|
|
|
|
"ifOutBroadcastPkts_prev": null,
|
|
|
|
|
"ifOutBroadcastPkts_delta": null,
|
|
|
|
|
"ifOutBroadcastPkts_rate": null,
|
|
|
|
|
"ifInMulticastPkts": null,
|
|
|
|
|
"ifInMulticastPkts_prev": null,
|
|
|
|
|
"ifInMulticastPkts_delta": null,
|
|
|
|
|
"ifInMulticastPkts_rate": null,
|
|
|
|
|
"ifOutMulticastPkts": null,
|
|
|
|
|
"ifOutMulticastPkts_prev": null,
|
|
|
|
|
"ifOutMulticastPkts_delta": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifOutMulticastPkts_rate": null
|
2018-10-17 16:03:51 +00:00
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
},
|
|
|
|
|
"poller": {
|
|
|
|
|
"ports": [
|
|
|
|
|
{
|
|
|
|
|
"port_descr_type": null,
|
|
|
|
|
"port_descr_descr": null,
|
|
|
|
|
"port_descr_circuit": null,
|
|
|
|
|
"port_descr_speed": null,
|
|
|
|
|
"port_descr_notes": null,
|
|
|
|
|
"ifDescr": "lo",
|
|
|
|
|
"ifName": "lo",
|
|
|
|
|
"portName": null,
|
|
|
|
|
"ifIndex": 1,
|
|
|
|
|
"ifSpeed": 0,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifSpeed_prev": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifConnectorPresent": null,
|
|
|
|
|
"ifPromiscuousMode": null,
|
|
|
|
|
"ifOperStatus": "up",
|
2020-01-24 11:58:01 +00:00
|
|
|
"ifOperStatus_prev": "up",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifAdminStatus": "up",
|
|
|
|
|
"ifAdminStatus_prev": null,
|
|
|
|
|
"ifDuplex": null,
|
|
|
|
|
"ifMtu": 1500,
|
|
|
|
|
"ifType": "other",
|
|
|
|
|
"ifAlias": "lo",
|
|
|
|
|
"ifPhysAddress": "0",
|
|
|
|
|
"ifHardType": null,
|
|
|
|
|
"ifLastChange": 0,
|
|
|
|
|
"ifVlan": "",
|
|
|
|
|
"ifTrunk": null,
|
|
|
|
|
"counter_in": null,
|
|
|
|
|
"counter_out": null,
|
|
|
|
|
"ignore": 0,
|
|
|
|
|
"disabled": 0,
|
|
|
|
|
"detailed": 0,
|
|
|
|
|
"deleted": 0,
|
|
|
|
|
"pagpOperationMode": null,
|
|
|
|
|
"pagpPortState": null,
|
|
|
|
|
"pagpPartnerDeviceId": null,
|
|
|
|
|
"pagpPartnerLearnMethod": null,
|
|
|
|
|
"pagpPartnerIfIndex": null,
|
|
|
|
|
"pagpPartnerGroupIfIndex": null,
|
|
|
|
|
"pagpPartnerDeviceName": null,
|
|
|
|
|
"pagpEthcOperationMode": null,
|
|
|
|
|
"pagpDeviceId": null,
|
|
|
|
|
"pagpGroupIfIndex": null,
|
|
|
|
|
"ifInUcastPkts": 0,
|
|
|
|
|
"ifInUcastPkts_prev": 0,
|
|
|
|
|
"ifInUcastPkts_delta": null,
|
|
|
|
|
"ifInUcastPkts_rate": null,
|
|
|
|
|
"ifOutUcastPkts": 0,
|
|
|
|
|
"ifOutUcastPkts_prev": 0,
|
|
|
|
|
"ifOutUcastPkts_delta": null,
|
|
|
|
|
"ifOutUcastPkts_rate": null,
|
|
|
|
|
"ifInErrors": 0,
|
|
|
|
|
"ifInErrors_prev": 0,
|
|
|
|
|
"ifInErrors_delta": null,
|
|
|
|
|
"ifInErrors_rate": null,
|
|
|
|
|
"ifOutErrors": 0,
|
|
|
|
|
"ifOutErrors_prev": 0,
|
|
|
|
|
"ifOutErrors_delta": null,
|
|
|
|
|
"ifOutErrors_rate": null,
|
|
|
|
|
"ifInOctets": 0,
|
|
|
|
|
"ifInOctets_prev": 0,
|
|
|
|
|
"ifInOctets_delta": null,
|
|
|
|
|
"ifInOctets_rate": null,
|
|
|
|
|
"ifOutOctets": 0,
|
|
|
|
|
"ifOutOctets_prev": 0,
|
|
|
|
|
"ifOutOctets_delta": null,
|
|
|
|
|
"ifOutOctets_rate": null,
|
|
|
|
|
"poll_prev": null,
|
|
|
|
|
"ifInNUcastPkts": 0,
|
|
|
|
|
"ifInNUcastPkts_prev": 0,
|
|
|
|
|
"ifInNUcastPkts_delta": null,
|
|
|
|
|
"ifInNUcastPkts_rate": null,
|
|
|
|
|
"ifOutNUcastPkts": 0,
|
|
|
|
|
"ifOutNUcastPkts_prev": 0,
|
|
|
|
|
"ifOutNUcastPkts_delta": null,
|
|
|
|
|
"ifOutNUcastPkts_rate": null,
|
|
|
|
|
"ifInDiscards": 0,
|
|
|
|
|
"ifInDiscards_prev": 0,
|
|
|
|
|
"ifInDiscards_delta": null,
|
|
|
|
|
"ifInDiscards_rate": null,
|
|
|
|
|
"ifOutDiscards": 0,
|
|
|
|
|
"ifOutDiscards_prev": 0,
|
|
|
|
|
"ifOutDiscards_delta": null,
|
|
|
|
|
"ifOutDiscards_rate": null,
|
|
|
|
|
"ifInUnknownProtos": 0,
|
|
|
|
|
"ifInUnknownProtos_prev": 0,
|
|
|
|
|
"ifInUnknownProtos_delta": null,
|
|
|
|
|
"ifInUnknownProtos_rate": null,
|
|
|
|
|
"ifInBroadcastPkts": 0,
|
|
|
|
|
"ifInBroadcastPkts_prev": 0,
|
|
|
|
|
"ifInBroadcastPkts_delta": null,
|
|
|
|
|
"ifInBroadcastPkts_rate": null,
|
|
|
|
|
"ifOutBroadcastPkts": 0,
|
|
|
|
|
"ifOutBroadcastPkts_prev": 0,
|
|
|
|
|
"ifOutBroadcastPkts_delta": null,
|
|
|
|
|
"ifOutBroadcastPkts_rate": null,
|
|
|
|
|
"ifInMulticastPkts": 0,
|
|
|
|
|
"ifInMulticastPkts_prev": 0,
|
|
|
|
|
"ifInMulticastPkts_delta": null,
|
|
|
|
|
"ifInMulticastPkts_rate": null,
|
|
|
|
|
"ifOutMulticastPkts": 0,
|
|
|
|
|
"ifOutMulticastPkts_prev": 0,
|
|
|
|
|
"ifOutMulticastPkts_delta": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifOutMulticastPkts_rate": null
|
2018-10-17 16:03:51 +00:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"port_descr_type": null,
|
|
|
|
|
"port_descr_descr": null,
|
|
|
|
|
"port_descr_circuit": null,
|
|
|
|
|
"port_descr_speed": null,
|
|
|
|
|
"port_descr_notes": null,
|
|
|
|
|
"ifDescr": "eth0",
|
|
|
|
|
"ifName": "eth0",
|
|
|
|
|
"portName": null,
|
|
|
|
|
"ifIndex": 2,
|
|
|
|
|
"ifSpeed": 100000000,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifSpeed_prev": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifConnectorPresent": null,
|
|
|
|
|
"ifPromiscuousMode": null,
|
|
|
|
|
"ifOperStatus": "up",
|
2020-01-24 11:58:01 +00:00
|
|
|
"ifOperStatus_prev": "up",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifAdminStatus": "up",
|
|
|
|
|
"ifAdminStatus_prev": null,
|
|
|
|
|
"ifDuplex": null,
|
|
|
|
|
"ifMtu": 1500,
|
|
|
|
|
"ifType": "iso88023Csmacd",
|
|
|
|
|
"ifAlias": "eth0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifPhysAddress": "0006230125f9",
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifHardType": null,
|
|
|
|
|
"ifLastChange": 0,
|
|
|
|
|
"ifVlan": "",
|
|
|
|
|
"ifTrunk": null,
|
|
|
|
|
"counter_in": null,
|
|
|
|
|
"counter_out": null,
|
|
|
|
|
"ignore": 0,
|
|
|
|
|
"disabled": 0,
|
|
|
|
|
"detailed": 0,
|
|
|
|
|
"deleted": 0,
|
|
|
|
|
"pagpOperationMode": null,
|
|
|
|
|
"pagpPortState": null,
|
|
|
|
|
"pagpPartnerDeviceId": null,
|
|
|
|
|
"pagpPartnerLearnMethod": null,
|
|
|
|
|
"pagpPartnerIfIndex": null,
|
|
|
|
|
"pagpPartnerGroupIfIndex": null,
|
|
|
|
|
"pagpPartnerDeviceName": null,
|
|
|
|
|
"pagpEthcOperationMode": null,
|
|
|
|
|
"pagpDeviceId": null,
|
|
|
|
|
"pagpGroupIfIndex": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifInUcastPkts": 1457323,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifInUcastPkts_prev": 0,
|
|
|
|
|
"ifInUcastPkts_delta": null,
|
|
|
|
|
"ifInUcastPkts_rate": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifOutUcastPkts": 1457327,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifOutUcastPkts_prev": 0,
|
|
|
|
|
"ifOutUcastPkts_delta": null,
|
|
|
|
|
"ifOutUcastPkts_rate": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifInErrors": 1878163,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifInErrors_prev": 0,
|
|
|
|
|
"ifInErrors_delta": null,
|
|
|
|
|
"ifInErrors_rate": null,
|
|
|
|
|
"ifOutErrors": 0,
|
|
|
|
|
"ifOutErrors_prev": 0,
|
|
|
|
|
"ifOutErrors_delta": null,
|
|
|
|
|
"ifOutErrors_rate": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifInOctets": 1048163459,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifInOctets_prev": 0,
|
|
|
|
|
"ifInOctets_delta": null,
|
|
|
|
|
"ifInOctets_rate": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifOutOctets": 252596803,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifOutOctets_prev": 0,
|
|
|
|
|
"ifOutOctets_delta": null,
|
|
|
|
|
"ifOutOctets_rate": null,
|
|
|
|
|
"poll_prev": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifInNUcastPkts": 11224315,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifInNUcastPkts_prev": 0,
|
|
|
|
|
"ifInNUcastPkts_delta": null,
|
|
|
|
|
"ifInNUcastPkts_rate": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"ifOutNUcastPkts": 29,
|
2018-10-17 16:03:51 +00:00
|
|
|
"ifOutNUcastPkts_prev": 0,
|
|
|
|
|
"ifOutNUcastPkts_delta": null,
|
|
|
|
|
"ifOutNUcastPkts_rate": null,
|
|
|
|
|
"ifInDiscards": 0,
|
|
|
|
|
"ifInDiscards_prev": 0,
|
|
|
|
|
"ifInDiscards_delta": null,
|
|
|
|
|
"ifInDiscards_rate": null,
|
|
|
|
|
"ifOutDiscards": 0,
|
|
|
|
|
"ifOutDiscards_prev": 0,
|
|
|
|
|
"ifOutDiscards_delta": null,
|
|
|
|
|
"ifOutDiscards_rate": null,
|
|
|
|
|
"ifInUnknownProtos": 0,
|
|
|
|
|
"ifInUnknownProtos_prev": 0,
|
|
|
|
|
"ifInUnknownProtos_delta": null,
|
|
|
|
|
"ifInUnknownProtos_rate": null,
|
|
|
|
|
"ifInBroadcastPkts": 0,
|
|
|
|
|
"ifInBroadcastPkts_prev": 0,
|
|
|
|
|
"ifInBroadcastPkts_delta": null,
|
|
|
|
|
"ifInBroadcastPkts_rate": null,
|
|
|
|
|
"ifOutBroadcastPkts": 0,
|
|
|
|
|
"ifOutBroadcastPkts_prev": 0,
|
|
|
|
|
"ifOutBroadcastPkts_delta": null,
|
|
|
|
|
"ifOutBroadcastPkts_rate": null,
|
|
|
|
|
"ifInMulticastPkts": 0,
|
|
|
|
|
"ifInMulticastPkts_prev": 0,
|
|
|
|
|
"ifInMulticastPkts_delta": null,
|
|
|
|
|
"ifInMulticastPkts_rate": null,
|
|
|
|
|
"ifOutMulticastPkts": 0,
|
|
|
|
|
"ifOutMulticastPkts_prev": 0,
|
|
|
|
|
"ifOutMulticastPkts_delta": null,
|
2020-05-23 17:05:18 +00:00
|
|
|
"ifOutMulticastPkts_rate": null
|
2018-10-17 16:03:51 +00:00
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"sensors": {
|
|
|
|
|
"discovery": {
|
|
|
|
|
"sensors": [
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "charge",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.2.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryLevel.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_descr": "Remaining battery capacity",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 100,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.6.1.0",
|
|
|
|
|
"sensor_index": "mginputCurrent.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Current Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 37,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.6.2.0",
|
|
|
|
|
"sensor_index": "mginputCurrent.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Current Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 37,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.6.3.0",
|
|
|
|
|
"sensor_index": "mginputCurrent.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Current Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 38,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.5.1.0",
|
|
|
|
|
"sensor_index": "mgoutputCurrent.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Current Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 35,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.5.2.0",
|
|
|
|
|
"sensor_index": "mgoutputCurrent.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Current Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 27,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.5.3.0",
|
|
|
|
|
"sensor_index": "mgoutputCurrent.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Current Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 41,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "current",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.6.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryCurrent.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_descr": "Battery",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 0,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "delay",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.1.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryRemainingTime.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_descr": "Remaining time",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 7260,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.3.1.0",
|
|
|
|
|
"sensor_index": "mginputFrequency.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Frequency Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": 47.5,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.3.2.0",
|
|
|
|
|
"sensor_index": "mginputFrequency.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Frequency Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": 47.5,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.3.3.0",
|
|
|
|
|
"sensor_index": "mginputFrequency.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Frequency Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": 47.5,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.3.1.0",
|
|
|
|
|
"sensor_index": "mgoutputFrequency.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Frequency Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 47.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.3.2.0",
|
|
|
|
|
"sensor_index": "mgoutputFrequency.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Frequency Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 47.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "frequency",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.3.3.0",
|
|
|
|
|
"sensor_index": "mgoutputFrequency.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Frequency Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 50,
|
|
|
|
|
"sensor_limit": 52.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 47.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "load",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.2.1.33.1.4.4.1.5.1.0",
|
|
|
|
|
"sensor_index": "501",
|
|
|
|
|
"sensor_type": "rfc1628",
|
|
|
|
|
"sensor_descr": "Percentage load",
|
2019-01-11 22:42:56 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 9,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit": 80,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "power",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.4.1.0",
|
|
|
|
|
"sensor_index": "kva.mgoutputLoadPerPhase.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output (VA) Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1000,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 9000,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "power",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.4.2.0",
|
|
|
|
|
"sensor_index": "kva.mgoutputLoadPerPhase.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output (VA) Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1000,
|
|
|
|
|
"sensor_current": 7000,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "power",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.4.3.0",
|
|
|
|
|
"sensor_index": "kva.mgoutputLoadPerPhase.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output (VA) Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1000,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 11000,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.15.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryChargerFault.0",
|
|
|
|
|
"sensor_type": "upsmgBatteryChargerFault",
|
|
|
|
|
"sensor_descr": "Battery Charger Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgBatteryChargerFault"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.9.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryFaultBattery.0",
|
|
|
|
|
"sensor_type": "upsmgBatteryFaultBattery",
|
|
|
|
|
"sensor_descr": "Battery Fault",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgBatteryFaultBattery"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.14.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryLowBattery.0",
|
|
|
|
|
"sensor_type": "upsmgBatteryLowBattery",
|
|
|
|
|
"sensor_descr": "Battery Charge Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgBatteryLowBattery"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.16.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryLowCondition.0",
|
|
|
|
|
"sensor_type": "upsmgBatteryLowCondition",
|
|
|
|
|
"sensor_descr": "Battery Condition",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgBatteryLowCondition"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.11.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryReplacement.0",
|
|
|
|
|
"sensor_type": "upsmgBatteryReplacement",
|
|
|
|
|
"sensor_descr": "Battery Replacement Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgBatteryReplacement"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.3.0",
|
|
|
|
|
"sensor_index": "upsmgInputBadStatus.0",
|
|
|
|
|
"sensor_type": "upsmgInputBadStatus",
|
|
|
|
|
"sensor_descr": "Input Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgInputBadStatus"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.4.0",
|
|
|
|
|
"sensor_index": "upsmgInputLineFailCause.0",
|
|
|
|
|
"sensor_type": "upsmgInputLineFailCause",
|
|
|
|
|
"sensor_descr": "Input Line Fail Cause",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 1,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgInputLineFailCause"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.9.0",
|
|
|
|
|
"sensor_index": "upsmgOutputInverterOff.0",
|
|
|
|
|
"sensor_type": "upsmgOutputInverterOff",
|
|
|
|
|
"sensor_descr": "UPS Inverter Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputInverterOff"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.3.0",
|
|
|
|
|
"sensor_index": "upsmgOutputOnBattery.0",
|
|
|
|
|
"sensor_type": "upsmgOutputOnBattery",
|
|
|
|
|
"sensor_descr": "Input Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputOnBattery"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.4.0",
|
|
|
|
|
"sensor_index": "upsmgOutputOnBypass.0",
|
|
|
|
|
"sensor_type": "upsmgOutputOnByPass",
|
|
|
|
|
"sensor_descr": "Bypass Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputOnByPass"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.10.0",
|
|
|
|
|
"sensor_index": "upsmgOutputOverLoad.0",
|
|
|
|
|
"sensor_type": "upsmgOutputOverLoad",
|
|
|
|
|
"sensor_descr": "Output OverLoad",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputOverLoad"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.11.0",
|
|
|
|
|
"sensor_index": "upsmgOutputOverTemp.0",
|
|
|
|
|
"sensor_type": "upsmgOutputOverTemp",
|
|
|
|
|
"sensor_descr": "Over Temperature",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputOverTemp"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "state",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.7.0",
|
|
|
|
|
"sensor_index": "upsmgOutputUtilityOff.0",
|
|
|
|
|
"sensor_type": "upsmgOutputUtilityOff",
|
|
|
|
|
"sensor_descr": "Utility Status",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 2,
|
|
|
|
|
"sensor_limit": null,
|
|
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": null,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": "upsmgOutputUtilityOff"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "temperature",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.7.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryTemperature.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_descr": "Battery",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 1,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 23,
|
|
|
|
|
"sensor_limit": 43,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 13,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.2.1.0",
|
|
|
|
|
"sensor_index": "mginputVoltage.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Phase/Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 409,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": 470.35,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit_low": 347.65,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.2.2.0",
|
|
|
|
|
"sensor_index": "mginputVoltage.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Phase/Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 410,
|
2019-01-11 01:48:37 +00:00
|
|
|
"sensor_limit": 471.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 348.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.6.2.1.2.3.0",
|
|
|
|
|
"sensor_index": "mginputVoltage.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Input Phase/Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 410,
|
2019-01-11 01:48:37 +00:00
|
|
|
"sensor_limit": 471.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 348.5,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.2.1.0",
|
|
|
|
|
"sensor_index": "mgoutputVoltage.1.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Phase/Phase 1",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
|
|
|
|
"sensor_current": 400,
|
2019-01-11 01:48:37 +00:00
|
|
|
"sensor_limit": 460,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
|
|
|
|
"sensor_limit_low": 340,
|
|
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.2.2.0",
|
|
|
|
|
"sensor_index": "mgoutputVoltage.2.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Phase/Phase 2",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 400,
|
2019-01-11 01:48:37 +00:00
|
|
|
"sensor_limit": 460,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 340,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.7.2.1.2.3.0",
|
|
|
|
|
"sensor_index": "mgoutputVoltage.3.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2019-03-12 01:32:30 +00:00
|
|
|
"sensor_descr": "Output Phase/Phase 3",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 400,
|
2019-01-11 01:48:37 +00:00
|
|
|
"sensor_limit": 460,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 340,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.4.1.705.1.5.5.0",
|
|
|
|
|
"sensor_index": "upsmgBatteryVoltage.0",
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_type": "apc-mgeups",
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_descr": "Battery",
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_current": 594,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit": 683.1,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit_low": 504.9,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.2.1.33.1.4.4.1.2.1.0",
|
|
|
|
|
"sensor_index": "1",
|
|
|
|
|
"sensor_type": "rfc1628",
|
|
|
|
|
"sensor_descr": "Output",
|
2019-01-11 22:42:56 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_current": 230.3,
|
|
|
|
|
"sensor_limit": 264.845,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit_low": 195.755,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"sensor_deleted": 0,
|
|
|
|
|
"sensor_class": "voltage",
|
|
|
|
|
"poller_type": "snmp",
|
|
|
|
|
"sensor_oid": ".1.3.6.1.2.1.33.1.3.3.1.3.1.0",
|
|
|
|
|
"sensor_index": "101",
|
|
|
|
|
"sensor_type": "rfc1628",
|
|
|
|
|
"sensor_descr": "Input",
|
2019-01-11 22:42:56 +00:00
|
|
|
"group": null,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_divisor": 10,
|
|
|
|
|
"sensor_multiplier": 1,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_current": 236.3,
|
2018-10-26 20:05:30 +00:00
|
|
|
"sensor_limit": 271.745,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_warn": null,
|
Remove guessed limits for some health sensors, documentation for sensor classes (#10327)
* Default to null for group yaml discovery.
* Update test data for a154bda yaml group null fix.
* Changes to guessed limit functions for sensors.
Original behaviour
===================
The file `includes/discovery/functions.inc.php` contains
`sensor_limit_low()` and `sensor_limit()` which both attempt to
guess a sane value for sensors when no explicitly defined
low_limit or high_limit can be found during discovery.
Both switch control structures used in those two functions
have empty case statements which means that if one of those matches,
it's going to fall through and run the code for each subsequent
case until a `break` is reached.
For example, when we call `function sensor_low_limit(dbm, -13.036)`
it will return the value `-12.3842` instead of `null`. That is
because there will be a match at `case 'dbm':` which falls through
all the way to `case 'cooling':`, where it performs
`$limit = -13.036 * 0.95` before hitting a `break`.
Changed behaviour
===================
Removed `power_consumed` and `count` guessed low_limit and
high_limit, I personally added those sensor classes in PR #9471
when I didn't understand that a switch control structure has
fall-through behaviour so I can guarantee that guessing limits for
those is a mistake on my behalf. It should not be there, only
power_factor can have guessed limits. Apologies for the issue,
I'm still a beginning programmer!
Furthermore, I removed guessed high_limit values for `current`
and `power` because these are supposed to draw higher values as
more devices or components are installed on for example a PDU or
a chassis.
Finally, I removed guessed low_limit and high_limit for `dbm`
sensors, there is a much too large variance in power budget on
commercially available optical transceivers for there to be a
sensible window where you can guess these values.
* Documentation on adding sensor classes.
* Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
|
|
|
"sensor_limit_low": 200.855,
|
2018-10-17 16:03:51 +00:00
|
|
|
"sensor_limit_low_warn": null,
|
|
|
|
|
"sensor_alert": 1,
|
|
|
|
|
"sensor_custom": "No",
|
|
|
|
|
"entPhysicalIndex": null,
|
|
|
|
|
"entPhysicalIndex_measured": null,
|
|
|
|
|
"sensor_prev": null,
|
|
|
|
|
"user_func": null,
|
|
|
|
|
"state_name": null
|
|
|
|
|
}
|
|
|
|
|
],
|
|
|
|
|
"state_indexes": [
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryChargerFault",
|
|
|
|
|
"state_descr": "Fault",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryChargerFault",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryFaultBattery",
|
|
|
|
|
"state_descr": "Fault",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryFaultBattery",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryLowBattery",
|
|
|
|
|
"state_descr": "Low Battery",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryLowBattery",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryLowCondition",
|
|
|
|
|
"state_descr": "Low Condition",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryLowCondition",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryReplacement",
|
|
|
|
|
"state_descr": "To be replaced",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgBatteryReplacement",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputBadStatus",
|
|
|
|
|
"state_descr": "Bad Status",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputBadStatus",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputLineFailCause",
|
|
|
|
|
"state_descr": "No Failure",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputLineFailCause",
|
|
|
|
|
"state_descr": "Tolerance Volt. Out",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputLineFailCause",
|
|
|
|
|
"state_descr": "Tolerance Freq. Out",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 3,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgInputLineFailCause",
|
|
|
|
|
"state_descr": "No Voltage",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 4,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputInverterOff",
|
|
|
|
|
"state_descr": "Inverter Off",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputInverterOff",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOnBattery",
|
|
|
|
|
"state_descr": "On Battery",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOnBattery",
|
|
|
|
|
"state_descr": "On Input Power",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOnByPass",
|
|
|
|
|
"state_descr": "On ByPass",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOnByPass",
|
|
|
|
|
"state_descr": "Not Active",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOverLoad",
|
|
|
|
|
"state_descr": "Yes",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOverLoad",
|
|
|
|
|
"state_descr": "No",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOverTemp",
|
|
|
|
|
"state_descr": "Over Temperature",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputOverTemp",
|
|
|
|
|
"state_descr": "OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputUtilityOff",
|
|
|
|
|
"state_descr": "No Voltage",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 1,
|
|
|
|
|
"state_generic_value": 2
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"state_name": "upsmgOutputUtilityOff",
|
|
|
|
|
"state_descr": "Output OK",
|
|
|
|
|
"state_draw_graph": 0,
|
|
|
|
|
"state_value": 2,
|
|
|
|
|
"state_generic_value": 0
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
},
|
|
|
|
|
"poller": "matches discovery"
|
|
|
|
|
}
|
|
|
|
|
}
|