As I mentioned in Part 1 of my series on ZenPacks, you can find hundreds of ZenPacks on the Zenoss Wiki Page. But you may need a ZenPack to monitor a service that hasn’t been publicly posted (if you happen to make one for Google TV, please be sure to let Dave Winter know). Lucky for you, the larger Zenoss community has developed standards and best practices to follow.
But having the tools to create ZenPacks doesn’t justify building your own ZenPack, similar to how having the ability to write applications doesn’t necessarily merit doing so.
So what steps do you need to take before building Dave his coveted Google TV ZenPack—or one specific to your business? Dave outlined several points, including the ones that follow.
1) Identify a Business Objective
As team leader of Zenoss’ new ZaaS solution, Dave explained that his team built out an Amazon Elastic Search cluster for the backend of this new service. “So as soon as we built an Elastic Search cluster, we now had the responsibility to monitor [it],” Dave said.
That’s a pretty obvious business need. After all, if ZaaS lacked a way to monitor its backend, it would be useless (because if ZaaS can’t be bothered to monitor its goings-on, why would you feel compelled to subscribe to its monitoring tool?).
While your particular situation may not be as cut and dried as this example, your business could have a similar monitoring requirement that requires a ZenPack. Perhaps you’re archiving customer purchase histories on a MySQL database, and need the ability to access that database should one of those customers return to your e-commerce site. You’re going to want to know if, for whatever reason, a customer cannot access that information when making a new purchase.
2) Figure Out What Type of Information Your ZenPack Must Obtain to Make it Valuable for Your Purpose
After the ZaaS team was unable to find either an official or community Elastic Search ZenPack, Dave realized they would need to build the ZenPack for its ZaaS implementation. But Dave didn’t want his team just to start throwing things against the wall, hoping they might stick:
I didn't want the guys just to blindly go in there and say, “We need to monitor one, two, three, four, and five,” say they're done and then build the specs for a ZenPack in 15 minutes.
For one thing, you don’t want to collect data just because it’s available. You need to figure out what measurable data matter to your business objective. In explaining the importance of determining the right metrics for the Elastic Cloud cluster ZenPack, Dave pointed his people to an article titled Measuring What Matters: How To Pick A Good Metric. According to this post, a good metric should be:
- A ratio or rate that can show comparisons
- Something capable of changing behavior, based on those comparisons.
For example, your proposed ZenPack may be capable of telling you the maximum number of Python “tuples” processed per second. But, as Dave pointed out:
If I don't know what a tuple is or what the significance is of how many it can process a second, then why would I monitor it [or] put a threshold on it? [Because I wouldn’t] know if the threshold at any level is valid [or] what to do if that threshold were exceeded.
So if you can’t answer questions like the ones above or can’t show whether your proposed measurement falls under the rubric of a “good metric,” you don’t need to muddy up your ZenPack with it.
3) Design it so that it Collects Information in an Intelligible and Comprehensive Way
Dave stressed the importance of making sure your ZenPack operated in the way you expect it to operate. Because my coding experience is minimal, he described this in a way that I (and most non-techies) can understand:
It’s not just [whether] the server is up [or] the process is running [or] that it’s on the network. I expect my Elastic Search [ZenPack] to speak, say, English and French, so that when I test it by saying, “Hello, my name is Dave,” it responds by saying, “Hello, my name is Elastic Search 1,” or it will say whatever that equivalent of that is in French when I prompt it in French. So when I start throwing English at it, and it spits back Czechoslovakian, I know there’s a problem with my service. And most likely, if there’s a problem doing these synthetic tests, there will be a problem for my customer, [which] will result in events.
In other words, you want to build your ZenPack in a comprehensive way. Let me quote Dave again because he explains it better than I could:
You’re not just looking at availability. You're looking at, “Are the lights on, are there people home, are they speaking English, so they know who I am? Are they speaking English really slowly...[like they’re] on drugs or something?” These things all need to be taken into consideration when you're building it.
So often I find people have built ZenPacks...where they haven’t taken a complete view into account when they were spec’ing it. “The process is there. It must be working.” You’re full of yourself, but you’re going to get woken up at 4:00 AM by a customer...complaining that [a process] is responding but with rainbows instead of black and white, which is what you wanted.
4) Always keep best practices in mind.
Dave didn’t go too deeply into best practices around building ZenPacks because “They’re well documented elsewhere.” But he again emphasized the need to map out your plans for a ZenPack:
It's like looking at a house and saying, “The lights are on so everything must be okay,” but there's no one in the house. I want to know [if] there’s a mom, a dad, three kids, a dog, how much food does the dad eat, how much food does the mom eat, etc. It looks like a nice house, but I don't know. Maybe the dog ate everyone.
Members of Dave’s team can expect him to drill them on aspects that pivot on the basic concept of “Did you think about this? Did you think about that?” But because Dave most likely isn’t your boss, here’s hoping you’ll internalize such thought patterns before you start coding away. While a dog is more likely to eat your homework than your family, it still makes good sense to make sure you know and understand a situation before it gets away from you.