Microsoft® Windows® 2000 Scripting Guide
« Previous | Next »
Reliability monitoring enables you to track the mean time between service failures. The mean time between failures tells you the amount of time you can expect a service to run before it fails. A service with a mean time between failures of 1000 hours is expected to run approximately 1000 hours before encountering problems.
Knowing the mean time between failure can help you prevent problems before they occur. For example, you might have a service that fails every 10 days because of a memory leak. Rather than wait for the service to fail (perhaps at a highly inconvenient time for your users), you might periodically schedule the service to stop and restart at a time that minimizes the impact on users, on other services, and on other parts of the computing environment.
Reliability monitoring can also tell you how long it takes for a service to be restored in the event that it does fail. For example, your reliability statistics might show that it takes 6 hours to fully restore a particular service. This information can help you plan routine service maintenance: If you need to upgrade or reconfigure the service, schedule this maintenance during a 6-hour block that minimally disrupts users.
You can create an event subscription that notifies you each time a service changes state (for example, goes from running to stopped). By saving these state changes to a database, you can calculate the mean time between failures and the time required to restore full functionality.
Listing 15.3 contains a script that uses a temporary event subscription to monitor changes in service state. To carry out this task, the script must perform the following steps:
Because the script monitors only changes to services, a Where clause is included to limit monitoring and data retrieval to instance modifications that involve the Win32_Service class.
To stop monitoring, you need to terminate the script.
Comparing the previous state with the current state enables you to identify whether the modification involved a change in service state. For example, a change in service state would be indicated by a service that was started when last monitored but is now stopped. If the previous and current states are the same, the modification did not involve service state but instead reflects a change to some other property of the service (such as changing the start mode from manual to autostart).
Listing 15.3 Monitoring Changes in Service Status by Using a Temporary Event Subscriber
|
|
Send us your feedback | « Previous | Next » |