As SharePoint becomes a more critical component of your infrastructure, it also becomes a service that needs to be more closely monitored to ensure its availability. But many organizations mistakenly try to treat SharePoint like other application servers, such as SQL Server.
The most common misconception is that it's SharePoint that you have to monitor. This false belief will lead most operations personnel to overlook the fact that SharePoint is really a combination of services that act together. Because these services are tightly integrated, your monitoring strategy needs to be multidimensional.
So what do you monitor? Start with SharePoint's core dependencies.
SharePoint is dependent on services that provide different functions to the core SharePoint services. If any of these core dependencies fails, it will cause SharePoint to cease working and seriously degrade your SharePoint farm's ability to service clients. Above all, you need to ensure that all of the following services are available and that SharePoint is able to leverage them:
Windows
Without Windows, SharePoint wouldn't work at all. So that means you must be vigilant and monitor all event logs to ensure that the OS is performing as expected. Event logs can be a great indicator that patches haven't been applied because errors in the event log will often point to issues with your SharePoint infrastructure.
Active Directory
Whether you use forms-based authentication or Active Directory for authenticating users, Active Directory is a requirement for server-to-server communication. SharePoint uses several service accounts and needs to communicate with AD to validate the credentials it uses for those accounts. The critical accounts include the SharePoint service account and the search account. SharePoint applications may also have unique accounts.
If SharePoint is unable to authenticate these accounts, the farm will come screeching to a halt pretty quickly. If you use AD for your authentication provider, it also becomes a critical source of profile data and will leverage the search account to periodically gather that data, adding it to SharePoint's profile store.
SQL Server
Everything in SharePoint is stored in a SQL database. As a result, if SQL Server ceases to function, SharePoint will quickly follow. So you must ensure that SQL Server is not only functional but that the SharePoint Web Front End can communicate with it as well. Make sure the service accounts that SharePoint uses have the appropriate access to the various databases—primarily the SharePoint_Config database and secondarily the content databases associated with each Web application.
Internet Information Server (IIS)
SharePoint is a Web-based application server. It relies on the IIS configuration and on the service being fully operational. Depending on the complexity of your SharePoint environment, IIS will be configured with one or more application pools and one or more IIS websites.
There may not be a one-to-one relationship between an application pool and website, but central administration and the Shared Services Provider will probably have dedicated application pools—or at least they should in a production environment. Other Web applications, like your main portal site or your My Sites application, may or may not have dedicated application pools. This is especially true if you have "extended" Web applications.
Take care to map out the relationships and the corresponding application pool identities. Keeping tabs on their status and response to requests will be key to ensuring SharePoint is available to your end users.
Beyond dependent services, there are a number of direct SharePoint components that are worth monitoring. Like dependent services, all of the following are more or less required for SharePoint's operation:
SharePoint's Timer Service
The "automatic" things that SharePoint does really aren't all that automatic. In fact, many of the processes that occur in a SharePoint environment are the result of the Timer Service and the related timer jobs defined in central administration.
The Timer Service is a true Windows service that is responsible for initiating this job. It generally runs every five minutes, but it could shut down or become inoperable for a few different reasons. Most often it's the result of some authentication problem with the identity it uses. This is a service that you should monitor. If it's not running, it's not likely to be noticed immediately, but when users don't get their alerts, you'll get calls.
SharePoint Search
Even with WSS, SharePoint has a search service running. The WSS search and the add-on MOSS search are used for indexing content as well as importing profile data. If these services are inoperable or inconsistently available, you'll almost immediately begin seeing issues with your farm, ranging from event log entries to inoperable search to your profile imports failing.
If you want to keep your users happy and SharePoint humming along, create a program for monitoring the items identified here. What hasn't been addressed are applications built on SharePoint or key add on tools like backup and recovery programs. All of these elements should also be monitored. Talk to you vendors to understand how these components can be included in your monitoring program.
SharePoint Content Databases
There's a known performance limit for SharePoint's content databases. In general, you shouldn't let these databases exceed 100 GB. Your site won't come crashing to a halt if you exceed that limit, but you will begin to notice performance degradation. Content databases are associated with an application, and you can have multiple data.
