| title | description | documentationcenter | author | manager | editor | ms.service | ms.devlang | ms.topic | ms.tgt_pltfrm | ms.workload | ms.date | ms.author |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Monitoring data collected by Azure Monitor | Microsoft Docs |
Monitoring data collected by Azure Monitor is separated into metrics that are lightweight and capable of supporting near real-time scenarios and logs that are stored in Log Analytics for advanced analysis. |
bwren |
carmonm |
tysonn |
monitoring |
na |
conceptual |
na |
infrastructure-services |
09/27/2018 |
bwren |
Azure Monitor is a service that helps you monitor your applications and the resources they rely on. Central to this function is storage of telemetry and other data from monitored resources. This article provides a complete description of how this data is stored and used by Azure Monitor.
All data collected by Azure Monitor fits into one of two fundamental types, metrics and logs. Metrics are numerical values that describe some aspect of a system at a particular point in time. They are lightweight and capable of supporting near real-time scenarios. Logs contain different kinds of data organized into records with different sets of properties for each type. Telemetry such as events and traces are stored as logs in addition to performance data so that it can all be combined for analysis.
Metrics are numerical values that describe some aspect of a system at a particular time. They are lightweight and capable of supporting near real-time scenarios. Metrics are collected at regular intervals whether or not the value changes. They're useful for alerting because they can be sampled frequently, and an alert can be fired quickly with relatively simple logic.
For example, you might collect processor utilization from a virtual machine every minute or the number of users logged in to your application every 10 minutes. You could fire an alert when one of those collected values or even the difference between two values exceeds a defined threshold.
Specific attributes of metrics in Azure include the following:
- Collected at one-minute frequency unless specified otherwise in the metric's definition.
- Uniquely identified by a metric name and a namespace that acts as a category.
- Stored for 93 days. You can copy metrics to Log Analytics for long term trending.
Each metric value has the following properties:
- The time the value was collected.
- The type of measurement the value represents.
- The resource the value is associated with.
- The value itself.
- Some metrics may have multiple dimensions as described in the next section. Custom metrics can have up to 10 dimensions.
Dimensions of a metric are name-value pairs that carry additional data to describe the metric value. For example, a metric Available disk space can have a dimension called Drive with values C:, D:, which would allow viewing either available disk space across all drives or for each drive individually.
The example below illustrates two datasets for a hypothetical metric called Network Throughput. The first dataset has no dimensions. The second dataset shows the values with two dimensions, I_P Address_ and Direction:
| Timestamp | Metric Value |
|---|---|
| 8/9/2017 8:14 | 1,331.8 Kbps |
| 8/9/2017 8:15 | 1,141.4 Kbps |
| 8/9/2017 8:16 | 1,110.2 Kbps |
This non-dimensional metric can only answer a basic question like "what was my network throughput at a given time?”
| Timestamp | Dimension "IP" | Dimension "Direction" | Metric Value |
|---|---|---|---|
| 8/9/2017 8:14 | IP="192.168.5.2" | Direction="Send" | 646.5 Kbps |
| 8/9/2017 8:14 | IP="192.168.5.2" | Direction="Receive" | 420.1 Kbps |
| 8/9/2017 8:14 | IP="10.24.2.15" | Direction="Send" | 150.0 Kbps |
| 8/9/2017 8:14 | IP="10.24.2.15" | Direction="Receive" | 115.2 Kbps |
| 8/9/2017 8:15 | IP="192.168.5.2" | Direction="Send" | 515.2 Kbps |
| 8/9/2017 8:15 | IP="192.168.5.2" | Direction="Receive" | 371.1 Kbps |
| 8/9/2017 8:15 | IP="10.24.2.15" | Direction="Send" | 155.0 Kbps |
| 8/9/2017 8:15 | IP="10.24.2.15" | Direction="Receive" | 100.1 Kbps |
This metric can answer questions such as "what was the network throughput for each IP address?", and "how much data was sent versus received?" Multi-dimensional metrics carry additional analytical and diagnostic value compared to non-dimensional metrics.
Individual metrics typically provide little insight on their own. They provide a single value without any context other than comparison to a simple threshold. They're valuable when combined with other metrics to identify patterns and trends, or when combined with logs that provide context around particular values.
For example, a certain number of users on your application at a given time might tell you little about the health of the application. But a sudden drop in users, indicated by multiple values of the same metric, might indicate a problem. Excessive exceptions thrown by the application, and indicated by a separate metric, might identify an application issue that's causing the drop. Events that the application creates to identify failures in its components can help you identify the root cause.
There are three fundamental sources of metrics collected by Azure Monitor. All of these metrics are available in the metric store where they can be evaluated together regardless of their source.
Platform metrics are created by Azure resources and give you visibility into their health and performance. Each type of resource creates a distinct set of metrics without any configuration required.
Application metrics are created by Application Insights for your monitored applications and help you detect performance issues and track trends in how your application is being used. This includes such values as Server response time and Browser exceptions.
Custom metrics are metrics that you define in addition to the standard metric that are automatically available. Custom metrics must be created against a single resource in the same region as that resource. You can create custom metrics using the following methods: - Define custom metrics in your application that's monitored by Application Insights. These are in addition to the standard set of application metrics. - Publish custom metrics from your Windows virtual machines using Windows Diagnostic Extension (WAD). - Publish custom metrics from your Linux virtual machines using InfluxData Telegraf Agent. - Write custom metrics from an Azure service using the custom metrics API.
Tasks that you can perform with metrics include the following:
- Use Metrics explorer to analyze collected metrics and plot them on a chart. Track the performance of a resource (such as a VM, website, or logic app) by pinning charts to an Azure dashboard.
- Configure a metric alert rule that sends a notification or takes automated action when the metric crosses a threshold.
- Use Autoscale to increase or decrease resources based on a metric crossing a threshold.
- Route metrics to Log Analytics to analyze metric data together with log data and to store metric values for longer than 93 days.
- Stream metrics to an Event Hub to route them to Azure Stream Analytics or to external systems.
- Archive the performance or health history of your resource for compliance, auditing, or offline reporting purposes.
- Access metric values from a command line or custom application using PowerShell cmdlets or REST API.
Metrics in Azure are collected in the Azure Monitor metrics database. This is a time series database optimized for quick retrieval and stores metric values for 93 days. Copy metrics to Log Analytics for long term analysis and trending.
Metric data is used in a variety of ways as described above. Use Metrics explorer to directly analyze the data in your metric store and chart the values of multiple metrics over time. You can view the charts interactively or pin them to a dashboard to view them with other visualizations. You can also retrieve metrics by using the Azure monitoring REST API.
Logs contain different kinds of data organized into records with different sets of properties for each type. Logs can contain numeric values like metrics but typically contain text data with detailed descriptions. They further differ from metrics in that they vary in their structure and are often not collected at regular intervals.
A common type of log entry is an event which are collected sporadically. They're created by an application or service and typically include enough information to provide complete context on their own. For example, an event can indicate that a particular resource was created or modified, a new host started in response to increased traffic, or an error was detected in an application.
Logs are especially useful for combining data from a variety of sources, for complex analysis, and for trending over time. Because the format of the data can vary, applications can create custom logs by using the structure that they need. Metrics are even replicated in logs to combine them with other monitoring data for trending and other data analysis.
Logs collected by Azure Monitor are stored in Log Analytics which collects telemetry and other data from a variety of sources. It provides a rich query language and an analytics engine that gives you insights into the operation of your applications and resources. Other Azure services such as Azure Security Center store their data in Log Analytics in order to provide a common data platform across Azure management.
Important
Data from Application Insights is stored in Log Analytics like other log data except that it's stored in a separate partition. This supports the same functionality as other Log Analytics data, but you must use the Application Insights console or the Application Insights API to access this data. You can use a cross-resource query to analyze application data together with other log data.
Log Analytics can collect data from a variety of sources both within Azure and from on-premises resources. Sources of data written to Log Analytics include the following:
- Activity logs from Azure resources that include information on their configuration and health and Diagnostic logs that provide insights into their operation.
- Agents on Windows and Linux virtual machines that send telemetry from the guest operating system and applications to Log Analytics according to Data Sources that you configure.
- Application data collected by Application Insights.
- Data providing insights into a particular application or service from monitoring solutions or features such as Container Insights, VM Insights, or Resource Group Insights.
- Security data collected by Azure Security Center.
- Metrics from Azure resources. This allows you to store metrics for longer than 93 days and to analyze it with other log data.
- Telemetry written to Azure Storage.
- Custom data from any REST API client using the HTTP Data Collector API client or from an Azure Logic App workflow.
Tasks that you can perform with logs include the following:
- Use the Log Analytics page in the Azure portal to write queries analyzing log data. Pin results rendered as tables or charts to an Azure dashboard.
- Configure a log alert rule that sends a notification or takes automated action when the results of the query match a particular result.
- Build a workflow based on data in Log Analytics using Logic Apps.
- Export the results of a query to Power BI to use different visualizations and share with users outside of Azure.
- Access metric values from a command line or custom application using PowerShell cmdlets or REST API.
All data from Log Analytics is retrieved using a log query that specifies a particular set of data. Queries are written using the Log Analytics query language which is a rich query language to quickly retrieve, consolidate, and analyze collected data. Use the Log Analytics page in the Azure portal to directly analyze the data in your metric store and chart the values of multiple metrics over time. You can view the charts interactively or pin them to a dashboard to view them with other visualizations. You can also retrieve metrics by using the Azure monitoring REST API.
You can copy metrics to Log Analytics to perform complex analysis with other data types by using its rich query language. You can also retain log data for longer periods than metrics, which enables you to perform trending over time. When metrics or any other performance data is stored in Log Analytics, that data acts as a log. Use metrics to support near real-time analysis and alerting while using logs for trending and analysis with other data.
You can get guidance for collecting metrics from Azure resources at Collect Azure service logs and metrics for use in Log Analytics. Get guidance for collecting resources metrics from Azure PaaS resources at Configure collection of Azure PaaS resource metrics with Log Analytics.
As described above, metrics are more responsive than logs, so you can create alerts with lower latency and at a lower cost. Log Analytics collects a significant amount of numeric data that would be suitable for metrics but isn't stored in the Azure metrics database. A common example is performance data collected from agents and management solutions. Some of these values can be copied into the metrics database, where they are available for alerting and for analysis with Metrics explorer.
The explanation of this feature is available at Create Metric Alerts for Logs in Azure Monitor. The list of values support is available at Supported metrics with Azure Monitor.
In addition to using the tools in Azure to analyze monitoring data, you may have a requirement to forward it to an external tool such as a security information and event management (SIEM) product. This forwarding is typically done directly from monitored resources through Azure Event Hubs.
You can get guidance for the different kinds of monitoring data at Stream Azure monitoring data to an event hub for consumption by an external tool.
- Learn about the monitoring data available for different resources in Azure.