Re: Patch for snmpdiskspace.monitor (ext2/ext3)
On 16/11/05 20:17, Ed Ravin wrote: Hans, thanks for posting the two patches! I hate to look a gift horse in the mouth, but I have a couple of concerns: No worry about the gift horse. I happen to disagree though. Not that its a big issue. This is not unique to ext2/ext3 filesystems - it's implemented on most Unix filesystems, and as the OP said, the percentage of reserved space is configurable. Well, let he who has another type of filesystem add his own if clause. And yes, it is configurable. I've never seen anybody do configure it though. There's no need. The amount of diskspace you win by configuring it, is obsolete in two months when the next generation of diskdrives comes out with double the capacity. It *could* be configured, yes, but I'm not here to make life easier for some hypothetical person who tweaks a setting that nobody ever tweaks. I'm here to solve my own problems. And it's keeping me pretty busy at that. Thus, I recommend that you make the reservation compensation a configurable option, turned off by default, so that people who upgrade to the new version aren't surprised by the change in behavior. Well, they *should* be surprised. Only 1/2 a :-) here. They do not have as much diskspace available as they thought they had. If they've configured a limit of 5 % they only get an alert when the disk is 100 % full. That's not good behaviour to me. It actually looks more like a bug, though technically it's not. To me free diskspace is what df reports. But YMMV. Likewise for the swap space patch - that too should be an option, perhaps a more generic option like --include-filesystems regexp which would check space on any filesystem whose description matched the regexp. Well, apart from the trivial nitpick that swapspace is not a filesystem, *and* under windows it's called Virtual Memory while under Linux its called Swap Space, this could still be called --include-swapspace but then again, who wouldn't appreciate the extra, relevant, if not to say important information the monitor now reports. So, if anything, I would be in favour of an --exclude-swapspace, to accomodate some hypothetical person who would be annoyed by the extra information the monitor is giving out. I'm not overwhelmed. Come to think of it, it could be as simple as a default setting in snmpdiskspace.cf: *Swap Space 0% *Virtual Memory 0% But it's only a few lines of code. You can do with it whatever you want. I won't be traumatized if you don't see it fit to use them. Neither will I if you decide to surround them with some sort of if clause. These are just two hacks that work for me, and I just posted them back to the list. To me mon is a day-to-day lifesaver, giving me, on an almost daily basis, alerts of the most important kind. I wouldn't know what to do without it. Competing products don't cut it. Oh, yeah, I also have a file.monitor which monitors (log) files for certain strings. That has come from a rudimentary hack to quite an elaborate script. I'll post it after I've brushed it up. Cheers, -- |Hans Kinwel | [EMAIL PROTECTED] ___ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
Patch for snmpdiskspace.monitor (ext2/ext3)
As a long time user of the snmpdiskspace.monitor, I was misled everytime
an alert went of, as it reported significantly more disk free then
available.
Cause was that ext2/ext3 filesystems reserves 5 % for emergencies, ie
root usage only. This diskspace is not available to the general user
(df doesn't see it), but according to SNMP this diskspace is unused
and hence snmpdiskspace.monitor reports much more disk free then is
available in reality. The problem is of course that recipients of the
alert think the amount of diskspace still suffices, while in reality the
situation is more urgent than it looks.
The solution turns out te be really simple: check if the filesystem is
ext2/ext3 and reduce the total diskspace by 5 % in the
snmpdiskspace.monitor. This is indeed the correct calculation for
calculating the true numbers. Alerts now generated correspond with what
one sees with df.
The patch is against Ed's version 1.5 2005/01/13. Attached is the
context diff. It might look impressive, but it's only four lines of code.
Something else, in the new SNMP::Session call I NEED to add a Version
= 2 parameter. Else the monitor crashes with could not get SNMP
info: Unknown user name. Debugging turns out te be quite obscure. I
would prefer it if the monitor came with a parameter or comment or
somesuch that would remind me of its existence.
Cheers,
--
|Hans Kinwel
| [EMAIL PROTECTED]
*** snmpdiskspace.monitor.old 2005-11-16 14:38:10.0 +0100
--- snmpdiskspace.monitor.new 2005-11-16 15:07:05.0 +0100
***
*** 331,337
sub get_values {
my ($host) = @_;
! my
(@disklist,$Type,$Descr,$AllocationUnits,$Size,$Used,$Freespace,$Percent,$InodePercent);
my ($v,$s);
--- 331,337
sub get_values {
my ($host) = @_;
! my
(@disklist,$Type,$FSType,$Descr,$AllocationUnits,$Size,$Used,$Freespace,$Percent,$InodePercent);
my ($v,$s);
***
*** 361,366
--- 361,367
['hrStorageAllocationUnits'],
['hrStorageSize'],
['hrStorageUsed'],
+ ['hrFSType'],
);
***
*** 372,377
--- 373,388
$AllocationUnits= $v-[3]-val;
$Size = $v-[4]-val;
$Used = $v-[5]-val;
+ $FSType = $v-[6]-val;
+
+ # if filesystem == ext2/ext3 then...
+ # ext2/ext3 filesystems reserve 5 % of diskspace for
emergencies.
+ # Substract from total, and get an outcome much more in line
with
+ # what df tells you
+ # .1.3.6.1.2.1.25.3.9.23 is OID:
HOST-RESOURCES-TYPES::hrFSLinuxExt2
+ if ($FSType eq .1.3.6.1.2.1.25.3.9.23) {
+ $Size = $Size * 0.95;
+ }
$Freespace = (($Size - $Used) * $AllocationUnits);
print STDERR Found HOST MIB filesystem: Type=$Type,
Descr=$Descr, AllocationUnits=$AllocationUnits, Size=$Size, Used=$Used\n if
$DEBUG;
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
Re: Patch for snmpdiskspace.monitor (ext2/ext3)
Hans Kinwel wrote: Cause was that ext2/ext3 filesystems reserves 5 % for emergencies, ie root usage only. This diskspace is not available to the general user Actually the reserved space can be set to any value (5% is the default in case you do not specify one an filesystem creation) To see the actual number of reserved block you may try for example dumpe2fs: # dumpe2fs -h /dev/sda2|grep Reserved dumpe2fs 1.38 (30-Jun-2005) Reserved block count: 192860 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) -- Dan Borlovan Level 7 Software ___ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
