Azure Websites provides an excellent hosting platform for a variety of applications (websites), but while most applications are well written and running perfectly, sometimes bad things can happen to a good application. The root cause could be a code bug or a service wide issue, and the challenge resides in isolating or root causing the actual issue.

There are a variety of available data points that can help. For example, HTTP logs are available, as well as  Event Logs, Process memory dumps and more. The question is, what do I do with this data? How do I interpret these logs in a way that it either helps me resolve the issue or provides prescriptive guidance? Most of the time, you end up working with Microsoft’s support or forums community members to get some pointers for isolation and resolution, but wouldn’t it be nice to be able to click a single button and get some answers? Our new Diagnostics as a Service (DaaS for short), attempts to do exactly that!

To make things easy, DaaS is provided as a Site Extension. Please click here to watch a short video and get acquainted with it.

NoteDaaS is ONLY available for Basic and Standard modes.

 

F.A.Q

1) How can I access DaaS?

DaaS is a site extension and can be accessed via your site’s SCM endpoint. To do so, adjust the SCM URL based on your own site’s name and browser to it:

HTTP logs stored in external storage will not be analyzed and error out.

 

4) What does “Diagnose Now” option do?

You can think of this as your “something is wrong, help me now” button. This option will immediately start a diagnostic session with the default settings. By default, it will collect and analyze memory dumps, HTTP logs and event logs from all VM instances of your web site. It collects and analyzes a second memory dump after 2 minutes (this provides two different states of your application and is useful in troubleshooting slow performance issues). There is contextual help available with every option.

Notes:

• Running Diagnostics on a production website will have some performance implications, while data is being collected and analyzed.
• By default, the logs and reports are stored on the user’s file system under the DataDaaSLogs and DataDaaSReports folders respectively. It is recommended to download the data after every session and the delete them from the site to free up the space. See question 6 below on how to download the data. Subsequently, you can use scheduled analysis option (discussed below) and provide custom storage location for your data to be stored. This way you never lose your data.

 

5) What does “Schedule Analysis” option do?

This option provides you a way to customize your diagnostics sessions. It is a wizard driven experience that lets you do the following:

• Schedule a DaaS session at a specific time or timespan.
• Choose data type or types to collect and analyze (it has contextual help and warning that shows up on clicking next to a data type).
• It lets you choose a specific VM instance to collect and analyze data from (addressing a scenario where your website is running on multiple instances). If you chose no instances it’ll run against all instances by default.
• It lets you choose an option to collect and analyze right away, or just collect for now and analyze at some later time.
• Finally, it lets you configure a custom blob storage location for the data and reports to be stored. Once configured, this becomes your default option and even “Diagnose Now” option will start storing data to the specified blob storage.

 

 

6) Where is my data and reports stored by default?

By default, data and reports are stored in your website’s file system under the D:homedataDaaSReports and D:homedataDaaSLogs folders.

To download all reports and data from the VM, you can use SCM endpoint URL like below.

https://.scm.azurewebsites.net/Zip/data/DaaS

Note: You will need to replace YourSiteName with your actual site name

For sessions with custom blob storage locations, data will be stored in specified blobs.

 

If you are using your website’s file system instead of custom blob storage then it is highly recommended that you backup and delete the diagnostics data regularly (after every run) to avoid hitting disk quotas. The data and reports generated by DaaS on VM file system counts against your storage quotas.

 

7) Where is my data and reports displayed by default?

They are listed with download links under the Sessions section. Upon expanding a given session, it will list out the session time, data type collection and analysis status. Clicking on the navigate button ( the icon that looks like a little arrow inside a circle), will take you to that specific session’s details.

 

8) What does the analyzed reports look like?

Below are screenshots of report examples for 3 supported data types. Note that each report will vary based on your application/website and that the reports below show only the top part of each report.

Memory Dumps

HTTP Logs

Event Logs

 

 

 

9) Can I choose to collect and analyze additional data types like, PHP Logs, Customer Application logs etc.?

DaaS supports creating custom data collectors and analyzers (this process currently falls into the “power users” category, we’ll be making it easier in a future release). We’ll explain how to set them up in a future blog post.

 

10) Why do my memory dumps reports not provide any recommendations or why do the threads call stack not resolve to known method calls inside my application?

In the current release DaaS can only work with Microsoft public symbol servers. This means for OSS binaries like PHP it is unable to resolve the symbols. In the future DaaS will allow customers to upload OSS binaries or custom binaries symbols to their website’s content folder, which will allow DaaS to resolve correct symbols.