Azure & Office 365

Posts Tagged ‘tracing’

Introduction:
SharePoint is architecture to proactively monitor lot of system and manage them. Sole purpose is to catch issues before they occur. Still if issues do occur, the system should give the administrator the capability to debug the issues with the least amount of resistance.

Lets talk about logging database. Logging collects information from all the servers and store it in 1 database. They are similar to ULS logs. ULS logs are stored in 14\logs folder collected and in event logs. It strengthens the logging database and make it a valuable tool.

Another area to concentrate on is Reporting services. These Reports are present for site collection level and they are pretty robust. Administrators utilized them as what they are searching for, and uncovers where functionality is lacking. SharePoint 2010 health monitoring jobs have the ability to uncover issues, report them, and then SharePoint is able to automatically correct the issue (in some cases).

Monitoring and reporting capabilities together makes administrator to be proactive when it comes to SharePoint farm management. These capabilities can be leveraged with other SharePoint functions such as alerts, so that the team managing the SharePoint farm should be well versed in the performance of the installation.

SharePoint 2010 logging database information:
SharePoint 2010 logging database is a major enhancement to monitoring, debugging, and protecting the health of the farm.

By default, the database is called WSS_Logging . This database should be the starting point for administrators to collect and analyze information.

ULS Logs are available at C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\14\Logs.

Access logging from SQL server:

• Open up SQL Server Management Studio.
• When asked for authentication, log in to the correct instance where SharePoint is running using your windows authentication credentials.
• Navigate to the WSS_Logging database and click on the plus sign to expand it.
• Under the toolbar at the top, click on the New Query button.
• In the new query window, type in the following query: Select * from RequestUsage.
• Click Execute.

Configuring what gets logged

SharePoint logging database capturing information can be modified via the Central Administration interface. The advantage of this being that the collection of information can be voluminous, which can also be the disadvantage.

Disk space, I/O, and just the amount of data needed to retain this information can become an issue. Being able to reduce the type of information that gets captured is critical to the wellness of your farm.
How to do it…

• Open the SharePoint 2010 Central Administration website.
• Click Monitoring.
• Under the Reporting section, click Configure usage and health data collection.

How it works…

The options presented in the usage and health data collection are logged to the logging database and to the ULS logs.

The health logging schedule can be modified to fit the needs (also known as Service Level Agreements) of your organization. It is important to remember that there is a hidden cost associated with the increased logging. The hidden cost is mainly in the form of storage and possibly performance.

The ULS logs have the potential to grow large. The logs can be moved to a new physical location (physical spindle), which does not contain the operating system or WFE/Application server software. The physical location reference must exist on all servers in the farm.

The location of the logs is set within Central Administration. To access the setting, go to Central Administration, click Monitoring, and then select Configure diagnostic logging. Under the Trace Log section is the Path. This contains the location of the ULS logs.
The logging information is retained for a period of 14 days by default. Using PowerShell you can change this parameter, using the following command:

Set-SPUsageDefinition -Identity <GUID> [-Enable] -DaysRetained 14

 

To be continued