Re: Re: Working Version of Net_Monitor - Please Review :)

On Mon, 06 Dec 2004 21:29:46 +0100, bertrand Gugger <bertrand@toggg.com> wrote: > Hi again Robert Peake who wrote: > > >> The resetState() method is samewhat too violent, > >> as it will provoke the resending of all alerts. > > > > resetState() will reset the previous state information. The purpose of > > this feature is to allow end users to reset the previous state, add > > new services and alerts, and run a completely different monitoring > > session if and when the previous monitoring session's state > > information is no longer relevant. > > Excuse me, I did read the code too quick. ;) > Anyway, I don't understand where this resetState() could be used, > as it's just acting on some internal properties which only exist in mean > Monitor object life. > > >> It should be possible to reset only one service for example. > > > > This is something I can look into. I suppose you might want to forget > > that a single host/service combination in a monitoring session has > > returned a non-OK result. However, this seems more rare than clearing > > the session state altogether to me. > > So, e.g. in my monitoring I have put a mail server wich stutter. > I mean for some technical reason, this server going down and try to > reboot all the time. > (unfortunately I recently got this actual case) > So on my lovely handy, I get SMS after SMS saying "up" and "down". > (unfortunately your package was still not ready, so it's a dream) > Then as I know some colleague is handling the stuff, I decide > to shut off the alarm, could be only for me or for everybody. > When colleague solves the problem, he/she likes to rest the alarm. > As was said before this is the responsibility of the app which is *using* Net_Monitor. There is no package in PEAR which is a "Full solution" in and of itself. The point of these packages is to be re-usable for many applications. You could quite easily add a "subscription" frontend to Net_Monitor which would allow all of this but it doesn't IMHO fit into the package directly as it's a different piece of functionality. > >> BTW, it's to be hoping, nobody puts a "\t" in message, > > > > AFAIK, messages returned from Net_* packges don't have tabs in them. I > > will look at possibly quoting the return message just in case. > > AFAYK ! When somebody in year 2047 handle you still widely used package > and forget that, the it's loosed. > When some traduction of your message is madde by someone ignoring this > point, > loosed again. > That's right you could escape the content so to be protected. > > >> I think this save format is quite dangerous. > > What format do you think would be more safe? > I do believe that some kind of serialized xml, > (Hi Justin we just crossed over) > wddx or session_register() > more closer to the PHP variables could be more flexible and safe. > > > > > > > > >> It's not directly concerning your package, but to get it work > >> some user interface would be usefull to handle the services and > >> recipients lists. > > > > > > See the 'examples' directory for an example of using an INI file to > > set up a monitoring session. Using this approach INI files could be > > passed as options on the command line, allowing for easy scheduling of > > monitoring sessions from inside a scheduler like crontab. > > > >> so even have the user (un)subscribe from itself. > > > > > > This would be a simple matter of a Net_Monitor->setAlerts(). I leave > > this up to the end user who integrates this into his/her application, > > since the purpose of Net_Monitor is monitor network services, not > > provide mailing-list functionality. > That's what I mean, you know in my dream story there above > I'm in some restaurant with ..., and I just have my handy there ! > > > >> One technical remark: why do you need to make copy of $this->stuff in > >> $stuff > >> everywhere ? Most often you can directly work on $this->stuff. > >> The same for subarrays, why make a copy ? > >> you may use so many indexes you like as: > >> $secondary[$j]['service'] > > Mostly for readability. I do use multidimensional array references > > where it is obvious what I am doing. Sometimes copying $this->variable > > is just convenient and sometimes it is necessary because I am changing > > the copied variable but do not want to change the class variable. > >> The stateDiff() method could follow both arrays in one loop > >> not need to double loop and reset ! > > Actually, it is necessary to act destructively on both arrays in the > > first set of nested loops. This is because the behavior of the alert > > call is to only return data when there is a problem. So, leftover > > problem states from the previous set of tests have to be identified to > > be reported as having changed to OK. This means removing all > > intersecting states, reindexing the previous state array, and then > > traversing the array setting the message and code to "OK." > > > > If the system were reporting everything, including successes, a > > recursive version of array_diff_assoc would work here. However, it is > > less efficient and really less desirable to report all the OK states, > > since OK states are only reported when they are a *change* from a > > non-OK state. > I never ment that should become recursive. > Nor am I such a guy to run after CPU picoseconds (time is loosed elsewhere) > Just your dream package is running periodically, all the time. > And, imagine, I have a success story for you: it's so cute so I build > a free (or "quite" free) service for all those bloody guyes > they just want to know each 15 minutes if one given web doc has changed. > They just like to get it everywhere just on handy. > My service get 10,000 clients > 2 loops can give 100,000,000 run of irrelevant copies in each functions. > I hope I can give you soon better as blah-blah, > a copy with parallel follow up of the both arrays. > (so far I got it right, it should be possible) > > Don't tell me such a success is out of reach. > Best. > -- > bertrand Gugger (toggg) > -- Justin Patrin