Goal / Scope
Improved monitoring of Ubiquity’s Unifi Cloudkey using Check-MK.
I find monitoring soothing, like a warm blanket. To monitor everything possible just feels good. I want to know what is happening at all times. I recently purchased a Ubiquity AP and corresponding Cloudkey device to manage it. I was able to add SNMP information to the configuration of the AP and pull in some simple information, but when it came to the Cloudkey itself, there was nothing. Determined to get anything more than a simple ping, I found a page that outlines how to enable SNMP on the Unifi Cloudkey. I took the time to walk through the steps of enabling SNMP on the device only to discover only a handful of items were returned, none of which were very useful. It was this point I had an idea. The underlying OS of the Cloudkey is a hacked version of Debian. Why couldn’t I install the Check_MK agent and report via SSH.
Methodology / Process Steps
In order to monitor a Ubiquity Cloudkey appliance with a Check_MK agent doesn’t require much. In fact, it is a similar setup to a standard Linux setup. If not using SSH, install xinetd, then install the agent. Verify the firewall ports are open (6656 by default) and query for services from the Check_MK web console. If using SSH, there are a couple of extra steps, but nothing terrible.
For Standard communication over port 6556
- Using your favorite scp client, upload the check_mk agent to the appliance
- Install xinetd for configurations not using SSH (I recommend SSH for security)
- install check_mk agent using the following command
sudo dpkg -i check_mk-agent-vXXX.deb
NOTE: sudo is only necessary if not running these commands as root, which is the recommended best practice.
- verify the firewall port 6556 is open to the monitoring node
- run a query against the Cloudkey and watch the magic
For SSH encrypted communication
- generate ssh keys using the process here
- validate the monitoring user is able to authenticate using the key
- using a scp client, upload check_mk agent to the appliance
- Install check_mk agent using the following command
dpkg -i check_mk-agent-vXXX.deb
- in the WATO configuration on the check_mk webpage, under Host and Service Parameters, select Individual program call instead of agent access.
- Set a name for the rule.
- Under the “Command line to execute” enter something like the following:
ssh -i /omd/sites/[site name]/.ssh/[identity file] -o ConnectTimeout=10 -l root $HOSTADDRESS$ check_mk_agent
This will create an SSH connection using the identity file specified with a connection timeout of 10 seconds and the user account of root at the ip address of the host (obtained from the individual host configuration) and run the check_mk agent.
To further improve security (as this is setup using a passwordless key pair), the following entry can be added to the SSH key line in the authorized_keys file on the monitored host
command="/usr/bin/check_mk_agent" ssh-rsa AAAAB3NzaC1y....a83
Known Issues / Troubleshooting
This section is for the issues that have well defined and tested solutions.
Problem: | SSH authentication fails and a prompt is displayed for password
Solution: | This is almost always due to 1 of 2 things either incorrect permissions on the .ssh directory or misconfigured SSH settings
- Check the permissions of the .ssh folder and the authorized_keys file itself. The should be set like the following:
On the device being monitored, both the file and the folder should be owned by the user.
The .ssh folder should be set to 700
The authorized_keys file should be set to 600
On the connecting device, verify the same permissions for the .ssh folder and the [identity] file should be set to 600 similar to the authorized_keys file.
Below is an example of the commands to complete these changes
chmod 700 $HOME/.ssh chmod go-w $HOME $HOME/.ssh chmod 600 $HOME/.ssh/authorized_keys chown 'whoami' $HOME/.ssh /authoried_keys
where $HOME is the current users home directory
- Check the authorized_key file on the monitored host,
Problem: | Running a query returns nothing or an error
Solution: | This is usually caused by firewall and / or incorrect installation of the client.
- Check the Check_MK node can access the monitored device on the SSH port using telnet.
telnet [host] [SSH port]
- Manually run the Check_MK agent from the monitored device.
Verify the output of this command. It should contain the counters and information about the host.
Datasource programs with Monitoring via SSH example