Re: [PEPr] Comment on Networking::Monitor

Hi Bertrand G., bertrand Gugger wrote:

I've been living in some industry with a few factories, and in each factory a few machines can be computers or PLC on a few nets, with a few human beings around. every alert should go to the right team/person We had to care of the alert system there and it went monstruous. If I need to build some real alert system, I can never use tis Net_Monitor as it is, and it's a pity because pear should furnish all around general support.

I must admit I don't quite understand what you would want to do differently in terms of alerts/services such that Net_Monitor would not do the job. Net_Monitor handles the most common cases I have run across in my years of working with (and being a) network administrator. Typically, a person or group is responsible for any number of servers or any number of services running on any number of servers. By assigning the SMTP and (coming soon) SMS addresses of these responsible persons to the Net_Monitor script that checks these services, the right people can be alerted. You can set up any number of small (dozen lines or less) scripts to run at any time interval you like to handle each of these groups and the servers/services they are responsible to monitor. You can also run multiple monitoring sessions through a single script by assigning a unique state file name for each session, then using setAlerts() and setServices() as appropriate to alternate between the different monitoring sessions for each group. Another common scenario is that someone is appointed "on call" for a set of servers/services for a certain duration of time. Often, this is handled by physically passing around a pager or other device. However, Net_Monitor can also handle the case where everyone has a pager and the alerts need to get routed based on the date. This can be accomplished without changing the state file or services, but by simply checking the date and calling setAlerts() with the new "on call" person's details, so they pick up right where the last person left off in terms of the state of the monitored services. So, by either using a number of small scripts that call Net_Monitor or by using the builtin functions in a single script to change the alerts, services, and state files, you can divide up, "who gets alerted about what" very easily. The only case I have heard you mention that Net_Monitor defintely does not (and to my mind should not) handle is the act of "subscribing and unsubscribing" people to the monitoring sessions. This is something that the end user can accomplish using setAlerts() or even by modifying an ini file that feeds Net_Monitor the list of alerts (see the example) such that when Net_Monitor is next run, the right people are in the list of people to alert based on their most recent subscribe/unsubscribe activity. However, handling the actual subscribe/unsubscribe functionality is not the aim of the package. Hopefully this helps clarify the real worlds use of Net_Monitor. Best, Robert