You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can monitor key performance metrics for any cloud service. Every cloud service role collects minimal data: CPU usage, network usage, and disk utilization. If the cloud service has the `Microsoft.Azure.Diagnostics` extension applied to a role, that role can collect additional points of data. This article provides an introduction to Azure Diagnostics for Cloud Services.
17
+
You can monitor key performance metrics for any cloud service. Every cloud service role collects minimal data: CPU usage, network usage, and disk utilization. If the cloud service has the `Microsoft.Azure.Diagnostics` extension applied to a role, that role can collect more points of data. This article provides an introduction to Azure Diagnostics for Cloud Services.
18
18
19
-
With basic monitoring, performance counter data from role instances is sampled and collected at 3-minute intervals. This basic monitoring data is not stored in your storage account and has no additional cost associated with it.
20
-
21
-
With advanced monitoring, additional metrics are sampled and collected at intervals of 5 minutes, 1 hour, and 12 hours. The aggregated data is stored in a storage account, in tables, and is purged after 10 days. The storage account used is configured by role; you can use different storage accounts for different roles. This is configured with a connection string in the [.csdef](cloud-services-model-and-package.md#servicedefinitioncsdef) and [.cscfg](cloud-services-model-and-package.md#serviceconfigurationcscfg) files.
19
+
With basic monitoring, performance counter data from role instances is sampled and collected at 3-minute intervals. This basic monitoring data isn't stored in your storage account and has no additional cost associated with it.
22
20
21
+
With advanced monitoring, more metrics are sampled and collected at intervals of 5 minutes, 1 hour, and 12 hours. The aggregated data is stored in a storage account, in tables, and is purged after 10 days. The storage account used is configured per role; you can use different storage accounts for different roles. You use a connection string in the [.csdef](cloud-services-model-and-package.md#servicedefinitioncsdef) and [.cscfg](cloud-services-model-and-package.md#serviceconfigurationcscfg) files for configuration.
23
22
24
23
## Basic monitoring
25
24
26
25
As stated in the introduction, a cloud service automatically collects basic monitoring data from the host virtual machine. This data includes CPU percentage, network in/out, and disk read/write. The collected monitoring data is automatically displayed on the overview and metrics pages of the cloud service, in the Azure portal.
27
26
28
-
Basic monitoring does not require a storage account.
27
+
Basic monitoring doesn't require a storage account.
29
28
30
29
31
30
32
31
## Advanced monitoring
33
32
34
-
Advanced monitoring involves using the **Azure Diagnostics** extension (and optionally the Application Insights SDK) on the role you want to monitor. The diagnostics extension uses a config file (per role) named **diagnostics.wadcfgx** to configure the diagnostics metrics monitored. The Azure Diagnostic extension collects and stores data in an Azure Storage account. These settings are configured in the **.wadcfgx**, [.csdef](cloud-services-model-and-package.md#servicedefinitioncsdef), and [.cscfg](cloud-services-model-and-package.md#serviceconfigurationcscfg) files. This means that there is an extra cost associated with advanced monitoring.
33
+
Advanced monitoring involves using the **Azure Diagnostics** extension (and optionally the Application Insights SDK) on the role you want to monitor. The diagnostics extension uses a config file (per role) named **diagnostics.wadcfgx** to configure the diagnostics metrics monitored. The Azure Diagnostic extension collects and stores data in an Azure Storage account. These settings are configured in the **.wadcfgx**, [.csdef](cloud-services-model-and-package.md#servicedefinitioncsdef), and [.cscfg](cloud-services-model-and-package.md#serviceconfigurationcscfg) files. This means that there's an extra cost associated with advanced monitoring.
35
34
36
35
As each role is created, Visual Studio adds the Azure Diagnostics extension to it. This diagnostics extension can collect the following types of information:
37
36
38
37
* Custom performance counters
39
38
* Application logs
40
39
* Windows event logs
41
40
* .NET event source
42
-
* IIS logs
43
-
* Manifest based ETW
44
-
* Crash dumps
41
+
* Internet Information Services (IIS) logs
42
+
* Manifest based Event Tracing for Windows (ETW)
45
43
* Customer error logs
46
44
47
45
> [!IMPORTANT]
@@ -57,7 +55,7 @@ There are two config files you must change for advanced diagnostics to be enable
57
55
58
56
### ServiceDefinition.csdef
59
57
60
-
In the **ServiceDefinition.csdef** file, add a new setting named `Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString` for each role that uses advanced diagnostics. Visual Studio adds this value to the file when you create a new project. In case it is missing, you can add it now.
58
+
In the **ServiceDefinition.csdef** file, add a new setting named `Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString` for each role that uses advanced diagnostics. Visual Studio adds this value to the file when you create a new project. In case it's missing, you can add it now.
This defines a new setting that must be added to every **ServiceConfiguration.cscfg** file.
67
+
This snippet defines a new setting that must be added to every **ServiceConfiguration.cscfg** file.
70
68
71
69
Most likely you have two **.cscfg** files, one named **ServiceConfiguration.cloud.cscfg** for deploying to Azure, and one named **ServiceConfiguration.local.cscfg** that is used for local deployments in the emulated environment. Open and change each **.cscfg** file. Add a setting named `Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString`. Set the value to the **Primary connection string** of the classic storage account. If you want to use the local storage on your development machine, use `UseDevelopmentStorage=true`.
72
70
@@ -84,10 +82,9 @@ Most likely you have two **.cscfg** files, one named **ServiceConfiguration.clou
84
82
85
83
## Use Application Insights
86
84
87
-
When you publish the Cloud Service from Visual Studio, you are given the option to send the diagnostic data to Application Insights. You can create the Application Insights Azure resource at that time or send the data to an existing Azure resource. Your cloud service can be monitored by Application Insights for availability, performance, failures, and usage. Custom charts can be added to Application Insights so that you can see the data that matters the most. Role instance data can be collected by using the Application Insights SDK in your cloud service project. For more information on how to integrate Application Insights, see [Application Insights with Cloud Services](../azure-monitor/app/azure-web-apps-net-core.md).
88
-
89
-
Note that while you can use Application Insights to display the performance counters (and the other settings) you have specified through the Windows Azure Diagnostics extension, you only get a richer experience by integrating the Application Insights SDK into your worker and web roles.
85
+
When you publish the Cloud Service from Visual Studio, you have the option to send the diagnostic data to Application Insights. You can create the Application Insights Azure resource at that time or send the data to an existing Azure resource. Application Insights can monitor your cloud service for availability, performance, failures, and usage. Custom charts can be added to Application Insights so that you can see the data that matters the most. Role instance data can be collected by using the Application Insights SDK in your cloud service project. For more information on how to integrate Application Insights, see [Application Insights with Cloud Services](../azure-monitor/app/azure-web-apps-net-core.md).
90
86
87
+
While you can use Application Insights to display the performance counters (and the other settings) you specified through the Microsoft Azure Diagnostics extension, you only get a richer experience by integrating the Application Insights SDK into your worker and web roles.
Conditions can be set for a cloud service worker role that trigger a scale in or out operation. The conditions for the role can be based on the CPU, disk, or network load of the role. You can also set a condition based on a message queue or the metric of some other Azure resource associated with your subscription.
18
+
You can set conditions for a cloud service worker role to trigger scale in or out operations. The conditions for the role can be based on the CPU, disk, or network load of the role. You can also set a condition based on a message queue or the metric of some other Azure resource associated with your subscription.
19
19
20
20
> [!NOTE]
21
21
> This article focuses on Cloud Service (classic). When you create a virtual machine (classic) directly, it is hosted in a cloud service. You can scale a standard virtual machine by associating it with an [availability set](/previous-versions/azure/virtual-machines/windows/classic/configure-availability-classic) and manually turn them on or off.
22
22
23
23
## Considerations
24
24
You should consider the following information before you configure scaling for your application:
25
25
26
-
*Scaling is affected by core usage.
26
+
*Core usage affects scaling.
27
27
28
-
Larger role instances use more cores. You can scale an application only within the limit of cores for your subscription. For example, say your subscription has a limit of 20 cores. If you run an application with two medium-sized cloud services (a total of 4 cores), you can only scale up other cloud service deployments in your subscription by the remaining 16 cores. For more information about sizes, see [Cloud Service Sizes](cloud-services-sizes-specs.md).
28
+
Larger role instances use more cores. You can scale an application only within the limit of cores for your subscription. For example, say your subscription has a limit of 20 cores. If you run an application with two medium-sized cloud services (a total of four cores), you can only scale up other cloud service deployments in your subscription by the remaining 16 cores. For more information about sizes, see [Cloud Service Sizes](cloud-services-sizes-specs.md).
29
29
30
30
* You can scale based on a queue message threshold. For more information about how to use queues, see [How to use the Queue Storage Service](/azure/storage/queues/storage-quickstart-queues-dotnet?tabs=passwordless%2Croles-azure-portal%2Cenvironment-variable-windows%2Csign-in-azure-cli).
31
31
32
32
* You can also scale other resources associated with your subscription.
33
33
34
-
* To enable high availability of your application, you should ensure that it is deployed with two or more role instances. For more information, see [Service Level Agreements](https://azure.microsoft.com/support/legal/sla/).
34
+
* To enable high availability of your application, you should ensure it deploys with two or more role instances. For more information, see [Service Level Agreements](https://azure.microsoft.com/support/legal/sla/).
35
35
36
36
* Auto Scale only happens when all the roles are in **Ready** state.
37
37
@@ -40,7 +40,7 @@ You should consider the following information before you configure scaling for y
40
40
After you select your cloud service, you should have the cloud service blade visible.
41
41
42
42
1. On the cloud service blade, on the **Roles and Instances** tile, select the name of the cloud service.
43
-
**IMPORTANT**: Make sure to click the cloud service role, not the role instance that is below the role.
43
+
**IMPORTANT**: Make sure to select the cloud service role, not the role instance that is below the role.
44
44
45
45
46
46
2. Select the **scale** tile.
@@ -60,7 +60,7 @@ Set the **Scale by** option to **schedule and performance rules**.
60
60
61
61
Select **Add Profile**. The profile determines which mode you want to use for the scale: **always**, **recurrence**, **fixed date**.
62
62
63
-
After you have configured the profile and rules, select the **Save** icon at the top.
63
+
After you configure the profile and rules, select the **Save** icon at the top.
64
64
65
65
#### Profile
66
66
The profile sets minimum and maximum instances for the scale, and also when this scale range is active.
@@ -81,7 +81,7 @@ The profile sets minimum and maximum instances for the scale, and also when this
81
81
82
82
83
83
84
-
After you have configured the profile, select the **OK** button at the bottom of the profile blade.
84
+
After you configure the profile, select the **OK** button at the bottom of the profile blade.
85
85
86
86
#### Rule
87
87
Rules are added to a profile and represent a condition that triggers the scale.
@@ -90,7 +90,7 @@ The rule trigger is based on a metric of the cloud service (CPU usage, disk acti
90
90
91
91
92
92
93
-
After you have configured the rule, select the **OK** button at the bottom of the rule blade.
93
+
After you configure the rule, select the **OK** button at the bottom of the rule blade.
94
94
95
95
## Back to manual scale
96
96
Navigate to the [scale settings](#where-scale-is-located) and set the **Scale by** option to **an instance count that I enter manually**.
@@ -103,4 +103,4 @@ This setting removes automated scaling from the role and then you can set the in
103
103
2. A role instance slider to set the instances to scale to.
104
104
3. Instances of the role to scale to.
105
105
106
-
After you have configured the scale settings, select the **Save** icon at the top.
106
+
After you configure the scale settings, select the **Save** icon at the top.
The cmdlet blocks momentarily while the new instances are provisioned and started. During this time, if you open a new PowerShell window and call **Get-AzureRole** as shown earlier, you will see the new target instance count. And if you inspect the role status in the portal, you should see the new instance starting up:
60
+
The cmdlet blocks momentarily while the new instances are provisioned and started. During this time, if you open a new PowerShell window and call **Get-AzureRole** as shown earlier, you see the new target instance count. If you inspect the role status in the portal, you should see the new instance starting up:
61
61
62
62
63
63
64
-
Once the new instances have started, the cmdlet will return successfully:
64
+
Once the new instances start, the cmdlet returns successfully:
@@ -71,4 +71,4 @@ You can scale in a role by removing instances in the same way. Set the **Count**
71
71
72
72
## Next steps
73
73
74
-
It is not possible to configure auto-scale for cloud services from PowerShell. To do that, see [How to auto scale a cloud service](cloud-services-how-to-scale-portal.md).
74
+
It isn't possible to configure autoscale for cloud services from PowerShell. To do that, see [How to auto scale a cloud service](cloud-services-how-to-scale-portal.md).
0 commit comments