Adding servers is pretty easy with bijk, their website provides the commands step by step for the most of the distros out there. In our particular case we are using ubuntu at our servers.

The first problem I had with bijk was that push method, which doesn’t require you to open up your ssh port to bijk outbound ips and should be your first choice as a sysadmin, didn’t work for us, so we ended up opening up our ssh port to Bijk outbound ips and started waiting for data.

Bijk offers nice and detailed graphs about your servers, the interface is nice and self-explanatory, and offers a pretty useful plugin base including mysql, postgresql, apache, nginx and memcached plugins. So you end up monitoring the required services pretty quick.

However, our experience with Bijk didn’t go on that seamless, on one of our Database servers, bijk-node (the agent you install on your servers to provide bijk with data) wasn’t reporting any data for mysql. After a week of mailing (which was only 3 or 4 consecutive mails long) with bijk staff, a purge&re-install of the bijk-node package fixed the problem.

So, we were getting data from our servers, the graphs were shiny and useful, alerts sounded nice, so we decided to upgrade to a paid plan.

At first our data receive interval wasn’t updated, which resulted in a 15 min poll frequency, which is a bit too low, whereas it should have been 5 mins. It took us a support ticket and a days wait to get our data poll interval to 5 mins.

After all the hassle, Bijk provides a pretty useful and rigid monitoring tool. Other than the problems setting up (and one more thing I will explain in a second), we didn’t have any problems for the last month.

The problem is, bijk has a minimum of 5 minute data poll frequency, and when you set up your alarms, say, for a CPU load of 3, bijk doesn’t send the alarm message if the load of 3 occurs between the data polls. Let me clear things up.

Server X has an average load of 0.1 - 2.5.

We set up our alarm for a CPU load of 3.

Bijk polls data at 19:00, which shows a CPU load of 2.0.

CPU load spikes to 4.2 at 19:03 which ends 30 seconds later at 19:03:30 and goes back to normal range.

Bijk polls data at 19:05, which shows a CPU load of 2.2 again and since 2.2 is still in the normal range, you don’t receive an alarm.

This doesn’t sound too bad since the CPU load faded back to normal value range and indeed everything is fine by 19:05. But if you want to, say, monitor users logged in, a ssh session occurring between 19:01 and 19:04 can go a long way unnoticed if you don’t check the graphs.

So, after all, monitoring is a dirty job. The required work to have a well enough monitoring software up and running is worth the time, but not affordable in dire situations like a close deadline or a product release. Bijk is affordable both price-wise and ease-to-use-wise. Bijk has been a valuable solution to our server stack and hope it gets even better over time.

Bijk is worth a try.

More reading on monitoring and why it sucks:

http://gigaom.com/2012/02/12/why-monitoring-sucks-for-now/