Sentry-go® Quick Web Server Monitor
Books On-line
-
v3.5 - August, 2004

 
T
hank you for choosing Sentry-go as your monitoring solution. Having installed the Quick Monitor, you now have access to a powerful tool that can both monitor & alert you to IIS Web Server & related service errors, web site & web page availability, FTP site & upload/download availability, internet port availability, errors written to the Windows Event Logs, IIS log file & other text-based log files, available disk space as well as hardware & software performance on your local server. In some cases, it can also take automatic action in order to resolve a fault without the need for any manual intervention.  

The Sentry-go Quick Monitor is a quick, easy & low cost way to monitor the appropriate areas of your Windows server. It comes with a number of predefined options which allow you you to start monitoring & setup your preferred alerting features in just a few minutes. The Quick Monitor is, however, also an extremely flexible and fully customisable solution, allowing you to tailor monitoring to your individual needs - again, quickly & easily without the need for many different add-ons!
 
We welcome your feedback - if you have a question, comment or want to monitor something you can't with this software, please let us know at Support@Sentry-go.com!
  

What would you like to do ?
 
If, like us, you'd rather get straight to the point than scroll through each section in turn, you're in the right place! Simply select the appropriate link below to see how Sentry-go can help you ... and how easy it is to use! But it doesn't stop there ... if you still have a question or a problem, or want to do something that you can't find, please let us know & we'll do our best to help. Simply e-mail details to Support@Sentry-go.com.
 
Monitoring ...
 
The heart of the Sentry-go system is the monitoring engine, a multi-threaded component that monitors the configured areas on the local server.
  
  
I want to ...
  
  - Monitor Web & related Windows Services on my server Click Here
  - Monitor one or more custom Windows Services on my server Click Here
  - Monitor the ability to access key web sites & check access times Click Here
  - Ensure that key pages return the correct information in a timely manner Click Here
  - Monitor the ability to access my FTP sites for upload & download Click Here
  - Ensure that files can be downloaded and/or uploaded via FTP Click Here
  - Ensure internet services are listening for inbound TCP/IP requests (check port availability) Click Here
  - Monitor entries written to Windows Event Logs on my server Click Here
  - Monitor entries written to the IIS & other text-based log files on my server Click Here
  - Monitor available disk space on my server Click Here
  - Monitor software & hardware performance (predefined or custom performance counters) Click Here
  - Configure general settings  Click Here
  - Configure Web Server security settings Click Here
  - Receive a daily e-mail informing me of the previous days total alerts Click Here
     
 
Response & Alerting ...
 
When a problem is detected, Sentry-go's alerting engine kicks in - either to take action automatically in order to resolve the problem quickly & without manual intervention, alert you & other Administrators to the fault in one or more ways, or both.

Automatic responses allow you, for example, to ...

  • Run a batch file or external organisation - e.g. to clear down temporary files 
  • Reboot the server
  • Restart a Windows Service

Alerting allows you to be informed of an issue as quickly as possible and in a way that suits your environment and working practices, for example ...

  • By e-mail
  • Network message
  • SMS or pager message 
  • SysLog Server
  • Forwarding to an external system etc.
 
I want to ...
 
  - See what alerts I already have set up Click Here
  - Find out about Sentry-go alert levels Click Here
- Notify one or more users by e-mail when an alert is generated Click Here
- Periodically retry sending e-mail notifications if my SMTP server is unavailable Click Here
- Notify one or more users by network message when an alert is generated Click Here
  - Retrieve a Daily Summary Report Click Here
  - Test an e-mail or network message notification Click Here
  - Alert using a different method (use the Alert Engine) Click Here
  - Find out how the Alert Engine works Click Here
  - Using an SMS Gateway  Click Here
  - Create a new Alert Engine file or script Click Here
  - Edit an existing Alert Engine file or script Click Here
- Send a customised e-mail when an alert is generated Click Here
- Log details with a SysLog server when an alert is generated Click Here
- Interface with an external gateway provider to send SMS or pager messages using SMTP (e-mail) Click Here
- Interface with an external gateway provider to send SMS or pager messages using HTTP (web server) Click Here
- Send information to an HTTP Web Server when an alert is generated Click Here
- Run a custom file or script when an alert is generated Click Here
  - Test an Alert Ending file or script Click Here
  - Find our more about Sentry-go "Place Markers" Click Here
- Log alert details to a text or log file Click Here
- Log alert details to a database  Click Here
- Create an alert table to hold the above alert information Click Here
     
 
On-line Reporting ...
  
In addition to monitoring and alerting, there may be times when you wish to access captured or logged information, or view the data being verified by the monitoring engine in real-time. With Sentry-go, you can easily access all this information, and more directly from your desktop browser, without the need for additional server-side software or add-ons.
 
 
I want to ...
 
  - Find out about the web-based reporting options available to me Click Here
  - Access a Sentry-go Web Report  Click Here
  - Find out about the Quick Monitor Home Page Click Here
  - Logon to the web server Click Here
  - View details of recent alerts generated by the Quick Monitor Click Here
  - View the current status of monitored values Click Here
  - View recorded performance information Click Here
  - View a site summary based on an IIS Log File Click Here
  - Run remote commands on the monitored server Click Here
  - Check the current configuration & alert settings Click Here
  - Customise the web pages with my own headers & footers Click Here
     
 
I still need some help!
   
No problem. If you can't find the answer to your question here or on-line at www.Sentry-go.com, or you have a problem or issue with the software, then please let us know and we'll do our best to help ...

Configuring the Sentry-go® Quick Monitor

 
During installation, Setup will have copied and configured a series of default settings, allowing you to start monitoring straight away with a minimum of fuss. The first time the Monitor is run, it too makes automatic checks on these settings and disables any features that are not available, again without any manual intervention being required.
 
To view these parameters & edit their values, define new monitoring tasks and further configure alerting options, simply run the Quick Web Monitor Configuration Utility. This is a quick and easy utility to use, designed specifically to allow you to configure the monitor to suit your needs in just a few moments. It is also fully described in the sections that follow.
 
Starting the Quick Monitor Configuration Utility
 
The Sentry-go Quick Monitor Configuration Utility is used to specify the settings that the monitor will use when monitoring the file system on the local server. To start the utility, simply run the application from the shortcut placed on the desktop or the taskbar's Start/Programs/Sentry-go menu ...

Alternatively, you can launch the application "goQMWebCfg.exe" directly from the directory in which the Quick Monitor was installed. By default, this will be "C:\Program Files\Sentry-go".

Logging On

The Configuration Utility allows you to view and edit the Quick Monitor settings on either the local or a remote PC/Server. To ensure that all facilities are available to you, especially when configuring a server remotely, you should run the Configuration Utility under a user account that has Administrative privileges. If your user ID has insufficient rights on the server, some facilities may be unavailable. To enable all features within the utility, it is recommended that you configure the monitor locally - by running the utility on the same machine that is running the monitor. 
 
In order to run the utility, you simply need to enter or select the server on which the monitor is running and your Sentry-go Administrator's password for that monitor on the target machine. This password is set during installation, but can be changed by selecting the "Password ..." button on the login window ...

By default, the Utility will connect you to the local PC or Server. To connect to a remote machine, simply enter the Windows name of the required machine and click OK. To select the PC/Server from a list, simply click the "..." button. The utility's main window contains a number of tabs. Each defines a specific area of the Quick Monitor and is discussed in more detail in the sections that follow.
  

Monitoring Local Services
 
In order to function, many systems that run on a Windows server are implemented as "Services" - applications that can run without any user being logged on to the system. The Print Server and other key systems operate like this, often launched at server startup and running 24 x 7. If a key service such as the print server should fail, the functions it provides will be unavailable, causing errors for users, other systems and potentially external customers. It is therefore extremely important that you ensure they are running and take immediate action if a fault occurs.    

To check standard and custom services automatically, run the Configuration Utility & select the "Service Monitoring" tab to display the following window ...

The options on this tab allow you to monitor the services typically found on a Windows Web Server machine, in addition to any other custom services you wish to check. If any of these are found to be unavailable or not running, action can be taken and/or notification made to the system administrator. 

Default Service Monitoring Options

The main windows lists all standard service checks along with any custom options that have been included. A tick against the entry indicates that it is being monitored by Sentry-go. Un-tick the entry to stop the service being monitored. The  following services are included on this window ...
 

Ensure IIS Web Server is running Select this option if you want the Quick Monitor to verify that the IIS web server service is running and to raise an error if it is not. You can also verify that the web service is monitoring the standard HTTP & HTTPS ports for incoming requests using the Quick Web monitor - see below.
  
By default, this check is enabled, and the IIS Web Server set for auto-restart, in the event it is not running.
 
Ensure FTP Publishing Service  Select this option if you want the Quick Monitor to verify that the FTP Publishing service is running and to raise an error if it is not. If you are using an FTP service on the local machine, you will probably wish to verify that this service is running. You can also verify that the FTP service is monitoring the standard FTP port for incoming requests using the Quick Web monitor - see below.
   
By default, this check is disabled.
 
Ensure Security Accounts Manager (SAM) service is running Select this option if you want the Quick Monitor to verify that the SAM service is running and to raise an error if it is not. On Windows 2000 and above, this is a key component that ensures applications or users cannot gain access to resources without authentication and authorization. 
    
By default, this check is disabled.
 
Ensure Task Scheduler service is running Select this option if you want the Quick Monitor to verify that the Task Scheduler service is running and raise an error if it is not. The Scheduler can be used to configure and schedule automated tasks on the local machine. If stopped or disabled, automated/scheduled tasks will not be run.
  
By default, this check is enabled, and the Scheduler set for auto-restart, in the event it is not running.
   
Ensure UPS service is running Select this option if you want the Quick Monitor to verify that the UPS service is running and raise an error if it is not. This service manages an uninterruptible power supply (UPS) if one is connected to the local computer. If it isn't running, data integrity and external UPS functionality/availability may be compromised. 
 
By default, this check is disabled. 
  
Note that some external UPS systems provide their own control software, in which case the built-in Windows software being monitored here may not be required.
    
Ensure Windows Management Instrumentation (WMI) service is running Select this option if you want the Quick Monitor to verify that the WMI service is running and raise an error if it is not. This service provides access to Windows Management Instrumentation - a a data-management layer that is included in Microsoft Windows 2000 and above, or as added functionality for older versions of Windows. WMI is designed to simplify the integrated management within a Windows enterprise environment.
 
By default, this check is disabled. 
  
Ensure Windows Time service is running Select this option if you want the Quick Monitor to verify that the Windows Time service is running and raise an error if it is not. This service, which is available on Windows 2000 and above uses a time synchronization system to synchronize the date and time of computers running on a Windows-based network. 
 
By default, this check is disabled. 
  
Ensure Alerter Service is running Select this option if you want the Quick Monitor to verify that the Windows Alerter service is running and to raise an error if it is not. The Alerter is used to notify selected users or computers of administrative alerts. 
  
By default, this check is enabled, and the Alerter Service is set for auto-restart, in the event it is not running.
 
Ensure DTC Service is running Select this option if you want the Quick Monitor to verify that the Microsoft Distributed Transaction Controller (DTC) is running and to raise an error if it is not. The DTC is used to control distributed transactions across processes and machines. 
   
By default, this check is disabled. 
 
Ensure Event Log Service is running Select this option if you want the Quick Monitor to verify that the local Event Log Service is running and to raise an error if it is not. This service is used by applications when they need to log information or error details to the central event logging system. If this service is not running, event log notification is unavailable. Records written to the event log can also be monitored via the Quick Monitor.
   
By default, this check is enabled, and the Event Log Service is set for auto-restart, in the event it is not running. 
   
Ensure Messenger Service is running Select this option if you want the Quick Monitor to verify that the Windows Messenger Service is running and to raise an error if it is not. The Messenger service is used to transmits network and alerter service messages between clients and servers. 
   
By default, this check is enabled, and the Messenger Service is set for auto-restart, in the event it is not running. 
 
Note: To be notified of this error, an e-mail alert must be configured. Network message notifications rely on this service and if this fails, no network message can be raised.
 
 

 
Custom Service Monitoring

The remaining services (if any) on the list are the custom services that are also being monitored. To add new services to the list, click the "Add" button - see Adding Custom Services below for more information. Custom services can either be de-selected or removed from the list permanently. To remove an entry, highlight it and click the "Remove" button. Pre-configured entries can be disabled but not removed. 

Monitoring Options

The lower half of the window allow you define what should happen in the event a failure is detected and an Alert triggered. To set the options for each service, highlight the appropriate service in the list (above), then edit the following values as required.

Respond after this no. errors  This value can be used to specify the number of errors that must occur in succession before the Quick Monitor takes the indicated action.
 
By default, this value is set to 1, indicating that an alert will be raised each time the check fails. If the value was set to 3, three successive errors must occur before the response is run.
     
Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
     
  • Restart the Service.
     
    If this option is selected, the associated service will automatically be restarted by the Quick Monitor in response to the failure. If the restart fails, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.   
 

After response, re-check in (mins) If the specified check fails and the configured does not resolve the problem, this value can be used to defer any future check for a  given period of time. This can be used to give the Administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent or automatic resolutions attempted.
 
If the monitor's automatic response resolves the problem, this value is ignored and monitoring continues as usual.
  
Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
  
Click here for more information on Alert Levels.
  

The above checks performed at regular intervals by the Quick Monitor. The interval itself can be adjusted to suit your needs using the following field.

Perform above checks every ... This value specifies how often, in minutes, the Quick Monitor should run the above checks
  
It is recommended that this value be set to no less than 5 minutes. To disable all the above checks (not recommended), set this value to 0.
 

Adding Custom Services
 
Unlike many other monitoring solutions that require you to manually set up each service you wish to monitor, Sentry-go Quick Monitors come pre-configured with the key services that we recommend are monitored on a Windows Web  Server machine. However, you can also monitor any other service that is installed on the server simply by clicking the "Add" button to display the following window ...

 

To add one or more services, simply select them from the list and click OK. They will then appear in the main services list and can then be further configured. Hold the CTRL or Shift key down to select multiple services from the list. Each service can be added multiple times if required.
 

Monitoring Web Content Delivery

  
Ensuring your web site & key pages are available to users and customers in a timely fashion is extremely important. Likewise, ensuring the pages delivered are correct is also of key importance. Checking these pages manually is a time consuming exercise, yet without performing them, the first report of any problems is usually in an e-mail from a user who can't get your site to work. If no report is made and the problem continues undetected, who knows how many users will be inconvenienced or potential customers go elsewhere ?
 
The Sentry-go Quick Remote Web Monitor allows you to check one or more web pages either locally or remotely. In effect, the monitor runs as a background web browser, periodically checking the pages you define. When a check is made you can ...

  • Check that the page is accessible, optionally within a given time.

  • Check that the page returned contains the given text

  • Check that the page returned doesn't contain specific text (e.g. error text)

  • Check that the page returned hasn't been updated (based on the date returned by the server)

  • Check that the page returned hasn't been changed updated (based on the page's content)

In addition, timings for each page retrieval can also be logged for later analysis. 

Configuring Web Content Delivery
 
To specify the web pages (e.g. .htm, .asp) you wish to check, run the Configuration Utility and select the "Web Content Delivery" tab to display the following window ...

The main list shows the current pages being checked. To add or edit the pages being checked, click either the Add or Edit button. For more information on adding a new page or editing an existing page, click here.
 
The entries at the bottom of the window indicate how the Quick Monitor should respond to any detected failure. The entries are set independently for each connection/query ...

Respond after this no. errors  This value can be used to specify the number of errors that must occur in succession before the Quick Monitor takes the indicated action.
 
By default, this value is set to 1, indicating that an alert will be raised each time the check fails. If the value was set to 3, three successive errors must occur before the response is run.
     
Trigger (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
  
Click here for more information on Alert Levels.
  
Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.   
 

After response, re-check in (mins) If the specified check fails and the configured does not resolve the problem, this value can be used to defer any future check for a  given period of time. This can be used to give the Administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent or automatic resolutions attempted.
 
If the monitor's automatic response resolves the problem, this value is ignored and monitoring continues as usual.
  

Adding or Editing an HTML Page or URL

When you click the Add or Edit button from the main window, the following dialog will be shown. From here, you define the web page you wish to verify and the check you wish to perform ...

From here you can set the following options in order to configure the web page you wish to check ...

Verify this Page (URL) This is the full path (URL) of the page you wish to access and verify. It should be entered in the format http://<Server>/<Page> - e.g. http://www.Sentry-go.com/index.htm. 
 
Be careful when specifying a page that contains frames as the frames page will be verified (e.g. for contents etc.) as opposed to the individual pages themselves. To check an individual page, specify it's URL in this field instead of the frames page. Also, be careful when specifying text that is formatted within the page (e.g. font changes etc.) If tags are found within the text string, the match will fail.
 
Connect to this Port Web server's listen on a given port for inbound requests from browsers. The default port for web servers is port 80. However, if your web server uses a different port, this can be specified here. 
 
If in doubt, this value should be 80.
 
Trigger an Alert if ...
  
The option selected here indicates which check the Quick Monitor is to perform when the page is returned by the web server. Simply select the appropriate option ...
  
The page cannot be accessed Select this option if you simply wish to ensure that the page is available from the web server.
  
The page does not contain the text below Select this option if you wish to check that the returned page contains some known text. Enter the appropriate text in the field below. If this text is not found in the returned page, an alert will be triggered.
 
In order to trigger an alert correctly, the text entered must not appear in any error page generated by your web site. A unique text string, rather than a single word is recommended for this text.
  
The page contains the text below Select this option if you wish to check for an error (or error text) being returned. Enter the appropriate text in the field below. If this text is found in the returned page, an alert will be triggered.

In order to trigger an alert correctly, the text entered must not normally appear in the page that should be shown by the URL. A unique text (error) string, rather than a single word is recommended for this text.
 
The page's last modified date changes Select this option if you wish to be informed when the page's last modified date changes from one check to another. This can be useful if you want to ensure no unauthorised changes are being made. 
 
The page's contents have changed Select this option if you wish to be informed when the page's contents change from one check to another. As with the above check, this can be useful if you want to ensure no unauthorised changes are being made (but with this check, no reliance on the last modified date.
 
Do not select this check for dynamic pages that change content each time the page is retrieved.
 
Time taken to retrieve the page Select this option to ensure the page (and any associated files such as graphics etc.) is returned within the seconds. If the time taken exceeds this value, an alert will be triggered.
 

Once you are happy with the settings entered, click OK to update or add the monitored item.
 

Monitoring FTP Transfers

 
Many sites and external systems transfer files using the File Transfer Protocol or FTP - e.g. to upload or download files to or from the server. Alternatively, you may use it internally for the underlying files that are used by dynamic pages on your site. Either way, knowing that FTP is running is of key importance if these transfers are going to be successful, yet checking them manually can be a slow process, especially when the only true way of checking is to try it!

With the Sentry-go Quick Remote Web Monitor, you can automate all these checks so they're run in the background and the results analysed automatically - in effect, automating an FTP client. If connectivity or transfer problems are found, Sentry-go can either take action itself or alert you to the fault for further investigation, thus freeing you to concentrate on other tasks when FTP transfers are running smoothly. When checking FTP you can ...

  • Check that the FTP site is accessible.

  • Check that a remote file on the FTP server exists - e.g. a file that should always be available for download etc.

  • Check that a remote file on the FTP server does not exist - e.g. an error file.

  • Check that a local file can be transferred to the FTP server (i.e. a PUT request can be made successfully).

  • Check that a local file can be transferred from the FTP server (i.e. a GET request can be made successfully).

  • Check that an FTP command can be run successfully on the server.

In addition, timings for each check can also be logged for later analysis. 

Configuring FTP Transfer Monitoring
 
To specify the FTP sites and files you wish to check, run the Configuration Utility and select the "FTP Delivery" tab to display the following window ...

The main list shows the current sites/files being checked. To add or edit these or new FTP sites/files, click either the Add or Edit button. For more information on adding a new check or editing an existing site/file, click here.

The entries at the bottom of the window indicate how the Quick Monitor should respond to any failure message detected in the selected file. The entries are set independently for each connection/query ...

Respond after this no. errors  This value can be used to specify the number of errors that must occur in succession before the Quick Monitor takes the indicated action.
 
By default, this value is set to 1, indicating that an alert will be raised each time the check fails. If the value was set to 3, three successive errors must occur before the response is run.
     
Trigger (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
  
Click here for more information on Alert Levels.
  
Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.   
 

After response, re-check in (mins) If the specified check fails and the configured does not resolve the problem, this value can be used to defer any future check for a  given period of time. This can be used to give the Administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent or automatic resolutions attempted.
 
If the monitor's automatic response resolves the problem, this value is ignored and monitoring continues as usual.
  
Perform the selected check every ... This value specifies how often, in minutes the associated check should be performed. 
   

Adding or Editing an FTP Check

When you click the Add or Edit button from the main window, the following dialog will be shown. From here, you define the FTP site you wish to verify and the command/check you wish to perform ...

From here you can set the following options in order to configure the web page you wish to check ...

Refer to this check as  This is the name that you will refer to the check as on both web reports and in any alerts generated. It is recommended that a short and accurate description be placed here - e.g. Primary File Download. 
 
FTP Site (or server) This is the name or IP-address of the FTP server you wish to connect to in order to perform the check. It is the same server as used by your web site or external users when FTP transfers are to be made.
 
Connect to port FTP server's listen on a given port for inbound requests from client PCs or other servers. The default port for FTP servers is port 21. However, if you know your FTP server uses a different port, this can be specified here. 
 
If in doubt, this value should be 21.
 
 
Login & Password These fields allow you to specify the user and password used to access the FTP site. If no login is required, you can leave this fields blank. Otherwise, enter the name/password that you would when prompted by your FTP client. If no user/password is specified and the FTP server requests one, the connection will fail.
 
Once Connected The option selected here allow you to define the actual check you wish to make. Simply select the option you want to run from the list ...
  • Verify that the site can be accessed. Select this option if you simply wish to ensure that the FTP site is available and can be connected to. No file transfers or other command beyond logging on will be run.
     
  • Check that the remote file exists. Select this option to connect to the FTP server and then verify that the file specified below exists within the remote directory (also specified below). If the file is missing or the connection cannot be made, an alert will be triggered.
     
  • Check that the remote file does not exist. Select this option to connect to the FTP server and then verify that the file specified below does not exist in the remote directory (also specified below). If the file is found, or the connection cannot be made, an alert will be triggered.
     
  • Check that the local file can be sent (PUT). Select this option to connect to the FTP server and perform a file transfer. In this test, the Quick Monitor will attempt to send the file specified, from the local machine to the remote server using FTP (a "PUT" request). If the connection cannot be made, the local file is missing or the file cannot be transferred, an alert will be triggered.
     
  • Check that the local file can be retrieved (GET). Select this option to connect to the FTP server and perform a file transfer. In this test, the Quick Monitor will attempt to retrieve the file specified, from the FTP server to the local machine using FTP (a "GET" request). If the connection cannot be made, the remote file is missing or the file cannot be transferred, an alert will be triggered.
     
  • Check that the FTP Command can be run. Select this option to connect to the FTP server and run a command directly on the server using FTP. The command, which is specified below can be any command recognised by your FTP server and as such is installation specific. 
Use this local directory This is the base directory that should be used on the local machine. Before files are transferred, the FTP session will use this as the current local directory. So, if you are transferring a file called C:\TEMP\TEST.TXT, you would set this field to "C:\TEMP". 
 
Use this remote directory This is the base directory that should be used on the remote FTP server machine. Before files are transfered, the FTP session will use this as the current remote directory. If you are transferring a file to a remote subdirectory called MyFiles, you would set this field to "MyFiles". If you wish to use the home directory (the directory you are automatically placed in when you connect to the FTP server), the this field to "." 
 
File to send/recv or check This is the name of the file you wish to either send, receive or check. It is this file, plus the local or remote directory specified above that indicates (i) the full path to the source file and (ii) the full path to the target.
 
Delete File after transfer Select this option if, after a successful file tranfer, the newly created target file should automatically be deleted. This option does not remove the source file, just the file that was copied will be deleted.
 
File Type File transfers typically copy either standard text (ASCII) or binary images such as .GIFs, .JPGs etc. This option allows you to specify the correct type of transfer that should be performed. Although this option will not affect the ability to transfer the file itself, an incorrect setting here may adversely affect the file's contents.
 
Run this FTP Command This option allows you to specify the command you wish to run on the FTP server once a connection has been established. Unless you wish to check the results of a command, this option can be left blank.
 
Result If you are checking that an FTP command can be run, this field allows you to specify the text that should be returned by the FTP server in order to indicate success. If the text entered here is found in the command result's output (e.g. simply the return code such as 220), then it is assumed that the check ran successfully. If the text is not found, an alert will be triggered.
 
To find the text that should be entered here, simply run an FTP session from the command line, connect to the FTP server, run the command manually and note the output returned. 
 

Once you are happy with the settings entered, click OK to update or add the monitored item.
 

Monitoring Internet Services & Ports

 
In brief, ports are an important part of internet communications. Services such as web, FTP or mail servers listen on "well known" ports for incoming requests. Browsers & mail clients in turn connect to the server using these ports. Once a connection is established, the request can be forwarded and actioned as appropriate. Checking that a port is ready to receive a new request is therefore an extremely effective way of establishing whether the underlying service is functioning correctly. 
 
Manually checking each port is actually quite complex and time consuming and often involves a number of different client applications. With Sentry-go, the whole monitoring process is automated and run continually in the background. With this method, you can simply be informed of any failures and need not rely on affected users (or potentially customers) to report faults.
  
Configuring Port Monitoring
 
To specify the servers & ports you wish to check, run the Configuration utility and select the "Ports" tab to display the following window ...

The main list shows the current servers, ports & internet services being checked. To add or edit these or new checks, click either the Add or Edit button. For more information on adding a new check an editing an existing one, click here.
 
The entries at the bottom of the window indicate how the Quick Monitor should respond to any failure message detected in the selected file. The entries are set independently for each site listed ...

Respond after this no. errors  This value can be used to specify the number of errors that must occur in succession before the Quick Monitor takes the indicated action.
 
By default, this value is set to 1, indicating that an alert will be raised each time the check fails. If the value was set to 3, three successive errors must occur before the response is run.
     
Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.   
 

After response, re-check in (mins) If the specified check fails and the configured does not resolve the problem, this value can be used to defer any future check for a  given period of time. This can be used to give the Administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent or automatic resolutions attempted.
 
If the monitor's automatic response resolves the problem, this value is ignored and monitoring continues as usual.
  
Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
  
Click here for more information on Alert Levels.
  
Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
 
Alert Level 1 is considered the highest level by the monitor, whilst 10 is the lowest. By default, all checks are set to Alert Level 1.
 
Click here for more information on using and allocating Alert Levels.
  
Network listen ports should be checked every ... This value specifies how often (in minutes) each port should be checked.
  

Adding or Editing a Port Check
 
When you click the Add or Edit button from the main window, the following dialog will be shown. From here, you define the check you wish to perform ...

From here you can set the following options in order to configure the web page you wish to check ...

Refer to this check as  This is the name that you will refer to the check as on both web reports and in any alerts generated. It is recommended that a short and accurate description be placed here - e.g. Main E-mail Server. 
 
Monitor this Port Number This option defines the port you wish to verify. The selection box lists the main "well known" ports you are likely to use. Simply select the name of the service you wish to check and it's default port will be assigned. 
 
To select a different or custom port (or to monitor a standard service that is configured to use a custom port), select "(Other)", and enter the port number in the following field directly.
  
Send this text to the server (Optional) After a successful connection has been made, you can further verify the remote server/service by sending a text command to it in order to initiate a response - e.g. HELO.
 
Many servers (e.g. POP3, IMAP etc.) require a Carriage Return/Line feed (CR/LF) to be sent after the command. To do this, select the check box below.
 
  
Append CR/LF to the above command (Optional) Some servers or remote services such as POP3 & IMAP require a Carriage Return/Line feed (CR/LF) to be sent after the command. This indicates the end of the command. To append a CR/LF, simply select this check box.
 
If the command continually times out, yet the service is running & the command string is correct, then you should ensure that this option is enabled.
 
If in doubt, it is recommended that this option is enabled.

 
Alert if this text is not found within the server's response (Optional) Regardless of whether a command is sent to the server or not, you can also check the response returned - from either the initial connection or the above command. This is particularly useful in order to confirm that the correct service is responding to the request.
 
If the text entered here is not found within the response, an alert will be triggered. Only part of the returned text need be entered here. 
 
To determine the appropriate text returned from the server, connect to the service using a Telnet client and note either the initial response (following the connection) or the response to the command entered above. 
 
 

Once you are happy with the settings entered, click OK to update or add the monitored item.
   

Checking Available Disk Space
 
Ensuring that sufficient disk space is available on your server at all times is often important for the smooth running of critical systems. This is especially true for system drives, drives containing user data and mailboxes etc.

Configuring free disk space verification is very easy with Sentry-go Quick Monitors, simply run the Configuration Utility and select the "Disk Space" tab. From here you can specify the drives you want to monitor, the available space each should have - in terms of megabytes or % free and the action you wish to take, should insufficient space be available ...

The first list shows all available drives on the server. To monitor one or more drives, simply select (tick) each you wish to verify and set the following values for them ...

Drive In the drive list, select the drive(s) you wish to monitor. A tick in the check box indicates that the drive is configured to be monitored. It is generally recommended that most fixed disks are monitored.
  
For this free space Depending on the option button below, this value specifies either the amount of free disk space (in Mb) or the percentage of free space that you wish to check for. If available space falls below this amount, an alert will be triggered. The current free disk space is shown against the drive in the drive list.
  
Mb Select this option if the value above indicates the amount of available disk space - in Mb, that you wish to ensure is available.
 
% of total Select this option if the value above indicates the percentage of total disk space you wish to remain free. 
 
Respond after this no. errors  This value can be used to specify the number of errors that must occur in succession before the Quick Monitor takes the indicated action.
 
By default, this value is set to 1, indicating that an alert will be raised each time the check fails. If the value was set to 3, three successive errors must occur before the response is run.
     
Response to run This option indicates how the Quick Monitor should perform in the event an error is detected. 
  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here.  
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.   
 

After response, re-check in (mins) If the specified check fails and the configured does not resolve the problem, this value can be used to defer any future check for a  given period of time. This can be used to give the Administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent or automatic resolutions attempted.
 
If the monitor's automatic response resolves the problem, this value is ignored and monitoring continues as usual.
     
Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
  
Click here for more information on Alert Levels.
  

Available disk space can be verified at regular intervals by the Quick Monitor. The interval itself can be adjusted to suit your needs.

Free disk space should be checked every ... This value specifies how often, in minutes, the Quick Monitor should verify available disk space on the selected drive.
 
For system drives and drives used by the print spooler, it is recommended that a more frequent check be performed - e.g. 5 - 15 minutes.  To disable all the above checks (not recommended), set this value to 0.
 

 

Monitoring Event Logs, IIS Log & Text-based Log Files

 
Many server-based applications, as well as Windows itself write their errors to the Windows Event Log. In addition, applications may also write messages to their own text-based log files. However, because both of these are typically located on the local machine, proactively monitoring them can be difficult. With Sentry-go, monitoring messages written to one or more Event Logs, text-based or memory mapped files is both quick & easy to achieve. 

To configure Event Log & log File monitoring, start the Configuration Utility and select the "Event Logs & Log Files" tab. The following window will be displayed, allowing you to configure one or more event logs or log files ...

The main list contains all the Event Logs and log files that are currently being monitored by Sentry-go. To disable an entry, simply uncheck it in the list.
 
To specify the response for a particular check, simply highlight the items in the list to edit the following options at the bottom of the window. The entries are set independently for each event log and log file ...

Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command  If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.

In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.
   

Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
 
Click here for more information on using and allocating Alert Levels.
  

Adding or Editing a Monitored Event Log or Text-based Log File  

To add or edit a monitored file or directory, start the Configuration utility, click the Event Log & Log Files tab, highlight any existing entry and click Edit or click the Add button to display the following window ...

From here the following options are available ... 

Refer to this log file or check as ... This is the unique name of the check being made. It is this name that will be displayed on reports and when alerts are generated. It is recommended that a short descriptive name be used for this value.
 
The type of this file is ... The value selected here indicates the type of file you'll be monitoring. It can be set to one of the following ...
  • Application Event Log.
     
    Select this option if you wish to monitor entries written to the Windows Application Event Log.
     
  • System  Event Log.
     
    Select this option if you wish to monitor entries written to the Windows System Event Log.
     
  • Security Event Log.
     
    Select this option if you wish to monitor entries security-written entries written to the Windows Security Event Log.
     
  • Text-based Log File.
     
    Select this option if you wish to monitor records written to a named text-based log file. The name & path & of the file should be specified in the field below.
     
  • Memory-mapped Log File.
     
    Select this option if you wish to monitor records written to a named memory-mapped file. The name & path & of the file should be specified in the field below. 
     
    Memory-mapped files allow applications to map all or part of a file on disk to a specific range of addresses within the process's address space. With memory mapped files, data is often cached and written in blocks. Although this improves performance, it does mean that monitoring must be handled differently to a standard text-based file.
      
    Select this option if the log file is a memory mapped file. For standard text-based log files, you should select the "Test-based log file" instead. If you are in doubt as to the type of log file being produced, please refer to the system's documentation.
     
  • Windows Event Log.
     
    Select this option if you wish to monitor a named Windows Event Log. The name of the log should be entered below.
The Name and/or Path of this file is ... Where applicable, enter the name and/or path of the log file you wish to monitor. 
  • For a "generic" Windows Event Log, enter the name of the log file you wish to monitor - e.g. Application, Security, System, DNS etc.
     
  • For text-based log files, this is the full path and name of the file that you wish to monitor.  System environment variables may be used within this name - e.g. %WINDIR%. In addition, if the filename contains a date, the following formats may be used ...
     
    • $$YY to include the 2 character year
    • $$MM to include the 2 character month
    • $$DD to include the 2 character day.

    If date variables are used, the Quick Monitor will automatically reset the date when that date changes - e.g. at midnight and continue monitoring the new file. 

A log file can be defined multiple times if required, in order to specify separate actions and detect different sets of keywords etc.
  

Event Type  Optional. Check this option and select the type of event you wish to report -e.g. errors, warnings etc. 
 
If not entered, all event types are used in the scan. Event Types are only available when monitoring Event Logs.
 
Event Source  Optional. Check this option and enter the name of the event source (the source name shown in Event Viewer for a particular message - normally the name of the application generating the event) you wish to report. 
 
If not entered, event from all sources are used in the scan. Event Source  is  only available when monitoring Event Logs.
 
Event ID  Optional. Check this option and enter the ID of the message you wish to check. Each event log message is generated with an ID that uniquely defines it within the context of the source application or system. 
 
If not entered, all IDs are used in the scan. Event IDs are  only available when monitoring Event Logs.
 

Defining Keywords or Phrases

The Quick Monitor detects errors in Event Logs and/or log files using Sentry-go's keyword detection technology. Keywords or phrases can be used either to detect an error, or to find errors that you do not wish to monitor. Both are defined at the bottom of this window ...

Add Keyword Click this button to add a keyword or phrase that you wish to monitor to the list. If the keyword or phrase is found, an alert will be triggered, unless excluded keywords are also found.
  
Add Exclude Click this button to add a keyword or phrase that indicates that the message should be ignored. If an excluded keyword is found, the message is automatically ignored, regardless of other settings.
  
Edit Click Edit to edit an existing keyword or phrase listed.
 
Delete Click Delete to remove an existing keyword or phrase from the list.
 
To Trigger an Alert ... must be present  This option determines when an alert should be triggered & keyword detection is defined ...
  • All Phrases.
     
    Select this option if all keywords listed must be present in the message in order to generate an alert. (Excluded keywords do not count in this check).
     
  • Any Phrase.
     
    Select this option to trigger an alert if one or more of the keywords listed are found in the message. 

Keywords or Phrases that Trigger an Error
 
When defining a message, there is no need to add complete error messages to this list - one or more keywords is usually sufficient. By default, standard messages (and all event log errors) are included when Setup installs the Quick Monitor.

The keywords used depends on the file being monitored ...
  • In most cases, generic keywords can be used such as "error", "failed", "insufficient", "problem" etc.
  • To be notified of any message that contains the word "error", simply add the word "error" to the included list (without quotation marks).
  • To be notified of any message that contains the phrase "this is an error", simply add that phrase (without quotes) to the included list.
  • To be notified of any message that contains the phrases "this is an error" and "database", use the [And] escape sequence within the included list. In other words, you'd add "this is an error [And] database" (without quotation marks).

Monitoring the IIS Log File
 
Although the Windows Event Log is a primary source for information and error logging, HTML and delivery errors that the IIS Web Server encounters are written to it's own log file - if logging is enabled on your web server. By monitoring this file, you can detect faults - e.g. HTTP & CGI-related errors such as 404 Page not Found, that have been displayed to users (or potentially customers) of your web sites. As with Event Log monitoring, this file is checked using keyword-based detection and is configured by selecting the "IIS Log File" from the file type selection list. 

System environment variables may be used within this name - e.g. %WINDIR%. In addition, if the file contains variable characters - e.g. the date, one of the following formats may be used ...

  • $YY to include the 2 character year
  • $$MM to include the 2 character month
  • $$DD to include the 2 character day.

If date variables are used, the Quick Monitor will automatically reset the date when that date changes - e.g. at midnight and continue monitoring the new file. 
 
 
By default, the IIS log file is set to "%WinDir%\System32\LogFiles\ex$$YY$$MM$$DD.log". For more details on configuring this log file within IIS, see below.

Defining the Log File within IIS

The IIS Web Server can write out HTTP and CGI-related errors to it's own log file - the log file that the Quick Monitor can then check based on keywords for errors. In particular, it enables you to detect (and therefore  resolve) web-site errors, missing pages, broken links, authorisation issues and other HTTP-related errors. 
 
To use this feature, you must configure IIS to output these errors to a known file - which is then monitored above. To do this, start the Internet Services Manager, navigate to the web site your wish to monitor and display it's properties. A window similar to that shown below will be displayed ...

On this window, ensure "Enable Logging" is selected and the format is set to "W3C Extended Log File Format". Select Properties to display logging parameters for the web server ...

On this window, set the appropriate time period to a time-based interval - "Daily" is recommended, then select the "User local time for file naming and rollover" to ensure the file's name is updated correctly at midnight. Set, or note the log file directory and log file name shown at the bottom of the window. This is the path/name that you will monitor within the Quick Monitor Configuration Utility. 
 
Finally, click the Extended Properties tab and ensure the following fields are selected ...

Other fields may also be specified if you wish to include additional diagnostics information but these fields are recommended as the minimum you should include ...

  • date time 

  • cs-method 

  • cs-uri-stem 

  • cs-uri-query 

  • sc-status 

  • cs(User-Agent) 

When complete, ensure the name and path of the IIS log file being monitored within the Configuration utility matches the name of the file being written by your IIS web server.

Defining HTTP Keywords or Phrases 

The Quick Monitor detects errors in log files using Sentry-go's keyword detection technology. Keywords or phrases can be used either to detect an error, or to find errors that you do not wish to monitor. To define both, click the "Keywords ..." button to display the following window ...

This window contains two tabs. The first, "Keywords to Include" is used to to define the keywords or phrases that, if found within the log record will cause the Quick Monitor to generate an error and, potentially, notify the system administrator. There is no need to add complete error messages to this list, one or more keywords is usually sufficient. By default, standard messages - e.g. 404, 500 etc. are included when Setup installs the Quick Monitor.

The keywords used depends on the file being monitored ...
  • In most cases, generic keywords can be used such as "error", "failed", "insufficient", "problem" etc.
  • For the IIS log file, keywords are normally be HTTP errors such as 404, 500 etc.
  • To be notified of any message that contains the word "error", simply add the word "error" to the included list (without quotation marks).
  • To be notified of any message that contains the phrase "this is an error", simply add that phrase (without quotes) to the included list.
  • To be notified of any message that contains the phrases "this is an error" and "database", use the [And] escape sequence within the included list. In other words, you'd add "this is an error [And] database" (without quotation marks).
Monitoring Performance Data

 
Keeping a check on the performance characteristics of the server, key software services as well as Web Server and related databases is vital to those wishing to proactively monitor any Windows system. In fact, many errors can be avoided by being alerted to early signs of performance problems and reacting accordingly.

Monitoring the performance of the above services is quick & easy with Sentry-go Quick Monitors. Unlike many other solutions, which require you to manually include each performance counter before you start, Sentry-go comes pre-configured to monitor the key aspects of the both server and software you're likely to need. Simply select the "Performance" tab to display a window similar to this ...

From here you can configure all performance monitoring features, the areas & thresholds you wish to check, covering server-related as well as Microsoft Web Server-related performance. Additional & custom counters can also be added and monitored as described below. 

Performance Counter Availability

The settings on this window refer to performance counters on the local server. Although all can be configured here, their activation depends on the counters available on the server itself. If any counters are missing when the server is started, a notification will be sent to the System Administrator and an error written to the Verify Configuration Report.

If you are running the Sentry-go Quick Monitor on a non-English version of Windows, a message will have been displayed during Setup, explaining that Web counters will not be pre-configured. In this case, the options below "IIS Server Performance" will be unavailable and you should add these entries under "Custom Performance" instead.

Which Areas  Would You Like to Monitor ?

The first selection list allows you to display performance checks for the following areas of the server ...

  • Server Performance

  • IIS Server Performance (if available - see above)

  • Custom Performance Counters - allowing you to monitor key aspects of each print queue defined on the local server.

Server &  IIS Server Performance 

Select one of these options to display & configure the following monitoring features ...

Server Performance
 
Note: The following items are totals for the server. Where applicable, you can also configure individual checks for more localised items - e.g. specific CPUs, disks etc. using the Custom Performance Option - see below. 

High CPU usage This check monitors the total % usage across the whole server (all processors) and indicates how busy the processor has been within the last sample interval. One or more processors may periodically be busy and so this check must be viewed over a longer period of time than simply a single direct count. If this value is consistently high, then the server may be overloaded or a process may be looping. Either way, the performance of services - e.g. your web site will almost certainly be affected. 
 
Recommended Check Value: 80
No. errors before notifying: 3
 
Memory low This value is the number of bytes of physical memory currently available to all processes running on the server. If the available memory is low, applications performance will suffer as Windows attempts to page data out to disk etc.
 
Recommended Check Value: 500000
No. errors before notifying: 0
 
% Paging File free space low This value is the amount (%) of the Paging File space currently available for the local server. As this value approaches 0, the amount of free virtual memory is running low and therefore some memory allocation requests may not be successful. In this case, additional paging file space should be allocated in order to prevent potential problems.
 
Recommended Check Value: 10
No. errors before notifying: 0
 
System Registry size near or at maximum The Registry database is an important Windows resource. This is the percentage of available registry space that is currently in use. If it approaches 100%, errors may occur if Windows cannot write new data to the registry. 
 
Recommended Check Value: 90
No. errors before notifying: 0
  
High no. Running processes This check monitors the number of running processes on the local server and raises an error if the entered maximum is exceeded. Too many processes may indicate the presence of ghost applications and consume server resources.
 
Default Value: Disabled
 
Suspicious no. Server Access attempts This is the number of times an open request on the server has failed with an access denied error since the last scan. A consistent value greater than 0 might indicate that someone is attempting to access server resources when they shouldn't be.
 
Recommended Check Value: 0 
   (but dependent on server usage)

No. errors before notifying: 0
 
Suspicious no. Server Logon attempts This is the number of logon attempts that have failed since the last scan. It indicates that an incorrect user or password has been specified for a resource - e.g. MTS or COM+ component or might also imply that a hacking utility is trying to guess passwords in order to by server security.
 
Recommended Check Value: 0
   (if users can logon directly to the server, this value
    should be increased)
No. errors before notifying: 0
 
High no. Internal Server Errors This is the number of times an internal Server Error occurred on the local machine. A value greater than 0 usually means there is a problem with the Server which in turn might mean your web site is or was unavailable at that time. Check the Windows Event Log for more information as to the cause of this error.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High Disk Queue Length This check monitors the current queue length of all disks on the local server. This value indicates the number of disk requests that are currently waiting or being serviced by the file system. 
 
A consistently high queue length will be causing performance delays to applications and services (subject to the configuration of the disk hardware itself) and so alterations to the file system's configuration, location of files (e.g. frequently accessed files, database files etc.) and the hardware itself might be considered.
   
Default Value: Disabled
 
  

IIS Web Server Performance
 
Note: The following items are Microsoft IIS Web server specific and show totals for the IIS Web server being monitored. Where applicable, you can also configure more localised checks using the Custom Performance Option - see below. 
 
If you are running the Sentry-go Quick Monitor on a non-English version of Windows, these options will be unavailable. In this case, please add the appropriate monitored items under "Custom Performance" instead.

High no. ASP requests This value indicates the rate at which the Web server is receiving ASP-related requests and shows the average request per second. It can be used to highlight higher than expected (or planned) throughput for primarily ASP-based sites. 
   
This value is primarily aimed at alerting you to the high throughput on the server, or potentially a denial of service attack. If more than the expected number of visitors are requesting pages from your site and they are legitimate requests, additional server resources may be required and this value changed accordingly. If your web site does not utilise Active Server Pages, this value will remain zero. See also "High no. Web requests". 
 
Recommended Check Value: Dependent on site
No. errors before notifying: Dependent on site
  
High no. ASP sessions This value indicates the number of currently active ASP sessions on your web server. If this number is higher than expected, then more users than you'd planned for are accessing your web site and ASP pages. In this case, you may wish to verify current server resources and raise this value accordingly. 
 
Recommended Check Value: Dependent on site
No. errors before notifying: Dependent on site
  
High no. ASP Errors This value indicates the rate at which the web server is encountering request errors.  
 
This number should remain at zero. A value greater than this indicates that one or more ASP scripts cannot execute properly - e.g. unavailable resource, or an error within your web site. 
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High ASP Queuing This is the number of requests currently waiting in a queue to be processed by ASP. If this value is higher than zero, the ASP application will be under performing because of this queuing. In this case, additional server resources may be required, or your current ASP site design is performing poorly. The failure may also indicate a delay elsewhere in the system - e.g. waiting for database access etc. 

Recommended Check Value: 0
No. errors before notifying: 0
 
High ASP Wait time This is the number of milliseconds the most recent request had to wait in the queue to be processed. The longer this wait time, the slower your site will be responding to browser requests. If this number is consistently too high, additional server resources may be required. You should aim to tune your server so that this value remains at zero.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Timeouts This is the number of requests that timed out whilst being processed. This indicates that one or more pages are taking too long to process. First verify why the page is taking so long to respond - e.g. resource contention, poor database performance etc. For specific "long running" pages, consider increasing the page's timeout, although this response should generally be kept to a minimum.

Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Not Authorised errors This is the number of requests that failed due to insufficient access rights since the last scan. A consistently high number here might indicate that incorrect permissions have been specified on the local server, or one or more users are trying to request resources that they shouldn't be. In general, this value should remain at zero.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Not Found errors This is the number of requests, since the last scan, that resulted in a "file not found" error being returned to the client. This may indicate missing files, configuration problems or a coding error on your web site. It should remain at zero.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Pre-processor errors This is the number of requests that failed because of preprocessor errors since the last scan. These indicate an ASP error on your web site and should remain at zero.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Requests Rejected This is the total number of requests that couldn't be executed because the ASP queue is full - i.e. there were insufficient resources available on the server to process them. If this value is greater than 0, your web server is probably overloaded and needs reconfiguring.
 
Recommended Check Value: 0
No. errors before notifying: 0
  
High no. ASP Script Compilation errors This is the number of requests that failed due to script-based compilation errors since the last scan. If this value is greater than 0, one or more scripts are incorrectly coded and should be amended.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. ASP Script errors This is the number of requests that failed since the last scan due to a runtime error within the script. If this value is greater than 0, one or more scripts are incorrectly coded, reference components that are unavailable or have suffered some other runtime error. Check the Windows Event Log to see if additional diagnostics are available for this error and correct accordingly.
 
Recommended Check Value: 0
No. errors before notifying: 0
 
High no. Web Requests This value is the rate of CGI requests per second that are simultaneously being processed by the Web service. It is aimed at alerting you to the high throughput on the server, or potentially a denial of service attack. If more than the expected number of visitors are requesting pages from your site and they are legitimate requests, additional server resources may be required and this value changed accordingly.
 
It will remain at zero if your web applications are based entirely around Active Server Pages. See also "High no. ASP requests".
 
Recommended Check Value: Dependent on site
No. errors before notifying: Dependent on site
  
High no. Web Connections This value is the current number of HTTP connections currently established with the IIS Web server. A higher than expected number indicates a busier site and in turn, my imply additional resources are required.
 
Recommended Check Value: Dependent on site
No. errors before notifying: Dependent on site
  
High no. Web Not Found errors This is the rate of errors were generated by the server because it was unable to find the requested URL. HTTP error 404 may also be seen in the IIS error log. Numerous failures may indicate a page has been moved or users are attempting to access a protected document - e.g. user list or file directories.
 
Recommended Check Value: 0
No. errors before notifying: 0
  
High no. Lock Errors during Web requests The rate HTTP requests using the LOCK method are made. Lock requests are used to lock a file for one user so that only that user can modify the file. /sec
 
Recommended Check Value: 0
No. errors before notifying: 0

The entries at the bottom of the window indicates the thresholds that will trigger an error and how the Quick Monitor should respond to any failures that occur. Click here for more information.

Custom Performance

For speed, the primary list of counters is pre-configured for you. However, with there may be times when you wish to monitor additional resources such as specific databases, more specific counters (e.g. a specific disk or CPU) as well as custom counters. With Sentry-go, you can easily monitor these resources as well, by selecting the Custom Performance option from the "Performance" tab. From here you can monitor additional custom performance counters

Adding Custom Counters
 
To monitor one or more custom performance counters, simply click the "Add" button to display the following window. Custom counters can also be deleted by highlighting the appropriate entry and selecting "Remove". Pre-configured entries can be disabled but not removed ...

The following options are available ...

To select a counter definition from Windows The easiest way of selecting an available counter is to select it from Windows. To do this, simply click the appropriate button to display the Windows Add Counter dialog as used by Windows Performance Monitor ...

For more information on this dialog, please refer to your Windows documentation.
  

Name of Counter Object This is the name of the Performance Counter object you wish to monitor - as defined within Windows.
 
Counter Name This is the name of the counter you wish to monitor - as defined within Windows.
 
Parent name This is the name of the Parent object you wish to monitor - as defined within Windows.
 
Instance name or number This is the instance name or number of the counter you wish to monitor - e.g. total, CPU 1, process name etc. It's value, if any, is dependent on the information you wish to monitor.
 
Index number This is the index number of the counter you wish to monitor - as defined within Windows.
 
The Counter  number is cumulative Check this option if the counter being monitored is a cumulative figure that simply increments as time passes (until the next Windows reboot). It allows the monitor to save current values and calculate the difference when performance counter data is retrieved.
 
If the value is an average value or a value retrieved within the sampling time, then this option should remain unchecked.
 
Trigger an Alert when ... Select the option that matches the required test - i.e. when the monitor should trigger an alert. Actual limits (thresholds) are defined on the main screen - i.e. after this window is closed. 
 
An alert can be raised if ...
  • The actual value exceeds the defined threshold
  • The actual value falls below the defined threshold
  • The actual value falls below the defined threshold but is greater than zero. This option is particularly useful when monitoring the rate at which something such as a network card is running (e.g. bytes per second). In this case, if the service is legitimately not performing any work, the rate will be zero, but is not an error. When work is required, a poor performing service will show a low rate, but usually higher than zero - thus triggering an alert.
Name shown on Alerts This is the name which will appear when an alert is triggered. It is typically a phrase such as "High no. of XXXX detected".
 
Name on HTML Status Report This is the name which will appear on the Current Status web report. It is typically the name of the counter - e.g. "No. XXXX" etc.
   
Display suffix This is the suffix, if any that will appear on the Current Status web report. For example, %, sessions, bytes, bps etc.
    

Once the counter has been defined, simply click OK. The new monitored item will be added to the Custom Performance list form where they can be further configured.

Specifying Performance Thresholds

For each of the above performance-related checks, the following options can be configured ...

No. errors before notifying This value specifies the number of errors that must occur in succession before an alert is triggered.
Response to run

Select the action that you wish to take in the event a failure is written to the specified event log or log file ...

  • No Response - Notify Only.
     
    Select this option if you simply wish to alert one or more System Administrators about the error by e-mail, network messaging or both. In this case, no corrective action will be attempted by the Quick Monitor.
     
    If this option is selected, one or both of the following actions will be taken when an alert is triggered ...
     
    • System Administrators defined on the "Alerting" tab are notified if the Alert level of the error is equal to the alert level that the user wishes to receive - or higher if the Administrator is receiving higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
        
    • Files & scripts defined on the "Alerting" tab are invoked via the Quick Monitor's Alert Engine if the Alert level of the error is equal to the alert level that the script is to be actioned for - or higher if the script is being run for higher alerts as well. By default, the alert level will be set to 1. To set an alternate level (between 1 and 10), simply select the appropriate value as the "Treat as" value below. 
       
      This option is particularly useful if you wish to handle the error in a customised way (e.g. to send the error to 3rd party application or utility) or to notify one or more Administrators using alternative methods such as SMS or pager. 
       
      For more information on the Alert Engine and associated scripts, click here
        
  • No Response - Log Only. 
     
    If logging is enabled via the "Logging" tab, either to file, database or both, then details of all alerts will be written to the appropriate location. If this option is set, no notification or action will be triggered. Instead, the alert will simply be written to the log.
     
  • Reboot the Server. 
     
    Select this option if the Quick Monitor should reboot the server in response to this failure. In this case, no corrective action will be attempted by the Quick Monitor.
     
    Before a reboot occurs, notifications, indicating that a reboot is about to occur will automatically be sent to the appropriate System Administrators based on the Alert level of the error. A short delay will precede any reboot, to ensure the above Administrators receive their notification.
       
    If, after the server is rebooted, the same alert is triggered again, the same Administrators will be notified but the reboot cancelled. This prevents continual reboots from being performed.
      
  • Run a Command. 
     
    This option allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a command, batch file or executable you wish to run in response to the failure. For example, to clear down temporary files to reclaim free disk space etc. 
     
    After the command has completed, the check that triggered the alert will automatically be re-run. If it fails once again, the Quick Monitor will automatically revert this option to "Notify the System Administrator" and the appropriate users will be notified as discussed above.
     
    In order to be kept informed of any response the Quick Monitor takes, you can also configure the following options on the "Settings" tab ...
     
    • Run without notifying
    • Run & notify, but do not call the Alert Engine
    • Run & notify, then invoke the Alert Engine
       
  • Run a VBScript. 
     
    This option also allows the Quick Monitor to take automatic corrective action to the appropriate test. If selected, the "Command to Run" option is enabled, allowing you to specify a Windows Scripting Host (WSH) or VBScript (VBS) file which should be run in response to the failure. 
     
    The same notification behavior as described above will be run for VBScripts as well. 
Command If the above option allows a command or script to be run automatically, that command or filename should be entered here. Any files must be available and accessible on the local server and so the use of local paths in filenames is recommended.
   
In order to pass error-specific information on the command line, simply include any of the in-built variables - e.g. <$$ERROR>, <$$SERVER>, <$$TIMELOGGED> etc. Click here for more information on these variable substitutions.
 
After response, recheck in (mins) If the specified check fails and an error is generated, this value can be used to prevent the Quick Monitor from notifying the system administrator of the error again within the specified period of time. This can be used to give the administrator time to investigate the problem further before being notified again and prevents continuous notifications being sent.  
Treat As (Alert Level) The value selected here indicates the Alert level for the corresponding alert that is raised in the event the check fails. The Alert Level is used by the Quick Monitor to determine which System Administrators should be notified and/or Scripts run in response to the triggered alert. 
 
Alert Level 1 is considered the highest level by the monitor, whilst 10 is the lowest. By default, all checks are set to Alert Level 1.
 
Click here for more information on using and allocating Alert Levels.
  

Performance checks can be performed at regular intervals by the Quick Monitor. The interval itself can be adjusted to suit your needs.

Monitor Performance Data 
every ...
This value specifies how often, in seconds, the Quick Monitor should verify the server's performance.
 
In general, it is recommended that checks be carried out every  10 - 30 seconds.
 

  

Logging Alerts to a File or Database

  
When an error or fault is detected by the Quick Monitor, you can log details to a file or database - maybe for further processing, statistical analysis or later reporting. To do this, start the Configuration utility and select the "Logging" tab to display the following window ...

The "Alert Logging" section allows you to define both file and/or database logging easily and extremely flexibly. 

Logging to a File

To log any triggered alert to a file, run the Configuration Utility, select the "Logging Tab" and check the "Log Triggered Alerts to a File" option. The following information can then be configured ...
 

File Record String This is the mask for the record that will be written to the file. It can be made up of one or more system variables, which will be substituted before the record is written. The variables used are the same as used by the Alert Engine - click here on these variable substitutions.

For example, for comma-separated records ...

<$$TIMELOGGED>, <$$ALERTLEVEL>, <$$SERVER>, <$$TEST>, <$$ERROR>
  

File Path/Name This field is used to specify the path/name of the log file you wish to create. To choose a name/path, click the "..." button to the right of the field. 
 
Note that the path selected/entered must be relative to the local server. If configuring a remote machine, navigate to that machine and select a UNC path - e.g. \\SERVER\Path.  
 
 

Logging to a Database

This option is similar to the above file log, except that triggered alerts are inserted into an SQL database. Any database that supports ODBC can be used. Simply install a suitable ODBC driver, create an ODBC entry that uses it and reference it on this panel - see below. You can insert the data into any database table, file or record using the "Insert string" defined. This allows you to define the SQL statement, substituting the actual alert values at run time.

To log alert information to a database table, simply check the "Log Triggered Alerts to a Database option". The following information can then be configured ...
 

SQL Insert String This is the mask for the SQL statement (normally an INSERT) that will be run in order to insert the alert into the database. It can be made up of one or more system variables, which will be substituted before the database connection is made and the statement run. The variables used are the same as used by the Alert Engine -  click here on these variable substitutions. 

For example, ...

INSERT INTO SentrygoAlerts (TimeOccurred, AlertLevel, Server, CheckName, AlertText) 
VALUES ('<$$TIMELOGGED>', <$$ALERTLEVEL>, '<$$SERVER>', '<$$TEST>', '<$$ERROR>')
  
The statement itself is dependent on the target table definition and the data types (e.g. string vs numeric etc.) See "Creating an Alert Table" below for more information.

Connecting DSN Select the data source that the Quick Monitor should use in order to connect to the target database/table. 

Click the "..." button to create a new DSN through ODBC. Note that this option is only available if you are configuring the local server.
 

User ID This value is used to specify the SQL Server User ID that is to be used with the above ODBC connection in order to logon to the database (if you are logging to a SQL Server database). To use a Trusted SQL Server Connection, leave this and the password entry blank. For more information on using trusted connections with Sentry-go, click here.
    
Password This is the password associated with the above SQL Server User ID. If no password  is required, simply leave this entry blank. 
  

Creating an Alert Table

You can create your Alert table using any format you require in any ODBC-compliant database such as SQL Server, Oracle, Microsoft Access - e.g. to fit in with other systems etc. 

Example databases/scripts for Microsoft SQL Server and Microsoft Access can be found in the "Alert Logging" folder on the installation disk or download file. 
 
You can also utilise another application's database table if required. However, when selecting or defining a suitable table or database file, it is worth bearing in mind the following definitions for the substitution fields used by Sentry-go ...
 

Variable Data type
<$$SERVER> CHAR/VARCHAR (255)
<$$ERROR> VARCHAR (<Length of Message>). It is recommended that either a text or memo-type field, or a VARCHAR field which is trimmed (cut to this length or less) is used within the SQL statement.
<$$TEST> & <$$SOURCE> CHAR/VARCHAR (255)
<$$INFO> CHAR/VARCHAR (255)
<$$TITLE> CHAR/VARCHAR (255)
<$$TIMELOGGED> CHAR/VARCHAR (30)
<$$TIMENOW> CHAR/VARCHAR (30)
<$$OSNAME> CHAR/VARCHAR (255)
<$$SERVICEPACK> CHAR/VARCHAR (255)
<$$ALERTLEVEL> Numeric 1-10

  

Sending Alerts when Errors are Detected

 
Most of the time, the Sentry-go Quick Monitor will run silently in the background on the local server. If an error is detected, there are typically two ways of reacting to it ...
  • In some cases, the first step may be obvious - e.g. clear down temporary files or restart a failed service. 
  • In other cases, further investigation may be required. In this case, one or more Administrators or support personnel need to be informed ASAP.

The action you wish to take - be it an automated response or triggered alert can easily be configured with Sentry-go. Simply start the Configuration utility and select the "Alerting" tab to display the following window ...

From here you can configure two types of alerts, those directly sent from the monitor (via a standard e-mail or network message) and those that are processed by the Alert Engine.

Alert Levels

Alert levels are a fundamental part of the Quick Monitor alerting system and allow you to control who should be notified and how they should be contacted when an error is detected. 
 
Alert Levels are numeric values and range from 1 to 10. They are used to categorise the type of alerts being sent - e.g. to a group of Administrators, a team or via specific means such as sending a pager SMS notification. Each monitored event is allocated an alert level (by default this will always be 1) but this can be changed when configuring the check. In addition to this, each Administrator or Alert Script/file is also allocated one or more alert levels. If the alert level being triggered matches the alert level of the Administrator etc., the latter will be notified. To be alert a particular user to all events, simply ensure that user is allocated  all Alert Levels. To receive alerts of a specific level, select those levels only.

Notifying with Standard E-mails or Network Messages

To alert one or more Administrators via e-mail or network message, run the Configuration Utility, select the "Alerting" tab and complete the entries at the top of the window ...

Notify Administrators The first list on this tab displays all defined System Administrators that will be notified either by e-mail or network messaging

To add a new Administrator, click the "Add ..." button (see below). To remove an entry, highlight it and click Remove.
 

E-Mail Server (SMTP) Name This value is used to specify the name of your SMTP (e-mail) server. This is the server that the Quick Monitor will connect to when it needs to notify system administrators (see below) by e-mail. 
 
using port  This value specifies the port on which the above SMTP is listening for inbound requests. By default, SMTP servers listen on port 25 and this value should be used unless you know that your server uses a different port or you have been advised otherwise by your provider. 
 
Send E-mail using this ID This is the user ID that will be used to send any E-mail notifications. 

It is recommended that this value is set to "Sentry-go/QM@<YourDomain>" where <YourDomain> is the domain under which the server runs as some e-mail servers require a valid domain for verification. Failing to set this value may result in e-mail alerts not being sent.
 

Network Message Server This value is used to specify the name of the Windows server that should be used to send network messages (NET SEND). This server must be running the Windows Messenger service and be available to the Quick Monitor over the network. By default, this value is blank, indicating that the local server should be used. 
 
 

Adding a New System Administrator (Notification)

When you click the Add button against the System Administrator's list, the following window will be displayed, allowing you to define the new Administrator, their contact details and Alert levels of interest etc. ...

The following options are available from this window ...
   

Please enter the user's E-Mail Address/Network ID This field is used to specify either the e-mail address or network user ID that will be used to notify this Administrator. The type of value entered is determined by the selection made below.

If an e-mail address is specified, it should be fully qualified with the full domain name and must be accessible (or reachable) from the SMTP server specified on the previous screen.
  

Use E-mail Address Select this option if the user is to be notified/alerted by e-mail - i.e. the above address is a valid e-mail address.
 
Use Network Messaging (NetSend) Select this option if the user is to be notified/alerted by e-mail - i.e. the above address is a valid e-mail address.
 
When should they be notified ? This list specifies all the alert levels that this user should be alerted to. Please select all that apply.
  
For more information on alert levels, please click here.
 
Daily Summary In some cases, the Quick Monitor will simply run in background - for example, if the server is running well and no alerts are triggered, no notifications will be sent. You may, however wish to be informed that the server is running satisfactorily, or keep a check on the total number of alerts sent from the monitor on a daily basis.
 
To enable this, simply tick the Daily Summary check box. When checked, this e-mail address will automatically receive a daily summary report indicating the total number of alerts raised within each primary category ...
  • No. Monitor-Specific errors 
  • No. Disk Space errors 
  • No. Event Log &/or /Log File errors 
  • No. Performance-related errors 

Alert Summaries are always sent by e-mail. This option is therefore disabled if network messaging has been specified above.
 

When complete, click OK to return to the previous screen. The new Administrator will be added to the list. Using the above configuration, alerts can be sent by network message ...

 

or by e-mail to any  e-mail client - e.g. Outlook or other e-mail-enabled devices such as "Mobile E-mail" from your mobile 
phone ...

Testing Notification Settings

To test the sending of an e-mail or network message, run the Configuration Utility on the server running the monitor, click the Alerting tab, highlight the appropriate e-mail address or user ID in the top list and click "Test". The following window will be displayed, showing progress as the test continues & any errors that occur. 

If an error does occur and the information displayed doesn't highlight the exact fault (or it directs you to the Sentry-go log file), click the "Log File ..." button at the bottom of the window. This will display the Quick Monitor's log file. Scroll to the bottom to view entries written by the above test.

Automatically Resending Failed E-mails

By default, e-mails are sent to the configured e-mail (SMTP) server as soon as the alert is triggered. However, if this server is unavailable or cannot be contacted, the e-mail alert will be lost (although other methods will continue to run and the associated recent errors web report will still highlight the fault). To change this behaviour, you can configure the Quick Monitor to periodically attempt to resend an alert in the event the e-mail cannot be sent. To enable or disable this, simply locate the following value in the local Windows Registry and edit is as require ...

HKLM
 \SOFTWARE
  \3Ds
   \Sentry-go <Quick Monitor Name>
    \CurrentVersion
     \Contacts
      \DelayedSMTPCheckInterval
This value controls whether the Quick Monitor should attempt to resend failed e-mail notifications and, if so, how often it should retry ...
  • If the above value is not present or set to 0 (the default), no resends will be attempted.
  • If the above value is set to a numeric value of 1 or more, any failed e-mails will be resent every X minutes (where X is the number specified) until either the e-mail is sent or the alert is overwritten.

Warning: Take care when editing the Windows Registry and do not change any other values unless asked to do so, or you fully understand the consequences. Making a mistake here may result in your server or Windows O/S becoming unusable.

Alerting through the Alert Engine (to a SysLog server, custom e-mail, SMS gateway, batch file or script etc.)

In addition to defining automatic responses and notifying Administrators using e-mail or network messaging, the Quick Monitor can also be configured to invoke the Alert Engine in order to run a batch file, script or preformatted file. Unlike standard commands or scripts which are run "as is", invoking the Alert Engine allows values specific to the error that triggered the alert to be injected (substituted) directly into the script or batch file at runtime. It is designed primarily to allow you to alert in any way you like - e.g. pass the error details to a 3rd party application, call a 3rd party utility in order to send an SMS or pager message etc. 

What is an SMS Gateway ?

An SMS gateway is an external service provided by a third party organisation that allows you to forward information in a predefined format and have them send the details to one or more mobile phones via the Short Message Service (SMS). Typically, details can be sent via a standard SMTP e-mail or HTTP.

Why use an SMS Gateway ?

Unless you want to alert an Administrator via SMS, there is no need to use this service. However, an SMS message is an ideal way of alerting you to a significant or important fault. By using an external service, rather than sending the message direct, you have the following advantages ...

  • Access & configuration is easy

  • No need to set up or maintain external modem connections

  • You can use your own provider or shop around for a low cost provider that can interface with your mobile network

The Alert Script templates provided with the Quick Monitor contain logic for a number of SMS Gateway providers 
including ...

  • BigFoot

  • ClickATell 

  • IntelliSoftware

Although 3Ds (UK) Limited do not specifically recommend any one solution, these have been tested successfully with Sentry-go software and, at the time of writing provide a low cost, affordable solution, If you are looking for an alternate provider, we recommend that you look for a company based on the mobile networtks they connect to - some charge higher costs for foreign networks.

How the Alert Engine Works

An Alert Engine script is a file - either a batch, script or preformatted file that can contain one or more special "place-markers" as discussed below. When the Engine is invoked, the Quick Monitor performs the following actions ...

  • A monitored error occurs & the Quick Monitor triggers an alert.
  • If the error's alert level is equal to or lower than this value, the Alert Engine will be invoked.
  • When invoked, the Alert Engine first copies the file to a temporary location.
  • The newly copied file is then compiled (rewritten), replacing any place-markers with error-specific values.
  • If the file is defined as a batch file it is then run through the Windows command interpreter & then (the temporary file is) deleted.
  • If the file is defined as a script, it is then run through the Script interpreter & then (the temporary file is) deleted.
  • If the file is a preformatted file, the information is used to invoke the appropriate interface. Once complete, the temporary file is deleted.

Choosing an Alert File Type
 
The Alert Engine allows you to define one of 5 types of Alert Engine file.
  

To do this ... Use this ... Description ...
Run one or more commands that can be run from the command line, external utilities etc. in succession (no programming logic required) Batch Alert file. This is a standard batch file containing one or more Windows commands, external command-line utilities or other batch files. Place markers may be coded within the file - e.g. as parameters to commands to include error-specific information.
Run one or more commands, access COM objects & scripting components, perform programming logic (e.g. logic based on specific conditions)  Alert Script. This is a VBScript or Windows Scripting Host file that contains one or more script-based commands. Scripts can be used in place of batch files when more programmatic control is required. Place markers may be coded within the file - e.g. as parameters to script commands to include error-specific information.
Log alert details to a SysLog server SysLog file. This is a preformatted file that the Alert Engine uses to log error information to a central SysLog server. The file controls the server name, port, severity & facility code as well as the error message itself.
Send a custom format e-mail, containing your own or specific text (as well as alert-specific information), interface with an external system (e.g. SMS/pager gateway) that accepts pre-formatted e-mails as input etc.  SMTP file. This is a preformatted file that the Alert Engine uses to send a custom format e-mail to one or more users, or external systems such as an SMS gateway. Many systems use e-mails as a way of retrieving information from external sources and this is one of the easiest ways of interfacing the details to such a system.
 
You can send a standard e-mail notification to one or more users by defining them directly under "Notify Administrators" on the Alert tab.
Interface with an external system (e.g. SMS/pager gateway) that accepts pre-formatted HTTP (web) requests as input etc.  HTTP file. This is a preformatted file that the Alert Engine uses to send error information to an external system using an HTTP (web server) interface. Using a URL, you can connect to and send information to the external web server - such as an SMS gateway. 

To configure the Alert Engine and determine which scripts would be run when, select the "Alerting" tab. The lower half of the window allows you to define the scripts that the Alert Engine will run ...

From here you can define each script and determine when they should be invoked.
 

These files & scripts will be run by the Alert Engine ... The files & scripts listed here will be run by the Alert Engine when the appropriate alert level (or, if configured a higher level) is triggered. To Add or remove a file from this list click the appropriate "Add ..." or "Remove" button.
  • Batch files are run through the standard Windows command line interpreter.
  • Windows Scripting Host (WSH) or VBScript are run through the CScript interpreter.
  • SysLog, SMTP and HTTP files are preformatted and contain a number of specific commands that tell the Alert Engine how to process the information. 

Adding a New Alert Engine File 
 
When you click the Add button against the Alert Engine file/script list, the following window will be displayed ...

The following options are available on this window ...
 

Script Location This field is used to specify the full path and name of the batch file or script that is to be run through the Alert Engine. Command line parameters can also be included here if required.
  
When editing an existing file, this will be the full path & name to that file on the server being monitored. If you're configuring the local server, you can click the "Edit ..." button to edit the file.
 
When defining a new file, simply enter the full path and name of the file, relative to the local server. If you're configuring the local server, you can click the "Edit ..." button to create & then edit the file. For preformatted files, a template will be provided, allowing you to quickly & easily supply your own information.
 
What type of file does this represent ? This options allows you select the type of Alert Engine script you are defining - click here for more information ...
  • Run as a standard Windows Batch file. Use this option to define a standard batch file containing one or more Windows commands, external command-line utilities or other batch files as well as error-specific information. Batch file are simpler than scripts & are best used when you wish to run a series of commands that need little or no programmatic control.
     
    Batch files are run through the Windows command interpreter (CMD).
      

  • Run as VBScript or Windows Scripting Host file. Use this option to define a VBScript or Windows Scripting Host file. Scripts provide greater programmatic control over batch files, but are more complex to develop, requiring programming knowledge. 
     
    Script files are run through the CScript interpreter (e.g. a .vbs file).
      

  • Send a SysLog file. Use this option when you want to log the alert to a SysLog server. 
     

  • Send an SMTP e-mail file. Use this option to send a custom/preformatted e-mail to one or more users or external systems. This can be a formatted e-mail containing your own text as well as error-specific information that can be sent to one or more users, or an external system such as an SMS gateway. Such a system can then be used to forward the alert on to a mobile phone or pager etc.
     
    You can send a standard e-mail notification to one or more users by defining them directly under "Notify Administrators" on the Alert tab.
      

  • Send an HTTP web file. Use this option to send error/alert information to an external system using an HTTP (web) interface. As with the SMTP option above, the HTTP protocol can often be used to forward information on to an external system such as an SMS gateway. 

Edit ... This button is available if you are updating the configuration on the local server. Click this button to edit an existing file or provide a template when a new Alert file is being created.
 
When should it run ? This list specifies all the alert levels that this script or file should be run for. Please select all that apply.
   
For more information on alert levels, please click here.
 

 
Editing an Alert Engine File
 
Alert Engine files are text files and can therefore be edited using an text editor such as Notepad. However, when configuring the local server, you can also use the in-built editor which is often more convenient and allows new files to be based on predefined templates, thus avoiding mistakes and speeding up the process of creating the file. To create a new file or edit an existing one, ensure the file name/path is entered and click the "Edit ..." button on the above window. The following will be displayed ...

From here you can edit the file as required. Click OK to save, or Cancel to abort any changes made.

Predefined Alert File Templates

When you select an Alert SMTP, SysLog or HTTP format File, a template will be provided for you. In some cases this will provide a number of example files & providers that you can use. It will also show a generic template that you can easily modify for your own provider or server. Simply edit the specific data values and remove any lines you no longer require.
 
When editing a template that has multiple examples, always remove any unwanted data lines from the original example. If you don't, the last entry found will be used and your file may not work correctly. 

Running a Batch File or Script through the Alert Engine

Batch file or scripts are standard text file run through the appropriate interpreter. In this example, a short VBScript is used to export alert information to an in-house system, through an external utility called LogInfo.exe. In particular, it shows how to include the strings "<$$ERROR>" and "<$$SERVER>" which are then expanded at runtime by the Alert Engine to include the actual error message and server name prior to running the script. Batch files are similar, except that standard Windows commands & external command-line utilities are used in place of script-based  commands.

'
' Sentry-go Quick Monitor Alert Engine Script to log alert information
' via an external LogInfo.exe routine. 
'
' See associated Quick Monitor documentation for more details on how to
' specify the information to send via this file.
'

' ------ Local declarations ------
Dim strTextToSend

' ------ Set up parameters ------ 
strTextToSend = "QM Error - < $$ERROR> on <$$SERVER>"
Set Shell = CreateObject("WScript.Shell")

' ------ Create & execute the target command ------ 
Shell.Run """c:\program files\Inhouse\LogInfo.exe""" """ & strTextToSend & """,,True

' ------ Cleanup ------ 
Set Shell = Nothing

' ------ End of Script ------ 

 
Sending a Custom SMTP (e-mail) through the Alert Engine

When the Alert File is defined as an SMTP file, the preformatted commands can easily be used to interface with an external SMTP server - e.g. to send a custom e-mail or to interface with an external system such as an SMS gateway. The following commands, which are generally used in the format <Command>:<Value> should be included in this type of file ...

Command Meaning
# Any commands or lines prefixed with a # are counted as comments by the Alert Engine and ignored. Blank lines are also ignored.
 
QM-SERVER: <TargetServer> Required. This command is used to identify the target SMTP (e-mail) server - either by name or IP address.
  
QM-PORT: <Port No>
Optional. This is the port number on which the SMTP server is listening for inbound requests. 
 
Unless otherwise stated by your provider or Administrator, this is normally 25. 
 
QM-SENDFROM: <User>@<YourDomain>
Required. This is the e-mail address of the user sending the mail. In general, this should be in the format <Someone>@<YourDomain> as the server may check the originating domain before proceeding.. 
 
QM-SENDTO: <User>@<Domain>, <User>@<Domain>, <User>@<Domain> etc. Required. This is the e-mail address of one or more users that should receive the mail. Separate multiple entries with a comma.
 
QM-SUBJECT: <Title>
Required. This is the string that will form the subject for the e-mail. It can contain any valid text or place markers.
<Alert Text>  The last parameter (with no command prefix) is the alert you wish to log. It can span multiple lines and contain one or more place markers. 
 

For example ...


# SMTP Alert File
#
# This file allows you to send alert details to an SMTP server.
# Simply edit the appropriate details below and configure the Alert 
# Engine to call this file for the appropriate alert levels. Any 
# place markers found (e.g. <$$ERROR>) will automatically be expanded 
# by the Alert Engine at runtime. 
#
QM-SERVER: MySMTPServer
QM-SENDFROM: Sentry-go@Company.com
QM-SENDTO: Support@Company.com, SMS@Provider.com
QM-SUBJECT: Critical Error Detected!
 
# The following (last) entry is the message we want to log. This
# will be expanded to contain the actual error/alert information
# at runtime.
 
The error <$$ERROR> occurred on server <$$SERVER> at <$$TIMELOGGED>
 

   
Logging an Error to a SysLog Server through the Alert Engine

When the Alert File is defined as a SysLog file, the preformatted commands can easily be used to interface with an external SysLog server. The following commands, which are generally used in the format <Command>:<Value> should be included in this type of file ...

Command Meaning
# Any commands or lines prefixed with a # are counted as comments by the Alert Engine and ignored. Blank lines are also ignored.
 
QM-SERVER: <TargetServer> Required. This command is used to identify the target SysLog server - either by name or IP address.
  
QM-PORT: <Port No>
Required. This is the port number on which the server is listening for inbound HTTP requests. 
 
Unless otherwise stated by your provider, this is normally 514. 
 
QM-SYSLOGSEVERITY: <Lvl> Optional. Indicates which SysLog severity you wish to log the alert under. If not specified, the default severity level is 1 (alert).
  
QM-SYSLOGFACILITY: <Lvl>
Optional. Indicates which SysLog facility you wish to log the alert under. If not specified, the default facility is 14 (alert message).
 
<Alert Text>  The last parameter (with no command prefix) is the alert you wish to log. It can span multiple lines, but will be truncated if the length exceeds the maximum size allowed by the SysLog standard.
 

For example ...


# SysLog Alert File
#
# This file allows you to send alert details to a SysLog server.
# Simply edit the appropriate details below and configure the Alert 
# Engine to call this file for the appropriate alert levels. Any 
# place markers found (e.g. <$$ERROR>) will automatically be expanded 
# by the Alert Engine at runtime. 
#
QM-SERVER: MySysLogServer
QM-PORT: 514
QM-SYSLOGSEVERITY: 1
QM-SYSLOGFACILITY: 1
 
# The following (last) entry is the message we want to log. This
# will be expanded to contain the actual error/alert information
# at runtime.
 
The error <$$ERROR> occurred on server <$$SERVER> at <$$TIMELOGGED>
 

 
Sending an Error via an HTTP Web Server through the Alert Engine

When the Alert File is defined as an HTTP file, the preformatted commands can easily be used to interface with an external web (HTTP) server (and optionally on to an external system such as an SMS gateway). The following commands, which are generally used in the format <Command>:<Value> should be included in this type of file ...

Command Meaning
# Any commands or lines prefixed with a # are counted as comments by the Alert Engine and ignored. Blank lines are also ignored.
 
QM-HTTPSERVER: <TargetServer> Required. Indicates the name or IP address of the target web/HTTP server. This name is dependent on your provider .
   
QM-PORT: <Port No.> This is the port number on which the server is listening for inbound HTTP requests. Unless otherwise stated by your provider, this is normally 80.
 
QM-METHOD: GET  Required. Indicates which HTTP call type the Alert Engine should use. Currently, this must be set to GET - indicating that an HTTP Get request is to be performed. This may be extended in a future version of the Quick Monitor Alert Engine.
  
QM-URL: <URL>?<Params>  Required. This is the URL that is to be called in order to make the GET request. It may contain one or more parameters as required. Parameters must be URL encoded - e.g. %20 in place of spaces, no double quotes etc.
 
QM-SUCCESSTEXT: <Text> Optional. If included, it indicates some text that the server will return to 
indicate that the call was successful - e.g. OK. If the text is not returned (or no text is returned), the command will be considered to have failed. 
  
If both QM-ERRORTEXT and QM-SUCCESSTEXT are included and neither string is found, it is assumed that the command failed.
 
 
QM-ERRORTEXT: <Text> Optional. If included, it indicates some text that the server will return to 
indicate that the call failed - e.g. Error. If the text is not returned (or no text is returned), the command will be considered to have worked successfully.
 
If both QM-ERRORTEXT and QM-SUCCESSTEXT are included and neither string is found, it is assumed that the command failed.
 

For example ...


# HTTP Alert File
#
# This file allows you to send alert details to an HTTP (Web) server.
# Simply edit the appropriate details below and configure the Alert 
# Engine to call this file for the appropriate alert levels. Any 
# place markers found (e.g. <$$ERROR>) will automatically be expanded 
# by the Alert Engine at runtime. 
#
QM-HTTPServer: www.YourProvidersSite.com
QM-Port: 80
QM-METHOD: GET 
  
# The following should appear on a single line
QM-URL: http://www.YourProvider.com/TheirPage.htm?
        Param1=Value&Text=<$$ERROR>%20on%20server%20<$$SERVER>
 
QM-SuccessText: OK
QM-ErrorText: ERR
 

 
Testing Alert Scripts

To test an alert script or file, run the Configuration Utility on the server running the monitor, click the Alerting tab, highlight the appropriate script in the lower list and click "Test". The following window will be displayed, showing progress as the test continues & any errors that occur. 

If an error does occur and the information displayed doesn't highlight the exact fault (or it directs you to the Sentry-go log file), click the "Log File ..." button at the bottom of the window. This will display the Quick Monitor's log file. Scroll to the bottom to view entries written by the above test.

Handling Alert Engine Script or File Errors
 
In the event the Alert Engine is unable to complete the request, more information will be logged to the Quick Monitor's error log file. You can access this from the Programs menu short cut (or access the file directly at <Path of Sentry-go Quick Monitor>\goQuickMon.log).

Sentry-go place markers

Any file or script that is processed by the Alert Engine can contain one or more special place markers. These strings, which are always in the format "<place marker-Name>" allow details specific to the error triggering the alert to be included within the response. For example, you can include the error message, title, server name and time logged to be included in, say, an SMS or pager message or export to another application or database. 
  
To include such information, simply add the appropriate place marker below within the command or file and should be treated as a string - e.g. strMessage = strMessage & " <$$ERROR> on <$$TIMELOGGED>". The following place markers are common to all Quick Server Monitors ...
 

Place Markers Translates to
<$$SERVER> The name of the local server
<$$ERROR> The error message (from a log file) or the error string raised by the Quick Monitor
<$$INFO> Returns specific information about the error - e.g. the name of the service that failed. 
  
When set, the value is dependent on the alert being triggered.
<$$TEST> or <$$TITLE> The name or title of the test that was performed and ultimately raised the alert
<$$TIMELOGGED> The time the error was raised in the format dd/mm/yy hh:mm.ss
<$$TIMELOGGED-MDY> The time the error was raised in the format mm/dd/yy hh:mm.ss
<$$SOURCE> The source/application name of an event log error or the name of the test etc.
<$$TIMENOW> The current time  in the format dd/mm/yy hh:mm.ss
<$$TIMENOW-MDY> The current time in the format mm/dd/yy hh:mm.ss
<$$OSNAME> The type of the server's Operating System - e.g. Windows NT, Windows 2000 etc.
<$$SERVICEPACK> The latest service pack string, if applicable

Additionally, for the Web Server Monitor the following may also be set. Some are dependent on the error triggered ...

Place Marker Applies to  Translates to
<$$DRIVE> Disk Space The name of the drive where insufficient space is available
<$$REQDISKSPACE> Disk Space The amount of space required on the above drive (the threshold)
<$$AVAILDISKSPACE> Disk Space The amount of available space on the checked drive 
<$$SERVICE> Running Services  The name of the service that failed
<$$EMAIL> E-mail Send/Receive  The address of the e-mail that failed
<$$EVENTLOG> Event Log  The name of the Event log where the error was detected
<$$EVENTLOGCHECK> Event Log The unique name of the Event Log check (the test name) that triggered the alert. 
<$$LOGFILE> Text-based Log File The name of the Log File where the error was detected
<$$FILEPATH> Text-based Log File The name/path of the file being monitored
<$$LOGFILECHECK> Text-based Log File The unique name of the Log File check (the test name) that triggered the alert. 
<$$PERFNAME> Performance The name of the performance check that failed
<$$PERFTHRESHOLD> Performance The threshold (limit) of the check that triggered the alert
<$$PERFVALUE> Performance The actual value returned from the performance check that trigger the alert
   
Web Reporting & Monitor Settings

 
In addition to monitoring & alerting functionality, Sentry-go Quick Server Monitors also contain an embedded web server, allowing you access information direct from the server/monitor using a desktop web browser such as Microsoft's Internet Explorer or Netscape's Navigator. 

To enable or disable Web Reporting as well as control other Quick Monitor settings, run the Configuration utility and click the "Settings" tab. The following window will be displayed ...

Configuring Quick Monitor Settings & the Embedded Web Server 

The upper section of this window allows you to control settings relating to the Quick Monitor itself, including the embedded web server ...
 

Wait this no. seconds after Windows starts before monitoring The Quick Monitor runs as a Windows service and is typically started automatically with other services. When the server is started, these services and resources can take differing times to start and may be launched in different sequences. This, in turn, can cause false alerts to be triggered by monitoring software which detects failures in services that have yet to start.

To guard against this problem, you can set this value, which is the time that must pass before monitoring commences - i.e. to allow other services to start. The value entered here is the number of seconds after Windows startup that must elapse before monitoring commences.
 

Cache this no. alerts locally This value specifies how many alerts will be saved at any one time on the local machine. The more alerts cached, the more will be shown on the Recent Alerts report. The most recent alerts are saved.
 
A minimum of 50 alerts can be saved. The higher this value, the more disk space will be required on the disk containing the Sentry-go directory. 
 
The web server listens on port ... This read-only/read-write value shows the port on which the local embedded web server is listening for requests. It is typically 80 or above. The value shown is the value that should be used when connecting to the web server directly from the browser using this format (you can omit the Port No. if this value is 80, the default port) ...

http://<Server Name>:<Port No>

When connected to the local machine, the listen port can be updated if required. When changing this value, the following should be noted ...

  • Always ensure no other software, or Quick Monitor is using the port you wish to assign. If two systems attempt to use the same port, the second will fail and connectivity will be lost. Care should therefore be taken when updating this value.

  • This value can only be changed when configuring the local server. The value is read-only when configuring remotely.

  • Existing web sessions using the original port will need to be refreshed/reconfigured to  use the new port/URL.

Display dates in the following format The setting of this option determines the format of dates displayed by the Quick Monitor. It will be defaulted to the appropriate value during Setup but can be changed to one of the following values here ...
  • Day/Month/Year
     
    Dates are presented in the UK date format - dd/mm/yyyy.
     
  • Month/Day/Year
     
    Dates are presented in the US date format - mm/dd/yyyy.

This setting also affects the date format used within place-marker variables, such as <$$TIMELOGGED>, with the exception of those using a named format - e.g. <$$TIMELOGGED-MDY>.
 

Enable Web Reports from this Quick Monitor Check this option to enable the embedded web server and access information from your web browser. To prevent web access from this Quick Monitor, uncheck this option.
  
Allow the Quick Monitor to Automatically Adjust Login Privileges The Sentry-go Quick Monitor runs as a Windows service. As such, if a different login is required (e.g. to run remote commands via a virtual web session), that login must be granted "Login as a Service" access right in order to function.
 
If this option is selected, the Quick Monitor will automatically grant the above access right when required. If it is left unchecked, the System Administrator must grant this access right (or grant access to a group which has the right) manually before the user can login.
 
Note: Once granted, the permission is retained by the user. Permissions are never revoked automatically by the Quick Monitor.
Restart the Quick Monitor Automatically on Applying New Settings When one or more settings are updated and you wish the Quick Monitor to use them, the monitor must be stopped & restarted. You can either do this manually at a later date or the Configuration Utility can prompt you when Apply or OK is clicked and changes have been made. However, to restart the monitor automatically without prompting, simply select this option.
 
When Sentry-go successfully resolves a problem automatically, what would you like to do ...? When the Quick Monitor takes automatic action in response to a problem (e.g. runs a command or script, restarts a service etc.), you can be alerted to the action in a number of ways. This allows you to be kept informed of all problems, even if the monitor has corrected the fault automatically ...
  • Run without notifying. 
     
    Select this option to run automatic actions without notifying any Administrators that the action has taken place.
     
  • Notify Administrators, but do not run the Alert Engine.
     
    Select this option to notify associated Administrators by e-mail or network message when automatic actions are run. All Administrators configured to receive the associated alert (i.e. based on the Alert Level) will be notified, but no Alert Engine scripts will be run.
     
    This option allows you to be notified by standard methods, without incurring any additional costs for using pager notification services etc., which can be reserved for unrecoverable errors only.
     
  • Notify Administrators and run the Alert Engine.
     
    Select this option to notify associated Administrators by e-mail or network message and run associated Alert Engine scripts when automatic actions are invoked. All Administrators configured to receive the associated alert (i.e. based on the Alert Level) will be notified, and all Alert Engine scripts (again based on the Alert Level) will be run. 

Configuring Web Server Security

When you access Sentry-go Web Reports from your browser, you have access to the Monitoring & Alert Engine, as well as real-time reports and remote command sessions.* For additional security and to protect access, especially when you wish to open reports over the internet, you can specify a number of specific a number of additional security options such as an Administrator's password & allowing access to specific IP addresses only. You can also specify a session timeout, which automatically logs out the user after X minutes of inactivity. 

* Remote Command Sessions can be disabled individually during installation for additional security if required.

To configure these options, click the "Web Security" button to display the following window ...

The following options are available ...

Current Password Before you can change any Administrator setting, you must enter the existing password on this field. if no password is currently define, leave this field blank.
 
New Password To change the Administrator's password, enter the current password (if any) above, and the new password here. If you do not want to change the password, leave this entry blank.
  
Confirm Password If you have entered a new password, you must confirm the value by re-entering it here.
   
When is login required ? The options here determine when the login page is displayed by the web server. If the login page is shown, the user must enter the Administrators password before being allowed to continue ...
  • Before accessing any web reports from this server. 
     
    Select this option for maximum security. If selected, the user must login before displaying any report (except the home page and Configuration Verification Report). 
     
    The login page will be shown for all primary reports unless the user is already logged in. To timeout sessions automatically, see below.
     
  • Before accessing non-read-only reports. 
     
    Select this option to request user login for any report that allows changes to be made on the server - e.g. Virtual Command Sessions etc.
     
    The login page will be shown for all primary reports unless the user is already logged in. To timeout sessions automatically, see below.
     
  • Never (not recommended)
     
    Select this option to disable logins and session timeouts. This option is not recommended, especially if you allow access from the internet. 
     
    When selected, no login will be required for any report generated by the Quick Monitor except Virtual Command Sessions which requires a Windows User/Password to be entered.
Sessions time out after ...  This option controls how long a session remains active when no requests are made. The higher the value specified, the longer an existing logged on session remains (and the user not re-prompted for their password again) even if no requests are made.
 
This option is not used if logins are not enforced (i.e. "Never" is selected above).
 
Client Access Restrictions By default, a browser from any client PC with connectivity to the server can access the Quick Monitor's web server. However, you can limit access to specific IP addresses or a range of IP-addresses by listing them here ...
  • To allow access to a specific address, enter it's IP address in the format a.b.c.d - e.g. 189.57.21.5
  • To allow access to a group of addresses, enter a partial address (the numbers that are common) - e.g. 189.57.21
     
    Use this option if your company uses DHCP where clients can receive different addresses within given range.

If no entries are listed, any client can access the web server. To disable all access, unselect the "Enable Quick Monitor Web Reports" from the Settings tab. 

   

Applying New Settings 

 
The Sentry-go Quick Web Monitor reads many of it's configuration options when it is started. If changes are made to it's settings using the Configuration Utility, then simply stop and start the service in order for them to take effect. You can do this in one of three ways ...

  • By manually restarting the service.

  • When you click Apply within the Configuration utility *.

  • When you exit the Configuration utility *.

* By setting the "Restart Quick Monitor Automatically on Applying New Settings", you can control whether the above prompt is displayed or not.

Restarting the Quick Monitor

To restart the Quick Monitor manually, follow these steps ...

  • On Windows NT,  run the Services applet from Windows Control Panel. On Windows 2000 and above, open the "Administrative Tools" folder within Control Panel, and run Services form there. A window similar to that shown below will be displayed ...

  • By default, the list shows all the available services on the local machine, so scroll down to highlight the appropriate monitor. 
  • On Windows NT, click Stop, then, when the service has stopped, click start. 
  • On Windows 2000 and above, right click/restart to stop & start the monitor.
  • Verify that the service starts by checking the status within the Services window. 
  • If an error occurs or the status doesn't change to "Started", refer to the monitor's log file for more information. By default, this is a text file called "goQuickMon.log" located in the Sentry-go home directory, defined during Setup.
Retrieving a Daily Summary Report
 
Assuming that the local server/file server is working well - which is obviously the aim, the Sentry-go Quick Monitor will remain silent. When a fault is detected, the appropriate alert will be triggered automatically.  In order to ensure the overall health of the system, you can receive a "Health Report" or "Daily Summary" on the previous day's server errors - e.g. to confirm that no problems were detected, or to total those that were.
 
The daily summary is automatically generated if any defined System Administrators have requested the report. To receive the report, select the "Alerting" tab and Add the appropriate Administrator's e-mail address via the "Add ..." Button. On the associated Add dialog, simply check the "Send Daily Summary to this user" option.
 
Summary information is sent daily, usually between midnight and 1 o'clock in the morning. Server Totals are cached in memory. If the Quick Monitor is stopped or reconfigured (and therefore restarted), the totals so far for that period will be reset.
  
HTML/Web Reporting
  
In addition to monitoring and alerting, there may be times when you wish to access captured or logged information, or view the data being verified by the monitoring engine in real-time. With Sentry-go, you can easily access all this information, and more directly from your desktop browser. 
 
System Requirements

The Sentry-go Quick Monitor includes an integrated web server built-in, allowing you to display HTML reports directly from the monitor itself, without the need to install, configure or gain access to an external web server. Web-based reporting is enabled through the "Settings" tab within the Quick Monitor's Configuration Utility. All you need is a web browser - we recommend you use Microsoft's Internet Explorer v5.x (or above) or Netscape Navigator v6.x (or above) browsers. 
  
Securing Web Reports & Web Server Access

Unlike generic web servers such as IIS or Apache, the integrated web server is dedicated to providing reports directly from the Quick Monitor. In terms of security, this means that only the reports documented here can be accessed - unknown scripts cannot be executed and downloads not performed, thus ensuring a level of security out of the box. However, in some cases, you may wish to restrict access to reports and/or the web server further and so the following options are provided ...

  • Some or all reports can be password protected, requiring the user to logon to the server before accessing the information. Logged-on sessions can also automatically be timed out after a configurable period of inactivity.
  • Access to the Quick Monitor's web server can be restricted to one or more specific IP addresses, or a range of addresses - e.g. addresses on the same subnet etc. If this option is enabled, only browsers logging in from clients with these IP addresses will be allowed access to the server.
  • The  Virtual Command Session require an additional login when run. This must be a valid Windows ID (and password) on the local server.
  • The  Virtual Command Session can be specifically disabled by the Administrator.

The web server can be enabled or disabled through the "Settings" tab on the Configuration Utility. Web security options are configured by clicking the "Web Security" button - please click here for more information.
    

Displaying Web Reports
 
You can easily access any HTML report in one of three ways - by entering the report's URL into your web browser, clicking on a desktop shortcut or menu or using the Sentry-go Web Launcher. The monitor's web server must be enabled in order to access these on-line reports.

Using a Shortcut

If you are running from the machine running the Sentry-go monitor, Setup will have created a set of shortcuts (icons) both on the desktop and the Start/Programs/Sentry-go menu. These shortcuts can also be copied to other machines such as your own desktop, thus allowing access to monitored values directly from there. Simply double click the appropriate icon to launch the default web browser and connect it to the appropriate Sentry-go Quick Monitor. 

Using the Configuration Utility

If you are running the Quick Monitor Configuration utility, you have immediate access to web reports. Simply click the button at the bottom left of the window to launch your default browser and access the home page ...

Using the Report's URL

Accessing an HTML Report in this way is as simple as entering a URL into your web browser, with the exception that you may also need to specify a port address along with the page itself. All web servers listen for client requests on a "port". By default, a web server's default port is port 80. However, if this port is already being used on the local machine - e.g. by another web server or another Quick Monitor, Setup will automatically allocate a new number - e.g. 81, 82 etc. 

Finding the Port Address

If you do not know the port address, run the Configuration Utility and select the "Settings" tab. The Web Server's listen port address is the value shown against the "The Web Server listens on port" entry. 

  • If the web server is listening on the default port (80), do not need to include the port number in the URL. By default, web browsers will attempt to connect on this port, so you simply need to enter the following URL into your web browser ...

http://<Server Name>/QMHome.htm - e.g. http://MyServer/QMHome.htm.

  • If the web server is listening on a different port, you can access the Quick Monitor's Home Page by entering the following URL into your browser's address field, substituting the appropriate port number as required ...

http://<Server Name>:<Port Number>/QMHome.htm - e.g. http://MyServer:83/QMHome.htm.

Using the Sentry-go Web Launcher

Although you can access any report directly from the browser or shortcut icon, you can also connect to any Quick Monitor on any available machine using the Sentry-go Web Launcher. This utility allows you to quickly & easily start your default browser and connect it to the home page of any local or networked Quick Monitor. 

Running the Sentry-go Web Launcher 
 
To run the Sentry-go Web Launcher, simply logon to a server where the Sentry-go Quick Monitor is installed and double click the "goQMConnect.exe" icon from Windows Explorer or the Sentry-go menu if installed. You may also wish to place this in your Startup folder so that it automatically starts each time you logon to your desktop. When run, the following window will be displayed ...

To launch your local web browser and connect it automatically to the Quick Monitor's home page, simply enter the Server's name or address and click OK. To select the server from a list, click the "..." button to the right of the field. By clicking OK, the browser will be launched and the above window closed. To continue to run this application after the browser is run, click the  Apply button instead of "OK".

Searching for Quick Monitors

In order to locate the Quick Monitor's Web Server, the utility automatically scans a range of addresses. By default, this range is between 80 and 100 but if the Quick Monitor listen address is outside these this, you can increase it by selecting the Options button. The following window will then allow you to modify the range scanned ...

 

The Quick Monitor Home Page
   
The Quick Monitor's Home Page lists all available reports on the given server (for all Quick Monitors installed) and provides links to them. If multiple Quick Monitors have been installed in different locations on the local server, only reports for the Quick Monitors installed in the same directory as the connected monitor will be displayed.

For each report, a link and brief description will be shown. To access a specific report, simply click on the appropriate link for the given monitor. 

To access this report ...
From the desktop Select the menu shortcut, desktop shortcut or run the Sentry-go Web launcher.
Enter this URL in your browser http://<Server Name>:<Port>/QMHome.htm

 

Password Protecting Web Reports
   
For added security, you can password protect some or all Sentry-go web reports. When a logon is requested, you must enter the Sentry-go password which is the "Administrators" password specified during Setup and configured using the Configuration Utility's "Settings" tab ...

The Quick Monitor Home Page never requires a password. For added security, the "Virtual Command Session" report, which allows you to execute remote commands on the server running the Quick Monitor can also be disabled during installation.
 

Recent Alerts Report

 
The Recent Alerts report gives you immediate access to the last X errors that have been triggered from the Quick Monitor on the specified server. The actual number available is dependent on the number being cached by Sentry-go - this is configured on the Settings tab of the Configuration Utility. From this report, it is easy to see ...

  • The errors that have recently been detected on the server.

  • Spot trends that might have occurred

  • View other potentially related issues that have arisen on the server for problem solving.

  • Ensure fixes have corrected a problem.

You can also access alerts that you may not have been notified about - e.g. because the associated alert level does not match your alert settings, or you weren't logged on when a network message was sent etc. An example of a similar report is shown here ...

To access this report ...
From the Quick Monitor Home Page  Click the Recent Alerts link
Enter this URL in your browser http://<Server Name>:<Port>/WebErrors.sgp
Logon Used within Report N/A

 

Current Status Report

 
The current status report allows you to connect directly to the Sentry-go engine and display the values it is currently monitoring and comparing to the defined thresholds. An example of a similar report is shown here ...

From here, the last known status of all files & directories being monitored is displayed, along with the most recent Event Log & log files messages recorded.

To access this report ...
From the Quick Monitor Home Page  Click the Current Status link
Enter this URL in your browser http://<Server Name>:<Port>/WebStatus.sgp.
Logon Used within Report N/A

    

Virtual Session Report (Remote Command Execution)

 
The Virtual Session page allows you to connect to and run commands directly on the remote server. It is designed to allow one or more batch commands to be executed on the server without the need for additional 3rd party software or a high speed network connection. 

With a Virtual Session, you can ...

  • Run & display results from one or more batch commands.

  • Run & display results from any Windows commands or utilities that are typically run from the command line.

The Virtual Session should not be used for ...

  • Run graphical applications.

  • Run command line applications or utilities that prompt for user input when started or during execution.

Recommendations ...

It is recommended that commands are batched and run as a complete unit, rather than issuing many separate calls. Not only is this quicker, but commands run separately are effectively run as independent processes, and therefore may not behave as expected.

For example, if you want to copy a file from the server to your PC, but cannot access a suitable server-side share, you can map a share from the server to your PC, copy the file, then delete the mapping through a Virtual Session. If this is performed as three separate commands (i.e. clicking "Run Command(s) Now" for the map, copy and un-map separately, the mapping may not be available during later sessions. However, if all three commands are issues within the same session (recommended), the request is not only performed more quickly but ensures the underlying mappings work correctly ...

   net use X: \\MyPC\TempShare
   copy c:\Logs\MyLog.log X:
   net use X: /d

When accessed, a web page similar to this will be displayed ...

The page is split into two main sections. The first section allows you to authenticate with the server whilst the second section allows you to enter one or more commands, configure timeouts and display the results of any previous commands run. To run one or more commands, you must first logon to the server by entering the requested details. You can do this either by specifying login information at same time as the commands you wish to run, or before entering any commands. 
 
Remote Server Login

The following fields allow you to logon to the remote server ...

You are attached to server This is the name of the server to which you are currently attached or connected.
   
User ID for the remote server Enter your Windows User ID for the server. You can either authenticate to the domain (entered below) or the remote server directly. 
  
Password This field allows you to specify the password for the above user. For security, authentication takes place directly on the target server.
  

Execute Remote Commands

The following fields allow you to specify, execute and display results from the remote server ...

Previous Return Code This is the code returned from the last series of commands that run. It may be set to ...
  • N/A - no command has been run or no information was available from the last command.
  • Timed out - the remote command ran but did not complete within the given timeout.
  • Success - The last command ran successfully and returned a result of 0.
  • <Code> - The last command ran successfully and returned a non-zero return code. Depending on the command, this may indicate success or failure.
Previous Results This is the output generated from the last command. It can be standard output (i.e. the result) or an error message, or both. If multiple commands were run, output from each will be displayed here.
 
Command(s) to Run This field allows you to specify one or more batch commands that you wish to execute on the remote server. Each command should be entered on a new line, just like you would entered commands in a console window.
 
When run, all the commands entered here will be batched into a single file and executed on the remote server.
 
Commands time out after This value specifies how long (in seconds) the Quick Monitor will wait before the command(s) are timed out. If a timeout occurs, an error will be reported and the batch file terminated on the remote server.
 
The default value is 30.  To wait until completion (i.e. no timeout), enter 0 for this value.
 
Don't wait for completion If you wish to execute remote commands but not wait for them to complete, select this option. if this option is selected, no output will be returned and job cancellation will not be available.
 
Show output lines Enter the number of lines you wish to display in the output window. The value will take effect the next time you submit a request.
 
Show command lines Enter the number of lines you wish to display for the command window. The value will take effect the next time you submit a request.
 

Logging On & Running Commands

To logon, run entered commands or both, simply select the "Logon and Run Command(s) Now" button. If a timeout value (or no timeout value) has been specified, the commands will be submitted and the page redisplayed when a result (or timeout) is returned. If the "Don't wait for Completion" option has been checked, the page will redisplay after immediately after the command is submitted on the remote server.

Cancelling Running Commands

In some cases, you may wish to cancel a command that is already running. To do this, simply click the "Cancel Running Command(s)" button. If the command can be cancelled, the Quick Monitor will terminate the remote process and redisplay the web page. 
 
Note that terminating (or timing out) a process should be avoided wherever possible & may not work in some cases - e.g. if a separate process was spawned on the server. Depending on the commands being cancelled, unpredictable results may occur if running commands are abnormally terminated.

To access this report ...
From the Quick Monitor Home Page  Click the Virtual Command Session link
Enter this URL in your browser http://<Server Name>:<Port>/QMRExec.htm.
Logon Used within Report Windows login information entered

 

Performance Logging Report

 
If performance logging data is configured to be recorded by the Quick Monitor, this report allows you to view captured data directly from the defined CSV (comma-separated values) file. It is an ideal way to spot trends in terms of local server, software and database performance. As shown below, the report is colour-coded in order to highlight any areas where thresholds have been exceeded and may therefore require further attention.

To access this report ...
From the Quick Monitor Home Page  Click the Performance Logging link
Enter this URL in your browser http://<Server Name>:<Port>/WebPerfLog.sgp.
Logon Used within Report N/A

Performance logging must first be enabled within the associated Quick Monitor in order to view this report. To configure Performance logging, click the Logging tab from within the Configuration Utility. 
 

Verify Configuration Report 

 
This report allows you to verify the Quick Monitor's current configuration and highlights any errors that were encountered since the last monitor's startup. It also allows you to trigger a test alert and verify that alerting mechanisms, e-mail addresses and alert engine scripts are performing correctly without having to wait for an alert to be generated. A page similar to this will be displayed ... 

Verifying the Monitor's Configuration
 
The report allows you to verify the current configuration being used by the Quick Monitor. The monitoring engine itself handles configuration errors in the following way, which are highlighted on this page ...

  • Each time the Quick Monitor is started, all defined configuration values are loaded and checked.

  • If an error occurs - e.g. a configured service is not installed on the server, an alert is triggered and the check disabled. An entry is also written to this report.
      
    Note that if the Quick Monitor's web server is not enabled, configuration errors are sent as notifications to the appropriate System Administrator(s).

Verifying the Alerting Mechanism

The lower section of the report allows you to select an alerting option and trigger a test alert. When run, the Quick Monitor automatically triggers an alert of the appropriate level and ...

  • Sends network notifications to all users configured for this alert level.

  • Sends e-mail notifications to all users configured for this alert level.

  • Runs any configured Alert Engine scripts or files for this alert level.

If, after the alert is triggered you do not receive the appropriate notification, or the expected scripts are not run, please check the appropriate entries within the Configuration Utility. For more information on Alert Levels and notifications, click here.
     

To access this report ...
From the Quick Monitor Home Page  Click the Verify Configuration link
Enter this URL in your browser http://<Server Name>:<Port>/QMConfigCheck.sgp.
Logon Used within Report N/A

      

IIS Log File Summary

 
The IIS Log File Summary Report allows you to process and summarise delivery messages written to the the Microsoft Internet Information Services (Server) log file on the remote server. The IIS Log File, which is also often monitored by the Quick Monitor for HTTP errors, records information about the requests made by client browsers to the web server, including pages & files. The report summarises the requests made to the server including any errors that were recorded, sorted by URL/file, no. requests or HTTP error. It is designed to show how your IIS server is being used, overall throughput, the most popular pages/files and any files that could not be delivered to the client.
  
To use this report ...

  • IIS logging must be enabled on your Web Server. This is enabled via the Internet Services Manager - for more information,  please refer to your Microsoft IIS documentation.

  • It is recommended that 1 file per day be created as this will help keep the individual file size to a minimum. 

  • In the above file, you must record at least the fields "sc-status", "cs-uri-stem".

You can either select a report based on the current day (e.g. today's, yesterday's the day before log etc.) or enter the entire path & name of the file you wish to summarise. Typically, the IIS log file is located under 
"<Windows Directory>\System32\LogFiles\W3SVC1" and it's name is in the format "exYYMMDD.LOG" 

IIS Log files can grow extremely large over the course of a day, especially on larger volume sites & servers. Where larger files are being processed, the report can take a long time to produce. 

An example of a similar report is shown here ...

 

To access this report ...
From the Quick Monitor Home Page  Click the IIS Log Summary link
Enter this URL in your browser http://<Server Name>:<Port>/IISLogSummary.htm.
Logon Used within Report N/A

     

Customising Web Reports with your own Headers & Footers

 
The reports detailed above come pre-formatted when you access the web server from your desktop browser. However, there may be times when you wish to customise the layout of these reports in terms of the header and/or footer - for example, to integrate Sentry-go reporting into your own support web site etc. The shaded areas below shows these header & footer areas in a typical report ...

To customise these areas, you simply provide your own HTML files that are merged into the generated reports at runtime, replacing the default header/footer provided. 

Independent Headers & Footers

Independent headers & footers allow you to define a header and/or footer that is applied to a particular web report. If both an independent header/footer and a common one is defined, the former will always be used. When defined, the HTML file will be used to generate the areas shown above. If required, you should also add the report's title to the custom header file. To do this, simply follow these steps ...

  • Locate the Quick Monitor's HTML directory. This is normally a folder called "HTML" within the directory where the monitor is installed - e.g. C:\Program Files\Sentry-go\HTML. Your HTML files should be placed here. 

  • Locate the Quick Monitor's Images directory. This is normally a folder called "Images" within the above HTML directory - e.g. C:\Program Files\Sentry-go\HTML\Images. Your graphics files should be placed here. 

  • Create your header and/or footer files for each report you wish to customise. These files ...

    - Should be standard HTML files 
    - Should not include <HTML>, <BODY>, <Head> tags etc.
    - Should be called <Name of Report>-Header.htm and/ or <Name of Report>-Footer.htm etc. ...
     
      - So, to override the login window, the 2 files would be called QMLogon-Header.htm & QMLogon-Footer.htm
      - To override the Web monitor's status report, the 2 files would be called WebStatus-Header.htm &
        WebErrors-Footer.htm etc.
     

  • Place graphics in the Images directory identified above.

  • Set the source for any graphics included in the above headers/footers to "images/<Name of File>" ...
     
    - e.g. <img border="0" src="images/MyGraphic.jpg" width="650" height="100">
     

  • For example ...

    <!-- 
    Example Custom HTML Header File - By giving this file the appropriate name and placing it in the Quick Monitor's HTML directory, it will automatically replace the report's standard header block
    //--> 

    <p align="center"><img border="0" src="images/CompanyHeader.jpg" 
    width="450" height="150"></p>
    <p align="center"><font face="Arial Black" size="4"><i><u>
    Company Support System - Recent Server Errors!</u></i></font></p> 

Common Header & Footer

A common header & footer allow you to define a single header and/or footer file that is applied to all reports generated by the Quick Monitor. If both an common header/footer and an independent one is defined, the latter will always be used. When defined, the HTML file will be used to generate the areas shown above. In addition, the report's title will also be generated automatically below the contents of the header file. To do this, simply follow these steps ...

  • Locate the Quick Monitor's HTML directory. This is normally a folder called "HTML" within the directory where the monitor is installed - e.g. C:\Program Files\Sentry-go\HTML. Your HTML files should be placed here. 

  • Locate the Quick Monitor's Images directory. This is normally a folder called "Images" within the above HTML directory - e.g. C:\Program Files\Sentry-go\HTML\Images. Your graphics files should be placed here. 

  • Create your header and/or footer files for each report you wish to customise. These files ...

    - Should be standard HTML files 
    - Should not include <HTML>, <BODY>, <Head> tags etc.
    - Should be called QM-Header.htm and/or QM-Footer.htm etc. ...
     

  • Place graphics in the Images directory identified above.

  • Set the source for any graphics included in the above headers/footers to "images/<Name of File>" ...
     
    - e.g. <img border="0" src="images/MyGraphic.jpg" width="650" height="100">

Uninstalling the Sentry-go Quick Monitor

 
In the event you wish to remove the Sentry-go Quick Monitor from the local PC, simply run the "Add/Remove Programs" applet from the Windows Control Panel. A window similar to the following will be displayed. From here, scroll down to the appropriate Sentry-go Quick Monitor entry and click the appropriate remove button ...

Setup will prompt you to confirm the software's removal ...

  • Click "Yes" to remove the Quick Monitor software. Because some components are shared across the installation, only specific files & shortcuts will be removed - see below. 

  • Upon completion, Setup checks to see if any other Sentry-go software is installed on the machine. If it isn't, you will be prompted to remove shared Sentry-go settings and configuration options. This allows all shared settings and files to be removed from the PC. 
     
    In most cases, if you are sure that all components were installed in the same Sentry-go directory and all have been removed (which this prompt implies), it is recommended that all files and configuration options are removed from the local machine by selecting "Yes" to this prompt.



   Copyright © 2002-2004, 3Ds (UK) Limited