[hobbit] Passing non-linux data to hobbit for monitoring and graphing.

[Kern, Thomas]

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