[Date Prev]   [Date Next] [Thread Prev]   [Thread Next] [Date Index]   [Thread Index]

 

     multithreaded monitors; SQL for data views

then Jonathan A. Zdziarski's all..
> 
> Another nice feature to consider would be a scalable method of forking off
> processes for monitoring.  if you have thousands of ICMP requests, chances
> are one process isn't going to be able to update them all at once anymore.

Portmon suffers from this in some ways as well I think. It may be because
we had to modify our old version of portmon to probe ports which do not
return any info upon connection (www for eg). I think this was the reason,
cant remember. In any case, I now have a fake monitor called

portMonOK?

with a warning status that should always be on  - its probing a bogus 
address for something, meaning that portmon is working since it will
always fail. When that message disappears from my webnocol, SOMETHING's
wedged somewhere.

> compiling with something like -DMAX_PROCESSES=20 or something the 'C'
> monitors and a similar value in the perl monitors could allow for a shared
> pool of free processes.

This would be a nice way to do things, or to write some truly threaded code.
(Python makes this easy for us rusty C coders who have no chance in hell
dealing with pthreads. ;)

------------------------------------------------------------------------------
BTW - I've been discussing an SQL database for the monitors with our
other admin/programmer here, and I think he will post soon on what he
thinks of all this (hopefully). Basically, his main argument is that
relational databases are not suited for large chunks of time based,
often updated, hierarchical data. You need a tree structure more than
rows in tables that have relations. 

Not that this cant be done in MySQL (or Postgres, our preference, since
Mysql isnt free, and we know Postgres core developpers ;) for eg,
but its probably not as flexible as a database thats aware of the
inherent structure in the data or its sources.

I'll prod him to summarize his ideas here.

Actually, I'll get my other friends to comment to me on this since they were
involved in Carolian Systems' (merged with SoftQuad later) Smart Alert's
development for some time, which Proctor & Gamble used at one point to
monitor their assembly/packaging lines.

/kc
-- 
Ken Chase, Director Operations                  Velocet Communications Inc.
math@velocet.ca                                              Toronto CANADA
--
"Sometimes two [harmless] words, when put together, strike fear in the
  hearts of men -- Microsoft Wallet."                           - Dave Gilbert