After some work elsewhere in i-scream it became apparent that using the device (filesystem) as the key might not work. As an example: swap 7346808 32 7346776 1% /var/run swap 686080 1912 684168 1% /tmp These two mounts have the same device name, "swap", but different mount points. Before this change they would have been treated as the same, even though they clearly have different properties. Using the mount point isn't as ideal as the device, as you could move a mount point on a live filesystem... but that wouldn't cause too many problems as a new Register would just be created.
Changed the Memory Monitor to correctly deal with "kb" values. This parallels the change in the Disk Monitor detailed by this Sourceforge bug tracker: [ #476364 ] disk monitor using 'value' thresholds
A small change to allow the 'thresholdMeasure' to be specified on a per
mount point basis. This seems a good idea because the actual thresholds can
already be specified for individual mount points. Of course, as with the
thresholds, a more global one can be specified which covers all mount of
the mount points.
The format is similar to that for mount points.
Monitor.Disk./fs.thresholdMeasure={PERCENTAGE,VALUE}
Monitor.Disk.thresholdMeasure={PERCENTAGE,VALUE}
Bug Fix for the following tracker ID on sourceforge: [ #479162 ] Disk Monitor - assumption of order As stated in the above bug report, the state of a disk was stored using only it's position in (ultimately) df's output. This position could change at runtime which makes it not that reliable. The consequences of a change in the position would not have been a disaster, but would have caused some confusion. The key for storing a disks state is now the physical device name, as this is will not change. The mount point was considered as the key, but it was decided that this could change at runtime too.
Typo fixes.
Bug Fix for the following tracker ID on sourceforge: [ #476364 ] disk monitor using 'value' thresholds This bug fix addresses the issue with 'kb disk checks' not checking the amount of disk space free, but rather the disk space in use. Whilst this was probably the plan initially, it seems somewhat more useful to check the amount of free space and alert if the value falls too low. This change has now been made. It should be noted that the documentation talks about 'kb of disk in use', which is not correct. The comments in the configuration file, however, talk about the 'absolute value of space free'. We'll take the latter as correct.
Major change in the java package naming. This has been held off for some time now, but it really needed doing. The future packaging of all i-scream products will be; uk.org.iscream.<product>.<subpart>.* In the case of the central monitoring system server this will be; uk.org.iscream.cms.server.* The whole server has been changed to follow this structure, and tested to a smallish extent. Further changes in other parts of the CMS will follow.
Fully javadoc'd all the monitors. Also made a few little changes here and there, removing code that had been duplicated by copying other monitors, and tidying up any silly little things (such has hardcoded integer values).
Modified to use the new style queuing in the local client
modified old comment
Now has support for giving separate mount points
added the option: Monitor.Disk.thresholdMeasure=VALUE/PERCENTAGE Monitor.Memory.thresholdMeasure=VALUE/PERCENTAGE to allow the choosing of what is used to measure the crossing of a threshold.
The whole server package structure has been changed. Old Package: uk.ac.ukc.iscream.* New Package: uk.org.iscream.*
TOTALLY re-wrote the Register class and made appropriate changes thoughout. It is now much more obvious what is going on in many places. The problem was probably caused by doing CPU as a first monitor and hard coding the number of attributes a Register stores. Now if a monitor wants to store multiple attributes, it has to do that itself. This makes alot of things much more readable and inteligable as a result.
The new Disk monitor, allows the monitoring of all disks on a host.
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, select a symbolic revision name using the selection box, or choose 'Use Text Field' and enter a numeric revision.