 |
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.
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 &
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 ...
The Virtual Session should not
be used for ...
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.
|
|