Microsoft Sharepoint Products and Technologies Resource Kit eBook

250 Part III: Planning and Deployment
Healthy operation requires that you monitor each component and alert system
administrators of problems. Most large enterprises already have policies in place for
managing hardware, networks, and operating systems. The SharePoint Portal Server
architecture does not introduce any new considerations with regard to those items.
Monitoring and Alerting Requirements
The more distributed an environment is, the more it requires monitoring. Failure to
monitor the status of the architecture results in a reactive administrative model in
which action is taken only after the problem has become serious enough for users
to report it. The monitoring solution for this architecture provides a proactive administrative
model in which problems are automatically detected before they escalate to
a level that affects the system. To meet this aim, you should be aware of general
monitoring principals and critical elements that need to be monitored.
It is imperative that alerts be used to bring any failure to the immediate attention
of the system administrator so that it can be rectified. If this is not done, the
infrastructure can slowly decay until it affects the performance of the website.
The monitoring and alerting infrastructure can also benefit scalability. Defining
alerts based on system usage makes it possible to be proactive and start scaling the
environment before users are affected. For example, an alert can be triggered when
processor utilization on the Web servers is consistently above a preset limit. This can
provide an indication that more servers or upgraded server hardware are required.
The following topics discuss several fundamental monitoring principles.
Monitoring Unobtrusively
A poorly designed or poorly implemented monitoring strategy can adversely affect
system performance or operation. In general, the monitoring solution should have
as minimal an impact as possible on the system it is monitoring, while providing all
relevant information.
For example, when using a probe, it is sufficient to retrieve a single entry,
which indicates that the server is functional, instead of retrieving multiple entries.
The system should be probed only as often as absolutely necessary to provide adequate
responsiveness. This limits the additional burden on the servers and applications.
Probing a system too soon and too often returns failure data sooner, but it can
place an obtrusive burden on the services.
Avoiding Cascading Failures
If a failure occurs, it can trigger other alerts in the monitoring solution. For example,
if one set of servers running Internet Information Services (IIS) fails, this might place
an additional load on the remaining servers, in turn generating alerts from those
servers. If this happens, you should disable noncritical services or applications to
reduce the load on the remaining servers. You should also evaluate system capabilities
to proactively provide extra system capacity in case the problem recurs.