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
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
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."
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
participants (3)
-
craig＠cookitservices.com
-
henrik＠hswn.dk
-
stoners＠verizon.net