Details
-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
None
-
any
Description
I have added support for aruba networks controllers and access points.
I will attach my patch.
One thing which is a bit unusual is that the aruba access points don't have an SNMP agent themselves. Instead you can get information about each access point from the controller it is connected to. I added support for the access points in a similar manner to getting information about ports of a switch.
Attachments
Activity
I will try to make everything use "accesspoint" and see if I can consolidate down to one rrd file per accesspoint.
> Are the different RRDs optional?
I could probably put them all in one per AP.
>Why are you using numeric oids? this is weird :
Because the OID contains the mac address of the AP in binary. If I don't use numeric APs, non-printable characters show up as periods (.) so multiple APs have the same index eg ..F.... So the numeric OIDs are necessary.
Thanks!
Would you believe it, but I've just started to merge generate_port_link into generate_entity_link. (we're trying to do away with "entity-type" specific functions).
Don't worry though, I'll merge generate_ap_link and generate_ap_url at the same time.
And now...
This part:
$ap=accesspoint_by_id($id);
$device = device_by_id_cache($ap['device_id']);
$rrd_filename = $config['rrd_dir'] . "/" . $device['hostname'] ."/".
safename("arubaap-$ap[name].$ap[radio_number].nummonclients.rrd");
Should be done in auth.inc.php, a 'graph category', like "port" or "sensor" is a grouping of things where the id passed is related to the same thing.
Are the different RRDs optional? Is there scope to merge any of them? Each RRD file we write involves at least a read to read the pointer, and a write to write the pointer, on top of the data writing.
Why are you using numeric oids? this is weird :
$type =$aruba_apstats["1.3.6.1.4.1.14823.2.2.1.5.2.1.5.1.2.$radioid"][''];
And I just noticed, but the table should be called accesspoints, as the id field is "accesspoint_id" (it makes it easier to do a lot of other things later). It'd also be a good idea to make sure the same term is used everywhere in the code, i.e. ap vs accesspoint vs access_point, it gets hard to guess 
Could you also attach a couple of rows from your database from the accesspoints table, and the matching rrds in a .tar.gz? So i can put them on the dev install and see how it looks.
I don't think anyone else has every committed anything which creates a new entity category before. It's hard work :>
adam.
Yeah, this is one of the reasons we recommend people making changes are in #observium on freenode 
changed to use rrd_rra
(which wasn't even there in the svn version I started with a month or so ago. I was basing my code on the previous code, as was suggested on twitter...)
Look at how we now build RRDs. You need to use the config option that we use in all other rrdtool_create calls.
Like :
rrdtool_create($mempool_rrd, "--step 300 DS:used:GAUGE:600:0:U DS:free:GAUGE:600:0:U ".$config['rrd_rra']);
At some point we intend to have per-module rra configurations, but not yet so the above is ok.
with the rest of the files (I hope)