How to Choose the Right Health and Performance Monitoring Tool for IoT

Jonathan Seroussi
jumperiot
Published in
3 min readJun 19, 2017

When examining an IoT device health and performance monitoring solution to integrate with your embedded device code, we chose to focus on open source options. Our thinking is that as the developer working on the device, you’d like the ability to control the code you’re adding to the system. Another consideration is being able to use the code in case the company providing the solution decides to shut down the project (happens with big companies and startups).

One aspect of open source to watch out for is licensing. In general, all the frameworks we examined include a license you can live with. Either BSD, MIT or Apache V2. Watch out from GPL licenses as those will force you to publish your embedded code.

We compared the following options: VMWare PULSE (Liota), Countly, Barracks.io and DevicePilot. We also took a look at a few more options but decided to keep them out: IBM Bluemix (cumbersome), Particle.io (works with particle hardware only), mBed (works with mbed enabled devices only), Runtime.io (work only with mynewt RTOS).

A general comment: it’s fairly easy to get going with Countly and Barracks.io. VMWare and DevicePilot require you to provide details before signing into a demo. In our opinion it sends a message that this is not for agile teams. Why not let us experiment in exchange for an email address?

And now for the grand comparison.

VMWare Liota (Light IoT agent)

Meant to work with VMWare IoT Pulse. Filled with a variety of protocols and communication options, it’s a great way to get going if you’re a Python enabled device. The thing with linux based devices is that they can last a couple of days on a battery or require a permanent power supply. Another interesting point is that this code is meant for gateways. The work to bring the data from the end device to the gateway is something you’ll need to factor in.

Barracks.io

A developer friendly device management platform. Provides a nice tool for monitoring as well. It was pretty tough to find the native C++ SDK (we didn’t find it), a requirement for the lower end bare-metal and RTOS based devices. There are Node.js and Python versions, which leave you again with the linux enabled devices. We did see a nordic nRF example but the gateways in the example are iOS and Android devices.

Countly

A developer friendly mobile crash reporting and analytics tool with an IoT option. Their C++ SDK is handy and minimal but is highly focused Arduino and co. devices. Which segments it as a maker tool rather than a professional tool. One thing to note is that Countly gracefully open sourced their server side as well.

DevicePilot

This tool is entirely different compared with the rest. It doesn’t require coding and only leverages cloud data. The thing is you’ll need to plug your device to something like AWS IoT or similar platform and then stream the data automatically to DevicePilot. It means you do the heavy lifting of moving the data to the cloud in a secure, bandwidth aware, low power manner.

Comparison summary

Our own Jumper Insights

For all the reasons above we created the Jumper uLogger. The uLogger provides a highly optimized embedded SDK for logging health related events in a cloud backend. It provides a secure HTTPS connection, requires minimal bandwidth, works on any device and has a friendly open source license. Feel free to check it out on https://www.jumper.io/insights.

Please send us a note or comment on the post with more options. Here’s a link to our spreadsheet for further research — spreadsheet.

Call for Input

If you find this interesting — signup to get updates from Jumper and join our closed beta.

--

--