Re: separating the monitoring engine from the display

Charles Owens (owensc@enc.edu)
Mon, 22 Jan 1996 16:44:13 -0500 (EST)

On Fri, 19 Jan 1996, Juergen Schoenwaelder wrote:

> Hi!
>
> Alan Hannan <alan@gi.net> said:
>
> Alan> Hmm, this really intrigued me, so I went to look, and it
> Alan> sounds like you're talking about 'netguard'. (Is this
> Alan> right, gurus?)
>
> I already wrote that we don't work on netguard anymore.
>
> Alan> Thanks alot, and I'll look forward to hearing anything at
> Alan> all about the itneraction of a network monitoring server and
> Alan> using tkined as a client....
>
> I will try to briefly look at some possible solutions:
>
> 1) Do it by hand. This means that you can write your personal monitoring
> scripts easily once you know enough about Tcl and the scotty
> extension. This solution has a lot of flexibility, although you
> have to write the code yourself. Available now. :-)
>
> 2) Design a monitoring server like netguard. This solution requires to
> define a common way to describe your monitoring jobs, where the
> data should go and how the data should be filtered/condensed. Tkined
> uses special scripts to interact with the monitoring server.
>
> 3) Split Tkined into a client/server application where you can remove the
> GUI from the `Tkined engine' itself. This leads to a monitoring
> server much like solution 2) but it allows to use the same
> monitoring scripts with and without a GUI. If done right, you will
> be able to connect to the monitoring server, modify it and
> disconnect again. The configuration of the monitoring server is
> simply stored in the *.tki map file (which will be real Tcl code
> instead of the ugly Tcl-like format used now).
>
> 4) Implement a stand-alone monitoring server that uses a database
> backend to store the data and also its configuration. There are
> some sample scripts of this sort in the bones directory (see bogart
> and bogart.conf). This is a variation of 2) and real database guys
> will love a solution like this. Tkined would need some scripts to
> manipulate the database.
>
> I think approach 3) is the way to go. Using a pseudo X11 server might
> be a short term solution. Separating the `Tkined engine' (I have no
> better name for it) from the GUI will allow to feed multiple GUIs
> efficiently and it keeps Tkined independend from software packages
> other than plain Tcl/Tk.

#3 by itself would definately be very nice, but I'd really like to also
like to use tkined as a front end to a network inventory/configuration
database (which is really #4). This seems like the best of all worlds.
The possibilities seem endless. Scripts could be written to tie in
various network services (e.g., DNS, bootp) to the database. It seems to
me that this has so many possibilities that I'm curious as to what
argument there might be for going with just #3 instead? (other than
perhaps #3 is easier to implement)

Wouldn't mSQL be a fine and dandy engine for this?

---
-------------------------------------------------------------------------
  Charles Owens					 Email:  owensc@enc.edu
                                       "I read somewhere to learn is to
  Information Technology Services     remember... and I've learned that
  Eastern Nazarene College            we've all forgot..."   - King's X
-------------------------------------------------------------------------