Windows Services Test

Many server applications in Windows environments run as background services. The WindowsServices test checks the availability of the service that corresponds to an application.

Target of the test : An IIS web server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every Service name that has been configured.

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed
  2. Host - The host for which the test is to be configured
  3. Port - the port to which the specified host listens

  4. ServiceName - Name of the service that is to be checked. More than one service name can also be provided with comma as the separator.

    Note:

    • When configuring the servicename, make sure that you specify the Display Nameof the service, and not the service Name you see in the Services window on your Windows host.
    • When monitoring an MS SQL server, the SERVICE parameter will be set to MSSQLServer by default. However, if the MS SQL server being monitored was installed using a named instance, the SQL service name will change. In such a case therefore, ensure that the SERVICE parameter is reconfigured to reflect the correct service name.

    To save the time and effort involved in manual service specification, eG Enterprise offers an easy-to-use auto-configure option in the form of a View/Configure button that is available next to the servicename text box. Refer to Auto-configuring the Windows Services to be Monitored for details on how to use this option.

  5. CORRECT - Increased uptime and lower mean time to repair are critical to ensuring that IT infrastructures deliver a high quality of service to users. Towards this end, the eG Enterprise suite embeds an optional auto-correction capability that enables eG agents to automatically correct problems in the environment, as soon as they occur. With this capability, as and when an abnormal situation is detected, an eG agent can initiate corrective actions automatically to resolve the problem. Automatic correction without the need for manual intervention by IT operations staff reduces service downtime and improves operational efficiency. By default, the auto-correction capability is available in the eG Enterprise suite for the Num_procs_running measure of ProcessTest, and the Availability measure of WinServiceTest. The eG Enterprise suite includes a default auto-correction script for WinServiceTest, which executes when the service that the eG agent has been configured to monitor, stops. To enable the auto-correction capability of the WinServiceTest, first, select the TRUE option against the CORRECT parameter in this page (by default, FALSE will be selected here).
  6. alarmtype - Upon selecting the TRUE option, two new parameters, namely, ALARMTYPE, USERPARAMS, and CORRECTIVESCRIPT will appear. The ALARMTYPE parameter indicates when the auto-corrective script should execute. You can set the corrective script to execute when a specific type of alarm is generated, by selecting an option from the ALARMTYPE list box. For example, if the Critical option is chosen from the ALARMTYPE list box, then the corrective script will run only when a critical alarm for the WinServiceTest is generated. Similarly, if the Critical/Major option is chosen, then the corrective script will execute only when the eG Enterprise system generates critical or major alarms for the WinServiceTest. In order to ensure that the corrective script executes regardless of the alarm type, select the Critical/Major/Minor option.
  7. userparams - The default script for WinServiceTest takes no parameters. Therefore, specify none against USERPARAMS.
  8. correctivescript - The CORRECTIVESCRIPT text box can also contain none, so that the default script is automatically associated with the test. Administrators can build new auto-correction capabilities to address probable issues with other tests, by writing their own corrective scripts. To know how to create custom auto-correction scripts, refer to the eG User Manual.
  9. ISPASSIVE – If the value chosen is yes, then the server under consideration is a passive server in a cluster. No alerts will be generated if the server is not running. Measures will be reported as “Not applicable’ by the agent if the server is not up.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Service availability:

Indicates the availability of the service.

Percent

A value of 100 indicates that the specified service has been configured and is currently executing. A value of 0 for this measure indicates that the specified service has been configured on the server but is not running at this time.  A value of –1 indicates that the service has not been configured on the target system.

Service state :

Indicates the current state of this service.

 

The values that this measure can report and their corresponding numeric values are discussed in the table below:

Measure Value Numeric Value

Running

 1

StartPending

 2

Stopped

 3

StopPending

 4

Paused

 5

PausePending

 6

Note:

By default, this measure reports the Measure Values listed in the table above to indicate service state. However, in the graph of this measure, service state is represented using the corresponding numeric equivalents only.