Hi all;

There appears to be a problem with jffnms.  When a unix system adds or
removes storage devices the usage graphs get messed up.  I will attempt
to explain better by example.

I had a system with a number of storage type devices that were
discovered and polling correctly.  These devices were mainly local
drives but also included 2 samba mounts of windows drives.  The windows
server became unavailable causing IO errors with the drives, which
caused snmpd to time out (a different problem, not with jff).  In order
to fix snmpd I had to unmount the drives.  

When I unmounted the drives the snmp drive table changed and the
graphing in jffnms ceased to function correctly.  The graphs still
appeared in the performance but they did not contain the correct data.
When I did a manual discovery I found that the drives that stopped
gathering data showed as "not found on host" and all historical data was
gone.  The drives that still contained historical and current data were
mapped to the wrong physical devices.  The only way I was able to reset
the data so that the polls would work correctly was to delete all
storage type devices and then rediscover them, which effectively erased
all previously collected statistics.

>From this situation it appears that fixed storage devices are mapped in
jffnms by hrStorageIndex.X where X is the device number from the MIB.
But in my case when the devices were unmounted the MIB changed the
device numbers because there were less devices.  Had the drives I
unmounted been the last 2 in the MIB I probably would not have seen any
errors.

It seems to me that with disk type storage devices there should be some
checking to ensure that hrStorageDescr.X == the device name for
hrStorageIndex.X in order to ensure that devices continue to poll
correctly when hrStorageIndex.X is changed.  There does not seem to be
any way to remap the hrStorageIndex in jffnms without editing the raw
data in the sql db or deleting all accumulated data.  

Please let me know if there is some better way to deal with this
situation.  Otherwise can you (or we) modify the program to use
hrStorageDescr.X as the key for tracking this type of device?  Even a
way to modify the hrStorageIndex in the jff interface would be useful.

Regards;

Brad

-- 
Brad Hudson
Systems Analyst
[EMAIL PROTECTED]
Telephone: (613) 694-2681
Fax: (613) 759-1651


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jffnms-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jffnms-users

Reply via email to