“Running on an independent system is almost a need for Xymon,” Malenfant explains. To address this need, the company deploys the monitoring solution on isolated machines that are running within an isolated infrastructure. However, even when Malavix is able to deploy Xymon on unused hardware that its customers already own, the customers must provide the infrastructure to support this hardware—the uninterruptible power supplies (UPSs), air conditioning systems, and so forth. And maintaining two different infrastructures is not an inexpensive or trouble-free proposition.
Malenfant confides that when he and his team returned from SUSECON in Washington, D.C. with their Raspberry Pi in hand, he did not believe that the tiny device would scale. “I was thinking that it [Xymon] would hang the machine first thing,” he says. After all, Xymon would be writing all of its monitoring data to a small SD card on the Raspberry Pi unless it was connected to an external USB storage device to enable more I/O. Still, Malenfant was curious. He began to test the device with Xymon, and to his surprise, “it took a lot of monitored things to slow the machine down.”
This isn’t to say that Malavix didn’t have problems to solve before it had a solution that would work for its customers. One of them was the Raspberry Pi’s lack of a hardware clock. Another was to figure out the optimal number of systems that the Raspberry Pi could monitor before it began to slow down. Malavix originally thought that it could solve the clock problem by attaching a hardware clock to one of the device’s ports, but this didn’t work because available hardware clocks have no drivers that will run on Raspberry Pis. If customers need to disconnect or reboot the Raspberry Pi, they must currently synchronize the device with a Network Time Protocol (NTP) server before starting Xymon and its requisite software packages. Required packages include a web server and web browser to support Xymon’s user interface, which provides graphical and alpha-numeric versions of data from monitored systems. (Malavix uses the Apache 2 web server). For a complete list of Xymon software prerequisites, visit the Xymon installation page at http://xymon.sourceforge.net/xymon/help/install.html. In addition to required software packages, Malavix’s Xymon deployment includes, among other things, Korn Shell software to support its Korn-based external monitoring plugins (see Figure 1).
To determine the Raspberry Pi’s scalability limitations, Malenfant and his team began incrementally adding tests that required the device to check results every three to five minutes. Malavix found that the Raspberry Pi’s scalability varied according to where status processing occurred. For example, when application extensions in client machines did the processing, the Raspberry Pi could handle more tests than it could if it had to do the processing itself, as it did when Xymon polled remote devices via Simple Network Management Protocol (SNMP). Scalability limitations also depended on how much Round Robin Database (RRD) data the Raspberry Pi had to store on its SD card. For example, if a status update required changes to 20 RRD files, the update had a greater impact than did an update with no RRD data.
Malavix stress tested the Raspberry Pi with up to 3000 status tests, which Xymon collected via SNMP from a large number of Ethernet ports. “Obviously, it was too much for the Pi,” Malenfant says. However, Malavix successfully moved the entire Xymon configuration from the Raspberry Pi to a standalone PC that was running SUSE Linux Enterprise Server 12, which proved that the Xymon solution can scale beyond the Raspberry Pi’s inherent limitations. “Staying with SLES [SUSE Linux Enterprise Server] 12 (from ARM to x86) is helpful because we can reuse almost everything done on the Pi,” Malenfant concludes.
With testing at its initial customer deployment now completed, Malavix has determined that as a general rule of thumb, Xymon Server on the Raspberry Pi can handle about 1500 status tests. Malavix estimates that this tentative figure will hold true for an estimated 80% of its customers.
Although the Raspberry Pi supports a number of operating systems, SUSE Linux Enterprise Server 12 is an obvious choice for Malavix because, as Malenfant explains, “we have a big base of customers running SAP,” including SAP HANA, on SUSE Linux Enterprise Server. “Most of the HANA infrastructures are being deployed on SLES [SUSE Linux Enterprise Server] to date,” he says. So leveraging customers’ expertise by deploying a monitoring system that also runs on SUSE Linux Enterprise Server makes sense.
Like the Xymon Monitor systems Malavix has deployed on customers’ x86 and IBM Power hardware, the Xymon monitoring system on Raspberry Pi can monitor a vast variety of network events and conditions. “We have monitoring for SAP, for DB2, for Oracle,“ says Malenfant. “And we can create scripts for about anything.” This includes everything from data-center temperature monitors to applications running on any UNIX-, Linux- or Windows-based machine.
The advantages customers gain by deploying Xymon Monitor on a Raspberry Pi are many and include a dramatically smaller footprint for the monitoring system infrastructure. “You can put it anywhere,” says Malenfant. All you need in the way of infrastructure is a “very very small UPS to put on the battery.” Malenfant adds: “The Raspberry Pi doesn’t heat, it doesn’t make noise. It doesn’t take space. There’s nothing to do with a Pi from a hardware maintenance perspective.”
For customers that don’t have unused hardware on which to deploy Xymon Monitor, another significant advantage is the device’s US$50 cost. This said, Malenfant cautions that the Raspberry Pi is not ideal for business applications in general.
“I honestly think that you can’t run that much on the Raspberry Pi. It’s a small card. It’s not powerful. You have to target things that are very, very optimized,” he warns, adding: “And this [Xymon] is a very optimized package.”