Re: [Mon-devel] Request to include monitor script with distribution
Brought to you by:
trockij
Menu
▾
▴
Re: [Mon-devel] Request to include monitor script with distribution
|
From: Todd L. <tl...@iv...> - 2005-12-21 17:58:43
|
On Sun, Dec 18, 2005 at 01:10:05AM -0500, Ed Ravin wrote: >the version you sent). See attached diffs - I fixed a couple of things >that turned up with "-w", typos in the names for the old MIB, some comments, >and a small sample of coding style things. Oh, and added an env >var for the community, every Mon script that uses communities should >support that (to keep the community name from turning up in the >mon.cgi details). Incorporated all your fixes. >Also, though it's not in the patch, I moved the duplicated array >declarations to the top next to the other globals, and it worked fine. >I'm using Perl 5.6.1, don't know what you have. <sigh> Yes, I wasn't paying attention and I had put the array declaration after the list() function call. Doesn't take a genius to figure out what *THAT* didn't work. >You can provide a label argument to the 'last' statement that points >to where you want to go. Still as a TODO. >I don't like "Rebuilding: 0%" as a status output - I first thought that >the filer was rebuilding the RAID and it's so slow it hasn't even gotten >to 1% yet. You should only add the "Rebuilding" tag if the status shows >that the filer is reconstructing the volume. Done. It shows "normal" now when the value is zero. On Sun, Dec 18, 2005 at 11:56:58AM -0500, Ed Ravin wrote: >filer ONTAP Volume Name Vol State Vol Status >--------------------------------------------------------------------------- >trantor 6.1.2R3 parity disk 8.30 active Rebuilding: 0% >trantor 6.1.2R3 data disk 8.31 active Rebuilding: 0% >trantor 6.1.2R3 data disk 8.23 reconstru Rebuilding: 82% <snip> >BTW, the filer is configured as two volumes, each with their own parity disk, >so it looks like the code needs to learn a bit more. Here's the MIB dump >that shows the different volumes: > >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.1 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.2 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.3 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.4 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.5 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.1.6 = 1 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.2.1 = 2 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.2.2 = 2 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.2.3 = 2 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.2.4 = 2 >enterprises.netapp.netapp1.raid.raidVTable.raidVEntry.raidVGroup.1.2.5 = 2 I think that was the reason why I originally used raidVPlexName instead of raidVDiskName, but both pieces of information are uniquely useful in their own right. A bit more processing could possibly make it so that it prints out a single line for a non-critical array, and only the lines of the reconstructing/failed/offline drives when there is a critical array. That would mean that I need to query both and do a bit of processing first. On Sun, Dec 18, 2005 at 12:38:41PM -0500, Ed Ravin wrote: >I hurriedly put netappraidstat.monitor into production and noticed that >it didn't support this filer: > NetApp Release 5.2.3P1: Wed Jan 12 11:15:32 PST 2000 Yes, it stops checking below 6.0. If the raidVTable exists in that MIB, then it could be added to the regex that checks the version numbers. But reading on... >And the filer helpfully had an empty sysDescr string, further confusing >things. The problem is that it didn't support raidVVol - this filer is If we can't get the ONTAP version, then we can't use it. So I'd say that we should not try to make it use that old a version (though arguably that old a version is the one most in need of monitoring). >so old, it only has one volume, thus no MIB entry for it. No big deal, >that filer should be in a museum and we're decomissioning it soon. >However, I did notice this fallout from adding -w: > $ ./netappraidstat.monitor --forceold nonexistent > Use of uninitialized value in concatenation (.) or string at > ./netappraidstat.monitor line 96. > 96 push (@ERRS, "could not create session to $host: " . $SNMP::Session::ErrorStr); Fixed. Ed, thanks for the testing and suggestions. This version has your fixes in it. When you feel this is suitable for production, let me know and we'll submit it to Jim for inclusion into cvs--it's not currently in HEAD as far as I can see, and I can think of no reason why it would have been put in the 1.0 branch. Please reference the attached script (not a patch, it's the full script). -- Regards... Todd OS X: We've been fighting the "It's a mac" syndrome with upper management for years now. Lately we've taken to just referring to new mac installations as "Unix" installations when presenting proposals and updates. For some reason, they have no problem with that. -- /. Linux kernel 2.6.12-12mdksmp 3 users, load average: 0.13, 0.09, 0.09 |