On Thu, 26 Sep 2002, David M Nolan wrote:
> Here's the patch of all my current changes.
thank you
> I'm going to start working on the per-host status tracking in the next
> week or so
this would be a good time to call 0.99.3 1.0 and start a 1.1 branch with
major changes.
let's discuss the details of the mon<->monitor and mon<->alert
communication on the list. what do you have in mind?
here's my suggestion as a starting point, adapted from Mon::Protocol
(the indentation is for clarity but not necessary):
monver 0.1
begin-block=summary
status=0
summary=all is ok except that hostname2 is failing
detail=here's the detail\nwith multiple lines and such
end-block=summary
begin-block=nodestatus
begin-node=hostname1
status=0
summary=hostname1 is ok
detail=esc-quoted detail
var1=val1
var2=val2
...etc.
end-node=hostname1
begin-node=hostname2
status=1
summary=hostname2 is dead
...etc.
end-node=hostname2
...etc.
end-block=nodestatus
here there are two blocks, one labeled "summary", the other labeled
"nodestatus". either could be optional, but at least one is required.
the "summary" block gives a synthesis of the overall status, to be
consumed by humans, while the "nodestatus" block communicates the gritty
details of each node which was tested.
"begin-node" marks a section of status variables which pertain to that
node (most frequently representing a host).
there are some variables which the mon server expects the monitor to
define (status, summary, etc.), but arbitrary variables are supported.
the values are escaped using the esc_str function in the mon code,
or something like it. end-of-record should be a newline, so minimally
newlines in the data should be escaped.
the same format monitors use to communicate status to the mon server
could be used for the server to do the same for alerts. for that matter,
traps could have the same format, also.
the above format has these properties:
- easy to parse
- easy for humans to read (makes debugging easier)
- simple to generate with /bin/sh (keeps monitor writing more
accessible to people)
- sequence of node statuses can be spit to stdout
on-the-fly, no need for the monitor to store status of all nodes
in memory and then re-arrange it for the output
how's that for a start?
_______________________________________________
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
