Windows Azure Cloud Service Basics: Remote monitoring

Welcome to the Fourth blog post about designing and implementing remote monitoring components in the cloud service base (CSF) in Windows http://www.aliyun.com/zixun/aggregation/13357.html >azure! So far, we have described the basic principles of application health in remote monitoring basics and troubleshooting, and outlined the basic tools, information sources, and scripts that are useful for you to information about the Windows Azure solution you are deploying. In the second article, we describe the remote monitoring-application health measurement, which describes how the application itself becomes the largest source of information for monitoring, and how the application can be reasonably used after it is put into production to achieve a manageable goal. In the third article, we describe how to scale and automate the data pipeline to gather monitoring and diagnostics information for different components and services in the solution, and to consolidate this information in the operational storage that can be queried.

This is the fourth blog to report as a topic, and the basics include demonstrating how to get the required system information to meet the various analysis and reporting requirements of your organization. We will outline the solutions provided in this blog and detail the implementation process in the appropriate WIKI articles. Specifically, we'll show you how to quickly extract information, such as database-tier resource utilization, end-to-end execution time analysis, and how to turn this information into reports and dashboards. The Wiki article then details the implementation of the operations store and provides an example of how to perform a profiling query on it. In addition, we will cover the reporting packages we provide and how to use Excel for in-depth analysis. After that, we'll show you how to extend the Help features provided to get the details that meet your needs.

Remote monitoring database in CSF

The previous article in this series discusses the data pipeline, which is the implementation of the CSF for the collector task shown in the following data flow diagram. With these collector tasks, the CSF remote monitoring worker role and scheduler can populate the remote Monitoring database periodically (periodically configurable). In this article, we describe the process of thinking that needs to be experienced in order to determine analysis and reporting requirements. Then provide detailed information in the appropriate WIKI article so that you know how to extract the information (as shown on the right side of the diagram) to provide this information through the reporting service, SSMS, and Excel.

Define reporting scenarios and requirements

The first critical step in effectively penetrating your remote monitoring data is defining the reporting scenario and its key requirements. A useful way to define a CSF remote monitoring solution is to first define three scenarios: Operational reporting scenarios, alert scenarios, and root-cause isolation scenarios. The "I can" method is then used to define the key requirements. Next, prioritize these scenarios so that most operational reporting scenarios and root-cause isolation scenarios can be implemented in a new CSF experience. The underlying data structure can meet your alert needs.

This approach is an important first step, allowing us to consider how the infrastructure supports existing requirements and potential future requirements, whether they are defined or later extended to remote monitoring databases. Therefore, you should use this approach especially if you plan to extend your remote monitoring database.

The following figure highlights specific portions of the CSF package associated with remote monitoring databases and reporting solutions.

We hope this will deepen your understanding of the solution.