Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Why should you set up your own SSL certificate versus using the certificate for
*.azurewebsites.net? (Choose all that apply.)
A. The *.azurewebsites.net certificate is more susceptible to phishing attacks.
B. The *.azurewebsites.net certificate is less secure.
C. You cannot use the *.azurewebsites.net certificate with a custom domain name.
D. Your data is not encrypted in transit with the *.azurewebsites.net certificate.
2. If you are developing a Node.js web application on Mac for deployment to Azure Websites, which tools might you use to manage your website? (Choose all that apply.) A. Windows PowerShell
B. xplat-cli
C. Management portal D. None of the above
3. Which of the following changes require you to update your DNS settings if you are using an A record to map your custom domain to your website? (Choose all that apply.) A. Deleting and re-adding the SSL certificate
B. Deleting the website and re-deploying C. Enabling SSL after configuring the A record
D. Switching your web hosting plan to Free tier and then back to Standard
Objective 1.3: Configure diagnostics, monitoring, and analytics
Operating a website without suitably configuring and leveraging diagnostics, monitoring, and analytics is like relying exclusively on your users calling to tell you about their experiences, what is working, and what is not. Without diagnostics, monitoring, and analytics, you cannot reac- tively investigate the cause of a failure, nor can you proactively prevent potential problems before your users experience them. Azure Websites provides multiple forms of logs, features for monitoring availability and automatically sending email alerts when the availability crosses a threshold, features for monitoring your website resource usage, and support for remotely debugging web application code.
This objective covers how to:
■
■ Retrieve diagnostics data and view streaming logs
■
■ Configure diagnostics
■
■ Use remote debugging
■
■ Configure endpoint monitoring
■
■ Configure alerts
■
■ Monitor website resources
Retrieving diagnostics data and viewing streaming logs
A web application hosted by Websites can leverage many different types of logs, each focused on presenting a particular source and format of diagnostic data. The following list describes each of these logs:
■
■ Event Log The equivalent of the logs typically found in the Windows Event Log on a Windows Server machine, this is a single XML file on the local file system of the website. In the context of Websites, the Event Log is particularly useful for capturing unhandled exceptions that may have escaped the application’s exception handling logic and surfaced to the web server. Only one XML file is created per website.
■
■ Web server logs Web server logs are textual files that create a text entry for each HTTP request to the website.
■
■ Detailed error message logs These HTML files are generated by the web server and log the error messages for failed requests that result in an HTTP status code of 400 or higher. One error message is captured per HTML file.
■
■ Failed request tracing logs In addition to the error message (captured by detailed error message logs), the stack trace that led to a failed HTTP request is captured in these XML documents that are presented with an XSL style sheet for in-browser consumption. One failed request trace is captured per XML file.
■
■ Application diagnostic logs These text-based trace logs are created by web application code in a manner specific to the platform the application is built in. For ASP.NET applications, these are created by invoking the logging methods in the System.Diagnostics.Trace class. Java, Node.js, Ruby, and Python applications running in Websites can emit similar text-based application diagnostic traces, with the log names, locations, and format specific to each platform.
Objective 1.3: Configure diagnostics, monitoring, and analytics CHAPTER 1 37 You can retrieve diagnostic data by using Visual Studio, the Site Control Management
(SCM) website, the command line in Windows PowerShell or the xplat-cli, or direct download via FTP to query Table or Blob storage.
Table 1-3 describes where to find each type of log when retrieving diagnostic data stored in the website’s local file system. The Log Files folder is physically located at D:\home\LogFiles.
TABLE 1-3 Locations of the various logs on the website’s local file system
Log Type Location
Event Log \LogFiles\eventlog.xml
Web server logs \LogFiles\http\RawLogs\*.log
Detailed error message logs \LogFiles\DetailedErrors\ErrorPage######.htm Failed request tracing logs \LogFiles\W3SVC*\*.xml
Also includes one *.xsd file that is used to format the XML file for display in supported browsers.
Application diagnostic logs (.NET) \LogFiles\Application\*.txt
Retrieving diagnostic data and log streaming using Visual Studio
Diagnostic data that’s configured to log to the file system of websites can be retrieved and viewed using Server Explorer within Visual Studio.
1. Launch Visual Studio.
2. From the View menu, select Server Explorer.
3. Expand the node labeled Azure. If you are prompted to log in, log in with your
organizational account or the Microsoft account that is associated with the website you want to manage.
4. Expand Websites.
5. Expand the website you want to manage.
6. Expand the Log Files folder to reveal the subfolders listed in Table 1-3, which contain the various diagnostic log files.
7. Expand any of the subfolders until you get to the desired file listing, and then double- click the file to download and open it within Visual Studio.
8. Alternately, to download the entire Log Files folder, complete the following steps:
A. In Server Explorer, right-click the website whose log files you want to download.
B. Select View Settings.
C. Click the Logs tab.
D. Under Actions, click the Download Logs link to download a *.zip file that contains all of the logs.
If in addition to or instead of having the application logs stored in the website’s local file system you want to retrieve the application logs stored in Azure Storage, complete the following steps:
1. In Server Explorer, right-click the website whose log files you want to download.
Objective 1.3: Configure diagnostics, monitoring, and analytics CHAPTER 1 39 2. Select View Settings.
3. Click the Logs tab.
4. Click the View All Application Logs link to open the logs table from Table storage.
EXAM TIP
Your own Failed Request Tracing Logs folder may include multiple folders that start with W3SVC. There are always two such folders because one is for your website and one is for the Site Control Manager (also known as Kudu) that runs in parallel to your website.
In addition to being able to download and view your application diagnostic logs, you can view them line by line as they are generated in real time in response to activity on the website. To view the logs in Visual Studio, in Server Explorer, right-click the website you want to monitor and select View Streaming Logs. The Output window appears and updates to indicate it has connected to the log streaming service. When the window is connected, any requests that generate application diagnostic trace output should cause the trace to appear in the output window.
Retrieving diagnostic data using Site Control Manager (Kudu)
Site Control Manager (SCM) (also known as Kudu) is a parallel website that is available with every deployed website, providing various management functions. In particular, it can be used to access and view diagnostic log data using only the browser. To access SCM, you must have administrator rights to the website. (If you can access the website via the portal, then you will be able to access SCM.) To retrieve data using SCM, complete the following steps:
1. Open your browser, and navigate to https://<yoursitename>.scm.azurewebsites.net. In the URL, ensure that you are accessing using SSL, that you replace <yoursitename>
with the name of your website, and that you add .scm. between your website’s name and .azurewebsites.net.
2. If you are not currently logged in with your organizational account or Microsoft ac- count, you will be prompted to log in. Be sure to use the credentials you would use to manage the website in the portal.
3. When you are logged in, click the Debug console menu, and select CMD.
4. In the screen that appears, you can explore the local file system of your website using a tabular view (top part of the screen) and a command line view (bottom part of the screen). In the tabular view, click the LogFiles folder.
5. A screen showing the root of all your log files appears. To view any of the files, click the download button (the left-most icon next to any file). To download a complete subdi- rectory (such as the entire DetailedErrors folder), click the download button to the far left of any subdirectory.
In SCM, you can also stream the logs, just as you can within Visual Studio. To do this, log in to the SCM website for your website, and complete the following steps:
6. From the Tools menu, select Log Stream.
7. When the page loads, you are connected to the log streaming service and can view the log entries as they are created in real time.
Retrieving diagnostic data using Windows PowerShell
Using the Azure PowerShell cmdlets, you can stream diagnostic logs. Ensure the cmdlets are installed and configured to connect to your subscription, and then use the command shown in Listing 1-7 to stream your diagnostic logs.
LISTING 1-7 Using Windows PowerShell to retrieve the streaming logs Get-AzureWebsiteLog -Name contoso -Tail
You will be connected to the log-streaming service and able to view the log records as they come in.
Objective 1.3: Configure diagnostics, monitoring, and analytics CHAPTER 1 41
Retrieving diagnostic data using the xplat-cli
Using the xplat-cli, you can download diagnostic logs, as well as stream application diagnostic logs. When the xplat-cli is installed, make sure that the default account is set to the subscrip- tion containing the website you are interested in, and then you can retrieve diagnostic data.
To download your diagnostic logs, from the command prompt, type the command shown in Listing 1-8.
LISTING 1-8 Downloading diagnostic logs using xplat-cli azure site log download
When prompted for the name of the website, enter just the name (not the full URL), and press Enter. When prompted for the website slot, press Enter to accept the default, or type the name of the slot and then press Enter. The diagnostic logs will download to your current directory as a file named Diagnostic.zip.
To connect your command window to the log-streaming service, enter the command shown in Listing 1-9.
LISTING 1-9 Using the xplat-cli to view streaming logs azure site tail
When prompted for the name of the website, enter just the name (not the full URL), and press Enter. When prompted for the website slot, press Enter to accept the default, or type the name of the slot and then press Enter.
You will be connected to the log-streaming service and able to view the log records as they come in.
Retrieving diagnostic data from FTP
You can download all of the diagnostic data using an FTP client. To do so, you must first set your deployment credentials for your website (these are different than your organizational or Microsoft account credentials used to access the portal). When those credentials are set, using the FTP client your choice, connect to the FTP host and enter your credentials to log in.
From the folder you connect to, drill down to the LogFiles folder where you can download your diagnostic logs.
RETRIEVING DIAGNOSTIC DATA FROM FTP (EXISTING PORTAL)
To retrieve diagnostic data from FTP in the management portal, complete the following steps:
1. Navigate to the dashboard of your website in the management portal accessed via https://manage.windowsazure.com.
2. Under Quick Glance, click Reset Your Deployment Credentials.
3. In the dialog box that appears, enter a username and password, and then confirm that password.
4. Click the check mark to save the deployment credentials, which are your FTP credentials.
5. Under Quick Glance, note the Deployment/FTP User. This is your username for FTP.
(You must include the website name that precedes the user you entered, so make sure you note it is <yourwebsitename>\<user> and not just <user>.)
6. Collect the FTP endpoint to connect to. Under Quick Glance, copy either the FTP Host Name or FTPS Host Name value (depending on what your FTP client supports and what you prefer to use).
7. Open your FTP client, and for the address, enter the FTP or FTPS host name. When prompted, enter your credentials. You are now connected via FTP and can download any of the log files from the LogFiles folder.
RETRIEVING DIAGNOSTIC DATA FROM FTP (PREVIEW PORTAL)
To retrieve diagnostic data from FTP in the Preview portal, complete the following steps:
1. Navigate to the blade of your website in the portal accessed via https://portal.azure.com.
2. Scroll down to Deployment and click Set Deployment Credentials.
3. On the blade that appears, enter a username and password, and then confirm that password.
Objective 1.3: Configure diagnostics, monitoring, and analytics CHAPTER 1 43 4. Click Save on the command bar.
5. Return to the blade of your website, click Settings, and then click Properties.
6. On the blade that appears, take note of the FTP/Deployment User. This is your username for FTP. (You must include the website name that precedes the user you entered, so make sure you note it is <yourwebsitename>\<user> and not just <user>.)
7. Collect the FTP endpoint to connect to. On the same blade as the user, copy either the FTP Host Name or FTPS Host Name value (depending on what your FTP client supports and what you prefer to use).
8. Open your FTP client, and for the address, enter the FTP or FTPS host name. When prompted, enter your credentials. You are now connected via FTP and can download any of the log files from the LogFiles folder.
Configuring diagnostics
The portal makes the configuration of diagnostic data a straightforward process, but you can also use the Azure PowerShell cmdlets and the xplat-cli to achieve the same results.
Configuring diagnostic data collection (existing portal)
To configure diagnostic data in the management portal, complete the following steps:
1. Navigate to the Configure tab of your website in the management portal accessed via https://manage.windowsazure.com.
2. Scroll down to Application Diagnostics. Application diagnostic logs are configured using the controls in this section.
3. To enable collection of application diagnostic logs to the local file system of the web- site, change the Application Logging (File System) option to On, and select a logging level.
4. To enable collection of application diagnostic logs to Table storage, change the Application Logging (Table Storage) option to On, and select a logging level. Click Manage Table Storage to choose a storage account from within your active subscrip- tion, as well as to create a new table or to write the log data to an existing table. Click the check mark to close the dialog box.
5. To enable writing the diagnostic logs to files in Blob storage, change the Application Logging (Blob Storage) option to On, and select a logging level. Optionally, select the Set Retention check box and enter a number of days to keep the log files. Click Man- age Blob Storage to choose a storage account from within your active subscription, as well as to create a new blob container or to write the log data to an existing blob container. Click the check mark to close the dialog box.
IMPORTANT AZURE STORAGE AND LOG DATA LIMITATIONS
Application diagnostic logging to Table or Blob storage is supported only for .NET applica- tions. While the portal may let you enable it for any website, log data will be collected to Azure Storage only from a .NET application.
6. To configure web server logs, detailed error message logs, and failed request tracing logs, on the Configure tab, scroll down to Site Diagnostics.
Objective 1.3: Configure diagnostics, monitoring, and analytics CHAPTER 1 45 7. To enable writing the diagnostic logs to the local file system of the website, change the
Web Server Logging option to File System and set a quota for the space consumed by these logs to between 25 and 100 MB. Optionally, select the Set Retention check box and enter a number of days to keep the log files.
8. To enable writing the diagnostic logs to Blob storage, change the Web Server Log- ging option to Storage. Optionally, select the Set Retention check box and enter a number of days to keep the log files. Click Manage Blob Storage to choose a storage account from within your active subscription, as well as to create a new blob container or to write the log data to an existing blob container. Click the check mark to close the dialog box.
9. To enable writing of detailed error message logs to the local file system of the website, change the Detailed Error Messages option to On.
10. To enable writing of failed request logs to the local file system of the website, change the Failed Request Tracing option to On.
11. After completing your application and site diagnostic configuration, be sure to click Save on the command bar to apply the changes to your website.
Configuring diagnostic data collection (Preview portal)
To configure diagnostic data collection in the Preview portal, complete the following steps:
1. Navigate to the blade of your website in the portal accessed via https://portal.azure.com.
2. Under Summary, click Settings, and then click Diagnostic Logs.
3. On the Logs blade, switch the desired logs to the On position.
4. Click Save.
NOTE EVENT LOG IS ALWAYS ENABLED
You may have noticed that there is no configuration setting for Event Log. This log is always enabled.
Using remote debugging
Remote debugging enables you to use your local copy of Visual Studio to debug an ASP.NET application running in Websites. When you are remote debugging, you can use Visual Studio to set breakpoints, examine variable values, and step through code. To debug a deployed website, you must ensure that it is a debug build (for example, it has the debug symbols).
After you have deployed a debug build, complete the following steps to start a debug session within Visual Studio.
1. Ensure the project you are debugging is built and that you have made no changes to it since you deployed it to Websites.
2. From the View menu, select Server Explorer.
3. Expand the node labeled Azure. If prompted to log in, login with your organizational account or the Microsoft account that is associated with the website you want to manage.
4. Expand Websites.
5. Right-click the website to debug and select Attach Debugger.
6. If you have never attached the remote debugger before, this process might take up to 30 seconds as it automatically configures the website for debugging.
7. When your web application’s home page has loaded in the browser, start debugging as you would if the code were running locally.
IMPORTANT HOW DEBUGGING AFFECTS YOUR WEBSITE
When you attach the debugger and pause at a breakpoint, you are stopping the deployed Azure website for all requests, so it is not a good idea to rely on this technique for produc- tion debugging because users will think your website is down. Also, if you spend more than a few minutes stopped at any one breakpoint, Azure will treat your Websites worker pro- cess as having become unresponsive and try to restart it, so be prepared to move quickly when attached with the remote debugger to a website.
Configuring endpoint monitoring
You can use endpoint monitoring to leverage Azure to provide outside-in monitoring of your website. That is, you leverage a service remote to your website, possibly in multiple regions around the world, to periodically ping your website to assess its health. To enable endpoint monitoring, provide the URL of the endpoint on your website that it should ping, and choose where you want to ping from. The results of these pings appear in the status dashboards for your website and can also be used to create alerts that send out an email when the results fall outside of thresholds you configure.