Building a Nagios Demo Environment: A Behind-the-Scenes Look

Friends, we’ve got a project, and we’re going to lay out our intentions for it here. If you don’t know me, I’m Michael Bellerue, a Technical Sales Engineer here at Nagios Enterprises. A big part of my job is just giving demos to people who want to see how our software works.

To that end, I created a demo environment for each Nagios Monitoring Solution. I’ve tried to make the demo environment as robust as possible but have been limited by the hardware I could get my hands on. For example, if I want to monitor a switch, I have the option of monitoring a demo switch, sitting on the network somewhere, or monitoring a production switch. The former shows very little real-world data, the latter comes with the risk of accidentally sharing something that we don’t want to be shared with the rest of the world.

No longer.

In our rebuild of the demo environment, we’re hoping to go several steps further: isolating the environment into its own little corner. This means that all traffic would be related to the demo environment. We could also extract the little corner of the network to bring with us to conferences, as well as add new and novel devices for monitoring.

But before I get too far into it, let’s start at the beginning.

The Challenge: Limitations of the Current Environment

As I touched on in the introduction, there are some limitations of the current demo environment.

Network Limitations

Probably the first, and most irritating limitation is trying to demo the basic monitoring of a switch. The switch that we have in the demo environment is a perfectly capable switch, but there’s no real traffic going over it. The systems that make up the demo environment all connect to one of our production switches, which I don’t have access to.

But seriously, I could probably show off throughput and port status of a production switch, but when we dig into flow data with Nagios Network Analyzer, now we’re starting to show off what IP addresses, internal and potentially external, that different systems are talking to. And that makes me a little uneasy.

Clusters and Virtualization

A lot of what we currently have in the demo environment is a mixture of theater of the mind, and smoke and mirrors. To demonstrate Business Process Intelligence, I have a cluster of six web servers, where one web server is down. The truth? Five of those web servers are the same server, just being monitored multiple times. The one web server that is down? Just an IP address that we know is not in use.

Would you like to know what it looks like to monitor a virtualization environment? Sorry. We have an environment that we’re using, but similar to the issue with demoing network gear, we don’t want to risk showing off something crucial in our production environment. I can tell you what each of the wizards will do. But showing is better than telling.

Conferences: How We Currently Ship Our Demo Environment

We like going to tech conferences. Right now, we regularly attend the Red Hat Summit. There are some rumblings that we might sneak in another conference, but for right now, Red Hat is the big one. The trouble we run into is how we want to run demos.

It used to be that we would just VPN into the office and run demos against our normal demo environment. Connectivity at Red Hat has been pretty good to us, but that isn’t something we can count on everywhere we go. What we’ve done for the last two conferences is bring a mini rack or two with us, with a copy of the demo environment.

This was amazingly useful but carried its own drawbacks. Getting a copy of the demo environment to the mini rack environment would take time, and as soon as it was there, the clock was ticking. We would have a block of empty performance data starting the moment we began the transfer, which is often a week, sometimes two before the shipping deadline.

The Rebuild: Goals for the New Environment

With the biggest of the limitations listed out, let’s dive into the goals for the new demo environment.

New Environment Design

Networking: A Dedicated Juniper Switch and a New Wizard Request

Instead of having a demo switch with all of one out of 48 ports actually up and in use, we have a brand-new Juniper switch which will have all of the demo environment hooked up to it. Without spoiling that too much, we’re looking at 10 devices, at least, being plugged directly into the switch. Still a far cry from the 48 total ports being in use, but it’ll be a lot easier to show off 10 ports that are actually in use, versus one port that is just connected so we can get data from it.

This will allow us to show proper throughput utilization, as well as NetFlow data. Hey, as long as we’re here, how would you, our customers, feel about a Juniper Switch Wizard? To say the least, I am hyped for this.

Real Clusters: OpenShift and Proxmox VE

Our two mini racks are destined to become our new permanent demo environment. Rather than running the environment on the same virtualization infrastructure as our production systems, we’ll be able to demo an actual Red Hat OpenShift cluster, as well as a Proxmox VE cluster! These will give us real clusters that we can see in Business Process Intelligence, as well as real systems to demo our OpenShift and Proxmox Wizards against. No more theater of the mind!

Conferences: Built to Travel

With the new setup, we plan to have the demo environment sit on its own little section of the network where we can literally just grab the Juniper switch, and everything connected to it (save for the uplink to the production network of course), and just roll to a conference. In the limitations section, one of the issues is the length of the gap in performance data. There’s going to be a certain amount of gap in the data, just because we’re shipping the environment a few days before the conference. But previously we’d take a copy of the demo environment and put it on the machines. Unfortunately, all of that could happen up to a couple of weeks before we needed to ship the environment. So, we’ve minimized the data gap from potentially a couple of weeks to a few days.

Physical Design at a Glance

• Juniper 48 port switch
• HP mini servers
• Fashionable 10-inch racks
• Proxmox cluster
• Red Hat OpenShift cluster
• Cyberpower UPSes

What’s Next

We’ll post updates as this project moves forward, so stay tuned.

Part of the goal here is setting up for more articles and videos down the line. So if there’s future content you’d like to see, from us in general or something specific, we want to hear about it—let us know by emailing us at [email protected].

This environment gives us the chance to build the content you actually want to see. We’re not in it for the views. We’re in it for the knowledge sharing.