I want to graph when the device was available and when not, so that I can show the needed people when the device went down, at what time etc. So I want it to graph like this.
1| | |
| | |
| | |
So I powered the device on so it went to 1, and then it went down again it goes to 0.
And thats what I want to do with the graphs.
P.S My graph post fails, just imagine it was looking nicely hehe
Hum. I think a good way to do this would be to write a custom datasource for ping availability. The custom provider could check d.pingStatus() which passes back an integer for up down. The data would then be put in to an RRD which is easily graphable. Whats more is this method doesn't require an extra test and is substantially less overhead than an extra test.
I would disassemble the Core DNS monitor pack and model off of that. It contains a custom datasource for collecting dns repsonse.
Isn't it possible to just create a command datasource that pulls a script for instance.
and then in the script have something like.
The problem is I have no idea how to put this together so that it will actually work, if this is the solution to my problem it would be awesome!
It is possible, however, it's a script. Running a script to do this will easily septuple the load of the test and create a huge amount of scheduler competition. Zencommand based tests also don't scale well.
On small instances it doesn't hurt to make use of command based tests. If I understand right you're looking for a test that scales- you'll need to make use of ZenOSSs special functionality to do that. Zencommand doesn't scale for the same reason that nagios and zabbix don't scale- they run individual tests and create scheduler competion and chaos.
I understand what you are saying, only problem is I have no idea how to disassemble the DNS monitor and assemble it again,nor any idea how to code a daemon.
The DNS monitor package, does it monitor a IP to check if it is up, then I can just use it as it is for all my devices to do the graphing etc without changing any code ?
EDIT: Nope, doesn't look like it will work without editing.
The package is a zipped up egg file. Egg files are just zip files renamed to .egg. To disassemble it just unzip it twice. Unfortunately there is little way to add scalable functionality that hasn't already been coded without knowing python. I highly reccomend learning the basics of python if you're going to be using ZenOSS as a large scale. If development is not an option there are more than a few of us on here that do development contracting.
Sigh, so this will not fix it then. On that thread they suggested decreasing the RRD values (If you have many devices), which I did. From 0.5 to 0.15. And also increasing the parralel jobs. Maybe to like 30-50 ?
Follow Us On Twitter »
||Latest from the Zenoss Blog »||Community||Products||Services||Customers||About Us|
Copyright © 2005-2011 Zenoss, Inc.