ext hobbit client scripts
list Craig Cook
Given the new client design of sending "raw" data back to the sever so it can decide what the status should be... How can I extend this concept and write an external client script with the same logic... ie. a custom mysql status script that just sends its data back to the central server. The server must analyse it somehow and set the status message, like it currently does for these: UP 1h LOAD 5.0 10.0 DISK * 90 95 SWAP 20 40 MEMPHYS 100 101 MEMSWAP 50 80 MEMACT 90 97 Thanks Craig Cook -- Systems Monitoring Consulting and Support Services http://www.cookitservices.com
list Henrik Størner
▸
On Mon, Sep 12, 2005 at 09:57:51PM -0500, Craig Cook wrote:
Given the new client design of sending "raw" data back to the sever so it can decide what the status should be... How can I extend this concept and write an external client script with the same logic... ie. a custom mysql status script that just sends its data back to the central server. The server must analyse it somehow and set the status message
You need to write two programs:
1) The client side tool that collects the data. Run it as a client
extension, and have it send back the data in using a "data"
message. I.e.
$BB $BBDISP "data $MACHINE.mydata"
2) A Hobbit server module to process the data.
Server modules are all of those programs in hobbitlaunch.cfg
that runs "hobbitd_channel --channel=X hobbitd_bla". For a start,
try running
~hobbit/server/bin/bbcmd hobbitd_channel --channel=data cat
(you must be logged in as the hobbit user). This just dumps the
incoming "data" messages to the console. You'll see it looks like
this:
@@data#18078|1126595825.225133|127.0.0.1||voodoo.hswn.dk|mydata
<the contents of the data message>
@@
The first line always has
@@data#Seq.no.|Timestamp|SenderIP|Origin|Hostname|Type
and the message ends with "@@"
"Origin" is currently not used and will always be blank.
So your server module - written in C, Perl, Ruby or whatever your
favourite programming language is - now has access to the full
data message sent by your client, and hence it can parse the data
and build a "status" message to generate the final status.
For debugging, You can start/stop modules without having to restart
Hobbit - just run the "hobbitd_channel ..." command on the command line.
--
Henrik Storner
list Jeff Stoner
▸
On Tue, 2005-09-13 at 09:23 +0200, Henrik Stoerner wrote:
@@data#18078|1126595825.225133|127.0.0.1||voodoo.hswn.dk|mydata <the contents of the data message> @@ The first line always has @@data#Seq.no.|Timestamp|SenderIP|Origin|Hostname|Type and the message ends with "@@"
Dumb question....what if incoming data message has "@@" embedded in it? How does hobbitd handle it? -- --Jeff "I need chocolate."
list Henrik Størner
▸
On Wed, Sep 14, 2005 at 08:50:45PM -0400, Jeff Stoner wrote:
On Tue, 2005-09-13 at 09:23 +0200, Henrik Stoerner wrote:@@data#18078|1126595825.225133|127.0.0.1||voodoo.hswn.dk|mydata <the contents of the data message> @@ The first line always has @@data#Seq.no.|Timestamp|SenderIP|Origin|Hostname|Type and the message ends with "@@"Dumb question....what if incoming data message has "@@" embedded in it? How does hobbitd handle it?
Not a dumb question at all. hobbitd handles it fine - so the web display will look OK. But the worker modules handling RRD updates, alerts and the history log updates will probably see a truncated message - and there'll be some noise in the Hobbit logfiles. The mitigating factor is that it has to be <newline>@@<newline> i.e. the "@@" must be on a separate line. I've assumed that sequence was sufficiently unique to not bother with additional safeguards. If it does turn out to be a problem, one could add a length field to the first line of the message to make it clear how large each message is. Henrik