The monitoring features in Microsoft SharePoint Server 2010 help you to understand how the SharePoint Server 2010 system is running, analyze and repair problems, and view metrics for the sites. Monitoring the SharePoint Server 2010 environment includes the following tasks:
- Configuring the various aspects of monitoring to suit business needs.
- Monitoring the environment and resolving any problems that might arise.
- Viewing reports and logs of the environment activity.
SharePoint Health Analyzer checks for potential configuration, performance, and usage problems in SharePoint Server 2010. It runs predefined health rules against servers in the farm and returns a status that tells you the outcome of the test.
Receive auto alerts
SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem.
Configuring monitoring
SharePoint Server 2010 comes installed with default settings for its monitoring features. However, you might want to change some of these settings to better suit the business needs. The aspects that you might change configuration settings for include diagnostic logging and health and usage data collection.
Diagnostic logging
SharePoint Server 2010 collects data in the diagnostic log that can be useful in troubleshooting. The default settings are sufficient for most situations, but depending upon the business needs and lifecycle of the farm, you might want to change these settings. For example, if you are deploying a new feature or making large-scale changes to the environment, you might want to change the logging level to either a more verbose level, to capture as much data about the state of the system during the changes, or to a lower level to reduce the size of the log and the resources needed to log the data.
The SharePoint Server 2010 environment might require configuration of the diagnostic loggings settings after initial deployment or upgrade and possibly throughout the system's life cycle. The guidelines in the following list can help you form best practices for the specific environment.
- Change
the drive that logging writes to. By default, diagnostic logging is
configured to write logs to the same drive and partition that SharePoint
Server 2010 was installed on. Because diagnostic logging can use lots
of drive space and writing to the logs can affect drive performance, you
should configure logging to write to a drive that is different from the
drive on which SharePoint Server 2010 was installed. You should also
consider the connection speed to the drive that logs are written to. If
verbose-level logging is configured, lots of log data is recorded.
Therefore, a slow connection might result in poor log performance.
- Restrict log disk space
usage. By default, the amount of disk space that diagnostic logging can
use is not limited. Therefore, limit the disk space that logging uses to
make sure that the disk does not fill up, especially if you configure
logging to write verbose-level events. When the disk restriction is used
up, the oldest logs are removed and new logging data information is
recorded.
Use the Verbose setting sparingly. You can configure diagnostic logging to record verbose-level events. This means that the system will log every action that SharePoint Server 2010 takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes and then re-configure logging to record only higher-level events after you make the change.
- Regularly back up logs.
The diagnostic logs contain important data. Therefore, back them up
regularly to make sure that this data is preserved. When you restrict
log drive space usage, or if you keep logs for only a few days, log
files are automatically deleted, starting with the oldest files first,
when the threshold is met.
Enable event log flooding protection. Enabling this setting configures the system to detect repeating events in the Windows event log. When the same event is logged repeatedly, the repeating events are detected and suppressed until conditions return to a typical state.
The monitoring features in SharePoint Server 2010 use specific timer jobs to perform monitoring tasks and collect monitoring data. The health and usage data might consist of performance counter data, event log data, timer service data, metrics for site collections and sites, search usage data, or various performance aspects of the Web servers. The system uses this data to create health reports, Web Analysis reports, and administrative reports. The system writes usage and health data to the logging folder and to the logging database.
A timer job is a trigger to start to run a specific Windows service for one of the SharePoint 2010 products. It contains a definition of the service to run and specifies how frequently the service should be started. The Windows SharePoint Services Timer v4 service (SPTimerV4) runs timer jobs. Many features in SharePoint 2010 products rely on timer jobs to run services according to a schedule.
You might want to change the schedules that the timer jobs run on to collect data more frequently or less frequently. You might even want to disable jobs that collect data that you are not interested in. You can perform the following tasks on timer jobs:
- Modify the schedule that the timer job runs on.
- Run timer jobs immediately.
- Enable or disable timer jobs.
- View timer job status. You can view currently scheduled jobs, failed jobs, currently running jobs, and a complete timer job history.
SharePoint Server 2010 includes a new, integrated health analysis tool that is named SharePoint Health Analyzer that enables you to check for potential configuration, performance, and usage problems. SharePoint Health Analyzer runs predefined health rules against servers in the farm. A health rule runs a test and returns a status that tells you the outcome of the test. When any rule fails, the status is written to the Health Reports list in SharePoint Server 2010 and to the Windows Event log. The SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list on the Review problems and solutions page in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem. You can also open the rule that raised the alert and change its settings.
Like all SharePoint Server 2010 lists, you can edit Health Analyzer Reports list items, create custom views, export the list items into Microsoft Excel, subscribe to the RSS feed for the list, and many other tasks. Each health rule falls in one of the following categories: Security, Performance, Configuration, or Availability.
A health rule can be run on a defined schedule or on an impromptu basis. All health rules are available through Central Administration, on the Monitoring page, for either immediate or scheduled execution.
Farm administrators can configure specific health rules to do the following:
- Enable or disable rules.
- Configure rules to run on a predefined schedule.
- Define the scope where the rules run.
- Receive e-mail alerts when problems are found.
- Run rules an impromptu basis.
SharePoint Server 2010 can be configured to collect data and create reports about server status and site use. You perform the following using reporting:
- View administrative reports, such as search reports.
- Create and review Information Management Policy Usage reports.
- View health reports that include slowest pages and top active pages.
- View Web Analytics reports that include Web site traffic reports, search query reports, and customized reports.
Reference:
http://www.c-sharpcorner.com/uploadfile/Roji.Joy/monitoring-features-of-sharepoint-2010/
No comments:
Post a Comment