-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
If you're going to mess around with that bit of code anyway...
I'm running a bunch of xen servers. On the dom0, I have dozens of logical volumes which all show up as dm-* which presents me with a number of problems
1) The names are totally meaningless 2) The dm-* name is a random string assigned at boot/creation time and has no connection with an actual device. I'm not even sure that the names aren't recycled if you delete a bunch of logical volumes and create new ones without rebooting.
These points actually applies to all block devices, not just the dm-*s, but at least the sd* devices usually require someone to open up the box and change hardware.
It would be very nice if there was an option to have the unix agent maintain this table, since it has access to all the info to map the snmp index number to something tied to the actual hardware or function of the block device. If that was stable, then it would also be feasible to allow the user to associate a description or label to the data.
The only alternative to this is to try and get the snmp folk to use something more stable than these names..... Or, extend snmpd to return the mapping in a user defined oid.... Hmmmmmm
3) The number of these devices make the disk i/o page unwieldy and horribly slow 4) The summary rrd charts are ridiculously large and provide no value 5) Most of this data is duplicated since I monitor the vms as well, which is a performance hit.
I could solve most of these issues if there was a way to tell observium to ignore any device named dm-[0-9]+ (and vif[0-9]+ on the network interface side). Is there some way to filter the devices that observium enumerates, and if not, could you add that pretty please??
On 03/11/2014 10:30 PM, Adam Armstrong wrote:
On 2014-03-11 19:56, Tony Lill wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Running that caused one minor change, but didn't fix anything. The problem is block device names such as returned by the ucd diskio mib are essentially meaningless and and should be assumed to be randomly assigned on reboot, if not more often.
When I was doing my own thing with mrtg, I ran a script that mapped the snmp index to a string that I grubbed out of /dev/disk/by-id
I'm assuming that observium uses that table to map the snmp index to a diskio_id and uses that to store the data. If I go in and fix the index and description, will observium overwrite it. I'm assuming no, since it hasn't fixed itself.
It seems the discovery code is still unfinished, it won't update existing entries, only add or remove them.
From includes/discovery/ucd-diskio.inc.php :
else { echo("."); // FIXME Need update code here! }
This is what happens when you code on the move and forget what you're doing!
I'll fix it in SVN, but it won't make it into CE for a while.
In the mean time, you could truncate the table and rediscover, and it'll be fine.
Thanks, adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
- -- Tony Lill, OCT, ajlill@AJLC.Waterloo.ON.CA President, A. J. Lill Consultants (519) 650 0660 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 - --------------- http://www.ajlc.waterloo.on.ca/ ----------------