Scenario
(1) You are responsible for administering one or more network servers and would like to be notified when one of your servers goes down before users complain.
(2) You are paying an ISP to provide network services and would like to measure their reliability to help insure the quality of service.
By combining hierarchical filter rules, traffic statistics, and flexible notification options, IPNetSentryX can function as a sophisticated network monitor. This application note will consider how to configure basic network monitoring.
Using the Default Configuration
Rule 2.5 shows an example of monitoring a server periodically to notify someone if it becomes unavailable. In this example, we send an echo request (ping) every 60 seconds in rule 2.5.1 to probe our NetTalk server. When the “Idle seconds” exceeds 60, the rule matches so it is reset to zero. It’s easy to create rules that fire at any regular interval. In this example, the URL in the parameter field:
- scan://192.168.0.2;limit=1;scanType=lookAround;scanProtocol=ping
specifies to scan a single address. We could have scanned the entire subnet to check several servers, or added more rules similar to this one to scan one subnet after another (additional scan URLs will be queued). We could also have used scan protocol TCP to connect to our server instead of pinging. Refer the help text for the Address Scan tool for more information on address scan URLs.
In rules 2.5.2 and 2.5.2.1 we check for an echo reply from the host at IP address 192.168.0.2 . If no reply is received within 3 minutes (200 seconds), we notify the administrator by E-mail (rule 2.5.1.1.1). You can specify the E-mail address you want notified explicitly as a parameter. If no address is specified here, it defaults to the E-mail address specified to receive the security log in the IPNetSentryX Preferences window. E-mail notification uses Mac OS X’s built-in message framework which depends on the settings in the E-mail tab of the Internet Preferences Pane.
Finally, if the server has been responding to our pings for over an hour, we reset the unresponsive count so we can report the next time the server goes down (2.5.2.1.1.2).
To test additional servers, we could append more rules similar to 2.5.2 and its children.
Rule 2.5 is disabled by default since it needs to be customized for your servers if desired. Notice if a parent is disabled, its children will be skipped even though the individual children might still be enabled.
Monitoring an ISP
To monitor a cable modem or DSL ISP, we might ping to our Name Server three times every 30 minutes and log if there is no response. At the end of each month, we could review the log to see how much downtime there was. Rule 2.5.1 below shows how we can send 3 probes once every 30 minutes.
Multiple "scan" or "lookup" URLs are queued and sent one after another with a short pause in between. By using the Lookup tool instead of the Address Scan tool, we could test a name lookup, or use a dynamic DNS service to check if a temporary DNS name is available.
Please send questions, comments, or suggestions using our general requests form:
http://www.sustworks.com/site/sup_questions.html
Top
Back to IPNetSentryX Application Notes
|