Baixe o app para aproveitar ainda mais
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
Compartilhar