| » Metadata | » Status |
|---|---|
|
|
| » Description | |
|
Purpose To provide a unified interface for checking the availability of services on external servers and sending meaningful alerts through a variety of media if a service becomes unavailable. Elements The service monitoring aspect of this package is essentially a unified interface to a number of packages designed to interact with Internet services. Initially, this list includes:
And could also include the Net_Telnet package that is currently being proposed once it has become more stable. The alert sending aspect is currently a unified interface to Net_SMTP, with plans to extend this to Net_SMS as well, whereby messages can be generated and sent directly from the package. This makes this package more robust in the event that the monitored servce that goes down is the SMTP relay for the package itself -- the package can still generate and send an SMTP message to an external address. Structure The package object inputs and stores two arrays -- one representing the person(s) to be notified in the event of a failure and the other representing the servers to be monitored. Each person can be assigned a notification type (currently SMTP only). Each server can be assigned any number and combination of services to be monitored (currently SMTP, HTTP, HTTPS, DNS, and FTP). Application The most common application for this package is a simple monitoring script that can be run at a scheduled interval (via php-cli) to check remote services and send an alert if a service is down. Useful Features Custom Subject and Alert Message Net_Monitor optionally takes in parameters to customize the subject line when sending email alerts as well as a simple format for customizing alerts. The default string, "%h: %s: %m" returns, for example, "foo.example.com: SMTP: Operation timed out." Other formats are possible using this pattern. Smart Alerts Net_Monitor stores the previous results of its tests (state) in a user-defined file. Alerts are only sent if the state has changed. This means that if Net_Monitor is invoked on the same set of hosts/services on a regular basis, notifications will be sent only when the state of a host/service changes. Optionally, Net_Monitor can be configured with notify_ok set to 0. This will disable Net_Monitor sending out alerts when a state changes from an error code to a code signifying everything is OK. Net_Monitor can also be optionally configured with notify_change set to 0. This will disable Net_Monitor sending out alerts when a state signifying a potential problem changes to another state signifiying a potential problem (e.g. from 404, meaning Page Not Found, to 0, meaning down). Both settings work independently of each other. Calling Net_Monitor::resetState() deletes the state file and clears variables associated with results for a particular instance of the class, allowing the end user to start a new monitoring session without having to restart PHP. Furthermore, calling Net_Monitor::resetHostState() with a host name and (optional) service name will reset the state for that given host (and service), allowing the end user to reset the state of a single host/service programatically through the Net_Monitor API. Possible Extensions Connection Time Monitoring One proposed extension is the ability to monitor the time it takes to connect to a service and return a value. This could be accomplished using the Benchmark package. By logging this data to a database, graphs of server response over time could be generated. This idea is currently under review, mostly to ascertain how accurate the connection time values would be given that the connections depend upon external classes with variable overhead. Document Change Monitoring Another proposed extension is the ability to check an HTTP or FTP file against a previously stored md5 sum of the file to see if it has changed. This feature would be the responsibility of the HTTP/FTP service clients (wrappers to HTTP_Request and Net_FTP) to accept an array of arguments containing the server fqdn and the file to check instead of just a string of the server fqdn. It is unclear if similar behavior extended to SMTP or DNS would prove useful. Ideas include issuing a VRFY command over SMTP to verify that an account exists on the server or checking that either a zone file has changed or a particular fqdn's IP address has changed on the DNS server. |
|
| » Dependencies | » Links |
|
|
| » Timeline | » Changelog |
|
|