Monitoring is an integral part of any IT administrator’s job; although this person is occasionally called on to perform reactionary maintenance (fixing things that go wrong), the lion’s share of duties should be focused on preventive administration. Monitoring logs and other metrics provided by the systems they support are a key component of long-term IT success.
SharePoint presents a special challenge from an administrative standpoint because it is dependent on a lot of other technologies such as SQL, IIS, ASP, the operating system, and SharePoint.
At any given time, a SharePoint administrator might need to know metrics such as these:
- How well IIS is serving pages
- If a member server’s operating system is functioning correctly
- How a SQL server is meeting the data requirements placed on it by the SharePoint farm
Add monitoring several SharePoint servers into the mix, and there are a lot of logs to be checked, especially in a smaller IT team. Event Viewer, IIS logs, SQL logs, and SharePoint logs can be individually monitored, but each individual logging system paints only a partial picture of the health and well-being of a SharePoint farm.
Event selection
Although configuring the usage and health data collection for the farm, you will be given the opportunity to choose from a series of events to capture. Several of these events are chosen by default, although you can choose to deselect them before enabling the usage and health data provider to enhance performance.
Shown in Table 1 is a listing of events that can be logged along with their initial logging state.
TABLE 1 Potential logging events
| Events to log | Enabled by default? |
| Analytics usage | Yes |
| App monitoring | Yes |
| App statistics | Yes |
| Bandwidth monitoring | No |
| Content export usage | Yes |
| Content import usage | Yes |
| Definition of usage fields for education telemetry | Yes |
| Definition of usage fields for microblog telemetry | Yes |
| Definition of usage fields for service calls | Yes |
| Definition of usage fields for SPDistributedCache calls | Yes |
| Definition of usage fields for workflow telemetry | Yes |
| Feature use | Yes |
| File I/O | Yes |
| Page requests | Yes |
| REST and client API action usage | Yes |
| REST and client API request usage | Yes |
| Sandbox request resource measures | Yes |
| Sandbox requests | Yes |
| SQL exceptions usage | No |
| SQL I/O usage | No |
| SQL latency usage | No |
| Task use | Yes |
| Tenant logging | No |
| Timer jobs | Yes |
| Tracks Access Services monitoring usage metrics | Yes |
| Tracks app database usage metrics | Yes |
| Tracks response times/processing time metrics for Access Services ADS and WFE subsystems | Yes |
| Tracks the CPU and memory usage characteristics of Access Services sessions | Yes |
| Events to log | Enabled by default? |
| User profile Active Directory import usage | Yes |
| User profile to SharePoint synchronization usage | Yes |
Configuring usage and health data collection
A newly created SharePoint installation creates the usage and health data collection services, but does not activate or configure them by default. These services can affect performance; as a result, they should not be activated until after the farm is fully configured, but prior to user acceptance testing.
To display the usage and health data collection configuration, do the following:
1. Open Central Administration and select Monitoring.
2. On the Monitoring page, under the Reporting section header, select Configure Usage And Health Data Collection.
There are six major components to the configuration of usage and health data collection:
- Usage data collection Choose to either enable or disable data collection (selected to be enabled by default).
- Event selection The selection of which events are to be captured within the logging database.
- Usage data collection settings Specifies the log file location on all SharePoint farm servers (set to %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\ by default).
- Health data collection Choose whether or not to enable health data collection settings and edit the health logging schedule (if necessary).
- Log collection schedule Choose whether you want to edit the log collection schedule via the Usage Data Imports and Usage Data Processing timer jobs.
- Logging database server Displays the current database server and name for the logging database along with the authentication method used to connect to SQL (Windows authentication or SQL authentication).
The database server and name are intentionally grayed out; these values can be reconfigured via Windows PowerShell cmdlets.
After you have made your selections on this page, clicking OK button activates the usage and health data collection functionality.
Logging database functionality
While installing your SharePoint farm, you specified a database to be stored in SQL for use in logging performance metrics. Individual metrics, captured by each member server of your SharePoint farm will be combined on a regular basis and stored in a series of partitioned tables within the logging database.
After the usage and health data collection has been configured in Central Administration, logged events are stored in a series of tables (partitioned by day), as shown in Figure 1. Each table has a total of 32 partitions, one for each possible day of a given month (31 days total) and another for the current day’s logs (a specific partitioned table, which is known as _Partition0).
FIGURE 1 WSS_Logging database tables
There are two timer jobs responsible for the collection and aggregation of logging data in a SharePoint farm:
- The Microsoft SharePoint Foundation usage data import timer job runs every five minutes by default and imports usage log files into the logging database.
- The Microsoft SharePoint Foundation usage data processing timer job runs once daily and expires usage data older than 30 days.
The usage data import timer job is fairly self-explanatory: All it does is extract logging data from every member of the farm and load this information into the logging database tables (by category) for further analysis. This information is temporarily stored in the _Partition0 table so logging information can be regularly added throughout the day.
At day’s end, the usage data processing job accumulates and analyzes the current day’s log information, removing it from _Partition0 and storing it in a different daily partition.
As an example, if today were the 10th of February and you selected the top 1,000 rows from the dbo.AccessServicesMonitoring_Partition10 table, you would be seeing logs from the 10th of January; today’s logs would still be stored in the _Partition0 table until the date rolls over to February 11th. At that point, the logs for February 10th would be moved by the usage data processing timer job to the _Partition10 table, and the _Partition0 table would be reset.
