[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 |