Buscar

DOCUMENTAÇÃO AZURE

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 471 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 471 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 471 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Table of ContentsTable of Contents
 Azure Monitor Documentation
 Overview
 Monitoring in Azure
 Quickstarts
 Alert (classic) on metric condition
 Alert on subscription activity
 Tutorials
 Autoscale on performance and schedule
 Archive monitoring data
 Concepts
 Sources of monitoring data
 Azure Monitor
 Metrics
 Autoscale
 Diagnostic logs
 Activity log
 Alerts
 Alerts (classic)
 Log alerts
 Activity log alerts (Preview)
 Extend alerts from Log Analytics to Azure
 Action groups
 Azure Diagnostics Extension
 Roles permissions and security
 Partner integrations
 How-to guides
 Walkthrough of Azure Monitor
 Create metrics charts in Metrics Explorer
 Use alerts
 Configure new metric or log alerts in Azure portal
 Configure classic alerts in Azure portal
 Configure classic alerts with CLI
 Configure classic alerts with Azure PowerShell
 Webhook actions for log alerts
 Create a classic metric alert with a Resource Manager template
 Copy alerts from OMS portal to Azure portal
 Use action groups with alerts
 Learn about the webhook schema
 SMS alert behavior
 Alert rate limiting
 Create action groups with Resource Manager
 Use diagnostic logs
 Archive
 Send to Log Analytics
 Stream to Event Hubs
 Enable diagnostic settings with Resource Manager templates
 Use activity log
 View events in activity log
 Configure alerts on an activity log event
 Archive activity log
 Stream activity log to Event Hubs
 Audit operations with Resource Manager
 Create activity log alerts with Resource Manager
 Migrate to activity log alerts
 Use service notifications
 View service notifications
 Configure alerts on service notifications
 Programmatic access
 Walkthrough using REST API
 Azure PowerShell samples
 Use Azure Diagnostics extension
 Send to Application Insights
 Send to Event Hubs
 Troubleshooting
 Use autoscale
 Walkthrough of autoscale
 Understand Autoscale settings
 Best practices
 Common metrics
 Common patterns
 Autoscale using a custom metric
 Autoscale VM scale sets using Resource Manager templates
 Automatically scale machines in a VM scale set
 Configure webhooks and email notifications on autoscale
 Route to other locations
 Send metrics to Grafana
 Send monitoring data to an event hub
 Reference
 Azure CLI
 Azure PowerShell
 REST
 Supported metrics
 Supported metrics for newer alerts
 Diagnostic logs services, categories, and schemas
 Activity log event schema
 Azure Diagnostics extension schema
 Resources
 Azure Roadmap
 Pricing calculator
 Regional availability
 Videos
 Quickstart templates
 Stack Overflow
 Code samples
 Usage and estimated costs
Monitoring Azure applications and resources
4/6/2018 • 9 min to read • Edit Online
Shared Capabilities
AlertsAlerts
Monitoring is the act of collecting and analyzing data to determine the performance, health, and availability of
your business application and the resources that it depends on. An effective monitoring strategy helps you
understand the detailed operation of the components of your application. It also helps you increase your uptime
by proactively notifying you of critical issues so that you can resolve them before they become problems.
Azure includes multiple services that individually perform a specific role or task in the monitoring space. Together,
these services deliver a comprehensive solution for collecting, analyzing, and acting on telemetry from your
application and the Azure resources that support them. They can also work to monitor critical on-premises
resources in order to provide a hybrid monitoring environment. Understanding the tools and data that are
available is the first step in developing a complete monitoring strategy for your application.
The following diagram shows a conceptual view of the components that work together to provide monitoring of
Azure resources. The following sections describe these components and provide links to detailed technical
information.
The core and deep monitoring service share functionality which provides the following capabilities.
DashboardsDashboards
Metrics ExplorerMetrics Explorer
Core monitoring
Azure MonitorAzure Monitor
NOTENOTE
Azure AdvisorAzure Advisor
Service HealthService Health
Azure alerts proactively notify you of critical conditions and potentially take corrective action. Alert rules can use
data from multiple sources, including metrics and logs. They use action groups, which contain unique sets of
recipients and actions in response to an alert. Based on your requirements, you can have alerts start external
actions by using webhooks and integrate with your ITSM tools.
You can use Azure dashboards to combine different kinds of data into a single pane in the Azure portal. You can
then share the dashboard with other Azure users.
For example, you can create a dashboard that combines:
Tiles that show a graph of metrics
A table of activity logs
A usage chart from Application Insights
The output of a log search in Log Analytics
You can also export Log Analytics data to Power BI. There, you can take advantage of additional visualizations. You
can also make the data available to others within and outside your organization.
Metrics are numerical values generated by an Azure resource to help you understand the operation and
performance of the resource. By using Metrics Explorer, you can send metrics to Log Analytics for analysis with
data from other sources.
Core monitoring provides fundamental, required monitoring across Azure resources. These services require
minimal configuration and collect core telemetry that the premium monitoring services use.
Azure Monitor enables core monitoring for Azure services by allowing the collection of metrics, activity logs, and
diagnostic logs. For example, the activity log tells you when new resources are created or modified.
Metrics are available that provide performance statistics for different resources and even the operating system
inside a virtual machine. You can view this data with one of the explorers in the Azure portal and create alerts
based on these metrics. Azure Monitor provides the fastest metrics pipeline (5 minute down to 1 minute), so you
should use it for time critical alerts and notifications.
You can also send these metrics and logs Azure Log Analytics for trending and detailed analysis, or create
additional alert rules to proactively notify you of critical issues as a result of that analysis.
Sending multi-dimensional metrics to Log Analytics via diagnostic settings is not currently supported. Metrics with
dimensions are exported as flattened single dimensional metrics, aggregated across dimension values.
For example: The 'Incoming Messages' metric on an Event Hub can be explored and charted on a per queue level. However,
when exported to Log Analytics the metric will be represented as all incoming messages across all queues in the Event Hub.
Azure Advisor constantly monitors your resource configuration and usage telemetry. It then gives you
personalized recommendations based on best practices. Following these recommendations helps you improve the
performance, security, and availability of the resources that support your applications.
Activity LogActivity Log
Deep monitoring services
Deep application monitoring
Application InsightsApplication Insights
Deep infrastructure monitoring
Log AnalyticsLog Analytics
Management solutionsManagement solutions
The health of your application relies on the Azure services that it depends on. Azure Service Health identifies any
issues with Azure services that might affect your application. Service Health also helps you plan for scheduled
maintenance.
Activity Log provides data about the operation of an Azure resource. This information includes:
Configuration changes to the resource.Service health incidents.
Recommendations on better utilizing the resource.
Information related to autoscale operations.
You can view logs for a particular resource on its page in the Azure portal. Or you can view logs from multiple
resources in Activity Log Explorer.
You can also send activity log entries to Log Analytics. There, you can analyze the logs by using data collected by
management solutions, agents on virtual machines, and other sources.
The following Azure services provide rich capabilities for collecting and analyzing monitoring data at a deeper
level. These services build on core monitoring and take advantage of common functionality in Azure. They provide
powerful analytics with collected data to give you unique insights into your applications and infrastructure. They
present data in the context of scenarios that are targeted to different audiences.
You can use Azure Application Insights to monitor availability, performance, and usage of your application,
whether it's hosted in the cloud or on-premises.
By instrumenting your application to work with Application Insights, you can achieve deep insights and implement
DevOps scenarios. You can quickly identify and diagnose errors without waiting for a user to report them. With
the information that you collect, you can make informed choices on your application's maintenance and
improvements.
Application Insights has extensive tools for interacting with the data that it collects. Application Insights stores its
data in a common repository. It can take advantage of shared functionality such as alerts, dashboards, and deep
analysis with the Log Analytics query language.
Log Analytics plays a central role in Azure monitoring by collecting data from a variety of resources (including
non-Microsoft tools) into a single repository. There, you can analyze the data by using a powerful query language.
Application Insights and Azure Security Center store their data in the Log Analytics data store and use its analytics
engine. Data is also collected from Azure Monitor, management solutions, and agents installed on virtual
machines in the cloud or on-premises. This shared functionality helps you form a complete picture of your
environment.
Management solutions are packaged sets of logic that provide insights for a particular application or service. They
rely on Log Analytics to store and analyze the monitoring data that they collect.
Network MonitoringNetwork Monitoring
Service MapService Map
Example scenarios
Monitoring a web applicationMonitoring a web application
Management solutions are available from Microsoft and partners to provide monitoring for various Azure and
third-party services. Examples of monitoring solutions include:
Container Monitoring, which helps you view and manage your container hosts.
Azure SQL Analytics, which collects and visualizes performance metrics for Azure SQL databases.
You can view all available management solutions in the Azure Portal under the Monitor screen.
There are several tools that work together to monitor various aspects of your network, whether in Azure or on-
premises.
Network Watcher provides scenario-based monitoring and diagnostics for different network scenarios in Azure. It
stores data in Azure metrics and diagnostics for further analysis. It works with the following solutions for
monitoring various aspects of your network.
Network Performance Monitor (NPM) is a cloud-based network monitoring solution that monitors connectivity
across public clouds, datacenters, and on-premises environments.
ExpressRoute Monitor is an NPM capability that monitors the end-to-end connectivity and performance over
Azure ExpressRoute circuits.
DNS Analytics is a solution that provides security, performance, and operations-related insights, based on your
DNS servers.
Service Endpoint Monitor tests the reachability of applications and detects performance bottlenecks across on-
premises, carrier networks, and cloud/private data centers.
Service Map provides insight into your IaaS environment by analyzing virtual machines with their different
processes and dependencies on other computers and external processes. It integrates events, performance data,
and management solutions in Log Analytics. You can then view this data in the context of each computer and its
relation to the rest of your environment.
Service Map is similar to Application Map in Application Insights. It focuses on the infrastructure components that
support your applications.
Following are high-level examples that illustrate how you can use different monitoring tools in Azure for different
scenarios.
Consider a web application deployed in Azure through Azure App Service, Azure Storage, and a SQL database.
You start by accessing metrics and activity logs for these resources on their pages in the Azure portal. You look for
critical information, such as the number of requests to the application and average response time. You also
identify any configuration changes.
You then go to Monitor in the portal in order to view metrics and logs for the different resources together. As you
determine standard parameters for the metrics, you create alert rules. These rules proactively notify you when, for
example, average response time increases beyond a threshold. To get a quick view of your application's daily
performance, you create an Azure dashboard to show graphs of metrics that represent critical KPIs.
To perform deeper monitoring of your application, you configure it for Application Insights. You can now collect
additional data that provides further insight into the operation and performance of your application. Application
Insights detects the underlying relationships between your app’s components. It allows for visual
representation via Application Map coupled with end-to-end tracing to diagnose the exact component,
Monitoring virtual machinesMonitoring virtual machines
Next steps
dependency, or exception where a problem has occurred.
You create Availability tests to proactively test your application from different regions. To help your developers,
you enable the Profiler so you can track requests and any exceptions down to a specific line of code. To gain
further visibility into services used in your application, you add the SQL Analytics solution to collect additional
data in Log Analytics.
After some time, you decide to investigate the root cause for periods when performance on the site has fallen
below a threshold. You write a query by using Log Analytics. It helps you correlate the usage and performance
data collected by Application Insights with configuration and performance data across the Azure resources that
support your application.
You have a mix of Windows and Linux virtual machines running in Azure. You use Azure Monitor to view activity
logs and host-level metrics. You add the Azure Diagnostics extension to the virtual machines in order to collect
metrics from the guest operating system. You then create alert rules to proactively notify you when basic metrics
like processor utilization and memory cross thresholds.
To collect more details about virtual machines running a business application, you create a Log Analytics
workspace and enable the VM extension on each machine. You configure the collection of different data sources
for your application and create views to report on its daily operation and performance. You then create alert rules
to notify you when particular error events are received.
To continuously monitor the health of the installed agent, you add the Agent Health management solution. To
gain further insight into the application, you add the dependency agent to the virtual machines in order to add
them to Service Map. Service Map discovers critical processes and identifies connections between machines with
other services.
After a reportedoutage, you use Service Map to perform forensics to identify the particular machines that
experienced the problem. You then create a query on the Log Analytics data to identify the issue in the future. And
you create an alert rule to proactively notify you when the condition is detected.
Learn more about:
Azure Monitor to get started with core monitoring metrics and alerts.
Application Insights if you're trying to diagnose problems in your App Service web app.
Log Analytics for analyzing collected monitoring data and logs.
Receive a notification when a metric value meets a
condition
3/20/2018 • 3 min to read • Edit Online
Sign in to the Azure portal
Create a Logic App
Azure Monitor makes metrics available for many Azure resources. These metrics convey the performance and
health of those resources. In many cases metric values can point to something being wrong with a resource. You
can create metric alerts to monitor for abnormal behavior and be notified if it occurs. This Quickstart steps through
creating a Logic App, creating a job, and visualizing the metrics for the logic app. It then goes through creating an
alert, and receiving a notification for a metric for the Logic App resource.
For more information on metrics and metric alerts, see Azure Monitor metrics overview and Azure Monitor alerts
overview.
If you don't have an Azure subscription, create a free account before you begin.
Sign in to the Azure portal.
1. Click the Create a resource button found on the upper left-hand corner of the Azure portal.
2. Search for and select Logic App. Click the Create button.
3. Enter the name myLogicApp and the Resource Group myResourceGroup. Use your subscription. Use the
default location. Check the Pin to Dashboard option. When complete, click Create.
4. The logic app should be pinned to your dashboard. Navigate to the logic app by clicking on it.
5. In the Logic App panel, select the Logic App Designer
6. Set up you values as seen in the following diagram.
View metrics for your logic app
.
7. In the designer, select the Recurrence trigger.
8. Set an interval of 20 and a frequency of second to ensure your logic app is triggered every 20 seconds.
9. Click the New Step button, and select Add an action.
10. Choose the HTTP option, and select HTTP-HTTP.
11. Set the Method as POST and the Uri to a web address of your choice.
12. Click Save.
13. It may take up to 5 minutes for the logic app run actions to occur.
1. Click the Monitor option in the left-hand navigation pane.
2. Select the Metrics tab, fill in the Subscription, Resource Group, Resource Type and Resource
information for your logic app.
3. From the list of metrics, choose Runs Started.
4. Modify the Time range of the chart to display data for the past hour.
5. You should now see a chart plotting the total number of runs your logic app has started over the past hour.
If you do not see any, make sure you have waited at least 5 minutes from the step above. Then refresh your
browser.
Create a metric alert for your logic app
1. In the top right portion of the metrics panel click the Add metric alert button.
2. Name your metric alert 'myLogicAppAlert', and provide a brief description for the alert.
3. Set the Condition for the metric alert as 'Greater than', set the Threshold as '10', and set the Period as
'Over the last 5 minutes'.
4. Finally, under Additional administrator email(s) enter your email address. This alert ensures that you
receive an email in the event your logic app has more than 10 failed runs within a period of 5 minutes.
Receive metric alert notifications for your logic app
Clean up resources
1. Within a few moments, you should receive an email from 'Microsoft Azure Alerts' to inform you the alert has
been 'activated'.
2. Navigate back to your logic app and modify the recurrence trigger to an interval of 1 and frequency of hour.
3. Within a few minutes, you should receive an email from 'Microsoft Azure Alerts' informing you the alert has
been 'resolved'.
Other quick starts in this collection build upon this quickstart. If you plan to continue on to work with subsequent
quick starts or with the tutorials, do not clean up the resources created in this quickstart. If you do not plan to
continue, use the following steps to delete all resources created by this quickstart in the Azure portal.
Next steps
1. From the left-hand menu in the Azure portal, click on Monitor.
2. Select the Alerts tab, find the alert you created in this quickstart guide and click on it.
3. In the metric alert panel, click Delete.
4. From the left-hand menu in the Azure portal, search for Logic App and then click Logic apps.
5. On the panel, click the logic app you created in this quickstart in the text box, and then click Delete.
In this quickstart, you’ve learned how to create a metric alert for your resources. For more information on metric
alerts, click through to our overview on alerts.
Azure Monitor subscription action alerts
Audit and receive notifications about important
actions in your Azure subscription
3/20/2018 • 3 min to read • Edit Online
Log in to the Azure portal
Create a network security group
The Azure Activity Log provides a history of subscription-level events in Azure. It offers information about who
created, updated, or deleted what resources and when they did it. You can create an Activity Log alert to receive
email, SMS, or webhook notifications when an activity occurs that match your alert conditions. This Quickstart
steps through creating a simple network security group, browsing the Activity Log to understand the event that
occurred, and then authoring an Activity Log alert to become notified when any network security group is created
going forwards.
If you don't have an Azure subscription, create a free account before you begin.
Log in to the Azure portal.
1. Click the Create a resource button found on the upper left-hand corner of the Azure portal.
2. Select Networking, select Network security group.
3. Enter "myNetworkSG" as the Name and create a new resource group named myResourceGroup. Click the
Create button.
Browse the Activity Log in the portal
Browse an event in the Activity Log
An event has now been added to the Activity Log that describes the creation of the network security group. Use the
following instructions to identify that event.
1. Click the Monitor button found on the left-hand navigation list. It opens to the Activity Log section. This
section contains a history of all actions that users have performed on resources in your subscription,
filterable by several properties such as the Resource Group, Timespan, and Category.
2. In the Activity Log section, click the Resource Group dropdown and select myResourceGroup. Change
the Timespan dropdown to Last 1 hour. Click Apply.
3. Click on the Write NetworkSecurityGroups event in the table of events shown.
The section that appears contains basic details of the operation that was performed, including the name, the
timestamp, and the user or application that performed it.
Click on the JSON tab to view the full event details. This includes the details of how the user or application was
authorized to perform the operation, the event category and level, and the status of the operation.
Create an Activity Log alert
1. Click on the Summary tab to return to the event summary.
2. In the summary section that appears, click Add activity log alert.
3. In the section that appears, give the Activity Log alert a name and description.
4. Under Criteria ensure that Event category is set to Administrative, Resource type is set to Network
security groups, Operation name is set to Create or Update Network Security Group, Status is set to
Succeeded and all other criteria fields are eitherblank or set to All. The criteria define the rules used to
determine whether the alert should be activated when a new event appears in the Activity Log.
5. Under Alert via select New action group and provide a name and short name for the action group. The
action group defines the set of actions taken when the alert is activated (when the criteria match a new
event).
6. Under Actions add 1 or more actions by providing a Name for the action, the Action type (for example,
email, SMS, or webhook), and Details for that particular action type (for example, a webhook URL, email
address, or SMS number).
Test the Activity Log alert
NOTENOTE
Clean up resources
Next steps
7. Click Ok to save the Activity Log alert.
It takes approximately 5 minutes for an Activity Log alert to become fully enabled. New events that occur before the Activity
Log alert is fully enabled do not generate notifications.
To test the alert, repeat the preceding section to Create a network security group, but give this network security
group a different name and reuse the existing resource group. Within a few minutes, you will receive a notification
that the network security group was created.
When no longer needed, delete the resource group and network security group. To do so, type the name of the
resource group you created into the search box at the top of the portal, and click on the name of the resource
group. In the section that is displayed, click the Delete resource group button, type the name of the resource
group, and click Delete.
In this quick start, you performed an operation to generate an Activity Log event and then created an Activity Log
alert to become notified when this operation occurs again in the future. You then tested the alert by performing
that operation again. Azure makes available Activity Log events from the past 90 days. If you need to retain events
longer than 90 days, try archiving your Activity Log data alongside your other monitoring data.
Archive monitoring data
Create an Autoscale Setting for Azure resources
based on performance data or a schedule
2/16/2018 • 5 min to read • Edit Online
Log in to the Azure portal
Create a Web App and App Service Plan
Autoscale settings enable you to add/remove instances of service based on preset conditions. These settings can be
created through the portal. This method provides a browser-based user interface for creating and configuring an
autoscale setting.
In this tutorial, you will
Create a Web App and App Service Plan
Configure autoscale rules for scale-in and scale out based on the number of requests a Web App receives
Trigger a scale-out action and watch the number of instances increase
Trigger a scale-in action and watch the number of instances decrease
Clean up your resources
If you don't have an Azure subscription, create a free account before you begin.
Log in to the Azure portal.
1. Click the Create a resource option from the left-hand navigation pane.
2. Search for and select the Web App item and click Create.
3. Select an app name like MyTestScaleWebApp. Create a new resource group *myResourceGroup' and place it
into the resource group of your choosing.
Within a few minutes, your resources should be provisioned. Use the Web App and corresponding App Service Plan
in the remainder of this tutorial.
Navigate to Autoscale settings
1. From the left-hand navigation pane, select the Monitor option. Once the page loads, select the Autoscale tab.
2. A list of the resources under your subscription that support autoscale are listed here. Identify the App Service
Plan that was created earlier in the tutorial, and click on it.
3. On the autoscale setting, click the Enable Autoscale button.
The next few steps help you fill the autoscale screen to look like following picture:
Configure default profile
1. Provide a Name for the autoscale setting.
2. In the default profile, ensure the Scale mode is set to 'Scale to a specific instance count'.
3. Set the instance count to 1. This setting ensures that when no other profile is active, or in effect, the default
profile returns the instance count to 1.
Create recurrance profile
Create a scale-out rule
1. Click on the Add a scale condition link under the default profile.
2. Edit the Name of this profile to be 'Monday to Friday profile'.
3. Ensure the Scale mode is set to 'Scale based on a metric'.
4. For Instance limits set the Minimum as '1', the Maximum as '2' and the Default as '1'. This setting
ensures that this profile does not autoscale the service plan to have less than 1 instance, or more than 2
instances. If the profile does not have sufficient data to make a decision, it uses the default number of
instances (in this case 1).
5. For Schedule, select 'Repeat specific days'.
6. Set the profile to repeat Monday through Friday, from 09:00 PST to 18:00 PST. This setting ensures that this
profile is only active and applicable 9AM to 6PM, Monday through Friday. During all other times, the
'Default' profile is the profile the autoscale setting uses.
1. In the 'Monday to Friday profile'.
2. Click the Add a rule link.
3. Set the Metric source to be 'other resource'. Set the Resource type as 'App Services' and the Resource as
the Web App created earlier in this tutorial.
4. Set the Time aggregation as 'Total', the Metric name as 'Requests', and the Time grain statistic as 'Sum'.
5. Set the Operator as 'Greater than', the Threshold as '10' and the Duration as '5' minutes.
6. Select the Operation as 'Increase count by', the Instance count as '1', and the Cool down as '5' minutes.
7. Click the Add button.
This rule ensures that if your Web App receives more than 10 requests within 5 minutes or less, one additional
instance is added to your App Service Plan to manage load.
Create a scale-in rule
We recommended you always to have a scale-in rule to accompany a scale-out rule. Having both ensures that your
resources are not over provisioned. Over provisioning means you have more instances running than needed to
handle the current load.
1. In the 'Monday to Friday profile'.
2. Click the Add a rule link.
3. Set the Metric source to be 'other resource'. Set the Resource type as 'App Services' and the Resource as
the Web App created earlier in this tutorial.
4. Set the Time aggregation as 'Total', the Metric name as 'Requests', and the Time grain statistic as
'Average'.
5. Set the Operator as 'Less than', the Threshold as '5' and the Duration as '5' minutes.
6. Select the Operation as 'Decrease count by', the Instance count as '1', and the Cool down as '5' minutes.
7. Click the Add button.
8. Save the autoscale setting.
Trigger scale-out action
To trigger the scale-out condition in the autoscale setting just created, the Web App must have more than 10
requests in less than 5 minutes.
1. Open a browser window and navigate to the Web App created earlier in this tutorial. You can find the URL
for your Web App in the Azure Portal by navigating to your Web App resource and clicking on the Browse
button in the 'Overview' tab.
2. In quick succession, reload the page more than 10 times.
3. From the left-hand navigation pane, select the Monitor option. Once the page loads select the Autoscale
tab.
4. From the list, select the App Service Plan used throughout this tutorial.
5. On the autoscale setting, click the Run history tab.
6. You see a chart reflecting the instance count of the App Service Plan over time.
Trigger scale-in action
Clean up resources
Next steps
7. In a few minutes, the instance count should rise from 1, to 2.
8. Under the chart, you see the activity log entries for each scale action taken by this autoscale setting.
The scale-in condition in the autoscale setting triggers if there are fewer than 5 requests to the Web App over a
period of10 minutes.
1. Ensure no requests are being sent to your Web App.
2. Load the Azure Portal.
3. From the left-hand navigation pane, select the Monitor option. Once the page loads select the Autoscale
tab.
4. From the list, select the App Service Plan used throughout this tutorial.
5. On the autoscale setting, click the Run history tab.
6. You see a chart reflecting the instance count of the App Service Plan over time.
7. In a few minutes, the instance count should drop from 2, to 1. The process takes at least 100 minutes.
8. Under the chart, are the corresponding set of activity log entries for each scale action taken by this autoscale
setting.
1. From the left-hand menu in the Azure portal, click All resources and then select the Web App created in this
tutorial.
2. On your resource page, click Delete, confirm delete by typing yes in the text box, and then click Delete.
3. Then select the App Service Plan resource and click Delete.
4. Confirm delete by typing yes in the text box, and then click Delete.
In this tutorial, you
Created a Web App and App Service Plan
Configured autoscale rules for scale-in and scale out based on the number of requests the Web App received
Triggered a scale-out action and watched the number of instances increase
Triggered a scale-in action and watched the number of instances decrease
Cleaned up your resources
To learn more about autoscale settings, continue on to the autoscale overview.
Archive your monitoring data
Archive Azure monitoring data
4/6/2018 • 7 min to read • Edit Online
Sign in to the Azure portal
Create a storage account
Route subscription logs to the storage account
Several layers of your Azure environment produce log and metric data that can be archived to an Azure Storage
Account. You may want to do this to preserve a history of monitoring data over time in an inexpensive, non-
searchable store after that data has passed its retention period in Log Analytics or Azure Monitor. This tutorial
steps through the process of configuring your Azure environment to archive data to a storage account.
Create a storage account to hold monitoring data
Route subscription logs to it
Route resource data to it
Route virtual machine (guest OS) data to it
View the monitoring data in it
Clean up your resources
If you don't have an Azure subscription, create a free account before you begin.
Sign in to the Azure portal.
First you need to set up a storage account to which the monitoring data will be archived. To do this, follow the
steps here.
You are now ready to begin to set up your Azure environment to route monitoring data to a storage account. First
we configure subscription-level data (contained in the Azure Activity Log) to be routed to the storage account. The
Azure Activity Log provides a history of subscription-level events in Azure. You can browse it in the Azure portal
to determine who created, updated, or deleted what resources and when they did it.
1. Click the Monitor button found on the left-hand navigation list, then on Activity Log.
2. In the Activity Log section that is displayed, click on the Export button.
3. In the Export activity log section that appears, check the box for Export to a storage account and click
Select a storage account.
4. In the section that appears, use the Storage account dropdown to select the name of the storage account
you created in the preceding Create a storage account step, then click OK.
Route resource data to the storage account
5. Set the Retention (days) slider to 30. This slider sets a number of days to retain the monitoring data in the
storage account. Azure Monitor automatically deletes data older than the number of days specified. A
retention of zero days stores the data indefinitely.
6. Click Save and close this section.
Monitoring data from your subscription is now flowing into the storage account.
Now we configure resource-level data (resource metrics and diagnostic logs) to be routed to the storage account
by setting up resource diagnostic settings.
1. Click the Monitor button found on the left-hand navigation list, then on Diagnostic Settings. Here you see
a list of all resources in your subscription that produce monitoring data through Azure Monitor. If you do
not have any resources in this list, you can create a logic app before proceeding so that you have a resource
that you can configure a diagnostic setting on.
2. Click on a resource in the list, and then click Turn on diagnostics.
If there is already a setting configured, you instead see the existing settings, and a button to Add
diagnostic setting. Click this button.
A resource diagnostic setting is a definition of what monitoring data should be routed from a particular
resource and where that monitoring data should go.
3. In the section that appears, give your setting a name and check the box for Archive to a storage account.
4. Click on the Configure button under Archive to a storage account and select the storage account you
created in the preceding section. Click OK.
5. Check all the boxes under Log and Metric. Depending on the resource type, you may only have one of
these options. These checkboxes control what categories of log and metric data available for that resource
type are sent to the destination you've selected, in this case, a storage account.
NOTENOTE
Route virtual machine (guest OS) data to the storage account
6. Set the Retention (days) slider to 30. This slider sets a number of days to retain the monitoring data in the
storage account. Azure Monitor automatically deletes data older than the number of days specified. A
retention of zero days stores the data indefinitely.
7. Click Save.
Monitoring data from your resource is now flowing into the storage account.
Sending multi-dimensional metrics via diagnostic settings is not currently supported. Metrics with dimensions are exported
as flattened single dimensional metrics, aggregated across dimension values.
For example: The 'Incoming Messages' metric on an Event Hub can be explored and charted on a per queue level. However,
when exported via diagnostic settings the metric will be represented as all incoming messages across all queues in the Event
Hub.
1. If you do not already have a virtual machine in your subscription, create a virtual machine.
2. In the left-hand navigation list in the portal, click on Virtual Machines.
3. In the list of virtual machines that is displayed, click on the virtual machine you created.
4. In the section that appears, click on Diagnostic Settings on the left-hand navigation. This section enables
you to set up the out-of-box monitoring extension from Azure Monitor on your virtual machine and route
data being produced by Windows or Linux to a storage account.
5. Click Enable guest-level monitoring in the section that appears.
6. Once the diagnostic setting has correctly saved, the Overview tab shows a list of the data being collected
and where it is being stored. Click on the Performance counters section to review the set of Windows
performance counters being collected.
7. Click on the Logs tab and check the checkboxes for Information level logs on Application and System logs.
View the monitoring data in the storage account
8. Click on the Agent tab and under Storage account click on the name of the storage account shown.
9. In the section that appears, pick the storage account you created in the preceding Create a storage
account step.
10. Click Save.
Monitoring data from your virtual machines is now flowing into the storage account.
If you have followed the preceding steps, data has begun flowing to your storage account.
1. For some data types, for example, the Activity Log, there needs to be some activity that generates an event
in the storage account. To generate activity in the ActivityLog, follow these instructions. You may need to
wait up to five minutes before the event appears in the storage account.
2. In the portal, navigate to the Storage Accounts section by finding it on the left-hand navigation bar.
3. Identify the storage account you created in the preceding section and click on it.
Clean up resources
Next steps
4. Click on Blobs, then on the container labeled insights-operational-logs and finally on the container
labeled name=default. This is the container that has your Activity Log in it. Monitoring data is broken out
into containers by resource ID (just the subscription ID for the Activity Log), then by date and time. The full
format for these blobs is:
insights-operational-logs/name=default/resourceId=/SUBSCRIPTIONS/{subscription ID}/y={four-digit
numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock
hour}/m=00/PT1H.json
5. Navigate to the PT1H.json file by clicking into the containers for resource ID, date, and time. Click on the
PT1H.json file and click Download. Each PT1H.json blob contains a JSON blob of events that occurred
within the hour specified in the blob URL (for example, h=12). During the present hour, events are
appended to the PT1H.json file as they occur. The minute value (m=00) is always 00, since log events are
broken into individual blobs per hour.
You can now view the JSON event that was stored in the storage account. For resource diagnostic logs, the
format for the blobs is:
insights-logs-{log category name}/resourceId=/{resource ID}/y={four-digit numeric year}/m={two-digit
numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
6. Guest OS monitoring data is stored in tables. navigate back to the storage account home, and click Tables.
There are tables for metrics, performance counters, and event logs.
You have now successfully set up monitoring data to be archived to a storage account.
1. Navigate back to the Export Activity Log section from the preceding Route subscription logs to the
storage account step, and click Reset.
2. Navigate to the Diagnostic Settings section, click the resource on which you created a diagnostic setting in
the preceding Route resource data to the storage account step, then find the setting you created, click
the Edit setting button and click Delete.
3. Navigate to the Diagnostic Settings section on the virtual machine you configured in the preceding Route
virtual machine (guest OS) data to the storage account step, and under the Agent tab click Remove
(beneath the Remove Azure Diagnostics agent section).
4. Navigate to the storage account you created in the preceding Create a storage account step and click
Delete storage account. Type the name of the storage account, and then click Delete.
5. If you created a virtual machine or Logic App for the preceding steps, delete those as well.
In this tutorial, you learned how to set up monitoring data from your Azure environment (subscription, resource,
and guest OS) to be archived to a storage account.
Create a storage account to hold monitoring data
Route subscription logs to it
Route resource data to it
Route virtual machine (guest OS) data to it
View the monitoring data in it
Clean up your resources
To get more out of your data and derive additional insights, also send your data into Log Analytics.
Get started with Log Analytics
Consume monitoring data from Azure
4/6/2018 • 1 min to read • Edit Online
Options for data consumption
DATA TYPE CATEGORY SUPPORTED SERVICES METHODS OF ACCESS
Azure Monitor platform-
level metrics
Metrics See list here
Compute guest OS metrics
(eg. perf counters)
Metrics Windows and Linux Virtual
Machines (v2), Cloud
Services, Service Fabric
Custom or application
metrics
Metrics Any application
instrumented with
Application Insights
Storage metrics Metrics Azure Storage
Billing data Metrics All Azure services
Activity Log Events All Azure services
Azure Monitor Diagnostic
Logs
Events See list here
Across the Azure platform, we are bringing together monitoring data in a single place with the Azure Monitor
pipeline, but practically acknowledge that today not all monitoring data is available in that pipeline yet. In this
article, we will summarize the various ways you can programmatically access monitoring data from Azure services.
REST API: Azure
Monitor Metric API
Storage blob or
event hub:
Diagnostic Settings
Storage table or
blob: Windows or
Linux Azure
diagnostics
Event hub: Windows
Azure diagnostics
REST API:
Application Insights
REST API
Storage table:
Storage Analytics
REST API: Azure
Resource Usage and
RateCard APIs
REST API: Azure
Monitor Events API
Storage blob or
event hub: Log
Profile
Storage blob or
event hub:
Diagnostic Settings
Compute guest OS logs (eg.
IIS, ETW, syslogs)
Events Windows and Linux Virtual
Machines (v2), Cloud
Services, Service Fabric
App Service logs Events App services
Storage logs Events Azure Storage
Security Center alerts Events Azure Security Center
Active Directory reporting Events Azure Active Directory
Security Center resource
status
Status All supported resources
Resource Health Status Supported services
Azure Monitor metric alerts Notifications See list here
Azure Monitor Activity Log
alerts
Notifications All Azure services
Autoscale notifications Notifications See list here
Log Search Query alerts Notifications Log Analytics
Application Insights metric
alerts
Notifications Application Insights
DATA TYPE CATEGORY SUPPORTED SERVICES METHODS OF ACCESS
Storage table or
blob: Windows or
Linux Azure
diagnostics
Event hub: Windows
Azure diagnostics
File, table, or blob
storage: Web app
diagnostics
Storage table:
Storage Analytics
REST API: Security
Alerts
REST API: Azure
Active Directory
graph API
REST API: Security
Statuses
REST API: Resource
health REST API
Webhook: Azure
metric alerts
Webhook: Azure
Activity Log alerts
Webhook: Autoscale
notification webhook
payload schema
Webhook: Log
Analytics alerts
Webhook:
Application Insights
alerts
Application Insights web
tests
Notifications Application Insights
DATA TYPE CATEGORY SUPPORTED SERVICES METHODS OF ACCESS
Next steps
Webhook:
Application Insights
alerts
Learn more about Azure Monitor metrics
Learn more about the Azure Activity Log
Learn more about Azure Diagnostic Logs
Overview of Azure Monitor
4/6/2018 • 6 min to read • Edit Online
Azure Monitor and Microsoft's other monitoring products
Portal overview page
This article provides an overview of the Azure Monitor service in Microsoft Azure. It discusses what Azure Monitor
does and provides pointers to additional information on how to use Azure Monitor. If you prefer a video
introduction, see Next steps links at the bottom of this article.
Azure Monitor provides base-level infrastructure metrics and logs for most services in Microsoft Azure. Azure
services that do not yet put their data into Azure Monitor will put it there in the future.
Microsoft ships additional products and services that provide additional monitoring capabilities for developers,
DevOps, or IT Ops that also have on-premises installations. For an overview and understanding of how these
different products and services work together, see Monitoring in Microsoft Azure.
Azure Monitor has a landing page that helps users:
Understand the monitoring capabilities offered by Azure.
Discover, configure, and on-board Azure’s platform and premium monitoring capabilities.
The page is a starting point for navigation, including on-boarding. It shows curated notable issues from different
services and allows the user to navigate to them in context.
When youopen the page, you can select among the subscriptions you have read access to. For a selected
subscription, you can see:
Triggered alerts and alert sources - This table shows summary counts, alert sources, and how many times
alerts fired for the selected time duration. It applies to both older and newer alerts. Read more about the newer
Azure Alerts.
Activity Log Errors - If any of your Azure resources log events with error-level severity, you can view a high-
level count and click through to the activity log page to investigate each event.
Azure Service Health - You can see a count of Service Health service issues, planned maintenance events, and
health advisories. Azure Service Health provides personalized information when problems in the Azure
infrastructure impact your services. See Azure Service Health for more information.
Application Insights - See KPIs for each AppInsights resource in the current subscription. The KPIs are
Azure Monitor Sources - Compute subset
Application - Diagnostics Logs, Application Logs, and MetricsApplication - Diagnostics Logs, Application Logs, and Metrics
Host and Guest VM metricsHost and Guest VM metrics
optimized for server-side application monitoring across ASP.NET web apps, Java, Node, and General application
types. The KPIs include metrics for request rate, response duration, failure rate, and availability %.
If you have not on-boarded to Log Analytics or Application Insights, or if you have not configured any Azure Alerts
in the current subscription, the page provides links to begin your on-boarding process.
The Compute services here include
Cloud Services
Virtual Machines
Virtual Machine scale sets
Service Fabric
Applications can run on top of the Guest OS in the compute model. They emit their own set of logs and metrics.
Azure Monitor relies on the Azure diagnostics extension (Windows or Linux) to collect most application level
metrics and logs. The types include
Performance counters
Application Logs
Windows Event Logs
.NET Event Source
IIS Logs
Manifest based ETW
Crash Dumps
Customer Error Logs
Without the diagnostics extension, only a few metrics like CPU usage are available.
The previously listed compute resources have a dedicated host VM and guest OS they interact with. The host VM
Activity LogActivity Log
Azure Monitor Sources - everything else
Resource - Metrics and Diagnostics LogsResource - Metrics and Diagnostics Logs
Host and Guest VM metricsHost and Guest VM metrics
Activity LogActivity Log
Uses for Monitoring Data
RouteRoute
and guest OS are the equivalent of root VM and guest VM in the Hyper-V hypervisor model. You can collect
metrics on both. You can also collect diagnostics logs on the guest OS.
You can search the Activity Log (previously called Operational or Audit Logs) for information about your resource
as seen by the Azure infrastructure. The log contains information such as times when resources are created or
destroyed. For more information, see Overview of Activity Log.
Collectable metrics and diagnostics logs vary based on the resource type. For example, Web Apps provides
statistics on the Disk IO and Percent CPU. Those metrics don't exist for a Service Bus queue, which instead provides
metrics like queue size and message throughput. A list of collectable metrics for each resource is available at
supported metrics.
There is not necessarily a 1:1 mapping between your resource and a particular Host or Guest VM so metrics are not
available.
The activity log is the same as for compute resources.
Once you collect your data, you can do the following with it in Azure Monitor.
You can stream monitoring data to other locations.
Examples include:
Send to Application Insights so you can use its richer visualization and analysis tools.
Send to Event Hubs so you can route to third-party tools.
Store and ArchiveStore and Archive
QueryQuery
VisualizeVisualize
AutomateAutomate
NOTENOTE
Methods of accessing Azure Monitor
Some monitoring data is already stored and available in Azure Monitor for a set amount of time.
Metrics are stored for 30 days.
Activity log entries are stored for 90 days.
Diagnostics logs are not stored at all.
If you want to store data longer than the time periods listed above, you can use an Azure storage. Monitoring data
is kept in your storage account based on a retention policy you set. You do have to pay for the space the data takes
up in Azure storage.
A few ways to use this data:
Once written, you can have other tools within or outside of Azure read it and process it.
You download the data locally for a local archive or change your retention policy in the cloud to keep data for
extended periods of time.
You leave the data in Azure storage indefinitely for archive purposes.
You can use the Azure Monitor REST API, cross platform Command-Line Interface (CLI) commands, PowerShell
cmdlets, or the .NET SDK to access the data in the system or Azure storage
Examples include:
Getting data for a custom monitoring application you have written
Creating custom queries and sending that data to a third-party application.
Visualizing your monitoring data in graphics and charts helps you find trends quicker than looking through the
data itself.
A few visualization methods include:
Use the Azure portal
Route data to Azure Application Insights
Route data to Microsoft PowerBI
Route the data to a third-party visualization tool using either live streaming or by having the tool read from an
archive in Azure storage
As part of the ongoing evolution of alerts on Microsoft Azure, now a unified experience for alerting is available. More details
on new Azure alerts
In the Azure alerts, you can use monitoring data to trigger alerts or even whole processes. Examples include:
Use data to autoscale compute instances up or down based on application load.
Send emails based on metric or log conditions.
Call a web URL (webhook) to execute an action in a system outside of Azure
Start a runbook in Azure automation to perform any variety of tasks
Next steps
In general, you can manipulate data tracking, routing, and retrieval using one of the following methods. Not all
methods are available for all actions or data types.
Azure portal
PowerShell
Cross-platform Command Line Interface (CLI)
REST API
.NET SDK
Learn more about
A video walkthrough of just Azure Monitor is available at
Get Started with Azure Monitor.
A video explaining a scenario where you can use Azure Monitor is available at Explore Microsoft Azure
monitoring and diagnostics and Azure Monitor in a video from Ignite 2016.
Run through the Azure Monitor interface in Getting Started with Azure Monitor
Set up the Azure Diagnostics Extensions if you are attempting to diagnose problems in your Cloud Service,
Virtual Machine, Virtual machine scale sets, or Service Fabric application.
Application Insights if you are trying to diagnostic problems in your App Service Web app.
Troubleshooting Azure Storage when using Storage Blobs, Tables, or Queues
Log Analytics and the Operations Management Suite
Overview of metrics in Microsoft Azure
4/6/2018 • 6 min to read • Edit Online
What are metrics?
What can you do with metrics?
What are the characteristics of metrics?
This article describes what metrics are in Microsoft Azure, their benefits, and how to start using them.
Azure Monitor enables you to consume telemetry to gain visibility into the performance and health of your
workloads on Azure. The most important type of Azure telemetry data is the metrics (also called performance
counters) emitted by most Azure resources. Azure Monitor provides several ways to configure and consume
these metrics for monitoring and troubleshooting.
Metrics are a valuable source of telemetry and enable you to do the following tasks:
Track theperformance of your resource (such as a VM, website, or logic app) by plotting its metrics on a
portal chart and pinning that chart to a dashboard.
Get notified of an issue that impacts the performance of your resource when a metric crosses a certain
threshold.
Configure automated actions, such as autoscaling a resource or firing a runbook when a metric crosses a
certain threshold.
Perform advanced analytics or reporting on performance or usage trends of your resource.
Archive the performance or health history of your resource for compliance or auditing purposes.
Metrics have the following characteristics:
All metrics have one-minute frequency (unless specified otherwise in a metric's definition). You receive a
metric value every minute from your resource, giving you near real-time visibility into the state and health of
your resource.
Metrics are available immediately. You don't need to opt in or set up additional diagnostics.
You can access 93 days of history for each metric. You can quickly look at the recent and monthly trends in
the performance or health of your resource.
Some metrics can have name-value pair attributes called dimensions. These enable you to further segment
and explore a metric in a more meaningful way.
You can also:
Configure a metric alert rule that sends a notification or takes automated action when the metric
crosses the threshold that you have set. Autoscale is a special automated action that enables you to scale
out your resource to meet incoming requests or loads on your website or computing resources. You can
configure an Autoscale setting rule to scale in or out based on a metric crossing a threshold.
Route all metrics Application Insights or Log Analytics to enable instant analytics, search, and custom
alerting on metrics data from your resources. You can also stream metrics to an Event Hub, enabling you
to then route them to Azure Stream Analytics or to custom apps for near-real time analysis. You set up
Event Hub streaming using diagnostic settings.
Archive metrics to storage for longer retention or use them for offline reporting. You can route your
Access metrics via the portal
To view metrics after creating a resourceTo view metrics after creating a resource
metrics to Azure Blob storage when you configure diagnostic settings for your resource.
Easily discover, access, and view all metrics via the Azure portal when you select a resource and plot the
metrics on a chart.
Consume the metrics via the new Azure Monitor REST APIs.
Query metrics by using the PowerShell cmdlets or the Cross-Platform REST API.
Following is a quick walkthrough of how to create a metric chart by using the Azure portal.
1. Open the Azure portal.
2. Create an Azure App Service website.
3. After you create a website, go to the Overview blade of the website.
4. You can view new metrics as a Monitoring tile. You can then edit the tile and select more metrics.
To access all metrics in a single placeTo access all metrics in a single place
1. Open the Azure portal.
2. Navigate to the new Monitor tab, and then and select the Metrics option underneath it.
3. Select your subscription, resource group, and the name of the resource from the drop-down list.
4. View the available metrics list. Then select the metric you are interested in and plot it.
5. You can pin it to the dashboard by clicking the pin on the upper-right corner.
NOTENOTE
Access metrics via the REST API
NOTENOTE
Export metrics
You can access host-level metrics from VMs (Azure Resource Manager-based) and virtual machine scale sets without any
additional diagnostic setup. These new host-level metrics are available for Windows and Linux instances. These metrics are
not to be confused with the Guest-OS-level metrics that you have access to when you turn on Azure Diagnostics on your
VMs or virtual machine scale sets. To learn more about configuring Diagnostics, see What is Microsoft Azure Diagnostics.
Azure Monitor also has a new metrics charting experience available in preview. This experience enables users to
overlay metrics from multiple resources on one chart. Users can also plot, segment, and filter multi-dimensional
metrics using this new metric charting experience. To learn more click here
Azure Metrics can be accessed via the Azure Monitor APIs. There are two APIs that help you discover and access
metrics:
Use the Azure Monitor Metric definitions REST API to access the list of metrics, and any dimensions, that are
available for a service.
Use the Azure Monitor Metrics REST API to segment, filter, and access the actual metrics data.
This article covers the metrics via the new API for metrics for Azure resources. The API version for the new metric
definitions and metrics APIs is 2018-01-01. The legacy metric definitions and metrics can be accessed with the API version
2014-04-01.
For a more detailed walkthrough using the Azure Monitor REST APIs, see Azure Monitor REST API walkthrough.
You can go to the Diagnostics settings blade under the Monitor tab and view the export options for metrics.
You can select metrics (and diagnostic logs) to be routed to Blob storage, to Azure Event Hubs, or to Log
Analytics for use-cases that were mentioned previously in this article.
NOTENOTE
Take action on metrics
Configure alert rulesConfigure alert rules
You can configure this via Resource Manager templates, PowerShell, Azure CLI, or REST APIs.
Sending multi-dimensional metrics via diagnostic settings is not currently supported. Metrics with dimensions are exported
as flattened single dimensional metrics, aggregated across dimension values.
For example: The 'Incoming Messages' metric on an Event Hub can be explored and charted on a per queue level.
However, when exported via diagnostic settings the metric will be represented as all incoming messages across all queues
in the Event Hub.
To receive notifications or take automated actions on metric data, you can configure alert rules or Autoscale
settings.
You can configure alert rules on metrics. These alert rules can check if a metric has crossed a certain threshold.
There are two metric alerting capabilities offered by Azure Monitor.
Metric alerts: They can then notify you via email or fire a webhook that can be used to run any custom script. You
can also use the webhook to configure third-party product integrations.
Autoscale your Azure resourcesAutoscale your Azure resources
Newer metric alerts have the ability to monitor multiple metrics, and thresholds, for a resource and then notify
you via an Action Group. Learn more about newer alerts here.
Some Azure resources support the scaling out or in of multiple instances to handle your workloads. Autoscale
applies to App Service (Web Apps), virtual machine scale sets, and classic Azure Cloud Services. You can
configure Autoscale rules to scale out or in when a certain metric that impacts your workload crosses a threshold
that you specify. For more information, see Overview of autoscaling.
Learn about supported services and metrics
Next steps
You can view a detailed list of all the supported services and their metrics at Azure Monitor metrics--supported
metrics per resource type.
Refer to the links throughout this article. Additionally, learn about:
Common metrics for autoscaling
How to create alert rules
Analyze logs from Azure storage with Log Analytics
Overview of autoscale in Microsoft Azure Virtual
Machines, Cloud Services, and Web Apps
11/16/2017 • 4 min to read • Edit Online
NOTENOTE
What is autoscale?
This article describes what Microsoft Azure autoscale is, its benefits, and how to get started using it.
Azure Monitor autoscale applies only to Virtual Machine Scale Sets, Cloud Services, and App Service - Web Apps.
Azure has two autoscale methods. An older version of autoscale applies to VirtualMachines (availability sets). This feature
has limited support and we recommend migrating to virtual machine scale sets for faster and more reliable autoscale
support. A link on how to use the older technology is included in this article.
Autoscale allows you to have the right amount of resources running to handle the load on your application. It
allows you to add resources to handle increases in load and also save money by removing resources that are
sitting idle. You specify a minimum and maximum number of instances to run and add or remove VMs
automatically based on a set of rules. Having a minimum makes sure your application is always running even
under no load. Having a maximum limits your total possible hourly cost. You automatically scale between these
two extremes using rules you create.
When rule conditions are met, one or more autoscale actions are triggered. You can add and remove VMs, or
perform other actions. The following conceptual diagram shows this process.
Resource Metrics
Custom Metrics
Time
The following explanation applies to the pieces of the previous diagram.
Resources emit metrics, these metrics are later processed by rules. Metrics come via different methods. Virtual
machine scale sets use telemetry data from Azure diagnostics agents whereas telemetry for Web apps and Cloud
services comes directly from the Azure Infrastructure. Some commonly used statistics include CPU Usage, memory
usage, thread counts, queue length, and disk usage. For a list of what telemetry data you can use, see Autoscale
Common Metrics.
You can also leverage your own custom metrics that your application(s) may be emitting. If you have configured
your application(s) to send metrics to Application Insights you can leverage those metrics to make decisions on
whether to scale or not.
Schedule-based rules are based on UTC. You must set your time zone properly when setting up your rules.
Rules
Actions and automation
Autoscale Settings
The diagram shows only one autoscale rule, but you can have many of them. You can create complex overlapping
rules as needed for your situation. Rule types include
Metric-based - For example, do this action when CPU usage is above 50%.
Time-based - For example, trigger a webhook every 8am on Saturday in a given time zone.
Metric-based rules measure application load and add or remove VMs based on that load. Schedule-based rules
allow you to scale when you see time patterns in your load and want to scale before a possible load increase or
decrease occurs.
Rules can trigger one or more types of actions.
Scale - Scale VMs in or out
Email - Send email to subscription admins, co-admins, and/or additional email address you specify
Automate via webhooks - Call webhooks, which can trigger multiple complex actions inside or outside Azure.
Inside Azure, you can start an Azure Automation runbook, Azure Function, or Azure Logic App. Example third-
party URL outside Azure include services like Slack and Twilio.
Autoscale use the following terminology and structure.
An autoscale setting is read by the autoscale engine to determine whether to scale up or down. It contains
one or more profiles, information about the target resource, and notification settings.
An autoscale profile is a combination of a:
capacity setting, which indicates the minimum, maximum, and default values for number of
instances.
set of rules, each of which includes a trigger (time or metric) and a scale action (up or down).
recurrence, which indicates when autoscale should put this profile into effect.
You can have multiple profiles, which allow you to take care of different overlapping
requirements. You can have different autoscale profiles for different times of day or days of
the week, for example.
A notification setting defines what notifications should occur when an autoscale event occurs
based on satisfying the criteria of one of the autoscale setting’s profiles. Autoscale can notify one
or more email addresses or make calls to one or more webhooks.
Horizontal vs vertical scaling
The full list of configurable fields and descriptions is available in the Autoscale REST API.
For code examples, see
Advanced Autoscale configuration using Resource Manager templates for VM Scale Sets
Autoscale REST API
Autoscale only scales horizontally, which is an increase ("out") or decrease ("in") in the number of VM instances.
Horizontal is more flexible in a cloud situation as it allows you to run potentially thousands of VMs to handle load.
In contrast, vertical scaling is different. It keeps the same number of VMs, but makes the VMs more ("up") or less
("down") powerful. Power is measured in memory, CPU speed, disk space, etc. Vertical scaling has more
limitations. It's dependent on the availability of larger hardware, which quickly hits an upper limit and can vary by
region. Vertical scaling also usually requires a VM to stop and restart.
 
Methods of access
Supported services for autoscale
SERVICE SCHEMA & DOCS
Web Apps Scaling Web Apps
Cloud Services Autoscale a Cloud Service
Virtual Machines: Classic Scaling Classic Virtual Machine Availability Sets
Virtual Machines: Windows Scale Sets Scaling virtual machine scale sets in Windows
Virtual Machines: Linux Scale Sets Scaling virtual machine scale sets in Linux
Virtual Machines: Windows Example Advanced Autoscale configuration using Resource Manager
templates for VM Scale Sets
Next steps
For more information, see Vertically scale Azure virtual machine with Azure Automation.
You can set up autoscale via
Azure portal
PowerShell
Cross-platform Command Line Interface (CLI)
Azure Monitor REST API
To learn more about autoscale, use the Autoscale Walkthroughs listed previously or refer to the following
resources:
Azure Monitor autoscale common metrics
Best practices for Azure Monitor autoscale
Use autoscale actions to send email and webhook alert notifications
Autoscale REST API
Troubleshooting Virtual Machine Scale Sets Autoscale
Collect and consume log data from your Azure
resources
4/6/2018 • 7 min to read • Edit Online
What are Azure resource diagnostic logs
What you can do with resource-level diagnostic logs
Azure resource-level diagnostic logs are logs emitted by a resource that provide rich, frequent data about the
operation of that resource. The content of these logs varies by resource type. For example, Network Security
Group rule counters and Key Vault audits are two categories of resource logs.
Resource-level diagnostic logs differ from the Activity Log. The Activity Log provides insight into the operations
that were performed on resources in your subscription using Resource Manager, for example, creating a virtual
machine or deleting a logic app. The Activity Log is a subscription-level log. Resource-level diagnostic logs
provide insight into operations that were performed within that resource itself, for example, getting a secret
from a Key Vault.
Resource-level diagnostic logs also differ from guest OS-level diagnostic logs. Guest OS diagnostic logs are
those collected by an agent running inside of a virtual machine or other supported resource type. Resource-level
diagnostic logs require no agent and capture resource-specific data from the Azure platform itself, while guest
OS-level diagnostic logs capture data from the operating system and applications running on a virtual machine.
Not all resources support the new type of resource diagnostic logs described here. This article contains a section
listing which resource types support the new resource-level diagnostic logs.
Here are some of the things you can do with resource diagnostic logs:
 Resource diagnostic settings
Save them to a Storage Account for auditing or manual inspection. You can specify the retention time (in
days) usingresource diagnostic settings.
Stream them to Event Hubs for ingestion by a third-party service or custom analytics solution such as
PowerBI.
Analyze them with Log Analytics
You can use a storage account or Event Hubs namespace that is not in the same subscription as the one emitting
logs. The user who configures the setting must have the appropriate RBAC access to both subscriptions.
Resource diagnostic logs for non-Compute resources are configured using resource diagnostic settings.
Resource diagnostic settings for a resource control:
Where resource diagnostic logs and metrics are sent (Storage Account, Event Hubs, and/or Log Analytics).
Which log categories are sent and whether metric data is also sent.
How long each log category should be retained in a storage account
A retention of zero days means logs are kept forever. Otherwise, the value can be any number of days
between 1 and 2147483647.
If retention policies are set but storing logs in a Storage Account is disabled (for example, if only Event
Hubs or Log Analytics options are selected), the retention policies have no effect.
Retention policies are applied per-day, so at the end of a day (UTC), logs from the day that is now
beyond the retention policy are deleted. For example, if you had a retention policy of one day, at the
NOTENOTE
WARNINGWARNING
How to enable collection of resource diagnostic logs
TIPTIP
Enable collection of resource diagnostic logs in the portalEnable collection of resource diagnostic logs in the portal
beginning of the day today the logs from the day before yesterday would be deleted.
These settings are easily configured via the diagnostic settings for a resource in the Azure portal, via Azure
PowerShell and CLI commands, or via the Azure Monitor REST API.
Sending multi-dimensional metrics via diagnostic settings is not currently supported. Metrics with dimensions are
exported as flattened single dimensional metrics, aggregated across dimension values.
For example: The 'Incoming Messages' metric on an Event Hub can be explored and charted on a per queue level.
However, when exported via diagnostic settings the metric will be represented as all incoming messages across all queues
in the Event Hub.
Diagnostic logs and metrics for from the guest OS layer of Compute resources (for example, VMs or Service Fabric) use a
separate mechanism for configuration and selection of outputs.
Collection of resource diagnostic logs can be enabled as part of creating a resource in a Resource Manager
template or after a resource is created from that resource's page in the portal. You can also enable collection at
any point using Azure PowerShell or CLI commands, or using the Azure Monitor REST API.
These instructions may not apply directly to every resource. See the schema links at the bottom of this page to
understand special steps that may apply to certain resource types.
You can enable collection of resource diagnostic logs in the Azure portal after a resource has been created either
by going to a specific resource or by navigating to Azure Monitor. To enable this via Azure Monitor:
1. In the Azure portal, navigate to Azure Monitor and click on Diagnostic Settings
2. Optionally filter the list by resource group or resource type, then click on the resource for which you
would like to set a diagnostic setting.
3. If no settings exist on the resource you have selected, you are prompted to create a setting. Click "Turn on
diagnostics."
If there are existing settings on the resource, you will see a list of settings already configured on this
resource. Click "Add diagnostic setting."
4. Give your setting a name, check the boxes for each destination to which you would like to send data, and
configure which resource is used for each destination. Optionally, set a number of days to retain these
logs by using the Retention (days) sliders (only applicable to the storage account destination). A
retention of zero days stores the logs indefinitely.
Enable collection of resource diagnostic logs via PowerShellEnable collection of resource diagnostic logs via PowerShell
Set-AzureRmDiagnosticSetting -ResourceId [your resource id] -StorageAccountId [your storage account id] -
Enabled $true
Set-AzureRmDiagnosticSetting -ResourceId [your resource id] -ServiceBusRuleId [your Service Bus rule id] -
Enabled $true
Set-AzureRmDiagnosticSetting -ResourceId [your resource id] -WorkspaceId [resource id of the log analytics 
workspace] -Enabled $true
5. Click Save.
After a few moments, the new setting appears in your list of settings for this resource, and diagnostic logs are
sent to the specified destinations as soon as new event data is generated.
To enable collection of resource diagnostic logs via Azure PowerShell, use the following commands:
To enable storage of diagnostic logs in a storage account, use this command:
The storage account ID is the resource ID for the storage account to which you want to send the logs.
To enable streaming of diagnostic logs to an event hub, use this command:
The service bus rule ID is a string with this format: {Service Bus resource ID}/authorizationrules/{key name} .
To enable sending of diagnostic logs to a Log Analytics workspace, use this command:
You can obtain the resource ID of your Log Analytics workspace using the following command:
(Get-AzureRmOperationalInsightsWorkspace).ResourceId
Enable collection of resource diagnostic logs via Azure CLI 2.0Enable collection of resource diagnostic logs via Azure CLI 2.0
az monitor diagnostic-settings create --name <diagnostic name> \
 --storage-account <name or ID of storage account> \
 --resource <target resource object ID> \
 --resource-group <storage account resource group> \
 --logs '[
 {
 "category": <category name>,
 "enabled": true,
 "retentionPolicy": {
 "days": <# days to retain>,
 "enabled": true
 }
 }]'
az monitor diagnostic-settings create --name <diagnostic name> \
 --event-hub <event hub name> \
 --event-hub-rule <event hub rule ID> \
 --resource <target resource object ID> \
 --logs '[
 {
 "category": <category name>,
 "enabled": true
 }
 ]'
az monitor diagnostic-settings create --name <diagnostic name> \
 --workspace <log analytics name or object ID> \
 --resource <target resource object ID> \
 --resource-group <log analytics workspace resource group> \
 --logs '[
 {
 "category": <category name>,
 "enabled": true
 }
 ]'
You can combine these parameters to enable multiple output options.
To enable collection of resource diagnostic logs via the Azure CLI 2.0, you use the az monitor diagnostic-settings
create command.
To enable storage of diagnostic logs in a Storage Account:
The --resource-group argument is only required if --storage-account is not an object ID.
To enable streaming of diagnostic logs to an event hub:
The rule ID is a string with this format: {Service Bus resource ID}/authorizationrules/{key name} .
To enable sending of diagnostic logs to a Log Analytics workspace:
The --resource-group argument is only required if --workspace is not an object ID
With any command, you can add additional categories to the diagnostic log by adding dictionaries to the JSON
array passed as the --logs parameter. You can combine the --storage-account , --event-hub , and --workspace
parameters to enable multiple output options.
Enable collection of resource diagnostic logs via REST APIEnable collection of resource diagnostic logs via REST API
Manage resource diagnostic settings in the portal
To change diagnostic settings using the Azure Monitor REST API, see this document.
Ensure that all of your resources are set up with diagnostic settings. Navigate to Monitor in the portal and open

Outros materiais