From: Frank D. <ke...@dr...> - 2003-02-12 00:02:45
|
Op Tuesday 11 February 2003 23:33, schreef u: > TODO. I found the TODO, I swear I looked before I sent that last email. > Guess I was in the wrong directory. I think I'll start off by changing > logThis to logExtended (To get familuar with the code again) Then I'll try > to group hosts. I would also like to have some default templates like web > servers that would check http https ssh without having to add them each > yourself. hi !! (aha you're back) well, this happent in the mean time: - patrick s. vogt joined 2 days ago. kmon wasn't really alive before he joined, i did not do any work on kmon between your patch (extinfo right ?) and before yesterday.. - herber hraeber sent a german translation and build system fixes - patrick implemented kmonsystemtray.* stuff and fixed some other stuff - and i started working on kmon again today (i fixed your extinfo patch, it works okay now) and now we were thinking about a redesign of some parts of kmon, the idea is we want a hierarchic structure instead of a simple list... * a 'host' has several roles - eg mailserver, webserver,... - , * that implies several monitors (http ping, ...) ... another possible abstraction is 'services' * a host has several dependant hosts (eg mailserver depends on router, because if router is down, mailserver will not be reachable) just like the original mon * this should all be possible without confusing the user, i don't think that'll be easy :) btw, i don't think the exact details of this all are totally clear yet (maybe patrick already has a clearer image, don't know). another idea is getting rid of the awful config dialog (its confusing and buggy now) and doing everything in the main GUI (there will be a main tool bar with buttons like 'new host/...' , 'edit' , 'remove' 'disable' and so on) btw, about the download links: aargh.. i'll fix them ASAP. there is more stuff on the page that ain't relevant anymore, will look into it and btw, as a belgian i don't know anyting about employment in utah but i hope you'll find a solution soon :) greetings, frank P.S. i put a tag (not branch) on current cvs (BEFORE_REWRITE_TAG) maybe we could put out a small kmon 0.3 maintenance with the fixed extinfo and the rmb, there is no official kde3.1 release neither, and so we have something before the rewrite starts ?? P.P.S you maybe want to join the just-created kmon-devel, see the lists page on our project or mail 'help' to kmo...@li..... |
From: Patrick S. V. <pat...@al...> - 2003-02-12 16:35:03
|
On Wednesday 12 February 2003 01:01, Frank Dekervel wrote: > * this should all be possible without confusing the user, i don't think > that'll be easy :) btw, i don't think the exact details of this all are > totally clear yet (maybe patrick already has a clearer image, don't know). yep I have an image, but normaly my images are rather for the adv user than for the luser... ... but having a adv user option might be a good idea anyway. > another idea is getting rid of the awful config dialog (its confusing and > buggy now) and doing everything in the main GUI (there will be a main tool > bar with buttons like 'new host/...' , 'edit' , 'remove' 'disable' and so > on) or even drag'n drop items > P.S. i put a tag (not branch) on current cvs (BEFORE_REWRITE_TAG) maybe we > could put out a small kmon 0.3 maintenance with the fixed extinfo and the > rmb, there is no official kde3.1 release neither, and so we have something > before the rewrite starts ?? ha, i should read _all_ email first... yeah, lets do a 0.3 release and have our monitors installed to, so kmon can start working without hacking. > P.P.S you maybe want to join the just-created kmon-devel, see the lists > page on our project or mail 'help' to > kmo...@li..... how is on this list? shouldn't you put all former devels there? i've created an #kmon channel at irc.kde.org and a kmon-cvs mailing list, but I still have to figure out how to echo cvs logs to the ml cp |
From: Patrick S. V. <pat...@al...> - 2003-02-12 17:01:59
|
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 |
From: Frank D. <ke...@dr...> - 2003-02-12 18:45:15
|
Op Wednesday 12 February 2003 18:14, schreef Patrick S. Vogt: > > hey, i tought i subscribed you to the mailinglist... ain't it done ? > > i'll subscribe brett too since he became active, see other mails ... > > there no archives... :( no ? so whats this: http://sourceforge.net/mailarchive/forum.php?forum=kmon-devel ? :) > > as for the cvs ml, do you know how to do it? > > > have to go now, will read and reply to your mails in an hour or so > > join #km...@ir... > but i'll leave at 1900 MET i'm there i'll make a kmon 0.3 now greetings, frank |
From: Frank D. <ke...@dr...> - 2003-02-12 19:28:18
|
hi! ok, i fixed the Makefile.am so it installs the example monitors, and i fixed the config dialog so it finds those monitors, now it should work out of the box. i put up the tarball here http://www.student.kuleuven.ac.be/~m9823990/kmon-0.3.tar.gz can you try to compile/install it and see if it compiles cleanly and if it works out of the box (it finds the example monitors when there is no pre-existing configfile) if okayed, i'll upload it to sourceforge as a file release and notify freshmeat and apps.kde.com... greetings, frank Op Wednesday 12 February 2003 19:44, schreef Frank Dekervel: > i'll make a kmon 0.3 now |
From: Frank D. <ke...@dr...> - 2003-02-12 12:15:35
|
hello, > I was thinking the same thing. How I was thinking to approach the problem > would be to set up everything like objects. You could have a Web Server > Object that would watch http,https,ssh or what ever someone might have on a > web server. You could create your own service objects to meet your own > needs. (My old job had a Mail server that also did DNS) well, that was what we meant with 'roles', a server can have several roles... > Once you have created your service object you could then assign that object > to a server. Then group the servers such that all the DNS servers could be > shown in a summary (collapsable tree). If we keep it flexable enough > admins could create the trees however they want. So they could group > things logical, by location or both. 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. > 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 > | | +-DNS Server1 > | | +-DNS Server2 > | | > | |- Web Servers > | | > | |-Web Server1 > | | > | |-http > | |-https > | > |-Site 2 > | > | |-DNS Servers > | | > | | |-DNS Server3 > | | | > | | | |-bind > | | | |-ssh > | | > | | +-DNS Server4 > | > | +-Router > | > | |-Web Servers > | > | +-Web Server2 > | +-Web Server3 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). 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 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 > +-Site 3 > > |-Localhost > | > |-ssh > > --You could collapse the whole tree to just show a "summary" -- > > > +-Site 1 > > +-Site 2 > > +-Site 3 > > +-Localhost > > > * 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 ? > 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. > > 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 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) > 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.. btw, kmo...@li... is the place to mail to :) greetings, frank |