Controller for NControllers from Meru: MC1500Mounting Small-to-medium enterprises and remote offices 30 access points MC4200 Large enterprises and regional offices 500 access points MC5000 Large enterprises, headquarters, large campuses 1,500 access points Meru delivers an all-wireless network that fully supports the enterprise. Log into the controller and enter password; login as: admin. Using keyboard-interactive authentication. Password: abc123 (or your password).
I want to monitor all the wireless access points in our Meruinstallation (1 controller, ~250 AP) using one of our monitor systems:icinga2 (a evolution of nagios).
In this post I describe the two main component of my setup: the checkscripts and the discovery script; both of them are available ongithub. A third(optional but useful) task is to add dependencies to the APs object sothat they depend on the switch they are connected to.
Monitor scripts
Looking in the meru SNMP MIBs I found a table where I can find a lotof informations about the APs, in fact there are both staticinformation (like the name, position, serial number,...) and dynamicone (like operational status, IP, uptime), so I can easily write ascript (icinga still runs external scripts like nagios) that, giventhe table index, checks the Operational and Availability status of theAP in that row and returns the result in the icinga way.
Using python with the library
easysnmp
I write the two scriptsmeru_AvailabilityStatus.py
and meru_OperationalState.py
: they takeas command line arguments the address of the meru controller, its SNMPcommunity and the AP index, they return a proper return code and ashort message. I also configure two custom commands in icinga thatruns this scripts.Now I have to add the APs objects to the monitor system, I want everyAP to be a host with a custom check command (I don't get the UP/DOWNstate with a ping but with a SNMP check) and two services: theavailability and the operational status.
Instead of using the usual
generic-host
template I create a newtemplate meru-AP
and the apply rules for the two services adding thefollowing lines to the configuration:Now I could add a AP host to the monitor simply including themeru-AP template and specifying the index of the AP in the SNMPtable writing something like this:
Discovery of the APs
With the monitor scripts and configuration I can add objects, but Iwould have to configure them manually (they are ~250) and keep theSNMP table indexes updated. This is a good thing to automate becausethe AP are too many and to reduce human errors.
I can get the list of the APs (and their proprieties) from the merucontroller using SNMP, I can generate the config files and load themor add the configuration using icinga REST API, I prefer the secondway since it doesn't require to restart icinga and to touch configfiles.
The first thing to do is to set up a API user in icinga with thepermission to get and modify the configuration, with this user I cando this operations:
- PUT: add a new AP to icinga
- GET: get the configuration of AP
- DELETE: remove an AP from icinga (useful to get rid of old APs)
So now I write a python script (
merudiscovery.py
) that gets the listof all APs from the meru controller and from icinga, it compare themand update the icinga object using the APIs. Since it's so easy to doit I also get other propreties from the controller and add them asvars to icinga (for example the hwtype, the building,...).The script takes as command line arguments the meru hostname andcommunity, the icinga hostname, username and password, it does theoperations and at the end it prints the counter of add, remove andupdate operations.
The script also mangages dependencies (as it is described in the nextsections), if it is not needed you can just comment it out.
Dependencies
What happens if the controller goes down? All the AP host objects willgo DOWN and so many misleading alerts would be fired while only one(the controller is down) is really interesting. This can be solvedeasily adding a dependency to every AP to the controller with thefollowing configuration (MeruController would be the name of thecontroller object in icinga):
Another thing that may happen is that the switch connected to the APmay go down and so extra alerts would be fired again, this time thesolution is not so easy like before.
For every AP I need to know which switch it is connected too, since Idon't have any automatic way to do this I just add this informationin the floor field in the AP configuration on the meru controller,this field will contain the name (as icinga knows it) of the switchand the discovery script will use this information to add a dependency(with a extra check to see if a switch with that name exists).
In our setup we also use Juniper virtual chassis technology, soknowing that the switch (in this case the virtual chassis) is upwouldn't be enough, I have to add a dependency to the member service(the actual physical switch). The discovery script also takes care ofthis using the port name information that is saved in the contactvariable of the AP.
I could have configured dependency with icinga apply rules, I decidedagainst it because I wanted to add extra checks (for example that theswitch actually exists) and regular expression matching in the code,maybe it could be done in the icinga configuration language, but Ifelt more confortable with python.
Possible improvements
My setup works and does what I need, but there are some small thing Ican improve:
- support for multiple controllers: at the moment I have only onemeru controller, so its hostname is written is someconfigurations. It would be easy to extend the scripts to supportmultiple controllers;
- icinga API certificate check: now I'm ignoring the SSLcertificate provided by the icinga API server, this is highlyinsecure and I'm mitigating it running the discovery script on themonitoring master;
- authentication of icinga API: instead of using passwordauthentication certificates would be more secure.