New devices, feature requests, questions
Hi folks,
I've been using Observium for a few weeks now and would like to start getting it work better with some of my unrecognised devices. Is there any general documentation about how to go about adding new device types? I'm not much of a PHP programmer, but i've done enough C & Java that i can usually muddle along. Which bits should i start hacking on?
For what it's worth the main devices i'm looking to support are Xirrus wireless arrays. I notice that Netgear switches are explicitly mentioned as not supported, but the limitation listed in the wiki (that they don't support MAC addresses in the IF-MIB) doesn't appear to be completely accurate - at least for my GS-108T at home.
Some features i think would be really great (and am prepared to work on):
* Filtering on the global memory screen (health/memory/) so that we can view, e.g., just physical memory, or just virtual memory, etc. A simple drop-down at the top of the list would make sense to me. * The global storage screen (health/storage/nographs/) would make a lot more sense to me if the size of the area which was shaded was relative to the size of the storage. Making the width of the gauge grow on a logarithmic scale would make sense to me.
And some questions and related suggestions:
* When we ignore a port, does that prevent graphing and data collection on it, or just notification? I have a lot of edge switches for which i have no use of port up/down notifications, but if it is up, i would like to collect the interface stats. Perhaps the "ignore" tickbox needs to be split into "collect" and "notify"? * Why do HP switches show VLANs as ports, but then never provide any interface statistics for them?
Thanks in advance, Paul
On 03/03/2011 21:34, Paul Gear wrote:
Hi folks,
I've been using Observium for a few weeks now and would like to start getting it work better with some of my unrecognised devices. Is there any general documentation about how to go about adding new device types? I'm not much of a PHP programmer, but i've done enough C & Java that i can usually muddle along. Which bits should i start hacking on?
Whichever bits you'd like to improve. There are things that need done just about everywhere. It's a good idea to be present in our IRC channel when doing work, so that you can communicate with other devs and users.
We've some philisophical ideas about how things should be done that might not match with what you want to do, so always best to check first :)
Also, we prefer to take patches via IRC, as svn-diffs hosted on a www somewhere.
For what it's worth the main devices i'm looking to support are Xirrus wireless arrays. I notice that Netgear switches are explicitly mentioned as not supported, but the limitation listed in the wiki (that they don't support MAC addresses in the IF-MIB) doesn't appear to be completely accurate - at least for my GS-108T at home.
You can probably ignore the things we say don't work. Those were a long time ago, and we now have better methods of detection. I should go back sort that page out.
The low end vendors do have very variable support for things :)
Some features i think would be really great (and am prepared to work on):
* Filtering on the global memory screen (health/memory/) so that we can view, e.g., just physical memory, or just virtual memory, etc. A simple drop-down at the top of the list would make sense to me.
A good idea :)
* The global storage screen (health/storage/nographs/) would make a lot more sense to me if the size of the area which was shaded was relative to the size of the storage. Making the width of the gauge grow on a logarithmic scale would make sense to me.
Well, how do you scale that so it stays relevant? In 5 years time we'll all have disks 10 times the size, etc, etc.
And some questions and related suggestions:
* When we ignore a port, does that prevent graphing and data collection on it, or just notification? I have a lot of edge switches for which i have no use of port up/down notifications, but if it is up, i would like to collect the interface stats. Perhaps the "ignore" tickbox needs to be split into "collect" and "notify"?
Ignore still collects, but alarms and the like should ignore the device. Disabled disables polling.
* Why do HP switches show VLANs as ports, but then never provide any interface statistics for them?
Because like most vendors, HP can't implement SNMP for shit.
adam.
On 04/03/11 19:39, Adam Armstrong wrote:
... Whichever bits you'd like to improve. There are things that need done just about everywhere. It's a good idea to be present in our IRC channel when doing work, so that you can communicate with other devs and users.
We've some philisophical ideas about how things should be done that might not match with what you want to do, so always best to check first :)
I will try to catch up with you guys on IRC as soon as i have a few spare hours. :-)
Also, we prefer to take patches via IRC, as svn-diffs hosted on a www somewhere.
I'm fast losing my svn-fu after switching my personal stuff to git, but hopefully i'll be able to work this out with a bit of prodding.
...
* The global storage screen (health/storage/nographs/) would make a lot more sense to me if the size of the area which was shaded was relative to the size of the storage. Making the width of the gauge grow on a logarithmic scale would make sense to me.Well, how do you scale that so it stays relevant? In 5 years time we'll all have disks 10 times the size, etc, etc.
My idea was that the entire width would be used to show the largest figure in the system and everything would just be scaled logarithmically between that and the smallest one (at, say, 10 pixels wide).
And some questions and related suggestions:
* When we ignore a port, does that prevent graphing and data collection on it, or just notification? I have a lot of edge switches for which i have no use of port up/down notifications, but if it is up, i would like to collect the interface stats. Perhaps the "ignore" tickbox needs to be split into "collect" and "notify"?Ignore still collects, but alarms and the like should ignore the device. Disabled disables polling.
That seems to work for devices, but not for ports - there's just ignore, and it seems to disable polling.
Paul
On 05/03/11 10:03, Paul Gear wrote:
...
And some questions and related suggestions:
* When we ignore a port, does that prevent graphing and data collection on it, or just notification? I have a lot of edge switches for which i have no use of port up/down notifications, but if it is up, i would like to collect the interface stats. Perhaps the "ignore" tickbox needs to be split into "collect" and "notify"?Ignore still collects, but alarms and the like should ignore the device. Disabled disables polling.
That seems to work for devices, but not for ports - there's just ignore, and it seems to disable polling.
Hi Adam, Tom, and others,
I tried to get you guys on IRC today, but it seems you weren't around. I've created two patches for this. They were created against the svn trunk which was up-to-date as of about 02:00 UTC today. (I hope they meet your coding standards; cut & paste coding is my speciality. ;-) )
* http://gear.dyndns.org/~paulgear/patches/observium-port-disable.patch This adds the concept of disabled ports as well as ignored. Disabling disables polling, ignoring disables notifications. I plan to use this on all my edge switches which connect end-user devices which are often turned off overnight or rebooted during the day. I still want to collect data when they up, but i don't care if they're down. * http://gear.dyndns.org/~paulgear/patches/observium-port-outofsync.patch This one changes the outofsync status (red colour) to check both the ignore and disabled flags on a port, instead of just the ignored status. Apply after observium-port-disable.patch.
There are a couple of things that my patches don't handle:
* Update of the database schema: i couldn't work out how to trigger this except by changing the static config file that said not to touch anything below the comment line. * Distinguishing between administratively down (/ports/admindown/) which is called "disabled" in the ports menu, and disabled from my patches' perspective, which means to disable polling.
Any feedback appreciated.
Regards, Paul
...
* http://gear.dyndns.org/~paulgear/patches/observium-port-disable.patch <http://gear.dyndns.org/%7Epaulgear/patches/observium-port-disable.patch> This adds the concept of disabled ports as well as ignored. Disabling disables polling, ignoring disables notifications. I plan to use this on all my edge switches which connect end-user devices which are often turned off overnight or rebooted during the day. I still want to collect data when they up, but i don't care if they're down. * http://gear.dyndns.org/~paulgear/patches/observium-port-outofsync.patch <http://gear.dyndns.org/%7Epaulgear/patches/observium-port-outofsync.patch> This one changes the outofsync status (red colour) to check both the ignore and disabled flags on a port, instead of just the ignored status. Apply after observium-port-disable.patch.There are a couple of things that my patches don't handle:
* Update of the database schema: i couldn't work out how to trigger this except by changing the static config file that said not to touch anything below the comment line. * Distinguishing between administratively down (/ports/admindown/) which is called "disabled" in the ports menu, and disabled from my patches' perspective, which means to disable polling.Any feedback appreciated.
A couple of further thoughts:
* The port summary calls ports administratively down "shutdown" - perhaps the ports menu should use this terminology as well, and we could add an extra menu item for "disabled". * It would be great if there was a way to set a device type (e.g. "edge switch", or "access layer switch" if you want to be all Ciscoey about it) which would set this flag on all ports by default. * What would be /really/ nifty is if we could determine which ports to ignore automatically by using the presence or absence of an LLDP neighbour on the port.
Regards, Paul
On 05/03/11 10:03, Paul Gear wrote:
...
...
* The global storage screen (health/storage/nographs/) would make a lot more sense to me if the size of the area which was shaded was relative to the size of the storage. Making the width of the gauge grow on a logarithmic scale would make sense to me.Well, how do you scale that so it stays relevant? In 5 years time we'll all have disks 10 times the size, etc, etc.
My idea was that the entire width would be used to show the largest figure in the system and everything would just be scaled logarithmically between that and the smallest one (at, say, 10 pixels wide).
Hi folks,
I've implemented this feature, but i'm not sure i really like it that much. You can see sample screenshots and a starting patch here:
http://gear.dyndns.org/~paulgear/patches/observium-r2029-variable-width/
I had to limit the smallest graph size to 1/2 of the available width (in order to fit the labels inside it), which makes it significantly less useful than i thought it would be. If we could have overlapping text & graph, and have the graph scale independently without making the text cram up, it might be a little more viable. But i would have to leave that to someone with significantly more HTML/JS fu.
Does anyone think it's a really good idea? If not, i'm thinking i'll just delete this and move on to something more useful.
Thanks, Paul
Paul,
On Fri, 2011-03-04 at 07:34 +1000, Paul Gear wrote:
Hi folks,
I've been using Observium for a few weeks now and would like to start getting it work better with some of my unrecognised devices. Is there any general documentation about how to go about adding new device types?
There's a short list in the DEVELOPING file in the Observium root. Maybe sometime this could be moved to the wiki, and we would appreciate it if you would report any things missing in that document while adding a new device type :-)
Regards, Tom
participants (3)
-
Adam Armstrong -
Paul Gear -
Tom Laermans