On 5/2/07, Henrik Stoerner <henrik at hswn.dk> 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