Visiting the Open Source Monitoring Conference 2016, Part 3

Monitoring most often deals with IT infrastructure. Sometimes it diverges a bit and starts caring about temperature and humidity, but in most cases that’s still limited to datacentre monitoring. In a talk at the Open Source Monitoring Conference 2016, Antony Stone covered some real world monitoring that goes a bit further than temperature monitoring. On a more classic-IT note, Shlomi Zadok covered system management with Foreman and security/compliance reporting by integrating with OpenSCAP. Let’s see what these fine gentlemen talked about.

Two cows

Antony started with somewhat more common and easily available monitoring – temperature, humidity, air pressure. Other types of sensors are less common and more expensive, but one could still expand in monitoring power consumption or solar power generation, gas consumption, water usage, rainfall – it all depends on what sensors you have access to. For data geeks, it is of course mandatory to monitor the environmental data indoors and outdoors. Think about the nice graphs, figuring out the rate of heat loss depending on the temperature difference…

Banking. Sure, the banks do a lot of monitoring of their own systems. But what interesting data could the user grab? The example used was monitoring the account balance and creating nice – or not so nice – graphs of it.

A graph, showing DeutscheBank account balance

Wait, monitoring account balance? What about security? From the two banks covered, one of them offered a way to log in with a reduced set of credentials and have a read-only access – view the balance, but no way to transfer the funds or make any other changes. The other mentioned bank supposedly does not offer such a feature, thus the demonstrated balance monitoring system had full access to the account. Gotta admit, that sounds scary to me and I would not automate account access if reduced capability login was not available.

Online retailers. At least as much internal monitoring as the banks, if not more. What would a consumer want to monitor there? Well, the price of something you are interested, surely! There might be a variation in price depending on the time of the day, day of the week, or season. Or there could be really weird changes in the price that an outside observer would find very hard to explain.

Graph showing Amazon item price

Graphing the price over time could give you an idea when to get that thing you have wanted for a long time but never got to shelling out for it. Note that you probably should not gather such data too often – Antony mentioned an email from Amazon, expressing disappointment at an automated process accessing the site 🙂

Let’s go countryside now. Buzzzzzzzzz. Modern technology is everywhere now, and that also includes beehives. Temperature in a beehive is important, and putting a few sensors in there can tell a lot to the bee keeper. Why a few? Placing three sensors at the bottom/middle/top of the hive can show the difference in temperature. At the bottom, air flows in and variation in temperature is bigger. Going higher, the hive itself absorbs the difference in temperature, and the middle sensor shows less variation, while the top sensor shows the least amount of variation – natural climate control.

Beehhive with a sensor on top of it

On a different note, I have to wonder whether these bees from the UK watch BBC One…

We’re still sightseeing the farm. Our next stop – byre (a cow barn). Turns out, cow pregnancy is not a simple thing. There’s a 20% chance of complications at the first calving – that’s a lot. It drops to 8% for later attempts. Still, on average, 3% of calves die during the birth, and that is both sad and expensive. Cows don’t have husbands to take them to the hospital when the time comes, thus notifying somebody competent – like a vet – is a very good idea. The initial approach is an internal sensor that takes temperature and contractions into account and alerts when the birth is expected to start soon. There are also less invasive options – a sensor could be put on a tail. Hmm, what good would that do? The tail movement can predict birth on average one hour in advance. Oh, the science and technology.

This very practical talk concluded with a large Lego-built gauge that one could move and see angle in a monitoring system, using a rotation sensor to detect the offset in degrees. I have to admit this made me want to drop all the other things next week and play with Lego Mindstorms.

Screenshot of ssh-ing to Lego MindStorms with ev3dev

While these things are definitely practical, they aren’t what most of the IT people do daily. Shlomi Zadok brought us back to the general IT by covering a system management tool Foreman, specifically integrating Foreman with OpenSCAP for security and compliance automation and reports.

Foreman started out as a user interface for Puppet, but soon grew to include support for Salt, Ansible, Chef and other solutions. It also supports provisioning to bare metal, libvirt, VMware, OpenStack,
EC2, Docker, Rackspace… well, nearly anything. The focus here was on integration with OpenSCAP – an collection of open source tools, implementing the SCAP, Security Content Automation Protocol – a standard, maintained by NIST.

As a sidenote, OpenSCAP page has this great suggestion on improving security:

People in the security space love acronyms! Just saying some of these out loud makes your infrastructure more secure.

OpenSCAP provides the tools to scan systems for compliance and even a graphical frontend to configure how the scan should be performed, SCAP Workbench. The OpenSCAP security scan is NIST certified, thus it might be possible to simply run the scan and provide the report to auditors – a great timesaver.

So where does Foreman come into all this? Being a system management tool, it allows to run the OpenSCAP scan manually, as well as schedule it and generate reports on the results. Assigning the proper policy to a host downloads all the needed data on that host, runs the scan and uploads the report to Foreman.

These reports start out at a very high, shiny level. We can see how many tests passed, how many failed, how many were inconclusive – and the distribution of the severity of the failed tests.

Foreman scan results
Screenshot from

A practical demo followed, showing creation of a new compliance policy, scheduling it for Tuesday and waiting for it to run. Well, not really – it was run manually right there. The report doesn’t just tell you that something is wrong, for most of the found issues it also shows the reasoning why that is considered to be an issue. Even more, for some of the most common issues it will also provide commands or a short script to remedy the issue. These commands can be run on a single host from Foreman, but they can also be run on many hosts – for example, on all the hosts where the issue was found.

The OpenSCAP project also has this awesome tagline that gives them extra points:

Audit, Fix and be Merry

Leave a Reply