Open peternewman opened 3 years ago
Personally, I think autodetection should be used, since it's more user-friendly and has negligible overhead.
I'm more of a Python guy and pretty far from fluent in Perl, so somebody else should probably write the actual code. But in principle, set:
$BASEBOARD_SYSTEM = '1.3.6.1.4.1.674.10892.1.' $OUTOFBAND_SYSTEM = '1.3.6.1.4.1.674.10892.5.4.'
$BASEBOARD_STORAGE = '1.3.6.1.4.1.674.10893.' $OUTOFBAND_STORAGE = '1.3.6.1.4.1.674.10892.5.5.'
And since there are no shared OIDs that can be used to determine if out-of-band iDRAC is used:
Check if BASEBOARD_SYSTEM + '300.10.1.9.1' exists. If so, use $BASEBOARD_SYSTEM and $BASEBOARD_STORAGE. Else, if OUTOFBAND_SYSTEM + '300.10.1.9.1' exists use $OUTOFBAND_SYSTEM and $OUTOFBAND_STORAGE. Else fail.
Then change all OIDs to be relative to these base nodes.
Also, if out-of-band (at least) check_connectors() should be skipped since there's no table of controller channels (no 1.3.6.1.4.1.674.10892.5.5.1.20.130.2 OID).
Personally, I think autodetection should be used, since it's more user-friendly and has negligible overhead.
Yeah fair point.
$BASEBOARD_SYSTEM = '1.3.6.1.4.1.674.10892.1.' $OUTOFBAND_SYSTEM = '1.3.6.1.4.1.674.10892.5.4.'
$BASEBOARD_STORAGE = '1.3.6.1.4.1.674.10893.' $OUTOFBAND_STORAGE = '1.3.6.1.4.1.674.10892.5.5.'
And since there are no shared OIDs that can be used to determine if out-of-band iDRAC is used:
Check if BASEBOARD_SYSTEM + '300.10.1.9.1' exists. If so, use $BASEBOARD_SYSTEM and $BASEBOARD_STORAGE. Else, if OUTOFBAND_SYSTEM + '300.10.1.9.1' exists use $OUTOFBAND_SYSTEM and $OUTOFBAND_STORAGE. Else fail.
Then change all OIDs to be relative to these base nodes.
Again that all sounds good. I may try and have a crack at this if I can remind myself where I'm using it (and assuming I get some time), but very happy for someone to beat me to it!
Also, if out-of-band (at least) check_connectors() should be skipped since there's no table of controller channels (no 1.3.6.1.4.1.674.10892.5.5.1.20.130.2 OID).
Good spot! I don't know how my code wasn't complaining, or at least I don't think it was.
Also, OIDs for FQDD (preferably DisplayName?) need to be added for all storage checks, and used instead of controller id. So quite a bit of code rewriting there.
And systemStateEventLogStatus is missing for iDRAC, so I guess check_esmlog_health can't be used.
physicalDiskState (1.3.6.1.4.1.674.10892.5.5.1.20.130.4.1.4) also has completely different values than arrayDiskState. For example, 2 means "failed" for arrayDiskState but "ready" for physicalDiskState. So if I have a spare drive it will be reported as failed unless pdisk_state values in check_physical_disks are updated:
my %pdisk_state
= (
1 => 'Unknown',
2 => 'Ready',
3 => 'Online',
4 => 'Foreign',
5 => 'Offline',
6 => 'Blocked',
7 => 'Failed',
8 => 'Non-RAID',
9 => 'Removed',
);
I guess there might be other similar issues. In any case, not as easy as just updating the OIDs.
Hi,
This is mostly a comment for now, for other people's benefit. Unhelpfully the iDRAC has a different set of OIDs for it's data. Applying this patch (which is based on some tweaks of mine so might not apply cleanly to trunk) fetches the data just from the iDRAC locations (hence no PR). It seems to work, but I've done pretty minimal testing.
I don't know if we should add options to switch between the two formats, or auto-detect or something?