[hobbit] Passing non-linux data to hobbit for monitoring and graphing.
I prefer A, C, then B as the order.
A) for the lack of any need to modify a hobbit server that is not under my control. Our Hobbit server is run by a different group. It is not on my mainframe.
C) does let me add NEW content like my BACKUP status, but I don't want to call my stuff NEW unless it really is new. If there is an existing Hobbit channel (?) for some data, I want to feed the channel so the non-mainframe admins can see and understand (CPU utilization > 95% can be bad on any platform so mark it red).
B) If I come across some data that really is important and might be important across platforms, I would look into modifying Hobbit to support it.
I haven't gotten a regular Hobbit client to run in my linux-under-z/VM systems but I would hope that it runs as well as the BigBrother clients I have running in some of my linux guests now. My concern here is really with supplying z/VM data to Hobbit. Later, I will be looking at the Hobbit client in linux.
/Thomas Kern /301-903-2211
-----Original Message----- From: Hubbard, Greg L [mailto:greg.hubbard at eds.com] Sent: Tuesday, October 17, 2006 1:26 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Passing non-linux data to hobbit for monitoring and graphing.
It looks to me like you have at least three choices:
A) modify your mainframe agent so it sends data that closely mimics a currently supported system. The easiest way to do this is to pick a "supported system" and then get the agent output from it and roll up your sleeves.
B) Let your mainframe agent send what it sends, but then modify the Hobbit source code so that the mainframe OS is added to the support list. Perhaps you can convince the ever-busy Henrik to do this for you if you can supply him with likely output, like what you just sent.
C) Bite the bullet and add some new columns that are unique to your mainframe system, and write an extermal script to review and parse the output and add to appropriate RRD's. Then create the necessary graph definitions, and update Hobbit to use them. There is useful documentation for how to do this in the standard Hobbit pages.
To me, "B" is the best long term approach, because I bet you may not be the only person who ever runs Linux on the mainframe and wants to manage it with Hobbit (though open source mainframe management does sound oxymoronish). "C" gives you the chance inject meaningful new content (channel info) that won't be found on any x86 Linux system you want to emulate. But "A" would help your mainframe system conform to the other systems.
Other options are left to the reader as an exercise... :)
GLH
-----Original Message----- From: Kern, Thomas [mailto:Thomas.Kern at hq.doe.gov] Sent: Tuesday, October 17, 2006 10:51 AM To: hobbit at hswn.dk Subject: [hobbit] Passing non-linux data to hobbit for monitoring and graphing.
Hello.
I have a non-linux system that I want to supply data to a hobbit server for monitoring. This is a z/VM system on an IBM mainframe. I have a client from Rich Smrcina. Using this client as a template, I want to pass other data to hobbit for monitoring and graphing. I have seen the hobbit webpages and graphs showing data like CPU utilization (System, User, IDLE) and User/Proc counts. Is there a manual that details what fields in what hobbit status messages are recorded and graphed by the default hobbit installation? I would like to know more about what each of the default tests is supposed to show so that I can transform my system's data into the format hobbit is expecting. I would rather not report data to new test columns until I cannot wedge my data into a hobbit format, like a status for my system backups.
/Thomas Kern /301-903-2211
On 10/17/06, Kern, Thomas <Thomas.Kern at hq.doe.gov> wrote:
C) does let me add NEW content like my BACKUP status, but I don't want to call my stuff NEW unless it really is new. If there is an existing Hobbit channel (?) for some data, I want to feed the channel so the non-mainframe admins can see and understand (CPU utilization > 95% can be bad on any platform so mark it red).
I think what Greg meant was, you can send any column header you like in a status message, so make stuff up to suit your needs. Just don't let it be too many characters, or it'll take up too much width. I've done this with many web page checkouts - I have columns labelled 'login', 'logout', 'check', 'db', 'stats', etc. Just don't use 'info' or 'trends'.
Ralph Mitchell
participants (2)
-
ralphmitchell@gmail.com
-
Thomas.Kern@hq.doe.gov