Re: [Kmon-devel] Re: Kmon

[Patrick S. V. <pat...@al...>]

On Wednesday 12 February 2003 13:14, Frank Dekervel wrote:
> hmm yup, but here we have to be careful:
> if a server goes down, all the servers that depend on it go down, but if a
> service goes down, the server containing that services goes down.. so in
> one case, dependancies go up in the tree, other case they go down in the
> tree. thats perfectly doable, but it might be confusing.

in the gui i would make difference between those two cases...
since it makes a big difference of (e.g. a smtp server) wether the smtp 
service is down or it just cannot send email on because the uplink is down.

> > So in this crapy example I would have created a DNS Service Object that
> > watched bind and ssh.  A Web Service Object that would watch http and
> > https. A Router object that would check TCP. And a localhost service
> > object that would check ssh.
> >
> > (The + designates a collapsed tree)
> >
> > |-Site 1
> > |
> > |	|- DNS Servers
> > |	|- Web Servers
> > |
> > |-Site 2
> > |
> > |	+-Router
> > |
> > |	|-Web Servers
>
> aha, i think i now understand patrick better, he said about the same thing
> i think (about putting a role in the tree, it makes sense definately, i
> just didn't see it).

you got it! :-)
btw: look at fwbuilder it got a gui like that

> hmm and logical grouping of hosts, it seems to make sense too but it'll get
> really difficult to get dependancies in the same tree. i'd like to have the

since such trees might become infinit recursiv, we must give some attention 
while checking subnodes, i.e. a trigger probably should not descend the tree 
more than one or to levels or even better detect recusion and abort.

> dependancies directly visible, but maybe it ain't needed and we just should
> do something right-mouse-button properties, dependancies, drag a something
> here to make this dependant on that something or so

we should definitivly have RMB properties and give some attention onto how the 
subitems open.

> > *  As far as creating the Service object I figure we would have a place
> > to add the mon scripts.  It would just list them all.
> > *  Another area to create/edit the Service Objects see attached file.  We
> > could also add the action to take if failed here.
> > * When creating a host you just bind it to a Service Object.  I haven't
> > thought of a way to group the servers in a tree but it should be in this
> > dialog.  If we don't put the action to take if failed at the Service
> > Object level we would need to put it here.
> >
> > If my crazy ideas don't make sense and you would like more screen shots
> > to get a better picture let me know and I'll quickly create you some.
>
> well i think it makes sense :) but 'when creating ...' don't you mean you
> create a host and then add some services and/or roles ?

you should be able to do nearly anything, copy a host (and change the name), 
move or copy a service/role from one node to an other.

> > Oh, we might want to also have each server keep track of its own logs and
> > maybe even have a history of them on file so admins can get an idea of
> > total uptime. I would recomend looking at having a DB handle that.

cool idea, we could consider to have a KMonLog object structure...

> > I will try to think of a way to incorporate your dependency idea.  I
> > think its a great idea.  If we tack dependency we can also make smart
> > decision like not have false actions taken.  IE Router goes down.  Kmon
> > might think the router and everything behind it is also down.  Then the

<dreaming>
kmon could initiate rerouting!
</dreaming>

> > poor admin (me) gets a page for the router a page for the mail server a
> > page for the web server . . . . . It should be enough to know the router
> > is down.  On that same tone if every mon test in a service object fails
> > not give pages for 3, 4 or how ever many mon's where attached to that
> > service object.  One that says all services for your.server.com failed
> > should be good.
>
> well, the separating out the logs can be a good idea, keeping statistics
> too, but it would be cool if you could use kmon without a db i think, and i
> would not go into too much detail (kmon is still a desktop app, and
> desktops happen to be shutdown at night :p)

mine is not... ;-)
having KMonLog objects allows us to log into a db, save to logs to files or 
email...  hmmm...
perhaps KMonAllert would be the name...  the gui itself could be just an 
allert...

> > What do you think.
> >
> > (I would also be happy to quickly qt designer up any proto type ideas you
> > or anyone else has.  It might be helpful to make sure we are all going
> > the same direction)
>
> i'd change "parameters" into "extra parameters" and add a checkbox
> "pass hostname/ip as first parameter" in the dialog you made..

and if not set parent() should be asked for a host/ip...

> btw, kmo...@li... is the place to mail to :)

hehe...  i hope i do not bombard you with emails, frank...

cp