On 5/2/07, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:
To do that, you would need to associate some "event ID" with each of the
settings that can cause a red/yellow status; e.g. you'd have
HOST=myhost
PROC tnslistener 1 ID=100
PROC httpd 4 ID=20
Hmmmm....this is a bit of a bummer and inspirational. I was hoping
some of the features of the bb-hosts grouping functions would allow
"groups" of "individual checks." In big shops where you have many
groups of people supporting systems is would be a big help, as well as
logically I think a great benefit to "monitoring the right thing" and
sharing configs.
Example, ssh should get monitored. What does that mean? The sshd
proc is up (and of course being trended for instances ;), a listener
is on port 22, /var/log/secure does not have "sshd cannot bind" or
"check_pass", file permissions/integrity on sshd, ssh-keysign are XYZ.
Henrik, I like the idea of every "individual check" being assigned a
"primary key"/eventid because then you could potentially do all this
aggregation/grouping on the server and you are absolutely correct
there could be individual checks needed for multiple "service" or
groups. The security team and the DBA team. If the unique id was
"hidden" and automatic that would be nice too, so that way us humans
wouldn't need to keep the mappings in our heads. So "host proc" could
be referenced and not "event id".
So in the end maybe end up with something like this (please forgive
any syntax slopiness/incorrectness)
SERVICE=ssh
PROC sshd
PORT 22
LOGCHECK /var/log/secure "check_pass"
SERVICE=mysql
PROC safe_mysqld mysqld
HOST=dbserver
SERVICE ssh mysql
Does this make any sense?
Scott