Sitecore Azure Log viewer

  0 rating
9/3/2013 1:56:38 AM
4/17/2015 1:39:27 PM
Provider: ClearPeople


When you use the Module Sitecore Azure 2.0 to move your Sitecore web site to Azure, you lose the log files and the old log viewer become useless. Now, the information is stored in the table WADLogstable, in the table storage. The idea behind this change is to be able to persist your logs, even if the vm supporting you application is replaced.

In order to review your logs, you should use a storage explorer  as "Azure storage explorer", or use the Azure Table Storage Driver of Linq Pad 4, etc. Due to the storage limitations, these applications are really uncomfortable when you're trying to find a problem, as is quite difficult (But possible) to filter by a range of dates, and it's not possible to do a wildcard search.

In order to make our lives a bit easier we've create the ClearPeople Azure Log Viewer. This module integrates within the Sitecore Azure Module 2.0 UI, and gives us the Sitecore logs and the windows events from within Sitecore and allows us to execute server searches by a date range, log level and instance name and then filter the results dynamically as we type.


  • Documentation > Requisites
    This module has been built on top of Sitecore Azure Module 2.0, so it's the only requisite.
  • Documentation > Installation
    Download the package and install it as any other package with the Installation wizard
  • Documentation > Configuration
    You can modify several settings of the module editing the file App_Config\Include\ClearPeople.Azure.config
    • ClearPeople.Azure.LogsViewer.MaxRowsPerRequest: This is the maximum number or records the application will request to the table storage. Usually, this is the maximum supported by the provider.
    • ClearPeople.Azure.LogsViewer.LogsTableName: This is the name of the table used to storage the logs.
    • ClearPeople.Azure.LogsViewer.WindowsEventsTableName: This is the name of the table used to storage the windows events.
    • ClearPeople.Azure.LogsViewer.NumberofExtraPagesToCache: The application will download extra pages and store them in cache.
    • ClearPeople.Azure.LogsViewer.DefaultHoursToGet: By default, the UI will get the logs from last x hours
    • ClearPeople.Azure.LogsViewer.FullyCachedTableSummaryText: Text to show in the summary when we've downloaded all the records available
    • ClearPeople.Azure.LogsViewer.CachingRowsPendingTableSummaryText: Text to show in the summary when there are pending rows to download.
    • ClearPeople.Azure.LogsViewer.StoageConnectionString: Connection string template
    • ClearPeople.Azure.LogsViewer.JQueryUIThemeUrl: URL of a jQueryUI theme
    • ClearPeople.Azure.LogsViewer.DialogWidth and ClearPeople.Azure.LogsViewer.DialogHeight: Dimensions of the dialog
    • ClearPeople.Azure.LogsViewer.BindGridOnLoad: Set this property to true to get logs when the application is opened. By default, the last two hours.
    • ClearPeople.Azure.LogsViewer.NoRecordsFoundText: Text to show when the server can't find any record for the selected filter.
    • ClearPeople.Azure.LogsViewer.LoadingText: Text to show while the application is busy.
  • Documentation > Using the Module
    Using the Module
    Open the Sitecore Azure module, and click on one of your farms. Two new options will appear at the bottom of the context menu.

    Here you can choose if you want to review Sitecore Logs, or Windows events. Both options will open the same interface, with the proper filter applied.

    Use the date time pickers to choose the period you are looking for. Choose a maximum log level if you don't want to get everything, the instance, if you need to filter per VM, and your desired number of rows and click "search". After a few seconds your logs will be there.

    If you're looking for a specific entry in the logs, click on "Filter current page", and type into the new text box. The filter will be applied instantly to the current page.

    You'll find a pagination control at the bottom of the table. You'll notice that the number of pages could increase while you're navigating through them. This is a Table storage limitation as you don't know the number of records until you get the last.

    Each different query will cache its own results, so if you go forward and backward through the pages, it won't create new request to the storage server.

Release notes
This is an initial version created for internal use. If you find any bug (you will), please help us to improve this tool sending your comments.
Don't install it directly in a production server, test it first. It won't damage your logs, but it will modify your settings and bin directory, so something could go wrong.
Keep in mind that queryng the table storage and downloading records has a cost.
Install the module at your own risk; we're not responsible of any damage it could cause.
For a list of issues and future releases plese visit the Git Hub Site
Read more Back
Code examples

Solution screenshots(0)


Reviews (0)

Sort by: Date Most votes
  • Profile Avatar

    Level: 0

    x0 x0 x0




    Was this helpful?


Comments (0)

Sort by: Date  Most votes

Leave a Comment

Comment must be field in
Post comment

Write a review

Title can't be empty
Review can't be empty
Post review


Title Description Download Action

Add File