Beginning with SQL Server 2008 R2 (10.50.x), Reporting Services servers in SharePoint mode can write Reporting Services events to the SharePoint Unified Logging Service (ULS) trace log. Reporting Services specific categories are available on the Monitoring page of SharePoint Central Administration.
The following table lists event categories and levels that are recommended for monitoring a Reporting Services environment. When an event is logged, each entry includes the time the event was logged, the process name, and the thread ID.
Category
Level
Description
Database
Verbose
Logs events that involve database access.
General
Verbose
Logs events that involve access to the following items:
Reporting Services Web pages
Report Viewer HTTP handler
Report access (.rdl files)
Data sources (.rsds files)
URLs on the SharePoint site (.smdl files)
Office Server General
Exception
Logs sign in failures.
Topology
Verbose
Logs current user information.
Web Parts
Verbose
Logs events that involve access to the Report Viewer Web Part.
Turn on and off Reporting Services events in the Reporting Services category
From SharePoint Central Administration, select Monitoring.
Select Configure Diagnostic Logging in the Reporting group.
Find SQL Server Reporting Services in the category list.
Select the plus symbol (+) to expand the sub categories under SQL Server Reporting Services.
Choose the subcategories to be added to the trace log.
At the bottom of the categories list, select an event level for the Least critical event to report to the trace log. Select None to disable tracing.
Note
The option Least critical event to report to the event log isn't supported by Reporting Services. The option is ignored.
Recommended configuration
The following logging options are recommended as a standard configuration:
HTTP Redirector
SOAP Client Proxy
If you're experiencing issues with configuration, add Configuration Pages.
You can review all of the current farm diagnostic log settings with the following PowerShell cmdlet:
Get-SPDiagnosticConfig
Reading the logs entries
The Reporting Services entries in the log are formatted in the following way.
Product:SQL Server Reporting Services
Category: Events related to the server have the characters Report Server at the beginning of the name. For example, Report Server Alerting Runtime. These events are also logged to the report server log files.
Category: Events related to or communicated from a web front-end component don't contain Report Server, for example, Report Server Alerting Runtime. The WFE entries do contain a CorrelationID but the server entries don't.
List of SQL Server Reporting Services events
The following table is a list of the events in the SQL Server Reporting Services category:
Area Name
Description or sample entries
Configuration Pages
HTTP Redirector
Local Mode Processing
Local Mode Rendering
SOAP Client Proxy
UI Pages
Power View
Log entries that were written to the LogClientTraceEvents API. These entries are sourced from client applications, including Power View, a feature of SQL Server Reporting Services Add-in.
All log entries from the LogClientTraceEvents API are logged under the Category of SQL Server Reporting Services, and the Area of Power View.
The client application determines the content of entries logged with the area of Power View. Power View support is no longer available after SQL Server 2017.
Report Server Alerting Runtime
Report Server App Domain Manager
Report Server Buffered Response
Report Server Cache
Report Server Catalog
Report Server Chunk
Report Server Cleanup
Report Server Configuration Manager
Sample entries:
MediumUsing report server internal url https://localhost:80/ReportServer.
UnexpectedMissing or Invalid ExtendedProtectionLevel setting
Report Server Crypto
Report Server Data Extension
Report Server DB Polling
Report Server Default
Report Server Email Extension
Report Server Excel Renderer
Report Server Extension Factory
Report Server HTTP Runtime
Report Server Image Renderer
Report Server Memory Monitoring
Report Server Notification
Report Server Processing
Report Server Provider
Report Server Rendering
Report Server Report Preview
Report Server Resource Utility
Sample Entries:
MediumReporting Services starting SKU: Evaluation
MediumEvaluation copy: 180 days left
Report Server Running Jobs
Report Server Running Requests
Report Server Schedule
Report Server Security
Report Server Service Controller
Report Server Session
Report Server Subscription
Report Server WCF Runtime
Report Server Web Server
Service Application Proxy
Shared Service
Sample entries:
MediumUpdating ReportingWebServiceApplication
MediumGranting access to content databases.
MediumProvisioning instances for ReportingWebServiceApplication
MediumProcessing service account change for ReportingWebServiceApplication
MediumSetting database permissions.
View a log file with PowerShell
You can use PowerShell to return a list of the Reporting Services related events from a ULS Log file. Enter the following command from the SharePoint 2010 Management Shell to return a filtered list of rows from the file a ULS log file UESQL11SPOINT-20110606-1530.log that contains sql server reporting services:
Get-content -path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\UESQL11SPOINT-20110606-1530.log" | select-string "sql server reporting services"
There are also tools you can download that allow you read ULS logs. For example, the SharePoint LogViewer, available on GitHub.
The trace log files are found in the folder c:\Program Files\Common files\Microsoft Shared\Web Server Extensions\14\logs but you can verify or change the path from the Diagnostic Logging page in SharePoint Central Administration.
See the report server execution log that's in Reporting Services, which contains information about reports on servers in native mode or a SharePoint farm.
Learn how to enable the Report Server HTTP log after you install Reporting Services. This feature logs every HTTP request and response a report server handles.
Learn to audit and diagnose your Windows Server environment for regulatory compliance, user activity, and troubleshooting. Implement security best practices through regular audits of your network environment to gain early warning of potential malicious activity.