Rob,
The problem is that this is scattered across several different places in the Hobbit architecture.
- Detecting the numbers. In a client-side (or server-side, though more rare) script, you do whatever you need to do to get some numbers. You format these numbers and send them to Hobbit. All Hobbit is looking for is the header line where you give it a color. The rest is just text that Hobbit will faithfully store and repeat back to you as date under the column you have selected. Knowing that only the first line is important, then you can do WHATEVER you want to show your numbers. Knowing that you will be parsing this text when you receive it, it is very helpful to put the data in a format that is easy to recognize and parse later, but is still readable to the human eye.
Another note -- you need to do all of this on new columns -- don't try to augment the existing Hobbit tests.
To debug: simply eyeball the text that is listed as column detail for your test. If Hobbit is getting it, and assigning a color, then you are out of the gate.
- On the Hobbit server, you write a custom parser script. This script is called with three parameters -- the column name (aka test name), the node name associated with the test, and a file name. What your script should do is branch appropriately according to the test name, and then read the file, parsing it as needed. The script can be written in any language (Perl comes to mind if you don't like shell). But keep in mind that there is ONLY ONE parsing script allowed, and it needs to be able to service all of your custom tests.
When you find the numbers you want for your test, you simply write to STDOUT the sequence that Hobbit is looking for to put your data in RRDS. ANYTHING else that you want to say in your script needs to be directed to a log file, or some other place.
You have to tell the Hobbit server to use your script -- this requires modification of the hobbitlaunch file to change the parameter list for the hobbit_rrd modules. Notice that there are two of them -- one for data, and one for status.
To debug: run your new test script by hand, supplying a bogus node name, the name of the real test, and the name of a file. I found it helpful to snag all of the test from the column detail and save it in a file, and then use that file as the file parameter. All you should see come out of your script is the RRD language -- first the DS statements, then the file name, and finally the data record. You can write it all to one RRD, or to several, depending on what you write out.
- Now that RRD's are being created, you have to go and create graph definitions in hobbit-graph.cfg and you have to tell Hobbit about them so you can see them. You can choose from the wealth that is already there to get examples or "borrow" code. You will need to consult the RRDTool documentation to understand these graph definitions, because Hobbit graph is simply passing these definitions through to RRDTool for graphing.
Now you need to update the Hobbit server configuration to include your graphs in both lists -- TRENDS and TEST2RRD. I could not keep things straight, so I ended up calling my graph definitions by the same name as my tests. So for test "foo" I create a graph definition "foo" instead of "bar".
To debug: First, are the RRD entries being created? You should see them in the data directory underneath the name of the host where the client-side test is being run.
Next, is there data being written to the RRD? You can dump the contents with RRDTool, but I forget the syntax. All you are looking for is that your data is ending up in the right place.
Next, can you see your graphs? If you don't see a graph at all on your test page, then you probably have not identified it correctly to the Hobbit server in the hobbitconfig. If you see a broken link where you expect a graph, the problem is probably with your hobbitgraph.cfg file -- you made an error specifying the graph.
I have created 7 or 8 custom tests with graphs and everything. The first one took several days, then I got a lot faster.
I wish I had time to be more exhaustive in the instructions...
Good luck!
GLH
-----Original Message----- From: Rob Munsch [mailto:rmunsch at solutionsforprogress.com] Sent: Wednesday, October 18, 2006 3:03 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Sending data from script to an rrd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ralph Mitchell wrote:
On 10/18/06, Rob Munsch <rmunsch at solutionsforprogress.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hubbard, Greg L wrote:
Script #2: is executed by hobbitd_rdd via the --extra-script option. This one extracts relevant information from the incoming status report
and echoes out the RRD creation parameters, the RRD file name, and the
data to stuff into the RRD. Hobbit_rrd reads that and does what's necessary to save the data in an RRD.
maybe i'm not being clear. It's been a long day...
I understand that the goal is to get data to RRD in a format it likes with data and filenames it understands. That part is obvious. The concept is not the issue; i know i want to graph things!
What is not obvious is where to warn hobbit that this info is coming and precisely how to send that info; "echo" clientside was, i thought, read by the client's hobbitd as in a wrapper, but i guess not..?
Rob Munsch Solutions For Progress IT www.solutionsforprogress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNoh/BvBcJFK6xYURAsnbAJ4thkw0rNR4Jvn7WoeX3s5ujdenygCfcz0J HwEES1jq8lQLA8s9YFD/04w= =kA5p -----END PGP SIGNATURE-----
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk