Have you ever felt the need to check how your reporting services instances are in terms of health? I’m going to give some tips that can start helping you on this subject, but first let’s understand how Reporting Services Logs are structured:
Report Server Execution Log
- The report server execution log contains data about reports execution status, including when a report was run, who ran it, where it was delivered, and which rendering format was used. This log is stored in the report server database and can be accessed through ExectutionLog2 view.
Report Server Service Trace Log
- The service trace log contains detailed information that is useful if you are debugging an application or investigating an issue or event. This log is saved into LogFiles directory in Reporting Services installation folder.
Report Server HTTP Log
- It contains a record of all HTTP requests and responses handled by the Report Server Web service and Report Manager.
Windows Application Log
- The Microsoft Windows Application log contains information about report server events.
Windows Performance logs
- The Windows Performance logs contain report server performance data. You can create performance logs, and then choose counters that determine which data to collect from Reporting Services Objects.
SharePoint trace log
- For report servers running in SharePoint integrated mode, the SharePoint trace logs contains Reporting Services information. You can also configure SSRS specific information for the SharePoint Unified Logging service (ULS).
Here are three useful guidelines you can use in your Reporting Services infrastructure and keep track of common problems you might have in a daily basis:
1. Check the percentage of reports that have errors during execution
With a simple query, check which reports have Status column different of rsSuccess in the execution log view. This can give you an overall perspective of which reports are being executed correctly and which ones are not. A good point to start is parameters combination.
2. Check which reports are running slow
Usually, users are always complaining about reports that are too slow after they make the request to Report Server. In execution log view, check for reports which take more time by doing the difference between TimeEnd and TimeStart columns. You can also see if most of this time is in data retrieval, processing or rendering from the correspondent columns.
This type of findings can take you to the next step of Reporting Services management: start using report caching!
3. Search for general exceptions in your report server trace log
With the help of Reporting Services LogViewer tool you can parse the log files from your installation directory and drill down into log information. This information is useful to get memory problems, report errors and misconfiguration.
I hope that the information on these pages is valuable to you. Your use of the information contained in these pages, however, is at your sole risk. All information on these pages is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Ezequiel. Further, Ezequiel shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.