Azure PDF

Contents
Azure Monitor Documentation

Overview
What is Azure Monitor?
Terminology changes
Quickstarts
Applications
.NET application
.NET Core application
Node.js application
Mobile application
Web application
Virtual machines
Collect - Azure VMs
Collect - Linux computer
Collect - Windows computer
Tutorials
Logs
Log Analytics
Log queries
Visualize log data
Alert on log data
Application Insights
Find application run-time exceptions
Find application performance issues
Alert on application health
Understand application users
Create custom dashboards
Archive platform metric and log data
Autoscale on performance and schedule
Samples
Azure PowerShell
Concepts
Azure management
Continuous monitoring
Data sources
Data platform
Overview
Data locations
Metrics
Logs
Log data ingestion time
Insights
Monitoring solutions
Data security
Log data
Personal log data handling
Application data collection, retention, and storage
Alerts
Overview
Metric alerts
Log alerts
Activity log alerts
Change analysis
Visualize data
Partner integrations
FAQ
Log Analytics
How-to guides
Manage Azure Monitor
Design a workspace deployment
Roles permissions and security
IP addresses
Log Analytics workspaces
Create a workspace
Use Azure portal
Use Azure CLI
Use Azure PowerShell
Delete and recover a workspace
Design for service providers
Manage access
Usage and cost
Usage and estimated costs
Application usage and costs
Log data usage and costs
Monitor resources
Applications
Application Insights overview
Code-based monitoring
ASP.NET Core
ASP.NET
Non-Http apps/Background apps
.NET Console
ILogger
Java
Web apps
Docker apps
Log traces
Unix metrics
Dependencies
Filter telemetry
Micrometer Metrics
Spring Boot app
Troubleshoot
Node.js apps
Node.js
Web pages
Client-side JavaScript
Application Insights API summary
Troubleshoot ASP.NET
Codeless monitoring
Azure VM and Azure virtual machine scale set
Azure App Service
Azure Cloud Services
Azure Functions
Kubernetes applications
Status Monitor
Status Monitor v2
Overview
Getting started
Detailed instructions
Troubleshooting and known issues
API Disable-InstrumentationEngine
API Disable-ApplicationInsightsMonitoring
API Enable-InstrumentationEngine
API Enable-ApplicationInsightsMonitoring
API Get-ApplicationInsightsMonitoringConfig
API Get-ApplicationInsightsMonitoringStatus
API Set-ApplicationInsightsMonitoringConfig
API Start-ApplicationInsightsMonitoringTrace
Create a resource
Application dashboard
Application Map
Transaction diagnostics
Availability
URL tests
Multi-step tests
Availability alerts
Performance testing
Troubleshooting
Distributed tracing
Overview
Telemetry correlation
Local forwarder
Python
Go
Live Metric stream
Metrics
Log-based & pre-aggregated metrics
Log-based metrics definitions
Classic metrics explorer
Search
Profiler
Overview
Enable Profiler for an App Service
Enable the Profiler for a Cloud Service
Enable Profiler for a Service Fabric Application
Enable Profiler for an Azure VM
Profiler for Linux App services (preview)
Profiler Settings
Track Requests for Profiling
Profiler Troubleshooting
Snapshot Debugger
Overview
Enable Snapshot Debugger for an App Service
Enable Snapshot Debugger for other environments
Upgrade Snapshot Debugger
Snapshot Debugger troubleshooting
Smart Detection
Failure anomalies
Performance anomalies
Trace degradation
Exception volume
Memory leak
Security detection
Manage smart detection rules
E-mail notification
Usage (user behavior analytics)
Overview
Send user context
Users, Sessions, Events
Funnels
Cohorts
Impact
Retention
User Flows
Usage analytics
Azure DevOps
Release annotations
Continuous monitoring
Advanced configuration
Access control
IP address collection
Sampling
TelemetryChannels
TelemetryProcessors
Track custom operations in .NET SDK
Custom email reports
Exceptions
Log traces
Performance counters
EventCounters
Dependencies
ApplicationInsights.config
Correlate custom data sources
Special topics
Deep diagnostics for web apps and services
Monitor performance in web applications
Separate development, test, and production
How do I ... in Application Insights?
Export
Continuous export
Export to Stream Analytics
Export to SQL using Stream Analytics
Export data model
Visual Studio
F5 insights
Trends
CodeLens
Other platforms
SharePoint sites
Windows desktop
Containers
Azure Monitor for containers
Overview
FAQ
Enable monitoring
Enable monitoring overview
Enable for new cluster
Enable for existing cluster
Region mappings
Analyze
Disable monitoring
View live logs
Analyze data with log queries
Alerting
Agent management
Configure agent collection settings
Update to enable metrics
Troubleshooting
Docker and Windows Container monitoring
Operating System (VMs and more)
Agents
Agents overview
Azure Diagnostics extension
Overview
Collect logs
Windows
Linux
Log Analytics agents
Overview
Windows agents
VM Extension for Windows
VM Extension for Linux
Log Analytics gateway
Agent management
Agent Health
Troubleshoot
Log Analytics VM Extension
Log Analytics Windows agent
Log Analytics Linux agent
Agent data sources
Overview
Windows events
Custom JSON data
CollectD performance data
Syslog
Linux application performance
IIS logs
Custom logs
Custom fields
Azure Monitor for VMs
Overview
Known issues
FAQ
Enable monitoring
Enable monitoring overview
Enable for single Azure VM
Enable using Azure Policy
Enable using Azure PowerShell
Enable for Hybrid environment
Integration with Operations Manager
Monitor health
Map dependencies
Monitor performance
Using workbooks
Analyze data with log queries
Disable monitoring
Capacity and performance solution
VMware Analytics solution
Wire Data solution
Service Map solution
Computer groups
Azure platform
Platform logs overview
Resource logs
Overview
Collect in Azure Monitor Logs
Archive to storage
Stream to Event Hubs
Activity log
Overview
View and retrieve
Collect and analyze
Collect across tenants
Export
Schema
Diagnostic settings
Create diagnostic setting
Create diagnostic setting with Resource Manager
Change to blob storage format
Stream data to Event Hubs
Key Vault Analytics
Service Fabric Analytics
Monitor resource groups
Storage
Azure Monitor for Storage
Databases
Azure SQL
SQL Server
Networks
Networking Analytics
DNS
Network Performance Monitor
Solution overview
Performance Monitor
Service Connectivity Monitor
ExpressRoute
Pricing
FAQ
Other resources
Assess AD Health
AD Replication Status
Office 365
Surface Hub
Use monitoring solutions
Overview
Target solutions
Collect custom data
Custom metrics
Metrics REST API
Log Analytics Data collector API
Log Analytics Data Collector API Pipeline example
Use System Center
Connect Operations Manager
Assess Operations Manager
Connect Configuration Manager
Stream data to Event Hubs
Analyze data
Metrics
Getting started with Metrics Explorer
Advanced features of Metrics Explorer
Examples of metric charts
Troubleshooting metric charts
Logs
Log query overview
Simple logs experience
Tutorials
Log Analytics tutorial
Log queries tutorial
Log data
Log data structure
Query scope
Standard properties
Query language
Query language Documentation
Language differences
Useful operators
Functions
Transition from log search
Lessons
String operations
Date and time operations
Aggregation functions
Advanced aggregations
Joins
JSON and data structures
Advanced query writing
Charts and diagrams
Search queries
Cheatsheets
SQL
Splunk
Cross resource
Cross-resource queries
app expression
workspace expression
resource expression
Unify application data resources
Examples and guidance
Log query examples
Smart analytics examples
Write efficient queries
Parse text data
Flow / Logic Apps
Flow connector with Logs
Flow Connector with applications
Logic Apps with applications
REST API
Visualize data
Views
View Designer
Tile reference
Visualization part reference
Filters
Power BI
Export log data
Export application data
Workbooks
Dashboards
Send data to Grafana
Alerting
Application alert rules
Availability
Metric alerts
Metric alert rules
Manage metric alerts
Use dynamic thresholds
Metric alerts on logs
Using Resource Manager template
Log alert rules
Configure alerts on analytics query
Queries
Webhook actions
Troubleshooting
Activity log alert rules
Alert on an activity log event
Migrate management events to activity log alerts
Service health alerts in activity log
View notifications
Configure alerts on notification events
Notifications and actions
Action rules (Preview)
Create action group
Common alert schema
Common alert schema definition
Integrate the common alert schema with Logic Apps
Webhook schema
SMS alert behavior
Notification rate limiting
Create action groups with Resource Manager
Implement a Logic App action
Alert Management solution
Alert user interface
About smart groups
Manage alert instances
Manage smart groups
Manage alert and smart group states
Manage alerts from other monitoring services
Migrate classic alert rules
About classic alerts
Prepare for migration
Understand the migration tool
Use the migration tool
Automatic migration process
Manage classic metric alerts
Classic metric alert using a Resource Manager template
Classic metric alert calling a webhook
Alert API
IT Service Management
IT Service Management Connector
IT Service Management connections
Create Service Manager web app
Automate
Autoscale
Overview
Walkthrough
Settings
Best practices
Common metrics
Common patterns
Scale with custom metrics
Scale VM scale sets
Scale VM scale sets using Resource Manager templates
Use webhooks and email notifications
PowerShell
Azure PowerShell samples
PowerShell cmdlets
Applications
Create Application Insights resources
Create resources
Set alerts
Get Azure diagnostics
Azure CLI samples
Resource Manager templates
Extend
Design and build
Solution file
Automation resources
Log searches and alerts
Views
Best practices
Reference
Service limits
Dependency auto-collection
NuGet packages
Platform support
Endpoint overrides
Data model
Overview
Request
Dependency
Exception
Trace
Event
Metric
Context
Integration with Azure Functions
Metrics
Supported metrics
Supported metrics for newer alerts
Diagnostic Logs
Diagnostic logs services, categories, and schemas
Azure CLI
Azure CLI - Application Insights (Preview)
Azure Functions
Azure PowerShell
Logs
REST API
Monitor
Logs
Resource Manager template
Monitor
Logs
Feature and API Retirement
Classic autoscale & metrics API
Classic alerting & monitoring
Switch log alert API preference
HockeyApp data
Web App Analytics solution
Application Insights Connector
Monitor Docker applications
OMS portal deprecation
Resources
Azure Roadmap
Pricing
Pricing calculator
News
Application Insights service updates
Log Analytics service updates
SDK release notes
Windows Analytics
Regional availability
Videos
Quickstart templates
Stack Overflow
Code samples
Azure Monitor overview
9/27/2019 • 9 minutes to read • Edit Online
Azure Monitor maximizes the availability and performance of your applications and services by delivering a
comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises
environments. It helps you understand how your applications are performing and proactively identifies issues
affecting them and the resources they depend on.
Just a few examples of what you can do with Azure Monitor include:
Detect and diagnose issues across applications and dependencies with Application Insights.
Correlate infrastructure issues with Azure Monitor for VMs and Azure Monitor for Containers.
Drill into your monitoring data with Log Analytics for troubleshooting and deep diagnostics.
Support operations at scale with smart alerts and automated actions.
Create visualizations with Azure dashboards and workbooks.
Overview
The following diagram gives a high-level view of Azure Monitor. At the center of the diagram are the data stores
for metrics and logs, which are the two fundamental types of data use by Azure Monitor. On the left are the
sources of monitoring data that populate these data stores. On the right are the different functions that Azure
Monitor performs with this collected data such as analysis, alerting, and streaming to external systems.
Monitoring data platform

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.
For many Azure resources, you'll see data collected by Azure Monitor right in their Overview page in the Azure
portal. Have a look at any virtual machine for example, and you'll see several charts displaying performance
metrics. Click on any of the graphs to open the data in metrics explorer in the Azure portal, which allows you to
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.
Log data collected by Azure Monitor can be analyzed with queries to quickly retrieve, consolidate, and analyze
collected data. You can create and test queries using Log Analytics in the Azure portal and then either directly
analyze the data using these tools or save queries for use with visualizations or alert rules.
Azure Monitor uses a version of the Kusto query language used by Azure Data Explorer that is suitable for
simple log queries but also includes advanced functionality such as aggregations, joins, and smart analytics. You
can quickly learn the query language using multiple lessons. Particular guidance is provided to users who are
already familiar with SQL and Splunk.
What data does Azure Monitor collect?

Azure Monitor can collect data from a variety of sources. You can think of monitoring data for your applications
in tiers ranging from your application, any operating system and services it relies on, down to the platform itself.
Azure Monitor collects data from each of the following tiers:
Application monitoring data: Data about the performance and functionality of the code you have written,
regardless of its platform.
Guest OS monitoring data: Data about the operating system on which your application is running. This
could be running in Azure, another cloud, or on-premises.
Azure resource monitoring data: Data about the operation of an Azure resource.
Azure subscription monitoring data: Data about the operation and management of an Azure subscription,
as well as data about the health and operation of Azure itself.
Azure tenant monitoring data: Data about the operation of tenant-level Azure services, such as Azure
Active Directory.
As soon as you create an Azure subscription and start adding resources such as virtual machines and web apps,
Azure Monitor starts collecting data. Activity logs record when resources are created or modified. Metrics tell
you how the resource is performing and the resources that it's consuming.
Extend the data you're collecting into the actual operation of the resources by enabling diagnostics and adding
an agent to compute resources. This will collect telemetry for the internal operation of the resource and allow
you to configure different data sources to collect logs and metrics from Windows and Linux guest operating
system.
Enable monitoring for your App Services application or VM and virtual machine scale set application, to enable
Application Insights to collect detailed information about your application including page views, application
requests, and exceptions. Further verify the availability of your application by configuring an availability test to
simulate user traffic.
Custom sources
Azure Monitor can collect log data from any REST client using the Data Collector API. This allows you to create
custom monitoring scenarios and extend monitoring to resources that don't expose telemetry through other
sources.
Insights
Monitoring data is only useful if it can increase your visibility into the operation of your computing environment.
Azure Monitor includes several features and tools that provide valuable insights into your applications and other
resources that they depend on. Monitoring solutions and features such as Application Insights and Azure
Monitor for containers provide deep insights into different aspects of your application and specific Azure
services.
Application Insights monitors the availability, performance, and usage of your web applications whether they're
hosted in the cloud or on-premises. It leverages the powerful data analysis platform in Azure Monitor to provide
you with deep insights into your application's operations and diagnose errors without waiting for a user to
report them. Application Insights includes connection points to a variety of development tools and integrates
with Visual Studio to support your DevOps processes.

Azure Monitor for containers is a feature designed to monitor the performance of container workloads deployed
to managed Kubernetes clusters hosted on Azure Kubernetes Service (AKS ). It gives you performance visibility
by collecting memory and processor metrics from controllers, nodes, and containers that are available in
Kubernetes through the Metrics API. Container logs are also collected. After you enable monitoring from
Kubernetes clusters, these metrics and logs are automatically collected for you through a containerized version
of the Log Analytics agent for Linux.
Azure Monitor for VMs monitors your Azure virtual machines (VM ) at scale by analyzing the performance and
health of your Windows and Linux VMs, including their different processes and interconnected dependencies on
other resources and external processes. The solution includes support for monitoring performance and
application dependencies for VMs hosted on-premises or another cloud provider.
Monitoring solutions in Azure Monitor are packaged sets of logic that provide insights for a particular
application or service. They include logic for collecting monitoring data for the application or service, queries to
analyze that data, and views for visualization. Monitoring solutions are available from Microsoft and partners to
provide monitoring for various Azure services and other applications.
Responding to critical situations

In addition to allowing you to interactively analyze monitoring data, an effective monitoring solution must be
able to proactively respond to critical conditions identified in the data that it collects. This could be sending a text
or mail to an administrator responsible for investigating an issue. Or you could launch an automated process
that attempts to correct an error condition.
Alerts
Alerts in Azure Monitor proactively notify you of critical conditions and potentially attempt to take corrective
action. Alert rules based on metrics provide near real time alerting based on numeric values, while rules based
on logs allow for complex logic across data from multiple sources.
Alert rules in Azure Monitor use action groups, which contain unique sets of recipients and actions that can be
shared across multiple rules. Based on your requirements, action groups can perform such actions as using
webhooks to have alerts start external actions or to integrate with your ITSM tools.
Autoscale
Autoscale allows you to have the right amount of resources running to handle the load on your application. It
allows you to create rules that use metrics collected by Azure Monitor to determine when to automatically 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 and the logic for when to increase or decrease resources.
Visualizing monitoring data

Visualizations such as charts and tables are effective tools for summarizing monitoring data and presenting it to
different audiences. Azure Monitor has its own features for visualizing monitoring data and leverages other
Azure services for publishing it to different audiences.
Dashboards
Azure dashboards allow you to combine different kinds of data, including both metrics and logs, into a single
pane in the Azure portal. You can optionally share the dashboard with other Azure users. Elements throughout
Azure Monitor can be added to an Azure dashboard in addition to the output of any log query or metrics chart.
For example, you could create a dashboard that combines tiles that show a graph of metrics, a table of activity
logs, a usage chart from Application Insights, and the output of a log query.
Views
Views visually present log data in Azure Monitor. Each view includes a single tile that drills down to a
combination of visualizations such as bar and line charts in addition to lists summarizing critical data.
Monitoring solutions include views that summarize data for a particular application, and you can create your
own views to present data from any log query. Like other elements in Azure Monitor, views can be added to
Azure dashboards.
Power BI
Power BI is a business analytics service that provides interactive visualizations across a variety of data sources
and is an effective means of making data available to others within and outside your organization. You can
configure Power BI to automatically import log data from Azure Monitor to take advantage of these additional
visualizations.
Integrate and export data

You'll often have the requirement to integrate Azure Monitor with other systems and to build custom solutions
that use your monitoring data. Other Azure services work with Azure Monitor to provide this integration.
Event Hub
Azure Event Hubs is a streaming platform and event ingestion service that can transform and store data using
any real-time analytics provider or batching/storage adapters. Use Event Hubs to stream Azure Monitor data to
partner SIEM and monitoring tools.
Logic Apps
Logic Apps is a service that allows you to automate tasks and business processes using workflows that integrate
with different systems and services. Activities are available that read and write metrics and logs in Azure
Monitor, which allows you to build workflows integrating with a variety of other systems.
API
Multiple APIs are available to read and write metrics and logs to and from Azure Monitor in addition to
accessing generated alerts. You can also configure and retrieve alerts. This provides you with essentially
unlimited possibilities to build custom solutions that integrate with Azure Monitor.
Next steps
Learn more about:
Metrics and logs for the data collected by Azure Monitor.
Data sources for how the different components of your application send telemetry.
Log queries for analyzing collected data.
Best practices for monitoring cloud applications and services.
Azure Monitor naming and terminology changes
Significant changes have been made to Azure Monitor recently, with different services being consolidated in order
to simplify monitoring for Azure customers. This article describes recent name and terminology changes in Azure
Monitor documentation.
February 2019 - Log Analytics terminology

After the consolidation of different services under Azure Monitor, we're taking the next step by modifying
terminology in our documentation to better describe the Azure Monitor service and its different components.
Log Analytics
Azure Monitor log data is still stored in a Log Analytics workspace and is still collected and analyzed by the same
Log Analytics service, but we are changing the term Log Analytics in many places to Azure Monitor logs. This term
better reflects its role in Azure Monitor and provides better consistency with metrics in Azure Monitor.
The term log analytics now primarily applies to the page in the Azure portal used to write and run queries and
analyze log data. It's the functional equivalent of metrics explorer, which is the page in the Azure portal used to
analyze metric data.
Workspaces that hold log data in Azure Monitor are still referred to as Log Analytics workspaces. The Log
Analytics menu in the Azure portal has been renamed to Log Analytics workspaces and is where you create
new workspaces and configure data sources. Analyze your logs and other monitoring data in Azure Monitor and
configure your workspace in Log Analytics workspaces.
Management solutions
Management solutions have been renamed to monitoring solutions, which better describes their functionality.
August 2018 - Consolidation of monitoring services into Azure Monitor

Log Analytics and Application Insights have been consolidated into Azure Monitor to provide a single integrated
experience for monitoring Azure resources and hybrid environments. No functionality has been removed from
these services, and users can perform the same scenarios that they've always completed with no loss or
compromise of any features.
Documentation for each of these services has been consolidated into a single set of content for Azure Monitor. This
will assist the reader in finding all of the content for a particular monitoring scenario in a single location as
opposed to having to reference multiple sets of content. As the consolidated service evolves, the content will
become more integrated.
Other features that were considered part of Log Analytics such as agents and views have also been repositioned as
features of Azure Monitor. Their functionality hasn't changed other than potential improvements to their
experience in the Azure portal.
April 2018 - Retirement of Operations Management Suite brand

Operations Management Suite (OMS ) was a bundling of the following Azure management services for licensing
purposes:
Azure Automation
Azure Backup
Log Analytics
Site Recovery
New pricing has been introduced for these services, and the OMS bundling is no longer available for new
customers. None of the services that were part of OMS have changed, except for the consolidation into Azure
Monitor described above.
Next steps
Read an overview of Azure Monitor that describes its different components and features.
Learn about the transition of the OMS portal.
Start monitoring your ASP.NET Web Application
With Azure Application Insights, you can easily monitor your web application for availability, performance, and
usage. You can also quickly identify and diagnose errors in your application without waiting for a user to report
them. With the information that you collect from Application Insights about the performance and effectiveness of
your app, you can make informed choices to maintain and improve your application.
This quickstart shows how to add Application Insights to an existing ASP.NET web application and start analyzing
live statistics, which is just one of the various methods you can use to analyze your application. If you do not have
an ASP.NET web application, you can create one following the Create an ASP.NET Web App quickstart.
Prerequisites
To complete this quickstart:
Install Visual Studio 2019 with the following workloads:
ASP.NET and web development
Azure development
If you don't have an Azure subscription, create a free account before you begin.
Enable Application Insights

1. Open your project in Visual Studio 2019.
2. Select Configure Application Insights from the Project menu. Visual Studio adds the Application Insights
SDK to your application.
IMPORTANT
The process to add Application Insights varies by ASP.NET template type. If you are using the Empty or Azure
Mobile App template select Project > Add Application Insights Telemetry. For all other ASP.NET templates
consult the instructions in the step above.
3. Click Get Started (earlier versions of Visual Studio have a Start Free button instead).
4. Select your subscription and click Register.
5. Select Project > Manage NuGet Packages > Package source: nuget.org > Update the Application
Insights SDK packages to the latest stable release.
6. Run your application by either selecting Start Debugging from the Debug menu or by pressing the F5
key.
Confirm app configuration

Application Insights gathers telemetry data for your application regardless of where it's running. Use the following
steps to start viewing this data.
1. Open Application Insights by clicking View -> Other Windows -> Application Insights Search. You see
the telemetry from your current session.
2. Click on the first request in the list (GET Home/Index in this example) to see the request details. Notice that
the status code and response time are both included along with other valuable information about the
request.
Start monitoring in the Azure portal

You can now open Application Insights in the Azure portal to view various details about your running application.
1. Expand the Connected Services folder (cloud and plug icon) in the Solution Explorer then right-click on
the Application Insights folder and click Open Application Insights Portal. You see some information
about your application and a variety of options.
2. Click on Application map to get a visual layout of the dependency relationships between your application
components. Each component shows KPIs such as load, performance, failures, and alerts.
3. Click on the App Analytics icon View in Logs (Analytics) on one of the application components. This
opens Logs (Analytics), which provides a rich query language for analyzing all data collected by
Application Insights. In this case, a query is generated for you that renders the request count as a chart. You
can write your own queries to analyze other data.
4. Click on Live Metrics Stream on the left under investigate. This shows live statistics about your application
as it's running. This includes such information as the number of incoming requests, the duration of those
requests, and any failures that occur. You can also inspect critical performance metrics such as processor and
memory.
If you are ready to host your application in Azure, you can publish it now. Follow the steps described in
Create an ASP.NET Web App Quickstart.
5. If you use Visual Studio to add Application Insights monitoring, you can automatically add client-side
monitoring. To add client-side monitoring manually to an application add the following JavaScript to your
application:

<script type="text/javascript">
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c=
{config:a},d=document,e=window;setTimeout(function(){var
b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagN
ame("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=
["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthentica
tedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"
),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var
g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<your instrumentation key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
</script>
To learn more, visit the GitHub repository for our open-source JavaScript SDK.
Video
External step-by-step video about configuring Application Insights with a .NET application from scratch.
Clean up resources
When you are done testing, you can delete the resource group and all related resources. To do so follow the steps
below.
1. From the left-hand menu in the Azure portal, click Resource groups and then click myResourceGroup.
2. On your resource group page, click Delete, type myResourceGroup in the text box, and then click Delete.
Next steps
In this quickstart, you’ve enabled your application for monitoring by Azure Application Insights. Continue to the
tutorials to learn how to use it to monitor statistics and detect issues in your application.
Azure Application Insights tutorials
Start Monitoring Your ASP.NET Core Web Application
them.
This quickstart guides you through adding the Application Insights SDK to an existing ASP.NET Core web
application. To learn about configuring Application Insights without Visual Studio checkout this article.
Prerequisites
Azure development
Install .NET Core 2.0 SDK
You will need an Azure subscription and an existing .NET Core web application.
If you don't have an ASP.NET Core web application, you can use our step-by-step guide to create an ASP.NET
Core app and add Application Insights.
Sign in to the Azure portal

Sign in to the Azure portal.

Application Insights can gather telemetry data from any internet-connected application, regardless of whether it's
running on-premises or in the cloud. Use the following steps to start viewing this data.
1. Select Create a resource > Developer tools > Application Insights.
NOTE
If this is your first time creating an Application Insights resource you can learn more by visiting the Create an
Application Insights Resource doc.
A configuration box appears; use the following table to fill out the input fields.
SETTINGS VALUE DESCRIPTION
Name Globally Unique Value Name that identifies the app you are
monitoring
Resource Group myResourceGroup Name for the new resource group to

host App Insights data
Location East US Choose a location near you, or near

where your app is hosted
2. Click Create.
Configure App Insights SDK

1. Open your ASP.NET Core Web App project in Visual Studio > Right-click on the AppName in the
Solution Explorer > Select Add > Application Insights Telemetry.
2. Click the Get Started button

3. Select your account and subscription > Select the Existing resource you created in the Azure portal > Click
Register.
4. Select Project > Manage NuGet Packages > Package source: nuget.org > Update the Application
Insights SDK packages to the latest stable release.
5. Select Debug > Start without Debugging (Ctrl+F5) to Launch your app
NOTE
It takes 3-5 minutes before data begins appearing in the portal. If this app is a low-traffic test app, keep in mind that most
metrics are only captured when there are active requests or operations.

1. Reopen the Application Insights Overview page in the Azure portal by selecting Home and under recent
resources select the resource you created earlier, to view details about your currently running application.
2. Click Application map for a visual layout of the dependency relationships between your application
3. Click on the App Analytics icon View in Analytics. This opens Application Insights Analytics,
which provides a rich query language for analyzing all data collected by Application Insights. In this case, a
query is generated for you that renders the request count as a chart. You can write your own queries to
analyze other data.
4. Return to the Overview page and examine the KPI Dashboards. This dashboard provides statistics about
your application health, including the number of incoming requests, the duration of those requests, and any
failures that occur.
5. On the left click on Metrics. Use the metrics explorer to investigate the health and utilization of your
resource. You can click Add new chart to create additional custom views or select Edit to modify the
existing chart types, height, color palette, groupings, and metrics. For example, you can make a chart that
displays the average browser page load time by picking "Browser page load time" from the metrics drop
down and "Avg" from aggregation. To learn more about Azure Metrics Explorer visit Getting started with
Azure Metrics Explorer.
Video
External step-by-step video about configuring Application Insights with .NET Core and Visual Studio from
scratch.
External step-by-step video about configuring Application Insights with .NET Core and Visual Studio Code from
scratch.
Clean up resources
below.
Next steps
Find and diagnose run-time exceptions
Quickstart: Start monitoring your Node.js Web
application with Azure Application Insights
them. With the version 0.20 SDK release onward, you can monitor common third-party packages, including
MongoDB, MySQL, and Redis.
This quickstart guides you through adding the version 0.22 Application Insights SDK for Node.js to an existing
Node.js web application.
Prerequisites
You need an Azure Subscription and an existing Node.js web application.
If you don't have a Node.js web application, you can create one by following the Create a Node.js web app
quickstart.


Application Insights can gather telemetry data from any internet-connected application, regardless of whether it's
running on-premises or in the cloud. Use the following steps to start viewing this data.
NOTE
A configuration page appears; use the following table to fill out the input fields.
monitoring
Application Type Node.js Application Type of app you are monitoring

2. Select Create.

1. Select Overview and copy your application's Instrumentation Key.
2. Add the Application Insights SDK for Node.js to your application. From your app's root folder run:
npm install applicationinsights --save
3. Edit your app's first .js file and add the two lines below to the topmost part of your script. If you are using
the Node.js quickstart app, you would modify the index.js file. Replace <instrumentation_key> with your
application's instrumentation key.
const appInsights = require('applicationinsights');

appInsights.setup('<instrumentation_key>').start();
4. Restart your app.
NOTE
It takes 3-5 minutes before data begins appearing in the portal. If this app is a low-traffic test app, keep in mind that most
metrics are only captured when there are active requests or operations occurring.

1. You can now reopen the Application Insights Overview page in the Azure portal, where you retrieved your
instrumentation key, to view details about your currently running application.
2. Select Application map for a visual layout of the dependency relationships between your application
3. Select the App Analytics icon View in Analytics. This opens Application Insights Analytics, which
provides a rich query language for analyzing all data collected by Application Insights. In this case, a query
is generated for you that renders the request count as a chart. You can write your own queries to analyze
other data.
4. Return to the Overview page and examine the KPI graphs. This dashboard provides statistics about your
application health, including the number of incoming requests, the duration of those requests, and any
failures that occur.
To enable the Page View Load Time chart to populate with client-side telemetry data, add this script to
each page that you want to track:

var appInsights=window.appInsights||function(config){
function i(config){t[config]=function(){var i=arguments;t.queue.push(function()
{t[config].apply(t,i)})}}var t=
{config:config},u=document,e=window,o="script",s="AuthenticatedUserContext",h="start",c="stop",l="Track"
,a=l+"Event",v=l+"Page",y=u.createElement(o),r,f;y.src=config.url||"https://az416426.vo.msecnd.net/scrip
ts/a/ai.0.js";u.getElementsByTagName(o)[0].parentNode.appendChild(y);try{t.cookie=u.cookie}catch(p)
{}for(t.queue=[],t.version="1.0",r=
["Event","Exception","Metric","PageView","Trace","Dependency"];r.length;)i("track"+r.pop());return
i("set"+s),i("clear"+s),i(h+a),i(c+a),i(h+v),i(c+v),i("flush"),config.disableExceptionTracking||
(r="onerror",i("_"+r),f=e[r],e[r]=function(config,i,u,e,o){var s=f&&f(config,i,u,e,o);return
s!==!0&&t["_"+r](config,i,u,e,o),s}),t
}({
instrumentationKey:"<insert instrumentation key>"
});
window.appInsights=appInsights;
appInsights.trackPageView();
</script>
5. On the left, select Metrics. Use the metrics explorer to investigate the health and utilization of your
resource. You can select Add new chart to create additional custom views or select Edit to modify the
existing chart types, height, color palette, groupings, and metrics. For example, you can make a chart that
displays the average browser page load time by selecting "Browser page load time" from the metrics drop
down and "Avg" from aggregation. To learn more about Azure Metrics Explorer visit Getting started with
Azure Metrics Explorer.
To learn more about monitoring Node.js, check out the additional App Insights Node.js documentation.
Clean up resources
below.
1. From the left-hand menu in the Azure portal, select Resource groups and then select myResourceGroup.
2. On your resource group page, select Delete, enter myResourceGroup in the text box, and then select Delete.
Next steps
Find and diagnose performance problems
Start analyzing your mobile app with App Center
and Application Insights
This quickstart guides you through connecting your app's App Center instance to Application Insights. With
Application Insights, you can query, segment, filter, and analyze your telemetry with more powerful tools than are
available from the Analytics service of App Center.
Prerequisites
To complete this quickstart, you need:
An Azure subscription.
An iOS, Android, Xamarin, Universal Windows, or React Native app.
Onboard to App Center

Before you can use Application Insights with your mobile app, you need to onboard your app to App Center.
Application Insights does not receive telemetry from your mobile app directly. Instead, your app sends custom
event telemetry to App Center. Then, App Center continuously exports copies of these custom events into
Application Insights as the events are received. (This does not apply to the Application Insights JS SDK or the
React Native plugin where telemetry is sent directly to Application Insights.)
To onboard your app, follow the App Center quickstart for each platform your app supports. Create separate App
Center instances for each platform:
iOS.
Android.
Xamarin.
Universal Windows.
React Native.
Track events in your app

After your app is onboarded to App Center, it needs to be modified to send custom event telemetry using the App
Center SDK. Custom events are the only type of App Center telemetry that is exported to Application Insights.
To send custom events from iOS apps, use the trackEvent or trackEvent:withProperties methods in the App
Center SDK. Learn more about tracking events from iOS apps.
MSAnalytics.trackEvent("Video clicked")
To send custom events from Android apps, use the trackEvent method in the App Center SDK. Learn more about
tracking events from Android apps.
Analytics.trackEvent("Video clicked")
To send custom events from other app platforms, use the trackEvent methods in their App Center SDKs.
To make sure your custom events are being received, go to the Events tab under the Analytics section in App
Center. It can take a couple minutes for events to show up from when they're sent from your app.
Create an Application Insights resource

Once your app is sending custom events and these events are being received by App Center, you need to create
an App Center-type Application Insights resource in the Azure portal:
1. Sign in to the Azure portal.
NOTE
A configuration box will appear. Use the table below to fill out the input fields.
Name Some globally unique value, like Name that identifies the app you are
"myApp-iOS" monitoring
Resource Group A new resource group, or an existing The resource group in which to
one from the menu create the new Application Insights
resource
Location A location from the menu Choose a location near you, or near
3. Click Create.
If your app supports multiple platforms (iOS, Android, etc.), it's best to create separate Application Insights
resources, one for each platform.
Export to Application Insights

In your new Application Insights resource on the Overview page. Copy the instrumentation key from your
resource.
In the App Center instance for your app:
1. On the Settings page, click Export.
2. Choose New Export, pick Application Insights, then click Customize.
3. Paste your Application Insights instrumentation key into the box.
4. Consent to increasing the usage of the Azure subscription containing your Application Insights resource. Each
Application Insights resource is free for the first 1 GB of data received per month. Learn more about
Application Insights pricing.
Remember to repeat this process for each platform your app supports.
Once export is set up, each custom event received by App Center is copied into Application Insights. It can take
several minutes for events to reach Application Insights, so if they don't show up immediately, wait a bit before
diagnosing further.
To give you more data when you first connect, the most recent 48 hours of custom events in App Center are
automatically exported to Application Insights.
Start monitoring your app

Application Insights can query, segment, filter, and analyze the custom event telemetry from your apps, beyond
the analytics tools App Center provides.
1. Query your custom event telemetry. From the Application Insights Overview page, choose Logs
(Analytics).
The Application Insights Logs (Analytics) portal associated with your Application Insights resource will
open. The Logs (Analytics) portal lets you directly query your data using the Log Analytics query language,
so you can ask arbitrarily complex questions about your app and its users.
Open a new tab in the Logs (Analytics) portal, then paste in the following query. It returns a count of how
many distinct users have sent each custom event from your app in the last 24 hours, sorted by these
distinct counts.
customEvents
| where timestamp >= ago(24h)
| summarize dcount(user_Id) by name
| order by dcount_user_Id desc
a. Select the query by clicking anywhere on the query in the text editor.
b. Then click Go to run the query.
Learn more about Application Insights Analytics and the Log Analytics query language.
2. Segment and filter your custom event telemetry. From the Application Insights Overview page,
choose Users in the table of contents.
The Users tool shows how many users of your app clicked certain buttons, visited certain screens, or
performed any other action that you are tracking as an event with the App Center SDK. If you've been
looking for a way to segment and filter your App Center events, the Users tool is a great choice.
For example, segment your usage by geography by choosing Country or region in the Split by
dropdown menu.
3. Analyze conversion, retention, and navigation patterns in your app. From the Application Insights
Overview page, choose User Flows in the table of contents.
The User Flows tool visualizes which events users send after some starting event. It's useful for getting an
overall picture of how users navigate through your app. It can also reveal places where many users are
churning from your app, or repeating the same actions over and over.
In addition to User Flows, Application Insights has several other user behavior analytics tools to answer
specific questions:
Funnels for analyzing and monitoring conversion rates.
Retention for analyzing how well your app retains users over time.
Workbooks for combining visualizations and text into a shareable report.
Cohorts for naming and saving specific groups of users or events so they can be easily referenced from
other analytics tools.
Clean up resources
If you do not want to continue using Application Insights with App Center, turn off export in App Center and
delete the Application Insights resource. This will prevent you from being charged further by Application Insights
for this resource.
To turn off export in App Center:
1. In App Center, go to Settings and choose Export.
2. Click the Application Insights export you want to delete, then click Delete export at the bottom and confirm.
To delete the Application Insights resource:
1. In the left-hand menu of the Azure portal, click Resource groups and then choose the resource group in
which your Application Insights resource was created.
2. Open the Application Insights resource you want to delete. Then click Delete in the top menu of the resource
and confirm. This will permanently delete the copy of the data that was exported to Application Insights.
Next steps
Understand how customers are using your app
Start monitoring your website
With Azure Monitor Application Insights, you can easily monitor your website for availability, performance, and
them. Application Insights provides both server-side monitoring as well as client/browser-side monitoring
capabilities.
This quickstart guides you through adding the open source Application Insights JavaScript SDK which allows you
to understand the client/browser-side experience for visitors to your website.
Prerequisites
You need an Azure Subscription.


Application Insights can gather telemetry data from any internet-connected application, running on-premises or in
the cloud. Use the following steps to start viewing this data.
1. Select Create a resource > Management tools > Application Insights.
NOTE
Application Insights Resource article.
monitoring


2. Click Create.
Create an HTML file

1. On your local computer, create a file called hello_world.html . For this example the file will be placed on the
root of the C: drive at C:\hello_world.html .
2. Copy the script below into hello_world.html :
<!DOCTYPE html>
<html>
<head>
<title>Azure Monitor Application Insights</title>
</head>
<body>
<h1>Azure Monitor Application Insights Hello World!</h1>
<p>You can use the Application Insights JavaScript SDK to perform client/browser-side monitoring of your
website. To learn about more advanced JavaScript SDK configurations visit the <a
href="https://github.com/Microsoft/ApplicationInsights-JS/blob/master/API-reference.md" title="API
Reference">API reference</a>.</p>
</body>
</html>

1. Select Overview > Essentials > Copy your application's Instrumentation Key.
2. Add the following script to your hello_world.html before the closing </head> tag:
var sdkInstance="appInsightsSDK";window[sdkInstance]="appInsights";var
aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){t[e]=function(){var
n=arguments;t.queue.push(function(){t[e].apply(t,n)})}}var t={config:e};t.initialize=!0;var
i=document,a=window;setTimeout(function(){var
n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.getEle
mentsByTagName("script")[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e){}t.queue=
[],t.version=2;for(var r=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("tr
ack"+r.pop());n("startTrackPage"),n("stopTrackPage");var
s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedUserCon
text"),n("flush"),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0=
==e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var
o=a[r];a[r]=function(e,n,i,a,s){var c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]
({message:e,url:n,lineNumber:i,columnNumber:a,error:s}),c},e.autoExceptionInstrumented=!0}return t}(
{
instrumentationKey:"INSTRUMENTATION_KEY"
}
);window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
3. Edit hello_world.html and add your instrumentation key.

4. Open hello_world.html in a local browser session. This will create a single pageview. You can refresh your
browser to generate multiple test page views.
1. You can now reopen the Application Insights Overview page in the Azure portal, where you retrieved your
instrumentation key, to view details about your currently running application. The four default charts on the
overview page are scoped to server-side application data. Since we are instrumenting the client/browser-
side interactions with the JavaScript SDK this particular view doesn't apply unless we also have a server-
side SDK installed.
2. Click on Analytics. This opens Analytics, which provides a rich query language for analyzing all data
collected by Application Insights. To view data related to the client-side browser requests run the following
query:
// average pageView duration by name

let timeGrain=1s;
let dataset=pageViews
// additional filters can be applied here
| where timestamp > ago(15m)
| where client_Type == "Browser" ;
// calculate average pageView duration for all pageViews
dataset
| summarize avg(duration) by bin(timestamp, timeGrain)
| extend pageView='Overall'
// render result in a chart
| render timechart
3. Go back to the Overview page. Click on Browser from under the Investigate header, then select
Performance Here you find metrics related to the performance of your website. There is also a
corresponding view for analyzing failures and exceptions in your website. You can click Samples to drill into
individual transaction details. From here, you can access the end-to-end transaction details experience.
4. To begin exploring the user behavior analytics tools, from the main Application Insights menu select Users
under the Usage header. Since we are testing from a single machine, we will only see data for one user. For
a live website, the distribution of users might look as follows:
5. If we had instrumented a more complex website with multiple pages, another useful tool is User Flows.
With User Flows you can track the pathway visitors takes through the various parts of your website.
To learn more advanced configurations for monitoring websites, check out the JavaScript SDK API reference.
Clean up resources
If you plan to continue on to work with subsequent quickstarts or with the tutorials, do not clean up the resources
created in this quickstart. Otherwise, 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
Find and diagnose performance problems
Collect data from an Azure virtual machine with
Azure Monitor
Azure Monitor can collect data directly from your Azure virtual machines into a Log Analytics workspace for
detailed analysis and correlation. Installing the Log Analytics VM extension for Windows and Linux allows Azure
Monitor to collect data from your Azure VMs. This quickstart shows you how to configure and collect data from
your Azure Linux or Windows VMs using the VM extension with a few easy steps.
This quickstart assumes you have an existing Azure virtual machine. If not you can create a Windows VM or
create a Linux VM following our VM quickstarts.
Sign in to Azure portal

Sign in to the Azure portal at https://portal.azure.com.
Create a workspace
1. In the Azure portal, select All services. In the list of resources, type Log Analytics. As you begin typing,
the list filters based on your input. Select Log Analytics workspaces.
2. Select Create, and then select choices for the following items:
Provide a name for the new Log Analytics workspace, such as DefaultLAWorkspace.
Select a Subscription to link to by selecting from the drop-down list if the default selected is not
appropriate.
For Resource Group, select an existing resource group that contains one or more Azure virtual
machines.
Select the Location your VMs are deployed to. For additional information, see which regions Log
Analytics is available in.
If you are creating a workspace in a new subscription created after April 2, 2018, it will
automatically use the Per GB pricing plan and the option to select a pricing tier will not be available.
If you are creating a workspace for an existing subscription created before April 2, or to subscription
that was tied to an existing EA enrollment, select your preferred pricing tier. For additional
information about the particular tiers, see Log Analytics Pricing Details.
3. After providing the required information on the Log Analytics workspace pane, select OK.
While the information is verified and the workspace is created, you can track its progress under Notifications
from the menu.
Enable the Log Analytics VM Extension

NOTE
As part of the ongoing transition from Microsoft Operations Management Suite to Azure Monitor, the Operations
Management Suite Agent for Windows or Linux will be referred to as the Log Analytics agent for Windows and Log
Analytics agent for Linux.
For Windows and Linux virtual machines already deployed in Azure, you install the Log Analytics agent with the
Log Analytics VM Extension. Using the extension simplifies the installation process and automatically configures
the agent to send data to the Log Analytics workspace that you specify. The agent is also upgraded automatically
when a newer version is released, ensuring that you have the latest features and fixes. Before proceeding, verify
the VM is running otherwise the process will fail to complete successfully.
NOTE
The Log Analytics agent for Linux cannot be configured to report to more than one Log Analytics workspace.
1. In the Azure portal, select All services found in the upper left-hand corner. In the list of resources, type
Log Analytics. As you begin typing, the list filters based on your input. Select Log Analytics
workspaces.
2. In your list of Log Analytics workspaces, select DefaultLAWorkspace created earlier.
3. On the left-hand menu, under Workspace Data Sources, select Virtual machines.
4. In the list of Virtual machines, select a virtual machine you want to install the agent on. Notice that the
Log Analytics connection status for the VM indicates that it is Not connected.
5. In the details for your virtual machine, select Connect. The agent is automatically installed and configured
for your Log Analytics workspace. This process takes a few minutes, during which time the Status shows
Connecting.
6. After you install and connect the agent, the Log Analytics connection status will be updated with This
workspace.
Collect event and performance data

Azure Monitor can collect events from the Windows event logs or Linux Syslog and performance counters that
you specify for longer term analysis and reporting, and take action when a particular condition is detected. Follow
these steps to configure collection of events from the Windows system log and Linux Syslog, and several
common performance counters to start with.
Data collection from Windows VM
1. Select Advanced settings.
2. Select Data, and then select Windows Event Logs.

3. You add an event log by typing in the name of the log. Type System and then select the plus sign +.
4. In the table, check the severities Error and Warning.
5. Select Save at the top of the page to save the configuration.
6. Select Windows Performance Data to enable collection of performance counters on a Windows
computer.
7. When you first configure Windows Performance counters for a new Log Analytics workspace, you are
given the option to quickly create several common counters. They are listed with a checkbox next to each.
Select Add the selected performance counters. They are added and preset with a ten second collection
sample interval.
Data collection from Linux VM
1. Select Syslog.
2. You add an event log by typing in the name of the log. Type Syslog and then select the plus sign +.
3. In the table, deselect the severities Info, Notice and Debug.
5. Select Linux Performance Data to enable collection of performance counters on a Linux computer.
6. When you first configure Linux Performance counters for a new Log Analytics workspace, you are given
the option to quickly create several common counters. They are listed with a checkbox next to each.
Select Apply below configuration to to my machines and then select Add the selected performance
counters. They are added and preset with a ten second collection sample interval.
View data collected

Now that you have enabled data collection, lets run a simple log search example to see some data from the target
VMs.
1. In the selected workspace, from the left-hand pane, select Logs.
2. On the Logs query page, type Perf in the query editor and select Run.
For example, the query in the following image returned 10,000 performance records. Your results will be
significantly less.
Clean up resources
When no longer needed, delete the Log Analytics workspace. To do so, select the Log Analytics workspace you
created earlier and on the resource page select Delete.
Next steps
Now that you are collecting operational and performance data from your Windows or Linux virtual machines,
you can easily begin exploring, analyzing, and taking action on data that you collect for free.
To learn how to view and analyze the data, continue to the tutorial.
View or analyze data in Log Analytics
Quickstart: Collect data from a Linux computer in a
hybrid environment with Azure Monitor
Azure Monitor can collect data directly from your physical or virtual Linux computers in your environment into a
Log Analytics workspace for detailed analysis and correlation. Installing the Log Analytics agent allows Azure
Monitor to collect data from a datacenter or other cloud environment. This quickstart shows you how to
configure and collect data from your Linux server with a few easy steps. For information about Azure Linux VMs,
see Collect data about Azure virtual machines.
To understand the supported configuration, see Supported Windows operating systems and Network firewall
configuration.

Create a workspace
appropriate.
machines.
If you are creating a workspace for an existing subscription created before April 2, or to
subscription that was tied to an existing EA enrollment, select your preferred pricing tier. For
additional information about the particular tiers, see Log Analytics Pricing Details.
from the menu.
Obtain workspace ID and key

Before installing the Log Analytics agent for Linux, you need the workspace ID and key for your Log Analytics
workspace. This information is required by the agent wrapper script to properly configure the agent and ensure it
can successfully communicate with Azure Monitor.
NOTE
Management Suite Agent for Windows or Linux will be referred to as the Log Analytics agent for Windows and Log
Analytics agent for Linux.
1. In the upper-left corner of the Azure portal, select All services. In the search box, enter Log Analytics. As
you type, the list filters based on your input. Select Log Analytics workspaces.
2. In your list of Log Analytics workspaces, select the workspace you created earlier. (You might have named
it DefaultLAWorkspace.)
3. Select Advanced settings:
4. Select Connected Sources, and then select Linux Servers.
5. The value to the right of Workspace ID and Primary Key. Copy and paste both into your favorite editor.
Install the agent for Linux

The following steps configure setup of the agent for Log Analytics in Azure and Azure Government cloud.
NOTE
The Log Analytics agent for Linux cannot be configured to report to more than one Log Analytics workspace.
If your Linux computer needs to communicate through a proxy server to Log Analytics, the proxy configuration
can be specified on the command line by including -p [protocol://][user:password@]proxyhost[:port] . The
proxyhost property accepts a fully qualified domain name or IP address of the proxy server.
For example: https://user01:password@proxy01.contoso.com:30443
1. To configure the Linux computer to connect to a Log Analytics workspace, run the following command
providing the workspace ID and primary key copied earlier. The following command downloads the agent,
validates its checksum, and installs it.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s <YOUR
WORKSPACE PRIMARY KEY>
The following command includes the -p proxy parameter and example syntax.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]
[user:password@]proxyhost[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY>
2. To configure the Linux computer to connect to Log Analytics workspace in Azure Government cloud, run
the following command providing the workspace ID and primary key copied earlier. The following
command downloads the agent, validates its checksum, and installs it.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s <YOUR
WORKSPACE PRIMARY KEY> -d opinsights.azure.us
The following command includes the -p proxy parameter and example syntax.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]
[user:password@]proxyhost[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY> -d
opinsights.azure.us
3. Restart the agent by running the following command:
sudo /opt/microsoft/omsagent/bin/service_control restart [<workspace id>]

Azure Monitor can collect events from the Linux Syslog and performance counters that you specify for longer
term analysis and reporting. It can also take action when it detects a particular condition. Follow these steps to
configure collection of events from the Linux Syslog, and several common performance counters to start with.
1. In the lower-left corner of the Azure portal, select More services. In the search box, enter Log Analytics.
As you type, the list filters based on your input. Select Log Analytics workspaces.
2. Select Data, and then select Syslog.
3. You add syslog by typing in the name of the log. Enter Syslog and then select the plus sign +.
4. In the table, uncheck the severities Info, Notice and Debug.
6. Select Linux Performance Data to enable collection of performance counters on a Linux computer.
7. When you first configure Linux Performance counters for a new Log Analytics workspace, you are given
the option to quickly create several common counters. They are listed with a checkbox next to each.
Select Apply below configuration to to my machines and then select Add the selected
performance counters. They are added and preset with a ten second collection sample interval.
View data collected

Now that you have enabled data collection, lets run a simple log search example to see some data from the target
computer.
For example, the query in the following image returned 10,000 Performance records. Your results will be
significantly less.
Clean up resources
When no longer needed, you can remove the agent from the Linux computer and delete the Log Analytics
workspace.
To remove the agent, run the following command on the Linux computer. The --purge argument completely
removes the agent and its configuration.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
&& sh onboard_agent.sh --purge
To delete the workspace, select the Log Analytics workspace you created earlier and on the resource page select
Delete.
Next steps
Now that you are collecting operational and performance data from your on-premises Linux computer, you can
easily begin exploring, analyzing, and taking action on data that you collect for free.
To learn how to view and analyze the data, continue to the tutorial.
Collect data from a Windows computer in a hybrid
environment with Azure Monitor
Azure Monitor can collect data directly from your your physical or virtual Windows computers in your
environment into a Log Analytics workspace for detailed analysis and correlation. Installing the Log Analytics
agent allows Azure Monitor to collect data from a datacenter or other cloud environment. This quickstart shows
you how to configure and collect data from your Windows computer with a few easy steps. For information about
Azure Windows VMs, see Collect data about Azure virtual machines.
To understand the supported configuration, see Supported Windows operating systems and Network firewall
configuration.

Create a workspace
appropriate.
machines.
If you are creating a workspace in a new subscription created after April 2, 2018, it will automatically
use the Per GB pricing plan and the option to select a pricing tier will not be available. If you are
creating a workspace for an existing subscription created before April 2, or to subscription that was
tied to an existing EA enrollment, select your preferred pricing tier. For additional information about
the particular tiers, see Log Analytics Pricing Details.
from the menu.
Get the workspace ID and key

Before you install the Log Analytics agent for Windows (also referred to as the Microsoft Monitoring Agent
(MMA)), you need the workspace ID and key for your Log Analytics workspace. The setup wizard needs this
information to properly configure the agent and ensure it can communicate with Azure Monitor.
1. In the upper-left corner of the Azure portal, select All services. In the search box, enter Log Analytics. As
you type, the list filters based on your input. Select Log Analytics workspaces.
2. In your list of Log Analytics workspaces, select the workspace you created earlier. (You might have named it
DefaultLAWorkspace.)
4. Select Connected Sources, and then select Windows Servers.
5. Copy the values to the right of Workspace ID and Primary Key. Paste them into your favorite editor.
Install the agent for Windows

The following steps install and configure the agent for Log Analytics in Azure and Azure Government. You'll use
the Microsoft Monitoring Agent Setup program to install the agent on your computer.
1. Continuing from the previous set of steps, on the Windows Servers page, select the Download Windows
Agent version that you want to download. Select the appropriate version for the processor architecture of
your Windows operating system.
2. Run Setup to install the agent on your computer.
3. On the Welcome page, select Next.
4. On the License Terms page, read the license and then select I Agree.
5. On the Destination Folder page, change or keep the default installation folder and then select Next.
6. On the Agent Setup Options page, connect the agent to Azure Log Analytics and then select Next.
7. On the Azure Log Analytics page, complete these steps:
a. Paste in the Workspace ID and Workspace Key (Primary Key) that you copied earlier. If the computer
should report to a Log Analytics workspace in Azure Government, select Azure US Government in the
Azure Cloud list.
b. If the computer needs to communicate through a proxy server to the Log Analytics service, select
Advanced and provide the URL and port number of the proxy server. If your proxy server requires
authentication, enter the user name and password for authentication with the proxy server and then
select Next.
8. Select Next after you've added the configuration settings:
9. On the Ready to Install page, review your choices and then select Install.
10. On the Configuration completed successfully page, select Finish.
When the installation and setup is finished, Microsoft Monitoring Agent appears in Control Panel. You can review
your configuration and verify that the agent is connected to the Log Analytics workspace. When connected, on the
Azure Log Analytics tab, the agent displays this message: The Microsoft Monitoring Agent has successfully
connected to the Microsoft Log Analytics service.
Azure Monitor can collect events that you specify from the Windows event log and performance counters for
longer term analysis and reporting. It can also take action when it detects a particular condition. Follow these steps
to configure collection of events from the Windows event log, and several common performance counters to start
with.
1. In the lower-left corner of the Azure portal, select More services. In the search box, enter Log Analytics.
As you type, the list filters based on your input. Select Log Analytics workspaces.
3. Select Data, and then select Windows Event Logs.

4. You add an event log by entering the name of the log. Enter System, and then select the plus sign (+).
5. In the table, select the Error and Warning severities.
6. Select Save at the top of the page.
7. Select Windows Performance Counters to enable collection of performance counters on a Windows
computer.
8. When you first configure Windows performance counters for a new Log Analytics workspace, you're given
the option to quickly create several common counters. Each option is listed, with a check box next to it:
.
Select Add the selected performance counters. The counters are added and preset with a ten-second
collection sample interval.
9. Select Save at the top of the page.
View collected data

Now that you've enabled data collection, let's run a simple log search to see some data from the target computer.
For example, the query in this image returned 10,000 Performance records. Your results will be significantly
less.
Clean up resources
You can remove the agent from your computer and delete the Log Analytics workspace if you no longer need
them.
To remove the agent, complete these steps:
1. Open Control Panel.
2. Open Programs and Features.
3. In Programs and Features, select Microsoft Monitoring Agent and then select Uninstall.
To delete the Log Analytics workspace you created earlier, select it, and, on the resource page, select Delete:
Next steps
Now that you're collecting operational and performance data from your Windows computer, you can easily begin
exploring, analyzing, and acting on the data you collect, for free.
To learn how to view and analyze the data, continue to the tutorial:
Get started with Log Analytics in Azure Monitor
NOTE
You can work through this exercise in your own environment if you are collecting data from at least one virtual machine. If
not then use our Demo environment, which includes plenty of sample data.
In this tutorial you will learn how to use Log Analytics in the Azure portal to write Azure Monitor log queries. It will
teach you how to:
Use Log Analytics to write a simple query
Understand the schema of your data
Filter, sort, and group results
Apply a time range
Create charts
Save and load queries
Export and share queries
For a tutorial on writing log queries, see Get started with log queries in Azure Monitor.
For more details on log queries, see Overview of log queries in Azure Monitor.
Meet Log Analytics

Log Analytics is a web tool used to write and execute Azure Monitor log queries. Open it by selecting Logs in the
Azure Monitor menu. It starts with a new blank query.
Firewall requirements
To use Log Analytics, your browser requires access to the following addresses. If your browser is accessing the
Azure portal through a firewall, you must enable access to these addresses.
URI IP PORTS
portal.loganalytics.io Dynamic 80,443
api.loganalytics.io Dynamic 80,443
docs.loganalytics.io Dynamic 80,443
Basic queries
Queries can be used to search terms, identify trends, analyze patterns, and provide many other insights based on
your data. Start with a basic query:
Event | search "error"
This query searches the Event table for records that contain the term error in any property.
Queries can start with either a table name or a search command. The above example starts with the table name
Event, which retrieves all records from the Event table. The pipe (|) character separates commands, so the output of
the first one serves as the input of the following command. You can add any number of commands to a single
query.
Another way to write that same query would be:
search in (Event) "error"
In this example, search is scoped to the Event table, and all records in that table are searched for the term error.
Running a query
Run a query by clicking the Run button or pressing Shift+Enter. Consider the following details which determine
the code that will be run and the data that's returned:
Line breaks: A single break makes your query easier to read. Multiple line breaks split it into separate queries.
Cursor: Place your cursor somewhere inside the query to execute it. The current query is considered to be the
code up until a blank line is found.
Time range - A time range of last 24 hours is set by default. To use a different range, use the time-picker or add
an explicit time range filter to your query.
Understand the schema

The schema is a collection of tables visually grouped under a logical category. Several of the categories are from
monitoring solutions. The LogManagement category contains common data such as Windows and Syslog events,
performance data, and agent heartbeats.
In each table, data is organized in columns with different data types as indicated by icons next to the column name.
For example, the Event table shown in the screenshot contains columns such as Computer which is text,
EventCategory which is a number, and TimeGenerated which is date/time.
Filter the results

Start by getting everything in the Event table.
Event
Log Analytics automatically scopes results by:

Time range: By default, queries are limited to the last 24 hours.
Number of results: Results are limited to maximum of 10,000 records.
This query is very general, and it returns too many results to be useful. You can filter the results either through the
table elements, or by explicitly adding a filter to the query. Filtering results through the table elements applies to the
existing result set, while a filter to the query itself will return a new filtered result set and could therefore produce
more accurate results.
Add a filter to the query
There is an arrow to the left of each record. Click this arrow to open the details for a specific record.
Hover above a column name for the "+" and "-" icons to display. To add a filter that will return only records with the
same value, click the "+" sign. Click "-" to exclude records with this value and then click Run to run the query again.
Filter through the table elements
Now let's focus on events with a severity of Error. This is specified in a column named EventLevelName. You'll need
to scroll to the right to see this column.
Click the Filter icon next to the column title, and in the pop-up window select values that Starts with the text error:
Sort and group results

The results are now narrowed down to include only error events from SQL Server, created in the last 24 hours.
However, the results are not sorted in any way. To sort the results by a specific column, such as timestamp for
example, click the column title. One click sorts in ascending order while a second click will sort in descending.
Another way to organize results is by groups. To group results by a specific column, simply drag the column header
above the other columns. To create subgroups, drag other columns the upper bar as well.
Select columns to display

The results table often includes a lot of columns. You might find that some of the returned columns are not
displayed by default, or you may want to remove some the columns that are displayed. To select the columns to
show, click the Columns button:
Select a time range
By default, Log Analytics applies the last 24 hours time range. To use a different range, select another value through
the time picker and click Run. In addition to the preset values, you can use the Custom time range option to select
an absolute range for your query.
When selecting a custom time range, the selected values are in UTC, which could be different than your local time
zone.
If the query explicitly contains a filter for TimeGenerated, the time picker title will show Set in query. Manual
selection will be disabled to prevent a conflict.
Charts
In addition to returning results in a table, query results can be presented in visual formats. Use the following query
as an example:
Event
| where EventLevelName == "Error"
| where TimeGenerated > ago(1d)
| summarize count() by Source
By default, results are displayed in a table. Click Chart to see the results in a graphic view:
The results are shown in a stacked bar chart. Click Stacked Column and select Pie to show another view of the
results:
Different properties of the view, such as x and y axes, or grouping and splitting preferences, can be changed
manually from the control bar.
You can also set the preferred view in the query itself, using the render operator.
Smart diagnostics
On a timechart, if there is a sudden spike or step in your data, you may see a highlighted point on the line. This
indicates that Smart Diagnostics has identified a combination of properties that filter out the sudden change. Click
the point to get more detail on the filter, and to see the filtered version. This may help you identify what caused the
change:
Pin to dashboard
To pin a diagram or table to one of your shared Azure dashboards, click the pin icon. Note that this icon has moved
to the top of the Log Analytics window, different from the screenshot below.
Certain simplifications are applied to a chart when you pin it to a dashboard:

Table columns and rows: In order to pin a table to the dashboard, it must have four or fewer columns. Only the
top seven rows are displayed.
Time restriction: Queries are automatically limited to the past 14 days.
Bin count restriction: If you display a chart that has a lot of discrete bins, less populated bins are automatically
grouped into a single others bin.
Save queries
Once you've created a useful query, you might want to save it or share with others. The Save icon is on the top bar.
You can save either the entire query page, or a single query as a function. Functions are queries that can also be
referenced by other queries. In order to save a query as a function, you must provide a function alias, which is the
name used to call this query when referenced by other queries.
NOTE
The following characters are supported - a–z, A–Z, 0-9, -, _, ., <space>, (, ), | in the Name field when saving or
editing the saved query.
Log Analytics queries are always saved to a selected workspace, and shared with other users of that workspace.
Load queries
The Query Explorer icon is at the top-right area. This lists all saved queries by category. It also enables you to mark
specific queries as Favorites to quickly find them in the future. Double-click a saved query to add it to the current
window.
Export and share as link

Log Analytics supports several exporting methods:
Excel: Save the results as a CSV file.
Power BI: Export the results to Power BI. See Import Azure Monitor log data into Power BI for details.
Share a link: The query itself can be shared as a link which can then be sent and executed by other users that
have access to the same workspace.
Next steps
Learn more about writing Azure Monitor log queries.
Get started with log queries in Azure Monitor
NOTE
You should complete Get started with Azure Monitor Log Analytics before completing this tutorial.
NOTE
You can work through this exercise in your own environment if you are collecting data from at least one virtual machine. If
not then use our Demo environment, which includes plenty of sample data.
In this tutorial you will learn to write log queries in Azure Monitor. It will teach you how to:
Understand query structure
Sort query results
Filter query results
Specify a time range
Select which fields to include in the results
Define and use custom fields
Aggregate and group results
For a tutorial on using Log Analytics in the Azure portal, see Get started with Azure Monitor Log Analytics.
For more details on log queries in Azure Monitor, see Overview of log queries in Azure Monitor.
Writing a new query

Queries can start with either a table name or the search command. You should start with a table name, since it
defines a clear scope for the query and improves both query performance and relevance of the results.
NOTE
The Kusto query language used by Azure Monitor is case-sensitive. Language keywords are typically written in lower-case.
When using names of tables or columns in a query, make sure to use the correct case, as shown on the schema pane.
Table -based queries

Azure Monitor organizes log data in tables, each composed of multiple columns. All tables and columns are shown
on the schema pane in Log Analytics in the Analytics portal. Identify a table that you're interested in and then take a
look at a bit of data:
SecurityEvent
| take 10
The query shown above returns 10 results from the SecurityEvent table, in no specific order. This is a very common
way to take a glance at a table and understand its structure and content. Let's examine how it's built:
The query starts with the table name SecurityEvent - this part defines the scope of the query.
The pipe (|) character separates commands, so the output of the first one in the input of the following command.
You can add any number of piped elements.
Following the pipe is the take command, which returns a specific number of arbitrary records from the table.
We could actually run the query even without adding | take 10 - that would still be valid, but it could return up to
10,000 results.
Search queries
Search queries are less structured, and generally more suited for finding records that include a specific value in any
of their columns:
search in (SecurityEvent) "Cryptographic"

| take 10
This query searches the SecurityEvent table for records that contain the phrase "Cryptographic". Of those records,
10 records will be returned and displayed. If we omit the in (SecurityEvent) part and just run
search "Cryptographic" , the search will go over all tables, which would take longer and be less efficient.
WARNING
Search queries are typically slower than table-based queries because they have to process more data.
Sort and top

While take is useful to get a few records, the results are selected and displayed in no particular order. To get an
ordered view, you could sort by the preferred column:
SecurityEvent
| sort by TimeGenerated desc
That could return too many results though and might also take some time. The above query sorts the entire
SecurityEvent table by the TimeGenerated column. The Analytics portal then limits the display to show only 10,000
records. This approach is of course not optimal.
The best way to get only the latest 10 records is to use top, which sorts the entire table on the server side and then
returns the top records:
SecurityEvent
| top 10 by TimeGenerated
Descending is the default sorting order, so we typically omit the desc argument.The output will look like this:
Where: filtering on a condition
Filters, as indicated by their name, filter the data by a specific condition. This is the most common way to limit
query results to relevant information.
To add a filter to a query, use the where operator followed by one or more conditions. For example, the following
query returns only SecurityEvent records where Level equals 8:
SecurityEvent
| where Level == 8
When writing filter conditions, you can use the following expressions:
EXPRESSION DESCRIPTION EXAMPLE
== Check equality Level == 8

(case-sensitive)
=~ Check equality EventSourceName =~ "microsoft-

(case-insensitive) windows-security-auditing"
!=, <> Check inequality Level != 4

(both expressions are identical)
and, or Required between conditions Level == 16 or CommandLine != ""
To filter by multiple conditions, you can either use and:
SecurityEvent
| where Level == 8 and EventID == 4672
or pipe multiple where elements one after the other:
SecurityEvent
| where Level == 8
| where EventID == 4672
NOTE
Values can have different types, so you might need to cast them to perform comparison on the correct type. For example,
SecurityEvent Level column is of type String, so you must cast it to a numerical type such as int or long, before you can use
numerical operators on it: SecurityEvent | where toint(Level) >= 10

Time picker
The time picker is next to the Run button and indicates we’re querying only records from the last 24 hours. This is
the default time range applied to all queries. To get only records from the last hour, select Last hour and run the
query again.
Time filter in query

You can also define your own time range by adding a time filter to the query. It’s best to place the time filter
immediately after the table name:
SecurityEvent
| where TimeGenerated > ago(30m)
| where toint(Level) >= 10
In the above time filter ago(30m) means "30 minutes ago" so this query only returns records from the last 30
minutes. Other units of time include days (2d), minutes (25m), and seconds (10s).
Project and Extend: select and compute columns

Use project to select specific columns to include in the results:
SecurityEvent
| project TimeGenerated, Computer, Activity
The preceding example generates this output:

You can also use project to rename columns and define new ones. The following example uses project to do the
following:
Select only the Computer and TimeGenerated original columns.
Rename the Activity column to EventDetails.
Create a new column named EventCode. The substring() function is used to get only the first four characters
from the Activity field.
SecurityEvent
| project Computer, TimeGenerated, EventDetails=Activity, EventCode=substring(Activity, 0, 4)
extend keeps all original columns in the result set and defines additional ones. The following query uses extend to
add the EventCode column. Note that this column may not display at the end of the table results in which case you
would need to expand the details of a record to view it.
SecurityEvent
| extend EventCode=substring(Activity, 0, 4)
Summarize: aggregate groups of rows

Use summarize to identify groups of records, according to one or more columns, and apply aggregations to them.
The most common use of summarize is count, which returns the number of results in each group.
The following query reviews all Perf records from the last hour, groups them by ObjectName, and counts the
records in each group:
Perf
| where TimeGenerated > ago(1h)
| summarize count() by ObjectName
Sometimes it makes sense to define groups by multiple dimensions. Each unique combination of these values
defines a separate group:
Perf
| summarize count() by ObjectName, CounterName
Another common use is to perform mathematical or statistical calculations on each group. For example, the
following calculates the average CounterValue for each computer:
Perf
| summarize avg(CounterValue) by Computer
Unfortunately, the results of this query are meaningless since we mixed together different performance counters.
To make this more meaningful, we should calculate the average separately for each combination of CounterName
and Computer:
Perf
| summarize avg(CounterValue) by Computer, CounterName
Summarize by a time column

Grouping results can also be based on a time column, or another continuous value. Simply summarizing
by TimeGenerated though would create groups for every single millisecond over the time range, since these are
unique values.
To create groups based on continuous values, it is best to break the range into manageable units using bin. The
following query analyzes Perf records that measure free memory ( Available MBytes) on a specific computer. It
calculates the average value of each 1 hour period over the last 7 days:
Perf
| where Computer == "ContosoAzADDS2"
| where CounterName == "Available MBytes"
| summarize avg(CounterValue) by bin(TimeGenerated, 1h)
To make the output clearer, you select to display it as a time-chart, showing the available memory over time:
Next steps
Learn about writing search queries
Create and share dashboards of Log Analytics data
Log Analytics dashboards can visualize all of your saved log queries, giving you the ability to find, correlate, and
share IT operational data in the organization. This tutorial covers creating a log query that will be used to support
a shared dashboard that will be accessed by your IT operations support team. You learn how to:
Create a shared dashboard in the Azure portal
Visualize a performance log query
Add a log query to a shared dashboard
Customize a tile in a shared dashboard
To complete the example in this tutorial, you must have an existing virtual machine connected to the Log Analytics
workspace.

Create a shared dashboard

Select Dashboard to open your default dashboard. Your dashboard will look different than the example below.
Here you can bring together operational data that is most important to IT across all your Azure resources,
including telemetry from Azure Log Analytics. Before we step into visualizing a log query, let's first create a
dashboard and share it. We can then focus on our example performance log query, which will render as a line
chart, and add it to the dashboard.
To create a dashboard, select the New dashboard button next to the current dashboard's name.
This action creates a new, empty, private dashboard and puts you into customization mode where you can name
your dashboard and add or rearrange tiles. Edit the name of the dashboard and specify Sample Dashboard for
this tutorial, and then select Done customizing.
When you create a dashboard, it is private by default, which means you are the only person who can see it. To
make it visible to others, use the Share button that appears alongside the other dashboard commands.
You are asked to choose a subscription and resource group for your dashboard to be published to. For
convenience, the portal's publishing experience guides you towards a pattern where you place dashboards in a
resource group called dashboards. Verify the subscription selected and then click Publish. Access to the
information displayed in the dashboard is controlled with Azure Resource Based Access Control.
Visualize a log query

Log Analytics is a dedicated portal used to work with log queries and their results. Features include the ability to
edit a query on multiple lines, selectively execute code, context sensitive Intellisense, and Smart Analytics. In this
tutorial, you will use Log Analytics to create a performance view in graphical form, save it for a future query, and
pin it to the shared dashboard created earlier.
Open Log Analytics by selecting Logs in the Azure Monitor menu. It starts with a new blank query.
Enter the following query to return processor utilization records for both Windows and Linux computers, grouped
by Computer and TimeGenerated, and displayed in a visual chart. Click Run to run the query and view the
resulting chart.
Perf
| where CounterName == "% Processor Time" and ObjectName == "Processor" and InstanceName == "_Total"
| summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1hr), Computer
| render timechart
Save the query by selecting the Save button from the top of the page.
In the Save Query control panel, provide a name such as Azure VMs - Processor Utilization and a category such
as Dashboards and then click Save. This way you can create a library of common queries that you can use and
modify. Finally, pin this to the shared dashboard created earlier by selecting the Pin to dashboard button from
the top right corner of the page and then selecting the dashboard name.
Now that we have a query pinned to the dashboard, you will notice it has a generic title and comment below it.
We should rename it to something meaningful that can be easily understood by those viewing it. Click the edit
button to customize the title and subtitle for the tile, and then click Update. A banner will appear asking you to
publish changes or discard. Click Save a copy.
Next steps
In this tutorial, you learned how to create a dashboard in the Azure portal and add a log query to it. Advance to
the next tutorial to learn the different responses you can implement based on log query results.
Respond to events with Log Analytics Alerts
Respond to events with Azure Monitor Alerts
Alerts in Azure Monitor can identify important information in your Log Analytics repository. They are created by
alert rules that automatically run log searches at regular intervals, and if results of the log search match particular
criteria, then an alert record is created and it can be configured to perform an automated response. This tutorial is
a continuation of the Create and share dashboards of Log Analytics data tutorial.
In this tutorial, you learn how to:
Create an alert rule
Configure an Action Group to send an e-mail notification
To complete the example in this tutorial, you must have an existing virtual machine connected to the Log Analytics
workspace.

Create alerts
Alerts are created by alert rules in Azure Monitor and can automatically run saved queries or custom log searches
at regular intervals. You can create alerts based on specific performance metrics or when certain events are
created, absence of an event, or a number of events are created within a particular time window. For example,
alerts can be used to notify you when average CPU usage exceeds a certain threshold, when a missing update is
detected, or when an event is generated upon detecting that a specific Windows service or Linux daemon is not
running. If the results of the log search match particular criteria, then an alert is created. The rule can then
automatically run one or more actions, such as notify you of the alert or invoke another process.
In the following example, you create a metric measurement alert rule based off of the Azure VMs - Processor
Utilization query saved in the Visualize data tutorial. An alert is created for each virtual machine that exceeds a
threshold of 90%.
1. In the Azure portal, click All services. In the list of resources, type Log Analytics. As you begin typing, the
list filters based on your input. Select Log Analytics.
2. In the left-hand pane, select Alerts and then click New Alert Rule from the top of the page to create a new
alert.
3. For the first step, under the Create Alert section, you are going to select your Log Analytics workspace as
the resource, since this is a log based alert signal. Filter the results by choosing the specific Subscription
from the drop-down list if you have more than one, which contains the VM and Log Analytics workspace
created earlier. Filter the Resource Type by selecting Log Analytics from the drop-down list. Finally, select
the Resource DefaultLAWorkspace and then click Done.
4. Under the section Alert Criteria, click Add Criteria to select our saved query and then specify logic that
the alert rule follows. From the Configure signal logic pane, select Azure VMs - Processor Utilization from
the list. The pane updates to present the configuration settings for the alert. On the top, it shows the results
for the last 30 minutes of the selected signal and the search query itself.
5. Configure the alert with the following information:
a. From the Based on drop-down list, select Metric measurement. A metric measurement will create an
alert for each object in the query with a value that exceeds our specified threshold.
b. For the Condition, select Greater than and enter 90 for Threshold.
c. Under Trigger Alert Based On section, select Consecutive breaches and from the drop-down list select
Greater than enter a value of 3.
d. Under Evaluation based on section, modify the Period value to 30 minutes. The rule will run every five
minutes and return records that were created within the last thirty minutes from the current time. Setting
the time period to a wider window accounts for the potential of data latency, and ensures the query returns
data to avoid a false negative where the alert never fires.
6. Click Done to complete the alert rule.
7. Now moving onto the second step, provide a name of your alert in the Alert rule name field, such as
Percentage CPU greater than 90 percent. Specify a Description detailing specifics for the alert, and
select Critical(Sev 0) for the Severity value from the options provided.
8. To immediately activate the alert rule on creation, accept the default value for Enable rule upon creation.
9. For the third and final step, you specify an Action Group, which ensures that the same actions are taken
each time an alert is triggered and can be used for each rule you define. Configure a new action group with
the following information:
a. Select New action group and the Add action group pane appears.
b. For Action group name, specify a name such as IT Operations - Notify and a Short name such as
itops-n.
c. Verify the default values for Subscription and Resource group are correct. If not, select the correct one
from the drop-down list.
d. Under the Actions section, specify a name for the action, such as Send Email and under Action Type
select Email/SMS/Push/Voice from the drop-down list. The Email/SMS/Push/Voice properties pane
will open to the right in order to provide additional information.
e. On the Email/SMS/Push/Voice pane, enable Email and provide a valid email SMTP address to deliver
the message to.
f. Click OK to save your changes.
10. Click OK to complete the action group.

11. Click Create alert rule to complete the alert rule. It starts running immediately.
View your alerts in Azure portal
Now that you have created an alert, you can view Azure alerts in a single pane and manage all alert rules across
your Azure subscriptions. It lists all the alert rules (enabled or disabled) and can be sorted based on target
resources, resource groups, rule name, or status. Included is an aggregated summary of all the fired alerts, and
total configured/enabled alert rules.
When the alert triggers, the table reflects the condition and how many times it occurred within the time range
selected (the default is last six hours). There should be a corresponding email in your inbox similar to the following
example showing the offending virtual machine and the top results that matched the search query in this case.
Next steps
In this tutorial, you learned how alert rules can proactively identify and respond to an issue when they run log
searches at scheduled intervals and match a particular criteria.
Follow this link to see pre-built Log Analytics script samples.
Log Analytics script samples
Find and diagnose run-time exceptions with Azure
Azure Application Insights collects telemetry from your application to help identify and diagnose run-time
exceptions. This tutorial takes you through this process with your application. You learn how to:
Modify your project to enable exception tracking
Identify exceptions for different components of your application
View details of an exception
Download a snapshot of the exception to Visual Studio for debugging
Analyze details of failed requests using query language
Create a new work item to correct the faulty code
Prerequisites
To complete this tutorial:
Azure development
Download and install the Visual Studio Snapshot Debugger.
Enable Visual Studio Snapshot Debugger
Deploy a .NET application to Azure and enable the Application Insights SDK.
The tutorial tracks the identification of an exception in your application, so modify your code in your
development or test environment to generate an exception.
Log in to Azure
Log in to the Azure portal at https://portal.azure.com.
Analyze failures
Application Insights collects any failures in your application and lets you view their frequency across different
operations to help you focus your efforts on those with the highest impact. You can then drill down on details of
these failures to identify root cause.
1. Select Application Insights and then your subscription.
2. To open the Failures panel either select Failures under the Investigate menu or click the Failed requests
graph.
3. The Failed requests panel shows the count of failed requests and the number of users affected for each
operation for the application. By sorting this information by user you can identify those failures that most
impact users. In this example, the GET Employees/Create and GET Customers/Details are likely
candidates to investigate because of their large number of failures and impacted users. Selecting an
operation shows further information about this operation in the right panel.
4. Reduce the time window to zoom in on the period where the failure rate shows a spike.
5. See the related samples by clicking on the button with the number of filtered results. The "suggested"
samples have related telemetry from all components, even if sampling may have been in effect in any of
them. Click on a search result to see the details of the failure.
6. The details of the failed request shows the Gantt chart which shows that there were two dependency
failures in this transaction, which also attributed to over 50% of the total duration of the transaction. This
experience presents all telemetry, across components of a distributed application that are related to this
operation ID. Learn more about the new experience. You can select any of the items to see its details on the
right side.
7. The operations detail also shows a FormatException which appears to have caused the failure. You can see
that it's due to an invalid zip code. You can open the debug snapshot to see code level debug information in
Visual Studio.
Identify failing code

The Snapshot Debugger collects snapshots of the most frequent exceptions in your application to assist you in
diagnosing its root cause in production. You can view debug snapshots in the portal to see the call stack and
inspect variables at each call stack frame. Afterwards, you have the option to debug the source code by
downloading the snapshot and opening it in Visual Studio 2019 Enterprise.
1. In the properties of the exception, click Open debug snapshot.
2. The Debug Snapshot panel opens with the call stack for the request. Click any method to view the values
of all local variables at the time of the request. Starting from the top method in this example, we can see
local variables that have no value.
3. The first call that has valid values is ValidZipCode, and we can see that a zip code was provided with letters
that isn't able to be translated into an integer. This appears to be the error in the code that needs to be
corrected.
4. You then have the option to download this snapshot into Visual Studio where we can locate the actual code
that needs to be corrected. To do so, click Download Snapshot.
5. The snapshot is loaded into Visual Studio.
6. You can now run a debug session in Visual Studio Enterprise that quickly identifies the line of code that
caused the exception.
Use analytics data
All data collected by Application Insights is stored in Azure Log Analytics, which provides a rich query language
that allows you to analyze the data in a variety of ways. We can use this data to analyze the requests that generated
the exception we're researching.
1. Click the CodeLens information above the code to view telemetry provided by Application Insights.
2. Click Analyze impact to open Application Insights Analytics. It's populated with several queries that
provide details on failed requests such as impacted users, browsers, and regions.
Add work item
If you connect Application Insights to a tracking system such as Azure DevOps or GitHub, you can create a work
item directly from Application Insights.
1. Return to the Exception Properties panel in Application Insights.
2. Click New Work Item.
3. The New Work Item panel opens with details about the exception already populated. You can add any
additional information before saving it.
Next steps
Now that you've learned how to identify run-time exceptions, advance to the next tutorial to learn how to identify
and diagnose performance issues.
Identify performance issues
Find and diagnose performance issues with Azure
Azure Application Insights collects telemetry from your application to help analyze its operation and performance.
You can use this information to identify problems that may be occurring or to identify improvements to the
application that would most impact users. This tutorial takes you through the process of analyzing the
performance of both the server components of your application and the perspective of the client. You learn how to:
Identify the performance of server-side operations
Analyze server operations to determine the root cause of slow performance
Identify slowest client-side operations
Analyze details of page views using query language
Prerequisites
Azure development
Enable the Application Insights profiler for your application.
Log in to Azure
Identify slow server operations

Application Insights collects performance details for the different operations in your application. By identifying
those operations with the longest duration, you can diagnose potential problems or best target your ongoing
development to improve the overall performance of the application.
1. Select Application Insights and then select your subscription.
2. To open the Performance panel either select Performance under the Investigate menu or click the
Server Response Time graph.
3. The Performance panel shows the count and average duration of each operation for the application. You
can use this information to identify those operations that most impact users. In this example, the GET
Customers/Details and GET Home/Index are likely candidates to investigate because of their relatively
high duration and number of calls. Other operations may have a higher duration but were rarely called, so
the effect of their improvement would be minimal.
4. The graph currently shows the average duration of the selected operations over time. You can switch to the
95th percentile to find the performance issues. Add the operations that you're interested in by pinning them
to the graph. This shows that there are some peaks worth investigating. Isolate this further by reducing the
time window of the graph.
5. The performance panel on the right shows distribution of durations for different requests for the selected
operation. Reduce the window to start around the 95th percentile. The "Top 3 dependencies" insights card,
can tell you at a glance that the external dependencies are likely contributing to the slow transactions. Click
on the button with number of samples to see a list of the samples. You can then select any sample to see
transaction details.
6. You can see at a glance that the call to Fabrikamaccount Azure Table is contributing most to the total
duration of the transaction. You can also see that an exception caused it to fail. You can click on any item in
the list to see its details on the right side. Learn more about the transaction diagnostics experience
7. The Profiler helps get further with code level diagnostics by showing the actual code that ran for the
operation and the time required for each step. Some operations may not have a trace since the profiler runs
periodically. Over time, more operations should have traces. To start the profiler for the operation, click
Profiler traces.
8. The trace shows the individual events for each operation so you can diagnose the root cause for the
duration of the overall operation. Click one of the top examples, which have the longest duration.
9. Click Hot Path to highlight the specific path of events that most contribute to the total duration of the
operation. In this example, you can see that the slowest call is from
FabrikamFiberAzureStorage.GetStorageTableData method. The part that takes most time is the
CloudTable.CreateIfNotExist method. If this line of code is executed every time the function gets called,
unnecessary network call and CPU resource will be consumed. The best way to fix your code is to put this
line in some startup method that only executes once.
10. The Performance Tip at the top of the screen supports the assessment that the excessive duration is due
to waiting. Click the waiting link for documentation on interpreting the different types of events.
11. For further analysis, you can click Download Trace to download the trace in to Visual Studio.
Use logs data for server

Logs provides a rich query language that allows you to analyze all data collected by Application Insights. You can
use this to perform deep analysis on request and performance data.
1. Return to the operation detail panel and click View in Logs (Analytics)
2. Logs opens with a query for each of the views in the panel. You can run these queries as they are or modify
them for your requirements. The first query shows the duration for this operation over time.
Identify slow client operations
In addition to identifying server processes to optimize, Application Insights can analyze the perspective of client
browsers. This can help you identify potential improvements to client components and even identify issues with
different browsers or different locations.
1. Select Browser under Investigate then click Browser Performance or select Performance under
Investigate and switch to the Browser tab by clicking the server/browser toggle button in the top right to
open the browser performance summary. This provides a visual summary of various telemetries of your
application from the perspective of the browser.
2. Select on one of the operation names then click the blue samples button in the bottom right and select an
operation. This will bring up the end-to-end transaction details and on the right side you can view the Page
View Properties. This allows you to view details of the client requesting the page including the type of
browser and its location. This information can assist you in determining whether there are performance
issues related to particular types of clients.
Use logs data for client
Like the data collected for server performance, Application Insights makes all client data available for deep
analysis using Logs.
1. Return to the browser summary and click View in Logs (Analytics)
2. Logs opens with a query for each of the views in the panel. The first query shows the duration for different
page views over time.
3. Smart Diagnostics is a feature of Logs identifies unique patterns in the data. When you click the Smart
Diagnostics dot in the line chart, the same query is run without the records that caused the anomaly. Details
of those records are shown in the comment section of the query so you can identify the properties of those
page views that are causing the excessive duration.
Next steps
Now that you've learned how to identify run-time exceptions, advance to the next tutorial to learn how to create
alerts in response to failures.
Alert on application health
Monitor and alert on application health with Azure
Azure Application Insights allows you to monitor your application and send you alerts when it is either unavailable,
experiencing failures, or suffering from performance issues. This tutorial takes you through the process of creating
tests to continuously check the availability of your application.
You learn how to:
Create availability test to continuously check the response of the application
Send mail to administrators when a problem occurs
Prerequisites
Create an Application Insights resource.
Sign in to Azure
Create availability test

Availability tests in Application Insights allow you to automatically test your application from various locations
around the world. In this tutorial, you will perform a url test to ensure that your web application is available. You
could also create a complete walkthrough to test its detailed operation.
2. Select Availability under the Investigate menu and then click Create test.
3. Type in a name for the test and leave the other defaults. This selection will trigger requests for the
application url every 5 minutes from five different geographic locations.
4. Select Alerts to open the Alerts dropdown where you can define details for how to respond if the test fails.
Choose Near-realtime and set the status to Enabled.
Type in an email address to send when the alert criteria is met. You could optionally type in the address of a
webhook to call when the alert criteria is met.
5. Return to the test panel, select the ellipses and edit alert to enter the configuration for your near-realtime
alert.
6. Set failed locations to greater than or equal to 3. Create an action group to configure who gets notified
when your alert threshold is breached.
7. Once you have configured your alert, click on the test name to view details from each location. Tests can be
viewed in both line graph and scatter plot format to visualize the success/failures for a given time range.
8. You can drill down into the details of any test by clicking on its dot in the scatter chart. This will launch the
end-to-end transaction details view. The example below shows the details for a failed request.
Next steps
Now that you've learned how to alert on issues, advance to the next tutorial to learn how to analyze how users are
interacting with your application.
Understand users
Use Azure Application Insights to understand how
customers are using your application
Azure Application Insights collects usage information to help you understand how your users interact with your
application. This tutorial walks you through the different resources that are available to analyze this information.
You will learn how to:
Analyze details about users accessing your application
Use session information to analyze how customers use your application
Define funnels that let you compare your desired user activity to their actual activity
Create a workbook to consolidate visualizations and queries into a single document
Group similar users to analyze them together
Learn which users are returning to your application
Inspect how users navigate through your application
Prerequisites
Azure development
Download and install the Visual Studio Snapshot Debugger.
Send telemetry from your application for adding custom events/page views
Send user context to track what a user does over time and fully utilize the usage features.
Log in to Azure
Get information about your users

The Users panel allows you to understand important details about your users in a variety of ways. You can use this
panel to understand such information as where your users are connecting from, details of their client, and what
areas of your application they're accessing.
2. Select Users in the menu.
3. The default view shows the number of unique users that have connected to your application over the past
24 hours. You can change the time window and set various other criteria to filter this information.
4. Click the During dropdown and change the time window to 7 days. This increases the data included in the
different charts in the panel.
5. Click the Split by dropdown to add a breakdown by a user property to the graph. Select Country or
region. The graph includes the same data but allows you to view a breakdown of the number of users for
each country/region.
6. Position the cursor over different bars in the chart and note that the count for each country/region reflects
only the time window represented by that bar.
7. Have a look at the Insights column at the right that perform analysis on your user data. This provides
information such as the number of unique sessions over the time period and records with common
properties that make up significant of the user data
Analyze user sessions
The Sessions panel is similar to the Users panel. Where Users helps you understand details about the users
accessing your application, Sessions helps you understand how those users used your application.
1. Select Sessions in the menu.
2. Have a look at the graph and note that you have the same options to filter and break down the data as in
the Users panel.
3. The Sample of these sessions pane on the right lists sessions that include a large number of events. These
are interesting sessions to analyze.
4. Click on one of the sessions to view its Session Timeline, which shows every action in the sessions. This
can help you identify information such as the sessions with a large number of exceptions.
Group together similar users

A Cohort is a set of users grouped on similar characteristics. You can use cohorts to filter data in other panels
allowing you to analyze particular groups of users. For example, you might want to analyze only users who
completed a purchase.
1. Select Cohorts in the menu.
2. Click New to create a new cohort.
3. Select the Who used dropdown and select an action. Only users who performed this action within the time
window of the report will be included.
4. Select Users in the menu.

5. In the Show dropdown, select the cohort you just created. The data for the graph is limited to those users.
Compare desired activity to reality

While the previous panels are focused on what users of your application did, Funnels focus on what you want
users to do. A funnel represents a set of steps in your application and the percentage of users who move between
steps. For example, you could create a funnel that measures the percentage of users who connect to your
application who search product. You can then see the percentage of users who add that product to a shopping cart,
and then the percentage of those who complete a purchase.
1. Select Funnels in the menu and then click New.
2. Type in a Funnel Name.
3. Create a funnel with at least two steps by selecting an action for each step. The list of actions is built from
usage data collected by Application Insights.
4. Click Save to save the funnel and then view its results. The window to the right of the funnel shows the
most common events before the first activity and after the last activity to help you understand user
tendencies around the particular sequence.
Learn which customers return
Retention helps you understand which users are coming back to your application.
1. Select Retention in the menu.
2. By default, the analyzed information includes users who performed any action and then returned to perform
any action. You can change this filter to any include, for example, only those users who returned after
completing a purchase.
3. The returning users that match the criteria are shown in graphical and table form for different time
durations. The typical pattern is for a gradual drop in returning users over time. A sudden drop from one
time period to the next might raise a concern.
Analyze user navigation
A User flow visualizes how users navigate between the pages and features of your application. This helps you
answer questions such as where users typically move from a particular page, how they typically exit your
application, and if there are any actions that are regularly repeated.
1. Select User flows in the menu.
2. Click New to create a new user flow and then click Edit to edit its details.
3. Increase the Time Range to 7 days and then select an initial event. The flow will track user sessions that
start with that event.
4. The user flow is displayed, and you can see the different user paths and their session counts. Blue lines
indicate an action that the user performed after the current action. A red line indicates the end of the user
session.
5. To remove an event from the flow, click the x in the corner of the action and then click Create Graph. The
graph is redrawn with any instances of that event removed. Click Edit to see that the event is now added to
Excluded events.
Consolidate usage data

Workbooks combine data visualizations, Analytics queries, and text into interactive documents. You can use
workbooks to group together common usage information, consolidate information from a particular incident, or
report back to your team on your application's usage.
1. Select Workbooks in the menu.
2. Click New to create a new workbook.
3. A query is already provided that includes all usage data in the last day displayed as a bar chart. You can use
this query, manually edit it, or click Sample queries to select from other useful queries.
4. Click Done editing.
5. Click Edit in the top pane to edit the text at the top of the workbook. This is formatted using markdown.
6. Click Add users to add a graph with user information. Edit the details of the graph if you want and then
click Done editing to save it.
Next steps
Now that you've learned how to analyze your users, advance to the next tutorial to learn how to create custom
dashboards that combine this information with other useful data about your application.
Create custom dashboards
Create custom KPI dashboards using Azure
You can create multiple dashboards in the Azure portal that each include tiles visualizing data from multiple Azure
resources across different resource groups and subscriptions. You can pin different charts and views from Azure
Application Insights to create custom dashboards that provide you with complete picture of the health and
performance of your application. This tutorial walks you through the creation of a custom dashboard that includes
multiple types of data and visualizations from Azure Application Insights. You learn how to:
Create a custom dashboard in Azure
Add a tile from the Tile Gallery
Add standard metrics in Application Insights to the dashboard
Add a custom metric chart Application Insights to the dashboard
Add the results of a Logs (Analytics) query to the dashboard
Prerequisites
Sign in to Azure
Create a new dashboard

A single dashboard can contain resources from multiple applications, resource groups, and subscriptions. Start the
tutorial by creating a new dashboard for your application.
1. On the dashboard pane, select New dashboard.
2. Type a name for the dashboard.

3. Have a look at the Tile Gallery for a variety of tiles that you can add to your dashboard. In addition to
adding tiles from the gallery, you can pin charts and other views directly from Application Insights to the
dashboard.
4. Locate the Markdown tile and drag it on to your dashboard. This tile allows you to add text formatted in
markdown, which is ideal for adding descriptive text to your dashboard.
5. Add text to the tile's properties and resize it on the dashboard canvas.
6. Click Done customizing at the top of the screen to exit tile customization mode.
Add health overview

A dashboard with static text isn't very interesting, so now add a tile from Application Insights to show information
about your application. You can add Application Insights tiles from the Tile Gallery, or you can pin them directly
from Application Insights screens. This allows you to configure charts and views that you're already familiar with
before pinning them to your dashboard. Start by adding the standard health overview for your application. This
requires no configuration and allows minimal customization in the dashboard.
1. Select your Application Insights resource on the home screen.
2. In the Overview pane, click the pin icon to add the tile to the last dashboard that you were viewing.
3. In the top right, a notification will appear that your tile was pinned to your dashboard. Click Pinned to
dashboard in the notification to return to your dashboard or use the dashboard pane.
4. That tile is now added to your dashboard. Select Edit to change the positioning of the tile. Click and drag
the it into position and then click Done customizing. Your dashboard now has a tile with some useful
information.
Add custom metric chart
The Metrics panel allows you to graph a metric collected by Application Insights over time with optional filters
and grouping. Like everything else in Application Insights, you can add this chart to the dashboard. This does
require you to do a little customization first.
1. Select your Application Insights resource in the home screen.
2. Select Metrics.
3. An empty chart has already been created, and you're prompted to add a metric. Add a metric to the chart
and optionally add a filter and a grouping. The example below shows the number of server requests
grouped by success. This gives a running view of successful and unsuccessful requests.
4. Select Pin to dashboard on the right. This adds the view to the last dashboard that you were working with.
5. In the top right, a notification will appear that your tile was pinned to your dashboard. Click Pinned to
dashboard in the notification to return to your dashboard or use the dashboard blade.
6. That tile is now added to your dashboard. Select Edit to change the positioning of the tile. Click and drag
the it into position and then click Done customizing.
Add Logs (Analytics) query

Azure Application Insights Logs (Analytics) provides a rich query language that allows you to analyze all of the
data collected Application Insights. Just like charts and other views, you can add the output of a logs query to your
dashboard.
Since Azure Applications Insights Logs (Analytics) is a separate service, you need to share your dashboard for it to
include a logs query. When you share an Azure dashboard, you publish it as an Azure resource, which can make it
available to other users and resources.
1. At the top of the dashboard screen, click Share.
2. Keep the Dashboard name the same and select the Subscription Name to share the dashboard. Click
Publish. The dashboard is now available to other services and subscriptions. You can optionally define
specific users who should have access to the dashboard.
3. Select your Application Insights resource in the home screen.
4. Click Logs (Analytics) on the left under monitoring to open the Logs (Analytics) portal.
5. Type the following query, which returns the top 10 most requested pages and their request count:
requests
| summarize count() by name
| sort by count_ desc
| take 10
6. Click Run to validate the results of the query.

7. Click the pin icon and select the name of your dashboard. The reason that this option has you select a
dashboard unlike the previous steps where the last dashboard was used is because the Logs (Analytics)
console is a separate service and needs to select from all available shared dashboards.
8. Before you go back to the dashboard, add another query, but this time render it as a chart so you see the
different ways to visualize a logs query in a dashboard. Start with the following query that summarizes the
top 10 operations with the most exceptions.
exceptions
| summarize count() by operation_Name
| sort by count_ desc
| take 10
9. Select Chart and then change to a Doughnut to visualize the output.
10. Click the pin icon on the top right to pin the chart to your dashboard and this time select the link to
return to your dashboard.
11. The results of the queries are now added to your dashboard in the format that you selected. Click and drag
each into position and then click Done customizing.
12. Select the pencil icon on each title to give them a descriptive title.
13. Select Share to republish your changes to your dashboard that now includes a variety of charts and
visualizations from Application Insights.
Next steps
Now that you've learned how to create custom dashboards, have a look at the rest of the Application Insights
documentation including a case study.
Deep diagnostics
Archive Azure metric and log data using Azure
Storage
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.
Azure Monitor platform metrics are kept for 93 days.
Resource diagnostic logs only appear if routed to Log Analytics, where they have a configurable retention
period with a minimum of 30 days.
Activity log entries are kept for 90 days.
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

Create a storage account

First you need to set up a storage account to which the monitoring data will be archived. To do this, follow the
steps here.
Route subscription logs to the storage account

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.
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.
Route resource data to 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.
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.
NOTE
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.
Route virtual machine (guest OS) data to the storage account

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.
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.
View the monitoring data in the storage account

WARNING
The format of the log data in the storage account will change to JSON Lines on Nov. 1st, 2018. See this article for a
description of the impact and how to update your tooling to handle the new format.
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 Activity Log, 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.
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.
Clean up resources
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.
Next steps
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
To get more out of your data and derive additional insights, also send your data into Log Analytics.
Get started with Log Analytics
Create an Autoscale Setting for Azure resources
based on performance data or a schedule
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
Log in to the Azure portal

Log in to the Azure portal.
Create a Web App and App Service Plan

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' or place it into
a 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 recurrence profile
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.
Create a scale-out rule

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.
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.
Trigger scale-in action

The scale-in condition in the autoscale setting triggers if there are fewer than 5 requests to the Web App over a
period of 10 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.
Clean up resources
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.
Next steps
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
Azure Monitor PowerShell samples
The following table includes links to PowerShell scripts samples to perform various functions in Azure Monitor.
Create workspace
Create a Log Analytics workspace Creates a Log Analytics workspace in Azure Monitor.
Azure Management - Monitoring
Monitoring in Azure is one aspect of Azure Management. This article briefly describes the different areas of
management required to deploy and maintain your applications and resources in Azure with links to
documentation to get you started.
Management in Azure
Management refers to the tasks and processes required to maintain your business applications and the resources
that support them. Azure has multiple services and tools that work together to provide complete management for
not only your applications running in Azure but also in other clouds and on-premises. Understanding the different
tools available and how they can be used together for a variety of management scenarios is the first step in
designing a complete management environment.
The following diagram illustrates the different areas of management that are required to maintain any application
or resource. These different areas can be thought of in terms of a lifecycle where each is required in continuous
succession over the lifespan of a resource. This starts with its initial deployment, through its continued operation,
and finally when it's retired.
The following sections briefly describe the different management areas and provide links to detailed content on the
main Azure services intended to address them.
Monitor
Monitoring is the act of collecting and analyzing data to determine the performance, health, and availability of your
business application and the resources it depends on. An effective monitoring strategy will help you understand the
detailed operation of the different components of your application and to increase your uptime by proactively
notifying you of critical issues so that you can resolve them before they become problems. Monitoring in Azure is
primarily provided by Azure Monitor which provides common stores for storing monitoring data, multiple data
sources for collecting data from the different tiers supporting your application, and features for analyzing and
responding to collected data.
Configure
Configure refers to the initial deployment and configuration of applications and resources and their ongoing
maintenance with patches and updates. Automation of these tasks through script and policy allows you to
eliminate redundancy, minimizing your time and effort and increasing your accuracy and efficiency. Azure
Automation provides the bulk of services for automating configuration tasks. In addition to runbooks for
automating processes, it provides configuration and update management, which assist you in managing
configuration through policy and in identifying and deploying updates.
Govern
Governance provides mechanisms and processes to maintain control over your applications and resources in
Azure. It involves planning your initiatives and setting strategic priorities. Governance in Azure is primarily
implemented with two services. Azure Policy allows you to create, assign and, manage policy definitions that
enforce different rules and actions over your resources, so those resources stay compliant with your corporate
standards and service level agreements. Azure Cost Management allows you to track cloud usage and
expenditures for your Azure resources and other cloud providers including AWS and Google.
Secure
Managing security of your applications, resources, and data involves a combination of assessing threats, collecting
and analyzing security data, and ensuring that your applications and resources are designed and configured in a
secure fashion. Security monitoring and threat analysis are provided by Azure Security Center which includes
unified security management and advanced threat protection across hybrid cloud workloads. You should also see
Introduction to Azure Security for comprehensive information on security in Azure and guidance on securely
configuring Azure resources.
Protect
Protection refers to ensuring that your applications and data are always available, even in the case of outages
beyond your control. Protection in Azure is provided by two services. Azure Backup provides backup and recovery
of your data, either in the cloud or on-premises. Azure Site Recovery ensures high availability of your application
by providing business continuity and immediate recovery in the case of disaster.
Migrate
Migration refers to transitioning workloads currently running on-premises to the Azure cloud. Azure Migrate is a
service that helps you assess the migration suitability, including performance-based sizing and cost estimates, of
on-premises virtual machines to Azure. Azure Site Recovery can help you perform the actual migration of virtual
machines from on-premises or from Amazon Web Services. Azure Database Migration will assist you in migrating
multiple database sources to Azure Data platforms.
Continuous monitoring with Azure Monitor
Continuous monitoring refers to the process and technology required to incorporate monitoring across each phase
of your DevOps and IT operations lifecycles. It helps to continuously ensure the health, performance, and reliability
of your application and infrastructure as it moves from development to production. Continuous monitoring builds
on the concepts of Continuous Integration and Continuous Deployment (CI/CD ) which help you develop and
deliver software faster and more reliably to provide continuous value to your users.
Azure Monitor is the unified monitoring solution in Azure that provides full-stack observability across applications
and infrastructure in the cloud and on-premises. It works seamlessly with Visual Studio and Visual Studio Code
during development and test and integrates with Azure DevOps for release management and work item
management during deployment and operations. It even integrates across the ITSM and SIEM tools of your choice
to help track issues and incidents within your existing IT processes.
This article describes specific steps for using Azure Monitor to enable continuous monitoring throughout your
workflows. It includes links to other documentation that provides details on implementing different features.
Enable monitoring for all your applications

In order to gain observability across your entire environment, you need to enable monitoring on all your web
applications and services. This will allow you to easily visualize end-to-end transactions and connections across all
the components.
Azure DevOps Projects give you a simplified experience with your existing code and Git repository, or choose
from one of the sample applications to create a Continuous Integration (CI) and Continuous Delivery (CD )
pipeline to Azure.
Continuous monitoring in your DevOps release pipeline allows you to gate or rollback your deployment based
on monitoring data.
Status Monitor allows you to instrument a live .NET app on Windows with Azure Application Insights, without
having to modify or redeploy your code.
If you have access to the code for your application, then enable full monitoring with Application Insights by
installing the Azure Monitor Application Insights SDK for .NET, Java, Node.js, or any other programming
languages. This allows you to specify custom events, metrics, or page views that are relevant to your application
and your business.
Enable monitoring for your entire infrastructure

Applications are only as reliable as their underlying infrastructure. Having monitoring enabled across your entire
infrastructure will help you achieve full observability and make it easier to discover a potential root cause when
something fails. Azure Monitor helps you track the health and performance of your entire hybrid infrastructure
including resources such as VMs, containers, storage, and network.
You automatically get platform metrics, activity logs and diagnostics logs from most of your Azure resources
with no configuration.
Enable deeper monitoring for VMs with Azure Monitor for VMs.
Enable deeper monitoring for AKS clusters with Azure Monitor for containers.
Add monitoring solutions for different applications and services in your environment.
Infrastructure as code is the management of infrastructure in a descriptive model, using the same versioning as
DevOps teams use for source code. It adds reliability and scalability to your environment and allows you to
leverage similar processes that used to manage your applications.
Use Resource Manager templates to enable monitoring and configure alerts over a large set of resources.
Use Azure Policy to enforce different rules over your resources. This ensures that those resources stay
compliant with your corporate standards and service level agreements.
Combine resources in Azure Resource Groups

A typical application on Azure today includes multiple resources such as VMs and App Services or microservices
hosted on Cloud Services, AKS clusters, or Service Fabric. These applications frequently utilize dependencies like
Event Hubs, Storage, SQL, and Service Bus.
Combine resources in Azure Resource Groups to get full visibility across all your resources that make up your
different applications. Azure Monitor for Resource Groups provides a simple way to keep track of the health and
performance of your entire full-stack application and enables drilling down into respective components for any
investigations or debugging.
Ensure quality through Continuous Deployment

Continuous Integration / Continuous Deployment allows you to automatically integrate and deploy code changes
to your application based on the results of automated testing. It streamlines the deployment process and ensures
the quality of any changes before they move into production.
Use Azure Pipelines to implement Continuous Deployment and automate your entire process from code
commit to production based on your CI/CD tests.
Use Quality Gates to integrate monitoring into your pre-deployment or post-deployment. This ensures that you
are meeting the key health/performance metrics (KPIs) as your applications move from dev to production and
any differences in the infrastructure environment or scale is not negatively impacting your KPIs.
Maintain separate monitoring instances between your different deployment environments such as Dev, Test,
Canary, and Prod. This ensures that collected data is relevant across the associated applications and
infrastructure. If you need to correlate data across environments, you can use multi-resource charts in Metrics
Explorer or create cross-resource queries in Azure Monitor.
Create actionable alerts with actions

A critical aspect of monitoring is proactively notifying administrators of any current and predicted issues.
Create alerts in Azure Monitor based on logs and metrics to identify predictable failure states. You should have
a goal of making all alerts actionable meaning that they represent actual critical conditions and seek to reduce
false positives. Use Dynamic Thresholds to automatically calculate baselines on metric data rather than defining
your own static thresholds.
Define actions for alerts to use the most effective means of notifying your administrators. Available actions for
notification are SMS, e-mails, push notifications, or voice calls.
Use more advanced actions to connect to your ITSM tool or other alert management systems through
webhooks.
Remediate situations identified in alerts as well with Azure Automation runbooks or Logic Apps that can be
launched from an alert using webhooks.
Use autoscaling to dynamically increase and decrease your compute resources based on collected metrics.
Prepare dashboards and workbooks

Ensuring that your development and operations have access to the same telemetry and tools allows them to view
patterns across your entire environment and minimize your Mean Time To Detect (MTTD ) and Mean Time To
Restore (MTTR ).
Prepare custom dashboards based on common metrics and logs for the different roles in your organization.
Dashboards can combine data from all Azure resources.
Prepare Workbooks to ensure knowledge sharing between development and operations. These could be
prepared as dynamic reports with metric charts and log queries, or even as troubleshooting guides prepared by
developers helping customer support or operations to handle basic problems.
Continuously optimize
Monitoring is one of the fundamental aspects of the popular Build-Measure-Learn philosophy, which recommends
continuously tracking your KPIs and user behavior metrics and then striving to optimize them through planning
iterations. Azure Monitor helps you collect metrics and logs relevant to your business and to add new data points
in the next deployment as required.
Use tools in Application Insights to track end-user behavior and engagement.
Use Impact Analysis to help you prioritize which areas to focus on to drive to important KPIs.
Next steps
Learn about the difference components of Azure Monitor.
Add continuous monitoring to your release pipeline.
Sources of monitoring data for Azure Monitor
Azure Monitor is based on a common monitoring data platform that includes Logs and Metrics. Collecting data
into this platform allows data from multiple resources to be analyzed together using a common set of tools in
Azure Monitor. Monitoring data may also be sent to other locations to support certain scenarios, and some
resources may write to other locations before they can be collected into Logs or Metrics.
This article describes the different sources of monitoring data collected by Azure Monitor in addition to the
monitoring data created by Azure resources. Links are provided to detailed information on configuration
required to collect this data to different locations.
Application tiers
Sources of monitoring data from Azure applications can be organized into tiers, the highest tiers being your
application itself and the lower tiers being components of Azure platform. The method of accessing data from
each tier varies. The application tiers are summarized in the table below, and the sources of monitoring data in
each tier are presented in the following sections. See Monitoring data locations in Azure for a description of each
data location and how you can access its data.
Azure
The following table briefly describes the application tiers that are specific to Azure. Following the link for further
details on each in the sections below.
TIER DESCRIPTION COLLECTION METHOD
Azure Tenant Data about the operation of tenant- View AAD data in portal or configure
level Azure services, such as Azure collection to Azure Monitor using a
Active Directory. tenant diagnostic setting.
Azure subscription Data related to the health and View in portal or configure collection to
management of cross-resource Azure Monitor using a log profile.
services in your Azure subscription
such as Resource Manager and Service
Health.
Azure resources Data about the operation and Metrics collected automatically, view in
performance of each Azure resource. Metrics Explorer.
Configure diagnostic settings to collect
logs in Azure Monitor.
Monitoring solutions and Insights
available for more detailed monitoring
for specific resource types.
Azure, other cloud, or on-premises

The following table briefly describes the application tiers that may be in Azure, another cloud, or on-premises.
Following the link for further details on each in the sections below.
Operating system (guest) Data about the operating system on Install Log Analytics agent to collect
compute resources. client data sources into Azure Monitor
and Dependency agent to collect
dependencies supporting Azure
Monitor for VMs.
For Azure virtual machines, install
Azure Diagnostic Extension to collect
logs and metrics into Azure Monitor.
Application Code Data about the performance and Instrument your code to collect data
functionality of the actual application into Application Insights.
and code, including performance
traces, application logs, and user
telemetry.
Custom sources Data from external services or other Collect log or metrics data into Azure
components or devices. Monitor from any REST client.
Azure tenant
Telemetry related to your Azure tenant is collected from tenant-wide services such as Azure Active Directory.
Azure Active Directory Audit Logs
Azure Active Directory reporting contains the history of sign-in activity and audit trail of changes made within a
particular tenant.
DESTINATION DESCRIPTION REFERENCE
Azure Monitor Logs Configure Azure AD logs to be Integrate Azure AD logs with Azure
collected in Azure Monitor to analyze Monitor logs (preview)
them with other monitoring data.
Azure Storage Export Azure AD logs to Azure Storage Tutorial: Archive Azure AD logs to an
for archiving. Azure storage account (preview)
Event Hub Stream Azure AD logs to other Tutorial: Stream Azure Active Directory
locations using Event Hubs. logs to an Azure event hub (preview).
Azure subscription
Telemetry related to the health and operation of your Azure subscription.
Azure Activity log

The Azure Activity log includes service health records along with records on any configuration changes made to
the resources in your Azure subscription. The Activity log is available to all Azure resources and represents their
external view.
Activity log The Activity log is collected into its own Query the Activity log in the Azure
data store that you can view from the portal
Azure Monitor menu or use to create
Activity log alerts.
Azure Monitor Logs Configure Azure Monitor Logs to Collect and analyze Azure activity logs
collect the Activity log to analyze it in Log Analytics workspace in Azure
with other monitoring data. Monitor
Azure Storage Export the Activity log to Azure Archive Activity log
Storage for archiving.
Event Hubs Stream the Activity log to other Stream Activity log to Event Hub.
locations using Event Hubs
Azure Service Health

Azure Service Health provides information about the health of the Azure services in your subscription that your
application and resources rely on.
Activity log Service Health records are stored in the View service health notifications by
Azure Monitor Logs Azure Activity log, so you can view using the Azure portal
them in the Azure portal or perform
any other activities you can perform
with the Activity log.
Azure resources
Metrics and resource logs provide information about the internal operation of Azure resources. These are
available for most Azure services, and monitoring solutions and insights collect additional data for particular
services.
Platform metrics
Most Azure services will send platform metrics that reflect their performance and operation directly to the
metrics database. The specific metrics will vary for each type of resource.
Azure Monitor Metrics Platform metrics will write to the Azure Getting started with Azure Metrics
Monitor metrics database with no Explorer
configuration. Access platform metrics Supported metrics with Azure Monitor
from Metrics Explorer.
Azure Monitor Logs Copy platform metrics to Logs for Azure diagnostics direct to Log
trending and other analysis using Log Analytics
Analytics.
Event Hubs Stream metrics to other locations using Stream Azure monitoring data to an
Event Hubs. event hub for consumption by an
external tool
Resource logs
Resource logs provide insights into the internal operation of an Azure resource. Resource logs are created
automatically, but you must create a diagnostic setting to specify a destination for them to collected for each
resource.
The configuration requirements and content of resource logs vary by resource type, and not all services yet
create them. See Supported services, schemas, and categories for Azure resource logs for details on each service
and links to detailed configuration procedures. If the service isn’t listed in this article, then that service doesn’t
currently create resource logs.
Azure Monitor Logs Send resource logs to Azure Monitor Collect Azure resource logs in Log
Logs for analysis with other collected Analytics workspace in Azure Monitor
log data.
Storage Send resource logs to Azure Storage Archive Azure resource logs
for archiving.
Event Hubs Stream resource logs to other locations Stream Azure resource logs to an event
using Event Hubs. hub
Operating system (guest)

Compute resources in Azure, in other clouds, and on-premises have a guest operating system to monitor. With
the installation of one or more agents, you can gather telemetry from the guest into Azure Monitor to analyze it
with the same monitoring tools as the Azure services themselves.
Azure Diagnostic extension
Enabling the Azure Diagnostics extension for Azure Virtual machines allows you to collect logs and metrics from
the guest operating system of Azure compute resources including Azure Cloud Service (classic) Web and Worker
Roles, Virtual Machines, virtual machine scale sets, and Service Fabric.
Storage When you enable the Diagnostics Store and view diagnostic data in Azure
Extension, it will write to a storage Storage
account by default.
Azure Monitor Metrics When you configure the Diagnostics Send Guest OS metrics to the Azure
Extension to collect performance Monitor metric store using a Resource
counters, they are written to the Azure Manager template for a Windows
Monitor metrics database. virtual machine
Application Insights Logs Collect logs and performance counters Send Cloud Service, Virtual Machine, or
from the compute resource supporting Service Fabric diagnostic data to
your application to be analyzed with Application Insights
other application data.
Event Hubs Configure the Diagnostics Extension to Streaming Azure Diagnostics data in
stream the data to other locations the hot path by using Event Hubs
using Event Hubs.
Log Analytics agent

Install the Log Analytics agent for comprehensive monitoring and management of your Windows or Linux
virtual machines. The virtual machine can be running in Azure, another cloud, or on-premises.

Azure Monitor Logs The Log Analytics agent connects to Agent data sources in Azure Monitor
Azure Monitor either directly or Connect Operations Manager to Azure
through System Center Operations Monitor
Manager and allows you to collect data
from data sources that you configure
or from monitoring solutions that
provide additional insights into
applications running on the virtual
machine.

Azure Monitor for VMs provides a customized monitoring experience for virtual machines providing features
beyond core Azure Monitor functionality, including service status and VM health. It requires a Dependency
Agent on Windows and Linux virtual machines that integrates with the Log Analytics agent to collect discovered
data about processes running on the virtual machine and external process dependencies.
Azure Monitor Logs Stores data about processes and Using Azure Monitor for VMs (preview)
dependencies on the agent. Map to understand application
components
VM Storage Azure Monitor for VMs stores heath Understand the health of your Azure
state information in a custom location. virtual machines
This is only available to Azure Monitor Azure Resource health REST API
for VMs in the Azure portal in addition
to the Azure Resource health REST API.
Application Code
Detailed application monitoring in Azure Monitor is done with Application Insights which collects data from
applications running on a variety of platforms. The application can be running in Azure, another cloud, or on-
premises.
Application data
When you enable Application Insights for an application by installing an instrumentation package, it collects
metrics and logs related to the performance and operation of the application. Application Insights stores the data
it collects in the same Azure Monitor data platform used by other data sources. It includes extensive tools for
analyzing this data, but you can also analyze it with data from other sources using tools such as Metrics Explorer
and Log Analytics.
Azure Monitor Logs Operational data about your Analyze log data in Azure Monitor
application including page views,
application requests, exceptions, and
traces.
Dependency information between Telemetry correlation in Application

application components to support Insights
Application Map and telemetry Application Map
correlation.
Results of availability tests that test the Monitor availability and responsiveness
availability and responsiveness of your of any web site
application from different locations on
the public Internet.
Azure Monitor Metrics Application Insights collects metrics Log-based and pre-aggregated metrics
describing the performance and in Application Insights
operation of the application in addition Application Insights API for custom
to custom metrics that you define in events and metrics
your application into the Azure
Monitor metrics database.
Azure Storage Send application data to Azure Storage Export telemetry from Application
for archiving. Insights
Details of availability tests are stored in Monitor availability and responsiveness

Azure Storage. Use Application Insights of any web site
in the Azure portal to download for
local analysis. Results of availability
tests are stored in Azure Monitor Logs.
Profiler trace data is stored in Azure Profile production applications in Azure

Storage. Use Application Insights in the with Application Insights
Azure portal to download for local
analysis.
Debug snapshot data that is captured How snapshots work

for a subset of exceptions is stored in
Azure Storage. Use Application Insights
in the Azure portal to download for
local analysis.
Monitoring Solutions and Insights

Monitoring solutions and Insights collect data to provide additional insights into the operation of a particular
service or application. They may address resources in different application tiers and even multiple tiers.
Azure Monitor Logs Monitoring solutions collect data into Data collection details for monitoring
Azure Monitor logs where it may be solutions in Azure
analyzed using the query language or
views that are typically included in the
solution.
Azure Monitor for Containers

Azure Monitor for Containers provides a customized monitoring experience for Azure Kubernetes Service (AKS ).
It collects additional data about these resources described in the following table.
Azure Monitor Logs Stores monitoring data for AKS Understand AKS cluster performance
including inventory, logs, and events. with Azure Monitor for containers
Metric data is also stored in Logs in
order to leverage its analysis
functionality in the portal.
Azure Monitor Metrics Metric data is stored in the metric View container metrics in metrics
database to drive visualization and explorer
alerts.
Azure Kubernetes Service In order to a near real time experience, How to view container logs real time
Azure Monitor for Containers presents with Azure Monitor for containers
data directly from the Azure (preview)
Kubernetes service in the Azure portal.

Azure Monitor for VMs provides a customized experience for monitoring virtual machines. A description of the
data collected by Azure Monitor for VMs is included in the Operating System (guest) section above.
Custom sources
In addition to the standard tiers of an application, you may need to monitor other resources that have telemetry
that can't be collected with the other data sources. For these resources, write this data to either Metrics or Logs
using an Azure Monitor API.
DESTINATION METHOD DESCRIPTION REFERENCE
Azure Monitor Logs Data Collector API Collect log data from any Send log data to Azure
REST client and store in Log Monitor with the HTTP Data
Analytics workspace. Collector API (public
preview)
Azure Monitor Metrics Custom Metrics API Collect metric data from any Send custom metrics for an
REST client and store in Azure resource to the Azure
Azure Monitor metrics Monitor metric store by
database. using a REST API
Other services
Other services in Azure write data to the Azure Monitor data platform. This allows you to analyze data collected
by these services with data collected by Azure Monitor and leverage the same analysis and visualization tools.
SERVICE DESTINATION DESCRIPTION REFERENCE
Azure Security Center Azure Monitor Logs Azure Security Center stores Data collection in Azure
the security data it collects Security Center
in a Log Analytics
workspace which allows it to
be analyzed with other log
data collected by Azure
Monitor.
Azure Sentinel Azure Monitor Logs Azure Sentinel stores the Connect data sources
data it collects from
different data sources in a
Log Analytics workspace
which allows it to be
analyzed with other log data
collected by Azure Monitor.
Next steps
Learn more about the types of monitoring data collected by Azure Monitor and how to view and analyze this
data.
List the different locations where Azure resources store data and how you can access it.
Azure Monitor data platform
Enabling observability across today's complex computing environments running distributed applications that
rely on both cloud and on-premises services, requires collection of operational data from every layer and every
component of the distributed system. You need to be able to perform deep insights on this data and
consolidate it into a single pane of glass with different perspectives to support the multitude of stakeholders in
your organization.
Azure Monitor collects and aggregates data from a variety of sources into a common data platform where it
can be used for analysis, visualization, and alerting. It provides a consistent experience on top of data from
multiple sources, which gives you deep insights across all your monitored resources and even with data from
other services that store their data in Azure Monitor.
Observability data in Azure Monitor

Metrics, logs, and distributed traces are commonly referred to as the three pillars of observability. These are the
different kinds of data that a monitoring tool must collect and analyze to provide sufficient observability of a
monitored system. Observability can be achieved by correlating data from multiple pillars and aggregating
data across the entire set of resources being monitored. Because Azure Monitor stores data from multiple
sources together, the data can be correlated and analyzed using a common set of tools. It also correlates data
across multiple Azure subscriptions and tenants, in addition to hosting data for other services.
Azure resources generate a significant amount of monitoring data. Azure Monitor consolidates this data along
with monitoring data from other sources into either a Metrics or Logs platform. Each is optimized for particular
monitoring scenarios, and each supports different features in Azure Monitor. Features such as data analysis,
visualizations, or alerting require you to understand the differences so that you can implement your required
scenario in the most efficient and cost effective manner. Insights in Azure Monitor such as Application Insights
or Azure Monitor for VMs have analysis tools that allow you to focus on the particular monitoring scenario
without having to understand the differences between the two types of data.
Metrics
Metrics are numerical values that describe some aspect of a system at a particular point in time. They are
collected at regular intervals and are identified with a timestamp, a name, a value, and one or more defining
labels. Metrics can be aggregated using a variety of algorithms, compared to other metrics, and analyzed for
trends over time.
Metrics in Azure Monitor are stored in a time-series database which is optimized for analyzing time-stamped
data. This makes metrics particularly suited for alerting and fast detection of issues. They can tell you how your
system is performing but typically need to be combined with logs to identify the root cause of issues.
Metrics are available for interactive analysis in the Azure portal with Metrics Explorer. They can be added to an
Azure dashboard for visualization in combination with other data and used for near-real time alerting.
Read more about Azure Monitor Metrics including their sources of data in Metrics in Azure Monitor.
Logs
Logs are events that occurred within the system. They can contain different kinds of data and may be
structured or free form text with a timestamp. They may be created sporadically as events in the environment
generate log entries, and a system under heavy load will typically generate more log volume.
Logs in Azure Monitor are stored in a Log Analytics workspace that's based on Azure Data Explorer which
provides a powerful analysis engine and rich query language. Logs typically provide enough information to
provide complete context of the issue being identified and are valuable for identifying root case of issues.
NOTE
It's important to distinguish between Azure Monitor Logs and sources of log data in Azure. For example, subscription
level events in Azure are written to an activity log that you can view from the Azure Monitor menu. Most resources will
write operational information to a diagnostic log that you can forward to different locations. Azure Monitor Logs is a log
data platform that collects activity logs and diagnostic logs along with other monitoring data to provide deep analysis
across your entire set of resources.
You can work with log queries interactively with Log Analytics in the Azure portal or add the results to an
Azure dashboard for visualization in combination with other data. You can also create log alerts which will
trigger an alert based on the results of a schedule query.
Read more about Azure Monitor Logs including their sources of data in Logs in Azure Monitor.
Distributed traces
Traces are series of related events that follow a user request through a distributed system. They can be used to
determine behavior of application code and the performance of different transactions. While logs will often be
created by individual components of a distributed system, a trace measures the operation and performance of
your application across the entire set of components.
Distributed tracing in Azure Monitor is enabled with the Application Insights SDK, and trace data is stored with
other application log data collected by Application Insights. This makes it available to the same analysis tools as
other log data including log queries, dashboards, and alerts.
Read more about distributed tracing at What is Distributed Tracing?.
Compare Azure Monitor Metrics and Logs

The following table compares Metrics and Logs in Azure Monitor.
ATTRIBUTE METRICS LOGS

ATTRIBUTE METRICS LOGS
Benefits Lightweight and capable of near-real Analyzed with rich query language.
time scenarios such as alerting. Ideal Ideal for deep analysis and identifying
for fast detection of issues. root cause.
Data Numerical values only Text or numeric data
Structure Standard set of properties including Unique set of properties depending

sample time, resource being on the log type.
monitored, a numeric value. Some
metrics include multiple dimensions
for further definition.
Collection Collected at regular intervals. May be collected sporadically as

events trigger a record to be created.
View in Azure portal Metrics Explorer Log Analytics
Data sources include Platform metrics collected from Azure Application and Diagnostics Logs.
resources. Monitoring solutions.
Applications monitored by Application Agents and VM extensions.
Insights. Application requests and exceptions.
Custom defined by application or API. Azure Security Center.
Data Collector API.
Collect monitoring data

Different sources of data for Azure Monitor will write to either a Log Analytics workspace (Logs) or the Azure
Monitor metrics database (Metrics) or both. Some sources will write directly to these data stores, while others
may write to another location such as Azure storage and require some configuration to populate logs or
metrics.
See Metrics in Azure Monitor and Logs in Azure Monitor for a listing of different data sources that populate
each type.
Stream data to external systems

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. Some sources can be configured
to send data directly to an event hub while you can use another process such as a Logic App to retrieve the
required data. See Stream Azure monitoring data to an event hub for consumption by an external tool for
details.
Next steps
Read more about Metrics in Azure Monitor.
Read more about Logs in Azure Monitor.
Learn about the monitoring data available for different resources in Azure.
Monitoring data locations in Azure Monitor
Azure Monitor is based on a data platform of Logs and Metrics as described in Azure Monitor data platform.
Monitoring data from Azure resources may be written to other locations though, either before they are copied to
Azure Monitor or to support additional scenarios.
Monitoring data locations

The following table identifies the different locations where monitoring data in Azure is sent and the different
methods for accessing it.
LOCATION DESCRIPTION METHODS OF ACCESS
Azure Monitor Metrics Time-series database which is optimized Metrics Explorer

for analyzing time-stamped data. Azure Monitor Metrics API
Azure Monitor Logs Log Analytics workspace that's based Log Analytics
on Azure Data Explorer which provides Log Analytics API
a powerful analysis engine and rich Application Insights API
query language.
Activity log Data from the Activity log is most Azure portal
useful when sent to Azure Monitor Azure Monitor Events API
Logs to analyze it with other data, but
it's also collected on its own so it can be
directly viewed in the Azure portal.
Azure Storage Some data sources will write directly to Storage Analytics
Azure storage and require configuration Server Explorer
to move data into Logs. You can also Storage Explorer
send data to Azure storage for
archiving and for integration with
external systems.
Event Hubs Send data to Azure Event Hubs to Capture to Storage

stream it to other locations.
Azure Monitor for VMs Azure Monitor for VMs stores workload Azure portal
health data in a custom location that's Workload monitor REST API
used by its monitoring experience in the Azure Resource health REST API
Azure portal.
Alerts Alerts created by Azure Monitor. Azure portal

Alerts Management REST API
Next steps
See the different sources of monitoring data collected by Azure Monitor.
Learn about the types of monitoring data collected by Azure Monitor and how to view and analyze this data.
Metrics in Azure Monitor
NOTE
The Azure Monitor data platform is based on two fundamental data types: Metrics and Logs. This article describes
Metrics. Refer to Logs in Azure Monitor for a detailed description of logs and to Azure Monitor data platform for a
comparison of the two.
Metrics in Azure Monitor are lightweight and capable of supporting near real-time scenarios making them
particularly useful for alerting and fast detection of issues. This article describes how metrics are structured,
what you can do with them, and identifies different data sources that store data in metrics.
What are metrics?

Metrics are numerical values that describe some aspect of a system at a particular time. Metrics are collected at
regular intervals and are useful for alerting because they can be sampled frequently, and an alert can be fired
quickly with relatively simple logic.
What can you do with Azure Monitor Metrics?

The following table lists the different ways that you can use metric data in Azure Monitor.
Analyze Use metrics explorer to analyze collected metrics on a chart

and compare metrics from different resources.
Visualize Pin a chart from metrics explorer to an Azure dashboard.

Create a workbook to combine with multiple sets of data in
an interactive report.Export the results of a query to Grafana
to leverage its dashboarding and combine with other data
sources.
Alert Configure a metric alert rule that sends a notification or

takes automated action when the metric value crosses a
threshold.
Automate Use Autoscale to increase or decrease resources based on a

metric value crossing a threshold.
Export Route Metrics to Logs to analyze data in Azure Monitor

Metrics together with data in Azure Monitor Logs and to
store metric values for longer than 93 days.
Stream Metrics to an Event Hub to route them to external
systems.
Retrieve Access metric values from a command line using PowerShell

cmdlets
Access metric values from custom application using REST
API.
Access metric values from a command line using CLI.
Archive Archive the performance or health history of your resource
for compliance, auditing, or offline reporting purposes.
How is data in Azure Monitor Metrics structured?

Data collected by Azure Monitor Metrics is stored in a time-series database which is optimized for analyzing
time-stamped data. Each set of metric values is a time series with the following properties:
The time the value was collected
The resource the value is associated with
A namespace that acts like a category for the metric
A metric name
The value itself
Some metrics may have multiple dimensions as described in Multi-dimensional metrics. Custom metrics can
have up to 10 dimensions.
Multi-dimensional metrics
One of the challenges to metric data is that it often has limited information to provide context for collected
values. Azure Monitor addresses this challenge with multi-dimensional metrics. Dimensions of a metric are
name-value pairs that carry additional data to describe the metric value. For example, a metric Available disk
space could 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, IP Address and Direction:
Network Throughput
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?”
Network Throughput + two dimensions ("IP" and "Direction")
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

TIMESTAMP DIMENSION "IP" DIMENSION "DIRECTION" METRIC VALUE
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.
Interacting with Azure Monitor Metrics

Use Metrics Explorer to interactively analyze the data in your metric database and chart the values of multiple
metrics over time. You can pin the charts to a dashboard to view them with other visualizations. You can also
retrieve metrics by using the Azure monitoring REST API.
Sources of Azure Monitor Metrics

There are three fundamental sources of metrics collected by Azure Monitor. Once these metrics are collected in
the Azure Monitor metric database, 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. Platform metrics are
collected from Azure resources at one-minute frequency unless specified otherwise in the metric's definition.
Guest OS metrics are collected from the guest operating system of a virtual machine. Enable guest OS metrics
for Windows virtual machines with Windows Diagnostic Extension (WAD ) and for Linux virtual machines with
InfluxData Telegraf Agent.
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 metrics that are automatically available.
You can define custom metrics in your application that's monitored by Application Insights or create custom
metrics for an Azure service using the custom metrics API.
Retention of Metrics
For most resources in Azure, metrics are stored for 93 days. There are some exceptions:
Guest OS metrics
Classic guest OS metrics. These are performance counters collected by the Windows Diagnostic Extension
(WAD ) or the Linux Diagnostic Extension (LAD ) and routed to an Azure storage account. Retention for these
metrics is 14 days.
Guest OS metrics sent to Azure Monitor Metrics. These are performance counters collected by the
Windows Diagnostic Extension (WAD ) and send to the Azure Monitor Sink, or via the InfluxData Telegraf
Agent on Linux machines. Retention for these metrics is 93 days.
Guest OS metrics collected by Log Analytics agent. These are performance counters collected by the
Log Analytics agent and sent to a Log Analytics workspace. Retention for these metrics is 31 days, and can
be extended up to 2 years.
Application Insights log-based metrics.
Behind the scene, log-based metrics translate into log queries. Their retention matches the retention of
events in underlying logs. For Application Insights resources, logs are stored for 90 days.
NOTE
You can send platform metrics for Azure Monitor resources to a Log Analytics workspace for long term trending.
Next steps
Learn more about the Azure Monitor data platform.
Learn about log data in Azure Monitor.
Logs in Azure Monitor
NOTE
All data collected by Azure Monitor fits into one of two fundamental types, Metrics and Logs. This article describes Logs.
Refer to Metrics in Azure Monitor for a detailed description of metrics and to Monitoring data collected by Azure
Monitor for a comparison of the two.
Logs in Azure Monitor are especially useful for performing complex analysis across data from a variety of
sources. This article describes how Logs are structured in Azure Monitor, what you can do with the data, and
identifies different data sources that store data in Logs.
NOTE
It's important to distinguish between Azure Monitor Logs and sources of log data in Azure. For example, subscription
level events in Azure are written to an activity log that you can view from the Azure Monitor menu. Most resources will
write operational information to a diagnostic log that you can forward to different locations. Azure Monitor Logs is a log
data platform that collects activity logs and diagnostic logs along with other monitoring data to provide deep analysis
across your entire set of resources.
What are Azure Monitor Logs?

Logs in Azure Monitor contain different kinds of data organized into records with different sets of properties
for each type. Logs can contain numeric values like Azure Monitor Metrics but typically contain text data with
detailed descriptions. They further differ from metric data in that they vary in their structure and are often not
collected at regular intervals. Telemetry such as events and traces are stored Azure Monitor Logs in addition to
performance data so that it can all be combined for analysis.
A common type of log entry is an event, which is collected sporadically. Events are 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.
Because the format of the data can vary, applications can create custom logs by using the structure that they
need. Metric data can even be stored in Logs to combine them with other monitoring data for trending and
other data analysis.
What can you do with Azure Monitor Logs?

The following table lists the different ways that you can use Logs in Azure Monitor.
Analyze Use Log Analytics in the Azure portal to write log queries
and interactively analyze log data using the powerful Data
Explorer analysis engine.
Use the Application Insights analytics console in the Azure
portal to write log queries and interactively analyze log data
from Application Insights.
Visualize Pin query results rendered as tables or charts to an Azure
dashboard.
Create a workbook to combine with multiple sets of data in
an interactive report.
Export the results of a query to Power BI to use different
visualizations and share with users outside of Azure.
Export the results of a query to Grafana to leverage its
dashboarding and combine with other data sources.
Alert Configure a log alert rule that sends a notification or takes

automated action when the results of the query match a
particular result.
Configure a metric alert rule on certain log data logs
extracted as metrics.
Retrieve Access log query results from a command line using Azure
CLI.
Access log query results from a command line using
PowerShell cmdlets.
Access log query results from a custom application using
REST API.
Export Build a workflow to retrieve log data and copy it to an

external location using Logic Apps.
How is data in Azure Monitor Logs structured?

Data collected by Azure Monitor Logs is stored in a Log Analytics workspace. Each workspace contains
multiple tables that each store data from a particular source. While all tables share some common properties,
each has a unique set of properties depending on the kind of data it stores. A new workspace will have
standard set of tables, and more tables will be added by different monitoring solutions and other services that
write to the workspace.
Log data from Application Insights uses the same Log Analytics engine as workspaces, but it's stored
separately for each monitored application. Each application has a standard set of tables to hold data such as
application requests, exceptions, and page views.
Log queries will either use data from a Log Analytics workspace or an Application Insights application. You can
use a cross-resource query to analyze application data together with other log data or to create queries
including multiple workspaces or applications.
Log queries
Data in Azure Monitor Logs is retrieved using a log query written with the Kusto query language, which allows
you to quickly retrieve, consolidate, and analyze collected data. Use Log Analytics to write and test log queries
in the Azure portal. It allows you to work with results interactively or pin them to a dashboard to view them
with other visualizations.
Open Log Analytics from Application Insights to analyze Application Insights data.
You can also retrieve log data by using the Log Analytics API and the Application Insights REST API.
Sources of Azure Monitor Logs

Azure Monitor can collect log data from a variety of sources both within Azure and from on-premises
resources. The following tables list the different data sources available from different resources that write data
to Azure Monitor Logs. Each has a link to details on any required configuration.
Azure tenant and subscription
DATA DESCRIPTION
Azure Active Directory audit logs Configured through Diagnostic settings for each directory.
See Integrate Azure AD logs with Azure Monitor logs.
Activity logs Stored separately by default and can be used for near real
time alerts. Install Activity log Analytics solution to write to
Log Analytics workspace. See Collect and analyze Azure
activity logs in Log Analytics.
Azure resources
DATA DESCRIPTION
Resource diagnostics Configure Diagnostic settings to write to diagnostic data,

including metrics to a Log Analytics workspace. See Stream
Azure Diagnostic Logs to Log Analytics.
Monitoring solutions Monitoring solutions write data they collect to their Log
Analytics workspace. See Data collection details for
management solutions in Azure for a list of solutions. See
Monitoring solutions in Azure Monitor for details on
installing and using solutions.
Metrics Send platform metrics for Azure Monitor resources to a Log

Analytics workspace to retain log data for longer periods
and to perform complex analysis with other data types
using the Kusto query language. See Stream Azure
Diagnostic Logs to Log Analytics.
Azure table storage Collect data from Azure storage where some Azure
resources write monitoring data. See Use Azure blob
storage for IIS and Azure table storage for events with Log
Analytics.
Virtual Machines
DATA DESCRIPTION
Agent data sources Data sources collected from Windows and Linux agents
include events, performance data, and custom logs. See
Agent data sources in Azure Monitor for a list of data
sources and details on configuration.
Monitoring solutions Monitoring solutions write data they collect from agents to
their Log Analytics workspace. See Data collection details for
management solutions in Azure for a list of solutions. See
Monitoring solutions in Azure Monitor for details on
installing and using solutions.
System Center Operations Manager Connect Operations Manager management group to Azure
Monitor to collect event and performance data from on-
premises agents into logs. See Connect Operations
Manager to Log Analytics for details on this configuration.
Applications
DATA DESCRIPTION
Requests and exceptions Detailed data about application requests and exceptions are
in the requests, pageViews, and exceptions tables. Calls to
external components are in the dependencies table.
Usage and performance Performance for the application is available in the requests,
browserTimings and performanceCounters tables. Data for
custom metrics is in the customMetrics table.
Trace data Results from distributed tracing are stored in the traces
table.
Availability tests Summary data from availability tests is stored in the

availabilityResults table. Detailed data from these tests are
in separate storage and accessed from Application Insights
in the Azure portal.
Insights
DATA DESCRIPTION
Azure Monitor for containers Inventory and performance data collected by Azure Monitor
for containers. See Container data-collection details for a list
of the tables.
Azure Monitor for VMs Map and performance data collected by Azure Monitor for
VMs. See How to query logs from Azure Monitor for VMs
for details on querying this data.
Custom
DATA DESCRIPTION
REST API Write data to a Log Analytics workspace from any REST
client. See Send log data to Azure Monitor with the HTTP
Data Collector API for details.
Logic App Write any data to a Log Analytics workspace from a Logic
App workflow with the Azure Log Analytics Data
Collector action.
Security
DATA DESCRIPTION
Azure Security Center Azure Security Center stores data that it collects in a Log
Analytics workspace where it can be analyzed with other log
data. See Data collection in Azure Security Center for details
on workspace configuration.
Azure Sentinel Azure Sentinel stores data from data sources into a Log
Analytics workspace. See Connect data sources.
Next steps
Learn about metrics in Azure Monitor.
Log data ingestion time in Azure Monitor
Azure Monitor is a high scale data service that serves thousands of customers sending terabytes of data each
month at a growing pace. There are often questions about the time it takes for log data to become available after
it's collected. This article explains the different factors that affect this latency.
Typical latency
Latency refers to the time that data is created on the monitored system and the time that it comes available for
analysis in Azure Monitor. The typical latency to ingest log data is between 2 and 5 minutes. The specific latency
for any particular data will vary depending on a variety of factors explained below.
Factors affecting latency

The total ingestion time for a particular set of data can be broken down into the following high-level areas.
Agent time - The time to discover an event, collect it, and then send it to Azure Monitor ingestion point as a log
record. In most cases, this process is handled by an agent.
Pipeline time - The time for the ingestion pipeline to process the log record. This includes parsing the
properties of the event and potentially adding calculated information.
Indexing time – The time spent to ingest a log record into Azure Monitor big data store.
Details on the different latency introduced in this process are described below.
Agent collection latency
Agents and management solutions use different strategies to collect data from a virtual machine, which may affect
the latency. Some specific examples include the following:
Windows events, syslog events, and performance metrics are collected immediately. Linux performance
counters are polled at 30-second intervals.
IIS logs and custom logs are collected once their timestamp changes. For IIS logs, this is influenced by the
rollover schedule configured on IIS.
Active Directory Replication solution performs its assessment every five days, while the Active Directory
Assessment solution performs a weekly assessment of your Active Directory infrastructure. The agent will
collect these logs only when assessment is complete.
Agent upload frequency
To ensure the Log Analytics agent is lightweight, the agent buffers logs and periodically uploads them to Azure
Monitor. Upload frequency varies between 30 seconds and 2 minutes depending on the type of data. Most data is
uploaded in under 1 minute. Network conditions may negatively affect the latency of this data to reach Azure
Monitor ingestion point.
Azure activity logs, diagnostic logs and metrics
Azure data adds additional time to become available at Log Analytics ingestion point for processing:
Data from diagnostic logs take 2-15 minutes, depending on the Azure service. See the query below to examine
this latency in your environment
Azure platform metrics take 3 minutes to be sent to Log Analytics ingestion point.
Activity log data will take about 10-15 minutes to be sent to Log Analytics ingestion point.
Once available at ingestion point, data takes additional 2-5 minutes to be available for querying.
Management solutions collection
Some solutions do not collect their data from an agent and may use a collection method that introduces additional
latency. Some solutions collect data at regular intervals without attempting near-real time collection. Specific
examples include the following:
Office 365 solution polls activity logs using the Office 365 Management Activity API, which currently does not
provide any near-real time latency guarantees.
Windows Analytics solutions (Update Compliance for example) data is collected by the solution at a daily
frequency.
Refer to the documentation for each solution to determine its collection frequency.
Pipeline -process time
Once log records are ingested into the Azure Monitor pipeline (as identified in the _TimeReceived property),
they're written to temporary storage to ensure tenant isolation and to make sure that data isn't lost. This process
typically adds 5-15 seconds. Some management solutions implement heavier algorithms to aggregate data and
derive insights as data is streaming in. For example, the Network Performance Monitoring aggregates incoming
data over 3-minute intervals, effectively adding 3-minute latency. Another process that adds latency is the process
that handles custom logs. In some cases, this process might add few minutes of latency to logs that are collected
from files by the agent.
New custom data types provisioning
When a new type of custom data is created from a custom log or the Data Collector API, the system creates a
dedicated storage container. This is a one-time overhead that occurs only on the first appearance of this data type.
Surge protection
The top priority of Azure Monitor is to ensure that no customer data is lost, so the system has built-in protection
for data surges. This includes buffers to ensure that even under immense load, the system will keep functioning.
Under normal load, these controls add less than a minute, but in extreme conditions and failures they could add
significant time while ensuring data is safe.
Indexing time
There is a built-in balance for every big data platform between providing analytics and advanced search
capabilities as opposed to providing immediate access to the data. Azure Monitor allows you to run powerful
queries on billions of records and get results within a few seconds. This is made possible because the
infrastructure transforms the data dramatically during its ingestion and stores it in unique compact structures. The
system buffers the data until enough of it is available to create these structures. This must be completed before the
log record appears in search results.
This process currently takes about 5 minutes when there is low volume of data but less time at higher data rates.
This seems counterintuitive, but this process allows optimization of latency for high-volume production workloads.
Checking ingestion time

Ingestion time may vary for different resources under different circumstances. You can use log queries to identify
specific behavior of your environment. The following table specifies how you can determine the different times for
a record as it's created and sent to Azure Monitor.
STEP PROPERTY OR FUNCTION COMMENTS

STEP PROPERTY OR FUNCTION COMMENTS
Record created at data source TimeGenerated

If the data source doesn't set this value,
then it will be set to the same time as
_TimeReceived.
Record received by Azure Monitor _TimeReceived

ingestion endpoint
Record stored in workspace and ingestion_time()

available for queries
Ingestion latency delays

You can measure the latency of a specific record by comparing the result of the ingestion_time() function to the
TimeGenerated property. This data can be used with various aggregations to find how ingestion latency behaves.
Examine some percentile of the ingestion time to get insights for large amount of data.
For example, the following query will show you which computers had the highest ingestion time over the prior 8
hours:
Heartbeat
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer
| top 20 by percentile_E2EIngestionLatency_95 desc
The preceding percentile checks are good for finding general trends in latency. To identify a short-term spike in
latency, using the maximum ( max() ) might be more effective.
If you want to drill down on the ingestion time for a specific computer over a period of time, use the following
query, which also visualizes the data from the past day in a graph:
Heartbeat
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by
bin(TimeGenerated,30m)
| render timechart
Use the following query to show computer ingestion time by the country/region they are located in which is based
on their IP address:
Heartbeat
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry
Different data types originating from the agent might have different ingestion latency time, so the previous
queries could be used with other types. Use the following query to examine the ingestion time of various Azure
services:
AzureDiagnostics
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider
Resources that stop responding

In some cases, a resource could stop sending data. To understand if a resource is sending data or not, look at its
most recent record which can be identified by the standard TimeGenerated field.
Use the Heartbeat table to check the availability of a VM, since a heartbeat is sent once a minute by the agent. Use
the following query to list the active computers that haven’t reported heartbeat recently:
Heartbeat
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer
| top 20 by NoHeartbeatPeriod desc
Next steps
Read the Service Level Agreement (SLA) for Azure Monitor.
Overview of Insights in Azure Monitor
Insights provide a customized monitoring experience for particular applications and services. They store data in
the Azure Monitor data platform and leverage other Azure Monitor features for analysis and alerting but may
collect additional data and provide a unique user experience in the Azure portal. Access insights from the Insights
section of the Azure Monitor menu in the Azure portal.
The following sections provide a brief description of the insights that are currently available in Azure Monitor. See
the detailed documentation for details on each.
Application Insights is an extensible Application Performance Management (APM ) service for web developers on
multiple platforms. Use it to monitor your live web application. It works for applications on a wide variety of
platforms including .NET, Node.js and Java EE, hosted on-premises, hybrid, or any public cloud. It also integrates
with your DevOps process and has connection points to a variety of development tools.
See What is Application Insights?.
Azure Monitor for Containers

Azure Monitor for containers monitors the performance of container workloads deployed to either Azure
Container Instances or managed Kubernetes clusters hosted on Azure Kubernetes Service (AKS ). Monitoring your
containers is critical, especially when you're running a production cluster, at scale, with multiple applications.
See Azure Monitor for containers overview.
Azure Monitor for Resource Groups (preview)
Azure Monitor for resource groups helps to triage and diagnose any problems your individual resources
encounter, while offering context as to the health and performance of the resource group as a whole.
See Monitor resource groups with Azure Monitor (preview ).
Azure Monitor for VMs (preview)

Azure Monitor for VMs monitors your Azure virtual machines (VM ) and virtual machine scale sets at scale. It
analyzes the performance and health of your Windows and Linux VMs, and monitors their processes and
dependencies on other resources and external processes.
See What is Azure Monitor for VMs?
Next steps
Learn more about the Azure Monitor data platform leveraged by insights.
Learn about the different data sources used by Azure Monitor and the different kinds of data collected by each
of the insights.
Inventory and data collection details for monitoring
solutions in Azure
Monitoring solutions leverage services in Azure to provide additional insight into the operation of a particular
application or service. Monitoring solutions typically collect log data and provide queries and views to analyze
collected data. You can add monitoring solutions to Azure Monitor for any applications and services that you use.
They are typically available at no cost but collect data that could invoke usage charges.
This article includes a list of montioring solutions available from Microsoft with links to their detailed
documentation. It also provides information on their method and frequency of data collection into Azure Monitor.
You can use the information in this article to identify the different solutions available and to understand the data
flow and connection requirements for different monitoring solutions.
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in a
Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the
terminology to better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.
List of monitoring solutions

The following table lists the monitoring solutions in Azure provided by Microsoft. An entry in the column means
that the solution collects data into Azure Monitor using that method. If a solution has no columns selected, then it
writes directly to Azure Monitor from another Azure service. Follow the link for each one to its detailed
documentation for more information.
Explanations of the columns are as follows:
Microsoft monitoring agent - Agent used on Windows and Linux to run managements pack from SCOM
and monitoring solutions from Azure. In this configuration, the agent is connected directly to Azure Monitor
without being connected to an Operations Manager management group.
Operations Manager - Identical agent as Microsoft monitoring agent. In this configuration, it's connected to
an Operations Manager management group that's connected to Azure Monitor.
Azure Storage - Solution collects data from an Azure storage account.
Operations Manager required? - A connected Operations Manager management group is required for data
collection by the monitoring solution.
Operations Manager agent data sent via management group - If the agent is connected to a SCOM
management group, then data is sent to Azure Monitor from the management server. In this case, the agent
doesn't need to connect directly to Azure Monitor. If this box isn't selected, then data is sent from the agent
directly to Azure Monitor even if the agent is connected to a SCOM management group. It will need to be able
to communicate to Azure Monitor through the Log Analytics gateway.
Collection frequency - Specifies the frequency that data is collected by the monitoring solution.
OPERATIONS
MANAGER
AGENT DATA
MICROSOFT OPERATION OPERATIONS SENT VIA
MONITORIN MONITORIN S MANAGER AZURE MANAGER MANAGEME COLLECTION
G SOLUTION PLATFORM G AGENT AGENT STORAGE REQUIRED? NT GROUP FREQUENCY
Activity Log Azure on

analytics notification
AD Windows • • • 7 days
Assessment
AD Windows • • • 5 days
Replication
Status
Agent Windows • • • 1 minute

Health and Linux
Alert Linux • on arrival

Manageme
nt (Nagios)
Alert Linux • 1 minute

Manageme
nt (Zabbix)
Alert Windows • • • 3 minutes

Manageme
nt
(Operations
Manager)
Azure Site Azure n/a

Recovery
Application Azure on
Insights notification
Connector
(Deprecate
d)
Automation Windows • • n/a

Hybrid
Worker
Azure Azure on
Application notification
Gateway
Analytics
Monitorin Platform Microsoft Operation Azure Operations Operations Collection

g solution monitorin s Manager storage Manager Manager frequency
g agent agent required? agent data
sent via
managem
ent group
OPERATIONS
MANAGER
AGENT DATA
Azure Azure on
Network notification
Security
Group
Analytics
(Deprecate
d)
Azure SQL Windows 1 minute

Analytics
(Preview)
Backup Azure on
notification
Capacity Windows • • • on arrival

and
Performanc
e (Preview)
Change Windows • • • varies

Tracking
Change Linux • varies

Tracking
Containers Windows • • 3 minutes

and Linux
Key Vault Windows on

Analytics notification
Malware Windows • • • hourly

Assessment
Network Windows • • TCP

Performanc handshakes
e Monitor every 5
seconds,
data sent
every 3
minutes
Office 365 Windows on

Analytics notification
(Preview)
OPERATIONS
MANAGER
AGENT DATA
Monitorin Platform Microsoft Operation Azure Operations Operations Collection

g solution monitorin s Manager storage Manager Manager frequency
g agent agent required? agent data
sent via
managem
ent group
Service Windows • 5 minutes

Fabric
Analytics
Service Windows • • 15 seconds

Map and Linux
SQL Windows • • • 7 days

Assessment
SurfaceHub Windows • on arrival
System Windows • • • seven days

Center
Operations
Manager
Assessment
(Preview)
Update Windows • • • at least 2

Manageme times per
nt day and 15
minutes
after
installing an
update
Upgrade Windows • 2 days

Readiness
VMware Linux • 3 minutes

Monitoring
(Deprecate
d)
Wire Data Windows • • 1 minute

2.0 (2012 R2 /
(Preview) 8.1 or later)
Next steps
Learn how to install and use monitoring solutions.
Learn how to create queries to analyze data collected by monitoring solutions.
Log Analytics data security
This document is intended to provide information specific to Log Analytics, which is a feature of Azure Monitor, to
supplement the information on Azure Trust Center.
This article explains how data is collected, processed, and secured by Log Analytics. You can use agents to connect
to the web service, use System Center Operations Manager to collect operational data, or retrieve data from Azure
diagnostics for use by Log Analytics.
The Log Analytics service manages your cloud-based data securely by using the following methods:
Data segregation
Data retention
Physical security
Incident management
Compliance
Security standards certifications
Contact us with any questions, suggestions, or issues about any of the following information, including our security
policies at Azure support options.
Sending data securely using TLS 1.2

To insure the security of data in transit to Log Analytics, we strongly encourage you to configure the agent to use at
least Transport Layer Security (TLS ) 1.2. Older versions of TLS/Secure Sockets Layer (SSL ) have been found to be
vulnerable and while they still currently work to allow backwards compatibility, they are not recommended, and
the industry is quickly moving to abandon support for these older protocols.
The PCI Security Standards Council has set a deadline of June 30th, 2018 to disable older versions of TLS/SSL
and upgrade to more secure protocols. Once Azure drops legacy support, if your agents cannot communicate over
at least TLS 1.2 you would not be able to send data to Log Analytics.
We do not recommend explicitly setting your agent to only use TLS 1.2 unless absolutely necessary, as it can break
platform level security features that allow you to automatically detect and take advantage of newer more secure
protocols as they become available, such as TLS 1.3.
Platform-specific guidance
PLATFORM/LANGUAGE SUPPORT MORE INFORMATION
Linux Linux distributions tend to rely on Check the OpenSSL Changelog to

OpenSSL for TLS 1.2 support. confirm your version of OpenSSL is
supported.
Windows 8.0 - 10 Supported, and enabled by default. To confirm that you are still using the
default settings.
Windows Server 2012 - 2016 Supported, and enabled by default. To confirm that you are still using the
default settings
Windows 7 SP1 and Windows Server Supported, but not enabled by default. See the Transport Layer Security (TLS)
2008 R2 SP1 registry settings page for details on
how to enable.
Data segregation
After your data is ingested by the Log Analytics service, the data is kept logically separate on each component
throughout the service. All data is tagged per workspace. This tagging persists throughout the data lifecycle, and it
is enforced at each layer of the service. Your data is stored in a dedicated database in the storage cluster in the
region you have selected.
Data retention
Indexed log search data is stored and retained according to your pricing plan. For more information, see Log
Analytics Pricing.
As part of your subscription agreement, Microsoft will retain your data per the terms of the agreement. When
customer data is removed, no physical drives are destroyed.
The following table lists some of the available solutions and provides examples of the type of data they collect.
SOLUTION DATA TYPES
Capacity and Performance Performance data and metadata
Update Management Metadata and state data
Log Management User-defined event logs, Windows Event Logs and/or IIS Logs
Change Tracking Software inventory, Windows service and Linux daemon

metadata, and Windows/Linux file metadata
SQL and Active Directory Assessment WMI data, registry data, performance data, and SQL Server
dynamic management view results
The following table shows examples of data types:
DATA TYPE FIELDS
Alert Alert Name, Alert Description, BaseManagedEntityId, Problem

ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity,
Category, Owner, ResolvedBy, TimeRaised, TimeAdded,
LastModified, LastModifiedBy,
LastModifiedExceptRepeatCount, TimeResolved,
TimeResolutionStateLastModified,
TimeResolutionStateLastModifiedInDB, RepeatCount
Configuration CustomerID, AgentID, EntityID, ManagedTypeID,

ManagedTypePropertyID, CurrentValue, ChangeDate
DATA TYPE FIELDS
Event EventId, EventOriginalID, BaseManagedEntityInternalId,

RuleId, PublisherId, PublisherName, FullNumber, Number,
Category, ChannelLevel, LoggingComputer, EventData,
EventParameters, TimeGenerated, TimeAdded
Note: When you write events with custom fields in to the
Windows event log, Log Analytics collects them.
Metadata BaseManagedEntityId, ObjectStatus, OrganizationalUnit,

ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName,
IPAddress, ForestDNSName, NetbiosComputerName,
VirtualMachineName, LastInventoryDate,
HostServerNameIsVirtualMachine, IP Address,
NetbiosDomainName, LogicalProcessors, DNSName,
DisplayName, DomainDnsName, ActiveDirectorySite,
PrincipalName, OffsetInMinuteFromGreenwichTime
Performance ObjectName, CounterName, PerfmonInstanceName,

PerformanceDataId, PerformanceSourceInternalID,
SampleValue, TimeSampled, TimeAdded
State StateChangeEventId, StateId, NewHealthState, OldHealthState,

Context, TimeGenerated, TimeAdded, StateId2,
BaseManagedEntityId, MonitorId, HealthState, LastModified,
LastGreenAlertGenerated, DatabaseTimeModified
Physical security
The Log Analytics service is managed by Microsoft personnel and all activities are logged and can be audited. Log
Analytics is operated as an Azure Service and meets all Azure Compliance and Security requirements. You can
view details about the physical security of Azure assets on page 18 of the Microsoft Azure Security Overview.
Physical access rights to secure areas are changed within one business day for anyone who no longer has
responsibility for the Log Analytics service, including transfer and termination. You can read about the global
physical infrastructure we use at Microsoft Datacenters.
Incident management
Log Analytics has an incident management process that all Microsoft services adhere to. To summarize, we:
Use a shared responsibility model where a portion of security responsibility belongs to Microsoft and a portion
belongs to the customer
Manage Azure security incidents:
Start an investigation upon detection of an incident
Assess the impact and severity of an incident by an on-call incident response team member. Based on
evidence, the assessment may or may not result in further escalation to the security response team.
Diagnose an incident by security response experts to conduct the technical or forensic investigation,
identify containment, mitigation, and workaround strategies. If the security team believes that customer
data may have become exposed to an unlawful or unauthorized individual, parallel execution of the
Customer Incident Notification process begins in parallel.
Stabilize and recover from the incident. The incident response team creates a recovery plan to mitigate
the issue. Crisis containment steps such as quarantining impacted systems may occur immediately and in
parallel with diagnosis. Longer term mitigations may be planned which occur after the immediate risk
has passed.
Close the incident and conduct a post-mortem. The incident response team creates a post-mortem that
outlines the details of the incident, with the intention to revise policies, procedures, and processes to
prevent a recurrence of the event.
Notify customers of security incidents:
Determine the scope of impacted customers and to provide anybody who is impacted as detailed a
notice as possible
Create a notice to provide customers with detailed enough information so that they can perform an
investigation on their end and meet any commitments they have made to their end users while not
unduly delaying the notification process.
Confirm and declare the incident, as necessary.
Notify customers with an incident notification without unreasonable delay and in accordance with any
legal or contractual commitment. Notifications of security incidents are delivered to one or more of a
customer's administrators by any means Microsoft selects, including via email.
Conduct team readiness and training:
Microsoft personnel are required to complete security and awareness training, which helps them to
identify and report suspected security issues.
Operators working on the Microsoft Azure service have addition training obligations surrounding their
access to sensitive systems hosting customer data.
Microsoft security response personnel receive specialized training for their roles
If loss of any customer data occurs, we notify each customer within one day. However, customer data loss has
never occurred with the service.
For more information about how Microsoft responds to security incidents, see Microsoft Azure Security Response
in the Cloud.
Compliance
The Log Analytics software development and service team's information security and governance program
supports its business requirements and adheres to laws and regulations as described at Microsoft Azure Trust
Center and Microsoft Trust Center Compliance. How Log Analytics establishes security requirements, identifies
security controls, manages, and monitors risks are also described there. Annually, we review polices, standards,
procedures, and guidelines.
Each development team member receives formal application security training. Internally, we use a version control
system for software development. Each software project is protected by the version control system.
Microsoft has a security and compliance team that oversees and assesses all services in Microsoft. Information
security officers make up the team and they are not associated with the engineering teams that develops Log
Analytics. The security officers have their own management chain and conduct independent assessments of
products and services to ensure security and compliance.
Microsoft's board of directors is notified by an annual report about all information security programs at Microsoft.
The Log Analytics software development and service team are actively working with the Microsoft Legal and
Compliance teams and other industry partners to acquire various certifications.
Certifications and attestations

Azure Log Analytics meets the following requirements:
ISO/IEC 27001
ISO/IEC 27018:2014
ISO 22301
Payment Card Industry (PCI Compliant) Data Security Standard (PCI DSS ) by the PCI Security Standards
Council.
Service Organization Controls (SOC ) 1 Type 1 and SOC 2 Type 1 compliant
HIPAA and HITECH for companies that have a HIPAA Business Associate Agreement
Windows Common Engineering Criteria
Microsoft Trustworthy Computing
As an Azure service, the components that Log Analytics uses adhere to Azure compliance requirements. You
can read more at Microsoft Trust Center Compliance.
NOTE
In some certifications/attestations, Log Analytics is listed under its former name of Operational Insights.
Cloud computing security data flow

The following diagram shows a cloud security architecture as the flow of information from your company and how
it is secured as is moves to the Log Analytics service, ultimately seen by you in the Azure portal. More information
about each step follows the diagram.
1. Sign up for Log Analytics and collect data

For your organization to send data to Log Analytics, you configure a Windows or Linux agent running on Azure
virtual machines, or on virtual or physical computers in your environment or other cloud provider. If you use
Operations Manager, from the management group you configure the Operations Manager agent. Users (which
might be you, other individual users, or a group of people) create one or more Log Analytics workspaces, and
register agents by using one of the following accounts:
Organizational ID
Microsoft Account - Outlook, Office Live, MSN
A Log Analytics workspace is where data is collected, aggregated, analyzed, and presented. A workspace is
primarily used as a means to partition data, and each workspace is unique. For example, you might want to have
your production data managed with one workspace and your test data managed with another workspace.
Workspaces also help an administrator control user access to the data. Each workspace can have multiple user
accounts associated with it, and each user account can access multiple Log Analytics workspaces. You create
workspaces based on datacenter region.
For Operations Manager, the Operations Manager management group establishes a connection with the Log
Analytics service. You then configure which agent-managed systems in the management group are allowed to
collect and send data to the service. Depending on the solution you have enabled, data from these solutions are
either sent directly from an Operations Manager management server to the Log Analytics service, or because of
the volume of data collected by the agent-managed system, are sent directly from the agent to the service. For
systems not monitored by Operations Manager, each connects securely to the Log Analytics service directly.
All communication between connected systems and the Log Analytics service is encrypted. The TLS (HTTPS )
protocol is used for encryption. The Microsoft SDL process is followed to ensure Log Analytics is up-to-date with
the most recent advances in cryptographic protocols.
Each type of agent collects data for Log Analytics. The type of data that is collected is depends on the types of
solutions used. You can see a summary of data collection at Add Log Analytics solutions from the Solutions
Gallery. Additionally, more detailed collection information is available for most solutions. A solution is a bundle of
predefined views, log search queries, data collection rules, and processing logic. Only administrators can use Log
Analytics to import a solution. After the solution is imported, it is moved to the Operations Manager management
servers (if used), and then to any agents that you have chosen. Afterward, the agents collect the data.
2. Send data from agents

You register all agent types with an enrollment key and a secure connection is established between the agent and
the Log Analytics service using certificate-based authentication and SSL with port 443. Log Analytics uses a secret
store to generate and maintain keys. Private keys are rotated every 90 days and are stored in Azure and are
managed by the Azure operations who follow strict regulatory and compliance practices.
With Operations Manager, the management group registered with a Log Analytics workspace establishes a secure
HTTPS connection with an Operations Manager management server.
For Windows or Linux agents running on Azure virtual machines, a read-only storage key is used to read
diagnostic events in Azure tables.
With any agent reporting to an Operations Manager management group that is integrated with Log Analytics, if
the management server is unable to communicate with the service for any reason, the collected data is stored
locally in a temporary cache on the management server. They try to resend the data every eight minutes for two
hours. For data that bypasses the management server and is sent directly to Log Analytics, the behavior is
consistent with the Windows agent.
The Windows or management server agent cached data is protected by the operating system's credential store. If
the service cannot process the data after two hours, the agents will queue the data. If the queue becomes full, the
agent starts dropping data types, starting with performance data. The agent queue limit is a registry key so you can
modify it, if necessary. Collected data is compressed and sent to the service, bypassing the Operations Manager
management group databases, so it does not add any load to them. After the collected data is sent, it is removed
from the cache.
As described above, data from the management server or direct-connected agents is sent over SSL to Microsoft
Azure datacenters. Optionally, you can use ExpressRoute to provide additional security for the data. ExpressRoute
is a way to directly connect to Azure from your existing WAN network, such as a multi-protocol label switching
(MPLS ) VPN, provided by a network service provider. For more information, see ExpressRoute.
3. The Log Analytics service receives and processes data

The Log Analytics service ensures that incoming data is from a trusted source by validating certificates and the
data integrity with Azure authentication. The unprocessed raw data is then stored in an Azure Event Hub in the
region the data will eventually be stored at rest. The type of data that is stored depends on the types of solutions
that were imported and used to collect data. Then, the Log Analytics service processes the raw data and ingests it
into the database.
The retention period of collected data stored in the database depends on the selected pricing plan. For the Free tier,
collected data is available for seven days. For the Paid tier, collected data is available for 31 days by default, but can
be extended to 730 days. Data is stored encrypted at rest in Azure storage, to ensure data confidentiality, and the
data is replicated within the local region using locally redundant storage (LRS ). The last two weeks of data are also
stored in SSD -based cache and this cache is encrypted.
4. Use Log Analytics to access the data

To access your Log Analytics workspace, you sign into the Azure portal using the organizational account or
Microsoft account that you set up previously. All traffic between the portal and Log Analytics service is sent over a
secure HTTPS channel. When using the portal, a session ID is generated on the user client (web browser) and data
is stored in a local cache until the session is terminated. When terminated, the cache is deleted. Client-side cookies,
which do not contain personally identifiable information, are not automatically removed. Session cookies are
marked HTTPOnly and are secured. After a pre-determined idle period, the Azure portal session is terminated.
Next steps
Learn how to collect data with Log Analytics for your Azure VMs following the Azure VM quickstart.
If you are looking to collect data from physical or virtual Windows or Linux computers in your environment,
see the Quickstart for Linux computers or Quickstart for Windows computers
Guidance for personal data stored in Log Analytics
and Application Insights
Log Analytics is a data store where personal data is likely to be found. Application Insights stores its data in a Log
Analytics partition. This article will discuss where in Log Analytics and Application Insights such data is typically
found, as well as the capabilities available to you to handle such data.
NOTE
For the purposes of this article log data refers to data sent to a Log Analytics workspace, while application data refers to
data collected by Application Insights.
NOTE
For information about viewing or deleting personal data, see Azure Data Subject Requests for the GDPR. For more
information about GDPR, see the GDPR section of the Service Trust portal.
Strategy for personal data handling

While it will be up to you and your company to ultimately determine the strategy with which you will handle your
private data (if at all), the following are some possible approaches. They are listed in order of preference from a
technical point of view from most to least preferable:
Where possible, stop collection of, obfuscate, anonymize, or otherwise adjust the data being collected to exclude
it from being considered "private". This is by far the preferred approach, saving you the need to create a very
costly and impactful data handling strategy.
Where not possible, attempt to normalize the data to reduce the impact on the data platform and performance.
For example, instead of logging an explicit User ID, create a lookup data that will correlate the username and
their details to an internal ID that can then be logged elsewhere. That way, should one of your users ask you to
delete their personal information, it is possible that only deleting the row in the lookup table corresponding to
the user will be sufficient.
Finally, if private data must be collected, build a process around the purge API path and the existing query API
path to meet any obligations you may have around exporting and deleting any private data associated with a
user.
Where to look for private data in Log Analytics?

Log Analytics is a flexible store, which while prescribing a schema to your data, allows you to override every field
with custom values. Additionally, any custom schema can be ingested. As such, it is impossible to say exactly where
Private data will be found in your specific workspace. The following locations, however, are good starting points in
your inventory:
Log data
IP addresses: Log Analytics collects a variety of IP information across many different tables. For example, the
following query shows all tables where IPv4 addresses have been collected over the last 24 hours:
search *
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally
provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| summarize count() by $table
User IDs: User IDs are found in a large variety of solutions and tables. You can look for a particular username
across your entire dataset using the search command:
search "[username goes here]"
Remember to look not only for human-readable user names but also GUIDs that can directly be traced back to
a particular user!
Device IDs: Like user IDs, device IDs are sometimes considered "private". Use the same approach as listed
above for user IDs to identify tables where this might be a concern.
Custom data: Log Analytics allows the collection in a variety of methods: custom logs and custom fields, the
HTTP Data Collector API , and custom data collected as part of system event logs. All of these are susceptible to
containing private data, and should be examined to verify whether any such data exists.
Solution-captured data: Because the solution mechanism is an open-ended one, we recommend reviewing all
tables generated by solutions to ensure compliance.
Application data
IP addresses: While Application Insights will by default obfuscate all IP address fields to "0.0.0.0", it is a fairly
common pattern to override this value with the actual user IP to maintain session information. The Analytics
query below can be used to find any table that contains values in the IP address column other than "0.0.0.0"
over the last 24 hours:
search client_IP != "0.0.0.0"

| where timestamp > ago(1d)
| summarize numNonObfuscatedIPs_24h = count() by $table
User IDs: By default, Application Insights will use randomly generated IDs for user and session tracking.
However, it is common to see these fields overridden to store an ID more relevant to the application. For
example: usernames, AAD GUIDs, etc. These IDs are often considered to be in-scope as personal data, and
therefore, should be handled appropriately. Our recommendation is always to attempt to obfuscate or
anonymize these IDs. Fields where these values are commonly found include session_Id, user_Id,
user_AuthenticatedId, user_AccountId, as well as customDimensions.
Custom data: Application Insights allows you to append a set of custom dimensions to any data type. These
dimensions can be any data. Use the following query to identify any custom dimensions collected over the last
24 hours:
search *
| where isnotempty(customDimensions)
| project $table, timestamp, name, customDimensions
In-memory and in-transit data: Application Insights will track exceptions, requests, dependency calls, and traces.
Private data can often be collected at the code and HTTP call level. Review the exceptions, requests,
dependencies, and traces tables to identify any such data. Use telemetry initializers where possible to obfuscate
this data.
Snapshot Debugger captures: The Snapshot Debugger feature in Application Insights allows you to collect
debug snapshots whenever an exception is caught on the production instance of your application. Snapshots
will expose the full stack trace leading to the exceptions as well as the values for local variables at every step in
the stack. Unfortunately, this feature does not allow for selective deletion of snap points, or programmatic
access to data within the snapshot. Therefore, if the default snapshot retention rate does not satisfy your
compliance requirements, the recommendation is to turn off the feature.
How to export and delete private data

As mentioned in the strategy for personal data handling section earlier, it is strongly recommended to if it all
possible, to restructure your data collection policy to disable the collection of private data, obfuscating or
anonymizing it, or otherwise modifying it to remove it from being considered "private". Handling the data will
foremost result in costs to you and your team to define and automate a strategy, build an interface for your
customers to interact with their data through, and ongoing maintenance costs. Further, it is computationally costly
for Log Analytics and Application Insights, and a large volume of concurrent query or purge API calls have the
potential to negatively impact all other interaction with Log Analytics functionality. That said, there are indeed
some valid scenarios where private data must be collected. For these cases, data should be handled as described in
this section.
NOTE
This article provides steps for how to delete personal data from the device or service and can be used to support your
obligations under the GDPR. If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.
View and export

For both view and export data requests, the Log Analytics query API or the Application Insights query API should
be used. Logic to convert the shape of the data to an appropriate one to deliver to your users will be up to you to
implement. Azure Functions makes a great place to host such logic.
IMPORTANT
While the vast majority of purge operations may complete much quicker than the SLA, the formal SLA for the completion
of purge operations is set at 30 days due to their heavy impact on the data platform used. This is an automated process;
there is no way to request that an operation be handled faster.
Delete
WARNING
Deletes in Log Analytics are destructive and non-reversible! Please use extreme caution in their execution.
We have made available as part of a privacy handling a purge API path. This path should be used sparingly due to
the risk associated with doing so, the potential performance impact, and the potential to skew all-up aggregations,
measurements, and other aspects of your Log Analytics data. See the Strategy for personal data handling section
for alternative approaches to handle private data.
Purge is a highly privileged operation that no app or user in Azure (including even the resource owner) will have
permissions to execute without explicitly being granted a role in Azure Resource Manager. This role is Data Purger
and should be cautiously delegated due to the potential for data loss.
IMPORTANT
In order to manage system resources, purge requests are throttled at 50 requests per hour. You should batch the execution
of purge requests by sending a single command whose predicate includes all user identities that require purging. Use the in
operator to specify multiple identities. You should run the query before executing the purge request to verify that the results
are expected.
Once the Azure Resource Manager role has been assigned, two new API paths are available:
Log data
POST purge - takes an object specifying parameters of data to delete and returns a reference GUID
GET purge status - the POST purge call will return an 'x-ms-status-location' header that will include a URL
that you can call to determine the status of your purge API. For example:
x-ms-status-location:
https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers
/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-
version=2015-03-20
IMPORTANT
While we expect the vast majority of purge operations to complete much quicker than our SLA, due to their heavy impact on
the data platform used by Log Analytics, the formal SLA for the completion of purge operations is set at 30 days.
Application data
POST purge - takes an object specifying parameters of data to delete and returns a reference GUID
GET purge status - the POST purge call will return an 'x-ms-status-location' header that will include a URL
that you can call to determine the status of your purge API. For example:
x-ms-status-location:
https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers
/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-
01
IMPORTANT
While the vast majority of purge operations may complete much quicker than the SLA, due to their heavy impact on the data
platform used by Application Insights, the formal SLA for the completion of purge operations is set at 30 days.
Next steps
To learn more about how Log Analytics data is collected, processed, and secured, see Log Analytics data
security.
To learn more about how Application Insights data is collected, processed, and secured, see Application Insights
data security.
Data collection, retention and storage in Application
Insights
When you install Azure Application Insights SDK in your app, it sends telemetry about your app to the Cloud.
Naturally, responsible developers want to know exactly what data is sent, what happens to the data, and how they
can keep control of it. In particular, could sensitive data be sent, where is it stored, and how secure is it?
First, the short answer:
The standard telemetry modules that run "out of the box" are unlikely to send sensitive data to the service. The
telemetry is concerned with load, performance and usage metrics, exception reports, and other diagnostic data.
The main user data visible in the diagnostic reports are URLs; but your app shouldn't in any case put sensitive
data in plain text in a URL.
You can write code that sends additional custom telemetry to help you with diagnostics and monitoring usage.
(This extensibility is a great feature of Application Insights.) It would be possible, by mistake, to write this code
so that it includes personal and other sensitive data. If your application works with such data, you should apply
a thorough review processes to all the code you write.
While developing and testing your app, it's easy to inspect what's being sent by the SDK. The data appears in
the debugging output windows of the IDE and browser.
The data is held in Microsoft Azure servers in the USA or Europe. (But your app can run anywhere.) Azure has
strong security processes and meets a broad range of compliance standards. Only you and your designated
team have access to your data. Microsoft staff can have restricted access to it only under specific limited
circumstances with your knowledge. It's encrypted in transit and at rest.
The rest of this article elaborates more fully on these answers. It's designed to be self-contained, so that you can
show it to colleagues who aren't part of your immediate team.
What is Application Insights?

Azure Application Insights is a service provided by Microsoft that helps you improve the performance and
usability of your live application. It monitors your application all the time it's running, both during testing and
after you've published or deployed it. Application Insights creates charts and tables that show you, for example,
what times of day you get most users, how responsive the app is, and how well it is served by any external
services that it depends on. If there are crashes, failures or performance issues, you can search through the
telemetry data in detail to diagnose the cause. And the service will send you emails if there are any changes in the
availability and performance of your app.
In order to get this functionality, you install an Application Insights SDK in your application, which becomes part
of its code. When your app is running, the SDK monitors its operation and sends telemetry to the Application
Insights service. This is a cloud service hosted by Microsoft Azure. (But Application Insights works for any
applications, not just those that are hosted in Azure.)
The Application Insights service stores and analyzes the telemetry. To see the analysis or search through the
stored telemetry, you sign in to your Azure account and open the Application Insights resource for your
application. You can also share access to the data with other members of your team, or with specified Azure
subscribers.
You can have data exported from the Application Insights service, for example to a database or to external tools.
You provide each tool with a special key that you obtain from the service. The key can be revoked if necessary.
Application Insights SDKs are available for a range of application types: web services hosted in your own Java EE
or ASP.NET servers, or in Azure; web clients - that is, the code running in a web page; desktop apps and services;
device apps such as Windows Phone, iOS, and Android. They all send telemetry to the same service.
What data does it collect?

How is the data is collected?
There are three sources of data:
The SDK, which you integrate with your app either in development or at run time. There are different SDKs
for different application types. There's also an SDK for web pages, which loads into the end-user's browser
along with the page.
Each SDK has a number of modules, which use different techniques to collect different types of
telemetry.
If you install the SDK in development, you can use its API to send your own telemetry, in addition to the
standard modules. This custom telemetry can include any data you want to send.
In some web servers, there are also agents that run alongside the app and send telemetry about CPU,
memory, and network occupancy. For example, Azure VMs, Docker hosts, and Java EE servers can have
such agents.
Availability tests are processes run by Microsoft that send requests to your web app at regular intervals.
The results are sent to the Application Insights service.
What kinds of data are collected?
The main categories are:
Web server telemetry - HTTP requests. Uri, time taken to process the request, response code, client IP address.
Session id.
Web pages - Page, user and session counts. Page load times. Exceptions. Ajax calls.
Performance counters - Memory, CPU, IO, Network occupancy.
Client and server context - OS, locale, device type, browser, screen resolution.
Exceptions and crashes - stack dumps, build id, CPU type.
Dependencies - calls to external services such as REST, SQL, AJAX. URI or connection string, duration,
success, command.
Availability tests - duration of test and steps, responses.
Trace logs and custom telemetry - anything you code into your logs or telemetry.
More detail.
How can I verify what's being collected?

If you're developing the app using Visual Studio, run the app in debug mode (F5). The telemetry appears in the
Output window. From there, you can copy it and format it as JSON for easy inspection.
There's also a more readable view in the Diagnostics window.
For web pages, open your browser's debugging window.
Can I write code to filter the telemetry before it is sent?

This would be possible by writing a telemetry processor plugin.
How long is the data kept?

Raw data points (that is, items that you can query in Analytics and inspect in Search) are kept for up to 730 days.
You can select a retention duration of 30, 60, 90, 120, 180, 270, 365, 550 or 730 days. If you need to keep data
longer than 730 days, you can use Continuous Export to copy it to a storage account during data ingestion.
Data kept longer than 90 days will incur addition charges. Learn more about Application Insights pricing on the
Azure Monitor pricing page.
Aggregated data (that is, counts, averages and other statistical data that you see in Metric Explorer) are retained at
a grain of 1 minute for 90 days.
Debug snapshots are stored for fifteen days. This retention policy is set on a per-application basis. If you need to
increase this value, you can request an increase by opening a support case in the Azure portal.
Who can access the data?

The data is visible to you and, if you have an organization account, your team members.
It can be exported by you and your team members and could be copied to other locations and passed on to other
people.
What does Microsoft do with the information my app sends to Application Insights?
Microsoft uses the data only in order to provide the service to you.
Where is the data held?

You can select the location when you create a new Application Insights resource. Know more about Application
Insights availability per region here.
Does that mean my app has to be hosted in the USA, Europe or Southeast Asia?
No. Your application can run anywhere, either in your own on-premises hosts or in the cloud.
How secure is my data?

Application Insights is an Azure Service. Security policies are described in the Azure Security, Privacy, and
Compliance white paper.
The data is stored in Microsoft Azure servers. For accounts in the Azure Portal, account restrictions are described
in the Azure Security, Privacy, and Compliance document.
Access to your data by Microsoft personnel is restricted. We access your data only with your permission and if it is
necessary to support your use of Application Insights.
Data in aggregate across all our customers' applications (such as data rates and average size of traces) is used to
improve Application Insights.
Could someone else's telemetry interfere with my Application Insights data?
They could send additional telemetry to your account by using the instrumentation key, which can be found in the
code of your web pages. With enough additional data, your metrics would not correctly represent your app's
performance and usage.
If you share code with other projects, remember to remove your instrumentation key.
Is the data encrypted?

All data is encrypted at rest and as it moves between data centers.
Is the data encrypted in transit from my application to Application Insights servers?
Yes, we use https to send data to the portal from nearly all SDKs, including web servers, devices and HTTPS web
pages. The only exception is data sent from plain HTTP web pages.
Does the SDK create temporary local storage?

Yes, certain Telemetry Channels will persist data locally if an endpoint cannot be reached. Please review below to
see which frameworks and telemetry channels are affected.
Telemetry channels that utilize local storage create temp files in the TEMP or APPDATA directories which are
restricted to the specific account running your application. This may happen when an endpoint was temporarily
unavailable or you hit the throttling limit. Once this issue is resolved, the telemetry channel will resume sending
all the new and persisted data.
This persisted data is not encrypted locally. If this is a concern, review the data and restrict the collection of private
data. (See How to export and delete private data for more information.)
If a customer needs to configure this directory with specific security requirements it can be configured per
framework. Please make sure that the process running your application has write access to this directory, but also
make sure this directory is protected to avoid telemetry being read by unintended users.
Java
C:\Users\username\AppData\Local\Temp is used for persisting data. This location isn't configurable from the config
directory and the permissions to access this folder are restricted to the specific user with required credentials.
(See implementation here.)
.Net
By default uses the current user’s local app data folder
ServerTelemetryChannel
%localAppData%\Microsoft\ApplicationInsights or temp folder %TMP% . ( See implementation here.)
Via configuration file:
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
Microsoft.AI.ServerTelemetryChannel">
<StorageFolder>D:\NewTestFolder</StorageFolder>
</TelemetryChannel>
Via code:
Remove ServerTelemetryChannel from configuration file
Add this snippet to your configuration:
ServerTelemetryChannel channel = new ServerTelemetryChannel();

channel.StorageFolder = @"D:\NewTestFolder";
channel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = channel;
NetCore
By default ServerTelemetryChannel uses the current user’s local app data folder
%localAppData%\Microsoft\ApplicationInsights or temp folder %TMP% . ( See implementation here.) In a Linux
environment, local storage will be disabled unless a storage folder is specified.
The following code snippet shows how to set ServerTelemetryChannel.StorageFolder in the ConfigureServices()
method of your Startup.cs class:
services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder =

"/tmp/myfolder"});
(See AspNetCore Custom Configuration for more information. )

Node.js
By default %TEMP%/appInsights-node{INSTRUMENTATION KEY} is used for persisting data. Permissions to access this
folder are restricted to the current user and Administrators. (See implementation here.)
The folder prefix appInsights-node can be overridden by changing the runtime value of the static variable
Sender.TEMPDIR_PREFIX found in Sender.ts.
How do I send data to Application Insights using TLS 1.2?

To insure the security of data in transit to the Application Insights endpoints, we strongly encourage customers to
configure their application to use at least Transport Layer Security (TLS ) 1.2. Older versions of TLS/Secure
Sockets Layer (SSL ) have been found to be vulnerable and while they still currently work to allow backwards
compatibility, they are not recommended, and the industry is quickly moving to abandon support for these
older protocols.
The PCI Security Standards Council has set a deadline of June 30th, 2018 to disable older versions of TLS/SSL
and upgrade to more secure protocols. Once Azure drops legacy support, if your application/clients cannot
communicate over at least TLS 1.2 you would not be able to send data to Application Insights. The approach you
take to test and validate your application's TLS support will vary depending on the operating system/platform as
well as the language/framework your application uses.
We do not recommend explicitly setting your application to only use TLS 1.2 unless absolutely necessary as this
can break platform level security features that allow you to automatically detect and take advantage of newer
more secure protocols as they become available such as TLS 1.3. We recommend performing a thorough audit of
your application's code to check for hardcoding of specific TLS/SSL versions.
Platform/Language specific guidance
Azure App Services Supported, configuration may be Support was announced in April 2018.
required. Read the announcement for
configuration details.
Azure Function Apps Supported, configuration may be Support was announced in April 2018.
required. Read the announcement for
configuration details.
.NET Supported, configuration varies by For detailed configuration info for .NET
version. 4.7 and earlier versions refer to these
instructions.
Status Monitor Supported, configuration required Status Monitor relies on OS

Configuration + .NET Configuration to
support TLS 1.2.
Node.js Supported, in v10.5.0, configuration Use the official Node.js TLS/SSL

may be required. documentation for any application
specific configuration.
Java Supported, JDK support for TLS 1.2 was JDK 8 uses TLS 1.2 by default.
added in JDK 6 update 121 and JDK 7.
Linux Linux distributions tend to rely on Check the OpenSSL Changelog to

OpenSSL for TLS 1.2 support. confirm your version of OpenSSL is
supported.
Windows 8.0 - 10 Supported, and enabled by default. To confirm that you are still using the
default settings.
Windows Server 2012 - 2016 Supported, and enabled by default. To confirm that you are still using the
default settings
Windows 7 SP1 and Windows Server Supported, but not enabled by default. See the Transport Layer Security (TLS)
2008 R2 SP1 registry settings page for details on
how to enable.
Windows Server 2008 SP2 Support for TLS 1.2 requires an update. See Update to add support for TLS 1.2
in Windows Server 2008 SP2.
Windows Vista Not Supported. N/A

Check what version of OpenSSL your Linux distribution is running
To check what version of OpenSSL you have installed, open the terminal and run:
openssl version -a
Run a test TLS 1.2 transaction on Linux

To run a basic preliminary test to see if your Linux system can communicate over TLS 1.2. Open the terminal and
run:
openssl s_client -connect bing.com:443 -tls1_2
Personal data stored in Application Insights

Our Application Insights personal data article discusses this issue in-depth.
Can my users turn off Application Insights?
Not directly. We don't provide a switch that your users can operate to turn off Application Insights.
However, you can implement such a feature in your application. All the SDKs include an API setting that turns off
telemetry collection.
Data sent by Application Insights

The SDKs vary between platforms, and there are several components that you can install. (Refer to Application
Insights - overview.) Each component sends different data.
Classes of data sent in different scenarios
YOUR ACTION DATA CLASSES COLLECTED (SEE NEX T TABLE)
Add Application Insights SDK to a .NET web project ServerContext

Inferred
Perf counters
Requests
Exceptions
Session
users
Install Status Monitor on IIS Dependencies

ServerContext
Inferred
Perf counters
Add Application Insights SDK to a Java web app ServerContext

Inferred
Request
Session
users
Add JavaScript SDK to web page ClientContext

Inferred
Page
ClientPerf
Ajax
Define default properties Properties on all standard and custom events

YOUR ACTION DATA CLASSES COLLECTED (SEE NEX T TABLE)
Call TrackMetric Numeric values

Properties
Call Track* Event name

Properties
Call TrackException Exceptions

Stack dump
Properties
SDK can't collect data. For example: SDK diagnostics

- can't access perf counters
- exception in telemetry initializer
For SDKs for other platforms, see their documents.

The classes of collected data
COLLECTED DATA CLASS INCLUDES (NOT AN EXHAUSTIVE LIST)
Properties Any data - determined by your code
DeviceContext Id, IP, Locale, Device model, network, network type, OEM
name, screen resolution, Role Instance, Role Name, Device
Type
ClientContext OS, locale, language, network, window resolution
Session session id
ServerContext Machine name, locale, OS, device, user session, user context,
operation
Inferred geo location from IP address, timestamp, OS, browser
Metrics Metric name and value
Events Event name and value
PageViews URL and page name or screen name
Client perf URL/page name, browser load time
Ajax HTTP calls from web page to server
Requests URL, duration, response code
Dependencies Type(SQL, HTTP, ...), connection string or URI, sync/async,

duration, success, SQL statement (with Status Monitor)
Exceptions Type, message, call stacks, source file and line number, thread
id
COLLECTED DATA CLASS INCLUDES (NOT AN EXHAUSTIVE LIST)
Crashes Process id, parent process id, crash thread id; application
patch, id, build; exception type, address, reason; obfuscated
symbols and registers, binary start and end addresses, binary
name and path, cpu type
Trace Message and severity level
Perf counters Processor time, available memory, request rate, exception

rate, process private bytes, IO rate, request duration, request
queue length
Availability Web test response code, duration of each test step, test
name, timestamp, success, response time, test location
SDK diagnostics Trace message or Exception
You can switch off some of the data by editing ApplicationInsights.config
NOTE
Client IP is used to infer geographic location, but by default IP data is no longer stored and all zeroes are written to the
associated field. To understand more about personal data handling we recommend this article. If you need to store IP
address data our IP address collection article will walk you through your options.
Credits
This product includes GeoLite2 data created by MaxMind, available from https://www.maxmind.com.
Overview of alerts in Microsoft Azure
This article describes what alerts are, their benefits, and how to get started using them.
What are alerts in Microsoft Azure?

Alerts proactively notify you when important conditions are found in your monitoring data. They allow you to
identify and address issues before the users of your system notice them.
This article discusses the unified alert experience in Azure Monitor, which includes alerts that were previously
managed by Log Analytics and Application Insights. The previous alert experience and alert types are called
classic alerts. You can view this older experience and older alert type by selecting View classic alerts at the
top of the alert page.
Overview
The diagram below represents the flow of alerts.
Alert Rule
Target Resource
Signal
Criteria /
Logic Test
Action Group Monitor

condition
Actions to do Alert State
Alert rules are separated from alerts and the actions taken when an alert fires. The alert rule captures the
target and criteria for alerting. The alert rule can be in an enabled or a disabled state. Alerts only fire when
enabled.
The following are key attributes of an alert rule:
Target Resource: Defines the scope and signals available for alerting. A target can be any Azure resource.
Example targets: a virtual machine, a storage account, a virtual machine scale set, a Log Analytics workspace,
or an Application Insights resource. For certain resources (like virtual machines), you can specify multiple
resources as the target of the alert rule.
Signal: Emitted by the target resource. Signals can be of the following types: metric, activity log, Application
Insights, and log.
Criteria: A combination of signal and logic applied on a target resource. Examples:
Percentage CPU > 70%
Server Response Time > 4 ms
Result count of a log query > 100
Alert Name: A specific name for the alert rule configured by the user.
Alert Description: A description for the alert rule configured by the user.
Severity: The severity of the alert after the criteria specified in the alert rule is met. Severity can range from 0
to 4.
Sev 0 = Critical
Sev 1 = Error
Sev 2 = Warning
Sev 3 = Informational
Sev 4 = Verbose
Action: A specific action taken when the alert is fired. For more information, see Action Groups.
What you can alert on

You can alert on metrics and logs, as described in monitoring data sources. These include but are not limited
to:
Metric values
Log search queries
Activity log events
Health of the underlying Azure platform
Tests for website availability
Previously, Azure Monitor metrics, Application Insights, Log Analytics, and Service Health had separate
alerting capabilities. Over time, Azure improved and combined both the user interface and different methods
of alerting. This consolidation is still in process. As a result, there are still some alerting capabilities not yet in
the new alerts system.
MONITOR SOURCE SIGNAL TYPE DESCRIPTION
Service health Activity log Not supported. See Create activity log
alerts on service notifications.
Application Insights Web availability tests Not supported. See Web test alerts.
Available to any website that's
instrumented to send data to
Application Insights. Receive a
notification when availability or
responsiveness of a website is below
expectations.
Manage alerts
You can set the state of an alert to specify where it is in the resolution process. When the criteria specified in
the alert rule is met, an alert is created or fired, and it has a status of New. You can change the status when
you acknowledge an alert and when you close it. All state changes are stored in the history of the alert.
The following alert states are supported.
STATE DESCRIPTION
New The issue has just been detected and hasn't yet been
reviewed.
Acknowledged An administrator has reviewed the alert and started

working on it.
Closed The issue has been resolved. After an alert has been closed,
you can reopen it by changing it to another state.
Alert state is different and independent of the monitor condition. Alert state is set by the user. Monitor
condition is set by the system. When an alert fires, the alert's monitor condition is set to fired. When the
underlying condition that caused the alert to fire clears, the monitor condition is set to resolved. The alert
state isn't changed until the user changes it. Learn how to change the state of your alerts and smart groups.
Smart groups
Smart groups are aggregations of alerts based on machine learning algorithms, which can help reduce alert
noise and aid in troubleshooting. Learn more about Smart Groups and how to manage your smart groups.
Alerts experience
The default Alerts page provides a summary of alerts that are created within a particular time range. It
displays the total alerts for each severity, with columns that identify the total number of alerts in each state
for each severity. Select any of the severities to open the All Alerts page filtered by that severity.
Alternatively, you can programmatically enumerate the alert instances generated on your subscriptions by
using REST APIs.
NOTE
You can only access alerts generated in the last 30 days.
It doesn't show or track classic alerts. You can change the subscriptions or filter parameters to update the
page.
You can filter this view by selecting values in the drop-down menus at the top of the page.
COLUMN DESCRIPTION
Subscription Select the Azure subscriptions for which you want to view
the alerts. You can optionally choose to select all your
subscriptions. Only alerts that you have access to in the
selected subscriptions are included in the view.
Resource group Select a single resource group. Only alerts with targets in
the selected resource group are included in the view.
Time range Only alerts fired within the selected time range are included
in the view. Supported values are the past hour, the past 24
hours, the past 7 days, and the past 30 days.
Select the following values at the top of the Alerts page to open another page:
VALUE DESCRIPTION
Total alerts The total number of alerts that match the selected criteria.
Select this value to open the All Alerts view with no filter.
Smart groups The total number of smart groups that were created from
the alerts that match the selected criteria. Select this value
to open the smart groups list in the All Alerts view.
Total alert rules The total number of alert rules in the selected subscription
and resource group. Select this value to open the Rules
view filtered on the selected subscription and resource
group.
Manage alert rules

To show the Rules page, select Manage alert rules. The Rules page is a single place for managing all alert
rules across your Azure subscriptions. It lists all alert rules and can be sorted based on target resources,
resource groups, rule name, or status. You can also edit, enable, or disable alert rules from this page.

You can author alerts in a consistent manner, regardless of the monitoring service or signal type. All fired
alerts and related details are available in single page.
Here's how to create a new alert rule:
1. Pick the target for the alert.
2. Select the signal from the available signals for the target.
3. Specify the logic to be applied to data from the signal.
This simplified authoring process no longer requires you to know the monitoring source or signals that are
supported before selecting an Azure resource. The list of available signals is automatically filtered based on
the target resource that you select. Also based on that target, you are guided through defining the logic of the
alert rule automatically.
You can learn more about how to create alert rules in Create, view, and manage alerts using Azure Monitor.
Alerts are available across several Azure monitoring services. For information about how and when to use
each of these services, see Monitoring Azure applications and resources.
All Alerts page

To see the All Alerts page, select Total Alerts. Here you can view a list of alerts created within the selected
time. You can view either a list of the individual alerts or a list of the smart groups that contain the alerts.
Select the banner at the top of the page to toggle between views.
You can filter the view by selecting the following values in the drop-down menus at the top of the page:
COLUMN DESCRIPTION
Subscription Select the Azure subscriptions for which you want to view
the alerts. You can optionally choose to select all your
subscriptions. Only alerts that you have access to in the
selected subscriptions are included in the view.
Resource group Select a single resource group. Only alerts with targets in
the selected resource group are included in the view.
Resource type Select one or more resource types. Only alerts with targets
of the selected type are included in the view. This column is
only available after a resource group has been specified.
COLUMN DESCRIPTION
Resource Select a resource. Only alerts with that resource as a target

are included in the view. This column is only available after
a resource type has been specified.
Severity Select an alert severity, or select All to include alerts of all

severities.
Monitor condition Select a monitor condition, or select All to include alerts of

all conditions.
Alert state Select an alert state, or select All to include alerts of all
states.
Monitor service Select a service, or select All to include all services. Only
alerts created by rules that use service as a target are
included.
Time range Only alerts fired within the selected time range are included
Select Columns at the top of the page to select which columns to show.
Alert details page

When you select an alert, this page provides details of the alert and enables you to change its state.
The Alert details page includes the following sections:
SECTION DESCRIPTION
Summary Displays the properties and other significant information

about the alert.
History Lists each action taken by the alert and any changes made
to the alert. Currently limited to state changes.
SECTION DESCRIPTION
Diagnostics Information about the smart group in which the alert is

included. The alert count refers to the number of alerts
that are included in the smart group. Includes other alerts
in the same smart group that were created in the past 30
days, regardless of the time filter in the alerts list page.
Select an alert to view its detail.
Role-based access control (RBAC) for your alert instances

The consumption and management of alert instances requires the user to have the built-in RBAC roles of
either monitoring contributor or monitoring reader. These roles are supported at any Azure Resource
Manager scope, from the subscription level to granular assignments at a resource level. For example, if a user
only has monitoring contributor access for virtual machine ContosoVM1 , that user can consume and manage
only alerts generated on ContosoVM1 .
Manage your alert instances programmatically

You might want to query programmatically for alerts generated against your subscription. This might be to
create custom views outside of the Azure portal, or to analyze your alerts to identify patterns and trends.
You can query for alerts generated against your subscriptions either by using the Alert Management REST
API or by using the Azure Resource Graph REST API for Alerts.
The Azure Resource Graph REST API for Alerts allows you to query for alert instances at scale. This is
recommended when you have to manage alerts generated across many subscriptions.
The following sample request to the API returns the count of alerts within one subscription:
{
"subscriptions": [
<subscriptionId>
],
"query": "where type =~ 'Microsoft.AlertsManagement/alerts' | summarize count()",
"options": {
"dataset":"alerts"
}
}
You can query the alerts for their essential fields.

Use the Alert Management REST API to get more information about specific alerts, including their alert
context fields.
Next steps
Learn more about Smart Groups
Learn about action groups
Managing your alert instances in Azure
Managing Smart Groups
Understand how metric alerts work in Azure Monitor
Metric alerts in Azure Monitor work on top of multi-dimensional metrics. These metrics could be platform metrics,
custom metrics, popular logs from Azure Monitor converted to metrics and Application Insights metrics. Metric
alerts evaluate at regular intervals to check if conditions on one or more metric time-series are true and notify you
when the evaluations are met. Metric alerts are stateful, that is, they only send out notifications when the state
changes.
How do metric alerts work?

You can define a metric alert rule by specifying a target resource to be monitored, metric name, condition type
(static or dynamic), and the condition (an operator and a threshold/sensitivity) and an action group to be triggered
when the alert rule fires. Condition types affect the way thresholds are determined. Learn more about Dynamic
Thresholds condition type and sensitivity options.
Alert rule with static condition type
Let's say you have created a simple static threshold metric alert rule as follows:
Target Resource (the Azure resource you want to monitor): myVM
Metric: Percentage CPU
Condition Type: Static
Time Aggregation (Statistic that is run over raw metric values. Supported time aggregations are Min, Max, Avg,
Total, Count): Average
Period (The look back window over which metric values are checked): Over the last 5 mins
Frequency (The frequency with which the metric alert checks if the conditions are met): 1 min
Operator: Greater Than
Threshold: 70
From the time the alert rule is created, the monitor runs every 1 min and looks at metric values for the last 5
minutes and checks if the average of those values exceeds 70. If the condition is met that is, the average
Percentage CPU for the last 5 minutes exceeds 70, the alert rule fires an activated notification. If you have
configured an email or a web hook action in the action group associated with the alert rule, you will receive an
activated notification on both.
When you are using multiple conditions in one rule, the rule "ands" the conditions together. That is, the alert fires
when all the conditions in the alert evaluate as true and resolve when one of the conditions is no longer true. And
example of this type of alert would be alert when "CPU higher than 90%" and "queue length is over 300 items".
Alert rule with dynamic condition type
Let's say you have created a simple Dynamic Thresholds metric alert rule as follows:
Target Resource (the Azure resource you want to monitor): myVM
Condition Type: Dynamic
Time Aggregation (Statistic that is run over raw metric values. Supported time aggregations are Min, Max, Avg,
Total, Count): Average
Period (The look back window over which metric values are checked): Over the last 5 mins
Frequency (The frequency with which the metric alert checks if the conditions are met): 1 min
Operator: Greater Than
Sensitivity: Medium
Look Back Periods: 4
Number of Violations: 4
Once the alert rule is created, the Dynamic Thresholds machine learning algorithm will acquire historical data that
is available, calculate threshold that best fits the metric series behavior pattern and will continuously learn based
on new data to make the threshold more accurate.
From the time the alert rule is created, the monitor runs every 1 min and looks at metric values in the last 20
minutes grouped into 5 minutes periods and checks if the average of the period values in each of the 4 periods
exceeds the expected threshold. If the condition is met that is, the average Percentage CPU in the last 20 minutes
(four 5 minutes periods) deviated from expected behavior four times, the alert rule fires an activated notification. If
you have configured an email or a web hook action in the action group associated with the alert rule, you will
receive an activated notification on both.
View and resolution of fired alerts
The above examples of alert rules firing can also be viewed in the Azure portal in the All Alerts blade.
Say the usage on "myVM" continues being above the threshold in subsequent checks, the alert rule will not fire
again until the conditions are resolved.
After some time, the usage on "myVM" comes back down to normal (goes below the threshold). The alert rule
monitors the condition for two more times, to send out a resolved notification. The alert rule sends out a
resolved/deactivated message when the alert condition is not met for three consecutive periods to reduce noise in
case of flapping conditions.
As the resolved notification is sent out via web hooks or email, the status of the alert instance (called monitor
state) in Azure portal is also set to resolved.
Using dimensions
Metric alerts in Azure Monitor also support monitoring multiple dimensions value combinations with one rule.
Let's understand why you might use multiple dimension combinations with the help of an example.
Say you have an App Service plan for your website. You want to monitor CPU usage on multiple instances
running your web site/app. You can do that using a metric alert rule as follows:
Target resource: myAppServicePlan
Dimensions
Instance = InstanceName1, InstanceName2
Time Aggregation: Average
Period: Over the last 5 mins
Frequency: 1 min
Operator: GreaterThan
Threshold: 70
Like before, this rule monitors if the average CPU usage for the last 5 minutes exceeds 70%. However, with the
same rule you can monitor two instances running your website. Each instance will get monitored individually and
you will get notifications individually.
Say you have a web app that is seeing massive demand and you will need to add more instances. The above rule
still monitors just two instances. However, you can create a rule as follows:
Dimensions
Instance = *
Frequency: 1 min
Threshold: 70
This rule will automatically monitor all values for the instance i.e you can monitor your instances as they come up
without needing to modify your metric alert rule again.
When monitoring multiple dimensions, Dynamic Thresholds alerts rule can create tailored thresholds for
hundreds of metric series at a time. Dynamic Thresholds results in fewer alert rules to manage and significant time
saving on management and creation of alerts rules.
Say you have a web app with many instances and you don't know what the most suitable threshold is. The above
rules will always use threshold of 70%. However, you can create a rule as follows:
Condition Type: Dynamic
Dimensions
Instance = *
Frequency: 1 min
Sensitivity: Medium
Look Back Periods: 1
Number of Violations: 1
This rule monitors if the average CPU usage for the last 5 minutes exceeds the expected behavior for each
instance. The same rule you can monitor instances as they come up without needing to modify your metric alert
rule again. Each instance will get a threshold that fits the metric series behavior pattern and will continuously
change based on new data to make the threshold more accurate. Like before, each instance will be monitored
individually and you will get notifications individually.
Increasing look-back periods and number of violations can also allow filtering alerts to only alert on your
definition of a significant deviation. Learn more about Dynamic Thresholds advanced options.
Monitoring at scale using metric alerts in Azure Monitor

So far, you have seen how a single metric alert could be used to monitor one or many metric time-series related to
a single Azure resource. Many times, you might want the same alert rule applied to many resources. Azure
Monitor also supports monitoring multiple resources with one metric alert rule. This feature is currently
supported only on virtual machines. Also, a single metric alert can monitor resources in one Azure region.
You can specify the scope of monitoring by a single metric alert in one of three ways:
as a list of virtual machines in one Azure region within a subscription
all virtual machines (in one Azure region) in one or more resource groups in a subscription
all virtual machines (in one Azure region) in one subscription
Creating metric alert rules that monitor multiple resources is like creating any other metric alert that monitors a
single resource. Only difference is that you would select all the resources you want to monitor. You can also create
these rules through Azure Resource Manager templates. You will receive individual notifications for each virtual
machine.
Typical latency
For metric alerts, typically you will get notified in under 5 minutes if you set the alert rule frequency to be 1 min. In
cases of heavy load for notification systems, you might see a longer latency.
Supported resource types for metric alerts

You can find the full list of supported resource types in this article.
If you are using classic metric alerts today and are looking to see if metric alerts support the all the resource types
you are using, the following table shows the resource types supported by classic metric alerts and if they are
supported by metric alerts today or not.
RESOURCE TYPE SUPPORTED BY CLASSIC METRIC ALERTS SUPPORTED BY METRIC ALERTS
Microsoft.ApiManagement/service Yes
Microsoft.Batch/batchAccounts Yes
Microsoft.Cache/redis Yes
Microsoft.ClassicCompute/virtualMachines No
Microsoft.ClassicCompute/domainNames/slots/roles No
Microsoft.CognitiveServices/accounts No
Microsoft.Compute/virtualMachines Yes
Microsoft.Compute/virtualMachineScaleSets Yes
Microsoft.ClassicStorage/storageAccounts No
Microsoft.DataFactory/datafactories Yes
Microsoft.DBforMySQL/servers Yes
Microsoft.DBforPostgreSQL/servers Yes
Microsoft.Devices/IotHubs No
Microsoft.DocumentDB/databaseAccounts Yes
Microsoft.EventHub/namespaces Yes
RESOURCE TYPE SUPPORTED BY CLASSIC METRIC ALERTS SUPPORTED BY METRIC ALERTS
Microsoft.Logic/workflows Yes
Microsoft.Network/loadBalancers Yes
Microsoft.Network/publicIPAddresses Yes
Microsoft.Network/applicationGateways Yes
Microsoft.Network/expressRouteCircuits Yes
Microsoft.Network/trafficManagerProfiles Yes
Microsoft.Search/searchServices Yes
Microsoft.ServiceBus/namespaces Yes
Microsoft.Storage/storageAccounts Yes
Microsoft.StreamAnalytics/streamingjobs Yes
Microsoft.TimeSeriesInsights/environments Yes
Microsoft. Web/serverfarms Yes
Microsoft. Web/sites (excluding functions) Yes
Microsoft. Web/hostingEnvironments/multiRolePools No
Microsoft. Web/hostingEnvironments/workerPools No
Microsoft.SQL/Servers No
Next steps
Learn how to create, view, and manage metric alerts in Azure
Learn how to deploy metric alerts using Azure Resource Manager templates
Learn more about action groups
Learn more about Dynamic Thresholds condition type
Log alerts in Azure Monitor
This article provides details of Log alerts are one of the types of alerts supported within the Azure Alerts and
allow users to use Azure's analytics platform as basis for alerting.
Log Alert consists of Log Search rules created for Azure Monitor Logs or Application Insights. To learn more
about its usage, see creating log alerts in Azure
NOTE
Popular log data from Azure Monitor Logs is now also available on the metric platform in Azure Monitor. For details view,
Metric Alert for Logs
Log search alert rule - definition and types

Log search rules are created by Azure Alerts to automatically run specified log queries at regular intervals. If the
results of the log query match particular criteria, then an alert record is created. The rule can then automatically
run one or more actions using Action Groups. Azure Monitoring Contributor role for creating, modifying, and
updating log alerts may be required; along with access & query execution rights for the analytics target(s) in alert
rule or alert query. In case the user creating doesn't have access to all analytics target(s) in alert rule or alert
query - the rule creation may fail or the log alert rule will be executed with partial results.
Log search rules are defined by the following details:
Log Query. The query that runs every time the alert rule fires. The records returned by this query are
used to determine whether an alert is to be triggered. Analytics query can be for a specific Log Analytics
workspace or Application Insights app and even span across multiple Log Analytics and Application
Insights resources provided the user has access as well as query rights to all resources.
IMPORTANT
cross-resource query support in log alerts for Application Insights and log alerts for Log Analytics configured using
scheduledQueryRules API only.
Some analytic commands and combinations are incompatible with use in log alerts; for more details view,
Log alert queries in Azure Monitor.
Time Period. Specifies the time range for the query. The query returns only records that were created
within this range of the current time. Time period restricts the data fetched for log query to prevent abuse
and circumvents any time command (like ago) used in log query.
For example, If the time period is set to 60 minutes, and the query is run at 1:15 PM, only records created
between 12:15 PM and 1:15 PM is returned to execute log query. Now if the log query uses time command
like ago (7d ), the log query would be run only for data between 12:15 PM and 1:15 PM - as if data exists
for only the past 60 minutes. And not for seven days of data as specified in log query.
Frequency. Specifies how often the query should be run. Can be any value between 5 minutes and 24
hours. Should be equal to or less than the time period. If the value is greater than the time period, then you
risk records being missed.
For example, consider a time period of 30 minutes and a frequency of 60 minutes. If the query is run at
1:00, it returns records between 12:30 and 1:00 PM. The next time the query would run is 2:00 when it
would return records between 1:30 and 2:00. Any records created between 1:00 and 1:30 would never be
evaluated.
Threshold. The results of the log search are evaluated to determine whether an alert should be created.
The threshold is different for the different types of log search alert rules.
Log search rules be it for Azure Monitor Logs or Application Insights, can be of two types. Each of these types is
described in detail in the sections that follow.
Number of results. Single alert created when the number records returned by the log search exceed a
specified number.
Metric measurement. Alert created for each object in the results of the log search with values that exceed
specified threshold.
The differences between alert rule types are as follows.
Number of results alert rules always creates a single alert, while Metric measurement alert rule creates an
alert for each object that exceeds the threshold.
Number of results alert rules create an alert when the threshold is exceeded a single time. Metric
measurement alert rules can create an alert when the threshold is exceeded a certain number of times over a
particular time interval.
Number of results alert rules
Number of results alert rules create a single alert when the number of records returned by the search query
exceed the specified threshold. This type of alert rule is ideal for working with events such as Windows event
logs, Syslog, WebApp Response, and Custom logs. You may want to create an alert when a particular error event
gets created, or when multiple error events are created within a particular time period.
Threshold: The threshold for a Number of results alert rules is greater than or less than a particular value. If the
number of records returned by the log search match this criteria, then an alert is created.
To alert on a single event, set the number of results to greater than 0 and check for the occurrence of a single
event that was created since the last time the query was run. Some applications may log an occasional error that
shouldn't necessarily raise an alert. For example, the application may retry the process that created the error
event and then succeed the next time. In this case, you may not want to create the alert unless multiple events are
created within a particular time period.
In some cases, you may want to create an alert in the absence of an event. For example, a process may log
regular events to indicate that it's working properly. If it doesn't log one of these events within a particular time
period, then an alert should be created. In this case, you would set the threshold to less than 1.
Example of Number of Records type log alert
Consider a scenario where you want to know when your web-based App gives a response to users with code 500
(that is) Internal Server Error. You would create an alert rule with the following details:
Query: requests | where resultCode == "500"
Time period: 30 minutes
Alert frequency: five minutes
Threshold value: Greater than 0
Then alert would run the query every 5 minutes, with 30 minutes of data - to look for any record where result
code was 500. If even one such record is found, it fires the alert and triggers the action configured.
Metric measurement alert rules
Metric measurement alert rules create an alert for each object in a query with a value that exceeds a specified
threshold and specified trigger condition. Unlike Number of results alert rules, Metric measurement alert
rules work when analytics result provides a time series. They have the following distinct differences from
Number of results alert rules.
Aggregate function: Determines the calculation that is performed and potentially a numeric field to
aggregate. For example, count() returns the number of records in the query, avg(CounterValue) returns
the average of the CounterValue field over the interval. Aggregate function in query must be
named/called: AggregatedValue and provide a numeric value.
Group Field: A record with an aggregated value is created for each instance of this field, and an alert can
be generated for each. For example, if you wanted to generate an alert for each computer, you would use
by Computer. In case, there are multiple group fields specified in alert query, user can specify which field
to be used to sort results by using the Aggregate On (metricColumn) parameter
NOTE
Aggregate On (metricColumn) option is available for Metric Measurement type log alerts for Application Insights
and log alerts for Log Analytics configured using scheduledQueryRules API only.
Interval: Defines the time interval over which the data is aggregated. For example, if you specified five
minutes, a record would be created for each instance of the group field aggregated at 5-minute intervals
over the time period specified for the alert.
NOTE
Bin function must be used in query to specify interval. As bin() can result in unequal time intervals - Alert will
automatically convert bin command to bin_at command with appropriate time at runtime, to ensure results with a
fixed point. Metric measurement type of log alert is designed to work with queries having up to three instances of
bin() command
Threshold: The threshold for Metric measurement alert rules is defined by an aggregate value and a
number of breaches. If any data point in the log search exceeds this value, it's considered a breach. If the
number of breaches in for any object in the results exceeds the specified value, then an alert is created for
that object.
Misconfiguration of the Aggregate On or metricColumn option can cause alert rules to misfire. For more
information, see troubleshooting when metric measurement alert rule is incorrect.
Example of Metric Measurement type log alert
Consider a scenario where you wanted an alert if any computer exceeded processor utilization of 90% three
times over 30 minutes. You would create an alert rule with the following details:
Query: Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" | summarize
AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer
Time period: 30 minutes
Alert frequency: five minutes
Alert Logic - Condition & Threshold: Greater than 90
Group Field (Aggregate-on): Computer
Trigger alert based on: Total breaches Greater than 2
The query would create an average value for each computer at 5-minute intervals. This query would be run every
5 minutes for data collected over the previous 30 minutes. Since the Group Field (Aggregate-on) chosen is
columnar 'Computer' - the AggregatedValue is split for various values of 'Computer' and average processor
utilization for each computer is determined for a time bin of 5 minutes. Sample query result for (say) three
computers, would be as below.
TIMEGENERATED [UTC] COMPUTER AGGREGATEDVALUE
20xx-xx-xxT01:00:00Z srv01.contoso.com 72
... ... ...
If query result was to be plotted, it would appear as.
In this example, we see in bins of 5 mins for each of the three computers - average processor utilization as
computed for 5 mins. Threshold of 90 being breached by srv01 only once at 1:25 bin. In comparison, srv02
exceeds 90 threshold at 1:10, 1:15 and 1:25 bins; while srv03 exceeds 90 threshold at 1:10, 1:15, 1:20 and 1:30.
Since alert is configured to trigger based on total breaches are more than two, we see that srv02 and srv03 only
meet the criteria. Hence separate alerts would be created for srv02 and srv03 since they breached the 90%
threshold twice across multiple time bins. If the Trigger alert based on: parameter was instead configured for
Continuous breaches option, then an alert would be fired only for srv03 since it breached the threshold for three
consecutive time bins from 1:10 to 1:20. And not for srv02, as it breached the threshold for two consecutive time
bins from 1:10 to 1:15.
Log search alert rule - firing and state

Log search alert rule works on the logic predicated by user as per configuration and the custom analytics query
used. Since the monitoring logic including the exact condition or reason why the alert rule should trigger is
encapsulated in an analytics query - which can differ in each log alert rule. Azure Alerts has scarce info of the
specific underlying root-cause (or) scenario being evaluated when the threshold condition of log search alert rule
is met or exceeded. Thus log alerts are referred to as state-less. And log alert rules will keep firing, as long as the
alert condition is met by the result of custom analytics query provided. Without the alert every getting resolved,
as the logic of the exact root-cause of monitoring failure is masked inside the analytics query provided by the
user. There currently being no mechanism for Azure Monitor Alerts to conclusively deduce root cause being
solved.
Lets us see the same with a practical example. Assume we have a log alert rule called Contoso -Log -Alert, as per
configuration in the example provided for Number of Results type log alert - where the custom alert query is
designed to look for 500 result code in logs.
At 1:05 PM when Contoso-Log-Alert was executed by Azure alerts, the log search result yielded zero records
with result code having 500. Since zero is below the threshold and the alert is not fired.
At the next iteration at 1:10 PM when Contoso-Log-Alert was executed by Azure alerts, log search result
provided five records with result code as 500. Since five exceeds the threshold and the alert is fired with
associated actions get triggered.
At 1:15 PM when Contoso-Log-Alert was executed by Azure alerts, log search result provided two records
with 500 result code. Since two exceeds the threshold and the alert is fired with associated actions get
triggered.
Now at the next iteration at 1:20 PM when Contoso-Log-Alert was executed by Azure alert, log search result
provided again zero records with 500 result code. Since zero is below the threshold and the alert is not fired.
But in the above listed case, at 1:15 PM - Azure alerts can't determine that the underlying issues seen at 1:10
persist and if there is net new failures. As query provided by user may be taking into account earlier records -
Azure alerts can be sure. Since the logic for the alert is encapsulated in the alert query - so the two records with
500 result code seen at 1:15 PM may or may not be already seen at 1:10 PM. Hence to err on the side of caution,
when Contoso-Log-Alert is executed at 1:15 PM, configured action is triggered again. Now at 1:20 PM when zero
records are seen with 500 result code - Azure alerts can't be certain that the cause of 500 result code seen at 1:10
PM and 1:15 PM is now solved and Azure Monitor alerts can confidently deduce the 500 error issues will not
happen for the same reasons again. Hence Contoso-Log-Alert will not changed to Resolved in Azure Alert
dashboard and/or notifications sent out stating resolution of alert. Instead the user who understands the exact
condition or reason for the logic embedded in the analytics query, can mark the alert as closed as needed.
Pricing and Billing of Log Alerts

Pricing applicable for Log Alerts is stated at the Azure Monitor Pricing page. In Azure bills, Log Alerts are
represented as type microsoft.insights/scheduledqueryrules with:
Log Alerts on Application Insights shown with exact alert name along with resource group and alert
properties
Log Alerts on Log Analytics shown with exact alert name along with resource group and alert properties;
when created using scheduledQueryRules API
The legacy Log Analytics API has alert actions and schedules as part of Log Analytics Saved Search and not
proper Azure Resources. Hence to enable billing for such legacy log alerts created for Log Analytics using of
Azure portal without switching to new API or via legacy Log Analytics API - hidden pseudo alert rules are
created on microsoft.insights/scheduledqueryrules for billing on Azure. The hidden pseudo alert rules created
for billing on microsoft.insights/scheduledqueryrules as shown as
<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId> along with resource group and alert properties.
NOTE
If invalid characters such as <, >, %, &, \, ?, / are present, they will be replaced with _ in the hidden pseudo alert
rule name and hence also in the Azure bill.
To remove the hidden scheduleQueryRules resources created for billing of alert rules using legacy Log Analytics
API, user can do any of the following:
Either user can switch API preference for the alert rules on the Log Analytics workspace and with no loss of
their alert rules or monitoring move to Azure Resource Manager compliant scheduledQueryRules API.
Thereby eliminate the need to make pseudo hidden alert rules for billing.
Or if the user doesn't want to switch API preference, the user will need to delete the original schedule and
alert action using legacy Log Analytics API or delete in Azure portal the original log alert rule
Additionally for the hidden scheduleQueryRules resources created for billing of alert rules using legacy Log
Analytics API, any modification operation like PUT will fail. As the microsoft.insights/scheduledqueryrules type
pseudo rules are for purpose of billing the alert rules created using legacy Log Analytics API. Any alert rule
modification should be done using legacy Log Analytics API (or) user can switch API preference for the alert
rules to use scheduledQueryRules API instead.
Next steps
Learn about creating in log alerts in Azure.
Understand webhooks in log alerts in Azure.
Learn about Azure Alerts.
Learn more about Application Insights.
Learn more about Log Analytics.
Alerts on activity log
Overview
Activity log alerts are alerts that activate when a new activity log event occurs that matches the conditions
specified in the alert. Based on the order and volume of the events recorded in Azure activity log, the alert rule will
fire. Activity log alert rules are Azure resources, so they can be created by using an Azure Resource Manager
template. They also can be created, updated, or deleted in the Azure portal. This article introduces the concepts
behind activity log alerts. For more information on creating or usage of activity log alert rules, see Create and
manage activity log alerts.
NOTE
Alerts cannot be created for events in Alert category of activity log.
Typically, you create activity log alerts to receive notifications when:

Specific operations occur on resources in your Azure subscription, often scoped to particular resource groups
or resources. For example, you might want to be notified when any virtual machine in
myProductionResourceGroup is deleted. Or, you might want to be notified if any new roles are assigned to a
user in your subscription.
A service health event occurs. Service health events include notification of incidents and maintenance events
that apply to resources in your subscription.
A simple analogy for understanding conditions on which alert rules can be created on activity log, is to explore or
filter events via Activity log in Azure portal. In Azure Monitor - Activity log, one can filter or find necessary event
and then create an alert by using the Add activity log alert button.
In either case, an activity log alert monitors only for events in the subscription in which the alert is created.
You can configure an activity log alert based on any top-level property in the JSON object for an activity log event.
For more information, see Overview of the Azure activity log. To learn more about service health events, see
Receive activity log alerts on service notifications .
Activity log alerts have a few common options:
Category: Administrative, Service Health, Autoscale, Security, Policy, and Recommendation.
Scope: The individual resource or set of resource(s) for which the alert on activity log is defined. Scope for an
activity log alert can be defined at various levels:
Resource Level: For example, for a specific virtual machine
Resource Group Level: For example, all virtual machines in a specific resource group
Subscription Level: For example, all virtual machines in a subscription (or) all resources in a subscription
Resource group: By default, the alert rule is saved in the same resource group as that of the target defined in
Scope. The user can also define the Resource Group where the alert rule should be stored.
Resource type: Resource Manager defined namespace for the target of the alert.
Operation name: The Azure Resource Manager operation name utilized for Role-Based Access Control .
Operations not registered with Azure Resource Manager can not be used in an activity log alert rule.
Level: The severity level of the event (Verbose, Informational, Warning, Error, or Critical).
Status: The status of the event, typically Started, Failed, or Succeeded.
Event initiated by: Also known as the "caller." The email address or Azure Active Directory identifier of the
user who performed the operation.
NOTE
In a subscription up to 100 alert rules can be created for an activity of scope at either: a single resource, all resources in
resource group (or) entire subscription level.
When an activity log alert is activated, it uses an action group to generate actions or notifications. An action group
is a reusable set of notification receivers, such as email addresses, webhook URLs, or SMS phone numbers. The
receivers can be referenced from multiple alerts to centralize and group your notification channels. When you
define your activity log alert, you have two options. You can:
Use an existing action group in your activity log alert.
Create a new action group.
To learn more about action groups, see Create and manage action groups in the Azure portal.
Next steps
Get an overview of alerts.
Learn about create and modify activity log alerts.
Review the activity log alert webhook schema.
Learn about service health notifications.
Use Application Change Analysis (preview) in Azure
Monitor
When a live site issue or outage occurs, quickly determining the root cause is critical. Standard monitoring
solutions might alert you to a problem. They might even indicate which component is failing. But this alert won't
always immediately explain the failure's cause. You know your site worked five minutes ago, and now it's broken.
What changed in the last five minutes? This is the question that Application Change Analysis is designed to answer
in Azure Monitor.
Building on the power of Azure Resource Graph, Change Analysis provides insights into your Azure application
changes to increase observability and reduce MTTR (mean time to repair).
IMPORTANT
Change Analysis is currently in preview. This preview version is provided without a service-level agreement. This version is not
recommended for production workloads. Some features might not be supported or might have constrained capabilities. For
more information, see Supplemental terms of use for Microsoft Azure previews.
Overview
Change Analysis detects various types of changes, from the infrastructure layer all the way to application
deployment. It's a subscription-level Azure resource provider that checks resource changes in the subscription.
Change Analysis provides data for various diagnostic tools to help users understand what changes might have
caused issues.
The following diagram illustrates the architecture of Change Analysis:
Currently Change Analysis is integrated into the Diagnose and solve problems experience in the App Service
web app. To enable change detection and view changes in the web app, see the Change Analysis for the Web Apps
feature section later in this article.
Azure Resource Manager deployment changes
Using Azure Resource Graph, Change Analysis provides a historical record of how the Azure resources that host
your application have changed over time. Change Analysis can detect, for example, changes in IP configuration
rules, managed identities, and SSL settings. So if a tag is added to a web app, Change Analysis reflects the change.
This information is available as long as the Microsoft.ChangeAnalysis resource provider is enabled in the Azure
subscription.
Changes in web app deployment and configuration
Change Analysis captures the deployment and configuration state of an application every 4 hours. It can detect, for
example, changes in the application environment variables. The tool computes the differences and presents what
has changed. Unlike Resource Manager changes, code deployment change information might not be available
immediately in the tool. To view the latest changes in Change Analysis, select Scan changes now.
Dependency changes
Changes to resource dependencies can also cause issues in a web app. For example, if a web app calls into a Redis
cache, the Redis cache SKU could affect the web app performance. To detect changes in dependencies, Change
Analysis checks the web app's DNS record. In this way, it identifies changes in all app components that could cause
issues. Currently the following dependencies are supported:
Web Apps
Azure Storage
Azure SQL
Change Analysis for the Web Apps feature

In Azure Monitor, Change Analysis is currently built into the self-service Diagnose and solve problems
experience. Access this experience from the Overview page of your App Service application.
Enable Change Analysis in the Diagnose and solve problems tool

1. Select Availability and Performance.
2. Select Application Changes. Not that the feature is also available in Application Crashes.
3. To enable Change Analysis, select Enable now.

4. Turn on Change Analysis and select Save.
5. To access Change Analysis, select Diagnose and solve problems > Availability and Performance >
Application Crashes. You'll see a graph that summarizes the type of changes over time along with details
on those changes:
Enable Change Analysis at scale

If your subscription includes numerous web apps, enabling the service at the level of the web app would be
inefficient. Run the following script to enable all web apps in your subscription.
Pre-requisites:
PowerShell Az Module. Follow instructions at Install the Azure PowerShell module
Run the following script:
# Log in to your Azure subscription

Connect-AzAccount
# Get subscription Id
$SubscriptionId = Read-Host -Prompt 'Input your subscription Id'
# Make Feature Flag visible to the subscription

Set-AzContext -SubscriptionId $SubscriptionId
# Register resource provider

Register-AzResourceProvider -ProviderNamespace "Microsoft.ChangeAnalysis"
# Enable each web app

$webapp_list = Get-AzWebApp | Where-Object {$_.kind -eq 'app'}
foreach ($webapp in $webapp_list)
{
$tags = $webapp.Tags
$tags[“hidden-related:diagnostics/changeAnalysisScanEnabled”]=$true
Set-AzResource -ResourceId $webapp.Id -Tag $tags -Force
}
Next steps
Enable Application Insights for Azure App Services apps.
Enable Application Insights for Azure VM and Azure virtual machine scale set IIS -hosted apps.
Learn more about Azure Resource Graph, which helps power Change Analysis.
Visualizing data from Azure Monitor
This article provides a summary of the available methods to visualize log and metric data stored in Azure Monitor.
Visualizations such as charts and graphs can help you analyze your monitoring data to drill-down on issues and
identify patterns. Depending on the tool you use, you may also have the option to share visualizations with other
users inside and outside of your organization.
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in a Log
Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the terminology
to better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.
Azure Dashboards
Azure dashboards are the primary dashboarding technology for Azure. They're particularly useful in providing
single pane of glass over your Azure infrastructure and services allowing you to quickly identify important issues.
Advantages
Deep integration into Azure. Visualizations can be pinned to dashboards from multiple Azure pages including
Metrics Explorer, Log Analytics, and Application Insights.
Supports both metrics and logs.
Combine data from multiple sources including output from metrics explorer, Log queries, and maps and
availability in Application Insights.
Option for personal or shared dashboards. Integrated with Azure role based authentication (RBAC ).
Automatic refresh. Metrics refresh depends on time range with minimum of five minutes. Logs refresh every
hour, with a manual refresh option on demand by clicking the "refresh" icon on a given visualization, or by
refreshing the full dashboard.
Parametrized metrics dashboards with timestamp and custom parameters.
Flexible layout options.
Full screen mode.
Limitations
Limited control over log visualizations with no support for data tables. Total number of data series is limited to
10 with further data series grouped under an other bucket.
No custom parameters support for log charts.
Log charts are limited to last 30 days.
Log charts can only be pinned to shared dashboards.
No interactivity with dashboard data.
Limited contextual drill-down.
Azure Monitor Views

Views in Azure Monitor allow you to create custom visualizations with log data. They are used by monitoring
solutions to present the data they collect.
Advantages
Rich visualizations for log data.
Export and import views to transfer them to other resource groups and subscriptions.
Integrates into Azure Monitor management model with workspaces and monitoring solutions.
Filters for custom parameters.
Interactive, supports multi-level drill-in (view that drills into another view )
Limitations
Supports logs but not metrics.
No personal views. Available to all users with access to the workspace.
No automatic refresh.
Limited layout options.
No support for querying across multiple workspaces or Application Insights applications.
Queries are limited in response size to 8MB and query execution time of 110 seconds.
Workbooks
Workbooks are interactive documents that provide deep insights into your data, investigation, and collaboration
inside the team. Specific examples where workbooks are useful are troubleshooting guides and incident
postmortem.
Advantages
Supports both metrics and logs.
Supports parameters enabling interactive reports where selecting an element in a table will dynamically update
associated charts and visualizations.
Document-like flow.
Option for personal or shared workbooks.
Easy, collaborative-friendly authoring experience.
Templates support public GitHub-based template gallery.
Limitations
No automatic refresh.
No dense layout like dashboards, which make workbooks less useful as a single pane of glass. Intended more
for providing deeper insights.
Power BI
Power BI is particularly useful for creating business-centric dashboards and reports, as well as reports analyzing
long-term KPI trends. You can import the results of a log query into a Power BI dataset so you can take advantage
of its features such as combining data from different sources and sharing reports on the web and mobile devices.
Advantages
Rich visualizations.
Extensive interactivity including zoom-in and cross-filtering.
Easy to share throughout your organization.
Integration with other data from multiple data sources.
Better performance with results cached in a cube.
Limitations
Supports logs but not metrics.
No Azure integration. Can't manage dashboards and models through Azure Resource Manager.
Query results need to be imported into Power BI model to configure. Limitation on result size and refresh.
Limited data refresh of eight times per day.
Grafana
Grafana is an open platform that excels in operational dashboards. It's particularly useful for detecting and
isolating and triaging operational incidents. You can add Grafana Azure Monitor data source plugin to your Azure
subscription to have it visualize your Azure metrics data.
Advantages
Rich visualizations.
Rich ecosystem of datasources.
Data interactivity including zoom in.
Supports parameters.
Limitations
No Azure integration. Can't manage dashboards and models through Azure Resource Manager.
Cost to support additional Grafana infrastructure or additional cost for Grafana Cloud.
Build your own custom application

You can access data in log and metric data in Azure Monitor through their API using any REST client, which allows
you to build your own custom websites and applications.
Advantages
Complete flexibility in UI, visualization, interactivity, and features.
Combine metrics and log data with other data sources.
Disadvantages
Significant engineering effort required.
Next steps
Learn about the data collected by Azure Monitor.
Learn about Azure dashboards.
Learn about Views in Azure Monitor.
Learn about Workbooks.
Learn about import log data into Power BI.
Learn about the Grafana Azure Monitor data source plugin.
Azure Monitor partner integrations
Listed in alphabetical order.
AlertLogic Log Manager
Alert Logic Log Manager collects VM, application, and Azure platform logs for security analysis and retention. It
also collects the Azure Activity Log through the Azure Monitor API. This information is used to detect malfeasance
and meet compliance requirements.
Go to the documentation.
AppDynamics
AppDynamics Application Performance Management (APM ) enables application owners to rapidly troubleshoot
performance bottlenecks and optimize the performance of their applications running in Azure environment. It can
monitor Azure Cloud Services (PaaS ), web & worker roles, Virtual Machines (IaaS ), Remote Service Detection
(Microsoft Azure Service Bus), Microsoft Azure Queue, Microsoft Azure Remote Services (Azure Blob), Azure
Queue (Microsoft Service Bus), Data Storage, and Microsoft Azure Blob Storage. AppDynamics APM is available in
the Azure Marketplace.
Microfocus ArcSight
ArcSight has a smart connector for Azure Monitor event hubs.
Learn more.
Atlassian JIRA
You can create JIRA tickets on Azure Monitor alerts.

Botmetric
Learn more.
Circonus
Circonus is a microservices monitoring and analytics platform built for on premises or SaaS deployment. It is fully
automatable API-Centric platform is more scalable and reliable than systems it monitors. Developed for the
requirements of DevOps, Circonus delivers percentile-based alerts, graphs, dashboards, and machine-learning
intelligence that enable business optimization. Circonus monitors your Microsoft Azure cloud resources and their
applications in real time. You can use Circonus to collect and track metrics for the variables you want to measure
for your resources and applications. With Circonus, you gain system-wide visibility into Azure’s resource
utilization, application performance, and operational health.
CloudHealth
Unite and automate your cloud with a platform built to save time and money. CloudHealth provides visibility,
intuitive optimization, and rock-solid governance practices for cloud management. The CloudHealth platform
enables enterprises and MSPs to maximize return on cloud investments. Make confident decisions around cost,
usage, performance, and security.
Learn More.
CloudMonix
CloudMonix offers monitoring, automation, and self-healing services for Microsoft Azure platform.
Datadog
Datadog is the world’s leading monitoring service for cloud-scale applications. It brings together data from servers,
databases, tools, and services to present a unified view of your entire stack. These capabilities are provided on a
SaaS -based data analytics platform. This service enables Dev and Ops teams to work collaboratively to avoid
downtime, resolve performance problems, and ensure that development and deployment cycles finish on time. By
integrating Datadog and Azure, you can collect and view metrics from across your infrastructure. Correlate VM
metrics with application-level metrics. Slice and dice your metrics using any combination of properties and custom
tags.
Dynatrace
The Dynatrace OneAgent integrates with Azure VMs and App Services via the Azure extension mechanism. This
way Dynatrace OneAgent can gather performance metrics about hosts, network, and services. Besides just
displaying metrics, Dynatrace visualizes environments end-to-end. It shows transactions from the client side to the
database layer. Dynatrace provides AI-based correlation of problems and fully integrated root-cause-analysis to
give method level insights into code and database. This insight makes troubleshooting and performance
optimizations much easier.
Elastic
Elastic is a search company. As the creators of the Elastic Stack (Elasticsearch, Kibana, Beats, and Logstash), Elastic
builds self-managed and SaaS offerings that make data usable in real time and at scale for search, logging, security,
and analytics use cases.
Grafana
Grafana is an open-source application that enables you to visualize time series metric data.
InfluxData
InfluxData, the creator of InfluxDB, delivers a modern Open Source Platform built from the ground up for
analyzing metrics and events (time series data) for DevOps and IoT applications. Whether the data comes from
humans, sensors, or machines, InfluxData empowers developers to build next-generation monitoring, analytics,
and IoT applications faster, easier, and to scale delivering real business value quickly. Based in San Francisco,
InfluxData’s more than 420 customers include Cisco, eBay, IBM, and Siemens.
Logic Monitor
LogicMonitor® is the leading SaaS -based, performance monitoring platform for complex IT infrastructure. With
coverage for thousands of technologies, LogicMonitor provides granular visibility into infrastructure and
application performance. LM Cloud’s comprehensive Azure monitoring enables users to correlate the performance
of Azure cloud, on-premises, and hybrid cloud resources -- all from a single platform. Automated resource
discovery, built in monitoring templates, preconfigured alert thresholds, and customizable dashboards combine to
give IT the speed, flexibility, and visibility required to succeed.
Moogsoft
Moogsoft AIOps accelerates the agile business transformation.

Microsoft Azure Automation and Control tools provide a real-time window into the status of the Applications and
microservices deployed in Azure. They help orchestrate diagnostics and runbooks for faster remediation. Other
third-party tools provide a window into the on-premises Applications and infrastructure status.
Moogsoft AIOps automates the Event to Remediation workflow without changing existing processes and
organizational structure.
Moogsoft runs in your Azure real-estate with integration to monitoring and automation tools across the hybrid
fabric. Moogsoft
actively detects application impacting incidents earlier
dynamically orchestrates the appropriate resources to make them situation aware
reduces the mean time to remediate and adverse impact on customer experience.
NewRelic
Learn more.
OpsGenie
OpsGenie acts as a dispatcher for the alerts generated by Azure. OpsGenie determines the right people to notify
based on on-call schedules and escalations. It can notify them using by email, text messages (SMS ), phone calls, or
push notifications. Azure generates alerts for detected problems. OpsGenie ensures the right people are working
on the problem.
PagerDuty
PagerDuty, the leading incident management solution, has provided first-class support for Azure Alerts on metrics.
PagerDuty supports notifications on Azure Monitor alerts, autoscale notifications, activity log events, and platform-
level metrics for Azure services. These enhancements give you increased visibility into the core Azure Platform.
You can take full advantage of PagerDuty’s incident management capabilities for real-time response. The expanded
Azure integration is made possible through webhooks. Webhooks allow you to set up and customize the solution
quickly and easily.
QRadar
The Microsoft Azure DSM and Microsoft Azure Event Hub Protocol are available for download from the IBM
support website. You can learn more about the integration with Azure here.
ScienceLogic
ScienceLogic delivers the next generation IT service assurance platform for managing any technology, anywhere.
ScienceLogic delivers the scale, security, automation, and resiliency necessary to simplify the tasks of managing IT
resources, services, and applications. The ScienceLogic platform uses Azure APIs to interface with Microsoft Azure.
ScienceLogic gives you real-time visibility into your Azure services and resources. So you know when something’s
not working and you can fix it faster. You can also manage Azure alongside your other clouds and data center
systems and services.
Learn more.
Serverless360
Serverless360 is a one platform tool to operate, manage, and monitor Azure serverless components.
Manageability is one of the key challenges with serverless implementations. Hundreds of small, discrete serverless
services are scattered in various places – managing and operating such solutions is complex. Serverless360 solves
these challenges with rich set of sophisticated tools. It can monitor serverless services like Azure Functions, Logic
Apps, Event Grids, Service Bus Queues, Topics, Relays, Event Hubs, Storage queues, files, blob, and tables.
Serverless360 is available in the Azure Marketplace. These capabilities are available on both SaaS and private
hosting (hosted on your own environment).
Learn more.
SignalFx
SignalFx is the leader in real-time operational intelligence for data-driven DevOps. The service discovers and
collects metrics across every component in the cloud. It replaces traditional point tools and provides real-time
visibility into today’s dynamic environments. Leveraging the massively scalable SignalFx platform, the SaaS
platform is optimized for container and microservices based architectures and provides powerful visualization,
proactive alerting, and collaborative triage capabilities across organizations of all sizes. SignalFx integrates directly
with Azure Monitor as well as through open-source connectors such as Telegraf, statsD, and collectd to provide
best in class dashboards, analytics, and alerts for Azure.
SIGNL4
SIGNL4 - the mobile alerting app for operations teams - is the fastest way to route critical alerts from Azure
Monitor to the right people at the right time – anywhere by push, text, and voice calls. SIGNL4 manages on-call
duties and shifts of your team, tracks delivery and ownership of alerts and escalates if necessary. Full transparency
across your team is provided. Using the super-easy REST web-hook of SIGNL4 any Azure service can be
connected with no effort. With SIGNL4, you will see up to 10x faster response over email notifications and manual
alerting.
SolarWinds
Learn more.
Splunk
The Azure Monitor Add-on for Splunk is available in the Splunkbase here.
Sumo Logic
Sumo Logic is a secure, cloud-native, machine data analytics service, delivering real-time, continuous intelligence
from structured, semi-structured, and unstructured data across the entire application lifecycle and stack. More than
1,000 customers around the globe rely on Sumo Logic for the analytics and insights to build, run, and secure their
applications and cloud infrastructures. With Sumo Logic, customers gain a multi-tenant, service-model advantage
to help increase competitive advantage, business value, and growth.
Learn more.
Turbonomic
Turbonomic delivers workload automation for hybrid clouds by simultaneously optimizing performance, cost, and
compliance in real time. Turbonomic helps organizations be elastic in their Azure estate by continuously optimizing
the estate to ensure applications constantly get the resources they require to deliver their SLA and nothing more
across compute, storage, and network for the IaaS and PaaS layer. Organizations can simulate migrations, properly
scale workloads, and retire datacenter resources to responsibly migrate to Azure on-time, within budget, while
assuring both performance and compliance. Turbonomic is API driven and runs as an agentless VM in Azure and
on-premises.
Learn more.
Next steps
Learn more about Azure Monitor
Access metrics using the REST API
Stream the Activity Log to a non-Microsoft service
Stream Diagnostic Logs to a non-Microsoft service
Log Analytics FAQ
NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will
continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure
PowerShell.
This Microsoft FAQ is a list of commonly asked questions about Log Analytics in Microsoft Azure. If you have any
additional questions about Log Analytics, go to the discussion forum and post your questions. When a question is
frequently asked, we add it to this article so that it can be found quickly and easily.
New Logs experience

Q: What's the difference between the new Logs experience and Log Analytics?
A: They are the same thing. Log Analytics is being integrated as a feature in Azure Monitor to provide a more
unified monitoring experience. The new Logs experience in Azure Monitor is exactly the same as the Log Analytics
queries that many customers have already been using.
Q: Can I still use Log Search?
A: Log Search is currently still available in the OMS portal and in the Azure portal under the name Logs (classic).
The OMS portal will be officially retired on January 15, 2019. The classic Logs experience in Azure portal will be
gradually retired and replaced the new Logs experience.
Q. Can I still use Advanced Analytics Portal?
The new Logs experience in the Azure portal is based on the Advanced Analytics Portal, but it still can be accessed
outside of the Azure portal. The roadmap for retiring this external portal will be announced soon.
Q. Why can't I see Query Explorer and Save buttons in the new Logs experience?
Query Explorer, Save and Set Alert buttons are not available when exploring Logs in the context of a specific
resource. To create alerts, save or load a query, Logs must be scoped to a workspace. To open Logs in workspace
context, select All services > Monitor > Logs. The last used workspace is selected, but you can select any other
workspace. See Viewing and analyzing data in Log Analytics for more information.
Q. How do I extract Custom Fields in the new Logs experience?
A: Custom Fields extraction are currently supported in the classic Logs experience.
Q. Where do I find List view in the new Logs?
A: List view is not available in the new Logs. There is an arrow to the left of each record in the results table. Click
this arrow to open the details for a specific record.
Q. After running a query, a list of suggested filters are available. How can I see filters?
A: Click ‘Filters’ on the left pane to see a preview of the new Filters implementation. This is now based on your full
result set instead of being limited by the 10,000 record limit of the UI. This is currently a list of the most popular
filters and the 10 most common values for each filter.
Q. Why am I getting the error: "Register resource provider 'Microsoft.Insights' for this subscription to enable
this query" in Logs, after drilling-in from VM?
A: By default, many resource providers are automatically registered, however, you may need to manually register
some resource providers. This configures your subscription to work with the resource provider. The scope for
registration is always the subscription. See Resource providers and types for more information.
Q. Why am I am getting no access error message when accessing Logs from a VM page?
A: To view VM Logs, you need to be granted with read permission to the workspaces that stores the VM logs. In
these cases, your administrator must grant you with to permissions in Azure.
Q. Why can I can access my workspace in OMS portal, but I get the error “You have no access” in the Azure
portal?
A: To access a workspace in Azure, you must have Azure permissions assigned. There are some cases where you
may not have appropriate access permissions. In these cases, your administrator must grant you with permissions
in Azure.See OMS portal moving to Azure for more information.
Q. Why can't I can’t see View Designer entry in Logs?
A: View Designer is only available in Logs for users assigned with Contributor permissions or higher.
Q. Can I still use the Analytics portal outside of Azure?
A. Yes, the Logs page in Azure and the Advanced Analytics portal are based on the same code. Log Analytics is
being integrated as a feature in Azure Monitor to provide a more unified monitoring experience. You can still
access Analytics portal using the URL:
https://portal.loganalytics.io/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/workspaces/{w
orkspaceName}.
General
Q. How can I see my views and solutions in Azure portal?
A: The list of views and installed solutions are available in Azure portal. Click All services. In the list of resources,
select Monitor, then click ...More. The last used workspace is selected, but you can select any other workspace.
Q. Why I can’t create workspaces in West Central US region?
A: This region is at temporary capacity limit. This limit is planned to be addressed by end of September, 2019.
Q. Does Log Analytics use the same agent as Azure Security Center?
A: In early June 2017, Azure Security Center began using the Microsoft Monitoring Agent to collect and store data.
To learn more, see Azure Security Center Platform Migration FAQ.
Q. What checks are performed by the AD and SQL Assessment solutions?
A: The following query shows a description of all checks currently performed:
(Type=SQLAssessmentRecommendation OR Type=ADAssessmentRecommendation) | dedup RecommendationId | select

FocusArea, ActionArea, Recommendation, Description | sort Type, FocusArea,ActionArea, Recommendation
The results can then be exported to Excel for further review.

Q. Why do I see something different than OMS in the System Center Operations Manager console?
A: Depending on what Update Rollup of Operations Manager you are on, you may see a node for System Center
Advisor, Operational Insights, or Log Analytics.
The text string update to OMS is included in a management pack, which needs to be imported manually. To see the
current text and functionality, follow the instructions on the latest System Center Operations Manager Update
Rollup KB article and refresh the console.
Q: Is there an on-premises version of Log Analytics?
A: No. Log Analytics is a scalable cloud service that processes and stores large amounts of data.
Q. How do I troubleshoot if Log Analytics is no longer collecting data?
A: For a subscription and workspace created before April 2, 2018 that is on the Free pricing tier, if more than 500
MB of data is sent in a day, data collection stops for the rest of the day. Reaching the daily limit is a common reason
that Log Analytics stops collecting data, or data appears to be missing.
Log Analytics creates an event of type Heartbeat and can be used to determine if data collection stops.
Run the following query in search to check if you are reaching the daily limit and missing data:
Heartbeat | summarize max(TimeGenerated)
To check a specific computer, run the following query:

Heartbeat | where Computer=="contosovm" | summarize max(TimeGenerated)
When data collection stops, depending on the time range selected, you will not see any records returned.
The following table describes reasons that data collection stops and a suggested action to resume data collection:
REASON DATA COLLECTION STOPS TO RESUME DATA COLLECTION
Limit of free data reached1 Wait until the following month for collection to automatically
restart, or
Change to a paid pricing tier
Azure subscription is in a suspended state due to: Convert to a paid subscription

Free trial ended Convert to a paid subscription
Azure pass expired Remove limit, or wait until limit resets
Monthly spending limit reached (for example on an MSDN or
Visual Studio subscription)
1 If your
workspace is on the Free pricing tier, you're limited to sending 500 MB of data per day to the service.
When you reach the daily limit, data collection stops until the next day. Data sent while data collection is stopped is
not indexed and is not available for searching. When data collection resumes, processing occurs only for new data
sent.
Log Analytics uses UTC time and each day starts at midnight UTC. If the workspace reaches the daily limit,
processing resumes during the first hour of the next UTC day.
Q. How can I be notified when data collection stops?
A: Use the steps described in create a new log alert to be notified when data collection stops.
When creating the alert for when data collection stops, set the:
Define alert condition specify your Log Analytics workspace as the resource target.
Alert criteria specify the following:
Signal Name select Custom log search.
Search query to
Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)
Alert logic is Based on number of results and Condition is Greater than a Threshold of 0
Time period of 30 minutes and Alert frequency to every 10 minutes
Define alert details specify the following:
Name to Data collection stopped
Severity to Warning
Specify an existing or create a new Action Group so that when the log alert matches criteria, you are notified if you
have a heartbeat missing for more than 15 minutes.
Configuration
Q. Can I change the name of the table/blob container used to read from Azure Diagnostics (WAD)?
A. No, it is not currently possible to read from arbitrary tables or containers in Azure storage.
Q. What IP addresses does the Log Analytics service use? How do I ensure that my firewall only allows traffic to
the Log Analytics service?
A. The Log Analytics service is built on top of Azure. Log Analytics IP addresses are in the Microsoft Azure
Datacenter IP Ranges.
As service deployments are made, the actual IP addresses of the Log Analytics service change. The DNS names to
allow through your firewall are documented in network requirements.
Q. I use ExpressRoute for connecting to Azure. Does my Log Analytics traffic use my ExpressRoute connection?
A. The different types of ExpressRoute traffic are described in the ExpressRoute documentation.
Traffic to Log Analytics uses the public-peering ExpressRoute circuit.
Q. Is there a simple and easy way to move an existing Log Analytics workspace to another Log Analytics
workspace/Azure subscription?
A. The Move-AzResource cmdlet lets you move a Log Analytics workspace, and also an Automation account from
one Azure subscription to another. For more information, see Move-AzResource.
This change can also be made in the Azure portal.
You can’t move data from one Log Analytics workspace to another, or change the region that Log Analytics data is
stored in.
Q: How do I add Log Analytics to System Center Operations Manager?
A: Updating to the latest update rollup and importing management packs enables you to connect Operations
Manager to Log Analytics.
NOTE
The Operations Manager connection to Log Analytics is only available for System Center Operations Manager 2012 SP1 and
later.
Q: How can I confirm that an agent is able to communicate with Log Analytics?
A: To ensure that the agent can communicate with OMS, go to: Control Panel, Security & Settings, Microsoft
Monitoring Agent.
Under the Azure Log Analytics (OMS ) tab, look for a green check mark. A green check mark icon confirms that
the agent is able to communicate with the Azure service.
A yellow warning icon means the agent is having issues communication with Log Analytics. One common reason
is the Microsoft Monitoring Agent service has stopped. Use service control manager to restart the service.
Q: How do I stop an agent from communicating with Log Analytics?
A: In System Center Operations Manager, remove the computer from the OMS managed computers list.
Operations Manager updates the configuration of the agent to no longer report to Log Analytics. For agents
connected to Log Analytics directly, you can stop them from communicating through: Control Panel, Security &
Settings, Microsoft Monitoring Agent. Under Azure Log Analytics (OMS ), remove all workspaces listed.
Q: Why am I getting an error when I try to move my workspace from one Azure subscription to another?
A: To move a workspace to a different subscription or resource group, you must first unlink the Automation
account in the workspace. Unlinking an Automation account requires the removal of these solutions if they are
installed in the workspace: Update Management, Change Tracking, or Start/Stop VMs during off-hours are
removed. After these solutions are removed, unlink the Automation account by selecting Linked workspaces on
the left pane in the Automation account resource and click Unlink workspace on the ribbon.
Removed solutions need to be reinstalled in the workspace, and the Automation link to the workspace needs to
be restated after the move.
Ensure you have permission in both Azure subscriptions.

Q: Why am I getting an error when I try to update a SavedSearch?
A: You need to add 'etag' in the body of the API, or the Azure Resource Manager template properties:
"properties": {
"etag": "*",
"query": "SecurityEvent | where TimeGenerated > ago(1h) | where EventID == 4625 | count",
"displayName": "An account failed to log on",
"category": "Security"
}
Agent data
Q. How much data can I send through the agent to Log Analytics? Is there a maximum amount of data per
customer?
A. The free plan sets a daily cap of 500 MB per workspace. The standard and premium plans have no limit on the
amount of data that is uploaded. As a cloud service, Log Analytics is designed to automatically scale up to handle
the volume coming from a customer – even if it is terabytes per day.
The Log Analytics agent was designed to ensure it has a small footprint. The data volume varies based on the
solutions you enable. You can find detailed information on the data volume and see the breakdown by solution in
the Usage page.
For more information, you can read a customer blog showing their results after evaluating the resource utilization
(footprint) of the OMS agent.
Q. How much network bandwidth is used by the Microsoft Management Agent (MMA ) when sending data to
Log Analytics?
A. Bandwidth is a function on the amount of data sent. Data is compressed as it is sent over the network.
Q. How much data is sent per agent?
A. The amount of data sent per agent depends on:
The solutions you have enabled
The number of logs and performance counters being collected
The volume of data in the logs
The free pricing tier is a good way to onboard several servers and gauge the typical data volume. Overall usage is
shown on the Usage page.
For computers that are able to run the WireData agent, use the following query to see how much data is being
sent:
Type=WireData (ProcessName="C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe")

(Direction=Outbound) | measure Sum(TotalBytes) by Computer
Next steps
Get started with Log Analytics to learn more about Log Analytics and get up and running in minutes.
Application Insights: Frequently Asked Questions
Configuration problems
I'm having trouble setting up my:
.NET app
Monitoring an already-running app
Azure diagnostics
Java web app
I get no data from my server
Set firewall exceptions
Set up an ASP.NET server
Set up a Java server
Can I use Application Insights with ...?

Web apps on an IIS server in Azure VM or Azure virtual machine scale set
Web apps on an IIS server - on-premises or in a VM
Java web apps
Node.js apps
Web apps on Azure
Cloud Services on Azure
App servers running in Docker
Single-page web apps
SharePoint
Windows desktop app
Other platforms
Is it free?
Yes, for experimental use. In the basic pricing plan, your application can send a certain allowance of data each
month free of charge. The free allowance is large enough to cover development, and publishing an app for a small
number of users. You can set a cap to prevent more than a specified amount of data from being processed.
Larger volumes of telemetry are charged by the Gb. We provide some tips on how to limit your charges.
The Enterprise plan incurs a charge for each day that each web server node sends telemetry. It is suitable if you
want to use Continuous Export on a large scale.
Read the pricing plan.
How much does it cost?

Open the Usage and estimated costs page in an Application Insights resource. There's a chart of recent
usage. You can set a data volume cap, if you want.
Open the Azure Billing blade to see your bills across all resources.
What does Application Insights modify in my project?
The details depend on the type of project. For a web application:
Adds these files to your project:
ApplicationInsights.config.
ai.js
Installs these NuGet packages:
Application Insights API - the core API
Application Insights API for Web Applications - used to send telemetry from the server
Application Insights API for JavaScript Applications - used to send telemetry from the client
The packages include these assemblies:
Microsoft.ApplicationInsights
Microsoft.ApplicationInsights.Platform
Inserts items into:
Web.config
packages.config
(New projects only - if you add Application Insights to an existing project, you have to do this manually.)
Inserts snippets into the client and server code to initialize them with the Application Insights resource ID.
For example, in an MVC app, code is inserted into the master page Views/Shared/_Layout.cshtml
How do I upgrade from older SDK versions?

See the release notes for the SDK appropriate to your type of application.
How can I change which Azure resource my project sends data to?
In Solution Explorer, right-click ApplicationInsights.config and choose Update Application Insights. You can
send the data to an existing or new resource in Azure. The update wizard changes the instrumentation key in
ApplicationInsights.config, which determines where the server SDK sends your data. Unless you deselect "Update
all," it will also change the key where it appears in your web pages.
What is Status Monitor?

A desktop app that you can use in your IIS web server to help configure Application Insights in web apps. It
doesn't collect telemetry: you can stop it when you are not configuring an app.
Learn more.
What telemetry is collected by Application Insights?

From server web apps:
HTTP requests
Dependencies. Calls to: SQL Databases; HTTP calls to external services; Azure Cosmos DB, table, blob storage,
and queue.
Exceptions and stack traces.
Performance Counters - If you use Status Monitor, Azure monitoring for App Services, Azure monitoring for
VM or virtual machine scale set, or the Application Insights collectd writer.
Custom events and metrics that you code.
Trace logs if you configure the appropriate collector.
From client web pages:
Page view counts
AJAX calls Requests made from a running script.
Page view load data
User and session counts
Authenticated user IDs
From other sources, if you configure them:
Azure diagnostics
Import to Analytics
Log Analytics
Logstash
Can I filter out or modify some telemetry?

Yes, in the server you can write:
Telemetry Processor to filter or add properties to selected telemetry items before they are sent from your app.
Telemetry Initializer to add properties to all items of telemetry.
Learn more for ASP.NET or Java.
How are city, country/region, and other geo location data calculated?
We look up the IP address (IPv4 or IPv6) of the web client using GeoLite2.
Browser telemetry: We collect the sender's IP address.
Server telemetry: The Application Insights module collects the client IP address. It is not collected if
X-Forwarded-For is set.
To learn more about how IP address and geolocation data is collected in Application Insights refer to this
article.
You can configure the ClientIpHeaderTelemetryInitializer to take the IP address from a different header. In some
systems, for example, it is moved by a proxy, load balancer, or CDN to X-Originating-IP . Learn more.
You can use Power BI to display your request telemetry on a map.
How long is data retained in the portal? Is it secure?

Take a look at Data Retention and Privacy.
Could personal data be sent in the telemetry?

This is possible if your code sends such data. It can also happen if variables in stack traces include personal data.
Your development team should conduct risk assessments to ensure that personal data is properly handled. Learn
more about data retention and privacy.
All octets of the client web address are always set to 0 after the geo location attributes are looked up.
My Instrumentation Key is visible in my web page source.
This is common practice in monitoring solutions.
It can't be used to steal your data.
It could be used to skew your data or trigger alerts.
We have not heard that any customer has had such problems.
You could:
Use two separate Instrumentation Keys (separate Application Insights resources), for client and server data. Or
Write a proxy that runs in your server, and have the web client send data through that proxy.
How do I see POST data in Diagnostic search?

We don't log POST data automatically, but you can use a TrackTrace call: put the data in the message parameter.
This has a longer size limit than the limits on string properties, though you can't filter on it.
Should I use single or multiple Application Insights resources?

Use a single resource for all the components or roles in a single business system. Use separate resources for
development, test, and release versions, and for independent applications.
See the discussion here
Example - cloud service with worker and web roles
How do I dynamically change the instrumentation key?

Discussion here
Example - cloud service with worker and web roles
What are the User and Session counts?

The JavaScript SDK sets a user cookie on the web client, to identify returning users, and a session cookie to
group activities.
If there is no client-side script, you can set cookies at the server.
If one real user uses your site in different browsers, or using in-private/incognito browsing, or different
machines, then they will be counted more than once.
To identify a logged-in user across machines and browsers, add a call to setAuthenticatedUserContext().
Have I enabled everything in Application Insights?

WHAT YOU SHOULD SEE HOW TO GET IT WHY YOU WANT IT
Availability charts Web tests Know your web app is up
Server app perf: response times, ... Add Application Insights to your Detect perf issues
project or Install AI Status Monitor on
server (or write your own code to track
dependencies)
Dependency telemetry Install AI Status Monitor on server Diagnose issues with databases or
other external components
WHAT YOU SHOULD SEE HOW TO GET IT WHY YOU WANT IT
Get stack traces from exceptions Insert TrackException calls in your code Detect and diagnose exceptions
(but some are reported automatically)
Search log traces Add a logging adapter Diagnose exceptions, perf issues
Client usage basics: page views, JavaScript initializer in web pages Usage analytics
sessions, ...
Client custom metrics Tracking calls in web pages Enhance user experience
Server custom metrics Tracking calls in server Business intelligence
Why are the counts in Search and Metrics charts unequal?

Sampling reduces the number of telemetry items (requests, custom events, and so on) that are actually sent from
your app to the portal. In Search, you see the number of items actually received. In metric charts that display a
count of events, you see the number of original events that occurred.
Each item that is transmitted carries an itemCount property that shows how many original events that item
represents. To observe sampling in operation, you can run this query in Analytics:
requests | summarize original_events = sum(itemCount), transmitted_events = count()
Automation
Configuring Application Insights
You can write PowerShell scripts using Azure Resource Monitor to:
Create and update Application Insights resources.
Set the pricing plan.
Get the instrumentation key.
Add a metric alert.
Add an availability test.
You can't set up a Metric Explorer report or set up continuous export.
Querying the telemetry
Use the REST API to run Analytics queries.
How can I set an alert on an event?

Azure alerts are only on metrics. Create a custom metric that crosses a value threshold whenever your event
occurs. Then set an alert on the metric. Note that: you'll get a notification whenever the metric crosses the
threshold in either direction; you won't get a notification until the first crossing, no matter whether the initial value
is high or low; there is always a latency of a few minutes.
Are there data transfer charges between an Azure web app and
Application Insights?
If your Azure web app is hosted in a data center where there is an Application Insights collection endpoint,
there is no charge.
If there is no collection endpoint in your host data center, then your app's telemetry will incur Azure outgoing
charges.
This doesn't depend on where your Application Insights resource is hosted. It just depends on the distribution of
our endpoints.
Can I send telemetry to the Application Insights portal?

We recommend you use our SDKs and use the SDK API. There are variants of the SDK for various platforms.
These SDKs handle buffering, compression, throttling, retries, and so on. However, the ingestion schema and
endpoint protocol are public.
Can I monitor an intranet web server?

Yes, but you will need to allow traffic to our services by either firewall exceptions or proxy redirects.
QuickPulse https://rt.services.visualstudio.com:443
ApplicationIdProvider https://dc.services.visualstudio.com:443
TelemetryChannel https://dc.services.visualstudio.com:443
Review our full list of services and IP addresses here.

Firewall exception
Allow your web server to send telemetry to our endpoints.
Gateway redirect
Route traffic from your server to a gateway on your intranet by overwriting Endpoints in your configuration. If
these "Endpoint" properties are not present in your config, these classes will use the default values shown below
in the example ApplicationInsights.config.
Your gateway should route traffic to our endpoint's base address. In your configuration, replace the default values
with http://<your.gateway.address>/<relative path> .
Example ApplicationInsights.config with default endpoints:
<ApplicationInsights>
...
<TelemetryModules>
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule,
Microsoft.AI.PerfCounterCollector">
<QuickPulseServiceEndpoint>https://rt.services.visualstudio.com/QuickPulseService.svc</QuickPulseServiceEndpoi
nt>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
<EndpointAddress>https://dc.services.visualstudio.com/v2/track</EndpointAddress>
</TelemetryChannel>
...
<ApplicationIdProvider
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationI
dProvider, Microsoft.ApplicationInsights">
<ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
</ApplicationIdProvider>
...
</ApplicationInsights>
Note ApplicationIdProvider is available starting in v2.6.0
Proxy passthrough
Proxy passthrough can be achieved by configuring either a machine level or application level proxy. For more
information see dotnet's article on DefaultProxy.
Example Web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
</defaultProxy>
</system.net>
Can I run Availability web tests on an intranet server?

Our web tests run on points of presence that are distributed around the globe. There are two solutions:
Firewall door - Allow requests to your server from the long and changeable list of web test agents.
Write your own code to send periodic requests to your server from inside your intranet. You could run Visual
Studio web tests for this purpose. The tester could send the results to Application Insights using the
TrackAvailability() API.
How long does it take for telemetry to be collected?

Most Application Insights data has a latency of under 5 minutes. Some data can take longer; typically larger log
files. For more information, see the Application Insights SLA.
More answers
Application Insights forum
Designing your Azure Monitor Logs deployment
Azure Monitor stores log data in a Log Analytics workspace, which is an Azure resource and a container where
data is collected, aggregated, and serves as an administrative boundary. While you can deploy one or more
workspaces in your Azure subscription, there are several considerations you should understand in order to ensure
your initial deployment is following our guidelines to provide you with a cost effective, manageable, and scalable
deployment meeting your organizations needs.
Data in a workspace is organized into tables, each of which stores different kinds of data and has its own unique
set of properties based on the resource generating the data. Most data sources will write to their own tables in a
Log Analytics workspace.
A Log Analytics workspace provides:

A geographic location for data storage.
Data isolation by granting different users access rights following one of our recommended design strategies.
Scope for configuration of settings like pricing tier, retention, and data capping.
This article provides a detailed overview of the design and migration considerations, access control overview, and
an understanding of the design implementations we recommend for your IT organization.
Important considerations for an access control strategy

Identifying the number of workspaces you need is influenced by one or more of the following requirements:
You are a global company and you need log data stored in specific regions for data sovereignty or compliance
reasons.
You are using Azure and you want to avoid outbound data transfer charges by having a workspace in the same
region as the Azure resources it manages.
You manage multiple departments or business groups, and you want each to see their own data, but not data
from others. Also, there is no business requirement for a consolidated cross department or business group
view.
IT organizations today are modeled following either a centralized, decentralized, or an in-between hybrid of both
structures. As a result, the following workspace deployment models have been commonly used to map to one of
these organizational structures:
Centralized: All logs are stored in a central workspace and administered by a single team, with Azure Monitor
providing differentiated access per-team. In this scenario, it is easy to manage, search across resources, and
cross-correlate logs. The workspace can grow significantly depending on the amount of data collected from
multiple resources in your subscription, with additional administrative overhead to maintain access control to
different users.
Decentralized: Each team has their own workspace created in a resource group they own and manage, and
log data is segregated per resource. In this scenario, the workspace can be kept secure and access control is
consistent with resource access, but it's difficult to cross-correlate logs. Users who need a broad view of many
resources cannot analyze the data in a meaningful way.
Hybrid: Security audit compliance requirements further complicate this scenario because many organizations
implement both deployment models in parallel. This commonly results in a complex, expensive, and hard-to-
maintain configuration with gaps in logs coverage.
When using the Log Analytics agents to collect data, you need to understand the following in order to plan your
agent deployment:
To collect data from Windows agents, you can configure each agent to report to one or more workspaces, even
while it is reporting to a System Center Operations Manager management group. The Windows agent can
report up to four workspaces.
The Linux agent does not support multi-homing and can only report to a single workspace.
If you are using System Center Operations Manager 2012 R2 or later:
Each Operations Manager management group can be connected to only one workspace.
Linux computers reporting to a management group must be configured to report directly to a Log Analytics
workspace. If your Linux computers are already reporting directly to a workspace and you want to monitor
them with Operations Manager, follow these steps to report to an Operations Manager management group.
You can install the Log Analytics Windows agent on the Windows computer and have it report to both
Operations Manager integrated with a workspace, and a different workspace.
Access control overview

With role-based access control (RBAC ), you can grant users and groups only the amount of access they need to
work with monitoring data in a workspace. This allows you to align with your IT organization operating model
using a single workspace to store collected data enabled on all your resources. For example, you grant access to
your team responsible for infrastructure services hosted on Azure virtual machines (VMs), and as a result they'll
have access to only the logs generated by the VMs. This is following our new resource-context log model. The
basis for this model is for every log record emitted by an Azure resource, it is automatically associated with this
resource. Logs are forwarded to a central workspace that respects scoping and RBAC based on the resources.
The data a user has access to is determined by a combination of factors that are listed in the following table. Each
is described in the sections below.
FACTOR DESCRIPTION
Access mode Method the user uses to access the workspace. Defines the
scope of the data available and the access control mode that's
applied.
Access control mode Setting on the workspace that defines whether permissions
are applied at the workspace or resource level.
Permissions Permissions applied to individual or groups of users for the

workspace or resource. Defines what data the user will have
access to.
Table level RBAC Optional granular permissions that apply to all users
regardless of their access mode or access control mode.
Defines which data types a user can access.
Access mode
The access mode refers to how a user accesses a Log Analytics workspace and defines the scope of data they can
access.
Users have two options for accessing the data:
Workspace-context: You can view all logs in the workspace you have permission to. Queries in this mode
are scoped to all data in all tables in the workspace. This is the access mode used when logs are accessed
with the workspace as the scope, such as when you select Logs from the Azure Monitor menu in the
Azure portal.
Resource-context: When you access the workspace for a particular resource, resource group, or
subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for
only resources in all tables that you have access to. Queries in this mode are scoped to only data associated
with that resource. This mode also enables granular RBAC.
NOTE
Logs are available for resource-context queries only if they were properly associated with the relevant resource.
Currently, the following resources have limitations:
Computers outside of Azure
Service Fabric
You can test if logs are properly associated with their resource by running a query and inspecting the records you're
interested in. If the correct resource ID is in the _ResourceId property, then data is available to resource-centric
queries.
Azure Monitor automatically determines the right mode depending on the context you perform the log search
from. The scope is always presented in the top-left section of Log Analytics.
Comparing access modes
The following table summarizes the access modes:
WORKSPACE-CONTEX T RESOURCE-CONTEX T
Who is each model intended for? Central administration. Administrators Application teams. Administrators of
who need to configure data collection Azure resources being monitored.
and users who need access to a wide
variety of resources. Also currently
required for users who need to access
logs for resources outside of Azure.
WORKSPACE-CONTEX T RESOURCE-CONTEX T
What does a user require to view logs? Permissions to the workspace. See Read access to the resource. See
Workspace permissions in Manage Resource permissions in Manage
access using workspace permissions. access using Azure permissions.
Permissions can be inherited (such as
from the containing resource group) or
directly assigned to the resource.
Permission to the logs for the resource
will be automatically assigned.
What is the scope of permissions? Workspace. Users with access to the Azure resource. User can query logs for
workspace can query all logs in the specific resources, resource groups, or
workspace from tables that they have subscription they have access to from
permissions to. See Table access control any workspace but can't query logs for
other resources.
How can user access logs? Start Logs from Azure Monitor Start Logs from the menu for
menu. the Azure resource
Start Logs from Log Analytics Start Logs from Azure Monitor
workspaces. menu.
From Azure Monitor Start Logs from Log Analytics
Workbooks. workspaces.
From Azure Monitor
Workbooks.
Access control mode

The Access control mode is a setting on each workspace that defines how permissions are determined for the
workspace.
Require workspace permissions: This control mode does not allow granular RBAC. For a user to access
the workspace, they must be granted permissions to the workspace or to specific tables.
If a user accesses the workspace following the workspace-context mode, they have access to all data in any
table they've been granted access to. If a user accesses the workspace following the resource-context mode,
they have access to only data for that resource in any table they've been granted access to.
This is the default setting for all workspaces created before March 2019.
Use resource or workspace permissions: This control mode allows granular RBAC. Users can be granted
access to only data associated with resources they can view by assigning Azure read permission.
When a user accesses the workspace in workspace-context mode, workspace permissions apply. When a
user accesses the workspace in resource-context mode, only resource permissions are verified, and
workspace permissions are ignored. Enable RBAC for a user by removing them from workspace
permissions and allowing their resource permissions to be recognized.
This is the default setting for all workspaces created after March 2019.
NOTE
If a user has only resource permissions to the workspace, they are only able to access the workspace using resource-
context mode assuming the workspace access mode is set to Use resource or workspace permissions.
To learn how to change the access control mode in the portal, with PowerShell, or using a Resource Manager
template, see Configure access control mode.
Ingestion volume rate limit

month at a growing pace. The default ingestion rate threshold is set to 500 MB/min per workspace. If you send
data at a higher rate to a single workspace, some data is dropped, and an event is sent to the Operation table in
your workspace every 6 hours while the threshold continues to be exceeded. If your ingestion volume continues to
exceed the rate limit or you are expecting to reach it sometime soon, you can request an increase to your
workspace by opening a support request.
To be notified on such an event in your workspace, create a log alert rule using the following query with alert logic
base on number of results grater than zero.
Operation
|where OperationCategory == "Ingestion"
|where Detail startswith "The rate of data crossed the threshold"
Recommendations
This scenario covers a single workspace design in your IT organizations subscription that is not constrained by
data sovereignty or regulatory compliance, or needs to map to the regions your resources are deployed within. It
allows your organizations security and IT admin teams the ability to leverage the improved integration with Azure
access management and more secure access control.
All resources, monitoring solutions, and Insights such as Application Insights and Azure Monitor for VMs,
supporting infrastructure and applications maintained by the different teams are configured to forward their
collected log data to the IT organizations centralized shared workspace. Users on each team are granted access to
logs for resources they have been given access to.
Once you have deployed your workspace architecture, you can enforce this on Azure resources with Azure Policy.
It provides a way to define policies and ensure compliance with your Azure resources so they send all their
diagnostic logs to a particular workspace. For example, with Azure virtual machines or virtual machine scale sets,
you can use existing policies that evaluate workspace compliance and report results, or customize to remediate if
non-compliant.
Workspace consolidation migration strategy

For customers who have already deployed multiple workspaces and are interested in consolidating to the
resource-context access model, we recommend you take an incremental approach to migrate to the recommended
access model, and you don't attempt to achieve this quickly or aggressively. Following a phased approach to plan,
migrate, validate, and retire following a reasonable timeline will help avoid any unplanned incidents or unexpected
impact to your cloud operations. If you do not have a data retention policy for compliance or business reasons,
you need to assess the appropriate length of time to retain data in the workspace you are migrating from during
the process. While you are reconfiguring resources to report to the shared workspace, you can still analyze the
data in the original workspace as necessary. Once the migration is complete, if you're governed to retain data in
the original workspace before the end of the retention period, don't delete it.
While planning your migration to this model, consider the following:
Understand what industry regulations and internal policies regarding data retention you must comply with.
Make sure that your application teams can work within the existing resource-context functionality.
Identify the access granted to resources for your application teams and test in a development environment
before implementing in production.
Configure the workspace to enable Use resource or workspace permissions.
Remove application teams permission to read and query the workspace.
Enable and configure any monitoring solutions, Insights such as Azure Monitor for containers and/or Azure
Monitor for VMs, your Automation account(s), and management solutions such as Update Management,
Start/Stop VMs, etc., that were deployed in the original workspace.
Next steps
To implement the security permissions and controls recommended in this guide, review manage access to logs.
Get started with roles, permissions, and security with
Azure Monitor
NOTE
PowerShell.
Many teams need to strictly regulate access to monitoring data and settings. For example, if you have team
members who work exclusively on monitoring (support engineers, DevOps engineers) or if you use a managed
service provider, you may want to grant them access to only monitoring data while restricting their ability to create,
modify, or delete resources. This article shows how to quickly apply a built-in monitoring RBAC role to a user in
Azure or build your own custom role for a user who needs limited monitoring permissions. It then discusses
security considerations for your Azure Monitor-related resources and how you can limit access to the data they
contain.
Built-in monitoring roles

Azure Monitor’s built-in roles are designed to help limit access to resources in a subscription while still enabling
those responsible for monitoring infrastructure to obtain and configure the data they need. Azure Monitor
provides two out-of-the-box roles: A Monitoring Reader and a Monitoring Contributor.
Monitoring Reader
People assigned the Monitoring Reader role can view all monitoring data in a subscription but cannot modify any
resource or edit any settings related to monitoring resources. This role is appropriate for users in an organization,
such as support or operations engineers, who need to be able to:
View monitoring dashboards in the portal and create their own private monitoring dashboards.
View alert rules defined in Azure Alerts
Query for metrics using the Azure Monitor REST API, PowerShell cmdlets, or cross-platform CLI.
Query the Activity Log using the portal, Azure Monitor REST API, PowerShell cmdlets, or cross-platform CLI.
View the diagnostic settings for a resource.
View the log profile for a subscription.
View autoscale settings.
View alert activity and settings.
Access Application Insights data and view data in AI Analytics.
Search Log Analytics workspace data including usage data for the workspace.
View Log Analytics management groups.
Retrieve the search schema in Log Analytics workspace.
List monitoring packs in Log Analytics workspace.
Retrieve and execute saved searches in Log Analytics workspace.
Retrieve the Log Analytics workspace storage configuration.
NOTE
This role does not give read access to log data that has been streamed to an event hub or stored in a storage account. See
below for information on configuring access to these resources.
Monitoring Contributor
People assigned the Monitoring Contributor role can view all monitoring data in a subscription and create or
modify monitoring settings, but cannot modify any other resources. This role is a superset of the Monitoring
Reader role, and is appropriate for members of an organization’s monitoring team or managed service providers
who, in addition to the permissions above, also need to be able to:
Publish monitoring dashboards as a shared dashboard.
Set diagnostic settings for a resource.*
Set the log profile for a subscription.*
Set alert rules activity and settings via Azure Alerts.
Create Application Insights web tests and components.
List Log Analytics workspace shared keys.
Enable or disable monitoring packs in Log Analytics workspace.
Create and delete and execute saved searches in Log Analytics workspace.
Create and delete the Log Analytics workspace storage configuration.
*user must also separately be granted ListKeys permission on the target resource (storage account or event hub
namespace) to set a log profile or diagnostic setting.
NOTE
This role does not give read access to log data that has been streamed to an event hub or stored in a storage account. See
below for information on configuring access to these resources.
Monitoring permissions and custom RBAC roles

If the above built-in roles don’t meet the exact needs of your team, you can create a custom RBAC role with more
granular permissions. Below are the common Azure Monitor RBAC operations with their descriptions.
OPERATION DESCRIPTION
Microsoft.Insights/ActionGroups/[Read, Write, Delete] Read/write/delete action groups.
Microsoft.Insights/ActivityLogAlerts/[Read, Write, Delete] Read/write/delete activity log alerts.
Microsoft.Insights/AlertRules/[Read, Write, Delete] Read/write/delete alert rules (from alerts classic).
Microsoft.Insights/AlertRules/Incidents/Read List incidents (history of the alert rule being triggered) for
alert rules. This only applies to the portal.
Microsoft.Insights/AutoscaleSettings/[Read, Write, Delete] Read/write/delete autoscale settings.
Microsoft.Insights/DiagnosticSettings/[Read, Write, Delete] Read/write/delete diagnostic settings.
Microsoft.Insights/EventCategories/Read Enumerate all categories possible in the Activity Log. Used by

the Azure portal.
OPERATION DESCRIPTION
Microsoft.Insights/eventtypes/digestevents/Read This permission is necessary for users who need access to

Activity Logs via the portal.
Microsoft.Insights/eventtypes/values/Read List Activity Log events (management events) in a

subscription. This permission is applicable to both
programmatic and portal access to the Activity Log.
Microsoft.Insights/ExtendedDiagnosticSettings/[Read, Write, Read/write/delete diagnostic settings for network flow logs.

Delete]
Microsoft.Insights/LogDefinitions/Read This permission is necessary for users who need access to

Activity Logs via the portal.
Microsoft.Insights/LogProfiles/[Read, Write, Delete] Read/write/delete log profiles (streaming Activity Log to event
hub or storage account).
Microsoft.Insights/MetricAlerts/[Read, Write, Delete] Read/write/delete near real-time metric alerts
Microsoft.Insights/MetricDefinitions/Read Read metric definitions (list of available metric types for a

resource).
Microsoft.Insights/Metrics/Read Read metrics for a resource.
Microsoft.Insights/Register/Action Register the Azure Monitor resource provider.
Microsoft.Insights/ScheduledQueryRules/[Read, Write, Delete] Read/write/delete log alerts in Azure Monitor.
NOTE
Access to alerts, diagnostic settings, and metrics for a resource requires that the user has Read access to the resource type
and scope of that resource. Creating (“write”) a diagnostic setting or log profile that archives to a storage account or streams
to event hubs requires the user to also have ListKeys permission on the target resource.
For example, using the above table you could create a custom RBAC role for an “Activity Log Reader” like this:
$role = Get-AzRoleDefinition "Reader"

$role.Id = $null
$role.Name = "Activity Log Reader"
$role.Description = "Can view activity logs."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Insights/eventtypes/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/mySubscription")
New-AzRoleDefinition -Role $role
Security considerations for monitoring data

Monitoring data—particularly log files—can contain sensitive information, such as IP addresses or user names.
Monitoring data from Azure comes in three basic forms:
1. The Activity Log, which describes all control-plane actions on your Azure subscription.
2. Diagnostic Logs, which are logs emitted by a resource.
3. Metrics, which are emitted by resources.
All three of these data types can be stored in a storage account or streamed to Event Hub, both of which are
general-purpose Azure resources. Because these are general-purpose resources, creating, deleting, and accessing
them is a privileged operation reserved for an administrator. We suggest that you use the following practices for
monitoring-related resources to prevent misuse:
Use a single, dedicated storage account for monitoring data. If you need to separate monitoring data into
multiple storage accounts, never share usage of a storage account between monitoring and non-monitoring
data, as this may inadvertently give those who only need access to monitoring data (for example, a third-party
SIEM ) access to non-monitoring data.
Use a single, dedicated Service Bus or Event Hub namespace across all diagnostic settings for the same reason
as above.
Limit access to monitoring-related storage accounts or event hubs by keeping them in a separate resource
group, and use scope on your monitoring roles to limit access to only that resource group.
Never grant the ListKeys permission for either storage accounts or event hubs at subscription scope when a
user only needs access to monitoring data. Instead, give these permissions to the user at a resource or resource
group (if you have a dedicated monitoring resource group) scope.
Limiting access to monitoring-related storage accounts
When a user or application needs access to monitoring data in a storage account, you should generate an Account
SAS on the storage account that contains monitoring data with service-level read-only access to blob storage. In
PowerShell, this might look like:
$context = New-AzStorageContext -ConnectionString "[connection string for your monitoring Storage Account]"
$token = New-AzStorageAccountSASToken -ResourceType Service -Service Blob -Permission "rl" -Context $context
You can then give the token to the entity that needs to read from that storage account, and it can list and read from
all blobs in that storage account.
Alternatively, if you need to control this permission with RBAC, you can grant that entity the
Microsoft.Storage/storageAccounts/listkeys/action permission on that particular storage account. This is necessary
for users who need to be able to set a diagnostic setting or log profile to archive to a storage account. For example,
you could create the following custom RBAC role for a user or application that only needs to read from one
storage account:

$role.Id = $null
$role.Name = "Monitoring Storage Account Reader"
$role.Description = "Can get the storage account keys for a monitoring storage account."
$role.Actions.Add("Microsoft.Storage/storageAccounts/listkeys/action")
$role.Actions.Add("Microsoft.Storage/storageAccounts/Read")
$role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.S
torage/storageAccounts/myMonitoringStorageAccount")
WARNING
The ListKeys permission enables the user to list the primary and secondary storage account keys. These keys grant the user
all signed permissions (read, write, create blobs, delete blobs, etc.) across all signed services (blob, queue, table, file) in that
storage account. We recommend using an Account SAS described above when possible.
Limiting access to monitoring-related event hubs

A similar pattern can be followed with event hubs, but first you need to create a dedicated Listen authorization rule.
If you want to grant, access to an application that only needs to listen to monitoring-related event hubs, do the
following:
1. Create a shared access policy on the event hub(s) that were created for streaming monitoring data with only
Listen claims. This can be done in the portal. For example, you might call it “monitoringReadOnly.” If
possible, you will want to give that key directly to the consumer and skip the next step.
2. If the consumer needs to be able to get the key ad hoc, grant the user the ListKeys action for that event hub.
This is also necessary for users who need to be able to set a diagnostic setting or log profile to stream to
event hubs. For example, you might create an RBAC rule:

$role.Id = $null
$role.Name = "Monitoring Event Hub Listener"
$role.Description = "Can get the key to listen to an event hub streaming monitoring data."
$role.Actions.Add("Microsoft.ServiceBus/namespaces/authorizationrules/listkeys/action")
$role.Actions.Add("Microsoft.ServiceBus/namespaces/Read")
$role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Micro
soft.ServiceBus/namespaces/mySBNameSpace")
Monitoring within a secured Virtual Network

Azure Monitor needs access to your Azure resources to provide the services you enable. If you would like to
monitor your Azure resources while still securing them from access to the Public Internet, you can enable the
following settings.
Secured Storage Accounts
Monitoring data is often written to a storage account. You may want to make sure that the data copied to a Storage
Account cannot be accessed by unauthorized users. For additional security, you can lock down network access to
only allow your authorized resources and trusted Microsoft services access to a storage account by restricting a
storage account to use "selected networks".
Azure Monitor is considered one of

these "trusted Microsoft services" If you allow trusted Microsoft services to access your Secured Storage, Azure
monitor will have access to your secured Storage Account; enabling writing Azure Monitor diagnostic logs, activity
log, and metrics to your Storage Account under these protected conditions. This will also enable Log Analytics to
read logs from secured storage.
For more information, see Network security and Azure Storage
Next steps
Read about RBAC and permissions in Resource Manager
Read the overview of monitoring in Azure
IP addresses used by Application Insights and Log
Analytics
The Azure Application Insights service uses a number of IP addresses. You might need to know these addresses
if the app that you are monitoring is hosted behind a firewall.
NOTE
Although these addresses are static, it's possible that we will need to change them from time to time. All Application
Insights traffic represents outbound traffic with the exception of availability monitoring and webhooks which require
inbound firewall rules.
TIP
Subscribe to this page as a RSS feed by adding https://github.com/MicrosoftDocs/azure-
docs/commits/master/articles/azure-monitor/app/ip-addresses.md.atom to your favorite RSS/ATOM reader to get notified
of the latest changes.
Outgoing ports
You need to open some outgoing ports in your server's firewall to allow the Application Insights SDK and/or
Status Monitor to send data to the portal:
PURPOSE URL IP PORTS
Telemetry dc.services.visualstudio.com 40.114.241.141 443

dc.applicationinsights.micros 104.45.136.42
oft.com 40.84.189.107
168.63.242.221
52.167.221.184
52.169.64.244
40.85.218.175
104.211.92.54
52.175.198.74
51.140.6.23
40.71.12.231
13.69.65.22
13.78.108.165
13.70.72.233
20.44.8.7
13.86.218.248
40.79.138.41
52.231.18.241
13.75.38.7
102.133.162.117
40.73.171.20
102.133.155.50
52.162.110.67
191.233.204.248
Live Metrics Stream rt.services.visualstudio.com 23.96.28.38 443

rt.applicationinsights.micros 13.92.40.198
oft.com
Status Monitor
Status Monitor Configuration - needed only when making changes.
Configuration management.core.windows.net 443
Configuration management.azure.com 443
Configuration login.windows.net 443
Configuration login.microsoftonline.com 443
Configuration secure.aadcdn.microsoftonline- 443

p.com
Configuration auth.gfx.ms 443
Configuration login.live.com 443
Installation globalcdn.nuget.org , 443

packages.nuget.org ,
api.nuget.org/v3/index.json
nuget.org ,
api.nuget.org ,
dc.services.vsallin.net
Availability tests
This is the list of addresses from which availability web tests are run. If you want to run web tests on your app,
but your web server is restricted to serving specific clients, then you will have to permit incoming traffic from our
availability test servers.
Open ports 80 (http) and 443 (https) for incoming traffic from these addresses (IP addresses are grouped by
location):
Australia East
20.40.124.176/28
20.40.124.240/28
20.40.125.80/28
Brazil South
191.233.26.176/28
191.233.26.128/28
191.233.26.64/28
France Central (Formerly France South)

20.40.129.96/28
20.40.129.112/28
20.40.129.128/28
20.40.129.144/28
France Central
20.40.129.32/28
20.40.129.48/28
20.40.129.64/28
20.40.129.80/28
East Asia
52.229.216.48/28
52.229.216.64/28
52.229.216.80/28
North Europe
52.158.28.64/28
52.158.28.80/28
52.158.28.96/28
52.158.28.112/28
Japan East
52.140.232.160/28
52.140.232.176/28
52.140.232.192/28
West Europe
51.144.56.96/28
51.144.56.112/28
51.144.56.128/28
51.144.56.144/28
51.144.56.160/28
51.144.56.176/28
UK South
51.105.9.128/28
51.105.9.144/28
51.105.9.160/28
UK West
20.40.104.96/28
20.40.104.112/28
20.40.104.128/28
20.40.104.144/28
Southeast Asia
52.139.250.96/28
52.139.250.112/28
52.139.250.128/28
52.139.250.144/28
West US
40.91.82.48/28
40.91.82.64/28
40.91.82.80/28
40.91.82.96/28
40.91.82.112/28
40.91.82.128/28
Central US
13.86.97.224/28
13.86.97.240/28
13.86.98.48/28
13.86.98.0/28
13.86.98.16/28
13.86.98.64/28
North Central US
23.100.224.16/28
23.100.224.32/28
23.100.224.32/28
23.100.224.48/28
23.100.224.64/28
23.100.224.80/28
23.100.224.96/28
23.100.224.112/28
23.100.225.0/28
South Central US
20.45.5.160/28
20.45.5.176/28
20.45.5.192/28
20.45.5.208/28
20.45.5.224/28
20.45.5.240/28
East US
20.42.35.32/28
20.42.35.64/28
20.42.35.80/28
20.42.35.96/28
20.42.35.112/28
20.42.35.128/28
Application Insights API

PURPOSE URI IP PORTS
API api.applicationinsights.io 23.96.58.253 80,443

api1.applicationinsights.io 13.78.151.158
52.163.88.44
52.189.210.240
13.77.201.34
13.78.149.206
52.232.28.146
52.175.241.170
20.36.36.66
52.147.29.101
40.115.155.252
20.188.34.152
52.141.32.103
API docs dev.applicationinsights.io 23.96.58.253 80,443

dev.applicationinsights.micro 13.78.151.158
soft.com 40.74.59.40
dev.aisvc.visualstudio.com 40.70.42.246
www.applicationinsights.io 40.117.198.0
www.applicationinsights.micr 137.116.226.91
osoft.com 52.163.88.44
www.aisvc.visualstudio.com 52.189.210.240
13.77.201.34
13.78.149.206
52.232.28.146
52.175.241.170
20.36.36.66
52.147.29.101
40.115.155.252
20.188.34.152
52.141.32.103
Azure Pipeline annotations aigs1.aisvc.visualstudio.com dynamic 443

extension
Log Analytics API

API api.loganalytics.io 23.96.58.253 80,443

*.api.loganalytics.io 13.78.151.158
40.74.59.40
40.70.42.246
40.117.198.0
137.116.226.91
52.163.88.44
52.189.210.240
13.77.201.34
13.78.149.206
52.232.28.146
52.175.241.170
20.36.36.66
52.147.29.101
40.115.155.252
20.188.34.152
52.141.32.103
API docs dev.loganalytics.io 23.96.58.253 80,443

docs.loganalytics.io 13.78.151.158
www.loganalytics.io 40.74.59.40
40.70.42.246
40.117.198.0
137.116.226.91
52.163.88.44
52.189.210.240
13.77.201.34
13.78.149.206
52.232.28.146
52.175.241.170
20.36.36.66
52.147.29.101
40.115.155.252
20.188.34.152
52.141.32.103
Application Insights Analytics

Analytics Portal analytics.applicationinsights.i dynamic 80,443

o
CDN applicationanalytics.azureed dynamic 80,443

ge.net
Media CDN applicationanalyticsmedia.az dynamic 80,443

ureedge.net
Note: *.applicationinsights.io domain is owned by Application Insights team.
Log Analytics Portal

Portal portal.loganalytics.io dynamic 80,443
CDN applicationanalytics.azureed dynamic 80,443

ge.net
Note: *.loganalytics.io domain is owned by the Log Analytics team.
Application Insights Azure portal Extension

Application Insights stamp2.app.insightsportal.vi dynamic 80,443

Extension sualstudio.com
Application Insights insightsportal-prod2- dynamic 80,443

Extension CDN cdn.aisvc.visualstudio.com
insightsportal-prod2-asiae-
cdn.aisvc.visualstudio.com
insightsportal-cdn-
aimon.applicationinsights.io
Application Insights SDKs

Application Insights JS SDK az416426.vo.msecnd.net dynamic 80,443

CDN
Application Insights Java aijavasdk.blob.core.windows. dynamic 80,443

SDK net
Alert webhooks
PURPOSE IP PORTS
Alerting 23.96.11.4 443
Profiler
Agent agent.azureserviceprofiler.ne 20.190.60.38 443

t 20.190.60.32
*.agent.azureserviceprofiler.n 52.173.196.230
et 52.173.196.209
23.102.44.211
23.102.45.216
13.69.51.218
13.69.51.175
138.91.32.98
138.91.37.93
40.121.61.208
40.121.57.2
51.140.60.235
51.140.180.52
52.138.31.112
52.138.31.127
104.211.90.234
104.211.91.254
13.70.124.27
13.75.195.15
52.185.132.101
52.185.132.170
20.188.36.28
40.89.153.171
52.141.22.239
52.141.22.149
102.133.162.233
102.133.161.73
Portal gateway.azureserviceprofiler. dynamic 443

net
Storage *.core.windows.net dynamic 443
Snapshot Debugger
NOTE
Profiler and Snapshot Debugger share the same set of IP addresses.

Agent ppe.azureserviceprofiler.net 20.190.60.38 443

*.ppe.azureserviceprofiler.net 20.190.60.32
52.173.196.230
52.173.196.209
23.102.44.211
23.102.45.216
13.69.51.218
13.69.51.175
138.91.32.98
138.91.37.93
40.121.61.208
40.121.57.2
51.140.60.235
51.140.180.52
52.138.31.112
52.138.31.127
104.211.90.234
104.211.91.254
13.70.124.27
13.75.195.15
52.185.132.101
52.185.132.170
20.188.36.28
40.89.153.171
52.141.22.239
52.141.22.149
102.133.162.233
102.133.161.73
Portal ppe.gateway.azureservicepr dynamic 443

ofiler.net
Storage *.core.windows.net dynamic 443

Create a Log Analytics workspace in the Azure
portal
Use the Log Analytics workspaces menu to create a Log Analytics workspace using the Azure portal. A Log
Analytics workspace is a unique environment for Azure Monitor log data. Each workspace has its own data
repository and configuration, and data sources and solutions are configured to store their data in a particular
workspace. You require a Log Analytics workspace if you intend on collecting data from the following sources:
Azure resources in your subscription
On-premises computers monitored by System Center Operations Manager
Device collections from System Center Configuration Manager
Diagnostics or log data from Azure storage
For other sources, such as Azure VMs and Windows or Linux VMs in your environment, see the following topics:
Collect data from Azure virtual machines
Collect data from hybrid Linux computer
Collect data from hybrid Windows computer

Create a workspace
1. In the Azure portal, click All services. In the list of resources, type Log Analytics. As you begin typing,
2. Click Add, and then select choices for the following items:
appropriate.
For Resource Group, choose to use an existing resource group already setup or create a new one.
Select an available Location. For more information, see which regions Log Analytics is available in
and search for Azure Monitor from the Search for a product field.
If you are creating a workspace for an existing subscription created before April 2, or to subscription
that was tied to an existing Enterprise Agreement (EA) enrollment, select your preferred pricing tier.
For more information about the particular tiers, see Log Analytics Pricing Details.
3. After providing the required information on the Log Analytics Workspace pane, click OK.
from the menu.
Next steps
Now that you have a workspace available, you can configure collection of monitoring telemetry, run log searches
to analyze that data, and add a management solution to provide additional data and analytic insights.
To enable data collection from Azure resources with Azure Diagnostics or Azure storage, see Collect Azure
service logs and metrics for use in Log Analytics.
Add System Center Operations Manager as a data source to collect data from agents reporting your
Operations Manager management group and store it in your Log Analytics workspace.
Connect Configuration Manager to import computers that are members of collections in the hierarchy.
Review the monitoring solutions available and how to add or remove a solution from your workspace.
Create a Log Analytics workspace with Azure CLI 2.0
The Azure CLI 2.0 is used to create and manage Azure resources from the command line or in scripts. This
quickstart shows you how to use Azure CLI 2.0 to deploy a Log Analytics workspace in Azure Monitor. A Log
Analytics workspace is a unique environment for Azure Monitor log data. Each workspace has its own data
repository and configuration, and data sources and solutions are configured to store their data in a particular
workspace. You require a Log Analytics workspace if you intend on collecting data from the following sources:
Diagnostic or log data from Azure storage
Use Azure Cloud Shell

Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. Cloud
Shell lets you use either bash or PowerShell to work with Azure services. You can use the Cloud Shell pre-
installed commands to run the code in this article without having to install anything on your local environment.
To launch Azure Cloud Shell:
OPTION EXAMPLE/LINK
Select Try It in the upper-right corner of a code block.

Selecting Try It doesn't automatically copy the code to Cloud
Shell.
Go to https://shell.azure.com or select the Launch Cloud

Shell button to open Cloud Shell in your browser.
Select the Cloud Shell button on the top-right menu bar in

the Azure portal.
To run the code in this article in Azure Cloud Shell:

1. Launch Cloud Shell.
2. Select the Copy button on a code block to copy the code.
3. Paste the code into the Cloud Shell session with Ctrl+Shift+V on Windows and Linux, or Cmd+Shift+V
on macOS.
4. Press Enter to run the code.
If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.30 or later. Run az --version to find the version. If you need to install or upgrade, see Install Azure CLI 2.0.
Create a workspace
Create a workspace with az group deployment create. The following example creates a workspace named
TestWorkspace in the resource group Lab in the eastus location using a Resource Manager template from your
local machine. The JSON template is configured to only prompt you for the name of the workspace, and specifies a
default value for the other parameters that would likely be used as a standard configuration in your environment.
Or you can store the template in an Azure storage account for shared access in your organization. For further
information about working with templates, see Deploy resources with Resource Manager templates and Azure CLI
For information about regions supported, see regions Log Analytics is available in and search for Azure Monitor
from the Search for a product field.
The following parameters set a default value:
location - defaults to East US
sku - defaults to the new Per-GB pricing tier released in the April 2018 pricing model
WARNING
If creating or configuring a Log Analytics workspace in a subscription that has opted into the new April 2018 pricing model,
the only valid Log Analytics pricing tier is PerGB2018.
Create and deploy template

1. Copy and paste the following JSON syntax into your file:
{
"$schema": "https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"workspaceName": {
"type": "String",
"metadata": {
"description": "Specifies the name of the workspace."
}
},
"location": {
"type": "String",
"allowedValues": [
"eastus",
"westus"
],
"defaultValue": "eastus",
"metadata": {
"description": "Specifies the location in which to create the workspace."
}
},
"sku": {
"type": "String",
"allowedValues": [
"Standalone",
"PerNode",
"PerGB2018"
],
"defaultValue": "PerGB2018",
"metadata": {
"description": "Specifies the service tier of the workspace: Standalone, PerNode, Per-GB"
}
}
},
"resources": [
{
"type": "Microsoft.OperationalInsights/workspaces",
"name": "[parameters('workspaceName')]",
"apiVersion": "2015-11-01-preview",
"location": "[parameters('location')]",
"properties": {
"sku": {
"Name": "[parameters('sku')]"
},
"features": {
"searchVersion": 1
}
}
}
]
}
2. Edit the template to meet your requirements. Review Microsoft.OperationalInsights/workspaces template

reference to learn what properties and values are supported.
3. Save this file as deploylaworkspacetemplate.json to a local folder.
4. You are ready to deploy this template. Use the following commands from the folder containing the template:
az group deployment create --resource-group <my-resource-group> --name <my-deployment-name> --template-

file deploylaworkspacetemplate.json
The deployment can take a few minutes to complete. When it finishes, you see a message similar to the following
that includes the result:
Next steps
service logs and metrics for use in Log Analytics.
Create a Log Analytics workspace with Azure
PowerShell
The Azure PowerShell module is used to create and manage Azure resources from the PowerShell command line
or in scripts. This quickstart shows you how to use the Azure PowerShell module to deploy a Log Analytics
workspace in Azure Monitor. A Log Analytics workspace is a unique environment for Azure Monitor log data. Each
workspace has its own data repository and configuration, and data sources and solutions are configured to store
their data in a particular workspace. You require a Log Analytics workspace if you intend on collecting data from
the following sources:
Diagnostic or log data from Azure storage
NOTE
PowerShell.
Use Azure Cloud Shell

Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. Cloud
Shell lets you use either bash or PowerShell to work with Azure services. You can use the Cloud Shell pre-
installed commands to run the code in this article without having to install anything on your local environment.
To launch Azure Cloud Shell:
OPTION EXAMPLE/LINK
Select Try It in the upper-right corner of a code block.

Selecting Try It doesn't automatically copy the code to Cloud
Shell.
Go to https://shell.azure.com or select the Launch Cloud

Shell button to open Cloud Shell in your browser.
OPTION EXAMPLE/LINK
Select the Cloud Shell button on the top-right menu bar in

the Azure portal.
To run the code in this article in Azure Cloud Shell:

1. Launch Cloud Shell.
2. Select the Copy button on a code block to copy the code.
3. Paste the code into the Cloud Shell session with Ctrl+Shift+V on Windows and Linux, or Cmd+Shift+V
on macOS.
4. Press Enter to run the code.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell Az module. Run
Get-Module -ListAvailable Az to find the version. If you need to upgrade, see Install the Azure PowerShell module.
If you are running PowerShell locally, you also need to run Connect-AzAccount to create a connection with Azure.
Create a workspace
Create a workspace with New -AzResourceGroupDeployment. The following example creates a workspace named
TestWorkspace in the resource group Lab in the eastus location using a Resource Manager template from your
local machine. The JSON template is configured to only prompt you for the name of the workspace, and specifies a
default value for the other parameters that would likely be used as a standard configuration in your environment.
For information about regions supported, see regions Log Analytics is available in and search for Azure Monitor
from the Search for a product field.
The following parameters set a default value:
location - defaults to East US
sku - defaults to the new Per-GB pricing tier released in the April 2018 pricing model
WARNING
If creating or configuring a Log Analytics workspace in a subscription that has opted into the new April 2018 pricing model,
the only valid Log Analytics pricing tier is PerGB2018.

{
"parameters": {
"workspaceName": {
"type": "String",
"metadata": {
}
},
"location": {
"type": "String",
"allowedValues": [
"eastus",
"westus"
],
"defaultValue": "eastus",
"metadata": {
}
},
"sku": {
"type": "String",
"allowedValues": [
"Standalone",
"PerNode",
"PerGB2018"
],
"metadata": {
"description": "Specifies the service tier of the workspace: Standalone, PerNode, Per-GB"
}
}
},
"resources": [
{
"properties": {
"sku": {
"Name": "[parameters('sku')]"
},
"features": {
"searchVersion": 1
}
}
}
]
}

4. You are ready to deploy this template. Use the following commands from the folder containing the template:
New-AzResourceGroupDeployment -Name <deployment-name> -ResourceGroupName <resource-group-name> -

TemplateFile deploylaworkspacetemplate.json
Next steps
service logs and metrics for use in Azure Monitor.
Delete and restore Azure Log Analytics workspace
This article explains the concept of Azure Log Analytics workspace soft-delete and how to recover deleted
workspace.
Considerations when deleting a workspace

When you delete a Log Analytics workspace, a soft-delete operation is performed to allow the recovery of the
workspace including its data and connected agents within 14 days, whether the deletion was accidental or
intentional. After the soft-delete period, the workspace and its data are non-recoverable and are queued for
permanent deletion within 30 days.
You want to exercise caution when you delete a workspace because there might be important data and
configuration that may negatively impact your service operation. Review what agents, solutions, and other Azure
services and sources that store their data in Log Analytics, such as:
Management solutions
Azure Automation
Agents running on Windows and Linux virtual machines
Agents running on Windows and Linux computers in your environment
System Center Operations Manager
The soft-delete operation deletes the workspace resource and any associated users’ permission is broken. If users
are associated with other workspaces, then they can continue using Log Analytics with those other workspaces.
Soft-delete behavior
The workspace delete operation removes the workspace Resource Manager resource, but its configuration and
data are kept for 14 days, while giving the appearance that the workspace is deleted. Any agents and System
Center Operations Manager management groups configured to report to the workspace remain in an orphaned
state during the soft-delete period. The service further provides a mechanism for recovering the deleted workspace
including its data and connected resources, essentially undoing the deletion.
NOTE
Installed solutions and linked services like Automation account are permanently removed from the workspace at deletion
time and can’t be recovered. These should be reconfigured after the recovery operation to bring the workspace to its
previous functionality.
You can delete a workspace using PowerShell, API, or in Azure portal.

Delete workspace in Azure portal
1. To sign in, go to the Azure portal.
2. In the Azure portal, select All services. In the list of resources, type Log Analytics. As you begin typing, the list
filters based on your input. Select Log Analytics workspaces.
3. In the list of Log Analytics workspaces, select a workspace and then click Delete from the top of the middle
pane.
4. When the confirmation message window appears asking you to confirm deletion of the workspace, click Yes.
Recover workspace
If you have Contributor permissions to the subscription and resource group to where the workspace was
associated before the soft-delete operation, you can recover it during its soft-delete period including its data,
configuration and connected agents. After the soft-delete period, the workspace is non-recoverable and assigned
for permanent deletion.
You can recover a workspace by re-creating the workspace using any of the supported create methods: PowerShell,
Azure CLI, or from the Azure portal as long as these properties are populated with the deleted workspace’s details
including:
1. Subscription ID
2. Resource Group name
3. Workspace name
4. Region
NOTE
Names of deleted workspaces are kept preserved for the soft-delete period and they can't be used when creating a new
workspace. The workspace names are released and available for use for new workspace creation after the soft-delete period
has expired.
Azure Monitor for Service Providers
Log Analytics workspaces in Azure Monitor can help managed service providers (MSPs), large enterprises,
independent software vendors (ISVs), and hosting service providers manage and monitor servers in customer's
on-premises or cloud infrastructure.
Large enterprises share many similarities with service providers, particularly when there is a centralized IT team
that is responsible for managing IT for many different business units. For simplicity, this document uses the term
service provider but the same functionality is also available for enterprises and other customers.
For partners and service providers who are part of the Cloud Solution Provider (CSP ) program, Log Analytics in
Azure Monitor is one of the Azure services available in Azure CSP subscriptions.
Architectures for Service Providers

Log Analytics workspaces provide a method for the administrator to control the flow and isolation of log data and
create an architecture that addresses its specific business needs. This article explains the design, deployment, and
migration considerations for a workspace, and the manage access article discusses how to apply and manage
permissions to log data. Service providers have additional considerations.
There are three possible architectures for service providers regarding Log Analytics workspaces:
1. Distributed - Logs are stored in workspaces located in the customer's tenant
In this architecture, a workspace is deployed in the customer's tenant that is used for all the logs of that customer.
The service provider administrators are granted access to this workspace using Azure Active Directory guest users
(B2B ). The service provider administrators will have to switch to their customer's directory in the Azure portal to be
able to access these workspaces.
The advantages of this architecture are:
The customer can manage access to the logs using their own role-based access.
Each customer can have different settings for their workspace such as retention and data capping.
Isolation between customers for regulatory and compliancy.
The charge for each workspace will be rolled into the customer's subscription.
Logs can be collected from all types of resources, not just agent-based. For example, Azure Audit Logs.
The disadvantages of this architecture are:
It is harder for the service provider to manage a large number of customer tenants at once.
Service provider administrators have to be provisioned in the customer directory.
The service provider can't analyze data across its customers.
2. Central - Logs are stored in a workspace located in the service provider tenant
In this architecture, the logs are not stored in the customer's tenants but only in a central location within one of the
service provider's subscriptions. The agents that are installed on the customer's VMs are configured to send their
logs to this workspace using the workspace ID and secret key.
The advantages of this architecture are:
It is easy to manage a large number of customers and integrate them to various backend systems.
The service provider has full ownership over the logs and the various artifacts such as functions and saved
queries.
The service provider can perform analytics across all of its customers.
The disadvantages of this architecture are:
This architecture is applicable only for agent-based VM data, it will not cover PaaS, SaaS and Azure fabric
data sources.
It might be hard to separate the data between the customers when they are merged into a single workspace.
The only good method to do so is to use the computer's fully qualified domain name (FQDN ) or via the
Azure subscription ID.
All data from all customers will be stored in the same region with a single bill and same retention and
configuration settings.
Azure fabric and PaaS services such as Azure Diagnostics and Azure Audit Logs requires the workspace to
be in the same tenant as the resource, thus they cannot send the logs to the central workspace.
All VM agents from all customers will be authenticated to the central workspace using the same workspace
ID and key. There is no method to block logs from a specific customer without interrupting other customers.
3. Hybrid - Logs are stored in workspace located in the customer's tenant and some of them are pulled to a
central location.
The third architecture mix between the two options. It is based on the first distributed architecture where the logs
are local to each customer but using some mechanism to create a central repository of logs. A portion of the logs is
pulled into a central location for reporting and analytics. This portion could be small number of data types or a
summary of the activity such as daily statistics.
There are two options to implement logs in a central location:
1. Central workspace: The service provider can create a workspace in its tenant and use a script that utilizes the
Query API with the Data Collection API to bring the data from the various workspaces to this central
location. Another option, other than a script, is to use Azure Logic Apps.
2. Power BI as a central location: Power BI can act as the central location when the various workspaces export
data to it using the integration between the Log Analytics workspace and Power BI.
Next steps
Automate creation and configuration of workspaces using Resource Manager templates
Automate creation of workspaces using PowerShell
Use Alerts to integrate with existing systems
Generate summary reports using Power BI
Review the process of configuring Log Analytics and Power BI to monitor multiple CSP customers
Manage access to log data and workspaces in Azure
Monitor
Azure Monitor stores log data in a Log Analytics workspace, which is essentially a container that includes data
and configuration information. To manage access to log data, you perform various administrative tasks related to
your workspace.
This article explains how to manage access to logs and to administer the workspaces that contain them, including:
How to grant access to users who need access to log data from specific resources using Azure role-based
access control (RBAC ).
How to grant access to the workspace using workspace permissions.
How to grant access to users who need access to log data in a specific table in the workspace using Azure
RBAC.
Configure access control mode

You can view the access control mode configured on a workspace from the Azure portal or with Azure
PowerShell. You can change this setting using one of the following supported methods:
Azure portal
Azure PowerShell
Azure Resource Manager template
From the Azure portal
You can view the current workspace access control mode on the Overview page for the workspace in the Log
Analytics workspace menu.
1. Sign in to the Azure portal at https://portal.azure.com.

2. In the Azure portal, select Log Analytics workspaces > your workspace.
You can change this setting from the Properties page of the workspace. Changing the setting will be disabled if
you don't have permissions to configure the workspace.
Using PowerShell
Use the following command to examine the access control mode for all workspaces in the subscription:
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {$_.Name +

": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}
The output should resemble the following:
DefaultWorkspace38917: True
DefaultWorkspace21532: False
A value of False means the workspace is configured with the workspace-context access mode. A value of True
means the workspace is configured with the resource-context access mode.
NOTE
If a workspace is returned without a boolean value and is blank, this also matches the results of a False value.
Use the following script to set the access control mode for a specific workspace to the resource-context
permission:
$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
{ $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force
Use the following script to set the access control mode for all workspaces in the subscription to the resource-
context permission:
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {

if ($_.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $_.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
{ $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $_.ResourceId -Properties $_.Properties -Force
Using a Resource Manager template

To configure the access mode in an Azure Resource Manager template, set the
enableLogAccessUsingOnlyResourcePermissions feature flag on the workspace to one of the following
values.
false: Set the workspace to workspace-context permissions. This is the default setting if the flag isn't set.
true: Set the workspace to resource-context permissions.
Manage access using workspace permissions

Each workspace can have multiple accounts associated with it, and each account can have access to multiple
workspaces. Access is managed using Azure role-based access.
The following activities also require Azure permissions:
ACTION AZURE PERMISSIONS NEEDED NOTES
Adding and removing monitoring Microsoft.Resources/deployments/* These permissions need to be granted

solutions Microsoft.OperationalInsights/* at resource group or subscription level.
Microsoft.OperationsManagement/*
Microsoft.Automation/*
Microsoft.Resources/deployments/*/write
Changing the pricing tier Microsoft.OperationalInsights/workspaces/*/write
Viewing data in the Backup and Site Administrator / Co-administrator Accesses resources deployed using the
Recovery solution tiles classic deployment model
Creating a workspace in the Azure Microsoft.Resources/deployments/*

portal Microsoft.OperationalInsights/workspaces/*
View workspace basic properties and Microsoft.OperationalInsights/workspaces/read

enter the workspace blade in the portal
Query logs using any interface Microsoft.OperationalInsights/workspaces/query/read
Access all log types using queries Microsoft.OperationalInsights/workspaces/query/*/read
Access a specific log table Microsoft.OperationalInsights/workspaces/query/<table_name>/read
Read the workspace keys to allow Microsoft.OperationalInsights/workspaces/sharedKeys/action

sending logs to this workspace
Manage access using Azure permissions

To grant access to the Log Analytics workspace using Azure permissions, follow the steps in use role assignments
to manage access to your Azure subscription resources. For example custom roles, see Example custom roles
Azure has two built-in user roles for Log Analytics workspaces:
Log Analytics Reader
Log Analytics Contributor
Members of the Log Analytics Reader role can:
View and search all monitoring data
View monitoring settings, including viewing the configuration of Azure diagnostics on all Azure resources.
The Log Analytics Reader role includes the following Azure actions:
TYPE PERMISSION DESCRIPTION
Action */read Ability to view all Azure resources and

resource configuration. Includes
viewing:
Virtual machine extension status
Configuration of Azure diagnostics on
resources
All properties and settings of all
resources.
For workspaces, it allows full
unrestricted permissions to read the
workspace settings and perform query
on the data. See more granular options
above.
Action Deprecated, no need to assign them to

Microsoft.OperationalInsights/workspaces/analytics/query/action
users.
Action Deprecated, no need to assign them to

Microsoft.OperationalInsights/workspaces/search/action
users.
Action Microsoft.Support/* Ability to open support cases
Not Action Prevents reading of workspace key

Microsoft.OperationalInsights/workspaces/sharedKeys/read
required to use the data collection API
and to install agents. This prevents the
user from adding new resources to the
workspace
Members of the Log Analytics Contributor role can:

Read all monitoring data as Log Analytics Reader can
Creating and configuring Automation accounts
Adding and removing management solutions
NOTE
In order to successfully perform the last two actions, this permission needs to be granted at the resource group or
subscription level.
Reading storage account keys

Configure collection of logs from Azure Storage
Edit monitoring settings for Azure resources, including
Adding the VM extension to VMs
Configuring Azure diagnostics on all Azure resources
NOTE
You can use the ability to add a virtual machine extension to a virtual machine to gain full control over a virtual machine.
The Log Analytics Contributor role includes the following Azure actions:
PERMISSION DESCRIPTION
*/read Ability to view all resources and resource configuration.

Includes viewing:
Virtual machine extension status
Configuration of Azure diagnostics on resources
All properties and settings of all resources.
For workspaces, it allows full unrestricted permissions to read
the workspace setting and perform query on the data. See
more granular options above.
Microsoft.Automation/automationAccounts/* Ability to create and configure Azure Automation accounts,

including adding and editing runbooks
Microsoft.ClassicCompute/virtualMachines/extensions/* Add, update and remove virtual machine extensions,

Microsoft.Compute/virtualMachines/extensions/* including the Microsoft Monitoring Agent extension and the
OMS Agent for Linux extension
Microsoft.ClassicStorage/storageAccounts/listKeys/action View the storage account key. Required to configure Log

Microsoft.Storage/storageAccounts/listKeys/action Analytics to read logs from Azure storage accounts
Microsoft.Insights/alertRules/* Add, update, and remove alert rules
Microsoft.Insights/diagnosticSettings/* Add, update, and remove diagnostics settings on Azure

resources
Microsoft.OperationalInsights/* Add, update, and remove configuration for Log Analytics

workspaces. To edit workspace advanced settings, user needs
Microsoft.OperationalInsights/workspaces/write .
Microsoft.OperationsManagement/* Add and remove management solutions
Microsoft.Resources/deployments/* Create and delete deployments. Required for adding and

removing solutions, workspaces, and automation accounts
Create and delete deployments. Required for adding and

Microsoft.Resources/subscriptions/resourcegroups/deployments/*
removing solutions, workspaces, and automation accounts
To add and remove users to a user role, it is necessary to have Microsoft.Authorization/*/Delete and
Microsoft.Authorization/*/Write permission.
Use these roles to give users access at different scopes:

Subscription - Access to all workspaces in the subscription
Resource Group - Access to all workspace in the resource group
Resource - Access to only the specified workspace
You should perform assignments at the resource level (workspace) to assure accurate access control. Use custom
roles to create roles with the specific permissions needed.
Resource permissions
When users query logs from a workspace using resource-context access, they'll have the following permissions
on the resource:
PERMISSION DESCRIPTION
Microsoft.Insights/logs/<tableName>/read Ability to view all log data for the resource.
Examples:
Microsoft.Insights/logs/*/read
Microsoft.Insights/logs/Heartbeat/read
Microsoft.Insights/diagnosticSettings/write Ability to configure diagnostics setting to allow setting up

logs for this resource.
/read permission is usually granted from a role that includes */read or * permissions such as the built-in Reader
and Contributor roles. Note that custom roles that include specific actions or dedicated built-in roles might not
include this permission.
See Defining per-table access control below if you want to create different access control for different tables.
Custom role examples

1. To grant a user access to log data from their resources, perform the following:
Configure the workspace access control mode to use workspace or resource permissions
Grant users */read or Microsoft.Insights/logs/*/read permissions to their resources. If they are
already assigned the Log Analytics Reader role on the workspace, it is sufficient.
2. To grant a user access to log data from their resources and configure their resources to send logs to the
workspace, perform the following:
Grant users the following permissions on the workspace:
Microsoft.OperationalInsights/workspaces/read and
Microsoft.OperationalInsights/workspaces/sharedKeys/action . With these permissions, users cannot
perform any workspace-level queries. They can only enumerate the workspace and use it as a
destination for diagnostic settings or agent configuration.
Grant users the following permissions to their resources: Microsoft.Insights/logs/*/read and
Microsoft.Insights/diagnosticSettings/write . If they are already assigned the Log Analytics
Contributor role, assigned the Reader role, or granted */read permissions on this resource, it is
sufficient.
3. To grant a user access to log data from their resources without being able to read security events and send
data, perform the following:
Grant users the following permissions to their resources: Microsoft.Insights/logs/*/read .
Add the following NonAction to block users from reading the SecurityEvent type:
Microsoft.Insights/logs/SecurityEvent/read . The NonAction shall be in the same custom role as the
action that provides the read permission ( Microsoft.Insights/logs/*/read ). If the user inherent the
read action from another role that is assigned to this resource or to the subscription or resource
group, they would be able to read all log types. This is also true if they inherit */read that exist for
example, with the Reader or Contributor role.
4. To grant a user access to log data from their resources and read all Azure AD sign-in and read Update
Management solution log data from the workspace, perform the following:
Grant users the following permissions on the workspace:
Microsoft.OperationalInsights/workspaces/read – required so the use can enumerate the
workspace and open the workspace blade in the Azure portal
Microsoft.OperationalInsights/workspaces/query/read – required for every user that can execute
queries
Microsoft.OperationalInsights/workspaces/query/SigninLogs/read – to be able to read Azure AD
sign-in logs
Microsoft.OperationalInsights/workspaces/query/Update/read – to be able to read Update
Management solution logs
Microsoft.OperationalInsights/workspaces/query/UpdateRunProgress/read – to be able to read
Update Management solution logs
Microsoft.OperationalInsights/workspaces/query/UpdateSummary/read – to be able to read Update
management logs
Microsoft.OperationalInsights/workspaces/query/Heartbeat/read – required to be able to use
Update Management solution
Microsoft.OperationalInsights/workspaces/query/ComputerGroup/read – required to be able to use
Update Management solution
Grant users the following permissions to their resources: */read , assigned to the Reader role, or
Microsoft.Insights/logs/*/read .
Table level RBAC

Table level RBAC allows you to define more granular control to data in a Log Analytics workspace in addition to
the other permissions. This control allows you to define specific data types that are accessible only to a specific set
of users.
You implement table access control with Azure custom roles to either grant or deny access to specific tables in the
workspace. These roles are applied to workspaces with either workspace-context or resource-context access
control modes regardless of the user's access mode.
Create a custom role with the following actions to define access to table access control.
To grant access to a table, include it in the Actions section of the role definition.
To deny access to a table, include it in the NotActions section of the role definition.
Use * to specify all tables.
For example, to create a role with access to the Heartbeat and AzureActivity tables, create a custom role using the
following actions:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
"Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
],
To create a role with access to only SecurityBaseline and no other tables, create a custom role using the following
actions:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],
"NotActions": [
"Microsoft.OperationalInsights/workspaces/query/*/read"
],
Custom logs
Custom logs are created from data sources such as custom logs and HTTP Data Collector API. The easiest way to
identify the type of log is by checking the tables listed under Custom Logs in the log schema.
You can't currently grant or deny access to individual custom logs, but you can grant or deny access to all custom
logs. To create a role with access to all custom logs, create a custom role using the following actions:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],
Considerations
If a user is granted global read permission with the standard Reader or Contributor roles that include the
*/read action, it will override the per-table access control and give them access to all log data.
If a user is granted per-table access but no other permissions, they would be able to access log data from the
API but not from the Azure portal. To provide access from the Azure portal, use Log Analytics Reader as its
base role.
Administrators of the subscription will have access to all data types regardless of any other permission
settings.
Workspace owners are treated like any other user for per-table access control.
You should assign roles to security groups instead of individual users to reduce the number of assignments.
This will also help you use existing group management tools to configure and verify access.
Next steps
See Log Analytics agent overview to gather data from computers in your datacenter or other cloud
environment.
See Collect data about Azure virtual machines to configure data collection from Azure VMs.
Monitoring usage and estimated costs in Azure
Monitor
NOTE
This article describes how to view usage and estimated costs across multiple Azure monitoring features for different pricing
models. Refer to the following articles for related information.
Manage cost by controlling data volume and retention in Log Analytics describes how to control your costs by changing
your data retention period.
Analyze data usage in Log Analytics describes how to analyze and alert on your data usage.
Manage pricing and data volume in Application Insights describes how to analyze data usage in Application Insights.
NOTE
PowerShell.
In the Monitor hub of the Azure portal, the Usage and estimated costs page explains the usage of core
monitoring features such as alerting, metrics, notifications, Azure Log Analytics, and Azure Application Insights.
For customers on the pricing plans available before April 2018, this also includes Log Analytics usage purchased
through the Insights and Analytics offer.
On this page, users can view their resource usage for the past 31 days, aggregated per subscription. Drill-ins show
usage trends over the 31-day period. A lot of data needs to come together for this estimate, so please be patient as
the page loads.
This example shows monitoring usage and an estimate of the resulting costs:
Select the link in the monthly usage column to open a chart that shows usage trends over the last 31-day period:
Here’s another similar usage and cost summary. This example shows a subscription in the new April 2018
consumption-based pricing model. Note the lack of any node-based billing. Data ingestion and retention for Log
Analytics and Application Insights are now reported on a new common meter.
New pricing model

In April 2018, a new monitoring pricing model was released. This features cloud-friendly, consumption-based
pricing. You only pay for what you use, without node-based commitments. Details of the new pricing model are
available for alerting, metrics, notifications, Log Analytics and Application Insights.
For customers onboarding to Log Analytics or Application Insights after April 2, 2018, the new pricing model is
the only option. For customers who already use these services, moving to the new pricing model is optional.
Assessing the impact of the new pricing model

The new pricing model will have different impacts on each customer based on their monitoring usage patterns. For
customers who were using Log Analytics or Application Insights before April 2, 2018, the Usage and estimated
cost page in Azure Monitor estimates any change in costs if they move to the new pricing model. It provides the
way to move a subscription into the new model. For most customers, the new pricing model will be advantageous.
For customers with especially high data usage patterns or in higher-cost regions, this may not be the case.
To see an estimate of your costs for the subscriptions that you chose on the Usage and estimated costs page,
select the blue banner near the top of the page. It’s best to do this one subscription at a time, because that's the
level at which the new pricing model can be adopted.
The new page shows a similar version of the prior page with a green banner:
The page also shows a different set of meters that correspond to the new pricing model. This list is an example:
Insight and Analytics\Overage per Node
Insight and Analytics\Included per Node
Application Insights\Basic Overage Data
Application Insights\Included Data
The new pricing model doesn't have node-based included data allocations. Therefore, these data ingestion meters
are combined into a new common data ingestion meter called Shared Services\Data Ingestion.
There's another change to data ingested into Log Analytics or Application Insights in regions with higher costs.
Data for these high-cost regions will be shown with the new regional meters. An example is Data Ingestion (US
West Central).
NOTE
The per subscription estimated costs do not factor into the account-level per node entitlements of the Operations
Management Suite (OMS) subscription. Consult your account representative for a more in-depth discussion of the new
pricing model in this case.
New pricing model and Operations Management Suite subscription

entitlements
Customers who purchased Microsoft Operations Management Suite E1 and E2 are eligible for per-node data
ingestion entitlements for Log Analytics and Application Insights. To receive these entitlements for Log Analytics
workspaces or Application Insights resources in a given subscription:
The subscription's pricing model must remain in the pre-April 2018 model.
Log Analytics workspaces should use the "Per-node (OMS )" pricing tier.
Application Insights resources should use the "Enterprise" pricing plan.
Depending on the number of nodes of the suite that your organization purchased, moving some subscriptions to
the new pricing model could be advantageous, but this requires careful consideration. In general, it is advisable
simply to stay in the pre-April 2018 model as described above.
WARNING
If your organization has purchased the Microsoft Operations Management Suite E1 and E2, it is usually best to keep your
subscriptions in the pre-April 2018 pricing model.
Changes when you're moving to the new pricing model

The new pricing model simplifies Log Analytics and Application Insights pricing options to only a single tier (or
plan). Moving a subscription into the new pricing model will:
Change the pricing tier for each Log Analytics to a new Per-GB tier (called “pergb2018” in Azure Resource
Manager)
Any Application Insights resources in the Enterprise plan is changed to the Basic plan.
The cost estimation shows the effects of these changes.
WARNING
Here an important note if you use Azure Resource Manager or PowerShell to deploy Log Analytics or Application Insights in
a subscription you have moved to the new pricing model. If you specify a pricing tier/plan other than the “pergb2018” for
Log Analytics or “Basic” for Application Insights, rather than failing the deployment due to specifying an invalid pricing
tier/plan, it will succeed but it will use only the valid pricing tier/plan (This does not apply to the Log Analytics Free tier
where an invalid pricing tier message is generated).
Moving to the new pricing model

If you’ve decided to adopt the new pricing model for a given subscription, go to each Application Insights resource,
open the Usage and estimated costs and be sure that it is in the Basic pricing tier, and go to each Log Analytics
workspace, open each the Pricing tier page and change to the Per GB (2018) pricing tier.
NOTE
The requirement that all Application Insights resources and Log Analytics workspaces within a given subscription adopt the
newest pricing model has now been removed, allowing greater flexability and easier configuration.
Automate moving to the new pricing model

As noted above, the is no longer a requirement to move all monitoring resources in a subscription to the new
pricing model at the same time, and hence the migratetonewpricingmodel action will no longer have any effect.
Now you can move Application Insights resources and Log Analytics workspaces separately into the newest
pricing tiers.
Automating this change is documented for Application Insights using Set-AzureRmApplicationInsightsPricingPlan
with -PricingPlan "Basic" and Log Analytics using Set-AzureRmOperationalInsightsWorkspace with
-sku "PerGB2018" .
Manage usage and costs for Application Insights
NOTE
This article describes how to analyze data usage Application Insights. Refer to the following articles for related information.
Monitoring usage and estimated costs describes how to view usage and estimated costs across multiple Azure
monitoring features for different pricing models. It also describes how to change your pricing model.
If you have questions about how pricing works for Application Insights, you can post a question in our forum.
Pricing model
Pricing for Azure Application Insights is based on data volume ingested and optionally for longer data retention.
Each Application Insights resource is charged as a separate service and contributes to the bill for your Azure
subscription.
Data volume details
Data volume is the number of bytes of telemetry received by Application Insights. Data volume is measured
as the size of the uncompressed JSON data package that's received by Application Insights from your
application. For tabular data imported to Analytics, data volume is measured as the uncompressed size of files
that are sent to Application Insights.
Your application's data volume charges are now reported on a new billing meter named Data Ingestion as of
April 2018. This new meter is shared across monitoring technologies such as Applications Insights and Log
Analytics and is currently under the service name Log Analytics.
Live Metrics Stream data isn't counted for pricing purposes.
NOTE
All prices displayed in screenshots in this article are for example purposes only. For current prices in your currency and
region, see Application Insights pricing.
Multi-step web tests

Multi-step web tests incur an additional charge. Multi-step web tests are web tests that perform a sequence of
actions.
There's no separate charge for ping tests of a single page. Telemetry from ping tests and multi-step tests is
charged the same as other telemetry from your app.
Understand your usage and estimate costs

Application Insights makes it easy to understand what your costs are likely to be based on recent usage patterns.
To get started, in the Azure portal, for the Application Insights resource, go to the Usage and estimated costs
page:
A. Review your data volume for the month. This includes all the data that's received and retained (after any
sampling) from your server and client apps, and from availability tests.
B. A separate charge is made for multi-step web tests. (This doesn't include simple availability tests, which are
included in the data volume charge.)
C. View data volume trends for the past month.
D. Enable data ingestion sampling.
E. Set the daily data volume cap.
To investigate your Application Insights usage more deeply, open the Metrics page, add the metric named "Data
point volume", and then select the Apply splitting option to split the data by "Telemetry item type".
Application Insights charges are added to your Azure bill. You can see details of your Azure bill in the Billing
section of the Azure portal, or in the Azure billing portal.
Managing your data volume

To understand how much data your app is sending, you can:
Go to the Usage and estimated cost pane to see the daily data volume chart.
In Metrics Explorer, add a new chart. For the chart metric, select Data point volume. Turn on Grouping, and
then group by Data type.
Use the systemEvents data type. For instance, to see the data volume ingested in the last day, the query would
be:
systemEvents
| where timestamp >= ago(1d)
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes)
This query can be used in an Azure Log Alert to set up alerting on data volumes.
The volume of data you send can be managed in three ways:
Sampling: You can use sampling to reduce the amount of telemetry that's sent from your server and
client apps, with minimal distortion of metrics. Sampling is the primary tool you can use to tune the
amount of data you send. Learn more about sampling features.
Daily cap: When you create an Application Insights resource in the Azure portal, the daily cap is set to
100 GB/day. When you create an Application Insights resource in Visual Studio, the default is small (only
32.3 MB/day). The daily cap default is set to facilitate testing. It's intended that the user will raise the daily
cap before deploying the app into production.
The maximum cap is 1,000 GB/day unless you request a higher maximum for a high-traffic application.
Warning emails about the daily cap are sent to account that are members of these roles for your
Application Insights resource: "ServiceAdmin", "AccountAdmin", "CoAdmin", "Owner".
Use care when you set the daily cap. Your intent should be to never hit the daily cap. If you hit the daily
cap, you lose data for the remainder of the day, and you can't monitor your application. To change the daily
cap, use the Daily volume cap option. You can access this option in the Usage and estimated costs
pane (this is described in more detail later in the article).
We've removed the restriction on some subscription types that have credit that couldn't be used for
Application Insights. Previously, if the subscription has a spending limit, the daily cap dialog has
instructions to remove the spending limit and enable the daily cap to be raised beyond 32.3 MB/day.
Throttling: Throttling limits the data rate to 32,000 events per second, averaged over 1 minute per
instrumentation key. The volume of data that your app sends is assessed every minute. If it exceeds the
per-second rate averaged over the minute, the server refuses some requests. The SDK buffers the data
and then tries to resend it. It spreads out a surge over several minutes. If your app consistently sends data
at more than the throttling rate, some data will be dropped. (The ASP.NET, Java, and JavaScript SDKs try
to resend data this way; other SDKs might simply drop throttled data.) If throttling occurs, a notification
warning alerts you that this has occurred.
Reduce your data volume

Here are some things you can do to reduce your data volume:
Use Sampling. This technology reduces your data rate without skewing your metrics. You don't lose the ability
to navigate between related items in Search. In server apps, sampling operates automatically.
Limit the number of Ajax calls that can be reported in every page view, or switch off Ajax reporting.
Edit ApplicationInsights.config to turn off collection modules that you don't need. For example, you might
decide that performance counters or dependency data are inessential.
Split your telemetry among separate instrumentation keys.
Pre-aggregate metrics. If you put calls to TrackMetric in your app, you can reduce traffic by using the overload
that accepts your calculation of the average and standard deviation of a batch of measurements. Or, you can
use a pre-aggregating package.
Manage your maximum daily data volume
You can use the daily volume cap to limit the data collected. However, if the cap is met, a loss of all telemetry sent
from your application for the remainder of the day occurs. It is not advisable to have your application hit the daily
cap. You can't track the health and performance of your application after it reaches the daily cap.
Instead of using the daily volume cap, use sampling to tune the data volume to the level you want. Then, use the
daily cap only as a "last resort" in case your application unexpectedly begins to send much higher volumes of
telemetry.
Identify what daily data limit to define
Review Application Insights Usage and estimated costs to understand the data ingestion trend and what is the
daily volume cap to define. It should be considered with care, since you won’t be able to monitor your resources
after the limit is reached.
Set the Daily Cap
To change the daily cap, in the Configure section of your Application Insights resource, in the Usage and
estimated costs page, select Daily Cap.
To change the daily cap via Azure Resource Manager, the property to change is the dailyQuota . Via Azure
Resource Manager you can also set the dailyQuotaResetTime and the daily cap's warningThreshold .
Sampling
Sampling is a method of reducing the rate at which telemetry is sent to your app, while retaining the ability to
find related events during diagnostic searches. You also retain correct event counts.
Sampling is an effective way to reduce charges and stay within your monthly quota. The sampling algorithm
retains related items of telemetry so, for example, when you use Search, you can find the request related to a
particular exception. The algorithm also retains correct counts so you see the correct values in Metric Explorer for
request rates, exception rates, and other counts.
There are several forms of sampling.
Adaptive sampling is the default for the ASP.NET SDK. Adaptive sampling automatically adjusts to the
volume of telemetry that your app sends. It operates automatically in the SDK in your web app so that
telemetry traffic on the network is reduced.
Ingestion sampling is an alternative that operates at the point where telemetry from your app enters the
Application Insights service. Ingestion sampling doesn't affect the volume of telemetry sent from your app,
but it reduces the volume that's retained by the service. You can use ingestion sampling to reduce the quota
that's used up by telemetry from browsers and other SDKs.
To set ingestion sampling, go to the Pricing pane:
WARNING
The Data sampling pane controls only the value of ingestion sampling. It doesn't reflect the sampling rate that's applied by
the Application Insights SDK in your app. If the incoming telemetry has already been sampled in the SDK, ingestion
sampling isn't applied.
To discover the actual sampling rate, no matter where it's been applied, use an Analytics query. The query looks
like this:
requests | where timestamp > ago(1d)

| summarize 100/avg(itemCount) by bin(timestamp, 1h)
| render areachart
In each retained record, itemCount indicates the number of original records that it represents. It's equal to 1 +
the number of previous discarded records.
Change the data retention period

NOTE
We've temporarily removed this feature while we address a possible issue. We'll have it back by the first week in October
2019.
The default retention for Application Insights resources is 90 days. Different retention periods can be selected for
each Application Insights resource. The full set of available retention periods is 30, 60, 90, 120, 180, 270, 365, 550
or 730 days.
To change the retention, from your Application Insights resource, go to the Usage and Estimated Costs page
and select the Data Retention option:
When billing is enabled for longer retention, data kept longer than 90 days will be billed as the same rate as is
currently billed for Azure Log Analytics data retention. Learn more at the Azure Monitor Pricing page. Stay up-
to-date on variable retention progress by voting for this suggestion.
Data transfer charges using Application Insights
Sending data to Application Insights might incur data bandwidth charges. As described in the Azure Bandwidth
pricing page, data transfer between Azure services located in two regions charged as outbound data transfer at
the normal rate. Inbound data transfer is free. However, this charge is very small (few %) compared to the costs
for Application Insights log data ingestion. Consequently controlling costs for Log Analytics needs to focus on
your ingested data volume, and we have guidance to help understand that here.
Limits summary
There are some limits on the number of metrics and events per application, that is, per instrumentation key.
Limits depend on the pricing plan that you choose.
RESOURCE DEFAULT LIMIT NOTE
Total data per day 100 GB You can reduce data by setting a cap. If
you need more data, you can increase
the limit in the portal, up to 1,000 GB.
For capacities greater than 1,000 GB,
send email to
AIDataCap@microsoft.com.
Throttling 32,000 events/second The limit is measured over a minute.
Data retention 30 - 730 days This resource is for Search, Analytics,

and Metrics Explorer.
Availability multi-step test detailed 90 days This resource provides detailed results
results retention of each step.
Maximum telemetry item size 64 kB
Maximum telemetry items per batch 64 K
Property and metric name length 150 See type schemas.
Property value string length 8,192 See type schemas.
Trace and exception message length 32,768 See type schemas.
Availability tests count per app 100
Profiler data retention 5 days
Profiler data sent per day 10 GB
For more information, see About pricing and quotas in Application Insights.
Disable daily cap e-mails

To disable the daily volume cap e-mails, under the Configure section of your Application Insights resource, in
the Usage and estimated costs pane, select Daily Cap. There are settings to send e-mail when the cap is
reached, as well as when an adjustable warning level has been reached. If you wish to disable all daily cap
volume-related emails uncheck both boxes.
Legacy Enterprise (Per Node) pricing tier
For early adopters of Azure Application Insights, there are still two possible pricing tiers: Basic and Enterprise.
The Basic pricing tier is the same as described above and is the default tier. It includes all Enterprise tier features,
at no additional cost. The Basic tier bills primarily on the volume of data that's ingested.
NOTE
These legacy pricing tiers have been renamed. The Enterprise pricing tier is now called Per Node and the Basic pricing tier
is now called Per GB. These new names are used below and in the Azure portal.
The Per Node (formerly Enterprise) tier has a per-node charge, and each node receives a daily data allowance. In
the Per Node pricing tier, you are charged for data ingested above the included allowance. If you are using
Operations Management Suite, you should choose the Per Node tier.
For current prices in your currency and region, see Application Insights pricing.
NOTE
In April 2018, we introduced a new pricing model for Azure monitoring. This model adopts a simple "pay-as-you-go" model
across the complete portfolio of monitoring services. Learn more about the new pricing model, how to assess the impact of
moving to this model based on your usage patterns, and how to opt into the new model
Per Node tier and Operations Management Suite subscription entitlements

Customers who purchase Operations Management Suite E1 and E2 can get Application Insights Per Node as an
additional component at no additional cost as previously announced. Specifically, each unit of Operations
Management Suite E1 and E2 includes an entitlement to one node of the Application Insights Per Node tier. Each
Application Insights node includes up to 200 MB of data ingested per day (separate from Log Analytics data
ingestion), with 90-day data retention at no additional cost. The tier is described in more detailed later in the
article.
Because this tier is applicable only to customers with an Operations Management Suite subscription, customers
who don't have an Operations Management Suite subscription don't see an option to select this tier.
NOTE
To ensure that you get this entitlement, your Application Insights resources must be in the Per Node pricing tier. This
entitlement applies only as nodes. Application Insights resources in the Per GB tier don't realize any benefit. This
entitlement isn't visible in the estimated costs shown in the Usage and estimated cost pane. Also, if you move a
subscription to the new Azure monitoring pricing model in April 2018, the Per GB tier is the only tier available. Moving a
subscription to the new Azure monitoring pricing model isn't advisable if you have an Operations Management Suite
subscription.
How the Per Node tier works

You pay for each node that sends telemetry for any apps in the Per Node tier.
A node is a physical or virtual server machine or a platform-as-a-service role instance that hosts your
app.
Development machines, client browsers, and mobile devices do not count as nodes.
If your app has several components that send telemetry, such as a web service and a back-end worker,
the components are counted separately.
Live Metrics Stream data isn't counted for pricing purposes. In a subscription, your charges are per
node, not per app. If you have five nodes that send telemetry for 12 apps, the charge is for five nodes.
Although charges are quoted per month, you're charged only for any hour in which a node sends telemetry
from an app. The hourly charge is the quoted monthly charge divided by 744 (the number of hours in a 31-
day month).
A data volume allocation of 200 MB per day is given for each node that's detected (with hourly granularity).
Unused data allocation isn't carried over from one day to the next.
If you choose the Per Node pricing tier, each subscription gets a daily allowance of data based on the
number of nodes that send telemetry to the Application Insights resources in that subscription. So, if
you have five nodes that send data all day, you'll have a pooled allowance of 1 GB applied to all
Application Insights resources in that subscription. It doesn't matter if certain nodes send more data
than other nodes because the included data is shared across all nodes. If on a given day, the Application
Insights resources receive more data than is included in the daily data allocation for this subscription,
the per-GB overage data charges apply.
The daily data allowance is calculated as the number of hours in the day (using UTC ) that each node
sends telemetry divided by 24 multiplied by 200 MB. So, if you have four nodes that send telemetry
during 15 of the 24 hours in the day, the included data for that day would be ((4 × 15) / 24) × 200 MB
= 500 MB. At the price of 2.30 USD per GB for data overage, the charge would be 1.15 USD if the
nodes send 1 GB of data that day.
The Per Node tier daily allowance isn't shared with applications for which you have chosen the Per GB
tier. Unused allowance isn't carried over from day-to-day.
Examples of how to determine distinct node count
SCENARIO TOTAL DAILY NODE COUNT
1 application using 3 Azure App Service instances and 1 4

virtual server
3 applications running on 2 VMs; the Application Insights 2

resources for these applications are in the same subscription
and in the Per Node tier
4 applications whose Applications Insights resources are in 13.33

the same subscription; each application running 2 instances
during 16 off-peak hours, and 4 instances during 8 peak
hours
Cloud services with 1 Worker Role and 1 Web Role, each 4

running 2 instances
A 5-node Azure Service Fabric cluster running 50 5

microservices; each microservice running 3 instances
The precise node counting depends on which Application Insights SDK your application is using.
In SDK versions 2.2 and later, both the Application Insights Core SDK and the Web SDK report each
application host as a node. Examples are the computer name for physical server and VM hosts or the
instance name for cloud services. The only exception is an application that uses only the .NET Core and
the Application Insights Core SDK. In that case, only one node is reported for all hosts because the host
name isn't available.
For earlier versions of the SDK, the Web SDK behaves like the newer SDK versions, but the Core SDK
reports only one node, regardless of the number of application hosts.
If your application uses the SDK to set roleInstance to a custom value, by default, that same value is
used to determine node count.
If you're using a new SDK version with an app that runs from client machines or mobile devices, the
node count might return a number that's very large (because of the large number of client machines or
mobile devices).
Automation
You can write a script to set the pricing tier by using Azure Resource Management. Learn how.
Next steps
Sampling
Manage usage and costs with Azure Monitor Logs
NOTE
This article describes how to control your costs in Azure Monitor by setting the data retention period for your Log Analytics
workspace. Refer to the following article for related information.
Monitoring usage and estimated costs describes how to view usage and estimated costs across multiple Azure
monitoring features for different pricing models. It also describes how to change your pricing model.
Azure Monitor Logs is designed to scale and support collecting, indexing, and storing massive amounts of data
per day from any source in your enterprise or deployed in Azure. While this may be a primary driver for your
organization, cost-efficiency is ultimately the underlying driver. To that end, it's important to understand that the
cost of a Log Analytics workspace isn't based only on the volume of data collected, it is also dependent on the plan
selected, and how long you chose to store data generated from your connected sources.
In this article we review how you can proactively monitor data volume and storage growth, and define limits to
control those associated costs.
Pricing model
Pricing for Log Analytics is based on data volume ingested and optionally for longer data retention. Each Log
Analytics workspace is charged as a separate service and contributes to the bill for your Azure subscription. The
amount of data ingestion can be considerable depending on the following factors:
Number of management solutions enabled
Use of solutions with their own billing model, for instance Azure Security Center
Number of VMs monitored
Type of data collected from each monitored VM
NOTE
The recently announced Capacity Reservation pricing tiers will be available for Log Analytics on November 1, 2019. Learn
more at the [https://azure.microsoft.com/en-us/pricing/details/monitor/](Azure Monitor pricing page).
Understand your usage and estimate costs

Azure Monitor Logs makes it easy to understand what the costs are likely be based on recent usage patterns. To
do this, use Log Analytics Usage and Estimated Costs to review and analyze data usage. The shows how much
data is collected by each solution, how much data is being retained and an estimate of your costs based on the
amount of data ingested and any additional retention beyond the included amount.
To explore your data in more detail, click on the icon at the top right of either of the charts on the Usage and
Estimated Costs page. Now you can work with this query to explore more details of your usage.
From the Usage and Estimated Costs page you can review your data volume for the month. This includes all the
data received and retained in your Log Analytics workspace. Click Usage details from the top of the page, to view
the usage dashboard with information on data volume trends by source, computers, and offering. To view and set
a daily cap or to modify the retention period, click Data volume management.
Log Analytics charges are added to your Azure bill. You can see details of your Azure bill under the Billing section
of the Azure portal or in the Azure Billing Portal.
Manage your maximum daily data volume

You can configure a daily cap and limit the daily ingestion for your workspace, but use care as your goal should
not be to hit the daily limit. Otherwise, you lose data for the remainder of the day, which can impact other Azure
services and solutions whose functionality may depend on up-to-date data being available in the workspace. As a
result, your ability to observe and receive alerts when the health conditions of resources supporting IT services
are impacted. The daily cap is intended to be used as a way to manage the unexpected increase in data volume
from your managed resources and stay within your limit, or when you want to limit unplanned charges for your
workspace.
When the daily limit is reached, the collection of billable data types stops for the rest of the day. A warning banner
appears across the top of the page for the selected Log Analytics workspace and an operation event is sent to the
Operation table under LogManagement category. Data collection resumes after the reset time defined under
Daily limit will be set at. We recommend defining an alert rule based on this operation event, configured to notify
when the daily data limit has been reached.
NOTE
The daily cap does not stop the collection of data from Azure Security Center, except for workspaces in which Azure Security
Center was installed before June 19, 2017.
Identify what daily data limit to define

Review Log Analytics Usage and estimated costs to understand the data ingestion trend and what is the daily
volume cap to define. It should be considered with care, since you won’t be able to monitor your resources after
the limit is reached.
Set the Daily Cap
The following steps describe how to configure a limit to manage the volume of data that Log Analytics workspace
will ingest per day.
1. From your workspace, select Usage and estimated costs from the left pane.
2. On the Usage and estimated costs page for the selected workspace, click Data volume management
from the top of the page.
3. Daily cap is OFF by default – click ON to enable it, and then set the data volume limit in GB/day.
Alert when Daily Cap reached

While we present a visual cue in the Azure portal when your data limit threshold is met, this behavior doesn't
necessarily align to how you manage operational issues requiring immediate attention. To receive an alert
notification, you can create a new alert rule in Azure Monitor. To learn more, see how to create, view, and manage
alerts.
To get you started, here are the recommended settings for the alert:
Target: Select your Log Analytics resource
Criteria:
Signal name: Custom log search
Search query: Operation | where Detail has 'OverQuota'
Based on: Number of results
Condition: Greater than
Threshold: 0
Period: 5 (minutes)
Frequency: 5 (minutes)
Alert rule name: Daily data limit reached
Severity: Warning (Sev 1)
Once alert is defined and the limit is reached, an alert is triggered and performs the response defined in the Action
Group. It can notify your team via email and text messages, or automate actions using webhooks, Automation
runbooks or integrating with an external ITSM solution.
Change the data retention period

The following steps describe how to configure how long log data is kept by in your workspace.
1. From your workspace, select Usage and estimated costs from the left pane.
2. On the Usage and estimated costs page, click Data volume management from the top of the page.
3. On the pane, move the slider to increase or decrease the number of days and then click OK. If you are on
the free tier, you will not be able to modify the data retention period and you need to upgrade to the paid
tier in order to control this setting.
The retention can also be set via ARM using the dataRetention parameter. Additionally, if you set the data
retention to 30 days, you can trigger an immediate purge of older data using the immediatePurgeDataOn30Days
parameter, which may be useful for compliance-related scenarios. This functionality is only exposed via ARM.
Two data types -- Usage and AzureActivity -- are retained for 90 days by default, and there is no charge for for
this 90 day retention. These data types are also free from data ingestion charges.
Legacy pricing tiers

Subscriptions who had a Log Analytics workspace or Application Insights resource in it before April 2, 2018, or
are linked to an Enterprise Agreement that started prior to February 1, 2019, will continue to have access to use
the legacy pricing tiers: Free, Standalone (Per GB ) and Per Node (OMS ). Workspaces in the Free pricing tier
will have daily data ingestion limited to 500 MB (except for security data types collected by Azure Security Center)
and the data retention is limited to 7 days. The Free pricing tier is intended only for evaluation purposes.
Workspaces in the Standalone or Per Node pricing tiers have user-configurable retention of up to 2 years.
Workspaces created prior to April 2016 also have access the original Standard and Premium pricing tiers which
have fixed data retention of 30 and 365 days respectively. New workspaces cannot be created in the Standard or
Premium pricing tiers, and if a workspace is moved out of these tiers, it cannot be moved back.
More details of pricing tier limitations are available here.
NOTE
To use the entitlements that come from purchasing OMS E1 Suite, OMS E2 Suite or OMS Add-On for System Center, choose
the Log Analytics Per Node pricing tier.
Changing pricing tier

If your Log Analytics workspace has access to legacy pricing tiers, to change between legacy pricing tiers:
1. In the Azure portal, from the Log Analytics subscriptions pane, select a workspace.
2. From the workspace pane, under General, select Pricing tier.
3. Under Pricing tier, select a pricing tier and then click Select.
You can also set the pricing tier via ARM using the ServiceTier parameter.
Troubleshooting why Log Analytics is no longer collecting data

If you are on the legacy Free pricing tier and have sent more than 500 MB of data in a day, data collection stops
for the rest of the day. Reaching the daily limit is a common reason that Log Analytics stops collecting data, or data
appears to be missing. Log Analytics creates an event of type Operation when data collection starts and stops. Run
the following query in search to check if you are reaching the daily limit and missing data:
Operation | where OperationCategory == 'Data Collection Status'
When data collection stops, the OperationStatus is Warning. When data collection starts, the OperationStatus is
Succeeded. The following table describes reasons that data collection stops and a suggested action to resume
data collection:
REASON COLLECTION STOPS SOLUTION
Daily limit of legacy Free pricing tier reached Wait until the following day for collection to automatically
restart, or change to a paid pricing tier.
Daily cap of your workspace was reached Wait for collection to automatically restart, or increase the
daily data volume limit described in manage the maximum
daily data volume. The daily cap reset time is shows on the
Data volume management page.
Azure subscription is in a suspended state due to: Convert to a paid subscription

Free trial ended Remove limit, or wait until limit resets
Azure pass expired
Monthly spending limit reached (for example on an MSDN or
Visual Studio subscription)
To be notified when data collection stops, use the steps described in Create daily data cap alert to be notified
when data collection stops. Use the steps described in create an action group to configure an e-mail, webhook, or
runbook action for the alert rule.
Troubleshooting why usage is higher than expected

Higher usage is caused by one, or both of:
More nodes than expected sending data to Log Analytics workspace
More data than expected being sent to Log Analytics workspace
Understanding nodes sending data

To understand the number of computers reporting heartbeats each day in the last month, use
Heartbeat | where TimeGenerated > startofday(ago(31d))

| summarize dcount(Computer) by bin(TimeGenerated, 1d)
| render timechart
To get a list of computers which will be billed as nodes if the workspace is in the legacy Per Node pricing tier, look
for nodes which are sending billed data types (some data types are free). To do this, use the _IsBillable
property and use the leftmost field of the fully qualified domain name. This returns the list of computers with
billed data:
union withsource = tt *
| where _IsBillable == true
| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize TotalVolumeBytes=sum(_BilledSize) by computerName
The count of billable nodes seen can be estimated as:
| billableNodes=dcount(computerName)
NOTE
Use these union withsource = tt * queries sparingly as scans across data types are expensive to execute. This query
replaces the old way of querying per-computer information with the Usage data type.
A more accurate calculation of what will actually be billed is to get the count of computers per hour that are
sending billed data types. (For workspaces in the legacy Per Node pricing tier, Log Analytics calculates the number
of nodes which need to be billed on an hourly basis.)
| summarize billableNodes=dcount(computerName) by bin(TimeGenerated, 1h) | sort by TimeGenerated asc
Understanding ingested data volume

On the Usage and Estimated Costs page, the Data ingestion per solution chart shows the total volume of data
sent and how much is being sent by each solution. This allows you to determine trends such as whether the overall
data usage (or usage by a particular solution) is growing, remaining steady or decreasing. The query used to
generate this is
Usage | where TimeGenerated > startofday(ago(31d))| where IsBillable == true

| summarize TotalVolumeGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d), Solution| render barchart
Note that the clause "where IsBillable = true" filters out data types from certain solutions for which there is no
ingestion charge.
You can drill in further to see data trends for specific data types, for example if you want to study the data due to
IIS logs:
Usage | where TimeGenerated > startofday(ago(31d))| where IsBillable == true

| where DataType == "W3CIISLog"
| summarize TotalVolumeGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d), Solution| render barchart
Data volume by computer

To see the size of billable events ingested per computer, use the _BilledSize property, which provides the size in
bytes:
| summarize Bytes=sum(_BilledSize) by computerName | sort by Bytes nulls last
The _IsBillable property specifies whether the ingested data will incur charges.
To see the count of billable events ingested per computer, use
| summarize eventCount=count() by computerName | sort by count_ nulls last
If you want to see counts for billable data types are sending data to a specific computer, use:
| where Computer == "computer name"
| summarize count() by tt | sort by count_ nulls last
Data volume by Azure resource, resource group, or subscription

For data from nodes hosted in Azure you can get the size of billable events ingested per computer, use the
_ResourceId property, which provides the full path to the resource:
| summarize Bytes=sum(_BilledSize) by _ResourceId | sort by Bytes nulls last
For data from nodes hosted in Azure you can get the size of billable events ingested per Azure subscription,
parse the _ResourceId property as:
| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/"
resourceGroup "/providers/" provider "/" resourceType "/" resourceName
| summarize Bytes=sum(_BilledSize) by subscriptionId | sort by Bytes nulls last
Changing subscriptionId to resourceGroup will show the billable ingested data volume by Azure resource group.
NOTE
Some of the fields of the Usage data type, while still in the schema, have been deprecated and will their values are no longer
populated. These are Computer as well as fields related to ingestion (TotalBatches, BatchesWithinSla, BatchesOutsideSla,
BatchesCapped and AverageProcessingTimeMs.
Querying for common data types

To dig deeper into the source of data for a particular data type, here are some useful example queries:
Security solution
SecurityEvent | summarize AggregatedValue = count() by EventID
Log Management solution
Usage | where Solution == "LogManagement" and iff(isnotnull(toint(IsBillable)), IsBillable == true,
IsBillable == "true") == true | summarize AggregatedValue = count() by DataType
Perf data type
Perf | summarize AggregatedValue = count() by CounterPath
Perf | summarize AggregatedValue = count() by CounterName
Event data type
Event | summarize AggregatedValue = count() by EventID
Event | summarize AggregatedValue = count() by EventLog, EventLevelName
Syslog data type
Syslog | summarize AggregatedValue = count() by Facility, SeverityLevel
Syslog | summarize AggregatedValue = count() by ProcessName
AzureDiagnostics data type
AzureDiagnostics | summarize AggregatedValue = count() by ResourceProvider, ResourceId
Tips for reducing data volume
Some suggestions for reducing the volume of logs collected include:
SOURCE OF HIGH DATA VOLUME HOW TO REDUCE DATA VOLUME
Security events Select common or minimal security events

Change the security audit policy to collect only needed events.
In particular, review the need to collect events for
- audit filtering platform
- audit registry
- audit file system
- audit kernel object
- audit handle manipulation
- audit removable storage
Performance counters Change performance counter configuration to:

- Reduce the frequency of collection
- Reduce number of performance counters
Event logs Change event log configuration to:

- Reduce the number of event logs collected
- Collect only required event levels. For example, do not
collect Information level events
Syslog Change syslog configuration to:

- Reduce the number of facilities collected
- Collect only required event levels. For example, do not
collect Info and Debug level events
AzureDiagnostics Change resource log collection to:

- Reduce the number of resources send logs to Log Analytics
- Collect only required logs
Solution data from computers that don't need the solution Use solution targeting to collect data from only required
groups of computers.
Getting Security and Automation node counts

If you are on "Per node (OMS )" pricing tier, then you are charged based on the number of nodes and solutions you
use, the number of Insights and Analytics nodes for which you are being billed will be shown in table on the
Usage and Estimated Cost page.
To see the number of distinct Security nodes, you can use the query:
union
(
Heartbeat
| where (Solutions has 'security' or Solutions has 'antimalware' or Solutions has 'securitycenter')
| project Computer
),
(
ProtectionStatus
| where Computer !in~
(
(
Heartbeat
| project Computer
)
)
| project Computer
)
| distinct Computer
| project lowComputer = tolower(Computer)
| distinct lowComputer
| count
To see the number of distinct Automation nodes, use the query:
ConfigurationData
| where (ConfigDataType == "WindowsServices" or ConfigDataType == "Software" or ConfigDataType =="Daemons")
| extend lowComputer = tolower(Computer) | summarize by lowComputer
| join (
Heartbeat
| where SCAgentChannel == "Direct"
| extend lowComputer = tolower(Computer) | summarize by lowComputer, ComputerEnvironment
) on lowComputer
| summarize count() by ComputerEnvironment | sort by ComputerEnvironment asc
Create an alert when data collection is high

This section describes how to create an alert if:
Data volume exceeds a specified amount.
Data volume is predicted to exceed a specified amount.
Azure Alerts support log alerts that use search queries.
The following query has a result when there is more than 100 GB of data collected in the last 24 hours:
union withsource = $table Usage

| where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable ==
"true") == true
| extend Type = $table | summarize DataGB = sum((Quantity / 1024)) by Type
| where DataGB > 100
The following query uses a simple formula to predict when more than 100 GB of data will be sent in a day:
union withsource = $table Usage

| where QuantityUnit == "MBytes" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable ==
"true") == true
| extend Type = $table
| summarize EstimatedGB = sum(((Quantity * 8) / 1024)) by Type
| where EstimatedGB > 100
To alert on a different data volume, change the 100 in the queries to the number of GB you want to alert on.
Use the steps described in create a new log alert to be notified when data collection is higher than expected.
When creating the alert for the first query -- when there is more than 100 GB of data in 24 hours, set the:
Signal Name select Custom log search
Search query to
union withsource = $table Usage | where QuantityUnit == "MBytes" and
iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type =
$table | summarize DataGB = sum((Quantity / 1024)) by Type | where DataGB > 100
Time period of 1440 minutes and Alert frequency to every 60 minutes since the usage data only
updates once per hour.
Name to Data volume greater than 100 GB in 24 hours
Severity to Warning
Specify an existing or create a new Action Group so that when the log alert matches criteria, you are notified.
When creating the alert for the second query -- when it is predicted that there will be more than 100 GB of data in
24 hours, set the:
Signal Name select Custom log search
Search query to
union withsource = $table Usage | where QuantityUnit == "MBytes" and
iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | extend Type =
$table | summarize EstimatedGB = sum(((Quantity * 8) / 1024)) by Type | where EstimatedGB > 100
Time period of 180 minutes and Alert frequency to every 60 minutes since the usage data only
updates once per hour.
Name to Data volume expected to greater than 100 GB in 24 hours
Severity to Warning
Specify an existing or create a new Action Group so that when the log alert matches criteria, you are notified.
When you receive an alert, use the steps in the following section to troubleshoot why usage is higher than
expected.
Data transfer charges using Log Analytics

Sending data to Log Analytics might incur data bandwidth charges. As described in the Azure Bandwidth pricing
page, data transfer between Azure services located in two regions charged as outbound data transfer at the
normal rate. Inbound data transfer is free. However, this charge is very small (few %) compared to the costs for
Log Analytics data ingestion. Consequently controlling costs for Log Analytics needs to focus on your ingested
data volume, and we have guidance to help understand that here.
Limits summary
There are some additional Log Analytics limits, some of which depend on the Log Analytics pricing tier. These are
documented here.
Next steps
See Log searches in Azure Monitor Logs to learn how to use the search language. You can use search queries
to perform additional analysis on the usage data.
Use the steps described in create a new log alert to be notified when a search criteria is met.
Use solution targeting to collect data from only required groups of computers.
To configure an effective event collection policy, review Azure Security Center filtering policy.
Change performance counter configuration.
To modify your event collection settings, review event log configuration.
To modify your syslog collection settings, review syslog configuration.
Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management

(APM ) service for web developers on multiple platforms. Use it to monitor your live web application. It
will automatically detect performance anomalies. It includes powerful analytics tools to help you
diagnose issues and to understand what users actually do with your app. It's designed to help you
continuously improve performance and usability. It works for apps on a wide variety of platforms
including .NET, Node.js and Java EE, hosted on-premises, hybrid, or any public cloud. It integrates with
your DevOps process, and has connection points to a variety of development tools. It can monitor and
analyze telemetry from mobile apps by integrating with Visual Studio App Center.
How does Application Insights work?

You install a small instrumentation package in your application, and set up an Application Insights
resource in the Microsoft Azure portal. The instrumentation monitors your app and sends telemetry
data to Azure Monitor. (The application can run anywhere - it doesn't have to be hosted in Azure.)
You can instrument not only the web service application, but also any background components, and the
JavaScript in the web pages themselves.
In addition, you can pull in telemetry from the host environments such as performance counters, Azure
diagnostics, or Docker logs. You can also set up web tests that periodically send synthetic requests to
your web service.
All these telemetry streams are integrated into Azure Monitor. In the Azure portal, you can apply
powerful analytic and search tools to the raw data.
What's the overhead?
The impact on your app's performance is very small. Tracking calls are non-blocking, and are batched
and sent in a separate thread.
What does Application Insights monitor?
Application Insights is aimed at the development team, to help you understand how your app is
performing and how it's being used. It monitors:
Request rates, response times, and failure rates - Find out which pages are most popular, at
what times of day, and where your users are. See which pages perform best. If your response times
and failure rates go high when there are more requests, then perhaps you have a resourcing
problem.
Dependency rates, response times, and failure rates - Find out whether external services are
slowing you down.
Exceptions - Analyze the aggregated statistics, or pick specific instances and drill into the stack
trace and related requests. Both server and browser exceptions are reported.
Page views and load performance - reported by your users' browsers.
AJAX calls from web pages - rates, response times, and failure rates.
User and session counts.
Performance counters from your Windows or Linux server machines, such as CPU, memory, and
network usage.
Host diagnostics from Docker or Azure.
Diagnostic trace logs from your app - so that you can correlate trace events with requests.
Custom events and metrics that you write yourself in the client or server code, to track business
events such as items sold or games won.
Where do I see my telemetry?

There are plenty of ways to explore your data. Check out these articles:
Smart detection and manual alerts

Automatic alerts adapt to your app's normal patterns of
telemetry and trigger when there's something outside
the usual pattern. You can also set alerts on particular
levels of custom or standard metrics.
Application map
The components of your app, with key metrics and
alerts.
Profiler
Inspect the execution profiles of sampled requests.
Usage analysis
Analyze user segmentation and retention.
Diagnostic search for instance data
Search and filter events such as requests, exceptions,
dependency calls, log traces, and page views.
Metrics Explorer for aggregated data

Explore, filter, and segment aggregated data such as
rates of requests, failures, and exceptions; response
times, page load times.
Dashboards
Mash up data from multiple resources and share with
others. Great for multi-component applications, and for
continuous display in the team room.
Live Metrics Stream

When you deploy a new build, watch these near-real-
time performance indicators to make sure everything
works as expected.
Analytics
Answer tough questions about your app's performance
and usage by using this powerful query language.
Visual Studio
See performance data in the code. Go to code from
stack traces.
Snapshot debugger
Debug snapshots sampled from live operations, with
parameter values.
Power BI
Integrate usage metrics with other business intelligence.
REST API
Write code to run queries over your metrics and raw
data.
Continuous export
Bulk export of raw data to storage as soon as it arrives.
How do I use Application Insights?

Monitor
Install Application Insights in your app, set up availability web tests, and:
Check-out the default application dashboard for your team room to keep an eye on load,
responsiveness, and the performance of your dependencies, page loads, and AJAX calls.
Discover which are the slowest and most failing requests.
Watch Live Stream when you deploy a new release, to know immediately about any degradation.
Detect, Diagnose
When you receive an alert or discover a problem:
Assess how many users are affected.
Correlate failures with exceptions, dependency calls, and traces.
Examine profiler, snapshots, stack dumps, and trace logs.
Build, Measure, Learn
Measure the effectiveness of each new feature that you deploy.
Plan to measure how customers use new UX or business features.
Write custom telemetry into your code.
Base the next development cycle on hard evidence from your telemetry.
Get started
Application Insights is one of the many services hosted within Microsoft Azure, and telemetry is sent
there for analysis and presentation. So before you do anything else, you'll need a subscription to
Microsoft Azure. It's free to sign up, and if you choose the basic pricing plan of Application Insights,
there's no charge until your application has grown to have substantial usage. If your organization
already has a subscription, they could add your Microsoft account to it.
There are several ways to get started. Begin with whichever works best for you. You can add the others
later.
At run time: instrument your web app on the server. Ideal for applications already deployed.
Avoids any update to the code.
ASP.NET or ASP.NET Core applications hosted on Azure Web Apps
ASP.NET applications hosted in IIS on Azure VM or Azure virtual machine scale set
ASP.NET applications hosted in IIS on-premises VM
At development time: add Application Insights to your code. Allows you to customize
telemetry collection and send additional telemetry.
ASP.NET Applications
ASP.NET Core Applications
.NET Console Applications
Java
Node.js
Other platforms
Instrument your web pages for page view, AJAX, and other client-side telemetry.
Analyze mobile app usage by integrating with Visual Studio App Center.
Availability tests - ping your website regularly from our servers.
Next steps
Get started at runtime with:
Azure VM and Azure virtual machine scale set IIS -hosted apps
IIS server
Azure Web Apps
Get started at development time with:
ASP.NET
ASP.NET Core
Java
Node.js
Support and feedback

Questions and Issues:
Troubleshooting
MSDN Forum
StackOverflow
Your suggestions:
UserVoice
Blog:
Application Insights blog
Application Insights for ASP.NET Core applications
This article describes how to enable Application Insights for an ASP.NET Core application. When you complete
the instructions in this article, Application Insights will collect requests, dependencies, exceptions, performance
counters, heartbeats, and logs from your ASP.NET Core application.
The example we'll use here is an MVC application that targets netcoreapp2.2 . You can apply these instructions to
all ASP.NET Core applications.
Supported scenarios
The Application Insights SDK for ASP.NET Core can monitor your applications no matter where or how they
run. If your application is running and has network connectivity to Azure, telemetry can be collected. Application
Insights monitoring is supported everywhere .NET Core is supported. Support covers:
Operating system: Windows, Linux, or Mac.
Hosting method: In process or out of process.
Deployment method: Framework dependent or self-contained.
Web server: IIS (Internet Information Server) or Kestrel.
Hosting platform: The Web Apps feature of Azure App Service, Azure VM, Docker, Azure Kubernetes
Service (AKS ), and so on.
.NET Core Runtime version: 1.XX, 2.XX, or 3.XX
IDE: Visual Studio, VS Code, or command line.
NOTE
If you are using ASP.NET Core 3.0 along with Application Insights, please use the 2.8.0 version or higher. This is the only
version that supports ASP.NET Core 3.0.
Prerequisites
A functioning ASP.NET Core application. If you need to create an ASP.NET Core application, follow this
ASP.NET Core tutorial.
A valid Application Insights instrumentation key. This key is required to send any telemetry to Application
Insights. If you need to create a new Application Insights resource to get an instrumentation key, see Create
an Application Insights resource.
Enable Application Insights server-side telemetry (Visual Studio)

1. Open your project in Visual Studio.
TIP
If you want to, you can set up source control for your project so you can track all the changes that Application
Insights makes. To enable source control, select File > Add to Source Control.
2. Select Project > Add Application Insights Telemetry.

3. Select Get Started. This selection's text might vary, depending on your version of Visual Studio. Some
earlier versions use a Start Free button instead.
4. Select your subscription. Then select Resource > Register.
5. After adding Application Insights to your project, check to confirm that you're using the latest stable
release of the SDK. Go to Project > Manage NuGet Packages >
Microsoft.ApplicationInsights.AspNetCore. If you need to, choose Update.
6. If you followed the optional tip and added your project to source control, go to View > Team Explorer >
Changes. Then select each file to see a diff view of the changes made by Application Insights telemetry.
Enable Application Insights server-side telemetry (no Visual Studio)

1. Install the Application Insights SDK NuGet package for ASP.NET Core. We recommend that you always
use the latest stable version. Find full release notes for the SDK on the open-source GitHub repo.
The following code sample shows the changes to be added to your project's .csproj file.
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.8.0" />
</ItemGroup>
2. Add services.AddApplicationInsightsTelemetry(); to the ConfigureServices() method in your Startup

class, as in this example:
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// The following line enables Application Insights telemetry collection.
services.AddApplicationInsightsTelemetry();
// This code adds other services for your application.

services.AddMvc();
}
3. Set up the instrumentation key.

Although you can provide the instrumentation key as an argument to AddApplicationInsightsTelemetry ,
we recommend that you specify the instrumentation key in configuration. The following code sample
shows how to specify an instrumentation key in appsettings.json . Make sure appsettings.json is copied
to the application root folder during publishing.
{
"ApplicationInsights": {
"InstrumentationKey": "putinstrumentationkeyhere"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
}
}
Alternatively, specify the instrumentation key in either of the following environment variables:
APPINSIGHTS_INSTRUMENTATIONKEY
ApplicationInsights:InstrumentationKey
For example:
SET ApplicationInsights:InstrumentationKey=putinstrumentationkeyhere
SET APPINSIGHTS_INSTRUMENTATIONKEY=putinstrumentationkeyhere
Typically, APPINSIGHTS_INSTRUMENTATIONKEY specifies the instrumentation key for applications deployed to

Azure Web Apps.
NOTE
An instrumentation key specified in code wins over the environment variable APPINSIGHTS_INSTRUMENTATIONKEY ,
which wins over other options.
Run your application

Run your application and make requests to it. Telemetry should now flow to Application Insights. The Application
Insights SDK automatically collects incoming web requests to your application, along with the following
telemetry as well.
Live Metrics
Live Metrics can be used to quickly verify if Application Insights monitoring is configured correctly. While it
might take a few minutes before telemetry starts appearing in the portal and analytics, Live Metrics would show
CPU usage of the running process in near real-time. It can also show other telemetry like Requests,
Dependencies, Traces, etc.
ILogger logs
Logs emitted via ILogger of severity Warning or greater are automatically captured. Follow ILogger docs to
customize which log levels are captured by Application Insights.
Dependencies
Dependency collection is enabled by default. This article explains the dependencies that are automatically
collected, and also contain steps to do manual tracking.
Support for performance counters in ASP.NET Core is limited:
SDK versions 2.4.1 and later collect performance counters if the application is running in Azure Web Apps
(Windows).
SDK versions 2.7.1 and later collect performance counters if the application is running in Windows and
targets NETSTANDARD2.0 or later.
For applications targeting the .NET Framework, all versions of the SDK support performance counters.
SDK Versions 2.8.0 and later support cpu/memory counter in Linux. No other counter is supported in Linux.
The recommended way to get system counters in Linux (and other non-Windows environments) is by using
EventCounters
EventCounter
EventCounterCollectionModule is enabled by default, and it will collect a default set of counters from .NET Core
3.0 apps. The EventCounter tutorial lists the default set of counters collected. It also has instructions on
customizing the list.
Enable client-side telemetry for web applications

The preceding steps are enough to help you start collecting server-side telemetry. If your application has client-
side components, follow the next steps to start collecting usage telemetry.
1. In _ViewImports.cshtml , add injection:
@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet
2. In _Layout.cshtml , insert HtmlHelper at the end of the <head> section but before any other script. If you
want to report any custom JavaScript telemetry from the page, inject it after this snippet:
@Html.Raw(JavaScriptSnippet.FullScript)
</head>
The .cshtml file names referenced earlier are from a default MVC application template. Ultimately, if you want
to properly enable client-side monitoring for your application, the JavaScript snippet must appear in the <head>
section of each page of your application that you want to monitor. You can accomplish this goal for this
application template by adding the JavaScript snippet to _Layout.cshtml .
If your project doesn't include _Layout.cshtml , you can still add client-side monitoring. You can do this by adding
the JavaScript snippet to an equivalent file that controls the <head> of all pages within your app. Or you can add
the snippet to multiple pages, but this solution is difficult to maintain and we generally don't recommend it.
Configure the Application Insights SDK

You can customize the Application Insights SDK for ASP.NET Core to change the default configuration. Users of
the Application Insights ASP.NET SDK might be familiar with changing configuration by using
ApplicationInsights.config or by modifying TelemetryConfiguration.Active . You change configuration
differently for ASP.NET Core. Add the ASP.NET Core SDK to the application and configure it by using ASP.NET
Core built-in dependency injection. Make almost all configuration changes in the ConfigureServices() method of
your Startup.cs class, unless you're directed otherwise. The following sections offer more information.
NOTE
In ASP.NET Core applications, changing configuration by modifying TelemetryConfiguration.Active isn't supported.
Using ApplicationInsightsServiceOptions
You can modify a few common settings by passing ApplicationInsightsServiceOptions to
AddApplicationInsightsTelemetry , as in this example:
{
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions aiOptions
= new
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();
// Disables adaptive sampling.
aiOptions.EnableAdaptiveSampling = false;
// Disables QuickPulse (Live Metrics stream).

aiOptions.EnableQuickPulseMetricStream = false;
services.AddApplicationInsightsTelemetry(aiOptions);
}
Full List of settings in ApplicationInsightsServiceOptions
SETTING DESCRIPTION DEFAULT
EnableQuickPulseMetricStream Enable/Disable LiveMetrics feature true
EnableAdaptiveSampling Enable/Disable Adaptive Sampling true
EnableHeartbeat Enable/Disable Heartbeats feature, true

which periodically (15-min default)
sends a custom metric named
'HeartBeatState' with information
about the runtime like .NET Version,
Azure Environment information, if
applicable, etc.
AddAutoCollectedMetricExtractor Enable/Disable AutoCollectedMetrics true

extractor, which is a TelemetryProcessor
that sends pre-aggregated metrics
about Requests/Dependencies before
sampling takes place.
RequestCollectionOptions.TrackExcepti Enable/Disable reporting of unhandled false in NETSTANDARD2.0 (because

ons Exception tracking by the Request Exceptions are tracked with
collection module. ApplicationInsightsLoggerProvider),
true otherwise.
See the configurable settings in ApplicationInsightsServiceOptions for the most up-to-date list.
Sampling
The Application Insights SDK for ASP.NET Core supports both fixed-rate and adaptive sampling. Adaptive
sampling is enabled by default.
For more information, see Configure adaptive sampling for ASP.NET Core applications.
Adding TelemetryInitializers
Use telemetry initializers when you want to define global properties that are sent with all telemetry.
Add any new TelemetryInitializer to the DependencyInjection container as shown in the following code. The
SDK automatically picks up any TelemetryInitializer that's added to the DependencyInjection container.

{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
}
Removing TelemetryInitializers
Telemetry initializers are present by default. To remove all or specific telemetry initializers, use the following
sample code after you call AddApplicationInsightsTelemetry() .

{
// Remove a specific built-in telemetry initializer

var tiToRemove = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
services.Remove(tiToRemove);
}
// Remove all initializers

// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
services.RemoveAll(typeof(ITelemetryInitializer));
}
Adding telemetry processors

You can add custom telemetry processors to TelemetryConfiguration by using the extension method
AddApplicationInsightsTelemetryProcessor on IServiceCollection . You use telemetry processors in advanced
filtering scenarios. Use the following example.

{
// ...
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
// If you have more processors:

services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Configuring or removing default TelemetryModules

Application Insights uses telemetry modules to automatically collect useful telemetry about specific workloads
without requiring manual tracking by user.
The following automatic-collection modules are enabled by default. These modules are responsible for
automatically collecting telemetry. You can disable or configure them to alter their default behavior.
RequestTrackingTelemetryModule - Collects RequestTelemetry from incoming web requests.
DependencyTrackingTelemetryModule - Collects DependencyTelemetry from outgoing http calls and sql calls.
PerformanceCollectorModule - Collects Windows PerformanceCounters.
QuickPulseTelemetryModule - Collects telemetry for showing in Live Metrics portal.
AppServicesHeartbeatTelemetryModule - Collects heart beats (which are sent as custom metrics), about Azure
App Service environment where application is hosted.
AzureInstanceMetadataTelemetryModule - Collects heart beats (which are sent as custom metrics), about Azure
VM environment where application is hosted.
EventCounterCollectionModule - Collects EventCounters. This module is a new feature and is available in SDK
Version 2.8.0 and higher.
To configure any default TelemetryModule , use the extension method ConfigureTelemetryModule<T> on
IServiceCollection , as shown in the following example.
using Microsoft.ApplicationInsights.DependencyCollector;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;

{
// The following configures DependencyTrackingTelemetryModule.

// Similarly, any other default modules can be configured.
services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) =>
{
module.EnableW3CHeadersInjection = true;
});
// The following removes all default counters from EventCounterCollectionModule, and adds a single one.
services.ConfigureTelemetryModule<EventCounterCollectionModule>(
(module, o) =>
{
module.Counters.Clear();
module.Counters.Add(new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
}
);
// The following removes PerformanceCollectorModule to disable perf-counter collection.

// Similarly, any other default modules can be removed.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>(t => t.ImplementationType ==
typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
Configuring a telemetry channel

The default channel is ServerTelemetryChannel . You can override it as the following example shows.
using Microsoft.ApplicationInsights.Channel;

{
// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel() {MaxTelemetryBufferCapacity =
19898 });
}
Disable telemetry dynamically

If you want to disable telemetry conditionally and dynamically, you may resolve TelemetryConfiguration instance
with ASP.NET Core dependency injection container anywhere in your code and set DisableTelemetry flag on it.
{
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration

configuration)
{
configuration.DisableTelemetry = true;
...
}
The above does not prevent any auto collection modules from collecting telemetry. Only the sending of
telemetry to Application Insights gets disabled with the above approach. If a particular auto collection module is
not desired, it is best to remove the telemetry module
Frequently asked questions

Does Application Insights support ASP.NET Core 3.0?
Yes. Update to Application Insights SDK for ASP.NET Core version 2.8.0 or higher. Older versions of the SDK do
not support ASP.NET Core 3.0.
Also, if you are using Visual Studio based instructions from here, update to the latest version of Visual Studio
2019 (16.3.0) to onboard. Previous versions of Visual Studio do not support automatic onboarding for ASP.NET
Core 3.0 apps.
How can I track telemetry that's not automatically collected?
Get an instance of TelemetryClient by using constructor injection, and call the required TrackXXX() method on
it. We don't recommend creating new TelemetryClient instances in an ASP.NET Core application. A singleton
instance of TelemetryClient is already registered in the DependencyInjection container, which shares
TelemetryConfiguration with rest of the telemetry. Creating a new TelemetryClient instance is recommended
only if it needs a configuration that's separate from the rest of the telemetry.
The following example shows how to track additional telemetry from a controller.
using Microsoft.ApplicationInsights;
public class HomeController : Controller

{
private TelemetryClient telemetry;
// Use constructor injection to get a TelemetryClient instance.

public HomeController(TelemetryClient telemetry)
{
this.telemetry = telemetry;
}
public IActionResult Index()

{
// Call the required TrackXXX method.
this.telemetry.TrackEvent("HomePageRequested");
return View();
}
For more information about custom data reporting in Application Insights, see Application Insights custom
metrics API reference.
Some Visual Studio templates used the UseApplicationInsights() extension method on IWebHostBuilder to
enable Application Insights. Is this usage still valid?
While the extension method UseApplicationInsights() is still supported, it is marked obsolete in Application
Insights SDK version 2.8.0 onwards. It will be removed in the next major version of the SDK. The recommended
way to enable Application Insights telemetry is by using AddApplicationInsightsTelemetry() because it provides
overloads to control some configuration. Also, in ASP.NET Core 3.0 apps,
services.AddApplicationInsightsTelemetry() is the only way to enable application insights.
I'm deploying my ASP.NET Core application to Web Apps. Should I still enable the Application Insights
extension from Web Apps?
If the SDK is installed at build time as shown in this article, you don't need to enable the Application Insights
extension from the App Service portal. Even if the extension is installed, it will back off when it detects that the
SDK is already added to the application. If you enable Application Insights from the extension, you don't have to
install and update the SDK. But if you enable Application Insights by following instructions in this article, you
have more flexibility because:
Application Insights telemetry will continue to work in:
All operating systems, including Windows, Linux, and Mac.
All publish modes, including self-contained or framework dependent.
All target frameworks, including the full .NET Framework.
All hosting options, including Web Apps, VMs, Linux, containers, Azure Kubernetes Service, and non-
Azure hosting.
All .NET Core versions including preview versions.
You can see telemetry locally when you're debugging from Visual Studio.
You can track additional custom telemetry by using the TrackXXX() API.
You have full control over the configuration.
Can I enable Application Insights monitoring by using tools like Status Monitor?
No. Status Monitor and Status Monitor v2 currently support ASP.NET 4.x only.
Is Application Insights automatically enabled for my ASP.NET Core 2.0 application?
The Microsoft.AspNetCore.All 2.0 metapackage included the Application Insights SDK (version 2.1.0). If you run
the application under Visual Studio debugger, Visual Studio enables Application Insights and shows telemetry
locally in the IDE itself. Telemetry wasn't sent to the Application Insights service unless an instrumentation key
was specified. We recommend following the instructions in this article to enable Application Insights, even for 2.0
apps.
If I run my application in Linux, are all features supported?
Yes. Feature support for the SDK is the same in all platforms, with the following exceptions:
Performance counters are supported only in Windows.
Even though ServerTelemetryChannel is enabled by default, if the application is running in Linux or MacOS,
the channel doesn't automatically create a local storage folder to keep telemetry temporarily if there are
network issues. Because of this limitation, telemetry is lost when there are temporary network or server
issues. To work around this issue, configure a local folder for the channel:
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;

{
// The following will configure the channel to use the given folder to temporarily
// store telemetry items during network or Application Insights server issues.
// User should ensure that the given folder already exists
// and that the application has read/write permissions.
services.AddSingleton(typeof(ITelemetryChannel),
new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
}
Is this SDK supported for the new .NET Core 3.0 Worker Service template applications?
This SDK requires HttpContext , and hence does not work in any non-HTTP applications, including the .NET
Core 3.0 Worker Service applications. Refer to this document for enabling application insights in such
applications, using the newly released Microsoft.ApplicationInsights.WorkerService SDK.
Open-source SDK
Read and contribute to the code.
Video
Check out this external step-by-step video to configure Application Insights with .NET Core and Visual Studio
from scratch.
Check out this external step-by-step video to configure Application Insights with .NET Core and Visual Studio
Code from scratch.
Next steps
Explore user flows to understand how users navigate through your app.
Configure a snapshot collection to see the state of source code and variables at the moment an exception is
thrown.
Use the API to send your own events and metrics for a detailed view of your app's performance and usage.
Use availability tests to check your app constantly from around the world.
Dependency Injection in ASP.NET Core
Set up Application Insights for your ASP.NET
website
This procedure configures your ASP.NET web app to send telemetry to the Azure Application Insights
service. It works for ASP.NET apps that are hosted either in your own IIS server on-premises or in the
Cloud. You get charts and a powerful query language that help you understand the performance of your
app and how people are using it, plus automatic alerts on failures or performance issues. Many developers
find these features great as they are, but you can also extend and customize the telemetry if you need to.
Setup takes just a few clicks in Visual Studio. You have the option to avoid charges by limiting the volume
of telemetry. This functionality allows you to experiment and debug, or to monitor a site with not many
users. When you decide you want to go ahead and monitor your production site, it's easy to raise the limit
later.
Prerequisites
To add Application Insights to your ASP.NET website, you need to:
Install Visual Studio 2019 for Windows with the following workloads:
ASP.NET and web development (Do not uncheck the optional components)
Azure development
Step 1: Add the Application Insights SDK

IMPORTANT
The screenshots in this example are based on Visual Studio 2017 version 15.9.9 and later. The experience to add
Application Insights varies across versions of Visual Studio as well as by ASP.NET template type. Older versions may
have alternate text such as "Configure Application Insights".
Right-click your web app name in the Solution Explorer, and choose Add > Application Insights
Telemetry
(Depending on your Application Insights SDK version you may be prompted to upgrade to the latest SDK
release. If prompted, select Update SDK.)
Application Insights Configuration screen:

Select Get Started.
If you want to set the resource group or the location where your data is stored, click Configure settings.
Resource groups are used to control access to data. For example, if you have several apps that form part of
the same system, you might put their Application Insights data in the same resource group.
Select Register.
Select Project > Manage NuGet Packages > Package source: nuget.org > Confirm that you have the
latest stable release of the Application Insights SDK.
Telemetry will be sent to the Azure portal, both during debugging and after you have published your app.
NOTE
If you don't want to send telemetry to the portal while you're debugging, just add the Application Insights SDK to
your app but don't configure a resource in the portal. You are able to see telemetry in Visual Studio while you are
debugging. Later, you can return to this configuration page, or you could wait until after you have deployed your
app and switch on telemetry at run time.
Step 2: Run your app

Run your app with F5. Open different pages to generate some telemetry.
In Visual Studio, you will see a count of the events that have been logged.
Step 3: See your telemetry
You can see your telemetry either in Visual Studio or in the Application Insights web portal. Search
telemetry in Visual Studio to help you debug your app. Monitor performance and usage in the web portal
when your system is live.
See your telemetry in Visual Studio
In Visual Studio, to view Application Insights data. Select Solution Explorer > Connected Services >
right-click Application Insights, and then click Search Live Telemetry.
In the Visual Studio Application Insights Search window, you will see the data from your application for
telemetry generated in the server side of your app. Experiment with the filters, and click any event to see
more detail.
TIP
If you don't see any data, make sure the time range is correct, and click the Search icon.
Learn more about Application Insights tools in Visual Studio.

See telemetry in web portal
You can also see telemetry in the Application Insights web portal (unless you chose to install only the SDK).
The portal has more charts, analytic tools, and cross-component views than Visual Studio. The portal also
provides alerts.
Open your Application Insights resource. Either sign into the Azure portal and find it there, or select
Solution Explorer > Connected Services > right-click Application Insights > Open Application
Insights Portal and let it take you there.
The portal opens on a view of the telemetry from your app.
In the portal, click any tile or chart to see more detail.

Step 4: Publish your app
Publish your app to your IIS server or to Azure. Watch Live Metrics Stream to make sure everything is
running smoothly.
Your telemetry builds up in the Application Insights portal, where you can monitor metrics, search your
telemetry. You can also use the powerful Kusto query language to analyze usage and performance, or to
find specific events.
You can also continue to analyze your telemetry in Visual Studio, with tools such as diagnostic search and
trends.
NOTE
If your app sends enough telemetry to approach the throttling limits, automatic sampling switches on. Sampling
reduces the quantity of telemetry sent from your app, while preserving correlated data for diagnostic purposes.
You're all set

Congratulations! You installed the Application Insights package in your app, and configured it to send
telemetry to the Application Insights service on Azure.
The Azure resource that receives your app's telemetry is identified by an instrumentation key. You'll find
this key in the ApplicationInsights.config file.
Upgrade to future SDK versions

To upgrade to a new release of the SDK, open the NuGet package manager, and filter on installed
packages. Select Microsoft.ApplicationInsights.Web, and choose Upgrade.
If you made any customizations to ApplicationInsights.config, save a copy of it before you upgrade. Then,
merge your changes into the new version.
Video
External step-by-step video about configuring Application Insights with a .NET application from scratch.
Next steps
There are alternative topics to look at if you are interested in:
Instrumenting a web app at runtime
More telemetry
Browser and page load data - Insert a code snippet in your web pages.
Get more detailed dependency and exception monitoring - Install Status Monitor on your server.
Code custom events to count, time, or measure user actions.
Get log data - Correlate log data with your telemetry.
Analysis
Working with Application Insights in Visual Studio
Includes information about debugging with telemetry, diagnostic search, and drill through to code.
Analytics - The powerful query language.
Alerts
Availability tests: Create tests to make sure your site is visible on the web.
Smart diagnostics: These tests run automatically, so you don't have to do anything to set them up. They
tell you if your app has an unusual rate of failed requests.
Metric alerts: Set alerts to warn you if a metric crosses a threshold. You can set them on custom metrics
that you code into your app.
Automation
Automate creating an Application Insights resource
Application Insights for Worker Service applications
(non-HTTP applications)
Application Insights is releasing a new SDK, called Microsoft.ApplicationInsights.WorkerService , which is best suited
for non-HTTP workloads like messaging, background tasks, console applications etc. These types of applications don't
have the notion of an incoming HTTP request like a traditional ASP.NET/ASP.NET Core Web Application, and hence
using Application Insights packages for ASP.NET or ASP.NET Core applications is not supported.
The new SDK does not do any telemetry collection by itself. Instead, it brings in other well known Application Insights
auto collectors like DependencyCollector, PerfCounterCollector, ApplicationInsightsLoggingProvider etc. This SDK
exposes extension methods on IServiceCollection to enable and configure telemetry collection.
Supported scenarios
The Application Insights SDK for Worker Service is best suited for non-HTTP applications no matter where or how
they run. If your application is running and has network connectivity to Azure, telemetry can be collected. Application
Insights monitoring is supported everywhere .NET Core is supported. This package can be used in the newly
introduced .NET Core 3.0 Worker Service, background tasks in Asp.Net Core 2.1/2.2, Console apps (.NET Core/ .NET
Framework), etc.
Prerequisites
A valid Application Insights instrumentation key. This key is required to send any telemetry to Application Insights. If
you need to create a new Application Insights resource to get an instrumentation key, see Create an Application
Insights resource.
Using Application Insights SDK for Worker Services

1. Install the Microsoft.ApplicationInsights.WorkerService package to the application. The following snippet shows the
changes that need to be added to your project's .csproj file.
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.8.0" />
</ItemGroup>
1. Call extension method on

AddApplicationInsightsTelemetryWorkerService(string instrumentationKey)
IServiceCollection , providing the instrumentation key. This method should be called at the beginning of the
application. The exact location depends on the type of application.
2. Retrieve an ILogger instance or TelemetryClient instance from the Dependency Injection (DI) container by
calling serviceProvider.GetRequiredService<TelemetryClient>(); or using Constructor Injection. This step will
trigger setting up of TelemetryConfiguration and auto collection modules.
Specific instructions for each type of application is described in the following sections.
.NET Core 3.0 worker service application

Full example is shared here
1. Download and install .NET Core 3.0
2. Create a new Worker Service project either by using Visual Studio new project template or command line
dotnet new worker
3. Install the Microsoft.ApplicationInsights.WorkerService package to the application.

4. Add services.AddApplicationInsightsTelemetryWorkerService(); to the CreateHostBuilder() method in your
Program.cs class, as in this example:
public static IHostBuilder CreateHostBuilder(string[] args) =>

Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
services.AddApplicationInsightsTelemetryWorkerService();
});
5. Modify your Worker.cs as per below example.
using Microsoft.ApplicationInsights.DataContracts;
public class Worker : BackgroundService

{
private readonly ILogger<Worker> _logger;
private TelemetryClient _telemetryClient;
private static HttpClient _httpClient = new HttpClient();
public Worker(ILogger<Worker> logger, TelemetryClient tc)

{
_logger = logger;
_telemetryClient = tc;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)

{
while (!stoppingToken.IsCancellationRequested)
{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or higher
is captured by Application Insights");
_logger.LogInformation("Calling bing.com");
var res = await httpClient.GetAsync("https://bing.com");
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
telemetryClient.TrackEvent("Bing call event completed");
}
await Task.Delay(1000, stoppingToken);

}
}
}
6. Set up the instrumentation key.

Although you can provide the instrumentation key as an argument to
AddApplicationInsightsTelemetryWorkerService , we recommend that you specify the instrumentation key in
configuration. The following code sample shows how to specify an instrumentation key in appsettings.json .
Make sure appsettings.json is copied to the application root folder during publishing.
{
"ApplicationInsights":
{
"InstrumentationKey": "putinstrumentationkeyhere"
},
"Logging":
{
"LogLevel":
{
}
}
}
Alternatively, specify the instrumentation key in either of the following environment variables.
APPINSIGHTS_INSTRUMENTATIONKEY or ApplicationInsights:InstrumentationKey
For example: SET ApplicationInsights:InstrumentationKey=putinstrumentationkeyhere OR

SET APPINSIGHTS_INSTRUMENTATIONKEY=putinstrumentationkeyhere
Typically, APPINSIGHTS_INSTRUMENTATIONKEY specifies the instrumentation key for applications deployed to Web Apps as
Web Jobs.
NOTE
An instrumentation key specified in code wins over the environment variable APPINSIGHTS_INSTRUMENTATIONKEY , which wins
over other options.
ASP.NET Core background tasks with hosted services

This document describes how to create backgrounds tasks in ASP.NET Core 2.1/2.2 application.
1. Install the
Microsoft.ApplicationInsights.WorkerService(https://www.nuget.org/packages/Microsoft.ApplicationInsights.WorkerService)
package to the application.
2. Add services.AddApplicationInsightsTelemetryWorkerService(); to the ConfigureServices() method, as in this
example:
public static async Task Main(string[] args)
{
var host = new HostBuilder()
.ConfigureAppConfiguration((hostContext, config) =>
{
config.AddJsonFile("appsettings.json", optional: true);
})
.ConfigureServices((hostContext, services) =>
{
services.AddLogging();
services.AddHostedService<TimedHostedService>();
// instrumentation key is read automatically from appsettings.json

})
.UseConsoleLifetime()
.Build();
using (host)
{
// Start the host
await host.StartAsync();
// Wait for the host to shutdown

await host.WaitForShutdownAsync();
}
}
Following is the code for TimedHostedService where the background task logic resides.
public class TimedHostedService : IHostedService, IDisposable

{
private readonly ILogger _logger;
private Timer _timer;
private TelemetryClient _telemetryClient;
private static HttpClient httpClient = new HttpClient();
public TimedHostedService(ILogger<TimedHostedService> logger, TelemetryClient tc)

{
_logger = logger;
this._telemetryClient = tc;
}
public Task StartAsync(CancellationToken cancellationToken)

{
_logger.LogInformation("Timed Background Service is starting.");
_timer = new Timer(DoWork, null, TimeSpan.Zero,

TimeSpan.FromSeconds(1));
return Task.CompletedTask;
}
private void DoWork(object state)

{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or higher is
captured by Application Insights");
_logger.LogInformation("Calling bing.com");
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
}
}
}
3. Set up the instrumentation key. Use the same appsettings.json from the .NET Core 3.0 Worker Service example
above.
.NET Core/.NET Framework Console application

As mentioned in the beginning of this article, the new package can be used to enable Application Insights Telemetry
from even a regular console application. This package targets NetStandard2.0 , and hence can be used for console apps
in .NET Core 2.0 or higher, and .NET Framework 4.7.2 or higher.
1. Install the
Microsoft.ApplicationInsights.WorkerService(https://www.nuget.org/packages/Microsoft.ApplicationInsights.W
orkerService) package to the application.
2. Modify Program.cs as below example.
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using System;
using System.Net.Http;
using System.Threading.Tasks;
namespace WorkerSDKOnConsole
{
class Program
{
static async Task Main(string[] args)
{
// Create the DI container.
IServiceCollection services = new ServiceCollection();
// Being a regular console app, there is no appsettings.json or configuration providers enabled by

default.
// Hence instrumentation key must be specified here.
services.AddApplicationInsightsTelemetryWorkerService("instrumentationkeyhere");
// Build ServiceProvider.
IServiceProvider serviceProvider = services.BuildServiceProvider();
// Obtain logger instance from DI.

ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();
// Obtain TelemetryClient instance from DI, for additional manual tracking or to flush.
var telemetryClient = serviceProvider.GetRequiredService<TelemetryClient>();
var httpClient = new HttpClient();
while (true) // This app runs indefinitely. replace with actual application termination logic.
{
logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
// Replace with a name which makes sense for this operation.

using (telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
logger.LogWarning("A sample warning message. By default, logs with severity Warning or
higher is captured by Application Insights");
logger.LogInformation("Calling bing.com");
logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
}
await Task.Delay(1000);
}
// Explicitly call Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if application terminates, telemetry is sent to the back-end.
telemetryClient.Flush();
Task.Delay(5000).Wait();
}
}
}
This console application also uses the same default TelemetryConfiguration , and it can be customized in the same way
as the examples in earlier section.
Run your application

Run your application. The example workers from all of the above above makes an http call every second to bing.com,
and also emits few logs using ILogger. These lines are wrapped inside StartOperation call of TelemetryClient , which
is used to create an operation (in this example RequestTelemetry named "operation"). Application Insights will collect
these ILogger logs (warning or above by default) and dependencies, and they will be correlated to the
RequestTelemetry with parent-child relationship. The correlation also works cross process/network boundary. For
example, if the call was made to another monitored component, then it will be correlated to this parent as well.
This custom operation of RequestTelemetry can be thought of as the equivalent of an incoming web request in a
typical Web Application. While it is not necessary to use an Operation, it fits best with the Application Insights
correlation data model - with RequestTelemetry acting as the parent operation, and every telemetry generated inside
the worker iteration being treated as logically belonging to the same operation. This approach also ensures all the
telemetry generated (automatic and manual) will have the same operation_id . As sampling is based on operation_id ,
sampling algorithm either keeps or drops all of the telemetry from a single iteration.
The following lists the full telemetry automatically collected by Application Insights.
Live Metrics
Live Metrics can be used to quickly verify if Application Insights monitoring is configured correctly. While it might take
a few minutes before telemetry starts appearing in the portal and analytics, Live Metrics would show CPU usage of
the running process in near real-time. It can also show other telemetry like Requests, Dependencies, Traces etc.
ILogger logs
Logs emitted via ILogger of severity Warning or greater are automatically captured. Follow ILogger docs to
customize which log levels are captured by Application Insights.
Dependencies
Dependency collection is enabled by default. This article explains the dependencies that are automatically collected,
and also contain steps to do manual tracking.
EventCounter
EventCounterCollectionModule is enabled by default, and it will collect a default set of counters from .NET Core 3.0
apps. The EventCounter tutorial lists the default set of counters collected. It also has instructions on customizing the
list.
Manually tracking additional telemetry
While the SDK automatically collects telemetry as explained above, in most cases user will need to send additional
telemetry to Application Insights service. The recommended way to track additional telemetry is by obtaining an
instance of TelemetryClient from Dependency Injection, and then calling one of the supported TrackXXX() API
methods on it. Another typical use case is custom tracking of operations. This approach is demonstrated in the Worker
examples above.
Configure the Application Insights SDK

The default TelemetryConfiguration used by the worker service SDK is similar to the automatic configuration used in a
ASP.NET or ASP.NET Core application, minus the TelemetryInitializers used to enrich telemetry from HttpContext .
You can customize the Application Insights SDK for Worker Service to change the default configuration. Users of the
Application Insights ASP.NET Core SDK might be familiar with changing configuration by using ASP.NET Core built-
in dependency injection. The WorkerService SDK is also based on similar principles. Make almost all configuration
changes in the ConfigureServices() section by calling appropriate methods on IServiceCollection , as detailed below.
NOTE
While using this SDK, changing configuration by modifying TelemetryConfiguration.Active isn't supported, and changes will
not be reflected.
Using ApplicationInsightsServiceOptions
You can modify a few common settings by passing ApplicationInsightsServiceOptions to
AddApplicationInsightsTelemetryWorkerService , as in this example:
using Microsoft.ApplicationInsights.WorkerService;

{
Microsoft.ApplicationInsights.WorkerService.ApplicationInsightsServiceOptions aiOptions
= new Microsoft.ApplicationInsights.WorkerService.ApplicationInsightsServiceOptions();
// Disables adaptive sampling.
// Disables QuickPulse (Live Metrics stream).

aiOptions.EnableQuickPulseMetricStream = false;
services.AddApplicationInsightsTelemetryWorkerService(aiOptions);
}
Note that ApplicationInsightsServiceOptions in this SDK is in the namespace

Microsoft.ApplicationInsights.WorkerService as opposed to Microsoft.ApplicationInsights.AspNetCore.Extensions in
the ASP.NET Core SDK.
Commonly used settings in ApplicationInsightsServiceOptions
SETTING DESCRIPTION DEFAULT
EnableQuickPulseMetricStream Enable/Disable LiveMetrics feature true
EnableAdaptiveSampling Enable/Disable Adaptive Sampling true
EnableHeartbeat Enable/Disable Heartbeats feature, which true

periodically (15-min default) sends a
custom metric named 'HeartBeatState'
with information about the runtime like
.NET Version, Azure Environment
information, if applicable, etc.
AddAutoCollectedMetricExtractor Enable/Disable AutoCollectedMetrics true

extractor, which is a TelemetryProcessor
that sends pre-aggregated metrics about
Requests/Dependencies before sampling
takes place.
See the configurable settings in ApplicationInsightsServiceOptions for the most up-to-date list.
Sampling
The Application Insights SDK for Worker Service supports both fixed-rate and adaptive sampling. Adaptive sampling
is enabled by default. Configuring sampling for Worker Service is done the same way as for ASP.NET Core
Applications.
Adding TelemetryInitializers
Use telemetry initializers when you want to define properties that are sent with all telemetry.
Add any new TelemetryInitializer to the DependencyInjection container and SDK will automatically add them to the
TelemetryConfiguration .
using Microsoft.ApplicationInsights.Extensibility;

{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
}
Removing TelemetryInitializers
Telemetry initializers are present by default. To remove all or specific telemetry initializers, use the following sample
code after you call AddApplicationInsightsTelemetryWorkerService() .

{
// Remove a specific built-in telemetry initializer
var tiToRemove = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
services.Remove(tiToRemove);
}
// Remove all initializers

// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
services.RemoveAll(typeof(ITelemetryInitializer));
}
Adding telemetry processors

You can add custom telemetry processors to TelemetryConfiguration by using the extension method
AddApplicationInsightsTelemetryProcessor on IServiceCollection . You use telemetry processors in advanced filtering
scenarios to allow for more direct control over what's included or excluded from the telemetry you send to the
Application Insights service. Use the following example.

{
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Configuring or removing default TelemetryModules

Application Insights uses telemetry modules to automatically collect telemetry about specific workloads without
requiring manual tracking.
The following automatic-collection modules are enabled by default. These modules are responsible for automatically
collecting telemetry. You can disable or configure them to alter their default behavior.
DependencyTrackingTelemetryModule
PerformanceCollectorModule
QuickPulseTelemetryModule
AppServicesHeartbeatTelemetryModule
AzureInstanceMetadataTelemetryModule
To configure any default TelemetryModule , use the extension method ConfigureTelemetryModule<T> on

IServiceCollection , as shown in the following example.
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

{
// The following configures QuickPulseTelemetryModule.

// Similarly, any other default modules can be configured.
services.ConfigureTelemetryModule<QuickPulseTelemetryModule>((module, o) =>
{
module.AuthenticationApiKey = "keyhere";
});
// The following removes PerformanceCollectorModule to disable perf-counter collection.

// Similarly, any other default modules can be removed.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
Configuring telemetry channel

The default channel is ServerTelemetryChannel . You can override it as the following example shows.

{
// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel() {MaxTelemetryBufferCapacity = 19898
});
}
Disable telemetry dynamically

If you want to disable telemetry conditionally and dynamically, you may resolve TelemetryConfiguration instance with
ASP.NET Core dependency injection container anywhere in your code and set DisableTelemetry flag on it.

{
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration configuration)

{
configuration.DisableTelemetry = true;
...
}

How can I track telemetry that's not automatically collected?
Get an instance of TelemetryClient by using constructor injection, and call the required TrackXXX() method on it. We
don't recommend creating new TelemetryClient instances. A singleton instance of TelemetryClient is already
registered in the DependencyInjection container, which shares TelemetryConfiguration with rest of the telemetry.
Creating a new TelemetryClient instance is recommended only if it needs a configuration that's separate from the rest
of the telemetry.
Can I use Visual Studio IDE to onboard Application Insights to a Worker Service project?
Visual Studio IDE onboarding is currently supported only for ASP.NET/ASP.NET Core Applications. This document
will be updated when Visual Studio ships support for onboarding Worker service applications.
Can I enable Application Insights monitoring by using tools like Status Monitor?
No. Status Monitor and Status Monitor v2 currently support ASP.NET 4.x only.
If I run my application in Linux, are all features supported?
Yes. Feature support for this SDK is the same in all platforms, with the following exceptions:
Performance counters are supported only in Windows with the exception of Process CPU/Memory shown in Live
Metrics.
Even though ServerTelemetryChannel is enabled by default, if the application is running in Linux or MacOS, the
channel doesn't automatically create a local storage folder to keep telemetry temporarily if there are network
issues. Because of this limitation, telemetry is lost when there are temporary network or server issues. To work
around this issue, configure a local folder for the channel:

{
// The following will configure the channel to use the given folder to temporarily
// store telemetry items during network or Application Insights server issues.
// User should ensure that the given folder already exists
// and that the application has read/write permissions.
services.AddSingleton(typeof(ITelemetryChannel),
new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
}
Sample applications
.NET Core Console Application Use this sample if you are using a Console Application written in either .NET Core (2.0
or higher) or .NET Framework (4.7.2 or higher)
ASP .NET Core background tasks with HostedServices Use this sample if you are in Asp.Net Core 2.1/2.2, and
creating background tasks as per official guidance here
.NET Core 3.0 Worker Service Use this sample if you have a .NET Core 3.0 Worker Service application as per official
guidance here
Open-source SDK
Read and contribute to the code.
Next steps
Use the API to send your own events and metrics for a detailed view of your app's performance and usage.
Track additional dependencies not automatically tracked.
Enrich or Filter auto collected telemetry.
Dependency Injection in ASP.NET Core.
Application Insights for .NET console applications
Application Insights lets you monitor your web application for availability, performance, and usage.
You need a subscription with Microsoft Azure. Sign in with a Microsoft account, which you might have for
Windows, Xbox Live, or other Microsoft cloud services. Your team might have an organizational subscription to
Azure: ask the owner to add you to it using your Microsoft account.
NOTE
There is a new beta Application Insights SDK called Microsoft.ApplicationInsights.WorkerService which can used to enable
Application Insights for any Console Applications. It is recommended to use this package and associated instructions from
here. This package targets NetStandard2.0 , and hence can be used in .NET Core 2.0 or higher, and .NET Framework 4.7.2
or higher. This document will be deprecated once a stable version of this new package is released.
Getting started
In the Azure portal, create an Application Insights resource. For application type, choose General.
Take a copy of the Instrumentation Key. Find the key in the Essentials drop-down of the new resource you
created.
Install latest Microsoft.ApplicationInsights package.
Set the instrumentation key in your code before tracking any telemetry (or set
APPINSIGHTS_INSTRUMENTATIONKEY environment variable). After that, you should be able to manually
track telemetry and see it on the Azure portal
// you may use different options to create configuration as shown later in this article
TelemetryConfiguration configuration = TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = " *your key* ";
var telemetryClient = new TelemetryClient(configuration);
telemetryClient.TrackTrace("Hello World!");
Install latest version of Microsoft.ApplicationInsights.DependencyCollector package - it automatically tracks

HTTP, SQL, or some other external dependency calls.
You may initialize and configure Application Insights from the code or using ApplicationInsights.config file. Make
sure initialization happens as early as possible.
NOTE
Instructions referring to ApplicationInsights.config are only applicable to apps that are targeting the .NET Framework, and
do not apply to .NET Core applications.
Using config file

By default, Application Insights SDK looks for ApplicationInsights.config file in the working directory when
TelemetryConfiguration is being created
TelemetryConfiguration config = TelemetryConfiguration.Active; // Reads ApplicationInsights.config file if
present
You may also specify path to the config file.
using System.IO;
TelemetryConfiguration configuration =
TelemetryConfiguration.CreateFromConfiguration(File.ReadAllText("C:\\ApplicationInsights.config"));
var telemetryClient = new TelemetryClient(configuration);
For more information, see configuration file reference.

You may get a full example of the config file by installing latest version of
Microsoft.ApplicationInsights.WindowsServer package. Here is the minimal configuration for dependency
collection that is equivalent to the code example.
<?xml version="1.0" encoding="utf-8"?>

<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<InstrumentationKey>Your Key</InstrumentationKey>
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer,
Microsoft.AI.DependencyCollector"/>
</TelemetryInitializers>
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule,
Microsoft.AI.DependencyCollector">
<ExcludeComponentCorrelationHttpHeadersOnDomains>
<Add>core.windows.net</Add>
<Add>core.chinacloudapi.cn</Add>
<Add>core.cloudapi.de</Add>
<Add>core.usgovcloudapi.net</Add>
<Add>localhost</Add>
<Add>127.0.0.1</Add>
</ExcludeComponentCorrelationHttpHeadersOnDomains>
<IncludeDiagnosticSourceActivities>
<Add>Microsoft.Azure.ServiceBus</Add>
<Add>Microsoft.Azure.EventHubs</Add>
</IncludeDiagnosticSourceActivities>
</Add>
</TelemetryModules>
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
Microsoft.AI.ServerTelemetryChannel"/>
Configuring telemetry collection from code
NOTE
Reading config file is not supported on .NET Core. You may consider using Application Insights SDK for ASP.NET Core
During application start-up create and configure DependencyTrackingTelemetryModule instance - it must be

singleton and must be preserved for application lifetime.
var module = new DependencyTrackingTelemetryModule();
// prevent Correlation Id to be sent to certain endpoints. You may add other domains as needed.
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.windows.net");
//...
// enable known dependency tracking, note that in future versions, we will extend this list.
// please check default settings in https://github.com/Microsoft/ApplicationInsights-dotnet-
server/blob/develop/Src/DependencyCollector/DependencyCollector/ApplicationInsights.config.install.xdt
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.ServiceBus");
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.EventHubs");
//....
// initialize the module

module.Initialize(configuration);
Add common telemetry initializers
// ensures proper DependencyTelemetry.Type is set for Azure RESTful API calls

configuration.TelemetryInitializers.Add(new HttpDependenciesParsingTelemetryInitializer());
If you created configuration with plain TelemetryConfiguration() constructor, you need to enable correlation
support additionally. It is not needed if you read configuration from file, used
TelemetryConfiguration.CreateDefault() or TelemetryConfiguration.Active .
configuration.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());
You may also want to install and initialize Performance Counter collector module as described here
Full example
using Microsoft.ApplicationInsights.DependencyCollector;
namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
TelemetryConfiguration configuration = TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = "removed";
configuration.TelemetryInitializers.Add(new HttpDependenciesParsingTelemetryInitializer());
var telemetryClient = new TelemetryClient();

using (InitializeDependencyTracking(configuration))
{
// run app...
telemetryClient.TrackTrace("Hello World!");
using (var httpClient = new HttpClient())

{
// Http dependency is automatically tracked!
httpClient.GetAsync("https://microsoft.com").Wait();
}
}
// before exit, flush the remaining data

telemetryClient.Flush();
// flush is not blocking so wait a bit

Task.Delay(5000).Wait();
static DependencyTrackingTelemetryModule InitializeDependencyTracking(TelemetryConfiguration

configuration)
{
var module = new DependencyTrackingTelemetryModule();
// prevent Correlation Id to be sent to certain endpoints. You may add other domains as needed.
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.windows.net");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.chinacloudapi.cn");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.cloudapi.de");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.usgovcloudapi.net");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("localhost");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("127.0.0.1");
// enable known dependency tracking, note that in future versions, we will extend this list.
// please check default settings in https://github.com/Microsoft/ApplicationInsights-dotnet-
server/blob/develop/Src/DependencyCollector/DependencyCollector/ApplicationInsights.config.install.xdt
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.ServiceBus");
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.EventHubs");
// initialize the module

module.Initialize(configuration);
return module;
}
}
}
Next steps
Monitor dependencies to see if REST, SQL, or other external resources are slowing you down.
Use the API to send your own events and metrics for a more detailed view of your app's performance and
usage.
ApplicationInsightsLoggerProvider for .NET Core
ILogger logs
ASP.NET Core supports a logging API that works with different kinds of built-in and third-party logging providers.
Logging is done by calling Log() or a variant of it on ILogger instances. This article demonstrates how to use
ApplicationInsightsLoggerProvider to capture ILogger logs in console and ASP.NET Core applications. This article
also describes how ApplicationInsightsLoggerProvider integrates with other Application Insights telemetry. To
learn more, see Logging in ASP.NET Core.
ASP.NET Core applications

ApplicationInsightsLoggerProvider is enabled by default in Microsoft.ApplicationInsights.AspNet SDK version
2.7.0-beta3 (and later) when you turn on regular Application Insights monitoring through either of the standard
methods:
By calling the UseApplicationInsights extension method on IWebHostBuilder
By calling the AddApplicationInsightsTelemetry extension method on IServiceCollection
ILogger logs that ApplicationInsightsLoggerProvider captures are subject to the same configuration as any other
telemetry that's collected. They have the same set of TelemetryInitializers and TelemetryProcessors, use the same
TelemetryChannel, and are correlated and sampled in the same way as other telemetry. If you use version 2.7.0-
beta3 or later, no action is required to capture ILogger logs.
Only Warning or higher ILogger logs (from all categories) are sent to Application Insights by default. But you can
apply filters to modify this behavior. Additional steps are required to capture ILogger logs from Program.cs or
Startup.cs. (See Capturing ILogger logs from Startup.cs and Program.cs in ASP.NET Core applications.)
If you use an earlier version of Microsoft.ApplicationInsights.AspNet SDK or you want to just use
ApplicationInsightsLoggerProvider without any other Application Insights monitoring, use the following
procedure:
1. Install the NuGet package:
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging.ApplicationInsights" Version="2.9.1" />
</ItemGroup>
2. Modify Program.cs as shown here:

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
public class Program

{
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>

WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureLogging(
builder =>
{
// Providing an instrumentation key here is required if you're using
// standalone package Microsoft.Extensions.Logging.ApplicationInsights
// or if you want to capture logs from early in the application startup
// pipeline from Startup.cs or Program.cs itself.
builder.AddApplicationInsights("ikey");
// Optional: Apply filters to control what logs are sent to Application Insights.
// The following configures LogLevel Information or above to be sent to
// Application Insights for all categories.
builder.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("", LogLevel.Information);
}
);
}
The code in step 2 configures ApplicationInsightsLoggerProvider . The following code shows an example Controller
class, which uses ILogger to send logs. The logs are captured by Application Insights.
public class ValuesController : ControllerBase

{
private readonly ÌLogger` _logger;
public ValuesController(ILogger<ValuesController> logger)

{
_logger = logger;
}
// GET api/values
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
// All the following logs will be picked up by Application Insights.
// and all of them will have ("MyKey", "MyValue") in Properties.
using (_logger.BeginScope(new Dictionary<string, object> { { "MyKey", "MyValue" } }))
{
_logger.LogWarning("An example of a Warning trace..");
_logger.LogError("An example of an Error level message");
}
return new string[] { "value1", "value2" };
}
}
Capture ILogger logs from Startup.cs and Program.cs in ASP.NET Core apps
NOTE
In ASP.NET Core 3.0 and later, it is no longer possible to inject ILogger in Startup.cs and Program.cs. See
https://github.com/aspnet/Announcements/issues/353 for more details.
The new ApplicationInsightsLoggerProvider can capture logs from early in the application-startup pipeline.
Although ApplicationInsightsLoggerProvider is automatically enabled in Application Insights (starting with version
2.7.0-beta3), it doesn't have an instrumentation key set up until later in the pipeline. So, only logs from
Controller/other classes will be captured. To capture every log starting with Program.cs and Startup.cs itself, you
must explicitly enable an instrumentation key for ApplicationInsightsLoggerProvider. Also, TelemetryConfiguration
is not fully set up when you log from Program.cs or Startup.cs itself. So those logs will have a minimum
configuration that uses InMemoryChannel, no sampling, and no standard telemetry initializers or processors.
The following examples demonstrate this capability with Program.cs and Startup.cs.
Example Program.cs
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

{
{
var host = CreateWebHostBuilder(args).Build();
var logger = host.Services.GetRequiredService<ILogger<Program>>();
// This will be picked up by AI
logger.LogInformation("From Program. Running the host now..");
host.Run();
}

.ConfigureLogging(
builder =>
{
// Providing an instrumentation key here is required if you're using
// standalone package Microsoft.Extensions.Logging.ApplicationInsights
// or if you want to capture logs from early in the application startup
// pipeline from Startup.cs or Program.cs itself.
builder.AddApplicationInsights("ikey");
// Adding the filter below to ensure logs of all severity from Program.cs
// is sent to ApplicationInsights.
(typeof(Program).FullName, LogLevel.Trace);
// Adding the filter below to ensure logs of all severity from Startup.cs
// is sent to ApplicationInsights.
(typeof(Startup).FullName, LogLevel.Trace);
}
);
}
Example Startup.cs
public class Startup
{
private readonly ÌLogger` _logger;
public Startup(IConfiguration configuration, ILogger<Startup> logger)

{
Configuration = configuration;
_logger = logger;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
{
// The following will be picked up by Application Insights.

_logger.LogInformation("Logging from ConfigureServices.");
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
_logger.LogInformation("Configuring for Development environment");
app.UseDeveloperExceptionPage();
}
else
{
_logger.LogInformation("Configuring for Production environment");
}
app.UseMvc();
}
}
Migrate from the old ApplicationInsightsLoggerProvider

Microsoft.ApplicationInsights.AspNet SDK versions before 2.7.0-beta2 supported a logging provider that's now
obsolete. This provider was enabled through the AddApplicationInsights() extension method of ILoggerFactory.
We recommend that you migrate to the new provider, which involves two steps:
1. Remove the ILoggerFactory.AddApplicationInsights() call from the Startup.Configure() method to avoid
double logging.
2. Reapply any filtering rules in code, because they will not be respected by the new provider. Overloads of
ILoggerFactory.AddApplicationInsights() took minimum LogLevel or filter functions. With the new provider,
filtering is part of the logging framework itself. It's not done by the Application Insights provider. So any filters
that are provided via ILoggerFactory.AddApplicationInsights() overloads should be removed. And filtering rules
should be provided by following the Control logging level instructions. If you use appsettings.json to filter
logging, it will continue to work with the new provider, because both use the same provider alias,
ApplicationInsights.
You can still use the old provider. (It will be removed only in a major version change to 3.xx.) But we recommend
that you migrate to the new provider for the following reasons:
The previous provider lacks support for log scopes. In the new provider, properties from scope are
automatically added as custom properties to the collected telemetry.
Logs can now be captured much earlier in the application startup pipeline. Logs from the Program and
Startup classes can now be captured.
With the new provider, filtering is done at the framework level itself. You can filter logs to the Application
Insights provider in the same way as for other providers, including built-in providers like Console, Debug, and
so on. You can also apply the same filters to multiple providers.
In ASP.NET Core (2.0 and later), the recommended way to enable logging providers is by using extension
methods on ILoggingBuilder in Program.cs itself.
NOTE
The new provider is available for applications that target NETSTANDARD2.0 or later. If your application targets older .NET
Core versions, such as .NET Core 1.1, or if it targets the .NET Framework, continue to use the old provider.
Console application
NOTE
There is a new beta Application Insights SDK called Microsoft.ApplicationInsights.WorkerService which can used to enable
Application Insights (ILogger and other Application Insights telemetry) for any Console Applications. It is recommended to
use this package and associated instructions from here. The following example will be deprecated once stable version of this
new package is released.
The following code shows a sample console application that's configured to send ILogger traces to Application
Insights.
Packages installed:
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.1.0" />
<PackageReference Include="Microsoft.Extensions.Logging.ApplicationInsights" Version="2.9.1" />
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.1.0" />
</ItemGroup>
class Program
{
{
// Channel is explicitly configured to do flush on it later.

var channel = new InMemoryChannel();
services.Configure<TelemetryConfiguration>(
(config) =>
{
config.TelemetryChannel = channel;
}
);
// Add the logging pipelines to use. We are using Application Insights only here.
services.AddLogging(builder =>
{
// Optional: Apply filters to configure LogLevel Trace or above is sent to
// Application Insights for all categories.
("", LogLevel.Trace);
builder.AddApplicationInsights("--YourAIKeyHere--");
});
// Build ServiceProvider.
IServiceProvider serviceProvider = services.BuildServiceProvider();
ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();
// Begin a new scope. This is optional.

using (logger.BeginScope(new Dictionary<string, object> { { "Method", nameof(Main) } }))
{
logger.LogInformation("Logger is working"); // this will be captured by Application Insights.
}
// Explicitly call Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if application terminates, telemetry is sent to the back-end.
channel.Flush();
Thread.Sleep(1000);
}
}
This example uses the standalone package Microsoft.Extensions.Logging.ApplicationInsights . By default, this

configuration uses the "bare minimum" TelemetryConfiguration for sending data to Application Insights. Bare
minimum means that InMemoryChannel is the channel that's used. There's no sampling and no standard
TelemetryInitializers. This behavior can be overridden for a console application, as the following example shows.
Install this additional package:
<PackageReference Include="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" Version="2.9.1" />
The following section shows how to override the default TelemetryConfiguration by using the
services.Configure<TelemetryConfiguration>() method. This example sets up ServerTelemetryChannel and
sampling. It adds a custom ITelemetryInitializer to the TelemetryConfiguration.
var serverChannel = new ServerTelemetryChannel();
services.Configure<TelemetryConfiguration>(
(config) =>
{
config.TelemetryChannel = serverChannel;
config.TelemetryInitializers.Add(new MyTelemetryInitalizer());
config.DefaultTelemetrySink.TelemetryProcessorChainBuilder.UseSampling(5);
serverChannel.Initialize(config);
}
);
// Add the logging pipelines to use. We are adding Application Insights only.
services.AddLogging(loggingBuilder =>
{
loggingBuilder.AddApplicationInsights();
});
........
........
// Explicitly calling Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if the application terminates, telemetry is sent to the back end.
serverChannel.Flush();
Thread.Sleep(1000);
Control logging level

The ASP.NET Core ILogger infra has a built-in mechanism to apply log filtering. This lets you control the logs that
are sent to each registered provider, including the Application Insights provider. The filtering can be done either in
configuration (typically by using an appsettings.json file) or in code. This facility is provided by the framework itself.
It's not specific to the Application Insights provider.
The following examples apply filter rules to ApplicationInsightsLoggerProvider.
Create filter rules in configuration with appsettings.json
For ApplicationInsightsLoggerProvider, the provider alias is ApplicationInsights . The following section of
appsettings.json configures logs for Warning and above from all categories and Error and above from categories
that start with "Microsoft" to be sent to ApplicationInsightsLoggerProvider .
{
"Logging": {
"LogLevel": {
"Default": "Warning",
"Microsoft": "Error"
}
},
"LogLevel": {
}
},
"AllowedHosts": "*"
}
Create filter rules in code

The following code snippet configures logs for Warning and above from all categories and for Error and above
from categories that start with "Microsoft" to be sent to ApplicationInsightsLoggerProvider . This configuration is
the same as in the previous section in appsettings.json.
.ConfigureLogging(logging =>
logging.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("", LogLevel.Warning)
.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("Microsoft", LogLevel.Error);

What are the old and new versions of ApplicationInsightsLoggerProvider?
Microsoft.ApplicationInsights.AspNet SDK included a built-in ApplicationInsightsLoggerProvider
(Microsoft.ApplicationInsights.AspNetCore.Logging.ApplicationInsightsLoggerProvider), which was enabled
through ILoggerFactory extension methods. This provider is marked obsolete from version 2.7.0-beta2. It will be
removed completely in the next major version change. The Microsoft.ApplicationInsights.AspNetCore 2.6.1
package itself isn't obsolete. It's required to enable monitoring of requests, dependencies, and so on.
The suggested alternative is the new standalone package Microsoft.Extensions.Logging.ApplicationInsights, which
contains an improved ApplicationInsightsLoggerProvider
(Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider) and extension methods on
ILoggerBuilder for enabling it.
Microsoft.ApplicationInsights.AspNet SDK version 2.7.0-beta3 takes a dependency on the new package and
enables ILogger capture automatically.
Why are some ILogger logs shown twice in Application Insights?
Duplication can occur if you have the older (now obsolete) version of ApplicationInsightsLoggerProvider enabled
by calling AddApplicationInsights on ILoggerFactory . Check if your Configure method has the following, and
remove it:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

{
loggerFactory.AddApplicationInsights(app.ApplicationServices, LogLevel.Warning);
// ..other code.
}
If you experience double logging when you debug from Visual Studio, set EnableDebugLogger to false in the code
that enables Application Insights, as follows. This duplication and fix is only relevant when you're debugging the
application.

{
ApplicationInsightsServiceOptions options = new ApplicationInsightsServiceOptions();
options.EnableDebugLogger = false;
services.AddApplicationInsightsTelemetry(options);
// ..other code.
}
I updated to Microsoft.ApplicationInsights.AspNet SDK version 2.7.0-beta3, and logs from ILogger are
captured automatically. How do I turn off this feature completely?
See the Control logging level section to see how to filter logs in general. To turn-off
ApplicationInsightsLoggerProvider, use LogLevel.None :
In code:
("", LogLevel.None);
In config:
{
"Logging": {
"LogLevel": {
"Default": "None"
}
}
Why do some ILogger logs not have the same properties as others?
Application Insights captures and sends ILogger logs by using the same TelemetryConfiguration that's used for
every other telemetry. But there's an exception. By default, TelemetryConfiguration is not fully set up when you log
from Program.cs or Startup.cs. Logs from these places won't have the default configuration, so they won't be
running all TelemetryInitializers and TelemetryProcessors.
I'm using the standalone package Microsoft.Extensions.Logging.ApplicationInsights, and I want to log some
additional custom telemetry manually. How should I do that?
When you use the standalone package, TelemetryClient is not injected to the DI container, so you need to create a
new instance of TelemetryClient and use the same configuration as the logger provider uses, as the following
code shows. This ensures that the same configuration is used for all custom telemetry as well as telemetry from
ILogger.
public class MyController : ApiController

{
// This telemtryclient can be used to track additional telemetry using TrackXXX() api.
private readonly TelemetryClient _telemetryClient;
private readonly ILogger _logger;
public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)

{
_telemetryClient = new TelemetryClient(options.Value);
_logger = logger;
}
}
NOTE
If you use the Microsoft.ApplicationInsights.AspNetCore package to enable Application Insights, modify this code to get
TelemetryClient directly in the constructor. For an example, see this FAQ.
What Application Insights telemetry type is produced from ILogger logs? Or where can I see ILogger logs in
Application Insights?
ApplicationInsightsLoggerProvider captures ILogger logs and creates TraceTelemetry from them. If an Exception
object is passed to the Log() method on ILogger, ExceptionTelemetry is created instead of TraceTelemetry. These
telemetry items can be found in same places as any other TraceTelemetry or ExceptionTelemetry for Application
Insights, including portal, analytics, or Visual Studio local debugger.
If you prefer to always send TraceTelemetry, use this snippet:
builder.AddApplicationInsights((opt) => opt.TrackExceptionsAsExceptionTelemetry = false);
I don't have the SDK installed, and I use the Azure Web Apps extension to enable Application Insights for my
ASP.NET Core applications. How do I use the new provider?
The Application Insights extension in Azure Web Apps uses the old provider. You can modify the filtering rules in
the appsettings.json file for your application. To take advantage of the new provider, use build-time instrumentation
by taking a NuGet dependency on the SDK. This article will be updated when the extension switches to use the
new provider.
I'm using the standalone package Microsoft.Extensions.Logging.ApplicationInsights and enabling Application
Insights provider by calling builder.AddApplicationInsights("ikey"). Is there an option to get an instrumentation
key from configuration?
Modify Program.cs and appsettings.json as follows:

{
{
CreateWebHostBuilder(args).Build().Run();
}

.ConfigureLogging((hostingContext, logging) =>
{
// hostingContext.HostingEnvironment can be used to determine environments as well.
var appInsightKey = hostingContext.Configuration["myikeyfromconfig"];
logging.AddApplicationInsights(appInsightKey);
});
}
Relevant section from appsettings.json :
{
"myikeyfromconfig": "putrealikeyhere"
}
This code is required only when you use a standalone logging provider. For regular Application Insights
monitoring, the instrumentation key is loaded automatically from the configuration path ApplicationInsights:
Instrumentationkey. Appsettings.json should look like this:
{
"ApplicationInsights":
{
"Instrumentationkey":"putrealikeyhere"
}
}
Next steps
Learn more about:
Logging in ASP.NET Core
.NET trace logs in Application Insights
Get started with Application Insights in a Java web
project
Application Insights is an extensible analytics service for web developers that helps you understand the
performance and usage of your live application. Use it to automatically instrument request, track
dependencies, and collect performance counters, diagnose performance issues and exceptions, and write code
to track what users do with your app.
Application Insights supports Java apps running on Linux, Unix, or Windows.

You need:
Java 7 or later
A subscription to Microsoft Azure.
1. Get an Application Insights instrumentation key

1. Sign in to the Microsoft Azure portal.
2. Create an Application Insights resource. Set the application type to Java web application.
3. Find the instrumentation key of the new resource. You'll need to paste this key into your code project
shortly.
2. Add the Application Insights SDK for Java to your project

Choose the appropriate way for your project.
If you're using Maven...
If your project is already set up to use Maven for build, merge the following code to your pom.xml file.
Then, refresh the project dependencies to get the binaries downloaded.
<dependencies>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-web-auto</artifactId>


<version>2.5.0</version>
</dependency>
</dependencies>
If you're using Gradle...

If your project is already set up to use Gradle for build, merge the following code to your build.gradle file.
Then refresh the project dependencies to get the binaries downloaded.
dependencies {
compile group: 'com.microsoft.azure', name: 'applicationinsights-web-auto', version: '2.5.0'
// or applicationinsights-web for manual web filter registration
// or applicationinsights-core for bare API
}
Otherwise, if you are manually managing dependencies ...

Download the latest version and copy the necessary files into your project, replacing any previous versions.
Questions...
What's the relationship between the -web-auto , -web and -core components?
gives you metrics that track HTTP servlet request counts and
applicationinsights-web-auto
response times, by automatically registering the Application Insights servlet filter at runtime.
applicationinsights-web also gives you metrics that track HTTP servlet request counts and
response times, but requires manual registration of the Application Insights servlet filter in your
application.
applicationinsights-core gives you just the bare API, for example, if your application is not servlet-
based.
How should I update the SDK to the latest version?
If you are using Gradle or Maven...
Update your build file to specify the latest version.
If you are manually managing dependencies...
Download the latest Application Insights SDK for Java and replace the old ones. Changes
are described in the SDK release notes.
3. Add an ApplicationInsights.xml file

Add ApplicationInsights.xml to the resources folder in your project, or make sure it is added to your project’s
deployment class path. Copy the following XML into it.
Substitute the instrumentation key that you got from the Azure portal.
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings"
schemaVersion="2014-05-30">


<InstrumentationKey>** Your instrumentation key **</InstrumentationKey>

<TelemetryModules>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
</TelemetryModules>



<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitializer
"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitializ
er"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"/
>
Optionally, the configuration file can reside in any location accessible to your application. The system
property -Dapplicationinsights.configurationDirectory specifies the directory that contains
ApplicationInsights.xml. For example, a configuration file located at
E:\myconfigs\appinsights\ApplicationInsights.xml would be configured with the property
-Dapplicationinsights.configurationDirectory="E:\myconfigs\appinsights" .
The instrumentation key is sent along with every item of telemetry and tells Application Insights to display
it in your resource.
The HTTP Request component is optional. It automatically sends telemetry about requests and response
times to the portal.
Event correlation is an addition to the HTTP request component. It assigns an identifier to each request
received by the server, and adds this identifier as a property to every item of telemetry as the property
'Operation.Id'. It allows you to correlate the telemetry associated with each request by setting a filter in
diagnostic search.
Alternative ways to set the instrumentation key
Application Insights SDK looks for the key in this order:
1. System property: -DAPPINSIGHTS_INSTRUMENTATIONKEY=your_ikey
2. Environment variable: APPINSIGHTS_INSTRUMENTATIONKEY
3. Configuration file: ApplicationInsights.xml
You can also set it in code:
String instrumentationKey = "00000000-0000-0000-0000-000000000000";
if (instrumentationKey != null)
{
TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
}
4. Add agent
Install the Java Agent to capture outgoing HTTP calls, JDBC queries, application logging, and better
operation naming.
5. Run your application

Either run it in debug mode on your development machine, or publish to your server.
6. View your telemetry in Application Insights

Return to your Application Insights resource in Microsoft Azure portal.
HTTP requests data appears on the overview blade. (If it isn't there, wait a few seconds and then click
Refresh.)
Learn more about metrics.

Click through any chart to see more detailed aggregated metrics.
Instance data
Click through a specific request type to see individual instances.
Analytics: Powerful query language
As you accumulate more data, you can run queries both to aggregate data and to find individual instances.
Analytics is a powerful tool for both for understanding performance and usage, and for diagnostic purposes.
7. Install your app on the server

Now publish your app to the server, let people use it, and watch the telemetry show up on the portal.
Make sure your firewall allows your application to send telemetry to these ports:
dc.services.visualstudio.com:443
f5.services.visualstudio.com:443
If outgoing traffic must be routed through a firewall, define system properties http.proxyHost and
http.proxyPort .
On Windows servers, install:
Microsoft Visual C++ Redistributable
(This component enables performance counters.)
Azure App Service config (Spring Boot)

Spring Boot apps running on Windows require additional configuration to run on Azure App Services.
Modify web.config and add the following:
<?xml version="1.0" encoding="UTF-8"?>

<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler"
resourceType="Unspecified"/>
</handlers>
<httpPlatform processPath="%JAVA_HOME%\bin\java.exe" arguments="-Djava.net.preferIPv4Stack=true -
Dserver.port=%HTTP_PLATFORM_PORT% -jar "%HOME%\site\wwwroot\AzureWebAppExample-0.0.1-
SNAPSHOT.jar"">
</httpPlatform>
</system.webServer>
</configuration>
Exceptions and request failures

Unhandled exceptions and request failures are automatically collected by the Application Insights web filter.
To collect data on other exceptions, you can insert calls to trackException() in your code.
Monitor method calls and external dependencies

Install the Java Agent to log specified internal methods and calls made through JDBC, with timing data.
And for automatic operation naming.
W3C distributed tracing

The Application Insights Java SDK now supports W3C distributed tracing.
The incoming SDK configuration is explained further in our article on correlation.
Outgoing SDK configuration is defined in the AI-Agent.xml file.
Open Investigate, Metrics, to see a range of performance counters.
Customize performance counter collection
To disable collection of the standard set of performance counters, add the following code under the root node
of the ApplicationInsights.xml file:
<PerformanceCounters>
<UseBuiltIn>False</UseBuiltIn>
</PerformanceCounters>
Collect additional performance counters

You can specify additional performance counters to be collected.
JMX counters (exposed by the Java Virtual Machine)
<Jmx>
<Add objectName="java.lang:type=ClassLoading" attribute="TotalLoadedClassCount"
displayName="Loaded Class Count"/>
<Add objectName="java.lang:type=Memory" attribute="HeapMemoryUsage.used" displayName="Heap Memory
Usage-used" type="composite"/>
</Jmx>
displayName – The name displayed in the Application Insights portal.

objectName – The JMX object name.
attribute – The attribute of the JMX object name to fetch
type (optional) - The type of JMX object’s attribute:
Default: a simple type such as int or long.
composite : the perf counter data is in the format of 'Attribute.Data'
tabular : the perf counter data is in the format of a table row
Windows performance counters

Each Windows performance counter is a member of a category (in the same way that a field is a member of a
class). Categories can either be global, or can have numbered or named instances.
<Windows>
<Add displayName="Process User Time" categoryName="Process" counterName="%User Time"
instanceName="__SELF__" />
<Add displayName="Bytes Printed per Second" categoryName="Print Queue" counterName="Bytes
Printed/sec" instanceName="Fax" />
</Windows>
displayName – The name displayed in the Application Insights portal.

categoryName – The performance counter category (performance object) with which this performance
counter is associated.
counterName – The name of the performance counter.
instanceName – The name of the performance counter category instance, or an empty string (""), if the
category contains a single instance. If the categoryName is Process, and the performance counter you'd
like to collect is from the current JVM process on which your app is running, specify "__SELF__" .
Unix performance counters
Install collectd with the Application Insights plugin to get a wide variety of system and network data.
Get user and session data

OK, you're sending telemetry from your web server. Now to get the full 360-degree view of your application,
you can add more monitoring:
Add telemetry to your web pages to monitor page views and user metrics.
Set up web tests to make sure your application stays live and responsive.
Send your own telemetry

Now that you've installed the SDK, you can use the API to send your own telemetry.
Track custom events and metrics to learn what users are doing with your application.
Search events and logs to help diagnose problems.
Availability web tests

Application Insights can test your website at regular intervals to check that it's up and responding well.
Learn more about how to set up availability web tests.
Questions? Problems?
Troubleshooting Java
Next steps
Monitor dependency calls
Monitor Unix performance counters
Add monitoring to your web pages to monitor page load times, AJAX calls, browser exceptions.
Write custom telemetry to track usage in the browser or at the server.
Use Analytics for powerful queries over telemetry from your app
For more information, visit Azure for Java developers.
Monitor Docker applications in Application Insights
(Deprecated)
NOTE
This solution has been deprecated. To learn more about our current investments in container monitoring we recommend
checking out Azure Monitor for containers.
Lifecycle events and performance counters from Docker containers can be charted on Application Insights. Install
the Application Insights image in a container in your host, and it will display performance counters for the host, as
well as for the other images.
With Docker, you distribute your apps in lightweight containers complete with all dependencies. They'll run on any
host machine that runs a Docker Engine.
When you run the Application Insights image on your Docker host, you get these benefits:
Lifecycle telemetry about all the containers running on the host - start, stop, and so on.
Performance counters for all the containers. CPU, memory, network usage, and more.
If you installed Application Insights SDK for Java in the apps running in the containers, all the telemetry of those
apps will have additional properties identifying the container and host machine. So for example, if you have
instances of an app running in more than one host, you can easily filter your app telemetry by host.
Set up your Application Insights resource

1. Sign into Microsoft Azure portal and open the Application Insights resource for your app; or create a new
one.
Which resource should I use? If the apps that you are running on your host were developed by someone
else, then you need to create a new Application Insights resource. This is where you view and analyze the
telemetry. (Select 'General' for the app type.)
But if you're the developer of the apps, then we hope you added Application Insights SDK to each of them. If
they're all really components of a single business application, then you might configure all of them to send
telemetry to one resource, and you'll use that same resource to display the Docker lifecycle and performance
data.
A third scenario is that you developed most of the apps, but you are using separate resources to display their
telemetry. In that case, you probably also want to create a separate resource for the Docker data.
2. Click the Essentials drop-down and copy the Instrumentation Key. You use this to tell the SDK where to
send its telemetry.
Keep that browser window handy, as you'll come back to it soon to look at your telemetry.
Run the Application Insights monitor on your host

Now that you've got somewhere to display the telemetry, you can set up the containerized app that will collect and
send it.
1. Connect to your Docker host.
2. Edit your instrumentation key into this command, and then run it:
docker run -v /var/run/docker.sock:/docker.sock -d microsoft/applicationinsights ikey=000000-1111-2222-

3333-444444444
Only one Application Insights image is required per Docker host. If your application is deployed on multiple Docker
hosts, then repeat the command on every host.
Update your app

If your application is instrumented with the Application Insights SDK for Java, add the following line into the
ApplicationInsights.xml file in your project, under the <TelemetryInitializers> element:
<Add type="com.microsoft.applicationinsights.extensibility.initializer.docker.DockerContextInitializer"/>
This adds Docker information such as container and host id to every telemetry item sent from your app.
View your telemetry

Go back to your Application Insights resource in the Azure portal.
Click through the Docker tile.
You'll shortly see data arriving from the Docker app, especially if you have other containers running on your
Docker engine.
Docker container events
To investigate individual events, click Search. Search and filter to find the events you want. Click any event to get
more detail.
Exceptions by container name
Docker context added to app telemetry
Request telemetry sent from the application instrumented with AI SDK, is enriched with Docker context
information.
Q&A
What does Application Insights give me that I can't get from Docker?
Detailed breakdown of performance counters by container and image.
Integrate container and app data in one dashboard.
Export telemetry for further analysis to a database, Power BI or other dashboard.
How do I get telemetry from the app itself?
Install the Application Insights SDK in the app. Learn how for: Java web apps, Windows web apps.
Video
Next steps
Application Insights for Java
Application Insights for Node.js
Application Insights for ASP.NET
Explore Java trace logs in Application Insights
If you're using Logback or Log4J (v1.2 or v2.0) for tracing, you can have your trace logs sent automatically to
Application Insights where you can explore and search on them.
Using the Application Insights Java agent

You can configure the Application Insights Java agent to automatically capture your logs, by enabling the feature
in the AI-Agent.xml file:

<ApplicationInsightsAgent>
<Instrumentation>
<BuiltIn enabled="true">
<Logging enabled="true" />
</BuiltIn>
</Instrumentation>
<AgentLogger />
</ApplicationInsightsAgent>
Alternatively, you can follow the instructions below.
Install the Java SDK

Follow the instructions to install Application Insights SDK for Java, if you haven't already done that.
Add logging libraries to your project

Choose the appropriate way for your project.
If you're using Maven...
If your project is already set up to use Maven for build, merge one of the following snippets of code into your
pom.xml file.
Then refresh the project dependencies, to get the binaries downloaded.
Logback
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-logback</artifactId>
<version>[2.0,)</version>
</dependency>
</dependencies>
Log4J v2.0
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-log4j2</artifactId>
</dependency>
</dependencies>
Log4J v1.2
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-log4j1_2</artifactId>
</dependency>
</dependencies>
If you're using Gradle...

If your project is already set up to use Gradle for build, add one of the following lines to the dependencies group
in your build.gradle file:
Then refresh the project dependencies, to get the binaries downloaded.
Logback
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-logback', version: '2.0.+'
Log4J v2.0
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j2', version: '2.0.+'
Log4J v1.2
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j1_2', version: '2.0.+'
Otherwise ...
Follow the guidelines to manually install Application Insights Java SDK, download the jar (After arriving at Maven
Central Page click on 'jar' link in download section) for appropriate appender and add the downloaded appender
jar to the project.
LOGGER DOWNLOAD LIBRARY
Logback Logback appender Jar applicationinsights-logging-logback
Log4J v2.0 Log4J v2 appender Jar applicationinsights-logging-log4j2
Log4j v1.2 Log4J v1.2 appender Jar applicationinsights-logging-log4j1_2
Add the appender to your logging framework

To start getting traces, merge the relevant snippet of code to the Log4J or Logback configuration file:
Logback
<appender name="aiAppender"
class="com.microsoft.applicationinsights.logback.ApplicationInsightsAppender">
<instrumentationKey>[APPLICATION_INSIGHTS_KEY]</instrumentationKey>
</appender>
<root level="trace">
<appender-ref ref="aiAppender" />
</root>
Log4J v2.0
<Configuration packages="com.microsoft.applicationinsights.log4j.v2">
<Appenders>
<ApplicationInsightsAppender name="aiAppender" instrumentationKey="[APPLICATION_INSIGHTS_KEY]" />
</Appenders>
<Loggers>
<Root level="trace">
<AppenderRef ref="aiAppender"/>
</Root>
</Loggers>
</Configuration>
Log4J v1.2
<appender name="aiAppender"
class="com.microsoft.applicationinsights.log4j.v1_2.ApplicationInsightsAppender">
<param name="instrumentationKey" value="[APPLICATION_INSIGHTS_KEY]" />
</appender>
<root>
<priority value ="trace" />
<appender-ref ref="aiAppender" />
</root>
The Application Insights appenders can be referenced by any configured logger, and not necessarily by the root
logger (as shown in the code samples above).
Explore your traces in the Application Insights portal

Now that you've configured your project to send traces to Application Insights, you can view and search these
traces in the Application Insights portal, in the Search blade.
Exceptions submitted via loggers will be displayed on the portal as Exception Telemetry.
Next steps
Diagnostic search
collectd: Linux performance metrics in Application
Insights
To explore Linux system performance metrics in Application Insights, install collectd, together with its Application
Insights plug-in. This open-source solution gathers various system and network statistics.
Typically you'll use collectd if you have already instrumented your Java web service with Application Insights. It
gives you more data to help you to enhance your app's performance or diagnose problems.
Get your instrumentation key

In the Microsoft Azure portal, open the Application Insights resource where you want the data to appear. (Or
create a new resource.)
Take a copy of the instrumentation key, which identifies the resource.
Install collectd and the plug-in

On your Linux server machines:
1. Install collectd version 5.4.0 or later.
2. Download the Application Insights collectd writer plugin. Note the version number.
3. Copy the plugin JAR into /usr/share/collectd/java .
4. Edit /etc/collectd/collectd.conf :
Ensure that the Java plugin is enabled.
Update the JVMArg for the java.class.path to include the following JAR. Update the version number to
match the one you downloaded:
/usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar
Add this snippet, using the Instrumentation Key from your resource:
LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
<Plugin ApplicationInsightsWriter>
InstrumentationKey "Your key"
</Plugin>
Here's part of a sample configuration file:

...
# collectd plugins
LoadPlugin cpu
LoadPlugin disk
LoadPlugin load
...
# Enable Java Plugin

LoadPlugin "java"
# Configure Java Plugin

<Plugin "java">
JVMArg "-verbose:jni"
JVMArg "-Djava.class.path=/usr/share/collectd/java/applicationinsights-collectd-
1.0.5.jar:/usr/share/collectd/java/collectd-api.jar"
# Enabling Application Insights plugin

LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
# Configuring Application Insights plugin

<Plugin ApplicationInsightsWriter>
InstrumentationKey "12345678-1234-1234-1234-123456781234"
</Plugin>
# Other plugin configurations ...

...
</Plugin>
...
Configure other collectd plugins, which can collect various data from different sources.
Restart collectd according to its manual.
View the data in Application Insights

In your Application Insights resource, open Metrics and add charts, selecting the metrics you want to see from the
Custom category.
By default, the metrics are aggregated across all host machines from which the metrics were collected. To view the
metrics per host, in the Chart details blade, turn on Grouping and then choose to group by CollectD -Host.
To exclude upload of specific statistics

By default, the Application Insights plugin sends all the data collected by all the enabled collectd 'read' plugins.
To exclude data from specific plugins or data sources:
Edit the configuration file.
In <Plugin ApplicationInsightsWriter> , add directive lines like this:
DIRECTIVE EFFECT
Exclude disk Exclude all data collected by the disk plugin
Exclude disk:read,write Exclude the sources named read and write from the
disk plugin.
Separate directives with a newline.

Problems?
I don't see data in the portal
Open Search to see if the raw events have arrived. Sometimes they take longer to appear in metrics explorer.
You might need to set firewall exceptions for outgoing data
Enable tracing in the Application Insights plugin. Add this line within <Plugin ApplicationInsightsWriter> :
SDKLogger true
Open a terminal and start collectd in verbose mode, to see any issues it is reporting:
sudo collectd -f
Known issue
The Application Insights Write plugin is incompatible with certain Read plugins. Some plugins sometimes send
"NaN" where the Application Insights plugin expects a floating-point number.
Symptom: The collectd log shows errors that include "AI: ... SyntaxError: Unexpected token N".
Workaround: Exclude data collected by the problem Write plugins.
Monitor dependencies, caught exceptions, and
method execution times in Java web apps
If you have instrumented your Java web app with Application Insights, you can use the Java Agent to get deeper
insights, without any code changes:
Dependencies: Data about calls that your application makes to other components, including:
Outgoing HTTP calls made via Apache HttpClient, OkHttp, and java.net.HttpURLConnection are
captured.
Redis calls made via the Jedis client are captured.
JDBC queries - For MySQL and PostgreSQL, if the call takes longer than 10 seconds, the agent
reports the query plan.
Application logging: Capture and correlate your application logs with HTTP requests and other
telemetry
Log4j 1.2
Log4j2
Logback
Better operation naming: (used for aggregation of requests in the portal)
Spring - based on @RequestMapping .
JAX-RS - based on @Path .
To use the Java agent, you install it on your server. Your web apps must be instrumented with the Application
Insights Java SDK.
Install the Application Insights agent for Java

1. On the machine running your Java server, download the agent. Please ensure to download the same
version of Java Agent as Application Insights Java SDK core and web packages.
2. Edit the application server startup script, and add the following JVM argument:
-javaagent:<full path to the agent JAR file>
For example, in Tomcat on a Linux machine:

export JAVA_OPTS="$JAVA_OPTS -javaagent:<full path to agent JAR file>"
3. Restart your application server.
Configure the agent

Create a file named AI-Agent.xml and place it in the same folder as the agent JAR file.
Set the content of the xml file. Edit the following example to include or omit the features you want.
<ApplicationInsightsAgent>
<Instrumentation>

<Logging enabled="true" />

<HTTP enabled="true" />


<JDBC enabled="true" />


<Jedis enabled="true" />

<MaxStatementQueryLimitInMS>1000</MaxStatementQueryLimitInMS>
</BuiltIn>
</Instrumentation>
</ApplicationInsightsAgent>
Additional config (Spring Boot)

java -javaagent:/path/to/agent.jar -jar path/to/TestApp.jar
For Azure App Services, do the following:

Select Settings > Application Settings
Under App Settings, add a new key value pair:
Key: JAVA_OPTS Value: -javaagent:D:/home/site/wwwroot/applicationinsights-agent-2.5.0.jar
For the latest version of the Java agent, check the releases here.
The agent must be packaged as a resource in your project such that it ends up in the D:/home/site/wwwroot/
directory. You can confirm that your agent is in the correct App Service directory by going to Development
Tools > Advanced Tools > Debug Console and examining the contents of the site directory.
Save the settings and Restart your app. (These steps only apply to App Services running on Windows.)
NOTE
AI-Agent.xml and the agent jar file should be in the same folder. They are often placed together in the /resources folder
of the project.
Enable W3C distributed tracing

Add the following to AI-Agent.xml:
<Instrumentation>
<HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
</BuiltIn>
</Instrumentation>
NOTE
Backward compatibility mode is enabled by default and the enableW3CBackCompat parameter is optional and should be
used only when you want to turn it off.
Ideally this would be the case when all your services have been updated to newer version of SDKs supporting
W3C protocol. It is highly recommended to move to newer version of SDKs with W3C support as soon as
possible.
Make sure that both incoming and outgoing (agent) configurations are exactly same.
View the data

In the Application Insights resource, aggregated remote dependency and method execution times appear under
the Performance tile.
To search for individual instances of dependency, exception, and method reports, open Search.
Diagnosing dependency issues - learn more.
Questions? Problems?
No data? Set firewall exceptions
Troubleshooting Java
Filter telemetry in your Java web app
Filters provide a way to select the telemetry that your Java web app sends to Application Insights. There are some
out-of-the-box filters that you can use, and you can also write your own custom filters.
The out-of-the-box filters include:
Trace severity level
Specific URLs, keywords or response codes
Fast responses - that is, requests to which your app responded to quickly
Specific event names
NOTE
Filters skew the metrics of your app. For example, you might decide that, in order to diagnose slow responses, you will set a
filter to discard fast response times. But you must be aware that the average response times reported by Application Insights
will then be slower than the true speed, and the count of requests will be smaller than the real count. If this is a concern, use
Sampling instead.
Setting filters
In ApplicationInsights.xml, add a TelemetryProcessors section like this example:
<TelemetryProcessors>
<BuiltInProcessors>
<Processor type="TraceTelemetryFilter">
<Add name="FromSeverityLevel" value="ERROR"/>
</Processor>
<Processor type="RequestTelemetryFilter">
<Add name="MinimumDurationInMS" value="100"/>
<Add name="NotNeededResponseCodes" value="200-400"/>
</Processor>
<Processor type="PageViewTelemetryFilter">
<Add name="DurationThresholdInMS" value="100"/>
<Add name="NotNeededNames" value="home,index"/>
<Add name="NotNeededUrls" value=".jpg,.css"/>
</Processor>
<Processor type="TelemetryEventFilter">

<Add name="NotNeededNames" value="Start,Stop,Pause"/>
</Processor>


<Processor type="SyntheticSourceFilter">

<Add name="NotNeededSources" value="Application Insights Availability Monitoring,BingPreview"
</Processor>
</BuiltInProcessors>
<CustomProcessors>
<Processor type="com.fabrikam.MyFilter">
<Add name="Successful" value="false"/>
</Processor>
</CustomProcessors>
</TelemetryProcessors>
Inspect the full set of built-in processors.
Built-in filters
Metric Telemetry filter
<Processor type="MetricTelemetryFilter">
<Add name="NotNeeded" value="metric1,metric2"/>
</Processor>
NotNeeded - Comma-separated list of custom metric names.

Page View Telemetry filter
<Processor type="PageViewTelemetryFilter">
<Add name="DurationThresholdInMS" value="500"/>
<Add name="NotNeededNames" value="page1,page2"/>
<Add name="NotNeededUrls" value="url1,url2"/>
</Processor>
DurationThresholdInMS - Duration refers to the time taken to load the page. If this is set, pages that loaded
faster than this time are not reported.
NotNeededNames - Comma-separated list of page names.
NotNeededUrls - Comma-separated list of URL fragments. For example, "home" filters out all pages that have
"home" in the URL.
Request Telemetry Filter
<Processor type="RequestTelemetryFilter">
<Add name="MinimumDurationInMS" value="500"/>
<Add name="NotNeededResponseCodes" value="page1,page2"/>
<Add name="NotNeededUrls" value="url1,url2"/>
</Processor>
Synthetic Source filter

Filters out all telemetry that have values in the SyntheticSource property. These include requests from bots, spiders
and availability tests.
Filter out telemetry for all synthetic requests:
<Processor type="SyntheticSourceFilter" />
Filter out telemetry for specific synthetic sources:
<Processor type="SyntheticSourceFilter" >

<Add name="NotNeeded" value="source1,source2"/>
</Processor>
NotNeeded - Comma-separated list of synthetic source names.

Telemetry Event filter
Filters custom events (logged using TrackEvent()).
<Processor type="TelemetryEventFilter" >

<Add name="NotNeededNames" value="event1, event2"/>
</Processor>
NotNeededNames - Comma-separated list of event names.

Trace Telemetry filter
Filters log traces (logged using TrackTrace() or a logging framework collector).
<Processor type="TraceTelemetryFilter">
<Add name="FromSeverityLevel" value="ERROR"/>
</Processor>
FromSeverityLevel valid values are:

OFF - Filter out ALL traces
TRACE - No filtering. equals to Trace level
INFO - Filter out TRACE level
WARN - Filter out TRACE and INFO
ERROR - Filter out WARN, INFO, TRACE
CRITICAL - filter out all but CRITICAL
Custom filters
1. Code your filter
In your code, create a class that implements TelemetryProcessor :
package com.fabrikam.MyFilter;
import com.microsoft.applicationinsights.extensibility.TelemetryProcessor;
import com.microsoft.applicationinsights.telemetry.Telemetry;
public class SuccessFilter implements TelemetryProcessor {
/* Any parameters that are required to support the filter.*/

private final String successful;
/* Initializers for the parameters, named "setParameterName" */

public void setNotNeeded(String successful)
{
this.successful = successful;
}
/* This method is called for each item of telemetry to be sent.

Return false to discard it.
Return true to allow other processors to inspect it. */
@Override
public boolean process(Telemetry telemetry) {
if (telemetry == null) { return true; }
if (telemetry instanceof RequestTelemetry)
{
RequestTelemetry requestTelemetry = (RequestTelemetry)telemetry;
return request.getSuccess() == successful;
}
return true;
}
}
2. Invoke your filter in the configuration file

In ApplicationInsights.xml:
<CustomProcessors>
<Processor type="com.fabrikam.SuccessFilter">
<Add name="Successful" value="false"/>
</Processor>
</CustomProcessors>
3. Invoke your filter (Java Spring)

For applications based on the Spring framework, custom telemetry processors must be registered in your main
application class as a bean. They will then be autowired when the application starts.
@Bean
public TelemetryProcessor successFilter() {
return new SuccessFilter();
}
You will need to create your own filter parameters in application.properties and leverage Spring Boot's
externalized configuration framework to pass those parameters into your custom filter.
Troubleshooting
My filter isn't working.
Check that you have provided valid parameter values. For example, durations should be integers. Invalid values
will cause the filter to be ignored. If your custom filter throws an exception from a constructor or set method, it
will be ignored.
Next steps
Sampling - Consider sampling as an alternative that does not skew your metrics.
How to use Micrometer with Azure Application
Insights Java SDK
Micrometer application monitoring measures metrics for JVM -based application code and lets you export the data
to your favorite monitoring systems. This article will teach you how to use Micrometer with Application Insights for
both Spring Boot and non-Spring Boot applications.
Using Spring Boot 1.5x

Add the following dependencies to your pom.xml or build.gradle file:
Application Insights spring-boot-starter 2.5.0 or later
Micrometer Azure Registry 1.1.0 or above
Micrometer Spring Legacy 1.1.0 or above (this backports the autoconfig code in the Spring framework).
ApplicationInsights Resource
Steps
1. Update the pom.xml file of your Spring Boot application and add the following dependencies in it:
<dependency>
<artifactId>applicationinsights-spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-spring-legacy</artifactId>
</dependency>
<dependency>
<artifactId>micrometer-registry-azure-monitor</artifactId>
</dependency>
2. Update the application.properties or yml file with the Application Insights Instrumentation key using the
following property:
azure.application-insights.instrumentation-key=<your-instrumentation-key-here>
3. Build your application and run

4. The above should get you up and running with pre-aggregated metrics auto collected to Azure Monitor. For
details on how to fine-tune Application Insights Spring Boot starter refer to the readme on GitHub.
Using Spring 2.x

Application Insights Spring-boot-starter 2.1.2 or above
Azure-spring-boot-metrics-starters 2.0.7 or later
Application Insights Resource
Steps:
1. Update the pom.xml file of your Spring Boot application and add the following dependency in it:
<dependency>
<artifactId>azure-spring-boot-metrics-starter</artifactId>
</dependency>
2. Update the application.properties or yml file with the Application Insights Instrumentation key using the
following property:
azure.application-insights.instrumentation-key=<your-instrumentation-key-here>
3. Build your application and run

4. The above should get you running with pre-aggregated metrics auto collected to Azure Monitor. For details
on how to fine-tune Application Insights Spring Boot starter refer to the readme on GitHub.
Default Metrics:
Automatically configured metrics for Tomcat, JVM, Logback Metrics, Log4J metrics, Uptime Metrics, Processor
Metrics, FileDescriptorMetrics.
For example, if Netflix Hystrix is present on class path we get those metrics as well.
The following metrics can be available by adding respective beans.
CacheMetrics (CaffeineCache, EhCache2, GuavaCache, HazelcastCache, JCache)
DataBaseTableMetrics
HibernateMetrics
JettyMetrics
OkHttp3 metrics
Kafka Metrics
How to turn off automatic metrics collection:
JVM Metrics:
management.metrics.binders.jvm.enabled=false
Logback Metrics:
management.metrics.binders.logback.enabled=false
Uptime Metrics:
management.metrics.binders.uptime.enabled=false
Processor Metrics:
management.metrics.binders.processor.enabled=false
FileDescriptorMetrics:
management.metrics.binders.files.enabled=false
Hystrix Metrics if library on classpath:
management.metrics.binders.hystrix.enabled=false
AspectJ Metrics if library on classpath:
spring.aop.enabled=false
NOTE
Specify the properties above in the application.properties or application.yml file of your Spring Boot application
Use Micrometer with non-Spring Boot web applications

Application Insights Web Auto 2.5.0 or later
Micrometer Azure Registry 1.1.0 or above
Application Insights Resource
Steps:
1. Add the following dependencies in your pom.xml or build.gradle file:
<dependency>
<artifactId>micrometer-registry-azure-monitor</artifactId>
</dependency>
<dependency>
<artifactId>applicationinsights-web-auto</artifactId>
</dependency>
2. Put ApplicationInsights.xml file in the resources folder:

<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings"
schemaVersion="2014-05-30">


<InstrumentationKey>** Your instrumentation key **</InstrumentationKey>

<TelemetryModules>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
</TelemetryModules>



<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitialize
r"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitiali
zer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"
/>
3. Sample Servlet class (emits a timer metric):

@WebServlet("/hello")
public class TimedDemo extends HttpServlet {
private static final long serialVersionUID = -4751096228274971485L;
@Override
@Timed(value = "hello.world")
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.getWriter().println("Hello World!");
MeterRegistry registry = (MeterRegistry)
getServletContext().getAttribute("AzureMonitorMeterRegistry");
//create new Timer metric

Timer sampleTimer = registry.timer("timer");
Stream<Integer> infiniteStream = Stream.iterate(0, i -> i+1);
infiniteStream.limit(10).forEach(integer -> {
try {
Thread.sleep(1000);
sampleTimer.record(integer, TimeUnit.MILLISECONDS);
} catch (Exception e) {}
});
}
@Override
public void init() throws ServletException {
System.out.println("Servlet " + this.getServletName() + " has started");
}
@Override
public void destroy() {
System.out.println("Servlet " + this.getServletName() + " has stopped");
}
4. Sample configuration class:

@WebListener
public class MeterRegistryConfiguration implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
// Create AzureMonitorMeterRegistry
private final AzureMonitorConfig config = new AzureMonitorConfig() {
@Override
public String get(String key) {
return null;
}
@Override
public Duration step() {
return Duration.ofSeconds(60);}
@Override
public boolean enabled() {
return false;
}
};
MeterRegistry azureMeterRegistry = AzureMonitorMeterRegistry.builder(config);
//set the config to be used elsewhere

servletContextEvent.getServletContext().setAttribute("AzureMonitorMeterRegistry",
azureMeterRegistry);
@Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {
}
}
To learn more about metrics, refer to the Micrometer documentation.

Other sample code on how to create different types of metrics can be found inthe official Micrometer GitHub repo.
How to bind additional metrics collection

SpringBoot/Spring
Create a bean of the respective metric category. For example, say we need Guava cache Metrics:
@Bean
GuavaCacheMetrics guavaCacheMetrics() {
Return new GuavaCacheMetrics();
}
There are several metrics that are not enabled by default but can be bound in the above fashion. For a complete list,
refer to the official Micrometer GitHub repo.
Non-Spring apps
Add the following binding code to the configuration file:
New GuavaCacheMetrics().bind(registry);
Next steps
To learn more about Micrometer, see the official Micrometer documentation.
To learn about Spring on Azure, see the official Spring on Azure documentation.
Troubleshooting and Q and A for Application Insights
for Java
Questions or problems with Azure Application Insights in Java? Here are some tips.
Build errors
In Eclipse or Intellij Idea, when adding the Application Insights SDK via Maven or Gradle, I get build or
checksum validation errors.
If the dependency element is using a pattern with wildcard characters (e.g. (Maven)
<version>
<version>[2.0,)</version> or ( Gradle) version:'2.0.+' ), try specifying a specific version instead like 2.0.1 .
See the release notes for the latest version.
No data
I added Application Insights successfully and ran my app, but I've never seen data in the portal.
Wait a minute and click Refresh. The charts refresh themselves periodically, but you can also refresh manually.
The refresh interval depends on the time range of the chart.
Check that you have an instrumentation key defined in the ApplicationInsights.xml file (in the resources folder
in your project) or configured as Environment variable.
Verify that there is no <DisableTelemetry>true</DisableTelemetry> node in the xml file.
In your firewall, you might have to open TCP ports 80 and 443 for outgoing traffic to
dc.services.visualstudio.com. See the full list of firewall exceptions
In the Microsoft Azure start board, look at the service status map. If there are some alert indications, wait until
they have returned to OK and then close and re-open your Application Insights application blade.
Turn on logging by adding an <SDKLogger /> element under the root node in the ApplicationInsights.xml file
(in the resources folder in your project), and check for entries prefaced with AI: INFO/WARN/ERROR for any
suspicious logs.
Make sure that the correct ApplicationInsights.xml file has been successfully loaded by the Java SDK, by
looking at the console's output messages for a "Configuration file has been successfully found" statement.
If the config file is not found, check the output messages to see where the config file is being searched for, and
make sure that the ApplicationInsights.xml is located in one of those search locations. As a rule of thumb, you
can place the config file near the Application Insights SDK JARs. For example: in Tomcat, this would mean the
WEB -INF/classes folder. During development you can place ApplicationInsights.xml in resources folder of your
web project.
Please also look at GitHub issues page for known issues with the SDK.
Please ensure to use same version of Application Insights core, web, agent and logging appenders to avoid any
version conflict issues.
I used to see data, but it has stopped
Check the status blog.
Have you hit your monthly quota of data points? Open Settings/Quota and Pricing to find out. If so, you can
upgrade your plan, or pay for additional capacity. See the pricing scheme.
Have you recently upgraded your SDK? Please ensure that only Unique SDK jars are present inside the project
directory. There should not be two different versions of SDK present.
Are you looking at the correct AI resource? Please match the iKey of your application to the resource where
you are expecting telemetry. They should be the same.
I don't see all the data I'm expecting
Open the Usage and estimated cost page and check whether sampling is in operation. (100% transmission
means that sampling isn't in operation.) The Application Insights service can be set to accept only a fraction of
the telemetry that arrives from your app. This helps you keep within your monthly quota of telemetry.
Do you have SDK Sampling turned on? If yes, data would be sampled at the rate specified for all the applicable
types.
Are you running an older version of Java SDK? Starting with version 2.0.1, we have introduced fault tolerance
mechanism to handle intermittent network and backend failures as well as data persistence on local drives.
Are you getting throttled due to excessive telemetry? If you turn on INFO logging, you will see a log message
"App is throttled". Our current limit is 32k telemetry items/second.
Java Agent cannot capture dependency data
Have you configured Java agent by following Configure Java Agent ?
Make sure both the java agent jar and the AI-Agent.xml file are placed in the same folder.
Make sure that the dependency you are trying to auto-collect is supported for auto collection. Currently we
only support MySQL, MsSQL, Oracle DB and Azure Cache for Redis dependency collection.
Are you using JDK 1.7 or 1.8? Currently we do not support dependency collection in JDK 9.
No usage data
I see data about requests and response times, but no page view, browser, or user data.
You successfully set up your app to send telemetry from the server. Now your next step is to set up your web
pages to send telemetry from the web browser.
Alternatively, if your client is an app in a phone or other device, you can send telemetry from there.
Use the same instrumentation key to set up both your client and server telemetry. The data will appear in the
same Application Insights resource, and you'll be able to correlate events from client and server.
Disabling telemetry
How can I disable telemetry collection?
In code:
TelemetryConfiguration config = TelemetryConfiguration.getActive();

config.setTrackingIsDisabled(true);
Or
Update ApplicationInsights.xml (in the resources folder in your project). Add the following under the root node:
<DisableTelemetry>true</DisableTelemetry>
Using the XML method, you have to restart the application when you change the value.
Changing the target

How can I change which Azure resource my project sends data to?
Get the instrumentation key of the new resource.
If you added Application Insights to your project using the Azure Toolkit for Eclipse, right click your web
project, select Azure, Configure Application Insights, and change the key.
If you had configured the Instrumentation Key as environment variable please update the value of the
environment variable with new iKey.
Otherwise, update the key in ApplicationInsights.xml in the resources folder in your project.
Debug data from the SDK

How can I find out what the SDK is doing?
To get more information about what's happening in the API, add <SDKLogger/> under the root node of the
ApplicationInsights.xml configuration file.
ApplicationInsights.xml
You can also instruct the logger to output to a file:
<SDKLogger type="FILE">

<Level>TRACE</Level>
<UniquePrefix>AI</UniquePrefix>
<BaseFolderPath>C:/agent/AISDK</BaseFolderPath>
</SDKLogger>
Spring Boot Starter

To enable SDK logging with Spring Boot Apps using the Application Insights Spring Boot Starter, add the
following to the application.properties file:
azure.application-insights.logger.type=file
azure.application-insights.logger.base-folder-path=C:/agent/AISDK
azure.application-insights.logger.level=trace
or to print to standard error:
azure.application-insights.logger.type=console
azure.application-insights.logger.level=trace
Java Agent
To enable JVM Agent Logging update the AI-Agent.xml file:
<AgentLogger type="FILE">

<Level>TRACE</Level>
<UniquePrefix>AI</UniquePrefix>
<BaseFolderPath>C:/agent/AIAGENT</BaseFolderPath>
</AgentLogger>
Java Command Line Properties

Since version 2.4.0
To enable logging using command line options, without changing configuration files:
java -Dapplicationinsights.logger.file.level=trace -Dapplicationinsights.logger.file.uniquePrefix=AI -

Dapplicationinsights.logger.baseFolderPath="C:/my/log/dir" -jar MyApp.jar
or to print to standard error:
java -Dapplicationinsights.logger.console.level=trace -jar MyApp.jar
The Azure start screen

I'm looking at the Azure portal. Does the map tell me something about my app?
No, it shows the health of Azure servers around the world.
From the Azure start board (home screen), how do I find data about my app?
Assuming you set up your app for Application Insights, click Browse, select Application Insights, and select the app
resource you created for your app. To get there faster in future, you can pin your app to the start board.
Intranet servers
Can I monitor a server on my intranet?
Yes, provided your server can send telemetry to the Application Insights portal through the public internet.
In your firewall, you might have to open TCP ports 80 and 443 for outgoing traffic to dc.services.visualstudio.com
and f5.services.visualstudio.com.
Data retention
How long is data retained in the portal? Is it secure?
See Data retention and privacy.
Debug logging
Application Insights uses org.apache.http . This is relocated within Application Insights core jars under the
namespace com.microsoft.applicationinsights.core.dependencies.http . This enables Application Insights to handle
scenarios where different versions of the same org.apache.http exist in one code base.
NOTE
If you enable DEBUG level logging for all namespaces in the app, it will be honored by all executing modules including
org.apache.http renamed as com.microsoft.applicationinsights.core.dependencies.http . Application Insights will
not be able to apply filtering for these calls because the log call is being made by the Apache library. DEBUG level logging
produce a considerable amount of log data and is not recommended for live production instances.
Next steps
I set up Application Insights for my Java server app. What else can I do?
Monitor availability of your web pages
Monitor web page usage
Track usage and diagnose issues in your device apps
Write code to track usage of your app
Capture diagnostic logs
Get help
Stack Overflow
File an issue on GitHub
Monitor your Node.js services and apps with
Azure Application Insights monitors your backend services and components after deployment, to help you
discover and rapidly diagnose performance and other issues. You can use Application Insights for Node.js
services that are hosted in your datacenter, in Azure VMs and web apps, and even in other public clouds.
To receive, store, and explore your monitoring data, include the SDK in your code, and then set up a
corresponding Application Insights resource in Azure. The SDK sends data to that resource for further analysis
and exploration.
The Node.js SDK can automatically monitor incoming and outgoing HTTP requests, exceptions, and some
system metrics. Beginning in version 0.20, the SDK also can monitor some common third-party packages, like
MongoDB, MySQL, and Redis. All events related to an incoming HTTP request are correlated for faster
troubleshooting.
You can use the TelemetryClient API to manually instrument and monitor additional aspects of your app and
system. We describe the TelemetryClient API in more detail later in this article.
Get started
Complete the following tasks to set up monitoring for an app or service.
Prerequisites
Before you begin, make sure that you have an Azure subscription, or get a new one for free. If your organization
already has an Azure subscription, an administrator can follow these instructions to add you to it.
Set up an Application Insights resource
2. Select Create a resource > Developer tools > Application Insights. The resource includes an
endpoint for receiving telemetry data, storage for this data, saved reports and dashboards, rule and alert
configuration, and more.
3. On the resource creation page, in the Application Type box, select Node.js Application. The app type
determines the default dashboards and reports that are created. (Any Application Insights resource can
collect data from any language and platform.)
Set up the Node.js SDK
Include the SDK in your app, so it can gather data.
1. Copy your resource's Instrumentation Key (also called an ikey) from the Azure portal. Application Insights
uses the ikey to map data to your Azure resource. Before the SDK can use your ikey, you must specify the
ikey in an environment variable or in your code.
2. Add the Node.js SDK library to your app's dependencies via package.json. From the root folder of your
app, run:
npm install applicationinsights --save
3. Explicitly load the library in your code. Because the SDK injects instrumentation into many other libraries,
load the library as early as possible, even before other require statements.
At the top of your first .js file, add the following code. The setup method configures the ikey (and thus,
the Azure resource) to be used by default for all tracked items.
const appInsights = require("applicationinsights");

appInsights.setup("<instrumentation_key>");
appInsights.start();
You also can provide an ikey via the environment variable APPINSIGHTS_INSTRUMENTATIONKEY,
instead of passing it manually to setup() or new appInsights.TelemetryClient() . This practice lets you
keep ikeys out of committed source code, and you can specify different ikeys for different environments.
For additional configuration options, see the following sections.
You can try the SDK without sending telemetry by setting
appInsights.defaultClient.config.disableAppInsights = true .
Monitor your app
The SDK automatically gathers telemetry about the Node.js runtime and about some common third-party
modules. Use your application to generate some of this data.
Then, in the Azure portal go to the Application Insights resource that you created earlier. In the Overview
timeline, look for your first few data points. To see more detailed data, select different components in the charts.
To view the topology that is discovered for your app, select the Application map button. Select components in
the map to see more details.
To learn more about your app, and to troubleshoot problems, in the INVESTIGATE section, select the other
views that are available.
No data?
Because the SDK batches data for submission, there might be a delay before items are displayed in the portal. If
you don't see data in your resource, try some of the following fixes:
Continue to use the application. Take more actions to generate more telemetry.
Click Refresh in the portal resource view. Charts periodically refresh on their own, but manually refreshing
forces them to refresh immediately.
Verify that required outgoing ports are open.
Use Search to look for specific events.
Check the FAQ.
SDK configuration
The SDK's configuration methods and default values are listed in the following code example.
To fully correlate events in a service, be sure to set .setAutoDependencyCorrelation(true) . With this option set, the
SDK can track context across asynchronous callbacks in Node.js.

appInsights.setup("<instrumentation_key>")
.setAutoDependencyCorrelation(true)
.setAutoCollectRequests(true)
.setAutoCollectPerformance(true)
.setAutoCollectExceptions(true)
.setAutoCollectDependencies(true)
.setAutoCollectConsole(true)
.setUseDiskRetryCaching(true)
.start();
TelemetryClient API
For a full description of the TelemetryClient API, see Application Insights API for custom events and metrics.
You can track any request, event, metric, or exception by using the Application Insights Node.js SDK. The
following code example demonstrates some of the APIs that you can use:
let appInsights = require("applicationinsights");

appInsights.setup().start(); // assuming ikey is in env var
let client = appInsights.defaultClient;
client.trackEvent({name: "my custom event", properties: {customProperty: "custom property value"}});

client.trackException({exception: new Error("handled exceptions can be logged with this method")});
client.trackMetric({name: "custom metric", value: 3});
client.trackTrace({message: "trace message"});
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers",
duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL"});
client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200,
success:true});
let http = require("http");

http.createServer( (req, res) => {
client.trackNodeHttpRequest({request: req, response: res}); // Place at the beginning of your request
handler
});
Track your dependencies

Use the following code to track your dependencies:
let appInsights = require("applicationinsights");

let client = appInsights.defaultClient;
var success = false;

let startTime = Date.now();
// Execute dependency call here...
let duration = Date.now() - startTime;
success = true;
client.trackDependency({dependencyTypeName: "dependency name", name: "command name", duration: duration,

success: success});
Add a custom property to all events

Use the following code to add a custom property to all events:
appInsights.defaultClient.commonProperties = {
environment: process.env.SOME_ENV_VARIABLE
};
Track HTTP GET requests

Use the following code to track HTTP GET requests:
var server = http.createServer((req, res) => {

if ( req.method === "GET" ) {
appInsights.defaultClient.trackNodeHttpRequest({request: req, response: res});
}
// Other work here...
res.end();
});
Track server startup time

Use the following code to track server startup time:
let start = Date.now();

server.on("listening", () => {
let duration = Date.now() - start;
appInsights.defaultClient.trackMetric({name: "server startup time", value: duration});
});
Next steps
Monitor your telemetry in the portal
Write Analytics queries over your telemetry
Application Insights for web pages
Find out about the performance and usage of your web page or app. If you add Application Insights to
your page script, you get timings of page loads and AJAX calls, counts, and details of browser exceptions
and AJAX failures, as well as users and session counts. All these can be segmented by page, client OS and
browser version, geo location, and other dimensions. You can set alerts on failure counts or slow page
loading. And by inserting trace calls in your JavaScript code, you can track how the different features of
your web page application are used.
Application Insights can be used with any web pages - you just add a short piece of JavaScript. If your web
service is Java or ASP.NET, you can use the server-side SDKs in conjunction with the client-side JavaScript
SDK to get an end-to-end understanding of your app's performance.
Adding the Javascript SDK

1. First you need an Application Insights resource. If you don't already have a resource and
instrumentation key, follow the create a new resource instructions.
2. Copy the instrumentation key from the resource where you want your JavaScript telemetry to be sent.
3. Add the Application Insights JavaScript SDK to your web page or app via one of the following two
options:
NPM Setup
JavaScript Snippet
IMPORTANT
You only need to use one of the methods below for adding the Application Insights JavaScript SDK to your
application. If you use the NPM based setup, don't use the snippet based setup. The same goes for the reverse
scenario when using the snippet based approach, don't also use the NPM based setup.
NPM based setup
import { ApplicationInsights } from '@microsoft/applicationinsights-web'
const appInsights = new ApplicationInsights({ config: {

instrumentationKey: 'YOUR_INSTRUMENTATION_KEY_GOES_HERE'
/* ...Other Configuration Options... */
} });
appInsights.loadAppInsights();
Snippet based setup

If your app does not use NPM, you can directly instrument your webpages with Application Insights by
pasting this snippet at the top of each your pages. Preferably, it should be the first script in your <head>
section so that it can monitor any potential issues with all of your dependencies.
n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.getEl
ementsByTagName("script")[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e){}t.queue=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("t
rack"+r.pop());n("startTrackPage"),n("stopTrackPage");var
s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedUserCo
ntext"),n("flush"),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0
===e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var
o=a[r];a[r]=function(e,n,i,a,s){var c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]
{
}
</script>
Sending telemetry to the Azure portal

By default the Application Insights JavaScript SDK autocollects a number of telemetry items that are
helpful in determining the health of your application and the underlying user experience. These include:
Uncaught exceptions in your app, including information on
Stack trace
Exception details and message accompanying the error
Line & column number of error
URL where error was raised
Network Dependency Requests made by your app XHR and Fetch (fetch collection is disabled by
default) requests, include information on
Url of dependency source
Command & Method used to request the dependency
Duration of the request
Result code and success status of the request
ID (if any) of user making the request
Correlation context (if any) where request is made
User information (for example, Location, network, IP )
Device information (for example, Browser, OS, version, language, resolution, model)
Session information
Telemetry initializers
Telemetry initializers are used to modify the contents of collected telemetry before being sent from the
user's browser. They can also be used to prevent certain telemetry from being sent, by returning false .
Multiple telemetry initializers can be added to your Application Insights instance, and they are executed in
order of adding them.
The input argument to addTelemetryInitializer is a callback that takes a ITelemetryItem as an argument
and returns a boolean or void . If returning false , the telemetry item is not sent, else it proceeds to the
next telemetry initializer, if any, or is sent to the telemetry collection endpoint.
An example of using telemetry initializers:
var telemetryInitializer = (envelope) => {
envelope.data.someField = 'This item passed through my telemetry initializer';
};
appInsights.addTelemetryInitializer(telemetryInitializer);
appInsights.trackTrace({message: 'This message will use a telemetry initializer'});
appInsights.addTelemetryInitializer(() => false); // Nothing is sent after this is executed

appInsights.trackTrace({message: 'this message will not be sent'}); // Not sent
Configuration
Most configuration fields are named such that they can be defaulted to false. All fields are optional except
for instrumentationKey .
NAME DEFAULT DESCRIPTION
instrumentationKey null Required

Instrumentation key that you
obtained from the Azure portal.
accountId null An optional account ID, if your app

groups users into accounts. No
spaces, commas, semicolons, equals,
or vertical bars
sessionRenewalMs 1800000 A session is logged if the user is

inactive for this amount of time in
milliseconds. Default is 30 minutes
sessionExpirationMs 86400000 A session is logged if it has

continued for this amount of time in
milliseconds. Default is 24 hours
maxBatchSizeInBytes 10000 Max size of telemetry batch. If a

batch exceeds this limit, it is
immediately sent and a new batch is
started
maxBatchInterval 15000 How long to batch telemetry for

before sending (milliseconds)
disableExceptionTracking false If true, exceptions are no

autocollected. Default is false.
disableTelemetry false If true, telemetry is not collected or

sent. Default is false.
enableDebug false If true, internal debugging data is

thrown as an exception instead of
being logged, regardless of SDK
logging settings. Default is false.
Note: Enabling this setting will result
in dropped telemetry whenever an
internal error occurs. This can be
useful for quickly identifying issues
with your configuration or usage of
the SDK. If you do not want to lose
telemetry while debugging, consider
using consoleLoggingLevel or
telemetryLoggingLevel instead of
enableDebug .
loggingLevelConsole 0 Logs internal Application Insights

errors to console.
0: off,
1: Critical errors only,
2: Everything (errors & warnings)
loggingLevelTelemetry 1 Sends internal Application Insights

errors as telemetry.
0: off,
1: Critical errors only,
2: Everything (errors & warnings)
diagnosticLogInterval 10000 (internal) Polling interval (in ms) for

internal logging queue
samplingPercentage 100 Percentage of events that will be

sent. Default is 100, meaning all
events are sent. Set this if you wish
to preserve your data cap for large-
scale applications.
autoTrackPageVisitTime false If true, on a pageview, the previous

instrumented page's view time is
tracked and sent as telemetry and a
new timer is started for the current
pageview. Default is false.
disableAjaxTracking false If true, Ajax calls are not

autocollected. Default is false.
disableFetchTracking true If true, Fetch requests are not

autocollected. Default is true
overridePageViewDuration false If true, default behavior of

trackPageView is changed to record
end of page view duration interval
when trackPageView is called. If false
and no custom duration is provided
to trackPageView, the page view
performance is calculated using the
navigation timing API. Default is
false.
maxAjaxCallsPerView 500 Default 500 - controls how many

Ajax calls will be monitored per page
view. Set to -1 to monitor all
(unlimited) Ajax calls on the page.
disableDataLossAnalysis true If false, internal telemetry sender

buffers will be checked at startup for
items not yet sent.
disableCorrelationHeaders false If false, the SDK will add two headers

('Request-Id' and 'Request-Context')
to all dependency requests to
correlate them with corresponding
requests on the server side. Default
is false.
correlationHeaderExcludedDomains Disable correlation headers for

specific domains
correlationHeaderDomains Enable correlation headers for

specific domains
disableFlushOnBeforeUnload false Default false. If true, flush method

will not be called when
onBeforeUnload event triggers
enableSessionStorageBuffer true Default true. If true, the buffer with

all unsent telemetry is stored in
session storage. The buffer is
restored on page load
isCookieUseDisabled false Default false. If true, the SDK will not

store or read any data from cookies.
cookieDomain null Custom cookie domain. This is

helpful if you want to share
Application Insights cookies across
subdomains.
isRetryDisabled false Default false. If false, retry on 206

(partial success), 408 (timeout), 429
(too many requests), 500 (internal
server error), 503 (service
unavailable), and 0 (offline, only if
detected)
isStorageUseDisabled false If true, the SDK will not store or read

any data from local and session
storage. Default is false.
isBeaconApiDisabled true If false, the SDK will send all

telemetry using the Beacon API
onunloadDisableBeacon false Default false. when tab is closed, the

SDK will send all remaining telemetry
using the Beacon API
sdkExtension null Sets the sdk extension name. Only

alphabetic characters are allowed.
The extension name is added as a
prefix to the 'ai.internal.sdkVersion'
tag (for example,
'ext_javascript:2.0.0'). Default is null.
isBrowserLinkTrackingEnabled false Default is false. If true, the SDK will

track all Browser Link requests.
appId null AppId is used for the correlation

between AJAX dependencies
happening on the client-side with
the server-side requests. When
Beacon API is enabled, it cannot be
used automatically, but can be set
manually in the configuration.
Default is null
enableCorsCorrelation false If true, the SDK will add two headers

('Request-Id' and 'Request-Context')
to all CORS requests to correlate
outgoing AJAX dependencies with
corresponding requests on the
server side. Default is false
namePrefix undefined An optional value that will be used as

name postfix for localStorage and
cookie name.
enableAutoRouteTracking false Automatically track route changes in

Single Page Applications (SPA). If
true, each route change will send a
new Pageview to Application
Insights. Hash route changes (
example.com/foo#bar ) are also
recorded as new page views.
enableRequestHeaderTracking false If true, AJAX & Fetch request

headers is tracked, default is false.
enableResponseHeaderTracking false If true, AJAX & Fetch request's

response headers is tracked, default
is false.
distributedTracingMode DistributedTracingModes.AI Sets the distributed tracing mode. If

AI_AND_W3C mode or W3C mode is
set, W3C trace context headers
(traceparent/tracestate) will be
generated and included in all
outgoing requests. AI_AND_W3C is
provided for back-compatibility with
any legacy Application Insights
instrumented services.
Single Page Applications

By default, this SDK will not handle state-based route changing that occurs in single page applications. To
enable automatic route change tracking for your single page application, you can add
enableAutoRouteTracking: true to your setup configuration.
Currently, we offer a separate React plugin which you can initialize with this SDK. It will also accomplish
route change tracking for you, as well as collect other React specific telemetry.
React extensions
EX TENSIONS
React
React Native
Explore browser/client-side data

Browser/client-side data can be viewed by going to Metrics and adding individual metrics you are
interested in:
You can also view your data from the JavaScript SDK via the Browser experience in the portal.
Select Browser and then choose Failures or Performance.
Performance
Dependencies
Analytics
To query your telemetry collected by the JavaScript SDK, select the View in Logs (Analytics) button. By
adding a where statement of client_Type == "Browser" , you will only see data from the JavaScript SDK
and any server-side telemetry collected by other SDKs will be excluded.
// average pageView duration by name

let timeGrain=5m;
let dataset=pageViews
// additional filters can be applied here
| where client_Type == "Browser" ;
// calculate average pageView duration for all pageViews
dataset
| summarize avg(duration) by bin(timestamp, timeGrain)
| extend pageView='Overall'
// render result in a chart
| render timechart
Source Map Support

The minified callstack of your exception telemetry can be unminified in the Azure portal. All existing
integrations on the Exception Details panel will work with the newly unminified callstack. Drag and drop
source map unminifying supports all existing and future JS SDKs (+Node.JS ), so you do not need to
upgrade your SDK version. To view your unminified callstack,
1. Select an Exception Telemetry item in the Azure portal to view its "End-to-end transaction details"
2. Identify which source maps correspond to this call stack. The source map must match a stack frame's
source file, but suffixed with .map
3. Drag and drop the source maps onto the call stack in the Azure portal
Application Insights Web Basic
For a lightweight experience, you can instead install the basic version of Application Insights
npm i --save @microsoft/applicationinsights-web-basic
This version comes with the bare minimum number of features and functionalities and relies on you to
build it up as you see fit. For example, it performs no autocollection (uncaught exceptions, AJAX, etc.). The
APIs to send certain telemetry types, like trackTrace , trackException , etc., are not included in this version,
so you will need to provide your own wrapper. The only API that is available is track . A sample is located
here.
Examples
For runnable examples, see Application Insights Javascript SDK Samples
Upgrading from the old Version of Application Insights

Breaking changes in the SDK V2 version:
To allow for better API signatures, some of the API calls such as trackPageView, trackException have
been updated. Running in IE8 or lower versions of the browser is not supported.
Telemetry envelope has field name and structure changes due to data schema updates.
Moved context.operation to context.telemetryTrace . Some fields were also changed ( operation.id --
> telemetryTrace.traceID )
If you want to manually refresh the current pageview ID (for example, in SPA apps) this can be
done with appInsights.properties.context.telemetryTrace.traceID = Util.newId()
If you're using the current application insights PRODUCTION SDK (1.0.20) and want to see if the new SDK
works in runtime, update the URL depending on your current SDK loading scenario.
Download via CDN scenario: Update the code snippet that you currently use to point to the
following URL:
"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js"
NPM scenario: Call downloadAndSetup to download the full ApplicationInsights script from CDN and
initialize it with instrumentation key:
appInsights.downloadAndSetup({
instrumentationKey: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
url: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js"
});
Test in internal environment to verify monitoring telemetry is working as expected. If all works, update
your API signatures appropriately to SDK V2 version and deploy in your production environments.
SDK performance/overhead
At just 25 KB gzipped, and taking only ~15 ms to initialize, Application Insights adds a negligible amount
of loadtime to your website. By using the snippet, minimal components of the library are quickly loaded. In
the meantime, the full script is downloaded in the background.
While the script is downloading from the CDN, all tracking of your page is queued. Once the downloaded
script finishes asynchronously initializing, all events that were queued are tracked. As a result, you will not
lose any telemetry during the entire life cycle of your page. This setup process provides your page with a
seamless analytics system, invisible to your users.
Summary:
25 KB gzipped
15 ms overall initialization time
Zero tracking missed during life cycle of page
Browser support
Latest ✔ Latest ✔ 9+ ✔ Latest ✔ Latest ✔
Open-source SDK
The Application Insights JavaScript SDK is open-source to view the source code or to contribute to the
project visit the official GitHub repository.
Next steps
Track usage
Custom events and metrics
Build-measure-learn
Application Insights API for custom events and
metrics
Insert a few lines of code in your application to find out what users are doing with it, or to help diagnose
issues. You can send telemetry from device and desktop apps, web clients, and web servers. Use the Azure
Application Insights core telemetry API to send custom events and metrics, and your own versions of
standard telemetry. This API is the same API that the standard Application Insights data collectors use.
API summary
The core API is uniform across all platforms, apart from a few variations like GetMetric (.NET only).
METHOD USED FOR
TrackPageView Pages, screens, blades, or forms.
TrackEvent User actions and other events. Used to track user

behavior or to monitor performance.
GetMetric Zero and multi-dimensional metrics, centrally configured

aggregation, C# only.
TrackMetric Performance measurements such as queue lengths not

related to specific events.
TrackException Logging exceptions for diagnosis. Trace where they occur

in relation to other events and examine stack traces.
TrackRequest Logging the frequency and duration of server requests

for performance analysis.
TrackTrace Diagnostic log messages. You can also capture third-

party logs.
TrackDependency Logging the duration and frequency of calls to external

components that your app depends on.
You can attach properties and metrics to most of these telemetry calls.
Before you start

If you don't have a reference on Application Insights SDK yet:
Add the Application Insights SDK to your project:
ASP.NET project
ASP.NET Core project
Java project
Node.js project
JavaScript in each webpage
In your device or web server code, include:
C#: using Microsoft.ApplicationInsights;
Visual Basic: Imports Microsoft.ApplicationInsights
Java: import com.microsoft.applicationinsights.TelemetryClient;
Node.js: var applicationInsights = require("applicationinsights");
Get a TelemetryClient instance

Get an instance of TelemetryClient (except in JavaScript in webpages):
For ASP.NET Core apps and Non HTTP/Worker for .NET/.NET Core apps, it is recommended to get an
instance of TelemetryClient from the dependency injection container as explained in their respective
documentation.
C#
private TelemetryClient telemetry = new TelemetryClient();
Visual Basic
Private Dim telemetry As New TelemetryClient
Java
private TelemetryClient telemetry = new TelemetryClient();
Node.js
var telemetry = applicationInsights.defaultClient;
TelemetryClient is thread-safe.
For ASP.NET and Java projects, incoming HTTP Requests are automatically captured. You might want to
create additional instances of TelemetryClient for other module of your app. For instance, you may have
one TelemetryClient instance in your middleware class to report business logic events. You can set
properties such as UserId and DeviceId to identify the machine. This information is attached to all events
that the instance sends.
C#
TelemetryClient.Context.User.Id = "...";
TelemetryClient.Context.Device.Id = "...";
Java
telemetry.getContext().getUser().setId("...");
telemetry.getContext().getDevice().setId("...");
In Node.js projects, you can use new applicationInsights.TelemetryClient(instrumentationKey?) to create a
new instance, but this is recommended only for scenarios that require isolated configuration from the
singleton defaultClient .
TrackEvent
In Application Insights, a custom event is a data point that you can display in Metrics Explorer as an
aggregated count, and in Diagnostic Search as individual occurrences. (It isn't related to MVC or other
framework "events.")
Insert TrackEvent calls in your code to count various events. How often users choose a particular feature,
how often they achieve particular goals, or maybe how often they make particular types of mistakes.
For example, in a game app, send an event whenever a user wins the game:
JavaScript
appInsights.trackEvent("WinGame");
C#
telemetry.TrackEvent("WinGame");
Visual Basic
telemetry.TrackEvent("WinGame")
Java
telemetry.trackEvent("WinGame");
Node.js
telemetry.trackEvent({name: "WinGame"});
Custom events in Analytics

The telemetry is available in the customEvents table in Application Insights Analytics. Each row represents
a call to trackEvent(..) in your app.
If sampling is in operation, the itemCount property shows a value greater than 1. For example
itemCount==10 means that of 10 calls to trackEvent(), the sampling process only transmitted one of
them. To get a correct count of custom events, you should therefore use code such as
customEvents | summarize sum(itemCount) .
GetMetric
Examples
C#
namespace User.Namespace.Example01
{
using System;
/// <summary>
/// Most simple cases are one-liners.
/// This is all possible without even importing an additional namespace.
/// </summary>
public class Sample01

{
/// <summary />
public static void Exec()
{
// *** SENDING METRICS ***
// Recall how you send custom telemetry with Application Insights in other cases, e.g.
Events.
// The following will result in an EventTelemetry object to be sent to the cloud right
away.
TelemetryClient client = new TelemetryClient();
client.TrackEvent("SomethingInterestingHappened");
// Metrics work very similar. However, the value is not sent right away.
// It is aggregated with other values for the same metric, and the resulting summary (aka
"aggregate" is sent automatically every minute.
// To mark this difference, we use a pattern that is similar, but different from the
established TrackXxx(..) pattern that sends telemetry right away:
client.GetMetric("CowsSold").TrackValue(42);
// *** MULTI-DIMENSIONAL METRICS ***
// The above example shows a zero-dimensional metric.

// Metrics can also be multi-dimensional.
// In the initial version we are supporting up to 2 dimensions, and we will add support
for more in the future as needed.
// Here is an example for a one-dimensional metric:
Metric animalsSold = client.GetMetric("AnimalsSold", "Species");
animalsSold.TrackValue(42, "Pigs");
animalsSold.TrackValue(24, "Horses");
// The values for Pigs and Horses will be aggregated separately from each other and will
result in two distinct aggregates.
// You can control the maximum number of number data series per metric (and thus your
resource usage and cost).
// The default limits are no more than 1000 total data series per metric, and no more than
100 different values per dimension.
// We discuss elsewhere how to change them.
// We use a common .NET pattern: TryXxx(..) to make sure that the limits are observed.
// If the limits are already reached, Metric.TrackValue(..) will return False and the
value will not be tracked. Otherwise it will return True.
// This is particularly useful if the data for a metric originates from user input, e.g. a
file:
Tuple<int, string> countAndSpecies = ReadSpeciesFromUserInput();

int count = countAndSpecies.Item1;
string species = countAndSpecies.Item2;
if (!animalsSold.TrackValue(count, species))
{
client.TrackTrace($"Data series or dimension cap was reached for metric
{animalsSold.Identifier.MetricId}.", SeverityLevel.Error);
}
// You can inspect a metric object to reason about its current state. For example:
int currentNumberOfSpecies = animalsSold.GetDimensionValues(1).Count;
}
private static void ResetDataStructure()

{
// Do stuff
}
private static Tuple<int, string> ReadSpeciesFromUserInput()

{
return Tuple.Create(18, "Cows");
}
private static int AddItemsToDataStructure()

{
// Do stuff
return 5;
}
}
}
TrackMetric
NOTE
Microsoft.ApplicationInsights.TelemetryClient.TrackMetric is not the preferred method for sending metrics. Metrics
should always be pre-aggregated across a time period before being sent. Use one of the GetMetric(..) overloads to
get a metric object for accessing SDK pre-aggregation capabilities. If you are implementing your own pre-
aggregation logic, you can use the TrackMetric() method to send the resulting aggregates. If your application
requires sending a separate telemetry item at every occasion without aggregation across time, you likely have a
use case for event telemetry; see TelemetryClient.TrackEvent
(Microsoft.ApplicationInsights.DataContracts.EventTelemetry).
Application Insights can chart metrics that are not attached to particular events. For example, you could
monitor a queue length at regular intervals. With metrics, the individual measurements are of less interest
than the variations and trends, and so statistical charts are useful.
In order to send metrics to Application Insights, you can use the TrackMetric(..) API. There are two ways
to send a metric:
Single value. Every time you perform a measurement in your application, you send the
corresponding value to Application Insights. For example, assume that you have a metric
describing the number of items in a container. During a particular time period, you first put three
items into the container and then you remove two items. Accordingly, you would call TrackMetric
twice: first passing the value 3 and then the value -2 . Application Insights stores both values on
your behalf.
Aggregation. When working with metrics, every single measurement is rarely of interest. Instead a
summary of what happened during a particular time period is important. Such a summary is called
aggregation. In the above example, the aggregate metric sum for that time period is 1 and the
count of the metric values is 2 . When using the aggregation approach, you only invoke
TrackMetric once per time period and send the aggregate values. This is the recommended
approach since it can significantly reduce the cost and performance overhead by sending fewer
data points to Application Insights, while still collecting all relevant information.
Examples
Single values
To send a single metric value:
JavaScript
appInsights.trackMetric("queueLength", 42.0);
C#
var sample = new MetricTelemetry();

sample.Name = "metric name";
sample.Value = 42.3;
telemetryClient.TrackMetric(sample);
Java
telemetry.trackMetric("queueLength", 42.0);
Node.js
telemetry.trackMetric({name: "queueLength", value: 42.0});
Custom metrics in Analytics

The telemetry is available in the customMetrics table in Application Insights Analytics. Each row
represents a call to trackMetric(..) in your app.
valueSum - This is the sum of the measurements. To get the mean value, divide by valueCount .
valueCount - The number of measurements that were aggregated into this trackMetric(..) call.
Page views
In a device or webpage app, page view telemetry is sent by default when each screen or page is loaded.
But you can change that to track page views at additional or different times. For example, in an app that
displays tabs or blades, you might want to track a page whenever the user opens a new blade.
User and session data is sent as properties along with page views, so the user and session charts come
alive when there is page view telemetry.
Custom page views
JavaScript
appInsights.trackPageView("tab1");
C#
telemetry.TrackPageView("GameReviewPage");
Visual Basic
telemetry.TrackPageView("GameReviewPage")
Java
telemetry.trackPageView("GameReviewPage");
If you have several tabs within different HTML pages, you can specify the URL too:
appInsights.trackPageView("tab1", "http://fabrikam.com/page1.htm");
Timing page views

By default, the times reported as Page view load time are measured from when the browser sends the
request, until the browser's page load event is called.
Instead, you can either:
Set an explicit duration in the trackPageView call:
appInsights.trackPageView("tab1", null, null, null, durationInMilliseconds); .
Use the page view timing calls startTrackPage and stopTrackPage .
JavaScript
// To start timing a page:

appInsights.startTrackPage("Page1");
...
// To stop timing and log the page:

appInsights.stopTrackPage("Page1", url, properties, measurements);
The name that you use as the first parameter associates the start and stop calls. It defaults to the current
page name.
The resulting page load durations displayed in Metrics Explorer are derived from the interval between the
start and stop calls. It's up to you what interval you actually time.
Page telemetry in Analytics
In Analytics two tables show data from browser operations:
The pageViews table contains data about the URL and page title
The browserTimings table contains data about client performance, such as the time taken to process
the incoming data
To find how long the browser takes to process different pages:
browserTimings
| summarize avg(networkDuration), avg(processingDuration), avg(totalDuration) by name
To discover the popularities of different browsers:
pageViews
| summarize count() by client_Browser
To associate page views to AJAX calls, join with dependencies:
pageViews
| join (dependencies) on operation_Id
TrackRequest
The server SDK uses TrackRequest to log HTTP requests.
You can also call it yourself if you want to simulate requests in a context where you don't have the web
service module running.
However, the recommended way to send request telemetry is where the request acts as an operation
context.
Operation context
You can correlate telemetry items together by associating them with operation context. The standard
request-tracking module does this for exceptions and other events that are sent while an HTTP request is
being processed. In Search and Analytics, you can easily find any events associated with the request using
its operation ID.
See Telemetry correlation in Application Insights for more details on correlation.
When tracking telemetry manually, the easiest way to ensure telemetry correlation by using this pattern:
C#
// Establish an operation context and associated telemetry item:

using (var operation = telemetryClient.StartOperation<RequestTelemetry>("operationName"))
{
// Telemetry sent in here will use the same operation ID.
...
telemetryClient.TrackTrace(...); // or other Track* calls
...
// Set properties of containing telemetry item--for example:

operation.Telemetry.ResponseCode = "200";
// Optional: explicitly send telemetry item:

telemetryClient.StopOperation(operation);
} // When operation is disposed, telemetry item is sent.
Along with setting an operation context, StartOperation creates a telemetry item of the type that you
specify. It sends the telemetry item when you dispose the operation, or if you explicitly call StopOperation .
If you use RequestTelemetry as the telemetry type, its duration is set to the timed interval between start
and stop.
Telemetry items reported within a scope of operation become 'children' of such operation. Operation
contexts could be nested.
In Search, the operation context is used to create the Related Items list:
See Track custom operations with Application Insights .NET SDK for more information on custom
operations tracking.
Requests in Analytics
In Application Insights Analytics, requests show up in the requests table.
If sampling is in operation, the itemCount property will show a value greater than 1. For example
itemCount==10 means that of 10 calls to trackRequest(), the sampling process only transmitted one of
them. To get a correct count of requests and average duration segmented by request names, use code
such as:
requests
| summarize count = sum(itemCount), avgduration = avg(duration) by name
TrackException
Send exceptions to Application Insights:
To count them, as an indication of the frequency of a problem.
To examine individual occurrences.
The reports include the stack traces.
C#
try
{
...
}
catch (Exception ex)
{
telemetry.TrackException(ex);
}
Java
try {
...
} catch (Exception ex) {
telemetry.trackException(ex);
}
JavaScript
try
{
...
}
catch (ex)
{
appInsights.trackException(ex);
}
Node.js
try
{
...
}
catch (ex)
{
telemetry.trackException({exception: ex});
}
The SDKs catch many exceptions automatically, so you don't always have to call TrackException explicitly.
ASP.NET: Write code to catch exceptions.
Java EE: Exceptions are caught automatically.
JavaScript: Exceptions are caught automatically. If you want to disable automatic collection, add a line
to the code snippet that you insert in your webpages:
({
instrumentationKey: "your key",
disableExceptionTracking: true
})
Exceptions in Analytics
In Application Insights Analytics, exceptions show up in the exceptions table.
itemCount==10 means that of 10 calls to trackException(), the sampling process only transmitted one of
them. To get a correct count of exceptions segmented by type of exception, use code such as:
exceptions
| summarize sum(itemCount) by type
Most of the important stack information is already extracted into separate variables, but you can pull
apart the details structure to get more. Since this structure is dynamic, you should cast the result to the
type you expect. For example:
exceptions
| extend method2 = tostring(details[0].parsedStack[1].method)
To associate exceptions with their related requests, use a join:
exceptions
| join (requests) on operation_Id
TrackTrace
Use TrackTrace to help diagnose problems by sending a "breadcrumb trail" to Application Insights. You
can send chunks of diagnostic data and inspect them in Diagnostic Search.
In .NET Log adapters use this API to send third-party logs to the portal.
In Java for Standard loggers like Log4J, Logback use Application Insights Log4j or Logback Appenders to
send third-party logs to the portal.
C#
telemetry.TrackTrace(message, SeverityLevel.Warning, properties);
Java
telemetry.trackTrace(message, SeverityLevel.Warning, properties);
Node.js
telemetry.trackTrace({
message: message,
severity: applicationInsights.Contracts.SeverityLevel.Warning,
properties: properties
});
Client/Browser-side JavaScript
trackTrace(message: string, properties?: {[string]:string}, severityLevel?: AI.SeverityLevel)
Log a diagnostic event such as entering or leaving a method.
PARAMETER DESCRIPTION
message Diagnostic data. Can be much longer than a name.
properties Map of string to string: Additional data used to filter

exceptions in the portal. Defaults to empty.
severityLevel Supported values: SeverityLevel.ts
You can search on message content, but (unlike property values) you can't filter on it.
The size limit on message is much higher than the limit on properties. An advantage of TrackTrace is that
you can put relatively long data in the message. For example, you can encode POST data there.
In addition, you can add a severity level to your message. And, like other telemetry, you can add property
values to help you filter or search for different sets of traces. For example:
C#
var telemetry = new Microsoft.ApplicationInsights.TelemetryClient();

telemetry.TrackTrace("Slow database response",
SeverityLevel.Warning,
new Dictionary<string,string> { {"database", db.ID} });
Java
Map<String, Integer> properties = new HashMap<>();

properties.put("Database", db.ID);
telemetry.trackTrace("Slow Database response", SeverityLevel.Warning, properties);
In Search, you can then easily filter out all the messages of a particular severity level that relate to a
particular database.
Traces in Analytics
In Application Insights Analytics, calls to TrackTrace show up in the traces table.
itemCount==10 means that of 10 calls to trackTrace() , the sampling process only transmitted one of
them. To get a correct count of trace calls, you should use therefore code such as
traces | summarize sum(itemCount) .
TrackDependency
Use the TrackDependency call to track the response times and success rates of calls to an external piece of
code. The results appear in the dependency charts in the portal.
C#

var startTime = DateTime.UtcNow;
var timer = System.Diagnostics.Stopwatch.StartNew();
try
{
success = dependency.Call();
}
catch(Exception ex)
{
success = false;
telemetry.TrackException(ex);
throw new Exception("Operation went wrong", ex);
}
finally
{
timer.Stop();
telemetry.TrackDependency("DependencyType", "myDependency", "myCall", startTime, timer.Elapsed,
success);
}
Java
boolean success = false;
long startTime = System.currentTimeMillis();
try {
success = dependency.call();
}
finally {
long endTime = System.currentTimeMillis();
long delta = endTime - startTime;
RemoteDependencyTelemetry dependencyTelemetry = new RemoteDependencyTelemetry("My Dependency",
"myCall", delta, success);
telemetry.setTimeStamp(startTime);
telemetry.trackDependency(dependencyTelemetry);
}
JavaScript

var startTime = new Date().getTime();
try
{
}
finally
{
var elapsed = new Date() - startTime;
telemetry.trackDependency({
dependencyTypeName: "myDependency",
name: "myCall",
duration: elapsed,
success: success
});
}
Remember that the server SDKs include a dependency module that discovers and tracks certain
dependency calls automatically--for example, to databases and REST APIs. You have to install an agent on
your server to make the module work.
In Java, certain dependency calls can be automatically tracked using Java Agent.
You use this call if you want to track calls that the automated tracking doesn't catch, or if you don't want to
install the agent.
To turn off the standard dependency-tracking module in C#, edit ApplicationInsights.config and delete the
reference to DependencyCollector.DependencyTrackingTelemetryModule . In Java, please do not install java
agent if you do not want to collect standard dependencies automatically.
Dependencies in Analytics
In Application Insights Analytics, trackDependency calls show up in the dependencies table.
itemCount==10 means that of 10 calls to trackDependency(), the sampling process only transmitted one
of them. To get a correct count of dependencies segmented by target component, use code such as:
dependencies
| summarize sum(itemCount) by target
To associate dependencies with their related requests, use a join:

dependencies
| join (requests) on operation_Id
Flushing data
Normally, the SDK sends data at fixed intervals (typically 30 secs) or whenever buffer is full (typically 500
items). However, in some cases, you might want to flush the buffer--for example, if you are using the SDK
in an application that shuts down.
C#
telemetry.Flush();
// Allow some time for flushing before shutdown.
System.Threading.Thread.Sleep(5000);
Java
telemetry.flush();
//Allow some time for flushing before shutting down
Thread.sleep(5000);
Node.js
telemetry.flush();
The function is asynchronous for the server telemetry channel.

Ideally, flush() method should be used in the shutdown activity of the Application.
Authenticated users
In a web app, users are (by default) identified by cookies. A user might be counted more than once if they
access your app from a different machine or browser, or if they delete cookies.
If users sign in to your app, you can get a more accurate count by setting the authenticated user ID in the
browser code:
JavaScript
// Called when my app has identified the user.

function Authenticated(signInId) {
var validatedId = signInId.replace(/[,;=| ]+/g, "_");
appInsights.setAuthenticatedUserContext(validatedId);
...
}
In an ASP.NET web MVC application, for example:

Razor
@if (Request.IsAuthenticated)
{
<script>
appInsights.setAuthenticatedUserContext("@User.Identity.Name
.Replace("\\", "\\\\")"
.replace(/[,;=| ]+/g, "_"));
</script>
}
It isn't necessary to use the user's actual sign-in name. It only has to be an ID that is unique to that user. It
must not include spaces or any of the characters ,;=| .
The user ID is also set in a session cookie and sent to the server. If the server SDK is installed, the
authenticated user ID is sent as part of the context properties of both client and server telemetry. You can
then filter and search on it.
If your app groups users into accounts, you can also pass an identifier for the account (with the same
character restrictions).
appInsights.setAuthenticatedUserContext(validatedId, accountId);
In Metrics Explorer, you can create a chart that counts Users, Authenticated, and User accounts.
You can also search for client data points with specific user names and accounts.
Filtering, searching, and segmenting your data by using

properties
You can attach properties and measurements to your events (and also to metrics, page views, exceptions,
and other telemetry data).
Properties are string values that you can use to filter your telemetry in the usage reports. For example, if
your app provides several games, you can attach the name of the game to each event so that you can see
which games are more popular.
There's a limit of 8192 on the string length. (If you want to send large chunks of data, use the message
parameter of TrackTrace.)
Metrics are numeric values that can be presented graphically. For example, you might want to see if there's
a gradual increase in the scores that your gamers achieve. The graphs can be segmented by the properties
that are sent with the event, so that you can get separate or stacked graphs for different games.
For metric values to be correctly displayed, they should be greater than or equal to 0.
There are some limits on the number of properties, property values, and metrics that you can use.
JavaScript
appInsights.trackEvent
("WinGame",
// String properties:
{Game: currentGame.name, Difficulty: currentGame.difficulty},
// Numeric metrics:
{Score: currentGame.score, Opponents: currentGame.opponentCount}
);
appInsights.trackPageView
("page name", "http://fabrikam.com/pageurl.html",
// String properties:
{Game: currentGame.name, Difficulty: currentGame.difficulty},
// Numeric metrics:
{Score: currentGame.score, Opponents: currentGame.opponentCount}
);
C#
// Set up some properties and metrics:

var properties = new Dictionary <string, string>
{{"game", currentGame.Name}, {"difficulty", currentGame.Difficulty}};
var metrics = new Dictionary <string, double>
{{"Score", currentGame.Score}, {"Opponents", currentGame.OpponentCount}};
// Send the event:

telemetry.TrackEvent("WinGame", properties, metrics);
Node.js
// Set up some properties and metrics:

var properties = {"game": currentGame.Name, "difficulty": currentGame.Difficulty};
var metrics = {"Score": currentGame.Score, "Opponents": currentGame.OpponentCount};
// Send the event:

telemetry.trackEvent({name: "WinGame", properties: properties, measurements: metrics});
Visual Basic
' Set up some properties:

Dim properties = New Dictionary (Of String, String)
properties.Add("game", currentGame.Name)
properties.Add("difficulty", currentGame.Difficulty)
Dim metrics = New Dictionary (Of String, Double)

metrics.Add("Score", currentGame.Score)
metrics.Add("Opponents", currentGame.OpponentCount)
' Send the event:

telemetry.TrackEvent("WinGame", properties, metrics)
Java
Map<String, String> properties = new HashMap<String, String>();
properties.put("game", currentGame.getName());
properties.put("difficulty", currentGame.getDifficulty());
Map<String, Double> metrics = new HashMap<String, Double>();

metrics.put("Score", currentGame.getScore());
metrics.put("Opponents", currentGame.getOpponentCount());
telemetry.trackEvent("WinGame", properties, metrics);
NOTE
Take care not to log personally identifiable information in properties.
Alternative way to set properties and metrics

If it's more convenient, you can collect the parameters of an event in a separate object:
var event = new EventTelemetry();
event.Name = "WinGame";
event.Metrics["processingTime"] = stopwatch.Elapsed.TotalMilliseconds;
event.Properties["game"] = currentGame.Name;
event.Properties["difficulty"] = currentGame.Difficulty;
event.Metrics["Score"] = currentGame.Score;
event.Metrics["Opponents"] = currentGame.Opponents.Length;
telemetry.TrackEvent(event);
WARNING
Don't reuse the same telemetry item instance ( event in this example) to call Track*() multiple times. This may
cause telemetry to be sent with incorrect configuration.
Custom measurements and properties in Analytics

In Analytics, custom metrics and properties show in the customMeasurements and customDimensions
attributes of each telemetry record.
For example, if you have added a property named "game" to your request telemetry, this query counts the
occurrences of different values of "game", and show the average of the custom metric "score":
requests
| summarize sum(itemCount), avg(todouble(customMeasurements.score)) by tostring(customDimensions.game)
Notice that:
When you extract a value from the customDimensions or customMeasurements JSON, it has dynamic
type, and so you must cast it tostring or todouble .
To take account of the possibility of sampling, you should use sum(itemCount) , not count() .
Timing events
Sometimes you want to chart how long it takes to perform an action. For example, you might want to
know how long users take to consider choices in a game. You can use the measurement parameter for
this.
C#
var stopwatch = System.Diagnostics.Stopwatch.StartNew();
// ... perform the timed action ...
stopwatch.Stop();
var metrics = new Dictionary <string, double>

{{"processingTime", stopwatch.Elapsed.TotalMilliseconds}};
// Set up some properties:

{{"signalSource", currentSignalSource.Name}};
// Send the event:

telemetry.TrackEvent("SignalProcessed", properties, metrics);
Java
long startTime = System.currentTimeMillis();
// Perform timed action
long endTime = System.currentTimeMillis();

Map<String, Double> metrics = new HashMap<>();
metrics.put("ProcessingTime", (double)endTime-startTime);
// Setup some properties

Map<String, String> properties = new HashMap<>();
properties.put("signalSource", currentSignalSource.getName());
// Send the event

telemetry.trackEvent("SignalProcessed", properties, metrics);
Default properties for custom telemetry

If you want to set default property values for some of the custom events that you write, you can set them
in a TelemetryClient instance. They are attached to every telemetry item that's sent from that client.
C#
var gameTelemetry = new TelemetryClient();

gameTelemetry.Context.GlobalProperties["Game"] = currentGame.Name;
// Now all telemetry will automatically be sent with the context property:
gameTelemetry.TrackEvent("WinGame");
Visual Basic
Dim gameTelemetry = New TelemetryClient()

gameTelemetry.Context.GlobalProperties("Game") = currentGame.Name
' Now all telemetry will automatically be sent with the context property:
gameTelemetry.TrackEvent("WinGame")
Java
import com.microsoft.applicationinsights.TelemetryClient;
import com.microsoft.applicationinsights.TelemetryContext;
...
TelemetryClient gameTelemetry = new TelemetryClient();

TelemetryContext context = gameTelemetry.getContext();
context.getProperties().put("Game", currentGame.Name);
gameTelemetry.TrackEvent("WinGame");
Node.js
var gameTelemetry = new applicationInsights.TelemetryClient();

gameTelemetry.commonProperties["Game"] = currentGame.Name;
gameTelemetry.TrackEvent({name: "WinGame"});
Individual telemetry calls can override the default values in their property dictionaries.
For JavaScript web clients, use JavaScript telemetry initializers.
To add properties to all telemetry, including the data from standard collection modules, implement
ITelemetryInitializer .
Sampling, filtering, and processing telemetry

You can write code to process your telemetry before it's sent from the SDK. The processing includes data
that's sent from the standard telemetry modules, such as HTTP request collection and dependency
collection.
Add properties to telemetry by implementing ITelemetryInitializer . For example, you can add version
numbers or values that are calculated from other properties.
Filtering can modify or discard telemetry before it's sent from the SDK by implementing
ITelemetryProcessor . You control what is sent or discarded, but you have to account for the effect on your
metrics. Depending on how you discard items, you might lose the ability to navigate between related
items.
Sampling is a packaged solution to reduce the volume of data that's sent from your app to the portal. It
does so without affecting the displayed metrics. And it does so without affecting your ability to diagnose
problems by navigating between related items such as exceptions, requests, and page views.
Learn more.
Disabling telemetry
To dynamically stop and start the collection and transmission of telemetry:
C#
TelemetryConfiguration.Active.DisableTelemetry = true;
Java
telemetry.getConfiguration().setTrackingDisabled(true);
To disable selected standard collectors--for example, performance counters, HTTP requests, or

dependencies--delete or comment out the relevant lines in ApplicationInsights.config. You can do this, for
example, if you want to send your own TrackRequest data.
Node.js
telemetry.config.disableAppInsights = true;
To disable selected standard collectors--for example, performance counters, HTTP requests, or

dependencies--at initialization time, chain configuration methods to your SDK initialization code:
applicationInsights.setup()
.setAutoCollectRequests(false)
.setAutoCollectPerformance(false)
.setAutoCollectExceptions(false)
.setAutoCollectDependencies(false)
.setAutoCollectConsole(false)
.start();
To disable these collectors after initialization, use the Configuration object:

applicationInsights.Configuration.setAutoCollectRequests(false)
Developer mode
During debugging, it's useful to have your telemetry expedited through the pipeline so that you can see
results immediately. You also get additional messages that help you trace any problems with the
telemetry. Switch it off in production, because it may slow down your app.
C#
TelemetryConfiguration.Active.TelemetryChannel.DeveloperMode = true;
Visual Basic
TelemetryConfiguration.Active.TelemetryChannel.DeveloperMode = True
Node.js
For Node.js, you can enable developer mode by enabling internal logging via setInternalLogging and
setting maxBatchSize to 0, which causes your telemetry to be sent as soon as it is collected.
applicationInsights.setup("ikey")
.setInternalLogging(true, true)
.start()
applicationInsights.defaultClient.config.maxBatchSize = 0;
Setting the instrumentation key for selected custom telemetry

C#
var telemetry = new TelemetryClient();
telemetry.InstrumentationKey = "---my key---";
// ...
Dynamic instrumentation key

To avoid mixing up telemetry from development, test, and production environments, you can create
separate Application Insights resources and change their keys, depending on the environment.
Instead of getting the instrumentation key from the configuration file, you can set it in your code. Set the
key in an initialization method, such as global.aspx.cs in an ASP.NET service:
C#
protected void Application_Start()

{
Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey =
// - for example -
WebConfigurationManager.Settings["ikey"];
...
}
JavaScript
appInsights.config.instrumentationKey = myKey;
In webpages, you might want to set it from the web server's state, rather than coding it literally into the
script. For example, in a webpage generated in an ASP.NET app:
JavaScript in Razor
// Standard Application Insights webpage script:
var appInsights = window.appInsights || function(config){ ...
// Modify this part:
}({instrumentationKey:
// Generate from server property:
@Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey;
}) // ...
String instrumentationKey = "00000000-0000-0000-0000-000000000000";
if (instrumentationKey != null)
{
TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
}
TelemetryContext
TelemetryClient has a Context property, which contains values that are sent along with all telemetry data.
They are normally set by the standard telemetry modules, but you can also set them yourself. For
example:
telemetry.Context.Operation.Name = "MyOperationName";
If you set any of these values yourself, consider removing the relevant line from
ApplicationInsights.config, so that your values and the standard values don't get confused.
Component: The app and its version.
Device: Data about the device where the app is running. (In web apps, this is the server or client
device that the telemetry is sent from.)
InstrumentationKey: The Application Insights resource in Azure where the telemetry appears. It's
usually picked up from ApplicationInsights.config.
Location: The geographic location of the device.
Operation: In web apps, the current HTTP request. In other app types, you can set this to group events
together.
ID: A generated value that correlates different events, so that when you inspect any event in
Diagnostic Search, you can find related items.
Name: An identifier, usually the URL of the HTTP request.
SyntheticSource: If not null or empty, a string that indicates that the source of the request has
been identified as a robot or web test. By default, it is excluded from calculations in Metrics
Explorer.
Properties: Properties that are sent with all telemetry data. It can be overridden in individual Track*
calls.
Session: The user's session. The ID is set to a generated value, which is changed when the user has not
been active for a while.
User: User information.
Limits
There are some limits on the number of metrics and events per application, that is, per instrumentation
key. Limits depend on the pricing plan that you choose.
Total data per day 100 GB You can reduce data by setting a
cap. If you need more data, you can
increase the limit in the portal, up to
1,000 GB. For capacities greater
than 1,000 GB, send email to
Data retention 30 - 730 days This resource is for Search, Analytics,

Availability multi-step test detailed 90 days This resource provides detailed

results retention results of each step.
Maximum telemetry item size 64 kB
Maximum telemetry items per batch 64 K

To avoid hitting the data rate limit, use sampling.
To determine how long data is kept, see Data retention and privacy.
Reference docs
ASP.NET reference
Java reference
JavaScript reference
SDK code
ASP.NET Core SDK
ASP.NET
Windows Server packages
Java SDK
Node.js SDK
JavaScript SDK
Questions
What exceptions might Track_ () calls throw?
None. You don't need to wrap them in try-catch clauses. If the SDK encounters problems, it will log
messages in the debug console output and--if the messages get through--in Diagnostic Search.
Is there a REST API to get data from the portal?
Yes, the data access API. Other ways to extract data include export from Analytics to Power BI and
continuous export.
Next steps
Search events and logs
Troubleshooting
Troubleshooting no data - Application Insights for
.NET
Some of my telemetry is missing

In Application Insights, I only see a fraction of the events that are being generated by my app.
If you are consistently seeing the same fraction, it's probably due to adaptive sampling. To confirm this, open
Search (from the overview blade) and look at an instance of a Request or other event. At the bottom of the
properties section click "..." to get full property details. If Request Count > 1, then sampling is in operation.
Otherwise, it's possible that you're hitting a data rate limit for your pricing plan. These limits are applied per
minute.
I'm experiencing data loss randomly.
Check if you are experiencing data loss at Telemetry Channel
Check for any known issues in Telemetry Channel GitHub repo
I'm experiencing data loss in Console App or on Web App when app is about to stop.
SDK channel keeps telemetry in buffer, and sends them in batches. If the application is shutting down, you may
need to explicitly call Flush(). Behavior of Flush() depends on the actual channel used.
No data from my server

I installed my app on my web server, and now I don't see any telemetry from it. It worked OK on my dev machine.
Probably a firewall issue. Set firewall exceptions for Application Insights to send data.
IIS Server might be missing some prerequisites: .NET Extensibility 4.5, and ASP.NET 4.5.
I installed Status Monitor on my web server to monitor existing apps. I don't see any results.
See Troubleshooting Status Monitor.
No 'Add Application Insights' option in Visual Studio

When I right-click an existing project in Solution Explorer, I don't see any Application Insights options.
Not all types of .NET project are supported by the tools. Web and WCF projects are supported. For other
project types such as desktop or service applications, you can still add an Application Insights SDK to your
project manually.
Make sure you have Visual Studio 2013 Update 3 or later. It comes pre-installed with Developer Analytics
tools, which provide the Application Insights SDK.
Select Tools, Extensions and Updates and check that Developer Analytics Tools is installed and enabled. If
so, click Updates to see if there's an update available.
Open the New Project dialog and choose ASP.NET Web application. If you see the Application Insights option
there, then the tools are installed. If not, try uninstalling and then re-installing the Developer Analytics Tools.
Adding Application Insights failed

When I try to add Application Insights to an existing project, I see an error message.
Likely causes:
Communication with the Application Insights portal failed; or
There is some problem with your Azure account;
You only have read access to the subscription or group where you were trying to create the new resource.
Fix:
Check that you provided sign-in credentials for the right Azure account.
In your browser, check that you have access to the Azure portal. Open Settings and see if there is any
restriction.
Add Application Insights to your existing project: In Solution Explorer, right click your project and choose "Add
Application Insights."
I get an error "Instrumentation key cannot be empty"

Looks like something went wrong while you were installing Application Insights or maybe a logging adapter.
In Solution Explorer, right-click your project and choose Application Insights > Configure Application
Insights. You'll get a dialog that invites you to sign in to Azure and either create an Application Insights resource,
or re-use an existing one.
"NuGet package(s) are missing" on my build server

Everything builds OK when I'm debugging on my development machine, but I get a NuGet error on the build
server.
Please see NuGet Package Restore and Automatic Package Restore.
Missing menu command to open Application Insights from Visual

Studio
When I right-click my project Solution Explorer, I don't see any Application Insights commands, or I don't see an
Open Application Insights command.
Likely causes:
If you created the Application Insights resource manually, or if the project is of a type that isn't supported by the
Application Insights tools.
The Developer Analytics tools are disabled in your Visual Studio.
Your Visual Studio is older than 2013 Update 3.
Fix:
Make sure your Visual Studio version is 2013 update 3 or later.
Select Tools, Extensions and Updates and check that Developer Analytics tools is installed and enabled. If
so, click Updates to see if there's an update available.
Right-click your project in Solution Explorer. If you see the command Application Insights > Configure
Application Insights, use it to connect your project to the resource in the Application Insights service.
Otherwise, your project type isn't directly supported by the Developer Analytics tools. To see your telemetry, sign
in to the Azure portal, choose Application Insights on the left navigation bar, and select your application.
'Access denied' on opening Application Insights from Visual Studio
The 'Open Application Insights' menu command takes me to the Azure portal, but I get an 'access denied' error.
The Microsoft sign-in that you last used on your default browser doesn't have access to the resource that was
created when Application Insights was added to this app. There are two likely reasons:
You have more than one Microsoft account - maybe a work and a personal Microsoft account? The sign-in that
you last used on your default browser was for a different account than the one that has access to add
Application Insights to the project.
Fix: Click your name at top right of the browser window, and sign out. Then sign in with the account that
has access. Then on the left navigation bar, click Application Insights and select your app.
Someone else added Application Insights to the project, and they forgot to give you access to the resource
group in which it was created.
Fix: If they used an organizational account, they can add you to the team; or they can grant you individual
access to the resource group.
'Asset not found' on opening Application Insights from Visual Studio

The 'Open Application Insights' menu command takes me to the Azure portal, but I get an 'asset not found' error.
Likely causes:
The Application Insights resource for your application has been deleted; or
The instrumentation key was set or changed in ApplicationInsights.config by editing it directly, without
updating the project file.
The instrumentation key in ApplicationInsights.config controls where the telemetry is sent. A line in the project file
controls which resource is opened when you use the command in Visual Studio.
Fix:
In Solution Explorer, right-click the project and choose Application Insights, Configure Application Insights. In
the dialog, you can either choose to send telemetry to an existing resource, or create a new one. Or:
Open the resource directly. Sign in to the Azure portal, click Application Insights on the left navigation bar, and
then select your app.
Where do I find my telemetry?

I signed in to the Microsoft Azure portal, and I'm looking at the Azure home dashboard. So where do I find my
Application Insights data?
On the left navigation bar, click Application Insights, then your app name. If you don't have any projects there,
you need to add or configure Application Insights in your web project.
There you'll see some summary charts. You can click through them to see more detail.
In Visual Studio, while you're debugging your app, click the Application Insights button.
No server data (or no data at all)

I ran my app and then opened the Application Insights service in Microsoft Azure, but all the charts show 'Learn
how to collect...' or 'Not configured.' Or, only Page View and user data, but no server data.
Run your application in debug mode in Visual Studio (F5). Use the application so as to generate some
telemetry. Check that you can see events logged in the Visual Studio output window.
In the Application Insights portal, open Diagnostic Search. Data usually appears here first.
Click the Refresh button. The blade refreshes itself periodically, but you can also do it manually. The refresh
interval is longer for larger time ranges.
Check the instrumentation keys match. On the main blade for your app in the Application Insights portal, in the
Essentials drop-down, look at Instrumentation key. Then, in your project in Visual Studio, open
ApplicationInsights.config and find the <instrumentationkey> . Check that the two keys are equal. If not:
In the portal, click Application Insights and look for the app resource with the right key; or
In Visual Studio Solution Explorer, right-click the project and choose Application Insights, Configure.
Reset the app to send telemetry to the right resource.
If you can't find the matching keys, check that you are using the same sign-in credentials in Visual Studio
as in to the portal.
In the Microsoft Azure home dashboard, look at the Service Health map. If there are some alert indications,
wait until they have returned to OK and then close and re-open your Application Insights application blade.
Check also our status blog.
Did you write any code for the server-side SDK that might change the instrumentation key in TelemetryClient
instances or in TelemetryContext ? Or did you write a filter or sampling configuration that might be filtering out
too much?
If you edited ApplicationInsights.config, carefully check the configuration of TelemetryInitializers and
TelemetryProcessors. An incorrectly-named type or parameter can cause the SDK to send no data.
No data on Page Views, Browsers, Usage

I see data in Server Response Time and Server Requests charts, but no data in Page View Load time, or in the
Browser or Usage blades.
The data comes from scripts in the web pages.
If you added Application Insights to an existing web project, you have to add the scripts by hand.
Make sure Internet Explorer isn't displaying your site in Compatibility mode.
Use the browser's debug feature (F12 on some browsers, then choose Network) to verify that data is being sent
to dc.services.visualstudio.com .
No dependency or exception data

See dependency telemetry and exception telemetry.
No performance data
Performance data (CPU, IO rate, and so on) is available for Java web services, Windows desktop apps, IIS web
apps and services if you install status monitor, and Azure Cloud Services. you'll find it under Settings, Servers.
No (server) data since I published the app to my server

Check that you actually copied all the Microsoft. ApplicationInsights DLLs to the server, together with
Microsoft.Diagnostics.Instrumentation.Extensions.Intercept.dll
In your firewall, you might have to open some TCP ports.
If you have to use a proxy to send out of your corporate network, set defaultProxy in Web.config
Windows Server 2008: Make sure you have installed the following updates: KB2468871, KB2533523,
KB2600217.
I used to see data, but it has stopped

Check the status blog.
Have you hit your monthly quota of data points? Open the Settings/Quota and Pricing to find out. If so, you
can upgrade your plan, or pay for additional capacity. See the pricing scheme.
I don't see all the data I'm expecting

If your application sends a lot of data and you are using the Application Insights SDK for ASP.NET version 2.0.0-
beta3 or later, the adaptive sampling feature may operate and send only a percentage of your telemetry.
You can disable it, but this is not recommended. Sampling is designed so that related telemetry is correctly
transmitted, for diagnostic purposes.
Client IP address is 0.0.0.0

On February 5 2018, we announced that we removed logging of the Client IP address. This does not affect Geo
Location.
NOTE
If you need the first 3 octets of the IP address, you can use a telemetry initializer to add a custom attribute. This does not
affect data collected prior to February 5, 2018.
Wrong geographical data in user telemetry

The city, region, and country dimensions are derived from IP addresses and aren't always accurate. These IP
addresses are processed for location first and then changed to 0.0.0.0 to be stored.
Exception "method not found" on running in Azure Cloud Services
Did you build for .NET 4.6? 4.6 is not automatically supported in Azure Cloud Services roles. Install 4.6 on each
role before running your app.
Troubleshooting Logs
Follow these instructions to capture troubleshooting logs for your framework.
.NET Framework
1. Install the Microsoft.AspNet.ApplicationInsights.HostingStartup package from NuGet. The version you
install must match the current installed version of Microsoft.ApplicationInsighs
2. Modify your applicationinsights.config file to include the following:
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.Extensibility.HostingStartup.FileDiagnosticsTelemetryModule,
Microsoft.AspNet.ApplicationInsights.HostingStartup">
<Severity>Verbose</Severity>
<LogFileName>mylog.txt</LogFileName>
<LogFilePath>C:\\SDKLOGS</LogFilePath>
</Add>
</TelemetryModules>
Your application must have Write permissions to the configured location

3. Restart process so that these new settings are picked up by SDK
4. Revert these changes when you are finished.
.NET Core
1. Install the Microsoft.AspNet.ApplicationInsights.HostingStartup package from NuGet. The version you install
must match the current installed version of Microsoft.ApplicationInsights
The latest version of Microsoft.ApplicationInsights.AspNetCore is 2.7.1, and it refers to

Microsoft.ApplicationInsights version 2.10. Hence the version of
Microsoft.AspNet.ApplicationInsights.HostingStartup to be installed should be 2.10.0
2. Modify ConfigureServices method in your Startup.cs class.:
services.AddSingleton<ITelemetryModule, FileDiagnosticsTelemetryModule>();
services.ConfigureTelemetryModule<FileDiagnosticsTelemetryModule>( (module, options) => {
module.LogFilePath = "C:\\SDKLOGS";
module.LogFileName = "mylog.txt";
module.Severity = "Verbose";
} );
Your application must have Write permissions to the configured location

3. Restart process so that these new settings are picked up by SDK
4. Revert these changes when you are finished.
Collect logs with PerfView

PerfView is a free diagnostics and performance-analysis tool that help isolate CPU, memory, and other issues by
collecting and visualizing diagnostics information from many sources.
The Application Insights SDK log EventSource self-troubleshooting logs that can be captured by PerfView.
To collect logs, download PerfView and run this command:
PerfView.exe collect -MaxCollectSec:300 -NoGui /onlyProviders=*Microsoft-ApplicationInsights-Core,*Microsoft-

ApplicationInsights-Data,*Microsoft-ApplicationInsights-WindowsServer-TelemetryChannel,*Microsoft-
ApplicationInsights-Extensibility-AppMapCorrelation-Dependency,*Microsoft-ApplicationInsights-Extensibility-
AppMapCorrelation-Web,*Microsoft-ApplicationInsights-Extensibility-DependencyCollector,*Microsoft-
ApplicationInsights-Extensibility-HostingStartup,*Microsoft-ApplicationInsights-Extensibility-
PerformanceCollector,*Microsoft-ApplicationInsights-Extensibility-EventCounterCollector,*Microsoft-
ApplicationInsights-Extensibility-PerformanceCollector-QuickPulse,*Microsoft-ApplicationInsights-
Extensibility-Web,*Microsoft-ApplicationInsights-Extensibility-WindowsServer,*Microsoft-ApplicationInsights-
WindowsServer-Core,*Microsoft-ApplicationInsights-Extensibility-EventSourceListener,*Microsoft-
ApplicationInsights-AspNetCore
You can modify these parameters as needed:

MaxCollectSec. Set this parameter to prevent PerfView from running indefinitely and affecting the
performance of your server.
OnlyProviders. Set this parameter to only collect logs from the SDK. You can customize this list based on your
specific investigations.
NoGui. Set this parameter to collect logs without the Gui.
For more information,
Recording performance traces with PerfView.
Application Insights Event Sources
Still not working...

Application Insights forum
Monitor application performance hosted on Azure
VM and Azure virtual machine scale sets
Enabling monitoring on your .NET based web applications running on Azure Virtual Machines and Azure Virtual
Machine Scale Sets is now easier than ever. Get all the benefits of using Application Insights without modifying
your code.
This article will walk you through enabling Application Insights monitoring using the
ApplicationMonitoringWindows extension and provide preliminary guidance for automating the process for
large-scale deployments.
IMPORTANT
Azure ApplicationMonitoringWindows extension is currently in public preview. This preview version is provided without a
service-level agreement, and we don't recommend it for production workloads. Some features might not be supported,
and some might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure
Previews.

There are two ways to enable application monitoring for Azure VM and Azure virtual machine scale set hosted
applications:
Agent-based application monitoring (ApplicationMonitoringWindows extension).
This method is the easiest to enable, and no advanced configuration is required. It is often referred to
as "runtime" monitoring. For Azure VMs and Azure virtual machine scale sets we recommend at a
minimum enabling this level of monitoring. After that, based on your specific scenario, you can
evaluate whether manual instrumentation is needed.
Currently only .Net IIS -hosted applications are supported.
Manually instrumenting the application through code by installing the Application Insights SDK.
This approach is much more customizable, but it requires adding a dependency on the Application
Insights SDK NuGet packages. This method, also means you have to manage the updates to the
latest version of the packages yourself.
If you need to make custom API calls to track events/dependencies not captured by default with
agent-based monitoring, you would need to use this method. Check out the API for custom events
and metrics article to learn more.
NOTE
If both agent based monitoring and manual SDK based instrumentation is detected only the manual instrumentation
settings will be honored. This is to prevent duplicate data from being sent. To learn more about this check out the
troubleshooting section below.
Manage agent-based monitoring for .NET applications on VM using

PowerShell
Install or update the application monitoring extension for VM
$publicCfgJsonString = '
{
"RedfieldConfiguration": {
"InstrumentationKeyMap": {
"Filters": [
{
"AppFilter": ".*",
"MachineFilter": ".*",
"InstrumentationSettings" : {
"InstrumentationKey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
}
]
}
}
}
';
$privateCfgJsonString = '{}';
Set-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Location "South Central US"

-Name "ApplicationMonitoring" -Publisher "Microsoft.Azure.Diagnostics" -Type "ApplicationMonitoringWindows"
-Version "2.8" -SettingString $publicCfgJsonString -ProtectedSettingString $privateCfgJsonString
Uninstall application monitoring extension from VM
Remove-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Name

"ApplicationMonitoring"
Query application monitoring extension status for VM
Get-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Name ApplicationMonitoring

-Status
Get list of installed extensions for VM
Get-AzResource -ResourceId
"/subscriptions/<mySubscriptionId>/resourceGroups/<myVmResourceGroup>/providers/Microsoft.Compute/virtualMac
hines/<myVmName>/extensions"
# Name : ApplicationMonitoring
# ResourceGroupName : <myVmResourceGroup>
# ResourceType : Microsoft.Compute/virtualMachines/extensions
# Location : southcentralus
# ResourceId :
/subscriptions/<mySubscriptionId>/resourceGroups/<myVmResourceGroup>/providers/Microsoft.Compute/virtualMach
ines/<myVmName>/extensions/ApplicationMonitoring
Manage agent-based monitoring for .NET applications on Azure

virtual machine scale set using powershell
Install or update the application monitoring extension for Azure virtual machine scale set
$publicCfgHashtable =
@{
"RedfieldConfiguration"= @{
"InstrumentationKeyMap"= @{
"Filters"= @(
@{
"AppFilter"= ".*";
"MachineFilter"= ".*";
"InstrumentationSettings"= @{
"InstrumentationKey"= "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"; # Application Insights
Instrumentation Key, create new Application Insights resource if you don't have one.
https://ms.portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/microsoft.insights%2Fcompo
nents
}
}
)
}
}
};
$privateCfgHashtable = @{};
$vmss = Get-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "<myVmssName>"
Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "ApplicationMonitoring" -Publisher

"Microsoft.Azure.Diagnostics" -Type "ApplicationMonitoringWindows" -TypeHandlerVersion "2.8" -Setting
$publicCfgHashtable -ProtectedSetting $privateCfgHashtable
Update-AzVmss -ResourceGroupName $vmss.ResourceGroupName -Name $vmss.Name -VirtualMachineScaleSet $vmss
# Note: depending on your update policy, you might need to run Update-AzVmssInstance for each instance
Uninstall application monitoring extension from Azure virtual machine scale set
$vmss = Get-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "<myVmssName>"
Remove-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "ApplicationMonitoring"
Update-AzVmss -ResourceGroupName $vmss.ResourceGroupName -Name $vmss.Name -VirtualMachineScaleSet $vmss
# Note: depending on your update policy, you might need to run Update-AzVmssInstance for each instance
Query application monitoring extension status for Azure virtual machine scale set
# Not supported by extensions framework
Get list of installed extensions for Azure virtual machine scale set
Get-AzResource -ResourceId
/subscriptions/<mySubscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachin
eScaleSets/<myVmssName>/extensions
# Name : ApplicationMonitoringWindows
# ResourceGroupName : <myResourceGroup>
# ResourceType : Microsoft.Compute/virtualMachineScaleSets/extensions
# Location :
# ResourceId :
/subscriptions/<mySubscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualMachin
eScaleSets/<myVmssName>/extensions/ApplicationMonitoringWindows
Troubleshooting
Below is our step-by-step troubleshooting guide for extension-based monitoring for .NET applications running
on Azure VM and Azure virtual machine scale sets.
NOTE
.NET Core, Java, and Node.js applications are only supported on Azure VM and Azure virtual machine scale sets via manual
SDK based instrumentation and therefore the steps below do not apply to these scenarios.
Extension execution output is logged to files found in the following directories:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.ApplicationMonitoringWindows\<version>\
Next steps
Learn how to deploy an application to an Azure virtual machine scale set.
Set up Availability web tests to be alerted if your endpoint is down.
Monitor Azure App Service performance
Enabling monitoring on your ASP.NET and ASP.NET Core based web applications running on Azure App
Services is now easier than ever. Whereas previously you needed to manually install a site extension, the latest
extension/agent is now built into the app service image by default. This article will walk you through enabling
Application Insights monitoring as well as provide preliminary guidance for automating the process for large-
scale deployments.
NOTE
Manually adding an Application Insights site extension via Development Tools > Extensions is deprecated. This method
of extension installation was dependent on manual updates for each new version. The latest stable release of the extension
is now preinstalled as part of the App Service image. The files are located in
d:\Program Files (x86)\SiteExtensions\ApplicationInsightsAgent and are automatically updated with each stable
release. If you follow the agent based instructions to enable monitoring below, it will automatically remove the deprecated
extension for you.

There are two ways to enable application monitoring for Azure App Services hosted applications:
Agent-based application monitoring (ApplicationInsightsAgent).
This method is the easiest to enable, and no advanced configuration is required. It is often referred to
as "runtime" monitoring. For Azure App Services we recommend at a minimum enabling this level of
monitoring, and then based on your specific scenario you can evaluate whether more advanced
monitoring through manual instrumentation is needed.
Manually instrumenting the application through code by installing the Application Insights SDK.
This approach is much more customizable, but it requires adding a dependency on the Application
Insights SDK NuGet packages. This method, also means you have to manage the updates to the
latest version of the packages yourself.
If you need to make custom API calls to track events/dependencies not captured by default with
agent-based monitoring, you would need to use this method. Check out the API for custom events
and metrics article to learn more.
NOTE
If both agent based monitoring and manual SDK based instrumentation is detected only the manual instrumentation
settings will be honored. This is to prevent duplicate data from sent. To learn more about this check out the
troubleshooting section below.
Enable agent-based monitoring for .NET applications

NOTE
The combination of APPINSIGHTS_JAVASCRIPT_ENABLED and urlCompression is not supported. For more info see the
explanation in the troubleshooting section.
1. Select Application Insights in the Azure control panel for your app service.
Choose to create a new resource, unless you already set up an Application Insights resource for
this application.
NOTE
When you click OK to create the new resource you will be prompted to Apply monitoring settings.
Selecting Continue will link your new Application Insights resource to your app service, doing so will also
trigger a restart of your app service.
2. After specifying which resource to use, you can choose how you want application insights to collect data
per platform for your application. ASP.NET app monitoring is on-by-default with two different levels of
collection.
.NET Basic collection level offers essential single-instance APM capabilities.

.NET Recommended collection level:
Adds CPU, memory, and I/O usage trends.
Correlates micro-services across request/dependency boundaries.
Collects usage trends, and enables correlation from availability results to transactions.
Collects exceptions unhandled by the host process.
Improves APM metrics accuracy under load, when sampling is used.
3. To configure settings like sampling, which you could previously control via the applicationinsights.config
file you can now interact with those same settings via Application settings with a corresponding prefix.
For example, to change the initial sampling percentage, you can create an Application setting of:
MicrosoftAppInsights_AdaptiveSamplingTelemetryProcessor_InitialSamplingPercentage and a value of
100 .
For the list of supported adaptive sampling telemetry processor settings, you can consult the code
and associated documentation.
Enable agent-based monitoring for .NET Core applications

The following versions of .NET Core are supported: ASP.NET Core 2.0, ASP.NET Core 2.1, ASP.NET Core 2.2
Targeting the full framework from .NET Core, self-contained deployment, and ASP.NET Core 3.0 are currently
not supported with agent/extension based monitoring. (Manual instrumentation via code will work in all of the
previous scenarios.)
1. Select Application Insights in the Azure control panel for your app service.
Choose to create a new resource, unless you already set up an Application Insights resource for
this application.
NOTE
When you click OK to create the new resource you will be prompted to Apply monitoring settings.
Selecting Continue will link your new Application Insights resource to your app service, doing so will also
trigger a restart of your app service.
2. After specifying which resource to use, you can choose how you want Application Insights to collect data
per platform for your application. .NET Core offers Recommended collection or Disabled for .NET
Core 2.0, 2.1, and 2.2.
Enable client-side monitoring for .NET applications
Client-side monitoring is opt-in for ASP.NET. To enable client-side monitoring:
Select Settings >** Application settings**
Under Application settings, add a new app setting name and value:
Name: APPINSIGHTS_JAVASCRIPT_ENABLED
Value: true
Save the settings and Restart your app.

To disable client-side monitoring either remove the associated key value pair from the Application settings, or set
the value to false.
Enable client-side monitoring for .NET Core applications

Client-side monitoring is enabled by default for .NET Core apps with Recommended collection, regardless
of whether the app setting 'APPINSIGHTS_JAVASCRIPT_ENABLED' is present.
If for some reason you would like to disable client-side monitoring:
Select Settings > Application settings
Under Application settings, add a new app setting name and value:
name: APPINSIGHTS_JAVASCRIPT_ENABLED
Value: false
Save the settings and Restart your app.
Automate monitoring
In order to enable telemetry collection with Application Insights, only the Application settings need to be set:
Application settings definitions
APP SETTING NAME DEFINITION VALUE
ApplicationInsightsAgent_EXTENSION_ Main extension, which controls runtime ~2

VERSION monitoring.
XDT_MicrosoftApplicationInsights_Mod In default mode only, essential features default or recommended .

e are enabled in order to insure optimal
performance.
InstrumentationEngine_EXTENSION_VE Controls if the binary-rewrite engine ~1

RSION InstrumentationEngine will be
turned on. This setting has
performance implications and impacts
cold start/startup time.
XDT_MicrosoftApplicationInsights_Base Controls if SQL & Azure table text will ~1

Extensions be captured along with the
dependency calls. Performance
warning: this setting requires the
InstrumentationEngine .
App Service Application settings with Azure Resource Manager

Application settings for App Services can be managed and configured with Azure Resource Manager templates.
This method can be used when deploying new App Service resources with Azure Resource Manager
automation, or for modifying the settings of existing resources.
The basic structure of the application settings JSON for an app service is below:
"resources": [
{
"name": "appsettings",
"type": "config",
"apiVersion": "2015-08-01",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', variables('webSiteName'))]"
],
"tags": {
"displayName": "Application Insights Settings"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
]
For an example of an Azure Resource Manager template with Application settings configured for Application
Insights, this template can be helpful, specifically the section starting on line 238.
Automate the creation of an Application Insights resource and link to your newly created App Service.
To create an Azure Resource Manager template with all the default Application Insights settings configured,
begin the process as if you were going to create a new Web App with Application Insights enabled.
Select Automation options
This option generates the latest Azure Resource Manager template with all required settings configured.
Below is a sample, replace all instances of AppMonitoredSite with your site name:
{
"resources": [
{
"name": "[parameters('name')]",
"type": "Microsoft.Web/sites",
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "[reference('microsoft.insights/components/AppMonitoredSite', '2015-05-
01').InstrumentationKey]"
},
{
"name": "ApplicationInsightsAgent_EXTENSION_VERSION",
"value": "~2"
}
]
},
"name": "[parameters('name')]",
"serverFarmId": "[concat('/subscriptions/', parameters('subscriptionId'),'/resourcegroups/',
parameters('serverFarmResourceGroup'), '/providers/Microsoft.Web/serverfarms/',
parameters('hostingPlanName'))]",
"hostingEnvironment": "[parameters('hostingEnvironment')]"
},
"dependsOn": [
"[concat('Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]",
"microsoft.insights/components/AppMonitoredSite"
],
"apiVersion": "2016-03-01",
"location": "[parameters('location')]"
},
{
"apiVersion": "2016-09-01",
"name": "[parameters('hostingPlanName')]",
"type": "Microsoft.Web/serverfarms",
"properties": {
"name": "[parameters('hostingPlanName')]",
"workerSizeId": "[parameters('workerSize')]",
"numberOfWorkers": "1",
"hostingEnvironment": "[parameters('hostingEnvironment')]"
},
"sku": {
"Tier": "[parameters('sku')]",
"Name": "[parameters('skuCode')]"
"Name": "[parameters('skuCode')]"
}
},
{
"apiVersion": "2015-05-01",
"name": "AppMonitoredSite",
"type": "microsoft.insights/components",
"location": "West US 2",
"properties": {
"ApplicationId": "[parameters('name')]",
"Request_Source": "IbizaWebAppExtensionCreate"
}
}
],
"parameters": {
"name": {
"type": "string"
},
"hostingPlanName": {
"type": "string"
},
"hostingEnvironment": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"skuCode": {
"type": "string"
},
"workerSize": {
"type": "string"
},
"serverFarmResourceGroup": {
"type": "string"
},
"subscriptionId": {
"type": "string"
}
},
"contentVersion": "1.0.0.0"
}
NOTE
The template will generate application settings in “default” mode. This mode is performance optimized, though you can
modify the template to activate whichever features you prefer.
Enabling through PowerShell

In order to enable the application monitoring through PowerShell, only the underlying application settings need
to be changed. Below is a sample, which enables application monitoring for a website called "AppMonitoredSite"
in the resource group "AppMonitoredRG", and configures data to be sent to the "012345678-abcd-ef01-2345-
6789abcd" instrumentation key.
NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which
will continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install
Azure PowerShell.
$app = Get-AzWebApp -ResourceGroupName "AppMonitoredRG" -Name "AppMonitoredSite" -ErrorAction Stop

$newAppSettings = @{} # case-insensitive hash map
$app.SiteConfig.AppSettings | %{$newAppSettings[$_.Name] = $_.Value} #preserve non Application Insights
Application settings.
$newAppSettings["APPINSIGHTS_INSTRUMENTATIONKEY"] = "012345678-abcd-ef01-2345-6789abcd"; # enable the
ApplicationInsightsAgent
$newAppSettings["ApplicationInsightsAgent_EXTENSION_VERSION"] = "~2"; # enable the ApplicationInsightsAgent
$app = Set-AzWebApp -AppSettings $newAppSettings -ResourceGroupName $app.ResourceGroup -Name $app.Name -
ErrorAction Stop
Upgrade monitoring extension/agent

Upgrading from versions 2.8.9 and up
Upgrading from version 2.8.9 happens automatically, without any additional actions. The new monitoring bits
are delivered in the background to the target app service, and on application restart they will be picked up.
To check which version of the extension you are running visit
http://yoursitename.scm.azurewebsites.net/ApplicationInsights
Upgrade from versions 1.0.0 - 2.6.5

Starting with version 2.8.9 the pre-installed site extension is used. If you are an earlier version, you can update
via one of two ways:
Upgrade by enabling via the portal. (Even if you have the Application Insights extension for Azure App
Service installed, the UI shows only Enable button. Behind the scenes, the old private site extension will
be removed.)
Upgrade through PowerShell:
1. Set the application settings to enable the pre-installed site extension ApplicationInsightsAgent. See
Enabling through powershell.
2. Manually remove the private site extension named Application Insights extension for Azure App
Service.
If the upgrade is done from a version prior to 2.5.1, check that the ApplicationInsigths dlls are removed from the
application bin folder see troubleshooting steps.
Troubleshooting
Below is our step-by-step troubleshooting guide for extension/agent based monitoring for .NET and .NET Core
based applications running on Azure App Services.
NOTE
Java and Node.js applications are only supported on Azure App Services via manual SDK based instrumentation and
therefore the steps below do not apply to these scenarios.
NOTE
ASP.NET Core 3.0 applications are not supported. Please follow Manual instrumentation via code for ASP.NET Core 3.0
apps.
1. Check that the application is monitored via ApplicationInsightsAgent .

Check that ApplicationInsightsAgent_EXTENSION_VERSION app setting is set to a value of "~2".
2. Ensure that the application meets the requirements to be monitored.
Browse to https://yoursitename.scm.azurewebsites.net/ApplicationInsights
Confirm that the Application Insights Extension Status is

Pre-Installed Site Extension, version 2.8.12.1527, is running.
If it is not running, follow the enable Application Insights monitoring instructions

Confirm that the status source exists and looks like:
Status source D:\home\LogFiles\ApplicationInsights\status\status_RD0003FF0317B6_4248_1.json
If a similar value is not present, it means the application is not currently running or is not
supported. To ensure that the application is running, try manually visiting the application
url/application endpoints, which will allow the runtime information to become available.
Confirm that IKeyExists is true
If it is false, add ÀPPINSIGHTS_INSTRUMENTATIONKEY with your ikey guid to your
application settings.
Confirm that there are no entries for AppAlreadyInstrumented , AppContainsDiagnosticSourceAssembly
, and AppContainsAspNetTelemetryCorrelationAssembly .
If any of these entries exist, remove the following packages from your application:
Microsoft.ApplicationInsights , System.Diagnostics.DiagnosticSource , and
Microsoft.AspNet.TelemetryCorrelation .
The table below provides a more detailed explanation of what these values mean, their underlying causes, and
recommended fixes:
PROBLEM VALUE EXPLANATION FIX
AppAlreadyInstrumented:true This value indicates that the extension Remove the references. Some of these
detected that some aspect of the SDK references are added by default from
is already present in the Application, certain Visual Studio templates, and
and will back-off. It can be due to a older versions of Visual Studio may add
reference to references to
System.Diagnostics.DiagnosticSource Microsoft.ApplicationInsights .
,
Microsoft.AspNet.TelemetryCorrelation
, or Microsoft.ApplicationInsights
AppAlreadyInstrumented:true If the application is targeting .NET Core Customers on .NET Core 2.1,2.2 are
2.1 or 2.2, and refers to recommended to use
Microsoft.AspNetCore.All meta- Microsoft.AspNetCore.App meta-
package, then it brings in Application package instead.
Insights, and extension will back-off.
AppAlreadyInstrumented:true This value can also be caused by the Clean the app folder to ensure that
presence of the above dlls in the app these dlls are removed.
folder from a previous deployment.
This value indicates that extension

AppContainsAspNetTelemetryCorrelationAssembly: Remove the reference.
true detected references to
Microsoft.AspNet.TelemetryCorrelation
in the application, and will back-off.
This value indicates that extension

AppContainsDiagnosticSourceAssembly**:true Remove the reference.
detected references to
System.Diagnostics.DiagnosticSource
in the application, and will back-off.
IKeyExists:false This value indicates that the Make sure the setting is present in the
instrumentation key is not present in App Service application settings.
the AppSetting,
APPINSIGHTS_INSTRUMENTATIONKEY .
Possible causes: The values may have
been accidentally removed, forgot to
set the values in automation script, etc.
APPINSIGHTS_JAVASCRIPT_ENABLED and urlCompression is not supported

If you use APPINSIGHTS_JAVASCRIPT_ENABLED=true in cases where content is encoded, you might get
errors like:
500 URL rewrite error
500.53 URL rewrite module error with message Outbound rewrite rules cannot be applied when the content
of the HTTP response is encoded ('gzip').
This is due to the APPINSIGHTS_JAVASCRIPT_ENABLED application setting being set to true and content-
encoding being present at the same time. This scenario is not supported yet. The workaround is to remove
APPINSIGHTS_JAVASCRIPT_ENABLED from your application settings. Unfortunately this means that if
client/browser-side JavaScript instrumentation is still required, manual SDK references are needed for your
webpages. Please follow the instructions for manual instrumentation with the JavaScript SDK.
For the latest information on the Application Insights agent/extension, check out the release notes.
Next steps
Run the profiler on your live app.
Azure Functions - monitor Azure Functions with Application Insights
Enable Azure diagnostics to be sent to Application Insights.
Monitor service health metrics to make sure your service is available and responsive.
Receive alert notifications whenever operational events happen or metrics cross a threshold.
Use Application Insights for JavaScript apps and web pages to get client telemetry from the browsers that
visit a web page.
Set up Availability web tests to be alerted if your site is down.
Application Insights for Azure cloud services
Application Insights can monitor Azure cloud service apps for availability, performance, failures, and usage by
combining data from Application Insights SDKs with Azure Diagnostics data from your cloud services. With the
feedback you get about the performance and effectiveness of your app in the wild, you can make informed
choices about the direction of the design in each development lifecycle.
Prerequisites
Before you begin, you need:
An Azure subscription. Sign in with your Microsoft account for Windows, Xbox Live, or other Microsoft cloud
services.
Microsoft Azure tools 2.9 or later.
Developer Analytics Tools 7.10 or later.
Get started quickly

The quickest and easiest way to monitor your cloud service with Application Insights is to choose that option
when you publish your service to Azure.
This option instruments your app at runtime, giving you all the telemetry that you need to monitor requests,
exceptions, and dependencies in your web role. It also monitors performance counters from your worker roles.
Any diagnostics traces generated by your app are also sent to Application Insights.
If this option is all you need, you're done.
Your next steps are viewing metrics from your app, querying your data with Analytics.
To monitor performance in the browser, you might also want to set up availability tests and add code to your
webpages.
The next sections discuss the following additional options:
Send data from various components and build configurations to separate resources.
Add custom telemetry from your app.
Sample app instrumented with Application Insights

In this sample app, Application Insights is added to a cloud service with two worker roles hosted in Azure.
In the next section, you learn how to adapt your own cloud service project in the same way.
Plan resources and resource groups

The telemetry from your app is stored, analyzed, and displayed in an Azure resource of type Application Insights.
Each resource belongs to a resource group. Resource groups are used to manage costs, to grant access to team
members, and to deploy updates in a single coordinated transaction. For example, you could write a script to
deploy an Azure cloud service and its Application Insights monitoring resources all in one operation.
Resources for components
We recommend that you create a separate resource for each component of your app. That is, you create a
resource for each web role and worker role. You can analyze each component separately, but you create a
dashboard that brings together the key charts from all the components, so that you can compare and monitor
them together in a single view.
An alternative approach is to send the telemetry from more than one role to the same resource, but add a
dimension property to each telemetry item that identifies its source role. In this approach, metric charts, such as
exceptions, normally show an aggregation of the counts from the various roles, but you can segment the chart
by the role identifier, as necessary. You can also filter searches by the same dimension. This alternative makes it a
bit easier to view everything at the same time, but it could also lead to some confusion between the roles.
Browser telemetry is usually included in the same resource as its server-side web role.
Put the Application Insights resources for the various components in one resource group. This approach makes
it easy to manage them together.
Separate development, test, and production
If you are developing custom events for your next feature while the previous version is live, you want to send the
development telemetry to a separate Application Insights resource. Otherwise, it can be hard to find your test
telemetry among all the traffic from the live site.
To avoid this situation, create separate resources for each build configuration or "stamp" (development, test,
production, and so on) of your system. Put the resources for each build configuration in a separate resource
group.
To send the telemetry to the appropriate resources, you can set up the Application Insights SDK so that it picks
up a different instrumentation key, depending on the build configuration.
Create an Application Insights resource for each role

If you've decided to create a separate resource for each role, and perhaps a separate set for each build
configuration, it's easiest to create them all in the Application Insights portal. If you create resources a lot, you
can automate the process.
1. In the Azure portal, select New > Developer Services > Application Insights.
2. In the Application Type drop-down list, select ASP.NET web application.

Each resource is identified by an instrumentation key. You might need this key later if you want to manually
configure or verify the configuration of the SDK.
Set up Azure Diagnostics for each role

Set this option to monitor your app with Application Insights. For web roles, this option provides performance
monitoring, alerts, diagnostics, and usage analysis. For other roles, you can search and monitor Azure
Diagnostics such as restart, performance counters, and calls to System.Diagnostics.Trace.
1. In Visual Studio Solution Explorer, under <YourCloudService> > Roles, open the properties of each
role.
2. In Configuration, select the Send diagnostics data to Application Insights check box, and then select
the Application Insights resource that you created earlier.
If you have decided to use a separate Application Insights resource for each build configuration, select the
configuration first.
This has the effect of inserting your Application Insights instrumentation keys into the files named
ServiceConfiguration.*.cscfg. Here is the Sample code.
If you want to vary the level of diagnostics information that's sent to Application Insights, you can do so by
editing the .cscfg files directly.
Install the SDK in each project

With this option, you can add custom business telemetry to any role. The option provides a closer analysis of
how your app is used and performs.
In Visual Studio, configure the Application Insights SDK for each cloud app project.
1. To configure web roles, right-click the project, and then select Configure Application Insights or Add
> Application Insights telemetry.
2. To configure worker roles:
a. Right-click the project, and then select Manage NuGet Packages.
b. Add Application Insights for Windows Servers.
3. To configure the SDK to send data to the Application Insights resource:
a. In a suitable startup function, set the instrumentation key from the configuration setting in the .cscfg file:
RoleEnvironment.GetConfigurationSettingValue("APPINSIGHTS_INSTRUMENTATIONKEY");
b. Repeat "step a" for each role in your app. See the examples:
Web role
Worker role
For webpages
4. Set the ApplicationInsights.config file to be copied always to the output directory.
A message in the .config file asks you to place the instrumentation key there. However, for cloud apps, it's
better to set it from the .cscfg file. This approach ensures that the role is correctly identified in the portal.
Set up Status Monitor to collect full SQL Queries (optional)

This step is only needed if you want to capture full SQL queries on .NET Framework.
1. In \*.csdef file Add startup task for each role similar to
<Startup>
<Task commandLine="AppInsightsAgent\InstallAgent.bat" executionContext="elevated" taskType="simple">
<Environment>
<Variable name="ApplicationInsightsAgent.DownloadLink" value="http://go.microsoft.com/fwlink/?
LinkID=522371" />
<Variable name="RoleEnvironment.IsEmulated">
<RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
</Variable>
</Environment>
</Task>
</Startup>
2. Download InstallAgent.bat and InstallAgent.ps1, put them into the AppInsightsAgent folder on each role
project. Make sure to copy them to the output directory through Visual Studio file properties or build
scripts.
3. On all Worker Roles, add environment variables:
<Environment>
<Variable name="COR_ENABLE_PROFILING" value="1" />
<Variable name="COR_PROFILER" value="{324F817A-7420-4E6D-B3C1-143FBED6D855}" />
<Variable name="MicrosoftInstrumentationEngine_Host" value="{CA487940-57D2-10BF-11B2-
A3AD5A13CBC0}" />
</Environment>
Run and publish the app

1. Run your app, and sign in to Azure.
2. Open the Application Insights resources that you created.
Individual data points are displayed in Search, and aggregated data is displayed in Metric Explorer.
3. Add more telemetry (see the next sections) and then publish your app to get live diagnostics and usage
feedback.
If there is no data, do the following:
1. To view individual events, open the Search tile.
2. In the app, open various pages so that it generates some telemetry.
3. Wait a few seconds, and then click Refresh.
For more information, see Troubleshooting.
View Azure Diagnostics events

You can find the Azure Diagnostics information in Application Insights in the following locations:
Performance counters are displayed as custom metrics.
Windows event logs are shown as traces and custom events.
Application logs, ETW logs, and any diagnostics infrastructure logs appear as traces.
To view performance counters and counts of events, open Metrics Explorer and add the following chart:
To search across the various trace logs that are sent by Azure Diagnostics, use Search or an Analytics query. For
example, suppose you have an unhandled exception that has caused a role to crash and recycle. That information
would show up in the Application channel of Windows Event Log. You can use Search to view the Windows
Event Log error and get the full stack trace for the exception. Doing so helps you find the root cause of the issue.
More telemetry
The next sections discuss how to get additional telemetry from various aspects of your app.
Track requests from worker roles

In web roles, the requests module automatically collects data about HTTP requests. For examples of how you can
override the default collection behavior, see the sample MVCWebRole.
You can capture the performance of calls to worker roles by tracking them in the same way as HTTP requests. In
Application Insights, the Request telemetry type measures a unit of named server-side work that can be timed
and can independently succeed or fail. Although HTTP requests are captured automatically by the SDK, you can
insert your own code to track requests to worker roles.
See the two sample worker roles instrumented to report requests:
WorkerRoleA
WorkerRoleB
Exceptions
For information about how to collect unhandled exceptions from various web app types, see Monitoring
exceptions in Application Insights.
The sample web role has MVC5 and Web API 2 controllers. The unhandled exceptions from the two are captured
with the following handlers:
AiHandleErrorAttribute set up for MVC5 controllers as shown in this example
AiWebApiExceptionLogger set up for Web API 2 controllers as shown in this example
For worker roles, you can track exceptions in two ways:
Use TrackException(ex).
If you have added the Application Insights trace listener NuGet package, you can use
System.Diagnostics.Trace to log exceptions as shown in this example.
The following counters are collected by default:
\Process(??APP_WIN32_PROC??)% Processor Time
\Memory\Available Bytes
.NET CLR Exceptions(??APP_CLR_PROC??)# of Exceps Thrown / sec
\Process(??APP_WIN32_PROC??)\Private Bytes
\Process(??APP_WIN32_PROC??)\IO Data Bytes/sec
\Processor(_Total)% Processor Time
For web roles, these counters are also collected:
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests/Sec
\ASP.NET Applications(??APP_W3SVC_PROC??)\Request Execution Time
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests In Application Queue
You can specify additional custom or other Windows performance counters by editing ApplicationInsights.config
as shown in this example.
Correlated telemetry for worker roles
For a rich diagnostics experience, you can view what led to a failed or high latency request. With web roles, the
SDK automatically sets up a correlation between related telemetry.
To achieve this view for worker roles, you can use a custom telemetry initializer to set a common Operation.Id
context attribute for all the telemetry. Doing so lets you view at a glance whether the latency or failure issue was
caused by a dependency or your code.
Here's how:
Set the correlationId into a CallContext as shown in this example. In this case, we are using the Request ID as
the correlationId.
Add a custom TelemetryInitializer implementation, to set the Operation.Id to the correlationId that was set
previously. For an example, see ItemCorrelationTelemetryInitializer.
Add the custom telemetry initializer. You could do so in the ApplicationInsights.config file or in code as shown
in this example.
Client telemetry
To get browser-based telemetry, such as page view counts, page load times, or script exceptions, and to write
custom telemetry in your page scripts, see Add the JavaScript SDK to your webpages.
Availability tests
To make sure your app stays live and responsive, Set up web tests.
Display everything together

For an overall picture of your system, you can display the key monitoring charts together on one dashboard. For
example, you could pin the request and failure counts of each role.
If your system uses other Azure services, such as Stream Analytics, include their monitoring charts as well.
If you have a client mobile app, use App Center. Create queries in Analytics to display the event counts, and pin
them to the dashboard.
Example
The example monitors a service that has a web role and two worker roles.
Exception "method not found" on running in Azure cloud services

Did you build for .NET 4.6? .NET 4.6 is not automatically supported in Azure cloud services roles. Install .NET 4.6
on each role before running your app.
Video
Next steps
Configure sending Azure Diagnostics to Application Insights
Automatically create Application Insights resources
Automate Azure Diagnostics
Azure Functions
Monitor Azure Functions
Azure Functions offers built-in integration with Azure Application Insights to monitor functions. This article shows
you how to configure Azure Functions to send system-generated log files to Application Insights.
We recommend using Application Insights because it collects log, performance, and error data. It automatically
detects performance anomalies and includes powerful analytics tools to help you diagnose issues and to
understand how your functions are used. It's designed to help you continuously improve performance and
usability. You can even use Application Insights during local function app project development. For more
information, see What is Application Insights?.
As the required Application Insights instrumentation is built into Azure Functions, all you need is a valid
instrumentation key to connect your function app to an Application Insights resource.
Application Insights pricing and limits

You can try out Application Insights integration with Function Apps for free. There's a daily limit to how much data
can be processed for free. You might hit this limit during testing. Azure provides portal and email notifications
when you're approaching your daily limit. If you miss those alerts and hit the limit, new logs won't appear in
Application Insights queries. Be aware of the limit to avoid unnecessary troubleshooting time. For more
information, see Manage pricing and data volume in Application Insights.
Enable Application Insights integration

For a function app to send data to Application Insights, it needs to know the instrumentation key of an Application
Insights resource. The key must be in an app setting named APPINSIGHTS_INSTRUMENTATIONKEY.
New function app in the portal
When you create your function app in the Azure portal, Application Insights integration is enabled by default. The
Application Insights resource has the same name as your function app, and it's created either in the same region or
in nearest region.
To review the Application Insights resource being created, select it to expand the Application Insights window.
You can change the New resource name or choose a different Location in an Azure geography where you want
to store your data.
When you choose Create, an Application Insights resource is created with your function app, which has the
APPINSIGHTS_INSTRUMENTATIONKEY set in application settings. Everything is ready to go.
Add to an existing function app

When you create a function app using the Azure CLI, Visual Studio, or Visual Studio Code, you must create the
Application Insights resource. You can then add the instrumentation key from that resource as an application
setting in your function app.
Functions makes it easy to add Application Insights integration to a function app from the Azure portal.
1. In the portal, select All services > Function Apps, select your function app, and then select the
Application Insights banner at the top of the window
2. Create an Application Insights resource by using the settings specified in the table below the image.
SETTING SUGGESTED VALUE DESCRIPTION
Name Unique app name It's easiest to use the same name as
your function app, which must be
unique in your subscription.
Location West Europe If possible, use the same region as

your function app, or one that's close
to that region.
3. Select OK. The Application Insights resource is created in the same resource group and subscription as your
function app. After the resource is created, close the Application Insights window.
4. Back in your function app, select Application settings, and then scroll down to Application settings. If
you see a setting named APPINSIGHTS_INSTRUMENTATIONKEY , Application Insights integration is enabled for
your function app running in Azure.
Early versions of Functions used built-in monitoring, which is no longer recommended. When enabling Application
Insights integration for such a function app, you must also disable built-in logging.
View telemetry in Monitor tab

With Application Insights integration enabled, you can view telemetry data in the Monitor tab.
1. In the function app page, select a function that has run at least once after Application Insights was
configured. Then select the Monitor tab.
2. Select Refresh periodically, until the list of function invocations appears.

It can take up to five minutes for the list to appear while the telemetry client batches data for transmission to
the server. (The delay doesn't apply to the Live Metrics Stream. That service connects to the Functions host
when you load the page, so logs are streamed directly to the page.)
3. To see the logs for a particular function invocation, select the Date column link for that invocation.
The logging output for that invocation appears in a new page.
You can see that both pages have a Run in Application Insights link to the Application Insights Analytics query
that retrieves the data.
The following query is displayed. You can see that the invocation list is limited to the last 30 days. The list shows no
more than 20 rows ( where timestamp > ago(30d) | take 20 ). The invocation details list is for the last 30 days with
no limit.
For more information, see Query telemetry data later in this article.
View telemetry in Application Insights

To open Application Insights from a function app in the Azure portal, go to the function app's Overview page.
Under Configured features, select Application Insights.
For information about how to use Application Insights, see the Application Insights documentation. This section
shows some examples of how to view data in Application Insights. If you're already familiar with Application
Insights, you can go directly to the sections about how to configure and customize the telemetry data.
The following areas of Application Insights can be helpful when evaluating the behavior, performance, and errors in
your functions:
TAB DESCRIPTION
Failures Create charts and alerts based on function failures and server
exceptions. The Operation Name is the function name.
Failures in dependencies aren't shown unless you implement
custom telemetry for dependencies.
Performance Analyze performance issues.
Servers View resource utilization and throughput per server. This data
can be useful for debugging scenarios where functions are
bogging down your underlying resources. Servers are referred
to as Cloud role instances.
Metrics Create charts and alerts that are based on metrics. Metrics
include the number of function invocations, execution time,
and success rates.
Live Metrics Stream View metrics data as it's created in real time.
Query telemetry data

Application Insights Analytics gives you access to all telemetry data in the form of tables in a database. Analytics
provides a query language for extracting, manipulating, and visualizing the data.
Here's a query example that shows the distribution of requests per worker over the last 30 minutes.
requests
| where timestamp > ago(30m)
| summarize count() by cloud_RoleInstance, bin(timestamp, 1m)
| render timechart
The tables that are available are shown in the Schema tab on the left. You can find data generated by function
invocations in the following tables:
TABLE DESCRIPTION
traces Logs created by the runtime and by function code.
requests One request for each function invocation.
exceptions Any exceptions thrown by the runtime.
customMetrics The count of successful and failing invocations, success rate,

and duration.
customEvents Events tracked by the runtime, for example: HTTP requests

that trigger a function.
performanceCounters Information about the performance of the servers that the

functions are running on.
The other tables are for availability tests, and client and browser telemetry. You can implement custom telemetry to
add data to them.
Within each table, some of the Functions-specific data is in a customDimensions field. For example, the following
query retrieves all traces that have log level Error .
traces
| where customDimensions.LogLevel == "Error"
The runtime provides the customDimensions.LogLevel and customDimensions.Category fields. You can provide
additional fields in logs that you write in your function code. See Structured logging later in this article.
Configure categories and log levels

You can use Application Insights without any custom configuration. The default configuration can result in high
volumes of data. If you're using a Visual Studio Azure subscription, you might hit your data cap for Application
Insights. Later in this article, you learn how to configure and customize the data that your functions send to
Application Insights. For a function app, logging is configured in the host.json file.
Categories
The Azure Functions logger includes a category for every log. The category indicates which part of the runtime
code or your function code wrote the log.
The Functions runtime creates logs with a category that begin with "Host." In version 1.x, the function started ,
function executed , and function completed logs have the category Host.Executor . Starting in version 2.x, these
logs have the category Function.<YOUR_FUNCTION_NAME> .
If you write logs in your function code, the category is Function in version 1.x of the Functions runtime. In version
2.x, the category is Function.<YOUR_FUNCTION_NAME>.User .
Log levels
The Azure Functions logger also includes a log level with every log. LogLevel is an enumeration, and the integer
code indicates relative importance:
LOGLEVEL CODE
Trace 0
LOGLEVEL CODE
Debug 1
Information 2
Warning 3
Error 4
Critical 5
None 6
Log level None is explained in the next section.

Log configuration in host.json
The host.json file configures how much logging a function app sends to Application Insights. For each category,
you indicate the minimum log level to send. There are two examples: the first example targets the Functions
version 2.x runtime (.NET Core) and the second example is for the version 1.x runtime.
Version 2.x
The v2.x runtime uses the .NET Core logging filter hierarchy.
{
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Information",
"Host.Results": "Error",
"Function": "Error",
"Host.Aggregator": "Trace"
}
}
}
Version 1.x
{
"logger": {
"categoryFilter": {
"defaultLevel": "Information",
"categoryLevels": {
"Host.Results": "Error",
"Host.Aggregator": "Trace"
}
}
}
}
This example sets up the following rules:

For logs with category Host.Results or Function , send only Error level and above to Application Insights.
Logs for Warning level and below are ignored.
For logs with category Host.Aggregator , send all logs to Application Insights. The Trace log level is the same
as what some loggers call Verbose , but use Trace in the host.json file.
For all other logs, send only Information level and above to Application Insights.
The category value in host.json controls logging for all categories that begin with the same value. Host in
host.json controls logging for Host.General , Host.Executor , Host.Results , and so on.
If host.json includes multiple categories that start with the same string, the longer ones are matched first. Suppose
you want everything from the runtime except Host.Aggregator to log at Error level, but you want
Host.Aggregator to log at the Information level:
Version 2.x
{
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Information",
"Host": "Error",
"Host.Aggregator": "Information"
}
}
}
Version 1.x
{
"logger": {
"categoryFilter": {
"defaultLevel": "Information",
"categoryLevels": {
"Host": "Error",
"Host.Aggregator": "Information"
}
}
}
}
To suppress all logs for a category, you can use log level None . No logs are written with that category and there's
no log level above it.
The following sections describe the main categories of logs that the runtime creates.
Category Host.Results
These logs show as "requests" in Application Insights. They indicate success or failure of a function.
All of these logs are written at Information level. If you filter at Warning or above, you won't see any of this data.
Category Host.Aggregator
These logs provide counts and averages of function invocations over a configurable period of time. The default
period is 30 seconds or 1,000 results, whichever comes first.
The logs are available in the customMetrics table in Application Insights. Examples are the number of runs,
success rate, and duration.
All of these logs are written at Information level. If you filter at Warning or above, you won't see any of this data.
Other categories
All logs for categories other than the ones already listed are available in the traces table in Application Insights.
All logs with categories that begin with Host are written by the Functions runtime. The "Function started" and
"Function completed" logs have category Host.Executor . For successful runs, these logs are Information level.
Exceptions are logged at Error level. The runtime also creates Warning level logs, for example: queue messages
sent to the poison queue.
Logs written by your function code have category Function and can be any log level.
Configure the aggregator

As noted in the previous section, the runtime aggregates data about function executions over a period of time. The
default period is 30 seconds or 1,000 runs, whichever comes first. You can configure this setting in the host.json
file. Here's an example:
{
"aggregator": {
"batchSize": 1000,
"flushTimeout": "00:00:30"
}
}
Configure sampling
Application Insights has a sampling feature that can protect you from producing too much telemetry data on
completed executions at times of peak load. When the rate of incoming executions exceeds a specified threshold,
Application Insights starts to randomly ignore some of the incoming executions. The default setting for maximum
number of executions per second is 20 (five in version 1.x). You can configure sampling in host.json. Here's an
example:
Version 2.x
{
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"maxTelemetryItemsPerSecond" : 20
}
}
}
}
Version 1.x
{
"applicationInsights": {
"sampling": {
"isEnabled": true,
"maxTelemetryItemsPerSecond" : 5
}
}
}
NOTE
Sampling is enabled by default. If you appear to be missing data, you might need to adjust the sampling settings to fit your
particular monitoring scenario.
Write logs in C# functions

You can write logs in your function code that appear as traces in Application Insights.
ILogger
Use an ILogger parameter in your functions instead of a TraceWriter parameter. Logs created by using
TraceWriter go to Application Insights, but ILogger lets you do structured logging.
With an ILogger object, you call Log<level> extension methods on ILogger to create logs. The following code
writes Information logs with category "Function."
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)

{
logger.LogInformation("Request for item with key={itemKey}.", id);
Structured logging
The order of placeholders, not their names, determines which parameters are used in the log message. Suppose
you have the following code:
string partitionKey = "partitionKey";

string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);
If you keep the same message string and reverse the order of the parameters, the resulting message text would
have the values in the wrong places.
Placeholders are handled this way so that you can do structured logging. Application Insights stores the parameter
name-value pairs and the message string. The result is that the message arguments become fields that you can
query on.
If your logger method call looks like the previous example, you can query the field customDimensions.prop__rowKey .
The prop__ prefix is added to ensure there are no collisions between fields the runtime adds and fields your
function code adds.
You can also query on the original message string by referencing the field
customDimensions.prop__{OriginalFormat} .
Here's a sample JSON representation of customDimensions data:
{
customDimensions: {
"prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
"Category":"Function",
"LogLevel":"Information",
"prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
}
}
Custom metrics logging

In C# script functions, you can use the LogMetric extension method on ILogger to create custom metrics in
Application Insights. Here's a sample method call:
logger.LogMetric("TestMetric", 1234);
This code is an alternative to calling TrackMetric by using the Application Insights API for .NET.
Write logs in JavaScript functions

In Node.js functions, use context.log to write logs. Structured logging isn't enabled.
context.log('JavaScript HTTP trigger function processed a request.' + context.invocationId);
Custom metrics logging

When you're running on version 1.x of the Functions runtime, Node.js functions can use the context.log.metric
method to create custom metrics in Application Insights. This method isn't currently supported in version 2.x.
Here's a sample method call:
context.log.metric("TestMetric", 1234);
This code is an alternative to calling trackMetric by using the Node.js SDK for Application Insights.
Log custom telemetry in C# functions

You can use the Microsoft.ApplicationInsights NuGet package to send custom telemetry data to Application
Insights. The following C# example uses the custom telemetry API. The example is for a .NET class library, but the
Application Insights code is the same for C# script.
Version 2.x
The version 2.x runtime uses newer features in Application Insights to automatically correlate telemetry with the
current operation. There's no need to manually set the operation Id , ParentId , or Name fields.
using System;
using System.Linq;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
namespace functionapp0915
{
public class HttpTrigger2
{
private readonly TelemetryClient telemetryClient;
/// Using dependency injection will guarantee that you use the same configuration for telemetry
collected automatically and manually.
public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
{
this.telemetryClient = new TelemetryClient(telemetryConfiguration);
}
[FunctionName("HttpTrigger2")]
public Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
HttpRequest req, ExecutionContext context, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
DateTime start = DateTime.UtcNow;
// Parse query parameter

string name = req.Query
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
// Track an Event
var evt = new EventTelemetry("Function called");
evt.Context.User.Id = name;
this.telemetryClient.TrackEvent(evt);
// Track a Metric
var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
metric.Context.User.Id = name;
this.telemetryClient.TrackMetric(metric);
// Track a Dependency
var dependency = new DependencyTelemetry
{
Name = "GET api/planets/1/",
Target = "swapi.co",
Data = "https://swapi.co/api/planets/1/",
Timestamp = start,
Duration = DateTime.UtcNow - start,
Success = true
};
dependency.Context.User.Id = name;
this.telemetryClient.TrackDependency(dependency);
return Task.FromResult<IActionResult>(new OkResult());

}
}
}
Version 1.x
using System;
using System.Net;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using System.Linq;
namespace functionapp0915
{
public static class HttpTrigger2
{
private static string key = TelemetryConfiguration.Active.InstrumentationKey =
System.Environment.GetEnvironmentVariable(
"APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);
private static TelemetryClient telemetryClient =

new TelemetryClient() { InstrumentationKey = key };
[FunctionName("HttpTrigger2")]
public static async Task<HttpResponseMessage> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
HttpRequestMessage req, ExecutionContext context, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
DateTime start = DateTime.UtcNow;
// Parse query parameter

string name = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
// Get request body

dynamic data = await req.Content.ReadAsAsync<object>();
// Set name to query string or body data

name = name ?? data?.name;
// Track an Event
var evt = new EventTelemetry("Function called");
UpdateTelemetryContext(evt.Context, context, name);
telemetryClient.TrackEvent(evt);
// Track a Metric
var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
UpdateTelemetryContext(metric.Context, context, name);
telemetryClient.TrackMetric(metric);
// Track a Dependency
var dependency = new DependencyTelemetry
{
Name = "GET api/planets/1/",
Target = "swapi.co",
Data = "https://swapi.co/api/planets/1/",
Timestamp = start,
Duration = DateTime.UtcNow - start,
Success = true
};
UpdateTelemetryContext(dependency.Context, context, name);
telemetryClient.TrackDependency(dependency);
}
// Correlate all telemetry with the current Function invocation

private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext,
string userName)
{
context.Operation.Id = functionContext.InvocationId.ToString();
context.Operation.ParentId = functionContext.InvocationId.ToString();
context.Operation.Name = functionContext.FunctionName;
context.User.Id = userName;
}
}
}
Don't call TrackRequest or StartOperation<RequestTelemetry> because you'll see duplicate requests for a function
invocation. The Functions runtime automatically tracks requests.
Don't set telemetryClient.Context.Operation.Id . This global setting causes incorrect correlation when many
functions are running simultaneously. Instead, create a new telemetry instance ( DependencyTelemetry ,
EventTelemetry ) and modify its Context property. Then pass in the telemetry instance to the corresponding
Track method on TelemetryClient ( TrackDependency() , TrackEvent() ). This method ensures that the telemetry
has the correct correlation details for the current function invocation.
Log custom telemetry in JavaScript functions

Here is a sample code snippet that sends custom telemetry with the Application Insights Node.js SDK:

appInsights.setup();
const client = appInsights.defaultClient;
module.exports = function (context, req) {

context.log('JavaScript HTTP trigger function processed a request.');
client.trackEvent({name: "my custom event", tagOverrides:{"ai.operation.id": context.invocationId},

properties: {customProperty2: "custom property value"}});
client.trackException({exception: new Error("handled exceptions can be logged with this method"),
tagOverrides:{"ai.operation.id": context.invocationId}});
client.trackMetric({name: "custom metric", value: 3, tagOverrides:{"ai.operation.id":
context.invocationId}});
client.trackTrace({message: "trace message", tagOverrides:{"ai.operation.id": context.invocationId}});
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM
Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL", tagOverrides:
{"ai.operation.id": context.invocationId}});
client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200,
success:true, tagOverrides:{"ai.operation.id": context.invocationId}});
context.done();
};
The tagOverrides parameter sets the operation_Id to the function's invocation ID. This setting enables you to
correlate all of the automatically generated and custom telemetry for a given function invocation.
Dependencies
Functions v2 automatically collects dependencies for HTTP requests, ServiceBus, and SQL.
You can write custom code to show the dependencies. For examples, see the sample code in the C# custom
telemetry section. The sample code results in an application map in Application Insights that looks like the
following image:
Report issues
To report an issue with Application Insights integration in Functions, or to make a suggestion or request, create an
issue in GitHub.
Streaming Logs
While developing an application, you often want to what's being written to the logs in near-real time when running
in Azure.
There are two ways to view a stream of log files being generated by your function executions.
Built-in log streaming: the App Service platform lets you view a stream of your application log files. This is
equivalent to the output seen when you debug your functions during local development and when you use
the Test tab in the portal. All log-based information is displayed. For more information, see Stream logs.
This streaming method supports only a single instance, and can't be used with an app running on Linux in a
Consumption plan.
Live Metrics Stream: when your function app is connected to Application Insights, you can view log data
and other metrics in near-real time in the Azure portal using Live Metrics Stream. Use this method when
monitoring functions running on multiple-instances or on Linux in a Consumption plan. This method uses
sampled data.
Log streams can be viewed both in the portal and in most local development environments.
Portal
You can view both types of log streams in the portal.
Built-in log streaming
To view streaming logs in the portal, select the Platform features tab in your function app. Then, under
Monitoring, choose Log streaming.
This connects your app to the log streaming service and application logs are displayed in the window. You can
toggle between Application logs and Web server logs.
Live Metrics Stream
To view the Live Metrics Stream for your app, select the Overview tab of your function app. When you have
Application Insights enables, you see an Application Insights link under Configured features. This link takes
you to the Application Insights page for your app.
In Application Insights, select Live Metrics Stream. Sampled log entries are displayed under Sample Telemetry.
Visual Studio Code
To turn on the streaming logs for your function app in Azure:
1. Select F1 to open the command palette, and then search for and run the command Azure Functions: Start
Streaming Logs.
2. Select your function app in Azure, and then select Yes to enable application logging for the function app.
3. Trigger your functions in Azure. Notice that log data is displayed in the Output window in Visual Studio
Code.
4. When you're done, remember to run the command Azure Functions: Stop Streaming Logs to disable
logging for the function app.
Core Tools
Built-in log streaming
Use the logstream option to start receiving streaming logs of a specific function app running in Azure, as in the
following example:
func azure functionapp logstream <FunctionAppName>
Live Metrics Stream

You can also view the Live Metrics Stream for your function app in a new browser window by including the
--browser option, as in the following example:
func azure functionapp logstream <FunctionAppName> --browser
Azure CLI
You can enable streaming logs by using the Azure CLI. Use the following commands to sign in, choose your
subscription, and stream log files:
az login
az account list
az account set --subscription <subscriptionNameOrId>
az webapp log tail --resource-group <RESOURCE_GROUP_NAME> --name <FUNCTION_APP_NAME>
Azure PowerShell
You can enable streaming logs by using Azure PowerShell. For PowerShell, use the following commands to add
your Azure account, choose your subscription, and stream log files:
Add-AzAccount
Get-AzSubscription
Get-AzSubscription -SubscriptionName "<subscription name>" | Select-AzSubscription
Get-AzWebSiteLog -Name <FUNCTION_APP_NAME> -Tail
Disable built-in logging

When you enable Application Insights, disable the built-in logging that uses Azure Storage. The built-in logging is
useful for testing with light workloads, but isn't intended for high-load production use. For production monitoring,
we recommend Application Insights. If built-in logging is used in production, the logging record might be
incomplete because of throttling on Azure Storage.
To disable built-in logging, delete the AzureWebJobsDashboard app setting. For information about how to delete app
settings in the Azure portal, see the Application settings section of How to manage a function app. Before you
delete the app setting, make sure no existing functions in the same function app use the setting for Azure Storage
triggers or bindings.
Next steps
For more information, see the following resources:
ASP.NET Core logging
Zero instrumentation application monitoring for
Kubernetes hosted applications
IMPORTANT
This functionality is currently in public preview. This preview version is provided without a service level agreement, and it's not
recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For
more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Azure Monitor now leverages service mesh tech on your Kubernetes cluster to provide out of the box application
monitoring for any Kubernetes hosted app. With default Application Insight features like Application Map to model
your dependencies, Live Metrics Stream for real-time monitoring, powerful visualizations with the default
dashboard, Metric Explorer, and Workbooks. This feature will help users spot performance bottlenecks and failure
hotspots across all of their Kubernetes workloads within a selected Kubernetes namespace. By capitalizing on your
existing service mesh investments with technologies like Istio, Azure Monitor enables auto-instrumented app
monitoring without any modification to your application's code.
NOTE
This is one of many ways to perform application monitoring on Kubernetes. You can also instrument any app hosted in
Kubernetes by using the Application Insights SDK without the need for a service mesh. To monitor Kubernetes without
instrumenting the application with an SDK you can use the below method.
Prerequisites
A Kubernetes cluster.
Console access to the cluster to run kubectl.
An Application Insight resource
Have a service mesh. If your cluster doesn't have Istio deployed, you can learn how to install and use Istio in
Azure Kubernetes Service.
Capabilities
By using zero instrumentation application monitoring for Kubernetes hosted apps, you will be able to use:
Application Map
Live Stream Metrics
Dashboards
Metrics Explorer
Distributed-tracing
End-to-end transaction monitoring
Installation steps
To enable the solution, we'll be performing the following steps:
Deploy the application (if not already deployed).
Ensure the application is part of the service mesh.
Observe collected telemetry.
Configure your app to work with a service mesh
Istio supports two ways of instrumenting a pod. In most cases, it's easiest to mark the Kubernetes namespace
containing your application with the istio -injection label:
kubectl label namespace <my-app-namespace> istio-injection=enabled
NOTE
Since service mesh lifts data off the wire, we cannot intercept the encrypted traffic. For traffic that doesn't leave the cluster,
use an unencrypted protocol (for example, HTTP). For external traffic that must be encrypted, consider setting up SSL
termination at the ingress controller.
Applications running outside of the service mesh are not affected.

Deploy your application
Deploy your application to my-app -namespace namespace. If the application is already deployed, and you have
followed the automatic sidecar injection method described above, you need to recreate pods to ensure Istio
injects its sidecar; either initiate a rolling update or delete individual pods and wait for them to be recreated.
Ensure your application complies with Istio requirements.
Deploy zero instrumentation application monitoring for Kubernetes hosted apps
1. Download and extract an Application Insights adapter release.
2. Navigate to /src/kubernetes/ inside the release folder.
3. Edit application-insights-istio -mixer-adapter-deployment.yaml
edit the value of ISTIO_MIXER_PLUGIN_AI_INSTRUMENTATIONKEY environment variable to contain
the instrumentation key of the Application Insights resource in Azure portal to contain the telemetry.
If necessary, edit the value of ISTIO_MIXER_PLUGIN_WATCHLIST_NAMESPACES environment variable
to contain a comma-separated list of namespaces for which you would like to enable monitoring. Leave it
blank to monitor all namespaces.
4. Apply every YAML file found under src/kubernetes/ by running the following (you must still be inside
/src/kubernetes/):
kubectl apply -f .
Verify deployment
Ensure Application Insights adapter has been deployed:
kubectl get pods -n istio-system -l "app=application-insights-istio-mixer-adapter"

NOTE
In some cases, fine-tuning tuning is required. To include or exclude telemetry for an individual pod from being collected, use
appinsights/monitoring.enabled label on that pod. This will have priority over all namespace-based configuration. Set
appinsights/monitoring.enabled to true to include the pod, and to false to exclude it.
View Application Insights telemetry

Generate a sample request against your application to confirm that monitoring is functioning properly.
Within 3-5 minutes, you should start seeing telemetry appear in the Azure portal. Be sure to check out the
Application Map section of your Application Insights resource in the Portal.
Troubleshooting
Below is the troubleshooting flow to use when telemetry doesn't appear in the Azure portal as expected.
1. Ensure the application is under load and is sending/receiving requests in plain HTTP. Since telemetry is
lifted off the wire, encrypted traffic is not supported. If there are no incoming or outgoing requests, there
will be no telemetry either.
2. Ensure the correct instrumentation key is provided in the
ISTIO_MIXER_PLUGIN_AI_INSTRUMENTATIONKEY environment variable in application-insights-istio -
mixer-adapter-deployment.yaml. The instrumentation key is found on the Overview tab of the Application
Insights resource in the Azure portal.
3. Ensure the correct Kubernetes namespace is provided in the
ISTIO_MIXER_PLUGIN_WATCHLIST_NAMESPACES environment variable in application-insights-istio -
mixer-adapter-deployment.yaml. Leave it blank to monitor all namespaces.
4. Ensure your application's pods have been sidecar-injected by Istio. Verify that Istio's sidecar exists on each
pod.
kubectl describe pod -n <my-app-namespace> <my-app-pod-name>
Verify that there is a container named istio -proxy running on the pod.
5. View the Application Insights adapter’s traces.
kubectl get pods -n istio-system -l "app=application-insights-istio-mixer-adapter"

kubectl logs -n istio-system application-insights-istio-mixer-adapter-<fill in from previous command
output>
The count of received telemetry items is updated once a minute. If it doesn't grow minute over minute - no
telemetry is being sent to the adapter by Istio. Look for any errors in the log.
6. If it has been established that Application Insight for Kubernetes adapter is not being fed telemetry, check
Istio's Mixer logs to figure out why it's not sending data to the adapter:
kubectl get pods -n istio-system -l "istio=mixer,app=telemetry"

kubectl logs -n istio-system istio-telemetry-<fill in from previous command output> -c mixer
Look for any errors, especially pertaining to communications with applicationinsightsadapter adapter.
FAQ
For the latest info for the progress on this project, visit the Application Insights adapter for Istio Mixer project's
GitHub.
Uninstall
To uninstall the product, for every YAML file found under src/kubernetes/ run:
kubectl delete -f <filename.yaml>
Next steps
To learn more about how Azure Monitor and containers work together visit Azure Monitor for containers overview
Instrument web apps at runtime with Application
Insights Codeless Attach
You can instrument a live web app with Azure Application Insights, without having to modify or redeploy your
code. You need a Microsoft Azure subscription.
Status Monitor is used to instrument a .NET application hosted in IIS either on-premises or in a VM.
If your app is deployed into Azure VM or Azure virtual machine scale set, follow these instructions.
If your app is deployed into Azure app services, follow these instructions.
If your app is deployed in an Azure VM, you can switch on Application Insights monitoring from the Azure
control panel.
(There are also separate articles about instrumenting Azure Cloud Services.)
You have a choice of two routes to apply Application Insights to your .NET web applications:
Build time: Add the Application Insights SDK to your web app code.
Run time: Instrument your web app on the server, as described below, without rebuilding and redeploying
the code.
NOTE
If you use build time instrumentation, run time instrumention will not work even if it is turned on.
Here's a summary of what you get by each route:
BUILD TIME RUN TIME
Requests & exceptions Yes Yes
More detailed exceptions Yes
Dependency diagnostics On .NET 4.6+, but less detail Yes, full detail: result codes, SQL
command text, HTTP verb
System performance counters Yes Yes
API for custom telemetry Yes No

BUILD TIME RUN TIME
Trace log integration Yes No
Page view & user data Yes No
Need to rebuild code Yes No
Monitor a live IIS web app

If your app is hosted on an IIS server, enable Application Insights by using Status Monitor.
1. On your IIS web server, sign in with administrator credentials.
2. If Application Insights Status Monitor is not already installed, download and run the installer
3. In Status Monitor, select the installed web application or website that you want to monitor. Sign in with
your Azure credentials.
Configure the resource where you want to see the results in the Application Insights portal. (Normally,
it's best to create a new resource. Select an existing resource if you already have web tests or client
monitoring for this app.)
4. Restart IIS.
Your web service is interrupted for a short while.
Customize monitoring options

Enabling Application Insights adds DLLs and ApplicationInsights.config to your web app. You can edit the
.config file to change some of the options.
When you re-publish your app, re-enable Application Insights

Before you re-publish your app, consider adding Application Insights to the code in Visual Studio. You'll get
more detailed telemetry and the ability to write custom telemetry.
If you want to re-publish without adding Application Insights to the code, be aware that the deployment
process may delete the DLLs and ApplicationInsights.config from the published web site. Therefore:
1. If you edited ApplicationInsights.config, take a copy of it before you re-publish your app.
2. Republish your app.
3. Re-enable Application Insights monitoring. (Use the appropriate method: either the Azure web app control
panel, or the Status Monitor on an IIS host.)
4. Reinstate any edits you performed on the .config file.
Troubleshooting
Confirm a valid installation
These are some steps that you can perform to confirm that your installation was successful.
Confirm that the applicationInsights.config file is present in the target app directory and contains your
ikey.
If you suspect that data is missing you can run a simple query in Analytics to list all the cloud roles
currently sending telemetry.
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
If you need to confirm that Application Insights is successfully attached you can run Sysinternals
Handle in a command window to confirm that applicationinsights.dll has been loaded by IIS.
handle.exe /p w3wp.exe
Can't connect? No telemetry?

Open the necessary outgoing ports in your server's firewall to allow Status Monitor to work.
Unable to login
If Status Monitor cannot login, do a command line install instead. Status Monitor attempts to login to
collect your ikey, but you can provide this manually using the command:
Import-Module 'C:\Program Files\Microsoft Application Insights\Status

Monitor\PowerShell\Microsoft.Diagnostics.Agent.StatusMonitor.PowerShell.dll'
Start-ApplicationInsightsMonitoring -Name appName -InstrumentationKey 00000000-000-000-000-0000000
Could not load file or assembly 'System.Diagnostics.DiagnosticSource'

You may get this error after enabling Application Insights. This is because the installer replaces this dll in your
bin directory. To fix update your web.config:
<dependentAssembly>
<assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51"/>
<bindingRedirect oldVersion="0.0.0.0-4.*.*.*" newVersion="4.0.2.1"/>
</dependentAssembly>
We are tracking this issue here.

Application diagnostic messages
Open Status Monitor and select your application on left pane. Check if there are any diagnostics
messages for this application in the "Configuration notifications" section:
Detailed logs
By default Status Monitor will output diagnostic logs at:
C:\Program Files\Microsoft Application Insights\Status Monitor\diagnostics.log
To output verbose logs, modify the config file:

C:\Program Files\Microsoft Application Insights\Status
Monitor\Microsoft.Diagnostics.Agent.StatusMonitor.exe.config
and add <add key="TraceLevel" value="All" /> to the appsettings . Then restart status monitor.
As Status Monitor is a .NET application you can also enable .net tracing by adding the appropriate
diagnostics to the config file. For example, in some scenarios it can be useful to see what's happening at
the network level by configuring network tracing
Insufficient permissions
On the server, if you see a message about "insufficient permissions", try the following:
In IIS Manager, select your application pool, open Advanced Settings, and under Process Model
note the identity.
In Computer management control panel, add this identity to the Performance Monitor Users group.
Conflict with Systems Center Operations Manager
If you have MMA/SCOM (Systems Center Operations Manager) installed on your server, some versions
can conflict. Uninstall both SCOM and Status Monitor, and re-install the latest versions.
Failed or incomplete installation
If Status Monitor fails during an installation, you could be left with an incomplete install that Status Monitor is
unable to recover from. This will require a manual reset.
Delete any of these files found in your application directory:
Any DLLs in your bin directory starting with either "Microsoft.AI." or "Microsoft.ApplicationInsights.".
This DLL in your bin directory "Microsoft.Web.Infrastructure.dll"
This DLL in your bin directory "System.Diagnostics.DiagnosticSource.dll"
In your application directory remove "App_Data\packages"
In your application directory remove "applicationinsights.config"
Additional Troubleshooting
See Additional Troubleshooting.
System Requirements
OS support for Application Insights Status Monitor on Server:
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows server 2012 R2
Windows Server 2016
with latest SP and .NET Framework 4.5 (Status Monitor is built on this version of the framework)
On the client side: Windows 7, 8, 8.1 and 10, again with .NET Framework 4.5
IIS support is: IIS 7, 7.5, 8, 8.5 (IIS is required)
Automation with PowerShell

You can start and stop monitoring by using PowerShell on your IIS server.
First import the Application Insights module:
Import-Module 'C:\Program Files\Microsoft Application Insights\Status
Monitor\PowerShell\Microsoft.Diagnostics.Agent.StatusMonitor.PowerShell.dll'
Find out which apps are being monitored:

Get-ApplicationInsightsMonitoringStatus [-Name appName]
-Name (Optional) The name of a web app.

Displays the Application Insights monitoring status for each web app (or the named app) in this IIS
server.
Returns ApplicationInsightsApplication for each app:
SdkState==EnabledAfterDeployment : App is being monitored, and was instrumented at run time,
either by the Status Monitor tool, or by Start-ApplicationInsightsMonitoring .
SdkState==Disabled : The app is not instrumented for Application Insights. Either it was never
instrumented, or run-time monitoring was disabled with the Status Monitor tool or with
Stop-ApplicationInsightsMonitoring .
SdkState==EnabledByCodeInstrumentation : The app was instrumented by adding the SDK to the
source code. Its SDK cannot be updated or stopped.
SdkVersion shows the version in use for monitoring this app.
LatestAvailableSdkVersion shows the version currently available on the NuGet gallery. To upgrade
the app to this version, use Update-ApplicationInsightsMonitoring .
Start-ApplicationInsightsMonitoring -Name appName -InstrumentationKey 00000000-000-000-000-0000000
-Name The name of the app in IIS

-InstrumentationKey The ikey of the Application Insights resource where you want the results to be
displayed.
This cmdlet only affects apps that are not already instrumented - that is, SdkState==NotInstrumented.
The cmdlet does not affect an app that is already instrumented. It does not matter whether the app was
instrumented at build time by adding the SDK to the code, or at run time by a previous use of this
cmdlet.
The SDK version used to instrument the app is the version that was most recently downloaded to this
server.
To download the latest version, use Update-ApplicationInsightsVersion.
Returns ApplicationInsightsApplication on success. If it fails, it logs a trace to stderr.
Name : Default Web Site/WebApp1

InstrumentationKey : 00000000-0000-0000-0000-000000000000
ProfilerState : ApplicationInsights
SdkState : EnabledAfterDeployment
SdkVersion : 1.2.1
LatestAvailableSdkVersion : 1.2.3
Stop-ApplicationInsightsMonitoring [-Name appName | -All]
-Name The name of an app in IIS

-All Stops monitoring all apps in this IIS server for which SdkState==EnabledAfterDeployment
Stops monitoring the specified apps and removes instrumentation. It only works for apps that have been
instrumented at run-time using the Status Monitoring tool or Start-ApplicationInsightsApplication. (
SdkState==EnabledAfterDeployment )
Returns ApplicationInsightsApplication.
Update-ApplicationInsightsMonitoring -Name appName [-InstrumentationKey "0000000-0000-000-000-0000" ]
-Name : The name of a web app in IIS.
-InstrumentationKey ( Optional.) Use this to change the resource to which the app's telemetry is sent.
This cmdlet:
Upgrades the named app to the version of the SDK most recently downloaded to this machine.
(Only works if SdkState==EnabledAfterDeployment )
If you provide an instrumentation key, the named app is reconfigured to send telemetry to the
resource with that key. (Works if SdkState != Disabled )
Update-ApplicationInsightsVersion
Downloads the latest Application Insights SDK to the server.
Questions about Status Monitor

What is Status Monitor?
A desktop application that you install in your IIS web server. It helps you instrument and configure web apps.
When do I use Status Monitor?
To instrument any web app that is running on your IIS server - even if it is already running.
To enable additional telemetry for web apps that have been built with the Application Insights SDK at
compile time.
Can I close it after it runs?
Yes. After it has instrumented the websites you select, you can close it.
It doesn't collect telemetry by itself. It just configures the web apps and sets some permissions.
What does Status Monitor do?
When you select a web app for Status Monitor to instrument:
Downloads and places the Application Insights assemblies and ApplicationInsights.config file in the web
app's binaries folder.
Enables CLR profiling to collect dependency calls.
What version of Application Insights SDK does Status Monitor install?
As of now, Status Monitor can only install Application Insights SDK versions 2.3 or 2.4.
The Application Insights SDK Version 2.4 is the last version to support .NET 4.0 which was EOL January
2016. Therefore, as of now Status Monitor can be used to instrument a .NET 4.0 application.
Do I need to run Status Monitor whenever I update the app?
Not if you redeploy incrementally.
If you select the 'delete existing files' option in the publish process, you would need to re-run Status Monitor
to configure Application Insights.
What telemetry is collected?
For applications that you instrument only at run-time by using Status Monitor:
HTTP requests
Calls to dependencies
Exceptions
For applications already instrumented at compile time:
Process counters.
Dependency calls (.NET 4.5); return values in dependency calls (.NET 4.6).
Exception stack trace values.
Learn more
Video
Download Status Monitor

Use the new PowerShell Module
Download and run the Status Monitor installer
Or run Web Platform Installer and search in it for Application Insights Status Monitor.
Next steps
View your telemetry:
Explore metrics to monitor performance and usage
Search events and logs to diagnose problems
Analytics for more advanced queries
Add more telemetry:
Create web tests to make sure your site stays live.
Add web client telemetry to see exceptions from web page code and to let you insert trace calls.
Add Application Insights SDK to your code so that you can insert trace and log calls
Status Monitor v2
Status Monitor v2 is a PowerShell module published to the PowerShell Gallery. It replaces Status Monitor. The
module provides codeless instrumentation of .NET web apps hosted with IIS. Telemetry is sent to the Azure portal,
where you can monitor your app.
PowerShell Gallery
Status Monitor v2 is located here: https://www.powershellgallery.com/packages/Az.ApplicationMonitor.
C U R R E NT V E R S I O N V 1.0.1
Instructions
See the getting started instructions to get a start with concise code samples.
See the detailed instructions for a deep dive on how to get started.
PowerShell API reference

Disable-ApplicationInsightsMonitoring
Disable-InstrumentationEngine
Enable-ApplicationInsightsMonitoring
Enable-InstrumentationEngine
Get-ApplicationInsightsMonitoringConfig
Get-ApplicationInsightsMonitoringStatus
Set-ApplicationInsightsMonitoringConfig
Start-ApplicationInsightsMonitoringTrace
Troubleshooting
Troubleshooting
Known issues
FAQ
Does Status Monitor v2 support proxy installations?
Yes. There are multiple ways to download Status Monitor v2. If your computer has internet access, you can
onboard to the PowerShell Gallery by using -Proxy parameters. You can also manually download the
module and either install it on your computer or use it directly. Each of these options is described in the
detailed instructions.
Does Status Monitor v2 support ASP.NET Core applications?
No. For instructions to enable monitoring of ASP.NET Core applications, see Application Insights for
ASP.NET Core applications. There's no need to install StatusMonitor for an ASP.NET Core application. This
is true even if ASP.NET Core application is hosted in IIS.
Does Status Monitor v2 support ASP.NET Core applications?
No. Please follow these instructions to enable monitoring for ASP.NET Core Applications. There is no need to
install StatusMonitor for an ASP.NET Core Application. This is true even if ASP.NET Core Application is hosted in
IIS.
How do I verify that the enablement succeeded?
The Get-ApplicationInsightsMonitoringStatus cmdlet can be used to verify that enablement
succeeded.
We recommend you use Live Metrics to quickly determine if your app is sending telemetry.
You can also use Log Analytics to list all the cloud roles currently sending telemetry:
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
Next steps
Explore metrics to monitor performance and usage.
Search events and logs to diagnose problems.
Use Analytics for more advanced queries.
Create dashboards.
Add more telemetry:
Add web client telemetry to see exceptions from web page code and to enable trace calls.
Add the Application Insights SDK to your code so you can insert trace and log calls.
Get started with Status Monitor v2
This article contains the quickstart commands expected to work for most environments. The instructions depend
on the PowerShell Gallery to distribute updates. These commands support the PowerShell -Proxy parameter.
For an explanation of these commands, customization instructions, and information about troubleshooting, see the
detailed instructions.
Download and install via PowerShell Gallery

Install prerequisites
Run PowerShell as Admin.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
Install-Module -Name PowerShellGet -Force
Close PowerShell.
Install Status Monitor v2
Run PowerShell as Admin.

Install-Module -Name Az.ApplicationMonitor -AllowPrerelease -AcceptLicense
Enable monitoring

Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Download and install manually (offline option)

Download the module
Manually download the latest version of the module from PowerShell Gallery.
Unzip and install Status Monitor v2
$pathToNupkg = "C:\Users\t\Desktop\Az.ApplicationMonitor.0.3.0-alpha.nupkg"
$pathToZip = ([io.path]::ChangeExtension($pathToNupkg, "zip"))
$pathToNupkg | rename-item -newname $pathToZip
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\Az.ApplicationMonitor"
Expand-Archive -LiteralPath $pathToZip -DestinationPath $pathInstalledModule
Enable monitoring
Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Next steps
Create dashboards.
Add more telemetry:
Do more with Status Monitor v2:
Review the detailed instructions for an explanation of the commands found here.
Use our guide to troubleshoot Status Monitor v2.
Status Monitor v2: Detailed instructions
This article describes how to onboard to the PowerShell Gallery and download the ApplicationMonitor module.
Included are the most common parameters that you'll need to get started. We've also provided manual download
instructions in case you don't have internet access.
Get an instrumentation key

To get started, you need an instrumentation key. For more information, see Create an Application Insights
resource.
Run PowerShell as Admin with an elevated execution policy

Run as Admin
PowerShell needs Administrator-level permissions to make changes to your computer.
Execution policy
Description: By default, running PowerShell scripts is disabled. We recommend allowing RemoteSigned scripts
for only the Current scope.
Reference: About Execution Policies and Set-ExecutionPolicy.
Command: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process .
Optional parameter:
-Force . Bypasses the confirmation prompt.
Example errors
Install-Module : The 'Install-Module' command was found in the module 'PowerShellGet', but the module could
not be
loaded. For more information, run 'Import-Module PowerShellGet'.
Import-Module : File C:\Program Files\WindowsPowerShell\Modules\PackageManagement\1.3.1\PackageManagement.psm1

cannot
be loaded because running scripts is disabled on this system. For more information, see
about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
Prerequisites for PowerShell

Audit your instance of PowerShell by running the $PSVersionTable command. This command produces the
following output:
Name Value
---- -----
PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
These instructions were written and tested on a computer running Windows 10 and the versions listed above.
Prerequisites for PowerShell Gallery

These steps will prepare your server to download modules from PowerShell Gallery.
NOTE
PowerShell Gallery is supported on Windows 10, Windows Server 2016, and PowerShell 6. For information about earlier
versions, see Installing PowerShellGet.
1. Run PowerShell as Admin with an elevated execution policy.

2. Install the NuGet package provider.
Description: You need this provider to interact with NuGet-based repositories like PowerShell Gallery.
Reference: Install-PackageProvider.
Command: Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 .
Optional parameters:
-Proxy . Specifies a proxy server for the request.
-Force . Bypasses the confirmation prompt.
You'll receive this prompt if NuGet isn't set up:
NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based
repositories. The NuGet
provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\t\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet
provider by running
'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to
install and import
the NuGet provider now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):
3. Configure PowerShell Gallery as a trusted repository.

Description: By default, PowerShell Gallery is an untrusted repository.
Reference: Set-PSRepository.
Command: Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted .
Optional parameter:
You'll receive this prompt if PowerShell Gallery isn't trusted:
Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the
modules from
'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):
You can confirm this change and audit all PSRepositories by running the Get-PSRepository command.
4. Install the newest version of PowerShellGet.
Description: This module contains the tooling used to get other modules from PowerShell Gallery.
Version 1.0.0.1 ships with Windows 10 and Windows Server. Version 1.6.0 or higher is required. To
determine which version is installed, run the Get-Command -Module PowerShellGet command.
Reference: Installing PowerShellGet.
Command: Install-Module -Name PowerShellGet .
-Force . Bypasses the "already installed" warning and installs the latest version.
You'll receive this error if you're not using the newest version of PowerShellGet:
Install-Module : A parameter cannot be found that matches parameter name 'AllowPrerelease'.

At line:1 char:20
Install-Module abc -AllowPrerelease
~~~~~~~~~~~~~~~~
CategoryInfo : InvalidArgument: (:) [Install-Module], ParameterBindingException
FullyQualifiedErrorId : NamedParameterNotFound,Install-Module
5. Restart PowerShell. You can't load the new version in the current session. New PowerShell sessions will
load the latest version of PowerShellGet.
Download and install the module via PowerShell Gallery

These steps will download the Az.ApplicationMonitor module from PowerShell Gallery.
1. Ensure that all prerequisites for PowerShell Gallery are met.
3. Install the Az.ApplicationMonitor module.
Reference: Install-Module.
Command: Install-Module -Name Az.ApplicationMonitor .
-AllowPrerelease . Allows installation of alpha and beta releases.
-AcceptLicense . Bypasses the "Accept License" prompt
-Force . Bypasses the "Untrusted Repository" warning.
Download and install the module manually (offline option)

If for any reason you can't connect to the PowerShell module, you can manually download and install the
Az.ApplicationMonitor module.
Manually download the latest nupkg file
1. Go to https://www.powershellgallery.com/packages/Az.ApplicationMonitor.
2. Select the latest version of the file in the Version History table.
3. Under Installation Options, select Manual Download.
Option 1: Install into a PowerShell modules directory
Install the manually downloaded PowerShell module into a PowerShell directory so it will be discoverable by
PowerShell sessions. For more information, see Installing a PowerShell Module.
Unzip nupkg as a zip file by using Expand-Archive (v1.0.1.0)
Description: The base version of Microsoft.PowerShell.Archive (v1.0.1.0) can't unzip nupkg files. Rename
the file with the .zip extension.
Reference: Expand-Archive.
Command:
$pathToNupkg = "C:\az.applicationmonitor.0.3.0-alpha.nupkg"
$pathToZip = ([io.path]::ChangeExtension($pathToNupkg, "zip"))
$pathToNupkg | rename-item -newname $pathToZip
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\az.applicationmonitor"
Expand-Archive -LiteralPath $pathToZip -DestinationPath $pathInstalledModule
Unzip nupkg by using Expand-Archive (v1.1.0.0)

Description: Use a current version of Expand-Archive to unzip nupkg files without changing the extension.
Reference: Expand-Archive and Microsoft.PowerShell.Archive.
Command:
$pathToNupkg = "C:\az.applicationmonitor.0.2.1-alpha.nupkg"
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\az.applicationmonitor"
Expand-Archive -LiteralPath $pathToNupkg -DestinationPath $pathInstalledModule
Option 2: Unzip and import nupkg manually

Install the manually downloaded PowerShell module into a PowerShell directory so it will be discoverable by
PowerShell sessions. For more information, see Installing a PowerShell Module.
If you're installing the module into any other directory, manually import the module by using Import-Module.
IMPORTANT
DLLs will install via relative paths. Store the contents of the package in your intended runtime directory and confirm that
access permissions allow read but not write.
1. Change the extension to ".zip" and extract the contents of the package into your intended installation directory.
2. Find the file path of Az.ApplicationMonitor.psd1.
4. Load the module by using the Import-Module Az.ApplicationMonitor.psd1 command.
Route traffic through a proxy

When you monitor a computer on your private intranet, you'll need to route HTTP traffic through a proxy.
The PowerShell commands to download and install Az.ApplicationMonitor from the PowerShell Gallery support a
-Proxy parameter. Review the preceding instructions when you write your installation scripts.
The Application Insights SDK will need to send your app's telemetry to Microsoft. We recommend that you
configure proxy settings for your app in your web.config file. For more information, see Application Insights FAQ:
Proxy passthrough.
Enable monitoring
Use the Enable-ApplicationInsightsMonitoring command to enable monitoring.
See the API reference for a detailed description of how to use this cmdlet.
Next steps
Create dashboards.
Add more telemetry:
Troubleshooting Status Monitor v2
When you enable monitoring, you might experience issues that prevent data collection. This article lists all known
issues and provides troubleshooting examples. If you come across an issue that's not listed here, you can contact
us on GitHub.
Known issues
Conflicting DLLs in an app's bin directory
If any of these DLLs are present in the bin directory, monitoring might fail:
Microsoft.ApplicationInsights.dll
Microsoft.AspNet.TelemetryCorrelation.dll
System.Diagnostics.DiagnosticSource.dll
Some of these DLLs are included in the Visual Studio default app templates, even if your app doesn't use them.
You can use troubleshooting tools to see symptomatic behavior:
PerfView:
ThreadID="7,500"
ProcessorNumber="0"
msg="Found 'System.Diagnostics.DiagnosticSource, Version=4.0.2.1, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' assembly, skipping attaching redfield binaries"
ExtVer="2.8.13.5972"
SubscriptionId=""
AppName=""
FormattedMessage="Found 'System.Diagnostics.DiagnosticSource, Version=4.0.2.1, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' assembly, skipping attaching redfield binaries"
IISReset and app load (without telemetry). Investigate with Sysinternals (Handle.exe and ListDLLs.exe):
.\handle64.exe -p w3wp | findstr /I "InstrumentationEngine AI. ApplicationInsights"

E54: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Re
dfieldIISModule.dll
.\Listdlls64.exe w3wp | findstr /I "InstrumentationEngine AI ApplicationInsights"

0x0000000009be0000 0x127000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\MicrosoftInstrumentati
onEngine_x64.dll
0x0000000009b90000 0x4f000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.ApplicationI
nsights.ExtensionsHost_x64.dll
0x0000000004d20000 0xb2000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.ApplicationI
nsights.Extensions.Base_x64.dll
Conflict with IIS shared configuration

If you have a cluster of web servers, you might be using a shared configuration. The HttpModule can't be injected
into this shared configuration. Run the Enable command on each web server to install the DLL into each server's
GAC.
After you run the Enable command, complete these steps:
1. Go to the shared configuration directory and find the applicationHost.config file.
2. Add this line to the modules section of your configuration:
<modules>

<add name="ManagedHttpModuleHelper"
type="Microsoft.AppInsights.IIS.ManagedHttpModuleHelper.ManagedHttpModuleHelper,
Microsoft.AppInsights.IIS.ManagedHttpModuleHelper, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler,runtimeVersionv4.0" />
</modules>
IIS Nested Applications

We don't instrument nested applications in IIS in version 1.0. We're tracking this issue here.
Advanced SDK Configuration isn't available.
The SDK configuration isn't exposed to the end user in version 1.0. We're tracking this issue here.
Troubleshooting
Troubleshooting PowerShell
Determine which modules are available
You can use the Get-Module -ListAvailable command to determine which modules are installed.
Import a module into the current session
If a module hasn't been loaded into a PowerShell session, you can manually load it by using the
Import-Module <path to psd1> command.
Troubleshooting the Status Monitor v2 module

List the commands available in the Status Monitor v2 module
Run the command Get-Command -Module Az.ApplicationMonitor to get the available commands:
CommandType Name Version Source

----------- ---- ------- ------
Cmdlet Disable-ApplicationInsightsMonitoring 0.4.0 Az.ApplicationMonitor
Cmdlet Disable-InstrumentationEngine 0.4.0 Az.ApplicationMonitor
Cmdlet Enable-ApplicationInsightsMonitoring 0.4.0 Az.ApplicationMonitor
Cmdlet Enable-InstrumentationEngine 0.4.0 Az.ApplicationMonitor
Cmdlet Get-ApplicationInsightsMonitoringConfig 0.4.0 Az.ApplicationMonitor
Cmdlet Get-ApplicationInsightsMonitoringStatus 0.4.0 Az.ApplicationMonitor
Cmdlet Set-ApplicationInsightsMonitoringConfig 0.4.0 Az.ApplicationMonitor
Cmdlet Start-ApplicationInsightsMonitoringTrace 0.4.0 Az.ApplicationMonitor
Determine the current version of the Status Monitor v2 module

Run the Get-ApplicationInsightsMonitoringStatus -PowerShellModule command to display the following
information about the module:
PowerShell module version
Application Insights SDK version
File paths of the PowerShell module
Review the API reference for a detailed description of how to use this cmdlet.
Troubleshooting running processes
You can inspect the processes on the instrumented computer to determine if all DLLs are loaded. If monitoring is
working, at least 12 DLLs should be loaded.
Use the Get-ApplicationInsightsMonitoringStatus -InspectProcess command to check the DLLs.
Review the API reference for a detailed description of how to use this cmdlet.
Collect ETW logs by using PerfView
Setup
1. Download PerfView.exe and PerfView64.exe from GitHub.
2. Start PerfView64.exe.
3. Expand Advanced Options.
4. Clear these check boxes:
Zip
Merge
.NET Symbol Collection
5. Set these Additional Providers:
61f6ca3b-4b5f-5602-fa60-759a2a2d1fbd,323adc25-e39b-5c87-8658-2c1af1a92dc5,925fa42b-9ef6-5fa7-10b8-
56449d7a2040,f7d60e07-e910-5aca-bdd2-9de45b46c560,7c739bb9-7861-412e-ba50-bf30d95eae36,61f6ca3b-4b5f-5602-
fa60-759a2a2d1fbd,323adc25-e39b-5c87-8658-2c1af1a92dc5,252e28f4-43f9-5771-197a-e8c7e750a984
Collecting logs
1. In a command console with Admin privileges, run the iisreset /stop command to turn off IIS and all web
apps.
2. In PerfView, select Start Collection.
3. In a command console with Admin privileges, run the iisreset /start command to start IIS.
4. Try to browse to your app.
5. After your app is loaded, return to PerfView and select Stop Collection.
Next steps
Review the API reference to learn about parameters you might have missed.
If you come across an issue that's not listed here, you can contact us on GitHub.
Status Monitor v2 API: Disable-
InstrumentationEngine
This article describes a cmdlet that's a member of the Az.ApplicationMonitor PowerShell module.
Description
Disables the instrumentation engine by removing some registry keys. Restart IIS for the changes to take effect.
IMPORTANT
This cmdlet requires a PowerShell session with Admin permissions.
Examples
PS C:\> Disable-InstrumentationEngine
Parameters
-Verbose
Common parameter. Use this switch to output detailed logs.
Output
Example output from successfully disabling the instrumentation engine
Configuring IIS Environment for instrumentation engine...

Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN[Environment]'
Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC[Environment]'
Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS[Environment]'
Configuring registry for instrumentation engine...
Next steps
Status Monitor v2 API: Disable-
ApplicationInsightsMonitoring
Description
Disables monitoring on the target computer. This cmdlet will remove edits to the IIS applicationHost.config and
remove registry keys.
IMPORTANT
Examples
PS C:\> Disable-ApplicationInsightsMonitoring
Parameters
-Verbose
Common parameter. Use this switch to display detailed logs.
Output
Example output from successfully disabling monitoring
Initiating Disable Process

Applying transformation to 'C:\Windows\System32\inetsrv\config\applicationHost.config'
'C:\Windows\System32\inetsrv\config\applicationHost.config' backed up to
'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-00z'
in :1,237
No element in the source document matches
'/configuration/location[@path='']/system.webServer/modules/add[@name='ManagedHttpModuleHelper']'
Not executing RemoveAll (transform line 1, 546)
Transformation to 'C:\Windows\System32\inetsrv\config\applicationHost.config' was successfully applied.
Operation: 'disable'
GAC Module will not be removed, since this operation might cause IIS instabilities
Configuring IIS Environment for codeless attach...
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN[Environment]
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC[Environment]
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS[Environment]
Successfully disabled Application Insights Status Monitor
Next steps
Status Monitor v2 API: Enable-InstrumentationEngine
Description
Enables the instrumentation engine by setting some registry keys. Restart IIS for the changes to take effect.
The instrumentation engine can supplement data collected by the .NET SDKs. It collects events and messages that
describe the execution of a managed process. These events and messages include dependency result codes, HTTP
verbs, and SQL command text.
Enable the instrumentation engine if:
You've already enabled monitoring with the Enable cmdlet but didn't enable the instrumentation engine.
You've manually instrumented your app with the .NET SDKs and want to collect additional telemetry.
IMPORTANT
NOTE
This cmdlet requires that you review and accept our license and privacy statement.
The instrumentation engine adds additional overhead and is off by default.
Examples
PS C:\> Enable-InstrumentationEngine
Parameters
-AcceptLicense
Optional. Use this switch to accept the license and privacy statement in headless installations.
-Verbose
Output
Example output from successfully enabling the instrumentation engine

Next steps
Use analytics for more advanced queries.
Create dashboards.
Add more telemetry:
Get the config to confirm that your settings were recorded correctly.
Get the status to inspect monitoring.
Status Monitor v2 API: Enable-
ApplicationInsightsMonitoring
Description
Enables codeless attach monitoring of IIS apps on a target computer.
This cmdlet will modify the IIS applicationHost.config and set some registry keys. It will also create an
applicationinsights.ikey.config file, which defines the instrumentation key used by each app. IIS will load the
RedfieldModule on startup, which will inject the Application Insights SDK into applications as the applications
start. Restart IIS for your changes to take effect.
After you enable monitoring, we recommend that you use Live Metrics to quickly check if your app is sending us
telemetry.
NOTE
To get started, you need an instrumentation key. For more information, see Create a resource.
This cmdlet requires that you review and accept our license and privacy statement.
IMPORTANT
This cmdlet requires a PowerShell session with Admin permissions and an elevated execution policy. For more information,
see Run PowerShell as administrator with an elevated execution policy.
Examples
Example with a single instrumentation key
In this example, all apps on the current computer are assigned a single instrumentation key.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Example with an instrumentation key map

In this example:
MachineFilter matches the current computer by using the '.*' wildcard.
AppFilter='WebAppExclude' provides a null instrumentation key. The specified app won't be instrumented.
AppFilter='WebAppOne' assigns the specified app a unique instrumentation key.
AppFilter='WebAppTwo' assigns the specified app a unique instrumentation key.
Finally, AppFilter also uses the '.*' wildcard to match all web apps that aren't matched by the earlier rules
and assign a default instrumentation key.
Spaces are added for readability.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKeyMap
@(@{MachineFilter='.*';AppFilter='WebAppExclude'},
@{MachineFilter='.*';AppFilter='WebAppOne';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxxxxxxx1'}},
@{MachineFilter='.*';AppFilter='WebAppTwo';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxxxxxxx2'}},
@{MachineFilter='.*';AppFilter='.*';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxdefault'}})
Parameters
-InstrumentationKey
Required. Use this parameter to supply a single instrumentation key for use by all apps on the target computer.
-InstrumentationKeyMap
Required. Use this parameter to supply multiple instrumentation keys and a mapping of the instrumentation keys
used by each app. You can create a single installation script for several computers by setting MachineFilter .
IMPORTANT
Apps will match against rules in the order that the rules are provided. So you should specify the most specific rules first and
the most generic rules last.
Schema
@(@{MachineFilter='.*';AppFilter='.*';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx'}})
MachineFilter is a required C# regex of the computer or VM name.

'.*' will match all
'ComputerName' will match only computers with the exact name specified.
AppFilter is a required C# regex of the IIS Site Name. You can get a list of sites on your server by running the
command get-iissite.
'.*' will match all
'SiteName' will match only the IIS Site with the exact name specified.
InstrumentationKey is required to enable monitoring of apps that match the preceding two filters.
Leave this value null if you want to define rules to exclude monitoring.
-EnableInstrumentationEngine
Optional. Use this switch to enable the instrumentation engine to collect events and messages about what's
happening during the execution of a managed process. These events and messages include dependency result
codes, HTTP verbs, and SQL command text.
The instrumentation engine adds overhead and is off by default.
-AcceptLicense
Optional. Use this switch to accept the license and privacy statement in headless installations.
-IgnoreSharedConfig
When you have a cluster of web servers, you might be using a shared configuration. The HttpModule can't be
injected into this shared configuration. This script will fail with the message that extra installation steps are
required. Use this switch to ignore this check and continue installing prerequisites. For more information, see
known conflict-with-iis-shared-configuration
-Verbose
-WhatIf
Common parameter. Use this switch to test and validate your input parameters without actually enabling
monitoring.
Output
Example output from a successful enablement
Initiating Disable Process

'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-52z'
in :1,237
No element in the source document matches
'/configuration/location[@path='']/system.webServer/modules/add[@name='ManagedHttpModuleHelper']'
Not executing RemoveAll (transform line 1, 546)
Operation: 'disable'
GAC Module will not be removed, since this operation might cause IIS instabilities
Successfully disabled Application Insights Status Monitor
Installing GAC module 'C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\0.2.0\content\Runtime\Microsoft.AppInsights.IIS.ManagedH
ttpModuleHelper.dll'
Found GAC module Microsoft.AppInsights.IIS.ManagedHttpModuleHelper.ManagedHttpModuleHelper,
Microsoft.AppInsights.IIS.ManagedHttpModuleHelper, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-52z_1'
Operation: 'enable'
Updating app pool permissions...
Successfully enabled Application Insights Status Monitor
Next steps
Create dashboards.
Add more telemetry:
Status Monitor v2 API: Get-
ApplicationInsightsMonitoringConfig
Description
Gets the config file and prints the values to the console.
IMPORTANT
Examples
PS C:\> Get-ApplicationInsightsMonitoringConfig
Parameters
No parameters required.
Output
Example output from reading the config file
RedfieldConfiguration:
Filters:
0)InstrumentationKey: AppFilter: WebAppExclude MachineFilter: .*
1)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx2 AppFilter: WebAppTwo MachineFilter: .*
2)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxdefault AppFilter: .* MachineFilter: .*
Next steps
Use analytics for more advanced queries.
Create dashboards.
Add more telemetry:
Make changes to the config by using the Set config cmdlet.
Status Monitor v2 API: Get-
ApplicationInsightsMonitoringStatus
Description
This cmdlet provides troubleshooting information about Status Monitor. Use this cmdlet to investigate the
monitoring status, version of the PowerShell Module, and to inspect the running process. This cmdlet will report
version information and information about key files required for monitoring.
IMPORTANT
Examples
Example: Application status
Run the command Get-ApplicationInsightsMonitoringStatus to display the monitoring status of web sites.
PS C:\Windows\system32> Get-ApplicationInsightsMonitoringStatus
Machine Identifier:
811D43F7EC807E389FEA2E732381288ACCD70AFFF9F569559AC3A75F023FA639
IIS Websites:
SiteName : Default Web Site

ApplicationPoolName : DefaultAppPool
SiteId : 1
SiteState : Stopped
SiteName : DemoWebApp111
ApplicationPoolName : DemoWebApp111
SiteId : 2
SiteState : Started
ProcessId : not found
SiteId : 3
SiteState : Started
ProcessId : 2024
Instrumented : true
InstrumentationKey : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx123
SiteId : 4
SiteState : Started
ProcessId : 5184
AppAlreadyInstrumented : true
In this example;
Machine Identifier is an anonymous ID used to uniquely identify your server. If you create a support
request, we'll need this ID to find logs for your server.
Default Web Site is Stopped in IIS
DemoWebApp111 has been started in IIS, but hasn't received any requests. This report shows that there's
no running process (ProcessId: not found).
DemoWebApp222 is running and is being monitored (Instrumented: true). Based on the user configuration,
Instrumentation Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx123 was matched for this site.
DemoWebApp333 has been manually instrumented using the Application Insights SDK. Status Monitor
detected the SDK and won't monitor this site.
Example: PowerShell module information
Run the command Get-ApplicationInsightsMonitoringStatus -PowerShellModule to display information about the
current module:
PS C:\> Get-ApplicationInsightsMonitoringStatus -PowerShellModule
PowerShell Module version:

0.4.0-alpha
Application Insights SDK version:

2.9.0.3872
Executing PowerShell Module Assembly:

Microsoft.ApplicationInsights.Redfield.Configurator.PowerShell, Version=2.8.14.11432, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
PowerShell Module Directory:

C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\0.2.2\content\PowerShell
Runtime Paths:
ParentDirectory (Exists: True)
C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content
ConfigurationPath (Exists: True)

C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\applicationInsights.ikey.config
ManagedHttpModuleHelperPath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AppInsights.IIS.ManagedHttpMo
duleHelper.dll
RedfieldIISModulePath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.RedfieldI
ISModule.dll
InstrumentationEngine86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\MicrosoftInstrumentationEngin
e_x86.dll
InstrumentationEngine64Path (Exists: True)

C:\Program
e_x64.dll
InstrumentationEngineExtensionHost86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\Microsoft.ApplicationInsights
.ExtensionsHost_x86.dll
InstrumentationEngineExtensionHost64Path (Exists: True)

C:\Program
InstrumentationEngineExtensionConfig86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\Microsoft.InstrumentationEngi
ne.Extensions.config
InstrumentationEngineExtensionConfig64Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.InstrumentationEngi
ne.Extensions.config
ApplicationInsightsSdkPath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.dll
Example: Runtime status
You can inspect the process on the instrumented computer to see if all DLLs are loaded. If monitoring is working,
at least 12 DLLs should be loaded.
Run the command Get-ApplicationInsightsMonitoringStatus -InspectProcess :
PS C:\> Get-ApplicationInsightsMonitoringStatus -InspectProcess
iisreset.exe /status
Status for IIS Admin Service ( IISADMIN ) : Running
Status for Windows Process Activation Service ( WAS ) : Running
Status for Net.Msmq Listener Adapter ( NetMsmqActivator ) : Running
Status for Net.Pipe Listener Adapter ( NetPipeActivator ) : Running
Status for Net.Tcp Listener Adapter ( NetTcpActivator ) : Running
Status for World Wide Web Publishing Service ( W3SVC ) : Running
handle64.exe -accepteula -p w3wp

BF0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.ServerTelemetryChannel.dll
C58: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.AzureAppServices.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.DependencyCollector.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.WindowsServer.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.Web.dll
CBC: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.PerfCounterCollector.dll
DB0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.Agent.Intercept.dll
B98: File (R-D) C:\Program
ISModule.dll
BB4: File (R-D) C:\Program
ISModule.Contracts.dll
BCC: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Redfield.
Lightup.dll
BE0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.dll
listdlls64.exe -accepteula w3wp

0x0000000019ac0000 0x127000 C:\Program
e_x64.dll
0x00000000198b0000 0x4f000 C:\Program
0x000000000c460000 0xb2000 C:\Program
.Extensions.Base_x64.dll
0x000000000ad60000 0x108000
C:\Windows\TEMP\2.4.0.0.Microsoft.ApplicationInsights.Extensions.Intercept_x64.dll
Parameters
(No parameters)
By default, this cmdlet will report the monitoring status of web applications. Use this option to review if your
application was successfully instrumented. You can also review which Instrumentation Key was matched to your
site.
-PowerShellModule
Optional. Use this switch to report the version numbers and paths of DLLs required for monitoring. Use this
option if you need to identify the version of any DLL, including the Application Insights SDK.
-InspectProcess
Optional. Use this switch to report whether IIS is running. It will also download external tools to determine if the
necessary DLLs are loaded into the IIS runtime.
If this process fails for any reason, you can run these commands manually:
iisreset.exe /status
handle64.exe -p w3wp | findstr /I "InstrumentationEngine AI. ApplicationInsights"
listdlls64.exe w3wp | findstr /I "InstrumentationEngine AI ApplicationInsights"
-Force
Optional. Used only with InspectProcess. Use this switch to skip the user prompt that appears before additional
tools are downloaded.
Next steps
Status Monitor v2 API: Set-
ApplicationInsightsMonitoringConfig
This document describes a cmdlet that's a member of the Az.ApplicationMonitor PowerShell module.
Description
Sets the config file without doing a full reinstallation. Restart IIS for your changes to take effect.
IMPORTANT
Examples
Example with a single instrumentation key
In this example, all apps on the current computer will be assigned a single instrumentation key.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Example with an instrumentation key map

In this example:
MachineFilter matches the current computer by using the '.*' wildcard.
AppFilter='WebAppExclude' provides a null instrumentation key. The specified app won't be instrumented.
AppFilter='WebAppOne' assigns the specified app a unique instrumentation key.
AppFilter='WebAppTwo' assigns the specified app a unique instrumentation key.
Finally, AppFilter also uses the '.*' wildcard to match all web apps that aren't matched by the earlier rules
and assign a default instrumentation key.
Spaces are added for readability.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKeyMap

@(@{MachineFilter='.*';AppFilter='WebAppExclude'},
@{MachineFilter='.*';AppFilter='WebAppOne';InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx1'},
@{MachineFilter='.*';AppFilter='WebAppTwo';InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx2'},
@{MachineFilter='.*';AppFilter='.*';InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxdefault'})
Parameters
-InstrumentationKey
Required. Use this parameter to supply a single instrumentation key for use by all apps on the target computer.
-InstrumentationKeyMap
Required. Use this parameter to supply multiple instrumentation keys and a mapping of the instrumentation keys
used by each app. You can create a single installation script for several computers by setting MachineFilter .
IMPORTANT
Apps will match against rules in the order that the rules are provided. So you should specify the most specific rules first and
the most generic rules last.
Schema
@(@{MachineFilter='.*';AppFilter='.*';InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'})
MachineFilter is a required C# regex of the computer or VM name.

'.*' will match all
'ComputerName' will match only computers with the specified name.
AppFilter is a required C# regex of the computer or VM name.
'.*' will match all
'ApplicationName' will match only IIS apps with the specified name.
InstrumentationKey is required to enable monitoring of the apps that match the preceding two filters.
Leave this value null if you want to define rules to exclude monitoring.
-Verbose
Output
By default, no output.
Example verbose output from setting the config file via -InstrumentationKey
VERBOSE: Operation: InstallWithIkey

VERBOSE: InstrumentationKeyMap parsed:
Filters:
0)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx AppFilter: .* MachineFilter: .*
VERBOSE: set config file
VERBOSE: Config File Path:
Example verbose output from setting the config file via -InstrumentationKeyMap
VERBOSE: Operation: InstallWithIkeyMap

VERBOSE: InstrumentationKeyMap parsed:
Filters:
0)InstrumentationKey: AppFilter: WebAppExclude MachineFilter: .*
1)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx2 AppFilter: WebAppTwo MachineFilter: .*
2)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxdefault AppFilter: .* MachineFilter: .*
VERBOSE: set config file
VERBOSE: Config File Path:
Next steps
Create dashboards.
Add more telemetry:
Add the Application Insights SDK to your code so you can insert trace and log calls
Status Monitor v2 API: Start-
ApplicationInsightsMonitoringTrace
Description
Collects ETW Events from the codeless attach runtime. This cmdlet is an alternative to running PerfView.
Collected events will be printed to the console in real-time and saved to an ETL file. The output ETL file can be
opened by PerfView for further investigation.
This cmdlet will run until it reaches the timeout duration (default 5 minutes) or is stopped manually ( Ctrl + C ).
IMPORTANT
Examples
How to collect events
Normally we would ask that you collect events to investigate why your application isn't being instrumented.
The codeless attach runtime will emit ETW events when IIS starts up and when your application starts up.
To collect these events:
1. In a cmd console with admin privileges, execute iisreset /stop To turn off IIS and all web apps.
2. Execute this cmdlet
3. In a cmd console with admin privileges, execute iisreset /start To start IIS.
4. Try to browse to your app.
5. After your app finishes loading, you can manually stop it ( Ctrl + C ) or wait for the timeout.
What events to collect
You have three options when collecting events:
1. Use the switch -CollectSdkEvents to collect events emitted from the Application Insights SDK.
2. Use the switch -CollectRedfieldEvents to collect events emitted by Status Monitor and the Redfield Runtime.
These logs are helpful when diagnosing IIS and application startup.
3. Use both switches to collect both event types.
4. By default, if no switch is specified both event types will be collected.
Parameters
-MaxDurationInMinutes
Optional. Use this parameter to set how long this script should collect events. Default is 5 minutes.
-LogDirectory
Optional. Use this switch to set the output directory of the ETL file. By default, this file will be created in the
PowerShell Modules directory. The full path will be displayed during script execution.
-CollectSdkEvents
Optional. Use this switch to collect Application Insights SDK events.
-CollectRedfieldEvents
Optional. Use this switch to collect events from Status Monitor and the Redfield runtime.
-Verbose
Output
Example of application startup logs
PS C:\Windows\system32> Start-ApplicationInsightsMonitoringTrace -ColectRedfieldEvents
Starting...
Log File: C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\logs\20190627_144217_ApplicationInsights_ETW_Tra
ce.etl
Tracing enabled, waiting for events.
Tracing will timeout in 5 minutes. Press CTRL+C to cancel.
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Resolved variables to:

MicrosoftAppInsights_ManagedHttpModulePath='C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.RedfieldII
SModule.dll',
MicrosoftAppInsights_ManagedHttpModuleType='Microsoft.ApplicationInsights.RedfieldIISModule.RedfieldIISModule'
MicrosoftDiagnosticServices_ManagedHttpModulePath2='', MicrosoftDiagnosticServices_ManagedHttpModuleType2=''
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Environment variable
'MicrosoftDiagnosticServices_ManagedHttpModulePath2' or 'MicrosoftDiagnosticServices_ManagedHttpModuleType2'
is null, skipping managed dll loading
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace
MulticastHttpModule.constructor, success, 70 ms
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Current assembly
'Microsoft.ApplicationInsights.RedfieldIISModule, Version=2.8.18.27202, Culture=neutral,
PublicKeyToken=f23a46de0be5d6f3' location 'C:\Program
SModule.dll'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Matched filter '.*'~'STATUSMONITORTE',
'.*'~'DemoWithSql'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Lightup assembly calculated path:
'C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Redfield.L
ightup.dll'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-FrameworkLightup Trace Loaded applicationInsights.config from
assembly's resource Microsoft.ApplicationInsights.Redfield.Lightup, Version=2.8.18.27202, Culture=neutral,
PublicKeyToken=f23a46de0be5d6f3/Microsoft.ApplicationInsights.Redfield.Lightup.ApplicationInsights-
recommended.config
2:42:34 PM EVENT: Microsoft-ApplicationInsights-FrameworkLightup Trace Successfully attached
ApplicationInsights SDK
2:42:34 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace
RedfieldIISModule.LoadLightupAssemblyAndGetLightupHttpModuleClass, success, 2687 ms
RedfieldIISModule.CreateAndInitializeApplicationInsightsHttpModules(lightupHttpModuleClass), success
2:42:34 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace ManagedHttpModuleHelper,
multicastHttpModule.Init() success, 3288 ms
MicrosoftAppInsights_ManagedHttpModulePath='C:\Program
SModule.dll',
MicrosoftAppInsights_ManagedHttpModuleType='Microsoft.ApplicationInsights.RedfieldIISModule.RedfieldIISModule'
MicrosoftDiagnosticServices_ManagedHttpModulePath2='', MicrosoftDiagnosticServices_ManagedHttpModuleType2=''
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Environment variable
'MicrosoftDiagnosticServices_ManagedHttpModulePath2' or 'MicrosoftDiagnosticServices_ManagedHttpModuleType2'
is null, skipping managed dll loading
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace
MulticastHttpModule.constructor, success, 0 ms
RedfieldIISModule.CreateAndInitializeApplicationInsightsHttpModules(lightupHttpModuleClass), success
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace ManagedHttpModuleHelper,
multicastHttpModule.Init() success, 0 ms
Timeout Reached. Stopping...
Next steps
Additional Troubleshooting:
Review additional troubleshooting steps here: https://docs.microsoft.com/azure/azure-monitor/app/status-
monitor-v2-troubleshoot
Review the API Reference to learn about parameters you might have missed.
If you need additional help, you can contact us on GitHub.
Azure Application Insights displays data about your application in a Microsoft Azure resource. Creating a new
resource is therefore part of setting up Application Insights to monitor a new application. After you have
created your new resource, you can get its instrumentation key and use that to configure the Application
Insights SDK. The instrumentation key links your telemetry to the resource.
Sign in to Microsoft Azure


Sign in to the Azure portal, and create an Application Insights resource:
monitoring.
Resource Group myResourceGroup Name for the new or existing resource

group to host App Insights data.

where your app is hosted.
Enter the appropriate values into the required fields, and then select Review + create.
When your app has been created, a new pane opens. This pane is where you see performance and usage data
about your monitored application.
Copy the instrumentation key

The instrumentation key identifies the resource that you want to associate your telemetry data with. You will
need copy to add the instrumentation key to your application's code.
Install the SDK in your app

Install the Application Insights SDK in your app. This step depends heavily on the type of your application.
Use the instrumentation key to configure the SDK that you install in your application.
The SDK includes standard modules that send telemetry without you having to write any additional code. To
track user actions or diagnose issues in more detail, use the API to send your own telemetry.
Creating a resource automatically

PowerShell
Create a new Application Insights resource
New-AzApplicationInsights [-ResourceGroupName] <String> [-Name] <String> [-Location] <String> [-Kind

<String>]
[-Tag <Hashtable>] [-DefaultProfile <IAzureContextContainer>] [-WhatIf] [-Confirm] [<CommonParameters>]
Example
New-AzApplicationInsights -Kind java -ResourceGroupName testgroup -Name test1027 -location eastus
Results
Id :
/subscriptions/{subid}/resourceGroups/testgroup/providers/microsoft.insights/components/test1027
ResourceGroupName : testgroup
Name : test1027
Kind : web
Location : eastus
Type : microsoft.insights/components
AppId : 8323fb13-32aa-46af-b467-8355cf4f8f98
ApplicationType : web
Tags : {}
CreationDate : 10/27/2017 4:56:40 PM
FlowType :
HockeyAppId :
HockeyAppToken :
InstrumentationKey : 00000000-aaaa-bbbb-cccc-dddddddddddd
ProvisioningState : Succeeded
RequestSource : AzurePowerShell
SamplingPercentage :
TenantId : {subid}
For the full PowerShell documentation for this cmdlet, and to learn how to retrieve the instrumentation key
consult the Azure PowerShell documentation.
Azure CLI (preview)
To access the preview Application Insights Azure CLI commands you first need to run:
az extension add -n application-insights
If you don't run the az extension add command you will see an error message that states:
az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az monitor --help'.
Now you can run the following to create your Application Insights resource:
az monitor app-insights component create --app
--location
--resource-group
[--application-type]
[--kind]
[--tags]
Example
az monitor app-insights component create --app demoApp --location westus2 --kind web -g demoRg --
application-type web
Results
az monitor app-insights component create --app demoApp --location eastus --kind web -g demoApp --
application-type web
{
"appId": "87ba512c-e8c9-48d7-b6eb-118d4aee2697",
"applicationId": "demoApp",
"applicationType": "web",
"creationDate": "2019-08-16T18:15:59.740014+00:00",
"etag": "\"0300edb9-0000-0100-0000-5d56f2e00000\"",
"flowType": "Bluefield",
"hockeyAppId": null,
"hockeyAppToken": null,
"id": "/subscriptions/{subid}/resourceGroups/demoApp/providers/microsoft.insights/components/demoApp",
"instrumentationKey": "00000000-aaaa-bbbb-cccc-dddddddddddd",
"kind": "web",
"location": "eastus",
"name": "demoApp",
"provisioningState": "Succeeded",
"requestSource": "rest",
"resourceGroup": "demoApp",
"samplingPercentage": null,
"tags": {},
"tenantId": {tenantID},
"type": "microsoft.insights/components"
}
For the full Azure CLI documentation for this command, and to learn how to retrieve the instrumentation key
consult the Azure CLI documentation.
Next steps
Diagnostic Search
Explore metrics
Write Analytics queries
Application Insights Overview dashboard
Application Insights has always provided a summary overview pane to allow quick, at-a-glance assessment of
your application's health and performance. The new overview dashboard provides a faster more flexible
experience.
How do I test out the new experience?

The new overview dashboard now launches by default:
Better performance
Time range selection has been simplified to a simple one-click interface.
Overall performance has been greatly increased. You have one-click access to popular features like Search and
Analytics. Each default dynamically updating KPI tile provides insight into corresponding Application Insights
features. To learn more about failed requests select Failures under the Investigate header:
Application dashboard
Application dashboard leverages the existing dashboard technology within Azure to provide a fully
customizable single pane view of your application health and performance.
To access the default dashboard select Application Dashboard in the upper left corner.
If this is your first time accessing the dashboard, it will launch a default view:
You can keep the default view if you like it. Or you can also add, and delete from the dashboard to best fit the
needs of your team.
NOTE
All users with access to the Application Insights resource share the same Application dashboard experience. Changes
made by one user will modify the view for all users.
To navigate back to the overview experience just select:

Troubleshooting
If you select Configure tile settings and set a custom time range in excess of 31 days your dashboard will not
display beyond 31 days of data, even with the default data retention of 90 days. There is currently no
workaround for this behavior.
Next steps
Funnels
Retention
User Flows
Application Map: Triage Distributed Applications
Application Map helps you spot performance bottlenecks or failure hotspots across all components of your
distributed application. Each node on the map represents an application component or its dependencies; and has
health KPI and alerts status. You can click through from any component to more detailed diagnostics, such as
Application Insights events. If your app uses Azure services, you can also click through to Azure diagnostics,
such as SQL Database Advisor recommendations.
What is a Component?
Components are independently deployable parts of your distributed/microservices application. Developers and
operations teams have code-level visibility or access to telemetry generated by these application components.
Components are different from "observed" external dependencies such as SQL, EventHub etc. which your
team/organization may not have access to (code or telemetry).
Components run on any number of server/role/container instances.
Components can be separate Application Insights instrumentation keys (even if subscriptions are different)
or different roles reporting to a single Application Insights instrumentation key. The preview map experience
shows the components regardless of how they are set up.
Composite Application Map

You can see the full application topology across multiple levels of related application components. Components
could be different Application Insights resources, or different roles in a single resource. The app map finds
components by following HTTP dependency calls made between servers with the Application Insights SDK
installed.
This experience starts with progressive discovery of the components. When you first load the application map, a
set of queries is triggered to discover the components related to this component. A button at the top-left corner
will update with the number of components in your application as they are discovered.
On clicking "Update map components", the map is refreshed with all components discovered until that point.
Depending on the complexity of your application, this may take a minute to load.
If all of the components are roles within a single Application Insights resource, then this discovery step is not
required. The initial load for such an application will have all its components.
One of the key objectives with this experience is to be able to visualize complex topologies with hundreds of
components.
Click on any component to see related insights and go to the performance and failure triage experience for that
component.
Investigate failures
Select investigate failures to launch the failures pane.
Investigate performance
To troubleshoot performance problems, select investigate performance.
Go to details
Select go to details to explore the end-to-end transaction experience, which can offer views down to the call
stack level.
View in Analytics
To query and investigate your applications data further, click view in analytics.
Alerts
To view active alerts and the underlying rules that cause the alerts to be triggered, select alerts.
Set cloud role name

Application Map uses the cloud role name property to identify the components on the map. The Application
Insights SDK automatically adds the cloud role name property to the telemetry emitted by components. For
example, the SDK will add a web site name or service role name to the cloud role name property. However,
there are cases where you may want to override the default value. To override cloud role name and change what
gets displayed on the Application Map:
.NET/.NET Core
Write custom TelemetryInitializer as below.
namespace CustomInitializer.Telemetry
{
public class MyTelemetryInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
{
//set custom role name here
telemetry.Context.Cloud.RoleName = "Custom RoleName";
telemetry.Context.Cloud.RoleInstance = "Custom RoleInstance";
}
}
}
}
ASP.NET apps: Load initializer to the active TelemetryConfiguration

In ApplicationInsights.config :

<Add Type="CustomInitializer.Telemetry.MyTelemetryInitializer, CustomInitializer"/>
...
An alternate method for ASP.NET Web apps is to instantiate the initializer in code, for example in Global.aspx.cs:
using CustomInitializer.Telemetry;

{
// ...
TelemetryConfiguration.Active.TelemetryInitializers.Add(new MyTelemetryInitializer());
}
NOTE
Adding initializer using ApplicationInsights.config or using TelemetryConfiguration.Active is not valid for
ASP.NET Core applications.
ASP.NET Core apps: Load initializer to the TelemetryConfiguration

For ASP.NET Core applications, adding a new TelemetryInitializer is done by adding it to the Dependency
Injection container, as shown below. This is done in ConfigureServices method of your Startup.cs class.
{
services.AddSingleton<ITelemetryInitializer, MyTelemetryInitializer>();
}
Node.js
var appInsights = require("applicationinsights");

appInsights.setup('INSTRUMENTATION_KEY').start();
appInsights.defaultClient.context.tags["ai.cloud.role"] = "your role name";
appInsights.defaultClient.context.tags["ai.cloud.roleInstance"] = "your role instance";
Alternate method for Node.js

appInsights.setup('INSTRUMENTATION_KEY').start();
appInsights.defaultClient.addTelemetryProcessor(envelope => {
envelope.tags["ai.cloud.role"] = "your role name";
envelope.tags["ai.cloud.roleInstance"] = "your role instance"
});
Java
If you use Spring Boot with the Application Insights Spring Boot starter, the only required change is to set your
custom name for the application in the application.properties file.
spring.application.name=<name-of-app>
The Spring Boot starter will automatically assign cloud role name to the value you enter for the
spring.application.name property.
For further information on Java correlation and how to configure cloud role name for non-SpringBoot
applications checkout this section on correlation.
Client/browser-side JavaScript
appInsights.queue.push(() => {
appInsights.addTelemetryInitializer((envelope) => {
envelope.tags["ai.cloud.role"] = "your role name";
envelope.tags["ai.cloud.roleInstance"] = "your role instance";
});
});
Understanding cloud role name within the context of the Application Map
As far as how to think about cloud role name, it can be helpful to look at an Application Map that has multiple
cloud role names present:
In the Application Map above each of the names in green boxes are cloud role name values for different aspects
of this particular distributed application. So for this app its roles consist of: Authentication , acmefrontend ,
Inventory Management , a Payment Processing Worker Role .
In the case of this app each of those cloud role names also represents a different unique Application Insights
resource with their own instrumentation keys. Since the owner of this application has access to each of those
four disparate Application Insights resources, Application Map is able to stitch together a map of the underlying
relationships.
For the official definitions:
[Description("Name of the role the application is a part of. Maps directly to the role name in azure.")]
[MaxStringLength("256")]
705: string CloudRole = "ai.cloud.role";
[Description("Name of the instance where the application is running. Computer name for on-premises,
instance name for Azure.")]
[MaxStringLength("256")]
715: string CloudRoleInstance = "ai.cloud.roleInstance";
Alternatively, cloud role instance can be helpful for scenarios where cloud role name tells you the problem is
somewhere in your web front-end, but you might be running your web front-end across multiple load-balanced
servers so being able to drill in a layer deeper via Kusto queries and knowing if the issue is impacting all web
front-end servers/instances or just one can be extremely important.
A scenario where you might want to override the value for cloud role instance could be if your app is running in
a containerized environment where just knowing the individual server might not be enough information to
locate a given issue.
For more information about how to override the cloud role name property with telemetry initializers, see Add
properties: ITelemetryInitializer.
Troubleshooting
If you're having trouble getting Application Map to work as expected, try these steps:
General
1. Make sure you're using an officially supported SDK. Unsupported/community SDKs might not support
correlation.
Refer to this article for a list of supported SDKs.
2. Upgrade all components to the latest SDK version.
3. If you're using Azure Functions with C#, upgrade to Functions V2.
4. Confirm cloud role name is correctly configured.
5. If you're missing a dependency, make sure it's in the list ofauto-collected dependencies. If not, you can
still track it manually with a track dependency call.
Too many nodes on the map
Application Map constructs an application node for each unique cloud role name present in your request
telemetry and a dependency node for each unique combination of type, target, and cloud role name in your
dependency telemetry. If there are more than 10,000 nodes in your telemetry, Application Map will not be able
to fetch all the nodes and links, so your map will be incomplete. If this happens, a warning message will appear
when viewing the map.
In addition, Application Map only supports up to 1000 separate ungrouped nodes rendered at once. Application
Map reduces visual complexity by grouping dependencies together that have the same type and callers, but if
your telemetry has too many unique cloud role names or too many dependency types, that grouping will be
insufficient, and the map will be unable to render.
To fix this, you'll need to change your instrumentation to properly set the cloud role name, dependency type, and
dependency target fields.
Dependency target should represent the logical name of a dependency. In many cases, it’s equivalent to
the server or resource name of the dependency. For example, in the case of HTTP dependencies it is set to
the hostname. It should not contain unique IDs or parameters that change from one request to another.
Dependency type should represent the logical type of a dependency. For example, HTTP, SQL or Azure
Blob are typical dependency types. It should not contain unique IDs.
The purpose of cloud role name is described in the above section.
Portal feedback
To provide feedback, use the feedback option.
Next steps
To learn more about how correlation works in Application Insights consult the telemetry correlation article.
The end-to-end transaction diagnostic experience correlates server-side telemetry from across all your
Application Insights monitored components into a single view.
For advanced correlation scenarios in ASP.NET Core and ASP.NET consult the track custom operations
article.
Unified cross-component transaction diagnostics
The unified diagnostics experience automatically correlates server-side telemetry from across all your Application
Insights monitored components into a single view. It doesn't matter if you have multiple resources with separate
instrumentation keys. Application Insights detects the underlying relationship and allows you to easily diagnose
the application component, dependency, or exception that caused a transaction slowdown or failure.
What is a Component?
Components are independently deployable parts of your distributed/microservices application. Developers and
operations teams have code-level visibility or access to telemetry generated by these application components.
Components are different from "observed" external dependencies such as SQL, EventHub etc. which your
team/organization may not have access to (code or telemetry).
Components run on any number of server/role/container instances.
Components can be separate Application Insights instrumentation keys (even if subscriptions are different) or
different roles reporting to a single Application Insights instrumentation key. The new experience shows
details across all components, regardless of how they have been set up.
NOTE
Missing the related item links? All of the related telemetry are in the top and bottom sections of the left side.
Transaction diagnostics experience

This view has four key parts: results list, a cross-component transaction chart, a time-sequence list of all telemetry
related to this operation, and the details pane for any selected telemetry item on the left.
Cross-component transaction chart

This chart provides a timeline with horizontal bars for the duration of requests and dependencies across
components. Any exceptions that are collected are also marked on the timeline.
The top row on this chart represents the entry point, the incoming request to the first component called in this
transaction. The duration is the total time taken for the transaction to complete.
Any calls to external dependencies are simple non-collapsible rows, with icons representing the dependency
type.
Calls to other components are collapsible rows. Each row corresponds to a specific operation invoked at the
component.
By default, the request, dependency, or exception that you selected is displayed on the right side.
Select any row to see its details on the right.
NOTE
Calls to other components have two rows: one row represents the outbound call (dependency) from the caller component,
and the other row corresponds to the inbound request at the called component. The leading icon and distinct styling of the
duration bars help differentiate between them.
All telemetry with this Operation Id

This section shows flat list view in a time sequence of all the telemetry related to this transaction. It also shows
the custom events, and traces that aren't displayed in the transaction chart. You can filter this list to telemetry
generated by a specific component/call. You can select any telemetry item in this list to see corresponding details
on the right.
Details of the selected telemetry

This collapsible pane shows the detail of any selected item from the transaction chart, or the list. "Show all" lists
all of the standard attributes that are collected. Any custom attributes are separately listed below the standard set.
Click on the "..." below the stack trace window to get an option to copy the trace. "Open profiler traces" or "Open
debug snapshot" shows code level diagnostics in corresponding detail panes.
Search results
This collapsible pane shows the other results that meet the filter criteria. Click on any result to update the
respective details the 3 sections listed above. We try to find samples that are most likely to have the details
available from all components even if sampling is in effect in any of them. These are shown as "suggested"
samples.
Profiler and snapshot debugger

Application Insights profiler or snapshot debugger help with code-level diagnostics of performance and failure
issues. With this experience, you can see profiler traces or snapshots from any component with a single click.
If you could not get Profiler working, please contact serviceprofilerhelp@microsoft.com
If you could not get Snapshot Debugger working, please contact snapshothelp@microsoft.com
FAQ
I see a single component on the chart, and the others are only showing as external dependencies without any
detail of what happened within those components.
Potential reasons:
Are the other components instrumented with Application Insights?
Are they using the latest stable Application Insights SDK?
If these components are separate Application Insights resources, do you have required access to their
telemetry?
If you do have access and the components are instrumented with the latest Application Insights SDKs, let us
know via the top right feedback channel.
I see duplicate rows for the dependencies. Is this expected?
At this time, we are showing the outbound dependency call separate from the inbound request. Typically, the two
calls look identical with only the duration value being different due to the network round trip. The leading icon
and distinct styling of the duration bars help differentiate between them. Is this presentation of the data
confusing? Give us your feedback!
What about clock skews across different component instances?
Timelines are adjusted for clock skews in the transaction chart. You can see the exact timestamps in the details
pane or by using Analytics.
Why is the new experience missing most of the related items queries?
This is by design. All of the related items, across all components, are already available on the left side (top and
bottom sections). The new experience has two related items that the left side doesn't cover: all telemetry from five
minutes before and after this event and the user timeline.
Monitor the availability of any website
After you've deployed your web app/website, you can set up recurring tests to monitor availability and
responsiveness. Azure Application Insights sends web requests to your application at regular intervals from points
around the world. It can alert you if your application isn't responding, or if it responds too slowly.
You can set up availability tests for any HTTP or HTTPS endpoint that is accessible from the public internet. You
don't have to make any changes to the website you're testing. In fact, it doesn't even have to be a site you own. You
can test the availability of a REST API that your service depends on.
Types of availability tests:
There are three types of availability tests:
URL ping test: a simple test that you can create in the Azure portal.
Multi-step web test: A recording of a sequence of web requests, which can be played back to test more complex
scenarios. Multi-step web tests are created in Visual Studio Enterprise and uploaded to the portal for execution.
Custom Track Availability Tests: If you decide to create a custom application to run availability tests, the
TrackAvailability() method can be used to send the results to Application Insights.
You can create up to 100 availability tests per Application Insights resource.

In order to create an availability test, you first need to create an Application Insights resource. If you have already
created a resource, proceed to the next section to create a URL Ping test.
From the Azure portal, select Create a resource > Developer Tools > Application Insights and create an
Application Insights resource.
Create a URL ping test

The name "URL ping test" is a bit of a misnomer. To be clear, this test is not making any use of ICMP (Internet
Control Message Protocol) to check your site's availability. Instead it uses more advanced HTTP request
functionality to validate whether an endpoint is responding. It also measures the performance associated with that
response, and adds the ability to set custom success criteria coupled with more advanced features like parsing
dependent requests, and allowing for retries.
To create your first availability request, open the Availability pane and select Create Test.
Create a test
SETTING EXPLANATION
URL The URL can be any web page you want to test, but it must be
visible from the public internet. The URL can include a query
string. So, for example, you can exercise your database a little.
If the URL resolves to a redirect, we follow it up to 10 redirects.
Parse dependent requests Test requests images, scripts, style files, and other files that are
part of the web page under test. The recorded response time
includes the time taken to get these files. The test fails if any of
these resources cannot be successfully downloaded within the
timeout for the whole test. If the option is not checked, the
test only requests the file at the URL you specified. Enabling
this option results in a stricter check. The test could fail for
cases, which may not be noticeable when manually browsing
the site.
Enable retries when the test fails, it is retried after a short interval. A failure is
reported only if three successive attempts fail. Subsequent
tests are then performed at the usual test frequency. Retry is
temporarily suspended until the next success. This rule is
applied independently at each test location. We recommend
this option. On average, about 80% of failures disappear on
retry.
Test frequency Sets how often the test is run from each test location. With a
default frequency of five minutes and five test locations, your
site is tested on average every minute.
Test locations Are the places from where our servers send web requests to
your URL. Our minimum number of recommended test
locations is five in order to insure that you can distinguish
problems in your website from network issues. You can select
up to 16 locations.
If your URL is not visible from the public internet, you can choose to selectively open up your firewall to
allow only the test transactions through. To learn more about the firewall exceptions for our availability test
agents, consult the IP address guide.
NOTE
We strongly recommend testing from multiple locations with a minimum of five locations. This is to prevent false alarms
that may result from transient issues with a specific location. In addition we have found that the optimal configuration is to
have the number of test locations be equal to the alert location threshold + 2.
Success criteria
SETTING EXPLANATION
Test timeout Decrease this value to be alerted about slow responses. The
test is counted as a failure if the responses from your site have
not been received within this period. If you selected Parse
dependent requests, then all the images, style files, scripts,
and other dependent resources must have been received
within this period.
HTTP response The returned status code that is counted as a success. 200 is
the code that indicates that a normal web page has been
returned.
Content match A string, like "Welcome!" We test that an exact case-sensitive

match occurs in every response. It must be a plain string,
without wildcards. Don't forget that if your page content
changes you might have to update it. Only English
characters are supported with content match
Alerts
SETTING EXPLANATION
Near-realtime (Preview) We recommend using Near-realtime alerts. Configuring this

type of alert is done after your availability test is created.
Classic We no longer recommended using classic alerts for new

availability tests.
Alert location threshold We recommend a minimum of 3/5 locations. The optimal

relationship between alert location threshold and the number
of test locations is alert location threshold = number of
test locations - 2, with a minimum of five test locations.
See your availability test results

Availability test results can be visualized with both line and scatter plot views.
After a few minutes, click Refresh to see your test results.
The scatterplot view shows samples of the test results that have diagnostic test-step detail in them. The test engine
stores diagnostic detail for tests that have failures. For successful tests, diagnostic details are stored for a subset of
the executions. Hover over any of the green/red dots to see the test, test name, and location.
Select a particular test, location, or reduce the time period to see more results around the time period of interest.
Use Search Explorer to see results from all executions, or use Analytics queries to run custom reports on this data.
Inspect and edit tests

To edit, temporarily disable, or delete a test click the ellipses next to a test name. It may take up to 20 minutes for
configuration changes to propagate to all test agents after a change is made.
You might want to disable availability tests or the alert rules associated with them while you are performing
maintenance on your service.
If you see failures

Click a red dot.
From an availability test result, you can see the transaction details across all components. Here you can:
Inspect the response received from your server.
Diagnose failure with correlated server-side telemetry collected while processing the failed availability test.
Log an issue or work item in Git or Azure Boards to track the problem. The bug will contain a link to this event.
Open the web test result in Visual Studio.
Learn more about the end to end transaction diagnostics experience here.
Click on the exception row to see the details of the server-side exception that caused the synthetic availability test to
fail. You can also get the debug snapshot for richer code level diagnostics.
In addition to the raw results, you can also view two key Availability metrics in Metrics Explorer:
1. Availability: Percentage of the tests that were successful, across all test executions.
2. Test Duration: Average test duration across all test executions.
Automation
Use PowerShell scripts to set up an availability test automatically.
Set up a webhook that is called when an alert is raised.
Troubleshooting
Dedicated troubleshooting article.
Next steps
Availability Alerts
You can monitor a recorded sequence of URLs and interactions with a website via multi-step web tests. This
article will walk you through the process of creating a multi-step web test with Visual Studio Enterprise.
NOTE
Multi-step web tests depend on Visual Studio webtest files. It was announced that Visual Studio 2019 will be the last
version with webtest functionality. It is important to understand that while no new features will be added, webtest
functionality in Visual Studio 2019 is still currently supported and will continue to be supported during the support
lifecycle of the product. The Azure Monitor product team has addressed questions regarding the future of multi-step
availability tests here.
Pre-requisites
Visual Studio 2017 Enterprise or greater.
Visual Studio web performance and load testing tools.
To locate the testing tools pre-requisite. Launch the Visual Studio Installer > Individual components >
Debugging and testing > Web performance and load testing tools.
NOTE
Multi-step web tests have additional costs associated with them. To learn more consult the official pricing guide.
Record a multi-step web test

To create a multi-step test, you record the scenario by using Visual Studio Enterprise, and then upload the
recording to Application Insights. Application Insights replays the scenario at set intervals and verifies the
response.
IMPORTANT
You can't use coded functions or loops in your tests. The test must be contained completely in the .webtest script.
However, you can use standard plugins.
Only English characters are supported in the multi-step web tests. If you use Visual Studio in other languages, please
update the web test definition file to translate/exclude non-English characters.
Use Visual Studio Enterprise to record a web session.

1. Create a Web performance and Load Test Project. File > New > Project > Visual C# > Test
2. Open the .webtest file and start recording.
3. Click through the steps you want your test to simulate as part of the recording.
4. Edit the test to:
Add validations to check the received text and response codes.
Remove any uneccesary interactions. You could also remove dependent requests for pictures or add
tracking sites which aren't relevant to you considering your test a success.
Keep in mind that you can only edit the test script - you can add custom code or call other web tests.
Don't insert loops in the test. You can use standard web test plug-ins.
5. Run the test in Visual Studio to validate and make sure it works.
The web test runner opens a web browser and repeats the actions you recorded. Make sure everything
behaves as expected.
Upload the web test

1. In the Application Insights portal on the Availability pane select Create Test > Test type > Multi-step
web test.
2. Set the test locations, frequency, and alert parameters.
Frequency & location
SETTING EXPLANATION
Test frequency Sets how often the test is run from each test location. With a
default frequency of five minutes and five test locations, your
site is tested on average every minute.
Test locations Are the places from where our servers send web requests to
your URL. Our minimum number of recommended test
locations is five in order to insure that you can distinguish
problems in your website from network issues. You can select
up to 16 locations.
Success criteria
SETTING EXPLANATION
Test timeout Decrease this value to be alerted about slow responses. The
test is counted as a failure if the responses from your site
have not been received within this period. If you selected
Parse dependent requests, then all the images, style files,
scripts, and other dependent resources must have been
received within this period.
HTTP response The returned status code that is counted as a success. 200 is
the code that indicates that a normal web page has been
returned.
Content match A string, like "Welcome!" We test that an exact case-sensitive

match occurs in every response. It must be a plain string,
without wildcards. Don't forget that if your page content
changes you might have to update it. Only English
characters are supported with content match
Alerts
SETTING EXPLANATION
Near-realtime (Preview) We recommend using Near-realtime alerts. Configuring this

type of alert is done after your availability test is created.
Classic We no longer recommended using classic alerts for new

availability tests.
Alert location threshold We recommend a minimum of 3/5 locations. The optimal

relationship between alert location threshold and the
number of test locations is alert location threshold =
number of test locations - 2, with a minimum of five test
locations.
Advanced Configuration
Plugging time and random numbers into your test
Suppose you're testing a tool that gets time-dependent data such as stocks from an external feed. When you
record your web test, you have to use specific times, but you set them as parameters of the test, StartTime and
EndTime.
When you run the test, you'd like EndTime always to be the present time, and StartTime should be 15 minutes
ago.
The Web Test Date Time Plugin provides the way to handle parameterize times.
1. Add a web test plug-in for each variable parameter value you want. In the web test toolbar, choose Add
Web Test Plugin.
In this example, we use two instances of the Date Time Plug-in. One instance is for "15 minutes ago" and
another for "now."
2. Open the properties of each plug-in. Give it a name and set it to use the current time. For one of them, set
Add Minutes = -15.
3. In the web test parameters, use {{plug-in name}} to reference a plug-in name.
Now, upload your test to the portal. It will use the dynamic values on every run of the test.
Dealing with sign-in
If your users sign in to your app, you have various options for simulating sign-in so that you can test pages
behind the sign-in. The approach you use depends on the type of security provided by the app.
In all cases, you should create an account in your application just for the purpose of testing. If possible, restrict
the permissions of this test account so that there's no possibility of the web tests affecting real users.
Simple username and password Record a web test in the usual way. Delete cookies first.
SAML authentication
PROPERTY NAME DESCRIPTION
Audience Uri The audience URI for the SAML token. This is the URI for the
Access Control Service (ACS) – including ACS namespace and
host name.
Certificate Password The password for the client certificate which will grant access
to the embedded private key.
Client Certificate The client certificate value with private key in Base64
encoded format.
Name Identifier The name identifier for the token
Not After The timespan for which the token will be valid. The default is
5 minutes.
Not Before The timespan for which a token created in the past will be
valid (to address time skews). The default is (negative) 5
minutes.
PROPERTY NAME DESCRIPTION
Target Context Parameter Name The context parameter that will receive the generated
assertion.
Client secret If your app has a sign-in route that involves a client secret, use that route. Azure Active Directory
(AAD ) is an example of a service that provides a client secret sign-in. In AAD, the client secret is the App Key.
Here's a sample web test of an Azure web app using an app key:
Get token from AAD using client secret (AppKey). Extract bearer token from response. Call API using bearer
token in the authorization header. Make sure that the web test is an actual client - that is, it has its own app in
AAD - and use its clientId + app key. Your service under test also has its own app in AAD: the appID URI of this
app is reflected in the web test in the resource field.
Open Authentication
An example of open authentication is signing in with your Microsoft or Google account. Many apps that use
OAuth provide the client secret alternative, so your first tactic should be to investigate that possibility.
If your test must sign in using OAuth, the general approach is:
Use a tool such as Fiddler to examine the traffic between your web browser, the authentication site, and your
app. Perform two or more sign-ins using different machines or browsers, or at long intervals (to allow tokens to
expire). By comparing different sessions, identify the token passed back from the authenticating site, that is then
passed to your app server after sign-in. Record a web test using Visual Studio. Parameterize the tokens, setting
the parameter when the token is returned from the authenticator, and using it in the query to the site. (Visual
Studio attempts to parameterize the test, but does not correctly parameterize the tokens.)
Troubleshooting
Next steps
Availability Alerts
Url ping web tests
Availability alerts
Azure Application Insights sends web requests to your application at regular intervals from points around the
world. It can alert you if your application isn't responding, or if it responds too slowly.
Enable alerts
Alerts are now automatically enabled by default, but in order to fully configure the alert you first have to initially
create your availability test.
NOTE
With the new unified alerts, the alert rule severity and notification preferences with action groups must be configured in the
alerts experience. Without the following steps, you will only receive in-portal notifications.
1. After saving the availability test, on the details tab click on the ellipsis by the test you just made. Click on
"edit alert".
2. Set the desired severity level, rule description and most importantly - the action group that has the
notification preferences you would like to use for this alert rule.
Alert on X out of Y locations reporting failures
The X out of Y locations alert rule is enabled by default in the new unified alerts experience, when you create a
new availability test. You can opt out by selecting the "classic" option or choosing to disable the alert rule.
NOTE
Configure the action groups to receive notifications when the alert triggers by following the steps above. Without this step,
you will only receive in-portal notifications when the rule triggers.
Alert on availability metrics

Using the new unified alerts, you can alert on segmented aggregate availability and test duration metrics as well:
1. Select an Application Insights resource in the Metrics experience, and select an Availability metric:
2. Configure alerts option from the menu will take you to the new experience where you can select specific
tests or locations to set up alert rule on. You can also configure the action groups for this alert rule here.
Alert on custom analytics queries
Using the new unified alerts, you can alert on custom log queries. With custom queries, you can alert on any
arbitrary condition that helps you get the most reliable signal of availability issues. This is also applicable, if you
are sending custom availability results using the TrackAvailability SDK.
TIP
The metrics on availability data include any custom availability results you may be submitting by calling our TrackAvailability
SDK. You can use the alerting on metrics support to alert on custom availability results.
Automate alerts
To automate this process with Azure Resource Manager templates, refer to the Create a metric alert with Resource
Manager template documentation.
Troubleshooting
Next steps
Url ping web tests
Performance testing
NOTE
The cloud-based load testing service has been deprecated. More information about the deprecation, the service availability,
and alternative services can be found here.
Application Insights allows you to generate load tests for your websites. Like availability tests, you can send either
basic requests or multi-step requests from Azure test agents around the world. Performance tests allow you to
simulate up to 20,000 simultaneous users for up to 60 minutes.

In order to create a performance test, you first need to create an Application Insights resource. If you have already
created a resource proceed to the next section.
From the Azure portal, select Create a resource > Developer Tools > Application Insights and create an
Application Insights resource.
Configure performance testing

If this is your first time creating performance test select Set Organization and choose an Azure DevOps
organization to be the source for your performance tests.
Under Configure, go to Performance Testing and click New to create a test.
To create a basic performance test, select a test type of Manual Test and fill out the desired settings for your test.
SETTING MAX VALUE
User Load 20,000
Duration (Minutes) 60
After your test is created, click Run test.

Once the test is complete, you will see results that look similar to the results below:
Configure Visual Studio web test
Application Insights advanced performance testing capabilities are built on top of Visual Studio performance and
load test projects.
Next steps
Url ping tests
Troubleshooting
This article will help you to troubleshoot common issues that may occur when using availability monitoring.
SSL/TLS errors
SYMPTOM/ERROR MESSAGE POSSIBLE CAUSES
Could not create SSL/TLS Secure Channel SSL version. Only TLS 1.0, 1.1, and 1.2 are supported. SSLv3
is not supported.
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Bad See StackExchange thread for more information.
Record MAC)
URL that is failing is to a CDN (Content Delivery Network) This may be caused by a misconfiguration on your CDN
Possible workaround
If the URLs that are experiencing the issue are always to dependent resources, it is recommended to disable
parse dependent requests for the web test.
Test fails only from certain locations

SYMPTOM/ERROR MESSAGE POSSIBLE CAUSES
A connection attempt failed because the connected party did Test agents in certain locations are being blocked by a firewall.
not properly respond after a period of time
Rerouting of certain IP addresses is occurring via (Load

Balancers, Geo traffic managers, Azure Express Route.)
If using Azure ExpressRoute, there are scenarios where

packets can be dropped in cases where Asymmetric Routing
occurs.
Test failure with a protocol violation error

SYMPTOM/ERROR MESSAGE POSSIBLE CAUSES POSSIBLE RESOLUTIONS
The server committed a protocol This occurs when malformed headers a. Contact web site host provider / CDN
violation. Section=ResponseHeader are detected. Specifically, some headers provider to fix the faulty servers.
Detail=CR must be followed by LF might not be using CRLF to indicate the b. In case the failed requests are
end of line, which violates the HTTP resources (e.g. style files, images,
specification. Application Insights scripts), you may consider disabling the
enforces this HTTP specification and parsing of dependent requests. Keep in
fails responses with malformed headers. mind, if you do this you will lose the
ability to monitor the availability of
those files).
NOTE
The URL may not fail on browsers that have a relaxed validation of HTTP headers. See this blog post for a detailed
explanation of this issue: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/
Common troubleshooting questions

Site looks okay but I see test failures? Why is Application Insights alerting me?
Does your test have Parse dependent requests enabled? That results in a strict check on resources such
as scripts, images etc. These types of failures may not be noticeable on a browser. Check all the images,
scripts, style sheets, and any other files loaded by the page. If any of them fails, the test is reported as failed,
even if the main HTML page loads without issue. To desensitize the test to such resource failures, simply
uncheck the Parse Dependent Requests from the test configuration.
To reduce odds of noise from transient network blips etc., ensure Enable retries for test failures
configuration is checked. You can also test from more locations and manage alert rule threshold
accordingly to prevent location-specific issues causing undue alerts.
Click on any of the red dots from the Availability experience, or any availability failure from the Search
explorer to see the details of why we reported the failure. The test result, along with the correlated server-
side telemetry (if enabled) should help understand why the test failed. Common causes of transient issues
are network or connection issues.
Did the test time-out? We abort tests after 2 minutes. If your ping or multi-step test takes longer than 2
minutes, we will report it as a failure. Consider breaking the test into multiple ones that can complete in
shorter durations.
Did all locations report failure, or only some of them? If only some reported failures, it may be due to
network/CDN issues. Again, clicking on the red dots should help understand why the location reported
failures.
I did not get an email when the alert triggered, or resolved or both?
Check the classic alerts configuration to confirm your email is directly listed, or a distribution list you are on is
configured to receive notifications. If it is, then check the distribution list configuration to confirm it can receive
external emails. Also check if your mail administrator may have any policies configured that may cause this issue.
I did not receive the webhook notification?
Check to ensure the application receiving the webhook notification is available, and successfully processes the
webhook requests. See this for more information.
Intermittent test failure with a protocol violation error?
The error ("protocol violation..CR must be followed by LF") indicates an issue with the server (or dependencies).
This happens when malformed headers are set in the response. It can be caused by load balancers or CDNs.
Specifically, some headers might not be using CRLF to indicate end of line, which violates the HTTP specification
and therefore fail validation at the .NET WebRequest level. Inspect the response to spot headers, which might be
in violation.
NOTE
The URL may not fail on browsers that have a relaxed validation of HTTP headers. See this blog post for a detailed
explanation of this issue: http://mehdi.me/a-tale-of-debugging-the-linkedin-api-net-and-http-protocol-violations/
I don't see any related server-side telemetry to diagnose test failures?*

If you have Application Insights set up for your server-side application, that may be because sampling is in
operation. Select a different availability result.
Can I call code from my web test?
No. The steps of the test must be in the .webtest file. And you can't call other web tests or use loops. But there are
several plug-ins that you might find helpful.
Is there a difference between "web tests" and "availability tests"?
The two terms may be referenced interchangeably. Availability tests is a more generic term that includes the single
URL ping tests in addition to the multi-step web tests.
I'd like to use availability tests on our internal server that runs behind a firewall.
There are two possible solutions:
Configure your firewall to permit incoming requests from the IP addresses of our web test agents.
Write your own code to periodically test your internal server. Run the code as a background process on a test
server behind your firewall. Your test process can send its results to Application Insights by using
TrackAvailability() API in the core SDK package. This requires your test server to have outgoing access to the
Application Insights ingestion endpoint, but that is a much smaller security risk than the alternative of
permitting incoming requests. The results will appear in the availability web tests blades though the experience
will be slightly simplified from what is available for tests created via the portal. Custom availability tests will
also appear as availability results in Analytics, Search, and Metrics.
Uploading a multi-step web test fails
Some reasons this might happen:
There's a size limit of 300 K.
Loops aren't supported.
References to other web tests aren't supported.
Data sources aren't supported.
My multi-step test doesn't complete
There's a limit of 100 requests per test. Also, the test is stopped if it runs longer than two minutes.
How can I run a test with client certificates?
This is currently not supported.
Who receives the (classic) alert notifications?

This section only applies to classic alerts and will help you optimize your alert notifications to ensure that only
your desired recipients receive notifications. To understand more about the difference between classic alertsand
the new alerts experience refer to the alerts overview article. To control alert notification in the new alerts
experience use action groups.
We recommend the use of specific recipients for classic alert notifications.
For alerts on failures from X out of Y locations, the bulk/group check-box option, if enabled, sends to
users with admin/co-admin roles. Essentially all administrators of the subscription will receive notifications.
For alerts on availability metrics the bulk/group check-box option if enabled, sends to users with owner,
contributor, or reader roles in the subscription. In effect, all users with access to the subscription the
Application Insights resource are in scope and will receive notifications.
NOTE
If you currently use the bulk/group check-box option, and disable it, you will not be able to revert the change.
Use the new alert experience/near-realtime alerts if you need to notify users based on their roles. With action
groups, you can configure email notifications to users with any of the contributor/owner/reader roles (not
combined together as a single option).
Next steps
Multi-step web testing
URL ping tests
What is Distributed Tracing?
The advent of modern cloud and microservices architectures has given rise to simple, independently deployable
services that can help reduce costs while increasing availability and throughput. But while these movements have
made individual services easier to understand as a whole, they’ve made overall systems more difficult to reason
about and debug.
In monolithic architectures, we’ve gotten used to debugging with call stacks. Call stacks are brilliant tools for
showing the flow of execution (Method A called Method B, which called Method C ), along with details and
parameters about each of those calls. This is great for monoliths or services running on a single process, but how
do we debug when the call is across a process boundary, not simply a reference on the local stack?
That’s where distributed tracing comes in.
Distributed tracing is the equivalent of call stacks for modern cloud and microservices architectures, with the
addition of a simplistic performance profiler thrown in. In Azure Monitor, we provide two experiences for
consuming distributed trace data. The first is our transaction diagnostics view, which is like a call stack with a time
dimension added in. The transaction diagnostics view provides visibility into one single transaction/request, and is
helpful for finding the root cause of reliability issues and performance bottlenecks on a per request basis.
Azure Monitor also offers an application map view which aggregates many transactions to show a topological
view of how the systems interact, and what the average performance and error rates are.
How to Enable Distributed Tracing

Enabling distributed tracing across the services in an application is as simple as adding the proper SDK or library
to each service, based on the language the service was implemented in.
Enabling via Application Insights SDKs

The Application Insights SDKs for .NET, .NET Core, Java, Node.js, and JavaScript all support distributed tracing
natively. Instructions for installing and configuring each Application Insights SDK are available below:
.NET
.NET Core
Java
Node.js
JavaScript
With the proper Application Insights SDK installed and configured, tracing information is automatically collected
for popular frameworks, libraries, and technologies by SDK dependency auto-collectors. The full list of supported
technologies is available in the Dependency auto-collection documentation.
Additionally, any technology can be tracked manually with a call to TrackDependency on the TelemetryClient.
Enable via OpenCensus

In addition to the Application Insights SDKs, Application Insights also supports distributed tracing through
OpenCensus. OpenCensus is an open source, vendor-agnostic, single distribution of libraries to provide metrics
collection and distributed tracing for services. It also enables the open source community to enable distributed
tracing with popular technologies like Redis, Memcached, or MongoDB. Microsoft collaborates on OpenCensus
with several other monitoring and cloud partners.
To add distributed tracing capabilities to an application with OpenCensus, first install and configure the
Application Insights Local Forwarder. From there, configure OpenCensus to route distributed trace data through
the Local Forwarder. Both Python and Go are supported.
The OpenCensus website maintains API reference documentation for Python and Go, as well as various different
guides for using OpenCensus.
Next steps
OpenCensus Python usage guide
Application map
End-to-end performance monitoring
Telemetry correlation in Application Insights
In the world of microservices, every logical operation requires work to be done in various components of the
service. Each of these components can be monitored separately by Azure Application Insights. The web-app
component communicates with the authentication provider component to validate user credentials, and with the
API component to get data for visualization. The API component can query data from other services and use
cache-provider components to notify the billing component about this call. Application Insights supports
distributed telemetry correlation, which you use to detect which component is responsible for failures or
performance degradation.
This article explains the data model used by Application Insights to correlate telemetry sent by multiple
components. It covers context-propagation techniques and protocols. It also covers the implementation of
correlation concepts on different languages and platforms.
Data model for telemetry correlation

Application Insights defines a data model for distributed telemetry correlation. To associate telemetry with the
logical operation, every telemetry item has a context field called operation_Id . This identifier is shared by every
telemetry item in the distributed trace. So, even with loss of telemetry from a single layer, you can still associate
telemetry reported by other components.
A distributed logical operation typically consists of a set of smaller operations, which are requests processed by one
of the components. These operations are defined by request telemetry. Every request telemetry has its own id
that identifies it uniquely and globally. And all telemetry items (such as traces and exceptions) that are associated
with this request should set the operation_parentId to the value of the request id .
Every outgoing operation, such as an HTTP call to another component, is represented by dependency telemetry.
Dependency telemetry also defines its own id that is globally unique. Request telemetry, initiated by this
dependency call, uses this id as its operation_parentId .
You can build a view of the distributed logical operation by using operation_Id , operation_parentId , and
request.id with dependency.id . These fields also define the causality order of telemetry calls.
In a microservices environment, traces from components can go to different storage items. Every component can
have its own instrumentation key in Application Insights. To get telemetry for the logical operation, the Application
Insights UX queries data from every storage item. When the number of storage items is huge, you'll need a hint
about where to look next. The Application Insights data model defines two fields to solve this problem:
request.source and dependency.target . The first field identifies the component that initiated the dependency
request, and the second identifies which component returned the response of the dependency call.
Example
Let's take an example of an application called Stock Prices, which shows the current market price of a stock by
using an external API called Stock . The Stock Prices application has a page called Stock page that the client web
browser opens by using GET /Home/Stock . The application queries the Stock API by using an HTTP call
GET /api/stock/value .
You can analyze the resulting telemetry by running a query:

(requests | union dependencies | union pageViews)
| where operation_Id == "STYz"
| project timestamp, itemType, name, id, operation_ParentId, operation_Id
In the results, note that all telemetry items share the root operation_Id . When an Ajax call is made from the page, a
new unique ID ( qJSXU ) is assigned to the dependency telemetry and the ID of the pageView is used as
operation_ParentId . The server request then uses the Ajax ID as operation_ParentId .
ITEMTYPE NAME ID OPERATION_PARENTID OPERATION_ID
pageView Stock page STYz STYz
dependency GET /Home/Stock qJSXU STYz STYz
request GET Home/Stock KqKwlrSt9PA= qJSXU STYz
dependency GET /api/stock/value bBrf2L7mm2g= KqKwlrSt9PA= STYz
When the call GET /api/stock/value is made to an external service, you want to know the identity of that server so
you can set the dependency.target field appropriately. When the external service doesn't support monitoring,
target is set to the host name of the service (for example, stock-prices-api.com ). However, if the service identifies
itself by returning a predefined HTTP header, target contains the service identity that allows Application Insights
to build a distributed trace by querying telemetry from that service.
Correlation headers
We're transitioning to W3C Trace-Context which defines:
traceparent : Carries the globally unique operation ID and unique identifier of the call.
tracestate : Carries tracing system -specific context.
Latest versions of Application Insights SDKs support Trace-Context protocol, but you may need to opt-into that (it
will keep backward compatibility with old correlation protocol supported by ApplicationInsights SDKs).
The correlation HTTP protocol aka Request-Id is on deprecation path. This protocol defines two headers:
Request-Id : Carries the globally unique ID of the call.
Correlation-Context : Carries the name-value pairs collection of the distributed trace properties.
Application Insights also defines the extension for the correlation HTTP protocol. It uses Request-Context name-
value pairs to propagate the collection of properties used by the immediate caller or callee. The Application Insights
SDK uses this header to set dependency.target and request.source fields.
Enable W3C distributed tracing support for classic ASP.NET apps
NOTE
No configuration needed starting with Microsoft.ApplicationInsights.Web and
Microsoft.ApplicationInsights.DependencyCollector
W3C Trace-Context support is done in the backward-compatible way and correlation is expected to work with
applications that are instrumented with previous versions of SDK (without W3C support).
If for any reason you want to keep using legacy Request-Id protocol, you may disable Trace-Context with following
configuration
Activity.DefaultIdFormat = ActivityIdFormat.Hierarchical;
Activity.ForceDefaultIdFormat = true;
If you run older version of the SDK, we recommend updating it or applying following configuration to enable
Trace-Context. This feature is available in Microsoft.ApplicationInsights.Web and
Microsoft.ApplicationInsights.DependencyCollector packages starting with version 2.8.0 -beta1. It's disabled by
default. To enable it, change ApplicationInsights.config :
Under RequestTrackingTelemetryModule , add the EnableW3CHeadersExtraction element with value set to true .
Under DependencyTrackingTelemetryModule , add the EnableW3CHeadersInjection element with value set to true .
Add W3COperationCorrelationTelemetryInitializer under the TelemetryInitializers similar to
<Add Type="Microsoft.ApplicationInsights.Extensibility.W3C.W3COperationCorrelationTelemetryInitializer,
Microsoft.ApplicationInsights"/>
...
Enable W3C distributed tracing support for ASP.NET Core apps
NOTE
No configuration needed starting with Microsoft.ApplicationInsights.AspNetCore version 2.8.0.
configuration
Trace-Context.
This feature is in version 2.5.0-beta1 and in
Microsoft.ApplicationInsights.AspNetCore
Microsoft.ApplicationInsights.DependencyCollector version 2.8.0 -beta1. It's disabled by default. To enable it, set
ApplicationInsightsServiceOptions.RequestCollectionOptions.EnableW3CDistributedTracing to true :

{
services.AddApplicationInsightsTelemetry(o =>
o.RequestCollectionOptions.EnableW3CDistributedTracing = true );
// ....
}
Enable W3C distributed tracing support for Java apps

Incoming configuration
For Java EE apps, add the following to the <TelemetryModules> tag inside ApplicationInsights.xml:
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModul
e>
<Param name = "W3CEnabled" value ="true"/>
<Param name ="enableW3CBackCompat" value = "true" />
</Add>
For Spring Boot apps, add the following properties:

azure.application-insights.web.enable-W3C=true
azure.application-insights.web.enable-W3C-backcompat-mode=true
Outgoing configuration
<Instrumentation>
</BuiltIn>
</Instrumentation>
NOTE
Backward compatibility mode is enabled by default, and the enableW3CBackCompat parameter is optional. Use it only
when you want to turn backward compatibility off.
Ideally, you would turn this off when all your services have been updated to newer versions of SDKs that support the
W3C protocol. We highly recommend that you move to these newer SDKs as soon as possible.
IMPORTANT
Make sure that both incoming and outgoing configurations are exactly the same.
Enable W3C distributed tracing support for Web apps

This feature is in Microsoft.ApplicationInsights.JavaScript . It's disabled by default. To enable it, use
distributedTracingMode config. AI_AND_W3C is provided for back-compatibility with any legacy Application
Insights instrumented services:
NPM Setup (ignore if using Snippet Setup)
import { ApplicationInsights, DistributedTracingModes } from '@microsoft/applicationinsights-web';

instrumentationKey: 'YOUR_INSTRUMENTATION_KEY_GOES_HERE',
distributedTracingMode: DistributedTracingModes.W3C
} });
Snippet Setup (Ignore if using NPM Setup)

aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){i[e]=function(){var
n=arguments;i.queue.push(function(){i[e].apply(i,n)})}}var i={config:e};i.initialize=!0;var
a=document,t=window;setTimeout(function(){var
n=a.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",a.getEle
mentsByTagName("script")[0].parentNode.appendChild(n)});try{i.cookie=a.cookie}catch(e){}i.queue=
[],i.version=2;for(var r=
ack"+r.pop());n("startTrackPage"),n("stopTrackPage");var o="Track"+r[0];if(n("start"+o),n("stop"+o),!
s=t[r];t[r]=function(e,n,a,t,o){var c=s&&s(e,n,a,t,o);return!0!==c&&i["_"+r]
({message:e,url:n,lineNumber:a,columnNumber:t,error:o}),c},e.autoExceptionInstrumented=!0}return i}
(
{
instrumentationKey:"INSTRUMENTATION_KEY",
distributedTracingMode: 2 // DistributedTracingModes.W3C
}
);
window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
OpenTracing and Application Insights

The OpenTracing data model specification and Application Insights data models map in the following way:
APPLICATION INSIGHTS OPENTRACING
Request , PageView Span with span.kind = server
Dependency Span with span.kind = client
Id of Request and Dependency SpanId
Operation_Id TraceId
Operation_ParentId Reference of type ChildOf (the parent span)
For more information, see the Application Insights telemetry data model.
For definitions of OpenTracing concepts, see the OpenTracing specification and semantic_conventions.
Telemetry correlation in .NET

Over time, .NET defined several ways to correlate telemetry and diagnostics logs:
System.Diagnostics.CorrelationManager allows tracking of LogicalOperationStack and ActivityId.
System.Diagnostics.Tracing.EventSource and Event Tracing for Windows ( ETW ) define the
SetCurrentThreadActivityId method.
ILogger uses Log Scopes.
Windows Communication Foundation (WCF ) and HTTP wire up "current" context propagation.
However, those methods didn't enable automatic distributed tracing support. DiagnosticSource is a way to support
automatic cross-machine correlation. .NET libraries support 'DiagnosticSource' and allow automatic cross-machine
propagation of the correlation context via the transport, such as HTTP.
The guide to Activities in DiagnosticSource explains the basics of tracking activities.
ASP.NET Core 2.0 supports extraction of HTTP headers and starting a new activity.
System.Net.Http.HttpClient , starting with version 4.1.0, supports automatic injection of the correlation HTTP
headers and tracking the HTTP call as an activity.
There is a new HTTP module, Microsoft.AspNet.TelemetryCorrelation, for classic ASP.NET. This module
implements telemetry correlation by using DiagnosticSource . It starts an activity based on incoming request
headers. It also correlates telemetry from the different stages of request processing, even for cases when every
stage of Internet Information Services (IIS ) processing runs on a different managed thread.
The Application Insights SDK, starting with version 2.4.0-beta1, uses DiagnosticSource and Activity to collect
telemetry and associate it with the current activity.
Telemetry correlation in the Java SDK

The Application Insights SDK for Java supports automatic correlation of telemetry beginning with version 2.0.0. It
automatically populates operation_id for all telemetry (such as traces, exceptions, and custom events) issued
within the scope of a request. It also takes care of propagating the correlation headers (described earlier) for
service-to-service calls via HTTP, if the Java SDK agent is configured.
NOTE
Only calls made via Apache HTTPClient are supported for the correlation feature. If you're using Spring RestTemplate or Feign,
both can be used with Apache HTTPClient under the hood.
Currently, automatic context propagation across messaging technologies (such Kafka, RabbitMQ, or Azure Service
Bus) isn't supported. However, it's possible to code such scenarios manually by using the trackDependency and
trackRequest APIs. In these APIs, a dependency telemetry represents a message being enqueued by a producer,
and the request represents a message being processed by a consumer. In this case, both operation_id and
operation_parentId should be propagated in the message's properties.
Telemetry correlation in Asynchronous Java Application

In order to correlate telemetry in Asynchronous Spring Boot application, please follow this in-depth article. It
provides guidance for instrumenting Spring's ThreadPoolTaskExecutor as well as ThreadPoolTaskScheduler.
Role name
At times, you might want to customize the way component names are displayed in the Application Map. To do so,
you can manually set the cloud_RoleName by doing one of the following:
If you use Spring Boot with the Application Insights Spring Boot starter, the only required change is to set
your custom name for the application in the application.properties file.
The Spring Boot starter automatically assigns cloudRoleName to the value you enter for the
If you're using the WebRequestTrackingFilter , the WebAppNameContextInitializer sets the application name
automatically. Add the following to your configuration file (ApplicationInsights.xml):
<ContextInitializers>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebAppNameContextInitializer" />
</ContextInitializers>
If you use the cloud context class:
telemetryClient.getContext().getCloud().setRole("My Component Name");
Next steps
Write custom telemetry.
For advanced correlation scenarios in ASP.NET Core and ASP.NET consult the track custom operations article.
Learn more about setting cloud_RoleName for other SDKs.
Onboard all components of your microservice on Application Insights. Check out the supported platforms.
See the data model for Application Insights types.
Learn how to extend and filter telemetry.
Review the Application Insights config reference.
Local forwarder (Preview)
Local forwarder is an agent that collects Application Insights or OpenCensus telemetry from a variety of SDKs
and routes it to Application Insights. It's capable of running under Windows and Linux. You may also be able to
run it under macOS, but that is not officially supported at this time.
Running local forwarder

Local forwarder is an open source project on GitHub. There are a variety of ways to run local forwarder on
multiple platforms.
Windows
Windows Service
The easiest way of running local forwarder under Windows is by installing it as a Windows Service. The release
comes with a Windows Service executable
(WindowsServiceHost/Microsoft.LocalForwarder.WindowsServiceHost.exe) which can be easily registered with the
operating system.
NOTE
The local forwarder service requires a minimum of .NET Framework 4.7. If you do not have .NET Framework 4.7 the service
will install, but it won't start. To access the lastest version of the .NET Framework visit the .NET Framework download
page.
1. Download the LF.WindowsServiceHost.zip file from the local forwarder release page on GitHub.
2. In this example for ease of demonstration, we will just extract the .zip file to the path
C:\LF-WindowsServiceHost .
To register the service and configure it to start at system boot run the following from the command line as
Administrator:
sc create "Local Forwarder" binpath="C:\LF-

WindowsServiceHost\Microsoft.LocalForwarder.WindowsServiceHost.exe" start=auto
You should receive a response of:

[SC] CreateService SUCCESS
To examine your new service via the Services GUI type services.msc
3. Right-click the new local forwarder and select Start. Your service will now enter a running state.
4. By default the service is created without any recovery actions. You can right-click and select Properties >
Recovery to configure automatic responses to a service failure.
Or if you prefer to set automatic recovery options programmatically for when failures occur, you can use:
sc failure "Local Forwarder" reset= 432000 actions= restart/1000/restart/1000/restart/1000
5. In the same location as your Microsoft.LocalForwarder.WindowsServiceHost.exe file, which in this example is

C:\LF-WindowsServiceHost there is a file called LocalForwarder.config . This is an xml based file that allows
you to adjust the configuration of your localforwader and specify the instrumentation key of the
Application Insights resource you want your distributed tracing data forwarded.
After editing the LocalForwarder.config file to add your instrumentation key, be sure to restart the Local
Forwarder Service to allow your changes to take effect.
6. To confirm that your desired settings are in place and that the local forwarder is listening for trace data as
expected check the LocalForwarder.log file. You should see results similar to the image below at the bottom
of the file:
Console application
For certain use cases, it might be beneficial to run local forwarder as a console application. The release comes with
the following executable versions of the console host:
a framework-dependent .NET Core binary /ConsoleHost/publish/Microsoft.LocalForwarder.ConsoleHost.dll.
Running this binary requires a .NET Core runtime to be installed; refer to this download page for details.
E:\uncdrop\ConsoleHost\publish>dotnet Microsoft.LocalForwarder.ConsoleHost.dll
a self-contained .NET Core set of binaries for x86 and x64 platforms. These don't require .NET Core runtime to
run. /ConsoleHost/win-x86/publish/Microsoft.LocalForwarder.ConsoleHost.exe, /ConsoleHost/win-
x64/publish/Microsoft.LocalForwarder.ConsoleHost.exe.
E:\uncdrop\ConsoleHost\win-x86\publish>Microsoft.LocalForwarder.ConsoleHost.exe
E:\uncdrop\ConsoleHost\win-x64\publish>Microsoft.LocalForwarder.ConsoleHost.exe
Linux
As with Windows, the release comes with the following executable versions of the console host:
a framework-dependent .NET Core binary /ConsoleHost/publish/Microsoft.LocalForwarder.ConsoleHost.dll.
Running this binary requires a .NET Core runtime to be installed; refer to this download page for details.
dotnet Microsoft.LocalForwarder.ConsoleHost.dll
a self-contained .NET Core set of binaries for linux-64. This one doesn't require .NET Core runtime to run.
/ConsoleHost/linux-x64/publish/Microsoft.LocalForwarder.ConsoleHost.
user@machine:~/ConsoleHost/linux-x64/publish$ sudo chmod +x Microsoft.LocalForwarder.ConsoleHost

user@machine:~/ConsoleHost/linux-x64/publish$ ./Microsoft.LocalForwarder.ConsoleHost
Many Linux users will want to run local forwarder as a daemon. Linux systems come with a variety of solutions for
service management, like Upstart, sysv, or systemd. Whatever your particular version is, you can use it to run local
forwarder in a way that is most appropriate for your scenario.
As an example, let's create a daemon service using systemd. We'll use the framework-dependent version, but the
same can be done for a self-contained one as well.
create the following service file named localforwarder.service and place it into /lib/systemd/system. This sample
assumes your user name is SAMPLE_USER and you've copied local forwarder framework-dependent binaries
(from /ConsoleHost/publish) to /home/SAMPLE_USER/LOCALFORWARDER_DIR.
# localforwarder.service
# Place this file into /lib/systemd/system/
# Use 'systemctl enable localforwarder' to start the service automatically on each boot
# Use 'systemctl start localforwarder' to start the service immediately
[Unit]
Description=Local Forwarder service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=SAMPLE_USER
WorkingDirectory=/home/SAMPLE_USER/LOCALFORWARDER_DIR
ExecStart=/usr/bin/env dotnet /home/SAMPLE_USER/LOCALFORWARDER_DIR/Microsoft.LocalForwarder.ConsoleHost.dll
noninteractive
[Install]
WantedBy=multi-user.target
Run the following command to instruct systemd to start local forwarder on every boot
systemctl enable localforwarder
Run the following command to instruct systemd to start local forwarder immediately
systemctl start localforwarder
Monitor the service by inspecting *.log files in the /home/SAMPLE_USER/LOCALFORWARDER_DIR

directory.
Mac
Local forwarder may work with macOS, but it is currently not officially supported.
Self-hosting
Local forwarder is also distributed as a .NET Standard NuGet package, allowing you to host it inside your own
.NET application.
using Library;
...
Host host = new Host();
// see section below on configuring local forwarder

string configuration = ...;
host.Run(config, TimeSpan.FromSeconds(5));
...
host.Stop();
Configuring local forwarder

When running one of local forwarder's own hosts (Console Host or Windows Service Host), you will find
LocalForwarder.config placed next to the binary.
When self-hosting the local forwarder NuGet, the configuration of the same format must be provided in code
(see section on self-hosting). For the configuration syntax, check the LocalForwarder.config in the GitHub
repository.
NOTE
Configuration may change from release to release, so pay attention to which version you're using.
Monitoring local forwarder

Traces are written out to the file system next to the executable that runs local forwarder (look for *.log files). You
can place a file with a name of NLog.config next to the executable to provide your own configuration in place of
the default one. See documentation for the description of the format.
If no configuration file is provided (which is the default), Local forwarder will use the default configuration, which
can be found here.
Next steps
Open Census
Collect distributed traces from Python (Preview)
Application Insights now supports distributed tracing of Python applications through integration with
OpenCensus. This article will walk you step-by-step through the process of setting up OpenCensus for Python and
getting your monitoring data to Application Insights.
Prerequisites
Python should be installed, this article uses Python 3.7.0, though earlier versions will likely work with minor
adjustment.

Create Application Insights resource

First you have to create an Application Insights resource, which will generate an instrumentation key(ikey). The
ikey is then used to configure the OpenCensus SDK to send telemetry data to Application Insights.
1. Select Create a resource > Developer Tools > Application Insights.
monitoring


2. Click Create.
Install OpenCensus Azure Monitor Exporters

1. Install the OpenCensus Azure Monitor Exporters:
python -m pip install opencensus-ext-azure

NOTE
python -m pip install opencensus-ext-azure assumes that you have a PATH environment variable set for your
Python installation. If you have not configured this, you would need to give the full directory path to where your
Python executable is located which would result in a command like:
C:\Users\Administrator\AppData\Local\Programs\Python\Python37-32\python.exe -m pip install
opencensus-ext-azure
.
2. First let's generate some trace data locally. In Python IDLE, or your editor of choice, enter the following
code:
from opencensus.trace.samplers import ProbabilitySampler

from opencensus.trace.tracer import Tracer
tracer = Tracer(sampler=ProbabilitySampler(1.0))
def valuePrompt():
with tracer.span(name="test") as span:
line = input("Enter a value: ")
print(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
3. Running the code will repeatedly prompt you to enter a value. With each entry, the value will be printed to
the shell, and a corresponding piece of SpanData will be generated by the OpenCensus Python Module.
The OpenCensus project defines a trace as a tree of spans.
Enter a value: 4
4
[SpanData(name='test', context=SpanContext(trace_id=8aa41bc469f1a705aed1bdb20c342603, span_id=None,
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='15ac5123ac1f6847',
parent_span_id=None, attributes=BoundedDict({}, maxlen=32), start_time='2019-06-27T18:21:22.805429Z',
end_time='2019-06-27T18:21:44.933405Z', child_span_count=0, stack_trace=None,
annotations=BoundedList([], maxlen=32), message_events=BoundedList([], maxlen=128),
links=BoundedList([], maxlen=32), status=None, same_process_as_parent_span=None, span_kind=0)]
Enter a value: 25
25
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='2e512f846ba342de',
Enter a value: 100
100
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='f3f9f9ee6db4740a',
4. While helpful for demonstration purposes, ultimately we want to emit the SpanData to Application Insights.
Modify your code from the previous step based on the following code sample:
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer
# TODO: replace the all-zero GUID with your instrumentation key.

tracer = Tracer(
exporter=AzureExporter(
instrumentation_key='00000000-0000-0000-0000-000000000000',
),
sampler=ProbabilitySampler(1.0),
)
def valuePrompt():
with tracer.span(name="test") as span:
line = input("Enter a value: ")
print(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
5. Now when you run the Python script, you should still be prompted to enter values, but now only the value is
being printed in the shell.

1. You can now reopen the Application Insights Overview page in the Azure portal, to view details about your
currently running application. Select Live Metric Stream.
2. Navigate back to the Overview page and select Application Map for a visual layout of the dependency
relationships and call timing between your application components.
Since we were only tracing one method call, our application map isn't as interesting. But application map
can scale to visualize far more distributed applications:
3. Select Investigate Performance to perform detailed performance analysis and determine the root cause
of slow performance.
4. Selecting Samples and then clicking on any of the samples that appear in the right-hand pane will launch
the end-to-end transaction details experience. While our sample app will just show us a single event, a more
complex application would allow you to explore the end-to-end transaction down to level of an individual
event's call stack.
OpenCensus for Python

Customization
Flask Integration
Django Integration
MySQL Integration
PostgreSQL
Next steps
OpenCensus Python on GitHub
Application map
Collect distributed traces from Go (Preview)
Application Insights now supports distributed tracing of Go applications through integration with OpenCensus
and our new local forwarder. This article will walk you step-by-step through the process of setting up OpenCensus
for Go and getting your trace data to Application Insights.
Prerequisites
Go should be installed, this article uses the version 1.11 Go Download.
Follow the instructions to install the local forwarder as a Windows service.

Create Application Insights resource

First you have to create an Application Insights resource which will generate an instrumentation key (ikey). The
ikey is then used to configure the local forwarder to send distributed traces from your OpenCensus instrumented
application, to Application Insights.
1. Select Create a resource > Developer Tools > Application Insights.
NOTE
If this is your first time creating an Application Insights resource you can learn more by visiting the Create an Application
Insights Resource article.
| Settings | Value | Description |
| ------------- |:-------------|:-----| | Name | Globally Unique Value | Name that identifies the app you are monitoring
| | Resource Group | myResourceGroup | Name for the new resource group to host App Insights data | | Location
| East US | Choose a location near you, or near where your app is hosted |
2. Click Create.
Configure local forwarder

1. Select Overview > Essentials > Copy your application's Instrumentation Key.
2. Edit your LocalForwarder.config file and add your instrumentation key. If you followed the instructions in
the pre-requisite the file is located at C:\LF-WindowsServiceHost
<OpenCensusToApplicationInsights>

<InstrumentationKey>{enter-instrumentation-key}</InstrumentationKey>
</OpenCensusToApplicationInsights>


<LiveMetricsStreamInstrumentationKey>{enter-instrumentation-key}
</LiveMetricsStreamInstrumentationKey>
</LocalForwarderConfiguration>
3. Restart the application Local Forwarder service.
OpenCensus Go packages
1. Install the Open Census packages for Go from the command line:
go get -u go.opencensus.io
go get -u contrib.go.opencensus.io/exporter/ocagent
2. Add the following code to a .go file and then build and run. (This example is derived from the official
OpenCensus guidance with added code that facilitates the integration with the local forwarder)
// Copyright 2018, OpenCensus Authors

//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package main
import (
"bytes"
"fmt"
"log"
"net/http"
os "os"
ocagent "contrib.go.opencensus.io/exporter/ocagent"
"go.opencensus.io/plugin/ochttp"
"go.opencensus.io/plugin/ochttp/propagation/tracecontext"
"go.opencensus.io/trace"
func main() {
// Register stats and trace exporters to export the collected data.
serviceName := os.Getenv("SERVICE_NAME")
if len(serviceName) == 0 {
serviceName = "go-app"
}
fmt.Printf(serviceName)
agentEndpoint := os.Getenv("OCAGENT_TRACE_EXPORTER_ENDPOINT")
if len(agentEndpoint) == 0 {
agentEndpoint = fmt.Sprintf("%s:%d", ocagent.DefaultAgentHost, ocagent.DefaultAgentPort)
}
fmt.Printf(agentEndpoint)
exporter, err := ocagent.NewExporter(ocagent.WithInsecure(), ocagent.WithServiceName(serviceName),
ocagent.WithAddress(agentEndpoint))
if err != nil {
log.Printf("Failed to create the agent exporter: %v", err)
}
trace.RegisterExporter(exporter)
trace.ApplyConfig(trace.Config{DefaultSampler: trace.AlwaysSample()})
client := &http.Client{Transport: &ochttp.Transport{Propagation: &tracecontext.HTTPFormat{}}}
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {

fmt.Fprintf(w, "hello world")
var jsonStr = []byte(`[ { "url": "http://blank.org", "arguments": [] } ]`)

r, _ := http.NewRequest("POST", "http://blank.org", bytes.NewBuffer(jsonStr))
r.Header.Set("Content-Type", "application/json")
// Propagate the trace header info in the outgoing requests.

r = r.WithContext(req.Context())
resp, err := client.Do(r)
if err != nil {
log.Println(err)
} else {
// TODO: handle response
resp.Body.Close()
}
})
http.HandleFunc("/call_blank", func(w http.ResponseWriter, req *http.Request) {

fmt.Fprintf(w, "hello world")
r, _ := http.NewRequest("GET", "http://blank.org", nil)
// Propagate the trace header info in the outgoing requests.

r = r.WithContext(req.Context())
resp, err := client.Do(r)
if err != nil {
log.Println(err)
} else {
// TODO: handle response
resp.Body.Close()
}
})
log.Fatal(http.ListenAndServe(":50030", &ochttp.Handler{Propagation: &tracecontext.HTTPFormat{}}))
3. Once the simple go app is running navigate to http://localhost:50030 . Each refresh of the browser will
generate the text "hello world" accompanied by corresponding span data that is picked up by the local
forwarder.
4. To confirm that the local forwarder is picking up the traces check the LocalForwarder.config file. If you
followed the steps in the prerequisite, it will be located in C:\LF-WindowsServiceHost .
In the image below of the log file, you can see that prior to running the second script where we added an
exporter OpenCensus input BatchesReceived was 0. Once we started running the updated script
BatchesReceived incremented equal to the number of values we entered:

1. You can now reopen the Application Insights Overview page in the Azure portal, to view details about your
currently running application. Select Live Metric Stream.
2. If you run the second Go app again and start refreshing the browser for http://localhost:50030 , you will
see live trace data as it arrives in Application Insights from the local forwarder service.
3. Navigate back to the Overview page and select Application Map for a visual layout of the dependency
relationships and call timing between your application components.
Since we were only tracing one method call, our application map isn't as interesting. But application map
can scale to visualize far more distributed applications:
4. Select Investigate Performance to perform detailed performance analysis and determine the root cause
of slow performance.
5. Selecting Samples and then clicking on any of the samples that appear in the right-hand pane will launch
the end-to-end transaction details experience. While our sample app will just show us a single event, a more
complex application would allow you to explore the end-to-end transaction down to level of an individual
event's call stack.
OpenCensus trace for Go

We only covered the basics of integrating OpenCensus for Go with the local forwarder and Application Insights.
The official OpenCensus Go usage guidance covers more advanced topics.
Next steps
Application map
Live Metrics Stream: Monitor & Diagnose with 1-
second latency
Probe the beating heart of your live, in-production web application by using Live Metrics Stream from
Application Insights. Select and filter metrics and performance counters to watch in real time, without any
disturbance to your service. Inspect stack traces from sample failed requests and exceptions. Together with
Profiler, Snapshot debugger. Live Metrics Stream provides a powerful and non-invasive diagnostic tool for your
live web site.
With Live Metrics Stream, you can:
Validate a fix while it is released, by watching performance and failure counts.
Watch the effect of test loads, and diagnose issues live.
Focus on particular test sessions or filter out known issues, by selecting and filtering the metrics you want to
watch.
Get exception traces as they happen.
Experiment with filters to find the most relevant KPIs.
Monitor any Windows performance counter live.
Easily identify a server that is having issues, and filter all the KPI/live feed to just that server.
Live Metrics are currently supported for ASP.NET, ASP.NET Core, Azure Functions, Java, and Node.js apps.
Get started
1. If you haven't yet install Application Insights in your web app, do that now.
2. In addition to the standard Application Insights packages
Microsoft.ApplicationInsights.PerfCounterCollector is required to enable Live Metrics stream.
3. Update to the latest version of the Application Insights package. In Visual Studio, right-click your
project and choose Manage Nuget packages. Open the Updates tab, and select all the
Microsoft.ApplicationInsights.* packages.
Redeploy your app.
4. In the Azure portal, open the Application Insights resource for your app, and then open Live Stream.
5. Secure the control channel if you might use sensitive data such as customer names in your filters.
Node.js
To use Live Metrics with Node.js you must update to version 1.30 or greater of the SDK. By default Live Metrics
is disabled in the Node.js SDK. To enable Live Metrics add setSendLiveMetrics(true) to your configuration
methods as you initialize the SDK.
No data? Check your server firewall
Check the outgoing ports for Live Metrics Stream are open in the firewall of your servers.
How does Live Metrics Stream differ from Metrics Explorer and
Analytics?
LIVE STREAM METRICS EXPLORER AND ANALYTICS
Latency Data displayed within one second Aggregated over minutes
No retention Data persists while it's on the chart, Data retained for 90 days
and is then discarded
On demand Data is streamed while you open Live Data is sent whenever the SDK is
Metrics installed and enabled
Free There is no charge for Live Stream data Subject to pricing
Sampling All selected metrics and counters are Events may be sampled
transmitted. Failures and stack traces
are sampled. TelemetryProcessors are
not applied.
Control channel Filter control signals are sent to the Communication is one-way, to the
SDK. We recommend you secure this portal
channel.
Select and filter your metrics

(Available with ASP.NET, ASP.NET Core, and Azure Functions (v2).)
You can monitor custom KPI live by applying arbitrary filters on any Application Insights telemetry from the
portal. Click the filter control that shows when you mouse-over any of the charts. The following chart is plotting
a custom Request count KPI with filters on URL and Duration attributes. Validate your filters with the Stream
Preview section that shows a live feed of telemetry that matches the criteria you have specified at any point in
time.
You can monitor a value different from Count. The options depend on the type of stream, which could be any
Application Insights telemetry: requests, dependencies, exceptions, traces, events, or metrics. It can be your own
custom measurement:
In addition to Application Insights telemetry, you can also monitor any Windows performance counter by
selecting that from the stream options, and providing the name of the performance counter.
Live metrics are aggregated at two points: locally on each server, and then across all servers. You can change the
default at either by selecting other options in the respective drop-downs.
Sample Telemetry: Custom Live Diagnostic Events

By default, the live feed of events shows samples of failed requests and dependency calls, exceptions, events, and
traces. Click the filter icon to see the applied criteria at any point in time.
As with metrics, you can specify any arbitrary criteria to any of the Application Insights telemetry types. In this
example, we are selecting specific request failures, traces, and events. We are also selecting all exceptions and
dependency failures.
Note: Currently, for Exception message-based criteria, use the outermost exception message. In the preceding
example, to filter out the benign exception with inner exception message (follows the "<--" delimiter) "The client
disconnected." use a message not-contains "Error reading request content" criteria.
See the details of an item in the live feed by clicking it. You can pause the feed either by clicking Pause or simply
scrolling down, or clicking an item. Live feed will resume after you scroll back to the top, or by clicking the
counter of items collected while it was paused.
Filter by server instance
If you want to monitor a particular server role instance, you can filter by server.
SDK Requirements
.NET
Custom Live Metrics Stream is available with version 2.4.0-beta2 or newer of Application Insights SDK for web.
Remember to select "Include Prerelease" option from NuGet package manager.
Node.js
Live Metrics Stream is available with version 1.3.0 or newer of the Application Insights SDK for Node.JS.
Remember to use setSendLiveMetrics(true) while configuring the SDK in your code.
Secure the control channel

The custom filters criteria you specify are sent back to the Live Metrics component in the Application Insights
SDK. The filters could potentially contain sensitive information such as customerIDs. You can make the channel
secure with a secret API key in addition to the instrumentation key.
Create an API Key
Add API key to Configuration
Classic ASP.NET
In the applicationinsights.config file, add the AuthenticationApiKey to the QuickPulseTelemetryModule:
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule,
<AuthenticationApiKey>YOUR-API-KEY-HERE</AuthenticationApiKey>
</Add>
Or in code, set it on the QuickPulseTelemetryModule:

TelemetryConfiguration configuration = new TelemetryConfiguration();

configuration.InstrumentationKey = "YOUR-IKEY-HERE";
QuickPulseTelemetryProcessor processor = null;
configuration.TelemetryProcessorChainBuilder
.Use((next) =>
{
processor = new QuickPulseTelemetryProcessor(next);
return processor;
})
.Build();
var QuickPulse = new QuickPulseTelemetryModule()

{
AuthenticationApiKey = "YOUR-API-KEY"
};
QuickPulse.Initialize(configuration);
QuickPulse.RegisterTelemetryProcessor(processor);
foreach (var telemetryProcessor in configuration.TelemetryProcessors)
{
if (telemetryProcessor is ITelemetryModule telemetryModule)
{
telemetryModule.Initialize(configuration);
}
}
Azure Function Apps

For Azure Function Apps (v2) securing the channel with an API key can be accomplished with an environment
variable.
Create an API key from within your Application Insights resource and go to Application Settings for your
Function App. Select add new setting and enter a name of APPINSIGHTS_QUICKPULSEAUTHAPIKEY and a value that
corresponds to your API key.
ASP.NET Core (Requires Application Insights ASP.NET Core SDK 2.3.0-beta or greater)
Modify your startup.cs file as follows:
First add
Then within the ConfigureServices method add:
services.ConfigureTelemetryModule<QuickPulseTelemetryModule> ((module, o) => module.AuthenticationApiKey =

"YOUR-API-KEY-HERE");
However, if you recognize and trust all the connected servers, you can try the custom filters without the
authenticated channel. This option is available for six months. This override is required once every new session,
or when a new server comes online.
NOTE
We strongly recommend that you set up the authenticated channel before entering potentially sensitive information like
CustomerID in the filter criteria.
Troubleshooting
No data? If your application is in a protected network: Live Metrics Stream uses a different IP addresses than
other Application Insights telemetry. Make sure those IP addresses are open in your firewall.
Next steps
Monitoring usage with Application Insights
Using Diagnostic Search
Profiler
Snapshot debugger
Log-based and pre-aggregated metrics in
This article explains the difference between “traditional” Application Insights metrics that are based on logs, and
pre-aggregated metrics that are currently in public preview. Both types of metrics are available to the users of
Application Insights, and each brings a unique value in monitoring application health, diagnostics and analytics.
The developers who are instrumenting applications can decide which type of metric is best suited to a particular
scenario, depending on the size of the application, expected volume of telemetry, and business requirements for
metrics precision and alerting.
Log-based Metrics
Until recently, the application monitoring telemetry data model in Application Insights was solely based on a small
number of predefined types of events, such as requests, exceptions, dependency calls, page views, etc. Developers
can use the SDK to either emit these events manually (by writing code that explicitly invokes the SDK) or they can
rely on the automatic collection of events from auto-instrumentation. In either case, the Application Insights
backend stores all collected events as logs, and the Application Insights blades in the Azure portal act as an
analytical and diagnostic tool for visualizing event-based data from logs.
Using logs to retain a complete set of events can bring great analytical and diagnostic value. For example, you can
get an exact count of requests to a particular URL with the number of distinct users who made these calls. Or you
can get detailed diagnostic traces, including exceptions and dependency calls for any user session. Having this type
of information can significantly improve visibility into the application health and usage, allowing to cut down the
time necessary to diagnose issues with an app.
At the same time, collecting a complete set of events may be impractical (or even impossible) for applications that
generate a lot of telemetry. For situations when the volume of events is too high, Application Insights implements
several telemetry volume reduction techniques, such as sampling and filtering that reduce the number of collected
and stored events. Unfortunately, lowering the number of stored events also lowers the accuracy of the metrics
that, behind the scenes, must perform query-time aggregations of the events stored in logs.
NOTE
In Application Insights, the metrics that are based on the query-time aggregation of events and measurements stored in
logs are called log-based metrics. These metrics typically have many dimensions from the event properties, which makes
them superior for analytics, but the accuracy of these metrics is negatively affected by sampling and filtering.
Pre-aggregated metrics
In addition to log-based metrics, in Fall of 2018, the Application Insights team shipped a public preview of metrics
that are stored in a specialized repository that is optimized for time series. The new metrics are no longer kept as
individual events with lots of properties. Instead, they are stored as pre-aggregated time series, and only with key
dimensions. This makes the new metrics superior at query time: retrieving data happens much faster and requires
less compute power. This consequently enables new scenarios such as near real-time alerting on dimensions of
metrics, more responsive dashboards, and more.
IMPORTANT
Both, log-based and pre-aggregated metrics coexist in Application Insights. To differentiate the two, in the Application
Insights UX the pre-aggregated metrics are now called “Standard metrics (preview)”, while the traditional metrics from the
events were renamed to “Log-based metrics”.
The newer SDKs (Application Insights 2.7 SDK or later for .NET) pre-aggregate metrics during collection before
telemetry volume reduction techniques kick in. This means that the accuracy of the new metrics isn’t affected by
sampling and filtering when using the latest Application Insights SDKs.
For the SDKs that don’t implement pre-aggregation (that is, older versions of Application Insights SDKs or for
browser instrumentation) the Application Insights backend still populates the new metrics by aggregating the
events received by the Application Insights event collection endpoint. This means that while you don’t benefit from
the reduced volume of data transmitted over the wire, you can still use the pre-aggregated metrics and experience
better performance and support of the near real-time dimensional alerting with SDKs that don’t pre-aggregate
metrics during collection.
It is worth mentioning that the collection endpoint pre-aggregates events before ingestion sampling, which means
that ingestion sampling will never impact the accuracy of pre-aggregated metrics, regardless of the SDK version
you use with your application.
Using pre-aggregation with Application Insights custom metrics

You can use pre-aggregation with custom metrics. The two main benefits are the ability to configure and alert on a
dimension of a custom metric and reducing the volume of data sent from the SDK to the Application Insights
collection endpoint.
There are several ways of sending custom metrics from the Application Insights SDK. If your version of the SDK
offers the GetMetric and TrackValue methods, this is the preferred way of sending custom metrics, since in this
case pre-aggregation happens inside of the SDK, not only reducing the volume of data stored in Azure, but also
the volume of data transmitted from the SDK to Application Insights. Otherwise, use the trackMetric method,
which will pre-aggregate metric events during data ingestion.
Custom metrics dimensions and pre-aggregation

All metrics that you send using trackMetric or GetMetric and TrackValue API calls are automatically stored in both
logs and metrics stores. However, while the log-based version of your custom metric always retains all
dimensions, the pre-aggregated version of the metric is stored by default with no dimensions. You can turn on
collection of dimensions of custom metrics on the usage and estimated cost tab by checking “Enable alerting on
custom metric dimensions”:
Why is collection of custom metrics dimensions turned off by default?
The collection of custom metrics dimensions is turned off by default because in the future storing custom metrics
with dimensions will be billed separately from Application Insights, while storing the non-dimensional custom
metrics will remain free (up to a quota). You can learn about the upcoming pricing model changes on our official
pricing page.
Creating charts and exploring log-based and standard pre-aggregated

metrics
Use Azure Monitor Metrics Explorer to plot charts from pre-aggregated and log-based metrics, and to author
dashboards with charts. After selecting the desired Application Insights resource, use the namespace picker to
switch between standard (preview ) and log-based metrics, or select a custom metric namespace:
Next steps
Near real-time alerting
GetMetric and TrackValue
Application Insights log-based metrics
Application Insights log-based metrics let you analyze the health of your monitored apps, create powerful
dashboards, and configure alerts. There are two kinds of metrics:
Log-based metrics behind the scene are translated into Kusto queries from stored events.
Standard metrics are stored as pre-aggregated time series.
Since standard metrics are pre-aggregated during collection, they have better performance at query time. This
makes them a better choice for dashboarding and in real-time alerting. The log -based metrics have more
dimensions, which makes them the superior option for data analysis and ad-hoc diagnostics. Use the namespace
selector to switch between log-based and standard metrics in metrics explorer.
Interpret and use queries from this article

This article lists metrics with supported aggregations and dimensions. The details about log-based metrics include
the underlying Kusto query statements. For convenience, each query uses defaults for time granularity, chart type,
and sometimes splitting dimension which simplifies using the query in Log Analytics without any need for
modification.
When you plot the same metric in metrics explorer, there are no defaults - the query is dynamically adjusted based
on your chart settings:
The selected Time range is translated into an additional where timestamp... clause to only pick the events
from selected time range. For example, a chart showing data for the most recent 24 hours, the query
includes | where timestamp > ago (24 h).
The selected Time granularity is put into the final summarize ... by bin(timestamp, [time grain]) clause.
Any selected Filter dimensions are translated into additional where clauses.
The selected Split chart dimension is translated into an extra summarize property. For example, if you split
your chart by location, and plot using a 5-minute time granularity, the summarize clause is summarized ... by
bin(timestamp, 5 m ), location.
NOTE
If you're new to the Kusto query language, you start by copying and pasting Kusto statements into the Log Analytics query
pane without making any modifications. Click Run to see basic chart. As you begin to understand the syntax of query
language, you can start making small modifications and see the impact of your change. Exploring your own data is a great
way to start realizing the full power of Log Analytics and Azure Monitor.
Availability metrics
Metrics in the Availability category enable you to see the health of your web application as observed from points
around the world. Configure the availability tests to start using any metrics from this category.
Availability (availabilityResults/availabilityPercentage )
The Availability metric shows the percentage of the web test runs that didn't detect any issues. The lowest possible
value is 0, which indicates that all of the web test runs have failed. The value of 100 means that all of the web test
runs passed the validation criteria.
UNIT OF MEASURE SUPPORTED AGGREGATIONS SUPPORTED DIMENSIONS
Percentage Average Run location, Test name
availabilityResults
| summarize sum(todouble(success == 1) * 100) / count() by bin(timestamp, 5m), location
| render timechart
Availability test duration (availabilityResults/duration)

The Availability test duration metric shows how much time it took for the web test to run. For the multi-step web
tests, the metric reflects the total execution time of all steps.
Milliseconds Average, Min, Max Run location, Test name, Test result
availabilityResults
| where notempty(duration)
| extend availabilityResult_duration = iif(itemType == 'availabilityResult', duration, todouble(''))
| summarize sum(availabilityResult_duration)/sum(itemCount) by bin(timestamp, 5m), location
| render timechart
Availability tests (availabilityResults/count)

The Availability tests metric reflects the count of the web tests runs by Azure Monitor.
Count Count Run location, Test name, Test result
availabilityResults
| summarize sum(itemCount) by bin(timestamp, 5m)
| render timechart
Browser metrics
Browser metrics are collected by the Application Insights JavaScript SDK from real end-user browsers. They
provide great insights into your users' experience with your web app. Browser metrics are typically not sampled,
which means that they provide higher precision of the usage numbers compared to server-side metrics which
might be skewed by sampling.
NOTE
To collect browser metrics, your application must be instrumented with the Application Insights JavaScript SDK.
Browser page load time (browserTimings/totalDuration)

UNIT OF MEASURE SUPPORTED AGGREGATIONS PRE-AGGREGATED DIMENSIONS
Milliseconds Average, Min, Max None

browserTimings
| where notempty(totalDuration)
| extend _sum = totalDuration
| extend _count = itemCount
| extend _sum = _sum * _count
| summarize sum(_sum) / sum(_count) by bin(timestamp, 5m)
| render timechart
Client processing time (browserTiming/processingDuration)

browserTimings
| where notempty(processingDuration)
| extend _sum = processingDuration
| summarize sum(_sum)/sum(_count) by bin(timestamp, 5m)
| render timechart
Page load network connect time (browserTimings/networkDuration)

browserTimings
| where notempty(networkDuration)
| extend _sum = networkDuration
| render timechart
Receiving response time (browserTimings/receiveDuration)

browserTimings
| where notempty(receiveDuration)
| extend _sum = receiveDuration
| render timechart
Send request time (browserTimings/sendDuration)


browserTimings
| where notempty(sendDuration)
| extend _sum = sendDuration
| render timechart
Failure metrics
The metrics in Failures show problems with processing requests, dependency calls, and thrown exceptions.
Browser exceptions (exceptions/browser)
This metric reflects the number of thrown exceptions from your application code running in browser. Only
exceptions that are tracked with a trackException() Application Insights API call are included in the metric.
PRE-AGGREGATED
UNIT OF MEASURE SUPPORTED AGGREGATIONS DIMENSIONS NOTES
Count Count None Log-based version uses Sum

aggregation
exceptions
| where notempty(client_Browser)
| render barchart
Dependency call failures (dependencies/failed)

The number of failed dependency calls.
PRE-AGGREGATED
Count Count None Log-based version uses Sum

aggregation
dependencies
| where success == 'False'
| render barchart
Exceptions (exceptions/count)
Each time when you log an exception to Application Insights, there is a call to the trackException() method of the
SDK. The Exceptions metric shows the number of logged exceptions.
PRE-AGGREGATED
Count Count Cloud role name, Cloud role Log-based version uses Sum
instance, Device type aggregation
exceptions
| render barchart
Failed requests (requests/failed)

The count of tracked server requests that were marked as failed. By default, the Application Insights SDK
automatically marks each server request that returned HTTP response code 5xx or 4xx as a failed request. You can
customize this logic by modifying success property of request telemetry item in a custom telemetry initializer.
PRE-AGGREGATED
Count Count Cloud role instance, Cloud Log-based version uses Sum
role name, Real or synthetic aggregation
traffic, Request performance,
Response code
requests
| render barchart
Server exceptions (exceptions/server)

This metric shows the number of server exceptions.
PRE-AGGREGATED
Count Count Cloud role name, Cloud role Log-based version uses Sum
instance aggregation
exceptions
| where isempty(client_Browser)
| render barchart
Use metrics in the Performance counters category to access system performance counters collected by
Application Insights.
Available memory (performanceCounters/availableMemory)
performanceCounters
| where ((category == "Memory" and counter == "Available Bytes") or name == "availableMemory")
| extend performanceCounter_value = iif(itemType == "performanceCounter", value, todouble(''))
| summarize sum(performanceCounter_value) / count() by bin(timestamp, 1m)
| render timechart
Exception rate (performanceCounters/exceptionRate )

performanceCounters
| where ((category == ".NET CLR Exceptions" and counter == "# of Exceps Thrown / sec") or name ==
"exceptionRate")
| extend performanceCounter_value = iif(itemType == 'performanceCounter',value,todouble(''))
| render timechart
HTTP request execution time (performanceCounters/requestExecutionTime )
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Request Execution Time") or name ==
"requestExecutionTime")
| render timechart
HTTP request rate (performanceCounters/requestsPerSecond)
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Requests/Sec") or name == "requestsPerSecond")
| render timechart
HTTP requests in application queue (performanceCounters/requestsInQueue )
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Requests In Application Queue") or name ==
"requestsInQueue")
| render timechart
Process CPU (performanceCounters/processCpuPercentage )

The metric shows how much of the total processor capacity is consumed by the process that is hosting your
monitored app.
Percentage Average, Min, Max Cloud role instance
performanceCounters
| where ((category == "Process" and counter == "% Processor Time Normalized") or name ==
"processCpuPercentage")
| render timechart
Process IO rate (performanceCounters/processIOBytesPerSecond)

Bytes per second Average, Min, Max Cloud role instance

performanceCounters
| where ((category == "Process" and counter == "IO Data Bytes/sec") or name == "processIOBytesPerSecond")
| render timechart
Process private bytes (performanceCounters/processPrivateBytes)

Amount of non-shared memory that the monitored process allocated for its data.
Bytes Average, Min, Max Cloud role instance
performanceCounters
| where ((category == "Process" and counter == "Private Bytes") or name == "processPrivateBytes")
| render timechart
Processor time (performanceCounters/processorCpuPercentage )

CPU consumption by all processes running on the monitored server instance.
Percentage Average, Min, Max Cloud role instance
NOTE
The processor time metric is not available for the applications hosted in Azure App Services. Use the Process CPU metric to
track CPU utilization of the web applications hosted in App Services.
performanceCounters
| where ((category == "Processor" and counter == "% Processor Time") or name == "processorCpuPercentage")
| render timechart
Server metrics
Dependency calls (dependencies/count)
This metric is in relation to the number of dependency calls.
dependencies
| render barchart
Dependency duration (dependencies/duration)

This metric refers to duration of dependency calls.
dependencies
| extend dependency_duration = iif(itemType == 'dependency',duration,todouble(''))
| extend _sum = dependency_duration
| extend _sum = _sum*_count
| summarize sum(_sum)/sum(_count) by bin(timestamp, 1m)
| render timechart
Server requests (requests/count)

This metric reflects the number of incoming server requests that were received by your web application.
requests
| render barchart
Server response time (requests/duration)

This metric reflects the time it took for the servers to process incoming requests.
requests
| extend request_duration = iif(itemType == 'request', duration, todouble(''))
| extend _sum = request_duration
| extend _sum = _sum*_count
| render timechart
Usage metrics
Page view load time (pageViews/duration)
This metric refers to the amount of time it took for PageView events to load.
pageViews
| extend pageView_duration = iif(itemType == 'pageView', duration, todouble(''))
| extend _sum = pageView_duration
| render barchart
Page views (pageViews/count)

The count of PageView events logged with the TrackPageView () Application Insights API.
pageViews
| summarize sum(itemCount) by bin(timestamp, 1h)
| render barchart
Sessions (sessions/count)
This metric refers to the count of distinct session IDs.
union traces, requests, pageViews, dependencies, customEvents, availabilityResults, exceptions, customMetrics,
browserTimings
| where notempty(session_Id)
| summarize dcount(session_Id) by bin(timestamp, 1h)
| render barchart
Traces (traces/count)
The count of trace statements logged with the TrackTrace() Application Insights API call.
traces
| summarize sum(itemCount) by bin(timestamp, 1h)
| render barchart
Users (users/count)
The number of distinct users who accessed your application. The accuracy of this metric may be significantly
impacted by using telemetry sampling and filtering.

browserTimings
| where notempty(user_Id)
| summarize dcount(user_Id) by bin(timestamp, 1h)
| render barchart
Users, Authenticated (users/authenticated)

The number of distinct users who authenticated into your application.

browserTimings
| where notempty(user_AuthenticatedId)
| summarize dcount(user_AuthenticatedId) by bin(timestamp, 1h)
| render barchart
Exploring Metrics in Application Insights
Metrics in Application Insights are measured values and counts of events that are sent in telemetry from
your application. They help you detect performance issues and watch trends in how your application is
being used. There's a wide range of standard metrics, and you can also create your own custom metrics
and events.
NOTE
This article describes the classic metrics explorer experience which is currently deprecated and will eventually be
retired. We recommend checking out the new experience which is described in this article.
Metrics and event counts are displayed in charts of aggregated values such as sums, averages, or counts.
Here's a sample set of charts:
You find metrics charts everywhere in the Application Insights portal. In most cases, they can be
customized, and you can add more charts to the blade. From the Overview blade, click through to more
detailed charts (which have titles such as "Servers"), or click Metrics Explorer to open a new blade where
you can create custom charts.
Time range
You can change the Time range covered by the charts or grids on any blade.
If you're expecting some data that hasn't appeared yet, click Refresh. Charts refresh themselves at intervals,
but the intervals are longer for larger time ranges. It can take a while for data to come through the analysis
pipeline onto a chart.
To zoom into part of a chart, drag over it:
Click the Undo Zoom button to restore it.
Granularity and point values

Hover your mouse over the chart to display the values of the metrics at that point.
The value of the metric at a particular point is aggregated over the preceding sampling interval.
The sampling interval or "granularity" is shown at the top of the blade.
You can adjust the granularity in the Time range blade:

The granularities available depend on the time range you select. The explicit granularities are alternatives to
the "automatic" granularity for the time range.
Editing charts and grids

To add a new chart to the blade:
Select Edit on an existing or new chart to edit what it shows:
You can display more than one metric on a chart, though there are restrictions about the combinations that
can be displayed together. As soon as you choose one metric, some of the others are disabled.
If you coded custom metrics into your app (calls to TrackMetric and TrackEvent) they will be listed here.
Segment your data

You can split a metric by property - for example, to compare page views on clients with different operating
systems.
Select a chart or grid, switch on grouping and pick a property to group by:
NOTE
When you use grouping, the Area and Bar chart types provide a stacked display. This is suitable where the
Aggregation method is Sum. But where the aggregation type is Average, choose the Line or Grid display types.
If you coded custom metrics into your app and they include property values, you'll be able to select the
property in the list.
Is the chart too small for segmented data? Adjust its height:
Aggregation types
The legend at the side by default usually shows the aggregated value over the period of the chart. If you
hover over the chart, it shows the value at that point.
Each data point on the chart is an aggregate of the data values received in the preceding sampling interval
or "granularity". The granularity is shown at the top of the blade, and varies with the overall timescale of the
chart.
Metrics can be aggregated in different ways:
Count is a count of the events received in the sampling interval. It is used for events such as
requests. Variations in the height of the chart indicates variations in the rate at which the events
occur. But note that the numeric value changes when you change the sampling interval.
Sum adds up the values of all the data points received over the sampling interval, or the period of
the chart.
Average divides the Sum by the number of data points received over the interval.
Unique counts are used for counts of users and accounts. Over the sampling interval, or over the
period of the chart, the figure shows the count of different users seen in that time.
% - percentage versions of each aggregation are used only with segmented charts. The total always
adds up to 100%, and the chart shows the relative contribution of different components of a total.
Change the aggregation type

The default method for each metric is shown when you create a new chart or when all metrics are
deselected:
Pin Y-axis
By default a chart shows Y axis values starting from zero till maximum values in the data range, to give a
visual representation of quantum of the values. But in some cases more than the quantum it might be
interesting to visually inspect minor changes in values. For customizations like this use the Y -axis range
editing feature to pin the Y -axis minimum or maximum value at desired place. Click on "Advanced
Settings" check box to bring up the Y -axis range Settings
Filter your data

To see just the metrics for a selected set of property values:
If you don't select any values for a particular property, it's the same as selecting them all: there is no filter
on that property.
Notice the counts of events alongside each property value. When you select values of one property, the
counts alongside other property values are adjusted.
Filters apply to all the charts on a blade. If you want different filters applied to different charts, create and
save different metrics blades. If you want, you can pin charts from different blades to the dashboard, so that
you can see them alongside each other.
Remove bot and web test traffic
Use the filter Real or synthetic traffic and check Real.
You can also filter by Source of synthetic traffic.
To add properties to the filter list
Would you like to filter telemetry on a category of your own choosing? For example, maybe you divide up
your users into different categories, and you would like segment your data by these categories.
Create your own property. Set it in a Telemetry Initializer to have it appear in all telemetry - including the
standard telemetry sent by different SDK modules.
Edit the chart type

Notice that you can switch between grids and graphs:
Save your metrics blade
When you've created some charts, save them as a favorite. You can choose whether to share it with other
team members, if you use an organizational account.
To see the blade again, go to the overview blade and open Favorites:
If you chose Relative time range when you saved, the blade will be updated with the latest metrics. If you
chose Absolute time range, it will show the same data every time.
Reset the blade

If you edit a blade but then you'd like to get back to the original saved set, just click Reset.
Live metrics stream
For a much more immediate view of your telemetry, open Live Stream. Most metrics take a few minutes to
appear, because of the process of aggregation. By contrast, live metrics are optimized for low latency.
Set alerts
To be notified by email of unusual values of any metric, add an alert. You can choose either to send the
email to the account administrators, or to specific email addresses.
Learn more about alerts.
Continuous Export
If you want data continuously exported so that you can process it externally, consider using Continuous
export.
Power BI
If you want even richer views of your data, you can export to Power BI.
Analytics
Analytics is a more versatile way to analyze your telemetry using a powerful query language. Use it if you
want to combine or compute results from metrics, or perform an in-depth exploration of your app's recent
performance.
From a metric chart, you can click the Analytics icon to get directly to the equivalent Analytics query.
Troubleshooting
I don't see any data on my chart.
Filters apply to all the charts on the blade. Make sure that, while you're focusing on one chart, you
didn't set a filter that excludes all the data on another.
If you want to set different filters on different charts, create them in different blades, save them as
separate favorites. If you want, you can pin them to the dashboard so that you can see them
alongside each other.
If you group a chart by a property that is not defined on the metric, then there will be nothing on the
chart. Try clearing 'group by', or choose a different grouping property.
Performance data (CPU, IO rate, and so on) is available for Java web services, Windows desktop
apps, IIS web apps and services if you install status monitor, and Azure Cloud Services. It isn't
available for Azure websites.
Video
Next steps
Monitoring usage with Application Insights
Using Diagnostic Search
Using Search in Application Insights
Search is a feature of Application Insights that you use to find and explore individual telemetry items,
such as page views, exceptions, or web requests. And you can view log traces and events that you have
coded.
(For more complex queries over your data, use Analytics.)
Where do you see Search?

In the Azure portal
You can open diagnostic search from the Application Insights Overview tab of your application (located
at in the top bar) or under investigate on the left.
Go to the Event types' drop-down menu to see a list of telemetry items- server requests, page views,
custom events that you have coded, and so on. At the top of the results' list, is a summary chart
showing counts of events over time.
Click out of the drop-down menu or Refresh to get new events.
In Visual Studio
In Visual Studio, there's also an Application Insights Search window. It's most useful for displaying
telemetry events generated by the application that you're debugging. But it can also show the events
collected from your published app at the Azure portal.
Open the Search window in Visual Studio:
The Search window has features similar to the web portal:
The Track Operation tab is available when you open a request or a page view. An 'operation' is a
sequence of events that is associated with to a single request or page view. For example, dependency
calls, exceptions, trace logs, and custom events might be part of a single operation. The Track Operation
tab shows graphically the timing and duration of these events in relation to the request or page view.
Inspect individual items

Select any telemetry item to see key fields and related items.
This will launch the end-to-end transaction details view.
Filter event types

Open the Event types' drop-down menu and choose the event types you want to see. (If, later, you want
to restore the filters, click Reset.)
The event types are:
Trace - Diagnostic logs including TrackTrace, log4Net, NLog, and System.Diagnostic.Trace calls.
Request - HTTP requests received by your server application, including pages, scripts, images, style
files, and data. These events are used to create the request and response overview charts.
Page View - Telemetry sent by the web client, used to create page view reports.
Custom Event - If you inserted calls to TrackEvent() in order to monitor usage, you can search
them here.
Exception - Uncaught exceptions in the server, and those that you log by using TrackException().
Dependency - Calls from your server application to other services such as REST APIs or
databases, and AJAX calls from your client code.
Availability - Results of availability tests.
Filter on property values

You can filter events on the values of their properties. The available properties depend on the event
types you selected. Click on the filter icon to start.
Choosing no values of a particular property has the same effect as choosing all values. It switches off
filtering on that property.
Notice that the counts to the right of the filter values show how many occurrences there are in the
current filtered set.
Find events with the same property

To find all the items with the same property value, either type it into the search bar or click the checkbox
when looking through properties in the filter tab.
Search the data
NOTE
To write more complex queries, open Logs (Analytics) from the top of the Search blade.
You can search for terms in any of the property values. This is useful if you have written custom events
with property values.
You might want to set a time range, as searches over a shorter range are faster.
Search for complete words, not substrings. Use quotation marks to enclose special characters.
STRING NOT FOUND FOUND
HomeController.About home homecontroller

controller about
out "homecontroller.about"
United States Uni united

ted states
united AND states
"united states"
Here are the search expressions you can use:
SAMPLE QUERY EFFECT
apple Find all events in the time range whose fields include
the word "apple"
apple AND banana Find events that contain both words. Use capital "AND",
apple banana not "and".
Short form.
apple OR banana Find events that contain either word. Use "OR", not "or".
apple NOT banana Find events that contain one word but not the other.
Sampling
If your app generates a large amount of telemetry (and you are using the ASP.NET SDK version 2.0.0-
beta3 or later), the adaptive sampling module automatically reduces the volume that is sent to the
portal by sending only a representative fraction of events. However, events that are related to the same
request are selected or deselected as a group, so that you can navigate between related events.
Learn about sampling.
Create work item

You can create a bug in GitHub or Azure DevOps with the details from any telemetry item.
Go to the end-to-end transaction detail view by clicking on any telemetry item then select Create work
item.
The first time you do this, you are asked to configure a link to your Azure DevOps organization and
project.
(You can also configure the link on the Work Items tab.)
Send more telemetry to Application Insights

In addition to the out-of-the-box telemetry sent by Application Insights SDK, you can:
Capture log traces from your favorite logging framework in .NET or Java. This means you can
search through your log traces and correlate them with page views, exceptions, and other events.
Write code to send custom events, page views, and exceptions.
Learn how to send logs and custom telemetry to Application Insights.
Q&A
How much data is retained?
See the Limits summary.
How can I see POST data in my server requests?
We don't log the POST data automatically, but you can use TrackTrace or log calls. Put the POST data in
the message parameter. You can't filter on the message in the same way you can filter on properties,
but the size limit is longer.
Next steps
Write complex queries in Analytics
Send logs and custom telemetry to Application Insights
Set up availability and responsiveness tests
Troubleshooting
Profile production applications in Azure with
Enable Application Insights Profiler for your application

Azure Application Insights Profiler provides performance traces for applications that are running in production in
Azure. Profiler captures the data automatically at scale without negatively affecting your users. Profiler helps you
identify the “hot” code path that takes the longest time when it's handling a particular web request.
Profiler works with .NET applications that are deployed on the following Azure services. Specific instructions for
enabling Profiler for each service type are in the links below.
Azure App Service
Azure Service Fabric
Azure Virtual Machines and virtual machine scale sets
PREVIEW ASP.NET Core Azure Linux Web Apps
If you've enabled Profiler but aren't seeing traces, check our Troubleshooting guide.
View Profiler data

For Profiler to upload traces, your application must be actively handling requests. If you're doing an experiment,
you can generate requests to your web app by using Application Insights performance testing. If you've newly
enabled Profiler, you can run a short load test. While the load test is running, select the Profile Now button on
the Profiler Settings pane. When Profiler is running, it profiles randomly about once per hour and for a duration
of two minutes. If your application is handling a steady stream of requests, Profiler uploads traces every hour.
After your application receives some traffic and Profiler has had time to upload the traces, you should have traces
to view. This process can take 5 to 10 minutes. To view traces, in the Performance pane, select Take Actions, and
then select the Profiler Traces button.
Select a sample to display a code-level breakdown of time spent executing the request.
The trace explorer displays the following information:

Show Hot Path: Opens the biggest leaf node, or at least something close. In most cases, this node is near a
performance bottleneck.
Label: The name of the function or event. The tree displays a mix of code and events that occurred, such as
SQL and HTTP events. The top event represents the overall request duration.
Elapsed: The time interval between the start of the operation and the end of the operation.
When: The time when the function or event was running in relation to other functions.
How to read performance data
The Microsoft service profiler uses a combination of sampling methods and instrumentation to analyze the
performance of your application. When detailed collection is in progress, the service profiler samples the
instruction pointer of each machine CPU every millisecond. Each sample captures the complete call stack of the
thread that's currently executing. It gives detailed information about what that thread was doing, at both a high
level and a low level of abstraction. The service profiler also collects other events to track activity correlation and
causality, including context switching events, Task Parallel Library (TPL ) events, and thread pool events.
The call stack that's displayed in the timeline view is the result of the sampling and instrumentation. Because each
sample captures the complete call stack of the thread, it includes code from Microsoft .NET Framework and from
other frameworks that you reference.
Object allocation (clr!JIT_New or clr!JIT_Newarr1)
clr!JIT_New and clr!JIT_Newarr1 are helper functions in .NET Framework that allocate memory from a
managed heap. clr!JIT_New is invoked when an object is allocated. clr!JIT_Newarr1 is invoked when an object
array is allocated. These two functions are usually fast and take relatively small amounts of time. If clr!JIT_New or
clr!JIT_Newarr1 takes a lot of time in your timeline, the code might be allocating many objects and consuming
significant amounts of memory.
Loading code (clr!ThePreStub)
clr!ThePreStub is a helper function in .NET Framework that prepares the code to execute for the first time. This
execution usually includes, but isn't limited to, just-in-time (JIT) compilation. For each C# method, clr!ThePreStub
should be invoked at most once during a process.
If clr!ThePreStub takes a long time for a request, the request is the first one to execute that method. The time for
.NET Framework runtime to load the first method is significant. You might consider using a warmup process that
executes that portion of the code before your users access it, or consider running Native Image Generator
(ngen.exe) on your assemblies.
Lock contention (clr!JITutil_MonContention or clr!JITutil_MonEnterWorker)
clr!JITutil_MonContention or clr!JITutil_MonEnterWorker indicates that the current thread is waiting for a
lock to be released. This text is often displayed when you execute a C# LOCK statement, invoke the
Monitor.Enter method, or invoke a method with the MethodImplOptions.Synchronized attribute. Lock
contention usually occurs when thread A acquires a lock and thread B tries to acquire the same lock before thread
A releases it.
Loading code ([COLD])
If the method name contains [COLD ], such as mscorlib.ni!
[COLD ]System.Reflection.CustomAttribute.IsDefined, .NET Framework runtime is executing code for the
first time that isn't optimized by profile-guided optimization. For each method, it should be displayed at most once
during the process.
If loading code takes a substantial amount of time for a request, the request is the first one to execute the
unoptimized portion of the method. Consider using a warmup process that executes that portion of the code
before your users access it.
Send HTTP request
Methods such as HttpClient.Send indicate that the code is waiting for an HTTP request to be completed.
Database operation
Methods such as SqlCommand.Execute indicate that the code is waiting for a database operation to finish.
Waiting (AWAIT_TIME)
AWAIT_TIME indicates that the code is waiting for another task to finish. This delay usually happens with the C#
AWAIT statement. When the code does a C# AWAIT, the thread unwinds and returns control to the thread pool,
and there's no thread that is blocked waiting for the AWAIT to finish. However, logically, the thread that did the
AWAIT is "blocked," and it's waiting for the operation to finish. The AWAIT_TIME statement indicates the
blocked time waiting for the task to finish.
Blocked time
BLOCKED_TIME indicates that the code is waiting for another resource to be available. For example, it might be
waiting for a synchronization object, for a thread to be available, or for a request to finish.
Unmanaged Async
.NET framework emits ETW events and passes activity ids between threads so that async calls can be tracked
across threads. Unmanaged code (native code) and some older styles of asynchronous code are missing these
events and activity ids, so the profiler cannot tell what thread and what functions are running on the thread. This is
labeled 'Unmanaged Async' in the call stack. If you download the ETW file, you may be able to use PerfView to get
more insight into what is happening.
CPU time
The CPU is busy executing the instructions.
Disk time
The application is performing disk operations.
Network time
The application is performing network operations.
When column
The When column is a visualization of how the INCLUSIVE samples collected for a node vary over time. The total
range of the request is divided into 32 time buckets. The inclusive samples for that node are accumulated in those
32 buckets. Each bucket is represented as a bar. The height of the bar represents a scaled value. For nodes that are
marked CPU_TIME or BLOCKED_TIME, or where there is an obvious relationship to consuming a resource (for
example, a CPU, disk, or thread), the bar represents the consumption of one of the resources during the bucket.
For these metrics, it's possible to get a value of greater than 100 percent by consuming multiple resources. For
example, if you use, on average, two CPUs during an interval, you get 200 percent.
Limitations
The default data retention period is five days. The maximum data that's ingested per day is 10 GB.
There are no charges for using the Profiler service. For you to use it, your web app must be hosted in at least the
basic tier of the Web Apps feature of Azure App Service.
Overhead and sampling algorithm

Profiler randomly runs two minutes every hour on each virtual machine that hosts the application that has Profiler
enabled for capturing traces. When Profiler is running, it adds from 5 to 15 percent CPU overhead to the server.
Next steps
Enable Application Insights Profiler for your Azure application. Also see:
App Services
Profile live Azure App Service apps with
You can run Profiler on ASP.NET and ASP.NET Core apps that are running on Azure App Service using Basic
service tier or higher. Enabling Profiler on Linux is currently only possible via this method.
Enable Profiler for your app

To enable Profiler for an app, follow the instructions below. If you're running a different type of Azure service,
here are instructions for enabling Profiler on other supported platforms:
Cloud Services
Service Fabric Applications
Virtual Machines
Application Insights Profiler is pre-installed as part of the App Services runtime. The steps below will show you
how to enable it for your App Service. Follow these steps even if you've included the App Insights SDK in your
application at build time.
1. Enable "Always On" setting for your app service. You can update the setting in the Configuration page
of your App Service under General Settings.
2. Go to the App Services pane in the Azure portal.
3. Navigate to Settings > Application Insights pane.
4. Either follow the instructions on the pane to create a new resource or select an existing App Insights
resource to monitor your app. Also make sure the Profiler is On. If your Application Insights resource is
in a different subscription from your App Service, you can't use this page to configure Application
Insights. You can still do it manually though by creating the necessary app settings manually. The next
section contains instructions for manually enabling Profiler.
5. Profiler is now enabled using an App Services App Setting.
Enable Profiler manually or with Azure Resource Manager
Application Insights Profiler can be enabled by creating app settings for your Azure App Service. The page
with the options shown above creates these app settings for you. But you can automate the creation of these
settings using a template or other means. These settings will also work if your Application Insights resource is
in a different subscription from your Azure App Service. Here are the settings needed to enable the profiler:
APP SETTING VALUE
APPINSIGHTS_INSTRUMENTATIONKEY iKey for your Application Insights resource
APPINSIGHTS_PROFILERFEATURE_VERSION 1.0.0
DiagnosticServices_EXTENSION_VERSION ~3
You can set these values using Azure Resource Manager Templates, Azure Powershell, Azure CLI.
Enabling Profiler for other clouds manually
If you want to enable the profiler for other clouds, you can use the below app settings.
APP SETTING US GOVERNMENT VALUES CHINA CLOUD
ApplicationInsightsProfilerEndpoint https://agent.serviceprofiler.azure.us https://profiler.applicationinsights.azur

e.cn
ApplicationInsightsEndpoint https://dc.applicationinsights.us https://dc.applicationinsights.azure.cn
Disable Profiler
To stop or restart Profiler for an individual app's instance, under Web Jobs, go to the app resource. To delete
Profiler, go to Extensions.
We recommend that you have Profiler enabled on all your apps to discover any performance issues as early as
possible.
Profiler's files can be deleted when using WebDeploy to deploy changes to your web application. You can
prevent the deletion by excluding the App_Data folder from being deleted during deployment.
Next steps
Profile live Azure Cloud Services with Application
Insights
You can also deploy Application Insights Profiler on these services:

Azure App Service
Azure Service Fabric applications
Azure Virtual Machines
Application Insights Profiler is installed with the Azure Diagnostics extension. You just need to configure Azure
Diagnostics to install Profiler and send profiles to your Application Insights resource.
Enable Profiler for Azure Cloud Services

1. Check to make sure that you're using .NET Framework 4.6.1 or newer. If you are using OS family 4, you'll
need to install .NET Framework 4.6.1 or newer with a startup task. OS Family 5 includes a compatible
version of .NET Framework by default.
2. Add Application Insights SDK to Azure Cloud Services.
The bug in the profiler that ships in the WAD for Cloud Services has been fixed. The latest version
of WAD (1.12.2.0) for Cloud Services works with all recent versions of the App Insights SDK. Cloud Service
hosts will upgrade WAD automatically, but it isn't immediate. To force an upgrade, you can redeploy your
service or reboot the node.
3. Track requests with Application Insights:
For ASP.NET web roles, Application Insights can track the requests automatically.
For worker roles, add code to track requests.
4. Configure the Azure Diagnostics extension to enable Profiler:
a. Locate the Azure Diagnostics diagnostics.wadcfgx file for your application role, as shown here:
If you can't find the file, see Set up diagnostics for Azure Cloud Services and Virtual Machines.
b. Add the following SinksConfig section as a child element of WadCfg :
<WadCfg>
<DiagnosticMonitorConfiguration>...</DiagnosticMonitorConfiguration>
<SinksConfig>
<Sink name="MyApplicationInsightsProfiler">

<ApplicationInsightsProfiler>00000000-0000-0000-0000-000000000000</ApplicationInsightsProfiler>
</Sink>
</SinksConfig>
</WadCfg>
NOTE
If the diagnostics.wadcfgx file also contains another sink of type ApplicationInsights, all three of the following
instrumentation keys must match:
The key that's used by your application.
The key that's used by the ApplicationInsights sink.
The key that's used by the ApplicationInsightsProfiler sink.
You can find the actual instrumentation key value that's used by the ApplicationInsights sink in the
ServiceConfiguration.*.cscfg files. After the Visual Studio 15.5 Azure SDK release, only the instrumentation keys that
are used by the application and the ApplicationInsightsProfiler sink need to match each other.
5. Deploy your service with the new Diagnostics configuration, and Application Insights Profiler is configured
to run on your service.
Next steps
Generate traffic to your application (for example, launch an availability test). Then, wait 10 to 15 minutes for
traces to start to be sent to the Application Insights instance.
See Profiler traces in the Azure portal.
To troubleshoot Profiler issues, see Profiler troubleshooting.
Profile live Azure Service Fabric applications with
You can also deploy Application Insights Profiler on these services:

Azure App Service
Set up the environment deployment definition

Application Insights Profiler is included with Azure Diagnostics. You can install the Azure Diagnostics extension by
using an Azure Resource Manager template for your Service Fabric cluster. Get a template that installs Azure
Diagnostics on a Service Fabric Cluster.
To set up your environment, take the following actions:
1. Profiler supports .NET Framework and .Net Core. If you're using .NET Framework, make sure you're using
.NET Framework 4.6.1 or later. It's sufficient to confirm that the deployed OS is Windows Server 2012 R2 or
later. Profiler supports .NET Core 2.1 and newer applications.
2. Search for the Azure Diagnostics extension in the deployment template file.
3. Add the following SinksConfig section as a child element of WadCfg . Replace the
ApplicationInsightsProfiler property value with your own Application Insights instrumentation key:
"SinksConfig": {
"Sink": [
{
"name": "MyApplicationInsightsProfilerSink",
"ApplicationInsightsProfiler": "00000000-0000-0000-0000-000000000000"
}
]
}
For information about adding the Diagnostics extension to your deployment template, see Use monitoring
and diagnostics with a Windows VM and Azure Resource Manager templates.
4. Deploy your Service Fabric cluster by using your Azure Resource Manager template.
If your settings are correct, Application Insights Profiler will be installed and enabled when the Azure
Diagnostics extension is installed.
5. Add Application Insights to your Service Fabric application.
For Profiler to collect profiles for your requests, your application must be tracking operations with
Application Insights. For stateless APIs, you can refer to instructions for tracking Requests for profiling. For
more information about tracking custom operations in other kinds of apps, see track custom operations
with Application Insights .NET SDK.
6. Redeploy your application.
Next steps
For help with troubleshooting Profiler issues, see Profiler troubleshooting.
Profile web apps running on an Azure virtual
machine or a virtual machine scale set by using
Application Insights Profiler
NOTE
PowerShell.
You can also deploy Azure Application Insights Profiler on these services:
Azure App Service
Deploy Profiler on a virtual machine or a virtual machine scale set

This article shows you how to get Application Insights Profiler running on your Azure virtual machine (VM ) or
Azure virtual machine scale set. Profiler is installed with the Azure Diagnostics extension for VMs. Configure the
extension to run Profiler, and build the Application Insights SDK into your application.
1. Add the Application Insights SDK to your ASP.NET application.
To view profiles for your requests, you must send request telemetry to Application Insights.
2. Install Azure Diagnostics extension on your VM. For full Resource Manager template examples, see:
Virtual machine
Virtual machine scale set
The key part is the ApplicationInsightsProfilerSink in the WadCfg. To have Azure Diagnostics enable
Profiler to send data to your iKey, add another sink to this section.
"SinksConfig": {
"Sink": [
{
"name": "ApplicationInsightsSink",
"ApplicationInsights": "85f73556-b1ba-46de-9534-606e08c6120f"
},
{
"name": "MyApplicationInsightsProfilerSink",
"ApplicationInsightsProfiler": "85f73556-b1ba-46de-9534-606e08c6120f"
}
]
},
3. Deploy the modified environment deployment definition.

Applying the modifications usually involves a full template deployment or a cloud service-based publish
through PowerShell cmdlets or Visual Studio.
The following PowerShell commands are an alternate approach for existing virtual machines that touch
only the Azure Diagnostics extension. Add the previously mentioned ProfilerSink to the config that's
returned by the Get-AzVMDiagnosticsExtension command. Then pass the updated config to the Set-
AzVMDiagnosticsExtension command.
$ConfigFilePath = [IO.Path]::GetTempFileName()
# After you export the currently deployed Diagnostics config to a file, edit it to include the
ApplicationInsightsProfiler sink.
(Get-AzVMDiagnosticsExtension -ResourceGroupName "MyRG" -VMName "MyVM").PublicSettings | Out-File -
Verbose $ConfigFilePath
# Set-AzVMDiagnosticsExtension might require the -StorageAccountName argument
# If your original diagnostics configuration had the storageAccountName property in the
protectedSettings section (which is not downloadable), be sure to pass the same original value you had
in this cmdlet call.
Set-AzVMDiagnosticsExtension -ResourceGroupName "MyRG" -VMName "MyVM" -DiagnosticsConfigurationPath
$ConfigFilePath
4. If the intended application is running through IIS, enable the IIS Http Tracing Windows feature.
a. Establish remote access to the environment, and then use the Add Windows features window. Or run the
following command in PowerShell (as administrator):
Enable-WindowsOptionalFeature -FeatureName IIS-HttpTracing -Online -All
b. If establishing remote access is a problem, you can use the Azure CLI to run the following command:
az vm run-command invoke -g MyResourceGroupName -n MyVirtualMachineName --command-id

RunPowerShellScript --scripts "Enable-WindowsOptionalFeature -FeatureName IIS-HttpTracing -Online -All"
5. Deploy your application.
Set Profiler Sink using Azure Resource Explorer

We don't yet have a way to set the Application Insights Profiler sink from the portal. Instead of using powershell
like described above, you can use Azure Resource Explorer to set the sink. But note, if you deploy the VM again,
the sink will be lost. You'll need to update the config you use when deploying the VM to preserve this setting.
1. Check that the Windows Azure Diagnostics extension is installed by viewing the extensions installed for
your virtual machine.
2. Find the VM Diagnostics extension for your VM. Expand your resource group, Microsoft.Compute
virtualMachines, virtual machine name, and extensions.
3. Add the Application Insights Profiler sink to the SinksConfig node under WadCfg. If you don't already
have a SinksConfig section, you may need to add one. Be sure to specify the proper Application Insights
iKey in your settings. You'll need to switch the explorers mode to Read/Write in the upper right corner and
Press the blue 'Edit' button.
4. When you're done editing the config, press 'Put'. If the put is successful, a green check will appear in the
middle of the screen.
Can Profiler run on on-premises servers?
We have no plan to support Application Insights Profiler for on-premises servers.
Next steps
For help with troubleshooting Profiler issues, see Profiler troubleshooting.
Profile ASP.NET Core Azure Linux web apps with
This feature is currently in preview.

Find out how much time is spent in each method of your live web application when using Application Insights.
Application Insights Profiler is now available for ASP.NET Core web apps that are hosted in Linux on Azure App
Service. This guide provides step-by-step instructions on how the Profiler traces can be collected for ASP.NET
Core Linux web apps.
After you complete this walkthrough, your app can collect Profiler traces like the traces that are shown in the
image. In this example, the Profiler trace indicates that a particular web request is slow because of time spent
waiting. The hot path in the code that's slowing the app is marked by a flame icon. The About method in the
HomeController section is slowing the web app because the method is calling the Thread.Sleep function.
Prerequisites
The following instructions apply to all Windows, Linux, and Mac development environments:
Install the .NET Core SDK 2.1.2 or later.
Install Git by following the instructions at Getting Started - Installing Git.
Set up the project locally

1. Open a Command Prompt window on your machine. The following instructions work for all Windows,
Linux, and Mac development environments.
2. Create an ASP.NET Core MVC web application:
dotnet new mvc -n LinuxProfilerTest
3. Change the working directory to the root folder for the project.
4. Add the NuGet package to collect the Profiler traces:
dotnet add package Microsoft.ApplicationInsights.Profiler.AspNetCore

5. Enable Application Insights in Program.cs:

.UseApplicationInsights() // Add this line of code to Enable Application Insights
.UseStartup<Startup>();
6. Enable Profiler in Startup.cs:

{
services.AddServiceProfiler(); // Add this line of code to Enable Profiler
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
7. Add a line of code in the HomeController.cs section to randomly delay a few seconds:
using System.Threading;
...
public IActionResult About()

{
Random r = new Random();
int delay = r.Next(5000, 10000);
Thread.Sleep(delay);
return View();
}
8. Save and commit your changes to the local repository:
git init
git add .
git commit -m "first commit"
Create the Linux web app to host your project

1. Create the web app environment by using App Service on Linux:
2. Create the deployment credentials:
NOTE
Record your password to use later when deploying your web app.
3. Choose the deployment options. Set up a local Git repository in the web app by following the instructions
on the Azure portal. A Git repository is automatically created.
For more deployment options, see this article.
Deploy your project

1. In your Command Prompt window, browse to the root folder for your project. Add a Git remote repository
to point to the repository on App Service:
git remote add azure https://<username>@<app_name>.scm.azurewebsites.net:443/<app_name>.git
Use the username that you used to create the deployment credentials.
Use the app name that you used to create the web app by using App Service on Linux.
2. Deploy the project by pushing the changes to Azure:
git push azure master
You should see output similar to the following example:
```
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 1.78 KiB | 911.00 KiB/s, done.
Total 9 (delta 3), reused 0 (delta 0)
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id 'd7369a99d7'.
remote: Generating deployment script.
remote: Running deployment command...
remote: Handling ASP.NET Core Web Application deployment.
remote: ......
remote: Restoring packages for /home/site/repository/EventPipeExampleLinux.csproj...
remote: .
remote: Installing Newtonsoft.Json 10.0.3.
remote: Installing Microsoft.ApplicationInsights.Profiler.Core 1.1.0-LKG
…
```
Add Application Insights to monitor your web apps

1. Create an Application Insights resource.
2. Copy the iKey value of the Application Insights resource and set the following settings in your web apps:
APPINSIGHTS_INSTRUMENTATIONKEY: [YOUR_APPINSIGHTS_KEY]
When the app settings are changed, the site automatically restarts. After the new settings are applied, the
Profiler immediately runs for two minutes. The Profiler then runs for two minutes every hour.
3. Generate some traffic to your website. You can generate traffic by refreshing the site About page a few
times.
4. Wait two to five minutes for the events to aggregate to Application Insights.
5. Browse to the Application Insights Performance pane in the Azure portal. You can view the Profiler traces
at the bottom right of the pane.
Known issues
Profile Now button doesn't work for Linux Profiler
The Linux version of the App Insights profiler does not yet support on demand profiling using the profile now
button.
Next steps
If you use custom containers that are hosted by Azure App Service, follow the instructions in Enable Service
Profiler for a containerized ASP.NET Core application to enable Application Insights Profiler.
Report any issues or suggestions to the Application Insights GitHub repository: ApplicationInsights-Profiler-
AspNetCore: Issues.
Configure Application Insights Profiler
Updated Profiler Agent

The trigger features only work with version 2.6 or newer of the profiler agent. If you are running an Azure App
Service, your agent will be updated automatically. You can see what version of the agent you are running if you go
to the Kudu URL for your website and append \DiagnosticServices to the end of it, like this:
https://yourwebsite.scm.azurewebsites.net/diagnosticservices. The Application Insights Profiler Webjob should
version 2.6 or newer. You can force an upgrade by restarting your web app.
If you are running the profiler on a VM or Cloud Service, you need to have Windows Azure Diagnostics (WAD )
extension version 16.0.4 or newer installed. You can check the version of WAD by logging onto your VM and
looking this directory: C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics\1.16.0.4. The directory
name is the version of WAD that is installed. The Azure VM agent will update WAD automatically when new
versions are available.
Profiler settings page

To open the Azure Application Insights Profiler settings pane, go to the Application Insights Performance pane, and
then select the Configure Profiler button.
That opens a page that looks like this:

The Configure Application Insights Profiler page has these features:
Profile Now Starts profiling sessions for all apps that are linked to this
instance of Application Insights.
Triggers Allows you to configure triggers that cause the profiler to run.
Recent profiling sessions Displays information about past profiling sessions.
Profile Now
This option allows you to start a profiling session on demand. When you click this link, all profiler agents that are
sending data to this Application Insights instance will start to capture a profile. After 5 to 10 minutes, the profile
session will show in the list below.
For a user to manually trigger a profiler session, they require at minimum "write" access on their role for the
Application Insights component. In most cases, you get this access automatically and no additional work is needed.
If you're having issues, the subscription scope role to add would be the "Application Insights Component
Contributor" role. See more about role access control with Azure Monitoring.
Trigger Settings
Clicking the Triggers button on the menu bar opens the trigger settings box. You can set up trigger to start
profiling when the percentage of CPU or Memory use hits the level you set.
On / Off Button On: profiler can be started by this trigger; Off: profiler won't
be started by this trigger.
Memory threshold When this percentage of memory is in use, the profiler will be
started.
Duration Sets the length of time the profiler will run when triggered.
Cooldown Sets the length of time the profiler will wait before checking
for the memory or CPU usage again after it's triggered.
Recent Profiling Sessions

This section of the page shows information about recent profiling sessions. A profiling session represents the
period of time when the profiler agent was taking a profile on one of the machines hosting your application. You
can open the profiles from a session by clicking on one of the rows. For each session, we show:
Triggered by How the session was started, either by a trigger, Profile Now,
or default sampling.
App Name Name of the application that was profiled.
Machine Instance Name of the machine the profiler agent ran on.
Timestamp Time when the profile was captured.
Tracee Number of traces that were attached to individual requests.
CPU % Percentage of CPU that was being used while the profiler was
running.
Memory % Percentage of memory that was being used while the profiler
was running.
Use web performance tests to generate traffic to your application

You can trigger Profiler manually with a single click. Suppose you're running a web performance test. You'll need
traces to help you understand how your web app is running under load. Having control over when traces are
captured is crucial, because you know when the load test will be running. But the random sampling interval might
miss it.
The next sections illustrate how this scenario works:
Step 1: Generate traffic to your web app by starting a web performance test
If your web app already has incoming traffic or if you just want to manually generate traffic, skip this section and
continue to Step 2.
1. In the Application Insights portal, select Configure > Performance Testing.
2. To start a new performance test, select the New button.
3. In the New performance test pane, configure the test target URL. Accept all default settings, and then
select Run test to start running the load test.
The new test is queued first, followed by a status of in progress.
Step 2: Start a Profiler on-demand session

1. When the load test is running, start Profiler to capture traces on the web app while it's receiving load.
2. Go to the Configure Profiler pane.
Step 3: View traces
After Profiler finishes running, follow the instructions on notification to go to Performance pane and view traces.
Next steps
Enable Profiler and view traces
Write code to track requests with Application Insights
To view profiles for your application on the Performance page, Azure Application Insights needs to track requests
for your application. Application Insights can automatically track requests for applications that are built on already-
instrumented frameworks. Two examples are ASP.NET and ASP.NET Core.
For other applications, such as Azure Cloud Services worker roles and Service Fabric stateless APIs, you need to
write code to tell Application Insights where your requests begin and end. After you've written this code, requests
telemetry is sent to Application Insights. You can view the telemetry on the Performance page, and profiles are
collected for those requests.
To manually track requests, do the following:
1. Early in the application lifetime, add the following code:
...
// Replace with your own Application Insights instrumentation key.
TelemetryConfiguration.Active.InstrumentationKey = "00000000-0000-0000-0000-000000000000";
For more information about this global instrumentation key configuration, see Use Service Fabric with
2. For any piece of code that you want to instrument, add a StartOperation<RequestTelemetry> using
statement around it, as shown in the following example:
...
var client = new TelemetryClient();
...
using (var operation = client.StartOperation<RequestTelemetry>("Insert_Your_Custom_Event_Unique_Name"))
{
// ... Code I want to profile.
}
Calling StartOperation<RequestTelemetry> within another StartOperation<RequestTelemetry> scope isn't

supported. You can use StartOperation<DependencyTelemetry> in the nested scope instead. For example:
using (var getDetailsOperation = client.StartOperation<RequestTelemetry>("GetProductDetails"))
{
try
{
ProductDetail details = new ProductDetail() { Id = productId };
getDetailsOperation.Telemetry.Properties["ProductId"] = productId.ToString();
// By using DependencyTelemetry, 'GetProductPrice' is correctly linked as part of the

'GetProductDetails' request.
using (var getPriceOperation = client.StartOperation<DependencyTelemetry>("GetProductPrice"))
{
double price = await _priceDataBase.GetAsync(productId);
if (IsTooCheap(price))
{
throw new PriceTooLowException(productId);
}
details.Price = price;
}
// Similarly, note how 'GetProductReviews' doesn't establish another RequestTelemetry.

using (var getReviewsOperation = client.StartOperation<DependencyTelemetry>("GetProductReviews"))
{
details.Reviews = await _reviewDataBase.GetAsync(productId);
}
getDetailsOperation.Telemetry.Success = true;
return details;
}
catch(Exception ex)
{
getDetailsOperation.Telemetry.Success = false;
// This exception gets linked to the 'GetProductDetails' request telemetry.

client.TrackException(ex);
throw;
}
}
Troubleshoot problems enabling or viewing
General troubleshooting
Profiles are uploaded only if there are requests to your application while Profiler is running
Azure Application Insights Profiler collects profiling data for two minutes each hour. It also collects data when you
select the Profile Now button in the Configure Application Insights Profiler pane. But the profiling data is
uploaded only when it can be attached to a request that happened while Profiler was running.
Profiler writes trace messages and custom events to your Application Insights resource. You can use these events
to see how Profiler is running. If you think Profiler should be running and capturing traces, but they're not
displayed in the Performance pane, you can check to see how Profiler is running:
1. Search for trace messages and custom events sent by Profiler to your Application Insights resource. You
can use this search string to find the relevant data:
stopprofiler OR startprofiler OR upload OR ServiceProfilerSample
The following image displays two examples of searches from two AI resources:
At the left, the application isn't receiving requests while Profiler is running. The message explains
that the upload was canceled because of no activity.
At the right, Profiler started and sent custom events when it detected requests that happened while
Profiler was running. If the ServiceProfilerSample custom event is displayed, it means that Profiler
attached a trace to a request and you can view the trace in the Application Insights Performance
pane.
If no telemetry is displayed, Profiler is not running. To troubleshoot, see the troubleshooting sections
for your specific app type later in this article.
2. If there were requests while Profiler ran, make sure that the requests are handled by the part of your
application that has Profiler enabled. Although applications sometimes consist of multiple components,
Profiler is enabled for only some of the components. The Configure Application Insights Profiler pane
displays the components that have uploaded traces.
Other things to check
Make sure that your app is running on .NET Framework 4.6.
If your web app is an ASP.NET Core application, it must be running at least ASP.NET Core 2.0.
If the data you're trying to view is older than a couple of weeks, try limiting your time filter and try again.
Traces are deleted after seven days.
Make sure that proxies or a firewall have not blocked access to https://gateway.azureserviceprofiler.net.
Double counting in parallel threads
In some cases, the total time metric in the stack viewer is more than the duration of the request.
This situation might occur when two or more threads are associated with a request and they are operating in
parallel. In that case, the total thread time is more than the elapsed time. One thread might be waiting on the other
to be completed. The viewer tries to detect this situation and omits the uninteresting wait. In doing so, it errs on
the side of displaying too much information rather than omit what might be critical information.
When you see parallel threads in your traces, determine which threads are waiting so that you can ascertain the
critical path for the request. Usually, the thread that quickly goes into a wait state is simply waiting on the other
threads. Concentrate on the other threads, and ignore the time in the waiting threads.
Error report in the profile viewer
Submit a support ticket in the portal. Be sure to include the correlation ID from the error message.
Troubleshoot Profiler on Azure App Service

For Profiler to work properly:
Your web app service plan must be Basic tier or higher.
Your web app must have Application Insights enabled.
Your web app must have the following app settings:
APP SETTING VALUE
The ApplicationInsightsProfiler3 webjob must be running. To check the webjob:

1. Go to Kudu.
2. In the Tools menu, select WebJobs Dashboard.
The WebJobs pane opens.
3. To view the details of the webjob, including the log, select the ApplicationInsightsProfiler3 link.
The Continuous WebJob Details pane opens.
If you can't figure out why Profiler isn't working for you, you can download the log and send it to our team for
assistance, serviceprofilerhelp@microsoft.com.
Manual installation
When you configure Profiler, updates are made to the web app's settings. If your environment requires it, you can
apply the updates manually. An example might be that your application is running in a Web Apps environment for
PowerApps. To apply updates manually:
1. In the Web App Control pane, open Settings.
2. Set .NET Framework version to v4.6.
3. Set Always On to On.
4. Create these app settings:
APP SETTING VALUE
Too many active profiling sessions

Currently, you can enable Profiler on a maximum of four Azure web apps and deployment slots that are running
in the same service plan. If you have more than four web apps running in one app service plan, Profiler might
throw a Microsoft.ServiceProfiler.Exceptions.TooManyETWSessionException. Profiler runs separately for each web
app and attempts to start an Event Tracing for Windows (ETW ) session for each app. But a limited number of ETW
sessions can be active at one time. If the Profiler webjob reports too many active profiling sessions, move some
web apps to a different service plan.
Deployment error: Directory Not Empty 'D:\home\site\wwwroot\App_Data\jobs'
If you're redeploying your web app to a Web Apps resource with Profiler enabled, you might see the following
message:
Directory Not Empty 'D:\home\site\wwwroot\App_Data\jobs'
This error occurs if you run Web Deploy from scripts or from the Azure DevOps deployment pipeline. The
solution is to add the following additional deployment parameters to the Web Deploy task:
-skip:Directory='.*\\App_Data\\jobs\\continuous\\ApplicationInsightsProfiler.*' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data\\jobs\\continuous$' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data\\jobs$' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data$'
These parameters delete the folder that's used by Application Insights Profiler and unblock the redeploy process.
They don't affect the Profiler instance that's currently running.
How do I determine whether Application Insights Profiler is running?
Profiler runs as a continuous webjob in the web app. You can open the web app resource in the Azure portal. In
the WebJobs pane, check the status of ApplicationInsightsProfiler. If it isn't running, open Logs to get more
information.
Troubleshoot problems with Profiler and Azure Diagnostics

The bug in the profiler that ships in the WAD for Cloud Services has been fixed. The latest version of
WAD (1.12.2.0) for Cloud Services works with all recent versions of the App Insights SDK. Cloud Service
hosts will upgrade WAD automatically, but it isn't immediate. To force an upgrade, you can redeploy your
service or reboot the node.
To see whether Profiler is configured correctly by Azure Diagnostics, do the following three things:
1. First, check to see whether the contents of the Azure Diagnostics configuration that are deployed are what
you expect.
2. Second, make sure that Azure Diagnostics passes the proper iKey on the Profiler command line.
3. Third, check the Profiler log file to see whether Profiler ran but returned an error.
To check the settings that were used to configure Azure Diagnostics:
1. Sign in to the virtual machine (VM ), and then open the log file at this location. (The drive could be c: or d:
and the plugin version could be different.)
c:\logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.11.3.12\DiagnosticsPlugin.log
or
c:\WindowsAzure\logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.11.3.12\DiagnosticsPlugin.lo
g
2. In the file, you can search for the string WadCfg to find the settings that were passed to the VM to
configure Azure Diagnostics. You can check to see whether the iKey used by the Profiler sink is correct.
3. Check the command line that's used to start Profiler. The arguments that are used to launch Profiler are in
the following file. (The drive could be c: or d:)
D:\ProgramData\ApplicationInsightsProfiler\config.json
4. Make sure that the iKey on the Profiler command line is correct.
5. Using the path found in the preceding config.json file, check the Profiler log file. It displays the debug
information that indicates the settings that Profiler is using. It also displays status and error messages from
Profiler.
If Profiler is running while your application is receiving requests, the following message is displayed:
Activity detected from iKey.
When the trace is being uploaded, the following message is displayed: Start to upload trace.
Debug snapshots on exceptions in .NET apps
When an exception occurs, you can automatically collect a debug snapshot from your live web application. The
snapshot shows the state of source code and variables at the moment the exception was thrown. The Snapshot
Debugger (preview ) in Azure Application Insights monitors exception telemetry from your web app. It collects
snapshots on your top-throwing exceptions so that you have the information you need to diagnose issues in
production. Include the Snapshot collector NuGet package in your application, and optionally configure
collection parameters in ApplicationInsights.config. Snapshots appear on exceptions in the Application Insights
portal.
You can view debug snapshots in the portal to see the call stack and inspect variables at each call stack frame. To
get a more powerful debugging experience with source code, open snapshots with Visual Studio 2019
Enterprise. In Visual Studio, you can also set Snappoints to interactively take snapshots without waiting for an
exception.
Debug snapshots are stored for seven days. This retention policy is set on a per-application basis. If you need to
increase this value, you can request an increase by opening a support case in the Azure portal.
Enable Application Insights Snapshot Debugger for your application

Snapshot collection is available for:
.NET Framework and ASP.NET applications running .NET Framework 4.5 or later.
.NET Core 2.0 and ASP.NET Core 2.0 applications running on Windows.
The following environments are supported:
Azure App Service
Azure Cloud Services running OS family 4 or later
Azure Service Fabric services running on Windows Server 2012 R2 or later
Azure Virtual Machines and virtual machine scale sets running Windows Server 2012 R2 or later
On-premises virtual or physical machines running Windows Server 2012 R2 or later
NOTE
Client applications (for example, WPF, Windows Forms or UWP) are not supported.
If you've enabled Snapshot Debugger but aren't seeing snapshots, check our Troubleshooting guide.
Grant permissions
Access to snapshots is protected by role-based access control (RBAC ). To inspect a snapshot, you must first be
added to the necessary role by a subscription owner.
NOTE
Owners and contributors do not automatically have this role. If they want to view snapshots, they must add themselves to
the role.
Subscription owners should assign the Application Insights Snapshot Debugger role to users who will inspect
snapshots. This role can be assigned to individual users or groups by subscription owners for the target
Application Insights resource or its resource group or subscription.
1. Navigate to the Application Insights resource in the Azure portal.
2. Click Access control (IAM ).
3. Click the +Add role assignment button.
4. Select Application Insights Snapshot Debugger from the Roles drop-down list.
5. Search for and enter a name for the user to add.
6. Click the Save button to add the user to the role.
IMPORTANT
Snapshots can potentially contain personal and other sensitive information in variable and parameter values.
View Snapshots in the Portal

After an exception has occurred in your application and a snapshot has been created, you should have snapshots
to view. It can take 5 to 10 minutes from an exception occurring to a snapshot ready and viewable from the
portal. To view snapshots, in the Failure pane, select the Operations button when viewing the Operations tab,
or select the Exceptions button when viewing the Exceptions tab:
Select an operation or exception in the right pane to open the End-to-End Transaction Details pane, then
select the exception event. If a snapshot is available for the given exception, an Open Debug Snapshot button
appears on the right pane with details for the exception.
In the Debug Snapshot view, you see a call stack and a variables pane. When you select frames of the call stack
in the call stack pane, you can view local variables and parameters for that function call in the variables pane.
Snapshots might include sensitive information, and by default they aren't viewable. To view snapshots, you must
have the Application Insights Snapshot Debugger role assigned to you.
View Snapshots in Visual Studio 2017 Enterprise or above

1. Click the Download Snapshot button to download a .diagsession file, which can be opened by Visual
Studio Enterprise.
2. To open the .diagsession file, you need to have the Snapshot Debugger Visual Studio component
installed. The Snapshot Debugger component is a required component of the ASP.net workload in Visual
Studio and can be selected from the Individual Component list in the Visual Studio installer. If you are
using a version of Visual Studio prior to Visual Studio 2017 version 15.5, you will need to install the
extension from the Visual Studio Marketplace.
3. After you open the snapshot file, the Minidump Debugging page in Visual Studio appears. Click Debug
Managed Code to start debugging the snapshot. The snapshot opens to the line of code where the
exception was thrown so that you can debug the current state of the process.
The downloaded snapshot includes any symbol files that were found on your web application server. These
symbol files are required to associate snapshot data with source code. For App Service apps, make sure to
enable symbol deployment when you publish your web apps.
How snapshots work

The Snapshot Collector is implemented as an Application Insights Telemetry Processor. When your application
runs, the Snapshot Collector Telemetry Processor is added to your application's telemetry pipeline. Each time
your application calls TrackException, the Snapshot Collector computes a Problem ID from the type of exception
being thrown and the throwing method. Each time your application calls TrackException, a counter is
incremented for the appropriate Problem ID. When the counter reaches the ThresholdForSnapshotting value, the
Problem ID is added to a Collection Plan.
The Snapshot Collector also monitors exceptions as they're thrown by subscribing to the
AppDomain.CurrentDomain.FirstChanceException event. When that event fires, the Problem ID of the exception
is computed and compared against the Problem IDs in the Collection Plan. If there's a match, then a snapshot of
the running process is created. The snapshot is assigned a unique identifier and the exception is stamped with
that identifier. After the FirstChanceException handler returns, the thrown exception is processed as normal.
Eventually, the exception reaches the TrackException method again where it, along with the snapshot identifier, is
reported to Application Insights.
The main process continues to run and serve traffic to users with little interruption. Meanwhile, the snapshot is
handed off to the Snapshot Uploader process. The Snapshot Uploader creates a minidump and uploads it to
Application Insights along with any relevant symbol (.pdb) files.
TIP
A process snapshot is a suspended clone of the running process.
Creating the snapshot takes about 10 to 20 milliseconds.
The default value for ThresholdForSnapshotting is 1. This is also the minimum value. Therefore, your app has to
trigger the same exception twice before a snapshot is created.
Set IsEnabledInDeveloperMode to true if you want to generate snapshots while debugging in Visual Studio.
The snapshot creation rate is limited by the SnapshotsPerTenMinutesLimit setting. By default, the limit is one
snapshot every ten minutes.
No more than 50 snapshots per day may be uploaded.
Limitations
The default data retention period is 15 days. For each Application Insights instance, a maximum number of 50
snapshots is allowed per day.
Publish symbols
The Snapshot Debugger requires symbol files on the production server to decode variables and to provide a
debugging experience in Visual Studio. Version 15.2 (or above) of Visual Studio 2017 publishes symbols for
release builds by default when it publishes to App Service. In prior versions, you need to add the following line
to your publish profile .pubxml file so that symbols are published in release mode:
<ExcludeGeneratedDebugSymbol>False</ExcludeGeneratedDebugSymbol>
For Azure Compute and other types, make sure that the symbol files are in the same folder of the main
application .dll (typically, wwwroot/bin ) or are available on the current path.
NOTE
For more information on the different symbol options that are available consult the Visual Studio documentation. For best
results, we recommend using “Full”, “Portable” or “Embedded”.
Optimized builds
In some cases, local variables can't be viewed in release builds because of optimizations that are applied by the
JIT compiler. However, in Azure App Services, the Snapshot Collector can deoptimize throwing methods that are
part of its Collection Plan.
TIP
Install the Application Insights Site Extension in your App Service to get deoptimization support.
Next steps
Enable Application Insights Snapshot Debugger for your application:
Azure App Service
Azure Service Fabric services
On-premises virtual or physical machines
Beyond Application Insights Snapshot Debugger:
Set snappoints in your code to get snapshots without waiting for an exception.
Diagnose exceptions in your web apps explains how to make more exceptions visible to Application Insights.
Smart Detection automatically discovers performance anomalies.
Enable Snapshot Debugger for .NET apps in Azure
App Service
Snapshot Debugger currently works for ASP.NET and ASP.NET Core apps that are running on Azure App
Service on Windows service plans.
Enable Snapshot Debugger

To enable Snapshot Debugger for an app, follow the instructions below. If you are running a different type of
Azure service, here are instructions for enabling Snapshot Debugger on other supported platforms:
Azure Service Fabric services
On-premises virtual or physical machines
If you are using a preview version of .NET Core, please follow the instructions for Enable Snapshot Debugger for
other environments first to include the Microsoft.ApplicationInsights.SnapshotCollector NuGet package with the
application, and then complete the rest of the instructions below.
Application Insights Snapshot Debugger is pre-installed as part of the App Services runtime, but you need to turn
it on to get snapshots for your App Service app. Once you have deployed an app, even if you have included the
Application Insights SDK in the source code, follow the steps below to enable the snapshot debugger.
1. Go to the App Services pane in the Azure portal.
2. Navigate to Settings > Application Insights pane.
3. Either follow the instructions on the pane to create a new resource or select an existing App Insights
resource to monitor your app. Also make sure both switches for Snapshot Debugger are On.
4. Snapshot Debugger is now enabled using an App Services App Setting.
Disable Snapshot Debugger
Follow the same steps as for Enable Snapshot Debugger, but switch both switches for Snapshot Debugger to
Off. We recommend that you have Snapshot Debugger enabled on all your apps to ease diagnostics of
application exceptions.
Next steps
Generate traffic to your application that can trigger an exception. Then, wait 10 to 15 minutes for snapshots to
be sent to the Application Insights instance.
See snapshots in the Azure portal.
For help with troubleshooting Snapshot Debugger issues, see Snapshot Debugger troubleshooting.
Enable Snapshot Debugger for .NET apps in Azure
Service Fabric, Cloud Service, and Virtual Machines
If your ASP.NET or ASP.NET core application runs in Azure App Service, it's highly recommended to enable
Snapshot Debugger through the Application Insights portal page. However, if your application requires a
customized Snapshot Debugger configuration, or a preview version of .NET core, then this instruction should
be followed in addition to the instructions for enabling through the Application Insights portal page.
If your application runs in Azure Service Fabric, Cloud Service, Virtual Machines, or on-premises machines, the
following instructions should be used.
Configure snapshot collection for ASP.NET applications

1. Enable Application Insights in your web app, if you haven't done it yet.
2. Include the Microsoft.ApplicationInsights.SnapshotCollector NuGet package in your app.
3. If needed, customized the Snapshot Debugger configuration added to ApplicationInsights.config. The
default Snapshot Debugger configuration is mostly empty and all settings are optional. Here is an
example showing a configuration equivalent to the default configuration:
<Add Type="Microsoft.ApplicationInsights.SnapshotCollector.SnapshotCollectorTelemetryProcessor,
Microsoft.ApplicationInsights.SnapshotCollector">

<IsEnabled>true</IsEnabled>


<IsEnabledInDeveloperMode>false</IsEnabledInDeveloperMode>

<ThresholdForSnapshotting>1</ThresholdForSnapshotting>

<MaximumSnapshotsRequired>3</MaximumSnapshotsRequired>

<MaximumCollectionPlanSize>50</MaximumCollectionPlanSize>

<ReconnectInterval>00:15:00</ReconnectInterval>

<ProblemCounterResetInterval>1.00:00:00</ProblemCounterResetInterval>

<SnapshotsPerTenMinutesLimit>3</SnapshotsPerTenMinutesLimit>

<SnapshotsPerDayLimit>30</SnapshotsPerDayLimit>

<ProvideAnonymousTelemetry>true</ProvideAnonymousTelemetry>

<FailedRequestLimit>3</FailedRequestLimit>
</Add>
4. Snapshots are collected only on exceptions that are reported to Application Insights. In some cases (for
example, older versions of the .NET platform), you might need to configure exception collection to see
exceptions with snapshots in the portal.
Configure snapshot collection for applications using ASP.NET Core

2.0 or above
1. Enable Application Insights in your ASP.NET Core web app, if you haven't done it yet.
NOTE
Be sure that your application references version 2.1.1, or newer, of the Microsoft.ApplicationInsights.AspNetCore
package.
2. Include the Microsoft.ApplicationInsights.SnapshotCollector NuGet package in your app.

3. Modify your application's Startup class to add and configure the Snapshot Collector's telemetry
processor.
a. If Microsoft.ApplicationInsights.SnapshotCollector NuGet package version 1.3.5 or above is used,
then add the following using statements to Startup.cs .
using Microsoft.ApplicationInsights.SnapshotCollector;
Add the following at the end of the ConfigureServices method in the Startup class in
Startup.cs .
services.AddSnapshotCollector((configuration) =>
Configuration.Bind(nameof(SnapshotCollectorConfiguration), configuration));
b. If Microsoft.ApplicationInsights.SnapshotCollector NuGet package version 1.3.4 or below is used,

then add the following using statements to Startup.cs .
using Microsoft.ApplicationInsights.SnapshotCollector;
using Microsoft.Extensions.Options;
using Microsoft.ApplicationInsights.AspNetCore;
Add the following SnapshotCollectorTelemetryProcessorFactory class to Startup class.

class Startup
{
private class SnapshotCollectorTelemetryProcessorFactory : ITelemetryProcessorFactory
{
private readonly IServiceProvider _serviceProvider;
public SnapshotCollectorTelemetryProcessorFactory(IServiceProvider serviceProvider) =>

_serviceProvider = serviceProvider;
public ITelemetryProcessor Create(ITelemetryProcessor next)

{
var snapshotConfigurationOptions =
_serviceProvider.GetService<IOptions<SnapshotCollectorConfiguration>>();
return new SnapshotCollectorTelemetryProcessor(next, configuration:
snapshotConfigurationOptions.Value);
}
}
...
Add the SnapshotCollectorConfiguration and SnapshotCollectorTelemetryProcessorFactory

services to the startup pipeline:
// This method gets called by the runtime. Use this method to add services to the
container.
{
// Configure SnapshotCollector from application settings
services.Configure<SnapshotCollectorConfiguration>
(Configuration.GetSection(nameof(SnapshotCollectorConfiguration)));
// Add SnapshotCollector telemetry processor.

services.AddSingleton<ITelemetryProcessorFactory>(sp => new
SnapshotCollectorTelemetryProcessorFactory(sp));
// TODO: Add other services your application needs here.

}
}
4. If needed, customized the Snapshot Debugger configuration by adding a

SnapshotCollectorConfiguration section to appsettings.json. All settings in the Snapshot Debugger
configuration are optional. Here is an example showing a configuration equivalent to the default
configuration:
{
"SnapshotCollectorConfiguration": {
"IsEnabledInDeveloperMode": false,
"ThresholdForSnapshotting": 1,
"MaximumSnapshotsRequired": 3,
"MaximumCollectionPlanSize": 50,
"ReconnectInterval": "00:15:00",
"ProblemCounterResetInterval":"1.00:00:00",
"SnapshotsPerTenMinutesLimit": 1,
"SnapshotsPerDayLimit": 30,
"SnapshotInLowPriorityThread": true,
"ProvideAnonymousTelemetry": true,
"FailedRequestLimit": 3
}
}
Configure snapshot collection for other .NET applications

1. If your application isn't already instrumented with Application Insights, get started by enabling
Application Insights and setting the instrumentation key.
2. Add the Microsoft.ApplicationInsights.SnapshotCollector NuGet package in your app.
3. Snapshots are collected only on exceptions that are reported to Application Insights. You may need to
modify your code to report them. The exception handling code depends on the structure of your
application, but an example is below:
TelemetryClient _telemetryClient = new TelemetryClient();
void ExampleRequest()
{
try
{
// TODO: Handle the request.
}
{
// Report the exception to Application Insights.
_telemetryClient.TrackException(ex);
// TODO: Rethrow the exception if desired.

}
}
Next steps
Generate traffic to your application that can trigger an exception. Then, wait 10 to 15 minutes for snapshots
to be sent to the Application Insights instance.
See snapshots in the Azure portal.
For help with troubleshooting Snapshot Debugger issues, see Snapshot Debugger troubleshooting.
Upgrading the Snapshot Debugger
To provide the best possible security for your data, Microsoft is moving away from TLS 1.0 and TLS 1.1, which
have been shown to be vulnerable to determined attackers. If you are using an older version of the site extension, it
will require an upgrade to continue working. This document outlines the steps needed to upgrade your Snapshot
debugger to the latest version. There are two primary upgrade paths depending on if you enabled the Snapshot
Debugger using a site extension or if you used an SDK/Nuget added to your application. Both upgrade paths are
discussed below.
Upgrading the site extension

If you enabled the Snapshot debugger using the site extension, you can easily upgrade using the following
procedure:
2. Navigate to your resource that has Application Insights and Snapshot debugger enabled. For example, for a
Web App, navigate to the App Service resource:
3. Once you have navigated to your resource, click on Application Insights in the Overview blade:
4. A new blade will open with the current settings. Unless you want to take the opportunity to change your
settings, you can leave them as is. The Apply button on the bottom of the blade is not enabled by default
and you will have to toggle one of the settings to activate the button. You don’t have to change any actual
settings, rather you can change the setting and then immediately change it back. We recommend toggling
the Profiler setting and then selecting Apply.
5. Once you click Apply, you will be asked to confirm the changes.
NOTE
The site will be restarted as part of the upgrade process.
6. Click Yes to apply the changes. During the process a notification will appear showing that changes are being
applied:
Once completed, a "Changes are applied" notification will appear.
The site has now been upgraded and is ready to use.
Upgrading Snapshot Debugger using SDK/Nuget

If the application is using a version of Microsoft.ApplicationInsights.SnapshotCollector below version 1.3.1, it will
need to be upgraded to a newer version to continue working.
Troubleshoot problems enabling Application Insights
Snapshot Debugger or viewing snapshots
If you enabled Application Insights Snapshot Debugger for your application, but are not seeing snapshots for
exceptions, you can use these instructions to troubleshoot. There can be many different reasons why snapshots
are not generated. You can run the snapshot health check to identify some of the possible common causes.
Use the snapshot health check

Several common problems result in the Open Debug Snapshot not showing up. Using an outdated Snapshot
Collector, for example; reaching the daily upload limit; or perhaps the snapshot is just taking a long time to upload.
Use the Snapshot Health Check to troubleshoot common problems.
There's a link in the exception pane of the end-to-end trace view that takes you to the Snapshot Health Check.
The interactive, chat-like interface looks for common problems and guides you to fix them.
If that doesn't solve the problem, then refer to the following manual troubleshooting steps.
Verify the instrumentation key

Make sure you're using the correct instrumentation key in your published application. Usually, the instrumentation
key is read from the ApplicationInsights.config file. Verify the value is the same as the instrumentation key for the
Application Insights resource that you see in the portal.
Preview Versions of .NET Core

If the application uses a preview version of .NET Core, and Snapshot Debugger was enabled through the
Application Insights pane in the portal, then Snapshot Debugger may not start. Follow the instructions at Enable
Snapshot Debugger for other environments first to include the Microsoft.ApplicationInsights.SnapshotCollector
NuGet package with the application in addition to enabling through the Application Insights pane.
Upgrade to the latest version of the NuGet package

If Snapshot Debugger was enabled through the Application Insights pane in the portal, then your application
should already be running the latest NuGet package. If Snapshot Debugger was enabled by including the
Microsoft.ApplicationInsights.SnapshotCollector NuGet package, use Visual Studio's NuGet Package Manager to
make sure you're using the latest version of Microsoft.ApplicationInsights.SnapshotCollector. Release notes can be
found at https://github.com/Microsoft/ApplicationInsights-Home/issues/167
Check the uploader logs

After a snapshot is created, a minidump file (.dmp) is created on disk. A separate uploader process creates that
minidump file and uploads it, along with any associated PDBs, to Application Insights Snapshot Debugger
storage. After the minidump has uploaded successfully, it's deleted from disk. The log files for the uploader
process are kept on disk. In an App Service environment, you can find these logs in D:\Home\LogFiles . Use the
Kudu management site for App Service to find these log files.
1. Open your App Service application in the Azure portal.
2. Click Advanced Tools, or search for Kudu.
3. Click Go.
4. In the Debug console drop-down list box, select CMD.
5. Click LogFiles.
You should see at least one file with a name that begins with Uploader_ or SnapshotUploader_ and a .log
extension. Click the appropriate icon to download any log files or open them in a browser. The file name includes a
unique suffix that identifies the App Service instance. If your App Service instance is hosted on more than one
machine, there are separate log files for each machine. When the uploader detects a new minidump file, it's
recorded in the log file. Here's an example of a successful snapshot and upload:
SnapshotUploader.exe Information: 0 : Received Fork request ID 139e411a23934dc0b9ea08a626db16c5 from process
6368 (Low pri)
DateTime=2018-03-09T01:42:41.8571711Z
SnapshotUploader.exe Information: 0 : Creating minidump from Fork request ID 139e411a23934dc0b9ea08a626db16c5
from process 6368 (Low pri)
DateTime=2018-03-09T01:42:41.8571711Z
SnapshotUploader.exe Information: 0 : Dump placeholder file created: 139e411a23934dc0b9ea08a626db16c5.dm_
DateTime=2018-03-09T01:42:41.8728496Z
SnapshotUploader.exe Information: 0 : Dump available 139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:45.7525022Z
SnapshotUploader.exe Information: 0 : Successfully wrote minidump to
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:45.7681360Z
SnapshotUploader.exe Information: 0 : Uploading
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp, 214.42 MB
(uncompressed)
DateTime=2018-03-09T01:42:45.7681360Z
SnapshotUploader.exe Information: 0 : Upload successful. Compressed size 86.56 MB
DateTime=2018-03-09T01:42:59.6184651Z
SnapshotUploader.exe Information: 0 : Extracting PDB info from
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp.
DateTime=2018-03-09T01:42:59.6184651Z
SnapshotUploader.exe Information: 0 : Matched 2 PDB(s) with local files.
DateTime=2018-03-09T01:42:59.6809606Z
SnapshotUploader.exe Information: 0 : Stamp does not want any of our matched PDBs.
DateTime=2018-03-09T01:42:59.8059929Z
SnapshotUploader.exe Information: 0 : Deleted
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:59.8530649Z
NOTE
The example above is from version 1.2.0 of the Microsoft.ApplicationInsights.SnapshotCollector NuGet package. In earlier
versions, the uploader process is called MinidumpUploader.exe and the log is less detailed.
In the previous example, the instrumentation key is c12a605e73c44346a984e00000000000 . This value should match
the instrumentation key for your application. The minidump is associated with a snapshot with the ID
139e411a23934dc0b9ea08a626db16c5 . You can use this ID later to locate the associated exception telemetry in
Application Insights Analytics.
The uploader scans for new PDBs about once every 15 minutes. Here's an example:
SnapshotUploader.exe Information: 0 : PDB rescan requested.

DateTime=2018-03-09T01:47:19.4457768Z
SnapshotUploader.exe Information: 0 : Scanning D:\home\site\wwwroot for local PDBs.
DateTime=2018-03-09T01:47:19.4457768Z
SnapshotUploader.exe Information: 0 : Local PDB scan complete. Found 2 PDB(s).
DateTime=2018-03-09T01:47:19.4614027Z
SnapshotUploader.exe Information: 0 : Deleted PDB scan marker :
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\6368.pdbscan
DateTime=2018-03-09T01:47:19.4614027Z
For applications that aren't hosted in App Service, the uploader logs are in the same folder as the minidumps:
%TEMP%\Dumps\<ikey> (where <ikey> is your instrumentation key).
Troubleshooting Cloud Services

For roles in Cloud Services, the default temporary folder may be too small to hold the minidump files, leading to
lost snapshots. The space needed depends on the total working set of your application and the number of
concurrent snapshots. The working set of a 32-bit ASP.NET web role is typically between 200 MB and 500 MB.
Allow for at least two concurrent snapshots. For example, if your application uses 1 GB of total working set, you
should make sure that there is at least 2 GB of disk space to store snapshots. Follow these steps to configure your
Cloud Service role with a dedicated local resource for snapshots.
1. Add a new local resource to your Cloud Service by editing the Cloud Service definition (.csdef) file. The
following example defines a resource called SnapshotStore with a size of 5 GB.
<LocalResources>
<LocalStorage name="SnapshotStore" cleanOnRoleRecycle="false" sizeInMB="5120" />
</LocalResources>
2. Modify your role's startup code to add an environment variable that points to the SnapshotStore local
resource. For Worker Roles, the code should be added to your role's OnStart method:
public override bool OnStart()

{
Environment.SetEnvironmentVariable("SNAPSHOTSTORE",
RoleEnvironment.GetLocalResource("SnapshotStore").RootPath);
return base.OnStart();
}
For Web Roles (ASP.NET), the code should be added to your web application's Application_Start method:
using Microsoft.WindowsAzure.ServiceRuntime;
using System;
namespace MyWebRoleApp
{
public class MyMvcApplication : System.Web.HttpApplication
{
{
Environment.SetEnvironmentVariable("SNAPSHOTSTORE",
RoleEnvironment.GetLocalResource("SnapshotStore").RootPath);
// TODO: The rest of your application startup code
}
}
}
3. Update your role's ApplicationInsights.config file to override the temporary folder location used by
SnapshotCollector

<TempFolder>%SNAPSHOTSTORE%</TempFolder>

</Add>
Overriding the Shadow Copy folder

When the Snapshot Collector starts up, it tries to find a folder on disk that is suitable for running the Snapshot
Uploader process. The chosen folder is known as the Shadow Copy folder.
The Snapshot Collector checks a few well-known locations, making sure it has permissions to copy the Snapshot
Uploader binaries. The following environment variables are used:
Fabric_Folder_App_Temp
LOCALAPPDATA
APPDATA
TEMP
If a suitable folder can't be found, Snapshot Collector reports an error saying "Could not find a suitable shadow
copy folder."
If the copy fails, Snapshot Collector reports a ShadowCopyFailed error.
If the uploader can't be launched, Snapshot Collector reports an UploaderCannotStartFromShadowCopy error. The
body of the message often contains System.UnauthorizedAccessException . This error usually occurs because the
application is running under an account with reduced permissions. The account has permission to write to the
shadow copy folder, but it doesn't have permission to execute code.
Since these errors usually happen during startup, they'll usually be followed by an ExceptionDuringConnect error
saying "Uploader failed to start."
To work around these errors, you can specify the shadow copy folder manually via the ShadowCopyFolder
configuration option. For example, using ApplicationInsights.config:

<ShadowCopyFolder>D:\SnapshotUploader</ShadowCopyFolder>

</Add>
Or, if you're using appsettings.json with a .NET Core application:
{
"InstrumentationKey": "<your instrumentation key>"
},
"SnapshotCollectorConfiguration": {
"ShadowCopyFolder": "D:\\SnapshotUploader"
}
}
Use Application Insights search to find exceptions with snapshots

When a snapshot is created, the throwing exception is tagged with a snapshot ID. That snapshot ID is included as
a custom property when the exception telemetry is reported to Application Insights. Using Search in Application
Insights, you can find all telemetry with the ai.snapshot.id custom property.
1. Browse to your Application Insights resource in the Azure portal.
2. Click Search.
3. Type ai.snapshot.id in the Search text box and press Enter.
If this search returns no results, then no snapshots were reported to Application Insights for your application in
the selected time range.
To search for a specific snapshot ID from the Uploader logs, type that ID in the Search box. If you can't find
telemetry for a snapshot that you know was uploaded, follow these steps:
1. Double-check that you're looking at the right Application Insights resource by verifying the instrumentation
key.
2. Using the timestamp from the Uploader log, adjust the Time Range filter of the search to cover that time
range.
If you still don't see an exception with that snapshot ID, then the exception telemetry wasn't reported to
Application Insights. This situation can happen if your application crashed after it took the snapshot but before it
reported the exception telemetry. In this case, check the App Service logs under Diagnose and solve problems to
see if there were unexpected restarts or unhandled exceptions.
Edit network proxy or firewall rules

If your application connects to the Internet via a proxy or a firewall, you may need to edit the rules to allow your
application to communicate with the Snapshot Debugger service. Here is a list of IP addresses and ports used by
the Snapshot Debugger.
Smart Detection in Application Insights
Smart Detection automatically warns you of potential performance problems and failure anomalies in your web
application. It performs proactive analysis of the telemetry that your app sends to Application Insights. If there is a
sudden rise in failure rates, or abnormal patterns in client or server performance, you get an alert. This feature
needs no configuration. It operates if your application sends enough telemetry.
You can access the detections issued by Smart Detection both from the emails you receive, and from the Smart
Detection blade.
Review your Smart Detections

You can discover detections in two ways:
You receive an email from Application Insights. Here's a typical example:
Click the big button to open more detail in the portal.

The Smart Detection blade in Application Insights. Select Smart Detection under the Investigate
menu to see a list of recent detections.
Select a detection to see its details.
What problems are detected?

Smart Detection detects and notifies about a variety of issues, such as:
Smart detection - Failure Anomalies. We use machine learning to set the expected rate of failed requests for
your app, correlating with load and other factors. If the failure rate goes outside the expected envelope, we
send an alert.
Smart detection - Performance Anomalies. You get notifications if response time of an operation or
dependency duration is slowing down compared to historical baseline or if we identify an anomalous pattern
in response time or page load time.
General degradations and issues, like Trace degredation, Memory leak, Abnormal rise in Exception volume and
Security anti-patterns.
(The help links in each notification take you to the relevant articles.)
Smart Detection email notifications

All Smart Detection rules, except for rules marked as preview, are configured by default to send email
notifications when detections are found.
Configuring email notifications for a specific Smart Detection rule can be done by opening the Smart Detection
Settings blade and selecting the rule, which will open the Edit rule blade.
Alternatively, you can change the configuration using Azure Resource Manager templates. See Manage
Application Insights smart detection rules using Azure Resource Manager templates for more details.
Video
Next steps
These diagnostic tools help you inspect the telemetry from your app:
Metric explorer
Search explorer
Analytics - powerful query language
Smart Detection is completely automatic. But maybe you'd like to set up some more alerts?
Manually configured metric alerts
Smart Detection - Failure Anomalies
Application Insights automatically notifies you in near real time if your web app experiences an abnormal rise in
the rate of failed requests. It detects an unusual rise in the rate of HTTP requests or dependency calls that are
reported as failed. For requests, failed requests are usually those with response codes of 400 or higher. To help
you triage and diagnose the problem, an analysis of the characteristics of the failures and related telemetry is
provided in the notification. There are also links to the Application Insights portal for further diagnosis. The
feature needs no set-up nor configuration, as it uses machine learning algorithms to predict the normal failure
rate.
This feature works for any web app, hosted in the cloud or on your own servers, that generates request or
dependency telemetry - for example, if you have a worker role that calls TrackRequest() or TrackDependency().
After setting up Application Insights for your project, and provided your app generates a certain minimum
amount of telemetry, Smart Detection of failure anomalies takes 24 hours to learn the normal behavior of your
app, before it is switched on and can send alerts.
Here's a sample alert.
NOTE
By default, you get a shorter format mail than this example. But you can switch to this detailed format.
Notice that it tells you:

The failure rate compared to normal app behavior.
How many users are affected - so you know how much to worry.
A characteristic pattern associated with the failures. In this example, there's a particular response code, request
name (operation) and app version. That immediately tells you where to start looking in your code. Other
possibilities could be a specific browser or client operating system.
The exception, log traces, and dependency failure (databases or other external components) that appear to be
associated with the characterized failures.
Links directly to relevant searches on the telemetry in Application Insights.
Failure Anomalies v2
A new version of the Failure Anomalies alert rule is now available. This new version is running on the new Azure
alerting platform and introduces a variety of improvements over the existing version.
What's new in this version?
Faster detection of issues
A richer set of actions - The alert rule is created with an associated Action Group named "Application Insights
Smart Detection" that contains email and webhook actions, and can be extended to trigger additional actions
when the alert fires.
More focused notifications - Email notifications sent from this alert rule are now sent by default to users
associated with the subscription's Monitoring Reader and Monitoring Contributor roles. More information on
this is available here.
Easier configuration via ARM templates - See example here.
Common alert schema support - Notifications sent from this alert rule follow the common alert schema.
Unified email template - Email notifications from this alert rule have a consistent look & feel with other alert
types. With this change, the option to get Failure Anomalies alerts with detailed diagnostics information is no
longer available.
How do I get the new version?
Newly created Application Insights resources are now provisioned with the new version of the Failure
Anomalies alert rule.
Existing Application Insights resources with the classic version of the Failure Anomalies alert rule will get the
new version once their hosting subscription is migrated to the new alerting platform as part of the classic
alerts retirement process.
NOTE
The new version of the Failure Anomalies alert rule remains free. In addition, email and webhook actions triggered by the
associated "Application Insights Smart Detection" Action Group are free as well.
Benefits of Smart Detection

Ordinary metric alerts tell you there might be a problem. But Smart Detection starts the diagnostic work for you,
performing a lot of the analysis you would otherwise have to do yourself. You get the results neatly packaged,
helping you to get quickly to the root of the problem.
How it works
Smart Detection monitors the telemetry received from your app, and in particular the failure rates. This rule
counts the number of requests for which the Successful request property is false, and the number of dependency
calls for which the Successful call property is false. For requests, by default,
Successful request == (resultCode < 400) (unless you have written custom code to filter or generate your own
TrackRequest calls).
Your app's performance has a typical pattern of behavior. Some requests or dependency calls will be more prone
to failure than others; and the overall failure rate may go up as load increases. Smart Detection uses machine
learning to find these anomalies.
As telemetry comes into Application Insights from your web app, Smart Detection compares the current behavior
with the patterns seen over the past few days. If an abnormal rise in failure rate is observed by comparison with
previous performance, an analysis is triggered.
When an analysis is triggered, the service performs a cluster analysis on the failed request, to try to identify a
pattern of values that characterize the failures. In the example above, the analysis has discovered that most failures
are about a specific result code, request name, Server URL host, and role instance. By contrast, the analysis has
discovered that the client operating system property is distributed over multiple values, and so it is not listed.
When your service is instrumented with these telemetry calls, the analyzer looks for an exception and a
dependency failure that are associated with requests in the cluster it has identified, together with an example of
any trace logs associated with those requests.
The resulting analysis is sent to you as alert, unless you have configured it not to.
Like the alerts you set manually, you can inspect the state of the alert and configure it in the Alerts blade of your
Application Insights resource. But unlike other alerts, you don't need to set up or configure Smart Detection. If you
want, you can disable it or change its target email addresses.
Alert logic details
The alerts are triggered by our proprietary machine learning algorithm so we can't share the exact
implementation details. With that said, we understand that you sometimes need to know more about how the
underlying logic works. The primary factors that are evaluated to determine if an alert should be triggered are:
Analysis of the failure percentage of requests/dependencies in a rolling time window of 20 minutes.
A comparison of the failure percentage of the last 20 minutes to the rate in the last 40 minutes and the past
seven days, and looking for significant deviations that exceed X-times that standard deviation.
Using an adaptive limit for the minimum failure percentage, which varies based on the app’s volume of
requests/dependencies.
Configure alerts
You can disable Smart Detection, change the email recipients, create a webhook, or opt in to more detailed alert
messages.
Open the Alerts page. Failure Anomalies is included along with any alerts that you have set manually, and you can
see whether it is currently in the alert state.
Click the alert to configure it.
Notice that you can disable Smart Detection, but you can't delete it (or create another one).
Detailed alerts
If you select "Get more detailed diagnostics" then the email will contain more diagnostic information. Sometimes
you'll be able to diagnose the problem just from the data in the email.
There's a slight risk that the more detailed alert could contain sensitive information, because it includes exception
and trace messages. However, this would only happen if your code could allow sensitive information into those
messages.
Triaging and diagnosing an alert

An alert indicates that an abnormal rise in the failed request rate was detected. It's likely that there is some
problem with your app or its environment.
From the percentage of requests and number of users affected, you can decide how urgent the issue is. In the
example above, the failure rate of 22.5% compares with a normal rate of 1%, indicates that something bad is going
on. On the other hand, only 11 users were affected. If it were your app, you'd be able to assess how serious that is.
In many cases, you will be able to diagnose the problem quickly from the request name, exception, dependency
failure and trace data provided.
There are some other clues. For example, the dependency failure rate in this example is the same as the exception
rate (89.3%). This suggests that the exception arises directly from the dependency failure - giving you a clear idea
of where to start looking in your code.
To investigate further, the links in each section will take you straight to a search page filtered to the relevant
requests, exception, dependency or traces. Or you can open the Azure portal, navigate to the Application Insights
resource for your app, and open the Failures blade.
In this example, clicking the 'View dependency failures details' link opens the Application Insights search blade. It
shows the SQL statement that has an example of the root cause: NULLs were provided at mandatory fields and
did not pass validation during the save operation.
Review recent alerts

Click Smart Detection to get to the most recent alert:
What's the difference ...
Smart Detection of failure anomalies complements other similar but distinct features of Application Insights.
Metric Alerts are set by you and can monitor a wide range of metrics such as CPU occupancy, request rates,
page load times, and so on. You can use them to warn you, for example, if you need to add more resources.
By contrast, Smart Detection of failure anomalies covers a small range of critical metrics (currently only
failed request rate), designed to notify you in near real time manner once your web app's failed request rate
increases significantly compared to web app's normal behavior.
Smart Detection automatically adjusts its threshold in response to prevailing conditions.
Smart Detection starts the diagnostic work for you.
Smart Detection of performance anomalies also uses machine intelligence to discover unusual patterns in
your metrics, and no configuration by you is required. But unlike Smart Detection of failure anomalies, the
purpose of Smart Detection of performance anomalies is to find segments of your usage manifold that
might be badly served - for example, by specific pages on a specific type of browser. The analysis is
performed daily, and if any result is found, it's likely to be much less urgent than an alert. By contrast, the
analysis for failure anomalies is performed continuously on incoming telemetry, and you will be notified
within minutes if server failure rates are greater than expected.
If you receive a Smart Detection alert

Why have I received this alert?
We detected an abnormal rise in failed requests rate compared to the normal baseline of the preceding period.
After analysis of the failures and associated telemetry, we think that there is a problem that you should look
into.
Does the notification mean I definitely have a problem?
We try to alert on app disruption or degradation, but only you can fully understand the semantics and the
impact on the app or users.
So, you guys look at my data?
No. The service is entirely automatic. Only you get the notifications. Your data is private.
Do I have to subscribe to this alert?
No. Every application that sends request telemetry has the Smart Detection alert rule.
Can I unsubscribe or get the notifications sent to my colleagues instead?
Yes, In Alert rules, click the Smart Detection rule to configure it. You can disable the alert, or change recipients
for the alert.
I lost the email. Where can I find the notifications in the portal?
In the Activity logs. In Azure, open the Application Insights resource for your app, then select Activity logs.
Some of the alerts are about known issues and I do not want to receive them.
We have alert suppression on our backlog.
Next steps
Metric explorer
Search explorer
Analytics - powerful query language
Smart detections are completely automatic. But maybe you'd like to set up some more alerts?
Smart Detection - Performance Anomalies
Application Insights automatically analyzes the performance of your web application, and can warn you about
potential problems. You might be reading this because you received one of our smart detection notifications.
This feature requires no special setup, other than configuring your app for Application Insights (on ASP.NET, Java,
or Node.js, and in web page code). It is active when your app generates enough telemetry.
When would I get a smart detection notification?

Application Insights has detected that the performance of your application has degraded in one of these ways:
Response time degradation - Your app has started responding to requests more slowly than it used to. The
change might have been rapid, for example because there was a regression in your latest deployment. Or it
might have been gradual, maybe caused by a memory leak.
Dependency duration degradation - Your app makes calls to a REST API, database, or other dependency.
The dependency is responding more slowly than it used to.
Slow performance pattern - Your app appears to have a performance issue that is affecting only some
requests. For example, pages are loading more slowly on one type of browser than others; or requests are
being served more slowly from one particular server. Currently, our algorithms look at page load times,
request response times, and dependency response times.
Smart Detection requires at least 8 days of telemetry at a workable volume in order to establish a baseline of
normal performance. So, after your application has been running for that period, any significant issue will result in
a notification.
Does my app definitely have a problem?

No, a notification doesn't mean that your app definitely has a problem. It's simply a suggestion about something
you might want to look at more closely.
How do I fix it?

The notifications include diagnostic information. Here's an example:
1. Triage. The notification shows you how many users or how many operations are affected. This can help
you assign a priority to the problem.
2. Scope. Is the problem affecting all traffic, or just some pages? Is it restricted to particular browsers or
locations? This information can be obtained from the notification.
3. Diagnose. Often, the diagnostic information in the notification will suggest the nature of the problem. For
example, if response time slows down when request rate is high, that suggests your server or dependencies
are overloaded.
Otherwise, open the Performance blade in Application Insights. There, you will find Profiler data. If
exceptions are thrown, you can also try the snapshot debugger.
Configure Email Notifications

Smart Detection notifications are enabled by default and sent to those who have Monitoring Reader and
Monitoring Contributor access to the subscription in which the Application Insights resource resides. To change
this, either click Configure in the email notification, or open Smart Detection settings in Application Insights.
You can use the unsubscribe link in the Smart Detection email to stop receiving the email notifications.
Emails about Smart Detections performance anomalies are limited to one email per day per Application Insights
resource. The email will be sent only if there is at least one new issue that was detected on that day. You won't get
repeats of any message.
FAQ
So, Microsoft staff look at my data?
No. The service is entirely automatic. Only you get the notifications. Your data is private.
Do you analyze all the data collected by Application Insights?
Not at present. Currently, we analyze request response time, dependency response time and page load
time. Analysis of additional metrics is on our backlog looking forward.
What types of application does this work for?
These degradations are detected in any application that generates the appropriate telemetry. If you
installed Application Insights in your web app, then requests and dependencies are automatically
tracked. But in backend services or other apps, if you inserted calls to TrackRequest() or
TrackDependency, then Smart Detection will work in the same way.
Can I create my own anomaly detection rules or customize existing rules?
Not yet, but you can:
Set up alerts that tell you when a metric crosses a threshold.
Export telemetry to a database or to PowerBI, where you can analyze it yourself.
How often is the analysis performed?
We run the analysis daily on the telemetry from the previous day (full day in UTC timezone).
So does this replace metric alerts?
No. We don't commit to detecting every behavior that you might consider abnormal.
If I don't do anything in response to a notification, will I get a reminder?
No, you get a message about each issue only once. If the issue persists it will be updated in the Smart
Detection feed blade.
I lost the email. Where can I find the notifications in the portal?
In the Application Insights overview of your app, click the Smart Detection tile. There you'll be able to
find all notifications up to 90 days back.
How can I improve performance?
Slow and failed responses are one of the biggest frustrations for web site users, as you know from your own
experience. So, it's important to address the issues.
Triage
First, does it matter? If a page is always slow to load, but only 1% of your site's users ever have to look at it, maybe
you have more important things to think about. On the other hand, if only 1% of users open it, but it throws
exceptions every time, that might be worth investigating.
Use the impact statement (affected users or % of traffic) as a general guide, but be aware that it isn't the whole
story. Gather other evidence to confirm.
Consider the parameters of the issue. If it's geography-dependent, set up availability tests including that region:
there might simply be network issues in that area.
Diagnose slow page loads
Where is the problem? Is the server slow to respond, is the page very long, or does the browser have to do a lot of
work to display it?
Open the Browsers metric blade. The segmented display of browser page load time shows where the time is
going.
If Send Request Time is high, either the server is responding slowly, or the request is a post with a lot of data.
Look at the performance metrics to investigate response times.
Set up dependency tracking to see whether the slowness is due to external services or your database.
If Receiving Response is predominant, your page and its dependent parts - JavaScript, CSS, images and so
on (but not asynchronously loaded data) are long. Set up an availability test, and be sure to set the option to
load dependent parts. When you get some results, open the detail of a result and expand it to see the load
times of different files.
High Client Processing time suggests scripts are running slowly. If the reason isn't obvious, consider adding
some timing code and send the times in trackMetric calls.
Improve slow pages
There's a web full of advice on improving your server responses and page load times, so we won't try to repeat it
all here. Here are a few tips that you probably already know about, just to get you thinking:
Slow loading because of big files: Load the scripts and other parts asynchronously. Use script bundling. Break
the main page into widgets that load their data separately. Don't send plain old HTML for long tables: use a
script to request the data as JSON or other compact format, then fill the table in place. There are great
frameworks to help with all this. (They also entail big scripts, of course.)
Slow server dependencies: Consider the geographical locations of your components. For example, if you're
using Azure, make sure the web server and the database are in the same region. Do queries retrieve more
information than they need? Would caching or batching help?
Capacity issues: Look at the server metrics of response times and request counts. If response times peak
disproportionately with peaks in request counts, it's likely that your servers are stretched.
Server Response Time Degradation

The response time degradation notification tells you:
The response time compared to normal response time for this operation.
How many users are affected.
Average response time and 90th percentile response time for this operation on the day of the detection and 7
days before.
Count of this operation requests on the day of the detection and 7 days before.
Correlation between degradation in this operation and degradations in related dependencies.
Links to help you diagnose the problem.
Profiler traces to help you view where operation time is spent (the link is available if Profiler trace
examples were collected for this operation during the detection period).
Performance reports in Metric Explorer, where you can slice and dice time range/filters for this
operation.
Search for this call to view specific call properties.
Failure reports - If count > 1 this mean that there were failures in this operation that might have
contributed to performance degradation.
Dependency Duration Degradation

Modern application more and more adopt micro services design approach, which in many cases leads to heavy
reliability on external services. For example, if your application relies on some data platform or even if you build
your own bot service you will probably relay on some cognitive services provider to enable your bots to interact in
more human ways and some data store service for bot to pull the answers from.
Example dependency degradation notification:
Notice that it tells you:
The duration compared to normal response time for this operation
How many users are affected
Average duration and 90th percentile duration for this dependency on the day of the detection and 7 days
before
Number of dependency calls on the day of the detection and 7 days before
Links to help you diagnose the problem
Performance reports in Metric Explorer for this dependency
Search for this dependency calls to view calls properties
Failure reports - If count > 1 this means that there were failed dependency calls during the detection
period that might have contributed to duration degradation.
Open Analytics with queries that calculate this dependency duration and count
Smart Detection of slow performing patterns

Application Insights finds performance issues that might only affect some portion of your users, or only affect
users in some cases. For example, notification about pages load is slower on one type of browser than on other
types of browsers, or if requests are served more slowly from a particular server. It can also discover problems
associated with combinations of properties, such as slow page loads in one geographical area for clients using
particular operating system.
Anomalies like these are very hard to detect just by inspecting the data, but are more common than you might
think. Often they only surface when your customers complain. By that time, it's too late: the affected users are
already switching to your competitors!
Currently, our algorithms look at page load times, request response times at the server, and dependency response
times.
You don't have to set any thresholds or configure rules. Machine learning and data mining algorithms are used to
detect abnormal patterns.
When shows the time the issue was detected.

What describes:
The problem that was detected;
The characteristics of the set of events that we found displayed the problem behavior.
The table compares the poorly-performing set with the average behavior of all other events.
Click the links to open Metric Explorer and Search on relevant reports, filtered on the time and properties of the
slow performing set.
Modify the time range and filters to explore the telemetry.
Next steps
Profiler
Snapshot debugger
Analytics
Analytics smart diagnostics
Smart detections are completely automatic. But maybe you'd like to set up some more alerts?
Degradation in trace severity ratio (preview)
Traces are widely used in applications, as they help tell the story of what happens behind the scenes. When things
go wrong, traces provide crucial visibility into the sequence of events leading to the undesired state. While traces
are generally unstructured, there is one thing that can concretely be learned from them – their severity level. In an
application’s steady state, we would expect the ratio between “good” traces (Info and Verbose) and “bad” traces
(Warning, Error, and Critical) to remain stable. The assumption is that “bad” traces may happen on a regular basis
to a certain extent due to any number of reasons (transient network issues for instance). But when a real problem
begins growing, it usually manifests as an increase in the relative proportion of “bad” traces vs “good” traces.
Application Insights Smart Detection automatically analyzes the traces logged by your application, and can warn
you about unusual patterns in the severity of your trace telemetry.
This feature requires no special setup, other than configuring trace logging for your app (see how to configure a
trace log listener for .NET or Java). It is active when your app generates enough exception telemetry.
When would I get this type of smart detection notification?

You might get this type of notification if the ratio between “good” traces (traces logged with a level of Info or
Verbose) and “bad” traces (traces logged with a level of Warning, Error, or Fatal) is degrading in a specific day,
compared to a baseline calculated over the previous seven days.

No, a notification doesn't mean that your app definitely has a problem. Although a degradation in the ratio
between “good” and “bad” traces might indicate an application issue, this change in ratio might be benign. For
example, the increase might be due to a new flow in the application emitting more “bad” traces than existing flows).
How do I fix it?

The notifications include diagnostic information to support in the diagnostics process:
1. Triage. The notification shows you how many operations are affected. This can help you assign a priority to the
problem.
2. Scope. Is the problem affecting all traffic, or just some operation? This information can be obtained from the
notification.
3. Diagnose. You can use the related items and reports linking to supporting information, to help you further
diagnose the issue.
Abnormal rise in exception volume (preview)
Application Insights automatically analyzes the exceptions thrown in your application, and can warn you about
unusual patterns in your exception telemetry.
This feature requires no special setup, other than configuring exception reporting for your app. It is active when
your app generates enough exception telemetry.

You might get this type of notification if your app is exhibiting an abnormal rise in the number of exceptions of a
specific type during a day, compared to a baseline calculated over the previous seven days. Machine learning
algorithms are being used for detecting the rise in exception count, while taking into account a natural growth in
your application usage.

No, a notification doesn't mean that your app definitely has a problem. Although an excessive number of
exceptions usually indicates an application issue, these exceptions might be benign and handled correctly by your
application.
How do I fix it?

The notifications include diagnostic information to support in the diagnostics process:
1. Triage. The notification shows you how many users or how many requests are affected. This can help you
assign a priority to the problem.
2. Scope. Is the problem affecting all traffic, or just some operation? This information can be obtained from the
notification.
3. Diagnose. The detection contains information about the method from which the exception was thrown, as well
as the exception type. You can also use the related items and reports linking to supporting information, to help
you further diagnose the issue.
Memory leak detection (preview)
Application Insights automatically analyzes the memory consumption of each process in your application, and can
warn you about potential memory leaks or increased memory consumption.
This feature requires no special setup, other than configuring performance counters for your app. It's active when
your app generates enough memory performance counters telemetry (for example, Private Bytes).

A typical notification will follow a consistent increase in memory consumption over a long period of time, in one or
more processes and/or one or more machines, which are part of your application. Machine learning algorithms are
used for detecting increased memory consumption that matches the pattern of a memory leak.
Does my app really have a problem?

No, a notification doesn't mean that your app definitely has a problem. Although memory leak patterns usually
indicate an application issue, these patterns could be typical to your specific process, or could have a natural
business justification, and can be ignored.
How do I fix it?

The notifications include diagnostic information to support in the diagnostic analysis process:
1. Triage. The notification shows you the amount of memory increase (in GB ), and the time range in which the
memory has increased. This can help you assign a priority to the problem.
2. Scope. How many machines exhibited the memory leak pattern? How many exceptions were triggered during
the potential memory leak? This information can be obtained from the notification.
3. Diagnose. The detection contains the memory leak pattern, showing memory consumption of the process
over time. You can also use the related items and reports linking to supporting information, to help you further
diagnose the issue.
Application security detection pack (preview)
Application Insights automatically analyzes the telemetry generated by your application and detects potential
security issues. This capability enables you to identify potential security problems, and handle them by fixing the
application or by taking the necessary security measures.
This feature requires no special setup, other than configuring your app to send telemetry.

There are three types of security issues that are detected:
1. Insecure URL access: a URL in the application is being accessed via both HTTP and HTTPS. Typically, a URL
that accepts HTTPS requests should not accept HTTP requests. This may indicate a bug or security issue in your
application.
2. Insecure form: a form (or other "POST" request) in the application uses HTTP instead of HTTPS. Using HTTP
can compromise the user data that is sent by the form.
3. Suspicious user activity: the application is being accessed from multiple countries/regions by the same user at
approximately the same time. For example, the same user accessed the application from Spain and the United
States within the same hour. This detection indicates a potentially malicious access attempt to your application.
Does my app definitely have a security issue?

No, a notification doesn't mean that your app definitely has a security issue. A detection of any of the scenarios
above can, in many cases, indicate a security issue. However, the detection may have a natural business
justification, and can be ignored.
How do I fix the "Insecure URL access" detection?

1. Triage. The notification provides the number of users who accessed insecure URLs, and the URL that was most
affected by insecure access. This can help you assign a priority to the problem.
2. Scope. What percentage of the users accessed insecure URLs? How many URLs were affected? This
information can be obtained from the notification.
3. Diagnose. The detection provides the list of insecure requests, and the lists of URLs and users that were
affected, to help you further diagnose the issue.
How do I fix the "Insecure form" detection?

1. Triage. The notification provides the number of insecure forms and number of users whose data was
potentially compromised. This can help you assign a priority to the problem.
2. Scope. Which form was involved in the largest number of insecure transmissions, and what is the distribution
of insecure transmissions over time? This information can be obtained from the notification.
3. Diagnose. The detection provides the list of insecure forms and a breakdown of the number of insecure
transmissions for each form, to help you further diagnose the issue.
How do I fix the "Suspicious user activity" detection?

1. Triage. The notification provides the number of different users that exhibited the suspicious behavior. This can
help you assign a priority to the problem.
2. Scope. From which countries/regions did the suspicious requests originate? Which user was the most
suspicious? This information can be obtained from the notification.
3. Diagnose. The detection provides the list of suspicious users and the list of countries/regions for each user, to
help you further diagnose the issue.
Alert on issues in Azure Cloud Services using the
Azure diagnostics integration with Azure Application
Insights
In this article, we will describe how to set up alert rules that monitor for issues like startup failures, crashes, and
role recycle loops in Azure Cloud Services (web and worker roles).
The method described in this article is based on the Azure Diagnostics integration with Application Insights, and
the recently released Log Alerts for Application Insights capability.
Define a base query

To get started, we will define a base query that retrieves the Windows Event Log events from the Windows Azure
channel, which are captured into Application Insights as trace records. These records can be used for detecting a
variety of issues in Azure Cloud Services, like startup failures, runtime failures and recycle loops.
NOTE
The base query below checks for issues in a time window of 30 minutes, and assumes a 10 minutes latency in ingesting the
telemetry records. These defaults can be configured as you see fit.
let window = 30m;

let endTime = ago(10m);
let EventLogs = traces
| where timestamp > endTime - window and timestamp < endTime
| extend channel = tostring(customDimensions.Channel), eventId = tostring(customDimensions.EventId)
| where channel == 'Windows Azure' and isnotempty(eventId)
| where tostring(customDimensions.DeploymentName) !contains 'deployment' // discard records captured from local
machines
| project timestamp, channel, eventId, message, cloud_RoleInstance, cloud_RoleName, itemCount;
Check for specific event IDs

After retrieving the Windows Event Log events, specific issues can be detected by checking for their respective
event ID and message properties (see examples below ). Simply combine the base query above with one of the
queries below, and used that combined query when defining the log alert rule.
NOTE
In the examples below, an issue will be detected if more than three events are found during the analyzed time window. This
default can be configured to change the sensitivity of the alert rule.
// Detect failures in the OnStart method
EventLogs
| where eventId == '2001'
| where message contains '.OnStart()'
| summarize Failures = sum(itemCount) by cloud_RoleInstance, cloud_RoleName
| where Failures > 3
// Detect failures during runtime

EventLogs
| where message contains '.Run()'
// Detect failures when running a startup task

EventLogs
// Detect recycle loops

EventLogs
Create an alert
In the navigation menu within your Application Insights resource, go to Alerts, and then select New Alert Rule.
In the Create rule window, under the Define alert condition section, click on Add criteria, and then select
Custom log search.
In the Search query box, paste the combined query you prepared in the previous step.
Then, continue to the Threshold box, and set its value to 0. You may optionally tweak the Period and Frequency
fields. Click Done.
Under the Define alert details section, provide a Name and Description to the alert rule, and set its Severity.
Also, make sure that the Enable rule upon creation button is set to Yes.
Under the Define action group section, you can select an existing Action group or create a new one. You may
choose to have the action group contain multiple actions of various types.
Once you've defined the Action group, confirm your changes and click Create alert rule.
Next Steps
Learn more about automatically detecting:
Failure anomalies Memory Leaks Performance anomalies
Manage Application Insights smart detection rules
using Azure Resource Manager templates
Smart detection rules in Application Insights can be managed and configured using Azure Resource Manager
templates. This method can be used when deploying new Application Insights resources with Azure Resource
Manager automation, or for modifying the settings of existing resources.
Smart detection rule configuration

You can configure the following settings for a smart detection rule:
If the rule is enabled (the default is true.)
If emails should be sent to users associated to the subscription’s Monitoring Reader and Monitoring
Contributor roles when a detection is found (the default is true.)
Any additional email recipients who should get a notification when a detection is found.
Email configuration is not available for Smart Detection rules marked as preview.
To allow configuring the rule settings via Azure Resource Manager, the smart detection rule configuration is now
available as an inner resource within the Application Insights resource, named ProactiveDetectionConfigs. For
maximal flexibility, each smart detection rule can be configured with unique notification settings.
Examples
Below are a few examples showing how to configure the settings of smart detection rules using Azure Resource
Manager templates. All samples refer to an Application Insights resource named “myApplication”, and to the "long
dependency duration smart detection rule", which is internally named “longdependencyduration”. Make sure to
replace the Application Insights resource name, and to specify the relevant smart detection rule internal name.
Check the table below for a list of the corresponding internal Azure Resource Manager names for each smart
detection rule.
Disable a smart detection rule
{
"name": "myApplication",
"type": "Microsoft.Insights/components",
"location": "[resourceGroup().location]",
"properties": {
"ApplicationId": "myApplication"
},
"resources": [
{
"name": "longdependencyduration",
"type": "ProactiveDetectionConfigs",
"dependsOn": [
"[resourceId('Microsoft.Insights/components', 'myApplication')]"
],
"properties": {
"sendEmailsToSubscriptionOwners": true,
"customEmails": [],
"enabled": false
}
}
]
}
Disable sending email notifications for a smart detection rule
{
"properties": {
},
"resources": [
{
"dependsOn": [
],
"properties": {
"sendEmailsToSubscriptionOwners": false,
"customEmails": [],
"enabled": true
}
}
]
}
Add additional email recipients for a smart detection rule

{
"properties": {
},
"resources": [
{
"dependsOn": [
],
"properties": {
"sendEmailsToSubscriptionOwners": true,
"customEmails": ['alice@contoso.com', 'bob@contoso.com'],
"enabled": true
}
}
]
}
Failure Anomalies v2 (non-classic) alert rule

This Azure Resource Manager template demonstrates configuring a Failure Anomalies v2 alert rule with a severity
of 2. This new version of the Failure Anomalies alert rule is part of the new Azure alerting platform, and replaces
the classic version that is being retired as part of the classic alerts retirement process.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"resources": [
{
"type": "microsoft.alertsmanagement/smartdetectoralertrules",
"apiVersion": "2019-03-01",
"name": "Failure Anomalies - my-app",
"location": "global",
"properties": {
"description": "Detects a spike in the failure rate of requests or dependencies",
"state": "Enabled",
"severity": "2",
"frequency": "PT1M",
"detector": {
"id": "FailureAnomaliesDetector"
},
"scope": ["/subscriptions/00000000-1111-2222-3333-
444444444444/resourceGroups/MyResourceGroup/providers/microsoft.insights/components/my-app"],
"actionGroups": {
"groupIds": ["/subscriptions/00000000-1111-2222-3333-
444444444444/resourcegroups/MyResourceGroup/providers/microsoft.insights/actiongroups/MyActionGroup"]
}
}
}
]
}
NOTE
This Azure Resource Manager template is unique to the Failure Anomalies v2 alert rule and is different from the other classic
Smart Detection rules described in this article.
Smart detection rule names

Below is a table of smart detection rule names as they appear in the portal, along with their internal names, that
should be used in the Azure Resource Manager template.
NOTE
Smart detection rules marked as preview don’t support email notifications. Therefore, you can only set the enabled property
for these rules.
AZURE PORTAL RULE NAME INTERNAL NAME
Slow page load time slowpageloadtime
Slow server response time slowserverresponsetime
Long dependency duration longdependencyduration
Degradation in server response time degradationinserverresponsetime
Degradation in dependency duration degradationindependencyduration
Degradation in trace severity ratio (preview) extension_traceseveritydetector
Abnormal rise in exception volume (preview) extension_exceptionchangeextension
Potential memory leak detected (preview) extension_memoryleakextension
Potential security issue detected (preview) extension_securityextensionspackage
Abnormal rise in daily data volume (preview) extension_billingdatavolumedailyspikeextension
Next Steps
Learn more about automatically detecting:
Failure anomalies
Memory Leaks
Smart Detection e-mail notification change
Based on customer feedback, on April 1, 2019, we’re changing the default roles who receive email notifications
from Smart Detection.
What is changing?
Currently, Smart Detection email notifications are sent by default to the Subscription Owner, Subscription
Contributor, and Subscription Reader roles. These roles often include users who are not actively involved in
monitoring, which causes many of these users to receive notifications unnecessarily. To improve this experience, we
are making a change so that email notifications only go to the Monitoring Reader and Monitoring Contributor
roles by default.
Scope of this change

This change will affect all Smart Detection rules, excluding the following ones:
Smart Detection rules marked as preview. These Smart Detection rules don’t support email notifications
today.
Failure Anomalies rule. This rule will start targeting the new default roles once it’s migrated from a classic
alert to the unified alerts platform (more information is available here.)
How to prepare for this change?

To ensure that email notifications from Smart Detection are sent to relevant users, those users must be assigned to
the Monitoring Reader or Monitoring Contributor roles of the subscription.
To assign users to the Monitoring Reader or Monitoring Contributor roles via the Azure portal, follow the steps
described in the Add a role assignment article. Make sure to select the Monitoring Reader or Monitoring
Contributor as the role to which users are assigned.
NOTE
Specific recipients of Smart Detection notifications, configured using the Additional email recipients option in the rule
settings, will not be affected by this change. These recipients will continue receiving the email notifications.
If you have any questions or concerns about this change, don’t hesitate to contact us.
Next steps
Learn more about Smart Detection:
Failure anomalies
Memory Leaks
Usage analysis with Application Insights
Which features of your web or mobile app are most popular? Do your users achieve their goals with your app?
Do they drop out at particular points, and do they return later? Azure Application Insights helps you gain
powerful insights into how people use your app. Every time you update your app, you can assess how well it
works for users. With this knowledge, you can make data driven decisions about your next development cycles.
Send telemetry from your app

The best experience is obtained by installing Application Insights both in your app server code, and in your web
pages. The client and server components of your app send telemetry back to the Azure portal for analysis.
1. Server code: Install the appropriate module for your ASP.NET, Azure, Java, Node.js, or other app.
Don't want to install server code? Just create an Azure Application Insights resource.
2. Web page code: Add the following script to your web page before the closing </head> . Replace
instrumentation key with the appropriate value for your Application Insights resource:
n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.ge
tElementsByTagName("script")[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e){}t.queue=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n
("track"+r.pop());n("startTrackPage"),n("stopTrackPage");var
s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedUse
rContext"),n("flush"),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&
&!0===e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+
(r="onerror"));var o=a[r];a[r]=function(e,n,i,a,s){var c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]
{
}
</script>
To learn more advanced configurations for monitoring websites, check out the JavaScript SDK reference
article.
3. Mobile app code: Use the App Center SDK to collect events from your app, then send copies of these
events to Application Insights for analysis by following this guide.
4. Get telemetry: Run your project in debug mode for a few minutes, and then look for results in the
Overview blade in Application Insights.
Publish your app to monitor your app's performance and find out what your users are doing with your
app.
Include user and session ID in your telemetry

To track users over time, Application Insights requires a way to identify them. The Events tool is the only Usage
tool that does not require a user ID or a session ID.
Start sending user and session IDs using this process.
Explore usage demographics and statistics

Find out when people use your app, what pages they're most interested in, where your users are located, what
browsers and operating systems they use.
The Users and Sessions reports filter your data by pages or custom events, and segment them by properties
such as location, environment, and page. You can also add your own filters.
Insights on the right point out interesting patterns in the set of data.
The Users report counts the numbers of unique users that access your pages within your chosen time
periods. For web apps, users are counted by using cookies. If someone accesses your site with different
browsers or client machines, or clears their cookies, then they will be counted more than once.
The Sessions report counts the number of user sessions that access your site. A session is a period of
activity by a user, terminated by a period of inactivity of more than half an hour.
More about the Users, Sessions, and Events tools
Retention - how many users come back?

Retention helps you understand how often your users return to use their app, based on cohorts of users that
performed some business action during a certain time bucket.
Understand what specific features cause users to come back more than others
Form hypotheses based on real user data
Determine whether retention is a problem in your product
The retention controls on top allow you to define specific events and time range to calculate retention. The
graph in the middle gives a visual representation of the overall retention percentage by the time range
specified. The graph on the bottom represents individual retention in a given time period. This level of detail
allows you to understand what your users are doing and what might affect returning users on a more detailed
granularity.
More about the Retention tool
Custom business events

To get a clear understanding of what users do with your app, it's useful to insert lines of code to log custom
events. These events can track anything from detailed user actions such as clicking specific buttons, to more
significant business events such as making a purchase or winning a game.
Although in some cases, page views can represent useful events, it isn't true in general. A user can open a
product page without buying the product.
With specific business events, you can chart your users' progress through your site. You can find out their
preferences for different options, and where they drop out or have difficulties. With this knowledge, you can
make informed decisions about the priorities in your development backlog.
Events can be logged from the client side of the app:
appInsights.trackEvent("ExpandDetailTab", {DetailTab: tabName});
Or from the server side:
var tc = new Microsoft.ApplicationInsights.TelemetryClient();

tc.TrackEvent("CreatedAccount", new Dictionary<string,string> {"AccountType":account.Type}, null);
...
tc.TrackEvent("AddedItemToCart", new Dictionary<string,string> {"Item":item.Name}, null);
...
tc.TrackEvent("CompletedPurchase");
You can attach property values to these events, so that you can filter or split the events when you inspect them
in the portal. In addition, a standard set of properties is attached to each event, such as anonymous user ID,
which allows you to trace the sequence of activities of an individual user.
Learn more about custom events and properties.
Slice and dice events
In the Users, Sessions, and Events tools, you can slice and dice custom events by user, event name, and
properties.
Design the telemetry with the app

When you are designing each feature of your app, consider how you are going to measure its success with your
users. Decide what business events you need to record, and code the tracking calls for those events into your
app from the start.
A | B Testing
If you don't know which variant of a feature will be more successful, release both of them, making each
accessible to different users. Measure the success of each, and then move to a unified version.
For this technique, you attach distinct property values to all the telemetry that is sent by each version of your
app. You can do that by defining properties in the active TelemetryContext. These default properties are added
to every telemetry message that the application sends - not just your custom messages, but the standard
telemetry as well.
In the Application Insights portal, filter and split your data on the property values, so as to compare the
different versions.
To do this, set up a telemetry initializer:
ASP.NET apps
// Telemetry initializer class

{
public void Initialize (ITelemetry telemetry)
{
telemetry.Properties["AppVersion"] = "v2.1";
}
}
In the web app initializer such as Global.asax.cs:

{
// ...
TelemetryConfiguration.Active.TelemetryInitializers
.Add(new MyTelemetryInitializer());
}
ASP.NET Core apps
NOTE
ASP.NET Core applications.
For ASP.NET Core applications, adding a new TelemetryInitializer is done by adding it to the Dependency
Injection container, as shown below. This is done in ConfigureServices method of your Startup.cs class.
{
}
All new TelemetryClients automatically add the property value you specify. Individual telemetry events can
override the default values.
Next steps
Funnels
Retention
User Flows
Workbooks
Add user context
Send user context IDs to enable usage experiences in
Azure Application Insights
Tracking users
Application Insights enables you to monitor and track your users through a set of product usage tools:
Funnels
Retention Cohorts
Workbooks
In order to track what a user does over time, Application Insights needs an ID for each user or session. Include the
following IDs in every custom event or page view.
Users, Funnels, Retention, and Cohorts: Include user ID.
Sessions: Include session ID.
NOTE
This is an advanced article outlining the manual steps for tracking user activity with Application Insights. With many web
applications these steps may not be required, as the default server-side SDKs in conjunction with the Client/Browser-side
JavaScript SDK, are often sufficient to automatically track user activity. If you haven't configured client-side monitoring in
addition to the server-side SDK, do that first and test to see if the user behavior analytics tools are performing as expected.
Choosing user IDs

User IDs should persist across user sessions to track how users behave over time. There are various approaches
for persisting the ID.
A definition of a user that you already have in your service.
If the service has access to a browser, it can pass the browser a cookie with an ID in it. The ID will persist for as
long as the cookie remains in the user's browser.
If necessary, you can use a new ID each session, but the results about users will be limited. For example, you
won't be able to see how a user's behavior changes over time.
The ID should be a Guid or another string complex enough to identify each user uniquely. For example, it could be
a long random number.
If the ID contains personally identifying information about the user, it is not an appropriate value to send to
Application Insights as a user ID. You can send such an ID as an authenticated user ID, but it does not fulfill the
user ID requirement for usage scenarios.
ASP.NET apps: Setting the user context in an ITelemetryInitializer

Create a telemetry initializer, as described in detail here. Pass the session ID through the request telemetry, and set
the Context.User.Id and the Context.Session.Id.
This example sets the user ID to an identifier that expires after the session. If possible, use a user ID that persists
across sessions.
Telemetry initializer
using System;
using System.Web;
namespace MvcWebRole.Telemetry
{
/*
* Custom TelemetryInitializer that sets the user ID.
*
*/
{
{
var ctx = HttpContext.Current;
// If telemetry initializer is called as part of request execution and not from some async thread
if (ctx != null)
{
var requestTelemetry = ctx.GetRequestTelemetry();
// Set the user and session ids from requestTelemetry.Context.User.Id, which is populated in
Application_PostAcquireRequestState in Global.asax.cs.
if (requestTelemetry != null && !string.IsNullOrEmpty(requestTelemetry.Context.User.Id) &&
(string.IsNullOrEmpty(telemetry.Context.User.Id) ||
string.IsNullOrEmpty(telemetry.Context.Session.Id)))
{
// Set the user id on the Application Insights telemetry item.
telemetry.Context.User.Id = requestTelemetry.Context.User.Id;
// Set the session id on the Application Insights telemetry item.

telemetry.Context.Session.Id = requestTelemetry.Context.User.Id;
}
}
}
}
}
Global.asax.cs
using System.Web;
using System.Web.Http;
using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
{
public class MvcApplication : HttpApplication
{
{
AreaRegistration.RegisterAllAreas();
GlobalConfiguration.Configure(WebApiConfig.Register);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
}
protected void Application_PostAcquireRequestState()

{
var requestTelemetry = Context.GetRequestTelemetry();
if (HttpContext.Current.Session != null && requestTelemetry != null &&

string.IsNullOrEmpty(requestTelemetry.Context.User.Id))
{
requestTelemetry.Context.User.Id = Session.SessionID;
}
}
}
}
Next steps
To enable usage experiences, start sending custom events or page views.
If you already send custom events or page views, explore the Usage tools to learn how users use your service.
Usage overview
Users, Sessions, and Events
Funnels
Retention
Workbooks
Users, sessions, and events analysis in Application
Insights
Find out when people use your web app, what pages they're most interested in, where your users are located, and
what browsers and operating systems they use. Analyze business and usage telemetry by using Azure
Get started
If you don't yet see data in the users, sessions, or events blades in the Application Insights portal, learn how to
get started with the usage tools.
The Users, Sessions, and Events segmentation tool

Three of the usage blades use the same tool to slice and dice telemetry from your web app from three
perspectives. By filtering and splitting the data, you can uncover insights about the relative usage of different
pages and features.
Users tool: How many people used your app and its features. Users are counted by using anonymous IDs
stored in browser cookies. A single person using different browsers or machines will be counted as more
than one user.
Sessions tool: How many sessions of user activity have included certain pages and features of your app.
A session is counted after half an hour of user inactivity, or after 24 hours of continuous use.
Events tool: How often certain pages and features of your app are used. A page view is counted when a
browser loads a page from your app, provided you have instrumented it.
A custom event represents one occurrence of something happening in your app, often a user interaction
like a button click or the completion of some task. You insert code in your app to generate custom events.
Querying for certain users
Explore different groups of users by adjusting the query options at the top of the Users tool:
Show: Choose a cohort of users to analyze.
Who used: Choose custom events and page views.
During: Choose a time range.
By: Choose how to bucket the data, either by a period of time or by another property such as browser or city.
Split By: Choose a property by which to split or segment the data.
Add Filters: Limit the query to certain users, sessions, or events based on their properties, such as browser or
city.
Saving and sharing reports

You can save Users reports, either private just to you in the My Reports section, or shared with everyone else
with access to this Application Insights resource in the Shared Reports section.
To share a link to a Users, Sessions, or Events report; click Share in the toolbar, then copy the link.
To share a copy of the data in a Users, Sessions, or Events report; click Share in the toolbar, then click the Word
icon to create a Word document with the data. Or, click the Word icon above the main chart.
Meet your users

The Meet your users section shows information about five sample users matched by the current query.
Considering and exploring the behaviors of individuals, in addition to aggregates, can provide insights about how
people actually use your app.
Next steps
Funnels
Retention
User Flows
Workbooks
Add user context
Discover how customers are using your application
with Application Insights Funnels
Understanding the customer experience is of the utmost importance to your business. If your application involves
multiple stages, you need to know if most customers are progressing through the entire process, or if they are
ending the process at some point. The progression through a series of steps in a web application is known as a
funnel. You can use Azure Application Insights Funnels to gain insights into your users, and monitor step-by-step
conversion rates.
Create your funnel

Before you create your funnel, decide on the question you want to answer. For example, you might want to know
how many users are viewing the home page, viewing a customer profile, and creating a ticket. In this example, the
owners of the Fabrikam Fiber company want to know the percentage of customers who successfully create a
customer ticket.
Here are the steps they take to create their funnel.
1. In the Application Insights Funnels tool, select New.
2. From the Time Range drop-down menu, select Last 90 days. Select either My funnels or Shared funnels.
3. From the Step 1 drop-down list, select Index.
4. From the Step 2 list, select Customer.
5. From the Step 3 list, select Create.
6. Add a name to the funnel, and select Save.
The following screenshot shows an example of the kind of data the Funnels tool generates. The Fabrikam owners
can see that during the last 90 days, 54.3 percent of their customers who visited the home page created a
customer ticket. They can also see that 2,700 of their customers came to the index from the home page. This
might indicate a refresh issue.
Funnels features
The preceding screenshot includes five highlighted areas. These are features of Funnels. The following list
explains more about each corresponding area in the screenshot:
1. If your app is sampled, you will see a sampling banner. Selecting the banner opens a context pane, explaining
how to turn sampling off.
2. You can export your funnel to Power BI.
3. Select a step to see more details on the right.
4. The historical conversion graph shows the conversion rates over the last 90 days.
5. Understand your users better by accessing the users tool. You can use filters in each step.
Next steps
Usage overview
Retention
Workbooks
Add user context
Export to Power BI
Application Insights cohorts
A cohort is a set of users, sessions, events, or operations that have something in common. In Azure Application
Insights, cohorts are defined by an analytics query. In cases where you have to analyze a specific set of users or
events repeatedly, cohorts can give you more flexibility to express exactly the set you’re interested in.
Cohorts versus basic filters

Cohorts are used in ways similar to filters. But cohorts' definitions are built from custom analytics queries, so
they're much more adaptable and complex. Unlike filters, you can save cohorts so other members of your team can
reuse them.
You might define a cohort of users who have all tried a new feature in your app. You can save this cohort in your
Application Insights resource. It's easy to analyze this saved group of specific users in the future.
NOTE
After they're created, cohorts are available from the Users, Sessions, Events, and User Flows tools.
Example: Engaged users

Your team defines an engaged user as anyone who uses your app five or more times in a given month. In this
section, you define a cohort of these engaged users.
1. Open the Cohorts tool.
2. Select the Template Gallery tab. You see a collection of templates for various cohorts.
3. Select Engaged Users -- by Days Used.
There are three parameters for this cohort:
Activities, where you choose which events and page views count as “usage.”
Period, the definition of a month.
UsedAtLeastCustom, the number of times users need to use something within a period to count as
engaged.
4. Change UsedAtLeastCustom to 5+ days, and leave Period on the default of 28 days.
Now this cohort represents all user IDs sent with any custom event or page view on 5 separate days in the
past 28.
5. Select Save.
TIP
Give your cohort a name, like “Engaged Users (5+ Days).” Save it to “My reports” or “Shared reports,” depending on
whether you want other people who have access to this Application Insights resource to see this cohort.
6. Select Back to Gallery.

What can you do by using this cohort?
Open the Users tool. In the Show drop-down box, choose the cohort you created under Users who belong to.
Now the Users tool is filtered to this cohort of users:
A few important things to notice:
You can't create this set through normal filters. The date logic is more advanced.
You can further filter this cohort by using the normal filters in the Users tool. So although the cohort is defined
on 28-day windows, you can still adjust the time range in the Users tool to be 30, 60, or 90 days.
These filters support more sophisticated questions that are impossible to express through the query builder. An
example is people who were engaged in the past 28 days. How did those same people behave over the past 60
days?
Example: Events cohort

You can also make cohorts of events. In this section, you define a cohort of the events and page views. Then you
see how to use them from the other tools. This cohort might define a set of events that your team considers active
usage or a set related to a certain new feature.
1. Open the Cohorts tool.
2. Select the Template Gallery tab. You’ll see a collection of templates for various cohorts.
3. Select Events Picker.
4. In the Activities drop-down box, select the events you want to be in the cohort.
5. Save the cohort and give it a name.
Example: Active users where you modify a query

The previous two cohorts were defined by using drop-down boxes. But you can also define cohorts by using
analytics queries for total flexibility. To see how, create a cohort of users from the United Kingdom.
1. Open the Cohorts tool, select the Template Gallery tab, and select Blank Users cohort.
There are three sections:
A Markdown text section, where you describe the cohort in more detail for others on your team.
A parameters section, where you make your own parameters, like Activities and other drop-down
boxes from the previous two examples.
A query section, where you define the cohort by using an analytics query.
In the query section, you write an analytics query. The query selects the certain set of rows that
describe the cohort you want to define. The Cohorts tool then implicitly adds a “| summarize by
user_Id” clause to the query. This data is previewed below the query in a table, so you can make sure
your query is returning results.
NOTE
If you don’t see the query, try resizing the section to make it taller and reveal the query. The animated .gif at
the beginning of this section illustrates the resizing behavior.
2. Copy and paste the following text into the query editor:
union customEvents, pageViews

| where client_CountryOrRegion == "United Kingdom"
3. Select Run Query. If you don't see user IDs appear in the table, change to a country/region where your
application has users.
4. Save and name the cohort.

I’ve defined a cohort of users from a certain country/region. When I compare this cohort in the Users tool to just
setting a filter on that country/region, I see different results. Why?
Cohorts and filters are different. Suppose you have a cohort of users from the United Kingdom (defined like the
previous example), and you compare its results to setting the filter “Country or region = United Kingdom.”
The cohort version shows all events from users who sent one or more events from the United Kingdom in the
current time range. If you split by country or region, you likely see many countries and regions.
The filters version only shows events from the United Kingdom. But if you split by country or region, you see
only the United Kingdom.
Learn more
Analytics query language
Users, sessions, events
User flows
Usage overview
Impact analysis with Application Insights
Impact analyzes how load times and other properties influence conversion rates for various parts of your app. To
put it more precisely, it discovers how any dimension of a page view, custom event, or request affects the
usage of a different page view or custom event.
Still not sure what Impact does?

One way to think of Impact is as the ultimate tool for settling arguments with someone on your team about how
slowness in some aspect of your site is affecting whether users stick around. While users may tolerate a certain
amount of slowness, Impact gives you insight into how best to balance optimization and performance to maximize
user conversion.
But analyzing performance is just a subset of Impact's capabilities. Since Impact supports custom events and
dimensions, answering questions like how does user browser choice correlate with different rates of conversion
are just a few clicks away.
NOTE
Your Application Insights resource must contain page views or custom events to use the Impact tool. Learn how to set up
your app to collect page views automatically with the Application Insights JavaScript SDK. Also keep in mind that since you
are analyzing correlation, sample size matters.
Is page load time impacting how many people convert on my page?

To begin answering questions with the Impact tool, choose an initial page view, custom event, or request.
1. Select a page view from the For the page view dropdown.
2. Leave the analyze how its dropdown on the default selection of Duration (In this context Duration is an alias
for Page Load Time.)
3. For the impacts the usage of dropdown, select a custom event. This event should correspond to a UI element
on the page view you selected in step 1.
In this instance as Product Page load time increases the conversion rate to Purchase Product clicked goes
down. Based on the distribution above, an optimal page load duration of 3.5 seconds could be targeted to achieve
a potential 55% conversion rate. Further performance improvements to reduce load time below 3.5 seconds do not
currently correlate with additional conversion benefits.
What if I’m tracking page views or load times in custom ways?

Impact supports both standard and custom properties and measurements. Use whatever you want. Instead of
duration, use filters on the primary and secondary events to get more specific.
Do users from different countries or regions convert at different rates?
1. Select a page view from the For the page view dropdown.
2. Choose “Country or region” in analyze how its dropdown
3. For the impacts the usage of dropdown, select a custom event that corresponds to a UI element on the page
view you chose in step 1.
In this case, the results no longer fit into a continuous x-axis model as they did in the first example. Instead, a
visualization similar to a segmented funnel is presented. Sort by Usage to view the variation of conversion to your
custom event based on country/region.
How does the Impact tool calculate these conversion rates?

Under the hood, the Impact tool relies on the Pearson correlation coefficient. Results are computed between -1 and
1 with -1 representing a negative linear correlation and 1 representing a positive linear correlation.
The basic breakdown of how Impact Analysis works is as follows:
Let A = the main page view/custom event/request you select in the first dropdown. (For the page view).
Let B = the secondary page view/custom event you select ( impacts the usage of).
Impact looks at a sample of all the sessions from users in the selected time range. For each session, it looks for
each occurrence of A.
Sessions are then broken into two different kinds of subsessions based on one of two conditions:
A converted subsession consists of a session ending with a B event and encompasses all A events that occur
prior to B.
An unconverted subsession occurs when all A's occur without a terminal B.
How Impact is ultimately calculated varies based on whether we are analyzing by metric or by dimension. For
metrics all A's in a subsession are averaged. Whereas for dimensions the value of each A contributes 1/N to the
value assigned to B where N is the number of A's in the subsession.
Next steps
Funnels
Retention
User Flows
Workbooks
Add user context
User retention analysis for web applications with
The retention feature in Azure Application Insights helps you analyze how many users return to your app, and
how often they perform particular tasks or achieve goals. For example, if you run a game site, you could compare
the numbers of users who return to the site after losing a game with the number who return after winning. This
knowledge can help you improve both your user experience and your business strategy.
Get started
If you don't yet see data in the retention tool in the Application Insights portal, learn how to get started with the
usage tools.
The Retention tool
1. The toolbar allows users to create new retention reports, open existing retention reports, save current
retention report or save as, revert changes made to saved reports, refresh data on the report, share report via
email or direct link, and access the documentation page.
2. By default, retention shows all users who did anything then came back and did anything else over a period.
You can select different combination of events to narrow the focus on specific user activities.
3. Add one or more filters on properties. For example, you can focus on users in a particular country or region.
Click Update after setting the filters.
4. The overall retention chart shows a summary of user retention across the selected time period.
5. The grid shows the number of users retained according to the query builder in #2. Each row represents a
cohort of users who performed any event in the time period shown. Each cell in the row shows how many of
that cohort returned at least once in a later period. Some users may return in more than one period.
6. The insights cards show top five initiating events, and top five returned events to give users a better
understanding of their retention report.
Users can hover over cells on the retention tool to access the analytics button and tool tips explaining what the
cell means. The Analytics button takes users to the Analytics tool with a pre-populated query to generate users
from the cell.
Use business events to track retention

To get the most useful retention analysis, measure events that represent significant business activities.
For example, many users might open a page in your app without playing the game that it displays. Tracking just
the page views would therefore provide an inaccurate estimate of how many people return to play the game
after enjoying it previously. To get a clear picture of returning players, your app should send a custom event
when a user actually plays.
It's good practice to code custom events that represent key business actions, and use these for your retention
analysis. To capture the game outcome, you need to write a line of code to send a custom event to Application
Insights. If you write it in the web page code or in Node.JS, it looks like this:
appinsights.trackEvent("won game");
Or in ASP.NET server code:
telemetry.TrackEvent("won game");
Learn more about writing custom events.
Next steps
Funnels
User Flows
Workbooks
Add user context
Analyze user navigation patterns with User Flows in
The User Flows tool visualizes how users navigate between the pages and features of your site. It's great for
answering questions like:
How do users navigate away from a page on your site?
What do users click on a page on your site?
Where are the places that users churn most from your site?
Are there places where users repeat the same action over and over?
The User Flows tool starts from an initial page view, custom event, or exception that you specify. Given this initial
event, User Flows shows the events that happened before and afterwards during user sessions. Lines of varying
thickness show how many times each path was followed by users. Special Session Started nodes show where
the subsequent nodes began a session. Session Ended nodes show how many users sent no page views or
custom events after the preceding node, highlighting where users probably left your site.
NOTE
Your Application Insights resource must contain page views or custom events to use the User Flows tool. Learn how to set
up your app to collect page views automatically with the Application Insights JavaScript SDK.
Start by choosing an initial event

To begin answering questions with the User Flows tool, choose an initial page view, custom event, or exception
to serve as the starting point for the visualization:
1. Click the link in the What do users do after...? title, or click the Edit button.
2. Select a page view, custom event, or exception from the Initial event dropdown.
3. Click Create graph.
The "Step 1" column of the visualization shows what users did most frequently just after the initial event, ordered
top to bottom from most to least frequent. The "Step 2" and subsequent columns show what users did thereafter,
creating a picture of all the ways users have navigated through your site.
By default, the User Flows tool randomly samples only the last 24 hours of page views and custom event from
your site. You can increase the time range and change the balance of performance and accuracy for random
sampling in the Edit menu.
If some of the page views, custom events, and exceptions aren’t relevant to you, click the X on the nodes you
want to hide. Once you've selected the nodes you want to hide, click the Create graph button below the
visualization. To see all of the nodes you've hidden, click the Edit button, then look at the Excluded events
section.
If page views or custom events are missing that you expect to see on the visualization:
Check the Excluded events section in the Edit menu.
Use the plus buttons on Others nodes to include less-frequent events in the visualization.
If the page view or custom event you expect is sent infrequently by users, try increasing the time range of the
visualization in the Edit menu.
Make sure the page view, custom event, or exception you expect is set up to be collected by the Application
Insights SDK in the source code of your site. Learn more about collecting custom events.
If you want to see more steps in the visualization, use the Previous steps and Next steps dropdowns above the
visualization.
After visiting a page or feature, where do users go and what do they

click?
If your initial event is a page view, the first column ("Step 1") of the visualization is a quick way to understand
what users did immediately after visiting the page. Try opening your site in a window next to the User Flows
visualization. Compare your expectations of how users interact with the page to the list of events in the "Step 1"
column. Often, a UI element on the page that seems insignificant to your team can be among the most-used on
the page. It can be a great starting point for design improvements to your site.
If your initial event is a custom event, the first column shows what users did just after performing that action. As
with page views, consider if the observed behavior of your users matches your team's goals and expectations. If
your selected initial event is "Added Item to Shopping Cart", for example, look to see if "Go to Checkout" and
"Completed Purchase" appear in the visualization shortly thereafter. If user behavior is different from your
expectations, use the visualization to understand how users are getting "trapped" by your site's current design.
Where are the places that users churn most from your site?
Watch for Session Ended nodes that appear high-up in a column in the visualization, especially early in a flow.
This means many users probably churned from your site after following the preceding path of pages and UI
interactions. Sometimes churn is expected - after completing a purchase on an eCommerce site, for example -
but usually churn is a sign of design problems, poor performance, or other issues with your site that can be
improved.
Keep in mind, that Session Ended nodes are based only on telemetry collected by this Application Insights
resource. If Application Insights doesn't receive telemetry for certain user interactions, users could still have
interacted with your site in those ways after the User Flows tool says the session ended.
Are there places where users repeat the same action over and over?
Look for a page view or custom event that is repeated by many users across subsequent steps in the
visualization. This usually means that users are performing repetitive actions on your site. If you find repetition,
think about changing the design of your site or adding new functionality to reduce repetition. For example,
adding bulk edit functionality if you find users performing repetitive actions on each row of a table element.
Common questions
Does the initial event represent the first time the event appears in a session, or any time it appears in a
session?
The initial event on the visualization only represents the first time a user sent that page view or custom event
during a session. If users can send the initial event multiple times in a session, then the "Step 1" column only
shows how users behave after the first instance of initial event, not all instances.
Some of the nodes in my visualization are too high-level. For example, a node that just says “Button Clicked.”
How can I break it down into more detailed nodes?
Use the Split by options in the Edit menu:
1. Choose the event you want to break down in the Event menu.
2. Choose a dimension in the Dimension menu. For example, if you have an event called “Button Clicked,” try a
custom property called “Button Name.”
Next steps
Usage overview
Retention
Adding custom events to your app
Troubleshoot user behavior analytics tools in
Have questions about the user behavior analytics tools in Application Insights: Users, Sessions, Events, Funnels,
User Flows, Retention, or Cohorts? Here are some answers.
Counting Users
The user behavior analytics tools show that my app has one user/session, but I know my app has many
users/sessions. How can I fix these incorrect counts?
All telemetry events in Application Insights have an anonymous user ID and a session ID as two of their standard
properties. By default, all of the usage analytics tools count users and sessions based on these IDs. If these
standard properties aren't being populated with unique IDs for each user and session of your app, you'll see an
incorrect count of users and sessions in the usage analytics tools.
If you're monitoring a web app, the easiest solution is to add the Application Insights JavaScript SDK to your app,
and make sure the script snippet is loaded on each page you want to monitor. The JavaScript SDK automatically
generates anonymous user and session IDs, then populates telemetry events with these IDs as they're sent from
your app.
If you're monitoring a web service (no user interface), create a telemetry initializer that populates the anonymous
user ID and session ID properties according to your service's notions of unique users and sessions.
If your app is sending authenticated user IDs, you can count based on authenticated user IDs in the Users tool. In
the "Show" dropdown, choose "Authenticated users."
The user behavior analytics tools don't currently support counting users or sessions based on properties other than
anonymous user ID, authenticated user ID, or session ID.
Naming Events
My app has thousands of different page view and custom event names. It's hard to distinguish between
them, and the user behavior analytics tools often become unresponsive. How can I fix these naming
issues?
Page view and custom event names are used throughout the user behavior analytics tools. Naming events well is
critical to getting value from these tools. The goal is a balance between having too few, overly generic names
("Button clicked") and having too many, overly specific names ("Edit button clicked on
http://www.contoso.com/index").
To make any changes to the page view and custom event names your app is sending, you need to change your
app's source code and redeploy. All telemetry data in Application Insights is stored for 90 days and cannot
be deleted, so changes you make to event names will take 90 days to fully manifest. For the 90 days after making
name changes, both the old and new event names will show up in your telemetry, so adjust queries and
communicate within your teams, accordingly.
If your app is sending too many page view names, check whether these page view names are specified manually in
code or if they're being sent automatically by the Application Insights JavaScript SDK:
If the page view names are manually specified in code using the trackPageView API, change the name to be
less specific. Avoid common mistakes like putting the URL in the name of the page view. Instead, use the
URL parameter of the trackPageView API. Move other details from the page view name into custom
properties.
If the Application Insights JavaScript SDK is automatically sending page view names, you can either change
your pages' titles or switch to manually sending page view names. The SDK sends the title of each page as
the page view name, by default. You could change your titles to be more general, but be mindful of SEO and
other impacts this change could have. Manually specifying page view names with the trackPageView API
overrides the automatically collected names, so you could send more general names in telemetry without
changing page titles.
If your app is sending too many custom event names, change the name in the code to be less specific. Again, avoid
putting URLs and other per-page or dynamic information in the custom event names directly. Instead, move these
details into custom properties of the custom event with the trackEvent API. For example, instead of
appInsights.trackEvent("Edit button clicked on http://www.contoso.com/index") , we suggest something like
appInsights.trackEvent("Edit button clicked", { "Source URL": "http://www.contoso.com/index" }) .
Next steps
User behavior analytics tools overview
Get help
Stack Overflow
Annotations on metric charts in Application Insights
Annotations on Metrics Explorer charts show where you deployed a new build, or other significant events.
Annotations make it easy to see whether your changes had any effect on your application's performance. They can
be automatically created by the Azure Pipelines build system. You can also create annotations to flag any event you
like by creating them from PowerShell.
NOTE
This article reflects the deprecated classic metrics experience. Annotations are only currently available in the classic
experience and in workbooks. To learn more about the current metrics experience, see Advanced features of Azure Metrics
Explorer.
Release annotations with Azure Pipelines build

Release annotations are a feature of the cloud-based Azure Pipelines service of Azure DevOps.
Install the Annotations extension (one time )
To be able to create release annotations, you'll need to install one of the many Azure DevOps extensions available
in the Visual Studio Marketplace.
1. Sign in to your Azure DevOps project.
2. On the Visual Studio Marketplace Release Annotations extension page, select your Azure DevOps
organization, and then select Install to add the extension to your Azure DevOps organization.
You only need to install the extension once for your Azure DevOps organization. You can now configure release
annotations for any project in your organization.
Configure release annotations
Create a separate API key for each of your Azure Pipelines release templates.
1. Sign in to the Azure portal and open the Application Insights resource that monitors your application. Or if
you don't have one, create a new Application Insights resource.
2. Open the API Access tab and copy the Application Insights ID.
3. In a separate browser window, open or create the release template that manages your Azure Pipelines
deployments.
4. Select Add task, and then select the Application Insights Release Annotation task from the menu.
5. Under Application ID, paste the Application Insights ID you copied from the API Access tab.
6. Back in the Application Insights API Access window, select Create API Key.
7. In the Create API key window, type a description, select Write annotations, and then select Generate
key. Copy the new key.
8. In the release template window, on the Variables tab, select Add to create a variable definition for the new
API key.
9. Under Name, enter ApiKey , and under Value, paste the API key you copied from the API Access tab.
10. Select Save in the main release template window to save the template.
View annotations
Now, whenever you use the release template to deploy a new release, an annotation is sent to Application Insights.
The annotations appear on charts in Metrics Explorer.
Select any annotation marker (light gray arrow ) to open details about the release, including requestor, source
control branch, release pipeline, and environment.
Create custom annotations from PowerShell

You can use the CreateReleaseAnnotation PowerShell script from GitHub to create annotations from any process
you like, without using Azure DevOps.
1. Make a local copy of CreateReleaseAnnotation.ps1.
2. Use the steps in the preceding procedure to get your Application Insights ID and create an API key from
your Application Insights API Access tab.
3. Call the PowerShell script with the following code, replacing the angle-bracketed placeholders with your
values. The -releaseProperties are optional.
.\CreateReleaseAnnotation.ps1 `
-applicationId "<applicationId>" `
-apiKey "<apiKey>" `
-releaseName "<releaseName>" `
-releaseProperties @{
"ReleaseDescription"="<a description>";
"TriggerBy"="<Your name>" }
You can modify the script, for example to create annotations for the past.
Next steps
Create work items
Automation with PowerShell
Add continuous monitoring to your release pipeline
Azure Pipelines integrates with Azure Application Insights to allow continuous monitoring of your DevOps release
pipeline throughout the software development lifecycle.
With continuous monitoring, release pipelines can incorporate monitoring data from Application Insights and
other Azure resources. When the release pipeline detects an Application Insights alert, the pipeline can gate or roll
back the deployment until the alert is resolved. If all checks pass, deployments can proceed automatically from test
all the way to production, without the need for manual intervention.
Configure continuous monitoring

1. In Azure DevOps, select an organization and project.
2. On the left menu of the project page, select Pipelines > Releases.
3. Drop down the arrow next to New and select New release pipeline. Or, if you don't have a pipeline yet,
select New pipeline on the page that appears.
4. On the Select a template pane, search for and select Azure App Service deployment with continuous
monitoring, and then select Apply.
5. In the Stage 1 box, select the hyperlink to View stage tasks.
6. In the Stage 1 configuration pane, complete the following fields:

PARAMETER VALUE
Stage name Provide a stage name, or leave it at Stage 1.
Azure subscription Drop down and select the linked Azure subscription you
want to use.
App type Drop down and select your app type.
App Service name Enter the name of your Azure App Service.
Resource Group name for Application Insights Drop down and select the resource group you want to
use.
Application Insights resource name Drop down and select the Application Insights resource
for the resource group you selected.
7. To save the pipeline with default alert rule settings, select Save at upper right in the Azure DevOps window.
Enter a descriptive comment, and then select OK.
Modify alert rules

Out of box, the Azure App Service deployment with continuous monitoring template has four alert rules:
Availability, Failed requests, Server response time, and Server exceptions. You can add more rules, or
change the rule settings to meet your service level needs.
To modify alert rule settings:
1. In the left pane of the release pipeline page, select Configure Application Insights Alerts.
2. In the Azure Monitor Alerts pane, select the ellipsis ... next to Alert rules.
3. In the Alert rules dialog, select the drop-down symbol next to an alert rule, such as Availability.
4. Modify the Threshold and other settings to meet your requirements.
5. Select OK, and then select Save at upper right in the Azure DevOps window. Enter a descriptive comment,
and then select OK.
Add deployment conditions
When you add deployment gates to your release pipeline, an alert that exceeds the thresholds you set prevents
unwanted release promotion. Once you resolve the alert, the deployment can proceed automatically.
To add deployment gates:
1. On the main pipeline page, under Stages, select the Pre-deployment conditions or Post-deployment
conditions symbol, depending on which stage needs a continuous monitoring gate.
2. In the Pre-deployment conditions configuration pane, set Gates to Enabled.

3. Next to Deployment gates, select Add.
4. Select Query Azure Monitor alerts from the dropdown menu. This option lets you access both Azure
Monitor and Application Insights alerts.
5. Under Evaluation options, enter the values you want for settings like The time between re-evaluation
of gates and The timeout after which gates fail.
View release logs

You can see deployment gate behavior and other release steps in the release logs. To open the logs:
1. Select Releases from the left menu of the pipeline page.
2. Select any release.
3. Under Stages, select any stage to view a release summary.
4. To view logs, select View logs in the release summary, select the Succeeded or Failed hyperlink in any
stage, or hover over any stage and select Logs.
Next steps
For more information about Azure Pipelines, see the Azure Pipelines documentation.
Resources, roles, and access control in Application
Insights
You can control who has read and update access to your data in Azure Application Insights, by using Role-based
access control in Microsoft Azure.
IMPORTANT
Assign access to users in the resource group or subscription to which your application resource belongs - not in the
resource itself. Assign the Application Insights component contributor role. This ensures uniform control of access to
web tests and alerts along with your application resource. Learn more.
NOTE
PowerShell.
Resources, groups and subscriptions

First, some definitions:
Resource - An instance of a Microsoft Azure service. Your Application Insights resource collects, analyzes
and displays the telemetry data sent from your application. Other types of Azure resources include web
apps, databases, and VMs.
To see your resources, open the Azure portal, sign in, and click All Resources. To find a resource, type part
of its name in the filter field.
Resource group - Every resource belongs to one group. A group is a convenient way to manage related
resources, particularly for access control. For example, into one resource group you could put a Web App,
an Application Insights resource to monitor the app, and a Storage resource to keep exported data.
Subscription - To use Application Insights or other Azure resources, you sign in to an Azure subscription.
Every resource group belongs to one Azure subscription, where you choose your price package and, if it's
an organization subscription, choose the members and their access permissions.
Microsoft account - The username and password that you use to sign in to Microsoft Azure subscriptions,
XBox Live, Outlook.com, and other Microsoft services.
Control access in the resource group

It's important to understand that in addition to the resource you created for your application, there are also
separate hidden resources for alerts and web tests. They are attached to the same resource group as your
Application Insights resource. You might also have put other Azure services in there, such as websites or storage.
To control access to these resources it's therefore recommended to:
Control access at the resource group or subscription level.
Assign the Application Insights Component contributor role to users. This allows them to edit web tests,
alerts, and Application Insights resources, without providing access to any other services in the group.
To provide access to another user

You must have Owner rights to the subscription or the resource group.
The user must have a Microsoft Account, or access to their organizational Microsoft Account. You can provide
access to individuals, and also to user groups defined in Azure Active Directory.
Navigate to resource group or directly to the resource itself
Choose Access control (IAM ) from the left-hand menu.
Select Add role assignment
The Add permissions view below is primarily specific to Application Insights resources, if you were viewing the
access control permissions from a higher level like resource groups, you would see additional non-Application
Insights-centric roles.
To view information on all Azure role-based access control built-in roles use the official reference content.
Select a role
Where applicable we link to the associated official reference documentation.
ROLE IN THE RESOURCE GROUP
Owner Can change anything, including user access.
Contributor Can edit anything, including all resources.
Application Insights Component contributor Can edit Application Insights resources, web tests and alerts.
ROLE IN THE RESOURCE GROUP
Reader Can view but not change anything.
Application Insights Snapshot Debugger Gives the user permission to use Application Insights
Snapshot Debugger features. Note that this role is included in
neither the Owner nor Contributor roles.
Azure Service Deploy Release Management Contributor Contributor role for services deploying through Azure Service
Deploy.
Data Purger Special role for purging personal data. See our guidance for
personal data for more information.
ExpressRoute Administrator Can create delete and manage express routes.
Log Analytics Contributor Log Analytics Contributor can read all monitoring data and
edit monitoring settings. Editing monitoring settings includes
adding the VM extension to VMs; reading storage account
keys to be able to configure collection of logs from Azure
Storage; creating and configuring Automation accounts;
adding solutions; and configuring Azure diagnostics on all
Azure resources.
Log Analytics Reader Log Analytics Reader can view and search all monitoring data
as well as and view monitoring settings, including viewing the
configuration of Azure diagnostics on all Azure resources.
masterreader Allows a user to view everything but not make changes.
Monitoring Contributor Can read all monitoring data and update monitoring settings.
Monitoring Metrics Publisher Enables publishing metrics against Azure resources.
Monitoring Reader Can read all monitoring data.
Resource Policy Contributor (Preview) Backfilled users from EA, with rights to create/modify resource
policy, create support ticket and read resource/hierarchy.
User Access Administrator Allows a user to manage access for other users to Azure
resources.
Website Contributor Lets you manage websites (not web plans), but not access to
them..
'Editing' includes creating, deleting and updating:

Resources
Web tests
Alerts
Continuous export
Select the user
If the user you want isn't in the directory, you can invite anyone with a Microsoft account. (If they use services like
Outlook.com, OneDrive, Windows Phone, or XBox Live, they have a Microsoft account.)
Related content
Role based access control in Azure
PowerShell query to determine role membership

Since certain roles can be linked to notifications and e-mail alerts it can be helpful to be able to generate a list of
users who belong to a given role. To help with generating these types of lists we offer the following sample
queries that can be adjusted to fit your specific needs:
Query entire subscription for Admin roles + Contributor roles
(Get-AzRoleAssignment -IncludeClassicAdministrators | Where-Object {$_.RoleDefinitionName -in

@('ServiceAdministrator', 'CoAdministrator', 'Owner', 'Contributor') } | Select -ExpandProperty SignInName |
Sort-Object -Unique) -Join ", "
Query within the context of a specific Application Insights resource for owners and contributors
$resourceGroup = “RGNAME”
$resourceName = “AppInsightsName”
$resourceType = “microsoft.insights/components”
(Get-AzRoleAssignment -ResourceGroup $resourceGroup -ResourceType $resourceType -ResourceName $resourceName |
Where-Object {$_.RoleDefinitionName -in @('Owner', 'Contributor') } | Select -ExpandProperty SignInName |
Sort-Object -Unique) -Join ", "
Query within the context of a specific resource group for owners and contributors
$resourceGroup = “RGNAME”
(Get-AzRoleAssignment -ResourceGroup $resourceGroup | Where-Object {$_.RoleDefinitionName -in @('Owner',
'Contributor') } | Select -ExpandProperty SignInName | Sort-Object -Unique) -Join ", "
Geolocation and IP address handling
This article explains how geolocation lookup and IP address handling occur in Application Insights along with how
to modify the default behavior.
Default behavior
By default IP addresses are temporarily collected, but not stored in Application Insights. The basic process is as
follows:
IP addresses are sent to Application Insights as part of telemetry data. Upon reaching the ingestion endpoint in
Azure, the IP address is used to perform a geolocation lookup using GeoLite2 from MaxMind. The results of this
lookup are used to populate the following fields client_City , client_StateOrProvince , client_CountryOrRegion . At
this point, the IP address is discarded and 0.0.0.0 is written to the client_IP field.
Browser telemetry: We temporarily collect the sender's IP address. IP address is calculated by the ingestion
endpoint.
Server telemetry: The Application Insights module temporarily collects the client IP address. It is not collected if
X-Forwarded-For is set.
This behavior is by design to help avoid unnecessary collection of personal data. Whenever possible, we
recommend avoiding the collection of personal data.
Overriding default behavior

While the default behavior is to minimize the collection of personal data, we still offer the flexibility to collect and
store IP address data. Before choosing to store any personal data like IP addresses, we strongly recommend
verifying that this does not break any compliance requirements or local regulations that you may be subject to. To
learn more about personal data handling in Application Insights, consult the guidance for personal data.
Storing IP address data

In order to enable IP collection and storage, the DisableIpMasking property of the Application Insights component
must be set to true . This property can be set either through Azure Resource Manager templates or by calling the
REST API.
Azure Resource Manager Template
{
"id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/microsoft.insights/components/<resource-name>",
"name": "<resource-name>",
"location": "westcentralus",
"tags": {
},
"kind": "web",
"properties": {
"Application_Type": "web",
"Flow_Type": "Redfield",
"Request_Source": "IbizaAIExtension",
// ...
"DisableIpMasking": true
}
}
Portal
If you only need to modify the behavior for a single Application Insights resource the easiest way to accomplish
this is via the Azure portal.
1. Go your Application Insights resource > Settings > Export Template
2. Select Deploy
3. Select Edit Template. (If your template has additional properties or resources that do not appear in this
example template, proceed with caution to ensure that all resources will accept the template deployment as
an incremental change/update.)
4. Make the following changes to the json for your resource and then click Save:
WARNING
If you experience an error that says: The resource group is in a location that is not supported by one or more
resources in the template. Please choose a different resource group. Temporarily select a different resource group
from the dropdown and then re-select your original resource group to resolve the error.
5. Select I agree > Purchase.
In this case nothing new is being purchased, we are just updating the config of the existing Application
Insights resource.
6. Once the deployment is complete new telemetry data will be recorded.
If you were to select and edit template again you would only see the default template and would not see
your newly added property and its associated value. If you aren't seeing IP address data and want to confirm
that "DisableIpMasking": true is set. Run the following PowerShell: (Replace Fabrikam-dev with the
appropriate resource and resource group name.)
# If you aren't using the cloud shell you will need to connect to your Azure account
# Connect-AzAccount
$AppInsights = Get-AzResource -Name 'Fabrikam-dev' -ResourceType 'microsoft.insights/components' -
ResourceGroupName 'Fabrikam-dev'
$AppInsights.Properties
A list of properties will be returned as a result. One of the properties should read DisableIpMasking: true . If
you run the PowerShell prior to deploying the new property with Azure Resource Manager, the property
will not exist.
Rest API
The Rest API payload to make the same modifications is as follows:
PATCH https://management.azure.com/subscriptions/<sub-id>/resourceGroups/<rg-
name>/providers/microsoft.insights/components/<resource-name>?api-version=2018-05-01-preview HTTP/1.1
Host: management.azure.com
Authorization: AUTH_TOKEN
Content-Type: application/json
Content-Length: 54
{
"location": "<resource location>",
"kind": "web",
"properties": {
"Application_Type": "web",
"DisableIpMasking": true
}
}
Telemetry initializer
If you need a more flexible alternative than DisableIpMasking to record all or part of IP addresses, you can use a
telemetry initializer to copy all or part the IP to a custom field.
ASP.NET / ASP.NET Core
namespace MyWebApp
{
public class CloneIPAddress : ITelemetryInitializer
{
{
ISupportProperties propTelemetry = telemetry as ISupportProperties;
if (propTelemetry !=null && !propTelemetry.Properties.ContainsKey("client-ip"))

{
string clientIPValue = telemetry.Context.Location.Ip;
propTelemetry.Properties.Add("client-ip", clientIPValue);
}
}
}
}
NOTE
If you are unable to access ISupportProperties , check and make sure you are running the latest stable release of the
Application Insights SDK. ISupportProperties are intended for high cardinality values, whereas GlobalProperties are
more appropriate for low cardinality values like region name, environment name, etc.
Enable telemetry initializer for .ASP.NET

namespace MyWebApp
{
public class MvcApplication : System.Web.HttpApplication
{
{
//Enable your telemetry initializer:
TelemetryConfiguration.Active.TelemetryInitializers.Add(new CloneIPAddress());
}
}
}
Enable telemetry initializer for ASP.NET Core

You can create your telemetry initializer the same way for ASP.NET Core as ASP.NET but to enable the initializer,
use the following example for reference:
{
services.AddSingleton<ITelemetryInitializer, CloneIPAddress>();
}
Node.js
appInsights.defaultClient.addTelemetryProcessor((envelope) => {
const baseData = envelope.data.baseData;
if (appInsights.Contracts.domainSupportsProperties(baseData)) {
const ipAddress = envelope.tags[appInsights.defaultClient.context.keys.locationIp];
if (ipAddress) {
baseData.properties["client-ip"] = ipAddress;
}
}
});
Client-side JavaScript
Unlike the server-side SDKs, the client-side Javascript SDK does not calculate IP address. By default IP address
calculation for client-side telemetry is performed at the ingestion endpoint in Azure upon telemetry arrival. This
means that if you were sending client-side data to a proxy and then forwarding to the ingestion endpoint, IP
address calculation may show the IP address of the proxy and not the client. If no proxy is used this should not be
an issue.
If you wish to calculate IP address directly on the client-side you would need to add your own custom logic to
perform this calculation and use the result to set the ai.location.ip tag. When ai.location.ip is set, IP address
calculation is not performed by the ingestion endpoint and the provided IP address is honored and used for
performing the geo lookup. In this scenario, IP address will still be zeroed out by default.
To retain the entire IP address calculated from your custom logic, you could use a telemetry initializer that would
copy the IP address data you provided in ai.location.ip to a separate custom field. But again unlike the server-
side SDKs, without relying on 3rd party libraries or your own custom client-side IP collection logic the client-side
SDK will not calculate the IP for you.
appInsights.addTelemetryInitializer((item) => {
const ipAddress = item.tags && item.tags["ai.location.ip"];
if (ipAddress) {
item.baseData.properties = {
...item.baseData.properties,
"client-ip": ipAddress
};
}
});
View the results of your telemetry initializer

If you then trigger new traffic against your site and wait approximately 2-5 minutes to ensure it had time to be
ingested, you can run a Kusto query to see if IP address collection is working:
requests
| where timestamp > ago(1h)
| project appName, operation_Name, url, resultCode, client_IP, customDimensions.["client-ip"]
Newly collected IP addresses should appear in the customDimensions_client-ip column. The default client-ip
column will still have all 4 octets either zeroed out or only displaying the first three octets depending on how you
have configured IP address collection at the component level. If you are testing locally after implementing the
telemetry initializer and the value you see for customDimensions_client-ip is ::1 this is expected behavior. ::1
represents the loopback address in IPv6. It is equivalent to 127.0.01 in IPv4 and is the result you will see when
testing from localhost.
Next Steps
Learn more about personal data collection in Application Insights.
Learn more about how IP address collection in Application Insights works. (This is an older external blog
post written by one of our engineers. It predates the current default behavior where IP address is recorded
as 0.0.0.0 , but it goes into greater depth on the mechanics of the built-in
ClientIpHeaderTelemetryInitializer .)
Sampling in Application Insights
Sampling is a feature in Azure Application Insights. It is the recommended way to reduce telemetry traffic
and storage, while preserving a statistically correct analysis of application data. The filter selects items that
are related, so that you can navigate between items when you are doing diagnostic investigations. When
metric counts are presented in the portal, they are renormalized to take into account sampling. Doing so
minimizes any effect on the statistics.
Sampling reduces traffic and data costs, and helps you avoid throttling.
In brief:
Sampling retains 1 in n records and discards the rest. For example, it might retain one in five events, a
sampling rate of 20%.
Adaptive Sampling is enabled by default in all the latest version of ASP.NET and ASP.NET Core
Software Development Kits (SDKs).
You can also set sampling manually. This can be configured in the portal on the Usage and estimated
costs page, in the ASP.NET SDK in the ApplicationInsights.config file, in the ASP.NET Core SDK via
code or in the Java SDK in the ApplicationInsights.xml file.
If you log custom events and need to ensure that a set of events is retained or discarded together, the
events must have the same OperationId value.
The sampling divisor n is reported in each record in the property itemCount , which in Search appears
under the friendly name "request count" or "event count". itemCount==1 when sampling is not in
operation.
If you write Analytics queries, you should take account of sampling. In particular, instead of simply
counting records, you should use summarize sum(itemCount) .
Types of sampling
There are three alternative sampling methods:
Adaptive sampling automatically adjusts the volume of telemetry sent from the SDK in your
ASP.NET/ASP.NET Core app. This is the default sampling from ASP.NET Web SDK v 2.0.0-beta3
onwards and Microsoft.ApplicationInsights.AspNetCore SDK v 2.2.0-beta1 onwards. Adaptive
sampling is currently only available for ASP.NET server-side telemetry.
Fixed-rate sampling reduces the volume of telemetry sent from both your ASP.NET or ASP.NET
Core or Java server and from your users' browsers. You set the rate. The client and server will
synchronize their sampling so that, in Search, you can navigate between related page views and
requests.
Ingestion sampling Works in the Azure portal. It discards some of the telemetry that arrives from
your app, at a sampling rate that you set. It doesn't reduce telemetry traffic sent from your app, but
helps you keep within your monthly quota. The main advantage of ingestion sampling is that you
can set the sampling rate without redeploying your app. Ingestion sampling works uniformly for all
servers and clients.
If Adaptive or Fixed rate sampling are in operation, Ingestion sampling is disabled.
Adaptive sampling in your ASP.NET/ASP.NET Core Web
Applications
Adaptive sampling is available for the Application Insights SDK for ASP.NET v 2.0.0-beta3 and later,
Microsoft.ApplicationInsights.AspNetCore SDK v 2.2.0-beta1 and later, and is enabled by default.
Adaptive sampling affects the volume of telemetry sent from your web server app to the Application
Insights service endpoint. The volume is adjusted automatically to keep within a specified maximum rate
of traffic, and is controlled via the setting MaxTelemetryItemsPerSecond . If the application produces a low
amount of telemetry, such as when debugging or due to low usage, items won't be dropped by the
sampling processor as long as volume is below MaxTelemetryItemsPerSecond . As the volume of telemetry
increases, sampling rate is adjusted so as to achieve the target volume.
To achieve the target volume, some of the generated telemetry is discarded. But like other types of
sampling, the algorithm retains related telemetry items. For example, when you're inspecting the
telemetry in Search, you'll be able to find the request related to a particular exception.
Metric counts such as request rate and exception rate are adjusted to compensate for the sampling rate,
so that they show approximately correct values in Metric Explorer.
Configuring adaptive sampling for ASP.NET Applications

Learn about configuring adaptive sampling for ASP.NET Core Applications.
In ApplicationInsights.config, you can adjust several parameters in the
AdaptiveSamplingTelemetryProcessor node. The figures shown are the default values:
<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
The target rate that the adaptive algorithm aims for on each server host. If your web app runs on
many hosts, reduce this value so as to remain within your target rate of traffic at the Application
Insights portal.
<EvaluationInterval>00:00:15</EvaluationInterval>
The interval at which the current rate of telemetry is reevaluated. Evaluation is performed as a
moving average. You might want to shorten this interval if your telemetry is liable to sudden
bursts.
<SamplingPercentageDecreaseTimeout>00:02:00</SamplingPercentageDecreaseTimeout>
When sampling percentage value changes, how soon after are we allowed to lower sampling
percentage again to capture less data.
<SamplingPercentageIncreaseTimeout>00:15:00</SamplingPercentageIncreaseTimeout>
When sampling percentage value changes, how soon after are we allowed to increase sampling
percentage again to capture more data.
<MinSamplingPercentage>0.1</MinSamplingPercentage>
As sampling percentage varies, what is the minimum value we're allowed to set.
<MaxSamplingPercentage>100.0</MaxSamplingPercentage>
As sampling percentage varies, what is the maximum value we're allowed to set.
<MovingAverageRatio>0.25</MovingAverageRatio>
In the calculation of the moving average, the weight assigned to the most recent value. Use a value
equal to or less than 1. Smaller values make the algorithm less reactive to sudden changes.
<InitialSamplingPercentage>100</InitialSamplingPercentage>
The value assigned when the app has just started. Don't reduce value while you're debugging.
<ExcludedTypes>Trace;Exception</ExcludedTypes>
A semi-colon delimited list of types that you do not want to be sampled. Recognized types are:
Dependency, Event, Exception, PageView, Request, Trace. All instances of the specified types are
transmitted; the types that are not specified are sampled.
<IncludedTypes>Request;Dependency</IncludedTypes>
A semi-colon delimited list of types that you want to be sampled. Recognized types are:
Dependency, Event, Exception, PageView, Request, Trace. The specified types are sampled; all
instances of the other types will always be transmitted.
To switch off adaptive sampling, remove the AdaptiveSamplingTelemetryProcessor node(s) from
applicationinsights-config.
Alternative: configure adaptive sampling in code
Instead of setting the sampling parameter in the .config file, you can programmatically set these values.
1. Remove all the AdaptiveSamplingTelemetryProcessor node(s) from the .config file.
2. Use the following snippet to configure Adaptive Sampling.
C#
using Microsoft.ApplicationInsights.WindowsServer.Channel.Implementation;
...
var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;

// If you are on ApplicationInsights SDK v 2.8.0-beta2 or higher, use the following line instead
// var builder =
TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
// Enable AdaptiveSampling so as to keep overall telemetry volume to 5 items per second.

builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5);
// If you have other telemetry processors:

builder.Use((next) => new AnotherProcessor(next));
builder.Build();
(Learn about telemetry processors.)

You can also adjust the sampling rate for each Telemetry type individually, or can even exclude certain
types from being sampled at all.
C#
// The following configures adaptive sampling with 5 items per second, and also excludes
DependencyTelemetry from being subject to sampling.
builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5, excludedTypes: "Dependency");
Configuring adaptive sampling for ASP.NET Core Applications.

There is no ApplicationInsights.Config for ASP.NET Core Applications, so every configuration is done
via code. Adaptive sampling is enabled by default for all ASP.NET Core applications. You can disable or
customize the sampling behavior.
Turning off Adaptive Sampling
The default sampling feature can be disabled while adding Application Insights service, in the method
ConfigureServices , using ApplicationInsightsServiceOptions within the Startup.cs file:

{
// ...
var aiOptions = new

//...
}
The above code will disable sampling feature. Follow the steps below to add sampling with more
customization options.
Configure Sampling settings
Use extension methods of TelemetryProcessorChainBuilder as shown below to customize sampling
behavior.
IMPORTANT
If you use this method to configure sampling, please make sure to use aiOptions.EnableAdaptiveSampling = false;
settings with AddApplicationInsightsTelemetry().
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration
configuration)
{
var builder = configuration.TelemetryProcessorChainBuilder;
// version 2.5.0-beta2 and above should use the following line instead of above.
(https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/CHANGELOG.md#version-250-
beta2)
// var builder = configuration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
// Using adaptive sampling

builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5);
// Alternately, the following configures adaptive sampling with 5 items per second, and also
excludes DependencyTelemetry from being subject to sampling.
// builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5, excludedTypes: "Dependency");
builder.Build();

// ...
}
If using the above method to configure sampling, make sure to use

aiOptions.EnableAdaptiveSampling = false; settings with AddApplicationInsightsTelemetry ().
Fixed-rate sampling for ASP.NET, ASP.NET Core, and Java

websites
Fixed rate sampling reduces the traffic sent from your web server and web browsers. Unlike adaptive
sampling, it reduces telemetry at a fixed rate decided by you. It also synchronizes the client and server
sampling so that related items are retained - for example, when you look at a page view in Search, you can
find its related request.
Like other sampling techniques, this also retains related items. For each HTTP request event, the request
and its related events are either discarded or transmitted together.
In Metrics Explorer, rates such as request and exception counts are multiplied by a factor to compensate
for the sampling rate, so that they are approximately correct.
Configuring fixed-rate sampling in ASP.NET
1. Disable adaptive sampling: In ApplicationInsights.config, remove or comment out the
AdaptiveSamplingTelemetryProcessor node.

2. Enable the fixed-rate sampling module. Add this snippet to ApplicationInsights.config:

<Add
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTelemetryProcessor,



<SamplingPercentage>10</SamplingPercentage>
</Add>
Alternative: enable fixed-rate sampling in your server code

Instead of setting the sampling parameter in the .config file, you can programmatically set these
values.
C#
...
var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;

// If you are on ApplicationInsights SDK v 2.8.0-beta2 or higher, use the following line instead
// var builder =
TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
builder.UseSampling(10.0); // percentage

builder.Build();
(Learn about telemetry processors.)

Configuring fixed-rate sampling in ASP.NET Core
1. Disable adaptive sampling: Changes can be made in the method ConfigureServices , using
ApplicationInsightsServiceOptions :

{
// ...
var aiOptions = new

//...
}
2. Enable the fixed-rate sampling module. Changes can be made in the method Configure as
shown in below snippet:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
var configuration = app.ApplicationServices.GetService<TelemetryConfiguration>();
var builder = configuration.TelemetryProcessorChainBuilder;

// version 2.5.0-beta2 and above should use the following line instead of above.
(https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/CHANGELOG.md#version-
250-beta2)
// var builder = configuration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
// Using fixed rate sampling

double fixedSamplingPercentage = 10;
builder.UseSampling(fixedSamplingPercentage);
builder.Build();
// ...
}
Configuring fixed-rate sampling in JAVA

1. Download and configure your web application with latest application insights java SDK
2. Enable the fixed-rate sampling module by adding the following snippet to
ApplicationInsights.xml file.
<BuiltInProcessors>
<Processor type = "FixedRateSamplingTelemetryProcessor">

<Add name = "SamplingPercentage" value = "50" />
</Processor>
</BuiltInProcessors>
3. You can Include or Exclude specific types of telemetry from Sampling using the following tags
inside the Processor tag "FixedRateSamplingTelemetryProcessor"
<ExcludedTypes>
<ExcludedType>Request</ExcludedType>
</ExcludedTypes>
<IncludedTypes>
<IncludedType>Exception</IncludedType>
</IncludedTypes>
The telemetry types that can be included or excluded from sampling are: Dependency, Event, Exception,
PageView, Request, and Trace.
NOTE
For the sampling percentage, choose a percentage that is close to 100/N where N is an integer. Currently sampling
doesn't support other values.
Ingestion sampling
This form of sampling operates at the point where the telemetry from your web server, browsers, and
devices reaches the Application Insights service endpoint. Although it doesn't reduce the telemetry traffic
sent from your app, it does reduce the amount processed and retained (and charged for) by Application
Insights.
Use this type of sampling if your app often goes over its monthly quota and you don't have the option of
using either of the SDK-based types of sampling.
Set the sampling rate in the Usage and estimated costs page:
Like other types of sampling, the algorithm retains related telemetry items. For example, when you're
inspecting the telemetry in Search, you'll be able to find the request related to a particular exception.
Metric counts such as request rate and exception rate are correctly retained.
Data points that are discarded by sampling are not available in any Application Insights feature such as
Continuous Export.
Ingestion sampling doesn't operate while SDK-based adaptive or fixed-rate sampling is in operation.
Adaptive sampling is enabled by default when ASP.NET/ASP.NET Core SDK is enabled in Visual Studio
or enabled in Azure Web App extensions or by using Status Monitor, and ingestion sampling is disabled.
If the sampling rate at the SDK is less than 100% (i.e items are being sampled) then the ingestion
sampling rate that you set is ignored.
WARNING
The value shown on the tile indicates the value that you set for ingestion sampling. It doesn't represent the actual
sampling rate if SDK sampling is in operation.
Sampling for web pages with JavaScript

You can configure web pages for fixed-rate sampling from any server.
When you configure the web pages for Application Insights, modify the JavaScript snippet that you get
from the Application Insights portal. (In ASP.NET apps, the snippet typically goes in _Layout.cshtml.)
Insert a line like samplingPercentage: 10, before the instrumentation key:
<script>
var appInsights= ...
}({
// Value must be 100/N where N is an integer.

// Valid examples: 50, 25, 20, 10, 5, 1, 0.1, ...
samplingPercentage: 10,
instrumentationKey:...
});
</script>
For the sampling percentage, choose a percentage that is close to 100/N where N is an integer. Currently
sampling doesn't support other values.
If you also enable fixed-rate sampling at the server, the clients and server will synchronize so that, in
Search, you can navigate between related page views and requests.
When to use sampling?

Adaptive sampling is automatically enabled in latest .NET and .NET Core SDKs. Regardless of which
version of the SDK you use, you can enable ingestion sampling to allow Application Insights to sample
the collected data.
By default no sampling is enabled in Java SDK. Currently, it only supports Fixed Rate Sampling. Adaptive
Sampling is not supported in Java SDK.
In general, for most small and medium size applications you don’t need sampling. The most useful
diagnostic information and most accurate statistics are obtained by collecting data on all your user
activities.
The main advantages of sampling are:
Application Insights service drops ("throttles") data points when your app sends a very high rate of
telemetry in short time interval.
To keep within the quota of data points for your pricing tier.
To reduce network traffic from the collection of telemetry.
Which type of sampling should I use?
Use ingestion sampling if:
You often go through your monthly quota of telemetry.
You're using a version of the SDK that doesn't support sampling - for example ASP.NET versions
earlier than 2.
You're getting too much telemetry from your users' web browsers.
Use fixed-rate sampling if:
You're using the Application Insights SDK for ASP.NET web services version 2.0.0 or later or Java SDK
v2.0.1 or later, and
You want synchronized sampling between client and server, so that, when you're investigating events in
Search, you can navigate between related events on the client and server, such as page views and http
requests.
You are confident of the appropriate sampling percentage for your app. It should be high enough to
get accurate metrics, but below the rate that exceeds your pricing quota and the throttling limits.
Use adaptive sampling:
If the conditions to use the other forms of sampling do not apply, we recommend adaptive sampling. This
setting is enabled by default in the ASP.NET/ASP.NET Core server SDK. It will not reduce traffic until a
certain minimum rate is reached, therefore, low -use sites will not be affected.
How do I know whether sampling is in operation?

To discover the actual sampling rate no matter where it has been applied, use an Analytics query such as
this:
union requests,dependencies,pageViews,browserTimings,exceptions,traces
| summarize RetainedPercentage = 100/avg(itemCount) by bin(timestamp, 1h), itemType
If RetainedPercentage for any type is less than 100, then that item is being sampled.
Application Insights does not sample session, metrics and performance counters telemetry
types in any sampling techniques described above. These types are always excluded from
sampling as reduction in precision can be highly undesirable for these telemetry types
How does sampling work?

Fixed-rate sampling feature of the SDK in ASP.NET versions from 2.0.0 and Java SDK version 2.0.1 and
onwards. Adaptive sampling is a feature of SDK in ASP.NET versions from 2.0.0 onwards. Ingestion
sampling is a feature of the Application Insights service, and can be in operation if the SDK is not
performing sampling.
The sampling algorithm decides which telemetry items to drop, and which ones to keep (whether it's in
the SDK or in the Application Insights service). The sampling decision is based on several rules that aim to
preserve all interrelated data points intact, maintaining a diagnostic experience in Application Insights that
is actionable and reliable even with a reduced data set. For example, if for a failed request your app sends
additional telemetry items (such as exception and traces logged from this request), sampling will not split
this request and other telemetry. It either keeps or drops them all together. As a result, when you look at
the request details in Application Insights, you can always see the request along with its associated
telemetry items.
The sampling decision is based on the operation ID of the request, which means that all telemetry items
belonging to a particular operation is either preserved or dropped. For the telemetry items that do not
have operation ID set (for example telemetry items reported from asynchronous threads with no http
context) sampling simply captures a percentage of telemetry items of each type. Prior to 2.5.0-beta2 of
.NET SDK, and 2.2.0-beta3 of ASP.NET Core SDK, the sampling decision was based on the hash of the
user ID for applications that define "user" (that is, most typical web applications). For the types of
applications that didn't define users (such as web services) the sampling decision was based on the
operation ID of the request.
When presenting telemetry back to you, the Application Insights service adjusts the metrics by the same
sampling percentage that was used at the time of collection, to compensate for the missing data points.
Hence, when looking at the telemetry in Application Insights, the users are seeing statistically correct
approximations that are very close to the real numbers.
The accuracy of the approximation largely depends on the configured sampling percentage. Also, the
accuracy increases for applications that handle a large volume of generally similar requests from lots of
users. On the other hand, for applications that don't work with a significant load, sampling is not needed
as these applications can usually send all their telemetry while staying within the quota, without causing
data loss from throttling.
WARNING
Application Insights does not sample metrics and sessions telemetry types. Reduction in the precision can be highly
undesirable for these telemetry types.
Adaptive sampling
Adaptive sampling adds a component that monitors the current rate of transmission from the SDK, and
adjusts the sampling percentage to try to stay within the target maximum rate. The adjustment is
recalculated at regular intervals, and is based on a moving average of the outgoing transmission rate.
Sampling and the JavaScript SDK

The client-side (JavaScript) SDK participates in fixed-rate sampling in conjunction with the server-side
SDK. The instrumented pages will only send client-side telemetry from the same users for which the
server-side made its decision to "sample in." This logic is designed to maintain integrity of user session
across client- and server-sides. As a result, from any particular telemetry item in Application Insights you
can find all other telemetry items for this user or session.
My client and server-side telemetry don't show coordinated samples as you describe above.
Verify that you enabled fixed-rate sampling both on server and client.
Make sure that the SDK version is 2.0 or above.
Check that you set the same sampling percentage in both the client and server.
Sampling in Azure Functions
Follow instructions from this to configure sampling for apps running in Azure Functions.
Frequently Asked Questions

What is the default sampling behavior in ASP.NET and ASP.NET Core SDK?
If you are using one of the latest versions of the above SDK, Adaptive Sampling is enabled by
default with five telemetry items per second. There are 2 AdaptiveSamplingTelemetryProcessors
added by default, and one includes Event type in sampling, and the other excludes Event type from
sampling. This configuration means that the SDK will try to limit telemetry items to five telemetry
items of Event types, and five telemetry items of all other types combined, thereby ensuring that
Events are sampled separately from other Telemetry types. Events are typically used for business
telemetry, and most likely should not be affected by diagnostic telemetry volumes.
The following shows the default ApplicationInsights.Config file generated. As described, there are
two separate AdaptiveSamplingTelemetryProcessor nodes added, one excluding Event types, and
another including it. In ASP.NET Core, exact same default behavior is enabled in code. Use the
examples in the earlier section of the document to change this default behavior.
<Add
<ExcludedTypes>Event</ExcludedTypes>
</Add>
<Add
<IncludedTypes>Event</IncludedTypes>
</Add>
Can telemetry be sampled more than once?

No. SamplingTelemetryProcessors ignore items from sampling considerations if the item is already
sampled. The same is true for Ingestion sampling as well, which won't apply sampling to those items
already sampled in the SDK itself.'
Why isn't sampling a simple "collect X percent of each telemetry type"?
While this sampling approach would provide with a high level of precision in metric approximations, it
would break ability to correlate diagnostic data per user, session, and request, which is critical for
diagnostics. Therefore, sampling works better with "collect all telemetry items for X percent of app
users", or "collect all telemetry for X percent of app requests" logic. For the telemetry items not
associated with the requests (such as background asynchronous processing), the fallback is to "collect
X percent of all items for each telemetry type."
Can the sampling percentage change over time?
Yes, adaptive sampling gradually changes the sampling percentage, based on the currently observed
volume of the telemetry.
If I use fixed -rate sampling, how do I know which sampling percentage will work the best for my app?
One way is to start with adaptive sampling, find out what rate it settles on (see the above question),
and then switch to fixed-rate sampling using that rate.
Otherwise, you have to guess. Analyze your current telemetry usage in Application Insights,
observe any throttling that is occurring, and estimate the volume of the collected telemetry. These
three inputs, together with your selected pricing tier, suggest how much you might want to reduce
the volume of the collected telemetry. However, an increase in the number of your users or some
other shift in the volume of telemetry might invalidate your estimate.
What happens if I configure sampling percentage too low?
Excessively low sampling percentage (over-aggressive sampling) reduces the accuracy of the
approximations, when Application Insights attempts to compensate the visualization of the data for the
data volume reduction. Also, diagnostic experience might be negatively impacted, as some of the
infrequently failing or slow requests may be sampled out.
What happens if I configure sampling percentage too high?
Configuring too high sampling percentage (not aggressive enough) results in an insufficient reduction
in the volume of the collected telemetry. You may still experience telemetry data loss related to
throttling, and the cost of using Application Insights might be higher than you planned due to overage
charges.
On what platforms can I use sampling?
Ingestion sampling can occur automatically for any telemetry above a certain volume, if the SDK is not
performing sampling. This configuration would work, for example, if you are using an older version of
the ASP.NET SDK or previous version of Java SDK(1.0.10 or before).
If you're using ASP.NET SDK versions 2.0.0 and above or ASP.NET CORE SDK version 2.2.0 and
above (hosted either in Azure or on your own server), you get adaptive sampling by default, but you
can switch to fixed-rate as described above. With fixed-rate sampling, the browser SDK automatically
synchronizes to sample related events.
If you're using Java SDK version 2.0.1 or above, you can configure ApplicationInsights.xml to turn on
Fixed Rate Sampling. Sampling is turned off by default. With fixed-rate sampling, the browser SDK
automatically synchronizes to sample related events.
There are certain rare events I always want to see. How can I get them past the sampling module?
The best way to achieve this is to write a custom TelemetryInitializer, which sets the
SamplingPercentage to 100 on the telemetry item you want retained, as shown below. As initializers are
guaranteed to be run before telemetry processors (including sampling), this ensures that all sampling
techniques will ignore this item from any sampling considerations.

{
{
if(somecondition)
{
((ISupportSampling)item).SamplingPercentage = 100;
}
}
}
Next steps
Filtering can provide more strict control of what your SDK sends.
Read the Developer Network article Optimize Telemetry with Application Insights.
Telemetry channels in Application Insights
Telemetry channels are an integral part of the Azure Application Insights SDKs. They manage buffering and
transmission of telemetry to the Application Insights service. The .NET and .NET Core versions of the SDKs have
two built-in telemetry channels: InMemoryChannel and ServerTelemetryChannel . This article describes each channel
in detail, including how to customize channel behavior.
What are telemetry channels?

Telemetry channels are responsible for buffering telemetry items and sending them to the Application Insights
service, where they're stored for querying and analysis. A telemetry channel is any class that implements the
Microsoft.ApplicationInsights.ITelemetryChannel interface.
The Send(ITelemetry item) method of a telemetry channel is called after all telemetry initializers and telemetry
processors are called. So, any items dropped by a telemetry processor won't reach the channel. Send() doesn't
typically send the items to the back end instantly. Typically, it buffers them in memory and sends them in batches,
for efficient transmission.
Live Metrics Stream also has a custom channel that powers the live streaming of telemetry. This channel is
independent of the regular telemetry channel, and this document doesn't apply to it.
Built-in telemetry channels

The Application Insights .NET and .NET Core SDKs ship with two built-in channels:
InMemoryChannel : A lightweight channel that buffers items in memory until they're sent. Items are buffered
in memory and flushed once every 30 seconds, or whenever 500 items are buffered. This channel offers
minimal reliability guarantees because it doesn't retry sending telemetry after a failure. This channel also
doesn't keep items on disk, so any unsent items are lost permanently upon application shutdown (graceful
or not). This channel implements a Flush() method that can be used to force-flush any in-memory
telemetry items synchronously. This channel is well suited for short-running applications where a
synchronous flush is ideal.
This channel is part of the larger Microsoft.ApplicationInsights NuGet package and is the default channel
that the SDK uses when nothing else is configured.
ServerTelemetryChannel : A more advanced channel that has retry policies and the capability to store data on
a local disk. This channel retries sending telemetry if transient errors occur. This channel also uses local disk
storage to keep items on disk during network outages or high telemetry volumes. Because of these retry
mechanisms and local disk storage, this channel is considered more reliable and is recommended for all
production scenarios. This channel is the default for ASP.NET and ASP.NET Core applications that are
configured according to the official documentation. This channel is optimized for server scenarios with long-
running processes. The Flush() method that's implemented by this channel isn't synchronous.
This channel is shipped as the Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel NuGet
package and is acquired automatically when you use either the Microsoft.ApplicationInsights.Web or
Microsoft.ApplicationInsights.AspNetCore NuGet package.
Configure a telemetry channel

You configure a telemetry channel by setting it to the active telemetry configuration. For ASP.NET applications,
configuration involves setting the telemetry channel instance to TelemetryConfiguration.Active , or by modifying
ApplicationInsights.config . For ASP.NET Core applications, configuration involves adding the channel to the
Dependency Injection Container.
The following sections show examples of configuring the StorageFolder setting for the channel in various
application types. StorageFolder is just one of the configurable settings. For the full list of configuration settings,
see the settings section later in this article.
Configuration by using ApplicationInsights.config for ASP.NET applications
The following section from ApplicationInsights.config shows the ServerTelemetryChannel channel configured with
StorageFolder set to a custom location:
<TelemetrySinks>
<Add Name="default">

<TelemetryChannel
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
<StorageFolder>d:\temp\applicationinsights</StorageFolder>
</TelemetryChannel>
</Add>
</TelemetrySinks>
Configuration in code for ASP.NET applications

The following code sets up a 'ServerTelemetryChannel' instance with StorageFolder set to a custom location. Add
this code at the beginning of the application, typically in Application_Start() method in Global.aspx.cs.
{
var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
}
Configuration in code for ASP.NET Core applications

Modify the ConfigureServices method of the Startup.cs class as shown here:

{
// This sets up ServerTelemetryChannel with StorageFolder set to a custom location.
services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel() {StorageFolder =
@"d:\temp\applicationinsights" });
}
IMPORTANT
Configuring the channel by using TelemetryConfiguration.Active is not recommended for ASP.NET Core applications.
Configuration in code for .NET/.NET Core console applications

For console apps, the code is the same for both .NET and .NET Core:
var serverTelemetryChannel = new ServerTelemetryChannel();

serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
Operational details of ServerTelemetryChannel

ServerTelemetryChannel stores arriving items in an in-memory buffer. The items are serialized, compressed, and
stored into a Transmission instance once every 30 seconds, or when 500 items have been buffered. A single
Transmission instance contains up to 500 items and represents a batch of telemetry that's sent over a single
HTTPS call to the Application Insights service.
By default, a maximum of 10 Transmission instances can be sent in parallel. If telemetry is arriving at faster rates,
or if the network or the Application Insights back end is slow, Transmission instances are stored in memory. The
default capacity of this in-memory Transmission buffer is 5 MB. When the in-memory capacity has been exceeded,
Transmission instances are stored on local disk up to a limit of 50 MB. Transmission instances are stored on local
disk also when there are network problems. Only those items that are stored on a local disk survive an application
crash. They're sent whenever the application starts again.
Configurable settings in channels

For the full list of configurable settings for each channel, see:
InMemoryChannel
ServerTelemetryChannel
Here are the most commonly used settings for ServerTelemetryChannel :
1. MaxTransmissionBufferCapacity : The maximum amount of memory, in bytes, used by the channel to buffer
transmissions in memory. When this capacity is reached, new items are stored directly to local disk. The
default value is 5 MB. Setting a higher value leads to less disk usage, but remember that items in memory
will be lost if the application crashes.
2. MaxTransmissionSenderCapacity : The maximum number of Transmission instances that will be sent to
Application Insights at the same time. The default value is 10. This setting can be configured to a higher
number, which is recommended when a huge volume of telemetry is generated. High volume typically
occurs during load testing or when sampling is turned off.
3. : The folder that's used by the channel to store items to disk as needed. In Windows, either
StorageFolder
%LOCALAPPDATA% or %TEMP% is used if no other path is specified explicitly. In environments other than
Windows, you must specify a valid location or telemetry won't be stored to local disk.
Which channel should I use?

ServerTelemetryChannel is recommended for most production scenarios involving long-running applications. The
Flush() method implemented by ServerTelemetryChannel isn't synchronous, and it also doesn't guarantee sending
all pending items from memory or disk. If you use this channel in scenarios where the application is about to shut
down, we recommend that you introduce some delay after calling Flush() . The exact amount of delay that you
might require isn't predictable. It depends on factors like how many items or Transmission instances are in
memory, how many are on disk, how many are being transmitted to the back end, and whether the channel is in
the middle of exponential back-off scenarios.
If you need to do a synchronous flush, we recommend that you use InMemoryChannel .

Does the Application Insights channel guarantee telemetry delivery? If not, what are the scenarios in which
telemetry can be lost?
The short answer is that none of the built-in channels offer a transaction-type guarantee of telemetry delivery to
the back end. ServerTelemetryChannel is more advanced compared with InMemoryChannel for reliable delivery, but
it also makes only a best-effort attempt to send telemetry. Telemetry can still be lost in several situations, including
these common scenarios:
1. Items in memory are lost when the application crashes.
2. Telemetry is lost during extended periods of network problems. Telemetry is stored to local disk during
network outages or when problems occur with the Application Insights back end. However, items older than
24 hours are discarded.
3. The default disk locations for storing telemetry in Windows are %LOCALAPPDATA% or %TEMP%. These
locations are typically local to the machine. If the application migrates physically from one location to
another, any telemetry stored in the original location is lost.
4. In Web Apps on Windows, the default disk-storage location is D:\local\LocalAppData. This location isn't
persisted. It's wiped out in app restarts, scale-outs, and other such operations, leading to loss of any
telemetry stored there. You can override the default and specify storage to a persisted location like D:\home.
However, such persisted locations are served by remote storage and so can be slow.
Does ServerTelemetryChannel work on systems other than Windows?
Although the name of its package and namespace includes "WindowsServer," this channel is supported on
systems other than Windows, with the following exception. On systems other than Windows, the channel doesn't
create a local storage folder by default. You must create a local storage folder and configure the channel to use it.
After local storage has been configured, the channel works the same way on all systems.
Does the SDK create temporary local storage? Is the data encrypted at storage?
The SDK stores telemetry items in local storage during network problems or during throttling. This data isn't
encrypted locally.
For Windows systems, the SDK automatically creates a temporary local folder in the %TEMP% or
%LOCALAPPDATA% directory, and restricts access to administrators and the current user only.
For systems other than Windows, no local storage is created automatically by the SDK, and so no data is stored
locally by default. You can create a storage directory yourself and configure the channel to use it. In this case, you're
responsible for ensuring that the directory is secured. Read more about data protection and privacy.
Open-source SDK
Like every SDK for Application Insights, channels are open source. Read and contribute to the code, or report
problems, at the official GitHub repo.
Next steps
Sampling
SDK Troubleshooting
Filtering and preprocessing telemetry in the
Application Insights SDK
You can write and configure plug-ins for the Application Insights SDK to customize how telemetry can be
enriched and processed before it's sent to the Application Insights service.
Sampling reduces the volume of telemetry without affecting your statistics. It keeps together related data
points so that you can navigate between them when diagnosing a problem. In the portal, the total counts are
multiplied to compensate for the sampling.
Filtering with Telemetry Processors lets you filter out telemetry in the SDK before it is sent to the server. For
example, you could reduce the volume of telemetry by excluding requests from robots. Filtering is a more
basic approach to reducing traffic than sampling. It allows you more control over what is transmitted, but
you have to be aware that it affects your statistics - for example, if you filter out all successful requests.
Telemetry Initializers add or modify properties to any telemetry sent from your app, including telemetry
from the standard modules. For example, you could add calculated values; or version numbers by which to
filter the data in the portal.
The SDK API is used to send custom events and metrics.
Before you start:
Install the appropriate SDK for you application. ASP.NET or ASP.NET Core or Non HTTP/Worker for
.NET/.NET Core or Java in your app.
Filtering: ITelemetryProcessor
This technique gives you direct control over what is included or excluded from the telemetry stream. Filtering
can be used to drop telemetry items from being sent to Application Insights. You can use it in conjunction with
Sampling, or separately.
To filter telemetry, you write a telemetry processor and register it with the TelemetryConfiguration . All
telemetry goes through your processor, and you can choose to drop it from the stream or give it to the next
processor in the chain. This includes telemetry from the standard modules such as the HTTP request collector
and the dependency collector, and telemetry you have tracked yourself. You can, for example, filter out
telemetry about requests from robots, or successful dependency calls.
WARNING
Filtering the telemetry sent from the SDK using processors can skew the statistics that you see in the portal, and make it
difficult to follow related items.
Instead, consider using sampling.
Create a telemetry processor (C#)

1. To create a filter, implement ITelemetryProcessor .
Notice that Telemetry Processors construct a chain of processing. When you instantiate a telemetry
processor, you are given a reference to the next processor in the chain. When a telemetry data point is
passed to the Process method, it does its work and then calls (or not calls) the next Telemetry Processor
in the chain.
public class SuccessfulDependencyFilter : ITelemetryProcessor

{
private ITelemetryProcessor Next { get; set; }
// next will point to the next TelemetryProcessor in the chain.

public SuccessfulDependencyFilter(ITelemetryProcessor next)
{
this.Next = next;
}
public void Process(ITelemetry item)

{
// To filter out an item, return without calling the next processor.
if (!OKtoSend(item)) { return; }
this.Next.Process(item);
}
// Example: replace with your own criteria.

private bool OKtoSend (ITelemetry item)
{
var dependency = item as DependencyTelemetry;
if (dependency == null) return true;
return dependency.Success != true;

}
}
2. Add your processor.

ASP.NET apps Insert this snippet in ApplicationInsights.config:
<Add Type="WebApplication9.SuccessfulDependencyFilter, WebApplication9">

<MyParamFromConfigFile>2-beta</MyParamFromConfigFile>
</Add>
You can pass string values from the .config file by providing public named properties in your class.
WARNING
Take care to match the type name and any property names in the .config file to the class and property names in the
code. If the .config file references a non-existent type or property, the SDK may silently fail to send any telemetry.
Alternatively, you can initialize the filter in code. In a suitable initialization class - for example AppStart in
Global.asax.cs - insert your processor into the chain:
var builder = TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;

builder.Use((next) => new SuccessfulDependencyFilter(next));

builder.Build();
TelemetryClients created after this point will use your processors.
ASP.NET Core/ Worker Service apps
NOTE
Adding processor using ApplicationInsights.config or using TelemetryConfiguration.Active is not valid for
ASP.NET Core applications or if you are using Microsoft.ApplicationInsights.WorkerService SDK.
For apps written using ASP.NET Core or WorkerService, adding a new TelemetryProcessor is done by using
AddApplicationInsightsTelemetryProcessor extension method on IServiceCollection , as shown below. This
method is called in ConfigureServices method of your Startup.cs class.

{
// ...
services.AddApplicationInsightsTelemetryProcessor<SuccessfulDependencyFilter>();

services.AddApplicationInsightsTelemetryProcessor<AnotherProcessor>();
}
Example filters
Synthetic requests
Filter out bots and web tests. Although Metrics Explorer gives you the option to filter out synthetic sources, this
option reduces traffic and ingestion size by filtering them at the SDK itself.

{
if (!string.IsNullOrEmpty(item.Context.Operation.SyntheticSource)) {return;}
// Send everything else:

}
Failed authentication
Filter out requests with a "401" response.

{
var request = item as RequestTelemetry;
if (request != null &&

request.ResponseCode.Equals("401", StringComparison.OrdinalIgnoreCase))
{
// To filter out an item, return without calling the next processor.
return;
}
// Send everything else

}
Filter out fast remote dependency calls

If you only want to diagnose calls that are slow, filter out the fast ones.
NOTE
This will skew the statistics you see on the portal.

{
var request = item as DependencyTelemetry;
if (request != null && request.Duration.TotalMilliseconds < 100)

{
return;
}
}
Diagnose dependency issues

This blog describes a project to diagnose dependency issues by automatically sending regular pings to
dependencies.
Add properties: ITelemetryInitializer

Use telemetry initializers to enrich telemetry with additional information and/or to override telemetry
properties set by the standard telemetry modules.
For example, the Application Insights for Web package collect telemetry about HTTP requests. By default, it
flags as failed any request with a response code >= 400. But if you want to treat 400 as a success, you can
provide a telemetry initializer that sets the Success property.
If you provide a telemetry initializer, it is called whenever any of the Track*() methods are called. This includes
Track() methods called by the standard telemetry modules. By convention, these modules do not set any
property that has already been set by an initializer. Telemetry initializers are called before calling telemetry
processors. So any enrichments done by initializers are visible to processors.
Define your initializer
C#
using System;
{
/*
* Custom TelemetryInitializer that overrides the default SDK
* behavior of treating response codes >= 400 as failed requests
*
*/
{
{
var requestTelemetry = telemetry as RequestTelemetry;
// Is this a TrackRequest() ?
if (requestTelemetry == null) return;
int code;
bool parsed = Int32.TryParse(requestTelemetry.ResponseCode, out code);
if (!parsed) return;
if (code >= 400 && code < 500)
{
// If we set the Success property, the SDK won't change it:
requestTelemetry.Success = true;
// Allow us to filter these requests in the portal:

requestTelemetry.Properties["Overridden400s"] = "true";
}
// else leave the SDK to set the Success property
}
}
}
ASP.NET apps: Load your initializer

In ApplicationInsights.config:

<Add Type="MvcWebRole.Telemetry.MyTelemetryInitializer, MvcWebRole"/>
...
Alternatively, you can instantiate the initializer in code, for example in Global.aspx.cs:

{
// ...
TelemetryConfiguration.Active.TelemetryInitializers.Add(new MyTelemetryInitializer());
}
See more of this sample.

ASP.NET Core/ Worker Service apps: Load your initializer
NOTE
ASP.NET Core applications or if you are using Microsoft.ApplicationInsights.WorkerService SDK.
For apps written using ASP.NET Core or WorkerService, adding a new TelemetryInitializer is done by adding
it to the Dependency Injection container, as shown below. This is done in Startup.ConfigureServices method.
{
}
Java telemetry initializers

Java SDK documentation
public interface TelemetryInitializer

{ /** Initializes properties of the specified object. * @param telemetry The {@link
com.microsoft.applicationinsights.telemetry.Telemetry} to initialize. */
void initialize(Telemetry telemetry); }
Then register the custom initializer in your applicationinsights.xml file.
<Add type="mypackage.MyConfigurableContextInitializer">
<Param name="some_config_property" value="some_value" />
</Add>
JavaScript telemetry initializers

JavaScript
Insert a telemetry initializer immediately after the initialization code that you got from the portal:
// ... initialization code
...({
instrumentationKey: "your instrumentation key"
});
window.appInsights = appInsights;
// Adding telemetry initializer.

// This is called whenever a new telemetry item
// is created.
appInsights.queue.push(function () {
appInsights.context.addTelemetryInitializer(function (envelope) {
var telemetryItem = envelope.data.baseData;
// To check the telemetry items type - for example PageView:

if (envelope.name == Microsoft.ApplicationInsights.Telemetry.PageView.envelopeType) {
// this statement removes url from all page view documents
telemetryItem.url = "URL CENSORED";
}
// To set custom properties:

telemetryItem.properties = telemetryItem.properties || {};
telemetryItem.properties["globalProperty"] = "boo";
// To set custom metrics:

telemetryItem.measurements = telemetryItem.measurements || {};
telemetryItem.measurements["globalMetric"] = 100;
});
});
// End of inserted code.
</script>
For a summary of the non-custom properties available on the telemetryItem, see Application Insights Export
Data Model.
You can add as many initializers as you like, and they are called in the order they are added.
Example TelemetryInitializers
Add custom property
The following sample initializer adds a custom property to every tracked telemetry.
public void Initialize(ITelemetry item)

{
var itemProperties = item as ISupportProperties;
if(itemProperties != null && !itemProperties.ContainsKey("customProp"))
{
itemProperties.Properties["customProp"] = "customValue";
}
}
Add cloud role name

The following sample initializer sets cloud role name to every tracked telemetry.
{
if(string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
{
telemetry.Context.Cloud.RoleName = "MyCloudRoleName";
}
}
ITelemetryProcessor and ITelemetryInitializer

What's the difference between telemetry processors and telemetry initializers?
There are some overlaps in what you can do with them: both can be used to add or modify properties of
telemetry, though it is recommended to use initializers for that purpose.
TelemetryInitializers always run before TelemetryProcessors.
TelemetryInitializers may be called more than once. By convention, they do not set any property that has
already been set.
TelemetryProcessors allow you to completely replace or discard a telemetry item.
All registered TelemetryInitializers are guaranteed to be called for every telemetry item. For Telemetry
processors, SDK guarantees calling the very first telemetry processor. Whether the rest of the processors are
called or not, is decided by the preceding telemetry processors.
Use TelemetryInitializers to enrich telemetry with additional properties, or override existing one. Use
TelemetryProcessor to filter out telemetry.
Troubleshooting ApplicationInsights.config
Confirm that the fully qualified type name and assembly name are correct.
Confirm that the applicationinsights.config file is in your output directory and contains any recent changes.
Reference docs
API Overview
ASP.NET reference
SDK Code
ASP.NET Core SDK
ASP.NET SDK
JavaScript SDK
Next steps
Search events and logs
Sampling
Troubleshooting

A distributed logical operation typically consists of a set of smaller operations, which are requests processed by one
of the components. These operations are defined by request telemetry. Every request telemetry has its own id
that identifies it uniquely and globally. And all telemetry items (such as traces and exceptions) that are associated
with this request should set the operation_parentId to the value of the request id .
In a microservices environment, traces from components can go to different storage items. Every component can
have its own instrumentation key in Application Insights. To get telemetry for the logical operation, the Application
Insights UX queries data from every storage item. When the number of storage items is huge, you'll need a hint
about where to look next. The Application Insights data model defines two fields to solve this problem:
request.source and dependency.target . The first field identifies the component that initiated the dependency
request, and the second identifies which component returned the response of the dependency call.
Example
using an external API called Stock . The Stock Prices application has a page called Stock page that the client web
browser opens by using GET /Home/Stock . The application queries the Stock API by using an HTTP call

In the results, note that all telemetry items share the root operation_Id . When an Ajax call is made from the page, a
new unique ID ( qJSXU ) is assigned to the dependency telemetry and the ID of the pageView is used as
When the call GET /api/stock/value is made to an external service, you want to know the identity of that server so
you can set the dependency.target field appropriately. When the external service doesn't support monitoring,
target is set to the host name of the service (for example, stock-prices-api.com ). However, if the service identifies
itself by returning a predefined HTTP header, target contains the service identity that allows Application Insights
to build a distributed trace by querying telemetry from that service.
Correlation headers
Latest versions of Application Insights SDKs support Trace-Context protocol, but you may need to opt-into that (it
will keep backward compatibility with old correlation protocol supported by ApplicationInsights SDKs).
value pairs to propagate the collection of properties used by the immediate caller or callee. The Application Insights
SDK uses this header to set dependency.target and request.source fields.
NOTE
configuration
Under DependencyTrackingTelemetryModule , add the EnableW3CHeadersInjection element with value set to true .
...
NOTE
configuration
Trace-Context.

{
// ....
}

<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModul
e>
</Add>

<Instrumentation>
</BuiltIn>
</Instrumentation>
NOTE
Backward compatibility mode is enabled by default, and the enableW3CBackCompat parameter is optional. Use it only
when you want to turn backward compatibility off.
Ideally, you would turn this off when all your services have been updated to newer versions of SDKs that support the
W3C protocol. We highly recommend that you move to these newer SDKs as soon as possible.
IMPORTANT


} });

n=a.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",a.getEle
mentsByTagName("script")[0].parentNode.appendChild(n)});try{i.cookie=a.cookie}catch(e){}i.queue=
ack"+r.pop());n("startTrackPage"),n("stopTrackPage");var o="Track"+r[0];if(n("start"+o),n("stop"+o),!
s=t[r];t[r]=function(e,n,a,t,o){var c=s&&s(e,n,a,t,o);return!0!==c&&i["_"+r]
(
{
}
);
</script>


However, those methods didn't enable automatic distributed tracing support. DiagnosticSource is a way to support
automatic cross-machine correlation. .NET libraries support 'DiagnosticSource' and allow automatic cross-machine
propagation of the correlation context via the transport, such as HTTP.

The Application Insights SDK for Java supports automatic correlation of telemetry beginning with version 2.0.0. It
automatically populates operation_id for all telemetry (such as traces, exceptions, and custom events) issued
NOTE
Only calls made via Apache HTTPClient are supported for the correlation feature. If you're using Spring RestTemplate or Feign,
both can be used with Apache HTTPClient under the hood.
Currently, automatic context propagation across messaging technologies (such Kafka, RabbitMQ, or Azure Service
Bus) isn't supported. However, it's possible to code such scenarios manually by using the trackDependency and
trackRequest APIs. In these APIs, a dependency telemetry represents a message being enqueued by a producer,
and the request represents a message being processed by a consumer. In this case, both operation_id and
operation_parentId should be propagated in the message's properties.

Role name
At times, you might want to customize the way component names are displayed in the Application Map. To do so,
you can manually set the cloud_RoleName by doing one of the following:
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebAppNameContextInitializer" />
Next steps
For advanced correlation scenarios in ASP.NET Core and ASP.NET consult the track custom operations article.
Track custom operations with Application Insights
.NET SDK
Azure Application Insights SDKs automatically track incoming HTTP requests and calls to dependent services,
such as HTTP requests and SQL queries. Tracking and correlation of requests and dependencies give you
visibility into the whole application's responsiveness and reliability across all microservices that combine this
application.
There is a class of application patterns that can't be supported generically. Proper monitoring of such patterns
requires manual code instrumentation. This article covers a few patterns that might require manual
instrumentation, such as custom queue processing and running long-running background tasks.
This document provides guidance on how to track custom operations with the Application Insights SDK. This
documentation is relevant for:
Application Insights for .NET (also known as Base SDK) version 2.4+.
Application Insights for web applications (running ASP.NET) version 2.4+.
Application Insights for ASP.NET Core version 2.1+.
Overview
An operation is a logical piece of work run by an application. It has a name, start time, duration, result, and a
context of execution like user name, properties, and result. If operation A was initiated by operation B, then
operation B is set as a parent for A. An operation can have only one parent, but it can have many child operations.
For more information on operations and telemetry correlation, see Azure Application Insights telemetry
correlation.
In the Application Insights .NET SDK, the operation is described by the abstract class OperationTelemetry and its
descendants RequestTelemetry and DependencyTelemetry.
Incoming operations tracking

The Application Insights web SDK automatically collects HTTP requests for ASP.NET applications that run in an
IIS pipeline and all ASP.NET Core applications. There are community-supported solutions for other platforms
and frameworks. However, if the application isn't supported by any of the standard or community-supported
solutions, you can instrument it manually.
Another example that requires custom tracking is the worker that receives items from the queue. For some
queues, the call to add a message to this queue is tracked as a dependency. However, the high-level operation
that describes message processing is not automatically collected.
Let's see how such operations could be tracked.
On a high level, the task is to create RequestTelemetry and set known properties. After the operation is finished,
you track the telemetry. The following example demonstrates this task.
HTTP request in Owin self-hosted app
In this example, trace context is propagated according to the HTTP Protocol for Correlation. You should expect to
receive headers that are described there.
public class ApplicationInsightsMiddleware : OwinMiddleware
{
// you may create a new TelemetryConfiguration instance, reuse one you already have
// or fetch the instance created by Application Insights SDK.
private readonly TelemetryConfiguration telemetryConfiguration = TelemetryConfiguration.CreateDefault();
private readonly TelemetryClient telemetryClient = new TelemetryClient(telemetryConfiguration);
public ApplicationInsightsMiddleware(OwinMiddleware next) : base(next) {}
public override async Task Invoke(IOwinContext context)

{
// Let's create and start RequestTelemetry.
var requestTelemetry = new RequestTelemetry
{
Name = $"{context.Request.Method} {context.Request.Uri.GetLeftPart(UriPartial.Path)}"
};
// If there is a Request-Id received from the upstream service, set the telemetry context
accordingly.
if (context.Request.Headers.ContainsKey("Request-Id"))
{
var requestId = context.Request.Headers.Get("Request-Id");
// Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
requestTelemetry.Context.Operation.Id = GetOperationId(requestId);
requestTelemetry.Context.Operation.ParentId = requestId;
}
// StartOperation is a helper method that allows correlation of

// current operations with nested operations/telemetry
// and initializes start time and duration on telemetry items.
var operation = telemetryClient.StartOperation(requestTelemetry);
// Process the request.

try
{
await Next.Invoke(context);
}
catch (Exception e)
{
requestTelemetry.Success = false;
telemetryClient.TrackException(e);
throw;
}
finally
{
// Update status code and success as appropriate.
if (context.Response != null)
{
requestTelemetry.ResponseCode = context.Response.StatusCode.ToString();
requestTelemetry.Success = context.Response.StatusCode >= 200 && context.Response.StatusCode
<= 299;
}
else
{
requestTelemetry.Success = false;
}
// Now it's time to stop the operation (and track telemetry).

}
}
public static string GetOperationId(string id)

{
// Returns the root ID from the '|' to the first '.' if any.
int rootEnd = id.IndexOf('.');
if (rootEnd < 0)
rootEnd = id.Length;
int rootStart = id[0] == '|' ? 1 : 0;
return id.Substring(rootStart, rootEnd - rootStart);
}
}
The HTTP Protocol for Correlation also declares the Correlation-Context header. However, it's omitted here for
simplicity.
Queue instrumentation
While there are W3C Trace Context and HTTP Protocol for Correlation to pass correlation details with HTTP
request, every queue protocol has to define how the same details are passed along the queue message. Some
queue protocols (such as AMQP ) allow passing additional metadata and some others (such Azure Storage
Queue) require the context to be encoded into the message payload.
NOTE
Cross-component tracing is not supported for queues yet With HTTP, if your producer and consumer send
telemetry to different Application Insights resources, Transaction Diagnostics Experience and Application Map show
transactions and map end-to-end. In case of queues this is not supported yet.
Service Bus Queue

Application Insights tracks Service Bus Messaging calls with the new Microsoft Azure ServiceBus Client for .NET
version 3.0.0 and higher. If you use message handler pattern to process messages, you are done: all Service Bus
calls done by your service are automatically tracked and correlated with other telemetry items. Refer to the
Service Bus client tracing with Microsoft Application Insights if you manually process messages.
If you use WindowsAzure.ServiceBus package, read further - following examples demonstrate how to track (and
correlate) calls to the Service Bus as Service Bus queue uses AMQP protocol and Application Insights doesn't
automatically track queue operations. Correlation identifiers are passed in the message properties.
Enqueue
public async Task Enqueue(string payload)
{
// StartOperation is a helper method that initializes the telemetry item
// and allows correlation of this operation with its parent and children.
var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queueName);
operation.Telemetry.Type = "Azure Service Bus";

operation.Telemetry.Data = "Enqueue " + queueName;
var message = new BrokeredMessage(payload);

// Service Bus queue allows the property bag to pass along with the message.
// We will use them to pass our correlation identifiers (and other context)
// to the consumer.
message.Properties.Add("ParentId", operation.Telemetry.Id);
message.Properties.Add("RootId", operation.Telemetry.Context.Operation.Id);
try
{
await queue.SendAsync(message);
// Set operation.Telemetry Success and ResponseCode here.

operation.Telemetry.Success = true;
}
catch (Exception e)
{
// Set operation.Telemetry Success and ResponseCode here.
operation.Telemetry.Success = false;
throw;
}
finally
{
}
}
Process
public async Task Process(BrokeredMessage message)
{
// After the message is taken from the queue, create RequestTelemetry to track its processing.
// It might also make sense to get the name from the message.
RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
var rootId = message.Properties["RootId"].ToString();

var parentId = message.Properties["ParentId"].ToString();
// Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
requestTelemetry.Context.Operation.Id = rootId;
requestTelemetry.Context.Operation.ParentId = parentId;
try
{
await ProcessMessage();
}
catch (Exception e)
{
throw;
}
finally
{
}
}
Azure Storage queue

The following example shows how to track the Azure Storage queue operations and correlate telemetry between
the producer, the consumer, and Azure Storage.
The Storage queue has an HTTP API. All calls to the queue are tracked by the Application Insights Dependency
Collector for HTTP requests. It is configured by default on ASP.NET and ASP.NET Core applications, with other
kinds of applicaiton, you can refer to console applications documentation
You also might want to correlate the Application Insights operation ID with the Storage request ID. For
information on how to set and get a Storage request client and a server request ID, see Monitor, diagnose, and
troubleshoot Azure Storage.
Enqueue
Because Storage queues support the HTTP API, all operations with the queue are automatically tracked by
Application Insights. In many cases, this instrumentation should be enough. However, to correlate traces on the
consumer side with producer traces, you must pass some correlation context similarly to how we do it in the
HTTP Protocol for Correlation.
This example shows how to track the Enqueue operation. You can:
Correlate retries (if any): They all have one common parent that's the Enqueue operation. Otherwise, they're
tracked as children of the incoming request. If there are multiple logical requests to the queue, it might be
difficult to find which call resulted in retries.
Correlate Storage logs (if and when needed): They're correlated with Application Insights telemetry.
The Enqueue operation is the child of a parent operation (for example, an incoming HTTP request). The HTTP
dependency call is the child of the Enqueue operation and the grandchild of the incoming request:
public async Task Enqueue(CloudQueue queue, string message)
{
var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queue.Name);
operation.Telemetry.Type = "Azure queue";
operation.Telemetry.Data = "Enqueue " + queue.Name;
// MessagePayload represents your custom message and also serializes correlation identifiers into
payload.
// For example, if you choose to pass payload serialized to JSON, it might look like
// {'RootId' : 'some-id', 'ParentId' : '|some-id.1.2.3.', 'message' : 'your message to process'}
var jsonPayload = JsonConvert.SerializeObject(new MessagePayload
{
RootId = operation.Telemetry.Context.Operation.Id,
ParentId = operation.Telemetry.Id,
Payload = message
});
CloudQueueMessage queueMessage = new CloudQueueMessage(jsonPayload);
// Add operation.Telemetry.Id to the OperationContext to correlate Storage logs and Application Insights
telemetry.
OperationContext context = new OperationContext { ClientRequestID = operation.Telemetry.Id};
try
{
await queue.AddMessageAsync(queueMessage, null, null, new QueueRequestOptions(), context);
}
catch (StorageException e)
{
operation.Telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
operation.Telemetry.Success = false;
operation.Telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
}
finally
{
}
}
To reduce the amount of telemetry your application reports or if you don't want to track the Enqueue operation
for other reasons, use the Activity API directly:
Create (and start) a new Activity instead of starting the Application Insights operation. You do not need to
assign any properties on it except the operation name.
Serialize yourActivity.Id into the message payload instead of operation.Telemetry.Id . You can also use
Activity.Current.Id .
Dequeue
Similarly to Enqueue , an actual HTTP request to the Storage queue is automatically tracked by Application
Insights. However, the Enqueue operation presumably happens in the parent context, such as an incoming
request context. Application Insights SDKs automatically correlate such an operation (and its HTTP part) with the
parent request and other telemetry reported in the same scope.
The Dequeue operation is tricky. The Application Insights SDK automatically tracks HTTP requests. However, it
doesn't know the correlation context until the message is parsed. It's not possible to correlate the HTTP request
to get the message with the rest of the telemetry especially when more than one message is received.
public async Task<MessagePayload> Dequeue(CloudQueue queue)
{
var operation = telemetryClient.StartOperation<DependencyTelemetry>("dequeue " + queue.Name);
operation.Telemetry.Type = "Azure queue";
operation.Telemetry.Data = "Dequeue " + queue.Name;
try
{
var message = await queue.GetMessageAsync();
}
catch (StorageException e)
{
telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
telemetry.Success = false;
telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
}
finally
{
}
return null;
}
Process
In the following example, an incoming message is tracked in a manner similarly to incoming HTTP request:
public async Task Process(MessagePayload message)

{
// After the message is dequeued from the queue, create RequestTelemetry to track its processing.
RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
// It might also make sense to get the name from the message.
requestTelemetry.Context.Operation.Id = message.RootId;
requestTelemetry.Context.Operation.ParentId = message.ParentId;
try
{
await ProcessMessage();
}
catch (Exception e)
{
throw;
}
finally
{
}
}
Similarly, other queue operations can be instrumented. A peek operation should be instrumented in a similar way
as a dequeue operation. Instrumenting queue management operations isn't necessary. Application Insights tracks
operations such as HTTP, and in most cases, it's enough.
When you instrument message deletion, make sure you set the operation (correlation) identifiers. Alternatively,
you can use the Activity API. Then you don't need to set operation identifiers on the telemetry items because
Application Insights SDK does it for you:
Create a new Activity after you've got an item from the queue.
Use Activity.SetParentId(message.ParentId) to correlate consumer and producer logs.
Start the Activity .
Track dequeue, process, and delete operations by using Start/StopOperation helpers. Do it from the same
asynchronous control flow (execution context). In this way, they're correlated properly.
Stop the Activity .
Use Start/StopOperation , or call Track telemetry manually.
Dependency Types
Application Insights uses dependency type to cusomize UI experiences. For queues it recognizes following types
of DependencyTelemetry that improve Transaction diagnostics experience:
Azure queue for Azure Storage Queues
Azure Event Hubs for Azure Event Hubs
Azure Service Bus for Azure Service Bus
Batch processing
With some queues, you can dequeue multiple messages with one request. Processing such messages is
presumably independent and belongs to the different logical operations. It's not possible to correlate the
Dequeue operation to a particular message being processed.
Each message should be processed in its own asynchronous control flow. For more information, see the
Outgoing dependencies tracking section.
Long-running background tasks

Some applications start long-running operations that might be caused by user requests. From the
tracing/instrumentation perspective, it's not different from request or dependency instrumentation:
async Task BackgroundTask()

{
var operation = telemetryClient.StartOperation<DependencyTelemetry>(taskName);
operation.Telemetry.Type = "Background";
try
{
int progress = 0;
while (progress < 100)
{
// Process the task.
telemetryClient.TrackTrace($"done {progress++}%");
}
}
catch (Exception e)
{
throw;
}
finally
{
}
}
In this example, telemetryClient.StartOperation creates DependencyTelemetry and fills the correlation context.
Let's say you have a parent operation that was created by incoming requests that scheduled the operation. As
long as BackgroundTask starts in the same asynchronous control flow as an incoming request, it's correlated with
that parent operation. BackgroundTask and all nested telemetry items are automatically correlated with the
request that caused it, even after the request ends.
When the task starts from the background thread that doesn't have any operation ( Activity ) associated with it,
BackgroundTask doesn't have any parent. However, it can have nested operations. All telemetry items reported
from the task are correlated to the DependencyTelemetry created in BackgroundTask .
Outgoing dependencies tracking

You can track your own dependency kind or an operation that's not supported by Application Insights.
The Enqueue method in the Service Bus queue or the Storage queue can serve as examples for such custom
tracking.
The general approach for custom dependency tracking is to:
Call the TelemetryClient.StartOperation (extension) method that fills the DependencyTelemetry properties that
are needed for correlation and some other properties (start time stamp, duration).
Set other custom properties on the DependencyTelemetry , such as the name and any other context you need.
Make a dependency call and wait for it.
Stop the operation with StopOperation when it's finished.
Handle exceptions.
public async Task RunMyTaskAsync()

{
using (var operation = telemetryClient.StartOperation<DependencyTelemetry>("task 1"))
{
try
{
var myTask = await StartMyTaskAsync();
}
catch(...)
{
}
}
}
Disposing operation causes operation to be stopped, so you may do it instead of calling StopOperation .
Warning: in some cases unhanded exception may prevent finally to be called so operations may not be
tracked.
Parallel operations processing and tracking
StopOperation only stops the operation that was started. If the current running operation doesn't match the one
you want to stop, StopOperation does nothing. This situation might happen if you start multiple operations in
parallel in the same execution context:
var firstOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 1");
var firstTask = RunMyTaskAsync();
var secondOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 2");

var secondTask = RunMyTaskAsync();
await firstTask;
// FAILURE!!! This will do nothing and will not report telemetry for the first operation
// as currently secondOperation is active.
telemetryClient.StopOperation(firstOperation);
await secondTask;
Make sure you always call StartOperation and process operation in the same async method to isolate
operations running in parallel. If operation is synchronous (or not async), wrap process and track with Task.Run :
public void RunMyTask(string name)

{
using (var operation = telemetryClient.StartOperation<DependencyTelemetry>(name))
{
Process();
}
}
public async Task RunAllTasks()

{
var task1 = Task.Run(() => RunMyTask("task 1"));
var task2 = Task.Run(() => RunMyTask("task 2"));
await Task.WhenAll(task1, task2);

}
ApplicationInsights operations vs System.Diagnostics.Activity

System.Diagnostics.Activity represents the distributed tracing context and is used by frameworks and libraries
to create and propagate context inside and outside of the process and correlate telemetry items. Activity works
together with System.Diagnostics.DiagnosticSource - the notification mechanism between the framework/library
to notify about interesting events (incoming or outgoing requests, exceptions, etc).
Activities are first-class citizens in Application Insights and automatic dependency and request collection relies
heavily on them along with DiagnosticSource events. If you create Activity in your application - it would not
result in Application Insights telemetry being created. Application Insights needs to receive DiagnosticSource
events and know the events names and payloads to translate Activity into telemetry.
Each Application Insights operation (request or dependency) involves Activity - when StartOperation is called,
it creates Activity underneath. StartOperation is the recommended way to track request or dependency
telemetries manually and ensure everything is correlated.
Next steps
Learn the basics of telemetry correlation in Application Insights.
Check out how correlated data powers Transaction Diagnostics Experience and Application Map.
See the data model for Application Insights types and data model.
Report custom events and metrics to Application Insights.
Check out standard configuration for context properties collection.
Check the System.Diagnostics.Activity User Guide to see how we correlate telemetry.
Automate custom reports with Azure Application
Insights data
Periodical reports help keep a team informed on how their business critical services are doing. Developers,
DevOps/SRE teams, and their managers can be productive with automated reports reliably delivering insights
without requiring everyone to sign in the portal. Such reports can also help identify gradual increases in latencies,
load or failure rates that may not trigger any alert rules.
Each enterprise has its unique reporting needs, such as:
Specific percentile aggregations of metrics, or custom metrics in a report.
Have different reports for daily, weekly, and monthly roll-ups of data for different audiences.
Segmentation by custom attributes like region, or environment.
Group some AI resources together in a single report, even if they may be in different subscriptions or resource
groups etc.
Separate reports containing sensitive metrics sent to selective audience.
Reports to stakeholders who may not have access to the portal resources.
NOTE
The weekly Application Insights digest email did not allow any customization, and will be discontinued in favor of the custom
options listed below. The last weekly digest email will be sent on June 11, 2018. Please configure one of the following options
to get similar custom reports (use the query suggested below).
To automate custom report emails

You can programmatically query Application Insights data to generate custom reports on a schedule. The following
options can help you get started quickly:
Automate reports with Microsoft Flow
Automate reports with Logic Apps
Use the "Application Insights scheduled digest" Azure function template in the Monitoring scenario. This
function uses SendGrid to deliver the email.
Sample query for a weekly digest email
The following query shows joining across multiple datasets for a weekly digest email like report. Customize it as
required and use it with any of the options listed above to automate a weekly report.
let period=7d;
requests
| where timestamp > ago(period)
| summarize Row = 1, TotalRequests = sum(itemCount), FailedRequests = sum(toint(success == 'False')),
RequestsDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
| join (
dependencies
| summarize Row = 1, TotalDependencies = sum(itemCount), FailedDependencies = sum(success == 'False'),
DependenciesDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
) on Row | join (
pageViews
| summarize Row = 1, TotalViews = sum(itemCount)
) on Row | join (
exceptions
| summarize Row = 1, TotalExceptions = sum(itemCount)
) on Row | join (
availabilityResults
| summarize Row = 1, OverallAvailability = iff(isnan(avg(toint(success))), '------',
tostring(toint(avg(toint(success)) * 10000) / 100.0)),
AvailabilityDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
) on Row
| project TotalRequests, FailedRequests, RequestsDuration, TotalDependencies, FailedDependencies,
DependenciesDuration, TotalViews, TotalExceptions, OverallAvailability, AvailabilityDuration
Application Insights scheduled digest report

1. From the Azure portal, select Create a Resource > Compute > Function App.
2. Enter appropriate info for your app and select Create. (Application Insights On is required only if you want
to monitor your new Function App with Application Insights)
3. Once your new Function App has completed deployment, select Go to resource.
4. Select New function.
5. Select the Application Insights scheduled digest template.
NOTE
By default, function apps are created with runtime version 2.x. You must target Azure Functions runtime version 1.x
to use the Application Insights scheduled digest template.
6. Enter an appropriate recipient e-mail address for your report and select Create.
7. Select your Function App > Platform features > Application settings.
8. Create three new application settings with appropriate corresponding values AI_APP_ID , AI_APP_KEY , and
SendGridAPI . Select Save.
(The AI_ values can be found under API Access for the Application Insights Resource you want to report on.
If you don't have an Application Insights API Key, there is the option to Create API Key.)
AI_APP_ID = Application ID
AI_APP_KEY = API Key
SendGridAPI =SendGrid API Key
NOTE
If you don't have a SendGrid account you can create one. SendGrid's documentation for Azure Functions is
here. If just want a minimal explanation of how to setup SendGrid and generate an API key one is provided at
the end of this article.
9. Select Integrate and under Outputs click SendGrid ($return).
10. Under the SendGridAPI Key App Setting, select your newly created App Setting for SendGridAPI.
11. Run and test your Function App.
12. Check your e-mail to confirm that the message was sent/received successfully.
SendGrid with Azure

These steps only apply if you don't already have a SendGrid account configured.
1. From the Azure portal select Create a resource search for SendGrid Email Delivery > Click Create >
and fill out the SendGrid specific create instructions.
2. Once created under SendGrid Accounts select Manage.
3. This will launch SendGrid's site. Select Settings > API Keys.
4. Create an API Key > choose Create & View (Please review SendGrid's documentation on restricted access
to determine what level of permissions is appropriate for your API Key. Full Access is selected here for
example purposes only.)
5. Copy the entire key, this value is what you need in your Function App settings as the value for SendGridAPI
Next steps
Learn more about creating Analytics queries.
Learn more about programmatically querying Application Insights data
Learn more about Logic Apps.
Learn more about Microsoft Flow.
Diagnose exceptions in your web apps with
Exceptions in your live web app are reported by Application Insights. You can correlate failed requests with
exceptions and other events at both the client and server, so that you can quickly diagnose the causes.
Set up exception reporting

To have exceptions reported from your server app:
Azure web apps: Add the Application Insights Extension
Azure VM and Azure virtual machine scale set IIS -hosted apps: Add the Application Monitoring
Extension
Install Application Insights SDK in your app code, or
IIS web servers: Run Application Insights Agent; or
Java web apps: Install the Java agent
Install the JavaScript snippet in your web pages to catch browser exceptions.
In some application frameworks or with some settings, you need to take some extra steps to catch more
exceptions:
Web forms
MVC
Web API 1.*
Web API 2.*
WCF
Diagnosing exceptions using Visual Studio

Open the app solution in Visual Studio to help with debugging.
Run the app, either on your server or on your development machine by using F5.
Open the Application Insights Search window in Visual Studio, and set it to display events from your app.
While you're debugging, you can do this just by clicking the Application Insights button.
Notice that you can filter the report to show just exceptions.
No exceptions showing? See Capture exceptions.
Click an exception report to show its stack trace. Click a line reference in the stack trace, to open the relevant
code file.
In the code, notice that CodeLens shows data about the exceptions:
Diagnosing failures using the Azure portal

Application Insights comes with a curated APM experience to help you diagnose failures in your monitored
applications. To start, click on the Failures option in the Application Insights resource menu located in the
Investigate section. You should see a full-screen view that shows you the failure rate trends for your requests,
how many of them are failing, and how many users are impacted. On the right, you'll see some of the most
useful distributions specific to the selected failing operation, including top three response codes, top three
exception types, and top three failing dependency types.
In a single click, you can then review representative samples for each of these subsets of operations. In
particular, to diagnose exceptions, you can click on the count of a particular exception to be presented with the
End-to-end transaction details tab, such as this one:
Alternatively, instead of looking at exceptions of a specific failing operation, you can start from the overall
view of exceptions, by switching to the Exceptions tab at the top. Here you can see all the exceptions collected
for your monitored app.
No exceptions showing? See Capture exceptions.
Custom tracing and log data

To get diagnostic data specific to your app, you can insert code to send your own telemetry data. This
displayed in diagnostic search alongside the request, page view, and other automatically collected data.
You have several options:
TrackEvent() is typically used for monitoring usage patterns, but the data it sends also appears under
Custom Events in diagnostic search. Events are named, and can carry string properties and numeric metrics
on which you can filter your diagnostic searches.
TrackTrace() lets you send longer data such as POST information.
TrackException() sends stack traces. More about exceptions.
If you already use a logging framework like Log4Net or NLog, you can capture those logs and see them in
diagnostic search alongside request and exception data.
To see these events, open Search from the left menu, select the drop-down menu Event types, and then
choose Custom Event, Trace, or Exception.
NOTE
If your app generates a lot of telemetry, the adaptive sampling module will automatically reduce the volume that is sent
to the portal by sending only a representative fraction of events. Events that are part of the same operation will be
selected or deselected as a group, so that you can navigate between related events. Learn about sampling.
How to see request POST data

Request details don't include the data sent to your app in a POST call. To have this data reported:
Install the SDK in your application project.
Insert code in your application to call Microsoft.ApplicationInsights.TrackTrace(). Send the POST data in the
message parameter. There is a limit to the permitted size, so you should try to send just the essential data.
When you investigate a failed request, find the associated traces.
Capturing exceptions and related diagnostic data

At first, you won't see in the portal all the exceptions that cause failures in your app. You'll see any browser
exceptions (if you're using the JavaScript SDK in your web pages). But most server exceptions are caught by
IIS and you have to write a bit of code to see them.
You can:
Log exceptions explicitly by inserting code in exception handlers to report the exceptions.
Capture exceptions automatically by configuring your ASP.NET framework. The necessary additions
are different for different types of framework.
Reporting exceptions explicitly

The simplest way is to insert a call to TrackException() in an exception handler.
try
{ ...
}
catch (ex)
{
appInsights.trackException(ex, "handler loc",
{Game: currentGame.Name,
State: currentGame.State.ToString()});
}
var telemetry = new TelemetryClient();

...
try
{ ...
}
{
// Set up some properties:
{{"Game", currentGame.Name}};
var measurements = new Dictionary <string, double>

{{"Users", currentGame.Users.Count}};
// Send the exception telemetry:

telemetry.TrackException(ex, properties, measurements);
}
Dim telemetry = New TelemetryClient

...
Try
...
Catch ex as Exception
' Set up some properties:
Dim properties = New Dictionary (Of String, String)
properties.Add("Game", currentGame.Name)
Dim measurements = New Dictionary (Of String, Double)

measurements.Add("Users", currentGame.Users.Count)
' Send the exception telemetry:

telemetry.TrackException(ex, properties, measurements)
End Try
The properties and measurements parameters are optional, but are useful for filtering and adding extra
information. For example, if you have an app that can run several games, you could find all the exception
reports related to a particular game. You can add as many items as you like to each dictionary.
Browser exceptions
Most browser exceptions are reported.
If your web page includes script files from content delivery networks or other domains, ensure your script tag
has the attribute crossorigin="anonymous" , and that the server sends CORS headers. This will allow you to get
a stack trace and detail for unhandled JavaScript exceptions from these resources.
Reuse your telemetry client

NOTE
TelemetryClient is recommended to be instantiated once and re-used throughout the life of an application.
Below is an example using TelemetryClient correctly.
public class GoodController : ApiController

{
// OK
private static readonly TelemetryClient telemetryClient;
static GoodController()
{
telemetryClient = new TelemetryClient();
}
}
Web forms
For web forms, the HTTP Module will be able to collect the exceptions when there are no redirects configured
with CustomErrors.
But if you have active redirects, add the following lines to the Application_Error function in Global.asax.cs. (Add
a Global.asax file if you don't already have one.)
void Application_Error(object sender, EventArgs e)

{
if (HttpContext.Current.IsCustomErrorEnabled && Server.GetLastError () != null)
{
var ai = new TelemetryClient(); // or re-use an existing instance
ai.TrackException(Server.GetLastError());
}
}
MVC
Starting with Application Insights Web SDK version 2.6 (beta3 and later), Application Insights collects
unhandled exceptions thrown in the MVC 5+ controllers methods automatically. If you have previously added
a custom handler to track such exceptions (as described in following examples), you may remove it to prevent
double tracking of exceptions.
There are a number of cases that the exception filters cannot handle. For example:
Exceptions thrown from controller constructors.
Exceptions thrown from message handlers.
Exceptions thrown during routing.
Exceptions thrown during response content serialization.
Exception thrown during application start-up.
Exception thrown in background tasks.
All exceptions handled by application still need to be tracked manually. Unhandled exceptions originating from
controllers typically result in 500 "Internal Server Error" response. If such response is manually constructed as
a result of handled exception (or no exception at all) it is tracked in corresponding request telemetry with
ResultCode 500, however Application Insights SDK is unable to track corresponding exception.
Prior versions support

If you use MVC 4 (and prior) of Application Insights Web SDK 2.5 (and prior), refer to the following examples
to track exceptions.
If the CustomErrors configuration is Off , then exceptions will be available for the HTTP Module to collect.
However, if it is RemoteOnly (default), or On , then the exception will be cleared and not available for
Application Insights to automatically collect. You can fix that by overriding the
System.Web.Mvc.HandleErrorAttribute class, and applying the overridden class as shown for the different
MVC versions below (GitHub source):
using System;
using System.Web.Mvc;
namespace MVC2App.Controllers
{
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple =
true)]
public class AiHandleErrorAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
if (filterContext != null && filterContext.HttpContext != null && filterContext.Exception !=
null)
{
//If customError is Off, then AI HTTPModule will report the exception
if (filterContext.HttpContext.IsCustomErrorEnabled)
{ //or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(filterContext.Exception);
}
}
base.OnException(filterContext);
}
}
}
MVC 2
Replace the HandleError attribute with your new attribute in your controllers.
namespace MVC2App.Controllers
{
[AiHandleError]
public class HomeController : Controller
{
...
Sample
MVC 3
Register AiHandleErrorAttribute as a global filter in Global.asax.cs:
public class MyMvcApplication : System.Web.HttpApplication

{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new AiHandleErrorAttribute());
}
...
Sample
MVC 4, MVC5
Register AiHandleErrorAttribute as a global filter in FilterConfig.cs:
public class FilterConfig

{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
// Default replaced with the override to track unhandled exceptions
filters.Add(new AiHandleErrorAttribute());
}
}
Sample
Web API
Starting with Application Insights Web SDK version 2.6 (beta3 and later), Application Insights collects
unhandled exceptions thrown in the controller methods automatically for WebAPI 2+. If you have previously
added a custom handler to track such exceptions (as described in following examples), you may remove it to
prevent double tracking of exceptions.
There are a number of cases that the exception filters cannot handle. For example:
Exceptions thrown from controller constructors.
Exceptions thrown from message handlers.
Exceptions thrown during routing.
Exceptions thrown during response content serialization.
Exception thrown during application start-up.
Exception thrown in background tasks.
All exceptions handled by application still need to be tracked manually. Unhandled exceptions originating from
controllers typically result in 500 "Internal Server Error" response. If such response is manually constructed as
a result of handled exception (or no exception at all) it is tracked in a corresponding request telemetry with
ResultCode 500, however Application Insights SDK is unable to track corresponding exception.
Prior versions support

If you use WebAPI 1 (and prior) of Application Insights Web SDK 2.5 (and prior), refer to the following
examples to track exceptions.
Web API 1.x
Override System.Web.Http.Filters.ExceptionFilterAttribute:
using System.Web.Http.Filters;
namespace WebAPI.App_Start
{
public class AiExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
if (actionExecutedContext != null && actionExecutedContext.Exception != null)
{ //or reuse instance (recommended!). see note above
ai.TrackException(actionExecutedContext.Exception);
}
base.OnException(actionExecutedContext);
}
}
}
You could add this overridden attribute to specific controllers, or add it to the global filter configuration in the
WebApiConfig class:
using WebApi1.x.App_Start;
namespace WebApi1.x
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(name: "DefaultApi", routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
...
config.EnableSystemDiagnosticsTracing();
// Capture exceptions for Application Insights:

config.Filters.Add(new AiExceptionFilterAttribute());
}
}
}
Sample
Web API 2.x
Add an implementation of IExceptionLogger:
using System.Web.Http.ExceptionHandling;
namespace ProductsAppPureWebAPI.App_Start
{
public class AiExceptionLogger : ExceptionLogger
{
public override void Log(ExceptionLoggerContext context)
{
if (context !=null && context.Exception != null)
{//or reuse instance (recommended!). see note above
ai.TrackException(context.Exception);
}
base.Log(context);
}
}
}
Add this to the services in WebApiConfig:
using System.Web.Http.ExceptionHandling;
using ProductsAppPureWebAPI.App_Start;
namespace WebApi2WithMVC
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// Web API configuration and services
// Web API routes

config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.Services.Add(typeof(IExceptionLogger), new AiExceptionLogger());
}
}
}
Sample
As alternatives, you could:
1. Replace the only ExceptionHandler with a custom implementation of IExceptionHandler. This is only called
when the framework is still able to choose which response message to send (not when the connection is
aborted for instance)
2. Exception Filters (as described in the section on Web API 1.x controllers above) - not called in all cases.
WCF
Add a class that extends Attribute and implements IErrorHandler and IServiceBehavior.
using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Web;
namespace WcfService4.ErrorHandling
{
public class AiLogExceptionAttribute : Attribute, IErrorHandler, IServiceBehavior
{
public void AddBindingParameters(ServiceDescription serviceDescription,
System.ServiceModel.ServiceHostBase serviceHostBase,
System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints,
System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
{
}
public void ApplyDispatchBehavior(ServiceDescription serviceDescription,

System.ServiceModel.ServiceHostBase serviceHostBase)
{
foreach (ChannelDispatcher disp in serviceHostBase.ChannelDispatchers)
{
disp.ErrorHandlers.Add(this);
}
}
public void Validate(ServiceDescription serviceDescription,

System.ServiceModel.ServiceHostBase serviceHostBase)
{
}
bool IErrorHandler.HandleError(Exception error)

{//or reuse instance (recommended!). see note above
ai.TrackException(error);
return false;
}
void IErrorHandler.ProvideFault(Exception error,

System.ServiceModel.Channels.MessageVersion version,
ref System.ServiceModel.Channels.Message fault)
{
}
}
}
Add the attribute to the service implementations:
namespace WcfService4
{
[AiLogException]
public class Service1 : IService1
{
...
Sample
Exception performance counters

If you have installed the Application Insights Agent on your server, you can get a chart of the exceptions rate,
measured by .NET. This includes both handled and unhandled .NET exceptions.
Open a Metric Explorer tab, add a new chart, and select Exception rate, listed under Performance Counters.
The .NET framework calculates the rate by counting the number of exceptions in an interval and dividing by
the length of the interval.
This is different from the 'Exceptions' count calculated by the Application Insights portal counting
TrackException reports. The sampling intervals are different, and the SDK doesn't send TrackException reports
for all handled and unhandled exceptions.
Next steps
Monitor REST, SQL, and other calls to dependencies
Monitor page load times, browser exceptions, and AJAX calls
Monitor performance counters
Explore .NET/.NET Core trace logs in Application
Insights
Send diagnostic tracing logs for your ASP.NET/ASP.NET Core application from ILogger, NLog, log4Net, or
System.Diagnostics.Trace to Azure Application Insights. You can then explore and search them. Those logs are
merged with the other log files from your application, so you can identify traces that are associated with each
user request and correlate them with other events and exception reports.
NOTE
Do you need the log-capture module? It's a useful adapter for third-party loggers. But if you aren't already using NLog,
log4Net, or System.Diagnostics.Trace, consider just calling Application Insights TrackTrace() directly.
Install logging on your app

Install your chosen logging framework in your project, which should result in an entry in app.config or
web.config.
<configuration>
<system.diagnostics>
<trace>
<listeners>
<add name="myAppInsightsListener"
type="Microsoft.ApplicationInsights.TraceListener.ApplicationInsightsTraceListener,
Microsoft.ApplicationInsights.TraceListener" />
</listeners>
</trace>
</system.diagnostics>
</configuration>
Configure Application Insights to collect logs

Add Application Insights to your project if you haven't done that yet. You'll see an option to include the log
collector.
Or right-click your project in Solution Explorer to Configure Application Insights. Select the Configure
trace collection option.
NOTE
No Application Insights menu or log collector option? Try Troubleshooting.
Manual installation
Use this method if your project type isn't supported by the Application Insights installer (for example a
Windows desktop project).
1. If you plan to use log4Net or NLog, install it in your project.
2. In Solution Explorer, right-click your project, and select Manage NuGet Packages.
3. Search for "Application Insights."
4. Select one of the following packages:
For ILogger: Microsoft.Extensions.Logging.ApplicationInsights
For NLog: Microsoft.ApplicationInsights.NLogTarget
For Log4Net: Microsoft.ApplicationInsights.Log4NetAppender
For System.Diagnostics: Microsoft.ApplicationInsights.TraceListener
Microsoft.ApplicationInsights.DiagnosticSourceListener nuget v2.11.0
Microsoft.ApplicationInsights.EtwCollector
Microsoft.ApplicationInsights.EventSourceListener
The NuGet package installs the necessary assemblies and modifies web.config or app.config if that's applicable.
ILogger
For examples of using the Application Insights ILogger implementation with console applications and
ASP.NET Core, see ApplicationInsightsLoggerProvider for .NET Core ILogger logs.
Insert diagnostic log calls

If you use System.Diagnostics.Trace, a typical call would be:
System.Diagnostics.Trace.TraceWarning("Slow response - database01");
If you prefer log4net or NLog, use:
logger.Warn("Slow response - database01");
Use EventSource events

You can configure System.Diagnostics.Tracing.EventSource events to be sent to Application Insights as traces.
First, install the Microsoft.ApplicationInsights.EventSourceListener NuGet package. Then edit the
TelemetryModules section of the ApplicationInsights.config file.
<Add Type="Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule,
Microsoft.ApplicationInsights.EventSourceListener">
<Sources>
<Add Name="MyCompany" Level="Verbose" />
</Sources>
</Add>
For each source, you can set the following parameters:

Name specifies the name of the EventSource to collect.
Level specifies the logging level to collect: Critical, Error, Informational, LogAlways, Verbose, or Warning.
Keywords (optional) specify the integer value of keyword combinations to use.
Use DiagnosticSource events

You can configure System.Diagnostics.DiagnosticSource events to be sent to Application Insights as traces.
First, install the Microsoft.ApplicationInsights.DiagnosticSourceListener NuGet package. Then edit the
"TelemetryModules" section of the ApplicationInsights.config file.
<Add Type="Microsoft.ApplicationInsights.DiagnosticSourceListener.DiagnosticSourceTelemetryModule,
Microsoft.ApplicationInsights.DiagnosticSourceListener">
<Sources>
<Add Name="MyDiagnosticSourceName" />
</Sources>
</Add>
For each DiagnosticSource you want to trace, add an entry with the Name attribute set to the name of your
DiagnosticSource.
Use ETW events

You can configure Event Tracing for Windows (ETW ) events to be sent to Application Insights as traces. First,
install the Microsoft.ApplicationInsights.EtwCollector NuGet package. Then edit the "TelemetryModules"
section of the ApplicationInsights.config file.
NOTE
ETW events can only be collected if the process that hosts the SDK runs under an identity that's a member of
Performance Log Users or Administrators.
<Add Type="Microsoft.ApplicationInsights.EtwCollector.EtwCollectorTelemetryModule,
Microsoft.ApplicationInsights.EtwCollector">
<Sources>
<Add ProviderName="MyCompanyEventSourceName" Level="Verbose" />
</Sources>
</Add>
For each source, you can set the following parameters:

ProviderName is the name of the ETW provider to collect.
ProviderGuid specifies the GUID of the ETW provider to collect. It can be used instead of ProviderName .
Level sets the logging level to collect. It can be Critical, Error, Informational, LogAlways, Verbose, or
Warning.
Keywords (optional) set the integer value of keyword combinations to use.
Use the Trace API directly

You can call the Application Insights trace API directly. The logging adapters use this API.
For example:

telemetry.TrackTrace("Slow response - database01");
An advantage of TrackTrace is that you can put relatively long data in the message. For example, you can
encode POST data there.
You can also add a severity level to your message. And, like other telemetry, you can add property values to
help filter or search for different sets of traces. For example:
telemetry.TrackTrace("Slow database response",
SeverityLevel.Warning,
new Dictionary<string,string> { {"database", db.ID} });
This would enable you to easily filter out in Search all the messages of a particular severity level that relate to a
particular database.
Explore your logs

Run your app in debug mode or deploy it live.
In your app's overview pane in the Application Insights portal, select Search.
You can, for example:
Filter on log traces or on items with specific properties.
Inspect a specific item in detail.
Find other system log data that relates to the same user request (has the same OperationId).
Save the configuration of a page as a favorite.
NOTE
If your application sends a lot of data and you're using the Application Insights SDK for ASP.NET version 2.0.0-beta3 or
later, the adaptive sampling feature may operate and send only a portion of your telemetry. Learn more about
sampling.
Troubleshooting
How do I do this for Java?
Use the Java log adapters.
There's no Application Insights option on the project context menu
Make sure that Developer Analytics Tools is installed on the development machine. At Visual Studio Tools >
Extensions and Updates, look for Developer Analytics Tools. If it isn't on the Installed tab, open the
Online tab and install it.
This might be a project type that Devloper Analytics Tools doesn't support. Use manual installation.
There's no log adapter option in the configuration tool
Install the logging framework first.
If you're using System.Diagnostics.Trace, make sure that you have it configured in web.config.
Make sure that you have the latest version of Application Insights. In Visual Studio, go to Tools >
Extensions and Updates, and open the Updates tab. If Developer Analytics Tools is there, select it to
update it.
I get the "Instrumentation key cannot be empty" error message
You probably installed the logging adapter Nuget package without installing Application Insights. In Solution
Explorer, right-click ApplicationInsights.config, and select Update Application Insights. You'll be prompted to
sign in to Azure and create an Application Insights resource or reuse an existing one. That should fix the
problem.
I can see traces but not other events in diagnostic search
It can take a while for all the events and requests to get through the pipeline.
How much data is retained?
Several factors affect the amount of data that's retained. For more information, see the limits section of the
customer event metrics page.
I don't see some log entries that I expected
If your application sends voluminous amounts of data and you're using the Application Insights SDK for
ASP.NET version 2.0.0-beta3 or later, the adaptive sampling feature may operate and send only a portion of
your telemetry. Learn more about sampling.
Next steps
Diagnose failures and exceptions in ASP.NET
Learn more about Search
Set up availability and responsiveness tests
Troubleshooting
System performance counters in Application Insights
Windows provides a wide variety of performance counters such as CPU occupancy, memory, disk, and network
usage. You can also define your own performance counters. Performance counters collection is supported as long
as your application is running under IIS on an on-premises host, or virtual machine to which you have
administrative access. Though applications running as Azure Web Apps don't have direct access to performance
counters, a subset of available counters are collected by Application Insights.
View counters
The Metrics pane shows the default set of performance counters.
The current default counters that are configured to be collected for ASP.NET/ASP.NET Core web applications are:
% Process\Processor Time
% Process\Processor Time Normalized
Memory\Available Bytes
ASP.NET Requests/Sec
.NET CLR Exceptions Thrown / sec
ASP.NET ApplicationsRequest Execution Time
Process\Private Bytes
Process\IO Data Bytes/sec
ASP.NET Applications\Requests In Application Queue
Processor(_Total)\% Processor Time
Add counters
If the performance counter you want isn't included in the list of metrics, you can add it.
1. Find out what counters are available in your server by using this PowerShell command on the local server:
Get-Counter -ListSet *
(See Get-Counter .)
2. Open ApplicationInsights.config.
If you added Application Insights to your app during development, edit ApplicationInsights.config in
your project, and then redeploy it to your servers.
3. Edit the performance collector directive:
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule,
<Counters>
<Add PerformanceCounter="\Objects\Processes"/>
<Add PerformanceCounter="\Sales(photo)\# Items Sold" ReportAs="Photo sales"/>
</Counters>
</Add>
NOTE
ASP.NET Core applications do not have ApplicationInsights.config , and hence the above method is not valid for
ASP.NET Core Applications.
You can capture both standard counters and those you've implemented yourself. \Objects\Processes is an
example of a standard counter that is available on all Windows systems. \Sales(photo)\# Items Sold is an
example of a custom counter that might be implemented in a web service.
The format is \Category(instance)\Counter" , or for categories that don't have instances, just \Category\Counter .
ReportAs is required for counter names that do not match [a-zA-Z()/-_ \.]+ - that is, they contain characters
that are not in the following sets: letters, round brackets, forward slash, hyphen, underscore, space, dot.
If you specify an instance, it will be collected as a dimension "CounterInstanceName" of the reported metric.
Collecting performance counters in code for ASP.NET Web Applications or .NET/.NET Core Console
Applications
To collect system performance counters and send them to Application Insights, you can adapt the snippet below:
var perfCollectorModule = new PerformanceCollectorModule();

perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Process([replace-with-application-process-name])\Page Faults/sec", "PageFaultsPerfSec")));
perfCollectorModule.Initialize(TelemetryConfiguration.Active);
Or you can do the same thing with custom metrics you created:
var perfCollectorModule = new PerformanceCollectorModule();

perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Sales(photo)\# Items Sold", "Photo sales"));
perfCollectorModule.Initialize(TelemetryConfiguration.Active);
Collecting performance counters in code for ASP.NET Core Web Applications

Modify ConfigureServices method in your Startup.cs class as below.

{
// The following configures PerformanceCollectorModule.

services.ConfigureTelemetryModule<PerformanceCollectorModule>((module, o) =>
{
// the application process name could be "dotnet" for ASP.NET Core self-hosted applications.
module.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Process([replace-with-application-process-name])\Page Faults/sec", "DotnetPageFaultsPerfSec"));
});
}
Performance counters in Analytics

You can search and display performance counter reports in Analytics.
The performanceCounters schema exposes the category , counter name, and instance name of each
performance counter. In the telemetry for each application, you'll see only the counters for that application. For
example, to see what counters are available:
('Instance' here refers to the performance counter instance, not the role, or server machine instance. The
performance counter instance name typically segments counters such as processor time by the name of the
process or application.)
To get a chart of available memory over the recent period:
Like other telemetry, performanceCounters also has a column cloud_RoleInstance that indicates the identity of
the host server instance on which your app is running. For example, to compare the performance of your app on
the different machines:
ASP.NET and Application Insights counts

What's the difference between the Exception rate and Exceptions metrics?
Exception rate is a system performance counter. The CLR counts all the handled and unhandled exceptions
that are thrown, and divides the total in a sampling interval by the length of the interval. The Application
Insights SDK collects this result and sends it to the portal.
Exceptions is a count of the TrackException reports received by the portal in the sampling interval of the
chart. It includes only the handled exceptions where you have written TrackException calls in your code,
and doesn't include all unhandled exceptions.
Performance counters for applications running in Azure Web Apps

Both ASP.NET and ASP.NET Core applications deployed to Azure Web Apps run in a special sandbox
environment. This environment does not allow direct access to system performance counters. However, a limited
subset of counters are exposed as environment variables as described here. Application Insights SDK for
ASP.NET and ASP.NET Core collects performance counters from Azure Web Apps from these special
environment variables. Only a subset of counters are available in this environment, and the full list can be found
here.
Performance counters in ASP.NET Core applications

Support for performance counters in ASP.NET Core is limited:
SDK versions 2.4.1 and later collect performance counters if the application is running in Azure Web Apps
(Windows).
SDK versions 2.7.1 and later collect performance counters if the application is running in Windows and targets
NETSTANDARD2.0 or later.
For applications targeting the .NET Framework, all versions of the SDK support performance counters.
SDK Versions 2.8.0 and later support cpu/memory counter in Linux. No other counter is supported in Linux.
The recommended way to get system counters in Linux (and other non-Windows environments) is by using
EventCounters
Alerts
Like other metrics, you can set an alert to warn you if a performance counter goes outside a limit you specify.
Open the Alerts pane and click Add Alert.
Next steps
Dependency tracking
Exception tracking
EventCounters introduction
EventCounter is .NET/.NET Core mechanism to publish and consume counters or statistics. This document gives
an overview of EventCounters and examples on how to publish and consume them. EventCounters are supported
in all OS platforms - Windows, Linux, and macOS. It can be thought of as a cross-platform equivalent for the
PerformanceCounters that is only supported in Windows systems.
While users can publish any custom EventCounters to meet their needs, the .NET Core 3.0 runtime publishes a set
of these counters by default. The document will walk through the steps required to collect and view
EventCounters (system defined or user defined) in Azure Application Insights.
Using Application Insights to collect EventCounters

Application Insights supports collecting EventCounters with its EventCounterCollectionModule , which is part of the
newly released nuget package Microsoft.ApplicationInsights.EventCounterCollector.
EventCounterCollectionModule is automatically enabled when using either AspNetCore or WorkerService.
EventCounterCollectionModule collects counters with a non-configurable collection frequency of 60 seconds. There
are no special permissions required to collect EventCounters.
Default counters collected

For apps running in .NET Core 3.0, the following counters are collected automatically by the SDK. The name of
the counters will be of the form "Category|Counter".
CATEGORY COUNTER
System.Runtime cpu-usage
System.Runtime working-set
System.Runtime gc-heap-size
System.Runtime gen-0-gc-count
System.Runtime time-in-gc
System.Runtime gen-0-size
System.Runtime loh-size
CATEGORY COUNTER
System.Runtime alloc-rate
System.Runtime assembly-count
System.Runtime exception-count
System.Runtime threadpool-thread-count
System.Runtime monitor-lock-contention-count
System.Runtime threadpool-queue-length
System.Runtime threadpool-completed-items-count
System.Runtime active-timer-count
Microsoft.AspNetCore.Hosting requests-per-second
Microsoft.AspNetCore.Hosting total-requests
Microsoft.AspNetCore.Hosting current-requests
Microsoft.AspNetCore.Hosting failed-requests
NOTE
Counters of category Microsoft.AspNetCore.Hosting are only added in Asp.Net Core Applications.
Customizing counters to be collected

The following example shows how to add/remove counters. This customization would be done in the
ConfigureServices method of your application after Application Insights telemetry collection is enabled using
either AddApplicationInsightsTelemetry() or AddApplicationInsightsWorkerService() . Following is an example
code from an ASP.NET Core application. For other type of applications, refer to this document.
using Microsoft.ApplicationInsights.Extensibility.EventCounterCollector;

{
//... other code...
// The following code shows several customizations done to EventCounterCollectionModule.

services.ConfigureTelemetryModule<EventCounterCollectionModule>(
(module, o) =>
{
// This removes all default counters.
module.Counters.Clear();
// This adds a user defined counter "MyCounter" from EventSource named "MyEventSource"
module.Counters.Add(new EventCounterCollectionRequest("MyEventSource", "MyCounter"));
// This adds the system counter "gen-0-size" from "System.Runtime"

module.Counters.Add(new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
}
);
// The following code removes EventCounterCollectionModule to disable the module completely.

var eventCounterModule = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(EventCounterCollectionModule));
if (eventCounterModule != null)
{
services.Remove(eventCounterModule);
}
}
Event counters in Metric Explorer

To view EventCounter metrics in Metric Explorer, select Application Insights resource, and chose Log-based
metrics as metric namespace. Then EventCounter metrics get displayed under PerformanceCounter category.
Event counters in Analytics

You can also search and display event counter reports in Analytics, in the performanceCounters table.
For example, run the following query to see what counters are collected and available to query:
performanceCounters | summarize avg(value) by name

To get a chart of a specific counter (for example: ThreadPool Completed Work Item Count ) over the recent period,
run the following query.
performanceCounters
| where name contains "System.Runtime|ThreadPool Completed Work Item Count"
| where timestamp >= ago(1h)
| summarize avg(value) by cloud_RoleInstance, bin(timestamp, 1m)
| render timechart
Like other telemetry, performanceCounters also has a column cloud_RoleInstance that indicates the identity of
the host server instance on which your app is running. The above query shows the counter value per instance, and
can be used to compare performance of different server instances.
Alerts
Like other metrics, you can set an alert to warn you if an event counter goes outside a limit you specify. Open the
Alerts pane and click Add Alert.

Can I see EventCounters in Live Metrics?
Live Metrics do not show EventCounters as of today. Use Metric Explorer or Analytics to see the telemetry.
Which platforms can I see the default list of .NET Core 3.0 counters?
EventCounter doesn't require any special permissions, and is supported in all platforms .NET Core 3.0 is
supported. This includes:
Operating system: Windows, Linux, or macOS.
Hosting method: In process or out of process.
Deployment method: Framework dependent or self-contained.
Web server: IIS (Internet Information Server) or Kestrel.
Hosting platform: The Web Apps feature of Azure App Service, Azure VM, Docker, Azure Kubernetes Service
(AKS ), and so on.
I have enabled Application Insights from Azure Web App Portal. But I can't see EventCounters.?
Application Insights extension for ASP.NET Core doesn't yet support this feature. This document will be updated
when this feature is supported.
Next steps
Dependency tracking
Dependency Tracking in Azure Application Insights
A dependency is an external component that is called by your app. It's typically a service called using HTTP, or
a database, or a file system. Application Insights measures the duration of dependency calls, whether its failing
or not, along with additional information like name of dependency and so on. You can investigate specific
dependency calls, and correlate them to requests and exceptions.
Automatically tracked dependencies

Application Insights SDKs for .NET and .NET Core ships with DependencyTrackingTelemetryModule which is a
Telemetry Module that automatically collects dependencies. This dependency collection is enabled
automatically for ASP.NET and ASP.NET Core applications, when configured as per the linked official docs.
DependencyTrackingTelemetryModule is shipped as this NuGet package, and is brought automatically when using
either of the NuGet packages Microsoft.ApplicationInsights.Web or Microsoft.ApplicationInsights.AspNetCore .
DependencyTrackingTelemetryModule currently tracks the following dependencies automatically:
DEPENDENCIES DETAILS
Http/Https Local or Remote http/https calls
WCF calls Only tracked automatically if Http-based bindings are used.
SQL Calls made with SqlClient . See this for capturing SQL
query.
Azure storage (Blob, Table, Queue ) Calls made with Azure Storage Client.
EventHub Client SDK Version 1.1.0 and above.
ServiceBus Client SDK Version 3.0.0 and above.
Azure Cosmos DB Only tracked automatically if HTTP/HTTPS is used. TCP

mode won't be captured by Application Insights.
If you're missing a dependency, or using a different SDK make sure it's in the list ofauto-collected
dependencies. If the dependency isn't auto-collected, you can still track it manually with a track dependency
call.
Setup automatic dependency tracking in Console Apps

To automatically track dependencies from .NET/.NET Core console apps, install the Nuget package
Microsoft.ApplicationInsights.DependencyCollector , and initialize DependencyTrackingTelemetryModule as
follows:
DependencyTrackingTelemetryModule depModule = new DependencyTrackingTelemetryModule();

depModule.Initialize(TelemetryConfiguration.Active);
How automatic dependency monitoring works?

Dependencies are automatically collected by using one of the following techniques:
Using byte code instrumentation around select methods. (InstrumentationEngine either from StatusMonitor
or Azure Web App Extension)
EventSource callbacks
DiagnosticSource callbacks (in the latest .NET/.NET Core SDKs)
Manually tracking dependencies

The following are some examples of dependencies, which aren't automatically collected, and hence require
manual tracking.
Azure Cosmos DB is tracked automatically only if HTTP/HTTPS is used. TCP mode won't be captured by
Redis
For those dependencies not automatically collected by SDK, you can track them manually using the
TrackDependency API that is used by the standard auto collection modules.
For example, if you build your code with an assembly that you didn't write yourself, you could time all the calls
to it, to find out what contribution it makes to your response times. To have this data displayed in the
dependency charts in Application Insights, send it using TrackDependency .
var startTime = DateTime.UtcNow;

var timer = System.Diagnostics.Stopwatch.StartNew();
try
{
// making dependency call
}
finally
{
timer.Stop();
telemetryClient.TrackDependency("myDependencyType", "myDependencyCall", "myDependencyData",
startTime, timer.Elapsed, success);
}
Alternatively, TelemetryClient provides extension methods StartOperation and StopOperation which can be
used to manually track dependencies, as shown here
If you want to switch off the standard dependency tracking module, remove the reference to
DependencyTrackingTelemetryModule in ApplicationInsights.config for ASP.NET applications. For ASP.NET
Core applications, follow instructions here.
Tracking AJAX calls from Web Pages

For web pages, Application Insights JavaScript SDK automatically collects AJAX calls as dependencies.
Advanced SQL tracking to get full SQL Query

For SQL calls, the name of the server and database is always collected and stored as name of the collected
DependencyTelemetry . There's an additional field called 'data', which can contain the full SQL query text.
For ASP.NET Core applications, there's no additional step required to get the full SQL Query.
For ASP.NET applications, full SQL query is collected with the help of byte code instrumentation, which
requires instrumentation engine. Additional platform-specific steps, as described below, are required.
PLATFORM STEP(S) NEEDED TO GET FULL SQL QUERY
Azure Web App In your web app control panel, open the Application
Insights blade and enable SQL Commands under .NET
IIS Server (Azure VM, on-prem, and so on.) Use the Status Monitor PowerShell Module to install the
Instrumentation Engine and restart IIS.
Azure Cloud Service Add startup task to install StatusMonitor

Your app should be onboarded to ApplicationInsights SDK
at build time by installing NuGet packages for ASP.NET or
ASP.NET Core applications
IIS Express Not supported
In the above cases, the correct way of validating that instrumentation engine is correctly installed is by
validating that the SDK version of collected DependencyTelemetry is 'rddp'. 'rdddsd' or 'rddf' indicates
dependencies are collected via DiagnosticSource or EventSource callbacks, and hence full SQL query won't be
captured.
Where to find dependency data

Application Map visualizes dependencies between your app and neighboring components.
Transaction Diagnostics shows unified, correlated server data.
Browsers tab shows AJAX calls from your users' browsers.
Click through from slow or failed requests to check their dependency calls.
Analytics can be used to query dependency data.
Diagnose slow requests

Each request event is associated with the dependency calls, exceptions, and other events that are tracked while
your app is processing the request. So if some requests are doing badly, you can find out whether it's because
of slow responses from a dependency.
Tracing from requests to dependencies
Open the Performance tab and navigate to the Dependencies tab at the top next to operations.
Click on a Dependency Name under overall. After you select a dependency a graph of that dependency's
distribution of durations will show up on the right.
Click on the blue Samples button on the bottom right and then on a sample to see the end-to-end transaction
details.
Profile your live site

No idea where the time goes? The Application Insights profiler traces HTTP calls to your live site and shows
you the functions in your code that took the longest time.
Failed requests
Failed requests might also be associated with failed calls to dependencies.
We can go to the Failures tab on the left and then click on the dependencies tab at the top.
Here you will be able to see the failed dependency count. To get more details about a failed occurrence trying
clicking on a dependency name in the bottom table. You can click on the blue Dependencies button at the
bottom right to get the end-to-end transaction details.
Logs (Analytics)
You can track dependencies in the Kusto query language. Here are some examples.
Find any failed dependency calls:
dependencies | where success != "True" | take 10
Find AJAX calls:
dependencies | where client_Type == "Browser" | take 10
Find dependency calls associated with requests:
dependencies
| where timestamp > ago(1d) and client_Type != "Browser"
| join (requests | where timestamp > ago(1d))
on operation_Id
Find AJAX calls associated with page views:

dependencies
| where timestamp > ago(1d) and client_Type == "Browser"
| join (browserTimings | where timestamp > ago(1d))
on operation_Id

How does automatic dependency collector report failed calls to dependencies?
Failed dependency calls will have 'success' field set to False. DependencyTrackingTelemetryModule does not
report ExceptionTelemetry . The full data model for dependency is described here.
Open-source SDK
Like every Application Insights SDK, dependency collection module is also open-source. Read and contribute
to the code, or report issues at the official GitHub repo.
Next steps
Exceptions
User & page data
Availability
Configuring the Application Insights SDK with
ApplicationInsights.config or .xml
The Application Insights .NET SDK consists of a number of NuGet packages. The core package provides the
API for sending telemetry to the Application Insights. Additional packages provide telemetry modules and
initializers for automatically tracking telemetry from your application and its context. By adjusting the
configuration file, you can enable or disable Telemetry Modules and initializers, and set parameters for some
of them.
The configuration file is named ApplicationInsights.config or ApplicationInsights.xml , depending on the
type of your application. It is automatically added to your project when you install most versions of the SDK.
By default, when using the automated experience from the Visual Studio template projects that support Add
> Application Insights Telemetry, the ApplicationInsights.config file is created in the project root folder
and when complied is copied to the bin folder. It is also added to a web app by Status Monitor on an IIS
server. The configuration file is ignored if extension for Azure website or extension for Azure VM and virtual
machine scale set is used.
There isn't an equivalent file to control the SDK in a web page.
This document describes the sections you see in the configuration file, how they control the components of
the SDK, and which NuGet packages load those components.
NOTE
ApplicationInsights.config and .xml instructions do not apply to the .NET Core SDK. For configuring .NET Core
applications, follow this guide.
Telemetry Modules (ASP.NET)

Each Telemetry Module collects a specific type of data and uses the core API to send the data. The modules
are installed by different NuGet packages, which also add the required lines to the .config file.
There's a node in the configuration file for each module. To disable a module, delete the node or comment it
out.
Dependency Tracking
Dependency tracking collects telemetry about calls your app makes to databases and external services and
databases. To allow this module to work in an IIS server, you need to install Status Monitor.
You can also write your own dependency tracking code using the TrackDependency API.
Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule
Microsoft.ApplicationInsights.DependencyCollector NuGet package.
Dependencies can be auto-collected without modifying your code by using agent-based (codeless) attach. To
use it in Azure web apps, enable the Application Insights extension. To use it in Azure VM or Azure virtual
machine scale set enable the Application Monitoring extension for VM and virtual machine scale set.
Performance collector
Collects system performance counters such as CPU, memory, and network load from IIS installations. You
can specify which counters to collect, including performance counters you have set up yourself.
Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule
Microsoft.ApplicationInsights.PerfCounterCollector NuGet package.
Application Insights Diagnostics Telemetry
The DiagnosticsTelemetryModule reports errors in the Application Insights instrumentation code itself. For
example, if the code cannot access performance counters or if an ITelemetryInitializer throws an
exception. Trace telemetry tracked by this module appears in the Diagnostic Search.
* `Microsoft.ApplicationInsights.Extensibility.Implementation.Tracing.DiagnosticsTelemetryModule`
* [Microsoft.ApplicationInsights](https://www.nuget.org/packages/Microsoft.ApplicationInsights) NuGet
package. If you only install this package, the ApplicationInsights.config file is not automatically
created.
Developer Mode
DeveloperModeWithDebuggerAttachedTelemetryModule forces the Application Insights TelemetryChannel to send
data immediately, one telemetry item at a time, when a debugger is attached to the application process. This
reduces the amount of time between the moment when your application tracks telemetry and when it
appears on the Application Insights portal. It causes significant overhead in CPU and network bandwidth.
Microsoft.ApplicationInsights.WindowsServer.DeveloperModeWithDebuggerAttachedTelemetryModule
Application Insights Windows Server NuGet package
Web Request Tracking
Reports the response time and result code of HTTP requests.
Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule
Microsoft.ApplicationInsights.Web NuGet package
Exception tracking
ExceptionTrackingTelemetryModule tracks unhandled exceptions in your web app. See Failures and exceptions.
Microsoft.ApplicationInsights.Web.ExceptionTrackingTelemetryModule
Microsoft.ApplicationInsights.Web NuGet package
Microsoft.ApplicationInsights.WindowsServer.UnobservedExceptionTelemetryModule - tracks unobserved task
exceptions.
Microsoft.ApplicationInsights.WindowsServer.UnhandledExceptionTelemetryModule - tracks unhandled
exceptions for worker roles, windows services, and console applications.
Application Insights Windows Server NuGet package.
EventSource Tracking
EventSourceTelemetryModule allows you to configure EventSource events to be sent to Application Insights as
traces. For information on tracking EventSource events, see Using EventSource Events.
Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule
Microsoft.ApplicationInsights.EventSourceListener
ETW Event Tracking
EtwCollectorTelemetryModule allows you to configure events from ETW providers to be sent to Application
Insights as traces. For information on tracking ETW events, see Using ETW Events.
Microsoft.ApplicationInsights.EtwCollector.EtwCollectorTelemetryModule
Microsoft.ApplicationInsights.EtwCollector
The Microsoft.ApplicationInsights package provides the core API of the SDK. The other Telemetry Modules
use this, and you can also use it to define your own telemetry.
No entry in ApplicationInsights.config.
Microsoft.ApplicationInsights NuGet package. If you just install this NuGet, no .config file is generated.
Telemetry Channel
The telemetry channel manages buffering and transmission of telemetry to the Application Insights service.
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel is the default
channel for web applications. It buffers data in memory, and employs retry mechanisms and local disk
storage for more reliable telemetry delivery.
Microsoft.ApplicationInsights.InMemoryChannel is a lightweight telemetry channel, which is used if no
other channel is configured.
Telemetry Initializers (ASP.NET)

Telemetry Initializers set context properties that are sent along with every item of telemetry.
You can write your own initializers to set context properties.
The standard initializers are all set either by the Web or WindowsServer NuGet packages:
AccountIdTelemetryInitializer sets the AccountId property.
AuthenticatedUserIdTelemetryInitializer sets the AuthenticatedUserId property as set by the
JavaScript SDK.
AzureRoleEnvironmentTelemetryInitializer updates the RoleName and RoleInstance properties of the
Device context for all telemetry items with information extracted from the Azure runtime
environment.
BuildInfoConfigComponentVersionTelemetryInitializer updates the Version property of the Component
context for all telemetry items with the value extracted from the BuildInfo.config file produced by
MS Build.
ClientIpHeaderTelemetryInitializer updates Ip property of the Location context of all telemetry
items based on the X-Forwarded-For HTTP header of the request.
DeviceTelemetryInitializer updates the following properties of the Device context for all telemetry
items.
Type is set to "PC"
Id is set to the domain name of the computer where the web application is running.
OemName is set to the value extracted from the Win32_ComputerSystem.Manufacturer field using WMI.
Model is set to the value extracted from the Win32_ComputerSystem.Model field using WMI.
NetworkType is set to the value extracted from the NetworkInterface .
Language is set to the name of the CurrentCulture .
DomainNameRoleInstanceTelemetryInitializer updates the RoleInstance property of the Device
context for all telemetry items with the domain name of the computer where the web application is
running.
OperationNameTelemetryInitializer updates the Name property of the RequestTelemetry and the
Name property of the Operation context of all telemetry items based on the HTTP method, as well as
names of ASP.NET MVC controller and action invoked to process the request.
OperationIdTelemetryInitializer or OperationCorrelationTelemetryInitializer updates the
Operation.Id context property of all telemetry items tracked while handling a request with the
automatically generated RequestTelemetry.Id .
SessionTelemetryInitializer updates the property of the Session context for all telemetry items
Id
with value extracted from the ai_session cookie generated by the ApplicationInsights JavaScript
instrumentation code running in the user's browser.
SyntheticTelemetryInitializer or SyntheticUserAgentTelemetryInitializer updates the User ,
Session , and Operation contexts properties of all telemetry items tracked when handling a request
from a synthetic source, such as an availability test or search engine bot. By default, Metrics Explorer
does not display synthetic telemetry.
The <Filters> set identifying properties of the requests.
UserTelemetryInitializer updates the Id and AcquisitionDate properties of User context for all
telemetry items with values extracted from the ai_user cookie generated by the Application Insights
JavaScript instrumentation code running in the user's browser.
WebTestTelemetryInitializer sets the user ID, session ID, and synthetic source properties for HTTP
requests that come from availability tests. The <Filters> set identifying properties of the requests.
For .NET applications running in Service Fabric, you can include the
Microsoft.ApplicationInsights.ServiceFabric NuGet package. This package includes a
FabricTelemetryInitializer , which adds Service Fabric properties to telemetry items. For more information,
see the GitHub page about the properties added by this NuGet package.
Telemetry Processors (ASP.NET)

Telemetry Processors can filter and modify each telemetry item just before it is sent from the SDK to the
portal.
You can write your own Telemetry Processors.
Adaptive sampling Telemetry Processor (from 2.0.0-beta3)
This is enabled by default. If your app sends a lot of telemetry, this processor removes some of it.
<Add
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor,
</Add>
The parameter provides the target that the algorithm tries to achieve. Each instance of the SDK works
independently, so if your server is a cluster of several machines, the actual volume of telemetry will be
multiplied accordingly.
Learn more about sampling.
Fixed-rate sampling Telemetry Processor (from 2.0.0-beta1)
There is also a standard sampling Telemetry Processor (from 2.0.1):
<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTelemetryProcessor,


<SamplingPercentage>10</SamplingPercentage>
</Add>
Channel parameters (Java)

These parameters affect how the Java SDK should store and flush the telemetry data that it collects.
MaxTelemetryBufferCapacity
The number of telemetry items that can be stored in the SDK's in-memory storage. When this number is
reached, the telemetry buffer is flushed - that is, the telemetry items are sent to the Application Insights
server.
Min: 1
Max: 1000
Default: 500
...
<Channel>
<MaxTelemetryBufferCapacity>100</MaxTelemetryBufferCapacity>
</Channel>
...
FlushIntervalInSeconds
Determines how often the data that is stored in the in-memory storage should be flushed (sent to
Application Insights).
Min: 1
Max: 300
Default: 5
...
<Channel>
<FlushIntervalInSeconds>100</FlushIntervalInSeconds>
</Channel>
...
MaxTransmissionStorageCapacityInMB
Determines the maximum size in MB that is allotted to the persistent storage on the local disk. This storage
is used for persisting telemetry items that failed to be transmitted to the Application Insights endpoint. When
the storage size has been met, new telemetry items will be discarded.
Min: 1
Max: 100
Default: 10
...
<Channel>
<MaxTransmissionStorageCapacityInMB>50</MaxTransmissionStorageCapacityInMB>
</Channel>
...
Local forwarder
Local forwarder is an agent that collects Application Insights or OpenCensus telemetry from a variety of
SDKs and frameworks and routes it to Application Insights. It's capable of running under Windows and
Linux. When coupled with the Application Insights Java SDK the local forwarder provides full support for
Live Metrics and adaptive sampling.
<Channel
type="com.microsoft.applicationinsights.channel.concrete.localforwarder.LocalForwarderTelemetryChannel">
<EndpointAddress></EndpointAddress>

<FlushIntervalInSeconds>5</FlushIntervalInSeconds>
<MaxTelemetryBufferCapacity>500</MaxTelemetryBufferCapacity>
</Channel>
If you are using SpringBoot starter, add the following to your configuration file (application.properties):
azure.application-insights.channel.local-forwarder.endpoint-address=
azure.application-insights.channel.local-forwarder.flush-interval-in-seconds=
azure.application-insights.channel.local-forwarder.max-telemetry-buffer-capacity=
Default values are the same for SpringBoot application.properties and applicationinsights.xml configuration.
InstrumentationKey
This determines the Application Insights resource in which your data appears. Typically you create a separate
resource, with a separate key, for each of your applications.
If you want to set the key dynamically - for example if you want to send results from your application to
different resources - you can omit the key from the configuration file, and set it in code instead.
To set the key for all instances of TelemetryClient, including standard Telemetry Modules, set the key in
TelemetryConfiguration.Active. Do this in an initialization method, such as global.aspx.cs in an ASP.NET
service:
{
// - for example -
WebConfigurationManager.AppSettings["ikey"];
//...
If you just want to send a specific set of events to a different resource, you can set the key for a specific
TelemetryClient:
var tc = new TelemetryClient();

tc.Context.InstrumentationKey = "----- my key ----";
tc.TrackEvent("myEvent");
// ...
To get a new key, create a new resource in the Application Insights portal.
ApplicationId Provider
Available starting in v2.6.0
The purpose of this provider is to lookup an Application ID based on an Instrumentation Key. The
Application ID is included in RequestTelemetry and DependencyTelemetry and used to determine
Correlation in the Portal.
This is available by setting TelemetryConfiguration.ApplicationIdProvider either in code or in config.
Interface: IApplicationIdProvider
public interface IApplicationIdProvider

{
bool TryGetApplicationId(string instrumentationKey, out string applicationId);
}
We provide two implementations in the Microsoft.ApplicationInsights sdk:

ApplicationInsightsApplicationIdProvider and DictionaryApplicationIdProvider .
ApplicationInsightsApplicationIdProvider
This is a wrapper around our Profile API. It will throttle requests and cache results.
This provider is added to your config file when you install either
Microsoft.ApplicationInsights.DependencyCollector or Microsoft.ApplicationInsights.Web
This class has an optional property . By default this is set to
ProfileQueryEndpoint
https://dc.services.visualstudio.com/api/profiles/{0}/appId . If you need to configure a proxy for this
configuration, we recommend proxying the base address and including "/api/profiles/{0}/appId". Note that
'{0}' is substituted at runtime per request with the Instrumentation Key.
Example Configuration via ApplicationInsights.config:
...
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplica
tionIdProvider, Microsoft.ApplicationInsights">
<ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
...
Example Configuration via code:
TelemetryConfiguration.Active.ApplicationIdProvider = new ApplicationInsightsApplicationIdProvider();
DictionaryApplicationIdProvider
This is a static provider, which will rely on your configured Instrumentation Key / Application ID pairs.
This class has a property Defined , which is a Dictionary<string,string> of Instrumentation Key to
Application ID pairs.
This class has an optional property Next which can be used to configure another provider to use when an
Instrumentation Key is requested that does not exist in your configuration.
Example Configuration via ApplicationInsights.config:
...
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.DictionaryApplicationIdPro
vider, Microsoft.ApplicationInsights">
<Defined>
<Type key="InstrumentationKey_1" value="ApplicationId_1"/>
<Type key="InstrumentationKey_2" value="ApplicationId_2"/>
</Defined>
<Next
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplica
tionIdProvider, Microsoft.ApplicationInsights" />
...
Example Configuration via code:
TelemetryConfiguration.Active.ApplicationIdProvider = new DictionaryApplicationIdProvider{

Defined = new Dictionary<string, string>
{
{"InstrumentationKey_1", "ApplicationId_1"},
{"InstrumentationKey_2", "ApplicationId_2"}
}
};
Next steps
Learn more about the API.
Correlating Application Insights data with custom
data sources
Application Insights collects several different data types: exceptions, traces, page views, and others. While this is
often sufficient to investigate your application’s performance, reliability, and usage, there are cases when it is useful
to correlate the data stored in Application Insights to other completely custom datasets.
Some situations where you might want custom data include:
Data enrichment or lookup tables: for example, supplement a server name with the owner of the server and the
lab location in which it can be found
Correlation with non-Application Insights data sources: for example, correlate data about a purchase on a web-
store with information from your purchase-fulfillment service to determine how accurate your shipping time
estimates were
Completely custom data: many of our customers love the query language and performance of the Azure
Monitor log platform that backs Application Insights, and want to use it to query data that is not at all related to
Application Insights. For example, to track the solar panel performance as part of a smart home installation as
outlined here.
How to correlate custom data with Application Insights data

Since Application Insights is backed by the powerful Azure Monitor log platform, we are able to use the full power
of Azure Monitor to ingest the data. Then, we will write queries using the “join” operator that will correlate this
custom data with the data available to us in Azure Monitor logs.
Ingesting data
In this section, we will review how to get your data into Azure Monitor logs.
If you don’t already have one, provision a new Log Analytics workspace by following these instructions through
and including the “create a workspace” step.
To start sending log data into Azure Monitor. Several options exist:
For a synchronous mechanism, you can either directly call the data collector API or use our Logic App
connector – simply look for “Azure Log Analytics” and pick the “Send Data” option:
For an asynchronous option, use the Data Collector API to build a processing pipeline. See this article for
details.
Correlating data
Application Insights is based on the Azure Monitor log platform. We can therefore use cross-resource joins to
correlate any data we ingested into Azure Monitor with our Application Insights data.
For example, we can ingest our lab inventory and locations into a table called “LabLocations_CL” in a Log Analytics
workspace called “myLA”. If we then wanted to review our requests tracked in Application Insights app called
“myAI” and correlate the machine names that served the requests to the locations of these machines stored in the
previously mentioned custom table, we can run the following query from either the Application Insights or Azure
Monitor context:
app('myAI').requests
| join kind= leftouter (
workspace('myLA').LabLocations_CL
| project Computer_S, Owner_S, Lab_S
) on $left.cloud_RoleInstance == $right.Computer
Next Steps
Check out the Data Collector API reference.
For more information on cross-resource joins.
Deep diagnostics for web apps and services with
Why do I need Application Insights?

Application Insights monitors your running web app. It tells you about failures and performance issues, and helps
you analyze how customers use your app. It works for apps running on many platforms (ASP.NET, Java EE,
Node.js, ...) and is hosted either in the Cloud or on-premises.
It's essential to monitor a modern application while it is running. Most importantly, you want to detect failures
before most of your customers do. You also want to discover and fix performance issues that, while not
catastrophic, perhaps slow things down or cause some inconvenience to your users. And when the system is
performing to your satisfaction, you want to know what the users are doing with it: Are they using the latest
feature? Are they succeeding with it?
Modern web applications are developed in a cycle of continuous delivery: release a new feature or improvement;
observe how well it works for the users; plan the next increment of development based on that knowledge. A key
part of this cycle is the observation phase. Application Insights provides the tools to monitor a web application for
performance and usage.
The most important aspect of this process is diagnostics and diagnosis. If the application fails, then business is
being lost. The prime role of a monitoring framework is therefore to detect failures reliably, notify you immediately,
and to present you with the information needed to diagnose the problem. This is exactly what Application Insights
does.
Where do bugs come from?
Failures in web systems typically arise from configuration issues or bad interactions between their many
components. The first task when tackling a live site incident is therefore to identify the locus of the problem: which
component or relationship is the cause?
Some of us, those with gray hair, can remember a simpler era in which a computer program ran in one computer.
The developers would test it thoroughly before shipping it; and having shipped it, would rarely see or think about it
again. The users would have to put up with the residual bugs for many years.
Things are so very different now. Your app has a plethora of different devices to run on, and it can be difficult to
guarantee the exact same behavior on each one. Hosting apps in the cloud means bugs can be fixed fast, but it also
means continuous competition and the expectation of new features at frequent intervals.
In these conditions, the only way to keep a firm control on the bug count is automated unit testing. It would be
impossible to manually re-test everything on every delivery. Unit test is now a commonplace part of the build
process. Tools such as the Xamarin Test Cloud help by providing automated UI testing on multiple browser
versions. These testing regimes allow us to hope that the rate of bugs found inside an app can be kept to a
minimum.
Typical web applications have many live components. In addition to the client (in a browser or device app) and the
web server, there's likely to be substantial backend processing. Perhaps the backend is a pipeline of components, or
a looser collection of collaborating pieces. And many of them won't be in your control - they are external services
on which you depend.
In configurations like these, it can be difficult and uneconomical to test for, or foresee, every possible failure mode,
other than in the live system itself.
Questions ...
Some questions we ask when we're developing a web system:
Is my app crashing?
What exactly happened? - If it failed a request, I want to know how it got there. We need a trace of events...
Is my app fast enough? How long does it take to respond to typical requests?
Can the server handle the load? When the rate of requests rises, does the response time hold steady?
How responsive are my dependencies - the REST APIs, databases and other components that my app calls. In
particular, if the system is slow, is it my component, or am I getting slow responses from someone else?
Is my app Up or Down? Can it be seen from around the world? Let me know if it stops....
What is the root cause? Was the failure in my component or a dependency? Is it a communication issue?
How many users are impacted? If I have more than one issue to tackle, which is the most important?

1. Application Insights instruments your app and sends telemetry about it while the app is running. Either you can
build the Application Insights SDK into the app, or you can apply instrumentation at runtime. The former
method is more flexible, as you can add your own telemetry to the regular modules.
2. The telemetry is sent to the Application Insights portal, where it is stored and processed. (Although Application
Insights is hosted in Microsoft Azure, it can monitor any web apps - not just Azure apps.)
3. The telemetry is presented to you in the form of charts and tables of events.
There are two main types of telemetry: aggregated and raw instances.
Instance data includes, for example, a report of a request that has been received by your web app. You can find
for and inspect the details of a request using the Search tool in the Application Insights portal. The instance
would include data such as how long your app took to respond to the request, as well as the requested URL,
approximate location of the client, and other data.
Aggregated data includes counts of events per unit time, so that you can compare the rate of requests with the
response times. It also includes averages of metrics such as request response times.
The main categories of data are:
Requests to your app (usually HTTP requests), with data on URL, response time, and success or failure.
Dependencies - REST and SQL calls made by your app, also with URI, response times and success
Exceptions, including stack traces.
Page view data, which come from the users' browsers.
Metrics such as performance counters, as well as metrics you write yourself.
Custom events that you can use to track business events
Log traces used for debugging.
Case Study: Real Madrid F.C.

The web service of Real Madrid Football Club serves about 450 million fans around the world. Fans access it both
through web browsers and the Club's mobile apps. Fans cannot only book tickets, but also access information and
video clips on results, players and upcoming games. They can search with filters such as numbers of goals scored.
There are also links to social media. The user experience is highly personalized, and is designed as a two-way
communication to engage fans.
The solution is a system of services and applications on Microsoft Azure. Scalability is a key requirement: traffic is
variable and can reach very high volumes during and around matches.
For Real Madrid, it's vital to monitor the system's performance. Azure Application Insights provides a
comprehensive view across the system, ensuring a reliable and high level of service.
The Club also gets in-depth understanding of its fans: where they are (only 3% are in Spain), what interest they
have in players, historical results, and upcoming games, and how they respond to match outcomes.
Most of this telemetry data is automatically collected with no added code, which simplified the solution and
reduced operational complexity. For Real Madrid, Application Insights deals with 3.8 billion telemetry points each
month.
Real Madrid uses the Power BI module to view their telemetry.
Smart detection
Proactive diagnostics is a recent feature. Without any special configuration by you, Application Insights
automatically detects and alerts you about unusual rises in failure rates in your app. It's smart enough to ignore a
background of occasional failures, and also rises that are simply proportionate to a rise in requests. So for example,
if there's a failure in one of the services you depend on, or if the new build you just deployed isn't working so well,
then you'll know about it as soon as you look at your email. (And there are webhooks so that you can trigger other
apps.)
Another aspect of this feature performs a daily in-depth analysis of your telemetry, looking for unusual patterns of
performance that are hard to discover. For example, it can find slow performance associated with a particular
geographical area, or with a particular browser version.
In both cases, the alert not only tells you the symptoms it's discovered, but also gives you data you need to help
diagnose the problem, such as relevant exception reports.
Customer Samtec said: "During a recent feature cutover, we found an under-scaled database that was hitting its
resource limits and causing timeouts. Proactive detection alerts came through literally as we were triaging the
issue, very near real time as advertised. This alert coupled with the Azure platform alerts helped us almost
instantly fix the issue. Total downtime < 10 minutes."
Live Metrics Stream

Deploying the latest build can be an anxious experience. If there are any problems, you want to know about them
right away, so that you can back out if necessary. Live Metrics Stream gives you key metrics with a latency of about
one second.
And lets you immediately inspect a sample of any failures or exceptions.
Application Map
Application Map automatically discovers your application topology, laying the performance information on top of
it, to let you easily identify performance bottlenecks and problematic flows across your distributed environment. It
allows you to discover application dependencies on Azure Services. You can triage the problem by understanding if
it is code-related or dependency related and from a single place drill into related diagnostics experience. For
example, your application may be failing due to performance degradation in SQL tier. With application map, you
can see it immediately and drill into the SQL Index Advisor or Query Insights experience.
Application Insights Analytics

With Analytics, you can write arbitrary queries in a powerful SQL -like language. Diagnosing across the entire app
stack becomes easy as various perspectives get connected and you can ask the right questions to correlate Service
Performance with Business Metrics and Customer Experience.
You can query all your telemetry instance and metric raw data stored in the portal. The language includes filter,
join, aggregation, and other operations. You can calculate fields and perform statistical analysis. There are both
tabular and graphical visualizations.
For example, it's easy to:
Segment your application’s request performance data by customer tiers to understand their experience.
Search for specific error codes or custom event names during live site investigations.
Drill down into the app usage of specific customers to understand how features are acquired and adopted.
Track sessions and response times for specific users to enable support and operations teams to provide instant
customer support.
Determine frequently used app features to answer feature prioritization questions.
Customer DNN said: "Application Insights has provided us with the missing part of the equation for being able to
combine, sort, query, and filter data as needed. Allowing our team to use their own ingenuity and experience to
find data with a powerful query language has allowed us to find insights and solve problems we didn't even know
we had. A lot of interesting answers come from the questions starting with 'I wonder if...'."
Development tools integration

Configuring Application Insights
Visual Studio and Eclipse have tools to configure the correct SDK packages for the project you are developing.
There's a menu command to add Application Insights.
If you happen to be using a trace logging framework such as Log4N, NLog, or System.Diagnostics.Trace, then you
get the option to send the logs to Application Insights along with the other telemetry, so that you can easily
correlate the traces with requests, dependency calls, and exceptions.
Search telemetry in Visual Studio
While developing and debugging a feature, you can view and search the telemetry directly in Visual Studio, using
the same search facilities as in the web portal.
And when Application Insights logs an exception, you can view the data point in Visual Studio and jump straight to
the relevant code.
During debugging, you have the option to keep the telemetry in your development machine, viewing it in Visual
Studio but without sending it to the portal. This local option avoids mixing debugging with production telemetry.
Work items
When an alert is raised, Application Insights can automatically create a work item in your work tracking system.
But what about...?

Privacy and storage - Your telemetry is kept on Azure secure servers.
Performance - the impact is very low. Telemetry is batched.
Pricing - You can get started for free, and that continues while you're in low volume.
Video
Next steps
Getting started with Application Insights is easy. The main options are:
IIS servers, and also for Azure App Service.
Instrument your project during development. You can do this for ASP.NET or Java apps, as well as Node.js and
a host of other types.
Instrument any web page by adding a short code snippet.
Monitor performance in web applications
Make sure your application is performing well, and find out quickly about any failures. Application Insights will tell
you about any performance issues and exceptions, and help you find and diagnose the root causes.
Application Insights can monitor both Java and ASP.NET web applications and services, WCF services. They can
be hosted on-premises, on virtual machines, or as Microsoft Azure websites.
On the client side, Application Insights can take telemetry from web pages and a wide variety of devices including
iOS, Android, and Windows Store apps.
Set up performance monitoring

If you haven't yet added Application Insights to your project (that is, if it doesn't have ApplicationInsights.config),
choose one of these ways to get started:
ASP.NET web apps
Add exception monitoring
Add dependency monitoring
Java EE web apps
Add dependency monitoring
Exploring performance metrics

In the Azure portal, browse to the Application Insights resource that you set up for your application. The overview
blade shows basic performance data:
Click any chart to see more detail, and to see results for a longer period. For example, click the Requests tile and
then select a time range:
Click a chart to choose which metrics it displays, or add a new chart and select its metrics:
NOTE
Uncheck all the metrics to see the full selection that is available. The metrics fall into groups; when any member of a group
is selected, only the other members of that group appear.
What does it all mean? Performance tiles and reports

There are various performance metrics you can get. Let's start with those that appear by default on the application
blade.
Requests
The number of HTTP requests received in a specified period. Compare this with the results on other reports to see
how your app behaves as the load varies.
HTTP requests include all GET or POST requests for pages, data, and images.
Click on the tile to get counts for specific URLs.
Average response time
Measures the time between a web request entering your application and the response being returned.
The points show a moving average. If there are many requests, there might be some that deviate from the average
without an obvious peak or dip in the graph.
Look for unusual peaks. In general, expect response time to rise with a rise in requests. If the rise is
disproportionate, your app might be hitting a resource limit such as CPU or the capacity of a service it uses.
Click the tile to get times for specific URLs.
Slowest requests
Shows which requests might need performance tuning.

Failed requests
A count of requests that threw uncaught exceptions.
Click the tile to see the details of specific failures, and select an individual request to see its detail.
Only a representative sample of failures is retained for individual inspection.
Other metrics
To see what other metrics you can display, click a graph, and then deselect all the metrics to see the full available
set. Click (i) to see each metric's definition.
Selecting any metric disables the others that can't appear on the same chart.
Set alerts
To be notified by email of unusual values of any metric, add an alert. You can choose either to send the email to the
account administrators, or to specific email addresses.
Set the resource before the other properties. Don't choose the webtest resources if you want to set alerts on
performance or usage metrics.
Be careful to note the units in which you're asked to enter the threshold value.
I don't see the Add Alert button. - Is this a group account to which you have read-only access? Check with the
account administrator.
Diagnosing issues
Here are a few tips for finding and diagnosing performance issues:
Set up web tests to be alerted if your web site goes down or responds incorrectly or slowly.
Compare the Request count with other metrics to see if failures or slow response are related to load.
Insert and search trace statements in your code to help pinpoint problems.
Monitor your Web app in operation with Live Metrics Stream.
Capture the state of your .NET application with Snapshot Debugger.
Find and fix performance bottlenecks with performance investigation

experience
You can use the performance investigation experience to review slow performing operations in your Web app. You
can quickly select a specific slow operation and use Profiler to root cause the slow operations down to code. Using
the new duration distribution shown for the selected operation you can quickly at a glance assess just how bad the
experience is for your customers. You can see how many of your user interactions were impacted for each slow
operation. In the following example, we've decided to take a closer look at the experience for GET
Customers/Details operation. In the duration distribution, we can see that there are three spikes. Leftmost spike is
around 400 ms and represents great responsive experience. Middle spike is around 1.2 s and represents a
mediocre experience. Finally at the 3.6 s we have another small spike that represents the 99th percentile
experience, which is likely to cause our customers to leave dissatisfied. That experience is ten times slower than the
great experience for the same operation.
To get a better sense of the user experiences for this operation, we can select a larger time range. We can then also
narrow down in time on a specific time window where the operation was slow. In the following example, we've
switched from the default 24 hours time range to the 7 days time range and then zoomed into the 9:47 to 12:47
time window between Tue the 12th and Wed the 13th. Both the duration distribution and the number of sample
and profiler traces have been updated on the right.
To narrow in on the slow experiences, we next zoom into the durations that fall between 95th and the 99th
percentile. These represent the 4% of user interactions that were slow.
We can now either look at the representative samples, by clicking on the Samples button, or at the representative
profiler traces, by clicking on the Profiler traces button. In this example, there are four traces that have been
collected for GET Customers/Details in the time window and range duration of interest.
Sometimes the issue will not be in your code, but rather in a dependency your code calls. You can switch to the
Dependencies tab in the performance triage view to investigate such slow dependencies. By default the
performance view is trending averages, but what you really want to look at is the 95th percentile (or the 99th, in
case you are monitoring a mature service). In the following example we have focused on the slow Azure BLOB
dependency, where we call PUT fabrikamaccount. The good experiences cluster around 40 ms, while the slow calls
to the same dependency are three times slower, clustering around 120 ms. It doesn't take many of these calls to
add up to cause the respective operation to noticeably slow down. You can drill into the representative samples and
profiler traces, just like you can with the Operations tab.
The performance investigation experience shows relevant insights along side the sample set you decided to focus
on. The best way to look at all of the available insights is to switch to a 30 days time range and then select Overall
to see insights across all operations for the past month.
Next steps
Web tests - Have web requests sent to your application at regular intervals from around the world.
Capture and search diagnostic traces - Insert trace calls and sift through the results to pinpoint issues.
Usage tracking - Find out how people use your application.
Troubleshooting - and Q & A
Separating telemetry from Development, Test, and
Production
When you are developing the next version of a web application, you don't want to mix up the Application Insights
telemetry from the new version and the already released version. To avoid confusion, send the telemetry from
different development stages to separate Application Insights resources, with separate instrumentation keys
(ikeys). To make it easier to change the instrumentation key as a version moves from one stage to another, it can
be useful to set the ikey in code instead of in the configuration file.
(If your system is an Azure Cloud Service, there's another method of setting separate ikeys.)
About resources and instrumentation keys

When you set up Application Insights monitoring for your web app, you create an Application Insights resource in
Microsoft Azure. You open this resource in the Azure portal in order to see and analyze the telemetry collected
from your app. The resource is identified by an instrumentation key (ikey). When you install the Application
Insights package to monitor your app, you configure it with the instrumentation key, so that it knows where to
send the telemetry.
You typically choose to use separate resources or a single shared resource in different scenarios:
Different, independent applications - Use a separate resource and ikey for each app.
Multiple components or roles of one business application - Use a single shared resource for all the component
apps. Telemetry can be filtered or segmented by the cloud_RoleName property.
Development, Test, and Release - Use a separate resource and ikey for versions of the system in 'stamp' or
stage of production.
A | B testing - Use a single resource. Create a TelemetryInitializer to add a property to the telemetry that
identifies the variants.
Dynamic instrumentation key

To make it easier to change the ikey as the code moves between stages of production, set it in code instead of in
the configuration file.
Set the key in an initialization method, such as global.aspx.cs in an ASP.NET service:
C#

{
// - for example -
WebConfigurationManager.AppSettings["ikey"];
...
In this example, the ikeys for the different resources are placed in different versions of the web configuration file.
Swapping the web configuration file - which you can do as part of the release script - will swap the target
resource.
Web pages
The iKey is also used in your app's web pages, in the script that you got from the quick start blade. Instead of
coding it literally into the script, generate it from the server state. For example, in an ASP.NET app:
JavaScript in Razor
// Standard Application Insights web page script:
var appInsights = window.appInsights || function(config){ ...
// Modify this part:
}({instrumentationKey:
// Generate from server property:
"@Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey"
}) // ...
Create additional Application Insights resources

To separate telemetry for different application components, or for different stamps (dev/test/production) of the
same component, then you'll have to create a new Application Insights resource.
In the portal.azure.com, add an Application Insights resource:
Application type affects what you see on the overview blade and the properties available in metric explorer.
If you don't see your type of app, choose one of the web types for web pages.
Resource group is a convenience for managing properties like access control. You could use separate
resource groups for development, test, and production.
Subscription is your payment account in Azure.
Location is where we keep your data. Currently it can't be changed.
Add to dashboard puts a quick-access tile for your resource on your Azure Home page.
Creating the resource takes a few seconds. You'll see an alert when it's done.
(You can write a PowerShell script to create a resource automatically.)
Getting the instrumentation key
The instrumentation key identifies the resource that you created.
You need the instrumentation keys of all the resources to which your app will send data.
Filter on build number

When you publish a new version of your app, you'll want to be able to separate the telemetry from different
builds.
You can set the Application Version property so that you can filter search and metric explorer results.
There are several different methods of setting the Application Version property.
Set directly:
telemetryClient.Context.Component.Version = typeof(MyProject.MyClass).Assembly.GetName().Version;
Wrap that line in a telemetry initializer to ensure that all TelemetryClient instances are set consistently.
[ASP.NET] Set the version in BuildInfo.config . The web module will pick up the version from the
BuildLabel node. Include this file in your project and remember to set the Copy Always property in
Solution Explorer.

<DeploymentEvent xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.microsoft.com/VisualStudio/DeploymentEvent/2013/06">
<ProjectName>AppVersionExpt</ProjectName>
<Build type="MSBuild">
<MSBuild>
<BuildLabel kind="label">1.0.0.2</BuildLabel>
</MSBuild>
</Build>
</DeploymentEvent>
[ASP.NET] Generate BuildInfo.config automatically in MSBuild. To do this, add a few lines to your .csproj
file:
<PropertyGroup>
<GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
<IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>
This generates a file called yourProjectName.BuildInfo.config. The Publish process renames it to

BuildInfo.config.
The build label contains a placeholder (AutoGen_...) when you build with Visual Studio. But when built with
MSBuild, it is populated with the correct version number.
To allow MSBuild to generate version numbers, set the version like 1.0.* in AssemblyReference.cs
Version and release tracking

To track the application version, make sure buildinfo.config is generated by your Microsoft Build Engine
process. In your .csproj file, add:
<PropertyGroup>
<GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
<IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>
When it has the build info, the Application Insights web module automatically adds Application version as a
property to every item of telemetry. That allows you to filter by version when you perform diagnostic searches, or
when you explore metrics.
However, notice that the build version number is generated only by the Microsoft Build Engine, not by the
developer build in Visual Studio.
Release annotations
If you use Azure DevOps, you can get an annotation marker added to your charts whenever you release a new
version. The following image shows how this marker appears.
Next steps
Shared resources for multiple roles
Create a Telemetry Initializer to distinguish A|B variants
How do I ... in Application Insights?
Get an email when ...

Email if my site goes down
Set an availability web test.
Email if my site is overloaded
Set an alert on Server response time. A threshold between 1 and 2 seconds should work.
Your app might also show signs of strain by returning failure codes. Set an alert on Failed requests.
If you want to set an alert on Server exceptions, you might have to do some additional setup in order to see data.
Email on exceptions
1. Set up exception monitoring
2. Set an alert on the Exception count metric
Email on an event in my app
Let's suppose you'd like to get an email when a specific event occurs. Application Insights doesn't provide this
facility directly, but it can send an alert when a metric crosses a threshold.
Alerts can be set on custom metrics, though not custom events. Write some code to increase a metric when the
event occurs:
telemetry.TrackMetric("Alarm", 10);
or:
var measurements = new Dictionary<string,double>();

measurements ["Alarm"] = 10;
telemetry.TrackEvent("status", null, measurements);
Because alerts have two states, you have to send a low value when you consider the alert to have ended:
telemetry.TrackMetric("Alarm", 0.5);
Create a chart in metric explorer to see your alarm:
Now set an alert to fire when the metric goes above a mid value for a short period:
Set the averaging period to the minimum.

You'll get emails both when the metric goes above and below the threshold.
Some points to consider:
An alert has two states ("alert" and "healthy"). The state is evaluated only when a metric is received.
An email is sent only when the state changes. This is why you have to send both high and low -value metrics.
To evaluate the alert, the average is taken of the received values over the preceding period. This occurs every
time a metric is received, so emails can be sent more frequently than the period you set.
Since emails are sent both on "alert" and "healthy", you might want to consider re-thinking your one-shot event
as a two-state condition. For example, instead of a "job completed" event, have a "job in progress" condition,
where you get emails at the start and end of a job.
Set up alerts automatically
Use PowerShell to create new alerts
Use PowerShell to Manage Application Insights

Create new resources
Create new alerts
Separate telemetry from different versions

Multiple roles in an app: Use a single Application Insights resource, and filter on cloud_Rolename.
Separating development, test, and release versions: Use different Application Insights resources. Pick up the
instrumentation keys from web.config. Learn more
Reporting build versions: Add a property using a telemetry initializer. Learn more
Monitor backend servers and desktop apps

Use the Windows Server SDK module.
Visualize data
Dashboard with metrics from multiple apps
In Metric Explorer, customize your chart and save it as a favorite. Pin it to the Azure dashboard.
Dashboard with data from other sources and Application Insights
Export telemetry to Power BI.
Or
Use SharePoint as your dashboard, displaying data in SharePoint web parts. Use continuous export and Stream
Analytics to export to SQL. Use PowerView to examine the database, and create a SharePoint web part for
PowerView.
Filter out anonymous or authenticated users
If your users sign in, you can set the authenticated user id. (It doesn't happen automatically.)
You can then:
Search on specific user ids
Filter metrics to either anonymous or authenticated users
Modify property names or values

Create a filter. This lets you modify or filter telemetry before it is sent from your app to Application Insights.
List specific users and their usage
If you just want to search for specific users, you can set the authenticated user id.
If you want a list of users with data such as what pages they look at or how often they log in, you have two options:
Set authenticated user id, export to a database and use suitable tools to analyze your user data there.
If you have only a small number of users, send custom events or metrics, using the data of interest as the metric
value or event name, and setting the user id as a property. To analyze page views, replace the standard
JavaScript trackPageView call. To analyze server-side telemetry, use a telemetry initializer to add the user id to
all server telemetry. You can then filter and segment metrics and searches on the user id.
Reduce traffic from my app to Application Insights

In ApplicationInsights.config, disable any modules you don't need, such the performance counter collector.
Use Sampling and filtering at the SDK.
In your web pages, Limit the number of Ajax calls reported for every page view. In the script snippet after
instrumentationKey:... , insert: ,maxAjaxCallsPerView:3 (or a suitable number ).
If you're using TrackMetric, compute the aggregate of batches of metric values before sending the result. There's
an overload of TrackMetric() that provides for that.
Learn more about pricing and quotas.
Disable telemetry
To dynamically stop and start the collection and transmission of telemetry from the server:
ASP.NET Classic applications
TelemetryConfiguration.Active.DisableTelemetry = true;
Other applications
It is not recommended to use TelemetryConfiguration.Active singleton on console or ASP.NET Core applications.
if you created TelemetryConfiguration instance yourself - set DisableTelemetry to true .
For ASP.NET Core applications you may access TelemetryConfiguration instance using ASP.NET Core
dependency injection. Please find more details in ApplicationInsights for ASP.NET Core applications article.
Disable selected standard collectors

You can disable standard collectors (for example, performance counters, HTTP requests, or dependencies)
ASP.NET applications - Delete or comment out the relevant lines in ApplicationInsights.config
ASP.NET Core applicaitons - Follow telemetry modules configuration options in ApplicationInsights
ASP.NET Core
View system performance counters

Among the metrics you can show in metrics explorer are a set of system performance counters. There's a
predefined blade titled Servers that displays several of them.
If you see no performance counter data
IIS server on your own machine or on a VM. Install Status Monitor.
Azure web site - we don't support performance counters yet. There are several metrics you can get as a
standard part of the Azure web site control panel.
Unix server - Install collectd
To display more performance counters
First, add a new chart and see if the counter is in the basic set that we offer.
If not, add the counter to the set collected by the performance counter module.
Export telemetry from Application Insights
Want to keep your telemetry for longer than the standard retention period? Or process it in some specialized
way? Continuous Export is ideal for this. The events you see in the Application Insights portal can be exported
to storage in Microsoft Azure in JSON format. From there, you can download your data and write whatever
code you need to process it.
Before you set up continuous export, there are some alternatives you might want to consider:
The Export button at the top of a metrics or search tab lets you transfer tables and charts to an Excel
spreadsheet.
Analytics provides a powerful query language for telemetry. It can also export results.
If you're looking to explore your data in Power BI, you can do that without using Continuous Export.
The Data access REST API lets you access your telemetry programmatically.
You can also access setup continuous export via Powershell.
After Continuous Export copies your data to storage (where it can stay for as long as you like), it's still available
in Application Insights for the usual retention period.
Continuous Export advanced storage configuration

Continuous Export does not support the following Azure storage features/configurations:
Use of VNET/Azure Storage firewalls in conjunction with Azure Blob storage.
Immutable storage for Azure Blob storage.
Azure Data Lake Storage Gen2.
Create a Continuous Export

1. In the Application Insights resource for your app under configure on the left, open Continuous Export
and choose Add:
2. Choose the telemetry data types you want to export.
3. Create or select an Azure storage account where you want to store the data. For more information on
storage pricing options, visit the official pricing page.
Click Add, Export Destination, Storage account, and then either create a new store or choose an existing
store.
WARNING
By default, the storage location will be set to the same geographical region as your Application Insights resource.
If you store in a different region, you may incur transfer charges.
4. Create or select a container in the storage.

Once you've created your export, it starts going. You only get data that arrives after you create the export.
There can be a delay of about an hour before data appears in the storage.
To edit continuous export
Click on continuous export and select the storage account to edit.
To stop continuous export
To stop the export, click Disable. When you click Enable again, the export will restart with new data. You won't
get the data that arrived in the portal while export was disabled.
To stop the export permanently, delete it. Doing so doesn't delete your data from storage.
Can't add or change an export?
To add or change exports, you need Owner, Contributor, or Application Insights Contributor access rights.
Learn about roles.
What events do you get?

The exported data is the raw telemetry we receive from your application, except that we add location data,
which we calculate from the client IP address.
Data that has been discarded by sampling is not included in the exported data.
Other calculated metrics are not included. For example, we don't export average CPU utilization, but we do
export the raw telemetry from which the average is computed.
The data also includes the results of any availability web tests that you have set up.
NOTE
Sampling. If your application sends a lot of data, the sampling feature may operate and send only a fraction of the
generated telemetry. Learn more about sampling.
Inspect the data

You can inspect the storage directly in the portal. Click home in the leftmost menu, at the top where it says
"Azure services" select Storage accounts, select the storage account name, on the overview page select Blobs
under services, and finally select the container name.
To inspect Azure storage in Visual Studio, open View, Cloud Explorer. (If you don't have that menu command,
you need to install the Azure SDK: Open the New Project dialog, expand Visual C#/Cloud and choose Get
Microsoft Azure SDK for .NET.)
When you open your blob store, you'll see a container with a set of blob files. The URI of each file derived from
your Application Insights resource name, its instrumentation key, telemetry-type/date/time. (The resource
name is all lowercase, and the instrumentation key omits dashes.)
The date and time are UTC and are when the telemetry was deposited in the store - not the time it was
generated. So if you write code to download the data, it can move linearly through the data.
Here's the form of the path:
$"{applicationName}_{instrumentationKey}/{type}/{blobDeliveryTimeUtc:yyyy-MM-dd}/{
blobDeliveryTimeUtc:HH}/{blobId}_{blobCreationTimeUtc:yyyyMMdd_HHmmss}.blob"
Where
blobCreationTimeUtc is time when blob was created in the internal staging storage
blobDeliveryTimeUtc is the time when blob is copied to the export destination storage
Data format
Each blob is a text file that contains multiple '\n'-separated rows. It contains the telemetry processed over a
time period of roughly half a minute.
Each row represents a telemetry data point such as a request or page view.
Each row is an unformatted JSON document. If you want to sit and stare at it, open it in Visual Studio and
choose Edit, Advanced, Format File:
Time durations are in ticks, where 10 000 ticks = 1 ms. For example, these values show a time of 1 ms to send a
request from the browser, 3 ms to receive it, and 1.8 s to process the page in the browser:
"sendRequest": {"value": 10000.0},

"receiveRequest": {"value": 30000.0},
"clientProcess": {"value": 17970000.0}
Detailed data model reference for the property types and values.
Processing the data

On a small scale, you can write some code to pull apart your data, read it into a spreadsheet, and so on. For
example:
private IEnumerable<T> DeserializeMany<T>(string folderName)

{
var files = Directory.EnumerateFiles(folderName, "*.blob", SearchOption.AllDirectories);
foreach (var file in files)
{
using (var fileReader = File.OpenText(file))
{
string fileContent = fileReader.ReadToEnd();
IEnumerable<string> entities = fileContent.Split('\n').Where(s => !string.IsNullOrWhiteSpace(s));
foreach (var entity in entities)
{
yield return JsonConvert.DeserializeObject<T>(entity);
}
}
}
}
For a larger code sample, see using a worker role.
Delete your old data

You are responsible for managing your storage capacity and deleting the old data if necessary.
If you regenerate your storage key...

If you change the key to your storage, continuous export will stop working. You'll see a notification in your
Azure account.
Open the Continuous Export tab and edit your export. Edit the Export Destination, but just leave the same
storage selected. Click OK to confirm.
The continuous export will restart.
Export samples
Stream Analytics sample 2
On larger scales, consider HDInsight - Hadoop clusters in the cloud. HDInsight provides a variety of
technologies for managing and analyzing big data, and you could use it to process data that has been exported
from Application Insights.
Q&A
But all I want is a one-time download of a chart.
Yes, you can do that. At the top of the tab, click Export Data.
I set up an export, but there's no data in my store.
Did Application Insights receive any telemetry from your app since you set up the export? You'll only
receive new data.
I tried to set up an export, but was denied access
If the account is owned by your organization, you have to be a member of the owners or contributors
groups.
Can I export straight to my own on-premises store?
No, sorry. Our export engine currently only works with Azure storage at this time.
Is there any limit to the amount of data you put in my store?
No. We'll keep pushing data in until you delete the export. We'll stop if we hit the outer limits for blob
storage, but that's pretty huge. It's up to you to control how much storage you use.
How many blobs should I see in the storage?
For every data type you selected to export, a new blob is created every minute (if data is available).
In addition, for applications with high traffic, additional partition units are allocated. In this case, each
unit creates a blob every minute.
I regenerated the key to my storage or changed the name of the container, and now the export doesn't
work.
Edit the export and open the export destination tab. Leave the same storage selected as before, and click
OK to confirm. Export will restart. If the change was within the past few days, you won't lose data.
Can I pause the export?
Yes. Click Disable.
Code samples
Stream Analytics sample
Use Stream Analytics to process exported data from
Azure Stream Analytics is the ideal tool for processing data exported from Application Insights. Stream Analytics
can pull data from a variety of sources. It can transform and filter the data, and then route it to a variety of sinks.
In this example, we'll create an adaptor that takes data from Application Insights, renames and processes some of
the fields, and pipes it into Power BI.
WARNING
There are much better and easier recommended ways to display Application Insights data in Power BI. The path illustrated
here is just an example to illustrate how to process exported data.
Create storage in Azure

Continuous export always outputs data to an Azure Storage account, so you need to create the storage first.
1. Create a "classic" storage account in your subscription in the Azure portal.
2. Create a container
3. Copy the storage access key

You'll need it soon to set up the input to the stream analytics service.
Start continuous export to Azure storage
Continuous export moves data from Application Insights into Azure storage.
1. In the Azure portal, browse to the Application Insights resource you created for your application.
2. Create a continuous export.
Select the storage account you created earlier:
Set the event types you want to see:

3. Let some data accumulate. Sit back and let people use your application for a while. Telemetry will come in
and you'll see statistical charts in metric explorer and individual events in diagnostic search.
And also, the data will export to your storage.
4. Inspect the exported data. In Visual Studio, choose View / Cloud Explorer, and open Azure / Storage. (If
you don't have this menu option, you need to install the Azure SDK: Open the New Project dialog and open
Visual C# / Cloud / Get Microsoft Azure SDK for .NET.)
Make a note of the common part of the path name, which is derived from the application name and
instrumentation key.
The events are written to blob files in JSON format. Each file may contain one or more events. So we'd like to read
the event data and filter out the fields we want. There are all kinds of things we could do with the data, but our
plan today is to use Stream Analytics to pipe the data to Power BI.
Create an Azure Stream Analytics instance

From the Azure portal, select the Azure Stream Analytics service, and create a new Stream Analytics job:
When the new job is created, select Go to resource.
Add a new input

Set it to take input from your Continuous Export blob:
Now you'll need the Primary Access Key from your Storage Account, which you noted earlier. Set this as the
Storage Account Key.
Set path prefix pattern
Be sure to set the Date Format to YYYY -MM -DD (with dashes).
The Path Prefix Pattern specifies where Stream Analytics finds the input files in the storage. You need to set it to
correspond to how Continuous Export stores the data. Set it like this:
webapplication27_12345678123412341234123456789abcdef0/PageViews/{date}/{time}
In this example:
webapplication27 is the name of the Application Insights resource all lower case.
1234... is the instrumentation key of the Application Insights resource, omitting dashes.
PageViews is the type of data you want to analyze. The available types depend on the filter you set in
Continuous Export. Examine the exported data to see the other available types, and see the export data model.
/{date}/{time} is a pattern written literally.
NOTE
Inspect the storage to make sure you get the path right.
Add new output

Now select your job > Outputs > Add.
Provide your work or school account to authorize Stream Analytics to access your Power BI resource. Then
invent a name for the output, and for the target Power BI dataset and table.
Set the query

The query governs the translation from input to output.
Use the Test function to check that you get the right output. Give it the sample data that you took from the inputs
page.
Query to display counts of events
Paste this query:
SELECT
flat.ArrayValue.name,
count(*)
INTO
[pbi-output]
FROM
[export-input] A
OUTER APPLY GetElements(A.[event]) as flat
GROUP BY TumblingWindow(minute, 1), flat.ArrayValue.name
export-input is the alias we gave to the stream input

pbi-output is the output alias we defined
We use OUTER APPLY GetElements because the event name is in a nested JSON array. Then the Select picks
the event name, together with a count of the number of instances with that name in the time period. The Group
By clause groups the elements into time periods of one minute.
Query to display metric values
SELECT
A.context.data.eventtime,
avg(CASE WHEN flat.arrayvalue.myMetric.value IS NULL THEN 0 ELSE flat.arrayvalue.myMetric.value END) as
myValue
INTO
[pbi-output]
FROM
[export-input] A
OUTER APPLY GetElements(A.context.custom.metrics) as flat
GROUP BY TumblingWindow(minute, 1), A.context.data.eventtime
This query drills into the metrics telemetry to get the event time and the metric value. The metric values are
inside an array, so we use the OUTER APPLY GetElements pattern to extract the rows. "myMetric" is the name
of the metric in this case.
Query to include values of dimension properties
WITH flat AS (
SELECT
MySource.context.data.eventTime as eventTime,
InstanceId = MyDimension.ArrayValue.InstanceId.value,
BusinessUnitId = MyDimension.ArrayValue.BusinessUnitId.value
FROM MySource
OUTER APPLY GetArrayElements(MySource.context.custom.dimensions) MyDimension
)
SELECT
eventTime,
InstanceId,
BusinessUnitId
INTO AIOutput
FROM flat
This query includes values of the dimension properties without depending on a particular dimension being at a
fixed index in the dimension array.
Run the job
You can select a date in the past to start the job from.
Wait until the job is Running.
See results in Power BI

WARNING
There are much better and easier recommended ways to display Application Insights data in Power BI. The path illustrated
here is just an example to illustrate how to process exported data.
Open Power BI with your work or school account, and select the dataset and table that you defined as the output
of the Stream Analytics job.
Now you can use this dataset in reports and dashboards in Power BI.
No data?
Check that you set the date format correctly to YYYY -MM -DD (with dashes).
Video
Noam Ben Zeev shows how to process exported data using Stream Analytics.
Next steps
Continuous export
Walkthrough: Export to SQL from Application
Insights using Stream Analytics
This article shows how to move your telemetry data from Azure Application Insights into an Azure SQL database
by using Continuous Export and Azure Stream Analytics.
Continuous export moves your telemetry data into Azure Storage in JSON format. We'll parse the JSON objects
using Azure Stream Analytics and create rows in a database table.
(More generally, Continuous Export is the way to do your own analysis of the telemetry your apps send to
Application Insights. You could adapt this code sample to do other things with the exported telemetry, such as
aggregation of data.)
We'll start with the assumption that you already have the app you want to monitor.
In this example, we will be using the page view data, but the same pattern can easily be extended to other data
types such as custom events and exceptions.
Add Application Insights to your application

To get started:
1. Set up Application Insights for your web pages.
(In this example, we'll focus on processing page view data from the client browsers, but you could also set
up Application Insights for the server side of your Java or ASP.NET app and process request, dependency
and other server telemetry.)
2. Publish your app, and watch telemetry data appearing in your Application Insights resource.
Create storage in Azure

Continuous export always outputs data to an Azure Storage account, so you need to create the storage first.
1. Create a storage account in your subscription in the Azure portal.
2. Create a container
3. Copy the storage access key

You'll need it soon to set up the input to the stream analytics service.
Start continuous export to Azure storage
1. In the Azure portal, browse to the Application Insights resource you created for your application.
2. Create a continuous export.
Select the storage account you created earlier:

Set the event types you want to see:
3. Let some data accumulate. Sit back and let people use your application for a while. Telemetry will come in
and you'll see statistical charts in metric explorer and individual events in diagnostic search.
And also, the data will export to your storage.
4. Inspect the exported data, either in the portal - choose Browse, select your storage account, and then
Containers - or in Visual Studio. In Visual Studio, choose View / Cloud Explorer, and open Azure /
Storage. (If you don't have this menu option, you need to install the Azure SDK: Open the New Project
dialog and open Visual C# / Cloud / Get Microsoft Azure SDK for .NET.)
Make a note of the common part of the path name, which is derived from the application name and
instrumentation key.
The events are written to blob files in JSON format. Each file may contain one or more events. So we'd like to
read the event data and filter out the fields we want. There are all kinds of things we could do with the data, but
our plan today is to use Stream Analytics to move the data to a SQL database. That will make it easy to run lots of
interesting queries.
Create an Azure SQL Database

Once again starting from your subscription in Azure portal, create the database (and a new server, unless you've
already got one) to which you'll write the data.
Make sure that the database server allows access to Azure services:
Create a table in Azure SQL DB

Connect to the database created in the previous section with your preferred management tool. In this
walkthrough, we will be using SQL Server Management Tools (SSMS ).
Create a new query, and execute the following T-SQL:
CREATE TABLE [dbo].[PageViewsTable](

[pageName] [nvarchar](max) NOT NULL,
[viewCount] [int] NOT NULL,
[url] [nvarchar](max) NULL,
[urlDataPort] [int] NULL,
[urlDataprotocol] [nvarchar](50) NULL,
[urlDataHost] [nvarchar](50) NULL,
[urlDataBase] [nvarchar](50) NULL,
[urlDataHashTag] [nvarchar](max) NULL,
[eventTime] [datetime] NOT NULL,
[isSynthetic] [nvarchar](50) NULL,
[deviceId] [nvarchar](50) NULL,
[deviceType] [nvarchar](50) NULL,
[os] [nvarchar](50) NULL,
[osVersion] [nvarchar](50) NULL,
[locale] [nvarchar](50) NULL,
[userAgent] [nvarchar](max) NULL,
[browser] [nvarchar](50) NULL,
[browserVersion] [nvarchar](50) NULL,
[screenResolution] [nvarchar](50) NULL,
[sessionId] [nvarchar](max) NULL,
[sessionIsFirst] [nvarchar](50) NULL,
[clientIp] [nvarchar](50) NULL,
[continent] [nvarchar](50) NULL,
[country] [nvarchar](50) NULL,
[province] [nvarchar](50) NULL,
[city] [nvarchar](50) NULL
)
CREATE CLUSTERED INDEX [pvTblIdx] ON [dbo].[PageViewsTable]

(
[eventTime] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
In this sample, we are using data from page views. To see the other data available, inspect your JSON output, and
see the export data model.
Create an Azure Stream Analytics instance

From the Azure portal, select the Azure Stream Analytics service, and create a new Stream Analytics job:
When the new job is created, select Go to resource.
Add a new input

Set it to take input from your Continuous Export blob:
Now you'll need the Primary Access Key from your Storage Account, which you noted earlier. Set this as the
Storage Account Key.
Set path prefix pattern
Be sure to set the Date Format to YYYY -MM -DD (with dashes).
The Path Prefix Pattern specifies how Stream Analytics finds the input files in the storage. You need to set it to
correspond to how Continuous Export stores the data. Set it like this:
webapplication27_12345678123412341234123456789abcdef0/PageViews/{date}/{time}
In this example:
webapplication27 is the name of the Application Insights resource, all in lower case.
1234... is the instrumentation key of the Application Insights resource with dashes removed.
PageViews is the type of data we want to analyze. The available types depend on the filter you set in
Continuous Export. Examine the exported data to see the other available types, and see the export data model.
/{date}/{time} is a pattern written literally.
To get the name and iKey of your Application Insights resource, open Essentials on its overview page, or open
Settings.
TIP
Use the Sample function to check that you have set the input path correctly. If it fails: Check that there is data in the
storage for the sample time range you chose. Edit the input definition and check you set the storage account, path prefix
and date format correctly.
Set query
Open the query section:
Replace the default query with:
SELECT flat.ArrayValue.name as pageName

, flat.ArrayValue.count as viewCount
, flat.ArrayValue.url as url
, flat.ArrayValue.urlData.port as urlDataPort
, flat.ArrayValue.urlData.protocol as urlDataprotocol
, flat.ArrayValue.urlData.host as urlDataHost
, flat.ArrayValue.urlData.base as urlDataBase
, flat.ArrayValue.urlData.hashTag as urlDataHashTag
,A.context.data.eventTime as eventTime
,A.context.data.isSynthetic as isSynthetic
,A.context.device.id as deviceId
,A.context.device.type as deviceType
,A.context.device.os as os
,A.context.device.osVersion as osVersion
,A.context.device.locale as locale
,A.context.device.userAgent as userAgent
,A.context.device.browser as browser
,A.context.device.browserVersion as browserVersion
,A.context.device.screenResolution.value as screenResolution
,A.context.session.id as sessionId
,A.context.session.isFirst as sessionIsFirst
,A.context.location.clientip as clientIp
,A.context.location.continent as continent
,A.context.location.country as country
,A.context.location.province as province
,A.context.location.city as city
INTO
AIOutput
FROM AIinput A
CROSS APPLY GetElements(A.[view]) as flat
Notice that the first few properties are specific to page view data. Exports of other telemetry types will have
different properties. See the detailed data model reference for the property types and values.
Set up output to database

Select SQL as the output.
Specify the SQL database.
Close the wizard and wait for a notification that the output has been set up.
Start processing
Start the job from the action bar:
You can choose whether to start processing the data starting from now, or to start with earlier data. The latter is
useful if you have had Continuous Export already running for a while.
After a few minutes, go back to SQL Server Management Tools and watch the data flowing in. For example, use a
query like this:
SELECT TOP 100 *

FROM [dbo].[PageViewsTable]
Related articles
Export to PowerBI using Stream Analytics
Continuous Export in Application Insights
Application Insights Export Data Model
This table lists the properties of telemetry sent from the Application Insights SDKs to the portal. You'll see these
properties in data output from Continuous Export. They also appear in property filters in Metric Explorer and
Diagnostic Search.
Points to note:
[0] in these tables denotes a point in the path where you have to insert an index; but it isn't always 0.
Time durations are in tenths of a microsecond, so 10000000 == 1 second.
Dates and times are UTC, and are given in the ISO format yyyy-MM-DDThh:mm:ss.sssZ
Example
// A server report about an HTTP request
{
"request": [
{
"urlData": { // derived from 'url'
"host": "contoso.org",
"base": "/",
"hashTag": ""
},
"responseCode": 200, // Sent to client
"success": true, // Default == responseCode<400
// Request id becomes the operation id of child events
"id": "fCOhCdCnZ9I=",
"name": "GET Home/Index",
"count": 1, // 100% / sampling rate
"durationMetric": {
"value": 1046804.0, // 10000000 == 1 second
// Currently the following fields are redundant:
"count": 1.0,
"min": 1046804.0,
"max": 1046804.0,
"stdDev": 0.0,
"sampledValue": 1046804.0
},
"url": "/"
}
],
"internal": {
"data": {
"id": "7f156650-ef4c-11e5-8453-3f984b167d05",
"documentVersion": "1.61"
}
},
"context": {
"device": { // client browser
"type": "PC",
"screenResolution": { },
"roleInstance": "WFWEB14B.fabrikam.net"
},
"application": { },
"location": { // derived from client ip
"continent": "North America",
"country": "United States",
// last octagon is anonymized to 0 at portal:
"clientip": "168.62.177.0",
"clientip": "168.62.177.0",
"province": "",
"city": ""
},
"data": {
"isSynthetic": true, // we identified source as a bot
// percentage of generated data sent to portal:
"samplingRate": 100.0,
"eventTime": "2016-03-21T10:05:45.7334717Z" // UTC
},
"user": {
"isAuthenticated": false,
"anonId": "us-tx-sn1-azr", // bot agent id
"anonAcquisitionDate": "0001-01-01T00:00:00Z",
"authAcquisitionDate": "0001-01-01T00:00:00Z",
"accountAcquisitionDate": "0001-01-01T00:00:00Z"
},
"operation": {
"id": "fCOhCdCnZ9I=",
"parentId": "fCOhCdCnZ9I=",
"name": "GET Home/Index"
},
"cloud": { },
"serverDevice": { },
"custom": { // set by custom fields of track calls
"dimensions": [ ],
"metrics": [ ]
},
"session": {
"id": "65504c10-44a6-489e-b9dc-94184eb00d86",
"isFirst": true
}
}
Context
All types of telemetry are accompanied by a context section. Not all of these fields are transmitted with every
data point.
PATH TYPE NOTES
context.custom.dimensions [0] object [ ] Key-value string pairs set by custom

properties parameter. Key max length
100, values max length 1024. More
than 100 unique values, the property
can be searched but cannot be used
for segmentation. Max 200 keys per
ikey.
context.custom.metrics [0] object [ ] Key-value pairs set by custom

measurements parameter and by
TrackMetrics. Key max length 100,
values may be numeric.
context.data.eventTime string UTC
context.data.isSynthetic boolean Request appears to come from a bot or

web test.
PATH TYPE NOTES
context.data.samplingRate number Percentage of telemetry generated by

the SDK that is sent to portal. Range
0.0-100.0.
context.device object Client device
context.device.browser string IE, Chrome, ...
context.device.browserVersion string Chrome 48.0, ...
context.device.deviceModel string
context.device.deviceName string
context.device.id string
context.device.locale string en-GB, de-DE, ...
context.device.network string
context.device.oemName string
context.device.os string
context.device.osVersion string Host OS
context.device.roleInstance string ID of server host
context.device.roleName string
context.device.screenResolution string
context.device.type string PC, Browser, ...
context.location object Derived from clientip.
context.location.city string Derived from clientip, if known
context.location.clientip string Last octagon is anonymized to 0.
context.location.continent string
context.location.country string
context.location.province string State or province
context.operation.id string Items that have the same operation id

are shown as Related Items in the
portal. Usually the request id.
context.operation.name string url or request name

PATH TYPE NOTES
context.operation.parentId string Allows nested related items.
context.session.id string Id of a group of operations from the

same source. A period of 30 minutes
without an operation signals the end of
a session.
context.session.isFirst boolean
context.user.accountAcquisitionDate string
context.user.accountId string
context.user.anonAcquisitionDate string
context.user.anonId string
context.user.authAcquisitionDate string Authenticated User
context.user.authId string
context.user.isAuthenticated boolean
context.user.storeRegion string
internal.data.documentVersion string
internal.data.id string Unique id that is assigned when an

item is ingested to Application Insights
Events
Custom events generated by TrackEvent().
PATH TYPE NOTES
event [0] count integer 100/(sampling rate). For example 4 =>

25%.
event [0] name string Event name. Max length 250.
event [0] url string
event [0] urlData.base string
event [0] urlData.host string
Exceptions
Reports exceptions in the server and in the browser.
PATH TYPE NOTES
basicException [0] assembly string
basicException [0] count integer 100/(sampling rate). For example 4 =>

25%.
basicException [0] exceptionGroup string
basicException [0] exceptionType string
basicException [0] string

failedUserCodeMethod

failedUserCodeAssembly
basicException [0] handledAt string
basicException [0] hasFullStack boolean
basicException [0] id string
basicException [0] method string
basicException [0] message string Exception message. Max length 10k.

outerExceptionMessage

outerExceptionThrownAtAssembly

outerExceptionThrownAtMethod
basicException [0] outerExceptionType string
basicException [0] outerId string
basicException [0] parsedStack [0] string

assembly

fileName
basicException [0] parsedStack [0] level integer
basicException [0] parsedStack [0] line integer

method
basicException [0] stack string Max length 10k

PATH TYPE NOTES
basicException [0] typeName string
Trace Messages
Sent by TrackTrace, and by the logging adapters.
PATH TYPE NOTES
message [0] loggerName string
message [0] parameters string
message [0] raw string The log message, max length 10k.
message [0] severityLevel string
Remote dependency
Sent by TrackDependency. Used to report performance and usage of calls to dependencies in the server, and
AJAX calls in the browser.
PATH TYPE NOTES
remoteDependency [0] async boolean
remoteDependency [0] baseName string
remoteDependency [0] string For example "home/index"

commandName
remoteDependency [0] count integer 100/(sampling rate). For example 4 =>

25%.
remoteDependency [0] string HTTP, SQL, ...

dependencyTypeName
remoteDependency [0] number Time from call to completion of

durationMetric.value response by dependency
remoteDependency [0] id string
remoteDependency [0] name string Url. Max length 250.
remoteDependency [0] resultCode string from HTTP dependency
remoteDependency [0] success boolean
remoteDependency [0] type string Http, Sql,...
remoteDependency [0] url string Max length 2000

PATH TYPE NOTES
remoteDependency [0] urlData.base string Max length 2000
remoteDependency [0] string

urlData.hashTag
remoteDependency [0] urlData.host string Max length 200
Requests
Sent by TrackRequest. The standard modules use this to reports server response time, measured at the server.
PATH TYPE NOTES
request [0] count integer 100/(sampling rate). For example: 4 =>

25%.
request [0] durationMetric.value number Time from request arriving to response.

1e7 == 1s
request [0] id string Operation id
request [0] name string GET/POST + url base. Max length 250
request [0] responseCode integer HTTP response sent to client
request [0] success boolean Default == (responseCode < 400)
request [0] url string Not including host
request [0] urlData.base string
request [0] urlData.hashTag string
request [0] urlData.host string
Page View Performance

Sent by the browser. Measures the time to process a page, from user initiating the request to display complete
(excluding async AJAX calls).
Context values show client OS and browser version.
PATH TYPE NOTES
clientPerformance [0] integer Time from end of receiving the HTML

clientProcess.value to displaying the page.
clientPerformance [0] name string
clientPerformance [0] integer Time taken to establish a network

networkConnection.value connection.
PATH TYPE NOTES
clientPerformance [0] integer Time from end of sending the request

receiveRequest.value to receiving the HTML in reply.
clientPerformance [0] integer Time from taken to send the HTTP

sendRequest.value request.
clientPerformance [0] total.value integer Time from starting to send the request
to displaying the page.
clientPerformance [0] url string URL of this request
clientPerformance [0] urlData.base string
clientPerformance [0] urlData.hashTag string
clientPerformance [0] urlData.host string
clientPerformance [0] urlData.protocol string
Page Views
Sent by trackPageView () or stopTrackPage
PATH TYPE NOTES
view [0] count integer 100/(sampling rate). For example 4 =>

25%.
view [0] durationMetric.value integer Value optionally set in trackPageView()

or by startTrackPage() -
stopTrackPage(). Not the same as
clientPerformance values.
view [0] name string Page title. Max length 250
view [0] url string
view [0] urlData.base string
view [0] urlData.hashTag string
view [0] urlData.host string
Availability
Reports availability web tests.
PATH TYPE NOTES
availability [0] availabilityMetric.name string availability

PATH TYPE NOTES
availability [0] availabilityMetric.value number 1.0 or 0.0
availability [0] count integer 100/(sampling rate). For example 4 =>

25%.
availability [0] dataSizeMetric.name string
availability [0] dataSizeMetric.value integer
availability [0] durationMetric.name string
availability [0] durationMetric.value number Duration of test. 1e7==1s
availability [0] message string Failure diagnostic
availability [0] result string Pass/Fail
availability [0] runLocation string Geo source of http req
availability [0] testName string
availability [0] testRunId string
availability [0] testTimestamp string
Metrics
Generated by TrackMetric().
The metric value is found in context.custom.metrics[0]
For example:
{
"metric": [ ],
"context": {
...
"custom": {
"dimensions": [
{ "ProcessId": "4068" }
],
"metrics": [
{
"dispatchRate": {
"value": 0.001295,
"count": 1.0,
"min": 0.001295,
"max": 0.001295,
"stdDev": 0.0,
"sampledValue": 0.001295,
"sum": 0.001295
}
}
} ] }
}
About metric values
Metric values, both in metric reports and elsewhere, are reported with a standard object structure. For example:
"durationMetric": {
"name": "contoso.org",
"type": "Aggregation",
"value": 468.71603053650279,
"count": 1.0,
"min": 468.71603053650279,
"max": 468.71603053650279,
"stdDev": 0.0,
"sampledValue": 468.71603053650279
}
Currently - though this might change in the future - in all values reported from the standard SDK modules,
count==1 and only the name and value fields are useful. The only case where they would be different would be
if you write your own TrackMetric calls in which you set the other parameters.
The purpose of the other fields is to allow metrics to be aggregated in the SDK, to reduce traffic to the portal. For
example, you could average several successive readings before sending each metric report. Then you would
calculate the min, max, standard deviation and aggregate value (sum or average) and set count to the number of
readings represented by the report.
In the tables above, we have omitted the rarely-used fields count, min, max, stdDev and sampledValue.
Instead of pre-aggregating metrics, you can use sampling if you need to reduce the volume of telemetry.
Durations
Except where otherwise noted, durations are represented in tenths of a microsecond, so that 10000000.0 means
1 second.
See also
Continuous Export
Code samples
Debug your applications with Azure Application
Insights in Visual Studio
In Visual Studio (2015 and later), you can analyze performance and diagnose issues in your ASP.NET web app
both in debugging and in production, using telemetry from Azure Application Insights.
If you created your ASP.NET web app using Visual Studio 2017 or later, it already has the Application Insights
SDK. Otherwise, if you haven't done so already, add Application Insights to your app.
To monitor your app when it's in live production, you normally view the Application Insights telemetry in the
Azure portal, where you can set alerts and apply powerful monitoring tools. But for debugging, you can also
search and analyze the telemetry in Visual Studio. You can use Visual Studio to analyze telemetry both from your
production site and from debugging runs on your development machine. In the latter case, you can analyze
debugging runs even if you haven't yet configured the SDK to send telemetry to the Azure portal.
Debug your project

Run your web app in local debug mode by using F5. Open different pages to generate some telemetry.
In Visual Studio, you see a count of the events that have been logged by the Application Insights module in your
project.
Click this button to search your telemetry.
Application Insights search

The Application Insights Search window shows events that have been logged. (If you signed in to Azure when you
set up Application Insights, you can search the same events in the Azure portal.)
NOTE
After you select or deselect filters, click the Search button at the end of the text search field.
The free text search works on any fields in the events. For example, search for part of the URL of a page; or the
value of a property such as client city; or specific words in a trace log.
Click any event to see its detailed properties.
For requests to your web app, you can click through to the code.
You can also open related items to help diagnose failed requests or exceptions.
View exceptions and failed requests
Exception reports show in the Search window. (In some older types of ASP.NET application, you have to set up
exception monitoring to see exceptions that are handled by the framework.)
Click an exception to get a stack trace. If the code of the app is open in Visual Studio, you can click through from
the stack trace to the relevant line of the code.
View request and exception summaries in the code

In the Code Lens line above each handler method, you see a count of the requests and exceptions logged by
Application Insights in the past 24 h.
NOTE
Code Lens shows Application Insights data only if you have configured your app to send telemetry to the Application
Insights portal.
More about Application Insights in Code Lens
Trends
Trends is a tool for visualizing how your app behaves over time.
Choose Explore Telemetry Trends from the Application Insights toolbar button or Application Insights Search
window. Choose one of five common queries to get started. You can analyze different datasets based on telemetry
types, time ranges, and other properties.
To find anomalies in your data, choose one of the anomaly options under the "View Type" dropdown. The filtering
options at the bottom of the window make it easy to hone in on specific subsets of your telemetry.
More about Trends.
Local monitoring
(From Visual Studio 2015 Update 2) If you haven't configured the SDK to send telemetry to the Application
Insights portal (so that there is no instrumentation key in ApplicationInsights.config) then the diagnostics window
displays telemetry from your latest debugging session.
This is desirable if you have already published a previous version of your app. You don't want the telemetry from
your debugging sessions to be mixed up with the telemetry on the Application Insights portal from the published
app.
It's also useful if you have some custom telemetry that you want to debug before sending telemetry to the portal.
At first, I fully configured Application Insights to send telemetry to the portal. But now I'd like to see the
telemetry only in Visual Studio.
In the Search window's Settings, there's an option to search local diagnostics even if your app sends
telemetry to the portal.
To stop telemetry being sent to the portal, comment out the line <instrumentationkey>... from
ApplicationInsights.config. When you're ready to send telemetry to the portal again, uncomment it.
Next steps
Add more data

Monitor usage, availability, dependencies, exceptions.
Integrate traces from logging frameworks. Write custom
telemetry.
Working with the Application Insights portal

View dashboards, powerful diagnostic and analytic tools,
alerts, a live dependency map of your application, and
exported telemetry data.
Analyzing Trends in Visual Studio
The Application Insights Trends tool visualizes how your web application's important telemetry events change
over time, helping you quickly identify problems and anomalies. By linking you to more detailed diagnostic
information, Trends can help you improve your app's performance, track down the causes of exceptions, and
uncover insights from your custom events.
Configure your web app for Application Insights

If you haven't done this already, configure your web app for Application Insights. This allows it to send telemetry
to the Application Insights portal. The Trends tool reads the telemetry from there.
Application Insights Trends is available in Visual Studio 2015 Update 3 and later.
Open Application Insights Trends

To open the Application Insights Trends window:
From the Application Insights toolbar button, choose Explore Telemetry Trends, or
From the project context menu, choose Application Insights > Explore Telemetry Trends, or
From the Visual Studio menu bar, choose View > Other Windows > Application Insights Trends.
You may see a prompt to select a resource. Click Select a resource, sign in with an Azure subscription, then
choose an Application Insights resource from the list for which you'd like to analyze telemetry trends.
Choose a trend analysis

Get started by choosing from one of five common trend analyses, each analyzing data from the last 24 hours:
Investigate performance issues with your server requests - Requests made to your service, grouped by
response times
Analyze errors in your server requests - Requests made to your service, grouped by HTTP response code
Examine the exceptions in your application - Exceptions from your service, grouped by exception type
Check the performance of your application's dependencies - Services called by your service, grouped by
response times
Inspect your custom events - Custom events you've set up for your service, grouped by event type.
These pre-built analyses are available later from the View common types of telemetry analysis button in the
upper-left corner of the Trends window.
Visualize trends in your application

Application Insights Trends creates a time series visualization from your app's telemetry. Each time series
visualization displays one type of telemetry, grouped by one property of that telemetry, over some time range. For
example, you might want to view server requests, grouped by the country from which they originated, over the
last 24 hours. In this example, each bubble on the visualization would represent a count of the server requests for
some country/region during one hour.
Use the controls at the top of the window to adjust what types of telemetry you view. First, choose the telemetry
types in which you're interested:
Telemetry Type - Server requests, exceptions, dependencies, or custom events
Time Range - Anywhere from the last 30 minutes to the last 3 days
Group By - Exception type, problem ID, country/region, and more.
Then, click Analyze Telemetry to run the query.
To navigate between bubbles in the visualization:
Click to select a bubble, which updates the filters at the bottom of the window, summarizing just the events that
occurred during a specific time period
Double-click a bubble to navigate to the Search tool and see all of the individual telemetry events that occurred
during that time period
Ctrl-click a bubble to de-select it in the visualization.
TIP
The Trends and Search tools work together to help you pinpoint the causes of issues in your service among thousands of
telemetry events. For example, if one afternoon your customers notice your app is being less responsive, start with Trends.
Analyze requests made to your service over the past several hours, grouped by response time. See if there's an unusually
large cluster of slow requests. Then double click that bubble to go to the Search tool, filtered to those request events. From
Search, you can explore the contents of those requests and navigate to the code involved to resolve the issue.
Filter
Discover more specific trends with the filter controls at the bottom of the window. To apply a filter, click on its
name. You can quickly switch between different filters to discover trends that may be hiding in a particular
dimension of your telemetry. If you apply a filter in one dimension, like Exception Type, filters in other dimensions
remain clickable even though they appear grayed-out. To un-apply a filter, click it again. Ctrl-click to select multiple
filters in the same dimension.
What if you want to apply multiple filters?

1. Apply the first filter.
2. Click the Apply selected filters and query again button by the name of the dimension of your first filter. This
will re-query your telemetry for only events that match the first filter.
3. Apply a second filter.
4. Repeat the process to find trends in specific subsets of your telemetry. For example, server requests named
"GET Home/Index" and that came from Germany and that received a 500 response code.
To un-apply one of these filters, click the Remove selected filters and query again button for the dimension.
Find anomalies
The Trends tool can highlight bubbles of events that are anomalous compared to other bubbles in the same time
series. In the View Type dropdown, choose Counts in time bucket (highlight anomalies) or Percentages in
time bucket (highlight anomalies). Red bubbles are anomalous. Anomalies are defined as bubbles with
counts/percentages exceeding 2.1 times the standard deviation of the counts/percentages that occurred in the past
two time periods (48 hours if you're viewing the last 24 hours, etc.).
TIP
Highlighting anomalies is especially helpful for finding outliers in time series of small bubbles that may otherwise look
similarly sized.
Next steps

Search telemetry, see data in CodeLens, and configure
Application Insights. All within Visual Studio.
Add more data

telemetry.
Dashboards, powerful diagnostic and analytic tools, alerts, a
live dependency map of your application, and telemetry
export.
Application Insights telemetry in Visual Studio
CodeLens
Methods in the code of your web app can be annotated with telemetry about run-time exceptions and request
response times. If you install Azure Application Insights in your application, the telemetry appears in Visual Studio
CodeLens - the notes at the top of each function where you're used to seeing useful information such as the
number of places the function is referenced or the last person who edited it.
NOTE
Application Insights in CodeLens is available in Visual Studio 2015 Update 3 and later, or with the latest version of Developer
Analytics Tools extension. CodeLens is available in the Enterprise and Professional editions of Visual Studio.
Where to find Application Insights data

Look for Application Insights telemetry in the CodeLens indicators of the public request methods of your web
application. CodeLens indicators are shown above method and other declarations in C# and Visual Basic code. If
Application Insights data is available for a method, you'll see indicators for requests and exceptions such as "100
requests, 1% failed" or "10 exceptions." Click a CodeLens indicator for more details.
TIP
Application Insights request and exception indicators may take a few extra seconds to load after other CodeLens indicators
appear.
Exceptions in CodeLens
The exception CodeLens indicator shows the number of exceptions that have occurred in the past 24 hours from
the 15 most frequently occurring exceptions in your application during that period, while processing the request
served by the method.
To see more details, click the exceptions CodeLens indicator:
The percentage change in number of exceptions from the most recent 24 hours relative to the prior 24 hours
Choose Go to code to navigate to the source code for the function throwing the exception
Choose Search to query all instances of this exception that have occurred in the past 24 hours
Choose Trend to view a trend visualization for occurrences of this exception in the past 24 hours
Choose View all exceptions in this app to query all exceptions that have occurred in the past 24 hours
Choose Explore exception trends to view a trend visualization for all exceptions that have occurred in the
past 24 hours.
TIP
If you see "0 exceptions" in CodeLens but you know there should be exceptions, check to make sure the right Application
Insights resource is selected in CodeLens. To select another resource, right-click on your project in the Solution Explorer and
choose Application Insights > Choose Telemetry Source. CodeLens is only shown for the 15 most frequently occurring
exceptions in your application in the past 24 hours, so if an exception is the 16th most frequently or less, you'll see "0
exceptions." Exceptions from ASP.NET views may not appear on the controller methods that generated those views.
TIP
If you see "? exceptions" in CodeLens, you need to associate your Azure account with Visual Studio or your Azure account
credential may have expired. In either case, click "? exceptions" and choose Add an account... to enter your credentials.
Requests in CodeLens
The request CodeLens indicator shows the number of HTTP requests that been serviced by a method in the past
24 hours, plus the percentage of those requests that failed.
To see more details, click the requests CodeLens indicator:
The absolute and percentage changes in number of requests, failed requests, and average response times over
the past 24 hours compared to the prior 24 hours
The reliability of the method, calculated as the percentage of requests that did not fail in the past 24 hours
Choose Search for requests or failed requests to query all the (failed) requests that occurred in the past 24
hours
Choose Trend to view a trend visualization for requests, failed requests, or average response times in the past
24 hours.
Choose the name of the Application Insights resource in the upper left corner of the CodeLens details view to
change which resource is the source for CodeLens data.
Next steps
Search telemetry, see data in CodeLens, and configure
Application Insights. All within Visual Studio.
Add more data

telemetry.

Dashboards, powerful diagnostic and analytic tools, alerts, a
live dependency map of your application, and telemetry
export.
Monitor a SharePoint site with Application Insights
Azure Application Insights monitors the availability, performance and usage of your apps. Here you'll learn how to
set it up for a SharePoint site.

In the Azure portal, create a new Application Insights resource. Choose ASP.NET as the application type.
The window that opens is the place where you'll see performance and usage data about your app. To get back to it
next time you login to Azure, you should find a tile for it on the start screen. Alternatively click Browse to find it.
Add the script to your web pages


var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c=
{config:a},d=document,e=window;setTimeout(function(){var
b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTag
Name("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=
["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthentic
atedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPag
e"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var
g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<your instrumentation key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
</script>
Insert the script just before the </head> tag of every page you want to track. If your website has a master page,
you can put the script there. For example, in an ASP.NET MVC project, you'd put it in View\Shared_Layout.cshtml
The script contains the instrumentation key that directs the telemetry to your Application Insights resource.
Add the code to your site pages
On the master page
If you can edit the site's master page, that will provide monitoring for every page in the site.
Check out the master page and edit it using SharePoint Designer or any other editor.
Add the code just before the tag.

Or on individual pages
To monitor a limited set of pages, add the script separately to each page.
Insert a web part and embed the code snippet in it.
View data about your app

Redeploy your app.
Return to your application blade in the Azure portal.
The first events will appear in Search.
Click Refresh after a few seconds if you're expecting more data.
Capturing User Id
The standard web page code snippet doesn't capture the user id from SharePoint, but you can do that with a small
modification.
1. Copy your app's instrumentation key from the Essentials drop-down in Application Insights.
2. Substitute the instrumentation key for 'XXXX' in the snippet below.

3. Embed the script in your SharePoint app instead of the snippet you get from the portal.
<SharePoint:ScriptLink ID="ScriptLink1" name="SP.js" runat="server" localizable="false" loadafterui="true" />
<SharePoint:ScriptLink ID="ScriptLink2" name="SP.UserProfiles.js" runat="server" localizable="false"
loadafterui="true" />
var personProperties;
// Ensure that the SP.UserProfiles.js file is loaded before the custom code runs.
SP.SOD.executeOrDelayUntilScriptLoaded(getUserProperties, 'SP.UserProfiles.js');
function getUserProperties() {
// Get the current client context and PeopleManager instance.
var clientContext = new SP.ClientContext.get_current();
var peopleManager = new SP.UserProfiles.PeopleManager(clientContext);
// Get user properties for the target user.

// To get the PersonProperties object for the current user, use the
// getMyProperties method.
personProperties = peopleManager.getMyProperties();
// Load the PersonProperties object and send the request.

clientContext.load(personProperties);
clientContext.executeQueryAsync(onRequestSuccess, onRequestFail);
}
// This function runs if the executeQueryAsync call succeeds.

function onRequestSuccess() {
var appInsights=window.appInsights||function(config){
function s(config){t[config]=function(){var i=arguments;t.queue.push(function(){t[config].apply(t,i)})}}var t=
{config:config},r=document,f=window,e="script",o=r.createElement(e),i,u;for(o.src=config.url||"//az416426.vo.m
secnd.net/scripts/a/ai.0.js",r.getElementsByTagName(e)[0].parentNode.appendChild(o),t.cookie=r.cookie,t.queue=
[],i=["Event","Exception","Metric","PageView","Trace"];i.length;)s("track"+i.pop());return
config.disableExceptionTracking||(i="onerror",s("_"+i),u=f[i],f[i]=function(config,r,f,e,o){var
s=u&&u(config,r,f,e,o);return s!==!0&&t["_"+i](config,r,f,e,o),s}),t
}({
instrumentationKey:"XXXX"
});
appInsights.trackPageView(document.title,window.location.href, {User:
personProperties.get_displayName()});
}
// This function runs if the executeQueryAsync call fails.

function onRequestFail(sender, args) {
}
</script>
Next Steps
Web tests to monitor the availability of your site.
Application Insights for other types of app.
Monitoring usage and performance in Classic
Windows Desktop apps
Applications hosted on premises, in Azure, and in other clouds can all take advantage of Application Insights. The
only limitation is the need to allow communication to the Application Insights service. For monitoring Universal
Windows Platform (UWP ) applications, we recommend Visual Studio App Center.
To send telemetry to Application Insights from a Classic Windows

application
1. In the Azure portal, create an Application Insights resource. For application type, choose ASP.NET app.
2. Take a copy of the Instrumentation Key. Find the key in the Essentials drop-down of the new resource you
just created.
3. In Visual Studio, edit the NuGet packages of your app project, and add
Microsoft.ApplicationInsights.WindowsServer. (Or choose Microsoft.ApplicationInsights if you just want
the bare API, without the standard telemetry collection modules.)
4. Set the instrumentation key either in your code:
TelemetryConfiguration.Active.InstrumentationKey = " your key ";
or in ApplicationInsights.config (if you installed one of the standard telemetry packages):

<InstrumentationKey> your key </InstrumentationKey>
If you use ApplicationInsights.config, make sure its properties in Solution Explorer are set to Build Action
= Content, Copy to Output Directory = Copy.
5. Use the API to send telemetry.
6. Run your app, and see the telemetry in the resource you created in the Azure portal.
Example code
public partial class Form1 : Form

{
private TelemetryClient tc = new TelemetryClient();
...
private void Form1_Load(object sender, EventArgs e)
{
// Alternative to setting ikey in config file:
tc.InstrumentationKey = "key copied from portal";
// Set session data:

tc.Context.Session.Id = Guid.NewGuid().ToString();
tc.Context.Device.OperatingSystem = Environment.OSVersion.ToString();
// Log a page view:

tc.TrackPageView("Form1");
...
}
protected override void OnClosing(System.ComponentModel.CancelEventArgs e)

{
e.Cancel = true;
if (tc != null)
{
tc.Flush(); // only for desktop apps
// Allow time for flushing:

System.Threading.Thread.Sleep(1000);
}
base.OnClosing(e);
}
Next steps
Create a dashboard
Diagnostic Search
Explore metrics
Write Analytics queries
Azure Monitor for containers overview
Azure Monitor for containers is a feature designed to monitor the performance of container workloads deployed
to either Azure Container Instances or managed Kubernetes clusters hosted on Azure Kubernetes Service (AKS ).
Monitoring your containers is critical, especially when you're running a production cluster, at scale, with multiple
applications.
Azure Monitor for containers gives you performance visibility by collecting memory and processor metrics from
controllers, nodes, and containers that are available in Kubernetes through the Metrics API. Container logs are
also collected. After you enable monitoring from Kubernetes clusters, metrics and logs are automatically
collected for you through a containerized version of the Log Analytics agent for Linux. Metrics are written to the
metrics store and log data is written to the logs store associated with your Log Analytics workspace.
What does Azure Monitor for containers provide?

Azure Monitor for containers delivers a comprehensive monitoring experience using different features of Azure
Monitor enabling you to understand the performance and health of your Kubernetes cluster and the container
workloads. With Azure Monitor for containers you can:
Identify AKS containers that are running on the node and their average processor and memory utilization.
This knowledge can help you identify resource bottlenecks.
Identify processor and memory utilization of container groups and their containers hosted in Azure
Container Instances.
Identify where the container resides in a controller or a pod. This knowledge can help you view the
controller's or pod's overall performance.
Review the resource utilization of workloads running on the host that are unrelated to the standard
processes that support the pod.
Understand the behavior of the cluster under average and heaviest loads. This knowledge can help you
identify capacity needs and determine the maximum load that the cluster can sustain.
Configure alerts to proactively notify you or record it when CPU and memory utilization on nodes or
containers exceed your thresholds.
Integrate with Prometheus to view application and workload metrics it collects from nodes and
Kubernetes using queries to create custom alerts, dashboards, and detailed perform detailed analysis.
NOTE
Support for Prometheus is a feature in public preview at this time.
Monitor container workloads deployed to AKS -engine.

Check out the following video providing an intermediate level deep dive to help you learn about monitoring your
AKS cluster with Azure Monitor for containers.
How do I access this feature?

You can access Azure Monitor for containers two ways, from Azure Monitor or directly from the selected AKS
cluster. From Azure Monitor, you have a global perspective of all the containers deployed, which are monitored
and which are not, allowing you to search and filter across your subscriptions and resource groups, and then drill
into Azure Monitor for containers from the selected container. Otherwise, you can access the feature directly
from a selected AKS container from the AKS page.
If you are interested in monitoring and managing your Docker and Windows container hosts running outside of
AKS to view configuration, audit, and resource utilization, see the Container Monitoring solution.
Next steps
To begin monitoring your AKS cluster, review How to enable the Azure Monitor for containers to understand the
requirements and available methods to enable monitoring.
Azure Monitor for containers Frequently Asked
Questions
This Microsoft FAQ is a list of commonly asked questions about Azure Monitor for containers. If you have any
additional questions about the solution, go to the discussion forum and post your questions. When a question is
frequently asked, we add it to this article so that it can be found quickly and easily.
Can I monitor my AKS-engine cluster with Azure Monitor for

containers?
Azure Monitor for containers supports monitoring container workloads deployed to AKS -engine (formerly known
as ACS -engine) cluster(s) hosted on Azure. For further details and an overview of steps required to enable
monitoring for this scenario, see Using Azure Monitor for containers for AKS -engine.
Why don't I see data in my Log Analytics workspace?

If you are unable to see any data in the Log Analytics workspace at a certain time everyday, you may have reached
the default 500 MB limit or the daily cap specified to control the amount of data to collect daily. When the limit is
met for the day, data collection stops and resumes only on the next day. To review your data usage and update to a
different pricing tier based on your anticipated usage patterns, see Log data usage and cost.
What are the container states specified in the ContainerInventory

table?
The ContainerInventory table contains information about both stopped and running containers. The table is
populated by a workflow inside the agent that queries the docker for all the containers (running and stopped), and
forwards that data the Log Analytics workspace.
How do I resolve Missing Subscription registration error?

If you receive the error Missing Subscription registration for Microsoft.OperationsManagement, you can
resolve it by registering the resource provider Microsoft.OperationsManagement in the subscription where the
workspace is defined. The documentation for how to do this can be found here.
Is there support for RBAC enabled AKS clusters?

The Container Monitoring solution doesn’t support RBAC, but it is supported with Azure Monitor for Containers.
The solution details page may not show the right information in the blades that show data for these clusters.
How do I enable log collection for containers in the kube-system

namespace through Helm?
The log collection from containers in the kube-system namespace is disabled by default. Log collection can be
enabled by setting an environment variable on the omsagent. For more information, see the Azure Monitor for
containers GitHub page.
How do I update the omsagent to the latest released version?
To learn how to upgrade the agent, see Agent management.
How do I enable multi-line logging?

Currently Azure Monitor for containers doesn’t support multi-line logging, but there are workarounds available.
You can configure all the services to write in JSON format and then Docker/Moby will write them as a single line.
For example, you can wrap your log as a JSON object as shown in the example below for a sample node.js
application:
console.log(json.stringify({
"Hello": "This example has multiple lines:",
"Docker/Moby": "will not break this into multiple lines",
"and you will receive":"all of them in log analytics",
"as one": "log entry"
}));
This data will look like the following example in Azure Monitor for logs when you query for it:
LogEntry : ({“Hello": "This example has multiple lines:","Docker/Moby": "will not break this into multiple
lines", "and you will receive":"all of them in log analytics", "as one": "log entry"}
For a detailed look at the issue, review the following GitHub link.
How do I resolve Azure AD errors when I enable live logs?

You may see the following error: The reply url specified in the request does not match the reply urls
configured for the application: '<application ID>'. The solution to solve it can be found in the article How to
view container logs real time with Azure Monitor for containers.
Why can't I upgrade cluster after onboarding?

If after you enable Azure Monitor for containers for an AKS cluster, you delete the Log Analytics workspace the
cluster was sending its data to, when attempting to upgrade the cluster it will fail. To work around this, you will
have to disable monitoring and then re-enable it referencing a different valid workspace in your subscription.
When you try to perform the cluster upgrade again, it should process and complete successfully.
Which ports and domains do I need to open/whitelist for the agent?

*.ods.opinsights.azure.com 443
*.oms.opinsights.azure.com 443
*.blob.core.windows.net 443
dc.services.visualstudio.com 443
*.microsoftonline.com 443
*.monitoring.azure.com 443
login.microsoftonline.com 443
Next steps
To begin monitoring your AKS cluster, review How to onboard the Azure Monitor for containers to understand the
How to enable Azure Monitor for containers
This article provides an overview of the options available to setup Azure Monitor for containers to monitor the
performance of workloads that are deployed to Kubernetes environments and hosted on Azure Kubernetes
Service.
Azure Monitor for containers can be enabled for new, or one or more existing deployments of AKS using the
following supported methods:
From the Azure portal, Azure PowerShell, or with Azure CLI
Using Terraform and AKS
NOTE
PowerShell.
Prerequisites
Before you start, make sure that you have the following:
A Log Analytics workspace.
Azure Monitor for containers supports a Log Analytics workspace in the regions listed in Azure Products by
region, excluding the region US Gov Virginia.
You can create a workspace when you enable monitoring of your new AKS cluster or let the onboarding
experience create a default workspace in the default resource group of the AKS cluster subscription. If you
chose to create it yourself, you can create it through Azure Resource Manager, through PowerShell, or in
the Azure portal. For a list of the supported mapping pairs used for the default workspace, see Region
mapping for Azure Monitor for containers.
You are a member of the Log Analytics contributor role to enable container monitoring. For more
information about how to control access to a Log Analytics workspace, see Manage workspaces.
You are a member of the Owner role on the AKS cluster resource.
NOTE
Management Suite Agent for Windows or Linux will be referred to as the Log Analytics agent for Windows and Log Analytics
agent for Linux.
Prometheus metrics are not collected by default. Before configuring the agent to collect them, it is important
you review the Prometheus documentation to understand what you can define.
Components
Your ability to monitor performance relies on a containerized Log Analytics agent for Linux specifically developed
for Azure Monitor for containers. This specialized agent collects performance and event data from all nodes in the
cluster, and the agent is automatically deployed and registered with the specified Log Analytics workspace during
deployment. The agent version is microsoft/oms:ciprod04202018 or later, and is represented by a date in the
following format: mmddyyyy.
NOTE
With the preview release of Windows Server support for AKS, an AKS cluster with Windows Server nodes do not have an
agent installed to collect data and forward to Azure Monitor. Instead, a Linux node automatically deployed in the cluster as
part of the standard deployment collects and forwards the data to Azure Monitor on behalf all Windows nodes in the cluster.
When a new version of the agent is released, it is automatically upgraded on your managed Kubernetes clusters
hosted on Azure Kubernetes Service (AKS ). To follow the versions released, see agent release announcements.
NOTE
If you have already deployed an AKS cluster, you enable monitoring by using either Azure CLI or a provided Azure Resource
Manager template, as demonstrated later in this article. You cannot use kubectl to upgrade, delete, re-deploy, or deploy
the agent. The template needs to be deployed in the same resource group as the cluster.
You enable Azure Monitor for containers by using one of the following methods described in the following table.
DEPLOYMENT STATE METHOD DESCRIPTION
New AKS cluster Create cluster using Azure CLI You can enable monitoring of a new
AKS cluster that you create with Azure
CLI.
Create cluster using Terraform You can enable monitoring of a new

AKS cluster that you create using the
open-source tool Terraform.
Existing AKS cluster Enable using Azure CLI You can enable monitoring of an AKS
cluster already deployed using Azure
CLI.
Enable using Terraform You can enable monitoring of an AKS

cluster already deployed using the
open-source tool Terraform.
Enable from Azure Monitor You can enable monitoring of one or

more AKS clusters already deployed
from the AKS multi-cluster page in
Azure Monitor.
Enable from AKS cluster You can enable monitoring directly from
an AKS cluster in the Azure portal.
Enable using an Azure Resource You can enable monitoring of an AKS

Manager template cluster with a pre-configured Azure
Resource Manager template.
Next steps
With monitoring enabled to capture health metrics for both the AKS cluster nodes and pods, these health
metrics are available in the Azure portal. To learn how to use Azure Monitor for containers, see View Azure
Kubernetes Service health.
Enable monitoring of a new Azure Kubernetes
Service (AKS) cluster
This article describes how to set up Azure Monitor for containers to monitor managed Kubernetes cluster hosted
on Azure Kubernetes Service that you are preparing to deploy in your subscription.
You can enable monitoring of an AKS cluster using one of the supported methods:
Azure CLI
Terraform
Enable using Azure CLI

To enable monitoring of a new AKS cluster created with Azure CLI, follow the step in the quickstart article under
the section Create AKS cluster.
NOTE
If you choose to use the Azure CLI, you first need to install and use the CLI locally. You must be running the Azure CLI
version 2.0.59 or later. To identify your version, run az --version . If you need to install or upgrade the Azure CLI, see
Install the Azure CLI.
Enable using Terraform

If you are deploying a new AKS cluster using Terraform, you specify the arguments required in the profile to create
a Log Analytics workspace if you do not chose to specify an existing one.
NOTE
If you choose to use Terraform, you must be running the Terraform Azure RM Provider version 1.17.0 or above.
To add Azure Monitor for containers to the workspace, see azurerm_log_analytics_solution and complete the
profile by including the addon_profile and specify oms_agent.
After you've enabled monitoring and all configuration tasks are completed successfully, you can monitor the
performance of your cluster in either of two ways:
Directly in the AKS cluster by selecting Health in the left pane.
By selecting the Monitor Container insights tile in the AKS cluster page for the selected cluster. In Azure
Monitor, in the left pane, select Health.
After you've enabled monitoring, it might take about 15 minutes before you can view health metrics for the cluster.
Verify agent and solution deployment

With agent version 06072018 or later, you can verify that both the agent and the solution were deployed
successfully. With earlier versions of the agent, you can verify only agent deployment.
Agent version 06072018 or later
Run the following command to verify that the agent is deployed successfully.
kubectl get ds omsagent --namespace=kube-system
The output should resemble the following, which indicates that it was deployed properly:
User@aksuser:~$ kubectl get ds omsagent --namespace=kube-system

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
omsagent 2 2 2 2 2 beta.kubernetes.io/os=linux 1d
To verify deployment of the solution, run the following command:
kubectl get deployment omsagent-rs -n=kube-system
User@aksuser:~$ kubectl get deployment omsagent-rs -n=kube-system

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
omsagent 1 1 1 1 3h
Agent version earlier than 06072018

To verify that the Log Analytics agent version released before 06072018 is deployed properly, run the following
command:

View configuration with CLI

Use the aks show command to get details such as is the solution enabled or not, what is the Log Analytics
workspace resourceID, and summary details about the cluster.
az aks show -g <resourceGroupofAKSCluster> -n <nameofAksCluster>
After a few minutes, the command completes and returns JSON -formatted information about solution. The results
of the command should show the monitoring add-on profile and resembles the following example output:
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID":
"/subscriptions/<WorkspaceSubscription>/resourceGroups/<DefaultWorkspaceRG>/providers/Microsoft.OperationalInsi
ghts/workspaces/<defaultWorkspaceName>"
},
"enabled": true
}
}
Next steps
If you experience issues while attempting to onboard the solution, review the troubleshooting guide
Enable monitoring of Azure Kubernetes Service (AKS)
cluster already deployed
This article describes how to set up Azure Monitor for containers to monitor managed Kubernetes cluster hosted
on Azure Kubernetes Service that have already been deployed in your subscription.
You can enable monitoring of an AKS cluster that's already deployed using one of the supported methods:
Azure CLI
Terraform
From Azure Monitor or directly from the AKS cluster in the Azure portal
With the provided Azure Resource Manager template by using the Azure PowerShell cmdlet
New-AzResourceGroupDeployment or with Azure CLI.

Enable using Azure CLI

The following step enables monitoring of your AKS cluster using Azure CLI. In this example, you are not required
to per-create or specify an existing workspace. This command simplifies the process for you by creating a default
workspace in the default resource group of the AKS cluster subscription if one does not already exist in the region.
The default workspace created resembles the format of DefaultWorkspace-<GUID>-<Region>.
az aks enable-addons -a monitoring -n MyExistingManagedCluster -g MyExistingManagedClusterRG
The output will resemble the following:
provisioningState : Succeeded
Integrate with an existing workspace

If you would rather integrate with an existing workspace, perform the following steps to first identify the full
resource ID of your Log Analytics workspace required for the --workspace-resource-id parameter, and then run the
command to enable the monitoring add-on against the specified workspace.
1. List all the subscriptions which you have access using the following command:
az account list --all -o table

Name CloudName SubscriptionId State
IsDefault
------------------------------------ ----------- ------------------------------------ ------- ------
-----
Microsoft Azure AzureCloud 68627f8c-91fO-4905-z48q-b032a81f8vy0 Enabled True
Copy the value for SubscriptionId.

2. Switch to the subscription hosting the Log Analytics workspace using the following command:
az account set -s <subscriptionId of the workspace>
3. The following example displays the list of workspaces in your subscriptions in the default JSON format.
az resource list --resource-type Microsoft.OperationalInsights/workspaces -o json
In the output, find the workspace name, and then copy the full resource ID of that Log Analytics workspace
under the field id.
4. Run the following command to enable the monitoring add-on, replacing the value for the
--workspace-resource-id parameter. The string value must be within the double quotes:
az aks enable-addons -a monitoring -n ExistingManagedCluster -g ExistingManagedClusterRG --workspace-

resource-id
“/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.OperationalInsig
hts/workspaces/<WorkspaceName>”
Enable using Terraform

1. Add the oms_agent add-on profile to the existing azurerm_kubernetes_cluster resource
addon_profile {
oms_agent {
enabled = true
log_analytics_workspace_id = "${azurerm_log_analytics_workspace.test.id}"
}
}
2. Add the azurerm_log_analytics_solution following the steps in the Terraform documentation.
Enable from Azure Monitor in the portal

To enable monitoring of your AKS cluster in the Azure portal from Azure Monitor, do the following:
1. In the Azure portal, select Monitor.
2. Select Containers from the list.
3. On the Monitor - containers page, select Non-monitored clusters.
4. From the list of non-monitored clusters, find the container in the list and click Enable.
5. On the Onboarding to Azure Monitor for containers page, if you have an existing Log Analytics
workspace in the same subscription as the cluster, select it from the drop-down list.
The list preselects the default workspace and location that the AKS container is deployed to in the
subscription.
NOTE
If you want to create a new Log Analytics workspace for storing the monitoring data from the cluster, follow the
instructions in Create a Log Analytics workspace. Be sure to create the workspace in the same subscription that the
AKS container is deployed to.
After you've enabled monitoring, it might take about 15 minutes before you can view health metrics for the cluster.
Enable directly from AKS cluster in the portal

To enable monitoring directly from one of your AKS clusters in the Azure portal, do the following:
1. In the Azure portal, select All services.
2. In the list of resources, begin typing Containers. The list filters based on your input.
3. Select Kubernetes services.
4. In the list of containers, select a container.

5. On the container overview page, select Monitor Containers.
6. On the Onboarding to Azure Monitor for containers page, if you have an existing Log Analytics
workspace in the same subscription as the cluster, select it in the drop-down list.
The list preselects the default workspace and location that the AKS container is deployed to in the
subscription.
NOTE
If you want to create a new Log Analytics workspace for storing the monitoring data from the cluster, follow the
instructions in Create a Log Analytics workspace. Be sure to create the workspace in the same subscription that the
AKS container is deployed to.
After you've enabled monitoring, it might take about 15 minutes before you can view operational data for the
cluster.
Enable using an Azure Resource Manager template

This method includes two JSON templates. One template specifies the configuration to enable monitoring, and the
other contains parameter values that you configure to specify the following:
The AKS container resource ID.
The resource group that the cluster is deployed in.
NOTE
The template needs to be deployed in the same resource group as the cluster.
The Log Analytics workspace has to be created before you enable monitoring using Azure PowerShell or CLI. To
create the workspace, you can set it up through Azure Resource Manager, through PowerShell, or in the Azure
portal.
If you are unfamiliar with the concept of deploying resources by using a template, see:
Deploy resources with Resource Manager templates and Azure PowerShell
Deploy resources with Resource Manager templates and the Azure CLI
If you choose to use the Azure CLI, you first need to install and use the CLI locally. You must be running the Azure
CLI version 2.0.59 or later. To identify your version, run az --version . If you need to install or upgrade the Azure
CLI, see Install the Azure CLI.
Create and execute a template
{
"parameters": {
"aksResourceId": {
"type": "string",
"metadata": {
"description": "AKS Cluster Resource ID"
}
},
"aksResourceLocation": {
"type": "string",
"metadata": {
"description": "Location of the AKS resource e.g. \"East US\""
}
},
"aksResourceTagValues": {
"type": "object",
"metadata": {
"description": "Existing all tags on AKS Cluster Resource"
}
},
"workspaceResourceId": {
"type": "string",
"metadata": {
"description": "Azure Monitor Log Analytics Resource ID"
}
}
},
"resources": [
{
"name": "[split(parameters('aksResourceId'),'/')[8]]",
"type": "Microsoft.ContainerService/managedClusters",
"location": "[parameters('aksResourceLocation')]",
"tags": "[parameters('aksResourceTagValues')]",
"apiVersion": "2018-03-31",
"properties": {
"mode": "Incremental",
"id": "[parameters('aksResourceId')]",
"addonProfiles": {
"omsagent": {
"enabled": true,
"config": {
"logAnalyticsWorkspaceResourceID": "[parameters('workspaceResourceId')]"
}
}
}
}
}
]
}
2. Save this file as existingClusterOnboarding.json to a local folder.

3. Paste the following JSON syntax into your file:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"parameters": {
"aksResourceId": {
"value":
"/subscriptions/<SubscriptionId>/resourcegroups/<ResourceGroup>/providers/Microsoft.ContainerService/man
agedClusters/<ResourceName>"
},
"value": "<aksClusterLocation>"
},
"workspaceResourceId": {
"value":
"/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroup>/providers/Microsoft.OperationalInsights/
workspaces/<workspaceName>"
},
"value": {
"<existing-tag-name1>": "<existing-tag-value1>",
"<existing-tag-nameN>": "<existing-tag-valueN>"
}
}
}
}
4. Edit the values for aksResourceId and aksResourceLocation using the values on the AKS Overview
page for the AKS cluster. The value for workspaceResourceId is the full resource ID of your Log Analytics
workspace, which includes the workspace name.
Edit the values for aksResourceTagValues to match the existing tag values specified for the AKS cluster.
5. Save this file as existingClusterParam.json to a local folder.
6. You are ready to deploy this template.
To deploy with Azure PowerShell, use the following commands in the folder that contains the
template:
New-AzResourceGroupDeployment -Name OnboardCluster -ResourceGroupName <ResourceGroupName> -

TemplateFile .\existingClusterOnboarding.json -TemplateParameterFile .\existingClusterParam.json
The configuration change can take a few minutes to complete. When it's completed, a message is
displayed that's similar to the following and includes the result:
To deploy with Azure CLI, run the following commands:
az login
az account set --subscription "Subscription Name"
az group deployment create --resource-group <ResourceGroupName> --template-file
./existingClusterOnboarding.json --parameters @./existingClusterParam.json
The configuration change can take a few minutes to complete. When it's completed, a message is
displayed that's similar to the following and includes the result:
After you've enabled monitoring, it might take about 15 minutes before you can view health metrics
for the cluster.
Verify agent and solution deployment

With agent version 06072018 or later, you can verify that both the agent and the solution were deployed
successfully. With earlier versions of the agent, you can verify only agent deployment.
Agent version 06072018 or later
Run the following command to verify that the agent is deployed successfully.

To verify deployment of the solution, run the following command:

omsagent 1 1 1 1 3h
Agent version earlier than 06072018

To verify that the Log Analytics agent version released before 06072018 is deployed properly, run the following
command:

View configuration with CLI

Use the aks show command to get details such as is the solution enabled or not, what is the Log Analytics
workspace resourceID, and summary details about the cluster.
az aks show -g <resourceGroupofAKSCluster> -n <nameofAksCluster>

After a few minutes, the command completes and returns JSON -formatted information about solution. The results
of the command should show the monitoring add-on profile and resembles the following example output:
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID":
"/subscriptions/<WorkspaceSubscription>/resourceGroups/<DefaultWorkspaceRG>/providers/Microsoft.OperationalInsi
ghts/workspaces/<defaultWorkspaceName>"
},
"enabled": true
}
}
Next steps
If you experience issues while attempting to onboard the solution, review the troubleshooting guide
Region mappings supported by Azure Monitor for
containers
When enabling Azure Monitor for containers, only certain regions are supported for linking a Log Analytics
workspace and an AKS cluster, and collecting custom metrics submitted to Azure Monitor.
Log Analytics workspace supported mappings

The AKS cluster resources or Log Analytics workspace can reside in other regions, and the following table shows
our mappings.
AKS CLUSTER REGION LOG ANALYTICS WORKSPACE REGION
Africa
SouthAfricaNorth WestEurope
SouthAfricaWest WestEurope
Australia
AustraliaEast AustraliaEast
AustraliaCentral AustraliaCentral
AustraliaCentral2 AustraliaCentral
AustraliaEast AustraliaEast
Asia Pacific
EastAsia EastAsia
SoutheastAsia SoutheastAsia
Brazil
BrazilSouth SouthCentralUS
Canada
CanadaCentral CanadaCentral
CanadaEast CanadaCentral
Europe
AKS CLUSTER REGION LOG ANALYTICS WORKSPACE REGION
FranceCentral FranceCentral
FranceSouth FranceCentral
NorthEurope NorthEurope
UKSouth UKSouth
UKWest UKSouth
WestEurope WestEurope
India
CentralIndia CentralIndia
SouthIndia CentralIndia
WestIndia CentralIndia
Japan
JapanEast JapanEast
JapanWest JapanEast
Korea
KoreaCentral KoreaCentral
KoreaSouth KoreaCentral
US
CentralUS CentralUS
EastUS EastUS
EastUS2 EastUS2
WestUS WestUS
WestUS2 WestUS2
WestCentralUS1 EastUS1
1 Due to capacity restraints, the region isn't available when creating new
resources. This includes a Log Analytics
workspace. However, preexisting linked resources in the region should continue to work.
Custom metrics supported regions

Collecting metrics from Azure Kubernetes Services (AKS ) clusters nodes and pods are supported for publishing as
custom metrics only in the following Azure regions.
Next steps
To begin monitoring your AKS cluster, review How to enable the Azure Monitor for containers to understand the
Understand AKS cluster performance with Azure
Monitor for containers
With Azure Monitor for containers, you can use the performance charts and health status to monitor the
workload of your Azure Kubernetes Service (AKS ) clusters from two perspectives. You can monitor directly from
an AKS cluster, or you can monitor all AKS clusters in a subscription from Azure Monitor. Viewing Azure
Container Instances is also possible when you monitor a specific AKS cluster.
This article helps you understand the two perspectives, and how Azure Monitor helps you quickly assess,
investigate, and resolve detected issues.
For information about how to enable Azure Monitor for containers, see Onboard Azure Monitor for containers.
Azure Monitor provides a multi-cluster view that shows the health status of all monitored AKS clusters running
Linux and Windows Server 2019 deployed across resource groups in your subscriptions. It shows AKS clusters
discovered that aren't monitored by the solution. You can immediately understand cluster health, and from here,
you can drill down to the node and controller performance page or navigate to see performance charts for the
cluster. For AKS clusters that were discovered and identified as unmonitored, you can enable monitoring for them
at any time.
The main differences in monitoring a Windows Server cluster with Azure Monitor for containers compared to a
Linux cluster are the following:
Memory RSS metric isn't available for Windows node and containers.
Disk storage capacity information isn't available for Windows nodes.
Live logs support is available with the exception of Windows container logs.
Only pod environments are monitored, not Docker environments.
With the preview release, a maximum of 30 Windows Server containers are supported. This limitation doesn't
apply to Linux containers.

Multi-cluster view from Azure Monitor

To view the health status of all AKS clusters deployed, select Monitor from the left pane in the Azure portal.
Under the Insights section, select Containers.
On the Monitored clusters tab, you learn the following:
How many clusters are in a Critical or unhealthy state, versus how many are Healthy or not reporting (referred
to as an Unknown state).
Whether all of the Azure Kubernetes Engine (AKS -engine) deployments are healthy.
How many nodes and user and system pods are deployed per cluster.
How much disk space is available and if there's a capacity issue.
The health statuses included are:
Healthy: No issues are detected for the VM, and it's functioning as required.
Critical: One or more critical issues are detected that must be addressed to restore normal operational state
as expected.
Warning: One or more issues are detected that must be addressed or the health condition could become
critical.
Unknown: If the service wasn't able to make a connection with the node or pod, the status changes to an
Unknown state.
Not found: Either the workspace, the resource group, or subscription that contains the workspace for this
solution was deleted.
Unauthorized: User doesn’t have required permissions to read the data in the workspace.
Error: An error occurred while attempting to read data from the workspace.
Misconfigured: Azure Monitor for containers wasn't configured correctly in the specified workspace.
No data: Data hasn't reported to the workspace for the last 30 minutes.
Health state calculates overall cluster status as the worst of the three states with one exception. If any of the three
states is Unknown, the overall cluster state shows Unknown.
The following table provides a breakdown of the calculation that controls the health states for a monitored cluster
on the multi-cluster view.
STATUS AVAILABILITY
User pod
Healthy 100%
Warning 90 - 99%
Critical <90%
STATUS AVAILABILITY
Unknown If not reported in last 30 minutes
System pod
Healthy 100%
Warning N/A
Critical <100%
Node
Healthy >85%
Warning 60 - 84%
Critical <60%
From the list of clusters, you can drill down to the Cluster page by selecting the name of the cluster. Then go to
the Nodes performance page by selecting the rollup of nodes in the Nodes column for that specific cluster. Or,
you can drill down to the Controllers performance page by selecting the rollup of the User pods or System
pods column.
View performance directly from an AKS cluster

Access to Azure Monitor for containers is available directly from an AKS cluster by selecting Insights from the
left pane. Information about your AKS cluster is organized into four perspectives:
Cluster
Nodes
Controllers
Containers
The default page opens when you select Insights > Cluster. Four line performance charts display key
performance metrics of your cluster.
The performance charts display four performance metrics:
Node CPU utilization %: An aggregated perspective of CPU utilization for the entire cluster. To filter the
results for the time range, select Avg, Min, 50th, 90th, 95th, or Max in the percentiles selector above the
chart. The filters can be used either individually or combined.
Node memory utilization %: An aggregated perspective of memory utilization for the entire cluster. To filter
the results for the time range, select Avg, Min, 50th, 90th, 95th, or Max in the percentiles selector above the
chart. The filters can be used either individually or combined.
Node count: A node count and status from Kubernetes. Statuses of the cluster nodes represented are Total,
Ready, and Not Ready. They can be filtered individually or combined in the selector above the chart.
Active pod count: A pod count and status from Kubernetes. Statuses of the pods represented are Total,
Pending, Running, Unknown, Succeeded, or Failed. They can be filtered individually or combined in the
selector above the chart.
Use the Left and Right arrow keys to cycle through each data point on the chart. Use the Up and Down arrow
keys to cycle through the percentile lines. Select the pin icon in the upper-right corner of any one of the charts to
pin the selected chart to the last Azure dashboard you viewed. From the dashboard, you can resize and reposition
the chart. Selecting the chart from the dashboard redirects you to Azure Monitor for containers and loads the
correct scope and view.
Azure Monitor for containers also supports Azure Monitor metrics explorer, where you can create your own plot
charts, correlate and investigate trends, and pin to dashboards. From metrics explorer, you also can use the
criteria that you set to visualize your metrics as the basis of a metric-based alert rule.
View container metrics in metrics explorer

In metrics explorer, you can view aggregated node and pod utilization metrics from Azure Monitor for containers.
The following table summarizes the details to help you understand how to use the metric charts to visualize
container metrics.
NAMESPACE METRIC DESCRIPTION
insights.container/nodes
cpuUsageMillicores Aggregated measurement of CPU

utilization across the cluster. It is a CPU
core split into 1000 units (milli = 1000).
Used to determine the usage of cores
in a container where many applications
might be using one core.
cpuUsagePercentage Aggregated average CPU utilization

measured in percentage across the
cluster.
memoryRssBytes Container RSS memory used in bytes.
memoryRssPercentage Container RSS memory used in percent.
memoryWorkingSetBytes Container working set memory used.
memoryWorkingSetPercentage Container working set memory used in

percent.
nodesCount A node count from Kubernetes.
insights.container/pods
PodCount A pod count from Kubernetes.
You can split a metric to view it by dimension and visualize how different segments of it compare to each other.
For a node, you can segment the chart by the host dimension. From a pod, you can segment it by the following
dimensions:
Controller
Kubernetes namespace
Node
Phase
Analyze nodes, controllers, and container health

When you switch to the Nodes, Controllers, and Containers tabs, a property pane automatically displays on the
right side of the page. It shows the properties of the item selected, which includes the labels you defined to
organize Kubernetes objects. When a Linux node is selected, the Local Disk Capacity section also shows the
available disk space and the percentage used for each disk presented to the node. Select the >> link in the pane to
view or hide the pane.
As you expand the objects in the hierarchy, the properties pane updates based on the object selected. From the
pane, you also can view Kubernetes events with predefined log searches by selecting the View Kubernetes
event logs link at the top of the pane. For more information about how to view Kubernetes log data, see Search
logs to analyze data. While you review cluster resources, you can see container logs and events in real time. For
more information about this feature and the configuration required to grant and control access, see View logs in
real time with Azure Monitor for containers.
Use the + Add Filter option at the top of the page to filter the results for the view by Service, Node,
Namespace, or Node Pool. After you select the filter scope, select one of the values shown in the Select
value(s) field. After the filter is configured, it's applied globally while viewing any perspective of the AKS cluster.
The formula only supports the equal sign. You can add additional filters on top of the first one to further narrow
your results. For example, if you specify a filter by Node, you can only select Service or Namespace for the
second filter.
Specifying a filter in one tab continues to be applied when you select another. It's deleted after you select the x
symbol next to the specified filter.
Switch to the Nodes tab and the row hierarchy follows the Kubernetes object model, which starts with a node in
your cluster. Expand the node to view one or more pods running on the node. If more than one container is
grouped to a pod, they're displayed as the last row in the hierarchy. You also can view how many non-pod-related
workloads are running on the host if the host has processor or memory pressure.
Windows Server containers that run the Windows Server 2019 OS are shown after all of the Linux-based nodes
in the list. When you expand a Windows Server node, you can view one or more pods and containers that run on
the node. After a node is selected, the properties pane shows version information. Agent information is excluded
because Windows Server nodes don't have an agent installed.
Azure Container Instances virtual nodes that run the Linux OS are shown after the last AKS cluster node in the
list. When you expand a Container Instances virtual node, you can view one or more Container Instances pods
and containers that run on the node. Metrics aren't collected and reported for nodes, only for pods.
From an expanded node, you can drill down from the pod or container that runs on the node to the controller to
view performance data filtered for that controller. Select the value under the Controller column for the specific
node.
Select controllers or containers at the top of the page to review the status and resource utilization for those
objects. To review memory utilization, in the Metric drop-down list, select Memory RSS or Memory working
set. Memory RSS is supported only for Kubernetes version 1.8 and later. Otherwise, you view values for Min %
as NaN %, which is a numeric data type value that represents an undefined or unrepresentable value.
Memory working set shows both the resident memory and virtual memory (cache) included and is a total of
what the application is using. Memory RSS shows only main memory (which is nothing but the resident
memory in other words). This metric shows the actual capacity of available memory. What is the difference
between resident memory and virtual memory?
Resident memory or main memory, is the actual amount of machine memory available to the nodes of the
cluster.
Virtual memory is reserved hard disk space (cache) used by the operating system to swap data from
memory to disk when under memory pressure, and then fetch it back to memory when needed.
By default, performance data is based on the last six hours, but you can change the window by using the
TimeRange option at the upper left. You also can filter the results within the time range by selecting Min, Avg,
50th, 90th, 95th, and Max in the percentile selector.
When you hover over the bar graph under the Trend column, each bar shows either CPU or memory usage,
depending on which metric is selected, within a sample period of 15 minutes. After you select the trend chart
through a keyboard, use the Alt+Page up key or Alt+Page down key to cycle through each bar individually. You
get the same details that you would if you hovered over the bar.
In the next example, for the first node in the list, aks-nodepool1 -, the value for Containers is 9. This value is a
rollup of the total number of containers deployed.
This information can help you quickly identify whether you have a proper balance of containers between nodes in
your cluster.
The information that's presented when you view the Nodes tab is described in the following table.
COLUMN DESCRIPTION
Name The name of the host.
Status Kubernetes view of the node status.
Min %, Avg %, 50th %, 90th %, 95th %, Max % Average node percentage based on percentile during the
selected duration.
Min, Avg, 50th, 90th, 95th, Max Average nodes' actual value based on percentile during the
time duration selected. The average value is measured from
the CPU/Memory limit set for a node. For pods and
containers, it's the average value reported by the host.
Containers Number of containers.
Uptime Represents the time since a node started or was rebooted.
Controller Only for containers and pods. It shows which controller it

resides in. Not all pods are in a controller, so some might
display N/A.
Trend Min %, Avg %, 50th %, 90th %, 95th %, Max % Bar graph trend represents the average percentile metric
percentage of the controller.
In the selector, select Controllers.
Here you can view the performance health of your controllers and Container Instances virtual node controllers or
virtual node pods not connected to a controller.
The row hierarchy starts with a controller. When you expand a controller, you view one or more pods. Expand a
pod, and the last row displays the container grouped to the pod. From an expanded controller, you can drill down
to the node it's running on to view performance data filtered for that node. Container Instances pods not
connected to a controller are listed last in the list.
Select the value under the Node column for the specific controller.
The information that's displayed when you view controllers is described in the following table.
COLUMN DESCRIPTION
Name The name of the controller.

COLUMN DESCRIPTION
Status The rollup status of the containers after it's finished running
with status such as OK, Terminated, Failed, Stopped, or
Paused. If the container is running but the status either
wasn't properly displayed or wasn't picked up by the agent
and hasn't responded for more than 30 minutes, the status is
Unknown. Additional details of the status icon are provided in
the following table.
Min %, Avg %, 50th %, 90th %, 95th %, Max % Rollup average of the average percentage of each entity for
the selected metric and percentile.
Min, Avg, 50th, 90th, 95th, Max Rollup of the average CPU millicore or memory performance
of the container for the selected percentile. The average value
is measured from the CPU/Memory limit set for a pod.
Containers Total number of containers for the controller or pod.
Restarts Rollup of the restart count from containers.
Uptime Represents the time since a container started.
Node Only for containers and pods. It shows which controller it

resides in.
Trend Min %, Avg %, 50th %, 90th %, 95th %, Max % Bar graph trend represents the average percentile metric of
the controller.
The icons in the status field indicate the online status of the containers.
ICON STATUS
Running (Ready)
Waiting or Paused
Last reported running but hasn't responded for more than 30

minutes
Successfully stopped or failed to stop
The status icon displays a count based on what the pod provides. It shows the worst two states, and when you
hover over the status, it displays a rollup status from all pods in the container. If there isn't a ready state, the status
value displays (0).
In the selector, select Containers.
Here you can view the performance health of your Azure Kubernetes and Azure Container Instances containers.
From a container, you can drill down to a pod or node to view performance data filtered for that object. Select the
value under the Pod or Node column for the specific container.
The information that's displayed when you view containers is described in the following table.
COLUMN DESCRIPTION
Name The name of the controller.
Status Status of the containers, if any. Additional details of the status

icon are provided in the next table.
COLUMN DESCRIPTION
Min %, Avg %, 50th %, 90th %, 95th %, Max % The rollup of the average percentage of each entity for the
selected metric and percentile.
Min, Avg, 50th, 90th, 95th, Max The rollup of the average CPU millicore or memory
performance of the container for the selected percentile. The
average value is measured from the CPU/Memory limit set
for a pod.
Pod Container where the pod resides.
Node Node where the container resides.
Restarts Represents the time since a container started.
Uptime Represents the time since a container was started or

rebooted.
Trend Min %, Avg %, 50th %, 90th %, 95th %, Max % Bar graph trend represents the average percentile metric
percentage of the container.
The icons in the status field indicate the online statuses of pods, as described in the following table.
ICON STATUS
Running (Ready)
Waiting or Paused
Last reported running but hasn't responded in more than 30

minutes
Successfully stopped or failed to stop
Failed state
Workbooks
Workbooks combine text,log queries, metrics, and parameters into rich interactive reports. Workbooks are
editable by any other team members who have access to the same Azure resources.
Azure Monitor for containers includes four workbooks to get you started:
Disk capacity: Presents interactive disk usage charts for each disk presented to the node within a
container by the following perspectives:
Disk percent usage for all disks.
Free disk space for all disks.
A grid that shows each node's disk, its percentage of used space, trend of percentage of used space, free
disk space (GiB ), and trend of free disk space (GiB ). When a row is selected in the table, the percentage
of used space and free disk space (GiB ) is shown underneath the row.
Disk IO: Presents interactive disk utilization charts for each disk presented to the node within a container
by the following perspectives:
Disk I/O summarized across all disks by read bytes/sec, writes bytes/sec, and read and write bytes/sec
trends.
Eight performance charts show key performance indicators to help measure and identify disk I/O
bottlenecks.
Kubelet: Includes two grids that show key node operating statistics:
Overview by node grid summarizes total operation, total errors, and successful operations by percent
and trend for each node.
Overview by operation type summarizes for each operation the total operation, total errors, and
successful operations by percent and trend.
Network: Presents interactive network utilization charts for each node's network adapter, and a grid
presents the key performance indicators to help measure the performance of your network adapters.
You access these workbooks by selecting each one from the View Workbooks drop-down list.
Next steps
Review Create performance alerts with Azure Monitor for containers to learn how to create alerts for high
CPU and memory utilization to support your DevOps or operational processes and procedures.
View log query examples to see predefined queries and examples to evaluate or customize to alert, visualize,
or analyze your clusters.
How to stop monitoring your Azure Kubernetes
Service (AKS) with Azure Monitor for containers
After you enable monitoring of your AKS cluster, you can stop monitoring the cluster if you decide you no longer
want to monitor it. This article shows how to accomplish this using the Azure CLI or with the provided Azure
Resource Manager templates.
Azure CLI
Use the az aks disable-addons command to disable Azure Monitor for containers. The command removes the
agent from the cluster nodes, it does not remove the solution or the data already collected and stored in your
Azure Monitor resource.
az aks disable-addons -a monitoring -n MyExistingManagedCluster -g MyExistingManagedClusterRG
To re-enable monitoring for your cluster, see Enable monitoring using Azure CLI.

Provided are two Azure Resource Manager template to support removing the solution resources consistently and
repeatedly in your resource group. One is a JSON template specifying the configuration to stop monitoring and
the other contains parameter values that you configure to specify the AKS cluster resource ID and resource group
that the cluster is deployed in.
If you're unfamiliar with the concept of deploying resources by using a template, see:
NOTE
The template needs to be deployed in the same resource group of the cluster. If you omit any other properties or add-ons
when using this template, it can result in their removal from the cluster. For example, enableRBAC for RBAC policies
implemented in your cluster, or aksResourceTagValues if tags are specified for the AKS cluster.
Create template
{
"parameters": {
"aksResourceId": {
"type": "string",
"metadata": {
"description": "AKS Cluster Resource ID"
}
},
"type": "string",
"metadata": {
"description": "Location of the AKS resource e.g. \"East US\""
}
}
},
"type": "object",
"metadata": {
"description": "Existing all tags on AKS Cluster Resource"
}
},
"resources": [
{
"name": "[split(parameters('aksResourceId'),'/')[8]]",
"type": "Microsoft.ContainerService/managedClusters",
"location": "[parameters('aksResourceLocation')]",
"tags": "[parameters('aksResourceTagValues')]"
"apiVersion": "2018-03-31",
"properties": {
"mode": "Incremental",
"id": "[parameters('aksResourceId')]",
"addonProfiles": {
"omsagent": {
"enabled": false,
"config": null
}
}
}
}
]
}
2. Save this file as OptOutTemplate.json to a local folder.

3. Paste the following JSON syntax into your file:
{
"parameters": {
"aksResourceId": {
"value":
"/subscriptions/<SubscriptionID>/resourcegroups/<ResourceGroup>/providers/Microsoft.ContainerService/man
agedClusters/<ResourceName>"
},
"value": "<aksClusterRegion>"
},
"value": {
"<existing-tag-nameN>": "<existing-tag-valueN>"
}
}
}
}
4. Edit the values for aksResourceId and aksResourceLocation by using the values of the AKS cluster, which
you can find on the Properties page for the selected cluster.
While you are on the Properties page, also copy the Workspace Resource ID. This value is required if you
decide you want to delete the Log Analytics workspace later. Deleting the Log Analytics workspace is not
performed as part of this process.
Edit the values for aksResourceTagValues to match the existing tag values specified for the AKS cluster.
5. Save this file as OptOutParam.json to a local folder.
6. You are ready to deploy this template.
Remove the solution using Azure CLI
Execute the following command with Azure CLI on Linux to remove the solution and clean up the configuration on
your AKS cluster.
az login
az group deployment create --resource-group <ResourceGroupName> --template-file ./OptOutTemplate.json --
parameters @./OptOutParam.json
The configuration change can take a few minutes to complete. When it's completed, a message similar to the
following that includes the result is returned:
Remove the solution using PowerShell
NOTE
PowerShell.
Execute the following PowerShell commands in the folder containing the template to remove the solution and
clean up the configuration from your AKS cluster.
Connect-AzAccount
Select-AzSubscription -SubscriptionName <yourSubscriptionName>
New-AzResourceGroupDeployment -Name opt-out -ResourceGroupName <ResourceGroupName> -TemplateFile
.\OptOutTemplate.json -TemplateParameterFile .\OptOutParam.json
The configuration change can take a few minutes to complete. When it's completed, a message similar to the
following that includes the result is returned:
If the workspace was created only to support monitoring the cluster and it's no longer needed, you have to
manually delete it. If you are not familiar with how to delete a workspace, see Delete an Azure Log Analytics
workspace with the Azure portal. Don't forget about the Workspace Resource ID we copied earlier in step 4,
you're going to need that.
How to view logs and events in real time (preview)
Azure Monitor for containers includes a feature, which is currently in preview, that provides a live view into your
Azure Kubernetes Service (AKS ) container logs (stdout/stderr) and events without having to run kubectl
commands. When you select either option, a new pane appears below the performance data table on the Nodes,
Controllers, and Containers view. It shows live logging and events generated by the container engine to further
assist in troubleshooting issues in real time.
NOTE
Contributor access to the cluster resource is required for this feature to work.
Live logs support three different methods to control access to the logs:
1. AKS without Kubernetes RBAC authorization enabled
2. AKS enabled with Kubernetes RBAC authorization
3. AKS enabled with Azure Active Directory (AD ) SAML -based single-sign on
Kubernetes cluster without RBAC enabled

If you have a Kubernetes cluster that is not configured with Kubernetes RBAC authorization or integrated with
Azure AD single-sign on, you do not need to follow these steps. Because Kubernetes authorization uses the kube-
api, read-only permissions are required.
Kubernetes RBAC authorization

If you have enabled Kubernetes RBAC authorization, you will need to apply cluster role binding. The following
example steps demonstrate how to configure cluster role binding from this yaml configuration template.
1. Copy and paste the yaml file and save it as LogReaderRBAC.yaml.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: containerHealth-log-reader
rules:
- apiGroups: [""]
resources: ["pods/log", "events"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: containerHealth-read-logs-global
roleRef:
kind: ClusterRole
name: containerHealth-log-reader
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: clusterUser
apiGroup: rbac.authorization.k8s.io
2. If you are configuring it for the first time, you apply the cluster rule binding by running the following
command: kubectl create -f LogReaderRBAC.yaml . If you previously enabled support for live logs preview
before we introduced live event logs, to update your configuration, run the following command:
kubectl apply -f LogReaderRBAC.yaml .
Configure AKS with Azure Active Directory

AKS can be configured to use Azure Active Directory (AD ) for user authentication. If you are configuring it for the
first time, see Integrate Azure Active Directory with Azure Kubernetes Service. During the steps to create the client
application, specify the following:
Redirect URI: Two Web application types need to be created. The first base URL value should be
https://afd.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-
libs/auth/auth.html
and the second base URL value should be
https://monitoring.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-
libs/auth/auth.html
.
After registering the application, from the Overview page select Authentication from the left-hand pane. On
the Authentication page, under Advanced settings implicitly grant Access tokens and ID tokens and then
save your changes.
NOTE
Configuring authentication with Azure Active Directory for single-sign on can only be accomplished during initial deployment
of a new AKS cluster. You cannot configure single-sign on for an AKS cluster already deployed.
IMPORTANT
If you reconfigured Azure AD for user authentication using the updated URI, clear your browser's cache to ensure the
updated authentication token is downloaded and applied.
View live logs and events

You can view real-time log events as they are generated by the container engine from the Nodes, Controllers,
and Containers view. From the properties pane, you select View live data (preview) option and a pane is
presented below the performance data table where you can view log and events in a continuous stream.
Log and event messages are limited based on what resource type is selected in the view.
VIEW RESOURCE TYPE LOG OR EVENT DATA PRESENTED
Nodes Node Event When a node is selected

events are not filtered and
show cluster-wide
Kubernetes events. The pane
title shows the name of the
cluster.
Nodes Pod Event When a pod is selected

events are filtered to its
namespace. The pane title
shows the namespace of the
pod.
Controllers Pod Event When a pod is selected

pod.
Controllers Controller Event When a controller is selected

controller.
Nodes/Controllers/Container Container Logs The pane title shows the

s name of the pod the
container is grouped with.
If the AKS cluster is configured with SSO using AAD, you are prompted to authenticate on first use during that
browser session. Select your account and complete authentication with Azure.
After successfully authenticating, the live log pane will appear in the bottom section of the middle pane. If the fetch
status indicator shows a green check mark, which is on the far right of the pane, it means it can retrieve data.
In the search bar, you can filter by key word to highlight that text in the log or event, and in the search bar on the
far right, it shows how many results match out the filter.
While viewing events, you can additionally limit the results using the Filter pill found to the right of the search bar.
Depending on what resource you have selected, the pill lists a pod, namespace, or cluster to chose from.
To suspend autoscroll and control the behavior of the pane and allow you to manually scroll through the new data
read, click on the Scroll option. To re-enable autoscroll, simply click the Scroll option again. You can also pause
retrieval of log or event data by clicking on the Pause option and when you are ready to resume, simply click Play.
You can go to Azure Monitor Logs to see historical container logs by selecting View container logs from the
drop-down list View in analytics.
Next steps
To continue learning how to use Azure Monitor and monitor other aspects of your AKS cluster, see View
Azure Kubernetes Service health.
View log query examples to see pre-defined queries and examples to evaluate or customize for alerting,
visualizing, or analyzing your clusters.
How to query logs from Azure Monitor for containers
Azure Monitor for containers collects performance metrics, inventory data, and health state information from
container hosts and containers, and forwards it to the Log Analytics workspace in Azure Monitor. Data is collected
every three minutes. This data is available for query in Azure Monitor. You can apply this data to scenarios that
include migration planning, capacity analysis, discovery, and on-demand performance troubleshooting.
Container records
Examples of records that are collected by Azure Monitor for containers and the data types that appear in log search
results are displayed in the following table:
DATA TYPE DATA TYPE IN LOG SEARCH FIELDS
Performance for hosts and containers Perf Computer, ObjectName, CounterName

(%Processor Time, Disk Reads MB, Disk
Writes MB, Memory Usage MB,
Network Receive Bytes, Network Send
Bytes, Processor Usage sec, Network),
CounterValue, TimeGenerated,
CounterPath, SourceSystem
Container inventory ContainerInventory TimeGenerated, Computer, container

name, ContainerHostname, Image,
ImageTag, ContainerState, ExitCode,
EnvironmentVar, Command,
CreatedTime, StartedTime, FinishedTime,
SourceSystem, ContainerID, ImageID
Container log ContainerLog TimeGenerated, Computer, image ID,

container name, LogEntrySource,
LogEntry, SourceSystem, ContainerID
Container node inventory ContainerNodeInventory TimeGenerated, Computer,

ClassName_s, DockerVersion_s,
OperatingSystem_s, Volume_s,
Network_s, NodeRole_s,
OrchestratorType_s, InstanceID_g,
SourceSystem
Inventory of pods in a Kubernetes KubePodInventory TimeGenerated, Computer, ClusterId,

cluster ContainerCreationTimeStamp, PodUid,
PodCreationTimeStamp,
ContainerRestartCount,
PodRestartCount, PodStartTime,
ContainerStartTime, ServiceName,
ControllerKind, ControllerName,
ContainerStatus,
ContainerStatusReason, ContainerID,
ContainerName, Name, PodLabel,
Namespace, PodStatus, ClusterName,
PodIp, SourceSystem
Inventory of nodes part of a KubeNodeInventory TimeGenerated, Computer,

Kubernetes cluster ClusterName, ClusterId,
LastTransitionTimeReady, Labels, Status,
KubeletVersion, KubeProxyVersion,
CreationTimeStamp, SourceSystem
Kubernetes Events KubeEvents TimeGenerated, Computer, ClusterId_s,

FirstSeen_t, LastSeen_t, Count_d,
ObjectKind_s, Namespace_s, Name_s,
Reason_s, Type_s, TimeGenerated_s,
SourceComponent_s, ClusterName_s,
Message, SourceSystem
Services in the Kubernetes cluster KubeServices TimeGenerated, ServiceName_s,

Namespace_s, SelectorLabels_s,
ClusterId_s, ClusterName_s, ClusterIP_s,
ServiceType_s, SourceSystem
Performance metrics for nodes part of Perf | where ObjectName == Computer, ObjectName, CounterName
the Kubernetes cluster “K8SNode” (cpuAllocatableBytes,
memoryAllocatableBytes,
cpuCapacityNanoCores,
memoryCapacityBytes,
memoryRssBytes, cpuUsageNanoCores,
memoryWorkingsetBytes,
restartTimeEpoch), CounterValue,
TimeGenerated, CounterPath,
SourceSystem
Performance metrics for containers part Perf | where ObjectName == CounterName ( cpuRequestNanoCores,
of the Kubernetes cluster “K8SContainer” memoryRequestBytes,
cpuLimitNanoCores,
memoryWorkingSetBytes,
restartTimeEpoch, cpuUsageNanoCores,
memoryRssBytes), CounterValue,
TimeGenerated, CounterPath,
SourceSystem
Custom Metrics InsightsMetrics Computer, Name, Namespace, Origin,

SourceSystem, Tags1 , TimeGenerated,
Type, Va, _ResourceId
1 The Tags property represents multiple dimensions for the corresponding metric. For additional information about
the metrics collected and stored in the InsightsMetrics table and a description of the record properties, see
InsightsMetrics overview.
NOTE
Search logs to analyze data

Azure Monitor Logs can help you look for trends, diagnose bottlenecks, forecast, or correlate data that can help
you determine whether the current cluster configuration is performing optimally. Pre-defined log searches are
provided for you to immediately start using or to customize to return the information the way you want.
You can perform interactive analysis of data in the workspace by selecting the View Kubernetes event logs or
View container logs option in the preview pane. The Log Search page appears to the right of the Azure portal
page that you were on.
The container logs output that's forwarded to your workspace are STDOUT and STDERR. Because Azure Monitor
is monitoring Azure-managed Kubernetes (AKS ), Kube-system is not collected today because of the large volume
of generated data.
Example log search queries
It's often useful to build queries that start with an example or two and then modify them to fit your requirements.
To help build more advanced queries, you can experiment with the following sample queries:
QUERY DESCRIPTION
ContainerInventory List all of a container's lifecycle information

| project Computer, Name, Image, ImageTag, ContainerState,
CreatedTime, StartedTime, FinishedTime
| render table
KubeEvents_CL Kubernetes events

| where not(isempty(Namespace_s))
| render table
ContainerImageInventory Image inventory

| summarize AggregatedValue = count() by Image, ImageTag,
Running
Select the Line chart display option: Container CPU

Perf
| where ObjectName == "K8SContainer" and CounterName
== "cpuUsageNanoCores" | summarize
AvgCPUUsageNanoCores = avg(CounterValue) by
bin(TimeGenerated, 30m), InstanceName
Select the Line chart display option: Container memory

Perf
| where ObjectName == "K8SContainer" and CounterName
== "memoryRssBytes" | summarize AvgUsedRssMemoryBytes
= avg(CounterValue) by bin(TimeGenerated, 30m),
InstanceName
The following example is a Prometheus metrics query. The metrics collected are counts and in order to determine
how many errors occurred within a specific time period, we have to subtract from the count. The dataset is
partitioned by partitionKey, meaning for each unique set of Name, HostName, and OperationType, we run a
subquery on that set that orders the logs by TimeGenerated, a process that makes it possible to find the previous
TimeGenerated and the count recorded for that time, to determine a rate.
let data = InsightsMetrics

| where Namespace contains 'prometheus'
| where Name == 'kubelet_docker_operations' or Name == 'kubelet_docker_operations_errors'
| extend Tags = todynamic(Tags)
| extend OperationType = tostring(Tags['operation_type']), HostName = tostring(Tags.hostName)
| extend partitionKey = strcat(HostName, '/' , Name, '/', OperationType)
| partition by partitionKey (
order by TimeGenerated asc
| extend PrevVal = prev(Val, 1), PrevTimeGenerated = prev(TimeGenerated, 1)
| extend Rate = iif(TimeGenerated == PrevTimeGenerated, 0.0, Val - PrevVal)
| where isnull(Rate) == false
)
| project TimeGenerated, Name, HostName, OperationType, Rate;
let operationData = data
| where Name == 'kubelet_docker_operations'
| project-rename OperationCount = Rate;
let errorData = data
| where Name == 'kubelet_docker_operations_errors'
| project-rename ErrorCount = Rate;
operationData
| join kind = inner ( errorData ) on TimeGenerated, HostName, OperationType
| project-away TimeGenerated1, Name1, HostName1, OperationType1
| extend SuccessPercentage = iif(OperationCount == 0, 1.0, 1 - (ErrorCount / OperationCount))
The output will show results similar to the following:
Next steps
Azure Monitor for containers does not include a predefined set of alerts. Review the Create performance alerts
with Azure Monitor for containers to learn how to create recommended alerts for high CPU and memory
utilization to support your DevOps or operational processes and procedures.
How to set up alerts for performance problems in
Azure Monitor for containers monitors the performance of container workloads that are deployed to Azure
Container Instances or to managed Kubernetes clusters that are hosted on Azure Kubernetes Service (AKS ).
This article describes how to enable alerts for the following situations:
When CPU or memory utilization on cluster nodes exceeds a threshold
When CPU or memory utilization on any container within a controller exceeds a threshold as compared to a
limit that's set on the corresponding resource
NotReady status node counts
Failed, Pending, Unknown, Running, or Succeeded pod-phase counts
When free disk space on cluster nodes exceeds a threshold
To alert for high CPU or memory utilization, or low free disk space on cluster nodes, use the queries that are
provided to create a metric alert or a metric measurement alert. Metric alerts have lower latency than log alerts.
But log alerts provide advanced querying and greater sophistication. Log alerts queries compare a datetime to the
present by using the now operator and going back one hour. (Azure Monitor for containers stores all dates in
Coordinated Universal Time (UTC ) format.)
If you're not familiar with Azure Monitor alerts, see Overview of alerts in Microsoft Azure before you start. To
learn more about alerts that use log queries, see Log alerts in Azure Monitor. For more about metric alerts, see
Metric alerts in Azure Monitor.
Resource utilization log search queries

The queries in this section support each alerting scenario. They're used in step 7 of the create alert section of this
article.
The following query calculates average CPU utilization as an average of member nodes' CPU utilization every
minute.
let endDateTime = now();
let startDateTime = ago(1h);
let trendBinSize = 1m;
let capacityCounterName = 'cpuCapacityNanoCores';
let usageCounterName = 'cpuUsageNanoCores';
KubeNodeInventory
| where TimeGenerated < endDateTime
| where TimeGenerated >= startDateTime
// cluster filter would go here if multiple clusters are reporting to the same Log Analytics workspace
| distinct ClusterName, Computer
| join hint.strategy=shuffle (
Perf
| where ObjectName == 'K8SNode'
| where CounterName == capacityCounterName
| summarize LimitValue = max(CounterValue) by Computer, CounterName, bin(TimeGenerated, trendBinSize)
| project Computer, CapacityStartTime = TimeGenerated, CapacityEndTime = TimeGenerated + trendBinSize,
LimitValue
) on Computer
| join kind=inner hint.strategy=shuffle (
Perf
| where TimeGenerated < endDateTime + trendBinSize
| where TimeGenerated >= startDateTime - trendBinSize
| where CounterName == usageCounterName
| project Computer, UsageValue = CounterValue, TimeGenerated
) on Computer
| where TimeGenerated >= CapacityStartTime and TimeGenerated < CapacityEndTime
| project ClusterName, Computer, TimeGenerated, UsagePercent = UsageValue * 100.0 / LimitValue
| summarize AggregatedValue = avg(UsagePercent) by bin(TimeGenerated, trendBinSize), ClusterName
The following query calculates average memory utilization as an average of member nodes' memory utilization
every minute.
let capacityCounterName = 'memoryCapacityBytes';
let usageCounterName = 'memoryRssBytes';
KubeNodeInventory
// cluster filter would go here if multiple clusters are reporting to the same Log Analytics workspace
| distinct ClusterName, Computer
Perf
| summarize LimitValue = max(CounterValue) by Computer, CounterName, bin(TimeGenerated, trendBinSize)
| project Computer, CapacityStartTime = TimeGenerated, CapacityEndTime = TimeGenerated + trendBinSize,
LimitValue
) on Computer
Perf
| project Computer, UsageValue = CounterValue, TimeGenerated
) on Computer
| where TimeGenerated >= CapacityStartTime and TimeGenerated < CapacityEndTime
| project ClusterName, Computer, TimeGenerated, UsagePercent = UsageValue * 100.0 / LimitValue
| summarize AggregatedValue = avg(UsagePercent) by bin(TimeGenerated, trendBinSize), ClusterName
IMPORTANT
The following queries use the placeholder values <your-cluster-name> and <your-controller-name> to represent your
cluster and controller. Replace them with values specific to your environment when you set up alerts.
The following query calculates the average CPU utilization of all containers in a controller as an average of CPU
utilization of every container instance in a controller every minute. The measurement is a percentage of the limit
set up for a container.
let capacityCounterName = 'cpuLimitNanoCores';
let usageCounterName = 'cpuUsageNanoCores';
let clusterName = '<your-cluster-name>';
let controllerName = '<your-controller-name>';
KubePodInventory
| where ClusterName == clusterName
| where ControllerName == controllerName
| extend InstanceName = strcat(ClusterId, '/', ContainerName),
ContainerName = strcat(controllerName, '/', tostring(split(ContainerName, '/')[1]))
| distinct Computer, InstanceName, ContainerName
Perf
| where ObjectName == 'K8SContainer'
| summarize LimitValue = max(CounterValue) by Computer, InstanceName, bin(TimeGenerated, trendBinSize)
| project Computer, InstanceName, LimitStartTime = TimeGenerated, LimitEndTime = TimeGenerated +
trendBinSize, LimitValue
) on Computer, InstanceName
Perf
| project Computer, InstanceName, UsageValue = CounterValue, TimeGenerated
| where TimeGenerated >= LimitStartTime and TimeGenerated < LimitEndTime
| project Computer, ContainerName, TimeGenerated, UsagePercent = UsageValue * 100.0 / LimitValue
| summarize AggregatedValue = avg(UsagePercent) by bin(TimeGenerated, trendBinSize) , ContainerName
The following query calculates the average memory utilization of all containers in a controller as an average of
memory utilization of every container instance in a controller every minute. The measurement is a percentage of
the limit set up for a container.
let capacityCounterName = 'memoryLimitBytes';
let usageCounterName = 'memoryRssBytes';
let controllerName = '<your-controller-name>';
KubePodInventory
| where ControllerName == controllerName
| extend InstanceName = strcat(ClusterId, '/', ContainerName),
ContainerName = strcat(controllerName, '/', tostring(split(ContainerName, '/')[1]))
| distinct Computer, InstanceName, ContainerName
Perf
| summarize LimitValue = max(CounterValue) by Computer, InstanceName, bin(TimeGenerated, trendBinSize)
| project Computer, InstanceName, LimitStartTime = TimeGenerated, LimitEndTime = TimeGenerated +
trendBinSize, LimitValue
Perf
| project Computer, InstanceName, UsageValue = CounterValue, TimeGenerated
| where TimeGenerated >= LimitStartTime and TimeGenerated < LimitEndTime
| project Computer, ContainerName, TimeGenerated, UsagePercent = UsageValue * 100.0 / LimitValue
| summarize AggregatedValue = avg(UsagePercent) by bin(TimeGenerated, trendBinSize) , ContainerName
The following query returns all nodes and counts that have a status of Ready and NotReady.

KubeNodeInventory
| distinct ClusterName, Computer, TimeGenerated
| summarize ClusterSnapshotCount = count() by bin(TimeGenerated, trendBinSize), ClusterName, Computer
| join hint.strategy=broadcast kind=inner (
KubeNodeInventory
| summarize TotalCount = count(), ReadyCount = sumif(1, Status contains ('Ready'))
by ClusterName, Computer, bin(TimeGenerated, trendBinSize)
| extend NotReadyCount = TotalCount - ReadyCount
) on ClusterName, Computer, TimeGenerated
| project TimeGenerated,
ClusterName,
Computer,
ReadyCount = todouble(ReadyCount) / ClusterSnapshotCount,
NotReadyCount = todouble(NotReadyCount) / ClusterSnapshotCount
| order by ClusterName asc, Computer asc, TimeGenerated desc
The following query returns pod phase counts based on all phases: Failed, Pending, Unknown, Running, or
Succeeded.

KubePodInventory
| distinct ClusterName, TimeGenerated
| summarize ClusterSnapshotCount = count() by bin(TimeGenerated, trendBinSize), ClusterName
| join hint.strategy=broadcast (
KubePodInventory
| distinct ClusterName, Computer, PodUid, TimeGenerated, PodStatus
| summarize TotalCount = count(),
PendingCount = sumif(1, PodStatus =~ 'Pending'),
RunningCount = sumif(1, PodStatus =~ 'Running'),
SucceededCount = sumif(1, PodStatus =~ 'Succeeded'),
FailedCount = sumif(1, PodStatus =~ 'Failed')
by ClusterName, bin(TimeGenerated, trendBinSize)
) on ClusterName, TimeGenerated
| extend UnknownCount = TotalCount - PendingCount - RunningCount - SucceededCount - FailedCount
| project TimeGenerated,
TotalCount = todouble(TotalCount) / ClusterSnapshotCount,
PendingCount = todouble(PendingCount) / ClusterSnapshotCount,
RunningCount = todouble(RunningCount) / ClusterSnapshotCount,
SucceededCount = todouble(SucceededCount) / ClusterSnapshotCount,
FailedCount = todouble(FailedCount) / ClusterSnapshotCount,
UnknownCount = todouble(UnknownCount) / ClusterSnapshotCount
| summarize AggregatedValue = avg(PendingCount) by bin(TimeGenerated, trendBinSize)
NOTE
To alert on certain pod phases, such as Pending, Failed, or Unknown, modify the last line of the query. For example, to alert
on FailedCount use:
| summarize AggregatedValue = avg(FailedCount) by bin(TimeGenerated, trendBinSize)
The following query returns cluster nodes disks which exceed 90% free space used. To get the cluster ID, first run
the following query and copy the value from the ClusterId property:
InsightsMetrics
| project ClusterId = Tags['container.azm.ms/clusterId']
| distinct tostring(ClusterId)
let clusterId = '<cluster-id>';
InsightsMetrics
| where Origin == 'container.azm.ms/telegraf'
| where Namespace == 'container.azm.ms/disk'
| project TimeGenerated, ClusterId = Tags['container.azm.ms/clusterId'], Computer = tostring(Tags.hostName),
Device = tostring(Tags.device), Path = tostring(Tags.path), DiskMetricName = Name, DiskMetricValue = Val
| where ClusterId =~ clusterId
| where DiskMetricName == 'used_percent'
| summarize AggregatedValue = max(DiskMetricValue) by bin(TimeGenerated, trendBinSize)
| where AggregatedValue >= 90

Follow these steps to create a log alert in Azure Monitor by using one of the log search rules that was provided
earlier.
NOTE
The following procedure to create an alert rule for container resource utilization requires you to switch to a new log alerts
API as described in Switch API preference for log alerts.

2. Select Monitor from the pane on the left side. Under Insights, select Containers.
3. On the Monitored Clusters tab, select a cluster from the list.
4. In the pane on the left side under Monitoring, select Logs to open the Azure Monitor logs page. You use
this page to write and execute Azure Log Analytics queries.
5. On the Logs page, select +New alert rule.
6. In the Condition section, select the Whenever the Custom log search is <logic undefined> pre-
defined custom log condition. The custom log search signal type is automatically selected because we're
creating an alert rule directly from the Azure Monitor logs page.
7. Paste one of the queries provided earlier into the Search query field.
8. Configure the alert as follows:
a. From the Based on drop-down list, select Metric measurement. A metric measurement creates an
alert for each object in the query that has a value above our specified threshold.
b. For Condition, select Greater than, and enter 75 as an initial baseline Threshold for the CPU and
memory utilization alerts. For the low disk space alert, enter 90. Or enter a different value that meets
your criteria.
c. In the Trigger Alert Based On section, select Consecutive breaches. From the drop-down list, select
Greater than, and enter 2.
d. To configure an alert for container CPU or memory utilization, under Aggregate on, select
ContainerName. To configure for cluster node low disk alert, select ClusterId.
e. In the Evaluated based on section, set the Period value to 60 minutes. The rule will run every 5
minutes and return records that were created within the last hour from the current time. Setting the time
period to a wide window accounts for potential data latency. It also ensures that the query returns data
to avoid a false negative in which the alert never fires.
9. Select Done to complete the alert rule.
10. Enter a name in the Alert rule name field. Specify a Description that provides details about the alert. And
select an appropriate severity level from the options provided.
11. To immediately activate the alert rule, accept the default value for Enable rule upon creation.
12. Select an existing Action Group or create a new group. This step ensures that the same actions are taken
every time that an alert is triggered. Configure based on how your IT or DevOps operations team manages
incidents.
13. Select Create alert rule to complete the alert rule. It starts running immediately.
Next steps
View log query examples to see pre-defined queries and examples to evaluate or customize for alerting,
visualizing, or analyzing your clusters.
To learn more about Azure Monitor and how to monitor other aspects of your AKS cluster, see View Azure
How to manage the Azure Monitor for containers
agent
Azure Monitor for containers uses a containerized version of the Log Analytics agent for Linux. After initial
deployment, there are routine or optional tasks you may need to perform during its lifecycle. This article details on
how to manually upgrade the agent and disable collection of environmental variables from a particular container.
How to upgrade the Azure Monitor for containers agent

Azure Monitor for containers uses a containerized version of the Log Analytics agent for Linux. When a new
version of the agent is released, the agent is automatically upgraded on your managed Kubernetes clusters hosted
on Azure Kubernetes Service (AKS ).
If the agent upgrade fails, this article describes the process to manually upgrade the agent. To follow the versions
released, see agent release announcements.
Upgrading agent on monitored Kubernetes cluster
The process to upgrade the agent consists of two straight forward steps. The first step is to disable monitoring with
Azure Monitor for containers using Azure CLI. Follow the steps described in the Disable monitoring article. Using
Azure CLI allows us to remove the agent from the nodes in the cluster without impacting the solution and the
corresponding data that is stored in the workspace.
NOTE
While you are performing this maintenance activity, the nodes in the cluster are not forwarding collected data, and
performance views will not show data between the time you remove the agent and install the new version.
To install the new version of the agent, follow the steps described in the enable monitoring using Azure CLI, to
complete this process.
After you've re-enabled monitoring, it might take about 15 minutes before you can view updated health metrics for
the cluster. To verify the agent upgraded successfully, run the command:
kubectl logs omsagent-484hw --namespace=kube-system
The status should resemble the following example, where the value for omi and omsagent should match the latest
version specified in the agent release history.
User@aksuser:~$ kubectl logs omsagent-484hw --namespace=kube-system
:
:
instance of Container_HostInventory
{
[Key] InstanceID=3a4407a5-d840-4c59-b2f0-8d42e07298c2
Computer=aks-nodepool1-39773055-0
DockerVersion=1.13.1
OperatingSystem=Ubuntu 16.04.3 LTS
Volume=local
Network=bridge host macvlan null overlay
NodeRole=Not Orchestrated
OrchestratorType=Kubernetes
}
Primary Workspace: b438b4f6-912a-46d5-9cb1-b44069212abc Status: Onboarded(OMSAgent Running)
omi 1.4.2.5
omsagent 1.6.0-163
docker-cimprov 1.0.0.31
How to disable environment variable collection on a container

Azure Monitor for containers collects environmental variables from the containers running in a pod and presents
them in the property pane of the selected container in the Containers view. You can control this behavior by
disabling collection for a specific container either during deployment of the AKS cluster, or after by setting the
environment variable AZMON_COLLECT_ENV. This feature is available from the agent version – ciprod11292018
and higher.
To disable collection of environmental variables on a new or existing container, set the variable
AZMON_COLLECT_ENV with a value of False in your Kubernetes deployment yaml configuration file.
- name: AZMON_COLLECT_ENV
value: "False"
Run the following command to apply the change to your AKS container: kubectl apply -f <path to yaml file> .
To verify the configuration change took effect, select a container in the Containers view in Azure Monitor for
containers, and in the property panel, expand Environment Variables. The section should show only the variable
created earlier - AZMON_COLLECT_ENV=FALSE. For all other containers, the Environment Variables section
should list all the environment variables discovered.
To re-enable discovery of the environmental variables, apply the same process earlier and change the value from
False to True, and then rerun the kubectl command to update the container.
- name: AZMON_COLLECT_ENV
value: "True"
Next steps
If you experience issues while upgrading the agent, review the troubleshooting guide for support.
Configure agent data collection for Azure Monitor for
containers
Azure Monitor for containers collects stdout, stderr, and environmental variables from container workloads deployed to managed
Kubernetes clusters hosted on Azure Kubernetes Service (AKS ) from the containerized agent. This agent can also collect time series
data (also referred to as metrics) from Prometheus using the containerized agent without having to set up and manage a
Prometheus server and database. You can configure agent data collection settings by creating a custom Kubernetes ConfigMaps to
control this experience.
This article demonstrates how to create ConfigMap and configure data collection based on your requirements.
NOTE
ConfigMap file settings overview

A template ConfigMap file is provided that allows you to easily edit it with your customizations without having to create it from
scratch. Before starting, you should review the Kubernetes documentation about ConfigMaps and familiarize yourself with how to
create, configure, and deploy ConfigMaps. This will allow you to filter stderr and stdout per namespace or across the entire cluster,
and environment variables for any container running across all pods/nodes in the cluster.
IMPORTANT
The minimum agent version supported to collect stdout, stderr, and environmental variables from container workloads is ciprod06142019 or
later. The minimum agent version supported for scraping Prometheus metrics is ciprod07092019 or later. To verify your agent version, from the
Node tab select a node, and in the properties pane note value of the Agent Image Tag property.
Data collection settings

The following are the settings that can be configured to control data collection.
KEY DATA TYPE VALUE DESCRIPTION
schema-version String (case sensitive) v1 This is the schema version used

by the agent when parsing this
ConfigMap. Currently supported
schema-version is v1. Modifying
this value is not supported and
will be rejected when ConfigMap
is evaluated.
config-version String Supports ability to keep track of

this config file's version in your
source control system/repository.
Maximum allowed characters are
10, and all other characters are
truncated.
KEY DATA TYPE VALUE DESCRIPTION
[log_collection_settings.stdout] Boolean true or false This controls if stdout container

enabled = log collection is enabled. When
set to true and no namespaces
are excluded for stdout log
collection (
log_collection_settings.stdout.exclude_namesp
setting below), stdout logs will be
collected from all containers
across all pods/nodes in the
cluster. If not specified in
ConfigMaps, the default value is
enabled = true .
[log_collection_settings.stdout] String Comma-separated array Array of Kubernetes namespaces

exclude_namespaces = for which stdout logs will not be
collected. This setting is effective
only if
log_collection_settings.stdout.enabled
is set to true . If not specified in
ConfigMap, the default value is
exclude_namespaces = ["kube-
system"]
.
[log_collection_settings.stderr] Boolean true or false This controls if stderr container

enabled = log collection is enabled. When
set to true and no namespaces
are excluded for stdout log
collection (
log_collection_settings.stderr.exclude_namesp
setting), stderr logs will be
collected from all containers
across all pods/nodes in the
cluster. If not specified in
ConfigMaps, the default value is
enabled = true .
[log_collection_settings.stderr] String Comma-separated array Array of Kubernetes namespaces

exclude_namespaces = for which stderr logs will not be
collected. This setting is effective
only if
log_collection_settings.stdout.enabled
is set to true . If not specified in
exclude_namespaces = ["kube-
system"]
.
[log_collection_settings.env_var]Boolean true or false This controls if environment

enabled = variable collection is enabled.
When set to false , no
environment variables are
collected for any container
running across all pods/nodes in
the cluster. If not specified in
enabled = true .
Prometheus scraping settings

Azure Monitor for containers provides a seamless experience to enable collection of Prometheus metrics by multiple scraping
through the following mechanisms as shown in the following table. The metrics are collected through a set of settings specified in a
single ConfigMap file, which is the same file used to configure collection of stdout, stderr, and environmental variables from
container workloads.
Active scraping of metrics from Prometheus is performed from one of two perspectives:
Cluster-wide - HTTP URL and discover targets from listed endpoints of a service, k8s services such as kube-dns and kube-state-
metrics, and pod annotations specific to an application. Metrics collected in this context will be defined in the ConfigMap section
[Prometheus data_collection_settings.cluster ].
Node-wide - HTTP URL and discover targets from listed endpoints of a service. Metrics collected in this context will be defined in
the ConfigMap section [Prometheus_data_collection_settings.node].
ENDPOINT SCOPE EXAMPLE
Pod annotation Cluster-wide annotations:

prometheus.io/scrape: "true"
prometheus.io/path: "/mymetrics"
prometheus.io/port: "8000"
<br>prometheus.io/scheme: "http"
Kubernetes service Cluster-wide http://my-service-dns.my-

namespace:9100/metrics
https://metrics-server.kube-
system.svc.cluster.local/metrics
url/endpoint Per-node and/or cluster-wide http://myurl:9101/metrics
When a URL is specified, Azure Monitor for containers only scrapes the endpoint. When Kubernetes service is specified, the service
name is resolved with the cluster DNS server to get the IP address and then the resolved service is scraped.
SCOPE KEY DATA TYPE VALUE DESCRIPTION
Cluster-wide Specify any one of the

following three methods
to scrape endpoints for
metrics.
urls String Comma-separated array HTTP endpoint (Either IP

address or valid URL path
specified). For example:
urls=
[$NODE_IP/metrics]
. ($NODE_IP is a specific
Azure Monitor for
containers parameter and
can be used instead of
node IP address. Must be
all uppercase.)
kubernetes_services String Comma-separated array An array of Kubernetes

services to scrape metrics
from kube-state-metrics.
For example,
kubernetes_services = ["https://metric
server.kube-
system.svc.cluster.local/metrics",http
service-dns.my-namespace:9100/metrics]
.
monitor_kubernetes_pods Boolean true or false When set to true in the

cluster-wide settings,
Azure Monitor for
containers agent will
scrape Kubernetes pods
across the entire cluster
for the following
Prometheus annotations:
prometheus.io/scrape:
prometheus.io/scheme:
prometheus.io/path:
prometheus.io/port:
prometheus.io/scrape Boolean true or false Enables scraping of the

pod.
monitor_kubernetes_pods
must be set to true .
prometheus.io/scheme String http or https Defaults to scrapping over

HTTP. If necessary, set to
https .
prometheus.io/path String Comma-separated array The HTTP resource path

on which to fetch metrics
from. If the metrics path is
not /metrics , define it
with this annotation.
prometheus.io/port String 9102 Specify a port to listen on.

If port is not set, it will
default to 9102.
Node-wide urls String Comma-separated array HTTP endpoint (Either IP

address or valid URL path
specified). For example:
urls=
[$NODE_IP/metrics]
. ($NODE_IP is a specific
Azure Monitor for
containers parameter and
can be used instead of
node IP address. Must be
all uppercase.)
Node-wide or Cluster- interval String 60s The collection interval

wide default is one minute (60
seconds). You can modify
the collection for either
the
[prometheus_data_collect
ion_settings.node] and/or
[prometheus_data_collect
ion_settings.cluster] to
time units such as ns, us
(or Âµs), ms, s, m, h.
Node-wide or Cluster- fieldpass String Comma-separated array You can specify certain
wide fielddrop metrics to be collected or
not from the endpoint by
setting the allow (
fieldpass ) and disallow
( fielddrop ) listing. You
must set the allow list
first.
ConfigMap is a global list and there can be only one ConfigMap applied to the agent. You cannot have another ConfigMap
overruling the collections.
Configure and deploy ConfigMaps

Perform the following steps to configure and deploy your ConfigMap configuration file to your cluster.
1. Download the template ConfigMap yaml file and save it as container-azm-ms-agentconfig.yaml.
2. Edit the ConfigMap yaml file with your customizations.
To exclude specific namespaces for stdout log collection, you configure the key/value using the following example:
[log_collection_settings.stdout] enabled = true exclude_namespaces = ["my-namespace-1", "my-namespace-2"] .
To disable environment variable collection for a specific container, set the key/value
[log_collection_settings.env_var] enabled = true to enable variable collection globally, and then follow the steps here
to complete configuration for the specific container.
To disable stderr log collection cluster-wide, you configure the key/value using the following example:
[log_collection_settings.stderr] enabled = false .
The following examples demonstrates how to configure the ConfigMap file metrics from a URL cluster-wide, from an
agent's DameonSet node-wide, and by specifying a pod annotation
Scrape Prometheus metrics from a specific URL across the cluster.
prometheus-data-collection-settings: |-
# Custom Prometheus metrics data collection settings
[prometheus_data_collection_settings.cluster]
interval = "1m" ## Valid time units are ns, us (or µs), ms, s, m, h.
fieldpass = ["metric_to_pass1", "metric_to_pass12"] ## specify metrics to pass through
fielddrop = ["metric_to_drop"] ## specify metrics to drop from collecting
urls = ["http://myurl:9101/metrics"] ## An array of urls to scrape metrics from
Scrape Prometheus metrics from an agent's DaemonSet running in every node in the cluster.
[prometheus_data_collection_settings.node]
interval = "1m" ## Valid time units are ns, us (or µs), ms, s, m, h.
# Node level scrape endpoint(s). These metrics will be scraped from agent's DaemonSet running in every node in the
cluster
urls = ["http://$NODE_IP:9103/metrics"]
fieldpass = ["metric_to_pass1", "metric_to_pass2"]
fielddrop = ["metric_to_drop"]
Scrape Prometheus metrics by specifying a pod annotation.

[prometheus_data_collection_settings.cluster]
interval = "1m" ## Valid time units are ns, us (or µs), ms, s, m, h
monitor_kubernetes_pods = true #replicaset will scrape Kubernetes pods for the following prometheus annotations:
- prometheus.io/scrape:"true" #Enable scraping for this pod
- prometheus.io/scheme:"http:" #If the metrics endpoint is secured then you will need to set this to `https`, if
not default ‘http’
- prometheus.io/path:"/mymetrics" #If the metrics path is not /metrics, define it with this annotation.
- prometheus.io/port:"8000" #If port is not 9102 use this annotation
3. Create ConfigMap by running the following kubectl command: kubectl apply -f <configmap_yaml_file.yaml> .
Example: kubectl apply -f container-azm-ms-agentconfig.yaml .
The configuration change can take a few minutes to finish before taking effect, and all omsagent pods in the cluster will
restart. The restart is a rolling restart for all omsagent pods, not all restart at the same time. When the restarts are finished, a
message is displayed that's similar to the following and includes the result: configmap "container-azm-ms-agentconfig" created .
To verify the configuration was successfully applied, use the following command to review the logs from an agent pod:
kubectl logs omsagent-fdf58 -n=kube-system . If there are configuration errors from the omsagent pods, the output will show errors
similar to the following:
***************Start Config Processing********************

config::unsupported/missing config schema version - 'v21' , using defaults
Errors related to applying configuration changes for Prometheus are also available for review. Either from the logs from an agent
pod using the same kubectl logs command or from live logs. Live logs show errors similar to the following:
2019-07-08T18:55:00Z E! [inputs.prometheus]: Error in plugin: error making HTTP request to http://invalidurl:1010/metrics: Get
http://invalidurl:1010/metrics: dial tcp: lookup invalidurl on 10.0.0.10:53: no such host
Errors prevent omsagent from parsing the file, causing it to restart and use the default configuration. After you correct the error(s) in
ConfigMap, save the yaml file and apply the updated ConfigMaps by running the command:
kubectl apply -f <configmap_yaml_file.yaml .
Applying updated ConfigMap

If you have already deployed a ConfigMap to your cluster and you want to update it with a newer configuration, you can edit the
ConfigMap file you've previously used and then apply using the same command as before,
kubectl apply -f <configmap_yaml_file.yaml .
The configuration change can take a few minutes to finish before taking effect, and all omsagent pods in the cluster will restart. The
restart is a rolling restart for all omsagent pods, not all restart at the same time. When the restarts are finished, a message is
displayed that's similar to the following and includes the result: configmap "container-azm-ms-agentconfig" updated .
Verifying schema version

Supported config schema versions are available as pod annotation (schema-versions) on the omsagent pod. You can see them with
the following kubectl command: kubectl describe pod omsagent-fdf58 -n=kube-system
The output will show similar to the following with the annotation schema-versions:
Name: omsagent-fdf58
Namespace: kube-system
Node: aks-agentpool-95673144-0/10.240.0.4
Start Time: Mon, 10 Jun 2019 15:01:03 -0700
Labels: controller-revision-hash=589cc7785d
dsName=omsagent-ds
pod-template-generation=1
Annotations: agentVersion=1.10.0.1
dockerProviderVersion=5.0.0-0
schema-versions=v1
Review Prometheus data usage
To view prometheus metrics scraped by Azure Monitor, specify "prometheus" as the Namespace. Here is a sample query to view
prometheus metrics from the default kubernetes namespace.
InsightsMetrics
| where Namespace contains "prometheus"
| extend tags=parse_json(Tags)
| where tostring(tags.namespace) == "default"
Prometheus data can also be directly queried by name.
InsightsMetrics
| where Name contains "some_prometheus_metric"
To identify the ingestion volume of each metrics size in GB per day to understand if it is high, the following query is provided.
InsightsMetrics
| summarize VolumeInGB = (sum(_BilledSize) / (1024 * 1024 * 1024)) by Name
| order by VolumeInGB desc
| render barchart
To estimate what each metrics size in GB is for a month to understand if the volume of data ingested received in the workspace is
high, the following query is provided.
InsightsMetrics
| summarize EstimatedGBPer30dayMonth = (sum(_BilledSize) / (1024 * 1024 * 1024)) * 30 by Name
| order by EstimatedGBPer30dayMonth desc
| render barchart

Further information on how to monitor data usage and analyze cost is available in Manage usage and costs with Azure Monitor
Logs.
Next steps
Azure Monitor for containers does not include a predefined set of alerts. Review the Create performance alerts with Azure Monitor
for containers to learn how to create recommended alerts for high CPU and memory utilization to support your DevOps or
operational processes and procedures.
To continue learning how to use Azure Monitor and monitor other aspects of your AKS cluster, see View Azure Kubernetes
Service health.
View log query examples to see pre-defined queries and examples to evaluate or customize for alerting, visualizing, or
analyzing your clusters.
How to update Azure Monitor for containers to
enable metrics
Azure Monitor for containers is introducing support for collecting metrics from Azure Kubernetes Services (AKS )
clusters nodes and pods and writing them to the Azure Monitor metrics store. This change is intended to deliver
improved timeliness when presenting aggregate calculations (Avg, Count, Max, Min, Sum) in performance charts,
support pinning performance charts in Azure portal dashboards, and support metric alerts.
The following metrics are enabled as part of this feature:
METRIC NAMESPACE METRIC DESCRIPTION
insights.container/nodes cpuUsageMillicores, These are node metrics and include host

cpuUsagePercentage, memoryRssBytes, as a dimension, and they also include
memoryRssPercentage, the
memoryWorkingSetBytes, node’s name as value for the host
memoryWorkingSetPercentage, dimension.
nodesCount
insights.container/pods podCount These are pod metrics and include the

following as dimensions -
ControllerName, Kubernetes
namespace, name, phase.
Updating the cluster to support these new capabilities can be performed from the Azure portal, Azure PowerShell,
or with Azure CLI. With Azure PowerShell and CLI, you can enable this per-cluster or for all clusters in your
subscription. New deployments of AKS will automatically include this configuration change and capabilities.
Either process assigns the Monitoring Metrics Publisher role to the cluster’s service principal so that the data
collected by the agent can be published to your clusters resource. Monitoring Metrics Publisher has permission
only to push metrics to the resource, it cannot alter any state, update the resource, or read any data. For further
information about the role, see Monitoring Metrics Publisher role.
Prerequisites
Before you start, make sure that you are a member of the Owner role on the AKS cluster resource to enable
collection of node and pod custom performance metrics.
Upgrade a cluster from the Azure portal

For existing AKS clusters monitored by Azure Monitor for containers, after selecting the cluster to view its health
from the multi-cluster view in Azure Monitor or directly from the cluster by selecting Insights from the left-hand
pane, you should see a banner at the top of the portal.
Clicking Enable will initiate the process to upgrade the cluster. This process can take several seconds to finish, and
you can track its progress under Notifications from the menu.
Upgrade all clusters using Bash in Azure Command Shell

Perform the following steps to update all clusters in your subscription using Bash in Azure Command Shell.
1. Run the following command by using the Azure CLI. Edit the value for subscriptionId using the value from
the AKS Overview page for the AKS cluster.
az login
curl -sL https://aka.ms/ci-md-onboard-atscale | bash -s subscriptionId
The configuration change can take a few seconds to complete. When it's completed, a message is displayed
that's similar to the following and includes the result:
completed role assignments for all AKS clusters in subscription: <subscriptionId>
Upgrade per cluster using Azure CLI

Perform the following steps to update a specific cluster in your subscription using Azure CLI.
1. Run the following command by using the Azure CLI. Edit the values for subscriptionId,
resourceGroupName, and clusterName using the values on the AKS Overview page for the AKS cluster.
To get the value of clientIdOfSPN, it is returned when you run the command az aks show as shown in the
example below.
az login
az aks show -g <resourceGroupName> -n <clusterName>
az role assignment create --assignee <clientIdOfSPN> --scope <clusterResourceId> --role "Monitoring
Metrics Publisher"
Upgrade all clusters using Azure PowerShell

Perform the following steps to update all clusters in your subscription using Azure PowerShell.
1. Copy and paste the following script into your file:
<#
.DESCRIPTION
Adds the Monitoring Metrics Publisher role assignment to the all AKS clusters in specified
subscription
.PARAMETER SubscriptionId
Subscription Id that the AKS cluster is in
#>
param(
[Parameter(mandatory = $true)]
[string]$SubscriptionId
)
# checks the required Powershell modules exist and if not exists, request the user permission to install
$azAccountModule = Get-Module -ListAvailable -Name Az.Accounts
$azAksModule = Get-Module -ListAvailable -Name Az.Aks
$azResourcesModule = Get-Module -ListAvailable -Name Az.Resources
if (($null -eq $azAccountModule) -or ( $null -eq $azAksModule ) -or ($null -eq $azResourcesModule)) {
$currentPrincipal = New-Object
Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if ($currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Host("Running script as an admin...")
Write-Host("")
}
else {
Write-Host("Please run the script as an administrator") -ForegroundColor Red
Stop-Transcript
exit
}
$message = "This script will try to install the latest versions of the following Modules : `
Az.Resources, Az.Accounts and Az.Aks using the command if not installed already`
`'Install-Module {Insert Module Name} -Repository PSGallery -Force -AllowClobber -ErrorAction
Stop -WarningAction Stop'
Ìf you do not have the latest version of these Modules, this troubleshooting script may not
run."
$question = "Do you want to Install the modules and run the script or just run the script?"
$choices = New-Object Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescription]

$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes, Install and
run'))
$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Continue without
installing the Module'))
$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Quit'))
$decision = $Host.UI.PromptForChoice($message, $question, $choices, 0)
switch ($decision) {
0 {
if ($null -eq $azResourcesModule) {

try {
Write-Host("Installing Az.Resources...")
Install-Module Az.Resources -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
Write-Host("Close other powershell logins and try installing the latest modules
forAz.Accounts in a new powershell window: eg. 'Install-Module Az.Accounts -Repository PSGallery -
Force'") -ForegroundColor Red
exit
}
}
if ($null -eq $azAccountModule) {

try {
Write-Host("Installing Az.Accounts...")
Install-Module Az.Accounts -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
exit
}
}
if ($null -eq $azAksModule) {

try {
Write-Host("Installing Az.Aks...")
Install-Module Az.Aks -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
Write-Host("Close other powershell logins and try installing the latest modules for
Az.Aks in a new powershell window: eg. 'Install-Module Az.Aks -Repository PSGallery -Force'") -
ForegroundColor Red
exit
}
}
}
1 {

try {
Import-Module Az.Resources -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Resources...") -ForegroundColor Red
Az.Resources in a new powershell window: eg. 'Install-Module Az.Resources -Repository PSGallery -
Stop-Transcript
exit
}
}
try {
Import-Module Az.Accounts -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Accounts...") -ForegroundColor Red
Az.Accounts in a new powershell window: eg. 'Install-Module Az.Accounts -Repository PSGallery -Force'")
-ForegroundColor Red
Stop-Transcript
exit
}
}
try {
Import-Module Az.Aks -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Aks... Please reinstall this Module") -ForegroundColor
Red
Stop-Transcript
exit
exit
}
}
}
2 {
Write-Host("")
Stop-Transcript
exit
}
}
}
try {
Write-Host("")
Write-Host("Trying to get the current Az login context...")
$account = Get-AzContext -ErrorAction Stop
Write-Host("Successfully fetched current AzContext context...") -ForegroundColor Green
Write-Host("")
}
catch {
Write-Host("")
Write-Host("Could not fetch AzContext..." ) -ForegroundColor Red
Write-Host("")
}
if ($account.Account -eq $null) {

try {
Write-Host("Please login...")
Connect-AzAccount -subscriptionid $SubscriptionId
}
catch {
Write-Host("")
Write-Host("Could not select subscription with ID : " + $SubscriptionId + ". Please make sure the ID
you entered is correct and you have access to the cluster" ) -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
}
else {
if ($account.Subscription.Id -eq $SubscriptionId) {
Write-Host("Subscription: $SubscriptionId is already selected. Account details: ")
$account
}
else {
try {
Write-Host("Current Subscription:")
$account
Write-Host("Changing to subscription: $SubscriptionId")
}
catch {
Write-Host("")
Write-Host("Could not select subscription with ID : " + $SubscriptionId + ". Please make sure
the ID you entered is correct and you have access to the cluster" ) -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
}
}
#
# get all the AKS clusters in specified subscription
#
Write-Host("getting all aks clusters in specified subscription ...")
$allClusters = Get-AzAks -ErrorVariable notPresent -ErrorAction SilentlyContinue
if ($notPresent) {
Write-Host("")
Write-Host("")
Write-Host("Failed to get Aks clusters in specified subscription. Please make sure that you have access
to the existing clusters") -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
Write-Host("Successfully got all aks clusters ...") -ForegroundColor Green
$clustersCount = $allClusters.Id.Length
Write-Host("Adding role assignment for the clusters ...")
for ($index = 0 ; $index -lt $clustersCount ; $index++) {
#
# Add Monitoring Metrics Publisher role assignment to the AKS cluster resource
#
$servicePrincipalClientId = $allClusters.ServicePrincipalProfile[$index].ClientId
$clusterResourceId = $allClusters.Id[$index]
$clusterName = $allClusters.Name[$index]
Write-Host("Adding role assignment for the cluster: $clusterResourceId, servicePrincipalClientId:

$servicePrincipalClientId ...")
New-AzRoleAssignment -ApplicationId $servicePrincipalClientId -scope $clusterResourceId -

RoleDefinitionName "Monitoring Metrics Publisher" -ErrorVariable assignmentError -ErrorAction
SilentlyContinue
if ($assignmentError) {
$roleAssignment = Get-AzRoleAssignment -scope $clusterResourceId -RoleDefinitionName "Monitoring

Metrics Publisher" -ErrorVariable getAssignmentError -ErrorAction SilentlyContinue
if ($assignmentError.Exception -match "role assignment already exists" -or ( $roleAssignment -and
$roleAssignment.ObjectType -like "ServicePrincipal" )) {
Write-Host("Monitoring Metrics Publisher role assignment already exists on the cluster resource
: '" + $clusterName + "'") -ForegroundColor Green
}
else {
Write-Host("Failed to add Monitoring Metrics Publisher role assignment to cluster : '" +

$clusterName + "' , error : $assignmentError") -ForegroundColor Red
}
}
else {
Write-Host("Successfully added Monitoring Metrics Publisher role assignment to cluster : '" +

$clusterName + "'") -ForegroundColor Green
Write-Host("Completed adding role assignment for the cluster: $clusterName ...")
Write-Host("Completed adding role assignment for the aks clusters in subscriptionId :$SubscriptionId")
2. Save this file as onboard_metrics_atscale.ps1 to a local folder.

3. Run the following command by using the Azure PowerShell. Edit the value for subscriptionId using the
value from the AKS Overview page for the AKS cluster.
.\onboard_metrics_atscale.ps1 subscriptionId
Completed adding role assignment for the aks clusters in subscriptionId :<subscriptionId>
Upgrade per cluster using Azure PowerShell

Perform the following steps to update a specific cluster using Azure PowerShell.
1. Copy and paste the following script into your file:
<#
.DESCRIPTION
Adds the Monitoring Metrics Publisher role assignment to the specified AKS cluster
.PARAMETER SubscriptionId
Subscription Id that the AKS cluster is in
.PARAMETER resourceGroupName
Resource Group name that the AKS cluster is in
.PARAMETER clusterName
Name of the AKS cluster.
#>
param(
[string]$SubscriptionId,
[string]$resourceGroupName,
[string] $clusterName
)
# checks the required Powershell modules exist and if not exists, request the user permission to install
$azAccountModule = Get-Module -ListAvailable -Name Az.Accounts
$azAksModule = Get-Module -ListAvailable -Name Az.Aks
$azResourcesModule = Get-Module -ListAvailable -Name Az.Resources
if (($null -eq $azAccountModule) -or ($null -eq $azAksModule) -or ($null -eq $azResourcesModule)) {
$currentPrincipal = New-Object
Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if ($currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Host("Running script as an admin...")
Write-Host("")
}
else {
Write-Host("Please run the script as an administrator") -ForegroundColor Red
Stop-Transcript
exit
}
$message = "This script will try to install the latest versions of the following Modules : `
Az.Resources, Az.Accounts and Az.Aks using the command`
`'Install-Module {Insert Module Name} -Repository PSGallery -Force -AllowClobber -ErrorAction
Ìf you do not have the latest version of these Modules, this troubleshooting script may not
run."
$question = "Do you want to Install the modules and run the script or just run the script?"
$choices = New-Object Collections.ObjectModel.Collection[Management.Automation.Host.ChoiceDescription]

$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Yes, Install and
run'))
$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Continue without
installing the Module'))
$choices.Add((New-Object Management.Automation.Host.ChoiceDescription -ArgumentList '&Quit'))
$decision = $Host.UI.PromptForChoice($message, $question, $choices, 0)
switch ($decision) {
0 {

try {
Write-Host("Installing Az.Resources...")
Install-Module Az.Resources -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
exit
}
}

try {
Write-Host("Installing Az.Accounts...")
Install-Module Az.Accounts -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
exit
}
}

try {
Write-Host("Installing Az.Aks...")
Install-Module Az.Aks -Repository PSGallery -Force -AllowClobber -ErrorAction Stop
}
catch {
Az.Aks in a new powershell window: eg. 'Install-Module Az.Aks -Repository PSGallery -Force'") -
ForegroundColor Red
exit
}
}
}
1 {

try {
Import-Module Az.Resources -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Resources...") -ForegroundColor Red
Az.Resources in a new powershell window: eg. 'Install-Module Az.Resources -Repository PSGallery -
Stop-Transcript
exit
exit
}
}
try {
Import-Module Az.Accounts -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Accounts...") -ForegroundColor Red
Az.Accounts in a new powershell window: eg. 'Install-Module Az.Accounts -Repository PSGallery -Force'")
-ForegroundColor Red
Stop-Transcript
exit
}
}
try {
Import-Module Az.Aks -ErrorAction Stop
}
catch {
Write-Host("Could not import Az.Aks... Please reinstall this Module") -ForegroundColor
Red
Stop-Transcript
exit
}
}
}
2 {
Write-Host("")
Stop-Transcript
exit
}
}
}
try {
Write-Host("")
Write-Host("Trying to get the current Az login context...")
$account = Get-AzContext -ErrorAction Stop
Write-Host("Successfully fetched current AzContext context...") -ForegroundColor Green
Write-Host("")
}
catch {
Write-Host("")
Write-Host("Could not fetch AzContext..." ) -ForegroundColor Red
Write-Host("")
}
if ($account.Account -eq $null) {

try {
Write-Host("Please login...")
Connect-AzAccount -subscriptionid $SubscriptionId
}
catch {
Write-Host("")
Write-Host("Could not select subscription with ID : " + $SubscriptionId + ". Please make sure the ID
you entered is correct and you have access to the cluster" ) -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
}
else {
if ($account.Subscription.Id -eq $SubscriptionId) {
Write-Host("Subscription: $SubscriptionId is already selected. Account details: ")
$account
}
}
else {
try {
Write-Host("Current Subscription:")
$account
Write-Host("Changing to subscription: $SubscriptionId")
}
catch {
Write-Host("")
Write-Host("Could not select subscription with ID : " + $SubscriptionId + ". Please make sure
the ID you entered is correct and you have access to the cluster" ) -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
}
}
#
# Check AKS cluster existance and access check
#
Write-Host("Checking aks cluster exists...")
$cluster = Get-AzAks -ResourceGroupName $resourceGroupName -Name $clusterName -ErrorVariable notPresent
-ErrorAction SilentlyContinue
if ($notPresent) {
Write-Host("")
Write-Host("Could not find Aks cluster. Please make sure that specified cluster exists: '" +
$clusterName + "'is correct and you have access to the cluster") -ForegroundColor Red
Write-Host("")
Stop-Transcript
exit
}
Write-Host("Successfully checked specified cluster exists details...") -ForegroundColor Green
$servicePrincipalClientId = $cluster.ServicePrincipalProfile.clientId
$clusterResourceId = $cluster.Id
#
# Add Monitoring Metrics Publisher role assignment to the AKS cluster resource
#
New-AzRoleAssignment -ApplicationId $servicePrincipalClientId -scope $clusterResourceId -

RoleDefinitionName "Monitoring Metrics Publisher" -ErrorVariable assignmentError -ErrorAction
SilentlyContinue
if ($assignmentError) {
$roleAssignment = Get-AzRoleAssignment -scope $clusterResourceId -RoleDefinitionName "Monitoring Metrics

Publisher" -ErrorVariable getAssignmentError -ErrorAction SilentlyContinue
if ($assignmentError.Exception -match "role assignment already exists" -or ( $roleAssignment -and

$roleAssignment.ObjectType -like "ServicePrincipal" )) {
Write-Host("Monitoring Metrics Publisher role assignment already exists on the cluster resource : '"
+ $clusterName + "'") -ForegroundColor Green
}
else {
Write-Host("Failed to add Monitoring Metrics Publisher role assignment to cluster : '" +

$clusterName + "' , error : $assignmentError") -ForegroundColor Red
}
}
else {
Write-Host("Successfully added Monitoring Metrics Publisher role assignment to cluster : '" +

$clusterName + "'") -ForegroundColor Green
}
2. Save this file as onboard_metrics.ps1 to a local folder.
3. Run the following command by using the Azure PowerShell. Edit the values for subscriptionId,
resourceGroupName, and clusterName using the values on the AKS Overview page for the AKS cluster.
.\onboard_metrics.ps1 subscriptionId <subscriptionId> resourceGroupName <resourceGroupName> clusterName

<clusterName>
Successfully added Monitoring Metrics Publisher role assignment to cluster : <clusterName>
Verify update
After initiating the update using one of the methods described earlier, you can use Azure Monitor metrics explorer
and verify from the Metric namespace that insights is listed. If it is, this indicates you can go ahead and start
setting up metric alerts or pinning your charts to dashboards.
Troubleshooting Azure Monitor for containers
When you configure monitoring of your Azure Kubernetes Service (AKS ) cluster with Azure Monitor for
containers, you may encounter an issue preventing data collection or reporting status. This article details some
common issues and troubleshooting steps.
Authorization error during onboarding or update operation

While enabling Azure Monitor for containers or updating a cluster to support collecting metrics, you may receive
an error resembling the following - The client <user’s Identity>' with object id '<user’s objectId>' does not have
authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope
During the onboarding or update process, granting the Monitoring Metrics Publisher role assignment is
attempted on the cluster resource. The user initiating the process to enable Azure Monitor for containers or the
update to support the collection of metrics must have access to the
Microsoft.Authorization/roleAssignments/write permission on the AKS cluster resource scope. Only
members of the Owner and User Access Administrator built-in roles are granted access to this permission. If
your security policies require assigning granular level permissions, we recommend you view custom roles and
assign it to the users who require it.
You can also manually grant this role from the Azure portal by performing the following steps:
2. In the Azure portal, click All services found in the upper left-hand corner. In the list of resources, type
Kubernetes. As you begin typing, the list filters based on your input. Select Azure Kubernetes.
3. In the list of Kubernetes clusters, select one from the list.
4. From the left-hand menu, click Access control (IAM ).
5. Select + Add to add a role assignment and select the Monitoring Metrics Publisher role and under the
Select box type AKS to filter the results on just the clusters service principals defined in the subscription.
Select the one from the list that is specific to that cluster.
6. Select Save to finish assigning the role.
Azure Monitor for containers is enabled but not reporting any

information
If Azure Monitor for containers is successfully enabled and configured, but you cannot view status information or
no results are returned from a log query, you diagnose the problem by following these steps:
1. Check the status of the agent by running the command:

2. Check the deployment status with agent version 06072018 or later using the command:
The output should resemble the following example, which indicates that it was deployed properly:

omsagent 1 1 1 1 3h
3. Check the status of the pod to verify that it is running using the command:
kubectl get pods --namespace=kube-system
The output should resemble the following example with a status of Running for the omsagent:
User@aksuser:~$ kubectl get pods --namespace=kube-system

NAME READY STATUS RESTARTS AGE
aks-ssh-139866255-5n7k5 1/1 Running 0 8d
azure-vote-back-4149398501-7skz0 1/1 Running 0 22d
azure-vote-front-3826909965-30n62 1/1 Running 0 22d
omsagent-484hw 1/1 Running 0 1d
omsagent-fkq7g 1/1 Running 0 1d
4. Check the agent logs. When the containerized agent gets deployed, it runs a quick check by running OMI
commands and displays the version of the agent and provider.
5. To verify that the agent has been deployed successfully, run the command:
kubectl logs omsagent-484hw --namespace=kube-system
The status should resemble the following example:
User@aksuser:~$ kubectl logs omsagent-484hw --namespace=kube-system

:
:
instance of Container_HostInventory
{
[Key] InstanceID=3a4407a5-d840-4c59-b2f0-8d42e07298c2
Computer=aks-nodepool1-39773055-0
DockerVersion=1.13.1
OperatingSystem=Ubuntu 16.04.3 LTS
Volume=local
Network=bridge host macvlan null overlay
NodeRole=Not Orchestrated
OrchestratorType=Kubernetes
}
Primary Workspace: b438b4f6-912a-46d5-9cb1-b44069212abc Status: Onboarded(OMSAgent Running)
omi 1.4.2.2
omsagent 1.6.0.23
docker-cimprov 1.0.0.31
Error messages
The table below summarizes known errors you may encounter while using Azure Monitor for containers.
ERROR MESSAGES ACTION
Error Message No data for selected filters It may take some time to establish monitoring data flow for
newly created clusters. Allow at least 10 to 15 minutes for
data to appear for your cluster.
ERROR MESSAGES ACTION
Error Message Error retrieving data While Azure Kubenetes Service cluster is setting up for health
and performance monitoring, a connection is established
between the cluster and Azure Log Analytics workspace. A
Log Analytics workspace is used to store all monitoring data
for your cluster. This error may occur when your Log Analytics
workspace has been deleted. Check if the workspace was
deleted and if it was, you will need to re-enable monitoring of
your cluster with Azure Monitor for containers and specify an
existing or create a new workspace. To re-enable, you will
need to disable monitoring for the cluster and enable Azure
Monitor for containers again.
Error retrieving data after adding Azure Monitor for When enable monitoring using az aks cli , Azure Monitor
containers through az aks cli for containers may not be properly deployed. Check whether
the solution is deployed. To do this, go to your Log Analytics
workspace and see if the solution is available by selecting
Solutions from the pane on the left-hand side. To resolve this
issue, you will need to redeploy the solution by following the
instructions on how to deploy Azure Monitor for containers
To help diagnose the problem, we have provided a troubleshooting script available here.
Next steps
With monitoring enabled to capture health metrics for both the AKS cluster nodes and pods, these health metrics
are available in the Azure portal. To learn how to use Azure Monitor for containers, see View Azure Kubernetes
Service health.
Container Monitoring solution in Azure Monitor
This article describes how to set up and use the Container Monitoring solution in Azure Monitor, which helps you
view and manage your Docker and Windows container hosts in a single location. Docker is a software
virtualization system used to create containers that automate software deployment to their IT infrastructure.
NOTE
Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the terminology to
better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.
The solution shows which containers are running, what container image they’re running, and where containers are
running. You can view detailed audit information showing commands used with containers. And, you can
troubleshoot containers by viewing and searching centralized logs without having to remotely view Docker or
Windows hosts. You can find containers that may be noisy and consuming excess resources on a host. And, you
can view centralized CPU, memory, storage, and network usage and performance information for containers. On
computers running Windows, you can centralize and compare logs from Windows Server, Hyper-V, and Docker
containers. The solution supports the following container orchestrators:
Docker Swarm
DC/OS
Kubernetes
Service Fabric
Red Hat OpenShift
If you have containers deployed in Azure Service Fabric, we recommend enabling both the Service Fabric solution
and this solution to include monitoring of cluster events. Before enabling the Service Fabric solution, review Using
the Service Fabric solution to understand what it provides and how to use it.
If you are interested in monitoring the performance of your workloads deployed to Kubernetes environments
hosted on Azure Kubernetes Service (AKS ), see Monitor Azure Kubernetes Service. The Container Monitoring
solution does not support monitoring that platform.
The following diagram shows the relationships between various container hosts and agents with Azure Monitor.
System requirements and supported platforms
Before starting, review the following details to verify you meet the prerequisites.
Container monitoring solution support for Docker Orchestrator and OS platform
The following table outlines the Docker orchestration and operating system monitoring support of container
inventory, performance, and logs with Azure Monitor.
CONTAI CONTAI
NER IMAGE NODE NER CONTAI CONTAI
WINDO INVENT INVENT INVENT PERFOR NER EVENT NER
ACS LINUX WS ORY ORY ORY MANCE EVENT LOG LOG
Kubern • • • • • • • • • •
etes
Mesos • • • • • • • • •
phere
DC/OS
Docker • • • • • • • • •
Swarm
Service • • • • • • • • •
Fabric
Red • • • • • • •
Hat
Open
Shift
Windo • • • • • • •
ws
Server
(standa
lone)
CONTAI CONTAI
NER IMAGE NODE NER CONTAI CONTAI
WINDO INVENT INVENT INVENT PERFOR NER EVENT NER
ACS LINUX WS ORY ORY ORY MANCE EVENT LOG LOG
Linux • • • • • • •
Server
(standa
lone)
Docker versions supported on Linux

Docker 1.11 to 1.13
Docker CE and EE v17.06
x64 Linux distributions supported as container hosts
Ubuntu 14.04 LTS and 16.04 LTS
CoreOS (stable)
Amazon Linux 2016.09.0
openSUSE 13.2
openSUSE LEAP 42.2
CentOS 7.2 and 7.3
SLES 12
RHEL 7.2 and 7.3
Red Hat OpenShift Container Platform (OCP ) 3.4 and 3.5
ACS Mesosphere DC/OS 1.7.3 to 1.8.8
ACS Kubernetes 1.4.5 to 1.6
Kubernetes events, Kubernetes inventory, and container processes are only supported with version 1.4.1-
45 and later of the Log Analytics agent for Linux
ACS Docker Swarm
NOTE
agent for Linux.
Supported Windows operating system

Windows Server 2016
Windows 10 Anniversary Edition (Professional or Enterprise)
Docker versions supported on Windows
Docker 1.12 and 1.13
Docker 17.03.0 and later
Installing and configuring the solution

Use the following information to install and configure the solution.
1. Add the Container Monitoring solution to your Log Analytics workspace from Azure marketplace or by
using the process described in Add monitoring solutions from the Solutions Gallery.
2. Install and use Docker with a Log Analytics agent. Based on your operating system and Docker orchestrator,
you can use the following methods to configure your agent.
For standalone hosts:
On supported Linux operating systems, install and run Docker and then install and configure the
Log Analytics agent for Linux.
On CoreOS, you cannot run the Log Analytics agent for Linux. Instead, you run a containerized
version of the Log Analytics agent for Linux. Review Linux container hosts including CoreOS or
Azure Government Linux container hosts including CoreOS if you are working with containers in
Azure Government Cloud.
On Windows Server 2016 and Windows 10, install the Docker Engine and client then connect an
agent to gather information and send it to Azure Monitor. Review Install and configure Windows
container hosts if you have a Windows environment.
For Docker multi-host orchestration:
If you have a Red Hat OpenShift environment, review Configure a Log Analytics agent for Red
Hat OpenShift.
If you have a Kubernetes cluster using the Azure Container Service:
Review Configure a Log Analytics Linux agent for Kubernetes.
Review Configure an Log Analytics Windows agent for Kubernetes.
Review Use Helm to deploy Log Analytics agent on Linux Kubernetes.
If you have an Azure Container Service DC/OS cluster, learn more at Monitor an Azure Container
Service DC/OS cluster with Azure Monitor.
If you have a Docker Swarm mode environment, learn more at Configure an Log Analytics agent
for Docker Swarm.
If you have a Service Fabric cluster, learn more at Monitor containers with Azure Monitor.
Review the Docker Engine on Windows article for additional information about how to install and configure your
Docker Engines on computers running Windows.
IMPORTANT
Docker must be running before you install the Log Analytics agent for Linux on your container hosts. If you've already
installed the agent before installing Docker, you need to reinstall the Log Analytics agent for Linux. For more information
about Docker, see the Docker website.
Install and configure Linux container hosts

After you've installed Docker, use the following settings for your container host to configure the agent for use with
Docker. First you need your Log Analytics workspace ID and key, which you can find in the Azure portal. In your
workspace, click Quick Start > Computers to view your Workspace ID and Primary Key. Copy and paste both
into your favorite editor.
For all Linux container hosts except CoreOS:
For more information and steps on how to install the Log Analytics agent for Linux, see Log Analytics agent
overview.
For all Linux container hosts including CoreOS:
Start the container that you want to monitor. Modify and use the following example:
sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v

/var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -
h=`hostname` -p 127.0.0.1:25225:25225 --name="omsagent" --restart=always microsoft/oms
For all Azure Government Linux container hosts including CoreOS:

Start the container that you want to monitor. Modify and use the following example:
sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/log:/var/log -v

/var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -e
DOMAIN="opinsights.azure.us" -p 127.0.0.1:25225:25225 -p 127.0.0.1:25224:25224/udp --name="omsagent" -
h=`hostname` --restart=always microsoft/oms
Switching from using an installed Linux agent to one in a container

If you previously used the directly-installed agent and want to instead use an agent running in a container, you
must first remove the Log Analytics agent for Linux. See Uninstalling the Log Analytics agent for Linux to
understand how to successfully uninstall the agent.
Configure a Log Analytics agent for Docker Swarm
You can run the Log Analytics agent as a global service on Docker Swarm. Use the following information to create
a Log Analytics agent service. You need to provide your Log Analytics Workspace ID and Primary Key.
Run the following on the master node.
sudo docker service create --name omsagent --mode global --mount

type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount
type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers -e WSID="<WORKSPACE
ID>" -e KEY="<PRIMARY KEY>" -p 25225:25225 -p 25224:25224/udp --restart-condition=on-failure
microsoft/oms
Se c u r e se c r e t s fo r D o c k e r Sw a r m
For Docker Swarm, once the secret for Workspace ID and Primary Key is created, use the following information to
create your secret information.
1. Run the following on the master node.
echo "WSID" | docker secret create WSID -

echo "KEY" | docker secret create KEY -
2. Verify that secrets were created properly.
keiko@swarmm-master-13957614-0:/run# sudo docker secret ls
ID NAME CREATED UPDATED

j2fj153zxy91j8zbcitnjxjiv WSID 43 minutes ago 43 minutes ago
l9rh3n987g9c45zffuxdxetd9 KEY 38 minutes ago 38 minutes ago
3. Run the following command to mount the secrets to the containerized Log Analytics agent.
sudo docker service create --name omsagent --mode global --mount

type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount
type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers --secret
source=WSID,target=WSID --secret source=KEY,target=KEY -p 25225:25225 -p 25224:25224/udp --restart-
condition=on-failure microsoft/oms
Configure a Log Analytics agent for Red Hat OpenShift

There are three ways to add the Log Analytics agent to Red Hat OpenShift to start collecting container monitoring
data.
Install the Log Analytics agent for Linux directly on each OpenShift node
Enable Log Analytics VM Extension on each OpenShift node residing in Azure
Install the Log Analytics agent as an OpenShift daemon-set
In this section we cover the steps required to install the Log Analytics agent as an OpenShift daemon-set.
1. Sign on to the OpenShift master node and copy the yaml file ocp-omsagent.yaml from GitHub to your
master node and modify the value with your Log Analytics Workspace ID and with your Primary Key.
2. Run the following commands to create a project for Azure Monitor and set the user account.
oc adm new-project omslogging --node-selector='zone=default'

oc project omslogging
oc create serviceaccount omsagent
oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:omslogging:omsagent
oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent
3. To deploy the daemon-set, run the following:

oc create -f ocp-omsagent.yaml
4. To verify it is configured and working correctly, type the following:

oc describe daemonset omsagent
and the output should resemble:
[ocpadmin@khm-0 ~]$ oc describe ds oms

Name: oms
Image(s): microsoft/oms
Selector: name=omsagent
Node-Selector: zone=default
Labels: agentVersion=1.4.0-12
name=omsagent
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Misscheduled: 0
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.
If you want to use secrets to secure your Log Analytics Workspace ID and Primary Key when using the Log
Analytics agent daemon-set yaml file, perform the following steps.
1. Sign on to the OpenShift master node and copy the yaml file ocp-ds-omsagent.yaml and secret generating
script ocp-secretgen.sh from GitHub. This script will generate the secrets yaml file for Log Analytics
Workspace ID and Primary Key to secure your secrete information.
2. Run the following commands to create a project for Azure Monitor and set the user account. The secret
generating script asks for your Log Analytics Workspace ID <WSID> and Primary Key <KEY> and upon
completion, it creates the ocp-secret.yaml file.
oc adm new-project omslogging --node-selector='zone=default'

oc project omslogging
oc create serviceaccount omsagent
oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:omslogging:omsagent
oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent
3. Deploy the secret file by running the following:

oc create -f ocp-secret.yaml
4. Verify deployment by running the following:

oc describe secret omsagent-secret
[ocpadmin@khocp-master-0 ~]$ oc describe ds oms

Name: oms
Image(s): microsoft/oms
Selector: name=omsagent
Node-Selector: zone=default
Labels: agentVersion=1.4.0-12
name=omsagent
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Misscheduled: 0
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.
5. Deploy the Log Analytics agent daemon-set yaml file by running the following:
oc create -f ocp-ds-omsagent.yaml
6. Verify deployment by running the following:

oc describe ds oms
[ocpadmin@khocp-master-0 ~]$ oc describe secret omsagent-secret

Name: omsagent-secret
Namespace: omslogging
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
KEY: 89 bytes
WSID: 37 bytes
Configure a Log Analytics Linux agent for Kubernetes

For Kubernetes, you use a script to generate the secrets yaml file for your Workspace ID and Primary Key to install
the Log Analytics agent for Linux. At the Log Analytics Docker Kubernetes GitHub page, there are files that you
can use with or without your secret information.
The Default Log Analytics agent for Linux DaemonSet does not have secret information (omsagent.yaml)
The Log Analytics agent for Linux DaemonSet yaml file uses secret information (omsagent-ds-secrets.yaml)
with secret generation scripts to generate the secrets yaml (omsagentsecret.yaml) file.
You can choose to create omsagent DaemonSets with or without secrets.
Default OMSagent DaemonSet yaml file without secrets
For the default Log Analytics agent DaemonSet yaml file, replace the <WSID> and <KEY> to your WSID and
KEY. Copy the file to your master node and run the following:
sudo kubectl create -f omsagent.yaml
Default OMSagent DaemonSet yaml file with secrets

1. To use Log Analytics agent DaemonSet using secret information, create the secrets first.
a. Copy the script and secret template file and make sure they are on the same directory.
Secret generating script - secret-gen.sh
secret template - secret-template.yaml
b. Run the script, like the following example. The script asks for the Log Analytics Workspace ID and
Primary Key and after you enter them, the script creates a secret yaml file so you can run it.
#> sudo bash ./secret-gen.sh
c. Create the secrets pod by running the following:
sudo kubectl create -f omsagentsecret.yaml
d. To verify, run the following:
keiko@ubuntu16-13db:~# sudo kubectl get secrets
Output should resemble:
NAME TYPE DATA AGE

default-token-gvl91 kubernetes.io/service-account-token 3 50d
omsagent-secret Opaque 2 1d
keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
WSID: 36 bytes
KEY: 88 bytes
e. Create your omsagent daemon-set by running sudo kubectl create -f omsagent-ds-secrets.yaml
2. Verify that the Log Analytics agent DaemonSet is running, similar to the following:
keiko@ubuntu16-13db:~# sudo kubectl get ds omsagent

NAME DESIRED CURRENT NODE-SELECTOR AGE
omsagent 3 3 <none> 1h
For Kubernetes, use a script to generate the secrets yaml file for Workspace ID and Primary Key for the Log
Analytics agent for Linux. Use the following example information with the omsagent yaml file to secure your secret
information.
keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret

Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
WSID: 36 bytes
KEY: 88 bytes
Configure a Log Analytics Windows agent for Kubernetes

For Windows Kubernetes, you use a script to generate the secrets yaml file for your Workspace ID and Primary
Key to install the Log Analytics agent. At the Log Analytics Docker Kubernetes GitHub page, there are files that you
can use with your secret information. You need to install the Log Analytics agent separately for the master and
agent nodes.
1. To use Log Analytics agent DaemonSet using secret information on the Master node, sign in and create the
secrets first.
a. Copy the script and secret template file and make sure they are on the same directory.
Secret generating script - secret-gen.sh
secret template - secret-template.yaml
b. Run the script, like the following example. The script asks for the Log Analytics Workspace ID and
Primary Key and after you enter them, the script creates a secret yaml file so you can run it.
#> sudo bash ./secret-gen.sh
c. Create your omsagent daemon-set by running kubectl create -f omsagentsecret.yaml
d. To check, run the following:
root@ubuntu16-13db:~# kubectl get secrets

NAME TYPE DATA AGE
default-token-gvl91 kubernetes.io/service-account-token 3 50d
omsagent-secret Opaque 2 1d
root@ubuntu16-13db:~# kubectl describe secrets omsagent-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
WSID: 36 bytes
KEY: 88 bytes
e. Create your omsagent daemon-set by running kubectl create -f ws-omsagent-de-secrets.yaml
2. Verify that the Log Analytics agent DaemonSet is running, similar to the following:
root@ubuntu16-13db:~# kubectl get deployment omsagent

NAME DESIRED CURRENT NODE-SELECTOR AGE
omsagent 1 1 <none> 1h
3. To install the agent on the Worker Node, which are running Windows, follow the steps in the section install
and configure Windows container hosts.
Use Helm to deploy Log Analytics agent on Linux Kubernetes
To use helm to deploy Log Analytics agent on your Linux Kubernetes environment, perform the following steps.
1. Create your omsagent daemon-set by running
helm install --name omsagent --set omsagent.secret.wsid=<WSID>,omsagent.secret.key=<KEY> stable/msoms
2. The results will look similar to the following:
NAME: omsagent
LAST DEPLOYED: Tue Sep 19 20:37:46 2017
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Secret
NAME TYPE DATA AGE
omsagent-msoms Opaque 3 3s
==> v1beta1/DaemonSet
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE
omsagent-msoms 3 3 3 3 3 <none> 3s
3. You can check the status of the omsagent by running: helm status "omsagent" and the output will look
similar to the following:
keiko@k8s-master-3814F33-0:~$ helm status omsagent
LAST DEPLOYED: Tue Sep 19 20:37:46 2017
NAMESPACE: default
STATUS: DEPLOYED
RESOURCES:
==> v1/Secret
NAME TYPE DATA AGE
omsagent-msoms Opaque 3 17m
==> v1beta1/DaemonSet
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE
omsagent-msoms 3 3 3 3 3 <none> 17m
For further information, please visit Container Solution Helm Chart.

Install and configure Windows container hosts
Use the information in section to install and configure Windows container hosts.
Preparation before installing Windows agents
Before you install agents on computers running Windows, you need to configure the Docker service. The
configuration allows the Windows agent or the Azure Monitor virtual machine extension to use the Docker TCP
socket so that the agents can access the Docker daemon remotely and to capture data for monitoring.
To c o n fi g u r e t h e D o c k e r se r v i c e
Perform the following PowerShell commands to enable TCP pipe and named pipe for Windows Server:
Stop-Service docker
dockerd --unregister-service
dockerd --register-service -H npipe:// -H 0.0.0.0:2375
Start-Service docker
For more information about the Docker daemon configuration used with Windows Containers, see Docker Engine
on Windows.
Install Windows agents
To enable Windows and Hyper-V container monitoring, install the Microsoft Monitoring Agent (MMA) on
Windows computers that are container hosts. For computers running Windows in your on-premises environment,
see Connect Windows computers to Azure Monitor. For virtual machines running in Azure, connect them to Azure
Monitor using the virtual machine extension.
You can monitor Windows containers running on Service Fabric. However, only virtual machines running in Azure
and computers running Windows in your on-premises environment are currently supported for Service Fabric.
You can verify that the Container Monitoring solution is set correctly for Windows. To check whether the
management pack was download properly, look for ContainerManagement.xxx. The files should be in the
C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs folder.
Solution components
From the Azure portal, navigate to the Solutions Gallery and add the Container Monitoring Solution. If you are
using Windows agents, then the following management pack is installed on each computer with an agent when
you add this solution. No configuration or maintenance is required for the management pack.
ContainerManagement.xxx installed in C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service
State\Management Packs
Container data collection details
The Container Monitoring solution collects various performance metrics and log data from container hosts and
containers using agents that you enable.
Data is collected every three minutes by the following agent types.
Log Analytics agent for Linux
Windows agent
Log Analytics VM extension
Container records
The following table shows examples of records collected by the Container Monitoring solution and the data types
that appear in log search results.
Performance for hosts and containers Perf Computer, ObjectName, CounterName

(%Processor Time, Disk Reads MB, Disk
Writes MB, Memory Usage MB,
Network Receive Bytes, Network Send
Bytes, Processor Usage sec, Network),
CounterValue,TimeGenerated,
CounterPath, SourceSystem
Container inventory ContainerInventory TimeGenerated, Computer, container

name, ContainerHostname, Image,
ImageTag, ContainerState, ExitCode,
EnvironmentVar, Command,
CreatedTime, StartedTime, FinishedTime,
SourceSystem, ContainerID, ImageID
Container image inventory ContainerImageInventory TimeGenerated, Computer, Image,

ImageTag, ImageSize, VirtualSize,
Running, Paused, Stopped, Failed,
SourceSystem, ImageID, TotalContainer
Container log ContainerLog TimeGenerated, Computer, image ID,

container name, LogEntrySource,
LogEntry, SourceSystem, ContainerID
Container service log ContainerServiceLog TimeGenerated, Computer,

TimeOfCommand, Image, Command,
SourceSystem, ContainerID
Container node inventory ContainerNodeInventory_CL TimeGenerated, Computer,

ClassName_s, DockerVersion_s,
OperatingSystem_s, Volume_s,
Network_s, NodeRole_s,
OrchestratorType_s, InstanceID_g,
SourceSystem
Kubernetes inventory KubePodInventory_CL TimeGenerated, Computer,

PodLabel_deployment_s,
PodLabel_deploymentconfig_s,
PodLabel_docker_registry_s, Name_s,
Namespace_s, PodStatus_s, PodIp_s,
PodUid_g, PodCreationTimeStamp_t,
SourceSystem
Container process ContainerProcess_CL TimeGenerated, Computer, Pod_s,

Namespace_s, ClassName_s,
InstanceID_s, Uid_s, PID_s, PPID_s, C_s,
STIME_s, Tty_s, TIME_s, Cmd_s, Id_s,
Name_s, SourceSystem
Kubernetes events KubeEvents_CL TimeGenerated, Computer, Name_s,

ObjectKind_s, Namespace_s, Reason_s,
Type_s, SourceComponent_s,
SourceSystem, Message
Labels appended to PodLabel data types are your own custom labels. The appended PodLabel labels shown in the
table are examples. So, PodLabel_deployment_s , PodLabel_deploymentconfig_s , PodLabel_docker_registry_s will
differ in your environment's data set and generically resemble PodLabel_yourlabel_s .
Monitor containers
After you have the solution enabled in the Azure portal, the Containers tile shows summary information about
your container hosts and the containers running in hosts.
The tile shows an overview of how many containers you have in the environment and whether they're failed,
running, or stopped.
Using the Containers dashboard
Click the Containers tile. From there you'll see views organized by:
Container Events - Shows container status and computers with failed containers.
Container Logs - Shows a chart of container log files generated over time and a list of computers with the
highest number of log files.
Kubernetes Events - Shows a chart of Kubernetes events generated over time and a list of the reasons why
pods generated the events. This data set is used only in Linux environments.
Kubernetes Namespace Inventory - Shows the number of namespaces and pods and shows their hierarchy.
This data set is used only in Linux environments.
Container Node Inventory - Shows the number of orchestration types used on container nodes/hosts. The
computer nodes/hosts are also listed by the number of containers. This data set is used only in Linux
environments.
Container Images Inventory - Shows the total number of container images used and number of image types.
The number of images are also listed by the image tag.
Containers Status - Shows the total number of container nodes/host computers that have running containers.
Computers are also listed by the number of running hosts.
Container Process - Shows a line chart of container processes running over time. Containers are also listed by
running command/process within containers. This data set is used only in Linux environments.
Container CPU Performance - Shows a line chart of the average CPU utilization over time for computer
nodes/hosts. Also lists the computer nodes/hosts based on average CPU utilization.
Container Memory Performance - Shows a line chart of memory usage over time. Also lists computer
memory utilization based on instance name.
Computer Performance - Shows line charts of the percent of CPU performance over time, percent of
memory usage over time, and megabytes of free disk space over time. You can hover over any line in a chart to
view more details.
Each area of the dashboard is a visual representation of a search that is run on collected data.
In the Container Status area, click the top area, as shown below.
Log Analytics opens, displaying information about the state of your containers.
From here, you can edit the search query to modify it to find the specific information you're interested in. For more
information about log queries, see Log queries in Azure Monitor.
Troubleshoot by finding a failed container

Log Analytics marks a container as Failed if it has exited with a non-zero exit code. You can see an overview of the
errors and failures in the environment in the Failed Containers area.
To find failed containers
1. Click the Container Status area.
2. Log Analytics opens and displays the state of your containers, similar to the following.
3. Expand the Failed line and click + to add its criteria to the query. Then comment out the Summarize line in the
query.
4. Run the query and then expand a line in the results to view the image ID.
5. Type the following in the log query. ContainerImageInventory | where ImageID == <ImageID> to see details about
the image such as image size and number of stopped and failed images.
Query logs for container data
When you're troubleshooting a specific error, it can help to see where it is occurring in your environment. The
following log types will help you create queries to return the information you want.
ContainerImageInventory – Use this type when you're trying to find information organized by image and to
view image information such as image IDs or sizes.
ContainerInventory – Use this type when you want information about container location, what their names
are, and what images they're running.
ContainerLog – Use this type when you want to find specific error log information and entries.
ContainerNodeInventory_CL Use this type when you want the information about host/node where
containers are residing. It provides you Docker version, orchestration type, storage, and network information.
ContainerProcess_CL Use this type to quickly see the process running within the container.
ContainerServiceLog – Use this type when you're trying to find audit trail information for the Docker
daemon, such as start, stop, delete, or pull commands.
KubeEvents_CL Use this type to see the Kubernetes events.
KubePodInventory_CL Use this type when you want to understand the cluster hierarchy information.
To query logs for container data
Choose an image that you know has failed recently and find the error logs for it. Start by finding a container
name that is running that image with a ContainerInventory search. For example, search for
ContainerInventory | where Image == "ubuntu" and ContainerState == "Failed"
Expand any row in the results to view details for that container.
Example log queries

It's often useful to build queries starting with an example or two and then modifying them to fit your environment.
As a starting point, you can experiment with the Sample Queries area to help you build more advanced queries.
Saving log queries
Saving queries is a standard feature in Azure Monitor. By saving them, you'll have those that you've found useful
handy for future use.
After you create a query that you find useful, save it by clicking Favorites at the top of the Log Search page. Then
you can easily access it later from the My Dashboard page.
Next steps
Query logs to view detailed container data records.
Overview of the Azure monitoring agents
Microsoft Azure provides multiple ways to collect different types of data from virtual machines running Microsoft
Windows and Linux hosted in Azure, your datacenter, or other cloud providers. The three types of agents available
to monitor a VM are:
Azure Diagnostics extensions
Log Analytics Agent for Linux and Windows
Dependency agent
This article describes the differences between them and their capabilities in order for you to determine which one
will support your IT service management or general monitoring requirements.
Azure Diagnostic extension

The Azure Diagnostics extension (commonly referred to as the Windows Azure Diagnostic (WAD ) or Linux Azure
Diagnostic (LAD ) extension), which has been provided for Azure Cloud Services since it became generally available
in 2010, is an agent that delivers simple collection of diagnostic data from an Azure compute resource like a VM,
and persist it to Azure storage. Once in storage, you choose to view with one of several available tools, such as
Server Explorer in Visual Studio and Azure Storage Explorer.
You can choose to collect:
A predefined set of operating system performance counters and event logs, or you can specify which to collect.
All requests and/or failed requests to an IIS web server
.NET app tracing output logs
Event tracing for Windows (ETW ) events
Collect log events from syslog
Crash dumps
The Azure Diagnostics agent should be used when you want to:
Archive logs and metrics to Azure storage
Integrate monitoring data with third-party tools. These tools use a variety of methods including querying the
storage account, forwarded to Event Hubs, or querying with the Azure Monitoring REST API
Upload data to Azure Monitor to create metric charts in the Azure portal or create near real-time metric alerts.
Autoscale virtual machine scale sets and Classic Cloud Services based on guest OS metrics.
Investigate VM boot issues with Boot Diagnostics.
Understand how your applications are performing and proactively identifies issues affecting them with
Configure Azure Monitor to import metrics and log data collected from Cloud Services, classic VMs, and
Service Fabric nodes stored in an Azure storage account.
Log Analytics agent

For advanced monitoring where you need to do more than collect metrics and a subset of logs, the Log Analytics
agent for Windows (also referred to as the Microsoft Monitoring Agent (MMA)) and Linux is required. The Log
Analytics agent was developed for comprehensive management across on-premises physical and virtual machines,
computers monitored by System Center Operations Manager, and VMs in hosted in other clouds. The Windows
and Linux agents connect to a Log Analytics workspace in Azure Monitor to collect both monitoring solution-
based data as well as custom data sources that you configure.
NOTE
agent for Linux.
The Log Analytics agent should be used when you want to:
Collect data from a variety of sources both within Azure, other cloud providers, and on-premises resources.
Use one of the Azure Monitor monitoring solutions such as Azure Monitor for VMs, Azure Monitor for
containers, etc.
Use one of the other Azure management services such as Azure Security Center, Azure Automation, etc.
Previously, several Azure services were bundled as the Operations Management Suite, and as a result the Log
Analytics agent is shared across services including Azure Security Center and Azure Automation. This includes the
full set of features they offer, delivering comprehensive management of your Azure VMs through their lifecycle.
Some examples of this are:
Azure Automation Update management of operating system updates.
Azure Automation Desired State Configuration to maintain consistent configuration state.
Track configuration changes with Azure Automation Change Tracking and Inventory.
Azure services such as Application Insights and Azure Security Center, which natively store their data directly in
Log Analytics.
Dependency agent
The Dependency agent was developed as part of the Service Map solution, which was not originally developed by
Microsoft. Service Map and Azure Monitor for VMs requires a Dependency Agent on Windows and Linux virtual
machines and it integrates with the Log Analytics agent to collect discovered data about processes running on the
virtual machine and external process dependencies. It stores this data in a Log Analytics workspace and visualizes
the discovered interconnected components.
You may need some combination of these agents to monitor your VM. The agents can be installed side by side as
Azure extensions, however on Linux, the Log Analytics agent must be installed first or else installation will fail.
Next steps
See Overview of the Log Analytics agent to review requirements and supported methods to deploy the agent
to machines hosted in Azure, in your datacenter, or other cloud environment.
What is Azure Diagnostics extension
The Azure Diagnostics extension is an agent within Azure that enables the collection of diagnostic data on a
deployed application. You can use the diagnostics extension from a number of different sources. Currently
supported are Azure Cloud Service (classic) Web and Worker Roles, Virtual Machines, Virtual Machine scale sets,
and Service Fabric. Other Azure services have different diagnostics methods. See Overview of monitoring in
Azure.
Linux Agent
A Linux version of the extension is available for Virtual Machines running Linux. The statistics collected and
behavior vary from the Windows version.
Data you can collect

The Azure Diagnostics extension can collect the following types of data:
DATA SOURCE DESCRIPTION
Performance counter metrics Operating System and custom performance counters
Application logs Trace messages written by your application
Windows Event logs Information sent to the Windows event logging system
.NET EventSource logs Code writing events using the .NET EventSource class
IIS Logs Information about IIS web sites
Manifest based ETW logs Event Tracing for Windows events generated by any process.
(1)
Crash dumps (logs) Information about the state of the process if an application
crashes
Custom error logs Logs created by your application or service
Azure Diagnostic infrastructure logs Information about Azure Diagnostics itself
(1) To get a list of ETW providers, run c:\Windows\System32\logman.exe query providers in a console window on
the machine you'd like to gather information from.
Data storage
The extension stores its data in an Azure Storage account that you specify.
You can also send it to Application Insights.
Another option is to stream it to Event Hub, which then allows you to send it to non-Azure monitoring services.
You also have the choice of sending your data to Azure Monitor metrics time-series database. At this time, this
sink is only applicable to Performance Counters. It enables you to send performance counters in as custom
metrics. This feature is in Preview. The Azure Monitor sink supports:
Retrieving all performance counters sent to Azure Monitor via the Azure Monitor metrics APIs.
Alerting on all performance counters sent to Azure Monitor via the metric alerts in Azure Monitor
Treating wildcard operator in performance counters as the "Instance" dimension on your metric. For example
if you collected the "LogicalDisk(*)/DiskWrites/sec" counter you would be able to filter and split on the
"Instance" dimension to plot or alert on the Disk Writes/sec for each Logical Disk on the VM (for example, C:)
To learn more on how to configure this sink, refer to the Azure diagnostics schema documentation.
Costs
Each of the options above may incur costs. Be sure to research them to avoid unexpected bills. Application
Insights, Event hub, and Azure Storage have separate costs associated with ingestion and the time stored. In
particular, Azure Storage will hold any data forever so you may want to purge older data after a certain time
period to keep your costs down.
Versioning and configuration schema

See Azure Diagnostics Version History and Schema.
Next steps
Choose which service you're trying to collect diagnostics on and use the following articles to get started. Use the
general Azure diagnostics links for reference for specific tasks.
Cloud Services using Azure Diagnostics

If using Visual Studio, see Use Visual Studio to trace a Cloud Services application to get started. Otherwise,
see
How to monitor Cloud services using Azure Diagnostics
Set up Azure Diagnostics in a Cloud Services Application
For more advanced topics, see
Using Azure Diagnostics with Application Insights for Cloud Services
Trace the flow of a Cloud Services application with Azure Diagnostics
Use PowerShell to set up diagnostics on Cloud Services
Virtual Machines
If using Visual Studio, see Use Visual Studio to trace Azure Virtual Machines to get started. Otherwise, see
Set up Azure Diagnostics on an Azure Virtual Machine
For more advanced topics, see
Use PowerShell to set up diagnostics on Azure Virtual Machines
Create a Windows Virtual machine with monitoring and diagnostics using Azure Resource Manager Template
Service Fabric
Get started at Monitor a Service Fabric application. Many other Service Fabric diagnostics articles are available in
the navigation tree on the left once you get to this article.
General articles
Learn to use Performance Counters in Azure Diagnostics.
If you have trouble with diagnostics starting or finding your data in Azure storage tables, see TroubleShooting
Azure Diagnostics
Collect Azure diagnostic logs from Azure Storage
Azure Monitor can read the logs for the following services that write diagnostics to table storage or IIS logs
written to blob storage:
Service Fabric clusters (Preview )
Virtual Machines
Web/Worker Roles
Before Azure Monitor can collect data into a Log Analytics workspace for these resources, Azure diagnostics must
be enabled.
Once diagnostics are enabled, you can use the Azure portal or PowerShell configure the workspace to collect the
logs.
Azure Diagnostics is an Azure extension that enables you to collect diagnostic data from a worker role, web role, or
virtual machine running in Azure. The data is stored in an Azure storage account and can then be collected by
Azure Monitor.
For Azure Monitor to collect these Azure Diagnostics logs, the logs must be in the following locations:
LOG TYPE RESOURCE TYPE LOCATION
IIS logs Virtual Machines wad-iis-logfiles (Blob Storage)

Web roles
Worker roles
Syslog Virtual Machines LinuxsyslogVer2v0 (Table Storage)
Service Fabric Operational Events Service Fabric nodes WADServiceFabricSystemEventTable
Service Fabric Reliable Actor Events Service Fabric nodes WADServiceFabricReliableActorEventTab

le
Service Fabric Reliable Service Events Service Fabric nodes WADServiceFabricReliableServiceEventTa

ble
Windows Event logs Service Fabric nodes WADWindowsEventLogsTable (Table

Virtual Machines Storage)
Web roles
Worker roles
Windows ETW logs Service Fabric nodes WADETWEventTable (Table Storage)

Virtual Machines
Web roles
Worker roles
NOTE
IIS logs from Azure Websites are not currently supported.
For virtual machines, you have the option of installing the Log Analytics agent into your virtual machine to enable
additional insights. In addition to being able to analyze IIS logs and Event Logs, you can perform additional
analysis including configuration change tracking, SQL assessment, and update assessment.
Enable Azure diagnostics in a virtual machine for event log and IIS log
collection
Use the following procedure to enable Azure diagnostics in a virtual machine for Event Log and IIS log collection
using the Microsoft Azure portal.
To enable Azure diagnostics in a virtual machine with the Azure portal
1. Install the VM Agent when you create a virtual machine. If the virtual machine already exists, verify that the
VM Agent is already installed.
In the Azure portal, navigate to the virtual machine, select Optional Configuration, then
Diagnostics and set Status to On.
Upon completion, the VM has the Azure Diagnostics extension installed and running. This extension
is responsible for collecting your diagnostics data.
2. Enable monitoring and configure event logging on an existing VM. You can enable diagnostics at the VM
level. To enable diagnostics and then configure event logging, perform the following steps:
a. Select the VM.
b. Click Monitoring.
c. Click Diagnostics.
d. Set the Status to ON.
e. Select each diagnostics log that you want to collect.
f. Click OK.
Enable Azure diagnostics in a Web role for IIS log and event collection
Refer to How To Enable Diagnostics in a Cloud Service for general steps on enabling Azure diagnostics. The
instructions below use this information and customize it for use with Log Analytics.
With Azure diagnostics enabled:
IIS logs are stored by default, with log data transferred at the scheduledTransferPeriod transfer interval.
Windows Event Logs are not transferred by default.
To enable diagnostics
To enable Windows Event Logs, or to change the scheduledTransferPeriod, configure Azure Diagnostics using the
XML configuration file (diagnostics.wadcfg), as shown in Step 4: Create your Diagnostics configuration file and
install the extension
The following example configuration file collects IIS Logs and all Events from the Application and System logs:
<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration
xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
configurationChangePollInterval="PT1M"
overallQuotaInMB="4096">
<Directories bufferQuotaInMB="0"
scheduledTransferPeriod="PT10M">

<IISLogs container="wad-iis" directoryQuotaInMB="0" />
</Directories>
<WindowsEventLog bufferQuotaInMB="0"
scheduledTransferLogLevelFilter="Verbose"
<DataSource name="Application!*" />
<DataSource name="System!*" />
</WindowsEventLog>
</DiagnosticMonitorConfiguration>
Ensure that your ConfigurationSettings specifies a storage account, as in the following example:
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=<AccountName>;AccountKey=<AccountKey>"/>
</ConfigurationSettings>
The AccountName and AccountKey values are found in the Azure portal in the storage account dashboard,
under Manage Access Keys. The protocol for the connection string must be https.
Once the updated diagnostic configuration is applied to your cloud service and it is writing diagnostics to Azure
Storage, then you are ready to configure the Log Analytics workspace.
Use the Azure portal to collect logs from Azure Storage

You can use the Azure portal to configure a Log Analytics workspace in Azure Monitor to collect the logs for the
following Azure services:
Service Fabric clusters
Virtual Machines
Web/Worker Roles
In the Azure portal, navigate to your Log Analytics workspace and perform the following tasks:
1. Click Storage accounts logs
2. Click the Add task
3. Select the Storage account that contains the diagnostics logs
This account can be either a classic storage account or an Azure Resource Manager storage account
4. Select the Data Type you want to collect logs for
The choices are IIS Logs; Events; Syslog (Linux); ETW Logs; Service Fabric Events
5. The value for Source is automatically populated based on the data type and cannot be changed
6. Click OK to save the configuration
Repeat steps 2-6 for additional storage accounts and data types that you want to collect into the workspace.
In approximately 30 minutes, you are able to see data from the storage account in the Log Analytics workspace.
You will only see data that is written to storage after the configuration is applied. The workspace does not read the
pre-existing data from the storage account.
NOTE
The portal does not validate that the Source exists in the storage account or if new data is being written.
Enable Azure diagnostics in a virtual machine for event log and IIS log
collection using PowerShell
NOTE
PowerShell.
Use the steps in Configuring Azure Monitor to index Azure diagnostics to use PowerShell to read from Azure
diagnostics that are written to table storage.
Using Azure PowerShell you can more precisely specify the events that are written to Azure Storage. For more
information, see Enabling Diagnostics in Azure Virtual Machines.
You can enable and update Azure diagnostics using the following PowerShell script. You can also use this script
with a custom logging configuration. Modify the script to set the storage account, service name, and virtual
machine name. The script uses cmdlets for classic virtual machines.
Review the following script sample, copy it, modify it as needed, save the sample as a PowerShell script file, and
then run the script.
#Connect to Azure
Add-AzureAccount
# settings to change:
$wad_storage_account_name = "myStorageAccount"
$service_name = "myService"
$vm_name = "myVM"
#Construct Azure Diagnostics public config and convert to config format
# Collect just system error events:

$wad_xml_config = "<WadCfg><DiagnosticMonitorConfiguration><WindowsEventLog
scheduledTransferPeriod=""PT1M""><DataSource name=""System!* "" /></WindowsEventLog>
</DiagnosticMonitorConfiguration></WadCfg>"
$wad_b64_config = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($wad_xml_config))
$wad_public_config = [string]::Format("{{""xmlCfg"":""{0}""}}",$wad_b64_config)
#Construct Azure diagnostics private config
$wad_storage_account_key = (Get-AzStorageKey $wad_storage_account_name).Primary

$wad_private_config = [string]::Format("{{""storageAccountName"":""{0}"",""storageAccountKey"":""
{1}""}}",$wad_storage_account_name,$wad_storage_account_key)
#Enable Diagnostics Extension for Virtual Machine
$wad_extension_name = "IaaSDiagnostics"
$wad_publisher = "Microsoft.Azure.Diagnostics"
$wad_version = (Get-AzureVMAvailableExtension -Publisher $wad_publisher -ExtensionName
$wad_extension_name).Version # Gets latest version of the extension
(Get-AzureVM -ServiceName $service_name -Name $vm_name) | Set-AzureVMExtension -ExtensionName

$wad_extension_name -Publisher $wad_publisher -PublicConfiguration $wad_public_config -PrivateConfiguration
$wad_private_config -Version $wad_version | Update-AzureVM
Next steps
Collect logs and metrics for Azure services for supported Azure services.
Enable Solutions to provide insight into the data.
Use search queries to analyze the data.
Azure Diagnostics extension configuration schema
versions and history
This page indexes Azure Diagnostics extension schema versions shipped as part of the Microsoft Azure SDK.
NOTE
The Azure Diagnostics extension is the component used to collect performance counters and other statistics from:
Virtual Machine Scale Sets
Service Fabric
Cloud Services
Network Security Groups
This page is only relevant if you are using one of these services.
The Azure Diagnostics extension is used with other Microsoft diagnostics products like Azure Monitor, which
includes Application Insights and Log Analytics. For more information, see Microsoft Monitoring Tools Overview.
Azure SDK and diagnostics versions shipping chart

AZURE SDK VERSION DIAGNOSTICS EX TENSION VERSION MODEL
1.x 1.0 plug-in
2.0 - 2.4 1.0 plug-in
2.5 1.2 extension
2.6 1.3 "
2.7 1.4 "
2.8 1.5 "
2.9 1.6 "
2.96 1.7 "
2.96 1.8 "
2.96 1.8.1 "
2.96 1.9 "
2.96 1.11 "

Azure Diagnostics version 1.0 first shipped in a plug-in model -- meaning that when you installed the Azure SDK,
you got the version of Azure diagnostics shipped with it.
Starting with SDK 2.5 (diagnostics version 1.2), Azure diagnostics went to an extension model. The tools to utilize
new features were only available in newer Azure SDKs, but any service using Azure diagnostics would pick up the
latest shipping version directly from Azure. For example, anyone still using SDK 2.5 would be loading the latest
version shown in the previous table, regardless if they are using the newer features.
Schemas index
Different versions of Azure diagnostics use different configuration schemas. Schema 1.0 and 1.2 have been
deprecated. For more information on version 1.3 and later, see Diagnostics 1.3 and later Configuration Schema
Version history
Diagnostics extension 1.11
Added support for the Azure Monitor sink. This sink is only applicable to performance counters. Enables sending
performance counters collected on your VM, VMSS, or cloud service to Azure Monitor as custom metrics. The
Azure Monitor sink supports:
Retrieving all performance counters sent to Azure Monitor via the Azure Monitor metrics APIs.
Alerting on all performance counters sent to Azure Monitor via the new unified alerts experience in Azure
Monitor
Treating wildcard operator in performance counters as the "Instance" dimension on your metric. For example if
you collected the "LogicalDisk(*)/DiskWrites/sec" counter you would be able to filter and split on the "Instance"
dimension to plot or alert on the Disk Writes/sec for each Logical Disk (C:, D:, etc.)
Define Azure Monitor as a new sink in your diagnostics extension configuration
"SinksConfig": {
"Sink": [
{
"name": "AzureMonitorSink",
"AzureMonitor": {}
},
]
}
<SinksConfig>
<Sink name="AzureMonitorSink">
<AzureMonitor/>
</Sink>
</SinksConfig>
NOTE
Configuring the Azure Monitor sink for Classic VMs and Classic CLoud Service requires more parameters to be defined in the
Diagnostics extension's private config.
For more details please reference the detailed diagnostics extension schema documentation.
Next, you can configure your performance counters to be routed to the Azure Monitor Sink.
"PerformanceCounters": {
"scheduledTransferPeriod": "PT1M",
"sinks": "AzureMonitorSink",
"PerformanceCounterConfiguration": [
{
"counterSpecifier": "\\Processor(_Total)\\% Processor Time",
"sampleRate": "PT1M",
"unit": "percent"
}
]
},
<PerformanceCounters scheduledTransferPeriod="PT1M", sinks="AzureMonitorSink">

<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT1M"
unit="percent" />

Added Docker support.
Diagnostics extension 1.8.1
Can specify a SAS token instead of a storage account key in the private config. If a SAS token is provided, the
storage account key is ignored.
{
"storageAccountName": "diagstorageaccount",
"storageAccountEndPoint": "https://core.windows.net",
"storageAccountSasToken": "{sas token}",
"SecondaryStorageAccounts": {
"StorageAccount": [
{
"name": "secondarydiagstorageaccount",
"endpoint": "https://core.windows.net",
"sasToken": "{sas token}"
}
]
}
}
<PrivateConfig>
<StorageAccount name="diagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
<SecondaryStorageAccounts>
<StorageAccount name="secondarydiagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas
token}" />
</SecondaryStorageAccounts>
</PrivateConfig>

Added Storage Type to PublicConfig. StorageType can be Table, Blob, TableAndBlob. Table is the default.
{
"WadCfg": {
},
"StorageAccount": "diagstorageaccount",
"StorageType": "TableAndBlob"
}
<PublicConfig>
<WadCfg />
<StorageAccount>diagstorageaccount</StorageAccount>
<StorageType>TableAndBlob</StorageType>
</PublicConfig>

Added the ability to route to EventHub.
Added the sinks element and the ability to send diagnostics data to Application Insights making it easier to
diagnose issues across your application as well as the system and infrastructure level.
Azure SDK 2.6 and diagnostics extension 1.3
For Cloud Service projects in Visual Studio, the following changes were made. (These changes also apply to later
versions of Azure SDK.)
The local emulator now supports diagnostics. This change means you can collect diagnostics data and ensure
your application is creating the right traces while you're developing and testing in Visual Studio. The connection
string UseDevelopmentStorage=true enables diagnostics data collection while you're running your cloud service
project in Visual Studio by using the Azure storage emulator. All diagnostics data is collected in the
(Development Storage) storage account.
The diagnostics storage account connection string
(Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString) is stored once again in the service
configuration (.cscfg) file. In Azure SDK 2.5 the diagnostics storage account was specified in the
diagnostics.wadcfgx file.
There are some notable differences between how the connection string worked in Azure SDK 2.4 and earlier and
how it works in Azure SDK 2.6 and later.
In Azure SDK 2.4 and earlier, the connection string was used at runtime by the diagnostics plugin to get the
storage account information for transferring diagnostics logs.
In Azure SDK 2.6 and later, Visual Studio uses the diagnostics connection string to configure the diagnostics
extension with the appropriate storage account information during publishing. The connection string lets you
define different storage accounts for different service configurations that Visual Studio will use when
publishing. However, because the diagnostics plugin is no longer available (after Azure SDK 2.5), the .cscfg file
by itself can't enable the Diagnostics Extension. You have to enable the extension separately through tools such
as Visual Studio or PowerShell.
To simplify the process of configuring the diagnostics extension with PowerShell, the package output from
Visual Studio also contains the public configuration XML for the diagnostics extension for each role. Visual
Studio uses the diagnostics connection string to populate the storage account information present in the public
configuration. The public config files are created in the Extensions folder and follow the pattern
PaaSDiagnostics.<RoleName>.PubConfig.xml . Any PowerShell based deployments can use this pattern to map
each configuration to a Role.
The connection string in the .cscfg file is also used by the Azure portal to access the diagnostics data so it can
appear in the Monitoring tab. The connection string is needed to configure the service to show verbose
monitoring data in the portal.
Migrating projects to Azure SDK 2.6 and later
When migrating from Azure SDK 2.5 to Azure SDK 2.6 or later, if you had a diagnostics storage account specified
in the .wadcfgx file, then it will stay there. To take advantage of the flexibility of using different storage accounts for
different storage configurations, you'll have to manually add the connection string to your project. If you're
migrating a project from Azure SDK 2.4 or earlier to Azure SDK 2.6, then the diagnostics connection strings are
preserved. However, note the changes in how connection strings are treated in Azure SDK 2.6 as specified in the
previous section.
How Visual Studio determines the diagnostics storage account
If a diagnostics connection string is specified in the .cscfg file, Visual Studio uses it to configure the diagnostics
extension when publishing, and when generating the public configuration xml files during packaging.
If no diagnostics connection string is specified in the .cscfg file, then Visual Studio falls back to using the storage
account specified in the .wadcfgx file to configure the diagnostics extension when publishing, and generating the
public configuration xml files when packaging.
The diagnostics connection string in the .cscfg file takes precedence over the storage account in the .wadcfgx file.
If a diagnostics connection string is specified in the .cscfg file, then Visual Studio uses that and ignores the
storage account in .wadcfgx.
What does the "Update development storage connection strings…" checkbox do?
The checkbox for Update development storage connection strings for Diagnostics and Caching with
Microsoft Azure storage account credentials when publishing to Microsoft Azure gives you a convenient
way to update any development storage account connection strings with the Azure storage account specified
during publishing.
For example, suppose you select this checkbox and the diagnostics connection string specifies
UseDevelopmentStorage=true . When you publish the project to Azure, Visual Studio will automatically update the
diagnostics connection string with the storage account you specified in the Publish wizard. However, if a real
storage account was specified as the diagnostics connection string, then that account is used instead.
Diagnostics functionality differences between Azure SDK 2.4 and earlier and Azure SDK 2.5 and later
If you're upgrading your project from Azure SDK 2.4 to Azure SDK 2.5 or later, you should bear in mind the
following diagnostics functionality differences.
Configuration APIs are deprecated – Programmatic configuration of diagnostics is available in Azure SDK
2.4 or earlier versions, but is deprecated in Azure SDK 2.5 and later. If your diagnostics configuration is currently
defined in code, you'll need to reconfigure those settings from scratch in the migrated project in order for
diagnostics to keep working. The diagnostics configuration file for Azure SDK 2.4 is diagnostics.wadcfg, and
diagnostics.wadcfgx for Azure SDK 2.5 and later.
Diagnostics for cloud service applications can only be configured at the role level, not at the instance
level.
Every time you deploy your app, the diagnostics configuration is updated – This can cause parity issues
if you change your diagnostics configuration from Server Explorer and then redeploy your app.
In Azure SDK 2.5 and later, crash dumps are configured in the diagnostics configuration file, not in
code – If you have crash dumps configured in code, you'll have to manually transfer the configuration from
code to the configuration file, because the crash dumps aren't transferred during the migration to Azure SDK
2.6.
Azure Diagnostics 1.3 and later configuration schema
NOTE
The Azure Diagnostics extension is the component used to collect performance counters and other statistics from:
Virtual Machine Scale Sets
Service Fabric
Cloud Services
Network Security Groups
This page is only relevant if you are using one of these services.
This page is valid for versions 1.3 and newer (Azure SDK 2.4 and newer). Newer configuration sections are commented to
show in what version they were added. Version 1.0 and 1.2 of the schema have been archived and no longer available.
The configuration file described here is used to set diagnostic configuration settings when the diagnostics monitor starts.
The extension is used in conjunction with other Microsoft diagnostics products like Azure Monitor, which includes Application
Insights and Log Analytics.
Download the public configuration file schema definition by executing the following PowerShell command:
(Get-AzureServiceAvailableExtension -ExtensionName 'PaaSDiagnostics' -ProviderNamespace

'Microsoft.Azure.Diagnostics').PublicConfigurationSchema | Out-File –Encoding utf8 -FilePath 'C:\temp\WadConfig.xsd'
For more information about using Azure Diagnostics, see Azure Diagnostics Extension.
Example of the diagnostics configuration file

The following example shows a typical diagnostics configuration file:

<DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<PublicConfig>
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="10000">
<PerformanceCounters scheduledTransferPeriod="PT1M", sinks="AzureMonitorSink">

unit="percent" />
<Directories scheduledTransferPeriod="PT5M">
<IISLogs containerName="iislogs" />
<FailedRequestLogs containerName="iisfailed" />
<DataSources>
<DirectoryConfiguration containerName="mynewprocess">
<Absolute path="C:\MyNewProcess" expandEnvironment="false" />
</DirectoryConfiguration>
<DirectoryConfiguration containerName="badapp">
<Absolute path="%SYSTEMDRIVE%\BadApp" expandEnvironment="true" />
<DirectoryConfiguration containerName="goodapp">
<LocalResource name="Skippy" relativePath="..\PeanutButter"/>
</DataSources>
</Directories>
<EtwProviders>
<EtwEventSourceProviderConfiguration
provider="MyProviderClass"
<Event id="0"/>
<Event id="1" eventDestination="errorTable"/>
<DefaultEvents />
</EtwEventSourceProviderConfiguration>
<EtwManifestProviderConfiguration provider="5974b00b-84c2-44bc-9e58-3a2451b4e3ad"
scheduledTransferLogLevelFilter="Information" scheduledTransferPeriod="PT2M">
<Event id="0"/>
<DefaultEvents eventDestination="defaultTable"/>
</EtwManifestProviderConfiguration>
</EtwProviders>
<WindowsEventLog scheduledTransferPeriod="PT5M">
<DataSource name="System!*[System[Provider[@Name='Microsoft Antimalware']]]"/>
<DataSource name="System!*[System[Provider[@Name='NTFS'] and (EventID=55)]]" />
<DataSource name="System!*[System[Provider[@Name='disk'] and (EventID=7 or EventID=52 or EventID=55)]]" />
</WindowsEventLog>
<Logs bufferQuotaInMB="1024"
scheduledTransferPeriod="PT1M"
scheduledTransferLogLevelFilter="Verbose"
sinks="ApplicationInsights.AppLogs"/> 
<CrashDumps containerName="wad-crashdumps" directoryQuotaPercentage="30" dumpType="Mini">

<CrashDumpConfiguration processName="mynewprocess.exe" />
<CrashDumpConfiguration processName="badapp.exe"/>
</CrashDumps>
<DockerSources> 

<Stats enabled="true" sampleRate="PT1M" scheduledTransferPeriod="PT1M" />
</DockerSources>
<SinksConfig> 

<Sink name="AzureMonitorSink">
<AzureMonitor> 
<resourceId>{insert resourceId}</ResourceId> 
<Region>{insert Azure region of resource}</Region> 
</AzureMonitor>
</Sink>
<Sink name="ApplicationInsights">
<ApplicationInsights>{Insert InstrumentationKey}</ApplicationInsights>
<Channels>
<Channel logLevel="Error" name="Errors" />
<Channel logLevel="Verbose" name="AppLogs" />
</Channels>
</Sink>
<Sink name="EventHub"> 
<EventHub Url="https://myeventhub-ns.servicebus.windows.net/diageventhub" SharedAccessKeyName="SendRule"
usePublisherId="false" />
</Sink>
<Sink name="secondaryEventHub"> 
<EventHub Url="https://myeventhub-ns.servicebus.windows.net/secondarydiageventhub"
SharedAccessKeyName="SendRule" usePublisherId="false" />
</Sink>
<Sink name="secondaryStorageAccount"> 
<StorageAccount name="secondarydiagstorageaccount" endpoint="https://core.windows.net" />
</Sink>
</SinksConfig>
</WadCfg>
<StorageAccount>diagstorageaccount</StorageAccount>
<StorageType>TableAndBlob</StorageType> 
</PublicConfig>
<PrivateConfig> 

<StorageAccount name="" key="" endpoint="" sasToken="{sas token}" /> 
SharedAccessKey="{base64 encoded key}" />
<AzureMonitorAccount>
<ServicePrincipalMeta> 
<PrincipalId>{Insert service principal clientId}</PrincipalId>
<Secret>{Insert service principal client secret}</Secret>
</ServicePrincipalMeta>
</AzureMonitorAccount>
<SecondaryStorageAccounts>
<StorageAccount name="secondarydiagstorageaccount" key="{base64 encoded key}" endpoint="https://core.windows.net"
sasToken="{sas token}" />
</SecondaryStorageAccounts>
<SecondaryEventHubs>
<EventHub Url="https://myeventhub-ns.servicebus.windows.net/secondarydiageventhub" SharedAccessKeyName="SendRule"
SharedAccessKey="{base64 encoded key}" />
</SecondaryEventHubs>
</PrivateConfig>
</DiagnosticsConfiguration>
NOTE
The public config Azure Monitor sink definition has two properties, resourceId and region. These are only required for Classic VMs and
Classic Cloud services. These properties should not be used for Resource Manager Virtual Machines or Virtual Machine Scale sets. There is
also an additional Private Config element for the Azure Monitor sink, that passes in a Principal Id and Secret. This is only required for
Classic VMs and Classic Cloud Services. For Resource Manager VMs and VMSS the Azure Monitor definition in the private config element
can be excluded.
JSON equivalent of the previous XML configuration file.

The PublicConfig and PrivateConfig are separated because in most json usage cases, they are passed as different variables.
These cases include Resource Manager templates, Virtual Machine Scale set PowerShell, and Visual Studio.
"PublicConfig" {
"WadCfg": {
"DiagnosticMonitorConfiguration": {
"overallQuotaInMB": 10000,
"DiagnosticInfrastructureLogs": {
"scheduledTransferLogLevelFilter": "Error"
},
"sinks": "AzureMonitorSink",
{
"unit": "percent"
}
]
},
"Directories": {
"IISLogs": {
"containerName": "iislogs"
},
"FailedRequestLogs": {
"containerName": "iisfailed"
},
"DataSources": [
{
"containerName": "mynewprocess",
"Absolute": {
"path": "C:\\MyNewProcess",
"expandEnvironment": false
}
},
{
"containerName": "badapp",
"Absolute": {
"path": "%SYSTEMDRIVE%\\BadApp",
"expandEnvironment": true
}
},
{
"containerName": "goodapp",
"LocalResource": {
"relativePath": "..\\PeanutButter",
"name": "Skippy"
}
}
]
},
"EtwProviders": {
"sinks": "",
"EtwEventSourceProviderConfiguration": [
{
"provider": "MyProviderClass",
"Event": [
{
"id": 0
},
{
"id": 1,
"eventDestination": "errorTable"
}
],
"DefaultEvents": {
}
}
],
"EtwManifestProviderConfiguration": [
{
"scheduledTransferLogLevelFilter": "Information",
"provider": "5974b00b-84c2-44bc-9e58-3a2451b4e3ad",
"Event": [
{
"id": 0
}
],
"DefaultEvents": {
}
}
]
},
"WindowsEventLog": {
"DataSource": [
{
"name": "System!*[System[Provider[@Name='Microsoft Antimalware']]]"
},
{
"name": "System!*[System[Provider[@Name='NTFS'] and (EventID=55)]]"
},
{
"name": "System!*[System[Provider[@Name='disk'] and (EventID=7 or EventID=52 or EventID=55)]]"
}
]
},
"Logs": {
"scheduledTransferLogLevelFilter": "Verbose",
"sinks": "ApplicationInsights.AppLogs"
},
"CrashDumps": {
"directoryQuotaPercentage": 30,
"dumpType": "Mini",
"containerName": "wad-crashdumps",
"CrashDumpConfiguration": [
{
"processName": "mynewprocess.exe"
},
{
"processName": "badapp.exe"
}
]
}
},
"SinksConfig": {
"Sink": [
{
"name": "AzureMonitorSink",
"AzureMonitor":
{
"ResourceId": "{insert resourceId if a classic VM or cloud service, else property not needed}",
"Region": "{insert Azure region of resource if a classic VM or cloud service, else property not
needed}"
}
},
{
"name": "ApplicationInsights",
"ApplicationInsights": "{Insert InstrumentationKey}",
"Channels": {
"Channel": [
{
"logLevel": "Error",
"name": "Errors"
},
{
"logLevel": "Verbose",
"name": "AppLogs"
}
]
}
},
{
"name": "EventHub",
"EventHub": {
"Url": "https://myeventhub-ns.servicebus.windows.net/diageventhub",
"SharedAccessKeyName": "SendRule",
"usePublisherId": false
}
},
{
"name": "secondaryEventHub",
"EventHub": {
"Url": "https://myeventhub-ns.servicebus.windows.net/secondarydiageventhub",
"usePublisherId": false
}
},
{
"name": "secondaryStorageAccount",
"StorageAccount": {
"endpoint": "https://core.windows.net"
}
}
]
}
},
"StorageAccount": "diagstorageaccount",
"StorageType": "TableAndBlob"
}
NOTE
The public config Azure Monitor sink definition has two properties, resourceId and region. These are only required for Classic VMs and
Classic Cloud services. These properties should not be used for Resource Manager Virtual Machines or Virtual Machine Scale sets.
"PrivateConfig" {
"storageAccountName": "diagstorageaccount",
"storageAccountKey": "{base64 encoded key}",
"storageAccountEndPoint": "https://core.windows.net",
"storageAccountSasToken": "{sas token}",
"EventHub": {
"Url": "https://myeventhub-ns.servicebus.windows.net/diageventhub",
"SharedAccessKey": "{base64 encoded key}"
},
"AzureMonitorAccount": {
"ServicePrincipalMeta": {
"PrincipalId": "{Insert service principal client Id}",
"Secret": "{Insert service principal client secret}"
}
},
"SecondaryStorageAccounts": {
"StorageAccount": [
{
"key": "{base64 encoded key}",
"endpoint": "https://core.windows.net",
"sasToken": "{sas token}"
}
]
},
"SecondaryEventHubs": {
"EventHub": [
{
"Url": "https://myeventhub-ns.servicebus.windows.net/secondarydiageventhub",
}
]
}
}
NOTE
There is an additional Private Config element for the Azure Monitor sink, that passes in a Principal Id and Secret. This is only required for
Classic VMs and Classic Cloud Services. For Resource Manager VMs and VMSS the Azure Monitor definition in the private config element
can be excluded.
Reading this page

The tags following are roughly in order shown in the preceding example. If you don't see a full description where you expect it,
search the page for the element or attribute.
Common Attribute Types

scheduledTransferPeriod attribute appears in several elements. It is the interval between scheduled transfers to storage
rounded up to the nearest minute. The value is an XML “Duration Data Type.”
DiagnosticsConfiguration Element
Tree: Root - DiagnosticsConfiguration
Added in version 1.3.
The top-level element of the diagnostics configuration file.
Attribute xmlns - The XML namespace for the diagnostics configuration file is:
http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration
CHILD ELEMENTS DESCRIPTION
PublicConfig Required. See description elsewhere on this page.
PrivateConfig Optional. See description elsewhere on this page.
IsEnabled Boolean. See description elsewhere on this page.
PublicConfig Element
Tree: Root - DiagnosticsConfiguration - PublicConfig
Describes the public diagnostics configuration.
WadCfg Required. See description elsewhere on this page.
StorageAccount The name of the Azure Storage account to store the data in. May
also be specified as a parameter when executing the Set-
AzureServiceDiagnosticsExtension cmdlet.
StorageType Can be Table, Blob, or TableAndBlob. Table is default. When

TableAndBlob is chosen, diagnostic data is written twice -- once to
each type.
LocalResourceDirectory The directory on the virtual machine where the Monitoring Agent
stores event data. If not, set, the default directory is used:
For a Worker/web role:

C:\Resources\<guid>\directory\<guid>.
<RoleName.DiagnosticStore\
For a Virtual Machine:

C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics\
<WADVersion>\WAD<WADVersion>
Required attributes are:
- path - The directory on the system to be used by Azure

Diagnostics.
- expandEnvironment - Controls whether environment variables

are expanded in the path name.
WadCFG Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG
Identifies and configures the telemetry data to be collected.
DiagnosticMonitorConfiguration Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration
Required
ATTRIBUTES DESCRIPTION
overallQuotaInMB The maximum amount of local disk space that may be consumed by
the various types of diagnostic data collected by Azure Diagnostics.
The default setting is 4096 MB.
useProxyServer Configure Azure Diagnostics to use the proxy server settings as set
in IE settings.
sinks Added in 1.5. Optional. Points to a sink location to also send

diagnostic data for all child elements that support sinks. Sink
example is Application Insights or Event Hubs.
CrashDumps See description elsewhere on this page.
DiagnosticInfrastructureLogs Enable collection of logs generated by Azure Diagnostics. The

diagnostic infrastructure logs are useful for troubleshooting the
diagnostics system itself. Optional attributes are:
- scheduledTransferLogLevelFilter - Configures the minimum

severity level of the logs collected.
- scheduledTransferPeriod - The interval between scheduled

transfers to storage rounded up to the nearest minute. The value is
an XML “Duration Data Type.”
Directories See description elsewhere on this page.
EtwProviders See description elsewhere on this page.
Metrics See description elsewhere on this page.
PerformanceCounters See description elsewhere on this page.
WindowsEventLog See description elsewhere on this page.
DockerSources See description elsewhere on this page.
CrashDumps Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - CrashDumps
Enable the collection of crash dumps.
containerName Optional. The name of the blob container in your Azure Storage
account to be used to store crash dumps.
crashDumpType Optional. Configures Azure Diagnostics to collect mini or full crash

dumps.
directoryQuotaPercentage Optional. Configures the percentage of overallQuotaInMB to be

reserved for crash dumps on the VM.

CrashDumpConfiguration Required. Defines configuration values for each process.
The following attribute is also required:
processName - The name of the process you want Azure

Diagnostics to collect a crash dump for.
Directories Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - Directories
Enables the collection of the contents of a directory, IIS failed access request logs and/or IIS logs.
Optional scheduledTransferPeriod attribute. See explanation earlier.
IISLogs Including this element in the configuration enables the collection of

IIS logs:
containerName - The name of the blob container in your Azure

Storage account to be used to store the IIS logs.
FailedRequestLogs Including this element in the configuration enables collection of logs

about failed requests to an IIS site or application. You must also
enable tracing options under system.WebServer in Web.config.
DataSources A list of directories to monitor.
DataSources Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - Directories -
DataSources
A list of directories to monitor.
DirectoryConfiguration Required. Required attribute:
containerName - The name of the blob container in your Azure

Storage account that to be used to store the log files.
DirectoryConfiguration Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - Directories -
DataSources - DirectoryConfiguration
May include either the Absolute or LocalResource element but not both.
Absolute The absolute path to the directory to monitor. The following

attributes are required:
- Path - The absolute path to the directory to monitor.
- expandEnvironment - Configures whether environment variables

in Path are expanded.
LocalResource The path relative to a local resource to monitor. Required attributes

are:
- Name - The local resource that contains the directory to monitor
- relativePath - The path relative to Name that contains the

directory to monitor
EtwProviders Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - EtwProviders
Configures collection of ETW events from EventSource and/or ETW Manifest based providers.
EtwEventSourceProviderConfiguration Configures collection of events generated from EventSource Class.

Required attribute:
provider - The class name of the EventSource event.
Optional attributes are:
- scheduledTransferLogLevelFilter - The minimum severity level to

transfer to your storage account.

EtwManifestProviderConfiguration Required attribute:
provider - The GUID of the event provider
Optional attributes are:
- scheduledTransferLogLevelFilter - The minimum severity level to

transfer to your storage account.

EtwEventSourceProviderConfiguration Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - EtwProviders-
EtwEventSourceProviderConfiguration
Configures collection of events generated from EventSource Class.
DefaultEvents Optional attribute:
eventDestination - The name of the table to store the events in
Event Required attribute:
id - The id of the event.
Optional attribute:

EtwManifestProviderConfiguration Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - EtwProviders -
EtwManifestProviderConfiguration
DefaultEvents Optional attribute:
Event Required attribute:
id - The id of the event.
Optional attribute:
Metrics Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - Metrics
Enables you to generate a performance counter table that is optimized for fast queries. Each performance counter that is
defined in the PerformanceCounters element is stored in the Metrics table in addition to the Performance Counter table.
The resourceId attribute is required. The resource ID of the Virtual Machine or Virtual Machine Scale Set you are deploying
Azure Diagnostics to. Get the resourceID from the Azure portal. Select Browse -> Resource Groups -> <Name>. Click the
Properties tile and copy the value from the ID field.
MetricAggregation Required attribute:
scheduledTransferPeriod - The interval between scheduled

PerformanceCounters Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - PerformanceCounters
Enables the collection of performance counters.
Optional attribute:
CHILD ELEMENT DESCRIPTION
PerformanceCounterConfiguration The following attributes are required:
- counterSpecifier - The name of the performance counter. For

example, \Processor(_Total)\% Processor Time . To get a list of
performance counters on your host, run the command typeperf .
- sampleRate - How often the counter should be sampled.
Optional attribute:
unit - The unit of measure of the counter.
sinks Added in 1.5. Optional. Points to a sink location to also send

diagnostic data. For example, Azure Monitor or Event Hubs.
WindowsEventLog Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - WindowsEventLog
Enables the collection of Windows Event Logs.
CHILD ELEMENT DESCRIPTION
DataSource The Windows Event logs to collect. Required attribute:
name - The XPath query describing the windows events to be

collected. For example:
Application!*[System[(Level <=3)]], System!*[System[(Level

<=3)]], System!*[System[Provider[@Name='Microsoft
Antimalware']]], Security!*[System[(Level <= 3)]
To collect all events, specify "*"
Logs Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - Logs
Present in version 1.0 and 1.1. Missing in 1.2. Added back in 1.3.
Defines the buffer configuration for basic Azure logs.
ATTRIBUTE TYPE DESCRIPTION
bufferQuotaInMB unsignedInt Optional. Specifies the maximum amount of

file system storage that is available for the
specified data.
The default is 0.
scheduledTransferLogLevelFilter string Optional. Specifies the minimum severity

level for log entries that are transferred. The
default value is Undefined, which transfers
all logs. Other possible values (in order of
most to least information) are Verbose,
Information, Warning, Error, and Critical.
scheduledTransferPeriod duration Optional. Specifies the interval between

scheduled transfers of data, rounded up to
the nearest minute.
The default is PT0S.
sinks string Added in 1.5. Optional. Points to a sink

location to also send diagnostic data. For
example, Application Insights or Event Hubs.
DockerSources
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - DiagnosticMonitorConfiguration - DockerSources
Added in 1.9.
ELEMENT NAME DESCRIPTION
Stats Tells the system to collect stats for Docker containers

SinksConfig Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - SinksConfig
A list of locations to send diagnostics data to and the configuration associated with those locations.
Sink See description elsewhere on this page.
Sink Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - SinksConfig - Sink
Defines locations to send diagnostic data to. For example, the Application Insights service.
ATTRIBUTE TYPE DESCRIPTION
name string A string identifying the sinkname.
ELEMENT TYPE DESCRIPTION
Application Insights string Used only when sending data to Application

Insights. Contain the Instrumentation Key
for an active Application Insights account
that you have access to.
Channels string One for each additional filtering that stream

that you
Channels Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - SinksConfig - Sink - Channels
Defines filters for streams of log data passing through a sink.
ELEMENT TYPE DESCRIPTION
Channel string See description elsewhere on this page.
Channel Element
Tree: Root - DiagnosticsConfiguration - PublicConfig - WadCFG - SinksConfig - Sink - Channels - Channel
Defines locations to send diagnostic data to. For example, the Application Insights service.
ATTRIBUTES TYPE DESCRIPTION
logLevel string Specifies the minimum severity level for log

entries that are transferred. The default
value is Undefined, which transfers all logs.
Other possible values (in order of most to
least information) are Verbose,
Information, Warning, Error, and Critical.
name string A unique name of the channel to refer to

PrivateConfig Element
Tree: Root - DiagnosticsConfiguration - PrivateConfig
Optional
Stores the private details of the storage account (name, key, and endpoint). This information is sent to the virtual machine, but
cannot be retrieved from it.
StorageAccount The storage account to use. The following attributes are required
- name - The name of the storage account.
- key - The key to the storage account.
- endpoint - The endpoint to access the storage account.
-sasToken (added 1.8.1)- You can specify an SAS token instead of a

storage account key in the private config. If provided, the storage
account key is ignored.
Requirements for the SAS Token:
- Supports account SAS token only
- b, t service types are required.
- a, c, u, w permissions are required.
- c, o resource types are required.
- Supports the HTTPS protocol only
- Start and expiry time must be valid.
IsEnabled Element
Tree: Root - DiagnosticsConfiguration - IsEnabled
Boolean. Use true to enable the diagnostics or false to disable the diagnostics.
Store and view diagnostic data in Azure Storage
Diagnostic data is not permanently stored unless you transfer it to the Microsoft Azure storage emulator or to
Azure storage. Once in storage, it can be viewed with one of several available tools.
Specify a storage account

You specify the storage account that you want to use in the ServiceConfiguration.cscfg file. The account
information is defined as a connection string in a configuration setting. The following example shows the default
connection string created for a new Cloud Service project in Visual Studio:
value="UseDevelopmentStorage=true" />
You can change this connection string to provide account information for an Azure storage account.
Depending on the type of diagnostic data that is being collected, Azure Diagnostics uses either the Blob service or
the Table service. The following table shows the data sources that are persisted and their format.
DATA SOURCE STORAGE FORMAT
Azure logs Table
IIS 7.0 logs Blob
Azure Diagnostics infrastructure logs Table
Failed Request Trace logs Blob
Windows Event logs Table
Performance counters Table
Crash dumps Blob
Custom error logs Blob
Transfer diagnostic data

For SDK 2.5 and later, the request to transfer diagnostic data can occur through the configuration file. You can
transfer diagnostic data at scheduled intervals as specified in the configuration.
For SDK 2.4 and previous you can request to transfer the diagnostic data through the configuration file as well as
programmatically. The programmatic approach also allows you to do on-demand transfers.
IMPORTANT
When you transfer diagnostic data to an Azure storage account, you incur costs for the storage resources that your
diagnostic data uses.
Store diagnostic data

Log data is stored in either Blob or Table storage with the following names:
Tables
WadLogsTable - Logs written in code using the trace listener.
WADDiagnosticInfrastructureLogsTable - Diagnostic monitor and configuration changes.
WADDirectoriesTable – Directories that the diagnostic monitor is monitoring. This includes IIS logs, IIS failed
request logs, and custom directories. The location of the blob log file is specified in the Container field and the
name of the blob is in the RelativePath field. The AbsolutePath field indicates the location and name of the file
as it existed on the Azure virtual machine.
WADPerformanceCountersTable – Performance counters.
WADWindowsEventLogsTable – Windows Event logs.
Blobs
wad-control-container – (Only for SDK 2.4 and previous) Contains the XML configuration files that controls
the Azure diagnostics .
wad-iis-failedreqlogfiles – Contains information from IIS Failed Request logs.
wad-iis-logfiles – Contains information about IIS logs.
"custom" – A custom container based on configuring directories that are monitored by the diagnostic monitor.
The name of this blob container will be specified in WADDirectoriesTable.
Tools to view diagnostic data

Several tools are available to view the data after it is transferred to storage. For example:
Server Explorer in Visual Studio - If you have installed the Azure Tools for Microsoft Visual Studio, you can use
the Azure Storage node in Server Explorer to view read-only blob and table data from your Azure storage
accounts. You can display data from your local storage emulator account and also from storage accounts you
have created for Azure. For more information, see Browsing and Managing Storage Resources with Server
Explorer.
Microsoft Azure Storage Explorer is a standalone app that enables you to easily work with Azure Storage data
on Windows, OSX, and Linux.
Azure Management Studio includes Azure Diagnostics Manager which allows you to view, download and
manage the diagnostics data collected by the applications running on Azure.
Next Steps
Trace the flow in a Cloud Services application with Azure Diagnostics
Send Cloud Service, Virtual Machine, or Service
Fabric diagnostic data to Application Insights
Cloud services, Virtual Machines, Virtual Machine Scale Sets and Service Fabric all use the Azure Diagnostics
extension to collect data. Azure diagnostics sends data to Azure Storage tables. However, you can also pipe all or
a subset of the data to other locations using Azure Diagnostics extension 1.5 or later.
This article describes how to send data from the Azure Diagnostics extension to Application Insights.
Diagnostics configuration explained

The Azure diagnostics extension 1.5 introduced sinks, which are additional locations where you can send
diagnostic data.
Example configuration of a sink for Application Insights:
<SinksConfig>
<Channels>
<Channel logLevel="Error" name="MyTopDiagData" />
<Channel logLevel="Verbose" name="MyLogData" />
</Channels>
</Sink>
</SinksConfig>
"SinksConfig": {
"Sink": [
{
"Channels": {
"Channel": [
{
"name": "MyTopDiagData"
},
{
"name": "MyLogData"
}
]
}
}
]
}
The Sink name attribute is a string value that uniquely identifies the sink.
The ApplicationInsights element specifies instrumentation key of the Application insights resource
where the Azure diagnostics data is sent.
If you don't have an existing Application Insights resource, see Create a new Application Insights
resource for more information on creating a resource and getting the instrumentation key.
If you are developing a Cloud Service with Azure SDK 2.8 and later, this instrumentation key is
automatically populated. The value is based on the APPINSIGHTS_INSTRUMENTATIONKEY
service configuration setting when packaging the Cloud Service project. See Use Application Insights
with Cloud Services.
The Channels element contains one or more Channel elements.
The name attribute uniquely refers to that channel.
The loglevel attribute lets you specify the log level that the channel allows. The available log levels in
order of most to least information are:
Verbose
Information
Warning
Error
Critical
A channel acts like a filter and allows you to select specific log levels to send to the target sink. For example, you
could collect verbose logs and send them to storage, but send only Errors to the sink.
The following graphic shows this relationship.
The following graphic summarizes the configuration values and how they work. You can include multiple sinks in
the configuration at different levels in the hierarchy. The sink at the top level acts as a global setting and the one
specified at the individual element acts like an override to that global setting.
Complete sink configuration example

Here is a complete example of the public configuration file that
1. sends all errors to Application Insights (specified at the DiagnosticMonitorConfiguration node)
2. also sends Verbose level logs for the Application Logs (specified at the Logs node).
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096"
sinks="ApplicationInsights.MyTopDiagData"> 
<DiagnosticInfrastructureLogs />
<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time"
sampleRate="PT3M" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT3M" />
</WindowsEventLog>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose"
sinks="ApplicationInsights.MyLogData"/> 
<SinksConfig>
<Channels>
<Channel logLevel="Error" name="MyTopDiagData" />
<Channel logLevel="Verbose" name="MyLogData" />
</Channels>
</Sink>
</SinksConfig>
</WadCfg>
"WadCfg": {
"sinks": "ApplicationInsights.MyTopDiagData", "_comment": "All info below sent to this channel",
},
{
"sampleRate": "PT3M"
},
{
"counterSpecifier": "\\Memory\\Available MBytes",
}
]
},
"DataSource": [
{
"name": "Application!*"
}
]
},
"Logs": {
"scheduledTransferLogLevelFilter": "Verbose",
"sinks": "ApplicationInsights.MyLogData", "_comment": "This specific info sent to this channel"
}
},
"SinksConfig": {
"Sink": [
{
"Channels": {
"Channel": [
{
"name": "MyTopDiagData"
},
{
"logLevel": "Verbose",
"name": "MyLogData"
}
]
}
}
]
}
}
In the previous configuration, the following lines have the following meanings:
Send all the data that is being collected by Azure diagnostics
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="ApplicationInsights">

"sinks": "ApplicationInsights",
}
Send only error logs to the Application Insights sink
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="ApplicationInsights.MyTopDiagdata">
"sinks": "ApplicationInsights.MyTopDiagData",
}
Send Verbose application logs to Application Insights
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose"

sinks="ApplicationInsights.MyLogData"/>
"sinks": "ApplicationInsights.MyLogData",
}
Limitations
Channels only log type and not performance counters. If you specify a channel with a performance
counter element, it is ignored.
The log level for a channel cannot exceed the log level for what is being collected by Azure
diagnostics. For example, you cannot collect Application Log errors in the Logs element and try to send
Verbose logs to the Application Insight sink. The scheduledTransferLogLevelFilter attribute must always collect
equal or more logs than the logs you are trying to send to a sink.
You cannot send blob data collected by Azure diagnostics extension to Application Insights. For
example, anything specified under the Directories node. For Crash Dumps the actual crash dump is sent to
blob storage and only a notification that the crash dump was generated is sent to Application Insights.
Next Steps
Learn how to view your Azure diagnostics information in Application Insights.
Use PowerShell to enable the Azure diagnostics extension for your application.
Use Visual Studio to enable the Azure diagnostics extension for your application
Streaming Azure Diagnostics data in the hot path by
using Event Hubs
Azure Diagnostics provides flexible ways to collect metrics and logs from cloud services virtual machines (VMs)
and transfer results to Azure Storage. Starting in the March 2016 (SDK 2.9) time frame, you can send Diagnostics
to custom data sources and transfer hot path data in seconds by using Azure Event Hubs.
Supported data types include:
Event Tracing for Windows (ETW ) events
Windows event logs
Application logs
Azure Diagnostics infrastructure logs
This article shows you how to configure Azure Diagnostics with Event Hubs from end to end. Guidance is also
provided for the following common scenarios:
How to customize the logs and metrics that get sent to Event Hubs
How to change configurations in each environment
How to view Event Hubs stream data
How to troubleshoot the connection
Prerequisites
Event Hubs receiving data from Azure Diagnostics is supported in Cloud Services, VMs, Virtual Machine Scale
Sets, and Service Fabric starting in the Azure SDK 2.9 and the corresponding Azure Tools for Visual Studio.
Azure Diagnostics extension 1.6 (Azure SDK for .NET 2.9 or later targets this by default)
Visual Studio 2013 or later
Existing configurations of Azure Diagnostics in an application by using a .wadcfgx file and one of the following
methods:
Visual Studio: Configuring Diagnostics for Azure Cloud Services and Virtual Machines
Windows PowerShell: Enable diagnostics in Azure Cloud Services using PowerShell
Event Hubs namespace provisioned per the article, Get started with Event Hubs
Connect Azure Diagnostics to Event Hubs sink

By default, Azure Diagnostics always sends logs and metrics to an Azure Storage account. An application may also
send data to Event Hubs by adding a new Sinks section under the PublicConfig / WadCfg element of the
.wadcfgx file. In Visual Studio, the .wadcfgx file is stored in the following path: Cloud Service Project > Roles >
(RoleName) > diagnostics.wadcfgx file.
<SinksConfig>
<Sink name="HotPath">
<EventHub Url="https://diags-mycompany-ns.servicebus.windows.net/diageventhub"
SharedAccessKeyName="SendRule" />
</Sink>
</SinksConfig>
"SinksConfig": {
"Sink": [
{
"name": "HotPath",
"EventHub": {
"Url": "https://diags-mycompany-ns.servicebus.windows.net/diageventhub",
"SharedAccessKeyName": "SendRule"
}
}
]
}
In this example, the event hub URL is set to the fully qualified namespace of the event hub: Event Hubs namespace
+ "/" + event hub name.
The event hub URL is displayed in the Azure portal on the Event Hubs dashboard.
The Sink name can be set to any valid string as long as the same value is used consistently throughout the config
file.
NOTE
There may be additional sinks, such as applicationInsights configured in this section. Azure Diagnostics allows one or more
sinks to be defined if each sink is also declared in the PrivateConfig section.
The Event Hubs sink must also be declared and defined in the PrivateConfig section of the .wadcfgx config file.
<PrivateConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<StorageAccount name="{account name}" key="{account key}" endpoint="{optional storage endpoint}" />
<EventHub Url="https://diags-mycompany-ns.servicebus.windows.net/diageventhub"
SharedAccessKeyName="SendRule" SharedAccessKey="{base64 encoded key}" />
</PrivateConfig>
{
"storageAccountName": "{account name}",
"storageAccountKey": "{account key}",
"storageAccountEndPoint": "{optional storage endpoint}",
"EventHub": {
"Url": "https://diags-mycompany-ns.servicebus.windows.net/diageventhub",
}
}
The SharedAccessKeyName value must match a Shared Access Signature (SAS ) key and policy that has been defined
in the Event Hubs namespace. Browse to the Event Hubs dashboard in the Azure portal, click the Configure tab,
and set up a named policy (for example, "SendRule") that has Send permissions. The StorageAccount is also
declared in PrivateConfig. There is no need to change values here if they are working. In this example, we leave
the values empty, which is a sign that a downstream asset will set the values. For example, the
ServiceConfiguration.Cloud.cscfg environment configuration file sets the environment-appropriate names and
keys.
WARNING
The Event Hubs SAS key is stored in plain text in the .wadcfgx file. Often, this key is checked in to source code control or is
available as an asset in your build server, so you should protect it as appropriate. We recommend that you use a SAS key
here with Send only permissions so that a malicious user can write to the event hub, but not listen to it or manage it.
Configure Azure Diagnostics to send logs and metrics to Event Hubs

As discussed previously, all default and custom diagnostics data, that is, metrics and logs, is automatically sent to
Azure Storage in the configured intervals. With Event Hubs and any additional sink, you can specify any root or
leaf node in the hierarchy to be sent to the event hub. This includes ETW events, performance counters, Windows
event logs, and application logs.
It is important to consider how many data points should actually be transferred to Event Hubs. Typically,
developers transfer low -latency hot-path data that must be consumed and interpreted quickly. Systems that
monitor alerts or autoscale rules are examples. A developer might also configure an alternate analysis store or
search store -- for example, Azure Stream Analytics, Elasticsearch, a custom monitoring system, or a favorite
monitoring system from others.
The following are some example configurations.
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="HotPath">

<PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\ISAPI Extension Requests/sec"
<PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Bytes Total/Sec" sampleRate="PT3M"
/>
"sinks": "HotPath",
{
},
{
},
{
"counterSpecifier": "\\Web Service(_Total)\\ISAPI Extension Requests/sec",
}
]
}
In the above example, the sink is applied to the parent PerformanceCounters node in the hierarchy, which means
all child PerformanceCounters will be sent to Event Hubs.
<PerformanceCounters scheduledTransferPeriod="PT1M">
<PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\ISAPI Extension Requests/sec"
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET\Requests Queued" sampleRate="PT3M"
sinks="HotPath" />
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET\Requests Rejected" sampleRate="PT3M"
sinks="HotPath"/>
sinks="HotPath"/>
{
"sinks": "HotPath"
},
{
},
{
},
{
"counterSpecifier": "\\ASP.NET\\Requests Rejected",
"sinks": "HotPath"
},
{
"counterSpecifier": "\\ASP.NET\\Requests Queued",
"sinks": "HotPath"
}
]
}
In the previous example, the sink is applied to only three counters: Requests Queued, Requests Rejected, and %
Processor time.
The following example shows how a developer can limit the amount of sent data to be the critical metrics that are
used for this service’s health.
<Logs scheduledTransferPeriod="PT1M" sinks="HotPath" scheduledTransferLogLevelFilter="Error" />
"Logs": {
"scheduledTransferLogLevelFilter": "Error",
"sinks": "HotPath"
}
In this example, the sink is applied to logs and is filtered only to error level trace.
Deploy and update a Cloud Services application and diagnostics config

Visual Studio provides the easiest path to deploy the application and Event Hubs sink configuration. To view and
edit the file, open the .wadcfgx file in Visual Studio, edit it, and save it. The path is Cloud Service Project > Roles
> (RoleName) > diagnostics.wadcfgx.
At this point, all deployment and deployment update actions in Visual Studio, Visual Studio Team System, and all
commands or scripts that are based on MSBuild and use the /t:publish target include the .wadcfgx in the
packaging process. In addition, deployments and updates deploy the file to Azure by using the appropriate Azure
Diagnostics agent extension on your VMs.
After you deploy the application and Azure Diagnostics configuration, you will immediately see activity in the
dashboard of the event hub. This indicates that you're ready to move on to viewing the hot-path data in the listener
client or analysis tool of your choice.
In the following figure, the Event Hubs dashboard shows healthy sending of diagnostics data to the event hub
starting sometime after 11 PM. That's when the application was deployed with an updated .wadcfgx file, and the
sink was configured properly.
NOTE
When you make updates to the Azure Diagnostics config file (.wadcfgx), it's recommended that you push the updates to the
entire application as well as the configuration by using either Visual Studio publishing, or a Windows PowerShell script.
View hot-path data

As discussed previously, there are many use cases for listening to and processing Event Hubs data.
One simple approach is to create a small test console application to listen to the event hub and print the output
stream. You can place the following code, which is explained in more detail in Get started with Event Hubs ), in a
console application.
Note that the console application must include the Event Processor Host NuGet package.
Remember to replace the values in angle brackets in the Main function with values for your resources.
//Console application code for EventHub test client

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using Microsoft.ServiceBus.Messaging;
namespace EventHubListener
{
class SimpleEventProcessor : IEventProcessor
{
Stopwatch checkpointStopWatch;
async Task IEventProcessor.CloseAsync(PartitionContext context, CloseReason reason)

{
Console.WriteLine("Processor Shutting Down. Partition '{0}', Reason: '{1}'.",
context.Lease.PartitionId, reason);
if (reason == CloseReason.Shutdown)
{
await context.CheckpointAsync();
}
}
Task IEventProcessor.OpenAsync(PartitionContext context)

{
Console.WriteLine("SimpleEventProcessor initialized. Partition: '{0}', Offset: '{1}'",
context.Lease.PartitionId, context.Lease.Offset);
this.checkpointStopWatch = new Stopwatch();
this.checkpointStopWatch.Start();
return Task.FromResult<object>(null);
}
async Task IEventProcessor.ProcessEventsAsync(PartitionContext context, IEnumerable<EventData>

messages)
{
foreach (EventData eventData in messages)
{
string data = Encoding.UTF8.GetString(eventData.GetBytes());
Console.WriteLine(string.Format("Message received. Partition: '{0}', Data: '{1}'",
context.Lease.PartitionId, data));
foreach (var x in eventData.Properties)

{
Console.WriteLine(string.Format(" {0} = {1}", x.Key, x.Value));
}
}
//Call checkpoint every 5 minutes, so that worker can resume processing from 5 minutes back if it
restarts.
if (this.checkpointStopWatch.Elapsed > TimeSpan.FromMinutes(5))
{
await context.CheckpointAsync();
this.checkpointStopWatch.Restart();
}
}
}
class Program
{
{
string eventHubConnectionString = "Endpoint= <your connection string>";
string eventHubName = "<Event hub name>";
string storageAccountName = "<Storage account name>";
string storageAccountKey = "<Storage account key>";
string storageConnectionString = string.Format("DefaultEndpointsProtocol=https;AccountName=
{0};AccountKey={1}", storageAccountName, storageAccountKey);
string eventProcessorHostName = Guid.NewGuid().ToString();

EventProcessorHost eventProcessorHost = new EventProcessorHost(eventProcessorHostName,
eventHubName, EventHubConsumerGroup.DefaultGroupName, eventHubConnectionString, storageConnectionString);
Console.WriteLine("Registering EventProcessor...");
var options = new EventProcessorOptions();
var options = new EventProcessorOptions();
options.ExceptionReceived += (sender, e) => { Console.WriteLine(e.Exception); };
eventProcessorHost.RegisterEventProcessorAsync<SimpleEventProcessor>(options).Wait();
Console.WriteLine("Receiving. Press enter key to stop worker.");

Console.ReadLine();
eventProcessorHost.UnregisterEventProcessorAsync().Wait();
}
}
}
Troubleshoot Event Hubs sinks

The event hub does not show incoming or outgoing event activity as expected.
Check that your event hub is successfully provisioned. All connection info in the PrivateConfig section of
.wadcfgx must match the values of your resource as seen in the portal. Make sure that you have a SAS
policy defined ("SendRule" in the example) in the portal and that Send permission is granted.
After an update, the event hub no longer shows incoming or outgoing event activity.
First, make sure that the event hub and configuration info is correct as explained previously. Sometimes the
PrivateConfig is reset in a deployment update. The recommended fix is to make all changes to .wadcfgx in
the project and then push a complete application update. If this is not possible, make sure that the
diagnostics update pushes a complete PrivateConfig that includes the SAS key.
I tried the suggestions, and the event hub is still not working.
Try looking in the Azure Storage table that contains logs and errors for Azure Diagnostics itself:
WADDiagnosticInfrastructureLogsTable. One option is to use a tool such as Azure Storage Explorer to
connect to this storage account, view this table, and add a query for TimeStamp in the last 24 hours. You can
use the tool to export a .csv file and open it in an application such as Microsoft Excel. Excel makes it easy to
search for calling-card strings, such as EventHubs, to see what error is reported.
Next steps
• Learn more about Event Hubs
Appendix: Complete Azure Diagnostics configuration file (.wadcfgx)

example
<DiagnosticsConfiguration
xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="applicationInsights.errors">
<DiagnosticInfrastructureLogs scheduledTransferLogLevelFilter="Error" />
<IISLogs containerName="wad-iis-logfiles" />
<FailedRequestLogs containerName="wad-failedrequestlogs" />
</Directories>
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="HotPath">
<PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\ISAPI Extension
Requests/sec" sampleRate="PT3M" />
<PerformanceCounterConfiguration counterSpecifier="\Web Service(_Total)\Bytes Total/Sec"
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET Applications(__Total__)\Requests/Sec"
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET Applications(__Total__)\Errors
Total/Sec" sampleRate="PT3M" />
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET\Requests Queued" sampleRate="PT3M" />
<PerformanceCounterConfiguration counterSpecifier="\ASP.NET\Requests Rejected" sampleRate="PT3M" />
</WindowsEventLog>
<CrashDumps>
<CrashDumpConfiguration processName="WaIISHost.exe" />
<CrashDumpConfiguration processName="WaWorkerHost.exe" />
<CrashDumpConfiguration processName="w3wp.exe" />
</CrashDumps>
<Logs scheduledTransferPeriod="PT1M" sinks="HotPath" scheduledTransferLogLevelFilter="Error" />
<SinksConfig>
<Sink name="HotPath">
<EventHub Url="https://diageventhub-py-ns.servicebus.windows.net/diageventhub-py"
SharedAccessKeyName="SendRule" />
</Sink>
<Sink name="applicationInsights">
<ApplicationInsights />
<Channels>
<Channel logLevel="Error" name="errors" />
</Channels>
</Sink>
</SinksConfig>
</WadCfg>
<StorageAccount>ACCOUNT_NAME</StorageAccount>
</PublicConfig>
<StorageAccount name="{account name}" key="{account key}" endpoint="{storage endpoint}" />
<EventHub Url="https://diageventhub-py-ns.servicebus.windows.net/diageventhub-py"
SharedAccessKeyName="SendRule" SharedAccessKey="YOUR_KEY_HERE" />
</PrivateConfig>
The complementary ServiceConfiguration.Cloud.cscfg for this example looks like the following.
<ServiceConfiguration serviceName="MyFixItCloudService"
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="3" osVersion="*"
schemaVersion="2015-04.2.6">
<Role name="MyFixIt.WorkerRole">
<Instances count="1" />
value="YOUR_CONNECTION_STRING" />
</Role>
</ServiceConfiguration>
Equivalent JSON settings for virtual machines is as follows:

Public Settings:
{
"WadCfg": {
"sinks": "applicationInsights.errors",
},
"Directories": {
"IISLogs": {
"containerName": "wad-iis-logfiles"
},
"containerName": "wad-failedrequestlogs"
}
},
"sinks": "HotPath",
{
},
{
},
{
"counterSpecifier": "\\Web Service(_Total)\\Bytes Total/Sec",
},
{
"counterSpecifier": "\\ASP.NET Applications(__Total__)\\Requests/Sec",
},
{
"counterSpecifier": "\\ASP.NET Applications(__Total__)\\Errors Total/Sec",
},
{
"counterSpecifier": "\\ASP.NET\\Requests Queued",
},
{
"counterSpecifier": "\\ASP.NET\\Requests Rejected",
},
{
}
]
},
"DataSource": [
{
}
]
},
"Logs": {
"scheduledTransferLogLevelFilter": "Error",
"sinks": "HotPath"
}
},
"SinksConfig": {
"Sink": [
{
"name": "HotPath",
"EventHub": {
"Url": "https://diageventhub-py-ns.servicebus.windows.net/diageventhub-py",
"SharedAccessKeyName": "SendRule"
}
},
{
"name": "applicationInsights",
"ApplicationInsights": "",
"Channels": {
"Channel": [
{
"name": "errors"
}
]
}
}
]
}
},
"StorageAccount": "{account name}"
}
Protected Settings:
{
"storageAccountName": "{account name}",
"storageAccountKey": "{account key}",
"storageAccountEndPoint": "{storage endpoint}",
"EventHub": {
"Url": "https://diageventhub-py-ns.servicebus.windows.net/diageventhub-py",
"SharedAccessKey": "YOUR_KEY_HERE"
}
}
Next steps
You can learn more about Event Hubs by visiting the following links:
Event Hubs overview
Create an event hub
Event Hubs FAQ
Send Guest OS metrics to the Azure Monitor metric
store using a Resource Manager template for a
Windows virtual machine
NOTE
PowerShell.
By using the Azure Monitor Diagnostics extension, you can collect metrics and logs from the guest operating
system (Guest OS ) that's running as part of a virtual machine, cloud service, or Service Fabric cluster. The
extension can send telemetry to many different locations.
This article describes the process for sending Guest OS performance metrics for a Windows virtual machine to the
Azure Monitor data store. Starting with Diagnostics version 1.11, you can write metrics directly to the Azure
Monitor metrics store, where standard platform metrics are already collected.
Storing them in this location allows you to access the same actions for platform metrics. Actions include near-real
time alerting, charting, routing, and access from a REST API and more. In the past, the Diagnostics extension
wrote to Azure Storage, but not to the Azure Monitor data store.
If you're new to Resource Manager templates, learn about template deployments and their structure and syntax.
Prerequisites
Your subscription must be registered with Microsoft.Insights.
You need to have either Azure PowerShell or Azure Cloud Shell installed.
Your VM resource must be in a region that supports custom metrics.
Set up Azure Monitor as a data sink

The Azure Diagnostics extension uses a feature called "data sinks" to route metrics and logs to different locations.
The following steps show how to use a Resource Manager template and PowerShell to deploy a VM by using the
new "Azure Monitor" data sink.
Author Resource Manager template

For this example, you can use a publicly available sample template. The starting templates are at
https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-simple-windows.
Azuredeploy.json is a preconfigured Resource Manager template for the deployment of a virtual machine.
Azuredeploy.parameters.json is a parameters file that stores information such as what user name and
password you would like to set for your VM. During deployment, the Resource Manager template uses the
parameters that are set in this file.
Download and save both files locally.
Modify azuredeploy.parameters.json
Open the azuredeploy.parameters.json file
1. Enter values for adminUsername and adminPassword for the VM. These parameters are used for
remote access to the VM. To avoid having your VM hijacked, DO NOT use the values in this template. Bots
scan the internet for user names and passwords in public GitHub repositories. They are likely to be testing
VMs with these defaults.
2. Create a unique dnsname for the VM.
Modify azuredeploy.json
Open the azuredeploy.json file
Add a storage account ID to the variables section of the template after the entry for storageAccountName.
// Find these lines.

"variables": {
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sawinvm')]",
// Add this line directly below.

"accountid": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
Add this Managed Service Identity (MSI) extension to the template at the top of the resources section. The
extension ensures that Azure Monitor accepts the metrics that are being emitted.
//Find this code.

"resources": [
// Add this code directly below.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'), '/', 'WADExtensionSetup')]",
"apiVersion": "2017-12-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]" ],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"port": 50342
}
}
},
Add the identity configuration to the VM resource to ensure that Azure assigns a system identity to the MSI
extension. This step ensures that the VM can emit guest metrics about itself to Azure Monitor.
// Find this section
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2017-03-30",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
// add these 3 lines below
"identity": {
"type": "SystemAssigned"
},
//end of added lines
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
...
Add the following configuration to enable the Diagnostics extension on a Windows virtual machine. For a simple
Resource Manager-based virtual machine, we can add the extension configuration to theresourcesarray for the
virtual machine. The line "sinks"— "AzMonSink" and the corresponding "SinksConfig" later in the section—enable
the extension to emit metrics directly to Azure Monitor. Feel free to add or remove performance counters as
needed.
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
},
//Start of section to add
"resources": [
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'), '/', 'Microsoft.Insights.VMDiagnosticsSettings')]",
"apiVersion": "2017-12-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Diagnostics",
"type": "IaaSDiagnostics",
"settings": {
"WadCfg": {
"WadCfg": {
},
"Directories": {
"IISLogs": {
"containerName": "wad-iis-logfiles"
},
"containerName": "wad-failedrequestlogs"
}
},
"sinks": "AzMonSink",
{
"counterSpecifier": "\\Memory\\Available Bytes",
"sampleRate": "PT15S"
},
{
"counterSpecifier": "\\Memory\\% Committed Bytes In Use",
},
{
"counterSpecifier": "\\Memory\\Committed Bytes",
}
]
},
"DataSource": [
{
}
]
},
"Logs": {
}
},
"SinksConfig": {
"Sink": [
{
"name" : "AzMonSink",
"AzureMonitor" : {}
}
]
}
},
"StorageAccount": "[variables('storageAccountName')]"
},
"protectedSettings": {
"storageAccountName": "[variables('storageAccountName')]",
"storageAccountKey": "[listKeys(variables('accountid'),'2015-06-15').key1]",
"storageAccountEndPoint": "https://core.windows.net/"
}
}
}
]
//End of section to add
Save and close both files.

Deploy the Resource Manager template
NOTE
You must be running the Azure Diagnostics extension version 1.5 or higher AND have the autoUpgradeMinorVersion:
property set to ‘true’ in your Resource Manager template. Azure then loads the proper extension when it starts the VM. If
you don't have these settings in your template, change them and redeploy the template.
To deploy the Resource Manager template, we leverage Azure PowerShell.

1. Launch PowerShell.
2. Log in to Azure using Login-AzAccount .
3. Get your list of subscriptions by using Get-AzSubscription .
4. Set the subscription that you're using to create/update the virtual machine in:
Select-AzSubscription -SubscriptionName "<Name of the subscription>"
5. To create a new resource group for the VM that's being deployed, run the following command:
New-AzResourceGroup -Name "<Name of Resource Group>" -Location "<Azure Region>"
NOTE
Remember to use an Azure region that is enabled for custom metrics.
6. Run the following commands to deploy the VM using the Resource Manager template.
NOTE
If you wish to update an existing VM, simply add -Mode Incremental to the end of the following command.
New-AzResourceGroupDeployment -Name "<NameThisDeployment>" -ResourceGroupName "<Name of the Resource

Group>" -TemplateFile "<File path of your Resource Manager template>" -TemplateParameterFile "<File
path of your parameters file>"
7. After your deployment succeeds, the VM should be in the Azure portal, emitting metrics to Azure Monitor.
NOTE
You might run into errors around the selected vmSkuSize. If this happens, go back to your azuredeploy.json file, and
update the default value of the vmSkuSize parameter. In this case, we recommend trying "Standard_DS1_v2").
Chart your metrics

1. Log in to the Azure portal.
2. On the left menu, select Monitor.
3. On the Monitor page, select Metrics.
4. Change the aggregation period to Last 30 minutes.
5. In the resource drop-down menu, select the VM that you created. If you didn't change the name in the
template, it should be SimpleWinVM2.
6. In the namespaces drop-down menu, select azure.vm.windows.guest
7. In the metrics drop down menu, select Memory%Committed Bytes in Use.
Next steps
Learn more about custom metrics.
Send guest OS metrics to the Azure Monitor metric
store by using an Azure Resource Manager template
for a Windows virtual machine scale set
NOTE
PowerShell.
By using the Azure Monitor Windows Azure Diagnostics (WAD ) extension, you can collect metrics and logs from
the guest operating system (guest OS ) that runs as part of a virtual machine, cloud service, or Azure Service Fabric
cluster. The extension can send telemetry to many different locations listed in the previously linked article.
This article describes the process to send guest OS performance metrics for a Windows virtual machine scale set
to the Azure Monitor data store. Starting with Windows Azure Diagnostics version 1.11, you can write metrics
directly to the Azure Monitor metrics store, where standard platform metrics are already collected. By storing them
in this location, you can access the same actions that are available for platform metrics. Actions include near real-
time alerting, charting, routing, access from the REST API, and more. In the past, the Windows Azure Diagnostics
extension wrote to Azure Storage but not the Azure Monitor data store.
If you're new to Resource Manager templates, learn about template deployments and their structure and syntax.
Prerequisites
You need to have Azure PowerShell installed, or you can use Azure Cloud Shell.
Set up Azure Monitor as a data sink

The Azure Diagnostics extension uses a feature called data sinks to route metrics and logs to different locations.
The following steps show how to use a Resource Manager template and PowerShell to deploy a VM by using the
new Azure Monitor data sink.
Author a Resource Manager template

For this example, you can use a publicly available sample template:
Azuredeploy.json is a preconfigured Resource Manager template for deployment of a virtual machine
scale set.
Azuredeploy.parameters.json is a parameters file that stores information like what username and
password you want to set for your VM. During deployment, the Resource Manager template uses the
parameters set in this file.
Download and save both files locally.
Modify azuredeploy.parameters.json
Open the azuredeploy.parameters.json file:
Provide a vmSKU you want to deploy. We recommend Standard_D2_v3.
Specify a windowsOSVersion you want for your virtual machine scale set. We recommend 2016-Datacenter.
Name the virtual machine scale set resource to be deployed by using a vmssName property. An example is
VMSS -WAD -TEST.
Specify the number of VMs you want to run on the virtual machine scale set by using the instanceCount
property.
Enter values for adminUsername and adminPassword for the virtual machine scale set. These parameters
are used for remote access to the VMs in the scale set. To avoid having your VM hijacked, do not use the ones
in this template. Bots scan the internet for usernames and passwords in public GitHub repositories. They're
likely to be testing VMs with these defaults.
Modify azuredeploy.json
Open the azuredeploy.json file.
Add a variable to hold the storage account information in the Resource Manager template. Any logs or
performance counters specified in the diagnostics config file are written to both the Azure Monitor metric store and
the storage account you specify here:
"variables": {
//add this line
"storageAccountName": "[concat('storage', uniqueString(resourceGroup().id))]",
Find the virtual machine scale set definition in the resources section and add the identity section to the
configuration. This addition ensures that Azure assigns it a system identity. This step also ensures that the VMs in
the scale set can emit guest metrics about themselves to Azure Monitor:
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "[variables('namingInfix')]",
"apiVersion": "2017-03-30",
//add these lines below
"identity": {
"type": "systemAssigned"
},
//end of lines to add
In the virtual machine scale set resource, find the virtualMachineProfile section. Add a new profile called
extensionsProfile to manage extensions.
In the extensionProfile, add a new extension to the template as shown in the VMSS -WAD -extension section.
This section is the managed identities for Azure resources extension that ensures the metrics being emitted are
accepted by Azure Monitor. The name field can contain any name.
The following code from the MSI extension also adds the diagnostics extension and configuration as an extension
resource to the virtual machine scale set resource. Feel free to add or remove performance counters as needed:
"extensionProfile": {
"extensions": [
// BEGINNING of added code
// Managed identities for Azure resources
{
{
"name": "VMSS-WAD-extension",
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"settings": {
"port": 50342
},
"protectedSettings": {}
}
},
// add diagnostic extension. (Remove this comment after pasting.)
{
"name": "[concat('VMDiagnosticsVmExt','_vmNodeType0Name')]",
"properties": {
"type": "IaaSDiagnostics",
"protectedSettings": {
"storageAccountName": "[variables('storageAccountName')]",
"storageAccountKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts',
variables('storageAccountName')),'2015-05-01-preview').key1]",
"storageAccountEndPoint": "https://core.windows.net/"
},
"publisher": "Microsoft.Azure.Diagnostics",
"settings": {
"WadCfg": {
"overallQuotaInMB": "50000",
"sinks": "AzMonSink",
{
"counterSpecifier": "\\Memory\\% Committed Bytes In Use",
},
{
"counterSpecifier": "\\Memory\\Available Bytes",
},
{
"counterSpecifier": "\\Memory\\Committed Bytes",
}
]
},
"EtwProviders": {
{
"provider": "Microsoft-ServiceFabric-Actors",
"scheduledTransferKeywordFilter": "1",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableActorEventTable"
}
},
{
"provider": "Microsoft-ServiceFabric-Services",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableServiceEventTable"
}
}
],
"EtwManifestProviderConfiguration": [
{
"provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
"provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
}
]
}
},
"SinksConfig": {
"Sink": [
{
"name": "AzMonSink",
"AzureMonitor": {}
}
]
}
},
"StorageAccount": "[variables('storageAccountName')]"
},
"typeHandlerVersion": "1.11"
}
}
]
}
}
}
},
//end of added code plus a few brackets. Be sure that the number and type of brackets match properly when
done.
{
"type": "Microsoft.Insights/autoscaleSettings",
...
Add a dependsOn for the storage account to ensure it's created in the correct order:
"dependsOn": [
"[concat('Microsoft.Network/loadBalancers/', variables('loadBalancerName'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
//add this line below
"[concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]"
Create a storage account if one isn't already created in the template:
"resources": [
// add this code
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[variables('storageAccountName')]",
"properties": {
"accountType": "Standard_LRS"
}
},
// end added code
{
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
Save and close both files.

Deploy the Resource Manager template
NOTE
You must be running the Azure Diagnostics extension version 1.5 or higher and have the autoUpgradeMinorVersion:
property set to true in your Resource Manager template. Azure then loads the proper extension when it starts the VM. If
you don't have these settings in your template, change them and redeploy the template.
To deploy the Resource Manager template, use Azure PowerShell:

1. Launch PowerShell.
2. Sign in to Azure using Login-AzAccount .
3. Get your list of subscriptions by using Get-AzSubscription .
4. Set the subscription you'll create, or update the virtual machine:
Select-AzSubscription -SubscriptionName "<Name of the subscription>"
5. Create a new resource group for the VM being deployed. Run the following command:
New-AzResourceGroup -Name "VMSSWADtestGrp" -Location "<Azure Region>"
NOTE
Remember to use an Azure region that's enabled for custom metrics. Remember to use an Azure region that's
enabled for custom metrics.
6. Run the following commands to deploy the VM:
NOTE
If you want to update an existing scale set, add -Mode Incremental to the end of the command.
New-AzResourceGroupDeployment -Name "VMSSWADTest" -ResourceGroupName "VMSSWADtestGrp" -TemplateFile "

<File path of your azuredeploy.JSON file>" -TemplateParameterFile "<File path of your
azuredeploy.parameters.JSON file>"
7. After your deployment succeeds, you should find the virtual machine scale set in the Azure portal. It should
emit metrics to Azure Monitor.
NOTE
You might run into errors around the selected vmSkuSize. In that case, go back to your azuredeploy.json file and
update the default value of the vmSkuSize parameter. We recommend that you try Standard_DS1_v2.
Chart your metrics

2. In the left-hand menu, select Monitor.

5. In the resource drop-down menu, select the virtual machine scale set you created.
6. In the namespaces drop-down menu, select azure.vm.windows.guest.
7. In the metrics drop-down menu, select Memory%Committed Bytes in Use.
You can then also choose to use the dimensions on this metric to chart it for a particular VM or to plot each VM in
the scale set.
Next steps
Send Guest OS metrics to the Azure Monitor data
store for a Windows virtual machine (classic)
NOTE
PowerShell.
The Azure Monitor Diagnostics extension (known as "WAD" or "Diagnostics") allows you to collect metrics and
logs from the guest operating system (Guest OS ) running as part of a virtual machine, cloud service, or Service
Fabric cluster. The extension can send telemetry to many different locations.
This article describes the process for sending Guest OS performance metrics for a Windows virtual machine
(classic) to the Azure Monitor metric store. Starting with Diagnostics version 1.11, you can write metrics directly to
the Azure Monitor metrics store, where standard platform metrics are already collected.
Storing them in this location allows you to access the same actions as you do for platform metrics. Actions include
near-real time alerting, charting, routing, access from a REST API, and more. In the past, the Diagnostics extension
wrote to Azure Storage, but not to the Azure Monitor data store.
The process that's outlined in this article only works on classic virtual machines that are running the Windows
operating system.
Prerequisites
You must be a service administrator or co-administrator on your Azure subscription.
Create a classic virtual machine and storage account

1. Create a classic VM by using the Azure portal.
2. When you're creating this VM, choose the option to create a new classic storage account. We use this
storage account in later steps.
3. In the Azure portal, go to the Storage accounts resource blade. Select Keys, and take note of the storage
account name and storage account key. You need this information in later steps.
Create a service principal

Create a service principle in your Azure Active Directory tenant by using the instructions at Create a service
principal. Note the following while going through this process:
Create new client secret for this app.
Save the key and the client ID for use in later steps.
Give this app “Monitoring Metrics Publisher” permissions to the resource that you want to emit metrics against.
You can use a resource group or an entire subscription.
NOTE
The Diagnostics extension uses the service principal to authenticate against Azure Monitor and emit metrics for your classic
VM.
Author Diagnostics extension configuration

1. Prepare your Diagnostics extension configuration file. This file dictates which logs and performance
counters the Diagnostics extension should collect for your classic VM. Following is an example:
<DiagnosticsConfiguration
xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="applicationInsights.errors">
</Directories>
<PerformanceCounterConfiguration counterSpecifier="\Processor(*)\% Processor Time"
sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes"
<PerformanceCounterConfiguration counterSpecifier="\Memory\Committed Bytes"
<PerformanceCounterConfiguration counterSpecifier="\Memory\% Committed Bytes"
<PerformanceCounterConfiguration counterSpecifier="\LogicalDisk(*)\Disk Read Bytes/sec"
<DataSource name="Application!*[System[(Level=1 or Level=2 or Level=3)]]" />
<DataSource name="Windows Azure!*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]" />
</WindowsEventLog>
<CrashDumps>
</CrashDumps>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Error" />
<Metrics resourceId="/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.ClassicCompute/virtualMachines/MyClassic
VM">
<MetricAggregation scheduledTransferPeriod="PT1M" />
<MetricAggregation scheduledTransferPeriod="PT1H" />
</Metrics>
<SinksConfig>
</SinksConfig>
</WadCfg>
<StorageAccount />
</PublicConfig>
<StorageAccount name="" endpoint="" />
</PrivateConfig>
2. In the “SinksConfig” section of your diagnostics file, define a new Azure Monitor sink, as follows:
<SinksConfig>
<Sink name="AzMonSink">
<AzureMonitor>
<ResourceId>Provide the resource ID of your classic VM </ResourceId>
<Region>The region your VM is deployed in</Region>
</AzureMonitor>
</Sink>
</SinksConfig>
3. In the section of your configuration file where the list of performance counters to be collected is listed, route
the performance counters to the Azure Monitor sink "AzMonSink".
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="AzMonSink">
...
4. In the private configuration, define the Azure Monitor account. Then add the service principal information to
use to emit metrics.
<ServicePrincipalMeta>
<PrincipalId>clientId for your service principal</PrincipalId>
<Secret>client secret of your service principal</Secret>
</PrivateConfig>
5. Save this file locally.
Deploy the Diagnostics extension to your cloud service

1. Launch PowerShell and sign in.
Login-AzAccount
2. Start by setting the context for your classic VM.
$VM = Get-AzureVM -ServiceName <VM’s Service_Name> -Name <VM Name>
3. Set the context of the classic storage account that was created with the VM.
$StorageContext = New-AzStorageContext -StorageAccountName <name of your storage account from earlier

steps> -storageaccountkey "<storage account key from earlier steps>"
4. Set the Diagnostics file path to a variable by using the following command:
$diagconfig = “<path of the diagnostics configuration file with the Azure Monitor sink configured>”
5. Prepare the update for your classic VM with the diagnostics file that has the Azure Monitor sink configured.
$VM_Update = Set-AzureVMDiagnosticsExtension -DiagnosticsConfigurationPath $diagconfig -VM $VM -

StorageContext $Storage_Context
6. Deploy the update to your VM by running the following command:
Update-AzureVM -ServiceName "ClassicVMWAD7216" -Name "ClassicVMWAD" -VM $VM_Update.VM

NOTE
It is still mandatory to provide a storage account as part of the installation of the Diagnostics extension. Any logs or
performance counters that are specified in the Diagnostics config file will be written to the specified storage account.
Plot the metrics in the Azure portal

1. Go to the Azure portal.
3. On the Monitor blade, select Metrics.
4. In the resources drop-down menu, select your classic VM.

6. In the metrics drop-down menu, select Memory\Committed Bytes in Use.
Next steps
Send Guest OS metrics to the Azure Monitor metric
store classic Cloud Services
NOTE
PowerShell.
With the Azure Monitor Diagnostics extension, you can collect metrics and logs from the guest operating system
(Guest OS ) running as part of a virtual machine, cloud service, or Service Fabric cluster. The extension can send
telemetry to many different locations.
This article describes the process for sending Guest OS performance metrics for Azure classic Cloud Services to
the Azure Monitor metric store. Starting with Diagnostics version 1.11, you can write metrics directly to the Azure
Monitor metrics store, where standard platform metrics are already collected.
Storing them in this location allows you to access the same actions that you can for platform metrics. Actions
include near-real time alerting, charting, routing, access from a REST API, and more. In the past, the Diagnostics
extension wrote to Azure Storage, but not to the Azure Monitor data store.
The process that's outlined in this article works only for performance counters in Azure Cloud Services. It doesn't
work for other custom metrics.
Prerequisites
You must be a service administrator or co-administrator on your Azure subscription.
Your Cloud Service must be in a region that supports custom metrics.
Provision a cloud service and storage account

1. Create and deploy a classic cloud service. A sample classic Cloud Services application and deployment can
be found at Get started with Azure Cloud Services and ASP.NET.
2. You can use an existing storage account or deploy a new storage account. It's best if the storage account is in
the same region as the classic cloud service that you created. In the Azure portal, go to the Storage
accounts resource blade, and then select Keys. Take note of the storage account name and the storage
account key. You'll need this information in later steps.
Create a service principle in your Azure Active Directory tenant by using the instructions at Use portal to create an
Azure Active Directory application and service principal that can access resources. Note the following while you're
going through this process:
You can put in any URL for the sign-in URL.
Create new client secret for this app.
Give the app created in the previous step Monitoring Metrics Publisher permissions to the resource you want to
emit metrics against. If you plan to use the app to emit custom metrics against many resources, you can grant these
permissions at the resource group or subscription level.
NOTE
The Diagnostics extension uses the service principal to authenticate against Azure Monitor and emit metrics for your cloud
service.
Author Diagnostics extension configuration

Prepare your Diagnostics extension configuration file. This file dictates which logs and performance counters the
Diagnostics extension should collect for your cloud service. Following is a sample Diagnostics configuration file:
<DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096">
</Directories>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Committed Bytes" sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Page Faults/sec" sampleRate="PT15S" />
<DataSource name="Application!*[System[(Level=1 or Level=2 or Level=3)]]" />
<DataSource name="Windows Azure!*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]" />
</WindowsEventLog>
<CrashDumps>
</CrashDumps>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Error" />
<SinksConfig>
</SinksConfig>
</WadCfg>
<StorageAccount />
</PublicConfig>
</PrivateConfig>
In the "SinksConfig" section of your diagnostics file, define a new Azure Monitor sink:
<SinksConfig>
<Sink name="AzMonSink">
<AzureMonitor>
<ResourceId>-Provide ClassicCloudService’s Resource ID-</ResourceId>
<Region>-Azure Region your Cloud Service is deployed in-</Region>
</AzureMonitor>
</Sink>
</SinksConfig>
In the section of your configuration file where you list the performance counters to collect, add the Azure Monitor
sink. This entry ensures that all the performance counters that you specified are routed to Azure Monitor as
metrics. You can add or remove performance counters according to your needs.
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="AzMonSink">

...
Finally, in the private configuration, add an Azure Monitor Account section. Enter the service principal client ID and
secret that you created earlier.
<ServicePrincipalMeta>
<PrincipalId>clientId from step 3</PrincipalId>
<Secret>client secret from step 3</Secret>
</PrivateConfig>
Save this diagnostics file locally.
Deploy the Diagnostics extension to your cloud service

Launch PowerShell and log in to Azure.
Login-AzAccount
Use the following commands to store the details of the storage account that you created earlier.
$storage_account = <name of your storage account from step 3>

$storage_keys = <storage account key from step 3>
Similarly, set the diagnostics file path to a variable by using the following command:
$diagconfig = “<path of the Diagnostics configuration file with the Azure Monitor sink configured>”
Deploy the Diagnostics extension to your cloud service with the diagnostics file with the Azure Monitor sink
configured using the following command:
Set-AzureServiceDiagnosticsExtension -ServiceName <classicCloudServiceName> -StorageAccountName

$storage_account -StorageAccountKey $storage_keys -DiagnosticsConfigurationPath $diagconfig
NOTE
It's still mandatory to provide a storage account as part of the installation of the Diagnostics extension. Any logs or
performance counters that are specified in the diagnostics config file are written to the specified storage account.
Plot metrics in the Azure portal

3. On the Monitor blade, select the Metrics Preview tab.
4. In the resources drop-down menu, select your classic cloud service.
6. In the metrics drop-down menu, select Memory\Committed Bytes in Use.
You use the dimension filtering and splitting capabilities to view the total memory that's used by a specific role or
role instance.
Next steps
Prepare for format change to Azure Monitor
diagnostic logs archived to a storage account
WARNING
If you are sending Azure resource diagnostic logs or metrics to a storage account using resource diagnostic settings or
activity logs to a storage account using log profiles, the format of the data in the storage account will change to JSON Lines
on Nov. 1, 2018. The instructions below describe the impact and how to update your tooling to handle the new format.
What is changing
Azure Monitor offers a capability that enables you to send resource diagnostic data and activity log data into an
Azure storage account, Event Hubs namespace, or into a Log Analytics workspace in Azure Monitor. In order to
address a system performance issue, on November 1, 2018 at 12:00 midnight UTC the format of log data send
to blob storage will change. If you have tooling that is reading data out of blob storage, you need to update your
tooling to understand the new data format.
On Thursday, November 1, 2018 at 12:00 midnight UTC, the blob format will change to be JSON Lines. This
means each record will be delimited by a newline, with no outer records array and no commas between JSON
records.
The blob format changes for all diagnostic settings across all subscriptions at once. The first PT1H.json file
emitted for November 1 will use this new format. The blob and container names remain the same.
Setting a diagnostic setting between now and November 1 continues to emit data in the current format until
November 1.
This change will occur at once across all public cloud regions. The change will not occur in Microsoft Azure
Operated by 21Vianet, Azure Germany, or Azure Government clouds yet.
This change impacts the following data types:
Azure resource diagnostic logs (see list of resources here)
Azure resource metrics being exported by diagnostic settings
Azure Activity log data being exported by log profiles
This change does not impact:
Network flow logs
Azure service logs not made available through Azure Monitor yet (for example, Azure App Service
diagnostic logs, storage analytics logs)
Routing of Azure diagnostic logs and activity logs to other destinations (Event Hubs, Log Analytics)
How to see if you are impacted
You are only impacted by this change if you:
1. Are sending log data to an Azure storage account using a resource diagnostic setting, and
2. Have tooling that depends on the JSON structure of these logs in storage.
To identify if you have resource diagnostic settings that are sending data to an Azure storage account, you can
navigate to the Monitor section of the portal, click on Diagnostic Settings, and identify any resources that have
Diagnostic Status set to Enabled:
If Diagnostic Status is set to enabled, you have an active diagnostic setting on that resource. Click on the resource
to see if any diagnostic settings are sending data to a storage account:
If you do have resources sending data to a storage account using these resource diagnostic settings, the format of
the data in that storage account will be impacted by this change. Unless you have custom tooling that operates off
of these storage accounts, the format change will not impact you.
Details of the format change
The current format of the PT1H.json file in Azure blob storage uses a JSON array of records. Here is a sample of a
KeyVault log file now:
{
"records": [
{
"time": "2016-01-05T01:32:01.2691226Z",
"resourceId": "/SUBSCRIPTIONS/361DA5D4-A47A-4C79-AFDD-
XXXXXXXXXXXX/RESOURCEGROUPS/CONTOSOGROUP/PROVIDERS/MICROSOFT.KEYVAULT/VAULTS/CONTOSOKEYVAULT",
"operationName": "VaultGet",
"operationVersion": "2015-06-01",
"category": "AuditEvent",
"resultType": "Success",
"resultSignature": "OK",
"resultDescription": "",
"durationMs": "78",
"callerIpAddress": "104.40.82.76",
"correlationId": "",
"identity": {
"claim": {
"http://schemas.microsoft.com/identity/claims/objectidentifier": "d9da5048-2737-4770-bd64-XXXXXXXXXXXX",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "live.com#username@outlook.com",
"appid": "1950a258-227b-4e31-a9cf-XXXXXXXXXXXX"
}
},
"properties": {
"clientInfo": "azure-resource-manager/2.0",
"requestUri": "https://control-prod-wus.vaultcore.azure.net/subscriptions/361da5d4-a47a-4c79-afdd-
XXXXXXXXXXXX/resourcegroups/contosoresourcegroup/providers/Microsoft.KeyVault/vaults/contosokeyvault?api-
version=2015-06-01",
"id": "https://contosokeyvault.vault.azure.net/",
"httpStatusCode": 200
}
},
{
"time": "2016-01-05T01:33:56.5264523Z",
"durationMs": "83",
"identity": {
"claim": {
}
},
"properties": {
version=2015-06-01",
}
}
]
}
The new format uses JSON lines, where each event is a line and the newline character indicates a new event. Here
is what the above sample will look like in the PT1H.json file after the change:
{"time": "2016-01-05T01:32:01.2691226Z","resourceId": "/SUBSCRIPTIONS/361DA5D4-A47A-4C79-AFDD-
XXXXXXXXXXXX/RESOURCEGROUPS/CONTOSOGROUP/PROVIDERS/MICROSOFT.KEYVAULT/VAULTS/CONTOSOKEYVAULT","operationName":
"VaultGet","operationVersion": "2015-06-01","category": "AuditEvent","resultType": "Success","resultSignature":
"OK","resultDescription": "","durationMs": "78","callerIpAddress": "104.40.82.76","correlationId":
"","identity": {"claim": {"http://schemas.microsoft.com/identity/claims/objectidentifier": "d9da5048-2737-4770-
bd64-XXXXXXXXXXXX","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":
"live.com#username@outlook.com","appid": "1950a258-227b-4e31-a9cf-XXXXXXXXXXXX"}},"properties": {"clientInfo":
"azure-resource-manager/2.0","requestUri": "https://control-prod-
wus.vaultcore.azure.net/subscriptions/361da5d4-a47a-4c79-afdd-
version=2015-06-01","id": "https://contosokeyvault.vault.azure.net/","httpStatusCode": 200}}
"VaultGet","operationVersion": "2015-06-01","category": "AuditEvent","resultType": "Success","resultSignature":
"OK","resultDescription": "","durationMs": "83","callerIpAddress": "104.40.82.76","correlationId":
"","identity": {"claim": {"http://schemas.microsoft.com/identity/claims/objectidentifier": "d9da5048-2737-4770-
bd64-XXXXXXXXXXXX","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":
This new format enables Azure Monitor to push log files using append blobs, which are more efficient for
continuously appending new event data.
How to update
You only need to make updates if you have custom tooling that ingests these log files for further processing. If you
are making use of an external log analytics or SIEM tool, we recommend using event hubs to ingest this data
instead. Event hubs integration is easier in terms of processing logs from many services and bookmarking location
in a particular log.
Custom tools should be updated to handle both the current format and the JSON Lines format described above.
This will ensure that when data starts to appear in the new format, your tools do not break.
Next steps
Learn about archiving resource diagnostic logs to a storage account
Learn about archiving activity log data to a storage account
Azure Diagnostics troubleshooting
This article describes troubleshooting information that's relevant to using Azure Diagnostics. For more information
about Azure diagnostics, see Azure Diagnostics overview.
Logical components
Diagnostics Plugin Launcher (DiagnosticsPluginLauncher.exe): Launches the Azure Diagnostics extension.
Serves as the entry point process.
Diagnostics Plugin (DiagnosticsPlugin.exe): Configures, launches, and manages the lifetime of the monitoring
agent. It is the main process that is launched by the launcher.
Monitoring Agent (MonAgent*.exe processes): Monitors, collects, and transfers the diagnostics data.
Log/artifact paths
Following are the paths to some important logs and artifacts. We refer to this information throughout the rest of
the document.
ARTIFACT PATH
Azure Diagnostics configuration file %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics

.PaaSDiagnostics<version>\Config.txt
Log files C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<

version>\
Local store for diagnostics data C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Tables
Monitoring agent configuration file C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Configuration\MaCo
nfig.xml
Azure Diagnostics extension package %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics

.PaaSDiagnostics<version>
Log collection utility path %SystemDrive%\Packages\GuestAgent\
MonAgentHost log file C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Configuration\MonA
gentHost.<seq_num>.log
Virtual machines
ARTIFACT PATH
ARTIFACT PATH
Azure Diagnostics configuration file C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<version>\RuntimeSettings
Log files C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\
Local store for diagnostics data C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
Monitoring agent configuration file C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\
MaConfig.xml
Status file C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<version>\Status
Azure Diagnostics extension package C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<DiagnosticsVersion>
Log collection utility path C:\WindowsAzure\Logs\WaAppAgent.log
MonAgentHost log file C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\
MonAgentHost.<seq_num>.log
Metric data doesn't appear in the Azure portal

Azure Diagnostics provides metric data that can be displayed in the Azure portal. If you have problems seeing the
data in portal, check the WADMetrics* table in the Azure Diagnostics storage account to see if the corresponding
metric records are there.
Here, the PartitionKey of the table is the resource ID, virtual machine, or virtual machine scale set. RowKey is the
metric name (also known as the performance counter name).
If the resource ID is incorrect, check Diagnostics Configuration > Metrics > ResourceId to see if the resource
ID is set correctly.
If there's no data for the specific metric, check Diagnostics Configuration > PerformanceCounter to see if the
metric (performance counter) is included. We enable the following counters by default:
\Processor(_Total)% Processor Time
\Memory\Available Bytes
\ASP.NET Applications(Total)\Requests/Sec
\ASP.NET Applications(Total)\Errors Total/Sec
\ASP.NET\Requests Queued
\ASP.NET\Requests Rejected
\Processor(w3wp)% Processor Time
\Process(w3wp)\Private Bytes
\Process(WaIISHost)% Processor Time
\Process(WaIISHost)\Private Bytes
\Process(WaWorkerHost)% Processor Time
\Process(WaWorkerHost)\Private Bytes
\Memory\Page Faults/sec
.NET CLR Memory(Global)% Time in GC
\LogicalDisk(C:)\Disk Write Bytes/sec
\LogicalDisk(C:)\Disk Read Bytes/sec
\LogicalDisk(D:)\Disk Write Bytes/sec
\LogicalDisk(D:)\Disk Read Bytes/sec
If the configuration is set correctly but you still can't see the metric data, use the following guidelines to help you
troubleshoot.
Azure Diagnostics is not starting

For information about why Azure Diagnostics failed to start, see the DiagnosticsPluginLauncher.log and
DiagnosticsPlugin.log files in the log files location that was provided earlier.
If these logs indicate Monitoring Agent not reporting success after launch , it means there was a failure launching
MonAgentHost.exe. Look at the logs in the location that's indicated for MonAgentHost log file in the previous
section.
The last line of the log files contains the exit code.
DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0
If you find a negative exit code, refer to the exit code table in the References section.
Diagnostics data is not logged to Azure Storage

Determine if none of the data is appearing or some of the data is appearing.
Diagnostics infrastructure logs
Diagnostics logs all errors in the Diagnostics infrastructure logs. Make sure you have enabled the capture of
Diagnostics infrastructure logs in your configuration. Then you can quickly look for any relevant errors that appear
in the DiagnosticInfrastructureLogsTable table in your configured storage account.
No data is appearing
The most common reason that event data doesn't appear at all is that the storage account information is defined
incorrectly.
Solution: Correct your Diagnostics configuration and reinstall Diagnostics.
If the storage account is configured correctly, remote access into the machine and verify that DiagnosticsPlugin.exe
and MonAgentCore.exe are running. If they aren't running, follow the steps in Azure Diagnostics is not starting.
If the processes are running, go to Is data getting captured locally? and follow the instructions there.
If this doesn't solve the problem, try to:
1. Uninstall the agent
2. Remove directory C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics
3. Install agent again
Part of the data is missing
If you are getting some data but not all, it means that the data collection/transfer pipeline is set correctly. Follow the
subsections here to narrow down the issue.
Is the collection configured?
The Diagnostics configuration contains instructions for a particular type of data to be collected. Review your
configuration to verify that you are only looking for data that you've configured for the collection.
Is the host generating data?
Performance counters: Open perfmon and check the counter.
Trace logs: Remote access into the VM and add a TextWriterTraceListener to the app’s config file. See
https://msdn.microsoft.com/library/sk36c28t.aspx to set up the text listener. Make sure the <trace> element
has <trace autoflush="true"> .
If you don't see trace logs being generated, see More about trace logs missing.
ETW traces: Remote access into the VM and install PerfView. In PerfView, run File > User Command >
Listen etwprovder1 > etwprovider2, and so on. The Listen command is case-sensitive, and there cannot
be spaces between the comma-separated list of ETW providers. If the command fails to run, you can select
the Log button in the bottom right of the Perfview tool to see what attempted to run and what the result
was. Assuming the input is correct, a new window pops up. In a few seconds, you begin seeing ETW traces.
Event logs: Remote access into the VM. Open Event Viewer , and then ensure that the events exist.
Is data getting captured locally?
Next, make sure the data is getting captured locally. The data is locally stored in *.tsf files in the local store for
diagnostics data. Different kinds of logs get collected in different .tsf files. The names are similar to the table
names in Azure Storage.
For example, Performance Countersget collected in PerformanceCountersTable.tsf . Event logs get collected in
WindowsEventLogsTable.tsf . Use the instructions in the Local log extraction section to open the local collection files
and verify that you see them getting collected on disk.
If you don't see logs getting collected locally, and have already verified that the host is generating data, you likely
have a configuration issue. Review your configuration carefully.
Also review the configuration that was generated for MonitoringAgent MaConfig.xml. Verify that there is a section
that describes the relevant log source. Then verify that it is not lost in translation between the Diagnostics
configuration and the monitoring agent configuration.
Is data getting transferred?
If you have verified that the data is getting captured locally but you still don't see it in your storage account, take
the following steps:
Verify that you have provided a correct storage account, and that you haven't rolled over keys for the given
storage account. For Azure Cloud Services, sometimes we see that people don't update
useDevelopmentStorage=true .
Verify that the provided storage account is correct. Make sure you don't have network restrictions that
prevent the components from reaching public storage endpoints. One way to do that is to remote access
into the machine, and then try to write something to the same storage account yourself.
Finally, you can look at what failures are being reported by the monitoring Agent. The monitoring agent
writes its logs in maeventtable.tsf , which is located in the local store for diagnostics data. Follow the
instructions in the Local log extraction section for opening this file. Then try to determine if there are
errors that indicate failures reading to local files writing to storage.
Capturing and archiving logs

If you are thinking about contacting support, the first thing they might ask you is to collect logs from your machine.
You can save time by doing that yourself. Run the CollectGuestLogs.exe utility at Log collection utility path. It
generates a .zip file with all relevant Azure logs in the same folder.
Diagnostics data tables not found
The tables in Azure storage that hold ETW events are named by using the following code:
if (String.IsNullOrEmpty(eventDestination)) {
if (e == "DefaultEvents")
tableName = "WADDefault" + MD5(provider);
else
tableName = "WADEvent" + MD5(provider) + eventId;
}
else
tableName = "WAD" + eventDestination;
Here is an example:
<EtwEventSourceProviderConfiguration provider="prov1">
<Event id="1" />
<Event id="2" eventDestination="dest1" />
<DefaultEvents />
<EtwEventSourceProviderConfiguration provider="prov2">
<DefaultEvents eventDestination="dest2" />
{
"provider": "prov1",
"Event": [
{
"id": 1
},
{
"id": 2,
"eventDestination": "dest1"
}
],
"DefaultEvents": {
"eventDestination": "DefaultEventDestination",
"sinks": ""
}
},
{
"provider": "prov2",
"DefaultEvents": {
"eventDestination": "dest2"
}
}
]
This code generates four tables:
EVENT TABLE NAME
provider=”prov1” <Event id=”1” /> WADEvent+MD5(“prov1”)+”1”
provider=”prov1” <Event id=”2” eventDestination=”dest1” /> WADdest1
provider=”prov1” <DefaultEvents /> WADDefault+MD5(“prov1”)

EVENT TABLE NAME
provider=”prov2” <DefaultEvents eventDestination=”dest2” WADdest2

/>
References
How to check Diagnostics extension configuration
The easiest way to check your extension configuration is to go to Azure Resource Explorer, and then go to the
virtual machine or cloud service where the Azure Diagnostics extension (IaaSDiagnostics / PaaDiagnostics) is.
Alternatively, remote desktop into the machine and look at the Azure Diagnostics Configuration file that's
described in the Log artifacts path section.
In either case, search for Microsoft.Azure.Diagnostics, and then for the xmlCfg or WadCfg field.
If you're searching on a virtual machine and the WadCfg field is present, it means the config is in JSON format. If
the xmlCfg field is present, it means the config is in XML and is base64-encoded. You need to decode it to see the
XML that was loaded by Diagnostics.
For the cloud service role, if you pick the configuration from disk, the data is base64-encoded, so you need to
decode it to see the XML that was loaded by Diagnostics.
Azure Diagnostics plugin exit codes
The plugin returns the following exit codes:
EXIT CODE DESCRIPTION
0 Success.
-1 Generic error.
-2 Unable to load the rcf file.

This internal error should only happen if the guest agent
plugin launcher is manually invoked incorrectly on the VM.
-3 Cannot load the Diagnostics configuration file.

Solution: Caused by a configuration file not passing
schema validation. The solution is to provide a
configuration file that complies with the schema.
-4 Another instance of the monitoring agent Diagnostics is

already using the local resource directory.
Solution: Specify a different value for
LocalResourceDirectory.
-6 The guest agent plugin launcher attempted to launch

Diagnostics with an invalid command line.
-10 The Diagnostics plugin exited with an unhandled exception.

-11 The guest agent was unable to create the process responsible
for launching and monitoring the monitoring agent.
Solution: Verify that sufficient system resources are
available to launch new processes.
-101 Invalid arguments when calling the Diagnostics plugin.

-102 The plugin process is unable to initialize itself.

-103 The plugin process is unable to initialize itself. Specifically, it is

unable to create the logger object.
-104 Unable to load the rcf file provided by the guest agent.
-105 The Diagnostics plugin cannot open the Diagnostics

configuration file.
This internal error should only happen if the Diagnostics
plugin is manually invoked incorrectly on the VM.
-106 Cannot read the Diagnostics configuration file.

Caused by a configuration file not passing schema
validation.
Solution: Provide a configuration file that complies with

the schema. For more information, see How to check
Diagnostics Extension Configuration.
-107 The resource directory pass to the monitoring agent is invalid.

This internal error should only happen if the monitoring
agent is manually invoked incorrectly on the VM.
-108 Unable to convert the Diagnostics configuration file into the

monitoring agent configuration file.
plugin is manually invoked with an invalid configuration
file.
-110 General Diagnostics configuration error.

plugin is manually invoked with an invalid configuration
file.
-111 Unable to start the monitoring agent.

available.
-112 General error
Local log extraction

The monitoring agent collects logs and artifacts as .tsf files. The .tsf file is not readable but you can convert it
into a .csv as follows:
<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf
A new file called <relevantLogFile>.csv is created in the same path as the corresponding .tsf file.
NOTE
You only need to run this utility against the main .tsf file (for example, PerformanceCountersTable.tsf). The accompanying files
(for example, PerformanceCountersTables_**001.tsf, PerformanceCountersTables_**002.tsf, and so on) are automatically
processed.
More about missing trace logs
NOTE
The following information applies mostly to Azure Cloud Services unless you have configured the
DiagnosticsMonitorTraceListener on an application that's running on your IaaS VM.
Make sure the DiagnosticMonitorTraceListener is configured in the web.config or app.config. This is

configured by default in cloud service projects. However, some customers comment it out, which causes the
trace statements to not be collected by diagnostics.
If logs are not getting written from the OnStart or Run method, make sure the
DiagnosticMonitorTraceListener is in the app.config. By default it is in the web.config, but that only
applies to code running within w3wp.exe. So you need it in app.config to capture traces that are running in
WaIISHost.exe.
Make sure you are using Diagnostics.Trace.TraceXXX instead of Diagnostics.Debug.WriteXXX. The
Debug statements are removed from a release build.
Make sure the compiled code actually has the Diagnostics.Trace lines (use Reflector, ildasm, or ILSpy to
verify). Diagnostics.Trace commands are removed from the compiled binary unless you use the TRACE
conditional compilation symbol. This is a common problem that occurs when you're using msbuild to build a
project.
Known issues and mitigations
Here is a list of known issues with known mitigations:
1. .NET 4.5 dependency
Windows Azure Diagnostics Extension has a runtime dependency on .NET 4.5 framework or later. At the time of
writing, all machines that are provisioned for Azure Cloud Services, as well as all official images that are based on
Azure virtual machines, have .NET 4.5 or later installed.
It is still possible encounter a situation where you try to run Windows Azure Diagnostics Extension on a machine
that doesn't have .NET 4.5 or later. This happens when you create your machine from an old image or snapshot, or
when you bring your own custom disk.
This generally manifests as an exit code 255 when running DiagnosticsPluginLauncher.exe. Failure happens
due to the following unhandled exception:
System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0,

Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
Mitigation: Install .NET 4.5 or later on your machine.

2. Performance counters data is available in storage but not showing in the portal
The portal experience in the virtual machines shows certain performance counters by default. If you don't see the
performance counters, and you know that the data is getting generated because it is available in storage, check the
following:
Whether the data in storage has counter names in English. If the counter names are not in English, the
portal metric chart won't able to recognize it. Mitigation: Change the machine's language to English for
system accounts. To do this, select Control Panel > Region > Administrative > Copy Settings. Next,
deselect Welcome screen and system accounts so that the custom language is not applied to the system
account.
If you are using wildcards (*) in your performance counter names, the portal won't able to correlate the
configured and collected counter when the performance counters are sent to the Azure Storage sink.
Mitigation: To make sure you can use wildcards and have the portal expand the (*), route your performance
counters to the "Azure Monitor" sink.
Use Linux Diagnostic Extension to monitor metrics
and logs
This document describes version 3.0 and newer of the Linux Diagnostic Extension.
IMPORTANT
For information about version 2.3 and older, see this document.
Introduction
The Linux Diagnostic Extension helps a user monitor the health of a Linux VM running on Microsoft Azure. It has
the following capabilities:
Collects system performance metrics from the VM and stores them in a specific table in a designated storage
account.
Retrieves log events from syslog and stores them in a specific table in the designated storage account.
Enables users to customize the data metrics that are collected and uploaded.
Enables users to customize the syslog facilities and severity levels of events that are collected and uploaded.
Enables users to upload specified log files to a designated storage table.
Supports sending metrics and log events to arbitrary EventHub endpoints and JSON -formatted blobs in the
designated storage account.
This extension works with both Azure deployment models.
Installing the extension in your VM

You can enable this extension by using the Azure PowerShell cmdlets, Azure CLI scripts, ARM templates, or the
Azure portal. For more information, see Extensions Features.
These installation instructions and a downloadable sample configuration configure LAD 3.0 to:
capture and store the same metrics as were provided by LAD 2.3;
capture a useful set of file system metrics, new to LAD 3.0;
capture the default syslog collection enabled by LAD 2.3;
enable the Azure portal experience for charting and alerting on VM metrics.
The downloadable configuration is just an example; modify it to suit your own needs.
Prerequisites
Azure Linux Agent version 2.2.0 or later. Most Azure VM Linux gallery images include version 2.2.7 or later.
Run /usr/sbin/waagent -version to confirm the version installed on the VM. If the VM is running an older
version of the guest agent, follow these instructions to update it.
Azure CLI. Set up the Azure CLI environment on your machine.
The wget command, if you don't already have it: Run sudo apt-get install wget .
An existing Azure subscription and an existing storage account within it to store the data.
List of supported Linux distributions is on https://github.com/Azure/azure-linux-
extensions/tree/master/Diagnostic#supported-linux-distributions
Sample installation
Fill in the correct values for the variables in the first section before running:
# Set your Azure VM diagnostic variables correctly below

my_resource_group=<your_azure_resource_group_name_containing_your_azure_linux_vm>
my_linux_vm=<your_azure_linux_vm_name>
my_diagnostic_storage_account=<your_azure_storage_account_for_storing_vm_diagnostic_data>
# Should login to Azure first before anything else

az login
# Select the subscription containing the storage account

az account set --subscription <your_azure_subscription_id>
# Download the sample Public settings. (You could also use curl or any web browser)
wget https://raw.githubusercontent.com/Azure/azure-linux-
extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json -O portal_public_settings.json
# Build the VM resource ID. Replace storage account name and resource ID in the public settings.
my_vm_resource_id=$(az vm show -g $my_resource_group -n $my_linux_vm --query "id" -o tsv)
sed -i "s#__DIAGNOSTIC_STORAGE_ACCOUNT__#$my_diagnostic_storage_account#g" portal_public_settings.json
sed -i "s#__VM_RESOURCE_ID__#$my_vm_resource_id#g" portal_public_settings.json
# Build the protected settings (storage account SAS token)

my_diagnostic_storage_account_sastoken=$(az storage account generate-sas --account-name
$my_diagnostic_storage_account --expiry 2037-12-31T23:59:00Z --permissions wlacu --resource-types co --
services bt -o tsv)
my_lad_protected_settings="{'storageAccountName': '$my_diagnostic_storage_account', 'storageAccountSasToken':
'$my_diagnostic_storage_account_sastoken'}"
# Finallly tell Azure to install and enable the extension

az vm extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic --version 3.0 --resource-
group $my_resource_group --vm-name $my_linux_vm --protected-settings "${my_lad_protected_settings}" --settings
portal_public_settings.json
The URL for the sample configuration, and its contents, are subject to change. Download a copy of the portal
settings JSON file and customize it for your needs. Any templates or automation you construct should use your
own copy, rather than downloading that URL each time.
Updating the extension settings
After you've changed your Protected or Public settings, deploy them to the VM by running the same command. If
anything changed in the settings, the updated settings are sent to the extension. LAD reloads the configuration and
restarts itself.
Migration from previous versions of the extension
The latest version of the extension is 3.0. Any old versions (2.x) are deprecated and may be unpublished on
or after July 31, 2018.
IMPORTANT
This extension introduces breaking changes to the configuration of the extension. One such change was made to improve
the security of the extension; as a result, backwards compatibility with 2.x could not be maintained. Also, the Extension
Publisher for this extension is different than the publisher for the 2.x versions.
To migrate from 2.x to this new version of the extension, you must uninstall the old extension (under the old publisher
name), then install version 3 of the extension.
Recommendations:
Install the extension with automatic minor version upgrade enabled.
On classic deployment model VMs, specify '3.*' as the version if you are installing the extension through
Azure XPLAT CLI or Powershell.
On Azure Resource Manager deployment model VMs, include '"autoUpgradeMinorVersion": true' in the
VM deployment template.
Use a new/different storage account for LAD 3.0. There are several small incompatibilities between LAD 2.3
and LAD 3.0 that make sharing an account troublesome:
LAD 3.0 stores syslog events in a table with a different name.
The counterSpecifier strings for builtin metrics differ in LAD 3.0.
Protected settings
This set of configuration information contains sensitive information that should be protected from public view, for
example, storage credentials. These settings are transmitted to and stored by the extension in encrypted form.
{
"storageAccountName" : "the storage account to receive data",
"storageAccountEndPoint": "the hostname suffix for the cloud for this account",
"storageAccountSasToken": "SAS access token",
"mdsdHttpProxy": "HTTP proxy settings",
"sinksConfig": { ... }
}
NAME VALUE
storageAccountName The name of the storage account in which data is written by

the extension.
storageAccountEndPoint (optional) The endpoint identifying the cloud in which the

storage account exists. If this setting is absent, LAD defaults
to the Azure public cloud, https://core.windows.net . To
use a storage account in Azure Germany, Azure Government,
or Azure China, set this value accordingly.
storageAccountSasToken An Account SAS token for Blob and Table services ( ss='bt' ),
applicable to containers and objects ( srt='co' ), which
grants add, create, list, update, and write permissions (
sp='acluw' ). Do not include the leading question-mark (?).
mdsdHttpProxy (optional) HTTP proxy information needed to enable the

extension to connect to the specified storage account and
endpoint.
sinksConfig (optional) Details of alternative destinations to which metrics

and events can be delivered. The specific details of each data
sink supported by the extension are covered in the sections
that follow.
To get a SAS token within a Resource Manager template, use the listAccountSas function. For an example
template, see List function example.
You can easily construct the required SAS token through the Azure portal.
1. Select the general-purpose storage account to which you want the extension to write
2. Select "Shared access signature" from the Settings part of the left menu
3. Make the appropriate sections as previously described
4. Click the "Generate SAS" button.
Copy the generated SAS into the storageAccountSasToken field; remove the leading question-mark ("?").
sinksConfig
"sinksConfig": {
"sink": [
{
"name": "sinkname",
"type": "sinktype",
...
},
...
]
},
This optional section defines additional destinations to which the extension sends the information it collects. The
"sink" array contains an object for each additional data sink. The "type" attribute determines the other attributes in
the object.
ELEMENT VALUE
ELEMENT VALUE
name A string used to refer to this sink elsewhere in the extension

configuration.
type The type of sink being defined. Determines the other values (if
any) in instances of this type.
Version 3.0 of the Linux Diagnostic Extension supports two sink types: EventHub, and JsonBlob.
The EventHub sink
"sink": [
{
"name": "sinkname",
"type": "EventHub",
"sasURL": "https SAS URL"
},
...
]
The "sasURL" entry contains the full URL, including SAS token, for the Event Hub to which data should be
published. LAD requires a SAS naming a policy that enables the Send claim. An example:
Create an Event Hubs namespace called contosohub
Create an Event Hub in the namespace called syslogmsgs
Create a Shared access policy on the Event Hub named writer that enables the Send claim
If you created a SAS good until midnight UTC on January 1, 2018, the sasURL value might be:
https://contosohub.servicebus.windows.net/syslogmsgs?
sr=contosohub.servicebus.windows.net%2fsyslogmsgs&sig=xxxxxxxxxxxxxxxxxxxxxxxxx&se=1514764800&skn=writer
For more information about generating SAS tokens for Event Hubs, see this web page.
The JsonBlob sink
"sink": [
{
"name": "sinkname",
"type": "JsonBlob"
},
...
]
Data directed to a JsonBlob sink is stored in blobs in Azure storage. Each instance of LAD creates a blob every
hour for each sink name. Each blob always contains a syntactically valid JSON array of object. New entries are
atomically added to the array. Blobs are stored in a container with the same name as the sink. The Azure storage
rules for blob container names apply to the names of JsonBlob sinks: between 3 and 63 lower-case alphanumeric
ASCII characters or dashes.
Public settings
This structure contains various blocks of settings that control the information collected by the extension. Each
setting is optional. If you specify ladCfg , you must also specify StorageAccount .
{
"ladCfg": { ... },
"perfCfg": { ... },
"fileLogs": { ... },
"StorageAccount": "the storage account to receive data",
"mdsdHttpProxy" : ""
}
ELEMENT VALUE
StorageAccount The name of the storage account in which data is written by

the extension. Must be the same name as is specified in the
Protected settings.
mdsdHttpProxy (optional) Same as in the Protected settings. The public value

is overridden by the private value, if set. Place proxy settings
that contain a secret, such as a password, in the Protected
settings.
The remaining elements are described in detail in the following sections.

ladCfg
"ladCfg": {
"diagnosticMonitorConfiguration": {
"eventVolume": "Medium",
"metrics": { ... },
"performanceCounters": { ... },
"syslogEvents": { ... }
},
"sampleRateInSeconds": 15
}
This optional structure controls the gathering of metrics and logs for delivery to the Azure Metrics service and to
other data sinks. You must specify either performanceCounters or syslogEvents or both. You must specify the
metrics structure.
ELEMENT VALUE
eventVolume (optional) Controls the number of partitions created within

the storage table. Must be one of "Large" , "Medium" , or
"Small" . If not specified, the default value is "Medium" .
sampleRateInSeconds (optional) The default interval between collection of raw

(unaggregated) metrics. The smallest supported sample rate is
15 seconds. If not specified, the default value is 15 .
metrics
"metrics": {
"resourceId": "/subscriptions/...",
"metricAggregation" : [
{ "scheduledTransferPeriod" : "PT1H" },
{ "scheduledTransferPeriod" : "PT5M" }
]
}
ELEMENT VALUE
resourceId The Azure Resource Manager resource ID of the VM or of the

virtual machine scale set to which the VM belongs. This
setting must be also specified if any JsonBlob sink is used in
the configuration.
scheduledTransferPeriod The frequency at which aggregate metrics are to be computed

and transferred to Azure Metrics, expressed as an IS 8601
time interval. The smallest transfer period is 60 seconds, that
is, PT1M. You must specify at least one
scheduledTransferPeriod.
Samples of the metrics specified in the performanceCounters section are collected every 15 seconds or at the
sample rate explicitly defined for the counter. If multiple scheduledTransferPeriod frequencies appear (as in the
example), each aggregation is computed independently.
performanceCounters
"performanceCounters": {
"sinks": "",
"performanceCounterConfiguration": [
{
"type": "builtin",
"class": "Processor",
"counter": "PercentIdleTime",
"counterSpecifier": "/builtin/Processor/PercentIdleTime",
"condition": "IsAggregate=TRUE",
"sampleRate": "PT15S",
"unit": "Percent",
"annotation": [
{
"displayName" : "Aggregate CPU %idle time",
"locale" : "en-us"
}
]
}
]
}
This optional section controls the collection of metrics. Raw samples are aggregated for each
scheduledTransferPeriod to produce these values:
mean
minimum
maximum
last-collected value
count of raw samples used to compute the aggregate
ELEMENT VALUE
sinks (optional) A comma-separated list of names of sinks to which

LAD sends aggregated metric results. All aggregated metrics
are published to each listed sink. See sinksConfig. Example:
"EHsink1, myjsonsink" .
type Identifies the actual provider of the metric.

ELEMENT VALUE
class Together with "counter", identifies the specific metric within

the provider's namespace.
counter Together with "class", identifies the specific metric within the
provider's namespace.
counterSpecifier Identifies the specific metric within the Azure Metrics

namespace.
condition (optional) Selects a specific instance of the object to which the

metric applies or selects the aggregation across all instances of
that object. For more information, see the builtin metric
definitions.
sampleRate IS 8601 interval that sets the rate at which raw samples for
this metric are collected. If not set, the collection interval is set
by the value of sampleRateInSeconds. The shortest supported
sample rate is 15 seconds (PT15S).
unit Should be one of these strings: "Count", "Bytes", "Seconds",

"Percent", "CountPerSecond", "BytesPerSecond", "Millisecond".
Defines the unit for the metric. Consumers of the collected
data expect the collected data values to match this unit. LAD
ignores this field.
displayName The label (in the language specified by the associated locale
setting) to be attached to this data in Azure Metrics. LAD
ignores this field.
The counterSpecifier is an arbitrary identifier. Consumers of metrics, like the Azure portal charting and alerting
feature, use counterSpecifier as the "key" that identifies a metric or an instance of a metric. For builtin metrics,
we recommend you use counterSpecifier values that begin with /builtin/ . If you are collecting a specific instance
of a metric, we recommend you attach the identifier of the instance to the counterSpecifier value. Some examples:
/builtin/Processor/PercentIdleTime - Idle time averaged across all vCPUs
/builtin/Disk/FreeSpace(/mnt) - Free space for the /mnt filesystem
/builtin/Disk/FreeSpace - Free space averaged across all mounted filesystems
Neither LAD nor the Azure portal expects the counterSpecifier value to match any pattern. Be consistent in how
you construct counterSpecifier values.
When you specify performanceCounters , LAD always writes data to a table in Azure storage. You can have the same
data written to JSON blobs and/or Event Hubs, but you cannot disable storing data to a table. All instances of the
diagnostic extension configured to use the same storage account name and endpoint add their metrics and logs to
the same table. If too many VMs are writing to the same table partition, Azure can throttle writes to that partition.
The eventVolume setting causes entries to be spread across 1 (Small), 10 (Medium), or 100 (Large) different
partitions. Usually, "Medium" is sufficient to ensure traffic is not throttled. The Azure Metrics feature of the Azure
portal uses the data in this table to produce graphs or to trigger alerts. The table name is the concatenation of
these strings:
WADMetrics
The "scheduledTransferPeriod" for the aggregated values stored in the table
P10DV2S
A date, in the form "YYYYMMDD", which changes every 10 days
Examples include WADMetricsPT1HP10DV2S20170410 and WADMetricsPT1MP10DV2S20170609 .
syslogEvents
"syslogEvents": {
"sinks": "",
"syslogEventConfiguration": {
"facilityName1": "minSeverity",
"facilityName2": "minSeverity",
...
}
}
This optional section controls the collection of log events from syslog. If the section is omitted, syslog events are
not captured at all.
The syslogEventConfiguration collection has one entry for each syslog facility of interest. If minSeverity is "NONE"
for a particular facility, or if that facility does not appear in the element at all, no events from that facility are
captured.
ELEMENT VALUE
sinks A comma-separated list of names of sinks to which individual

log events are published. All log events matching the
restrictions in syslogEventConfiguration are published to each
listed sink. Example: "EHforsyslog"
facilityName A syslog facility name (such as "LOG_USER" or

"LOG_LOCAL0"). See the "facility" section of the syslog man
page for the full list.
minSeverity A syslog severity level (such as "LOG_ERR" or "LOG_INFO").

See the "level" section of the syslog man page for the full list.
The extension captures events sent to the facility at or above
the specified level.
When you specify syslogEvents , LAD always writes data to a table in Azure storage. You can have the same data
written to JSON blobs and/or Event Hubs, but you cannot disable storing data to a table. The partitioning behavior
for this table is the same as described for performanceCounters . The table name is the concatenation of these
strings:
LinuxSyslog
A date, in the form "YYYYMMDD", which changes every 10 days
Examples include LinuxSyslog20170410 and LinuxSyslog20170609 .
perfCfg
This optional section controls execution of arbitrary OMI queries.
"perfCfg": [
{
"namespace": "root/scx",
"query": "SELECT PercentAvailableMemory, PercentUsedSwap FROM SCX_MemoryStatisticalInformation",
"table": "LinuxOldMemory",
"frequency": 300,
"sinks": ""
}
]
ELEMENT VALUE
namespace (optional) The OMI namespace within which the query should
be executed. If unspecified, the default value is "root/scx",
implemented by the System Center Cross-platform Providers.
query The OMI query to be executed.
table (optional) The Azure storage table, in the designated storage

account (see Protected settings).
frequency (optional) The number of seconds between execution of the

query. Default value is 300 (5 minutes); minimum value is 15
seconds.
sinks (optional) A comma-separated list of names of additional sinks

to which raw sample metric results should be published. No
aggregation of these raw samples is computed by the
extension or by Azure Metrics.
Either "table" or "sinks", or both, must be specified.

fileLogs
Controls the capture of log files. LAD captures new text lines as they are written to the file and writes them to table
rows and/or any specified sinks (JsonBlob or EventHub).
"fileLogs": [
{
"file": "/var/log/mydaemonlog",
"table": "MyDaemonEvents",
"sinks": ""
}
]
ELEMENT VALUE
file The full pathname of the log file to be watched and captured.
The pathname must name a single file; it cannot name a
directory or contain wildcards.
table (optional) The Azure storage table, in the designated storage

account (as specified in the protected configuration), into
which new lines from the "tail" of the file are written.
sinks (optional) A comma-separated list of names of additional sinks

to which log lines sent.
Either "table" or "sinks", or both, must be specified.
Metrics supported by the builtin provider

The builtin metric provider is a source of metrics most interesting to a broad set of users. These metrics fall into
five broad classes:
Processor
Memory
Network
Filesystem
Disk
builtin metrics for the Processor class
The Processor class of metrics provides information about processor usage in the VM. When aggregating
percentages, the result is the average across all CPUs. In a two-vCPU VM, if one vCPU was 100% busy and the
other was 100% idle, the reported PercentIdleTime would be 50. If each vCPU was 50% busy for the same period,
the reported result would also be 50. In a four-vCPU VM, with one vCPU 100% busy and the others idle, the
reported PercentIdleTime would be 75.
COUNTER MEANING
PercentIdleTime Percentage of time during the aggregation window that

processors were executing the kernel idle loop
PercentProcessorTime Percentage of time executing a non-idle thread
PercentIOWaitTime Percentage of time waiting for IO operations to complete
PercentInterruptTime Percentage of time executing hardware/software interrupts

and DPCs (deferred procedure calls)
PercentUserTime Of non-idle time during the aggregation window, the

percentage of time spent in user more at normal priority
PercentNiceTime Of non-idle time, the percentage spent at lowered (nice)

priority
PercentPrivilegedTime Of non-idle time, the percentage spent in privileged (kernel)

mode
The first four counters should sum to 100%. The last three counters also sum to 100%; they subdivide the sum of
PercentProcessorTime, PercentIOWaitTime, and PercentInterruptTime.
To obtain a single metric aggregated across all processors, set "condition": "IsAggregate=TRUE" . To obtain a metric
for a specific processor, such as the second logical processor of a four-vCPU VM, set "condition": "Name=\\"1\\"" .
Logical processor numbers are in the range [0..n-1] .
builtin metrics for the Memory class
The Memory class of metrics provides information about memory utilization, paging, and swapping.
COUNTER MEANING
AvailableMemory Available physical memory in MiB
PercentAvailableMemory Available physical memory as a percent of total memory
UsedMemory In-use physical memory (MiB)
PercentUsedMemory In-use physical memory as a percent of total memory
PagesPerSec Total paging (read/write)

COUNTER MEANING
PagesReadPerSec Pages read from backing store (swap file, program file,
mapped file, etc.)
PagesWrittenPerSec Pages written to backing store (swap file, mapped file, etc.)
AvailableSwap Unused swap space (MiB)
PercentAvailableSwap Unused swap space as a percentage of total swap
UsedSwap In-use swap space (MiB)
PercentUsedSwap In-use swap space as a percentage of total swap
This class of metrics has only a single instance. The "condition" attribute has no useful settings and should be
omitted.
builtin metrics for the Network class
The Network class of metrics provides information about network activity on an individual network interfaces since
boot. LAD does not expose bandwidth metrics, which can be retrieved from host metrics.
COUNTER MEANING
BytesTransmitted Total bytes sent since boot
BytesReceived Total bytes received since boot
BytesTotal Total bytes sent or received since boot
PacketsTransmitted Total packets sent since boot
PacketsReceived Total packets received since boot
TotalRxErrors Number of receive errors since boot
TotalTxErrors Number of transmit errors since boot
TotalCollisions Number of collisions reported by the network ports since

boot
Although this class is instanced, LAD does not support capturing Network metrics aggregated across all network
devices. To obtain the metrics for a specific interface, such as eth0, set "condition": "InstanceID=\\"eth0\\"" .
builtin metrics for the Filesystem class
The Filesystem class of metrics provides information about filesystem usage. Absolute and percentage values are
reported as they'd be displayed to an ordinary user (not root).
COUNTER MEANING
FreeSpace Available disk space in bytes
UsedSpace Used disk space in bytes

COUNTER MEANING
PercentFreeSpace Percentage free space
PercentUsedSpace Percentage used space
PercentFreeInodes Percentage of unused inodes
PercentUsedInodes Percentage of allocated (in use) inodes summed across all

filesystems
BytesReadPerSecond Bytes read per second
BytesWrittenPerSecond Bytes written per second
BytesPerSecond Bytes read or written per second
ReadsPerSecond Read operations per second
WritesPerSecond Write operations per second
TransfersPerSecond Read or write operations per second
Aggregated values across all file systems can be obtained by setting "condition": "IsAggregate=True" . Values for a
specific mounted file system, such as "/mnt", can be obtained by setting "condition": 'Name="/mnt"' .
NOTE: If using the Azure Portal instead of JSON, the correct condition field form is Name='/mnt'
builtin metrics for the Disk class
The Disk class of metrics provides information about disk device usage. These statistics apply to the entire drive. If
there are multiple file systems on a device, the counters for that device are, effectively, aggregated across all of
them.
COUNTER MEANING
ReadsPerSecond Read operations per second
WritesPerSecond Write operations per second
TransfersPerSecond Total operations per second
AverageReadTime Average seconds per read operation
AverageWriteTime Average seconds per write operation
AverageTransferTime Average seconds per operation
AverageDiskQueueLength Average number of queued disk operations
ReadBytesPerSecond Number of bytes read per second
WriteBytesPerSecond Number of bytes written per second

COUNTER MEANING
BytesPerSecond Number of bytes read or written per second
Aggregated values across all disks can be obtained by setting "condition": "IsAggregate=True" . To get information
for a specific device (for example, /dev/sdf1), set "condition": "Name=\\"/dev/sdf1\\"" .
Installing and configuring LAD 3.0 via CLI

Assuming your protected settings are in the file PrivateConfig.json and your public configuration information is in
PublicConfig.json, run this command:
az vm extension set *resource_group_name* *vm_name* LinuxDiagnostic Microsoft.Azure.Diagnostics '3.*' --

private-config-path PrivateConfig.json --public-config-path PublicConfig.json
The command assumes you are using the Azure Resource Management mode (arm) of the Azure CLI. To configure
LAD for classic deployment model (ASM ) VMs, switch to "asm" mode ( azure config mode asm ) and omit the
resource group name in the command. For more information, see the cross-platform CLI documentation.
An example LAD 3.0 configuration

Based on the preceding definitions, here's a sample LAD 3.0 extension configuration with some explanation. To
apply this sample to your case, you should use your own storage account name, account SAS token, and
EventHubs SAS tokens.
PrivateConfig.json
These private settings configure:
a storage account
a matching account SAS token
several sinks (JsonBlob or EventHubs with SAS tokens)
{
"storageAccountName": "yourdiagstgacct",
"storageAccountSasToken": "sv=xxxx-xx-xx&ss=bt&srt=co&sp=wlacu&st=yyyy-yy-yyT21%3A22%3A00Z&se=zzzz-zz-
zzT21%3A22%3A00Z&sig=fake_signature",
"sinksConfig": {
"sink": [
{
"name": "SyslogJsonBlob",
"type": "JsonBlob"
},
{
"name": "FilelogJsonBlob",
"type": "JsonBlob"
},
{
"name": "LinuxCpuJsonBlob",
"type": "JsonBlob"
},
{
"name": "MyJsonMetricsBlob",
"type": "JsonBlob"
},
{
"name": "LinuxCpuEventHub",
"type": "EventHub",
"sasURL": "https://youreventhubnamespace.servicebus.windows.net/youreventhubpublisher?
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=fake_signature&se
=1808096361&skn=yourehpolicy"
},
{
"name": "MyMetricEventHub",
"type": "EventHub",
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&skn=
yourehpolicy"
},
{
"name": "LoggingEventHub",
"type": "EventHub",
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&se=1
808096361&skn=yourehpolicy"
}
]
}
}
PublicConfig.json
These public settings cause LAD to:
Upload percent-processor-time and used-disk-space metrics to the WADMetrics* table
Upload messages from syslog facility "user" and severity "info" to the LinuxSyslog* table
Upload raw OMI query results (PercentProcessorTime and PercentIdleTime) to the named LinuxCPU table
Upload appended lines in file /var/log/myladtestlog to the MyLadTestLog table
In each case, data is also uploaded to:
Azure Blob storage (container name is as defined in the JsonBlob sink)
EventHubs endpoint (as specified in the EventHubs sink)
{
"StorageAccount": "yourdiagstgacct",
"sampleRateInSeconds": 15,
"sampleRateInSeconds": 15,
"ladCfg": {
"diagnosticMonitorConfiguration": {
"performanceCounters": {
"sinks": "MyMetricEventHub,MyJsonMetricsBlob",
"performanceCounterConfiguration": [
{
"unit": "Percent",
"type": "builtin",
"counter": "PercentProcessorTime",
"counterSpecifier": "/builtin/Processor/PercentProcessorTime",
"annotation": [
{
"locale": "en-us",
"displayName": "Aggregate CPU %utilization"
}
],
"condition": "IsAggregate=TRUE",
"class": "Processor"
},
{
"unit": "Bytes",
"type": "builtin",
"counter": "UsedSpace",
"counterSpecifier": "/builtin/FileSystem/UsedSpace",
"annotation": [
{
"locale": "en-us",
"displayName": "Used disk space on /"
}
],
"condition": "Name=\"/\"",
"class": "Filesystem"
}
]
},
"metrics": {
"metricAggregation": [
{
"scheduledTransferPeriod": "PT1H"
},
{
"scheduledTransferPeriod": "PT1M"
}
],
"resourceId":
"/subscriptions/your_azure_subscription_id/resourceGroups/your_resource_group_name/providers/Microsoft.Compute
/virtualMachines/your_vm_name"
},
"eventVolume": "Large",
"syslogEvents": {
"sinks": "SyslogJsonBlob,LoggingEventHub",
"syslogEventConfiguration": {
"LOG_USER": "LOG_INFO"
}
}
}
},
"perfCfg": [
{
"query": "SELECT PercentProcessorTime, PercentIdleTime FROM SCX_ProcessorStatisticalInformation WHERE
Name='_TOTAL'",
"table": "LinuxCpu",
"frequency": 60,
"sinks": "LinuxCpuJsonBlob,LinuxCpuEventHub"
}
],
"fileLogs": [
{
"file": "/var/log/myladtestlog",
"file": "/var/log/myladtestlog",
"table": "MyLadTestLog",
"sinks": "FilelogJsonBlob,LoggingEventHub"
}
]
}
The resourceId in the configuration must match that of the VM or the virtual machine scale set.
Azure platform metrics charting and alerting knows the resourceId of the VM you're working on. It expects to
find the data for your VM using the resourceId the lookup key.
If you use Azure autoscale, the resourceId in the autoscale configuration must match the resourceId used by
LAD.
The resourceId is built into the names of JsonBlobs written by LAD.
View your data

Use the Azure portal to view performance data or set alerts:
The performanceCounters data are always stored in an Azure Storage table. Azure Storage APIs are available for
many languages and platforms.
Data sent to JsonBlob sinks is stored in blobs in the storage account named in the Protected settings. You can
consume the blob data using any Azure Blob Storage APIs.
In addition, you can use these UI tools to access the data in Azure Storage:
Visual Studio Server Explorer.
Microsoft Azure Storage Explorer.
This snapshot of a Microsoft Azure Storage Explorer session shows the generated Azure Storage tables and
containers from a correctly configured LAD 3.0 extension on a test VM. The image doesn't match exactly with the
sample LAD 3.0 configuration.
See the relevant EventHubs documentation to learn how to consume messages published to an EventHubs
endpoint.
Next steps
Create metric alerts in Azure Monitor for the metrics you collect.
Create monitoring charts for your metrics.
Learn how to create a virtual machine scale set using your metrics to control autoscaling.
Collect custom metrics for a Linux VM with the
InfluxData Telegraf agent
By using Azure Monitor, you can collect custom metrics via your application telemetry, an agent running on your
Azure resources, or even outside-in monitoring systems. Then you can submit them directly to Azure Monitor.
This article provides instructions on how to deploy the InfluxData Telegraf agent on a Linux VM in Azure and
configure the agent to publish metrics to Azure Monitor.
InfluxData Telegraf agent

Telegraf is a plug-in-driven agent that enables the collection of metrics from over 150 different sources.
Depending on what workloads run on your VM, you can configure the agent to leverage specialized input plug-ins
to collect metrics. Examples are MySQL, NGINX, and Apache. By using output plug-ins, the agent can then write
to destinations that you choose. The Telegraf agent has integrated directly with the Azure Monitor custom metrics
REST API. It supports an Azure Monitor output plug-in. By using this plug-in, the agent can collect workload-
specific metrics on your Linux VM and submit them as custom metrics to Azure Monitor.
Send custom metrics

For this tutorial, we deploy a Linux VM that runs the Ubuntu 16.04 LTS operating system. The Telegraf agent is
supported for most Linux operating systems. Both Debian and RPM packages are available along with
unpackaged Linux binaries on the InfluxData download portal. See this Telegraf installation guide for additional
installation instructions and options.
Create a new Linux VM:
1. Select the Create a resource option from the left-hand navigation pane.
2. Search for Virtual Machine.
3. Select Ubuntu 16.04 LTS and select Create.
4. Provide a VM name like MyTelegrafVM.
5. Leave the disk type as SSD. Then provide a username, such as azureuser.
6. For Authentication type, select Password. Then enter a password you'll use later to SSH into this VM.
7. Choose to Create new resource group. Then provide a name, such as myResourceGroup. Choose your
Location. Then select OK.
8. Select a size for the VM. You can filter by Compute type or Disk type, for example.
9. On the Settings page in Network > Network Security Group > Select public inbound ports, select
HTTP and SSH (22). Leave the rest of the defaults and select OK.
10. On the summary page, select Create to start the VM deployment.
11. The VM is pinned to the Azure portal dashboard. After the deployment finishes, the VM summary
automatically opens.
12. In the VM pane, navigate to the Identity tab. Ensure that your VM has a system-assigned identity set to
On.
Connect to the VM
Create an SSH connection with the VM. Select the Connect button on the overview page for your VM.
In the Connect to virtual machine page, keep the default options to connect by DNS name over port 22. In
Login using VM local account, a connection command is shown. Select the button to copy the command. The
following example shows what the SSH connection command looks like:
ssh azureuser@XXXX.XX.XXX
Paste the SSH connection command into a shell, such as Azure Cloud Shell or Bash on Ubuntu on Windows, or
use an SSH client of your choice to create the connection.
Install and configure Telegraf

To install the Telegraf Debian package onto the VM, run the following commands from your SSH session:
# download the package to the VM
wget https://dl.influxdata.com/telegraf/releases/telegraf_1.8.0~rc1-1_amd64.deb
# install the package
sudo dpkg -i telegraf_1.8.0~rc1-1_amd64.deb
Telegraf’s configuration file defines Telegraf’s operations. By default, an example configuration file is installed at
the path /etc/telegraf/telegraf.conf. The example configuration file lists all possible input and output plug-ins.
However, we'll create a custom configuration file and have the agent use it by running the following commands:
# generate the new Telegraf config file in the current directory

telegraf --input-filter cpu:mem --output-filter azure_monitor config > azm-telegraf.conf
# replace the example config with the new generated config

sudo cp azm-telegraf.conf /etc/telegraf/telegraf.conf
NOTE
The preceding code enables only two input plug-ins: cpu and mem. You can add more input plug-ins, depending on the
workload that runs on your machine. Examples are Docker, MySQL, and NGINX. For a full list of input plug-ins, see the
Additional configuration section.
Finally, to have the agent start using the new configuration, we force the agent to stop and start by running the
following commands:
# stop the telegraf agent on the VM

sudo systemctl stop telegraf
# start the telegraf agent on the VM to ensure it picks up the latest configuration
sudo systemctl start telegraf
Now the agent will collect metrics from each of the input plug-ins specified and emit them to Azure Monitor.
Plot your Telegraf metrics in the Azure portal

1. Open the Azure portal.
2. Navigate to the new Monitor tab. Then select Metrics.
3. Select your VM in the resource selector.
4. Select the Telegraf/CPU namespace, and select the usage_system metric. You can choose to filter by the
dimensions on this metric or split on them.
Additional configuration
The preceding walkthrough provides information on how to configure the Telegraf agent to collect metrics from a
few basic input plug-ins. The Telegraf agent has support for over 150 input plug-ins, with some supporting
additional configuration options. InfluxData has published a list of supported plugins and instructions on how to
configure them.
Additionally, in this walkthrough, you used the Telegraf agent to emit metrics about the VM the agent is deployed
on. The Telegraf agent can also be used as a collector and forwarder of metrics for other resources. To learn how to
configure the agent to emit metrics for other Azure resources, see Azure Monitor Custom Metric Output for
Telegraf.
Clean up resources
When they're no longer needed, you can delete the resource group, virtual machine, and all related resources. To
do so, select the resource group for the virtual machine and select Delete. Then confirm the name of the resource
group to delete.
Next steps
Collect log data with the Log Analytics agent
The Azure Log Analytics agent, previously referred to as the Microsoft Monitoring Agent (MMA) or OMS Linux
agent, was developed for comprehensive management across on-premises machines, computers monitored by
System Center Operations Manager, and virtual machines in any cloud. The Windows and Linux agents attach to
an Azure Monitor and store collected log data from different sources in your Log Analytics workspace, as well as
any unique logs or metrics as defined in a monitoring solution.
This article provides a detailed overview of the agent, system and network requirements, and the different
deployment methods.
Overview
Before analyzing and acting on collected data, you first need to install and connect agents for all of the machines
that you want to send data to the Azure Monitor service. You can install agents on your Azure VMs using the
Azure Log Analytics VM extension for Windows and Linux, and for machines in a hybrid environment using
setup, command line, or with Desired State Configuration (DSC ) in Azure Automation.
The agent for Linux and Windows communicates outbound to the Azure Monitor service over TCP port 443, and
if the machine connects through a firewall or proxy server to communicate over the Internet, review requirements
below to understand the network configuration required. If your IT security policies do not allow computers on
the network to connect to the Internet, you can set up a Log Analytics gateway and then configure the agent to
connect through the gateway to Azure Monitor logs. The agent can then receive configuration information and
send data collected depending on what data collection rules and monitoring solutions you have enabled in your
workspace.
When using the Log Analytics agents to collect data, you need to understand the following in order to plan your
agent deployment:
To collect data from Windows agents, you can configure each agent to report to one or more workspaces, even
while it is reporting to a System Center Operations Manager management group. The Windows agent can
report up to four workspaces.
The Linux agent does not support multi-homing and can only report to a single workspace.
The Windows agent supports the FIPS 140 standard, while the Linux agent does not support it.
If you are using System Center Operations Manager 2012 R2 or later:
Each Operations Manager management group can be connected to only one workspace.
Linux computers reporting to a management group must be configured to report directly to a Log Analytics
workspace. If your Linux computers are already reporting directly to a workspace and you want to monitor
them with Operations Manager, follow these steps to report to an Operations Manager management group.
You can install the Log Analytics Windows agent on the Windows computer and have it report to both
Operations Manager integrated with a workspace, and a different workspace.
The agent for Linux and Windows isn't only for connecting to Azure Monitor, it also supports Azure Automation
to host the Hybrid Runbook worker role and other services such as Change Tracking, Update Management, and
Azure Security Center. For more information about the Hybrid Runbook Worker role, see Azure Automation
Hybrid Runbook Worker.
Supported Windows operating systems

The following versions of the Windows operating system are officially supported for the Windows agent:
Windows Server 2019
Windows Server 2008 R2, 2012, 2012 R2, 2016, version 1709 and 1803
Windows 7 SP1, Windows 8 Enterprise and Pro, and Windows 10 Enterprise and Pro
NOTE
While the Log Analytics agent for Windows was designed to support server monitoring scenarios, we realize you may run
Windows client to support workloads configured and optimized for the server operating system. The agent does support
Windows client, however our monitoring solutions don't focus on client monitoring scenarios unless explicitly stated.
Supported Linux operating systems

This section provides details about the supported Linux distributions.
Starting with versions released after August 2018, we are making the following changes to our support model:
Only the server versions are supported, not client.
New versions of Azure Linux Endorsed distros are always supported.
All minor releases are supported for each major version listed.
Versions that have passed their manufacturer's end-of-support date are not supported.
New versions of AMI are not supported.
Only versions that run SSL 1.x by default are supported.
NOTE
If you are using a distro or version that is not currently supported and doesn't align to our support model, we recommend
that you fork this repo, acknowledging that Microsoft support will not provide assistance with forked agent versions.
Amazon Linux 2017.09 (x64)

CentOS Linux 6 (x86/x64) and 7 (x64)
Oracle Linux 6 and 7 (x86/x64)
Red Hat Enterprise Linux Server 6 (x86/x64) and 7 (x64)
Debian GNU/Linux 8 and 9 (x86/x64)
Ubuntu 14.04 LTS (x86/x64), 16.04 LTS (x86/x64), and 18.04 LTS (x64)
SUSE Linux Enterprise Server 12 (x64) and 15 (x64)
NOTE
OpenSSL 1.1.0 is only supported on x86_x64 platforms (64-bit) and OpenSSL earlier than 1.x is not supported on any
platform.
Agent prerequisites
The following table highlights the packages required for supported Linux distros that the agent will be installed
on.
REQUIRED PACKAGE DESCRIPTION MINIMUM VERSION
Glibc GNU C Library 2.5-12
Openssl OpenSSL Libraries 1.0.x or 1.1.x
Curl cURL web client 7.15.5
Python-ctypes
PAM Pluggable Authentication Modules
NOTE
Either rsyslog or syslog-ng are required to collect syslog messages. The default syslog daemon on version 5 of Red Hat
Enterprise Linux, CentOS, and Oracle Linux version (sysklog) is not supported for syslog event collection. To collect syslog
data from this version of these distributions, the rsyslog daemon should be installed and configured to replace sysklog.
TLS 1.2 protocol

To insure the security of data in transit to Azure Monitor logs, we strongly encourage you to configure the agent
to use at least Transport Layer Security (TLS ) 1.2. Older versions of TLS/Secure Sockets Layer (SSL ) have been
found to be vulnerable and while they still currently work to allow backwards compatibility, they are not
recommended. For additional information, review Sending data securely using TLS 1.2.
Network firewall requirements

The information below list the proxy and firewall configuration information required for the Linux and Windows
agent to communicate with Azure Monitor logs.
AGENT RESOURCE PORTS DIRECTION BYPASS HTTPS INSPECTION
*.ods.opinsights.azure.com Port 443 Outbound Yes
*.oms.opinsights.azure.com Port 443 Outbound Yes
*.blob.core.windows.net Port 443 Outbound Yes
*.azure-automation.net Port 443 Outbound Yes

For firewall information required for Azure Government, see Azure Government management.
If you plan to use the Azure Automation Hybrid Runbook Worker to connect to and register with the Automation
service to use runbooks in your environment, it must have access to the port number and the URLs described in
Configure your network for the Hybrid Runbook Worker.
The Windows and Linux agent supports communicating either through a proxy server or Log Analytics gateway
to Azure Monitor using the HTTPS protocol. Both anonymous and basic authentication (username/password) are
supported. For the Windows agent connected directly to the service, the proxy configuration is specified during
installation or after deployment from Control Panel or with PowerShell.
For the Linux agent, the proxy server is specified during installation or after installation by modifying the
proxy.conf configuration file. The Linux agent proxy configuration value has the following syntax:
[protocol://][user:password@]proxyhost[:port]
NOTE
If your proxy server does not require you to authenticate, the Linux agent still requires providing a pseudo user/password.
This can be any username or password.
PROPERTY DESCRIPTION
Protocol https
user Optional username for proxy authentication
password Optional password for proxy authentication
proxyhost Address or FQDN of the proxy server/Log Analytics gateway
port Optional port number for the proxy server/Log Analytics

gateway
For example: https://user01:password@proxy01.contoso.com:30443
NOTE
If you use special characters such as “@” in your password, you receive a proxy connection error because value is parsed
incorrectly. To work around this issue, encode the password in the URL using a tool such as URLDecode.
Install and configure agent

Connecting machines in your Azure subscription or hybrid environment directly with Azure Monitor logs can be
accomplished using different methods depending on your requirements. The following table highlights each
method to determine which works best in your organization.
SOURCE METHOD DESCRIPTION

SOURCE METHOD DESCRIPTION
Azure VM - Log Analytics VM extension for - The extension installs the Log
Windows or Linux using Azure CLI or Analytics agent on Azure virtual
with an Azure Resource Manager machines and enrolls them into an
template existing Azure Monitor workspace.
- Manually from the Azure portal - Azure Security Center can provision
- Azure Security Center Automatic the Log Analytics agent on all
provisioning supported Azure VMs and any new
ones that are created if you enable it to
monitor for security vulnerabilities and
threats. If enabled, any new or existing
VM without an installed agent will be
provisioned.
Hybrid Windows computer - Manual install Install the Microsoft Monitoring agent
- Azure Automation DSC from the command line or using an
- Resource Manager template with automated method such as Azure
Azure Stack Automation DSC, System Center
Configuration Manager, or with an
Azure Resource Manager template if
you have deployed Microsoft Azure
Stack in your datacenter.
Hybrid Linux computer Manual install Install the agent for Linux calling a
wrapper-script hosted on GitHub.
System Center Operations Manager Integrate Operations Manager with Configure integration between
Log Analytics Operations Manager and Azure
Monitor logs to forward collected data
from Windows computers reporting to
a management group.
Next steps
Review data sources to understand the data sources available to collect data from your Windows or Linux
system.
Learn about log queries to analyze the data collected from data sources and solutions.
Learn about monitoring solutions that add functionality to Azure Monitor and also collect data into the Log
Analytics workspace.
Connect Windows computers to Azure Monitor
In order to monitor and manage virtual machines or physical computers in your local datacenter or other cloud
environment with Azure Monitor, you need to deploy the Log Analytics agent (also referred to as the Microsoft
Monitoring Agent (MMA)) and configure it to report to one or more Log Analytics workspaces. The agent also
supports the Hybrid Runbook Worker role for Azure Automation.
On a monitored Windows computer, the agent is listed as the Microsoft Monitoring Agent service. The Microsoft
Monitoring Agent service collects events from log files and Windows event log, performance data, and other
telemetry. Even when the agent is unable to communicate with Azure Monitor it reports to, the agent continues
to run and queues the collected data on the disk of the monitored computer. When the connection is restored,
the Microsoft Monitoring Agent service sends collected data to the service.
The agent may be installed by using one of the following methods. Most installations use a combination of these
methods to install different sets of computers, as appropriate. Details on using each method are provided later in
the article.
Manual installation. Setup is manually run on the computer using the setup wizard, from the command line,
or deployed using an existing software distribution tool.
Azure Automation Desired State Configuration (DSC ). Using DSC in Azure Automation with a script for
Windows computers already deployed in your environment.
PowerShell script.
Resource Manager template for virtual machines running Windows on-premises in Azure Stack.
NOTE
Azure Security Center (ASC) depends on the Microsoft Monitoring Agent (also referred to as the Log Analytics Windows
agent) and will install and configure it to report to a Log Analytics workspace as part of its deployment. ASC includes an
automatic provisioning option which enables automatic installation of the Log Analytics Windows agent on all VMs in your
subscription and configures it to report to a specific workspace. For more information about this option, see Enable
automatic provisioning of Log Analytics agent.
If you need to configure the agent to report to more than one workspace, this cannot be performed during initial
setup, only afterwards by updating the settings from Control Panel or PowerShell as described in Adding or
removing a workspace.
To understand the supported configuration, review supported Windows operating systems and network firewall
configuration.
Obtain workspace ID and key

Before installing the Log Analytics agent for Windows, you need the workspace ID and key for your Log
Analytics workspace. This information is required during setup from each installation method to properly
configure the agent and ensure it can successfully communicate with Azure Monitor in Azure commercial and
US Government cloud.
list filters based on your input. Select Log Analytics.
2. In your list of Log Analytics workspaces, select the workspace you intend on configuring the agent to report
to.
4. Select Connected Sources, and then select Windows Servers.

5. Copy and paste into your favorite editor, the Workspace ID and Primary Key.
Configure Agent to use TLS 1.2

To configure use of the TLS 1.2 protocol for communication between the Windows agent and the Log Analytics
service, you can follow the steps below to enable before the agent is installed on the virtual machine or
afterwards.
1. Locate the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\P
rotocols
2. Create a subkey under Protocols for TLS 1.2
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
3. Create a Client subkey under the TLS 1.2 protocol version subkey you created earlier. For example,
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client.
4. Create the following DWORD values under
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client:
Enabled [Value = 1]
DisabledByDefault [Value = 0]
Configure .NET Framework 4.6 or later to support secure cryptography, as by default it is disabled. The strong
cryptography uses more secure network protocols like TLS 1.2, and blocks protocols that are not secure.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319.
2. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319.
4. Create the DWORD value SchUseStrongCrypto under this subkey with a value of 1.
5. Restart the system for the settings to take effect.
Install the agent using setup wizard

The following steps install and configure the Log Analytics agent in Azure and Azure Government cloud by
using the setup wizard for the agent on your computer. If you want to learn how to configure the agent to also
report to a System Center Operations Manager management group, see deploy the Operations Manager agent
with the Agent Setup Wizard.
1. In your Log Analytics workspace, from the Windows Servers page you navigated to earlier, select the
appropriate Download Windows Agent version to download depending on the processor architecture of
the Windows operating system.
2. Run Setup to install the agent on your computer.
3. On the Welcome page, click Next.
4. On the License Terms page, read the license and then click I Agree.
5. On the Destination Folder page, change or keep the default installation folder and then click Next.
6. On the Agent Setup Options page, choose to connect the agent to Azure Log Analytics and then click Next.
7. On the Azure Log Analytics page, perform the following:
a. Paste the Workspace ID and Workspace Key (Primary Key) that you copied earlier. If the computer
should report to a Log Analytics workspace in Azure Government cloud, select Azure US
Government from the Azure Cloud drop-down list.
b. If the computer needs to communicate through a proxy server to the Log Analytics service, click
Advanced and provide the URL and port number of the proxy server. If your proxy server requires
authentication, type the username and password to authenticate with the proxy server and then click
Next.
8. Click Next once you have completed providing the necessary configuration settings.
9. On the Ready to Install page, review your choices and then click Install.
10. On the Configuration completed successfully page, click Finish.
When complete, the Microsoft Monitoring Agent appears in Control Panel. To confirm it is reporting to Log
Analytics, review Verify agent connectivity to Log Analytics.
Install the agent using the command line

The downloaded file for the agent is a self-contained installation package. The setup program for the agent and
supporting files are contained in the package and need to be extracted in order to properly install using the
command line shown in the following examples.
NOTE
If you want to upgrade an agent, you need to use the Log Analytics scripting API. See the topic Managing and maintaining
the Log Analytics agent for Windows and Linux for further information.
The following table highlights the specific parameters supported by setup for the agent, including when
deployed using Automation DSC.
MMA-SPECIFIC OPTIONS NOTES
NOAPM=1 Optional parameter. Installs the agent without .NET

Application Performance Monitoring.
ADD_OPINSIGHTS_WORKSPACE 1 = Configure the agent to report to a workspace
OPINSIGHTS_WORKSPACE_ID Workspace ID (guid) for the workspace to add
OPINSIGHTS_WORKSPACE_KEY Workspace key used to initially authenticate with the

workspace
MMA-SPECIFIC OPTIONS NOTES
OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE Specify the cloud environment where the workspace is

located
0 = Azure commercial cloud (default)
1 = Azure Government
OPINSIGHTS_PROXY_URL URI for the proxy to use
OPINSIGHTS_PROXY_USERNAME Username to access an authenticated proxy
OPINSIGHTS_PROXY_PASSWORD Password to access an authenticated proxy
1. To extract the agent installation files, from an elevated command prompt run MMASetup-<platform>.exe /c
and it will prompt you for the path to extract files to. Alternatively, you can specify the path by passing the
arguments MMASetup-<platform>.exe /c /t:<Full Path> .
2. To silently install the agent and configure it to report to a workspace in Azure commercial cloud, from the
folder you extracted the setup files to type:
setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0

OPINSIGHTS_WORKSPACE_ID="<your workspace ID>" OPINSIGHTS_WORKSPACE_KEY="<your workspace key>"
AcceptEndUserLicenseAgreement=1
or to configure the agent to report to Azure US Government cloud, type:
setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=1

OPINSIGHTS_WORKSPACE_ID="<your workspace ID>" OPINSIGHTS_WORKSPACE_KEY="<your workspace key>"
AcceptEndUserLicenseAgreement=1
NOTE
The string values for the parameters OPINSIGHTS_WORKSPACE_ID and OPINSIGHTS_WORKSPACE_KEY need to be
encapsulated in double-quotes to instruct Windows Installer to interprit as valid options for the package.
Install the agent using DSC in Azure Automation

You can use the following script example to install the agent using Azure Automation DSC. If you do not have an
Automation account, see Get started with Azure Automation to understand requirements and steps for creating
an Automation account required before using Automation DSC. If you are not familiar with Automation DSC,
review Getting started with Automation DSC.
The following example installs the 64-bit agent, identified by the URI value. You can also use the 32-bit version
by replacing the URI value. The URIs for both versions are:
Windows 64-bit agent - https://go.microsoft.com/fwlink/?LinkId=828603
Windows 32-bit agent - https://go.microsoft.com/fwlink/?LinkId=828604
NOTE
This procedure and script example does not support upgrading the agent already deployed to a Windows computer.
The 32-bit and 64-bit versions of the agent package have different product codes and new versions released also
have a unique value. The product code is a GUID that is the principal identification of an application or product
and is represented by the Windows Installer ProductCode property. The ProductId value in the
MMAgent.ps1 script has to match the product code from the 32-bit or 64-bit agent installer package.
To retrieve the product code from the agent install package directly, you can use Orca.exe from the Windows
SDK Components for Windows Installer Developers that is a component of the Windows Software
Development Kit or using PowerShell following an example script written by a Microsoft Valuable Professional
(MVP ). For either approach, you first need to extract the MOMagent.msi file from the MMASetup installation
package. This is shown earlier in the first step under the section Install the agent using the command line.
1. Import the xPSDesiredStateConfiguration DSC Module from
https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration into Azure Automation.
2. Create Azure Automation variable assets for OPSINSIGHTS_WS_ID and OPSINSIGHTS_WS_KEY. Set
OPSINSIGHTS_WS_ID to your Log Analytics workspace ID and set OPSINSIGHTS_WS_KEY to the
primary key of your workspace.
3. Copy the script and save it as MMAgent.ps1.
Configuration MMAgent
{
$OIPackageLocalPath = "C:\Deploy\MMASetup-AMD64.exe"
$OPSINSIGHTS_WS_ID = Get-AutomationVariable -Name "OPSINSIGHTS_WS_ID"
$OPSINSIGHTS_WS_KEY = Get-AutomationVariable -Name "OPSINSIGHTS_WS_KEY"
Import-DscResource -ModuleName xPSDesiredStateConfiguration

Import-DscResource -ModuleName PSDesiredStateConfiguration
Node OMSnode {
Service OIService
{
Name = "HealthService"
State = "Running"
DependsOn = "[Package]OI"
}
xRemoteFile OIPackage {
Uri = "https://go.microsoft.com/fwlink/?LinkId=828603"
DestinationPath = $OIPackageLocalPath
}
Package OI {
Ensure = "Present"
Path = $OIPackageLocalPath
Name = "Microsoft Monitoring Agent"
ProductId = "8A7F2C51-4C7D-4BFD-9014-91D11F24AAE2"
Arguments = '/C:"setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=' +
$OPSINSIGHTS_WS_ID + ' OPINSIGHTS_WORKSPACE_KEY=' + $OPSINSIGHTS_WS_KEY + '
AcceptEndUserLicenseAgreement=1"'
DependsOn = "[xRemoteFile]OIPackage"
}
}
}
4. Update the ProductId value in the script with the product code extracted from the latest version of the
agent install package using the methods recommended earlier.
5. Import the MMAgent.ps1 configuration script into your Automation account.
6. Assign a Windows computer or node to the configuration. Within 15 minutes, the node checks its
configuration and the agent is pushed to the node.
Verify agent connectivity to Log Analytics

Verify agent connectivity to Log Analytics
Once installation of the agent is complete, verifying it is successfully connected and reporting can be
accomplished in two ways.
From the computer in Control Panel, find the item Microsoft Monitoring Agent. Select it and on the Azure
Log Analytics tab, the agent should display a message stating: The Microsoft Monitoring Agent has
successfully connected to the Microsoft Operations Management Suite service.
You can also perform a simple log query in the Azure portal.
1. In the Azure portal, click All services. In the list of resources, type Azure Monitor. As you begin typing,
the list filters based on your input. Select Azure Monitor.
2. Select Logs in the menu.
3. On the Logs pane, in the query field type:
Heartbeat
| where Category == "Direct Agent"
In the search results returned, you should see heartbeat records for the computer indicating it is connected and
reporting to the service.
Next steps
Review Managing and maintaining the Log Analytics agent for Windows and Linux to learn about how to
reconfigure, upgrade, or remove the agent from the virtual machine.
Review Troubleshooting the Windows agent if you encounter issues while installing or managing the
agent.
2 minutes to read
2 minutes to read
Connect computers without internet access by using
the Log Analytics gateway in Azure Monitor
NOTE
As Microsoft Operations Management Suite (OMS) transitions to Microsoft Azure Monitor, terminology is changing. This
article refers to OMS Gateway as the Azure Log Analytics gateway.
This article describes how to configure communication with Azure Automation and Azure Monitor by using the
Log Analytics gateway when computers that are directly connected or that are monitored by Operations Manager
have no internet access.
The Log Analytics gateway is an HTTP forward proxy that supports HTTP tunneling using the HTTP CONNECT
command. This gateway sends data to Azure Automation and a Log Analytics workspace in Azure Monitor on
behalf of the computers that cannot directly connect to the internet. It does not cache data from the agents, the
agent handles caching data in this situation until communication is restored.
The Log Analytics gateway supports:
Reporting up to the same four Log Analytics workspace agents that are behind it and that are configured with
Azure Automation Hybrid Runbook Workers.
Windows computers on which the Microsoft Monitoring Agent is directly connected to a Log Analytics
workspace in Azure Monitor.
Linux computers on which a Log Analytics agent for Linux is directly connected to a Log Analytics workspace
in Azure Monitor.
System Center Operations Manager 2012 SP1 with UR7, Operations Manager 2012 R2 with UR3, or a
management group in Operations Manager 2016 or later that is integrated with Log Analytics.
Some IT security policies don't allow internet connection for network computers. These unconnected computers
could be point of sale (POS ) devices or servers supporting IT services, for example. To connect these devices to
Azure Automation or a Log Analytics workspace so you can manage and monitor them, configure them to
communicate directly with the Log Analytics gateway. The Log Analytics gateway can receive configuration
information and forward data on their behalf. If the computers are configured with the Log Analytics agent to
directly connect to a Log Analytics workspace, the computers instead communicate with the Log Analytics
gateway.
The Log Analytics gateway transfers data from the agents to the service directly. It doesn't analyze any of the data
in transit.
When an Operations Manager management group is integrated with Log Analytics, the management servers can
be configured to connect to the Log Analytics gateway to receive configuration information and send collected
data, depending on the solution you have enabled. Operations Manager agents send some data to the
management server. For example, agents might send Operations Manager alerts, configuration assessment data,
instance space data, and capacity data. Other high-volume data, such as Internet Information Services (IIS ) logs,
performance data, and security events, is sent directly to the Log Analytics gateway.
If one or more Operations Manager Gateway servers are deployed to monitor untrusted systems in a perimeter
network or an isolated network, those servers can't communicate with a Log Analytics gateway. Operations
Manager Gateway servers can report only to a management server. When an Operations Manager management
group is configured to communicate with the Log Analytics gateway, the proxy configuration information is
automatically distributed to every agent-managed computer that is configured to collect log data for Azure
Monitor, even if the setting is empty.
To provide high availability for directly connected or Operations Management groups that communicate with a
Log Analytics workspace through the gateway, use network load balancing (NLB ) to redirect and distribute traffic
across multiple gateway servers. That way, if one gateway server goes down, the traffic is redirected to another
available node.
The computer that runs the Log Analytics gateway requires the Log Analytics Windows agent to identify the
service endpoints that the gateway needs to communicate with. The agent also needs to direct the gateway to
report to the same workspaces that the agents or Operations Manager management group behind the gateway
are configured with. This configuration allows the gateway and the agent to communicate with their assigned
workspace.
A gateway can be multihomed to up to four workspaces. This is the total number of workspaces a Windows agent
supports.
Each agent must have network connectivity to the gateway so that agents can automatically transfer data to and
from the gateway. Avoid installing the gateway on a domain controller.
The following diagram shows data flowing from direct agents, through the gateway, to Azure Automation and Log
Analytics. The agent proxy configuration must match the port that the Log Analytics gateway is configured with.
The following diagram shows data flow from an Operations Manager management group to Log Analytics.
Set up your system
Computers designated to run the Log Analytics gateway must have the following configuration:
Windows 10, Windows 8.1, or Windows 7
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, or
Windows Server 2008
Microsoft .NET Framework 4.5
At least a 4-core processor and 8 GB of memory
A Log Analytics agent for Windows that is configured to report to the same workspace as the agents that
communicate through the gateway
Language availability
The Log Analytics gateway is available in these languages:
Chinese (Simplified)
Chinese (Traditional)
Czech
Dutch
English
French
German
Hungarian
Italian
Japanese
Korean
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Russian
Spanish (International)
Supported encryption protocols
The Log Analytics gateway supports only Transport Layer Security (TLS ) 1.0, 1.1, and 1.2. It doesn't support
Secure Sockets Layer (SSL ). To ensure the security of data in transit to Log Analytics, configure the gateway to use
at least TLS 1.2. Older versions of TLS or SSL are vulnerable. Although they currently allow backward
compatibility, avoid using them.
For additional information, review Sending data securely using TLS 1.2.
Supported number of agent connections
The following table shows approximately how many agents can communicate with a gateway server. Support is
based on agents that upload about 200 KB of data every 6 seconds. For each agent tested, data volume is about
2.7 GB per day.
GATEWAY AGENTS SUPPORTED (APPROXIMATE)
CPU: Intel Xeon Processor E5-2660 v3 @ 2.6 GHz 2 Cores 600

Memory: 4 GB
Network bandwidth: 1 Gbps
CPU: Intel Xeon Processor E5-2660 v3 @ 2.6 GHz 4 Cores 1000

Memory: 8 GB
Network bandwidth: 1 Gbps
Download the Log Analytics gateway

Get the latest version of the Log Analytics gateway Setup file from either Microsoft Download Center or the Azure
portal.
To get the Log Analytics gateway from the Azure portal, follow these steps:
1. Browse the list of services, and then select Log Analytics.
2. Select a workspace.
3. In your workspace blade, under General, select Quick Start.
4. Under Choose a data source to connect to the workspace, select Computers.
5. In the Direct Agent blade, select Download Log Analytics gateway.
or
1. In your workspace blade, under Settings, select Advanced settings.
2. Go to Connected Sources > Windows Servers and select Download Log Analytics gateway.
Install Log Analytics gateway using setup wizard

To install a gateway using the setup wizard, follow these steps.
1. From the destination folder, double-click Log Analytics gateway.msi.
2. On the Welcome page, select Next.
3. On the License Agreement page, select I accept the terms in the License Agreement to agree to the
Microsoft Software License Terms, and then select Next.
4. On the Port and proxy address page:
a. Enter the TCP port number to be used for the gateway. Setup uses this port number to configure an
inbound rule on Windows Firewall. The default value is 8080. The valid range of the port number is 1
through 65535. If the input does not fall into this range, an error message appears.
b. If the server where the gateway is installed needs to communicate through a proxy, enter the proxy
address where the gateway needs to connect. For example, enter http://myorgname.corp.contoso.com:80 . If
you leave this field blank, the gateway will try to connect to the internet directly. If your proxy server
requires authentication, enter a username and password.
c. Select Next.
5. If you do not have Microsoft Update enabled, the Microsoft Update page appears, and you can choose to
enable it. Make a selection and then select Next. Otherwise, continue to the next step.
6. On the Destination Folder page, either leave the default folder C:\Program Files\OMS Gateway or enter
the location where you want to install the gateway. Then select Next.
7. On the Ready to install page, select Install. If User Account Control requests permission to install, select
Yes.
8. After Setup finishes, select Finish. To verify that the service is running, open the services.msc snap-in and
verify that OMS Gateway appears in the list of services and that its status is Running.
Install the Log Analytics gateway using the command line

The downloaded file for the gateway is a Windows Installer package that supports silent installation from the
command line or other automated method. If you are not familiar with the standard command-line options for
Windows Installer, see Command-line options.
The following table highlights the parameters supported by setup.
PARAMETERS NOTES
PORTNUMBER TCP port number for gateway to listen on
PROXY IP address of proxy server
INSTALLDIR Fully qualified path to specify install directory of gateway

software files
USERNAME User Id to authenticate with proxy server

PARAMETERS NOTES
PASSWORD Password of the user Id to authenticate with proxy
LicenseAccepted Specify a value of 1 to verify you accept license agreement
HASAUTH Specify a value of 1 when USERNAME/PASSWORD parameters

are specified
HASPROXY Specify a value of 1 when specifying IP address for PROXY

parameter
To silently install the gateway and configure it with a specific proxy address, port number, type the following:
Msiexec.exe /I “oms gateway.msi” /qn PORTNUMBER=8080 PROXY=”10.80.2.200” HASPROXY=1 LicenseAccepted=1
Using the /qn command-line option hides setup, /qb shows setup during silent install.
If you need to provide credentials to authenticate with the proxy, type the following:
Msiexec.exe /I “oms gateway.msi” /qn PORTNUMBER=8080 PROXY=”10.80.2.200” HASPROXY=1 HASAUTH=1

USERNAME=”<username>” PASSWORD=”<password>” LicenseAccepted=1
After installation, you can confirm the settings are accepted (exlcuding the username and password) using the
following PowerShell cmdlets:
Get-OMSGatewayConfig – Returns the TCP Port the gateway is configured to listen on.
Get-OMSGatewayRelayProxy – Returns the IP address of the proxy server you configured it to
communicate with.
Configure network load balancing

You can configure the gateway for high availability using network load balancing (NLB ) using either Microsoft
Network Load Balancing (NLB ), Azure Load Balancer, or hardware-based load balancers. The load balancer
manages traffic by redirecting the requested connections from the Log Analytics agents or Operations Manager
management servers across its nodes. If one Gateway server goes down, the traffic gets redirected to other nodes.
Microsoft Network Load Balancing
To learn how to design and deploy a Windows Server 2016 network load balancing cluster, see Network load
balancing. The following steps describe how to configure a Microsoft network load balancing cluster.
1. Sign onto the Windows server that is a member of the NLB cluster with an administrative account.
2. Open Network Load Balancing Manager in Server Manager, click Tools, and then click Network Load
Balancing Manager.
3. To connect an Log Analytics gateway server with the Microsoft Monitoring Agent installed, right-click the
cluster's IP address, and then click Add Host to Cluster.
4. Enter the IP address of the gateway server that you want to connect.
Azure Load Balancer

To learn how to design and deploy an Azure Load Balancer, see What is Azure Load Balancer?. To deploy a basic
load balancer, follow the steps outlined in this quickstart excluding the steps outlined in the section Create back-
end servers.
NOTE
Configuring the Azure Load Balancer using the Basic SKU, requires that Azure virtual machines belong to an Availability Set.
To learn more about availability sets, see Manage the availability of Windows virtual machines in Azure. To add existing
virtual machines to an availability set, refer to Set Azure Resource Manager VM Availability Set.
After the load balancer is created, a backend pool needs to be created, which distributes traffic to one or more
gateway servers. Follow the steps described in the quickstart article section Create resources for the load balancer.
NOTE
When configuring the health probe it should be configured to use the TCP port of the gateway server. The health probe
dynamically adds or removes the gateway servers from the load balancer rotation based on their response to health checks.
Configure the Log Analytics agent and Operations Manager

management group
In this section, you'll see how to configure directly connected Log Analytics agents, an Operations Manager
management group, or Azure Automation Hybrid Runbook Workers with the Log Analytics gateway to
communicate with Azure Automation or Log Analytics.
Configure a standalone Log Analytics agent
When configuring the Log Analytics agent, replace the proxy server value with the IP address of the Log Analytics
gateway server and its port number. If you have deployed multiple gateway servers behind a load balancer, the
Log Analytics agent proxy configuration is the virtual IP address of the load balancer.
NOTE
To install the Log Analytics agent on the gateway and Windows computers that directly connect to Log Analytics, see
Connect Windows computers to the Log Analytics service in Azure. To connect Linux computers, see Configure a Log
Analytics agent for Linux computers in a hybrid environment.
After you install the agent on the gateway server, configure it to report to the workspace or workspace agents that
communicate with the gateway. If the Log Analytics Windows agent is not installed on the gateway, event 300 is
written to the OMS Gateway event log, indicating that the agent needs to be installed. If the agent is installed but
not configured to report to the same workspace as the agents that communicate through it, event 105 is written to
the same log, indicating that the agent on the gateway needs to be configured to report to the same workspace as
the agents that communicate with the gateway.
After you complete configuration, restart the OMS Gateway service to apply the changes. Otherwise, the gateway
will reject agents that attempt to communicate with Log Analytics and will report event 105 in the OMS Gateway
event log. This will also happen when you add or remove a workspace from the agent configuration on the
gateway server.
For information related to the Automation Hybrid Runbook Worker, see Automate resources in your datacenter
or cloud by using Hybrid Runbook Worker.
Configure Operations Manager, where all agents use the same proxy server
The Operations Manager proxy configuration is automatically applied to all agents that report to Operations
Manager, even if the setting is empty.
To use OMS Gateway to support Operations Manager, you must have:
Microsoft Monitoring Agent (version 8.0.10900.0 or later) installed on the OMS Gateway server and
configured with the same Log Analytics workspaces that your management group is configured to report to.
Internet connectivity. Alternatively, OMS Gateway must be connected to a proxy server that is connected to the
internet.
NOTE
If you specify no value for the gateway, blank values are pushed to all agents.
If your Operations Manager management group is registering with a Log Analytics workspace for the first time,
you won't see the option to specify the proxy configuration for the management group in the Operations console.
This option is available only if the management group has been registered with the service.
To configure integration, update the system proxy configuration by using Netsh on the system where you're
running the Operations console and on all management servers in the management group. Follow these steps:
1. Open an elevated command prompt:
a. Select Start and enter cmd.
b. Right-click Command Prompt and select Run as administrator.
2. Enter the following command:
netsh winhttp set proxy <proxy>:<port>
After completing the integration with Log Analytics, remove the change by running netsh winhttp reset proxy .
Then, in the Operations console, use the Configure proxy server option to specify the Log Analytics gateway
server.
1. On the Operations Manager console, under Operations Management Suite, select Connection, and
then select Configure Proxy Server.
2. Select Use a proxy server to access the Operations Management Suite and then enter the IP address
of the Log Analytics gateway server or virtual IP address of the load balancer. Be careful to start with the
prefix http:// .
3. Select Finish. Your Operations Manager management group is now configured to communicate through
the gateway server to the Log Analytics service.
Configure Operations Manager, where specific agents use a proxy server
For large or complex environments, you might want only specific servers (or groups) to use the Log Analytics
gateway server. For these servers, you can't update the Operations Manager agent directly because this value is
overwritten by the global value for the management group. Instead, override the rule used to push these values.
NOTE
Use this configuration technique if you want to allow for multiple Log Analytics gateway servers in your environment. For
example, you can require specific Log Analytics gateway servers to be specified on a regional basis.
To configure specific servers or groups to use the Log Analytics gateway server:
1. Open the Operations Manager console and select the Authoring workspace.
2. In the Authoring workspace, select Rules.
3. On the Operations Manager toolbar, select the Scope button. If this button is not available, make sure you
have selected an object, not a folder, in the Monitoring pane. The Scope Management Pack Objects
dialog box displays a list of common targeted classes, groups, or objects.
4. In the Look for field, enter Health Service and select it from the list. Select OK.
5. Search for Advisor Proxy Setting Rule.
6. On the Operations Manager toolbar, select Overrides and then point to Override the Rule\For a specific
object of class: Health Service and select an object from the list. Or create a custom group that contains
the health service object of the servers you want to apply this override to. Then apply the override to your
custom group.
7. In the Override Properties dialog box, add a check mark in the Override column next to the
WebProxyAddress parameter. In the Override Value field, enter the URL of the Log Analytics gateway
server. Be careful to start with the prefix http:// .
NOTE
You don't need to enable the rule. It's already managed automatically with an override in the Microsoft System
Center Advisor Secure Reference Override management pack that targets the Microsoft System Center Advisor
Monitoring Server Group.
8. Select a management pack from the Select destination management pack list, or create a new unsealed
management pack by selecting New.
9. When you finish, select OK.
Configure for Automation Hybrid Runbook Workers
If you have Automation Hybrid Runbook Workers in your environment, follow these steps for manual, temporary
workarounds to configure OMS Gateway to support the workers.
To follow the steps in this section, you need to know the Azure region where the Automation account resides. To
find that location:
2. Select the Azure Automation service.
3. Select the appropriate Azure Automation account.
4. View its region under Location.
Use the following tables to identify the URL for each location.
Job Runtime Data service URLs
LOCATION URL
North Central US ncus-jobruntimedata-prod-su1.azure-automation.net
West Europe we-jobruntimedata-prod-su1.azure-automation.net

LOCATION URL
South Central US scus-jobruntimedata-prod-su1.azure-automation.net
East US 2 eus2-jobruntimedata-prod-su1.azure-automation.net
Central Canada cc-jobruntimedata-prod-su1.azure-automation.net
North Europe ne-jobruntimedata-prod-su1.azure-automation.net
South East Asia sea-jobruntimedata-prod-su1.azure-automation.net
Central India cid-jobruntimedata-prod-su1.azure-automation.net
Japan jpe-jobruntimedata-prod-su1.azure-automation.net
Australia ase-jobruntimedata-prod-su1.azure-automation.net
Agent service URLs
LOCATION URL
North Central US ncus-agentservice-prod-1.azure-automation.net
West Europe we-agentservice-prod-1.azure-automation.net
South Central US scus-agentservice-prod-1.azure-automation.net
East US 2 eus2-agentservice-prod-1.azure-automation.net
Central Canada cc-agentservice-prod-1.azure-automation.net
North Europe ne-agentservice-prod-1.azure-automation.net
South East Asia sea-agentservice-prod-1.azure-automation.net
Central India cid-agentservice-prod-1.azure-automation.net
Japan jpe-agentservice-prod-1.azure-automation.net
Australia ase-agentservice-prod-1.azure-automation.net
If your computer is registered as a Hybrid Runbook Worker automatically, use the Update Management solution
to manage the patch. Follow these steps:
1. Add the Job Runtime Data service URLs to the Allowed Host list on the Log Analytics gateway. For example:
Add-OMSGatewayAllowedHost we-jobruntimedata-prod-su1.azure-automation.net
2. Restart the Log Analytics gateway service by using the following PowerShell cmdlet:
Restart-Service OMSGatewayService
If your computer is joined to Azure Automation by using the Hybrid Runbook Worker registration cmdlet, follow
these steps:
1. Add the agent service registration URL to the Allowed Host list on the Log Analytics gateway. For example:
Add-OMSGatewayAllowedHost ncus-agentservice-prod-1.azure-automation.net
2. Add the Job Runtime Data service URLs to the Allowed Host list on the Log Analytics gateway. For example:
Add-OMSGatewayAllowedHost we-jobruntimedata-prod-su1.azure-automation.net
3. Restart the Log Analytics gateway service. Restart-Service OMSGatewayService
Useful PowerShell cmdlets

You can use cmdlets to complete the tasks to update the Log Analytics gateway's configuration settings. Before
you use cmdlets, be sure to:
1. Install the Log Analytics gateway (Microsoft Windows Installer).
2. Open a PowerShell console window.
3. Import the module by typing this command: Import-Module OMSGateway
4. If no error occurred in the previous step, the module was successfully imported and the cmdlets can be used.
Enter Get-Module OMSGateway
5. After you use the cmdlets to make changes, restart the OMS Gateway service.
An error in step 3 means that the module wasn't imported. The error might occur when PowerShell can't find the
module. You can find the module in the OMS Gateway installation path: C:\Program Files\Microsoft OMS
Gateway\PowerShell\OmsGateway.
CMDLET PARAMETERS DESCRIPTION EXAMPLE
Get-OMSGatewayConfig Key Gets the configuration of Get-OMSGatewayConfig

the service
Set-OMSGatewayConfig Key (required) Changes the configuration Set-OMSGatewayConfig -

Value of the service Name ListenPort -Value
8080
Get- Gets the address of relay Get-

OMSGatewayRelayProxy (upstream) proxy OMSGatewayRelayProxy
Set- Address Sets the address (and 1. Set a relay proxy and
OMSGatewayRelayProxy Username credential) of relay credential:
Password (upstream) proxy Set-
OMSGatewayRelayProxy
-Address
http://www.myproxy.com:8080
-Username user1 -
Password 123
2. Set a relay proxy that

doesn't need authentication:
Set-
-Address
http://www.myproxy.com:8080
3. Clear the relay proxy

setting:
Set-
-Address ""
CMDLET PARAMETERS DESCRIPTION EXAMPLE
Get- Gets the currently allowed Get-

OMSGatewayAllowedHost host (only the locally OMSGatewayAllowedHost
configured allowed host, not
automatically downloaded
allowed hosts)
Add- Host (required) Adds the host to the Add-

OMSGatewayAllowedHost allowed list OMSGatewayAllowedHost -
Host www.test.com
Remove- Host (required) Removes the host from the Remove-

OMSGatewayAllowedHost allowed list OMSGatewayAllowedHost
-Host www.test.com
Add- Subject (required) Adds the client certificate Add-OMSGatewayAllowed

OMSGatewayAllowedClientCertificate subject to the allowed list ClientCertificate
-Subject mycert
Remove- Subject (required) Removes the client Remove-

OMSGatewayAllowedClientCertificate certificate subject from the OMSGatewayAllowed
allowed list ClientCertificate
-Subject mycert
Get- Gets the currently allowed Get-

OMSGatewayAllowedClientCertificate client certificate subjects OMSGatewayAllowed
(only the locally configured ClientCertificate
allowed subjects, not
automatically downloaded
allowed subjects)
Troubleshooting
To collect events logged by the gateway, you should have the Log Analytics agent installed.
Log Analytics gateway event IDs and descriptions

The following table shows the event IDs and descriptions for Log Analytics gateway log events.
ID DESCRIPTION
400 Any application error that has no specific ID.
401 Wrong configuration. For example, listenPort = "text" instead

of an integer.
402 Exception in parsing TLS handshake messages.
403 Networking error. For example, cannot connect to target

server.
100 General information.
101 Service has started.
102 Service has stopped.
103 An HTTP CONNECT command was received from client.
104 Not an HTTP CONNECT command.
105 Destination server is not in allowed list, or destination port is

not secure (443).
Ensure that the MMA agent on your OMS Gateway server

and the agents that communicate with OMS Gateway are
connected to the same Log Analytics workspace.
105 ERROR TcpConnection – Invalid Client certificate:

CN=Gateway.
Ensure that you're using OMS Gateway version 1.0.395.0 or

greater. Also ensure that the MMA agent on your OMS
Gateway server and the agents communicating with OMS
Gateway are connected to the same Log Analytics workspace.
106 Unsupported TLS/SSL protocol version.
The Log Analytics gateway supports only TLS 1.0, TLS 1.1, and
1.2. It does not support SSL.
107 The TLS session has been verified.
Performance counters to collect

The following table shows the performance counters available for the Log Analytics gateway. Use Performance
Monitor to add the counters.
NAME DESCRIPTION
Log Analytics Gateway/Active Client Connection Number of active client network (TCP) connections
Log Analytics Gateway/Error Count Number of errors
Log Analytics Gateway/Connected Client Number of connected clients

NAME DESCRIPTION
Log Analytics Gateway/Rejection Count Number of rejections due to any TLS validation error
Assistance
When you're signed in to the Azure portal, you can get help with the Log Analytics gateway or any other Azure
service or feature. To get help, select the question mark icon in the upper-right corner of the portal and select
New support request. Then complete the new support request form.
Next steps
Add data sources to collect data from connected sources, and store the data in your Log Analytics workspace.
Managing and maintaining the Log Analytics agent
for Windows and Linux
After initial deployment of the Log Analytics Windows or Linux agent in Azure Monitor, you may need to
reconfigure the agent, upgrade it, or remove it from the computer if it has reached the retirement stage in its
lifecycle. You can easily manage these routine maintenance tasks manually or through automation, which reduces
both operational error and expenses.
Upgrading agent
The Log Analytics agent for Windows and Linux can be upgraded to the latest release manually or automatically
depending on the deployment scenario and environment the VM is running in. The following methods can be
used to upgrade the agent.
ENVIRONMENT INSTALLATION METHOD UPGRADE METHOD
Azure VM Log Analytics agent VM extension for Agent is automatically upgraded by

Windows/Linux default unless you configured your
Azure Resource Manager template to
opt out by setting the property
autoUpgradeMinorVersion to false.
Custom Azure VM images Manual install of Log Analytics agent Updating VMs to the newest version of
for Windows/Linux the agent needs to be performed from
the command line running the
Windows installer package or Linux self-
extracting and installable shell script
bundle.
Non-Azure VMs Manual install of Log Analytics agent Updating VMs to the newest version of
for Windows/Linux the agent needs to be performed from
the command line running the
Windows installer package or Linux self-
extracting and installable shell script
bundle.
Upgrade Windows agent

To update the agent on a Windows VM to the latest version not installed using the Log Analytics VM extension,
you either run from the Command Prompt, script or other automation solution, or by using the MMASetup-
<platform>.msi Setup Wizard.
You can download the latest version of the Windows agent from your Log Analytics workspace, by performing the
following steps.
list filters based on your input. Select Log Analytics workspaces.
3. In your list of Log Analytics workspaces, select the workspace.
4. In your Log Analytics workspace, select Advanced settings, then select Connected Sources, and finally
Windows Servers.
5. From the Windows Servers page, select the appropriate Download Windows Agent version to
download depending on the processor architecture of the Windows operating system.
NOTE
During the upgrade of the Log Analytics agent for Windows, it does not support configuring or reconfiguring a workspace to
report to. To configure the agent, you need to follow one of the supported methods listed under Adding or removing a
workspace.
To upgrade using the Setup Wizard

1. Sign on to the computer with an account that has administrative rights.
2. Execute MMASetup-<platform>.exe to start the Setup Wizard.
3. On the first page of the Setup Wizard, click Next.
4. In the Microsoft Monitoring Agent Setup dialog box, click I agree to accept the license agreement.
5. In the Microsoft Monitoring Agent Setup dialog box, click Upgrade. The status page displays the
progress of the upgrade.
6. When the Microsoft Monitoring Agent configuration completed successfully. page appears, click
Finish.
To upgrade from the command line
2. To extract the agent installation files, from an elevated command prompt run MMASetup-<platform>.exe /c
and it will prompt you for the path to extract files to. Alternatively, you can specify the path by passing the
arguments MMASetup-<platform>.exe /c /t:<Full Path> .
3. Run the following command, where D:\ is the location for the upgrade log file.
setup.exe /qn /l*v D:\logs\AgentUpgrade.log AcceptEndUserLicenseAgreement=1
Upgrade Linux agent

Upgrade from prior versions (>1.0.0-47) is supported. Performing the installation with the --upgrade command
will upgrade all components of the agent to the latest version.
Run the following command to upgrade the agent.
sudo sh ./omsagent-*.universal.x64.sh --upgrade
Adding or removing a workspace

Windows agent
The steps in this section are necessary when you want to not only reconfigure the Windows agent to report to a
different workspace or to remove a workspace from its configuration, but also when you want to configure the
agent to report to more than one workspace (commonly referred to as multi-homing). Configuring the Windows
agent to report to multiple workspaces can only be performed after initial setup of the agent and using the
methods described below.
Update settings from Control Panel
3. Select Microsoft Monitoring Agent and then click the Azure Log Analytics tab.
4. If removing a workspace, select it and then click Remove. Repeat this step for any other workspace you
want the agent to stop reporting to.
5. If adding a workspace, click Add and on the Add a Log Analytics Workspace dialog box, paste the
Workspace ID and Workspace Key (Primary Key). If the computer should report to a Log Analytics
workspace in Azure Government cloud, select Azure US Government from the Azure Cloud drop-down list.
6. Click OK to save your changes.
Remove a workspace using PowerShell
$workspaceId = "<Your workspace Id>"

$mma = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
$mma.RemoveCloudWorkspace($workspaceId)
$mma.ReloadConfiguration()
Add a workspace in Azure commercial using PowerShell

$workspaceKey = "<Your workspace Key>"
$mma.AddCloudWorkspace($workspaceId, $workspaceKey)
Add a workspace in Azure for US Government using PowerShell

$workspaceKey = "<Your workspace Key>"
$mma.AddCloudWorkspace($workspaceId, $workspaceKey, 1)
NOTE
If you've used the command line or script previously to install or configure the agent, EnableAzureOperationalInsights
was replaced by AddCloudWorkspace and RemoveCloudWorkspace .
Linux agent
The following steps demonstrate how to reconfigure the Linux agent if you decide to register it with a different
workspace or to remove a workspace from its configuration.
1. To verify it is registered to a workspace, run the following command:
/opt/microsoft/omsagent/bin/omsadmin.sh -l
It should return a status similar to the following example:

Primary Workspace: <workspaceId> Status: Onboarded(OMSAgent Running)
It is important that the status also shows the agent is running, otherwise the following steps to reconfigure
the agent will not complete successfully.
2. If it is already registered with a workspace, remove the registered workspace by running the following
command. Otherwise if it is not registered, proceed to the next step.
/opt/microsoft/omsagent/bin/omsadmin.sh -X
3. To register with a different workspace, run the following command:

/opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <shared key> [-d <top level domain>]
4. To verify your changes took effect, run the following command:

/opt/microsoft/omsagent/bin/omsadmin.sh -l
It should return a status similar to the following example:

Primary Workspace: <workspaceId> Status: Onboarded(OMSAgent Running)
The agent service does not need to be restarted in order for the changes to take effect.
Update proxy settings

To configure the agent to communicate to the service through a proxy server or Log Analytics gateway after
deployment, use one of the following methods to complete this task.
Windows agent
Update settings using Control Panel
3. Select Microsoft Monitoring Agent and then click the Proxy Settings tab.
4. Click Use a proxy server and provide the URL and port number of the proxy server or gateway. If your
proxy server or Log Analytics gateway requires authentication, type the username and password to
authenticate and then click OK.
Update settings using PowerShell
Copy the following sample PowerShell code, update it with information specific to your environment, and save it
with a PS1 file name extension. Run the script on each computer that connects directly to the Log Analytics
param($ProxyDomainName="https://proxy.contoso.com:30443", $cred=(Get-Credential))
# First we get the Health Service configuration object. We need to determine if we

#have the right update rollup with the API we need. If not, no need to run the rest of the script.
$healthServiceSettings = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
$proxyMethod = $healthServiceSettings | Get-Member -Name 'SetProxyInfo'
if (!$proxyMethod)
{
Write-Output 'Health Service proxy API not present, will not update settings.'
return
}
Write-Output "Clearing proxy settings."

$healthServiceSettings.SetProxyInfo('', '', '')
$ProxyUserName = $cred.username
Write-Output "Setting proxy to $ProxyDomainName with proxy username $ProxyUserName."

$healthServiceSettings.SetProxyInfo($ProxyDomainName, $ProxyUserName, $cred.GetNetworkCredential().password)
Linux agent
Perform the following steps if your Linux computers need to communicate through a proxy server or Log
Analytics gateway. The proxy configuration value has the following syntax
[protocol://][user:password@]proxyhost[:port] . The proxyhost property accepts a fully qualified domain name or
IP address of the proxy server.
1. Edit the file /etc/opt/microsoft/omsagent/proxy.conf by running the following commands and change the
values to your specific settings.
proxyconf="https://proxyuser:proxypassword@proxyserver01:30443"
sudo echo $proxyconf >>/etc/opt/microsoft/omsagent/proxy.conf
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/proxy.conf
sudo /opt/microsoft/omsagent/bin/service_control restart [<workspace id>]
Uninstall agent
Use one of the following procedures to uninstall the Windows or Linux agent using the command line or setup
wizard.
Windows agent
Uninstall from Control Panel
2. In Control Panel, click Programs and Features.
3. In Programs and Features, click Microsoft Monitoring Agent, click Uninstall, and then click Yes.
NOTE
The Agent Setup Wizard can also be run by double-clicking MMASetup-<platform>.exe, which is available for download
from a workspace in the Azure portal.
Uninstall from the command line

The downloaded file for the agent is a self-contained installation package created with IExpress. The setup
program for the agent and supporting files are contained in the package and need to be extracted in order to
properly uninstall using the command line shown in the following example.
2. To extract the agent installation files, from an elevated command prompt run
extract MMASetup-<platform>.exe and it will prompt you for the path to extract files to. Alternatively, you can
specify the path by passing the arguments extract MMASetup-<platform>.exe /c:<Path> /t:<Path> . For more
information on the command-line switches supported by IExpress, see Command-line switches for IExpress
and then update the example to suit your needs.
3. At the prompt, type %WinDir%\System32\msiexec.exe /x <Path>:\MOMAgent.msi /qb .
Linux agent
To remove the agent, run the following command on the Linux computer. The --purge argument completely
removes the agent and its configuration.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
&& sh onboard_agent.sh --purge
Configure agent to report to an Operations Manager management
group
Windows agent
Perform the following steps to configure the Log Analytics agent for Windows to report to a System Center
Operations Manager management group.
NOTE
agent for Linux.

3. Click Microsoft Monitoring Agent and then click the Operations Manager tab.
4. If your Operations Manager servers have integration with Active Directory, click Automatically update
management group assignments from AD DS.
5. Click Add to open the Add a Management Group dialog box.
6. In Management group name field, type the name of your management group.
7. In the Primary management server field, type the computer name of the primary management server.
8. In the Management server port field, type the TCP port number.
9. Under Agent Action Account, choose either the Local System account or a local domain account.
10. Click OK to close the Add a Management Group dialog box and then click OK to close the Microsoft
Monitoring Agent Properties dialog box.
Linux agent
Perform the following steps to configure the Log Analytics agent for Linux to report to a System Center
Operations Manager management group.
NOTE
agent for Linux.
1. Edit the file /etc/opt/omi/conf/omiserver.conf
2. Ensure that the line beginning with httpsport= defines the port 1270. Such as: httpsport=1270
3. Restart the OMI server: sudo /opt/omi/bin/service_control restart
Next steps
Review Troubleshooting the Linux agent if you encounter issues while installing or managing the Linux
agent.
Review Troubleshooting the Windows agent if you encounter issues while installing or managing the
Windows agent.
Agent Health solution in Azure Monitor
The Agent Health solution in Azure helps you understand, for all of the agents reporting directly to the Log
Analytics workspace in Azure Monitor or a System Center Operations Manager management group connected to
Azure Monitor, which are unresponsive and submitting operational data. You can also keep track of how many
agents are deployed, where they are distributed geographically, and perform other queries to maintain awareness
of the distribution of agents deployed in Azure, other cloud environments, or on-premises.
Prerequisites
Before you deploy this solution, confirm you have currently supported Windows agents reporting to the Log
Analytics workspace or reporting to an Operations Manager management group integrated with your workspace.
Solution components
This solution consists of the following resources that are added to your workspace and directly connected agents
or Operations Manager connected management group.
Management packs
If your System Center Operations Manager management group is connected to a Log Analytics workspace, the
following management packs are installed in Operations Manager. These management packs are also installed on
directly connected Windows computers after adding this solution. There is nothing to configure or manage with
these management packs.
Microsoft System Center Advisor HealthAssessment Direct Channel Intelligence Pack
(Microsoft.IntelligencePacks.HealthAssessmentDirect)
Microsoft System Center Advisor HealthAssessment Server Channel Intelligence Pack
(Microsoft.IntelligencePacks.HealthAssessmentViaServer).
For more information on how solution management packs are updated, see Connect Operations Manager to Log
Analytics.
Configuration
Add the Agent Health solution to your Log Analytics workspace using the process described in Add solutions.
There is no further configuration required.
Data collection
Supported agents
The following table describes the connected sources that are supported by this solution.
CONNECTED SOURCE SUPPORTED DESCRIPTION
Windows agents Yes Heartbeat events are collected from

direct Windows agents.
System Center Operations Manager Yes Heartbeat events are collected from
management group agents reporting to the management
group every 60 seconds and then
forwarded to Azure Monitor. A direct
connection from Operations Manager
agents to Azure Monitor is not
required. Heartbeat event data is
forwarded from the management
group to the Log Analytics workspace.
Using the solution

When you add the solution to your Log Analytics workspace, the Agent Health tile will be added to your
dashboard. This tile shows the total number of agents and the number of unresponsive agents in the last 24 hours.
Click on the Agent Health tile to open the Agent Health dashboard. The dashboard includes the columns in the
following table. Each column lists the top ten events by count that match that column’s criteria for the specified
time range. You can run a log search that provides the entire list by selecting See all at the right bottom of each
column, or by clicking the column header.
COLUMN DESCRIPTION
Agent count over time A trend of your agent count over a period of seven days for
both Linux and Windows agents.
Count of unresponsive agents A list of agents that haven’t sent a heartbeat in the past 24
hours.
Distribution by OS Type A partition of how many Windows and Linux agents you have
in your environment.
Distribution by Agent Version A partition of the different agent versions installed in your
environment and a count of each one.
Distribution by Agent Category A partition of the different categories of agents that are
sending up heartbeat events: direct agents, OpsMgr agents,
or the OpsMgr Management Server.
Distribution by Management Group A partition of the different Operations Manager Management

groups in your environment.
COLUMN DESCRIPTION
Geo-location of Agents A partition of the different countries/regions where you have

agents and a total count of the number of agents that have
been installed in each country/region.
Count of Gateways Installed The number of servers that have the Log Analytics gateway
installed, and a list of these servers.
Azure Monitor log records

The solution creates one type of record in the Log Analytics workspace.
Heartbeat records
A record with a type of Heartbeat is created. These records have the properties in the following table.
Type Heartbeat
Category Value is Direct Agent, SCOM Agent, or SCOM Management

Server.
Computer Computer name.
OSType Windows or Linux operating system.
OSMajorVersion Operating system major version.
OSMinorVersion Operating system minor version.
Version Log Analytics Agent or Operations Manager Agent version.
SCAgentChannel Value is Direct and/or SCManagementServer.
IsGatewayInstalled If Log Analytics gateway is installed, value is true, otherwise

value is false.
ComputerIP IP address of the computer.

RemoteIPCountry Geographic location where computer is deployed.
ManagementGroupName Name of Operations Manager management group.
SourceComputerId Unique ID of computer.
RemoteIPLongitude Longitude of computer's geographic location.
RemoteIPLatitude Latitude of computer's geographic location.
Each agent reporting to an Operations Manager management server will send two heartbeats, and
SCAgentChannel property's value will include both Direct and SCManagementServer depending on what data
sources and monitoring solutions you have enabled in your subscription. If you recall, data from solutions are
either sent directly from an Operations Manager management server to Azure Monitor, or because of the volume
of data collected on the agent, are sent directly from the agent to Azure Monitor. For heartbeat events which have
the value SCManagementServer, the ComputerIP value is the IP address of the management server since the
data is actually uploaded by it. For heartbeats where SCAgentChannel is set to Direct, it is the public IP address of
the agent.
Sample log searches

The following table provides sample log searches for records collected by this solution.
QUERY DESCRIPTION
Heartbeat | distinct Computer Total number of agents
Heartbeat | summarize LastCall = max(TimeGenerated) by Count of unresponsive agents in the last 24 hours
Computer | where LastCall < ago(24h)
Heartbeat | summarize LastCall = max(TimeGenerated) by Count of unresponsive agents in the last 15 minutes
Computer | where LastCall < ago(15m)
Heartbeat | where TimeGenerated > ago(24h) and Computer Computers online (in the last 24 hours)
in ((Heartbeat | where TimeGenerated > ago(24h) | distinct
Computer)) | summarize LastCall = max(TimeGenerated) by
Computer
Heartbeat | where TimeGenerated > ago(24h) and Computer Total Agents Offline in Last 30 minutes (for the last 24 hours)
!in ((Heartbeat | where TimeGenerated > ago(30m) | distinct
Computer)) | summarize LastCall = max(TimeGenerated) by
Computer
Heartbeat | summarize AggregatedValue = dcount(Computer) Get a trend of number of agents over time by OSType
by OSType
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by OS Type

by OSType
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by Agent Version

by Version
QUERY DESCRIPTION
Heartbeat | summarize AggregatedValue = count() by Distribution by Agent Category

Category
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by Management Group

by ManagementGroupName
Heartbeat | summarize AggregatedValue = dcount(Computer) Geo-location of Agents

by RemoteIPCountry
Heartbeat | where iff(isnotnull(toint(IsGatewayInstalled)), Number of Log Analytics Gateways Installed

IsGatewayInstalled == true, IsGatewayInstalled == "true") ==
true | distinct Computer
Next steps
Learn about Alerts in Azure Monitor for details on generating alerts from log queries.
Troubleshooting the Log Analytics VM extension in
Azure Monitor
This article provides help troubleshooting errors you might experience with the Log Analytics VM extension for
Windows and Linux virtual machines running on Microsoft Azure, and suggests possible solutions to resolve them.
To verify the status of the extension, perform the following steps from the Azure portal.
1. Sign into the Azure portal.
2. In the Azure portal, click All services. In the list of resources, type virtual machines. As you begin typing,
the list filters based on your input. Select Virtual machines.
3. In your list of virtual machines, find and select it.
4. On the virtual machine, click Extensions.
5. From the list, check to see if the Log Analytics extension is enabled or not. For Linux, the agent is listed as
OMSAgentforLinux and for Windows, the agent is listed as MicrosoftMonitoringAgent.
6. Click on the extension to view details.

Troubleshooting Azure Windows VM extension
If the Microsoft Monitoring Agent VM extension is not installing or reporting, you can perform the following steps
to troubleshoot the issue.
1. Check if the Azure VM agent is installed and working correctly by using the steps in KB 2965986.
You can also review the VM agent log file C:\WindowsAzure\logs\WaAppAgent.log
If the log does not exist, the VM agent is not installed.
Install the Azure VM Agent
2. Review the Microsoft Monitoring Agent VM extension log files in
C:\Packages\Plugins\Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent
3. Ensure the virtual machine can run PowerShell scripts
4. Ensure permissions on C:\Windows\temp haven’t been changed
5. View the status of the Microsoft Monitoring Agent by typing the following in an elevated PowerShell window
on the virtual machine
(New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg').GetCloudWorkspaces() | Format-List
6. Review the Microsoft Monitoring Agent setup log files in
C:\Windows\System32\config\systemprofile\AppData\Local\SCOM\Logs
For more information, see troubleshooting Windows extensions.
Troubleshooting Linux VM extension

NOTE
agent for Linux.
If the Log Analytics agent for Linux VM extension is not installing or reporting, you can perform the following steps
to troubleshoot the issue.
1. If the extension status is Unknown check if the Azure VM agent is installed and working correctly by reviewing
the VM agent log file /var/log/waagent.log
If the log does not exist, the VM agent is not installed.
Install the Azure VM Agent on Linux VMs
2. For other unhealthy statuses, review the Log Analytics agent for Linux VM extension logs files in
/var/log/azure/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux/*/extension.log and
/var/log/azure/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux/*/CommandExecution.log
3. If the extension status is healthy, but data is not being uploaded review the Log Analytics agent for Linux log
files in /var/opt/microsoft/omsagent/log/omsagent.log
For more information, see troubleshooting Linux extensions.
Next steps
For additional troubleshooting guidance related to the Log Analytics agent for Linux hosted on computers outside
of Azure, see Troubleshoot Azure Log Analytics Linux Agent.
How to troubleshoot issues with the Log Analytics
agent for Windows
This article provides help troubleshooting errors you might experience with the Log Analytics agent for Windows
in Azure Monitor and suggests possible solutions to resolve them.
If none of these steps work for you, the following support channels are also available:
Customers with Premier support benefits can open a support request with Premier.
Customers with Azure support agreements can open a support request in the Azure portal.
Visit the Log Analytics Feedback page to review submitted ideas and bugs https://aka.ms/opinsightsfeedback
or file a new one.
Important troubleshooting sources

To assist with troubleshooting issues related to Log Analytics agent for Windows, the agent logs events to the
Windows Event Log, specifically under Application and Services\Operations Manager.
Connectivity issues
If the agent is communicating through a proxy server or firewall, there may be restrictions in place preventing
communication from the source computer and the Azure Monitor service. If communication is blocked,
misconfiguration, registration with a workspace may fail while attempting to install the agent, configure the agent
post-setup to report to an additional workspace, or agent communication fails after successful registration. This
section describes the methods to troubleshoot this type of issue with the Windows agent.
Double check that the firewall or proxy is configured to allow the following ports and URLs described in the
following table. Also confirm HTTP inspection is not enabled for web traffic, as it can prevent a secure TLS channel
between the agent and Azure Monitor.
AGENT RESOURCE PORTS DIRECTION BYPASS HTTPS INSPECTION
*.ods.opinsights.azure.com Port 443 Outbound Yes
*.oms.opinsights.azure.com Port 443 Outbound Yes
*.blob.core.windows.net Port 443 Outbound Yes
*.azure-automation.net Port 443 Outbound Yes
For firewall information required for Azure Government, see Azure Government management.
There are several ways you can verify if the agent is successfully communicating with Azure Monitor.
Enable the Azure Log Analytics Agent Health assessment in the workspace. From the Agent Health
dashboard, view the Count of unresponsive agents column to quickly see if the agent is listed.
Run the following query to confirm the agent is sending a heartbeat to the workspace it is configured to
report to. Replace <ComputerName> with the actual name of the machine.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
If the computer is successfully communicating with the service, the query should return a result. If the
query did not return a result, first verify the agent is configured to report to the correct workspace. If it is
configured correctly, proceed to step 3 and search the Windows Event Log to identify if the agent is logging
what issue might be preventing it from communicating with Azure Monitor.
Another method to identify a connectivity issue is by running the TestCloudConnectivity tool. The tool is
installed by default with the agent in the folder %SystemRoot%\Program Files\Microsoft Monitoring
Agent\Agent. From an elevated command prompt, navigate to the folder and run the tool. The tool returns
the results and highlights where the test failed (for example, if it was related to a particular port/URL that
was blocked).
Filter the Operations Manager event log by Event sources - Health Service Modules, HealthService, and
Service Connector and filter by Event Level Warning and Error to confirm if it has written events from the
following table. If they are, review the resolution steps included for each possible event.
EVENT ID SOURCE DESCRIPTION RESOLUTION
2133 & 2129 Health Service Connection to the service This error can occur when
from the agent failed the agent cannot
communicate directly or
through a firewall/proxy
server to the Azure
Monitor service. Verify
agent proxy settings or
that the network
firewall/proxy allows TCP
traffic from the computer
to the service.
2138 Health Service Modules Proxy requires Configure the agent proxy
authentication settings and specify the
username/password
required to authenticate
with the proxy server.
2129 Health Service Modules Failed connection/Failed Check your network

SSL negotiation adapter TCP/IP settings
and agent proxy settings.
2127 Health Service Modules Failure sending data If it only happens

received error code periodically during the day,
it could just be a random
anomaly that can be
ignored. Monitor to
understand how often it
happens. If it happens
often throughout the day,
first check your network
configuration and proxy
settings. If the description
includes HTTP error code
404 and it's the first time
that the agent tries to
send data to the service, it
will include a 500 error
with an inner 404 error
code. 404 means not
found, which indicates that
the storage area for the
new workspace is still
being provisioned. On next
retry, data will successfully
write to the workspace as
expected. An HTTP error
403 might indicate a
permission or credentials
issue. There is more
information included with
the 403 error to help
troubleshoot the issue.
4000 Service Connector DNS name resolution The machine could not
failed resolve the Internet
address used when
sending data to the
service. This might be DNS
resolver settings on your
machine, incorrect proxy
settings, or maybe a
temporary DNS issue with
your provider. If it happens
periodically, it could be
caused by a transient
network-related issue.
4001 Service Connector Connection to the service This error can occur when
failed. the agent cannot
communicate directly or
through a firewall/proxy
server to the Azure
Monitor service. Verify
agent proxy settings or
that the network
firewall/proxy allows TCP
traffic from the computer
to the service.
4002 Service Connector The service returned HTTP This error is written during
status code 403 in the agent’s initial
response to a query. registration phase and
Check with the service you’ll see a URL similar to
administrator for the the following:
health of the service. The https://<workspaceID>.o
query will be retried later. ms.opinsights.azure.com/
AgentService.svc/AgentTo
pologyRequest. An error
code 403 means forbidden
and can be caused by a
mistyped Workspace ID or
key, or the data and time
is incorrect on the
computer. If the time is +/-
15 minutes from current
time, then onboarding
fails. To correct this,
update the date and/or
timezone of your Windows
computer.
Data collection issues

After the agent is installed and reports to its configured workspace or workspaces, it may stop receiving
configuration, collecting or forwarding performance, logs, or other data to the service depending on what is
enabled and targeting the computer. It is necessary to determine if:
Is it a particular data type or all data that is not available in the workspace?
Is the data type specified by a solution or specified as part of the workspace data collection configuration?
How many computers are affected? Is it a single or multiple computers reporting to the workspace?
Was it working and did it stop at a particular time of day, or has it never been collected?
Is the log search query you are using syntactically correct?
Has the agent ever received its configuration from Azure Monitor?
The first step in troubleshooting is to determine if the computer is sending a heartbeat event.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
If the query returns results, then you need to determine if a particular data type is not collected and forwarded to
the service. This could be caused by the agent not receiving updated configuration from the service, or some other
symptom preventing the agent from operating normally. Perform the following steps to further troubleshoot.
1. Open an elevated command prompt on the computer and restart the agent service by typing
net stop healthservice && net start healthservice .
2. Open the Operations Manager event log and search for event IDs 7023, 7024, 7025, 7028 and 1210 from
Event source HealthService. These events indicate the agent is successfully receiving configuration from
Azure Monitor and they are actively monitoring the computer. The event description for event ID 1210 will
also specify on the last line all of the solutions and Insights that are included in the scope of monitoring on
the agent.
3. If after several minutes you do not see the expected data in the query results or visualization, depending on
if you are viewing the data from a solution or Insight, from the Operations Manager event log, search for
Event sources HealthService and Health Service Modules and filter by Event Level Warning and Error to
confirm if it has written events from the following table.
8000 HealthService This event will specify if a Event ID 2136 from source
workflow related to HealthService is written
performance, event, or together with this event
other data type collected is and can indicate the agent
unable to forward to the is unable to communicate
service for ingestion to the with the service, possibly
workspace. due to misconfiguration of
the proxy and
authentication settings,
network outage, or the
network firewall/proxy
does not allow TCP traffic
from the computer to the
service.
10102 and 10103 Health Service Modules Workflow could not This can occur if the
resolve data source. specified performance
counter or instance does
not exist on the computer
or is incorrectly defined in
the workspace data
settings. If this is a user-
specified performance
counter, verify the
information specified is
following the correct
format and exists on the
target computers.
26002 Health Service Modules Workflow could not This can occur if the
resolve data source. specified Windows event
log does not exist on the
computer. This error can
be safely ignored if the
computer is not expected
to have this event log
registered, otherwise if this
is a user-specified event
log, verify the information
specified is correct.
How to troubleshoot issues with the Log Analytics
agent for Linux
This article provides help troubleshooting errors you might experience with the Log Analytics agent for Linux in
Azure Monitor and suggests possible solutions to resolve them.
If none of these steps work for you, the following support channels are also available:
Customers with Premier support benefits can open a support request with Premier.
Customers with Azure support agreements can open a support request in the Azure portal.
Diagnose OMI Problems with the OMI troubleshooting guide.
File a GitHub Issue.
Visit the Log Analytics Feedback page to review submitted ideas and bugs https://aka.ms/opinsightsfeedback
or file a new one.
Important log locations and Log Collector tool

FILE PATH
Log Analytics agent for Linux log file /var/opt/microsoft/omsagent/<workspace

id>/log/omsagent.log
Log Analytics agent configuration log file /var/opt/microsoft/omsconfig/omsconfig.log
We recommend you to use our log collector tool to retrieve important logs for troubleshooting or before
submitting a GitHub issue. You can read more about the tool and how to run it here.
Important configuration files

CATEGORY FILE LOCATION
Syslog /etc/syslog-ng/syslog-ng.conf or /etc/rsyslog.conf

or /etc/rsyslog.d/95-omsagent.conf
Performance, Nagios, Zabbix, Log Analytics output and /etc/opt/microsoft/omsagent/<workspace

general agent id>/conf/omsagent.conf
Additional configurations /etc/opt/microsoft/omsagent/<workspace

id>/conf/omsagent.d/*.conf
NOTE
Editing configuration files for performance counters and Syslog is overwritten if the collection is configured from the data
menu Log Analytics Advanced Settings in the Azure portal for your workspace. To disable configuration for all agents, disable
collection from Log Analytics Advanced Settings or for a single agent run the following:
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable'
Installation error codes
ERROR CODE MEANING
NOT_DEFINED Because the necessary dependencies Installation of auoms failed, install

are not installed, the auoms auditd package auditd.
plugin will not be installed
2 Invalid option provided to the shell

bundle. Run
sudo sh ./omsagent-
*.universal*.sh --help
for usage
3 No option provided to the shell bundle.

Run
sudo sh ./omsagent-
*.universal*.sh --help
for usage.
4 Invalid package type OR invalid proxy

settings; omsagent-rpm.sh packages
can only be installed on RPM-based
systems, and omsagent-deb.sh
packages can only be installed on
Debian-based systems. It is recommend
you use the universal installer from the
latest release. Also review to verify your
proxy settings.
5 The shell bundle must be executed as

root OR there was 403 error returned
during onboarding. Run your command
using sudo .
6 Invalid package architecture OR there

was error 200 error returned during
onboarding; omsagent-x64.sh
packages can only be installed on 64-
bit systems, and omsagent-x86.sh
packages can only be installed on 32-
bit systems. Download the correct
package for your architecture from the
latest release.
17 Installation of OMS package failed.

Look through the command output for
the root failure.
19 Installation of OMI package failed. Look

through the command output for the
root failure.
20 Installation of SCX package failed. Look

root failure.
ERROR CODE MEANING
21 Installation of Provider kits failed. Look

root failure.
22 Installation of bundled package failed.

Look through the command output for
the root failure
23 SCX or OMI package already installed.

Use --upgrade instead of
--install to install the shell bundle.
30 Internal bundle error. File a GitHub

Issue with details from the output.
55 Unsupported openssl version OR

Cannot connect to Azure Monitor OR
dpkg is locked OR missing curl
program.
61 Missing Python ctypes library. Install

the Python ctypes library or package
(python-ctypes).
62 Missing tar program, install tar.
63 Missing sed program, install sed.
64 Missing curl program, install curl.
65 Missing gpg program, install gpg.
Onboarding error codes

ERROR CODE MEANING
2 Invalid option provided to the omsadmin script. Run

sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h
for usage.
3 Invalid configuration provided to the omsadmin script. Run

sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h
for usage.
4 Invalid proxy provided to the omsadmin script. Verify the

proxy and see our documentation for using an HTTP proxy.
5 403 HTTP error received from Azure Monitor. See the full
output of the omsadmin script for details.
6 Non-200 HTTP error received from Azure Monitor. See the full
ERROR CODE MEANING
7 Unable to connect to Azure Monitor. See the full output of

the omsadmin script for details.
8 Error onboarding to Log Analytics workspace. See the full

30 Internal script error. File a GitHub Issue with details from the
output.
31 Error generating agent ID. File a GitHub Issue with details

from the output.
32 Error generating certificates. See the full output of the

omsadmin script for details.
33 Error generating metaconfiguration for omsconfig. File a

GitHub Issue with details from the output.
34 Metaconfiguration generation script not present. Retry

onboarding with
sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w
<Workspace ID> -s <Workspace Key>
.
Enable debug logging

OMS output plugin debug
FluentD allows for plugin-specific logging levels allowing you to specify different log levels for inputs and outputs.
To specify a different log level for OMS output, edit the general agent configuration at
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf .
In the OMS output plugin, before the end of the configuration file, change the log_level property from info to
debug :
<match oms.** docker.**>

type out_oms
log_level debug
num_threads 5
buffer_chunk_limit 5m
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
buffer_queue_limit 10
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
Debug logging allows you to see batched uploads to Azure Monitor separated by type, number of data items, and
time taken to send:
Example debug enabled log:
Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s
Verbose output
Instead of using the OMS output plugin you can also output data items directly to stdout , which is visible in the
Log Analytics agent for Linux log file.
In the Log Analytics general agent configuration file at
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf , comment out the OMS output plugin by adding a
# in front of each line:
#<match oms.** docker.**>

# type out_oms
# log_level info
# num_threads 5
# buffer_chunk_limit 5m
# buffer_type file
# buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
# buffer_queue_limit 10
# flush_interval 20s
# retry_limit 10
# retry_wait 30s
#</match>
Below the output plugin, uncomment the following section by removing the # in front of each line:
<match **>
type stdout
</match>
Issue: Unable to connect through proxy to Azure Monitor

Probable causes
The proxy specified during onboarding was incorrect
The Azure Monitor and Azure Automation Service Endpoints are not whitelisted in your datacenter
Resolution
1. Reonboard to Azure Monitor with the Log Analytics agent for Linux by using the following command with
the option -v enabled. It allows verbose output of the agent connecting through the proxy to Azure
Monitor. /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v
2. Review the section Update proxy settings to verify you have properly configured the agent to communicate
through a proxy server.
Double check that the following Azure Monitor endpoints are whitelisted:
AGENT RESOURCE PORTS DIRECTION
*.ods.opinsights.azure.com Port 443 Inbound and outbound
*.oms.opinsights.azure.com Port 443 Inbound and outbound
*.blob.core.windows.net Port 443 Inbound and outbound

AGENT RESOURCE PORTS DIRECTION
*.azure-automation.net Port 443 Inbound and outbound
Issue: You receive a 403 error when trying to onboard

Probable causes
Date and Time is incorrect on Linux Server
Workspace ID and Workspace Key used are not correct
Resolution
1. Check the time on your Linux server with the command date. If the time is +/- 15 minutes from current time,
then onboarding fails. To correct this update the date and/or timezone of your Linux server.
2. Verify you have installed the latest version of the Log Analytics agent for Linux. The newest version now
notifies you if time skew is causing the onboarding failure.
3. Reonboard using correct Workspace ID and Workspace Key following the installation instructions earlier in this
article.
Issue: You see a 500 and 404 error in the log file right after onboarding
This is a known issue that occurs on first upload of Linux data into a Log Analytics workspace. This does not affect
data being sent or service experience.
Issue: You see omiagent using 100% CPU

Probable causes
A regression in nss-pem package v1.0.3-5.el7 caused a severe performance issue, that we've been seeing come up
a lot in Redhat/Centos 7.x distributions. To learn more about this issue, check the following documentation: Bug
1667121 Performance regression in libcurl.
Performance related bugs don't happen all the time, and they are very difficult to reproduce. If you experience
such issue with omiagent you should use the script omiHighCPUDiagnostics.sh which will collect the stack trace of
the omiagent when exceeding a certain threshold.
1. Download the script
wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-
Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh
2. Run diagnostics for 24 hours with 30% CPU threshold

bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30
3. Callstack will be dumped in omiagent_trace file, If you notice many Curl and NSS function calls, follow
resolution steps below.
Resolution (step by step)
1. Upgrade the nss-pem package to v1.0.3-5.el7_6.1.
sudo yum upgrade nss-pem
2. If nss-pem is not available for upgrade (mostly happens on Centos), then downgrade curl to 7.29.0-46. If by
mistake you run "yum update", then curl will be upgraded to 7.29.0-51 and the issue will happen again.
sudo yum downgrade curl libcurl
3. Restart OMI:
sudo scxadmin -restart
Issue: You are not seeing any data in the Azure portal
Probable causes
Onboarding to Azure Monitor failed
Connection to Azure Monitor is blocked
Log Analytics agent for Linux data is backed up
Resolution
1. Check if onboarding Azure Monitor was successful by checking if the following file exists:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf
2. Reonboard using the omsadmin.sh command-line instructions

3. If using a proxy, refer to the proxy resolution steps provided earlier.
4. In some cases, when the Log Analytics agent for Linux cannot communicate with the service, data on the
agent is queued to the full buffer size, which is 50 MB. The agent should be restarted by running the
following command: /opt/microsoft/omsagent/bin/service_control restart [<workspace id>] .
NOTE
This issue is fixed in agent version 1.1.0-28 and later.
Issue: You are not seeing forwarded Syslog messages

Probable causes
The configuration applied to the Linux server does not allow collection of the sent facilities and/or log levels
Syslog is not being forwarded correctly to the Linux server
The number of messages being forwarded per second are too great for the base configuration of the Log
Analytics agent for Linux to handle
Resolution
Verify the configuration in the Log Analytics workspace for Syslog has all the facilities and the correct log
levels. Review configure Syslog collection in the Azure portal
Verify the native syslog messaging daemons ( rsyslog , syslog-ng ) are able to receive the forwarded messages
Check firewall settings on the Syslog server to ensure that messages are not being blocked
Simulate a Syslog message to Log Analytics using logger command
logger -p local0.err "This is my test message"
Issue: You are receiving Errno address already in use in omsagent log
file
If you see
[error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use -
bind(2) for "127.0.0.1" port 25224>
in omsagent.log.
Probable causes
This error indicates that the Linux Diagnostic extension (LAD ) is installed side by side with the Log Analytics Linux
VM extension, and it is using same port for syslog data collection as omsagent.
Resolution
1. As root, execute the following commands (note that 25224 is an example and it is possible that in your
environment you see a different port number used by LAD ):
/opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229
sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
You then need to edit the correct rsyslogd or syslog_ng config file and change the LAD -related
configuration to write to port 25229.
2. If the VM is running rsyslogd , the file to be modified is: /etc/rsyslog.d/95-omsagent.conf (if it exists, else
/etc/rsyslog ). If the VM is running syslog_ng , the file to be modified is: /etc/syslog-ng/syslog-ng.conf .
3. Restart omsagent sudo /opt/microsoft/omsagent/bin/service_control restart .

4. Restart syslog service.
Issue: You are unable to uninstall omsagent using purge option

Probable causes
Linux Diagnostic Extension is installed
Linux Diagnostic Extension was installed and uninstalled, but you still see an error about omsagent being used
by mdsd and cannot be removed.
Resolution
1. Uninstall the Linux Diagnostic Extension (LAD ).
2. Remove Linux Diagnostic Extension files from the machine if they are present in the following location:
/var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ and
/var/opt/microsoft/omsagent/LAD/ .
Issue: You cannot see data any Nagios data

Probable causes
Omsagent user does not have permissions to read from Nagios log file
Nagios source and filter have not been uncommented from omsagent.conf file
Resolution
1. Add omsagent user to read from Nagios file by following these instructions.
2. In the Log Analytics agent for Linux general configuration file at
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf , ensure that both the Nagios source and
filter are uncommented.
<source>
type tail
path /var/log/nagios/nagios.log
format none
tag oms.nagios
</source>
<filter oms.nagios>
type filter_nagios_log
</filter>
Issue: You are not seeing any Linux data

Probable causes
Onboarding to Azure Monitor failed
Connection to Azure Monitor is blocked
Virtual machine was rebooted
OMI package was manually upgraded to a newer version compared to what was installed by Log Analytics
agent for Linux package
DSC resource logs class not found error in omsconfig.log log file
Log Analytics agent for data is backed up
DSC logs Current configuration does not exist. Execute Start-DscConfiguration command with -Path
parameter to specify a configuration file and create a current configuration first. in omsconfig.log log file, but
no log message exists about PerformRequiredConfigurationChecks operations.
Resolution
1. Install all dependencies like auditd package.
2. Check if onboarding to Azure Monitor was successful by checking if the following file exists:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf . If it was not, reonboard using the
omsadmin.sh command line instructions.
3. If using a proxy, check proxy troubleshooting steps above.
4. In some Azure distribution systems, omid OMI server daemon does not start after the virtual machine is
rebooted. This will result in not seeing Audit, ChangeTracking, or UpdateManagement solution-related data.
The workaround is to manually start omi server by running sudo /opt/omi/bin/service_control restart .
5. After OMI package is manually upgraded to a newer version, it has to be manually restarted for Log
Analytics agent to continue functioning. This step is required for some distros where OMI server does not
automatically start after it is upgraded. Run sudo /opt/omi/bin/service_control restart to restart OMI.
6. If you see DSC resource class not found error in omsconfig.log, run
sudo /opt/omi/bin/service_control restart .
7. In some cases, when the Log Analytics agent for Linux cannot talk to Azure Monitor, data on the agent is
backed up to the full buffer size: 50 MB. The agent should be restarted by running the following command
/opt/microsoft/omsagent/bin/service_control restart .
NOTE
This issue is fixed in Agent version 1.1.0-28 or later
If omsconfig.log log file does not indicate that PerformRequiredConfigurationChecks operations are running
periodically on the system, there might be a problem with the cron job/service. Make sure cron job exists
under /etc/cron.d/OMSConsistencyInvoker . If needed run the following commands to create the cron job:
mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee
/etc/cron.d/OMSConsistencyInvoker
Also, make sure the cron service is running. You can use service cron status with Debian, Ubuntu, SUSE,
or service crond status with RHEL, CentOS, Oracle Linux to check the status of this service. If the service
does not exist, you can install the binaries and start the service using the following:
Ubuntu/Debian
# To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start
SUSE

sudo zypper in cron -y
sudo systemctl enable cron
sudo systemctl start cron
RHEL/CeonOS

sudo yum install -y crond
sudo service crond start
Oracle Linux

sudo yum install -y cronie
sudo service crond start
Issue: When configuring collection from the portal for Syslog or Linux
performance counters, the settings are not applied
Probable causes
The Log Analytics agent for Linux has not picked up the latest configuration
The changed settings in the portal were not applied
Resolution
Background: omsconfig is the Log Analytics agent for Linux configuration agent that looks for new portal-side
configuration every five minutes. This configuration is then applied to the Log Analytics agent for Linux
configuration files located at /etc/opt/microsoft/omsagent/conf/omsagent.conf.
In some cases, the Log Analytics agent for Linux configuration agent might not be able to communicate with
the portal configuration service resulting in latest configuration not being applied.
1. Check that the omsconfig agent is installed by running dpkg --list omsconfig or rpm -qi omsconfig
. If it is not installed, reinstall the latest version of the Log Analytics agent for Linux.
2. Check that the omsconfig agent can communicate with Azure Monitor by running the following
command sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' .
This command returns the configuration that agent receives from the service, including Syslog
settings, Linux performance counters, and custom logs. If this command fails, run the following
command
sudo su omsagent -c 'python
/opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'
. This command forces the omsconfig agent to talk to Azure Monitor and retrieve the latest
configuration.
Issue: You are not seeing any custom log data
Probable causes
Onboarding to Azure Monitor failed.
The setting Apply the following configuration to my Linux Servers has not been selected.
omsconfig has not picked up the latest custom log configuration from the service.
Log Analytics agent for Linux user omsagent is unable to access the custom log due to permissions or not
being found. You may see the following errors:
[DATETIME] [warn]: file not found. Continuing without tailing it.
[DATETIME] [error]: file not accessible by omsagent.
Known Issue with Race Condition fixed in Log Analytics agent for Linux version 1.1.0-217
Resolution
1. Verify onboarding to Azure Monitor was successful by checking if the following file exists:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf . If not, either:
2. Reonboard using the omsadmin.sh command line instructions.

3. Under Advanced Settings in the Azure portal, ensure that the setting Apply the following
configuration to my Linux Servers is enabled.
4. Check that the omsconfig agent can communicate with Azure Monitor by running the following command
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' . This command
returns the configuration that agent receives from the service, including Syslog settings, Linux performance
counters, and custom logs. If this command fails, run the following command
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py . This
command forces the omsconfig agent to talk to Azure Monitor and retrieve the latest configuration.
Background: Instead of the Log Analytics agent for Linux running as a privileged user - root , the agent runs as
the omsagent user. In most cases, explicit permission must be granted to this user in order for certain files to be
read. To grant permission to omsagent user, run the following commands:
1. Add the omsagent user to specific group sudo usermod -a -G <GROUPNAME> <USERNAME>
2. Grant universal read access to the required file sudo chmod -R ugo+rx <FILE DIRECTORY>
There is a known issue with a race condition with the Log Analytics agent for Linux version earlier than 1.1.0-217.
After updating to the latest agent, run the following command to get the latest version of the output plugin
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace
id>/conf/omsagent.conf
.
Issue: You are trying to reonboard to a new workspace

When you try to reonboard an agent to a new workspace, the Log Analytics agent configuration needs to be
cleaned up before reonboarding. To clean up old configuration from the agent, run the shell bundle with --purge
sudo sh ./omsagent-*.universal.x64.sh --purge
Or
sudo sh ./onboard_agent.sh --purge
You can continue reonboard after using the --purge option

Log Analytics agent extension in the Azure portal is marked with a
failed state: Provisioning failed
Probable causes
Log Analytics agent has been removed from the operating system
Log Analytics agent service is down, disabled, or not configured
Resolution
Perform the following steps to correct the issue.
1. Remove extension from Azure portal.
2. Install the agent following the instructions.
sudo /opt/microsoft/omsagent/bin/service_control restart .
Wait several minutes and the provisioning state changes to Provisioning succeeded.
Issue: The Log Analytics agent upgrade on-demand

Probable causes
The Log Analytics agent packages on the host are outdated.
Resolution
Perform the following steps to correct the issue.
1. Check for the latest release on page.
2. Download install script (1.4.2-124 as example version):
wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-
124/omsagent-1.4.2-124.universal.x64.sh
3. Upgrade packages by executing sudo sh ./omsagent-*.universal.x64.sh --upgrade .

Agent data sources in Azure Monitor
The data that Azure Monitor collects from agents is defined by the data sources that you configure. The data
from agents is stored as log data with a set of records. Each data source creates records of a particular type with
each type having its own set of properties.
Summary of data sources

The following table lists the agent data sources that are currently available in Azure Monitor. Each has a link to a
separate article providing detail for that data source. It also provides information on their method and frequency
of collection.
OPERATION
S MANAGER
AGENT
DATA SENT
LOG OPERATION OPERATION VIA
DATA ANALYTICS S MANAGER AZURE S MANAGER MANAGEME COLLECTION
SOURCE PLATFORM AGENT AGENT STORAGE REQUIRED? NT GROUP FREQUENCY
Custom Windows • on arrival

logs
Custom Linux • on arrival

logs
IIS logs Windows • • • depends on

Log File
Rollover
setting
Performanc Windows • • as
e counters scheduled,
minimum of
10 seconds
OPERATION
S MANAGER
AGENT
DATA SENT
LOG OPERATION OPERATION VIA
DATA ANALYTICS S MANAGER AZURE S MANAGER MANAGEME COLLECTION
SOURCE PLATFORM AGENT AGENT STORAGE REQUIRED? NT GROUP FREQUENCY
Performanc Linux • as
e counters scheduled,
minimum of
10 seconds
Syslog Linux • from Azure

storage: 10
minutes;
from agent:
on arrival
Windows Windows • • • • on arrival

Event logs
Configuring data sources

You configure data sources from the Data menu in Advanced Settings for the workspace. Any configuration is
delivered to all connected sources in your workspace. You cannot currently exclude any agents from this
configuration.
1. In the Azure portal, select Log Analytics workspaces > your workspace > Advanced Settings.
2. Select Data.
3. Click on the data source you want to configure.
4. Follow the link to the documentation for each data source in the above table for details on their configuration.
Data collection
Data source configurations are delivered to agents that are directly connected to Azure Monitor within a few
minutes. The specified data is collected from the agent and delivered directly to Azure Monitor at intervals
specific to each data source. See the documentation for each data source for these specifics.
For System Center Operations Manager agents in a connected management group, data source configurations
are translated into management packs and delivered to the management group every 5 minutes by default. The
agent downloads the management pack like any other and collects the specified data. Depending on the data
source, the data will be either sent to a management server which forwards the data to the Azure Monitor, or the
agent will send the data to Azure Monitor without going through the management server. See Data collection
details for monitoring solutions in Azure for details. You can read about details of connecting Operations
Manager and Azure Monitor and modifying the frequency that configuration is delivered at Configure
Integration with System Center Operations Manager.
If the agent is unable to connect to Azure Monitor or Operations Manager, it will continue to collect data that it
will deliver when it establishes a connection. Data can be lost if the amount of data reaches the maximum cache
size for the client, or if the agent is not able to establish a connection within 24 hours.
Log records
All log data collected by Azure Monitor is stored in the workspace as records. Records collected by different data
sources will have their own set of properties and be identified by their Type property. See the documentation for
each data source and solution for details on each record type.
Next steps
Learn about monitoring solutions that add functionality to Azure Monitor and also collect data into the
workspace.
Learn about log queries to analyze the data collected from data sources and monitoring solutions.
Configure alerts to proactively notify you of critical data collected from data sources and monitoring solutions.
Windows event log data sources in Azure Monitor
Windows Event logs are one of the most common data sources for collecting data using Windows agents since
many applications write to the Windows event log. You can collect events from standard logs such as System and
Application in addition to specifying any custom logs created by applications you need to monitor.
Configuring Windows Event logs

Configure Windows Event logs from the Data menu in Advanced Settings.
Azure Monitor only collects events from the Windows event logs that are specified in the settings. You can add an
event log by typing in the name of the log and clicking +. For each log, only the events with the selected severities
are collected. Check the severities for the particular log that you want to collect. You cannot provide any additional
criteria to filter events.
As you type the name of an event log, Azure Monitor provides suggestions of common event log names. If the
log you want to add does not appear in the list, you can still add it by typing in the full name of the log. You can
find the full name of the log by using event viewer. In event viewer, open the Properties page for the log and copy
the string from the Full Name field.
NOTE
Critical events from the Windows event log will have a severity of "Error" in Azure Monitor Logs.
Data collection
Azure Monitor collects each event that matches a selected severity from a monitored event log as the event is
created. The agent records its place in each event log that it collects from. If the agent goes offline for a period of
time, then it collects events from where it last left off, even if those events were created while the agent was
offline. There is a potential for these events to not be collected if the event log wraps with uncollected events
being overwritten while the agent is offline.
NOTE
Azure Monitor does not collect audit events created by SQL Server from source MSSQLSERVER with event ID 18453 that
contains keywords - Classic or Audit Success and keyword 0xa0000000000000.
Windows event records properties

Windows event records have a type of Event and have the properties in the following table:
Computer Name of the computer that the event was collected from.
EventCategory Category of the event.
EventData All event data in raw format.
EventID Number of the event.
EventLevel Severity of the event in numeric form.
EventLevelName Severity of the event in text form.
EventLog Name of the event log that the event was collected from.
ParameterXml Event parameter values in XML format.
ManagementGroupName Name of the management group for System Center

Operations Manager agents. For other agents, this value is
AOI-<workspace ID>
RenderedDescription Event description with parameter values
Source Source of the event.
SourceSystem Type of agent the event was collected from.

OpsManager – Windows agent, either direct connect or
Operations Manager managed
Linux – All Linux agents
AzureStorage – Azure Diagnostics
TimeGenerated Date and time the event was created in Windows.
UserName User name of the account that logged the event.

Log queries with Windows Events
The following table provides different examples of log queries that retrieve Windows Event records.
QUERY DESCRIPTION
Event All Windows events.
Event | where EventLevelName == "error" All Windows events with severity of error.
Event | summarize count() by Source Count of Windows events by source.
Event | where EventLevelName == "error" | summarize Count of Windows error events by source.
count() by Source
Next steps
Configure Log Analytics to collect other data sources for analysis.
Configure collection of performance counters from your Windows agents.
Collecting custom JSON data sources with the Log
Analytics agent for Linux in Azure Monitor
NOTE
agent for Linux.
Custom JSON data sources can be collected into Azure Monitor using the Log Analytics agent for Linux. These
custom data sources can be simple scripts returning JSON such as curl or one of FluentD's 300+ plugins. This
article describes the configuration required for this data collection.
NOTE
Log Analytics agent for Linux v1.1.0-217+ is required for Custom JSON Data
Configuration
Configure input plugin
To collect JSON data in Azure Monitor, add oms.api. to the start of a FluentD tag in an input plugin.
For example, following is a separate configuration file in
exec-json.conf
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/ . This uses the FluentD plugin exec to run a curl
command every 30 seconds. The output from this command is collected by the JSON output plugin.
<source>
type exec
command 'curl localhost/json.output'
format json
tag oms.api.httpresponse
run_interval 30s
</source>
<match oms.api.httpresponse>
type out_oms_api
log_level info
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms_api_httpresponse*.buffer
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
The configuration file added under /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/ will require to

have its ownership changed with the following command.
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/conf/omsagent.d/exec-json.conf
Configure output plugin

Add the following output plugin configuration to the main configuration in
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf or as a separate configuration file placed in
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/
<match oms.api.**>
type out_oms_api
log_level info
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms_api*.buffer
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
Restart Log Analytics agent for Linux

Restart the Log Analytics agent for Linux service with the following command.
sudo /opt/microsoft/omsagent/bin/service_control restart
Output
The data will be collected in Azure Monitor with a record type of <FLUENTD_TAG>_CL .
For example, the custom tag tag oms.api.tomcat in Azure Monitor with a record type of tomcat_CL . You could
retrieve all records of this type with the following log query.
Type=tomcat_CL
Nested JSON data sources are supported, but are indexed based off of parent field. For example, the following
JSON data is returned from a log query as tag_s : "[{ "a":"1", "b":"2" }] .
{
"tag": [{
"a":"1",
"b":"2"
}]
}
Next steps
Collect data from CollectD on Linux agents in Azure
Monitor
CollectD is an open source Linux daemon that periodically collects performance metrics from applications and
system level information. Example applications include the Java Virtual Machine (JVM ), MySQL Server, and Nginx.
This article provides information on collecting performance data from CollectD in Azure Monitor.
A full list of available plugins can be found at Table of Plugins.
The following CollectD configuration is included in the Log Analytics agent for Linux to route CollectD data to the
NOTE
agent for Linux.
LoadPlugin write_http
<Plugin write_http>
<Node "oms">
URL "127.0.0.1:26000/oms.collectd"
Format "JSON"
StoreRates true
</Node>
</Plugin>
Additionally, if using an versions of collectD before 5.5 use the following configuration instead.
LoadPlugin write_http
<Plugin write_http>
<URL "127.0.0.1:26000/oms.collectd">
Format "JSON"
StoreRates true
</URL>
</Plugin>
The CollectD configuration uses the default write_http plugin to send performance metric data over port 26000 to
NOTE
This port can be configured to a custom-defined port if needed.
The Log Analytics agent for Linux also listens on port 26000 for CollectD metrics and then converts them to Azure
Monitor schema metrics. The following is the Log Analytics agent for Linux configuration collectd.conf .
<source>
type http
port 26000
bind 127.0.0.1
</source>
<filter oms.collectd>
type filter_collectd
</filter>
NOTE
CollectD by default is set to read values at a 10-second interval. As this directly affects the volume of data sent to Azure
Monitor Logs, you might need to tune this interval within the CollectD configuration to strike a good balance between the
monitoring requirements and associated costs and usage for Azure Monitor Logs.
Versions supported
Azure Monitor currently supports CollectD version 4.8 and above.
Log Analytics agent for Linux v1.1.0-217 or above is required for CollectD metric collection.
Configuration
The following are basic steps to configure collection of CollectD data in Azure Monitor.
1. Configure CollectD to send data to the Log Analytics agent for Linux using the write_http plugin.
2. Configure the Log Analytics agent for Linux to listen for the CollectD data on the appropriate port.
3. Restart CollectD and Log Analytics agent for Linux.
Configure CollectD to forward data
1. To route CollectD data to the Log Analytics agent for Linux, oms.conf needs to be added to CollectD's
configuration directory. The destination of this file depends on the Linux distro of your machine.
If your CollectD config directory is located in /etc/collectd.d/:
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/oms.conf /etc/collectd.d/oms.conf
If your CollectD config directory is located in /etc/collectd/collectd.conf.d/:
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/oms.conf /etc/collectd/collectd.conf.d/oms.conf

NOTE
For CollectD versions before 5.5 you will have to modify the tags in oms.conf as shown above.
2. Copy collectd.conf to the desired workspace's omsagent configuration directory.
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/collectd.conf
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/collectd.conf
3. Restart CollectD and Log Analytics agent for Linux with the following commands.
sudo service collectd restart sudo /opt/microsoft/omsagent/bin/service_control restart
CollectD metrics to Azure Monitor schema conversion

To maintain a familiar model between infrastructure metrics already collected by Log Analytics agent for Linux and
the new metrics collected by CollectD the following schema mapping is used:
COLLECTD METRIC FIELD AZURE MONITOR FIELD
host Computer
plugin None
plugin_instance Instance Name

If plugin_instance is null then InstanceName="_Total"
type ObjectName
type_instance CounterName
If type_instance is null then CounterName=blank
dsnames[] CounterName
dstypes None
values[] CounterValue
Next steps
Use Custom Fields to parse data from syslog records into individual fields.
Syslog data sources in Azure Monitor
Syslog is an event logging protocol that is common to Linux. Applications will send messages that may be stored
on the local machine or delivered to a Syslog collector. When the Log Analytics agent for Linux is installed, it
configures the local Syslog daemon to forward messages to the agent. The agent then sends the message to
Azure Monitor where a corresponding record is created.
NOTE
Azure Monitor supports collection of messages sent by rsyslog or syslog-ng, where rsyslog is the default daemon. The
default syslog daemon on version 5 of Red Hat Enterprise Linux, CentOS, and Oracle Linux version (sysklog) is not
supported for syslog event collection. To collect syslog data from this version of these distributions, the rsyslog daemon
should be installed and configured to replace sysklog.
The following facilities are supported with the Syslog collector:

kern
user
mail
daemon
auth
syslog
lpr
news
uucp
cron
authpriv
ftp
local0-local7
For any other facility, configure a Custom Logs data source in Azure Monitor.
Configuring Syslog
The Log Analytics agent for Linux will only collect events with the facilities and severities that are specified in its
configuration. You can configure Syslog through the Azure portal or by managing configuration files on your
Linux agents.
Configure Syslog in the Azure portal
Configure Syslog from the Data menu in Advanced Settings. This configuration is delivered to the configuration
file on each Linux agent.
You can add a new facility by typing in its name and clicking +. For each facility, only messages with the selected
severities will be collected. Check the severities for the particular facility that you want to collect. You cannot
provide any additional criteria to filter messages.
By default, all configuration changes are automatically pushed to all agents. If you want to configure Syslog
manually on each Linux agent, then uncheck the box Apply below configuration to my machines.
Configure Syslog on Linux agent
When the Log Analytics agent is installed on a Linux client, it installs a default syslog configuration file that defines
the facility and severity of the messages that are collected. You can modify this file to change the configuration.
The configuration file is different depending on the Syslog daemon that the client has installed.
NOTE
If you edit the syslog configuration, you must restart the syslog daemon for the changes to take effect.
rsyslog
The configuration file for rsyslog is located at /etc/rsyslog.d/95-omsagent.conf. Its default contents are shown
below. This collects syslog messages sent from the local agent for all facilities with a level of warning or higher.
kern.warning @127.0.0.1:25224
user.warning @127.0.0.1:25224
daemon.warning @127.0.0.1:25224
auth.warning @127.0.0.1:25224
syslog.warning @127.0.0.1:25224
uucp.warning @127.0.0.1:25224
authpriv.warning @127.0.0.1:25224
ftp.warning @127.0.0.1:25224
cron.warning @127.0.0.1:25224
local0.warning @127.0.0.1:25224
local1.warning @127.0.0.1:25224
local2.warning @127.0.0.1:25224
local3.warning @127.0.0.1:25224
local4.warning @127.0.0.1:25224
local5.warning @127.0.0.1:25224
local6.warning @127.0.0.1:25224
local7.warning @127.0.0.1:25224
You can remove a facility by removing its section of the configuration file. You can limit the severities that are
collected for a particular facility by modifying that facility's entry. For example, to limit the user facility to messages
with a severity of error or higher you would modify that line of the configuration file to the following:
user.error @127.0.0.1:25224
syslog-ng
The configuration file for syslog-ng is location at /etc/syslog-ng/syslog-ng.conf. Its default contents are shown
below. This collects syslog messages sent from the local agent for all facilities and all severities.
#
# Warnings (except iptables) in one file:
#
destination warn { file("/var/log/warn" fsync(yes)); };
log { source(src); filter(f_warn); destination(warn); };
#OMS_Destination
destination d_oms { udp("127.0.0.1" port(25224)); };
#OMS_facility = auth
filter f_auth_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(auth); };
log { source(src); filter(f_auth_oms); destination(d_oms); };
#OMS_facility = authpriv
filter f_authpriv_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(authpriv); };
log { source(src); filter(f_authpriv_oms); destination(d_oms); };
#OMS_facility = cron
filter f_cron_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(cron); };
log { source(src); filter(f_cron_oms); destination(d_oms); };
#OMS_facility = daemon
filter f_daemon_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(daemon); };
log { source(src); filter(f_daemon_oms); destination(d_oms); };
#OMS_facility = kern
filter f_kern_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(kern); };
log { source(src); filter(f_kern_oms); destination(d_oms); };
#OMS_facility = local0
filter f_local0_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local0); };
log { source(src); filter(f_local0_oms); destination(d_oms); };
#OMS_facility = local1
filter f_local1_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local1); };
log { source(src); filter(f_local1_oms); destination(d_oms); };
#OMS_facility = mail
filter f_mail_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(mail); };
log { source(src); filter(f_mail_oms); destination(d_oms); };
#OMS_facility = syslog
filter f_syslog_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(syslog); };
log { source(src); filter(f_syslog_oms); destination(d_oms); };
#OMS_facility = user
filter f_user_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
You can remove a facility by removing its section of the configuration file. You can limit the severities that are
collected for a particular facility by removing them from its list. For example, to limit the user facility to just alert
and critical messages, you would modify that section of the configuration file to the following:
#OMS_facility = user
filter f_user_oms { level(alert,crit) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
Collecting data from additional Syslog ports

The Log Analytics agent listens for Syslog messages on the local client on port 25224. When the agent is installed,
a default syslog configuration is applied and found in the following location:
Rsyslog: /etc/rsyslog.d/95-omsagent.conf
Syslog-ng: /etc/syslog-ng/syslog-ng.conf
You can change the port number by creating two configuration files: a FluentD config file and a rsyslog-or-syslog-
ng file depending on the Syslog daemon you have installed.
The FluentD config file should be a new file located in: /etc/opt/microsoft/omsagent/conf/omsagent.d and
replace the value in the port entry with your custom port number.
<source>
type syslog
port %SYSLOG_PORT%
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>
<filter oms.syslog.**>
type filter_syslog
</filter>
For rsyslog, you should create a new configuration file located in: /etc/rsyslog.d/ and replace the value
%SYSLOG_PORT% with your custom port number.
NOTE
If you modify this value in the configuration file 95-omsagent.conf , it will be overwritten when the agent applies a
default configuration.
# OMS Syslog collection for workspace %WORKSPACE_ID%

kern.warning @127.0.0.1:%SYSLOG_PORT%
user.warning @127.0.0.1:%SYSLOG_PORT%
daemon.warning @127.0.0.1:%SYSLOG_PORT%
auth.warning @127.0.0.1:%SYSLOG_PORT%
The syslog-ng config should be modified by copying the example configuration shown below and adding
the custom modified settings to the end of the syslog-ng.conf configuration file located in /etc/syslog-ng/ .
Do not use the default label %WORKSPACE_ID%_oms or %WORKSPACE_ID_OMS, define a custom
label to help distinguish your changes.
NOTE
If you modify the default values in the configuration file, they will be overwritten when the agent applies a default
configuration.
filter f_custom_filter { level(warning) and facility(auth; };
destination d_custom_dest { udp("127.0.0.1" port(%SYSLOG_PORT%)); };
log { source(s_src); filter(f_custom_filter); destination(d_custom_dest); };
After completing the changes, the Syslog and the Log Analytics agent service needs to be restarted to ensure the
configuration changes take effect.
Syslog record properties

Syslog records have a type of Syslog and have the properties in the following table.
Computer Computer that the event was collected from.
Facility Defines the part of the system that generated the message.
HostIP IP address of the system sending the message.
HostName Name of the system sending the message.
SeverityLevel Severity level of the event.
SyslogMessage Text of the message.
ProcessID ID of the process that generated the message.
EventTime Date and time that the event was generated.
Log queries with Syslog records

The following table provides different examples of log queries that retrieve Syslog records.
QUERY DESCRIPTION
Syslog All Syslogs.
Syslog | where SeverityLevel == "error" All Syslog records with severity of error.
Syslog | summarize AggregatedValue = count() by Computer Count of Syslog records by computer.
Syslog | summarize AggregatedValue = count() by Facility Count of Syslog records by facility.
Next steps
Use Custom Fields to parse data from syslog records into individual fields.
Configure Linux agents to collect other types of data.
Windows and Linux performance data sources in
Azure Monitor
Performance counters in Windows and Linux provide insight into the performance of hardware components,
operating systems, and applications. Azure Monitor can collect performance counters at frequent intervals for
Near Real Time (NRT) analysis in addition to aggregating performance data for longer term analysis and
reporting.
Configuring Performance counters

Configure Performance counters from the Data menu in Advanced Settings.
When you first configure Windows or Linux Performance counters for a new workspace, you are given the
option to quickly create several common counters. They are listed with a checkbox next to each. Ensure that any
counters you want to initially create are checked and then click Add the selected performance counters.
For Windows performance counters, you can choose a specific instance for each performance counter. For Linux
performance counters, the instance of each counter that you choose applies to all child counters of the parent
counter. The following table shows the common instances available to both Linux and Windows performance
counters.
INSTANCE NAME DESCRIPTION
_Total Total of all the instances
* All instances
(/|/var) Matches instances named: / or /var

Follow this procedure to add a new Windows performance counter to collect.
1. Type the name of the counter in the text box in the format object(instance)\counter. When you start
typing, you are presented with a matching list of common counters. You can either select a counter from
the list or type in one of your own. You can also return all instances for a particular counter by specifying
object\counter.
When collecting SQL Server performance counters from named instances, all named instance counters
start with MSSQL$ and followed by the name of the instance. For example, to collect the Log Cache Hit
Ratio counter for all databases from the Database performance object for named SQL instance INST2,
specify MSSQL$INST2:Databases(*)\Log Cache Hit Ratio .
2. Click + or press Enter to add the counter to the list.
3. When you add a counter, it uses the default of 10 seconds for its Sample Interval. You can change this to
a higher value of up to 1800 seconds (30 minutes) if you want to reduce the storage requirements of the
collected performance data.
4. When you're done adding counters, click the Save button at the top of the screen to save the
configuration.
Linux performance counters
Follow this procedure to add a new Linux performance counter to collect.
1. By default, all configuration changes are automatically pushed to all agents. For Linux agents, a configuration
file is sent to the Fluentd data collector. If you wish to modify this file manually on each Linux agent, then
uncheck the box Apply below configuration to my Linux machines and follow the guidance below.
2. Type the name of the counter in the text box in the format object(instance)\counter. When you start typing,
you are presented with a matching list of common counters. You can either select a counter from the list or
type in one of your own.
3. Click + or press Enter to add the counter to the list of other counters for the object.
4. All counters for an object use the same Sample Interval. The default is 10 seconds. You change this to a
higher value of up to 1800 seconds (30 minutes) if you want to reduce the storage requirements of the
collected performance data.
5. When you're done adding counters, click the Save button at the top of the screen to save the configuration.
Configure Linux performance counters in configuration file
Instead of configuring Linux performance counters using the Azure portal, you have the option of editing
configuration files on the Linux agent. Performance metrics to collect are controlled by the configuration in
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.
Each object, or category, of performance metrics to collect should be defined in the configuration file as a single
<source> element. The syntax follows the pattern below.
<source>
type oms_omi
object_name "Processor"
instance_regex ".*"
counter_name_regex ".*"
interval 30s
</source>
The parameters in this element are described in the following table.
PARAMETERS DESCRIPTION
object_name Object name for the collection.

PARAMETERS DESCRIPTION
instance_regex A regular expression defining which instances to collect. The

value: .* specifies all instances. To collect processor metrics
for only the _Total instance, you could specify _Total . To
collect process metrics for only the crond or sshd instances,
you could specify: (crond\|sshd) .
counter_name_regex A regular expression defining which counters (for the object)

to collect. To collect all counters for the object, specify: .* .
To collect only swap space counters for the memory object,
for example, you could specify: .+Swap.+
interval Frequency at which the object's counters are collected.
The following table lists the objects and counters that you can specify in the configuration file. There are
additional counters available for certain applications as described in Collect performance counters for Linux
applications in Azure Monitor.
OBJECT NAME COUNTER NAME
Logical Disk % Free Inodes
Logical Disk % Free Space
Logical Disk % Used Inodes
Logical Disk % Used Space
Logical Disk Disk Read Bytes/sec
Logical Disk Disk Reads/sec
Logical Disk Disk Transfers/sec
Logical Disk Disk Write Bytes/sec
Logical Disk Disk Writes/sec
Logical Disk Free Megabytes
Logical Disk Logical Disk Bytes/sec
Memory % Available Memory
Memory % Available Swap Space
Memory % Used Memory
Memory % Used Swap Space
Memory Available MBytes Memory

Memory Available MBytes Swap
Memory Page Reads/sec
Memory Page Writes/sec
Memory Pages/sec
Memory Used MBytes Swap Space
Memory Used Memory MBytes
Network Total Bytes Transmitted
Network Total Bytes Received
Network Total Bytes
Network Total Packets Transmitted
Network Total Packets Received
Network Total Rx Errors
Network Total Tx Errors
Network Total Collisions
Physical Disk Avg. Disk sec/Read
Physical Disk Avg. Disk sec/Transfer
Physical Disk Avg. Disk sec/Write
Physical Disk Physical Disk Bytes/sec
Process Pct Privileged Time
Process Pct User Time
Process Used Memory kBytes
Process Virtual Shared Memory
Processor % DPC Time
Processor % Idle Time
Processor % Interrupt Time

Processor % IO Wait Time
Processor % Nice Time
Processor % Privileged Time
Processor % Processor Time
Processor % User Time
System Free Physical Memory
System Free Space in Paging Files
System Free Virtual Memory
System Processes
System Size Stored In Paging Files
System Uptime
System Users
Following is the default configuration for performance metrics.

<source>
type oms_omi
object_name "Physical Disk"
instance_regex ".*"
interval 5m
</source>
<source>
type oms_omi
object_name "Logical Disk"
instance_regex ".*
interval 5m
</source>
<source>
type oms_omi
object_name "Processor"
instance_regex ".*
interval 30s
</source>
<source>
type oms_omi
object_name "Memory"
instance_regex ".*"
interval 30s
</source>
Data collection
Azure Monitor collects all specified performance counters at their specified sample interval on all agents that
have that counter installed. The data is not aggregated, and the raw data is available in all log query views for the
duration specified by your subscription.
Performance record properties

Performance records have a type of Perf and have the properties in the following table.
Computer Computer that the event was collected from.
CounterName Name of the performance counter
CounterPath Full path of the counter in the form \\

<Computer>\object(instance)\counter.
CounterValue Numeric value of the counter.
InstanceName Name of the event instance. Empty if no instance.
ObjectName Name of the performance object

SourceSystem Type of agent the data was collected from.

SCOM
AzureStorage – Azure Diagnostics
TimeGenerated Date and time the data was sampled.
Sizing estimates
A rough estimate for collection of a particular counter at 10-second intervals is about 1 MB per day per instance.
You can estimate the storage requirements of a particular counter with the following formula.
1 MB x (number of counters) x (number of agents) x (number of instances)
Log queries with Performance records

The following table provides different examples of log queries that retrieve Performance records.
QUERY DESCRIPTION
Perf All Performance data
Perf | where Computer == "MyComputer" All Performance data from a particular computer
Perf | where CounterName == "Current Disk Queue Length" All Performance data for a particular counter
Perf | where ObjectName == "Processor" and CounterName Average CPU Utilization across all computers
== "% Processor Time" and InstanceName == "_Total" |
summarize AVGCPU = avg(CounterValue) by Computer
Perf | where CounterName == "% Processor Time" | Maximum CPU Utilization across all computers
summarize AggregatedValue = max(CounterValue) by
Computer
Perf | where ObjectName == "LogicalDisk" and Average Current Disk Queue length across all the instances
CounterName == "Current Disk Queue Length" and of a given computer
Computer == "MyComputerName" | summarize
AggregatedValue = avg(CounterValue) by InstanceName
Perf | where CounterName == "Disk Transfers/sec" | 95th Percentile of Disk Transfers/Sec across all computers
summarize AggregatedValue = percentile(CounterValue, 95)
by Computer
Perf | where CounterName == "% Processor Time" and Hourly average of CPU usage across all computers
InstanceName == "_Total" | summarize AggregatedValue =
avg(CounterValue) by bin(TimeGenerated, 1h), Computer
QUERY DESCRIPTION
Perf | where Computer == "MyComputer" and Hourly 70 percentile of every % percent counter for a
CounterName startswith_cs "%" and InstanceName == particular computer
"_Total" | summarize AggregatedValue =
percentile(CounterValue, 70) by bin(TimeGenerated, 1h),
CounterName
Perf | where CounterName == "% Processor Time" and Hourly average, minimum, maximum, and 75-percentile CPU
InstanceName == "_Total" and Computer == "MyComputer" usage for a specific computer
| summarize ["min(CounterValue)"] = min(CounterValue),
["avg(CounterValue)"] = avg(CounterValue),
["percentile75(CounterValue)"] = percentile(CounterValue,
75), ["max(CounterValue)"] = max(CounterValue) by
bin(TimeGenerated, 1h), Computer
Perf | where ObjectName == "MSSQL$INST2:Databases" and All Performance data from the Database performance object
InstanceName == "master" for the master database from the named SQL Server instance
INST2.
Next steps
Collect performance counters from Linux applications including MySQL and Apache HTTP Server.
Export collected data to Power BI for additional visualizations and analysis.
Collect performance counters for Linux applications
in Azure Monitor
NOTE
agent for Linux.
This article provides details for configuring the Log Analytics agent for Linux to collect performance counters for
specific applications into Azure Monitor. The applications included in this article are:
MySQL
Apache HTTP Server
MySQL
If MySQL Server or MariaDB Server is detected on the computer when the Log Analytics agent is installed, a
performance monitoring provider for MySQL Server will be automatically installed. This provider connects to the
local MySQL/MariaDB server to expose performance statistics. MySQL user credentials must be configured so
that the provider can access the MySQL Server.
Configure MySQL credentials
The MySQL OMI provider requires a preconfigured MySQL user and installed MySQL client libraries in order to
query the performance and health information from the MySQL instance. These credentials are stored in an
authentication file that's stored on the Linux agent. The authentication file specifies what bind-address and port the
MySQL instance is listening on and what credentials to use to gather metrics.
During installation of the Log Analytics agent for Linux the MySQL OMI provider will scan MySQL my.cnf
configuration files (default locations) for bind-address and port and partially set the MySQL OMI authentication
file.
The MySQL authentication file is stored at /var/opt/microsoft/mysql-cimprov/auth/omsagent/mysql-auth .
Authentication file format
Following is the format for the MySQL OMI authentication file
[Port]=[Bind-Address], [username], [Base64 encoded Password]

(Port)=(Bind-Address), (username), (Base64 encoded Password)
(Port)=(Bind-Address), (username), (Base64 encoded Password)
AutoUpdate=[true|false]
The entries in the authentication file are described in the following table.
Port Represents the current port the MySQL instance is listening

on. Port 0 specifies that the properties following are used for
default instance.
Bind-Address Current MySQL bind-address.
username MySQL user used to use to monitor the MySQL server

instance.
Base64 encoded Password Password of the MySQL monitoring user encoded in Base64.
AutoUpdate Specifies whether to rescan for changes in the my.cnf file and
overwrite the MySQL OMI Authentication file when the
MySQL OMI Provider is upgraded.
Default instance
The MySQL OMI authentication file can define a default instance and port number to make managing multiple
MySQL instances on one Linux host easier. The default instance is denoted by an instance with port 0. All
additional instances will inherit properties set from the default instance unless they specify different values. For
example, if MySQL instance listening on port ‘3308’ is added, the default instance’s bind-address, username, and
Base64 encoded password will be used to try and monitor the instance listening on 3308. If the instance on 3308
is bound to another address and uses the same MySQL username and password pair only the bind-address is
needed, and the other properties will be inherited.
The following table has example instance settings
DESCRIPTION FILE
Default instance and instance with port 3308. 0=127.0.0.1, myuser, cnBwdA==
3308=, ,
AutoUpdate=true
Default instance and instance with port 3308 and different 0=127.0.0.1, myuser, cnBwdA==
user name and password. 3308=127.0.1.1, myuser2,cGluaGVhZA==
AutoUpdate=true
MySQL OMI Authentication File Program

Included with the installation of the MySQL OMI provider is a MySQL OMI authentication file program which can
be used to edit the MySQL OMI Authentication file. The authentication file program can be found at the following
location.
/opt/microsoft/mysql-cimprov/bin/mycimprovauth
NOTE
The credentials file must be readable by the omsagent account. Running the mycimprovauth command as omsgent is
recommended.
The following table provides details on the syntax for using mycimprovauth.
OPERATION EXAMPLE DESCRIPTION
autoupdate false or true mycimprovauth autoupdate false Sets whether or not the authentication
file will be automatically updated on
restart or update.
default bind-address username mycimprovauth default 127.0.0.1 root Sets the default instance in the MySQL
password pwd OMI authentication file.
The password field should be entered in
plain text - the password in the MySQL
OMI authentication file will be Base 64
encoded.
delete default or port_num mycimprovauth 3308 Deletes the specified instance by either
default or by port number.
help mycimprov help Prints out a list of commands to use.
print mycimprov print Prints out an easy to read MySQL OMI

authentication file.
update port_num bind-address mycimprov update 3307 127.0.0.1 root Updates the specified instance or adds
username password pwd the instance if it does not exist.
The following example commands define a default user account for the MySQL server on localhost. The password
field should be entered in plain text - the password in the MySQL OMI authentication file will be Base 64 encoded
sudo su omsagent -c '/opt/microsoft/mysql-cimprov/bin/mycimprovauth default 127.0.0.1 <username> <password>'

sudo /opt/omi/bin/service_control restart
Database Permissions Required for MySQL Performance Counters

The MySQL User requires access to the following queries to collect MySQL Server performance data.
SHOW GLOBAL STATUS;

SHOW GLOBAL VARIABLES:
The MySQL user also requires SELECT access to the following default tables.
information_schema
mysql.
These privileges can be granted by running the following grant commands.
GRANT SELECT ON information_schema.* TO ‘monuser’@’localhost’;

GRANT SELECT ON mysql.* TO ‘monuser’@’localhost’;
NOTE
To grant permissions to a MySQL monitoring user the granting user must have the ‘GRANT option’ privilege as well as the
privilege being granted.
Define performance counters

Once you configure the Log Analytics agent for Linux to send data to Azure Monitor, you must configure the
performance counters to collect. Use the procedure in Windows and Linux performance data sources in Azure
Monitor with the counters in the following table.
MySQL Database Disk Space in Bytes
MySQL Database Tables
MySQL Server Aborted Connection Pct
MySQL Server Connection Use Pct
MySQL Server Disk Space Use in Bytes
MySQL Server Full Table Scan Pct
MySQL Server InnoDB Buffer Pool Hit Pct
MySQL Server InnoDB Buffer Pool Use Pct
MySQL Server InnoDB Buffer Pool Use Pct
MySQL Server Key Cache Hit Pct
MySQL Server Key Cache Use Pct
MySQL Server Key Cache Write Pct
MySQL Server Query Cache Hit Pct
MySQL Server Query Cache Prunes Pct
MySQL Server Query Cache Use Pct
MySQL Server Table Cache Hit Pct
MySQL Server Table Cache Use Pct
MySQL Server Table Lock Contention Pct
Apache HTTP Server

If Apache HTTP Server is detected on the computer when the omsagent bundle is installed, a performance
monitoring provider for Apache HTTP Server will be automatically installed. This provider relies on an Apache
module that must be loaded into the Apache HTTP Server in order to access performance data. The module can be
loaded with the following command:
sudo /opt/microsoft/apache-cimprov/bin/apache_config.sh -c
To unload the Apache monitoring module, run the following command:

sudo /opt/microsoft/apache-cimprov/bin/apache_config.sh -u
Define performance counters

Once you configure the Log Analytics agent for Linux to send data to Azure Monitor, you must configure the
performance counters to collect. Use the procedure in Windows and Linux performance data sources in Azure
Monitor with the counters in the following table.
Apache HTTP Server Busy Workers
Apache HTTP Server Idle Workers
Apache HTTP Server Pct Busy Workers
Apache HTTP Server Total Pct CPU
Apache Virtual Host Errors per Minute - Client
Apache Virtual Host Errors per Minute - Server
Apache Virtual Host KB per Request
Apache Virtual Host Requests KB per Second
Apache Virtual Host Requests per Second
Next steps
Collect performance counters from Linux agents.
Collect IIS logs in Azure Monitor
Internet Information Services (IIS ) stores user activity in log files that can be collected by Azure Monitor and
stored as log data.
Configuring IIS logs

Azure Monitor collects entries from log files created by IIS, so you must configure IIS for logging.
Azure Monitor only supports IIS log files stored in W3C format and does not support custom fields or IIS
Advanced Logging. It does not collect logs in NCSA or IIS native format.
Configure IIS logs in Azure Monitor from the Advanced Settings menu. There is no configuration required other
than selecting Collect W3C format IIS log files.
Data collection
Azure Monitor collects IIS log entries from each agent each time the log timestamp changes. The log is read every
5 minutes. If for any reason IIS doesn't update the timestamp before the rollover time when a new file is created,
entries will be collected following creation of the new file. The frequency of new file creation is controlled by the
Log File Rollover Schedule setting for the IIS site, which is once a day by default. If the setting is Hourly, Azure
Monitor collects the log each hour. If the setting is Daily, Azure Monitor collects the log every 24 hours.
IIS log record properties

IIS log records have a type of W3CIISLog and have the properties in the following table:
Computer Name of the computer that the event was collected from.
cIP IP address of the client.
csMethod Method of the request such as GET or POST.
csReferer Site that the user followed a link from to the current site.
csUserAgent Browser type of the client.

csUserName Name of the authenticated user that accessed the server.

Anonymous users are indicated by a hyphen.
csUriStem Target of the request such as a web page.
csUriQuery Query, if any, that the client was trying to perform.
ManagementGroupName Name of the management group for Operations Manager

agents. For other agents, this is AOI-<workspace ID>
RemoteIPCountry Country/region of the IP address of the client.
RemoteIPLatitude Latitude of the client IP address.
RemoteIPLongitude Longitude of the client IP address.
scStatus HTTP status code.
scSubStatus Substatus error code.
scWin32Status Windows status code.
sIP IP address of the web server.
SourceSystem OpsMgr
sPort Port on the server the client connected to.
sSiteName Name of the IIS site.
TimeGenerated Date and time the entry was logged.
TimeTaken Length of time to process the request in milliseconds.
Log queries with IIS logs

The following table provides different examples of log queries that retrieve IIS log records.
QUERY DESCRIPTION
W3CIISLog All IIS log records.
W3CIISLog | where scStatus==500 All IIS log records with a return status of 500.
W3CIISLog | summarize count() by cIP Count of IIS log entries by client IP address.
W3CIISLog | where csHost=="www.contoso.com" | summarize Count of IIS log entries by URL for the host
count() by csUriStem www.contoso.com.
W3CIISLog | summarize sum(csBytes) by Computer | take Total bytes received by each IIS computer.
500000
Next steps
Configure Azure Monitor to collect other data sources for analysis.
Custom logs in Azure Monitor
The Custom Logs data source in Azure Monitor allows you to collect events from text files on both Windows and
Linux computers. Many applications log information to text files instead of standard logging services such as
Windows Event log or Syslog. Once collected, you can either parse the data into individual fields in your queries
or extract the data during collection to individual fields.
The log files to be collected must match the following criteria.

The log must either have a single entry per line or use a timestamp matching one of the following formats
at the start of each entry.
YYYY -MM -DD HH:MM:SS
M/D/YYYY HH:MM:SS AM/PM
Mon DD, YYYY HH:MM:SS
yyMMdd HH:mm:ss
ddMMyy HH:mm:ss
MMM d hh:mm:ss
dd/MMM/yyyy:HH:mm:ss zzz
yyyy-MM -ddTHH:mm:ssK
The log file must not allow circular logging or log rotation, where the file is overwritten with new entries.
The log file must use ASCII or UTF -8 encoding. Other formats such as UTF -16 are not supported.
NOTE
If there are duplicate entries in the log file, Azure Monitor will collect them. However, the query results will be inconsistent
where the filter results show more events than the result count. It will be important that you validate the log to determine if
the application that creates it is causing this behavior and address it if possible before creating the custom log collection
definition.
NOTE
A Log Analytics workspace supports the following limits:
Only 500 custom logs can be created.
A table only supports up to 500 columns.
The maximum number of characters for the column name is 500.
IMPORTANT
Custom log collection requires that the application writing the log file flushes the log content to the disk periodically. This is
because the custom log collection relies on filesystem change notifications for the log file being tracked.
Defining a custom log

Use the following procedure to define a custom log file. Scroll to the end of this article for a walkthrough of a
sample of adding a custom log.
Step 1. Open the Custom Log Wizard
The Custom Log Wizard runs in the Azure portal and allows you to define a new custom log to collect.
1. In the Azure portal, select Log Analytics workspaces > your workspace > Advanced Settings.
2. Click on Data > Custom logs.
3. By default, all configuration changes are automatically pushed to all agents. For Linux agents, a configuration
file is sent to the Fluentd data collector.
4. Click Add+ to open the Custom Log Wizard.
Step 2. Upload and parse a sample log
You start by uploading a sample of the custom log. The wizard will parse and display the entries in this file for you
to validate. Azure Monitor will use the delimiter that you specify to identify each record.
New Line is the default delimiter and is used for log files that have a single entry per line. If the line starts with a
date and time in one of the available formats, then you can specify a Timestamp delimiter which supports entries
that span more than one line.
If a timestamp delimiter is used, then the TimeGenerated property of each record stored in Azure Monitor will be
populated with the date/time specified for that entry in the log file. If a new line delimiter is used, then
TimeGenerated is populated with date and time that Azure Monitor collected the entry.
1. Click Browse and browse to a sample file. Note that this may button may be labeled Choose File in some
browsers.
2. Click Next.
3. The Custom Log Wizard will upload the file and list the records that it identifies.
4. Change the delimiter that is used to identify a new record and select the delimiter that best identifies the
records in your log file.
5. Click Next.
Step 3. Add log collection paths
You must define one or more paths on the agent where it can locate the custom log. You can either provide a
specific path and name for the log file, or you can specify a path with a wildcard for the name. This supports
applications that create a new file each day or when one file reaches a certain size. You can also provide multiple
paths for a single log file.
For example, an application might create a log file each day with the date included in the name as in
log20100316.txt. A pattern for such a log might be log*.txt which would apply to any log file following the
application’s naming scheme.
The following table provides examples of valid patterns to specify different log files.
DESCRIPTION PATH
All files in C:\Logs with .txt extension on Windows agent C:\Logs\*.txt
All files in C:\Logs with a name starting with log and a .txt C:\Logs\log*.txt
extension on Windows agent
All files in /var/log/audit with .txt extension on Linux agent /var/log/audit/*.txt
All files in /var/log/audit with a name starting with log and a /var/log/audit/log*.txt
.txt extension on Linux agent
1. Select Windows or Linux to specify which path format you are adding.
2. Type in the path and click the + button.
3. Repeat the process for any additional paths.
Step 4. Provide a name and description for the log
The name that you specify will be used for the log type as described above. It will always end with _CL to
distinguish it as a custom log.
1. Type in a name for the log. The _CL suffix is automatically provided.
2. Add an optional Description.
3. Click Next to save the custom log definition.
Step 5. Validate that the custom logs are being collected
It may take up to an hour for the initial data from a new custom log to appear in Azure Monitor. It will start
collecting entries from the logs found in the path you specified from the point that you defined the custom log. It
will not retain the entries that you uploaded during the custom log creation, but it will collect already existing
entries in the log files that it locates.
Once Azure Monitor starts collecting from the custom log, its records will be available with a log query. Use the
name that you gave the custom log as the Type in your query.
NOTE
If the RawData property is missing from the query, you may need to close and reopen your browser.
Step 6. Parse the custom log entries

The entire log entry will be stored in a single property called RawData. You will most likely want to separate the
different pieces of information in each entry into individual properties for each record. Refer to Parse text data in
Azure Monitor for options on parsing RawData into multiple properties.
Removing a custom log

Use the following process in the Azure portal to remove a custom log that you previously defined.
1. From the Data menu in the Advanced Settings for your workspace, select Custom Logs to list all your
custom logs.
2. Click Remove next to the custom log to remove.
Data collection
Azure Monitor will collect new entries from each custom log approximately every 5 minutes. The agent will record
its place in each log file that it collects from. If the agent goes offline for a period of time, then Azure Monitor will
collect entries from where it last left off, even if those entries were created while the agent was offline.
The entire contents of the log entry are written to a single property called RawData. See Parse text data in Azure
Monitor for methods to parse each imported log entry into multiple properties.
Custom log record properties

Custom log records have a type with the log name that you provide and the properties in the following table.
TimeGenerated Date and time that the record was collected by Azure
Monitor. If the log uses a time-based delimiter then this is the
time collected from the entry.
SourceSystem Type of agent the record was collected from.

RawData Full text of the collected entry. You will most likely want to
parse this data into individual properties.
ManagementGroupName Name of the management group for System Center

Operations Manage agents. For other agents, this is AOI-
<workspace ID>
Sample walkthrough of adding a custom log

The following section walks through an example of creating a custom log. The sample log being collected has a
single entry on each line starting with a date and time and then comma-delimited fields for code, status, and
message. Several sample entries are shown below.
2019-08-27 01:34:36 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected

2019-08-27 01:33:33 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2019-08-27 01:35:44 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2019-08-27 01:38:22 302,Error,Application could not connect to database
2019-08-27 01:31:34 303,Error,Application lost connection to database
Upload and parse a sample log

We provide one of the log files and can see the events that it will be collecting. In this case New Line is a sufficient
delimiter. If a single entry in the log could span multiple lines though, then a timestamp delimiter would need to
be used.
Add log collection paths
The log files will be located in C:\MyApp\Logs. A new file will be created each day with a name that includes the
date in the pattern appYYYYMMDD.log. A sufficient pattern for this log would be C:\MyApp\Logs\*.log.
Provide a name and description for the log

We use a name of MyApp_CL and type in a Description.
Validate that the custom logs are being collected

We use a simple query of MyApp_CL to return all records from the collected log.
Alternatives to custom logs
While custom logs are useful if your data fits the criteria listed about, but there are cases such as the following
where you need another strategy:
The data doesn't fit the required structure such as having the timestamp in a different format.
The log file doesn't adhere to requirements such as file encoding or an unsupported folder structure.
The data requires preprocessing or filtering before collection.
In the cases where your data can't be collected with custom logs, consider the following alternate strategies:
Use a custom script or other method to write data to Windows Events or Syslog which are collected by Azure
Monitor.
Send the data directly to Azure Monitor using HTTP Data Collector API. An example using runbooks in Azure
Automation is provided in Collect log data in Azure Monitor with an Azure Automation runbook.
Next steps
See Parse text data in Azure Monitor for methods to parse each imported log entry into multiple properties.
Create custom fields in a Log Analytics workspace in
Azure Monitor
NOTE
This article describes how to parse text data in a Log Analytics workspace as it's collected. We recommend parsing text data
in a query filter after it's collected following the guidance described in Parse text data in Azure Monitor. It provides several
advantages over using custom fields.
The Custom Fields feature of Azure Monitor allows you to extend existing records in your Log Analytics
workspace by adding your own searchable fields. Custom fields are automatically populated from data extracted
from other properties in the same record.
For example, the sample record below has useful data buried in the event description. Extracting this data into a
separate property makes it available for such actions as sorting and filtering.
NOTE
In the Preview, you are limited to 100 custom fields in your workspace. This limit will be expanded when this feature reaches
general availability.
Creating a custom field

When you create a custom field, Log Analytics must understand which data to use to populate its value. It uses a
technology from Microsoft Research called FlashExtract to quickly identify this data. Rather than requiring you to
provide explicit instructions, Azure Monitor learns about the data you want to extract from examples that you
provide.
The following sections provide the procedure for creating a custom field. At the bottom of this article is a
walkthrough of a sample extraction.
NOTE
The custom field is populated as records matching the specified criteria are added to the Log Analytics workspace, so it will
only appear on records collected after the custom field is created. The custom field will not be added to records that are
already in the data store when it’s created.
Step 1 – Identify records that will have the custom field

The first step is to identify the records that will get the custom field. You start with a standard log query and then
select a record to act as the model that Azure Monitor will learn from. When you specify that you are going to
extract data into a custom field, the Field Extraction Wizard is opened where you validate and refine the criteria.
1. Go to Logs and use a query to retrieve the records that will have the custom field.
2. Select a record that Log Analytics will use to act as a model for extracting data to populate the custom field.
You will identify the data that you want to extract from this record, and Log Analytics will use this information
to determine the logic to populate the custom field for all similar records.
3. Expand the record properties, click the ellipse to the left of the top property of the record, and select Extract
fields from.
4. The Field Extraction Wizard is opened, and the record you selected is displayed in the Main Example
column. The custom field will be defined for those records with the same values in the properties that are
selected.
5. If the selection is not exactly what you want, select additional fields to narrow the criteria. In order to change
the field values for the criteria, you must cancel and select a different record matching the criteria you want.
Step 2 - Perform initial extract.
Once you’ve identified the records that will have the custom field, you identify the data that you want to extract.
Log Analytics will use this information to identify similar patterns in similar records. In the step after this you will
be able to validate the results and provide further details for Log Analytics to use in its analysis.
1. Highlight the text in the sample record that you want to populate the custom field. You will then be presented
with a dialog box to provide a name and data type for the field and to perform the initial extract. The characters
_CF will automatically be appended.
2. Click Extract to perform an analysis of collected records.
3. The Summary and Search Results sections display the results of the extract so you can inspect its accuracy.
Summary displays the criteria used to identify records and a count for each of the data values identified.
Search Results provides a detailed list of records matching the criteria.
Step 3 – Verify accuracy of the extract and create custom field
Once you have performed the initial extract, Log Analytics will display its results based on data that has already
been collected. If the results look accurate then you can create the custom field with no further work. If not, then
you can refine the results so that Log Analytics can improve its logic.
1. If any values in the initial extract aren’t correct, then click the Edit icon next to an inaccurate record and select
Modify this highlight in order to modify the selection.
2. The entry is copied to the Additional examples section underneath the Main Example. You can adjust the
highlight here to help Log Analytics understand the selection it should have made.
3. Click Extract to use this new information to evaluate all the existing records. The results may be modified for
records other than the one you just modified based on this new intelligence.
4. Continue to add corrections until all records in the extract correctly identify the data to populate the new
custom field.
5. Click Save Extract when you are satisfied with the results. The custom field is now defined, but it won’t be
added to any records yet.
6. Wait for new records matching the specified criteria to be collected and then run the log search again. New
records should have the custom field.
7. Use the custom field like any other record property. You can use it to aggregate and group data and even use it
to produce new insights.
Viewing custom fields

You can view a list of all custom fields in your management group from the Advanced Settings menu of your
Log Analytics workspace in the Azure portal. Select Data and then Custom fields for a list of all custom fields in
your workspace.
Removing a custom field
There are two ways to remove a custom field. The first is the Remove option for each field when viewing the
complete list as described above. The other method is to retrieve a record and click the button to the left of the
field. The menu will have an option to remove the custom field.
Sample walkthrough
The following section walks through a complete example of creating a custom field. This example extracts the
service name in Windows events that indicate a service changing state. This relies on events created by Service
Control Manager during system startup on Windows computers. If you want to follow this example, you must be
collecting Information events for the System log.
We enter the following query to return all events from Service Control Manager that have an Event ID of 7036
which is the event that indicates a service starting or stopping.
We then select and expand any record with event ID 7036.

We define custom fields by clicking the ellipse next to the top property.
The Field Extraction Wizard is opened, and the EventLog and EventID fields are selected in the Main
Example column. This indicates that the custom field will be defined for events from the System log with an event
ID of 7036. This is sufficient so we don’t need to select any other fields.
We highlight the name of the service in the RenderedDescription property and use Service to identify the
service name. The custom field will be called Service_CF. The field type in this case is a string, so we can leave
that unchanged.
We see that the service name is identified properly for some records but not for others. The Search Results show
that part of the name for the WMI Performance Adapter wasn’t selected. The Summary shows that one record
identified Modules Installer instead of Windows Modules Installer.
We start with the WMI Performance Adapter record. We click its edit icon and then Modify this highlight.
We increase the highlight to include the word WMI and then rerun the extract.
We can see that the entries for WMI Performance Adapter have been corrected, and Log Analytics also used
that information to correct the records for Windows Module Installer.
We can now run a query that verifies Service_CF is created but is not yet added to any records. That's because
the custom field doesn't work against existing records so we need to wait for new records to be collected.
After some time has passed so new events are collected, we can see that the Service_CF field is now being added
to records that match our criteria.
We can now use the custom field like any other record property. To illustrate this, we create a query that groups by
the new Service_CF field to inspect which services are the most active.
Next steps
Learn about log queries to build queries using custom fields for criteria.
Monitor custom log files that you parse using custom fields.
What is Azure Monitor for VMs (preview)?
Azure Monitor for VMs monitors your Azure virtual machines (VM ) and virtual machine scale sets at scale. It
analyzes the performance and health of your Windows and Linux VMs, and monitors their processes and
dependencies on other resources and external processes.
As a solution, Azure Monitor for VMs includes support for monitoring performance and application
dependencies for VMs that are hosted on-premises or in another cloud provider. Three key features deliver in-
depth insight:
Logical components of Azure VMs that run Windows and Linux: Are measured against pre-
configured health criteria, and they alert you when the evaluated condition is met.
Pre-defined trending performance charts: Display core performance metrics from the guest VM
operating system.
Dependency map: Displays the interconnected components with the VM from various resource groups
and subscriptions.
The features are organized into three perspectives:
Health
Performance
Map
NOTE
Currently, the Health feature is offered only for Azure virtual machines. Performance and Map features support Azure
VMs, Azure VM scale sets, and virtual machines that are hosted in your environment or other cloud provider.
Integration with Azure Monitor logs delivers powerful aggregation and filtering, and it can analyze data trends
over time. Such comprehensive workload monitoring can't be achieved with Azure Monitor or Service Map
alone.
You can view this data in a single VM from the virtual machine directly, or you can use Azure Monitor to deliver
an aggregated view of your VMs. This view is based on each feature's perspective:
Health: The VMs are related to a resource group.
Map and Performance: The VMs are configured to report to a specific Log Analytics workspace.
Azure Monitor for VMs can deliver predictable performance and availability of vital applications. It identifies
critical operating system events, performance bottlenecks, and network issues. Azure Monitor for VMs can also
help you understand whether an issue is related to other dependencies.
Data usage
When you deploy Azure Monitor for VMs, the data that's collected by your VMs is ingested and stored in Azure
Monitor. Health criteria metrics are stored in Azure Monitor in a time-series database, performance and
dependency data collected are stored in a Log Analytics workspace. Based on the pricing that's published on the
Azure Monitor pricing page, Azure Monitor for VMs is billed for:
The data that's ingested and stored.
The number of health criteria metric time-series that are monitored.
The alert rules that are created.
The notifications that are sent.
The log size varies by the string lengths of performance counters, and it can increase with the number of logical
disks and network adapters allocated to the VM. If you already have a workspace and are collecting these
counters, no duplicate charges are applied. If you're already using Service Map, the only change you’ll see is the
additional connection data that's sent to Azure Monitor.
Next steps
To understand the requirements and methods that help you monitor your virtual machines, review Deploy
Azure Monitor for VMs.
Known issues with Azure Monitor for VMs (preview)
This article covers known issues with Azure Monitor for VMs, a solution in Azure that combines health, discovery
of application components, and performance monitoring of the Azure VM operating system.
Health
The following are known issues with the current release of the Health feature:
If an Azure VM is removed or deleted, it's displayed in the VM list view for sometime. Additionally, clicking the
state of a removed or deleted VM opens the Health Diagnostics view and then initiates a loading loop.
Selecting the name of the deleted VM opens a pane with a message stating that the VM has been deleted.
Configuration changes, such as updating a threshold, take up to 30 minutes even if the portal or Workload
Monitor API might update them immediately.
The Health Diagnostics experience updates faster than the other views. The information might be delayed when
you switch between them.
For Linux VMs, the title of the page listing the health criteria for a single VM view has the entire domain name
of the VM instead of the user-defined VM name.
After you disable monitoring for a VM using one of the supported methods and you try deploying it again, you
should deploy it in the same workspace. If you choose a different workspace and try to view the health state for
that VM, it might show inconsistent behavior.
After removing the solution components from your workspace, you may continue to see health state from your
Azure VMs; specifically performance and map data when you navigate to either view in the portal. Data will
eventually stop appearing from the Performance and Map view after sometime; however the Health view will
continue to show health status for your VMs. The Try now option will be available to re-onboard from
Performance and Map views only.
Next steps
To understand the requirements and methods for enabling monitoring of your virtual machines, review Enable
Azure Monitor for VMs.
Azure Monitor for VMs (preview) Frequently Asked
Questions
This Microsoft FAQ is a list of commonly asked questions about Azure Monitor for VMs. If you have any additional
questions about the solution, go to the discussion forum and post your questions. When a question is frequently
asked, we add it to this article so that it can be found quickly and easily.
Can I onboard to an existing workspace?

If your virtual machines are already connected to a Log Analytics workspace, you may continue to use that
workspace when onboarding to Azure Monitor for VMs, provided it is in one of the supported regions listed here.
When onboarding, we configure performance counters for the workspace that will cause all of the VMs reporting
data to the workspace to begin collecting this information for display and analysis in Azure Monitor for VMs. As a
result, you will see performance data from all of the VMs connected to the selected workspace. The Health and
Map features are only enabled for the VMs that you have specified to onboard.
For more information on which performance counters are enabled, refer to our enable overview article.
Can I onboard to a new workspace?

If your VMs are not currently connected to an existing Log Analytics workspace, you need to create a new
workspace to store your data. Creating a new default workspace is done automatically if you configure a single
Azure VM for Azure Monitor for VMs through the Azure portal.
If you choose to use the script-based method, these steps are covered in the Enable Azure Monitor for VMs
(preview ) using Azure PowerShell or Resource Manager template article.
What do I do if my VM is already reporting to an existing workspace?

If you are already collecting data from your virtual machines, you may have already configured it to report data to
an existing Log Analytics workspace. As long as that workspace is in one of our supported regions, you can enable
Azure Monitor for VMs to that pre-existing workspace. If the workspace you are already using is not in one of our
supported regions, you won’t be able to onboard to Azure Monitor for VMs at this time. We are actively working to
support additional regions.
NOTE
We configure performance counters for the workspace that affects all VMs that report to the workspace, whether or not you
have chosen to onboard them to Azure Monitor for VMs. For more details on how performance counters are configured for
the workspace, please refer to our documentation. For information about the counters configured for Azure Monitor for VMs,
please refer to our enable Azure Monitor for VMs article.
Why did my VM fail to onboard?

When onboarding an Azure VM from the Azure portal, the following steps occur:
A default Log Analytics workspace is created, if that option was selected.
The performance counters are configured for selected workspace. If this step fails, you notice that some of the
performance charts and tables aren't showing data for the VM you onboarded. You can fix this by running the
PowerShell script documented here.
The Log Analytics agent is installed on Azure VMs using a VM extension, if determined it is required.
The Azure Monitor for VMs Map Dependency agent is installed on Azure VMs using an extension, if
determined it is required.
Azure Monitor components supporting the Health feature are configured, if needed, and the VM is configured
to report health data.
During the onboard process, we check for status on each of the above to return a notification status to you in the
portal. Configuration of the workspace and the agent installation typically takes 5 to 10 minutes. Viewing
monitoring and health data in the portal take an additional 5 to 10 minutes.
If you have initiated onboarding and see messages indicating the VM needs to be onboarded, allow for up to 30
minutes for the VM to complete the process.
I only enabled Azure Monitor for VMs, Why do I see all my VMs
monitored by the Health feature?
The Health feature is enabled for all VMs that are connected to the Log Analytics workspace, even when the action
is initiated for a single VM.
Can I modify the schedule for when health criteria evaluates a

condition?
No, the time period and frequency of health criteria can't be modified with this release.
Can I disable health criteria for a condition I don't need to monitor?

Health criteria can't be disabled in this release.
Are the health alert severities configurable?

Health alert severity cannot be modified, they can only be enabled or disabled. Additionally, some alert severities
update based on the state of health criteria.
If I reconfigure the settings of a particular health criteria, can it be

scoped to a specific instance?
If you modify any setting of a health criterion instance, all health criteria instances of the same type on the Azure
VM are modified. For example, if the threshold of the disk free-space health criterion instance that corresponds to
logical disk C: is modified, this threshold applies to all other logical disks that are discovered and monitored for the
same VM.
Does the Health feature monitor logical processors and cores?

No, individual processor and logical processor level health criteria is not included for a Windows, only Total CPU
utilization is monitored by default to effectively evaluate CPU pressure based on the total number of logical CPUs
available to the Azure VM.
Are all health criteria thresholds configurable?

Thresholds for health criteria that target a Windows VM aren’t modifiable, because their health states are set to
running or available. When you query the health state from the Workload Monitor API, it displays the
comparisonOperator value of LessThan or GreaterThan with a threshold value of 4 for the service or entity if:
DNS Client Service Health – Service isn't running.
DHCP client service health – Service isn't running.
RPC Service Health – Service isn't running.
Windows firewall service health – Service isn't running.
Windows event log service health – Service isn't running.
Server service health – Service isn't running.
Windows remote management service health – Service isn't running.
File system error or corruption – Logical Disk is unavailable.
Thresholds for the following Linux health criteria aren’t modifiable, because their health state is already set to true.
The health state displays the comparisonOperator with a value LessThan and threshold value of 1 when queried
from the Workload Monitoring API for the entity, depending on its context:
Logical Disk Status – Logical disk isn't online/ available
Disk Status – Disk isn't online/ available
Network Adapter Status - Network adapter is disabled
How do I modify alerts that are included with the Health feature?
Alert rules that are defined for each health criterion aren't displayed in the Azure portal. You can enable or disable a
health alert rule only in the Workload Monitor API. Also, you can't assign an Azure Monitor action group for health
alerts in the Azure portal. You can only use the notification setting API to configure an action group to be triggered
whenever a health alert is fired. Currently, you can assign action groups against a VM so that all health alerts fired
against the VM trigger the same action groups. Unlike traditional Azure alerts, there's no concept of a separate
action group for each health alert rule. Additionally, only action groups that are configured to provide email or
SMS notifications are supported when health alerts are triggered.
I don’t see some or any data in the performance charts for my VM

If you don’t see performance data in the disk table or in some of the performance charts then your performance
counters may not be configured in the workspace. To resolve, run the following PowerShell script.
How is Azure Monitor for VMs Map feature different from Service
Map?
The Azure Monitor for VMs Map feature is based on Service Map, but has the following differences:
The Map view can be accessed from the VM blade and from Azure Monitor for VMs under Azure Monitor.
The connections in the Map are now clickable and display a view of the connection metric data in the side panel
for the selected connection.
There is a new API that is used to create the maps to better support more complex maps.
Monitored VMs are now included in the client group node, and the donut chart shows the proportion of
monitored vs unmonitored virtual machines in the group. It can also be used to filter the list of machines when
the group is expanded.
Monitored virtual machines are now included in the server port group nodes, and the donut chart shows the
proportion of monitored vs unmonitored machines in the group. It can also be used to filter the list of machines
when the group is expanded.
The map style has been updated to be more consistent with App Map from Application insights.
The side panels have been updated, and do not have the full set of integration's that were supported in Service
Map - Update Management, Change Tracking, Security, and Service Desk.
The option for choosing groups and machines to map has been updated and now supports Subscriptions,
Resource Groups, Azure virtual machine scale sets, and Cloud services.
You cannot create new Service Map machine groups in the Azure Monitor for VMs Map feature.
Why do my performance charts show dotted lines?

This can occur for a few reasons. In cases where there is a gap in data collection we depict the lines as dotted. If you
have modified the data sampling frequency for the performance counters enabled (the default setting is to collect
data every 60 seconds), you can see dotted lines in the chart if you choose a narrow time range for the chart and
your sampling frequency is less than the bucket size used in the chart (for example, the sampling frequency is
every 10 minutes and each bucket on the chart is 5 minutes). Choosing a wider time range to view should cause
the chart lines to appear as solid lines rather than dots in this case.
Are groups supported with Azure Monitor for VMs?

Yes, once you install the Dependency agent we collect information from the VMs to display groups based upon
subscription, resource group, virtual machine scale sets, and cloud services. If you have been using Service Map
and have created machine groups, these are displayed as well. Computer groups will also appear in the groups
filter if you have created them for the workspace you are viewing.
How do I see the details for what is driving the 95th percentile line in
the aggregate performance charts?
By default, the list is sorted to show you the VMs that have the highest value for the 95th percentile for the selected
metric, except for the Available memory chart, which shows the machines with the lowest value of the 5th
percentile. Clicking on the chart will open the Top N List view with the appropriate metric selected.
How does the Map feature handle duplicate IPs across different vnets
and subnets?
If you are duplicating IP ranges either with VMs or Azure virtual machine scale sets across subnets and vnets, it
can cause Azure Monitor for VMs Map to display incorrect information. This is a known issue and we are
investigating options to improve this experience.
Does Map feature support IPv6?

Map feature currently only supports IPv4 and we are investigating support for IPv6. We also support IPv4 that is
tunneled inside IPv6.
When I load a map for a Resource Group or other large group the map
is difficult to view
While we have made improvements to Map to handle large and complex configurations, we realize a map can have
a lot of nodes, connections, and node working as a cluster. We are committed to continuing to enhance support to
increase scalability.
Why does the network chart on the Performance tab look different
than the network chart on the Azure VM Overview page?
The overview page for an Azure VM displays charts based on the host's measurement of activity in the guest VM.
For the network chart on the Azure VM Overview, it only displays network traffic that will be billed. This does not
include inter-vnet traffic. The data and charts shown for Azure Monitor for VMs is based on data from the guest
VM and the network chart displays all TCP/IP traffic that is inbound and outbound to that VM, including inter-vnet.
How is response time measured for data stored in VMConnection and

displayed in the connection panel and workbooks?
Response time is an approximation. Since we do not instrument the code of the application, we do not really know
when a request begins and when the response arrives. Instead we observe data being sent on a connection and
then data coming back on that connection. Our agent keeps track of these sends and receives and attempts to pair
them: a sequence of sends, followed by a sequence of receives is interpreted as a request/response pair. The timing
between these operations is the response time. It will include the network latency and the server processing time.
This approximation works well for protocols that are request/response based: a single request goes out on the
connection, and a single response arrives. This is the case for HTTP (S ) (without pipelining), but not satisfied for
other protocols.
Are their limitations if I am on the Log Analytics Free pricing plan?

If you have configured Azure Monitor with a Log Analytics workspace using the Free pricing tier, Azure Monitor for
VMs Map feature will only support five connected machines connected to the workspace. If you have five VMs
connected to a free workspace, you disconnect one of the VMs and then later connect a new VM, the new VM is
not monitored and reflected on the Map page.
Under this condition, you will be prompted with the Try Now option when you open the VM and select Insights
(preview) from the left-hand pane, even after it has been installed already on the VM. However, you are not
prompted with options as would normally occur if this VM were not onboarded to Azure Monitor for VMs.
Next steps
Review Enable Azure Monitor for VMs to understand requirements and methods to enable monitoring of your
virtual machines.
Enable Azure Monitor for VMs (preview) overview
This article provides an overview of the options available to set up Azure Monitor for VMs. Use Azure Monitor for
VMs to monitor health and performance. Discover application dependencies that run on Azure virtual machines
(VMs) and virtual machine scale sets, on-premises VMs, or VMs hosted in another cloud environment.
To set up Azure Monitor for VMs:
Enable a single Azure VM or virtual machine scale set by selecting Insights (preview) directly from the VM or
virtual machine scale set.
Enable two or more Azure VMs and virtual machine scale sets by using Azure Policy. This method ensures that
on existing and new VMs and scale sets, the required dependencies are installed and properly configured.
Noncompliant VMs and scale sets are reported, so you can decide whether to enable them and to remediate
them.
Enable two or more Azure VMs or virtual machine scale sets across a specified subscription or resource group
by using PowerShell.
Enable Azure Monitor for VMs to monitor VMs or physical computers hosted in your corporate network or
other cloud environment.
Prerequisites
Before you start, make sure that you understand the information in the following sections.
NOTE
The following information described in this section is also applicable to the Service Map solution.
Log Analytics
Azure Monitor for VMs supports a Log Analytics workspace in the following regions:
West Central US
West US 21
East US
East US21
Canada Central
UK South
North Europe1
West Europe
Southeast Asia
Japan East1
Australia East1
Australia Southeast1
1 This region doesn't currently support the Health feature of Azure Monitor for VMs.
NOTE
You can deploy Azure VMs from any region. These VMs aren't limited to the regions supported by the Log Analytics
workspace.
If you don't have a workspace, you can create one by using one of these resources:
The Azure CLI
PowerShell
The Azure portal
Azure Resource Manager
You can also create a workspace while you're enabling monitoring for a single Azure VM or virtual machine scale
set in the Azure portal.
To set up an at-scale scenario that uses Azure Policy, Azure PowerShell, or Azure Resource Manager templates, in
your Log Analytics workspace:
Install the ServiceMap and InfrastructureInsights solutions. You can complete this installation by using a
provided Azure Resource Manager template. Or on the Get Started tab, select Configure Workspace.
Configure the Log Analytics workspace to collect performance counters.
To configure your workspace for the at-scale scenario, use one of the following methods:
Use Azure PowerShell.
On the Azure Monitor for VMs Policy Coverage page, select Configure Workspace.
Supported operating systems
The following table lists the Windows and Linux operating systems that Azure Monitor for VMs supports. Later in
this section, you'll find a full list that details the major and minor Linux OS release and supported kernel versions.
OS VERSION PERFORMANCE MAPS HEALTH
Windows Server 2019 X X X
Windows Server 2016 1803 X X X
Windows Server 2016 X X X
Windows Server 2012 R2 X X X
Windows Server 2012 X X
Windows Server 2008 R2 X X
Windows 10 1803 X X
Windows 8.1 X X
Windows 8 X X
Windows 7 SP1 X X
OS VERSION PERFORMANCE MAPS HEALTH
Red Hat Enterprise Linux X X X

(RHEL) 6, 7
Ubuntu 18.04, 16.04 X X X
CentOS Linux 7, 6 X X X
SUSE Linux Enterprise Server X X X

(SLES) 12
Debian 9.4, 8 X1 X
1 The Performance feature of Azure Monitor for VMs is available only from Azure Monitor. It isn't available
directly from the left pane of the Azure VM.
NOTE
The Health feature of Azure Monitor for VMs does not support nested virtualization in an Azure VM.
NOTE
In the Linux operating system:
Only default and SMP Linux kernel releases are supported.
Nonstandard kernel releases, such as Physical Address Extension (PAE) and Xen, aren't supported for any Linux
distribution. For example, a system with the release string of 2.6.16.21-0.8-xen isn't supported.
Custom kernels, including recompilations of standard kernels, aren't supported.
CentOSPlus kernel is supported.
The Linux kernel must be patched for the Spectre vulnerability. Please consult your Linux distribution vendor for more
details.
Red Hat Linux 7
OS VERSION KERNEL VERSION
7.6 3.10.0-957
7.5 3.10.0-862
7.4 3.10.0-693
Red Hat Linux 6
6.10 2.6.32-754
6.9 2.6.32-696
CentOSPlus
6.10 2.6.32-754.3.5
2.6.32-696.30.1
6.9 2.6.32-696.30.1
2.6.32-696.18.7
Ubuntu Server
18.04 5.0 (includes Azure-tuned kernel)

4.18*
4.15*
16.04.3 4.15.*
16.04 4.13.*
4.11.*
4.10.*
4.8.*
4.4.*
SUSE Linux 12 Enterprise Server
12 SP4 4.12.* (includes Azure-tuned kernel)
12 SP3 4.4.*
12 SP2 4.4.*
Debian
9 4.9
The Microsoft Dependency agent

The Map feature in Azure Monitor for VMs gets its data from the Microsoft Dependency agent. The Dependency
agent relies on the Log Analytics agent for its connection to Log Analytics. So your system must have the Log
Analytics agent installed and configured with the Dependency agent.
Whether you enable Azure Monitor for VMs for a single Azure VM or you use the at-scale deployment method,
use the Azure VM Dependency agent extension to install the agent as part of the experience.
NOTE
The following information described in this section is also applicable to the Service Map solution.
In a hybrid environment, you can download and install the Dependency agent manually. If your VMs are hosted
outside Azure, use an automated deployment method.
The following table describes the connected sources that the Map feature supports in a hybrid environment.
Windows agents Yes Along with the Log Analytics agent for
Windows, Windows agents need the
Dependency agent. For more
information, see supported operating
systems.
Linux agents Yes Along with the Log Analytics agent for
Linux, Linux agents need the
Dependency agent. For more
information, see supported operating
systems.
System Center Operations Manager No

management group
You can download the Dependency agent from these locations:
FILE OS VERSION SHA-256
InstallDependencyAgent- Windows 9.9.2 6DFF19B9690E42CA190E3B

Windows.exe 69137C77904B657FA0289
5033EAA4C3A6A41DA5C6
A
InstallDependencyAgent- Linux 9.9.1 1CB447EF30FC042FE7499A

Linux64.bin 686638F3F9B4F449692FB9
D80096820F8024BE4D7C
Role-based access control

To enable and access the features in Azure Monitor for VMs, you must have the Log Analytics contributor role. To
view performance, health, and map data, you must have the monitoring reader role for the Azure VM. The Log
Analytics workspace must be configured for Azure Monitor for VMs.
For more information about how to control access to a Log Analytics workspace, see Manage workspaces.
How to enable Azure Monitor for VMs (preview)

Enable Azure Monitor for VMs by using one of the methods described in this table:
Single Azure VM or virtual machine Enable from the VM You can enable a single Azure VM by
scale set selecting Insights (preview) directly
from the VM or virtual machine scale
set.
Multiple Azure VMs or virtual machine Enable through Azure Policy You can enable multiple Azure VMs by
scale sets using Azure Policy and available policy
definitions.
Multiple Azure VMs or virtual machine Enable through Azure PowerShell or You can enable multiple Azure VMs or
scale sets Azure Resource Manager templates virtual machine scale sets across a
specified subscription or resource group
by using Azure PowerShell or Azure
Resource Manager templates.
Hybrid cloud Enable for the hybrid environment You can deploy to VMs or physical
computers that are hosted in your
datacenter or other cloud
environments.
Performance counters enabled

Azure Monitor for VMs configures a Log Analytics workspace to collect the performance counters that it uses. The
following tables list the objects and counters that are collected every 60 seconds.
LogicalDisk % Free Space
LogicalDisk Avg. Disk sec/Read
LogicalDisk Avg. Disk sec/Transfer
LogicalDisk Avg. Disk sec/Write
LogicalDisk Disk Bytes/sec
LogicalDisk Disk Read Bytes/sec
LogicalDisk Disk Reads/sec
LogicalDisk Disk Transfers/sec
LogicalDisk Disk Write Bytes/sec
LogicalDisk Disk Writes/sec
LogicalDisk Free Megabytes
Memory Available MBytes
Network Adapter Bytes Received/sec
Network Adapter Bytes Sent/sec
Linux performance counters

Logical Disk % Used Space
Logical Disk Disk Read Bytes/sec
Logical Disk Disk Reads/sec
Logical Disk Disk Transfers/sec
Logical Disk Disk Write Bytes/sec
Logical Disk Disk Writes/sec
Logical Disk Free Megabytes
Logical Disk Logical Disk Bytes/sec
Memory Available MBytes Memory
Network Total Bytes Received
Network Total Bytes Transmitted
Management packs
When Azure Monitor for VMs is enabled and configured with a Log Analytics workspace, a management pack is
forwarded to all the Windows computers reporting to that workspace. If you have integrated your System Center
Operations Manager management group with the Log Analytics workspace, the Service Map management pack is
deployed from the management group to the Windows computers reporting to the management group.
The management pack is named Microsoft.IntelligencePacks.ApplicationDependencyMonitor. Its written to
%Programfiles%\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs\ folder. The data source
that the management pack uses is
%Program files%\Microsoft Monitoring Agent\Agent\Health Service State\Resources\
<AutoGeneratedID>\Microsoft.EnterpriseManagement.Advisor.ApplicationDependencyMonitorDataSource.dll
.
Diagnostic and usage data

Microsoft automatically collects usage and performance data through your use of the Azure Monitor service.
Microsoft uses this data to improve the quality, security, and integrity of the service.
To provide accurate and efficient troubleshooting capabilities, the Map feature includes data about the
configuration of your software. The data provides information such as the operating system and version, IP
address, DNS name, and workstation name. Microsoft doesn't collect names, addresses, or other contact
information.
For more information about data collection and usage, see the Microsoft Online Services Privacy Statement.
NOTE
For information about viewing or deleting personal data, see Azure Data Subject Requests for the GDPR. For more
information about GDPR, see the GDPR section of the Service Trust portal.
Now that you've enabled monitoring for your VM, monitoring information is available for analysis in Azure
Monitor for VMs.
Next steps
To learn how to use the Health feature, see View Azure Monitor for VMs Health. To view discovered application
dependencies, see View Azure Monitor for VMs Map.
Enable Azure Monitor for VMs (preview) for
evaluation
You can evaluate Azure Monitor for VMs (preview ) on a small number of Azure virtual machines (VMs) or on a
single VM or virtual machine scale set. The easiest and most direct way to enable monitoring is from the Azure
portal. Your goal is to monitor your VMs and discover any performance or availability issues.
Before you begin, review the prerequisites and make sure your subscription and resources meet the requirements.
Enable monitoring for a single Azure VM

To enable monitoring of your Azure VM:
2. Select Virtual Machines.
3. From the list, select a VM.
4. On the VM page, in the Monitoring section, select Insights (preview).
5. On the Insights (preview) page, select Try now.
6. On the Azure Monitor Insights Onboarding page, if you have an existing Log Analytics workspace in the
same subscription, select it in the drop-down list.
The list preselects the default workspace and location where the VM is deployed in the subscription.
NOTE
To create a new Log Analytics workspace to store the monitoring data from the VM, see Create a Log Analytics
workspace. Your Log Analytics workspace must belong to one of the supported regions.
After you've enabled monitoring, you might need to wait about 10 minutes before you can view the health metrics
for the VM.
Enable monitoring for a single virtual machine scale set
To enable monitoring of your Azure virtual machine scale set:
2. Select Virtual Machine Scale Sets.
3. From the list, select a virtual machine scale set.
4. On the virtual machine scale set page, in the Monitoring section, select Insights (preview).
5. On the Insights (preview) page, if you want to use an existing Log Analytics workspace, select it in the
drop-down list.
The list preselects the default workspace and location that the VM is deployed to in the subscription.
NOTE
To create a new Log Analytics workspace to store the monitoring data from the virtual machine scale set, see Create
a Log Analytics workspace. Your Log Analytics workspace must belong to one of the supported regions.
After you've enabled monitoring, you might need to wait about 10 minutes before you can view the monitoring
data for the scale set.
NOTE
If you use a manual upgrade model for your scale set, upgrade the instances to complete the setup. You can start the
upgrades from the Instances page, in the Settings section.
Now that you've enabled monitoring for your VM or virtual machine scale set, the monitoring information is
available for analysis in Azure Monitor for VMs.
Next steps
To learn how to use the Health feature, see Understand the health of your Azure Monitor VMs.
To view discovered application dependencies, see Use Azure Monitor for VMs Map.
To identify bottlenecks, overall utilization, and your VM's performance, see View Azure VM performance.
Enable Azure Monitor for VMs (preview) by using
Azure Policy
This article explains how to enable Azure Monitor for VMs (preview ) for Azure virtual machines or virtual machine
scale sets by using Azure Policy. At the end of this process, you will have successfully configured enabling the Log
Analytics and Dependency agents and identified virtual machines that aren't compliant.
To discover, manage, and enable Azure Monitor for VMs for all of your Azure virtual machines or virtual machine
scale sets, you can use either Azure Policy or Azure PowerShell. Azure Policy is the method we recommend
because you can manage policy definitions to effectively govern your subscriptions to ensure consistent
compliance and automatic enabling of newly provisioned VMs. These policy definitions:
Deploy the Log Analytics agent and the Dependency agent.
Report on compliance results.
Remediate for noncompliant VMs.
If you're interested in accomplishing these tasks with Azure PowerShell or an Azure Resource Manager template,
see Enable Azure Monitor for VMs (preview ) using Azure PowerShell or Azure Resource Manager templates.
Manage Policy Coverage feature overview

Originally, the experience with Azure Policy for managing and deploying the policy definitions for Azure Monitor
for VMs was done exclusively from Azure Policy. The Manage Policy Coverage feature makes it simpler and easier
to discover, manage, and enable at scale the Enable Azure Monitor for VMs initiative, which includes the policy
definitions mentioned earlier. You can access this new feature from the Get Started tab in Azure Monitor for VMs.
Select Manage Policy Coverage to open the Azure Monitor for VMs Policy Coverage page.
From here, you can check and manage coverage for the initiative across your management groups and
subscriptions. You can understand how many VMs exist in each of the management groups and subscriptions and
their compliance status.
This information is useful to help you plan and execute your governance scenario for Azure Monitor for VMs from
one central location. While Azure Policy provides a compliance view when a policy or initiative is assigned to a
scope, with this new page you can discover where the policy or initiative isn't assigned and assign it in place. All
actions like assign, view, and edit redirect to Azure Policy directly. The Azure Monitor for VMs Policy Coverage
page is an expanded and integrated experience for only the initiative Enable Azure Monitor for VMs.
From this page, you also can configure your Log Analytics workspace for Azure Monitor for VMs, which:
Installs the Installing Service Map and Infrastructure Insights solutions.
Enables the operating system performance counters used by the performance charts, workbooks, and your
custom log queries and alerts.
This option isn't related to any policy actions. It's available to provide an easy way to satisfy the prerequisites
required for enabling Azure Monitor for VMs.
What information is available on this page?
The following table provides a breakdown of the information that's presented on the policy coverage page and
how to interpret it.
FUNCTION DESCRIPTION
Scope Management group and subscriptions that you have or

inherited access to with ability to drill down through the
management group hierarchy.
FUNCTION DESCRIPTION
Role Your role to the scope, which might be reader, owner, or

contributor. In some cases, it might appear blank to indicate
that you might have access to the subscription but not to the
management group it belongs to. Information in other
columns varies depending on your role. The role is key in
determining what data you can see and actions you can
perform in terms of assigning policies or initiatives (owner),
editing them, or viewing compliance.
Total VMs Number of VMs under that scope. For a management group,
it's a sum of VMs nested under the subscriptions or child
management group.
Assignment Coverage Percent of VMs that are covered by the policy or initiative.
Assignment Status Information on the status of your policy or initiative

assignment.
Compliant VMs Number of VMs that are compliant under the policy or
initiative. For the initiative Enable Azure Monitor for VMs,
this is the number of VMs that have both Log Analytics agent
and Dependency agent. In some cases, it might appear blank
because of no assignment, no VMs, or not enough
permissions. Information is provided under Compliance
State.
Compliance The overall compliance number is the sum of distinct

resources that are compliant divided by the sum of all distinct
resources.
Compliance State Information on the compliance state for your policy or

initiative assignment.
When you assign the policy or initiative, the scope selected in the assignment could be the scope listed or a subset
of it. For instance, you might have created an assignment for a subscription (policy scope) and not a management
group (coverage scope). In this case, the value of Assignment Coverage indicates the VMs in the policy or
initiative scope divided by the VMs in coverage scope. In another case, you might have excluded some VMs,
resource groups, or a subscription from policy scope. If the value is blank, it indicates that either the policy or
initiative doesn't exist or you don't have permission. Information is provided under Assignment Status.
Enable by using Azure Policy

To enable Azure Monitor for VMs by using Azure Policy in your tenant:
Assign the initiative to a scope: management group, subscription, or resource group.
Review and remediate compliance results.
For more information about assigning Azure Policy, see Azure Policy overview and review the overview of
management groups before you continue.
Policies for Azure VMs
The policy definitions for an Azure VM are listed in the following table.
NAME DESCRIPTION TYPE
[Preview]: Enable Azure Monitor for Enable Azure Monitor for the virtual Initiative
VMs machines in the specified scope
(management group, subscription, or
resource group). Takes Log Analytics
workspace as a parameter.
[Preview]: Audit Dependency agent Reports VMs as noncompliant if the VM Policy

deployment – VM image (OS) unlisted image (OS) isn't defined in the list and
the agent isn't installed.
[Preview]: Audit Log Analytics agent Reports VMs as noncompliant if the VM Policy
deployment – VM image (OS) unlisted image (OS) isn't defined in the list and
the agent isn't installed.
[Preview]: Deploy Dependency agent for Deploy Dependency agent for Linux Policy
Linux VMs VMs if the VM image (OS) is defined in
the list and the agent isn't installed.
[Preview]: Deploy Dependency agent for Deploy Dependency agent for Windows Policy
Windows VMs VMs if the VM image (OS) is defined in
[Preview]: Deploy Log Analytics agent Deploy Log Analytics agent for Linux Policy
for Linux VMs VMs if the VM image (OS) is defined in
[Preview]: Deploy Log Analytics agent Deploy Log Analytics agent for Policy
for Windows VMs Windows VMs if the VM image (OS) is
defined in the list and the agent isn't
installed.
Policies for Azure virtual machine scale sets

The policy definitions for an Azure virtual machine scale set are listed in the following table.
[Preview]: Enable Azure Monitor for Enable Azure Monitor for the virtual Initiative
virtual machine scale sets machine scale sets in the specified
scope (management group,
subscription, or resource group). Takes
Log Analytics workspace as a parameter.
Note: If your scale set upgrade policy is
set to Manual, apply the extension to all
the VMs in the set by calling upgrade
on them. In the CLI, this is az vmss
update-instances.
[Preview]: Audit Dependency agent Reports virtual machine scale set as Policy
deployment in virtual machine scale noncompliant if the VM image (OS) isn't
sets – VM image (OS) unlisted defined in the list and the agent isn't
installed.
[Preview]: Audit Log Analytics agent Reports virtual machine scale set as Policy
deployment in virtual machine scale noncompliant if the VM image (OS) isn't
sets – VM image (OS) unlisted defined in the list and the agent isn't
installed.
[Preview]: Deploy Dependency agent for Deploy Dependency agent for Linux Policy
Linux virtual machine scale sets virtual machine scale sets if the VM
image (OS) is defined in the list and the
agent isn't installed.
[Preview]: Deploy Dependency agent for Deploy Dependency agent for Windows Policy
Windows virtual machine scale sets virtual machine scale sets if the VM
image (OS) is defined in the list and the
[Preview]: Deploy Log Analytics agent Deploy Log Analytics agent for Linux Policy
for Linux virtual machine scale sets virtual machine scale sets if the VM
Image (OS) is defined in the list and the
[Preview]: Deploy Log Analytics agent Deploy Log Analytics agent for Policy
for Windows virtual machine scale sets Windows virtual machine scale sets if
the VM image (OS) is defined in the list
and the agent isn't installed.
Standalone policy (not included with the initiative) is described here:
[Preview]: Audit Log Analytics Report VMs as noncompliant if they Policy

workspace for VM – Report mismatch aren't logging to the Log Analytics
workspace specified in the policy or
initiative assignment.
Assign the Azure Monitor initiative

To create the policy assignment from the Azure Monitor for VMs Policy Coverage page, follow these steps. To
understand how to complete these steps, seeCreate a policy assignment from the Azure portal.
When you assign the policy or initiative, the scope selected in the assignment could be the scope listed here or a
subset of it. For instance, you might have created an assignment for the subscription (policy scope) and not the
management group (coverage scope). In this case, the coverage percentage would indicate the VMs in the policy or
initiative scope divided by the VMs in the coverage scope. In another case, you might have excluded some VMs, or
resource groups, or a subscription from the policy scope. If it's blank, it indicates that either the policy or initiative
doesn't exist or you don't have permissions. Information is provided under Assignment Status.
3. Choose Virtual Machines (preview) in the Insights section.
4. Select the Get Started tab. On the page, select Manage Policy Coverage.
5. Select either a management group or a subscription from the table. Select Scope by selecting the ellipsis
(...). In the example, a scope limits the policy assignment to a grouping of virtual machines for enforcement.
6. On the Azure Policy assignment page, it's pre-populated with the initiative Enable Azure Monitor for
VMs. The Assignment name box is automatically populated with the initiative name, but you can change
it. You also can add an optional description. The Assigned by box is automatically populated based on who
is logged in. This value is optional.
7. (Optional) To remove one or more resources from the scope, select Exclusions.
8. In the Log Analytics workspace drop-down list for the supported region, select a workspace.
NOTE
If the workspace is beyond the scope of the assignment, grant Log Analytics Contributor permissions to the policy
assignment's Principal ID. If you don't do this, you might see a deployment failure like
The client '343de0fe-e724-46b8-b1fb-97090f7054ed' with object id '343de0fe-e724-46b8-b1fb-
97090f7054ed' does not have authorization to perform action
'microsoft.operationalinsights/workspaces/read' over scope ...
To grant access, review how to manually configure the managed identity.
The Managed Identity check box is selected because the initiative being assigned includes a policy with the
deployIfNotExists effect.
9. In the Manage Identity location drop-down list, select the appropriate region.
10. Select Assign.
After you create the assignment, the Azure Monitor for VMs Policy Coverage page updates Assignment
Coverage, Assignment Status, Compliant VMs, and Compliance State to reflect the changes.
The following matrix maps each possible compliance state for the initiative.
COMPLIANCE STATE DESCRIPTION
Compliant All VMs in the scope have the Log Analytics and Dependency
agents deployed to them.
Not Compliant Not all VMs in the scope have the Log Analytics and
Dependency agents deployed to them and might require
remediation.
Not Started A new assignment was added.
Lock You don't have sufficient privileges to the management

group.1
Blank No policy is assigned.
1 If you don’t have access to the management group, ask an owner

to provide access. Or, view compliance and
manage assignments through the child management groups or subscriptions.
The following table maps each possible assignment status for the initiative.
ASSIGNMENT STATUS DESCRIPTION
Success All VMs in the scope have the Log Analytics and Dependency
agents deployed to them.
Warning The subscription isn't under a management group.
Not Started A new assignment was added.
Lock You don't have sufficient privileges to the management

group.1
ASSIGNMENT STATUS DESCRIPTION
Blank No VMs exist or a policy isn't assigned.
Action Assign a policy or edit an assignment.
1 If you don’t have access to the management group, ask an owner

to provide access. Or, view compliance and
manage assignments through the child management groups or subscriptions.
Review and remediate the compliance results

The following example is for an Azure VM, but it also applies to virtual machine scale sets. To learn how to review
compliance results, see Identify noncompliance results. On the Azure Monitor for VMs Policy Coverage page,
select either a management group or a subscription from the table. Select View Compliance by selecting the
ellipsis (...).
Based on the results of the policies included with the initiative, VMs are reported as noncompliant in the following
scenarios:
Log Analytics agent or Dependency agent isn't deployed.
This scenario is typical for a scope with existing VMs. To mitigate it, deploy the required agents by creating
remediation tasks on a noncompliant policy.
[Preview ]: Deploy Dependency agent for Linux VMs
[Preview ]: Deploy Dependency agent for Windows VMs
[Preview ]: Deploy Log Analytics agent for Linux VMs
[Preview ]: Deploy Log Analytics agent for Windows VMs
VM image (OS ) isn't identified in the policy definition.
The criteria of the deployment policy include only VMs that are deployed from well-known Azure VM
images. Check the documentation to see whether the VM OS is supported. If it isn't supported, duplicate
the deployment policy and update or modify it to make the image compliant.
[Preview ]: Audit Dependency agent deployment – VM image (OS ) unlisted
[Preview ]: Audit Log Analytics agent deployment – VM image (OS ) unlisted
VMs aren't logging in to the specified Log Analytics workspace.
It's possible that some VMs in the initiative scope are logging in to a Log Analytics workspace other than
the one that's specified in the policy assignment. This policy is a tool to identify which VMs are reporting to
a noncompliant workspace.
[Preview ]: Audit Log Analytics workspace for VM – Report mismatch
Edit an initiative assignment

At any time after you assign an initiative to a management group or subscription, you can edit it to modify the
following properties:
Assignment name
Description
Assigned by
Exceptions
Next steps
Now that monitoring is enabled for your virtual machines, this information is available for analysis with Azure
Monitor for VMs.
To learn how to use the health feature, see View Azure Monitor for VMs health.
To view discovered application dependencies, see View Azure Monitor for VMs Map.
To identify bottlenecks and overall utilization with your VM's performance, see View Azure VM performance.
Enable Azure Monitor for VMs (preview) using Azure
PowerShell or Resource Manager templates
NOTE
PowerShell.
This article explains how to enable Azure Monitor for VMs (preview ) for Azure virtual machines or virtual machine
scale sets by using Azure PowerShell or Azure Resource Manager templates. At the end of this process, you will
have successfully begun monitoring all of your virtual machines and learn if any are experiencing performance or
availability issues.
Set up a Log Analytics workspace

If you don't have a Log Analytics workspace, you need to create one. Review the methods that are suggested in the
Prerequisites section before you continue with the steps to configure it. Then you can finish the deployment of
Azure Monitor for VMs by using the Azure Resource Manager template method.
Enable performance counters
If the Log Analytics workspace that's referenced by the solution isn't already configured to collect the performance
counters required by the solution, you need to enable them. You can do so in one of two ways:
Manually, as described in Windows and Linux performance data sources in Log Analytics
By downloading and running a PowerShell script that's available from the Azure PowerShell Gallery
Install the ServiceMap and InfrastructureInsights solutions
This method includes a JSON template that specifies the configuration for enabling the solution components in
your Log Analytics workspace.
If you don't know how to deploy resources by using a template, see:
To use the Azure CLI, you first need to install and use the CLI locally. You must be running the Azure CLI version
2.0.27 or later. To identify your version, run az --version . To install or upgrade the Azure CLI, see Install the Azure
CLI.
{
"parameters": {
"WorkspaceName": {
"type": "string"
},
"WorkspaceLocation": {
"type": "string"
}
},
"resources": [
{
"name": "[parameters('WorkspaceName')]",
"location": "[parameters('WorkspaceLocation')]",
"resources": [
{
"name": "[concat('ServiceMap', '(', parameters('WorkspaceName'),')')]",
"type": "Microsoft.OperationsManagement/solutions",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/',
parameters('WorkspaceName'))]"
],
"properties": {
"workspaceResourceId": "
[resourceId('Microsoft.OperationalInsights/workspaces/', parameters('WorkspaceName'))]"
},
"plan": {
"publisher": "Microsoft",
"product": "[Concat('OMSGallery/', 'ServiceMap')]",
"promotionCode": ""
}
},
{
"name": "[concat('InfrastructureInsights', '(', parameters('WorkspaceName'),')')]",
"dependsOn": [
],
"properties": {
"workspaceResourceId": "
[resourceId('Microsoft.OperationalInsights/workspaces/', parameters('WorkspaceName'))]"
},
"plan": {
"name": "[concat('InfrastructureInsights', '(',
parameters('WorkspaceName'),')')]",
"product": "[Concat('OMSGallery/', 'InfrastructureInsights')]",
"promotionCode": ""
}
}
]
}
]
}
2. Save this file as installsolutionsforvminsights.json to a local folder.

3. Capture the values for WorkspaceName, ResourceGroupName, and WorkspaceLocation. The value for
WorkspaceName is the name of your Log Analytics workspace. The value for WorkspaceLocation is the
region the workspace is defined in.
4. You're ready to deploy this template.
Use the following PowerShell commands in the folder that contains the template:
New-AzResourceGroupDeployment -Name DeploySolutions -TemplateFile

InstallSolutionsForVMInsights.json -ResourceGroupName <ResourceGroupName> -WorkspaceName
<WorkspaceName> -WorkspaceLocation <WorkspaceLocation - example: eastus>
The configuration change can take a few minutes to finish. When it's finished, a message displays
To run the following command by using the Azure CLI:
az login
az group deployment create --name DeploySolutions --resource-group <ResourceGroupName> --
template-file InstallSolutionsForVMInsights.json --parameters WorkspaceName=<workspaceName>
WorkspaceLocation=<WorkspaceLocation - example: eastus>
The configuration change can take a few minutes to finish. When it's finished, a message is displayed
Enable with Azure Resource Manager templates

We have created example Azure Resource Manager templates for onboarding your virtual machines and virtual
machine scale sets. These templates include scenarios you can use to enable monitoring on an existing resource
and create a new resource that has monitoring enabled.
NOTE
The template needs to be deployed in the same resource group as the resource to be brought on board.

CLI.
Download templates
The Azure Resource Manager templates are provided in an archive file (.zip) that you can download from our
GitHub repo. Contents of the file include folders that represent each deployment scenario with a template and
parameter file. Before you run them, modify the parameters file and specify the values required. Don't modify the
template file unless you need to customize it to support your particular requirements. After you have modified the
parameter file, you can deploy it by using the following methods described later in this article.
The download file contains the following templates for different scenarios:
ExistingVmOnboarding template enables Azure Monitor for VMs if the virtual machine already exists.
NewVmOnboarding template creates a virtual machine and enables Azure Monitor for VMs to monitor it.
ExistingVmssOnboarding template enables Azure Monitor for VMs if the virtual machine scale set already
exists.
NewVmssOnboarding template creates virtual machine scale sets and enables Azure Monitor for VMs to
monitor them.
ConfigureWorksapce template configures your Log Analytics workspace to support Azure Monitor for VMs
by enabling the solutions and collection of Linux and Windows operating system performance counters.
NOTE
If virtual machine scale sets were already present and the upgrade policy is set to Manual, Azure Monitor for VMs won't be
enabled for instances by default after running the ExistingVmssOnboarding Azure Resource Manager template. You have
to manually upgrade the instances.
Deploy by using Azure PowerShell

The following step enables monitoring by using Azure PowerShell.
New-AzResourceGroupDeployment -Name OnboardCluster -ResourceGroupName <ResourceGroupName> -TemplateFile

<Template.json> -TemplateParameterFile <Parameters.json>
The configuration change can take a few minutes to finish. When it's finished, a message displays that's similar to
the following and includes the result:
Deploy by using the Azure CLI

The following step enables monitoring by using the Azure CLI.
az login
az group deployment create --resource-group <ResourceGroupName> --template-file <Template.json> --parameters
<Parameters.json>
The output resembles the following:
Enable with PowerShell

To enable Azure Monitor for VMs for multiple VMs or virtual machine scale sets, use the PowerShell script Install-
VMInsights.ps1. It's available from the Azure PowerShell Gallery. This script iterates through:
Every virtual machine and virtual machine scale set in your subscription.
The scoped resource group that's specified by ResourceGroup.
A single VM or virtual machine scale set that's specified by Name.
For each VM or virtual machine scale set, the script verifies whether the VM extension is already installed. If the
VM extension isn't installed, the script tries to reinstall it. If the VM extension is installed, the script installs the Log
Analytics and Dependency agent VM extensions.
Verify you are using Azure PowerShell module Az version 1.0.0 or later with Enable-AzureRM compatibility aliases
enabled. Run Get-Module -ListAvailable Az to find the version. If you need to upgrade, see Install Azure
PowerShell module. If you're running PowerShell locally, you also need to run Connect-AzAccount to create a
connection with Azure.
To get a list of the script's argument details and example usage, run Get-Help .
Get-Help .\Install-VMInsights.ps1 -Detailed
SYNOPSIS
This script installs VM extensions for Log Analytics and the Dependency agent as needed for VM Insights.
SYNTAX
.\Install-VMInsights.ps1 [-WorkspaceId] <String> [-WorkspaceKey] <String> [-SubscriptionId] <String> [[-
ResourceGroup]
<String>] [[-Name] <String>] [[-PolicyAssignmentName] <String>] [-ReInstall] [-TriggerVmssManualVMUpdate]
[-Approve] [-WorkspaceRegion] <String>
[-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
This script installs or reconfigures the following on VMs and virtual machine scale sets:
- Log Analytics VM extension configured to supplied Log Analytics workspace
- Dependency agent VM extension
Can be applied to:

- Subscription
- Resource group in a subscription
- Specific VM or virtual machine scale set
- Compliance results of a policy for a VM or VM extension
Script will show you a list of VMs or virtual machine scale sets that will apply to and let you confirm to
continue.
Use -Approve switch to run without prompting, if all required parameters are provided.
If the extensions are already installed, they will not install again.
Use -ReInstall switch if you need to, for example, update the workspace.
Use -WhatIf if you want to see what would happen in terms of installs, what workspace configured to, and
status of the extension.
PARAMETERS
-WorkspaceId <String>
Log Analytics WorkspaceID (GUID) for the data to be sent to
-WorkspaceKey <String>
Log Analytics Workspace primary or secondary key
-SubscriptionId <String>
SubscriptionId for the VMs/VM Scale Sets
If using PolicyAssignmentName parameter, subscription that VMs are in
-ResourceGroup <String>
<Optional> Resource Group to which the VMs or VM Scale Sets belong
-Name <String>
<Optional> To install to a single VM/VM Scale Set
-PolicyAssignmentName <String>
<Optional> Take the input VMs to operate on as the Compliance results from this Assignment
<Optional> Take the input VMs to operate on as the Compliance results from this Assignment
If specified will only take from this source.
-ReInstall [<SwitchParameter>]
<Optional> If VM/VM Scale Set is already configured for a different workspace, set this to change to
the new workspace
-TriggerVmssManualVMUpdate [<SwitchParameter>]
<Optional> Set this flag to trigger update of VM instances in a scale set whose upgrade policy is set
to Manual
-Approve [<SwitchParameter>]
<Optional> Gives the approval for the installation to start with no confirmation prompt for the listed
VMs/VM Scale Sets
-WorkspaceRegion <String>
Region the Log Analytics Workspace is in
Supported values: "East US","eastus","Southeast Asia","southeastasia","West Central
US","westcentralus","West Europe","westeurope"
For Health supported is: "East US","eastus","West Central US","westcentralus"
-WhatIf [<SwitchParameter>]
<Optional> See what would happen in terms of installs.
If extension is already installed will show what workspace is currently configured, and status of the
VM extension
-Confirm [<SwitchParameter>]
<Optional> Confirm every action
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
-------------------------- EXAMPLE 1 --------------------------

.\Install-VMInsights.ps1 -WorkspaceRegion eastus -WorkspaceId <WorkspaceId>-WorkspaceKey <WorkspaceKey> -
SubscriptionId <SubscriptionId>
-ResourceGroup <ResourceGroup>
Install for all VMs in a resource group in a subscription
-------------------------- EXAMPLE 2 --------------------------

-ResourceGroup <ResourceGroup> -ReInstall
Specify to reinstall extensions even if already installed, for example, to update to a different workspace
-------------------------- EXAMPLE 3 --------------------------

-PolicyAssignmentName a4f79f8ce891455198c08736 -ReInstall
Specify to use a PolicyAssignmentName for source and to reinstall (move to a new workspace)
The following example demonstrates using the PowerShell commands in the folder to enable Azure Monitor for
VMs and understand the expected output:
$WorkspaceId = "<GUID>"
$WorkspaceKey = "<Key>"
$SubscriptionId = "<GUID>"
.\Install-VMInsights.ps1 -WorkspaceId $WorkspaceId -WorkspaceKey $WorkspaceKey -SubscriptionId $SubscriptionId
-WorkspaceRegion eastus
Getting list of VMs or virtual machine scale sets matching criteria specified
VMs or virtual machine scale sets matching criteria:
db-ws-1 VM running
db-ws2012 VM running
This operation will install the Log Analytics and Dependency agent extensions on the previous two VMs or
virtual machine scale sets.
VMs in a non-running state will be skipped.
Extension will not be reinstalled if already installed. Use -ReInstall if desired, for example, to update
workspace.
Confirm
Continue?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
db-ws-1 : Deploying DependencyAgentWindows with name DAExtension

db-ws-1 : Successfully deployed DependencyAgentWindows
db-ws-1 : Deploying MicrosoftMonitoringAgent with name MMAExtension
db-ws-1 : Successfully deployed MicrosoftMonitoringAgent
db-ws2012 : Deploying DependencyAgentWindows with name DAExtension
db-ws2012 : Successfully deployed DependencyAgentWindows
db-ws2012 : Deploying MicrosoftMonitoringAgent with name MMAExtension
db-ws2012 : Successfully deployed MicrosoftMonitoringAgent
Summary:
Already onboarded: (0)
Succeeded: (4)
db-ws-1 : Successfully deployed DependencyAgentWindows
db-ws-1 : Successfully deployed MicrosoftMonitoringAgent
db-ws2012 : Successfully deployed DependencyAgentWindows
db-ws2012 : Successfully deployed MicrosoftMonitoringAgent
Connected to different workspace: (0)
Not running - start VM to configure: (0)
Failed: (0)
Next steps
Monitor for VMs.
To learn how to use the health feature, see View Azure Monitor for VMs health.
To identify bottlenecks and overall utilization with your VM's performance, see View Azure VM Performance.
Enable Azure Monitor for VMs (preview) for a hybrid
environment
NOTE
PowerShell.
This article explains how to enable Azure Monitor for VMs (preview ) for virtual machines or physical computers
hosted in your datacenter or other cloud environment. At the end of this process, you will have successfully begun
monitoring your virtual machines in your environment and learn if they are experiencing any performance or
availability issues.
Before you get started, be sure to review the prerequisites and verify that your subscription and resources meet
the requirements. Review the requirements and deployment methods for the Log Analytics Linux and Windows
agent.
NOTE
agent for Linux.
NOTE
The Azure Monitor for VMs Map Dependency agent doesn't transmit any data itself, and it doesn't require any changes to
firewalls or ports. The Map data is always transmitted by the Log Analytics agent to the Azure Monitor service, either directly
or through the Operations Management Suite gateway if your IT security policies don't allow computers on the network to
connect to the internet.
The steps to complete this task are summarized as follows:

1. Install Log Analytics agent for Windows or Linux. Before you install the agent, review the Log Analytics
agent overview article to understand system prerequisites and deployment methods.
2. Download and install the Azure Monitor for VMs Map Dependency agent for Windows or Linux.
3. Enable the collection of performance counters.
4. Deploy Azure Monitor for VMs.
NOTE
The information described in this article for deploying the Dependency agent is also applicable to the Service Map solution.
Install the Dependency agent on Windows
You can install the Dependency agent manually on Windows computers by running
InstallDependencyAgent-Windows.exe . If you run this executable file without any options, it starts a setup wizard that
you can follow to install the agent interactively.
NOTE
Administrator privileges are required to install or uninstall the agent.
The following table highlights the parameters that are supported by setup for the agent from the command line.
/? Returns a list of the command-line options.
/S Performs a silent installation with no user interaction.
For example, to run the installation program with the /? parameter, enter InstallDependencyAgent-
Windows.exe /?.
Files for the Windows Dependency agent are installed in C:\Program Files\Microsoft Dependency Agent by
default. If the Dependency agent fails to start after setup is finished, check the logs for detailed error information.
The log directory is %Programfiles%\Microsoft Dependency Agent\logs.
Install the Dependency agent on Linux

The Dependency agent is installed on Linux servers from InstallDependencyAgent-Linux64.bin, a shell script with a
self-extracting binary. You can run the file by using sh or add execute permissions to the file itself.
NOTE
Root access is required to install or configure the agent.
-help Get a list of the command-line options.
-s Perform a silent installation with no user prompts.
--check Check permissions and the operating system, but don't install
the agent.
For example, to run the installation program with the -help parameter, enter InstallDependencyAgent-
Linux64.bin -help.
Install the Linux Dependency agent as root by running the command sh InstallDependencyAgent-Linux64.bin .
If the Dependency agent fails to start, check the logs for detailed error information. On Linux agents, the log
directory is /var/opt/microsoft/dependency-agent/log.
Files for the Dependency agent are placed in the following directories:
FILES LOCATION
Core files /opt/microsoft/dependency-agent
Log files /var/opt/microsoft/dependency-agent/log
Config files /etc/opt/microsoft/dependency-agent/config
Service executable files /opt/microsoft/dependency-agent/bin/microsoft-dependency-

agent
/opt/microsoft/dependency-agent/bin/microsoft-dependency-
agent-manager
Binary storage files /var/opt/microsoft/dependency-agent/storage
Installation script examples

To easily deploy the Dependency agent on many servers at once, the following script example is provided to
download and install the Dependency agent on either Windows or Linux.
PowerShell script for Windows
Invoke-WebRequest "https://aka.ms/dependencyagentwindows" -OutFile InstallDependencyAgent-Windows.exe
.\InstallDependencyAgent-Windows.exe /S
Shell script for Linux
wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin

sudo sh InstallDependencyAgent-Linux64.bin -s
Desired State Configuration

To deploy the Dependency agent using Desired State Configuration (DSC ), you can use the
xPSDesiredStateConfiguration module with the following example code:
configuration ServiceMap {
$DAPackageLocalPath = "C:\InstallDependencyAgent-Windows.exe"
Node localhost
{
# Download and install the Dependency agent
xRemoteFile DAPackage
{
Uri = "https://aka.ms/dependencyagentwindows"
DestinationPath = $DAPackageLocalPath
}
xPackage DA
{
Ensure="Present"
Name = "Dependency Agent"
Path = $DAPackageLocalPath
Arguments = '/S'
ProductId = ""
InstalledCheckRegKey =
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\DependencyAgent"
InstalledCheckRegValueName = "DisplayName"
InstalledCheckRegValueData = "Dependency Agent"
DependsOn = "[xRemoteFile]DAPackage"
}
}
}
Enable performance counters

If the Log Analytics workspace that's referenced by the solution isn't already configured to collect the performance
counters required by the solution, you need to enable them. You can do so in one of two ways:
Manually, as described in Windows and Linux performance data sources in Log Analytics
By downloading and running a PowerShell script that's available from the Azure PowerShell Gallery
Deploy Azure Monitor for VMs

This method includes a JSON template that specifies the configuration for enabling the solution components in
CLI.
Create and execute a template
{
"parameters": {
"WorkspaceName": {
"type": "string"
},
"WorkspaceLocation": {
"type": "string"
}
},
"resources": [
{
"name": "[parameters('WorkspaceName')]",
"resources": [
{
"dependsOn": [
],
"properties": {
"workspaceResourceId": "[resourceId('Microsoft.OperationalInsights/workspaces/',
},
"plan": {
"product": "[Concat('OMSGallery/', 'ServiceMap')]",
"promotionCode": ""
}
},
{
"name": "[concat('InfrastructureInsights', '(', parameters('WorkspaceName'),')')]",
"dependsOn": [
],
"properties": {
},
"plan": {
"name": "[concat('InfrastructureInsights', '(',
parameters('WorkspaceName'),')')]",
"product": "[Concat('OMSGallery/', 'InfrastructureInsights')]",
"promotionCode": ""
}
}
]
}
]
}
2. Save this file as installsolutionsforvminsights.json to a local folder.

3. Capture the values for WorkspaceName, ResourceGroupName, and WorkspaceLocation. The value for
WorkspaceName is the name of your Log Analytics workspace. The value for WorkspaceLocation is the
region the workspace is defined in.
4. You're ready to deploy this template by using the following PowerShell command:
New-AzResourceGroupDeployment -Name DeploySolutions -TemplateFile InstallSolutionsForVMInsights.json -

ResourceGroupName ResourceGroupName> -WorkspaceName <WorkspaceName> -WorkspaceLocation
<WorkspaceLocation - example: eastus>
The configuration change can take a few minutes to finish. When it's finished, a message displays that's
similar to the following and includes the result:
After you've enabled monitoring, it might take about 10 minutes before you can view the health state and
metrics for the hybrid computer.
Troubleshooting
VM doesn't appear on the map
If your Dependency agent installation succeeded, but you don't see your computer on the map, diagnose the
problem by following these steps.
1. Is the Dependency agent installed successfully? You can validate this by checking to see if the service is
installed and running.
Windows: Look for the service named "Microsoft Dependency agent."
Linux: Look for the running process "microsoft-dependency-agent."
2. Are you on the Free pricing tier of Log Analytics? The Free plan allows for up to five unique computers. Any
subsequent computers won't show up on the map, even if the prior five are no longer sending data.
3. Is the computer sending log and perf data to Azure Monitor Logs? Perform the following query for your
computer:
Usage | where Computer == "computer-name" | summarize sum(Quantity), any(QuantityUnit) by DataType
Did it return one or more results? Is the data recent? If so, your Log Analytics agent is operating correctly
and communicating with the service. If not, check the agent on your server: Log Analytics agent for
Windows troubleshooting or Log Analytics agent for Linux troubleshooting.
Computer appears on the map but has no processes
If you see your server on the map, but it has no process or connection data, that indicates that the Dependency
agent is installed and running, but the kernel driver didn't load.
Check the C:\Program Files\Microsoft Dependency Agent\logs\wrapper.log file (Windows) or
/var/opt/microsoft/dependency-agent/log/service.log file (Linux). The last lines of the file should indicate why the
kernel didn't load. For example, the kernel might not be supported on Linux if you updated your kernel.
Next steps
Monitor for VMs.
To learn how to use the Health feature, see View Azure Monitor for VMs health.
To identify bottlenecks and overall utilization with your VM's performance, see View Azure VM performance.
System Center Operations Manager integration with
Azure Monitor for VMs Map feature
In Azure Monitor for VMs, you can view discovered application components on Windows and Linux virtual
machines (VMs) that run in Azure or your environment. With this integration between the Map feature and System
Center Operations Manager, you can automatically create distributed application diagrams in Operations Manager
that are based on the dynamic dependency maps in Azure Monitor for VMs.
NOTE
If you have already deployed Service Map, you can view your maps in Azure Monitor for VMs, which includes additional
features to monitor VM health and performance. The Map feature of Azure Monitor for VMs is intended to replace the
standalone Service Map solution. To learn more, see Azure Monitor for VMs overview.
Prerequisites
A System Center Operations Manager management group (2012 R2 or later).
A Log Analytics workspace configured to support Azure Monitor for VMs.
One or more Windows and Linux virtual machines or physical computers that are monitored by Operations
Manager and sending data to your Log Analytics workspace. Linux servers reporting to an Operations Manager
management group need to be configured to directly connect to Azure Monitor. For more information, review
the overview in Collect log data with the Log Analytics agent.
A service principal with access to the Azure subscription that is associated with the Log Analytics workspace.
For more information, go to Create a service principal.
Install the Service Map management pack

You enable the integration between Operations Manager and the Map feature by importing the
Microsoft.SystemCenter.ServiceMap management pack bundle (Microsoft.SystemCenter.ServiceMap.mpb). You
can download the management pack bundle from the Microsoft Download Center. The bundle contains the
following management packs:
Microsoft Service Map Application Views
Microsoft System Center Service Map Internal
Microsoft System Center Service Map Overrides
Microsoft System Center Service Map
Configure integration
After you install the Service Map management pack, a new node, Service Map, is displayed under Operations
Management Suite in the Administration pane of your Operations Manager Operations console.
NOTE
Operations Management Suite was a collection of services that included Log Analytics, is now part of Azure Monitor.
To configure Azure Monitor for VMs Map integration, do the following:
1. To open the configuration wizard, in the Service Map Overview pane, click Add workspace.
2. In the Connection Configuration window, enter the tenant name or ID, application ID (also known as the
username or clientID ), and password of the service principal, and then click Next. For more information, go
to Create a service principal.
3. In the Subscription Selection window, select the Azure subscription, Azure resource group (the one that
contains the Log Analytics workspace), and Log Analytics workspace, and then click Next.
4. In the Machine Group Selection window, you choose which Service Map Machine Groups you want to
sync to Operations Manager. Click Add/Remove Machine Groups, choose groups from the list of
Available Machine Groups, and click Add. When you are finished selecting groups, click Ok to finish.
5. In the Server Selection window, you configure the Service Map Servers Group with the servers that you
want to sync between Operations Manager and the Map feature. Click Add/Remove Servers.
For the integration to build a distributed application diagram for a server, the server must be:
Monitored by Operations Manager
Configured to report to the Log Analytics workspace configured with Azure Monitor for VMs
Listed in the Service Map Servers Group
6. Optional: Select the All Management Servers Resource Pool to communicate with Log Analytics, and then
click Add Workspace.
It might take a minute to configure and register the Log Analytics workspace. After it is configured,
Operations Manager initiates the first Map sync.
Monitor integration
After the Log Analytics workspace is connected, a new folder, Service Map, is displayed in the Monitoring pane of
the Operations Manager Operations console.
The Service Map folder has four nodes:

Active Alerts: Lists all the active alerts about the communication between Operations Manager and Azure
Monitor.
NOTE
These alerts are not Log Analytics alerts synced with Operations Manager, they are generated in the management
group based on workflows defined in the Service Map management pack.
Servers: Lists the monitored servers that are configured to sync from Azure Monitor for VMs Map feature.
Machine Group Dependency Views: Lists all machine groups that are synced from the Map feature. You
can click any group to view its distributed application diagram.
Server Dependency Views: Lists all servers that are synced from the Map feature. You can click any server
to view its distributed application diagram.
Edit or delete the workspace

You can edit or delete the configured workspace through the Service Map Overview pane (Administration pane
> Operations Management Suite > Service Map).
NOTE
Operations Management Suite was a collection of services that included Log Analytics, which is now part of Azure Monitor.
You can configure only one Log Analytics workspace in this current release.
Configure rules and overrides

A rule, Microsoft.SystemCenter.ServiceMapImport.Rule, periodically fetches information from Azure Monitor for
VMs Map feature. To modify the synchronization interval, you can override the rule and modify the value for the
parameter IntervalMinutes.
Enabled: Enable or disable automatic updates.
IntervalMinutes: Specifies the time between updates. The default interval is one hour. If you want to sync
maps more frequently, you can change the value.
TimeoutSeconds: Specifies the length of time before the request times out.
TimeWindowMinutes: Specifies the time window for querying data. The default is 60 minutes, which is the
maximum interval allowed.
Known issues and limitations

The current design presents the following issues and limitations:
You can only connect to a single Log Analytics workspace.
Although you can add servers to the Service Map Servers Group manually through the Authoring pane, the
maps for those servers are not synced immediately. They will be synced from Azure Monitor for VMs Map
feature during the next sync cycle.
If you make any changes to the Distributed Application Diagrams created by the management pack, those
changes will likely be overwritten on the next sync with Azure Monitor for VMs.

For official Azure documentation about creating a service principal, see:
Create a service principal by using PowerShell
Create a service principal by using Azure CLI
Create a service principal by using the Azure portal
Feedback
Do you have any feedback for us about integration with Azure Monitor for VMs Map feature or this
documentation? Visit our User Voice page, where you can suggest features or vote on existing suggestions.
Understand the health of your Azure virtual
machines
Azure includes services for specific roles or tasks in the monitoring space, but it doesn't provide in-depth health
perspectives of operating systems (OSs) hosted on Azure virtual machines (VMs). Although you can use Azure
Monitor for different conditions, it's not designed to model and represent the health of core components, or the
overall health of VMs.
By using Azure Monitor for VMs health, you can actively monitor the availability and performance of a Windows
or Linux guest OS. The health feature uses a model that represents key components and their relationships,
provides criteria that specifies how to measure component health, and sends an alert when it detects an
unhealthy condition.
Viewing the overall health state of an Azure VM and the underlying OS can be observed from two perspectives:
directly from a VM, or across all VMs in a resource group from Azure Monitor.
This article shows how to quickly assess, investigate, and resolve health issues when they are detected by the
Azure Monitor for VMs health feature.
For information about configuring Azure Monitor for VMs, see Enable Azure Monitor for VMs.
Monitoring configuration details

This section outlines the default health criteria to monitor Azure Windows and Linux VMs. All health criteria are
pre-configured to send an alert when they detect an unhealthy condition.
LOOKBACK
MONITOR FREQUENCY DURATION ALERT ON WORKLOAD
NAME (MIN) (MIN) OPERATOR THRESHOLD STATE SEVERITY CATEGORY
Logical Disk 5 15 <> 1 (true) Critical Sev1 Linux

Online
Logical Disk 5 15 < 200 MB Warning Sev1 Linux

Free Space (warning) Sev2
100 MB
(critical)
Logical Disk 5 15 < 5% Critical Sev1 Linux

% Free
Inodes
Logical Disk 5 15 < 5% Critical Sev1 Linux

% Free
Space
Network 5 15 <> 1 (true) Warning Sev2 Linux

Adapter
Status
LOOKBACK
Operating 5 10 < 2.5 MB Critical Sev1 Linux

System
Available
Megabytes
Memory
Disk Avg. 5 25 > 0.05s Critical Sev1 Linux

Disk
sec/Read

Disk
sec/Transfer

Disk
sec/Write
Disk Status 5 25 <> 1 (true) Critical Sev1 Linux
Operating 5 10 >= 95% Critical Sev1 Linux

System
Total
Percent
Processor
Time
Total CPU 5 10 >= 95% Critical Sev1 Windows

Utilization
Percentage
File system 60 60 <> 4 Critical Sev1 Windows

error or
corruption
Average 1 15 > 0.04s Warning Sev2 Windows

Logical Disk
Seconds
Per Read

Logical Disk
Seconds
Per Transfer

Logical Disk
Seconds
Per Write
(Logical
Disk)
LOOKBACK
Current 5 60 >= 32 Warning Sev2 Windows

Disk Queue
Length
(Logical
Disk)
Logical Disk 15 60 > 500 MB Critical Sev1 Windows

Free Space warning Sev2
(MB) 300 MB
critical
Logical Disk 15 60 > 10% Critical Sev1 Windows

Free Space warning Sev2
(%) 5% critical
Logical Disk 15 360 <= 20% Warning Sev2 Windows

Percent Idle
Time
Percent 5 60 >= 60% Warning Sev2 Windows

Bandwidth
Used Read

Bandwidth
Used Total

Bandwidth
Used Write
DHCP 5 12 <> 4 (running) Critical Sev1 Windows

Client
Service
Health
DNS Client 5 12 <> 4 (running) Critical Sev1 Windows

Service
Health
Windows 5 12 <> 4 (running) Critical Sev1 Windows

Event Log
Service
Health

Firewall
Service
Health
RPC Service 5 12 <> 4 (running) Critical Sev1 Windows

Health
LOOKBACK
Server 5 12 <> 4 (running) Critical Sev1 Windows

Service
Health

Remote
Manageme
nt Service
Health
Available 5 10 < 100 MB Critical Sev1 Windows

Megabytes
of Memory
Free 5 10 <= 5000 Critical Sev1 Windows

System
Page Table
Entries
Memory 5 10 >= 5000/s Warning Sev1 Windows

Pages Per
Second
Percentage 5 10 > 80% Critical Sev1 Windows

of
Committed
Memory in
Use

Disk
Seconds
Per Transfer

Disk
Seconds
Per Write
Current 5 60 >= 32 Warning Sev2 Windows

Disk Queue
Length
Disk 5 60 >= 20% Warning Sev2 Windows

Percent Idle
Time
NOTE
Lookback Duration represents how often the look back window checks the metric values, such as over the last five minutes.
NOTE
Frequency represents how often the metric alert checks if the conditions are met, such as every one minute. It is the rate at
which health criterion is executed, and lookback is the duration over which health criterion is evaluated. For example, health
criterion is evaluating if the condition CPU utilization is greater than 95 percent with a frequency of 5 minutes and
remains greater than 95% for 15 minutes (3 consecutive evaluation cycles), then the state is updated to critical severity if it
wasn't already.

To sign in, go to the Azure portal.
Introduction to Azure Monitor for VMs health

Before you use the health feature for a single VM or group of VMs, it's important to understand how the
information is presented and what the visualizations represent.
View health directly from a VM
To view the health of an Azure VM, select Insights (preview) in the left pane of the VM. On the VM insights
page, the Health tab is open by default and shows the health view of the VM.
In the Guest VM health section, the table shows the health rollup of performance components monitored by
health criteria for the VM, and the total number of VM health alerts raised by unhealthy components. These
components include CPU, Memory, Disk, and Network. Expand the chevron next to Guest VM health to view
the health its components.
Selecting the state next to the component will open the Health Diagnostics experience in the context of the
selected component. It shows the composition of the state of that component, describing what health criteria are
used to compute its health. For more information, see Health Diagnostics and working with health criteria. For
more information about alerts, see Alerts.
The health states defined for a VM are described in the following table:
ICON HEALTH STATE MEANING
Healthy The VM is within the defined health

conditions. This state indicates there
are no issues detected and the VM is
functioning normally. With a parent
rollup monitor, health rolls up and
reflects the best-case or worst-case
state of the child.
Critical The state isn't within the defined health

condition, indicating that one or more
critical issues were detected. These
issues must be addressed to restore
normal functionality. With a parent
rollup monitor, the health state rolls up
and reflects the best-case or worst-
case state of the child.
ICON HEALTH STATE MEANING
Warning The state is between two thresholds for

the defined health condition, where
one indicates a warning state and the
other indicates a critical state (three
health state thresholds can be
configured), or when a non-critical
issue can cause critical problems if
unresolved. With a parent rollup
monitor, if one or more children is in a
warning state, the parent will reflect a
warning state. If one child is in a critical
state and another child in a warning
state, the parent rollup will show the
health state as critical.
Unknown The state can't be computed for several

reasons. The following section provides
additional details and possible
solutions.
An Unknown health state can be caused by the following issues:

The agent was reconfigured and no longer reports to the workspace specified when Azure Monitor for VMs
was enabled. To configure the agent to report to the workspace see, adding or removing a workspace.
The VM was deleted.
The workspace associated with Azure Monitor for VMs was deleted. You can recover the workspace if you
have Premier support benefits. Go to Premier and open a support request.
The solution dependencies were deleted. To re-enable the ServiceMap and InfrastructureInsights solutions in
your Log Analytics workspace, reinstall these solutions by using the Azure Resource Manager template. Or,
use the Configure Workspace option found in the Get Started tab.
The VM was shut down.
The Azure VM service is unavailable, or maintenance is being performed.
The workspace daily data or retention limit was met.
Select View health diagnostics to open a page showing all the components of a VM, associated health criteria,
state changes, and other issues detected by monitoring components related to the VM.
For more information, see Health diagnostics.
In the Health section, a table shows the health rollup of performance components monitored by health criteria.
These components include CPU, Memory, Disk, and Network. Selecting a component opens a page that lists
all the monitoring criterion and the health state of that component.
When you access health from an Azure VM that runs Windows, the health state of the top five core Windows
services is shown under Core services health. Selecting any of the services opens a page that lists the health
criteria monitoring for that component along with its health state.
Selecting the name of the health criteria opens the property pane. In this pane, you can review the configuration
details, including if the health criteria have a corresponding Azure Monitor alert.
For more information, see Health Diagnostics and working with health criteria.
Aggregate VM perspective
To view the health collection for all your VMs in a resource group, select Azure Monitor from the navigation list
in the portal, and then select Virtual Machines (preview).
In the Subscription and Resource Group drop-down lists, select the appropriate resource group that includes
the VMs related to the group, to view their reported health state. Your selection only applies to the health feature
and doesn't carry over to Performance or Map tabs.
The Health tab provides the following information:
How many VMs are in a critical or unhealthy state, versus how many are healthy or are not submitting data
(referred to as an Unknown state).
Which and how many VMs by OS are reporting an unhealthy state.
How many VMs are unhealthy because of an issue detected with a processor, disk, memory, or network
adapter, categorized by health state.
How many VMs are unhealthy because of an issue detected with a core OS service, categorized by health
state.
On the Health tab, you can identify the critical issues detected by the health criteria monitoring the VM, and
review alert details and associated knowledge articles. These articles can assist in the diagnosis and remediation
of issues. Select any of the severities to open the All Alerts page filtered by that severity.
The VM distribution by operating system list shows VMs listed by Windows edition or Linux distribution,
along with their version. In each OS category, the VMs are broken down further based on the health of the VM.
Select any column including VM count, Critical, Warning, Healthy, or Unknown. View the list of filtered
results in the Virtual Machines page that match the column selected.
For example, to review all VMs that run Red Hat Enterprise Linux release 7.5, select the VM count value for that
OS, and it will list the VMs matching that filter and their current health state.
You click Show Health check box and the health state is returned for the filtered results in the table.
For any one of the items in the list, you can click the corresponding health state to launch Health Diagnostics,
which shows how health is evaluated for the selected VM.
In the Virtual Machines page, if you select the name of a VM under the column VM Name, you're directed to
the VM instance page. This page provides more details of the alerts and health criteria issues that are affecting
the selected VM. Filter the health state details by selecting Health State icon in the upper-left corner of the page
to see which components are unhealthy. You can also view VM Health alerts raised by an unhealthy component
categorized by alert severity.
From the VM list view, select the name of a VM to open the Health page for that VM, similarly as if you selected
Insights (preview) from the VM directly.
The Virtual Machines (preview) in Azure Monitor page shows a rollup health status for the VM and alerts.
This health status is categorized by severity, which represents VM health alerts raised when the health state
changed from healthy to unhealthy, based on criteria. Selecting VMs in critical condition opens a page with a
list of one or more VMs in a critical health state.
Selecting the health status for one of the VMs shows the Health Diagnostics view of the VM. In this view, you
can determine which health criteria is reflecting a health-state issue. When the Health Diagnostics page opens,
it shows all the VM components and their associated health criteria with the current health state.
For more information, see Health diagnostics.
Selecting View all health criteria opens a page showing a list of all the health criteria available with this feature.
The information can be further filtered based on the following options:
Type. There are three types of health criteria to assess conditions and roll up the overall health state of a
monitored VM:
Unit. Measures some aspect of a VM. This health criteria type might be checking a performance
counter to determine the performance of the component, running a script to perform a synthetic
transaction, or watching for an event that indicates an error. The filter is set to unit by default.
Dependency. Provides a health rollup between different entities. This health criteria allows the health
of an entity to depend on the health of another type of entity that it relies on for successful operation.
Aggregate. Provides a combined health state of similar health criteria. Unit and dependency health
criterion are typically configured under an aggregate health criterion. In addition to providing better
general organization of the many different health criteria targeted at an entity, aggregate health
criterion provides a unique health state for distinct categories of the entities.
Category. The type of health criteria used to group similar criteria for reporting purposes. These
categories are Availability and Performance.
To see which instances are unhealthy, select a value under the Unhealthy Component column. In this page, a
table lists the components that are in a critical health state.
Health diagnostics
The Health Diagnostics page allows you to visualize the health model of a VM. This page lists all VM
components, associated health criteria, state changes, and other significant issues identified by monitored
components related to the VM.
Start health diagnostics by using the following methods:
By rollup health state for all VMs from the aggregate VM perspective in Azure Monitor:
1. On the Health page, select the icon for Critical, Warning, Healthy, or Unknown health state under
the section Guest VM health.
2. Go to the page that lists all the VMs matching that filtered category.
3. Select the value in the Health State column to open the health diagnostics scoped to that VM.
By OS from the aggregate VM perspective in Azure Monitor. Under VM distribution, selecting any one
of the column values will open the Virtual Machines page and return a list in the table matching the
filtered category. Selecting the value under Health State column opens health diagnostics for the selected
VM.
From the guest VM on the Azure Monitor for VMs Health tab, by selecting View health diagnostics.
Health diagnostics organizes health information into two categories: availability and performance.
All health criteria defined for a component, such as logical disk, CPU, and so on, can be viewed without filtering
on the two categories. These views can be in an all-up view of criteria, or via filtering the results by either
category when you select Availability or Performance.
Also, the criteria category can be seen next to the Health Criteria column. If the criteria don't match the selected
category, a message stating No health criteria available for the selected category appears in the Health
Criteria column.
The state of a health criteria is defined by one of four types: Critical, Warning, Healthy, and Unknown. The first
three are configurable, meaning that you can modify the threshold values of the monitors directly in the Health
Criteria configuration pane. This is also possible by using the Azure Monitor REST API update monitor
operation. Unknown isn't configurable and is reserved for specific scenarios.
The Health Diagnostics page has three main sections:
Component Model
Health Criteria
State Changes
Component model
The leftmost column in the Health Diagnostics page is Component Model. All components, which are
associated with the VM, are displayed in this column along with their current health state.
In the following example, the discovered components are Disk, Logical Disk, Processor, Memory, and
Operating System. Multiple instances of these components are discovered and displayed in this column.
For example, the following figure shows that the VM has two instances of logical disks, C: and D:, which are in a
healthy state:
Health criteria
The center column in the Health Diagnostics page is Health Criteria. The health model defined for the VM is
displayed in a hierarchical tree. The health model for a VM consists of unit and aggregate health criteria.
A health criterion measures the health of a monitored instance, which could be a threshold value, state of an
entity, and so on. A health criterion has either two or three configurable health state thresholds, as described
earlier. At any point, the health criterion can be in only one of its potential states.
The health model defines criteria that determine the health of the overall target and components of the target.
The hierarchy of criteria is shown in the Health Criteria section on the Health Diagnostics page.
The health-rollup policy is part of the configuration of aggregate health criteria (the default is set to worst-of).
You can find a default set of health criteria running as part of this feature in the Monitoring configuration details
section of this article.
You can also use the Azure Monitor REST API monitor instances list by resource to get a list of all health criteria.
This criteria includes configuration details running against the Azure VM resource.
The Unit health criteria type can have its configuration modified by selecting the ellipsis link to the right side.
Select Show Details to open the configuration pane.
In the configuration pane for the selected health criteria, if you use the example Average Disk Seconds Per
Write, the threshold can be configured with a different numeric value. It's a two-state monitor, meaning it can
change only from Healthy to Warning.
Other health criteria sometimes use three states, where you can configure the value for warning and critical
health-state thresholds. You can also modify a threshold by using Azure Monitor REST API monitor
configuration.
NOTE
Applying health criteria configuration changes to one instance applies them to all monitored instances. For example, if you
select Disk -1 D: and then modify the Average Disk Seconds Per Write threshold, the change applies to all instances
discovered and monitored on the VM.
If you want to learn more about health criteria, we've included knowledge articles to help you identify problems,
causes, and resolutions. Select View information on the page to see the related knowledge article.
To review all the knowledge articles included with Azure Monitor for VMs health, see Azure Monitor health
knowledge documentation.
State changes
The far-right column of the Health Diagnostics page is State Changes. This column lists all the state changes
associated with the health criteria selected in the Health Criteria section, or the state change of the VM if a VM
was selected from the Component Model or Health Criteria column of the table.
The following section shows the health-criteria state and the associated time. This information shows the latest
state at the top of the column.
Association of Component Model, Health Criteria, and State Changes columns
The three columns are interlinked with each other. When you select an instance in the Component Model
column, the Health Criteria column is filtered to that component view. Correspondingly, the State Changes
column is updated based on the selected health criteria.
For example, if you select Disk - 1 D: from the list under Component Model, Health Criteria filters to Disk -
1D:, and State Changes shows the state change based on the availability of Disk - 1 D:.
To see an updated health state, you can refresh the Health Diagnostics page by selecting the Refresh link. If there
is an update to the health criterion's health state based on the pre-defined polling interval, this task allows you to
avoid waiting and reflects the latest health state. The Health Criteria State is a filter that lets you scope the
results based on the selected health state: Healthy, Warning, Critical, Unknown, and All. The Last Updated time
in the upper-right corner represents the last time the Health Diagnostics page was refreshed.
Alerts
Azure Monitor for VMs health integrates with Azure Alerts. It raises an alert when predefined criteria, when
detected, change from a healthy state to an unhealthy state. Alerts are categorized by severity, from Sev 0
through Sev 4, with Sev 0 as the highest level.
Alerts aren't associated with an action group to notify you when the alert has been triggered. A user with Owner
role at the subscription scope must configure notifications by following the steps in the Configure alerts section.
The total number of VM Health alerts categorized by severity is available on the Health dashboard under the
Alerts section. When you select either the total number of alerts or the number corresponding to a severity level,
the Alerts page opens and lists all alerts matching your selection.
For example, if you select the row corresponding to Sev level 1, you'll see the following view:
The All Alerts page isn't scoped to show only alerts matching your selection. It's also filtered by Resource type
to show only health alerts raised by a VM resource. This format is reflected in the alert list, under the column
Target Resource, where it shows the Azure VM the raised alert when an unhealthy condition was met.
Alerts from other resource types or services are not intended to be included in this view. These alerts include log
alerts, which are based on log queries or metric alerts that you'd normally view from the default Azure Monitor
All Alerts page.
You can filter this view by selecting values in the drop-down menus at the top of the page.
COLUMN DESCRIPTION
Subscription Select an Azure subscription. Only alerts in the selected

subscription are included in the view.
Resource Group Select a single resource group. Only alerts with targets in the
selected resource group are included in the view.
COLUMN DESCRIPTION
Resource type Select one or more resource types. By default, only alerts of
target Virtual machines is selected and included in this view.
This column is only available after a resource group has been
specified.
Resource Select a resource. Only alerts with that resource as a target

are included in the view. This column is available only after a
resource type has been specified.
Severity Select an alert severity or select All to include alerts of all

severities.
Monitor Condition Select a monitor condition to filter alerts if they have been
fired or resolved by the system if the condition is no longer
active. Or, select All to include alerts of all conditions.
Alert state Select an alert state, New, Acknowledge, Closed, or All to

include alerts of all states.
Monitor service Select a service or select All to include all services. Only alerts
from VM Insights are supported for this feature.
Time range Only alerts fired within the selected time window are included
When you select an alert, the Alert detail page is displayed. This page provides details of the alert and allows
you to change its state.
To learn more about managing alerts, see Create, view, and manage alerts using Azure Monitor.
NOTE
Creating new alerts based on health criteria or modifying existing health alert rules in Azure Monitor from the portal isn't
currently supported.
You can change an alert state for one or multiple alerts by selecting them, and then selecting Change state from
the All Alerts page in the upper-left corner. Select one of the states on the Change alert state pane, add a
description of the change in the Comment field, and then select Ok to commit your changes. When the
information is verified and the changes are applied, track the progress under Notifications in the menu.
Configure alerts
You can't manage certain alert-management tasks from the Azure portal. These tasks must be performed by
using the Azure Monitor REST API. Specifically:
Enabling or disabling an alert for health criteria
Setting up notifications for health criteria alerts
Each example uses ARMClient on your Windows machine. If you are not familiar with this method, see Using
ARMClient.
Enable or disable an alert rule
To enable or disable an alert for specific health criteria, the property alertGeneration must be modified with a
value of either Disabled or Enabled.
To identify the monitorId for specific health criteria, the following example shows how to query for that value for
the criteria LogicalDisk\Avg Disk Seconds Per Transfer:
1. In a terminal window, type armclient.exe login. Doing so prompts you to sign in to Azure.
2. Enter the following command to retrieve all the health criterion active on a specific VM and identify the
value for monitorId property:
armclient GET
"subscriptions/subscriptionId/resourceGroups/resourcegroupName/providers/Microsoft.Compute/virtualMach
ines/vmName/providers/Microsoft.WorkloadMonitor/monitors?api-version=2018-08-31-preview”
The following example shows the output of the armclient GET command. Take note of the value of
MonitorId. This value is required for the next step, where we must specify the ID of the health criteria and
modify its property to create an alert.
"id": "/subscriptions/a7f23fdb-e626-4f95-89aa-
3a360a90861e/resourcegroups/Lab/providers/Microsoft.Compute/virtualMachines/SVR01/providers/Microsoft.
WorkloadMonitor/monitors/ComponentTypeId='LogicalDisk',MonitorId='Microsoft_LogicalDisk_AvgDiskSecPerR
ead'",
"name": "ComponentTypeId='LogicalDisk',MonitorId='Microsoft_LogicalDisk_AvgDiskSecPerRead'",
"type": "Microsoft.WorkloadMonitor/virtualMachines/monitors"
},
{
"properties": {
"description": "Monitor the performance counter LogicalDisk\\Avg Disk Sec Per Transfer",
"monitorId": "Microsoft_LogicalDisk_AvgDiskSecPerTransfer",
"monitorName": "Microsoft.LogicalDisk.AvgDiskSecPerTransfer",
"monitorDisplayName": "Average Logical Disk Seconds Per Transfer",
"parentMonitorName": null,
"parentMonitorDisplayName": null,
"monitorType": "Unit",
"monitorCategory": "PerformanceHealth",
"componentTypeId": "LogicalDisk",
"componentTypeName": "LogicalDisk",
"componentTypeDisplayName": "Logical Disk",
"monitorState": "Enabled",
"criteria": [
{
"healthState": "Warning",
"comparisonOperator": "GreaterThan",
"threshold": 0.1
}
],
"alertGeneration": "Enabled",
"frequency": 1,
"lookbackDuration": 17,
"documentationURL": "https://aka.ms/Ahcs1r",
"configurable": true,
"signalType": "Metrics",
"signalName": "VMHealth_Avg. Logical Disk sec/Transfer"
},
"etag": null,
3. Enter the following command to modify the alertGeneration property:
armclient patch
subscriptions/subscriptionId/resourceGroups/resourcegroupName/providers/Microsoft.Compute/virtualMachi
nes/vmName/providers/Microsoft.WorkloadMonitor/monitors/Microsoft_LogicalDisk_AvgDiskSecPerTransfer?
api-version=2018-08-31-preview "{'properties':{'alertGeneration':'Disabled'}}"
4. Enter the GET command used in step 2 to verify that the property value is set to Disabled.
Associate an action group with health criteria
Azure Monitor for VMs health supports SMS and email notifications when alerts are generated from unhealthy
health criteria. To configure notifications, note the name of the configured action group to send SMS or email
notifications.
NOTE
This action must be performed against each monitored VM that you want to receive a notification for. It doesn't apply to all
VMs in a resource group.
1. In a terminal window, enter armclient.exe login. Doing so prompts you to sign in to Azure.
2. Enter the following command to associate an action group with alert rules:
$payload = "{'properties':{'ActionGroupResourceIds':
['/subscriptions/subscriptionId/resourceGroups/resourcegroupName/providers/microsoft.insights/actionGr
oups/actiongroupName']}}"
armclient PUT
https://management.azure.com/subscriptions/subscriptionId/resourceGroups/resourcegroupName/providers/M
icrosoft.Compute/virtualMachines/vmName/providers/Microsoft.WorkloadMonitor/notificationSettings/defau
lt?api-version=2018-08-31-preview $payload
3. To verify that the value of the property actionGroupResourceIds was successfully updated, enter the
following command:
armclient GET
"subscriptions/subscriptionName/resourceGroups/resourcegroupName/providers/Microsoft.Compute/virtualMa
chines/vmName/providers/Microsoft.WorkloadMonitor/notificationSettings?api-version=2018-08-31-preview"
The output should look like the following criteria:
{
"value": [
{
"properties": {
"actionGroupResourceIds": [
"/subscriptions/a7f23fdb-e626-4f95-89aa-
3a360a90861e/resourceGroups/Lab/providers/microsoft.insights/actionGroups/Lab-IT%20Ops%20Notify"
]
},
"etag": null,
"id": "/subscriptions/a7f23fdb-e626-4f95-89aa-
3a360a90861e/resourcegroups/Lab/providers/Microsoft.Compute/virtualMachines/SVR01/providers/Microsoft.
WorkloadMonitor/notificationSettings/default",
"name": "notificationSettings/default",
"type": "Microsoft.WorkloadMonitor/virtualMachines/notificationSettings"
}
],
"nextLink": null
}
Next steps
To identify limitations and overall VM performance, see View Azure VM performance.
To learn about discovered application dependencies, see View Azure Monitor for VMs Map.
Use the Map feature of Azure Monitor for VMs
(preview) to understand application components
In Azure Monitor for VMs, you can view discovered application components on Windows and Linux virtual
machines (VMs) that run in Azure or your environment. You can observe the VMs in two ways. View a map
directly from a VM or view a map from Azure Monitor to see the components across groups of VMs. This article
will help you understand these two viewing methods and how to use the Map feature.
For information about configuring Azure Monitor for VMs, see Enable Azure Monitor for VMs.
Sign in to Azure
Introduction to the Map experience

Before diving into the Map experience, you should understand how it presents and visualizes information.
Whether you select the Map feature directly from a VM or from Azure Monitor, the Map feature presents a
consistent experience. The only difference is that from Azure Monitor, one map shows all the members of a
multiple-tier application or cluster.
The Map feature visualizes the VM dependencies by discovering running processes that have:
Active network connections between servers.
Inbound and outbound connection latency.
Ports across any TCP -connected architecture over a specified time range.
Expand a VM to show process details and only those processes that communicate with the VM. The client group
shows the count of front-end clients that connect into the VM. The server-port groups show the count of back-
end servers the VM connects to. Expand a server-port group to see the detailed list of servers that connect over
that port.
When you select the VM, the Properties pane on the right shows the VM's properties. Properties include
system information reported by the operating system, properties of the Azure VM, and a doughnut chart that
summarizes the discovered connections.
On the right side of the pane, select Log Events to show a list of data that the VM has sent to Azure Monitor.
This data is available for querying. Select any record type to open the Logs page, where you see the results for
that record type. You also see a preconfigured query that's filtered against the VM.
Close the Logs page and return to the Properties pane. There, select Alerts to view VM health-criteria alerts.
The Map feature integrates with Azure Alerts to show alerts for the selected server in the selected time range.
The server displays an icon for current alerts, and the Machine Alerts pane lists the alerts.
To make the Map feature display relevant alerts, create an alert rule that applies to a specific computer:
Include a clause to group alerts by computer (for example, by Computer interval 1 minute).
Base the alert on a metric.
For more information about Azure Alerts and creating alert rules, see Unified alerts in Azure Monitor.
In the upper-right corner, the Legend option describes the symbols and roles on the map. For a closer look at
your map and to move it around, use the zoom controls in the lower-right corner. You can set the zoom level and
fit the map to the size of the page.
Connection metrics
The Connections pane displays standard metrics for the selected connection from the VM over the TCP port.
The metrics include response time, requests per minute, traffic throughput, and links.
Failed connections
The map shows failed connections for processes and computers. A dashed red line indicates a client system is
failing to reach a process or port. For systems that use the Dependency agent, the agent reports on failed
connection attempts. The Map feature monitors a process by observing TCP sockets that fail to establish a
connection. This failure could result from a firewall, a misconfiguration in the client or server, or an unavailable
remote service.
Understanding failed connections can help you troubleshoot, validate migration, analyze security, and
understand the overall architecture of the service. Failed connections are sometimes harmless, but they often
point to a problem. Connections might fail, for example, when a failover environment suddenly becomes
unreachable or when two application tiers can't communicate with each other after a cloud migration.
Client groups
On the map, client groups represent client machines that connect to the mapped machine. A single client group
represents the clients for an individual process or machine.
To see the monitored clients and IP addresses of the systems in a client group, select the group. The contents of
the group appear below.
If the group includes monitored and unmonitored clients, you can select the appropriate section of the group's
doughnut chart to filter the clients.
Server-port groups
Server-port groups represent ports on servers that have inbound connections from the mapped machine. The
group contains the server port and a count of the number of servers that have connections to that port. Select
the group to see the individual servers and connections.
If the group includes monitored and unmonitored servers, you can select the appropriate section of the group's
doughnut chart to filter the servers.
View a map from a VM

To access Azure Monitor for VMs directly from a VM:
1. In the Azure portal, select Virtual Machines.
2. From the list, choose a VM. In the Monitoring section, choose Insights (preview).
3. Select the Map tab.
The map visualizes the VM's dependencies by discovering running process groups and processes that have
active network connections over a specified time range.
By default, the map shows the last 30 minutes. If you want to see how dependencies looked in the past, you can
query for historical time ranges of up to one hour. To run the query, use the TimeRange selector in the upper-
left corner. You might run a query, for example, during an incident or to see the status before a change.
View a map from a virtual machine scale set
To access Azure Monitor for VMs directly from a virtual machine scale set:
1. In the Azure portal, select Virtual machine scale sets.
2. From the list, choose a VM. Then in the Monitoring section, choose Insights (preview).
The map visualizes all instances in the scale set as a group node along with the group's dependencies. The
expanded node lists the instances in the scale set. You can scroll through these instances 10 at a time.
To load a map for a specific instance, first select that instance on the map. Then select the ellipsis button (...) to
the right and choose Load Server Map. In the map that appears, you see process groups and processes that
have active network connections over a specified time range.
query for historical time ranges of up to one hour. To run the query, use the TimeRange selector. You might run
a query, for example, during an incident or to see the status before a change.
NOTE
You can also access a map for a specific instance from the Instances view for your virtual machine scale set. In the
Settings section, go to Instances > Insights (preview).
View a map from Azure Monitor

In Azure Monitor, the Map feature provides a global view of your VMs and their dependencies. To access the
Map feature in Azure Monitor:
2. In the Insights section, choose Virtual Machines (preview).
Choose a workspace by using the Workspace selector at the top of the page. If you have more than one Log
Analytics workspace, choose the workspace that's enabled with the solution and that has VMs reporting to it.
The Group selector returns subscriptions, resource groups, computer groups, and virtual machine scale sets of
computers that are related to the selected workspace. Your selection applies only to the Map feature and doesn't
carry over to Performance or Health.
query for historical time ranges of up to one hour. To run the query, use the TimeRange selector. You might run
a query, for example, during an incident or to see the status before a change.
Next steps
To learn how to use the Health feature, see View Azure VM health.
To identify bottlenecks, check performance, and understand overall utilization of your VMs, see View
performance status for Azure Monitor for VMs.
How to chart performance with Azure Monitor for
VMs (preview)
Azure Monitor for VMs includes a set of performance charts that target several key performance indicators (KPIs)
to help you determine how well a virtual machine is performing. The charts show resource utilization over a
period of time so you can identify bottlenecks, anomalies, or switch to a perspective listing each machine to view
resource utilization based on the metric selected. While there are numerous elements to consider when dealing
with performance, Azure Monitor for VMs monitors key operating system performance indicators related to
processor, memory, network adapter, and disk utilization. Performance complements the health monitoring
feature and helps expose issues that indicate a possible system component failure, support tuning and
optimization to achieve efficiency, or support capacity planning.
Multi-VM perspective from Azure Monitor

From Azure Monitor, the Performance feature provides a view of all monitored VMs deployed across workgroups
in your subscriptions or in your environment. To access from Azure Monitor, perform the following steps.
2. Choose Virtual Machines (preview) in the Solutions section.
3. Select the Performance tab.
On the Top N Charts tab, if you have more than one Log Analytics workspace, choose the workspace enabled
with the solution from the Workspace selector at the top of the page. The Group selector will return
subscriptions, resource groups, computer groups, and virtual machine scale sets of computers related to the
selected workspace that you can use to further filter results presented in the charts on this page and across the
other pages. Your selection only applies to the Performance feature and does not carry over to Health or Map.
By default, the charts show the last 24 hours. Using the TimeRange selector, you can query for historical time
ranges of up to 30 days to show how performance looked in the past.
The five capacity utilization charts shown on the page are:
CPU Utilization % - shows the top five machines with the highest average processor utilization
Available Memory - shows the top five machines with the lowest average amount of available memory
Logical Disk Space Used % - shows the top five machines with the highest average disk space used % across
all disk volumes
Bytes Sent Rate - shows the top five machines with highest average of bytes sent
Bytes Receive Rate - shows the top five machines with highest average of bytes sent
Clicking on the pin icon at the upper right-hand corner of any one of the five charts will pin the selected chart to
the last Azure dashboard you last viewed. From the dashboard, you can resize and reposition the chart. Selecting
the chart from the dashboard will redirect you to Azure Monitor for VMs and load the correct scope and view.
Clicking on the icon located to the left of the pin icon on any one of the five charts opens the Top N List view.
Here you see the resource utilization for that performance metric by individual VM in a list view and which
machine is trending highest.
When you click on the virtual machine, the Properties pane is expanded on the right to show the properties of
the item selected, such as system information reported by the operating system, properties of the Azure VM, etc.
Clicking on one of the options under the Quick Links section will redirect you to that feature directly from the
selected VM.
Switch to the Aggregated Charts tab to view the performance metrics filtered by average or percentiles
measures.
The following capacity utilization charts are provided:

CPU Utilization % - defaults showing the average and top 95th percentile
Available Memory - defaults showing the average, top 5th, and 10th percentile
Logical Disk Space Used % - defaults showing the average and 95th percentile
Bytes Sent Rate - defaults showing average bytes sent
Bytes Receive Rate - defaults showing average bytes received
You can also change the granularity of the charts within the time range by selecting Avg, Min, Max, 50th, 90th,
and 95th in the percentile selector.
To view the resource utilization by individual VM in a list view and see which machine is trending with highest
utilization, select the Top N List tab. The Top N List page shows the top 20 machines sorted by the most utilized
by 95th percentile for the metric CPU Utilization %. You can see more machines by selecting Load More, and the
results expand to show the top 500 machines.
NOTE
The list cannot show more than 500 machines at a time.
To filter the results on a specific virtual machine in the list, enter its computer name in the Search by name
textbox.
If you would rather view utilization from a different performance metric, from the Metric drop-down list select
Available Memory, Logical Disk Space Used %, Network Received Byte/s, or Network Sent Byte/s and
the list updates to show utilization scoped to that metric.
Selecting a virtual machine from the list opens the Properties panel on the right-side of the page and from here
you can select Performance detail. The Virtual Machine Detail page opens and is scoped to that VM, similar
in experience when accessing VM Insights Performance directly from the Azure VM.
View performance directly from an Azure VM

To access directly from a virtual machine, perform the following steps.
2. From the list, choose a VM and in the Monitoring section choose Insights (preview).
3. Select the Performance tab.
This page not only includes performance utilization charts, but also a table showing for each logical disk
discovered, its capacity, utilization, and total average by each measure.
The following capacity utilization charts are provided:
CPU Utilization % - defaults showing the average and top 95th percentile
Available Memory - defaults showing the average, top 5th, and 10th percentile
Logical Disk Space Used % - defaults showing the average and 95th percentile
Logical Disk IOPS - defaults showing the average and 95th percentile
Logical Disk MB/s - defaults showing the average and 95th percentile
Max Logical Disk Used % - defaults showing the average and 95th percentile
Bytes Sent Rate - defaults showing average bytes sent
Bytes Receive Rate - defaults showing average bytes received
Clicking on the pin icon at the upper right-hand corner of any one of the charts pins the selected chart to the last
Azure dashboard you viewed. From the dashboard, you can resize and reposition the chart. Selecting the chart
from the dashboard redirects you to Azure Monitor for VMs and loads the performance detail view for the VM.
View performance directly from an Azure virtual machine scale set

To access directly from an Azure virtual machine scale set, perform the following steps.
1. In the Azure portal, select Virtual machine scale sets.
2. From the list, choose a VM and in the Monitoring section choose Insights (preview) to view the
Performance tab.
This page loads the Azure Monitor performance view, scoped to the selected scale set. This enables you to see the
Top N Instances in the scale set across the set of monitored metrics, view the aggregate performance across the
scale set, and see the trends for selected metrics across the individual instances n the scale set. Selecting an
instance from the list view lets you load it's map or navigate into a detailed performance view for that instance.
Clicking on the pin icon at the upper right-hand corner of any one of the charts pins the selected chart to the last
Azure dashboard you viewed. From the dashboard, you can resize and reposition the chart. Selecting the chart
from the dashboard redirects you to Azure Monitor for VMs and loads the performance detail view for the VM.
NOTE
You can also access a detailed performance view for a specific instance from the Instances view for your scale set. Navigate
to Instances under the Settings section, and then choose Insights (preview).
Alerts
Performance metrics enabled as part of Azure Monitor for VMs do not include pre-configured alert rules. There
are health alerts corresponding to performance issues detected on your Azure VM, such as high CPU utilization,
low memory available, low disk space, etc. However, these health alerts only apply to all VMs enabled for Azure
Monitor for VMs.
However, we may only collect and store a subset of the performance metrics you require in the Log Analytics
workspace. If your monitoring strategy requires analysis or alerting that includes other performance metrics in
order to effectively evaluate capacity or health of the virtual machine, or you need the flexibility to specify your
own alerting criteria or logic, you can configure collection of those performance counters in Log Analytics and
define log alerts. While Log Analytics allows you to perform complex analysis with other data types, and provide
longer retention to support trend analysis, metrics on the other hand, are lightweight and capable of supporting
near real-time scenarios. They are collected by the Azure Diagnostic agent and stored in the Azure Monitor
metrics store, allowing you to create alerts with lower latency and at a lower cost.
Review the overview of collection of metrics and logs with Azure Monitor to further understand the fundamental
differences and other considerations before configuring collection of these additional metrics and alert rules.
Next steps
To learn how to use the health feature, see View Azure Monitor for VMs Health, or to view discovered application
dependencies, see View Azure Monitor for VMs Map.
Create interactive reports with Azure Monitor
workbooks
Workbooks combine text,log queries, metrics, and parameters into rich interactive reports. Workbooks are editable
by any other team members who have access to the same Azure resources.
Workbooks are helpful for scenarios such as:
Exploring the usage of your virtual machine when you don't know the metrics of interest in advance: CPU
utilization, disk space, memory, network dependencies, etc. Unlike other usage analytics tools, workbooks let
you combine multiple kinds of visualizations and analyses, making them great for this kind of free-form
exploration.
Explaining to your team how a recently provisioned VM is performing, by showing metrics for key counters and
other log events.
Sharing the results of a resizing experiment of your VM with other members of your team. You can explain the
goals for the experiment with text, then show each usage metric and analytics queries used to evaluate the
experiment, along with clear call-outs for whether each metric was above- or below -target.
Reporting the impact of an outage on the usage of your VM, combining data, text explanation, and a discussion
of next steps to prevent outages in the future.
Azure Monitor for VMs includes several workbooks to get you started, and the following table summarizes them.
WORKBOOK DESCRIPTION SCOPE
Performance Provides a customizable version of our At scale

Top N List and Charts view in a single
workbook that leverages all of the Log
Analytics performance counters that
you have enabled.
Performance counters A Top N chart view across a wide set of At scale

performance counters.
Connections Connections provides an in-depth view At scale

of the inbound and outbound
connections from your monitored VMs.
Active Ports Provides a list of the processes that At scale

have bound to the ports on the
monitored VMs and their activity in the
chosen timeframe.
Open Ports Provides the number of ports open on At scale

your monitored VMs and the details on
those open ports.
Failed Connections Display the count of failed connections At scale

on your monitored VMs, the failure
trend, and if the percentage of failures is
increasing over time.
WORKBOOK DESCRIPTION SCOPE
Security and Audit An analysis of your TCP/IP traffic that At scale

reports on overall connections,
malicious connections, where the IP
endpoints reside globally. To enable all
features, you will need to enable
Security Detection.
TCP Traffic A ranked report for your monitored At scale

VMs and their sent, received, and total
network traffic in a grid and displayed
as a trend line.
Traffic Comparison This workbooks lets you compare At scale

network traffic trends for a single
machine or a group of machines.
Performance Provides a customizable version of our Single VM

Performance view that leverages all of
the Log Analytics performance counters
that you have enabled.
Connections Connections provides an in-depth view Single VM

of the inbound and outbound
connections from your VM.
Starting with a template or saved workbook

A workbook is made up of sections consisting of independently editable charts, tables, text, and input controls. To
better understand workbooks, let's start by opening a template and walk through creating a custom workbook.
2. Select Virtual Machines.
4. On the VM page, in the Monitoring section, select Insights (preview).
5. On the VM insights page, select Performance or Maps tab and then select View Workbooks from the link
on the page.
6. From the drop-down list, select Go to Gallery from the bottom of the list.
It launches the workbook gallery with a number of prebuilt workbooks to help you get started.
7. We'll start with the Default Template, which is located under the heading Quick start.
Editing workbook sections

Workbooks have two modes: editing mode, and reading mode. When the default template workbook is first
launched, it opens in editing mode. It shows all the content of the workbook, including any steps and parameters
that are otherwise hidden. Reading mode presents a simplified report style view. Reading mode allows you to
abstract away the complexity that went into creating a report while still having the underlying mechanics only a few
clicks away when needed for modification.
1. When you're done editing a section, click Done Editing in the bottom-left corner of the section.
2. To create a duplicate of a section, click the Clone this section icon. Creating duplicate sections is a great to
way to iterate on a query without losing previous iterations.
3. To move up a section in a workbook, click the Move up or Move down icon.
4. To remove a section permanently, click the Remove icon.
Adding text and Markdown sections

Adding headings, explanations, and commentary to your workbooks helps turn a set of tables and charts into a
narrative. Text sections in workbooks support the Markdown syntax for text formatting, like headings, bold, italics,
and bulleted lists.
To add a text section to your workbook, use the Add text button at the bottom of the workbook, or at the bottom
of any section.
Adding query sections
To add query section to your workbook, use the Add query button at the bottom of the workbook, or at the
bottom of any section.
Query sections are highly flexible and can be used to answer questions like:
How was my CPU utilization during the same time period as an increase in network traffic?
What was the trend in available disk space over the last month?
How many network connection failures did my VM experience over the last two weeks?
You also aren't only limited to querying from the context of the virtual machine you launched the workbook from.
You can query across multiple virtual machines, as well as Log Analytics workspaces, as long as you have access
permission to those resources.
To include data from other Log Analytics workspaces or from a specific Application Insights app using the
workspace identifier. To learn more about cross-resource queries, refer to the official guidance.
Advanced analytic query settings
Each section has its own advanced settings, which are accessible via the settings icon located to the right of the
Add parameters button.
Custom width Makes an item an arbitrary size, so you can fit many items on
a single line allowing you to better organize your charts and
tables into rich interactive reports.
Conditionally visible Specify to hide steps based on a parameter when in reading

mode.
Export a parameter Allow a selected row in the grid or chart to cause later steps to
change values or become visible.
Show query when not editing Displays the query above the chart or table even when in
reading mode.
Show open in analytics button when not editing Adds the blue Analytics icon to the right-hand corner of the
chart to allow one-click access.
Most of these settings are fairly intuitive, but to understand Export a parameter it is better to examine a
workbook that makes use of this functionality.
One of the prebuilt workbooks - TCP Traffic, provides information on connection metrics from a VM.
The first section of the workbook is based on log query data. The second section is also based on log query data,
but selecting a row in the first table will interactively update the contents of the charts:
The behavior is possible through use of the When an item is selected, export a parameter advanced settings,
which are enabled in the table's log query.
The second log query then utilizes the exported values when a row is selected to create a set of values that are then
used by the section heading and charts. If no row is selected, it hides the section heading and charts.
For example, the hidden parameter in the second section uses the following reference from the row selected in the
grid:
VMConnection
| where TimeGenerated {TimeRange}
| where Computer in ("{ComputerName}") or '*' in ("{ComputerName}")
| summarize Sent = sum(BytesSent), Received = sum(BytesReceived) by bin(TimeGenerated, {TimeRange:grain})
Adding metrics sections

Metrics sections give you full access to incorporate Azure Monitor metrics data into your interactive reports. In
Azure Monitor for VMs, the prebuilt workbooks will typically contain analytic query data rather than metric data.
You may choose to create workbooks with metric data, allowing you to take full advantage of the best of both
features all in one place. You also have the ability to pull in metric data from resources in any of the subscriptions
you have access to.
Here is an example of virtual machine data being pulled into a workbook to provide a grid visualization of CPU
performance:
Adding parameter sections

Workbook parameters allow you to change values in the workbook without having to manually edit the query or
text sections. This removes the requirement of needing to understand the underlying analytics query language and
greatly expands the potential audience of workbook-based reporting.
The values of parameters are replaced in query, text or other parameter sections by putting the name of the
parameter in braces, like {parameterName} . Parameter names are limited to similar rules as JavaScript identifiers,
alphabetic characters or underscores, followed by alphanumeric characters or underscores. For example, a1 is
allowed, but 1a is not allowed.
Parameters are linear, starting from the top of a workbook and flowing down to later steps. Parameters declared
later in a workbook can override parameters that were declared earlier. This also lets parameters that use queries to
access the values from parameters defined earlier. Within a parameter's step itself, parameters are also linear, left to
right, where parameters to the right can depend on a parameter declared earlier in that same step.
There are four different types of parameters, which are currently supported:
Text Allows the user to edit a text box, and you can optionally
supply a query to fill in the default value.
Drop down Allows the user to choose from a set of values.
Time range picker Allows the user to choose from a predefined set of time range
values, or pick from a custom time range.
Resource picker Allows the user to choose from the resources selected for the
workbook.
Using a text parameter

The value a user types in the text box is replaced directly in the query, with no escaping or quoting. If the value you
need is a string, the query should have quotes around the parameter (like '{parameter}').
The text parameter allows the value in a text box to be used anywhere. It can be a table name, column name,
function name, operator, etc. The text parameter type has a setting Get default value from analytics query,
which allows the workbook author to use a query to populate the default value for that text box.
When using the default value from a log query, only the first value of the first row (row 0, column 0) is used as the
default value. Therefore it is recommended to limit your query to return just one row and one column. Any other
data returned by the query is ignored.
Whatever value the query returns will be replaced directly with no escaping or quoting. If the query returns no
rows, the result of the parameter is either an empty string (if the parameter is not required) or undefined (if the
parameter is required).
Using a drop-down
The dropdown parameter type lets you create a drop-down control, allowing the selection of one or many values.
The dropdown is populated by a log query or JSON. If the query returns one column, the values in that column are
both the value and the label in the drop-down control. If the query returns two columns, the first column is the
value, and the second column is the label shown in the drop-down. If the query returns three columns, the third
column is used to indicate the default selection in that drop-down. This column can be any type, but the simplest is
to use bool or numeric types, where 0 is false, and 1 is true.
If the column is a string type, null/empty string is considered false, and any other value is considered true. For
single selection drop-downs, the first value with a true value is used as the default selection. For multiple selection
drop-downs, all values with a true value are used as the default selected set. The items in the drop-down are shown
in whatever order the query returned rows.
Let's look at the parameters present in the Connections Overview report. Click the edit symbol next to Direction.
This will launch the Edit Parameter menu item.

The JSON lets you generate an arbitrary table populated with content. For example, the following JSON generates
two values in the drop-down:
[
{ "value": "inbound", "label": "Inbound"},
{ "value": "outbound", "label": "Outbound"}
]
A more applicable example is using a drop-down to pick from a set of performance counters by name:
Perf
| summarize by CounterName, ObjectName
| order by ObjectName asc, CounterName asc
| project Counter = pack('counter', CounterName, 'object', ObjectName), CounterName, group = ObjectName
The query will display results as follows:

Drop-downs are incredibly powerful tools for customizing and creating interactive reports.
Time range parameters
While you can make your own custom time range parameter via the dropdown parameter type, you can also use
the out-of-box time range parameter type if you don't need the same degree of flexibility.
Time range parameter types have 15 default ranges that go from five minutes to the last 90 days. There is also an
option to allow custom time range selection, which allows the operator of the report to choose explicit start and
stop values for the time range.
Resource picker
The resource picker parameter type gives you the ability to scope your report to certain types of resources. An
example of a prebuilt workbook that leverages the resource picker type is the Performance workbook.
Saving and sharing workbooks with your team
Workbooks are saved within a Log Analytics Workspace or a virtual machine resource, depending on how you
access the workbooks gallery. The workbook can be saved to the My Reports section that's private to you or in the
Shared Reports section that's accessible to everyone with access to the resource. To view all the workbooks in the
resource, click the Open button in the action bar.
To share a workbook that's currently in My Reports:
1. Click Open in the action bar
2. Click the "..." button beside the workbook you want to share
3. Click Move to Shared Reports.
To share a workbook with a link or via email, click Share in the action bar. Keep in mind that recipients of the link
need access to this resource in the Azure portal to view the workbook. To make edits, recipients need at least
Contributor permissions for the resource.
To pin a link to a workbook to an Azure Dashboard:
2. Click the "..." button beside the workbook you want to pin
3. Click Pin to dashboard.
Next steps
To learn how to use the health feature, see View Azure VM Health, or to view discovered application dependencies,
see View Azure Monitor for VMs Map.
How to query logs from Azure Monitor for VMs
(preview)
Azure Monitor for VMs collects performance and connection metrics, computer and process inventory data, and
health state information and forwards it to the Log Analytics workspace in Azure Monitor. This data is available for
query in Azure Monitor. You can apply this data to scenarios that include migration planning, capacity analysis,
discovery, and on-demand performance troubleshooting.
Map records
One record is generated per hour for each unique computer and process, in addition to the records that are
generated when a process or computer starts or is on-boarded to Azure Monitor for VMs Map feature. These
records have the properties in the following tables. The fields and values in the ServiceMapComputer_CL events
map to fields of the Machine resource in the ServiceMap Azure Resource Manager API. The fields and values in
the ServiceMapProcess_CL events map to the fields of the Process resource in the ServiceMap Azure Resource
Manager API. The ResourceName_s field matches the name field in the corresponding Resource Manager
resource.
There are internally generated properties you can use to identify unique processes and computers:
Computer: Use ResourceId or ResourceName_s to uniquely identify a computer within a Log Analytics
workspace.
Process: Use ResourceId to uniquely identify a process within a Log Analytics workspace. ResourceName_s is
unique within the context of the machine on which the process is running (MachineResourceName_s)
Because multiple records can exist for a specified process and computer in a specified time range, queries can
return more than one record for the same computer or process. To include only the most recent record, add "|
dedup ResourceId" to the query.
Connections and ports
The Connection Metrics feature introduces two new tables in Azure Monitor logs - VMConnection and
VMBoundPort. These tables provide information about the connections for a machine (inbound and outbound), as
well as the server ports that are open/active on them. ConnectionMetrics are also exposed via APIs that provide
the means to obtain a specific metric during a time window. TCP connections resulting from accepting on a
listening socket are inbound, while those created by connecting to a given IP and port are outbound. The direction
of a connection is represented by the Direction property, which can be set to either inbound or outbound.
Records in these tables are generated from data reported by the Dependency Agent. Every record represents an
observation over a 1-minute time interval. The TimeGenerated property indicates the start of the time interval.
Each record contains information to identify the respective entity, that is, connection or port, as well as metrics
associated with that entity. Currently, only network activity that occurs using TCP over IPv4 is reported.
Common fields and conventions
The following fields and conventions apply to both VMConnection and VMBoundPort:
Computer: Fully-qualified domain name of reporting machine
AgentID: The unique identifier for a machine with the Log Analytics agent
Machine: Name of the Azure Resource Manager resource for the machine exposed by ServiceMap. It is of the
form m -{GUID }, where GUID is the same GUID as AgentID
Process: Name of the Azure Resource Manager resource for the process exposed by ServiceMap. It is of the
form p -{hex string }. Process is unique within a machine scope and to generate a unique process ID across
machines, combine Machine and Process fields.
ProcessName: Executable name of the reporting process.
All IP addresses are strings in IPv4 canonical format, for example 13.107.3.160
To manage cost and complexity, connection records do not represent individual physical network connections.
Multiple physical network connections are grouped into a logical connection, which is then reflected in the
respective table. Meaning, records in VMConnection table represent a logical grouping and not the individual
physical connections that are being observed. Physical network connection sharing the same value for the
following attributes during a given one-minute interval, are aggregated into a single logical record in
VMConnection.
Direction Direction of the connection, value is inbound or outbound
Machine The computer FQDN
Process Identity of process or groups of processes, initiating/accepting

the connection
SourceIp IP address of the source
DestinationIp IP address of the destination
DestinationPort Port number of the destination
Protocol Protocol used for the connection. Values is tcp.
To account for the impact of grouping, information about the number of grouped physical connections is provided
in the following properties of the record:
LinksEstablished The number of physical network connections that have been

established during the reporting time window
LinksTerminated The number of physical network connections that have been

terminated during the reporting time window
LinksFailed The number of physical network connections that have failed

during the reporting time window. This information is
currently available only for outbound connections.
LinksLive The number of physical network connections that were open

at the end of the reporting time window
Metrics
In addition to connection count metrics, information about the volume of data sent and received on a given logical
connection or network port are also included in the following properties of the record:
BytesSent Total number of bytes that have been sent during the
reporting time window
BytesReceived Total number of bytes that have been received during the
Responses The number of responses observed during the reporting time

window.
ResponseTimeMax The largest response time (milliseconds) observed during the

reporting time window. If no value, the property is blank.
ResponseTimeMin The smallest response time (milliseconds) observed during the

ResponseTimeSum The sum of all response times (milliseconds) observed during

the reporting time window. If no value, the property is blank.
The third type of data being reported is response time - how long does a caller spend waiting for a request sent
over a connection to be processed and responded to by the remote endpoint. The response time reported is an
estimation of the true response time of the underlying application protocol. It is computed using heuristics based
on the observation of the flow of data between the source and destination end of a physical network connection.
Conceptually, it is the difference between the time the last byte of a request leaves the sender, and the time when
the last byte of the response arrives back to it. These two timestamps are used to delineate request and response
events on a given physical connection. The difference between them represents the response time of a single
request.
In this first release of this feature, our algorithm is an approximation that may work with varying degree of success
depending on the actual application protocol used for a given network connection. For example, the current
approach works well for request-response based protocols such as HTTP (S ), but does not work with one-way or
message queue-based protocols.
Here are some important points to consider:
1. If a process accepts connections on the same IP address but over multiple network interfaces, a separate record
for each interface will be reported.
2. Records with wildcard IP will contain no activity. They are included to represent the fact that a port on the
machine is open to inbound traffic.
3. To reduce verbosity and data volume, records with wildcard IP will be omitted when there is a matching record
(for the same process, port, and protocol) with a specific IP address. When a wildcard IP record is omitted, the
IsWildcardBind record property with the specific IP address, will be set to "True" to indicate that the port is
exposed over every interface of the reporting machine.
4. Ports that are bound only on a specific interface have IsWildcardBind set to False.
Naming and Classification
For convenience, the IP address of the remote end of a connection is included in the RemoteIp property. For
inbound connections, RemoteIp is the same as SourceIp, while for outbound connections, it is the same as
DestinationIp. The RemoteDnsCanonicalNames property represents the DNS canonical names reported by the
machine for RemoteIp. The RemoteDnsQuestions and RemoteClassification properties are reserved for future use.
Geolocation
VMConnection also includes geolocation information for the remote end of each connection record in the
following properties of the record:
RemoteCountry The name of the country/region hosting RemoteIp. For

example, United States
RemoteLatitude The geolocation latitude. For example, 47.68
RemoteLongitude The geolocation longitude. For example, -122.12
Malicious IP
Every RemoteIp property in VMConnection table is checked against a set of IPs with known malicious activity. If
the RemoteIp is identified as malicious the following properties will be populated (they are empty, when the IP is
not considered malicious) in the following properties of the record:
MaliciousIp The RemoteIp address
IndicatorThreadType Threat indicator detected is one of the following values,

Botnet, C2, CryptoMining, Darknet, DDos, MaliciousUrl,
Malware, Phishing, Proxy, PUA, Watchlist.
Description Description of the observed threat.
TLPLevel Traffic Light Protocol (TLP) Level is one of the defined values,
White, Green, Amber, Red.
Confidence Values are 0 – 100.
Severity Values are 0 – 5, where 5 is the most severe and 0 is not

severe at all. Default value is 3.
FirstReportedDateTime The first time the provider reported the indicator.
LastReportedDateTime The last time the indicator was seen by Interflow.
IsActive Indicates indicators are deactivated with True or False value.
ReportReferenceLink Links to reports related to a given observable.
AdditionalInformation Provides additional information, if applicable, about the

observed threat.
Ports
Ports on a machine that actively accept incoming traffic or could potentially accept traffic, but are idle during the
reporting time window, are written to the VMBoundPort table.
Every record in VMBoundPort is identified by the following fields:
Process Identity of process (or groups of processes) with which the

port is associated with.
Ip Port IP address (can be wildcard IP, 0.0.0.0)
Port The Port number
Protocol The protocol. Example, tcp or udp (only tcp is currently

supported).
The identity a port is derived from the above five fields and is stored in the PortId property. This property can be
used to quickly find records for a specific port across time.
Metrics
Port records include metrics representing the connections associated with them. Currently, the following metrics
are reported (the details for each metric are described in the previous section):
BytesSent and BytesReceived
LinksEstablished, LinksTerminated, LinksLive
ResposeTime, ResponseTimeMin, ResponseTimeMax, ResponseTimeSum
If a process accepts connections on the same IP address but over multiple network interfaces, a separate record
for each interface will be reported.
Records with wildcard IP will contain no activity. They are included to represent the fact that a port on the
To reduce verbosity and data volume, records with wildcard IP will be omitted when there is a matching record
IsWildcardBind property for the record with the specific IP address, will be set to True. This indicates the port is
Ports that are bound only on a specific interface have IsWildcardBind set to False.
ServiceMapComputer_CL records
Records with a type of ServiceMapComputer_CL have inventory data for servers with the Dependency agent.
These records have the properties in the following table:
Type ServiceMapComputer_CL
SourceSystem OpsManager
ResourceId The unique identifier for a machine within the workspace
ResourceName_s The unique identifier for a machine within the workspace
ComputerName_s The computer FQDN
Ipv4Addresses_s A list of the server's IPv4 addresses
DnsNames_s An array of DNS names

OperatingSystemFamily_s Windows or Linux
OperatingSystemFullName_s The full name of the operating system
Bitness_s The bitness of the machine (32-bit or 64-bit)
PhysicalMemory_d The physical memory in MB
Cpus_d The number of CPUs
CpuSpeed_d The CPU speed in MHz
VirtualizationState_s unknown, physical, virtual, hypervisor
VirtualMachineType_s hyperv, vmware, and so on
VirtualMachineNativeMachineId_g The VM ID as assigned by its hypervisor
VirtualMachineName_s The name of the VM
BootTime_t The boot time
ServiceMapProcess_CL Type records

Records with a type of ServiceMapProcess_CL have inventory data for TCP -connected processes on servers with
the Dependency agent. These records have the properties in the following table:
Type ServiceMapProcess_CL
ResourceId The unique identifier for a process within the workspace
ResourceName_s The unique identifier for a process within the machine on

which it is running
MachineResourceName_s The resource name of the machine
ExecutableName_s The name of the process executable
StartTime_t The process pool start time
FirstPid_d The first PID in the process pool
Description_s The process description
CompanyName_s The name of the company
InternalName_s The internal name

ProductName_s The name of the product
ProductVersion_s The product version
FileVersion_s The file version
CommandLine_s The command line
ExecutablePath_s The path to the executable file
WorkingDirectory_s The working directory
UserName The account under which the process is executing
UserDomain The domain under which the process is executing
Sample log searches

List all known machines
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId`
When was the VM last rebooted
let Today = now(); ServiceMapComputer_CL | extend DaysSinceBoot = Today - BootTime_t | summarize by Computer,
DaysSinceBoot, BootTime_t | sort by BootTime_t asc`
Summary of Azure VMs by image, location, and SKU
ServiceMapComputer_CL | where AzureLocation_s != "" | summarize by ComputerName_s, AzureImageOffering_s,

AzureLocation_s, AzureImageSku_s`
List the physical memory capacity of all managed computers.
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project PhysicalMemory_d,

ComputerName_s`
List computer name, DNS, IP, and OS.
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project ComputerName_s,

OperatingSystemFullName_s, DnsNames_s, Ipv4Addresses_s`
Find all processes with "sql" in the command line
ServiceMapProcess_CL | where CommandLine_s contains_cs "sql" | summarize arg_max(TimeGenerated, *) by

ResourceId`
Find a machine (most recent record) by resource name

search in (ServiceMapComputer_CL) "m-4b9c93f9-bc37-46df-b43c-899ba829e07b" | summarize arg_max(TimeGenerated,
*) by ResourceId`
Find a machine (most recent record) by IP address
search in (ServiceMapComputer_CL) "10.229.243.232" | summarize arg_max(TimeGenerated, *) by ResourceId`
List all known processes on a specified machine
ServiceMapProcess_CL | where MachineResourceName_s == "m-559dbcd8-3130-454d-8d1d-f624e57961bc" | summarize

arg_max(TimeGenerated, *) by ResourceId`
List all computers running SQL Server
ServiceMapComputer_CL | where ResourceName_s in ((search in (ServiceMapProcess_CL) "\*sql\*" | distinct

MachineResourceName_s)) | distinct ComputerName_s`
List all unique product versions of curl in my datacenter
ServiceMapProcess_CL | where ExecutableName_s == "curl" | distinct ProductVersion_s`
Create a computer group of all computers running CentOS
ServiceMapComputer_CL | where OperatingSystemFullName_s contains_cs "CentOS" | distinct ComputerName_s`
Bytes sent and received trends
VMConnection | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer | order by

Computer desc | render timechart`
Which Azure VMs are transmitting the most bytes
VMConnection | join kind=fullouter(ServiceMapComputer_CL) on $left.Computer == $right.ComputerName_s |

summarize count(BytesSent) by Computer, AzureVMSize_s | sort by count_BytesSent desc`
Link status trends
VMConnection | where TimeGenerated >= ago(24hr) | where Computer == "acme-demo" | summarize

dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by
bin(TimeGenerated, 1h) | render timechart`
Connection failures trend
VMConnection | where Computer == "acme-demo" | extend bythehour = datetime_part("hour", TimeGenerated) |

project bythehour, LinksFailed | summarize failCount = count() by bythehour | sort by bythehour asc | render
timechart`
Bound Ports
VMBoundPort
| where TimeGenerated >= ago(24hr)
| where Computer == 'admdemo-appsvr'
| distinct Port, ProcessName
Number of open ports across machines
VMBoundPort
| where Ip != "127.0.0.1"
| summarize by Computer, Machine, Port, Protocol
| summarize OpenPorts=count() by Computer, Machine
| order by OpenPorts desc
Score processes in your workspace by the number of ports they have open
VMBoundPort
| where Ip != "127.0.0.1"
| summarize by ProcessName, Port, Protocol
| summarize OpenPorts=count() by ProcessName
| order by OpenPorts desc
Aggregate behavior for each port

This query can then be used to score ports by activity, e.g., ports with most inbound/outbound traffic, ports with
most connections
//
VMBoundPort
| where Ip != "127.0.0.1"
| summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived),
LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated,
LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind
| project-away TimeGenerated
| order by Machine, Computer, Port, Ip, ProcessName
Summarize the outbound connections from a group of machines

// the machines of interest
let machines = datatable(m: string) ["m-82412a7a-6a32-45a9-a8d6-538354224a25"];
// map of ip to monitored machine in the environment
let ips=materialize(ServiceMapComputer_CL
| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s
| mvexpand ips to typeof(string));
// all connections to/from the machines of interest
let out=materialize(VMConnection
| where Machine in (machines)
| summarize arg_max(TimeGenerated, *) by ConnectionId);
// connections to localhost augmented with RemoteMachine
let local=out
| where RemoteIp startswith "127."
| project ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort,
Protocol, RemoteIp, RemoteMachine=Machine;
// connections not to localhost augmented with RemoteMachine
let remote=materialize(out
| where RemoteIp !startswith "127."
| join kind=leftouter (ips) on $left.RemoteIp == $right.ips
| summarize by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp,
DestinationPort, Protocol, RemoteIp, RemoteMachine=MonitoredMachine);
// the remote machines to/from which we have connections
let remoteMachines = remote | summarize by RemoteMachine;
// all augmented connections
(local)
| union (remote)
//Take all outbound records but only inbound records that come from either //unmonitored machines or monitored
machines not in the set for which we are computing dependencies.
| where Direction == 'outbound' or (Direction == 'inbound' and RemoteMachine !in (machines))
DestinationPort, Protocol, RemoteIp, RemoteMachine
// identify the remote port
| extend RemotePort=iff(Direction == 'outbound', DestinationPort, 0)
// construct the join key we'll use to find a matching port
| extend JoinKey=strcat_delim(':', RemoteMachine, RemoteIp, RemotePort, Protocol)
// find a matching port
| join kind=leftouter (VMBoundPort
| where Machine in (remoteMachines)
| summarize arg_max(TimeGenerated, *) by PortId
| extend JoinKey=strcat_delim(':', Machine, Ip, Port, Protocol)) on JoinKey
// aggregate the remote information
| summarize Remote=makeset(iff(isempty(RemoteMachine), todynamic('{}'), pack('Machine', RemoteMachine,
'Process', Process1, 'ProcessName', ProcessName1))) by ConnectionId, Direction, Machine, Process, ProcessName,
SourceIp, DestinationIp, DestinationPort, Protocol
Next steps
If you are new to writing log queries in Azure Monitor, review how to use Log Analytics in the Azure portal to
write log queries.
Learn about writing search queries.
Disable monitoring of your VMs in Azure Monitor for
VMs (preview)
After you enable monitoring of your virtual machines (VMs), you can later choose to disable monitoring in Azure
Monitor for VMs. This article shows how to disable monitoring for one or more VMs.
Currently, Azure Monitor for VMs doesn't support selective disabling of VM monitoring. Your Log Analytics
workspace might support Azure Monitor for VMs and other solutions. It might also collect other monitoring data.
If your Log Analytics workspace provides these services, you need to understand the effect and methods of
disabling monitoring before you start.
Azure Monitor for VMs relies on the following components to deliver its experience:
A Log Analytics workspace, which stores monitoring data from VMs and other sources.
A collection of performance counters configured in the workspace. The collection updates the monitoring
configuration on all VMs connected to the workspace.
InfrastructureInsights and ServiceMap , which are monitoring solutions configured in the workspace. These
solutions update the monitoring configuration on all VMs connected to the workspace.
MicrosoftMonitoringAgent and DependencyAgent , which are Azure VM extensions. These extensions collect and
send data to the workspace.
As you prepare to disable monitoring of your VMs, keep these considerations in mind:
If you evaluated with a single VM and used the preselected default Log Analytics workspace, you can disable
monitoring by uninstalling the Dependency agent from the VM and disconnecting the Log Analytics agent from
this workspace. This approach is appropriate if you intend to use the VM for other purposes and decide later to
reconnect it to a different workspace.
If you selected a preexisting Log Analytics workspace that supports other monitoring solutions and data
collection from other sources, you can remove solution components from the workspace without interrupting or
affecting your workspace.
NOTE
After removing the solution components from your workspace, you might continue to see health state from your Azure VMs;
specifically, you'll see performance and map data when you go to either view in the portal. Data will eventually stop appearing
in the Performance and Map views. But the Health view will continue to show health status for your VMs. The Try now
option will be available from the selected Azure VM so you can re-enable monitoring in the future.
Remove Azure Monitor for VMs completely

If you still need the Log Analytics workspace, follow these steps to completely remove Azure Monitor for VMs.
You'll remove the InfrastructureInsights and ServiceMap solutions from the workspace.
NOTE
If you used the Service Map monitoring solution before you enabled Azure Monitor for VMs and you still rely on it, don't
remove that solution as described in the last step of the following procedure.
2. In the Azure portal, select All services. In the list of resources, type Log Analytics. As you begin typing, the list
filters suggestions based on your input. Select Log Analytics.
3. In your list of Log Analytics workspaces, select the workspace you chose when you enabled Azure Monitor for
VMs.
4. On the left, select Solutions.
5. In the list of solutions, select InfrastructureInsights(workspace name). On the Overview page for the
solution, select Delete. When prompted to confirm, select Yes.
6. In the list of solutions, select ServiceMap(workspace name). On the Overview page for the solution, select
Delete. When prompted to confirm, select Yes.
Before you enabled Azure Monitor for VMs, if you didn't collect performance counters for the Windows-based or
Linux-based VMs in your workspace, disable those rules for Windows and for Linux.
Disable monitoring and keep the workspace

If your Log Analytics workspace still needs to support monitoring from other sources, following these steps to
disable monitoring on the VM that you used to evaluate Azure Monitor for VMs. For Azure VMs, you'll remove the
dependency agent VM extension and the Log Analytics agent VM extension for Windows or Linux directly from
the VM.
NOTE
Don't remove the Log Analytics agent if:
Azure Automation manages the VM to orchestrate processes or to manage configuration or updates.
Azure Security Center manages the VM for security and threat detection.
If you do remove the Log Analytics agent, you will prevent those services and solutions from proactively managing your VM.

4. On the left, select Extensions. On the Extensions page, select DependencyAgent.
5. On the extension properties page, select Uninstall.
6. On the Extensions page, select MicrosoftMonitoringAgent. On the extension properties page, select
Uninstall.
Plan Hyper-V virtual machine capacity with the
Capacity and Performance solution (deprecated)
NOTE
The Capacity and Performance solution has been deprecated. Customers who have already installed the solution can
continue to use it, but Capacity and Performance can not be added to any new workspaces.
You can use the Capacity and Performance solution in Monitor to help you understand the capacity of your Hyper-
V servers. The solution provides insights into your Hyper-V environment by showing you the overall utilization
(CPU, memory, and disk) of the hosts and the VMs running on those Hyper-V hosts. Metrics are collected for CPU,
memory, and disks across all your hosts and the VMs running on them.
The solution:
Shows hosts with highest and lowest CPU and memory utilization
Shows VMs with highest and lowest CPU and memory utilization
Shows VMs with highest and lowest IOPS and throughput utilization
Shows which VMs are running on which hosts
Shows the top disks with high throughput, IOPS, and latency in cluster shared volumes
Allows you to customize and filter based on groups
NOTE
The previous version of the Capacity and Performance solution called Capacity Management required both System Center
Operations Manager and System Center Virtual Machine Manager. This updated solution doesn't have those dependencies.
Connected sources
CONNECTED SOURCE SUPPORT DESCRIPTION
Windows agents Yes The solution collects capacity and

performance data information from
Windows agents.
Linux agents No The solution does not collect capacity

and performance data information from
direct Linux agents.
SCOM management group Yes The solution collects capacity and

performance data from agents in a
connected SCOM management group.
A direct connection from the SCOM
agent to Log Analytics is not required.
Azure storage account No Azure storage does not include capacity

and performance data.
Prerequisites
Windows or Operations Manager agents must be installed on Windows Server 2012 or higher Hyper-V hosts,
not virtual machines.
Configuration
Perform the following step to add the Capacity and Performance solution to your workspace.
Add the Capacity and Performance solution to your Log Analytics workspace using the process described in
Add Log Analytics solutions from the Solutions Gallery.
Management packs
If your SCOM management group is connected to your Log Analytics workspace, then the following management
packs will be installed in SCOM when you add this solution. There is no configuration or maintenance of these
management packs required.
Microsoft.IntelligencePacks.CapacityPerformance
The 1201 event resembles:
New Management Pack with id:"Microsoft.IntelligencePacks.CapacityPerformance", version:"1.10.3190.0" received.
When the Capacity and Performance solution is updated, the version number will change.
Analytics.
Using the solution

When you add the Capacity and Performance solution to your workspace, the Capacity and Performance is added
to the Overview dashboard. This tile displays a count of the number of currently active Hyper-V hosts and the
number of active virtual machines that were monitored for the time period selected.
Review utilization
Click on the Capacity and Performance tile to open the Capacity and Performance dashboard. The dashboard
includes the columns in the following table. Each column lists up to ten items matching that column's criteria for
the specified scope and time range. You can run a log search that returns all records by clicking See all at the
bottom of the column or by clicking the column header.
Hosts
Host CPU Utilization Shows a graphical trend of the CPU utilization of host computers and a list of
hosts, based on the selected time period. Hover over the line chart to view details for a specific point in
time. Click the chart to view more details in log search. Click any host name to open log search and view
CPU counter details for hosted VMs.
Host Memory Utilization Shows a graphical trend of the memory utilization of host computers and a
list of hosts, based on the selected time period. Hover over the line chart to view details for a specific
point in time. Click the chart to view more details in log search. Click any host name to open log search
and view memory counter details for hosted VMs.
Virtual Machines
VM CPU Utilization Shows a graphical trend of the CPU utilization of virtual machines and a list of
virtual machines, based on the selected time period. Hover over the line chart to view details for a
specific point in time for the top 3 VMs. Click the chart to view more details in log search. Click any VM
name to open log search and view aggregated CPU counter details for the VM.
VM Memory Utilization Shows a graphical trend of the memory utilization of virtual machines and a
list of virtual machines, based on the selected time period. Hover over the line chart to view details for a
specific point in time for the top 3 VMs. Click the chart to view more details in log search. Click any VM
name to open log search and view aggregated memory counter details for the VM.
VM Total Disk IOPS Shows a graphical trend of the total disk IOPS for virtual machines and a list of
virtual machines with the IOPS for each, based on the selected time period. Hover over the line chart to
view details for a specific point in time for the top 3 VMs. Click the chart to view more details in log
search. Click any VM name to open log search and view aggregated disk IOPS counter details for the
VM.
VM Total Disk Throughput Shows a graphical trend of the total disk throughput for virtual machines
and a list of virtual machines with the total disk throughput for each, based on the selected time period.
Hover over the line chart to view details for a specific point in time for the top 3 VMs. Click the chart to
view more details in log search. Click any VM name to open log search and view aggregated total disk
throughput counter details for the VM.
Clustered Shared Volumes
Total Throughput Shows the sum of both reads and writes on clustered shared volumes.
Total IOPS Shows the sum of input/output operations per second on clustered shared volumes.
Total Latency Shows the total latency on clustered shared volumes.
Host Density The top tile shows the total number of hosts and virtual machines available to the solution. Click
the top tile to view additional details in log search. Also lists all hosts and the number of virtual machines that
are hosted. Click a host to drill into the VM results in a log search.
Evaluate performance
Production computing environments differ greatly from one organization to another. Also, capacity and
performance workloads might depend on how your VMs are running, and what you consider normal. Specific
procedures to help you measure performance would probably not apply to your environment. So, more
generalized prescriptive guidance is better suited to help. Microsoft publishes a variety of prescriptive guidance
articles to help you measure performance.
To summarize, the solution collects capacity and performance data from a variety of sources including performance
counters. Use that capacity and performance data that presented in various surfaces in the solution and compare
your results to those at the Measuring Performance on Hyper-V article. Although the article was published some
time ago, the metrics, considerations, and guidelines are still valid. The article contains links to other useful
resources.
Sample log searches

The following table provides sample log searches for capacity and performance data collected and calculated by
this solution.
QUERY DESCRIPTION
All host memory configurations Perf | where ObjectName == "Capacity and Performance" and
CounterName == "Host Assigned Memory MB" | summarize
MB = avg(CounterValue) by InstanceName
All VM memory configurations Perf | where ObjectName == "Capacity and Performance" and
CounterName == "VM Assigned Memory MB" | summarize
MB = avg(CounterValue) by InstanceName
Breakdown of Total Disk IOPS across all VMs Perf | where ObjectName == "Capacity and Performance" and
(CounterName == "VHD Reads/s" or CounterName == "VHD
Writes/s") | summarize AggregatedValue = avg(CounterValue)
by bin(TimeGenerated, 1h), CounterName, InstanceName
Breakdown of Total Disk Throughput across all VMs Perf | where ObjectName == "Capacity and Performance" and
(CounterName == "VHD Read MB/s" or CounterName ==
"VHD Write MB/s") | summarize AggregatedValue =
avg(CounterValue) by bin(TimeGenerated, 1h), CounterName,
InstanceName
Breakdown of Total IOPS across all CSVs Perf | where ObjectName == "Capacity and Performance" and
(CounterName == "CSV Reads/s" or CounterName == "CSV
Breakdown of Total Throughput across all CSVs Perf | where ObjectName == "Capacity and Performance" and
(CounterName == "CSV Reads/s" or CounterName == "CSV
Breakdown of Total Latency across all CSVs Perf | where ObjectName == "Capacity and Performance" and
(CounterName == "CSV Read Latency" or CounterName ==
"CSV Write Latency") | summarize AggregatedValue =
avg(CounterValue) by bin(TimeGenerated, 1h), CounterName,
InstanceName
Next steps
Use Log searches in Log Analytics to view detailed Capacity and Performance data.
VMware Monitoring (Deprecated) solution in Azure
Monitor
NOTE
The VMware Monitoring solution has been deprecated. Customers who have already installed the solution can continue to
use it, but VMware Monitoring can not be added to any new workspaces.
The VMware Monitoring solution in Azure Monitor is a solution that helps you create a centralized logging and
monitoring approach for large VMware logs. This article describes how you can troubleshoot, capture, and
manage the ESXi hosts in a single location using the solution. With the solution, you can see detailed data for all
your ESXi hosts in a single location. You can see top event counts, status, and trends of VM and ESXi hosts
provided through the ESXi host logs. You can troubleshoot by viewing and searching centralized ESXi host logs.
And, you can create alerts based on log search queries.
The solution uses native syslog functionality of the ESXi host to push data to a target VM, which has the Log
Analytics agent. However, the solution doesn't write files into syslog within the target VM. The Log Analytics agent
opens port 1514 and listens to this. Once it receives the data, the Log Analytics agent pushes the data into Azure
Monitor.
Install and configure the solution

Add the VMware Monitoring solution to your subscription using the process described in Install a monitoring
solution.
Supported VMware ESXi hosts
vSphere ESXi Host 5.5, 6.0, and 6.5
Prepare a Linux server
Create a Linux operating system VM to receive all syslog data from the ESXi hosts. The Log Analytics Linux agent
is the collection point for all ESXi host syslog data. You can use multiple ESXi hosts to forward logs to a single
Linux server, as in the following example.
NOTE
agent for Linux.
Configure syslog collection
1. Set up syslog forwarding for VSphere. For detailed information to help set up syslog forwarding, see
Configuring syslog on ESXi 5.0 and higher (2003322). Go to ESXi Host Configuration > Software >
Advanced Settings > Syslog.
2. In the Syslog.global.logHost field, add your Linux server and the port number 1514. For example,
tcp://hostname:1514 or tcp://123.456.789.101:1514
3. Open the ESXi host firewall for syslog. ESXi Host Configuration > Software > Security Profile >
Firewall and open Properties.
4. Check the vSphere Console to verify that syslog is properly set up. Confirm on the ESXI host that port 1514
is configured.
5. Download and install the Log Analytics agent for Linux on the Linux server. For more information, see the
Documentation for Log Analytics agent for Linux.
6. After the Log Analytics agent for Linux is installed, go to the
/etc/opt/microsoft/omsagent/sysconf/omsagent.d directory and copy the vmware_esxi.conf file to the
/etc/opt/microsoft/omsagent/conf/omsagent.d directory and the change the owner/group and permissions
of the file. For example:
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/vmware_esxi.conf
/etc/opt/microsoft/omsagent/conf/omsagent.d
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/conf/omsagent.d/vmware_esxi.conf
7. Restart the Log Analytics agent for Linux by running

sudo /opt/microsoft/omsagent/bin/service_control restart .
8. Test the connectivity between the Linux server and the ESXi host by using the nc command on the ESXi
Host. For example:
[root@ESXiHost:~] nc -z 123.456.789.101 1514
Connection to 123.456.789.101 1514 port [tcp/*] succeeded!
9. In the Azure portal, perform a log query for VMware_CL . When Azure Monitor collects the syslog data, it
retains the syslog format. In the portal, some specific fields are captured, such as Hostname and
ProcessName.
If your view log search results are similar to the image above, you're set to use the VMware Monitoring
solution dashboard.
VMware data collection details

The VMware Monitoring solution collects various performance metrics and log data from ESXi hosts using the
Log Analytics agents for Linux that you have enabled.
The following table shows data collection methods and other details about how data is collected.
LOG SCOM AGENT

ANALYTICS DATA SENT VIA
AGENT FOR AZURE SCOM MANAGEMENT COLLECTION
PLATFORM LINUX SCOM AGENT STORAGE REQUIRED? GROUP FREQUENCY
Linux • every 3
minutes
The following table show examples of data fields collected by the VMware Monitoring solution:
FIELD NAME DESCRIPTION
Device_s VMware storage devices
ESXIFailure_s failure types
EventTime_t time when event occurred
HostName_s ESXi host name

FIELD NAME DESCRIPTION
Operation_s create VM or delete VM
ProcessName_s event name
ResourceId_s name of the VMware host
ResourceLocation_s VMware
ResourceName_s VMware
ResourceType_s Hyper-V
SCSIStatus_s VMware SCSI status
SyslogMessage_s Syslog data
UserName_s user who created or deleted VM
VMName_s VM name
Computer host computer
TimeGenerated time the data was generated
DataCenter_s VMware datacenter
StorageLatency_s storage latency (ms)
VMware Monitoring solution overview

The VMware tile appears in your Log Analytics workspace. It provides a high-level view of any failures. When you
click the tile, you go into a dashboard view.
Navigate the dashboard view

In the VMware dashboard view, blades are organized by:
Failure Status Count
Top Host by Event Counts
Top Event Counts
Virtual Machine Activities
ESXi Host Disk Events
Click any blade to open Log Analytics search pane that shows detailed information specific for the blade.
From here, you can edit the log query to modify it for something specific. For details on creating log queries, see
Find data using log queries in Azure Monitor.
Find ESXi host events
A single ESXi host generates multiple logs, based on their processes. The VMware Monitoring solution centralizes
them and summarizes the event counts. This centralized view helps you understand which ESXi host has a high
volume of events and what events occur most frequently in your environment.
You can drill further by clicking an ESXi host or an event type.
When you click an ESXi host name, you view information from that ESXi host. If you want to narrow results with
the event type, add “ProcessName_s=EVENT TYPE” in your search query. You can select ProcessName in the search
filter. That narrows the information for you.
Find high VM activities

A virtual machine can be created and deleted on any ESXi host. It's helpful for an administrator to identify how
many VMs an ESXi host creates. That in-turn, helps to understand performance and capacity planning. Keeping
track of VM activity events is crucial when managing your environment.
If you want to see additional ESXi host VM creation data, click an ESXi host name.
Common log queries

The solution includes other useful queries that can help you manage your ESXi hosts, such as high storage space,
storage latency, and path failure.
Save queries
Saving log queries is a standard feature in Azure Monitor and can help you keep any queries that you’ve found
useful. After you create a query that you find useful, save it by clicking the Favorites. A saved query lets you easily
reuse it later from the My Dashboard page where you can create your own custom dashboards.
Create alerts from queries

After you’ve created your queries, you might want to use the queries to alert you when specific events occur. See
Alerts in Log Analytics for information about how to create alerts. For examples of alerting queries and other
query examples, see the Monitor VMware using Log Analytics blog post.

What do I need to do on the ESXi host setting? What impact will it have on my current environment?
The solution uses the native ESXi Host Syslog forwarding mechanism. You don't need any additional Microsoft
software on the ESXi Host to capture the logs. It should have a low impact to your existing environment. However,
you do need to set syslog forwarding, which is ESXI functionality.
Do I need to restart my ESXi host?
No. This process does not require a restart. Sometimes, vSphere does not properly update the syslog. In such a
case, log on to the ESXi host and reload the syslog. Again, you don't have to restart the host, so this process isn't
disruptive to your environment.
Can I increase or decrease the volume of log data sent to Log Analytics?
Yes you can. You can use the ESXi Host Log Level settings in vSphere. Log collection is based on the info level. So,
if you want to audit VM creation or deletion, you need to keep the info level on Hostd. For more information, see
the VMware Knowledge Base.
Why is Hostd not providing data to Log Analytics? My log setting is set to info.
There was an ESXi host bug for the syslog timestamp. For more information, see the VMware Knowledge Base.
After you apply the workaround, Hostd should function normally.
Can I have multiple ESXi hosts forwarding syslog data to a single VM with omsagent?
Yes. You can have multiple ESXi hosts forwarding to a single VM with omsagent.
Why don't I see data flowing into Log Analytics?
There can be multiple reasons:
The ESXi host is not correctly pushing data to the VM running omsagent. To test, perform the following
steps:
1. To confirm, log on to the ESXi host using ssh and run the following command:
nc -z ipaddressofVM 1514
If this is not successful, vSphere settings in the Advanced Configuration are likely not correct. See
Configure syslog collection for information about how to set up the ESXi host for syslog forwarding.
2. If syslog port connectivity is successful, but you don't still see any data, then reload the syslog on the
ESXi host by using ssh to run the following command: esxcli system syslog reload
The VM with Log Analytics agent is not set correctly. To test this, perform the following steps:
1. Log Analytics listens to the port 1514. To verify that it is open, run the following command:
netstat -a | grep 1514
2. You should see port 1514/tcp open. If you do not, verify that the omsagent is installed correctly. If you
do not see the port information, then the syslog port is not open on the VM.
a. Verify that the Log Analytics agent is running by using ps -ef | grep oms . If it is not running, start the
process by running the command sudo /opt/microsoft/omsagent/bin/service_control start
b. Open the /etc/opt/microsoft/omsagent/conf/omsagent.d/vmware_esxi.conf file.
c. Verify that the proper user and group setting is valid, similar to:
-rw-r--r-- 1 omsagent omiusers 677 Sep 20 16:46 vmware_esxi.conf
d. If the file does not exist or the user and group setting is wrong, take corrective action by Preparing a Linux
server.
Next steps
Use log queries in Log Analytics to view detailed VMware host data.
Create your own dashboards showing VMware host data.
Create alerts when specific VMware host events occur.
Wire Data 2.0 (Preview) solution in Azure Monitor
Wire data is consolidated network and performance data collected from Windows-connected and Linux-connected
computers with the Log Analytics agent, including those monitored by Operations Manager in your environment.
Network data is combined with your other log data to help you correlate data.
NOTE
In addition to the Log Analytics agent, the Wire Data solution uses Microsoft Dependency Agents that you install
on computers in your IT infrastructure. Dependency Agents monitor network data sent to and from your
computers for network levels 2-3 in the OSI model, including the various protocols and ports used. Data is then
sent to Azure Monitor using agents.
NOTE
If you have already deployed Service Map, or are considering Service Map or Azure Monitor for VMs, there is a new
connection metrics data set they collect and store in Azure Monitor that provides comparable information to Wire Data.
By default, Azure Monitor logs data for CPU, memory, disk, and network performance data from counters built
into Windows and Linux, as well as other performance counters that you can specify. Network and other data
collection is done in real-time for each agent, including subnets and application-level protocols being used by the
computer. Wire Data looks at network data at the application level, not down at the TCP transport layer. The
solution doesn't look at individual ACKs and SYNs. Once the handshake is completed, it is considered a live
connection and marked as Connected. That connection stays live as long as both sides agree the socket is open and
data can pass back and forth. Once either side closes the connection, it is marked as Disconnected. Therefore, it
only counts the bandwidth of successfully completed packets, it doesn't report on resends or failed packets.
If you've used sFlow or other software with Cisco's NetFlow protocol, then the statistics and data you see from
wire data will be familiar to you.
Some of the types of built-in Log search queries include:
Agents that provide wire data
IP address of agents providing wire data
Outbound communications by IP addresses
Number of bytes sent by application protocols
Number of bytes sent by an application service
Bytes received by different protocols
Total bytes sent and received by IP version
Average latency for connections that were measured reliably
Computer processes that initiated or received network traffic
Amount of network traffic for a process
When you search using wire data, you can filter and group data to view information about the top agents and top
protocols. Or you can view when certain computers (IP addresses/MAC addresses) communicated with each other,
for how long, and how much data was sent—basically, you view metadata about network traffic, which is search-
based.
However, since you're viewing metadata, it's not necessarily useful for in-depth troubleshooting. Wire data in
Azure Monitor is not a full capture of network data. It is not intended for deep packet-level troubleshooting. The
advantage of using the agent, compared to other collection methods, is that you don't have to install appliances,
reconfigure your network switches, or perform complicated configurations. Wire data is simply agent-based—you
install the agent on a computer and it will monitor its own network traffic. Another advantage is when you want to
monitor workloads running in cloud providers or hosting service provider or Microsoft Azure, where the user
doesn't own the fabric layer.
Connected sources
Wire Data gets its data from the Microsoft Dependency Agent. The Dependency Agent depends on the Log
Analytics agent for its connections to Azure Monitor. This means that a server must have the Log Analytics agent
installed and configured with the Dependency agent. The following table describes the connected sources that the
Wire Data solution supports.
Windows agents Yes Wire Data analyzes and collects data

from Windows agent computers.
In addition to the Log Analytics agent

for Windows, Windows agents require
the Microsoft Dependency agent. See
the supported operating systems for a
complete list of operating system
versions.
Linux agents Yes Wire Data analyzes and collects data

from Linux agent computers.
In addition to the Log Analytics agent

for Linux, Linux agents require the
Microsoft Dependency agent. See the
supported operating systems for a
complete list of operating system
versions.
System Center Operations Manager Yes Wire Data analyzes and collects data
management group from Windows and Linux agents in a
connected System Center Operations
Manager management group.
A direct connection from the System

Center Operations Manager agent
computer to Azure Monitor is required.
Azure storage account No Wire Data collects data from agent

computers, so there is no data from it
to collect from Azure Storage.
On Windows, the Microsoft Monitoring Agent (MMA) is used by both System Center Operations Manager and
Azure Monitor to gather and send data. Depending on the context, the agent is called the System Center
Operations Manager Agent, Log Analytics agent, MMA, or Direct Agent. System Center Operations Manager and
Azure Monitor provide slightly different versions of the MMA. These versions can each report to System Center
Operations Manager, to Azure Monitor, or to both.
On Linux, the Log Analytics agent for Linux gathers and sends data to Azure Monitor. You can use Wire Data on
servers with agents directly connected to Azure Monitor, or on servers that are connecting to Azure Monitor via
System Center Operations Manager management groups.
The Dependency agent does not transmit any data itself, and it does not require any changes to firewalls or ports.
The data in Wire Data is always transmitted by the Log Analytics agent to Azure Monitor, either directly or through
the Log Analytics gateway.
If you are a System Center Operations Manager user with a management group connected to Azure Monitor:
No additional configuration is required when your System Center Operations Manager agents can access the
internet to connect to Azure Monitor.
You need to configure the Log Analytics gateway to work with System Center Operations Manager when your
System Center Operations Manager agents cannot access Azure Monitor over the internet.
If your Windows or Linux computers cannot directly connect to the service, you need to configure the Log
Analytics agent to connect to Azure Monitor using the Log Analytics gateway. You can download the Log Analytics
gateway from the Microsoft Download Center.
Prerequisites
Requires the Insight and Analytics solution offer.
If you're using the previous version of the Wire Data solution, you must first remove it. However, all data
captured through the original Wire Data solution is still available in Wire Data 2.0 and log search.
Administrator privileges are required to install or uninstall the Dependency agent.
The Dependency agent must be installed on a computer with a 64-bit operating system.
Operating systems
The following sections list the supported operating systems for the Dependency agent. Wire Data doesn't support
32-bit architectures for any operating system.
Windows Server
Windows Server 2019
Windows Server 2016 1803
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 SP1
Windows desktop
Windows 10 1803
Windows 10
Windows 8.1
Windows 8
Windows 7
Supported Linux operating systems
The following sections list the supported operating systems for the Dependency agent on Linux.
Only default and SMP Linux kernel releases are supported.
Nonstandard kernel releases, such as PAE and Xen, are not supported for any Linux distribution. For example, a
system with the release string of "2.6.16.21-0.8-xen" is not supported.
Custom kernels, including recompiles of standard kernels, are not supported.
Red Hat Li n u x 7
7.4 3.10.0-693
7.5 3.10.0-862
7.6 3.10.0-957
Red Hat Li n u x 6
6.9 2.6.32-696
6.10 2.6.32-754
C e n t O SP l u s
6.9 2.6.32-696.18.7
2.6.32-696.30.1
6.10 2.6.32-696.30.1
2.6.32-754.3.5
U b u n t u Se r v e r

Ubuntu 18.04 kernel 4.15.*

4.18*
Ubuntu 16.04.3 kernel 4.15.*
16.04 4.4.*
4.8.*
4.10.*
4.11.*
4.13.*
14.04 3.13.*
4.4.*
SU SE L i n u x 1 1 En t e r p r i se Se r v e r
11 SP4 3.0.*
SU SE L i n u x 1 2 En t e r p r i se Se r v e r
12 SP2 4.4.*
12 SP3 4.4.*
Dependency agent downloads

FILE OS VERSION SHA-256
InstallDependencyAgent- Windows 9.7.4 A111B92AB6CF28EB68B696

Windows.exe C60FE51F980BFDFF78C36A
900575E17083972989E0
InstallDependencyAgent- Linux 9.7.4 AB58F3DB8B1C3DEE75126

Linux64.bin 90E5A65F1DFC41B4383154
3B5C040FCCE8390F2282C
Configuration
Perform the following steps to configure the Wire Data solution for your workspaces.
1. Enable the Activity Log Analytics solution from the Azure marketplace or by using the process described in Add
monitoring solutions from the Solutions Gallery.
2. Install the Dependency agent on each computer where you want to get data. The Dependency agent can
monitor connections to immediate neighbors, so you might not need an agent on every computer.
NOTE
You cannot add the previous version of the Wire Data solution to new workspaces. If you have the original Wire Data
solution enabled, you can continue to use it. However, to use Wire Data 2.0, you must first remove the original version.
Install the Dependency agent on Windows
Administrator privileges are required to install or uninstall the agent.
The Dependency agent is installed on computers running Windows through InstallDependencyAgent-
Windows.exe. If you run this executable file without any options, it starts a wizard that you can follow to install
interactively.
Use the following steps to install the Dependency agent on each computer running Windows:
1. Install the Log Analytics agent following the steps in Collect data from Windows computers hosted in your
environment.
2. Download the Windows Dependency agent using the link in the previous section and then run it by using the
following command: InstallDependencyAgent-Windows.exe
3. Follow the wizard to install the agent.
4. If the Dependency agent fails to start, check the logs for detailed error information. For Windows agents, the
log directory is %Programfiles%\Microsoft Dependency Agent\logs.
Windows command line
Use options from the following table to install from a command line. To see a list of the installation flags, run the
installer by using the /? flag as follows.
InstallDependencyAgent-Windows.exe /?
FLAG DESCRIPTION
/? Get a list of the command-line options.
/S Perform a silent installation with no user prompts.
Files for the Windows Dependency agent are placed in C:\Program Files\Microsoft Dependency agent by default.
Install the Dependency agent on Linux
Root access is required to install or configure the agent.
The Dependency agent is installed on Linux computers through InstallDependencyAgent-Linux64.bin, a shell script
with a self-extracting binary. You can run the file by using sh or add execute permissions to the file itself.
Use the following steps to install the Dependency agent on each Linux computer:
1. Install the Log Analytics agent following the steps in Collect data from Linux computers hosted in your
environment.
2. Download the Linux Dependency agent using the link in the previous section and then install it as root by using
the following command: sh InstallDependencyAgent-Linux64.bin
3. If the Dependency agent fails to start, check the logs for detailed error information. On Linux agents, the log
directory is: /var/opt/microsoft/dependency-agent/log.
To see a list of the installation flags, run the installation program with the -help flag as follows.
InstallDependencyAgent-Linux64.bin -help
FLAG DESCRIPTION
-help Get a list of the command-line options.

FLAG DESCRIPTION
-s Perform a silent installation with no user prompts.
--check Check permissions and the operating system but do not

install the agent.
Files for the Dependency agent are placed in the following directories:
FILES LOCATION
Core files /opt/microsoft/dependency-agent
Log files /var/opt/microsoft/dependency-agent/log
Config files /etc/opt/microsoft/dependency-agent/config
Service executable files /opt/microsoft/dependency-agent/bin/microsoft-dependency-

agent
/opt/microsoft/dependency-agent/bin/microsoft-dependency-
agent-manager
Binary storage files /var/opt/microsoft/dependency-agent/storage
Installation script examples

To easily deploy the Dependency agent on many servers at once, it helps to use a script. You can use the following
script examples to download and install the Dependency agent on either Windows or Linux.
PowerShell script for Windows
Invoke-WebRequest "https://aka.ms/dependencyagentwindows" -OutFile InstallDependencyAgent-Windows.exe
.\InstallDependencyAgent-Windows.exe /S
Shell script for Linux
wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin
sh InstallDependencyAgent-Linux64.bin -s
Desired State Configuration

To deploy the Dependency agent via Desired State Configuration, you can use the xPSDesiredStateConfiguration
module and a bit of code like the following:
$DAPackageLocalPath = "C:\InstallDependencyAgent-Windows.exe"
Node $NodeName
# Download and install the Dependency agent
xRemoteFile DAPackage
Uri = "https://aka.ms/dependencyagentwindows"
DestinationPath = $DAPackageLocalPath
DependsOn = "[Package]OI"
xPackage DA
Ensure = "Present"
Name = "Dependency Agent"
Path = $DAPackageLocalPath
Arguments = '/S'
ProductId = ""
InstalledCheckRegKey =
"HKEY\_LOCAL\_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\DependencyAgent"
InstalledCheckRegValueName = "DisplayName"
InstalledCheckRegValueData = "Dependency Agent"
Uninstall the Dependency agent

Use the following sections to help you remove the Dependency agent.
Uninstall the Dependency agent on Windows
An administrator can uninstall the Dependency agent for Windows through Control Panel.
An administrator can also run %Programfiles%\Microsoft Dependency Agent\Uninstall.exe to uninstall the
Dependency agent.
Uninstall the Dependency agent on Linux
To completely uninstall the Dependency agent from Linux, you must remove the agent itself and the connector,
which is installed automatically with the agent. You can uninstall both by using the following single command:
rpm -e dependency-agent dependency-agent-connector
Management packs
When Wire Data is activated in a Log Analytics workspace, a 300-KB management pack is sent to all the Windows
servers in that workspace. If you are using System Center Operations Manager agents in a connected
management group, the Dependency Monitor management pack is deployed from System Center Operations
Manager. If the agents are directly connected, Azure Monitor delivers the management pack.
The management pack is named Microsoft.IntelligencePacks.ApplicationDependencyMonitor. It's written to:
%Programfiles%\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs. The data source
that the management pack uses is: %Program files%\Microsoft Monitoring Agent\Agent\Health Service
State\Resources<AutoGeneratedID>\Microsoft.EnterpriseManagement.Advisor.ApplicationDependencyMonitorD
ataSource.dll.
Using the solution

The Wire Data solution acquires data from computers running Windows Server 2012 R2, Windows 8.1, and
later operating systems.
Microsoft .NET Framework 4.0 or later is required on computers where you want to acquire wire data from.
Add the Wire Data solution to your Log Analytics workspace using the process described in Add monitoring
solutions from the Solutions Gallery. There is no further configuration required.
If you want to view wire data for a specific solution, you need to have the solution already added to your
workspace.
After you have agents installed and you install the solution, the Wire Data 2.0 tile appears in your workspace.
Using the Wire Data 2.0 solution

In the Overview page for your Log Analytics workspace in the Azure portal, click the Wire Data 2.0 tile to open
the Wire Data dashboard. The dashboard includes the blades in the following table. Each blade lists up to 10 items
matching that blade's criteria for the specified scope and time range. You can run a log search that returns all
records by clicking See all at the bottom of the blade or by clicking the blade header.
BLADE DESCRIPTION
BLADE DESCRIPTION
Agents capturing network traffic Shows the number of agents that are capturing network traffic
and lists the top 10 computers that are capturing traffic. Click
the number to run a log search for
WireData | summarize sum(TotalBytes) by Computer |
take 500000
. Click a computer in the list to run a log search returning the
total number of bytes captured.
Local Subnets Shows the number of local subnets that agents have
discovered. Click the number to run a log search for
WireData | summarize sum(TotalBytes) by LocalSubnet
that lists all subnets with the number of bytes sent over each
one. Click a subnet in the list to run a log search returning the
total number of bytes sent over the subnet.
Application-level Protocols Shows the number of application-level protocols in use, as

discovered by agents. Click the number to run a log search for
WireData | summarize sum(TotalBytes) by
ApplicationProtocol
. Click a protocol to run a log search returning the total
number of bytes sent using the protocol.
You can use the Agents capturing network traffic blade to determine how much network bandwidth is being
consumed by computers. This blade can help you easily find the chattiest computer in your environment. Such
computers could be overloaded, acting abnormally, or using more network resources than normal.
Similarly, you can use the Local Subnets blade to determine how much network traffic is moving through your
subnets. Users often define subnets around critical areas for their applications. This blade offers a view into those
areas.
The Application-level Protocols blade is useful because it's helpful know what protocols are in use. For example,
you might expect SSH to not be in use in your network environment. Viewing information available in the blade
can quickly confirm or disprove your expectation.
It's also useful to know if protocol traffic is increasing or decreasing over time. For example, if the amount of data
being transmitted by an application is increasing, that might be something you should be aware of, or that you
might find noteworthy.
Input data
Wire data collects metadata about network traffic using the agents that you have enabled. Each agent sends data
about every 15 seconds.
Output data
A record with a type of WireData is created for each type of input data. WireData records have properties shown
in the following table:
Computer Computer name where data was collected
TimeGenerated Time of the record
LocalIP IP address of the local computer
SessionState Connected or disconnected
ReceivedBytes Amount of bytes received
ProtocolName Name of the network protocol used
IPVersion IP version
Direction Inbound or outbound
MaliciousIP IP address of a known malicious source
Severity Suspected malware severity
RemoteIPCountry Country/region of the remote IP address
ManagementGroupName Name of the Operations Manager management group
SourceSystem Source where data was collected
SessionStartTime Start time of session
SessionEndTime End time of session
LocalSubnet Subnet where data was collected
LocalPortNumber Local port number
RemoteIP Remote IP address used by the remote computer
RemotePortNumber Port number used by the remote IP address
SessionID A unique value that identifies communication session between

two IP addresses
SentBytes Number of bytes sent
TotalBytes Total number of bytes sent during session
ApplicationProtocol Type of network protocol used
ProcessID Windows process ID
ProcessName Path and file name of the process

RemoteIPLongitude IP longitude value
RemoteIPLatitude IP latitude value
Next steps
Search logs to view detailed wire data search records.
Using Service Map solution in Azure
Service Map automatically discovers application components on Windows and Linux systems and maps the
communication between services. With Service Map, you can view your servers in the way that you think of
them: as interconnected systems that deliver critical services. Service Map shows connections between servers,
processes, inbound and outbound connection latency, and ports across any TCP -connected architecture, with no
configuration required other than the installation of an agent.
This article describes the details of onboarding and using Service Map. For information about configuring the
prerequisites for this solution, see Enable the Azure Monitor for VMs overview. To summarize, you need the
following:
A Log Analytics workspace to enable this solution.
The Log Analytics agent installed on the Windows computer or Linux server configured to report the same
workspace that you enabled the solution with.
The Dependency agent installed on the Windows computer or Linux server.
NOTE
If you have already deployed Service Map, you can now also view your maps in Azure Monitor for VMs, which includes
additional features to monitor VM health and performance. To learn more, see Azure Monitor for VMs overview. To learn
about the differences between the Service Map solution and Azure Monitor for VMs Map feature, see the following FAQ.
Sign in to Azure
Enable Service Map

1. Enable the Service Map solution from the Azure marketplace or by using the process described in Add
monitoring solutions from the Solutions Gallery.
2. Install the Dependency agent on Windows or Install the Dependency agent on Linux on each computer where
you want to get data. The Dependency Agent can monitor connections to immediate neighbors, so you might
not need an agent on every computer.
You access Service Map in the Azure portal from your Log Analytics workspace, and select the option Solutions
from the left pane.
.
From the list of solutions, select ServiceMap(workspaceName) and in the Service Map solution overview page
click on the Service Map summary tile.
Use cases: Make your IT processes dependency aware

Discovery
Service Map automatically builds a common reference map of dependencies across your servers, processes, and
third-party services. It discovers and maps all TCP dependencies, identifying surprise connections, remote third-
party systems you depend on, and dependencies to traditional dark areas of your network, such as Active
Directory. Service Map discovers failed network connections that your managed systems are attempting to make,
helping you identify potential server misconfiguration, service outage, and network issues.
Incident management
Service Map helps eliminate the guesswork of problem isolation by showing you how systems are connected and
affecting each other. In addition to identifying failed connections, it helps identify misconfigured load balancers,
surprising or excessive load on critical services, and rogue clients, such as developer machines talking to
production systems. By using integrated workflows with Change Tracking, you can also see whether a change
event on a back-end machine or service explains the root cause of an incident.
Migration assurance
By using Service Map, you can effectively plan, accelerate, and validate Azure migrations, which helps ensure that
nothing is left behind and surprise outages do not occur. You can discover all interdependent systems that need to
migrate together, assess system configuration and capacity, and identify whether a running system is still serving
users or is a candidate for decommissioning instead of migration. After the move is complete, you can check on
client load and identity to verify that test systems and customers are connecting. If your subnet planning and
firewall definitions have issues, failed connections in Service Map maps point you to the systems that need
connectivity.
Business continuity
If you are using Azure Site Recovery and need help defining the recovery sequence for your application
environment, Service Map can automatically show you how systems rely on each other to ensure that your
recovery plan is reliable. By choosing a critical server or group and viewing its clients, you can identify which
front-end systems to recover after the server is restored and available. Conversely, by looking at critical servers’
back-end dependencies, you can identify which systems to recover before your focus systems are restored.
Patch management
Service Map enhances your use of the System Update Assessment by showing you which other teams and
servers depend on your service, so you can notify them in advance before you take down your systems for
patching. Service Map also enhances patch management by showing you whether your services are available and
properly connected after they are patched and restarted.
Mapping overview
Service Map agents gather information about all TCP -connected processes on the server where they’re installed
and details about the inbound and outbound connections for each process.
From the list in the left pane, you can select machines or groups that have Service Map agents to visualize their
dependencies over a specified time range. Machine dependency maps focus on a specific machine, and they show
all the machines that are direct TCP clients or servers of that machine. Machine Group maps show sets of servers
and their dependencies.
Machines can be expanded in the map to show the running process groups and processes with active network
connections during the selected time range. When a remote machine with a Service Map agent is expanded to
show process details, only those processes that communicate with the focus machine are shown. The count of
agentless front-end machines that connect into the focus machine is indicated on the left side of the processes
they connect to. If the focus machine is making a connection to a back-end machine that has no agent, the back-
end server is included in a Server Port Group, along with other connections to the same port number.
By default, Service Map maps show the last 30 minutes of dependency information. By using the time controls at
the upper left, you can query maps for historical time ranges of up to one hour to show how dependencies looked
in the past (for example, during an incident or before a change occurred). Service Map data is stored for 30 days
in paid workspaces, and for 7 days in free workspaces.
Status badges and border coloring

At the bottom of each server in the map can be a list of status badges conveying status information about the
server. The badges indicate that there is some relevant information for the server from one of the solution
integrations. Clicking a badge takes you directly to the details of the status in the right pane. The currently
available status badges include Alerts, Service Desk, Changes, Security, and Updates.
Depending on the severity of the status badges, machine node borders can be colored red (critical), yellow
(warning), or blue (informational). The color represents the most severe status of any of the status badges. A gray
border indicates a node that has no status indicators.
Process Groups
Process Groups combine processes that are associated with a common product or service into a process group.
When a machine node is expanded it will display standalone processes along with process groups. If any inbound
and outbound connections to a process within a process group has failed then the connection is shown as failed
for the entire process group.
Machine Groups
Machine Groups allow you to see maps centered around a set of servers, not just one so you can see all the
members of a multi-tier application or server cluster in one map.
Users select which servers belong in a group together and choose a name for the group. You can then choose to
view the group with all of its processes and connections, or view it with only the processes and connections that
directly relate to the other members of the group.
Creating a Machine Group
To create a group, select the machine or machines you want in the Machines list and click Add to group.
There, you can choose Create new and give the group a name.
NOTE
Machine groups are limited to 10 servers.
Viewing a Group
Once you’ve created some groups, you can view them by choosing the Groups tab.
Then select the Group name to view the map for that Machine Group.
The machines that belong to the group are outlined in white in the map.
Expanding the Group will list the machines that make up the Machine Group.
Filter by processes
You can toggle the map view between showing all processes and connections in the Group and only the ones that
directly relate to the Machine Group. The default view is to show all processes. You can change the view by
clicking the filter icon above the map.
When All processes is selected, the map will include all processes and connections on each of the machines in
the Group.
If you change the view to show only group-connected processes, the map will be narrowed down to only those
processes and connections that are directly connected to other machines in the group, creating a simplified view.
Adding machines to a group

To add machines to an existing group, check the boxes next to the machines you want and then click Add to
group. Then, choose the group you want to add the machines to.
Removing machines from a group
In the Groups List, expand the group name to list the machines in the Machine Group. Then, click on the ellipsis
menu next to the machine you want to remove and choose Remove.
Removing or renaming a group
Click on the ellipsis menu next to the group name in the Group List.
Role icons
Certain processes serve particular roles on machines: web servers, application servers, database, and so on.
Service Map annotates process and machine boxes with role icons to help identify at a glance the role a process
or server plays.
ROLE ICON DESCRIPTION
Web server
Application server
Database server
LDAP server
ROLE ICON DESCRIPTION
SMB server
Failed connections
Failed connections are shown in Service Map maps for processes and computers, with a dashed red line
indicating that a client system is failing to reach a process or port. Failed connections are reported from any
system with a deployed Service Map agent if that system is the one attempting the failed connection. Service
Map measures this process by observing TCP sockets that fail to establish a connection. This failure could result
from a firewall, a misconfiguration in the client or server, or a remote service being unavailable.
Understanding failed connections can help with troubleshooting, migration validation, security analysis, and
overall architectural understanding. Failed connections are sometimes harmless, but they often point directly to a
problem, such as a failover environment suddenly becoming unreachable, or two application tiers being unable to
talk after a cloud migration.
Client Groups
Client Groups are boxes on the map that represent client machines that do not have Dependency Agents. A single
Client Group represents the clients for an individual process or machine.
To see the IP addresses of the servers in a Client Group, select the group. The contents of the group are listed in
the Client Group Properties pane.
Server Port Groups
Server Port Groups are boxes that represent server ports on servers that do not have Dependency Agents. The
box contains the server port and a count of the number of servers with connections to that port. Expand the box
to see the individual servers and connections. If there is only one server in the box, the name or IP address is
listed.
Context menu
Clicking the ellipsis (...) at the top right of any server displays the context menu for that server.
Load server map

Clicking Load Server Map takes you to a new map with the selected server as the new focus machine.
Show self-links
Clicking Show Self-Links redraws the server node, including any self-links, which are TCP connections that start
and end on processes within the server. If self-links are shown, the menu command changes to Hide Self-Links,
so that you can turn them off.
Computer summary
The Machine Summary pane includes an overview of a server's operating system, dependency counts, and data
from other solutions. Such data includes performance metrics, service desk tickets, change tracking, security, and
updates.
Computer and process properties

When you navigate a Service Map map, you can select machines and processes to gain additional context about
their properties. Machines provide information about DNS name, IPv4 addresses, CPU and memory capacity,
VM type, operating system and version, last reboot time, and the IDs of their OMS and Service Map agents.
You can gather process details from operating-system metadata about running processes, including process
name, process description, user name and domain (on Windows), company name, product name, product version,
working directory, command line, and process start time.
The Process Summary pane provides additional information about the process’s connectivity, including its
bound ports, inbound and outbound connections, and failed connections.
Alerts integration
Service Map integrates with Azure Alerts to show fired alerts for the selected server in the selected time range.
The server displays an icon if there are current alerts, and the Machine Alerts pane lists the alerts.
To enable Service Map to display relevant alerts, create an alert rule that fires for a specific computer. To create
proper alerts:
Include a clause to group by computer (for example, by Computer interval 1 minute).
Choose to alert based on metric measurement.
Log events integration

Service Map integrates with Log Search to show a count of all available log events for the selected server during
the selected time range. You can click any row in the list of event counts to jump to Log Search and see the
individual log events.
Service Desk integration
Service Map integration with the IT Service Management Connector is automatic when both solutions are
enabled and configured in your Log Analytics workspace. The integration in Service Map is labeled "Service
Desk." For more information, see Centrally manage ITSM work items using IT Service Management Connector.
The Machine Service Desk pane lists all IT Service Management events for the selected server in the selected
time range. The server displays an icon if there are current items and the Machine Service Desk pane lists them.
To open the item in your connected ITSM solution, click View Work Item.
To view the details of the item in Log Search, click Show in Log Search. Connection metrics are written to two
new tables in Log Analytics
Change Tracking integration

Service Map integration with Change Tracking is automatic when both solutions are enabled and configured in
The Machine Change Tracking pane lists all changes, with the most recent first, along with a link to drill down
to Log Search for additional details.
The following image is a detailed view of a ConfigurationChange event that you might see after you select Show
in Log Analytics.
Performance integration
The Machine Performance pane displays standard performance metrics for the selected server. The metrics
include CPU utilization, memory utilization, network bytes sent and received, and a list of the top processes by
network bytes sent and received.
To see performance data, you may need to enable the appropriate Log Analytics performance counters. The
counters you will want to enable:
Windows:
Processor(*)\% Processor Time
Memory\% Committed Bytes In Use
Network Adapter(*)\Bytes Sent/sec
Network Adapter(*)\Bytes Received/sec
Linux:
Processor(*)\% Processor Time
Memory(*)\% Used Memory
Network Adapter(*)\Bytes Sent/sec
Network Adapter(*)\Bytes Received/sec
To get the network performance data, you must also have enabled the Wire Data 2.0 solution in your workspace.
Security integration
Service Map integration with Security and Audit is automatic when both solutions are enabled and configured in
The Machine Security pane shows data from the Security and Audit solution for the selected server. The pane
lists a summary of any outstanding security issues for the server during the selected time range. Clicking any of
the security issues drills down into a Log Search for details about them.
Updates integration
Service Map integration with Update Management is automatic when both solutions are enabled and configured
in your Log Analytics workspace.
The Machine Updates pane displays data from the Update Management solution for the selected server. The
pane lists a summary of any missing updates for the server during the selected time range.
Log Analytics records
Service Map computer and process inventory data is available for search in Log Analytics. You can apply this data
to scenarios that include migration planning, capacity analysis, discovery, and on-demand performance
troubleshooting.
One record is generated per hour for each unique computer and process, in addition to the records that are
generated when a process or computer starts or is on-boarded to Service Map. These records have the properties
in the following tables. The fields and values in the ServiceMapComputer_CL events map to fields of the Machine
resource in the ServiceMap Azure Resource Manager API. The fields and values in the ServiceMapProcess_CL
events map to the fields of the Process resource in the ServiceMap Azure Resource Manager API. The
ResourceName_s field matches the name field in the corresponding Resource Manager resource.
NOTE
As Service Map features grow, these fields are subject to change.
There are internally generated properties you can use to identify unique processes and computers:
Computer: Use ResourceId or ResourceName_s to uniquely identify a computer within a Log Analytics
workspace.
Process: Use ResourceId to uniquely identify a process within a Log Analytics workspace. ResourceName_s is
unique within the context of the machine on which the process is running (MachineResourceName_s)
Because multiple records can exist for a specified process and computer in a specified time range, queries can
return more than one record for the same computer or process. To include only the most recent record, add "|
dedup ResourceId" to the query.
Connections
Connection metrics are written to a new table in Log Analytics - VMConnection. This table provides information
about the connections for a machine (inbound and outbound). Connection Metrics are also exposed with APIs
that provide the means to obtain a specific metric during a time window. TCP connections resulting from "accept-
ing on a listening socket are inbound, while those created by connect-ing to a given IP and port are outbound.
The direction of a connection is represented by the Direction property, which can be set to either inbound or
outbound.
Records in these tables are generated from data reported by the Dependency agent. Every record represents an
observation over a one minute time interval. The TimeGenerated property indicates the start of the time interval.
Each record contains information to identify the respective entity, that is, connection or port, as well as metrics
associated with that entity. Currently, only network activity that occurs using TCP over IPv4 is reported.
To manage cost and complexity, connection records do not represent individual physical network connections.
Multiple physical network connections are grouped into a logical connection, which is then reflected in the
respective table. Meaning, records in VMConnection table represent a logical grouping and not the individual
physical connections that are being observed. Physical network connection sharing the same value for the
following attributes during a given one minute interval, are aggregated into a single logical record in
VMConnection.
Direction Direction of the connection, value is inbound or outbound
Machine The computer FQDN
Process Identity of process or groups of processes,

initiating/accepting the connection
SourceIp IP address of the source
DestinationIp IP address of the destination
DestinationPort Port number of the destination
Protocol Protocol used for the connection. Values is tcp.
To account for the impact of grouping, information about the number of grouped physical connections is
provided in the following properties of the record:
LinksEstablished The number of physical network connections that have been

established during the reporting time window
LinksTerminated The number of physical network connections that have been

terminated during the reporting time window
LinksFailed The number of physical network connections that have failed

during the reporting time window. This information is
currently available only for outbound connections.
LinksLive The number of physical network connections that were open

at the end of the reporting time window
Metrics
In addition to connection count metrics, information about the volume of data sent and received on a given
logical connection or network port are also included in the following properties of the record:
BytesSent Total number of bytes that have been sent during the
BytesReceived Total number of bytes that have been received during the
Responses The number of responses observed during the reporting time

window.
ResponseTimeMax The largest response time (milliseconds) observed during the

ResponseTimeMin The smallest response time (milliseconds) observed during

the reporting time window. If no value, the property is blank.
ResponseTimeSum The sum of all response times (milliseconds) observed during

the reporting time window. If no value, the property is blank
The third type of data being reported is response time - how long does a caller spend waiting for a request sent
over a connection to be processed and responded to by the remote endpoint. The response time reported is an
estimation of the true response time of the underlying application protocol. It is computed using heuristics based
on the observation of the flow of data between the source and destination end of a physical network connection.
Conceptually, it is the difference between the time the last byte of a request leaves the sender, and the time when
the last byte of the response arrives back to it. These two timestamps are used to delineate request and response
events on a given physical connection. The difference between them represents the response time of a single
request.
In this first release of this feature, our algorithm is an approximation that may work with varying degree of
success depending on the actual application protocol used for a given network connection. For example, the
current approach works well for request-response based protocols such as HTTP (S ), but does not work with one-
way or message queue-based protocols.
1. If a process accepts connections on the same IP address but over multiple network interfaces, a separate
record for each interface will be reported.
2. Records with wildcard IP will contain no activity. They are included to represent the fact that a port on the
3. To reduce verbosity and data volume, records with wildcard IP will be omitted when there is a matching record
IsWildcardBind record property with the specific IP address, will be set to "True" to indicate that the port is
4. Ports that are bound only on a specific interface have IsWildcardBind set to "False".
Naming and Classification
For convenience, the IP address of the remote end of a connection is included in the RemoteIp property. For
inbound connections, RemoteIp is the same as SourceIp, while for outbound connections, it is the same as
DestinationIp. The RemoteDnsCanonicalNames property represents the DNS canonical names reported by the
machine for RemoteIp. The RemoteDnsQuestions and RemoteClassification properties are reserved for future
use.
Geolocation
VMConnection also includes geolocation information for the remote end of each connection record in the
following properties of the record:
RemoteCountry The name of the country/region hosting RemoteIp. For

example, United States
RemoteLatitude The geolocation latitude. For example, 47.68
RemoteLongitude The geolocation longitude. For example, -122.12
Malicious IP
Every RemoteIp property in VMConnection table is checked against a set of IPs with known malicious activity. If
the RemoteIp is identified as malicious the following properties will be populated (they are empty, when the IP is
not considered malicious) in the following properties of the record:
MaliciousIp The RemoteIp address
IndicatorThreadType Threat indicator detected is one of the following values,

Botnet, C2, CryptoMining, Darknet, DDos, MaliciousUrl,
Malware, Phishing, Proxy, PUA, Watchlist.
Description Description of the observed threat.
TLPLevel Traffic Light Protocol (TLP) Level is one of the defined values,
White, Green, Amber, Red.
Confidence Values are 0 – 100.
Severity Values are 0 – 5, where 5 is the most severe and 0 is not

severe at all. Default value is 3.
FirstReportedDateTime The first time the provider reported the indicator.
LastReportedDateTime The last time the indicator was seen by Interflow.
IsActive Indicates indicators are deactivated with True or False value.
ReportReferenceLink Links to reports related to a given observable.

AdditionalInformation Provides additional information, if applicable, about the

observed threat.
ServiceMapComputer_CL records
Records with a type of ServiceMapComputer_CL have inventory data for servers with Service Map agents. These
records have the properties in the following table:
Type ServiceMapComputer_CL
ResourceId The unique identifier for a machine within the workspace
ResourceName_s The unique identifier for a machine within the workspace
ComputerName_s The computer FQDN
DnsNames_s An array of DNS names
OperatingSystemFamily_s Windows or Linux
OperatingSystemFullName_s The full name of the operating system
Bitness_s The bitness of the machine (32-bit or 64-bit)
PhysicalMemory_d The physical memory in MB
Cpus_d The number of CPUs
CpuSpeed_d The CPU speed in MHz
VirtualizationState_s unknown, physical, virtual, hypervisor
VirtualMachineType_s hyperv, vmware, and so on
VirtualMachineNativeMachineId_g The VM ID as assigned by its hypervisor
VirtualMachineName_s The name of the VM
BootTime_t The boot time
ServiceMapProcess_CL Type records

Records with a type of ServiceMapProcess_CL have inventory data for TCP -connected processes on servers with
Service Map agents. These records have the properties in the following table:
Type ServiceMapProcess_CL
ResourceId The unique identifier for a process within the workspace
ResourceName_s The unique identifier for a process within the machine on

which it is running
MachineResourceName_s The resource name of the machine
ExecutableName_s The name of the process executable
StartTime_t The process pool start time
FirstPid_d The first PID in the process pool
Description_s The process description
CompanyName_s The name of the company
InternalName_s The internal name
ProductName_s The name of the product
ProductVersion_s The product version
FileVersion_s The file version
CommandLine_s The command line
ExecutablePath _s The path to the executable file
WorkingDirectory_s The working directory
UserName The account under which the process is executing
UserDomain The domain under which the process is executing
Sample log searches

List all known machines
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId
List the physical memory capacity of all managed computers.
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project PhysicalMemory_d,
ComputerName_s
List computer name, DNS, IP, and OS.
ServiceMapComputer_CL | summarize arg_max(TimeGenerated, *) by ResourceId | project ComputerName_s,
OperatingSystemFullName_s, DnsNames_s, Ipv4Addresses_s
Find all processes with "sql" in the command line
ServiceMapProcess_CL | where CommandLine_s contains_cs "sql" | summarize arg_max(TimeGenerated, *) by
ResourceId
Find a machine (most recent record) by resource name
search in (ServiceMapComputer_CL ) "m-4b9c93f9-bc37-46df-b43c-899ba829e07b" | summarize
arg_max(TimeGenerated, *) by ResourceId
Find a machine (most recent record) by IP address
search in (ServiceMapComputer_CL ) "10.229.243.232" | summarize arg_max(TimeGenerated, *) by ResourceId
List all known processes on a specified machine
ServiceMapProcess_CL | where MachineResourceName_s == "m-559dbcd8-3130-454d-8d1d-f624e57961bc" |
summarize arg_max(TimeGenerated, *) by ResourceId
List all computers running SQL
ServiceMapComputer_CL | where ResourceName_s in ((search in (ServiceMapProcess_CL ) "*sql*" | distinct
MachineResourceName_s)) | distinct ComputerName_s
List all unique product versions of curl in my datacenter
ServiceMapProcess_CL | where ExecutableName_s == "curl" | distinct ProductVersion_s
Create a computer group of all computers running CentOS
ServiceMapComputer_CL | where OperatingSystemFullName_s contains_cs "CentOS" | distinct
ComputerName_s
Summarize the outbound connections from a group of machines
// the machines of interest
let machines = datatable(m: string) ["m-82412a7a-6a32-45a9-a8d6-538354224a25"];
// map of ip to monitored machine in the environment
let ips=materialize(ServiceMapComputer_CL
| summarize ips=makeset(todynamic(Ipv4Addresses_s)) by MonitoredMachine=ResourceName_s
| mvexpand ips to typeof(string));
// all connections to/from the machines of interest
let out=materialize(VMConnection
| where Machine in (machines)
| summarize arg_max(TimeGenerated, *) by ConnectionId);
// connections to localhost augmented with RemoteMachine
let local=out
| where RemoteIp startswith "127."
| project ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort,
Protocol, RemoteIp, RemoteMachine=Machine;
// connections not to localhost augmented with RemoteMachine
let remote=materialize(out
| where RemoteIp !startswith "127."
| join kind=leftouter (ips) on $left.RemoteIp == $right.ips
DestinationPort, Protocol, RemoteIp, RemoteMachine=MonitoredMachine);
// the remote machines to/from which we have connections
let remoteMachines = remote | summarize by RemoteMachine;
// all augmented connections
(local)
| union (remote)
//Take all outbound records but only inbound records that come from either //unmonitored machines or
monitored machines not in the set for which we are computing dependencies.
| where Direction == 'outbound' or (Direction == 'inbound' and RemoteMachine !in (machines))
DestinationPort, Protocol, RemoteIp, RemoteMachine
// identify the remote port
| extend RemotePort=iff(Direction == 'outbound', DestinationPort, 0)
// construct the join key we'll use to find a matching port
| extend JoinKey=strcat_delim(':', RemoteMachine, RemoteIp, RemotePort, Protocol)
// find a matching port
| join kind=leftouter (VMBoundPort
| where Machine in (remoteMachines)
| summarize arg_max(TimeGenerated, *) by PortId
| extend JoinKey=strcat_delim(':', Machine, Ip, Port, Protocol)) on JoinKey
// aggregate the remote information
| summarize Remote=makeset(iff(isempty(RemoteMachine), todynamic('{}'), pack('Machine', RemoteMachine,
'Process', Process1, 'ProcessName', ProcessName1))) by ConnectionId, Direction, Machine, Process,
ProcessName, SourceIp, DestinationIp, DestinationPort, Protocol
REST API
All the server, process, and dependency data in Service Map is available via the Service Map REST API.
Diagnostic and usage data

Microsoft automatically collects usage and performance data through your use of the Service Map service.
Microsoft uses this data to provide and improve the quality, security, and integrity of the Service Map service. To
provide accurate and efficient troubleshooting capabilities, the data includes information about the configuration
of your software, such as operating system and version, IP address, DNS name, and workstation name. Microsoft
does not collect names, addresses, or other contact information.
For more information about data collection and usage, see the Microsoft Online Services Privacy Statement.
Next steps
Learn more about log searches in Log Analytics to retrieve data that's collected by Service Map.
Troubleshooting
If you have any problems installing or running Service Map, this section can help you. If you still can't resolve
your problem, please contact Microsoft Support.
Dependency agent installation problems
Installer prompts for a reboot
The Dependency agent generally does not require a reboot upon installation or removal. However, in certain rare
cases, Windows Server requires a reboot to continue with an installation. This happens when a dependency,
usually the Microsoft Visual C++ Redistributable library requires a reboot because of a locked file.
Message "Unable to install Dependency agent: Visual Studio Runtime libraries failed to install (code = [code_number])" appears
The Microsoft Dependency agent is built on the Microsoft Visual Studio runtime libraries. You'll get a message if
there's a problem during installation of the libraries.
The runtime library installers create logs in the %LOCALAPPDATA%\temp folder. The file is
dd_vcredist_arch_yyyymmddhhmmss.log , where arch is x86 or amd64 and yyyymmddhhmmss is the date and time
(24-hour clock) when the log was created. The log provides details about the problem that's blocking installation.
It might be useful to install the latest runtime libraries first.
The following table lists code numbers and suggested resolutions.
CODE DESCRIPTION RESOLUTION
0x17 The library installer requires a Windows Look in the most recent library installer
update that hasn't been installed. log.
If a reference to
Windows8.1-KB2999226-x64.msu is
followed by a line
Error 0x80240017: Failed to
execute MSU package,
you don't have the prerequisites to
install KB2999226. Follow the
instructions in the prerequisites section
in Universal C Runtime in Windows
article. You might need to run Windows
Update and reboot multiple times in
order to install the prerequisites.
Run the Microsoft Dependency agent

installer again.
Post-installation issues
Server doesn't appear in Service Map
If your Dependency agent installation succeeded, but you don't see your machine in the Service Map solution:
Is the Dependency agent installed successfully? You can validate this by checking to see if the service is
installed and running.
Windows: Look for the service named Microsoft Dependency agent. Linux: Look for the running
process microsoft-dependency-agent.
Are you on the Log Analytics free tier? The Free plan allows for up to five unique Service Map machines.
Any subsequent machines won't appear in Service Map, even if the prior five are no longer sending data.
Is your server sending log and perf data to Azure Monitor Logs? Go to Azure Monitor\Logs and run the
following query for your computer:
Usage | where Computer == "admdemo-appsvr" | summarize sum(Quantity), any(QuantityUnit) by DataType
Did you get a variety of events in the results? Is the data recent? If so, your Log Analytics agent is operating
correctly and communicating with the workspace. If not, check the agent on your machine: Log Analytics agent
for Windows troubleshooting or Log Analytics agent for Linux troubleshooting.
Server appears in Service Map but has no processes
If you see your machine in Service Map, but it has no process or connection data, that indicates that the
Dependency agent is installed and running, but the kernel driver didn't load.
Check the C:\Program Files\Microsoft Dependency Agent\logs\wrapper.log file (Windows) or
/var/opt/microsoft/dependency-agent/log/service.log file ( Linux). The last lines of the file should indicate why
the kernel didn't load. For example, the kernel might not be supported on Linux if you updated your kernel.
Feedback
Do you have any feedback for us about Service Map or this documentation? Visit our User Voice page, where you
can suggest features or vote up existing suggestions.
Computer groups in Azure Monitor log queries
Computer groups in Azure Monitor allow you to scope log queries to a particular set of computers. Each group is
populated with computers either using a query that you define or by importing groups from different sources.
When the group is included in a log query, the results are limited to records that match the computers in the
group.
NOTE
Creating a computer group

You can create a computer group in Azure Monitor using any of the methods in the following table. Details on
each method are provided in the sections below.
METHOD DESCRIPTION
Log query Create a log query that returns a list of computers.
Log Search API Use the Log Search API to programmatically create a
computer group based on the results of a log query.
Active Directory Automatically scan the group membership of any agent

computers that are members of an Active Directory domain
and create a group in Azure Monitor for each security group.
(Windows machines only)
Configuration Manager Import collections from System Center Configuration

Manager and create a group in Azure Monitor for each.
Windows Server Update Services Automatically scan WSUS servers or clients for targeting
groups and create a group in Azure Monitor for each.
Log query
Computer groups created from a log query contain all of the computers returned by a query that you define. This
query is run every time the computer group is used so that any changes since the group was created is reflected.
You can use any query for a computer group, but it must return a distinct set of computers by using
distinct Computer . Following is a typical example query that you could use for as a computer group.
Heartbeat | where Computer contains "srv" | distinct Computer
Use the following procedure to create a computer group from a log search in the Azure portal.
1. Click Logs in the Azure Monitor menu in the Azure portal.
2. Create and run a query that returns the computers that you want in the group.
3. Click Save at the top of the screen.
4. Change Save as to Function and select Save this query as a computer group.
5. Provide values for each property for the computer group described in the table and click Save.
The following table describes the properties that define a computer group.
Name Name of the query to display in the portal.
Function alias A unique alias used to identify the computer group in a query.
Category Category to organize the queries in the portal.
Active Directory
When you configure Azure Monitor to import Active Directory group memberships, it analyzes the group
membership of any Windows domain joined computers with the Log Analytics agent. A computer group is
created in Azure Monitor for each security group in Active Directory, and each Windows computer is added to the
computer groups corresponding to the security groups they are members of. This membership is continuously
updated every 4 hours.
NOTE
Imported Active Directory groups only contain Windows machines.
You configure Azure Monitor to import Active Directory security groups from Advanced settings in your Log
Analytics workspace in the Azure portal. Select Computer Groups, Active Directory, and then Import Active
Directory group memberships from computers. There is no further configuration required.
When groups have been imported, the menu lists the number of computers with group membership detected and
the number of groups imported. You can click on either of these links to return the ComputerGroup records with
this information.
Windows Server Update Service
When you configure Azure Monitor to import WSUS group memberships, it analyzes the targeting group
membership of any computers with the Log Analytics agent. If you are using client-side targeting, any computer
that is connected to Azure Monitor and is part of any WSUS targeting groups has its group membership
imported to Azure Monitor. If you are using server-side targeting, the Log Analytics agent should be installed on
the WSUS server in order for the group membership information to be imported to Azure Monitor. This
membership is continuously updated every 4 hours.
You configure Azure Monitor to import WSUS groups from Advanced settings in your Log Analytics workspace
in the Azure portal. Select Computer Groups, WSUS, and then Import WSUS group memberships. There is
no further configuration required.
When groups have been imported, the menu lists the number of computers with group membership detected and
the number of groups imported. You can click on either of these links to return the ComputerGroup records with
this information.
System Center Configuration Manager
When you configure Azure Monitor to import Configuration Manager collection memberships, it creates a
computer group for each collection. The collection membership information is retrieved every 3 hours to keep the
computer groups current.
Before you can import Configuration Manager collections, you must connect Configuration Manager to Azure
Monitor.
When collections have been imported, the menu lists the number of computers with group membership detected
and the number of groups imported. You can click on either of these links to return the ComputerGroup records
with this information.
Managing computer groups

You can view computer groups that were created from a log query or the Log Search API from Advanced
settings in your Log Analytics workspace in the Azure portal. Select Computer Groups and then Saved Groups.
Click the x in the Remove column to delete the computer group. Click the View members icon for a group to
run the group's log search that returns its members. You can't modify a computer group but instead must delete
and then recreate it with the modified settings.
Using a computer group in a log query
You use a Computer group created from a log query in a query by treating its alias as a function, typically with the
following syntax:
Table | where Computer in (ComputerGroup)
For example, you could use the following to return UpdateSummary records for only computers in a computer
group called mycomputergroup.
UpdateSummary | where Computer in (mycomputergroup)
Imported computer groups and their included computers are stored in the ComputerGroup table. For example,
the following query would return a list of computers in the Domain Computers group from Active Directory.
ComputerGroup | where GroupSource == "ActiveDirectory" and Group == "Domain Computers" | distinct Computer
The following query would return UpdateSummary records for only computers in Domain Computers.
let ADComputers = ComputerGroup | where GroupSource == "ActiveDirectory" and Group == "Domain Computers" |
distinct Computer;
UpdateSummary | where Computer in (ADComputers)
Computer group records

A record is created in the Log Analytics workspace for each computer group membership created from Active
Directory or WSUS. These records have a type of ComputerGroup and have the properties in the following
table. Records are not created for computer groups based on log queries.
Type ComputerGroup
SourceSystem SourceSystem
Computer Name of the member computer.
Group Name of the group.
GroupFullName Full path to the group including the source and source name.
GroupSource Source that group was collected from.
ActiveDirectory
WSUS
WSUSClientTargeting
GroupSourceName Name of the source that the group was collected from. For
Active Directory, this is the domain name.
ManagementGroupName Name of the management group for SCOM agents. For other
agents, this is AOI-<workspace ID>
TimeGenerated Date and time the computer group was created or updated.
Next steps
Overview of Azure platform logs
Platform logs provide detailed diagnostic and auditing information for Azure resources and the Azure platform
they depend on. They are automatically generated although you need to configure certain platform logs to be
forwarded to one or more destinations to be retained. This article provides an overview of platform logs including
what information they provide and how you can configure them for collection and analysis.
Types of platform logs

The following table lists the specific platform logs that are available at different layers of Azure.
LAYER LOGS DESCRIPTION
Azure Resources Resource logs Provide insight into operations that

were performed within an Azure
resource (the data plane), for example
getting a secret from a Key Vault or
making a request to a database. The
content of resource logs varies by the
Azure service and resource type.
Resource logs were previously referred
to as diagnostic logs.
Azure Subscription Activity log Provides insight into the operations on

each Azure resource in the subscription
from the outside (the management
plane) in addition to updates on Service
Health events. There is a single Activity
log for each Azure subscription.
Azure Tenant Azure Active Directory logs Contains the history of sign-in activity
and audit trail of changes made in the
Azure Active Directory for a particular
tenant.
Viewing platform logs
You can view the Activity log and Azure Active Directory logs in the Azure portal. You must send resource logs to a
destination to view them.
Destinations
You can send platform logs to one or more of the destinations in the following table depending on your
monitoring requirements.
DESTINATION SCENARIO REFERENCES
Log Analytics workspace Analyze the logs with other monitoring Resource logs
data and leverage Azure Monitor Activity log
features such as log queries and alerts. Azure Activity Directory logs
Azure storage Archive the logs for audit, static Resource logs
analysis, or backup. Activity log
Azure Activity Directory logs
Event hub Stream the logs to third-party logging Resource logs

and telemetry systems. Activity log
Azure Activity Directory logs
Diagnostic settings and log profiles

Configure destinations for Resource logs and Azure Active Directory logs by creating a Diagnostic setting.
Configure destinations for the Activity log by creating a log profile or by connecting it to a Log Analytics
workspace.
The diagnostic setting and log profile define the following:
One or more destinations to send selected logs and metrics.
Which log categories and metrics from the resource are sent to the destinations.
If a storage account is selected as a destination, how long each log category should be retained.
Next steps
Learn more about the Activity log
Learn more about resource logs
View the resource log schema for different Azure services
Azure Resource logs overview
Azure Resource logs are platform logs emitted by Azure resources that describe their internal operation. All resource logs share a
common top-level schema with the flexibility for each service to emit unique properties for their own events.
NOTE
Resource logs were previously known as diagnostic logs.
Collecting resource logs

Resource logs are automatically generated by supported Azure resources, but they aren't collected unless you configure them using a
diagnostic setting. Create a diagnostic setting for each Azure resource to forward the logs to the following destinations:
DESTINATION SCENARIO
Log Analytics workspace Analyze the logs with other monitoring data and leverage Azure Monitor
features such as log queries and log alerts.
Azure storage Archive the logs for auditing or backup.
Event hub Stream the logs to third-party logging and telemetry systems.
Compute resources
Resource logs differ from guest OS-level logs in Azure compute resources. Compute resources require an agent to collect logs and
metrics from their guest OS, including such data as event logs, syslog, and performance counters. Use the Diagnostic Extension to route
log data from Azure virtual machines and the Log Analytics agent to collect logs and metrics from virtual machines in Azure, in other
clouds, and on-premises into a Log Analytics workspace. See Sources of monitoring data for Azure Monitor for details.
Resource logs schema

Each Azure service has its own schema when resource logs are written to one of the destinations, but they all share a the top level
schema in the following table. See Service-specific schemas below for links to the schema for each service.
NAME REQUIRED/OPTIONAL DESCRIPTION
time Required The timestamp (UTC) of the event.
resourceId Required The resource ID of the resource that emitted

the event. For tenant services, this is of the
form /tenants/tenant-id/providers/provider-
name.
tenantId Required for tenant logs The tenant ID of the Active Directory tenant
that this event is tied to. This property is only
used for tenant-level logs, it does not appear in
resource-level logs.
operationName Required The name of the operation represented by this

event. If the event represents an RBAC
operation, this is the RBAC operation name (eg.
Microsoft.Storage/storageAccounts/blobServices
/blobs/Read). Typically modeled in the form of a
Resource Manager operation, even if they are
not actual documented Resource Manager
operations (
Microsoft.
<providerName>/<resourceType>/<subtype>/<Write/Read/Delete
)
operationVersion Optional The api-version associated with the operation, if

the operationName was performed using an API
(eg.
http://myservice.windowsazure.net/object?
api-version=2016-06-01
). If there is no API that corresponds to this
operation, the version represents the version of
that operation in case the properties associated
with the operation change in the future.
category Required The log category of the event. Category is the

granularity at which you can enable or disable
logs on a particular resource. The properties
that appear within the properties blob of an
event are the same within a particular log
category and resource type. Typical log
categories are “Audit” “Operational” “Execution”
and “Request.”
resultType Optional The status of the event. Typical values include

Started, In Progress, Succeeded, Failed, Active,
and Resolved.
resultSignature Optional The sub status of the event. If this operation

corresponds to a REST API call, this is the HTTP
status code of the corresponding REST call.
resultDescription Optional The static text description of this operation, eg.

“Get storage file.”
durationMs Optional The duration of the operation in milliseconds.
callerIpAddress Optional The caller IP address, if the operation

corresponds to an API call that would come
from an entity with a publicly-available IP
address.
correlationId Optional A GUID used to group together a set of related

events. Typically, if two events have the same
operationName but two different statuses (eg.
“Started” and “Succeeded”), they share the same
correlation ID. This may also represent other
relationships between events.
identity Optional A JSON blob that describes the identity of the

user or application that performed the
operation. Typically this will include the
authorization and claims / JWT token from
active directory.
Level Optional The severity level of the event. Must be one of

Informational, Warning, Error, or Critical.
location Optional The region of the resource emitting the event,

eg. “East US” or “France South”
properties Optional Any extended properties related to this

particular category of events. All custom/unique
properties must be put inside this “Part B” of
the schema.
Service-specific schemas
The schema for resource diagnostic logs varies depends on the resource type which is defined by the resourceId property) and the
category properties. This following list shows all Azure services that support resource logs with links to the service and category-
specific schema where available.
SERVICE SCHEMA & DOCS
Azure Active Directory Overview, Audit log schema and Sign-ins schema
Analysis Services https://azure.microsoft.com/blog/azure-analysis-services-integration-with-

azure-diagnostic-logs/
API Management API Management Diagnostic Logs
Application Gateways Diagnostics Logging for Application Gateway
Azure Automation Log analytics for Azure Automation
Azure Batch Azure Batch diagnostic logging
Azure Database for MySQL Azure Database for MySQL diagnostic logs
Azure Database for PostgreSQL Azure Database for PostgreSQL diagnostic logs
Cognitive Services Diagnostic Logging for Azure Cognitive Services
Content Delivery Network Azure Diagnostic Logs for CDN
CosmosDB Azure Cosmos DB Logging
Data Factory Monitor Data Factories using Azure Monitor
Data Lake Analytics Accessing diagnostic logs for Azure Data Lake Analytics
Data Lake Store Accessing diagnostic logs for Azure Data Lake Store
Event Hubs Azure Event Hubs diagnostic logs
Express Route Schema not available.
Azure Firewall Schema not available.
IoT Hub IoT Hub Operations
Key Vault Azure Key Vault Logging
Load Balancer Log analytics for Azure Load Balancer
Logic Apps Logic Apps B2B custom tracking schema
Network Security Groups Log analytics for network security groups (NSGs)
DDOS Protection Manage Azure DDoS Protection Standard
Power BI Dedicated Diagnostic logging for Power BI Embedded in Azure
Recovery Services Data Model for Azure Backup
Search Enabling and using Search Traffic Analytics
Service Bus Azure Service Bus diagnostic logs
SQL Database Azure SQL Database diagnostic logging
Stream Analytics Job diagnostic logs
Traffic Manager Traffic Manager Log schema

Virtual Networks Schema not available.
Virtual Network Gateways Schema not available.
Next Steps
Learn more about other Azure platform logs that you can use to monitor Azure.
Collect Azure resource logs in Log Analytics
workspace in Azure Monitor
Resource logs in Azure provide rich, frequent data about the internal operation of an Azure resource. This article
describes collecting resource logs in a Log Analytics workspace which allows you to analyze it with other
monitoring data collected in Azure Monitor Logs using powerful log queries and also to leverage other Azure
Monitor features such as alerts and visualizations.
What you can do with resource logs in a workspace

Collecting resource logs into a Log Analytics workspace allows you to analyze the logs of all your Azure resources
together and to take advantage of all the features available to Azure Monitor Logs which includes the following:
Log queries - Create log queries using a powerful query language to quickly analyze and gain insights into
your diagnostic data, and to analyze it with data collected from other sources in Azure Monitor.
Alerting - Get proactive notification of critical conditions and patterns identified in your resource logs using
log alerts in Azure Monitor.
Visualizations - Pin the results of a log query to an Azure dashboard or include it in a workbook as part of an
interactive report.
Prerequisites
You need to create a new workspace if you don't already have one. The workspace does not have to be in the same
subscription as the resource sending logs as long as the user who configures the setting has appropriate RBAC
access to both subscriptions.
Create a diagnostic setting

Resource logs are not collected by default. Collect them in a Log Analytics workspace and other destinations by
creating a diagnostic setting for an Azure resource. See Create diagnostic setting to collect logs and metrics in
Azure for details.
Collection mode
Data collected in a Log Analytics workspace is stored in tables as described in Structure of Azure Monitor Logs.
The tables used by resource logs depend on what type of collection the resource is using:
Azure diagnostics - All data written is to the AzureDiagnostics table.
Resource-specific - Data is written to individual table for each category of the resource.
Azure Diagnostics mode
In this mode, all data from any diagnostic setting will be collected in the AzureDiagnostics table. This is the legacy
method used today by most Azure services.
Since multiple resource types send data to the same table, its schema is the superset of the schemas of all the
different data types being collected.
Consider the following example where diagnostic settings are being collected in the same workspace for the
following data types:
Audit logs of service 1 (having a schema consisting of columns A, B, and C )
Error logs of service 1 (having a schema consisting of columns D, E, and F )
Audit logs of service 2 (having a schema consisting of columns G, H, and I)
The AzureDiagnostics table will look as follows:
RESOU
RCEPRO CATEGO
VIDER RY A B C D E F G H I
Micros AuditL x1 y1 z1
oft.Serv ogs
ice1
Micros ErrorLo q1 w1 e1
oft.Serv gs
ice1
Micros AuditL j1 k1 l1
oft.Serv ogs
ice2
Micros ErrorLo q2 w2 e2
oft.Serv gs
ice1
Micros AuditL j3 k3 l3
oft.Serv ogs
ice2
Micros AuditL x5 y5 z5
oft.Serv ogs
ice1
...
Resource -Specific
In this mode, individual tables in the selected workspace are created for each category selected in the diagnostic
setting. This method is recommended since it makes it much easier to work with the data in log queries, provides
better discoverability of schemas and their structure, improves performance across both ingestion latency and
query times, and the ability to grant RBAC rights on a specific table. All Azure services will eventually migrate to
the Resource-Specific mode.
The example above would result in three tables being created:
Table Service1AuditLogs as follows:
RESOURCE PROVIDER CATEGORY A B C
Service1 AuditLogs x1 y1 z1
Service1 AuditLogs x5 y5 z5
...
Table Service1ErrorLogs as follows:

RESOURCE PROVIDER CATEGORY D E F
Service1 ErrorLogs q1 w1 e1
Service1 ErrorLogs q2 w2 e2
...
Table Service2AuditLogs as follows:
RESOURCE PROVIDER CATEGORY G H I
Service2 AuditLogs j1 k1 l1
Service2 AuditLogs j3 k3 l3
...
Select the collection mode

Most Azure resources will write data to the workspace in either Azure Diagnostic or Resource-Specific mode
without giving you a choice. See the documentation for each service for details on which mode it uses. All Azure
services will eventually use Resource-Specific mode. As part of this transition, some resources will allow you to
select a mode in the diagnostic setting. You should specify resource-specific mode for any new diagnostic settings
since this makes the data easier to manage and may help you to avoid complex migrations at a later date.
NOTE
Currently, Azure diagnostics and Resource-specific mode can only be selected when configuring the diagnostic setting in
the Azure portal. If you configure the setting using CLI, PowerShell, or Rest API, it will default to Azure diagnostic.
You can modify an existing diagnostic setting to resource-specific mode. In this case, data that was already
collected will remain in the AzureDiagnostics table until it's removed according to your retention setting for the
workspace. New data will be collected in to the dedicated table. Use the union operator to query data across both
tables.
Continue to watch Azure Updates blog for announcements about Azure services supporting Resource-Specific
mode.
Column limit in AzureDiagnostics
There is a 500 property limit for any table in Azure Monitor Logs. Once this limit is reached, any rows containing
data with any property outside of the first 500 will be dropped at ingestion time. The AzureDiagnostics table is in
particular susceptible to this limit since it includes properties for all Azure services writing to it.
If you're collecting diagnostic logs from multiple services, AzureDiagnostics may exceed this limit, and data will be
missed. Until all Azure services support resource-specific mode, you should configure resources to write to
multiple workspaces to reduce the possibility of reaching the 500 column limit.
Azure Data Factory
Azure Data Factory, because of a very detailed set of logs, is a service that is known to write a large number of
columns and potentially cause AzureDiagnostics to exceed its limit. For any diagnostic settings configured before
the resource-specific mode was enabled there will be a new column created for every uniquely-named user
parameter against any activity. More columns will be created because of the verbose nature of activity inputs and
outputs.
You should migrate your logs to use the resource-specific mode as soon as possible. If you are unable to do so
immediately, an interim alternative is to isolate Azure Data Factory logs into their own workspace to minimize the
chance of these logs impacting other log types being collected in your workspaces.
Next steps
To learn about Azure resource logs, see Overview of Azure Resource logs.
To create a diagnostic setting to collect resource logs to a Log Analytics workspace, see Create diagnostic
setting to collect logs and metrics in Azure.
Archive Azure resource logs to storage account
describes collecting resource logs to an Azure storage account to retain data for archiving.
Prerequisites
You need to create an Azure storage account if you don't already have one. The storage account does not have to
be in the same subscription as the resource sending logs as long as the user who configures the setting has
appropriate RBAC access to both subscriptions.
You should not use an existing storage account that has other, non-monitoring data stored in it so that you can
better control access to monitoring data. If you are also archiving the Activity log to a storage account though,
you may choose to use that same storage account to keep all monitoring data in a central location.

Resource logs are not collected by default. Collect them in an Azure storage account and other destinations by
creating a diagnostic setting for an Azure resource. See Create diagnostic setting to collect logs and metrics in
Azure for details.
Data retention
The retention policy defines the number of days to retain the data from each log category and metric data stored
in a storage account. A retention policy can be any number of days between 0 and 365. A retention policy of zero
specifies that the events for that log category are stored indefinitely.
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 will be deleted. For example, if you had a retention policy of one day, at the beginning of the day
today the logs from the day before yesterday would be deleted. The delete process begins at midnight UTC, but
note that it can take up to 24 hours for the logs to be deleted from your storage account.
Schema of resource logs in storage account

Once you have created the diagnostic setting, a storage container is created in the storage account as soon as an
event occurs in one of the enabled log categories. The blobs within the container use the following naming
convention:
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group

name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/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
For example, the blob for a network security group might have a name similar to the following:
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=201
6/m=08/d=22/h=18/m=00/PT1H.json
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 resource log events are broken into individual blobs per hour.
Within the PT1H.json file, each event is stored with the following format. This will use a common top level
schema but be unique for each Azure services as described in Resource logs schema.
{"time": "2016-07-01T00:00:37.2040000Z","systemId": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category":

"NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-
890123456789/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","op
erationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-
123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/
s1id1234-5679-0123-4567-
890123456789/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/secu
rityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}
NOTE
Platform logs are written to blob storage using JSON lines, where each event is a line and the newline character indicates a
new event. This format was implemented in November 2018. Prior to this date, logs were written to blob storage as a json
array of records as described in Prepare for format change to Azure Monitor platform logs archived to a storage account.
Next steps
Download blobs for analysis.
Archive Azure Active Directory logs with Azure Monitor.
Read more about resource logs.
Stream Azure resource logs to Azure Event Hubs
describes streaming resource logs to event hubs to send data to external systems such as third-party SIEMs and
other log analytics solutions.
What you can do with resource logs sent to an event hub

Stream resource logs in Azure to event hubs to provide the following functionality:
Stream logs to 3rd party logging and telemetry systems – Stream all of your resource logs to a single
event hub to pipe log data to a third-party SIEM or log analytics tool.
Build a custom telemetry and logging platform – The highly scalable publish-subscribe nature of event
hubs allows you to flexibly ingest resource logs into a custom teletry platform. See Designing and Sizing a
Global Scale Telemetry Platform on Azure Event Hubs for details.
View service health by streaming data to Power BI – Use Event Hubs, Stream Analytics, and Power BI
to transform your diagnostics data into near real-time insights on your Azure services. See Stream Analytics
and Power BI: A real-time analytics dashboard for streaming data for details on this solution.
The following SQL code is a sample Stream Analytics query that you can use to parse all the log data in to a
Power BI table:
SELECT
records.ArrayValue.[Properties you want to track]
INTO
[OutputSourceName – the Power BI source]
FROM
[InputSourceName] AS e
CROSS APPLY GetArrayElements(e.records) AS records
Prerequisites
You need to create an event hub if you don't already have one. If you previously streamed resource logs to this
Event Hubs namespace, then that event hub will be reused.
The shared access policy for the namespace defines the permissions that the streaming mechanism has. Streaming
to Event Hubs requires Manage, Send, and Listen permissions. You can create or modify shared access policies in
the Azure portal under the Configure tab for your Event Hubs namespace.
To update the diagnostic setting to include streaming, you must have the ListKey permission on that Event Hubs
authorization rule. The Event Hubs namespace does not have to be in the same subscription as the subscription
that's emitting logs, as long as the user who configures the setting has appropriate RBAC access to both
subscriptions and both subscriptions are in the same AAD tenant.

Resource logs are not collected by default. Send them to an event hub and other destinations by creating a
diagnostic setting for an Azure resource. See Create diagnostic setting to collect logs and metrics in Azure for
details.
Stream data from compute resources
The process in this article is for non-compute resources as described in Overview of Azure resource logs. Stream
resource logs from Azure compute resources using the Windows Azure Diagnostics agent. See Streaming Azure
Diagnostics data in the hot path by using Event Hubs for details.
Consuming log data from event hubs

When you consume resource logs from event hubs, it will be is JSON format with the elements in the following
table.
records An array of all log events in this payload.
time Time at which the event occurred.
category Log category for this event.
resourceId Resource ID of the resource that generated this event.
operationName Name of the operation.
level Optional. Indicates the log event level.
properties Properties of the event. These will vary for each Azure service
as described in .
Following is sample output data from Event Hubs:

{
"records": [
{
"time": "2016-07-15T18:00:22.6235064Z",
"workflowId": "/SUBSCRIPTIONS/DF602C9C-7AA0-407D-A6FB-
EB20C8BD1192/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/DF602C9C-7AA0-407D-A6FB-
EB20C8BD1192/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/0858733001350992
1957/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"subscriptionId": "df602c9c-7aa0-407d-a6fb-eb20c8bd1192",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330013509921957",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
"clientTrackingId": "08587330013509921958"
}
}
},
{
"time": "2016-07-15T18:01:15.7532989Z",
"level": "Information",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"runId": "08587330012106702630",
},
"correlation": {
"actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
}
}
}
]
}
Next steps
Stream Azure Active Directory logs with Azure Monitor.
Read more about Azure resource logs.
Get started with Event Hubs.
Overview of Azure Activity log
The Azure Activity Log provides insight into subscription-level events that have occurred in Azure. This
includes a range of data, from Azure Resource Manager operational data to updates on Service Health events.
The Activity Log was previously known as Audit Logs or Operational Logs, since the Administrative category
reports control-plane events for your subscriptions.
Use the Activity Log, to determine the what, who, and when for any write operations (PUT, POST, DELETE )
taken on the resources in your subscription. You can also understand the status of the operation and other
relevant properties.
The Activity Log does not include read (GET) operations or operations for resources that use the Classic/RDFE
model.
Comparison to resource logs

There is a single Activity Log for each Azure subscription. It provides data about the operations on a resource
from the outside (the "control plane"). Resource Logs are emitted by a resource and provide information about
the operation of that resource (the "data plane"). You must create a diagnostic setting for each resource to
collect resource logs.
NOTE
The Azure Activity Log is primarily for activities that occur in Azure Resource Manager. It does not track resources using
the Classic/RDFE model. Some Classic resource types have a proxy resource provider in Azure Resource Manager (for
example, Microsoft.ClassicCompute). If you interact with a Classic resource type through Azure Resource Manager using
these proxy resource providers, the operations appear in the Activity Log. If you interact with a Classic resource type
outside of the Azure Resource Manager proxies, your actions are only recorded in the Operation Log. The Operation Log
can be browsed in a separate section of the portal.
Activity Log retention

Once created, Activity Log entries are not modified or deleted by the system. Also, you can't change them in the
interface or programmatically. Activity Log events are stored for 90 days. To store this data for longer periods,
collect it in Azure Monitor or export it to storage or Event Hubs.
View the Activity Log

View the Activity Log for all resources from the Monitor menu in the Azure portal. View the Activity Log for a
particular resource from the Activity Log option in that resource's menu. You can also retrieve Activity Log
records with PowerShell, CLI, or REST API. See View and retrieve Azure Activity log events.
Collect Activity Log in Azure Monitor

Collect the Activity Log into a Log Analytics workspace in Azure Monitor to analyze it with other monitoring
data and to retain the data for longer than 90 days. See Collect and analyze Azure activity logs in Log Analytics
Export Activity Log

Export the Activity Log to Azure Storage for archiving or stream it to an Event Hub for ingestion by a third-
party service or custom analytics solution. See Export the Azure Activity Log. You can also analyze Activity Log
events in Power BI using the Power BI content pack.
Alert on Activity Log
You can create an alert when particular events are created in the Activity Log with an Activity Log alert. You can
also create an alert using a log query when your Activity Log is connected to a Log Analytics workspace, but
there is a cost to log query alerts. There is no cost for Activity Log alerts.
Categories in the Activity Log

Each event in the Activity Log has a particular category that are described in the following table. For full details
on the schemata of these categories, see Azure Activity Log event schema.
CATEGORY DESCRIPTION
Administrative Contains the record of all create, update, delete, and action
operations performed through Resource Manager. Examples
of Administrative events include create virtual machine and
delete network security group.
Every action taken by a user or application using Resource

Manager is modeled as an operation on a particular
resource type. If the operation type is Write, Delete, or
Action, the records of both the start and success or fail of
that operation are recorded in the Administrative category.
Administrative events also include any changes to role-
based access control in a subscription.
Service Health Contains the record of any service health incidents that
have occurred in Azure. An example of a Service Health
event SQL Azure in East US is experiencing downtime.
Service Health events come in Six varieties: Action Required,

Assisted Recovery, Incident, Maintenance, Information, or
Security. These events are only created if you have a
resource in the subscription that would be impacted by the
event.
Resource Health Contains the record of any resource health events that have
occurred to your Azure resources. An example of a Resource
Health event is Virtual Machine health status changed to
unavailable.
Resource Health events can represent one of four health

statuses: Available, Unavailable, Degraded, and Unknown.
Additionally, Resource Health events can be categorized as
being Platform Initiated or User Initiated.
Alert Contains the record of activations for Azure alerts. An

example of an Alert event is CPU % on myVM has been over
80 for the past 5 minutes.
Autoscale Contains the record of any events related to the operation

of the autoscale engine based on any autoscale settings you
have defined in your subscription. An example of an
Autoscale event is Autoscale scale up action failed.
Recommendation Contains recommendation events from Azure Advisor.

CATEGORY DESCRIPTION
Security Contains the record of any alerts generated by Azure

Security Center. An example of a Security event is Suspicious
double extension file executed.
Policy Contains records of all effect action operations performed by

Azure Policy. Examples of Policy events include Audit and
Deny. Every action taken by Policy is modeled as an
operation on a resource.
Next Steps
Create a log profile to export the Azure Activity Log
Stream the Azure Activity Log to Event Hubs
Archive the Azure Activity Log to storage
View and retrieve Azure Activity log events
The Azure Activity Log provides insight into subscription-level events that have occurred in Azure. This article
provides details on different methods for viewing and retrieving Activity Log events.
Azure portal
View the Activity Log for all resources from the Monitor menu in the Azure portal. View the Activity Log for a
particular resource from the Activity Log option in that resource's menu.
You can filter Activity Log events by the following fields:

Timespan: The start and end time for events.
Category: The event category as described in Categories in the Activity Log.
Subscription: One or more Azure subscription names.
Resource group: One or more resource groups within the selected subscriptions.
Resource (name): - The name of a specific resource.
Resource type: The type of resource, for example Microsoft.Compute/virtualmachines.
Operation name - The name of an Azure Resource Manager operation, for example
Microsoft.SQL/servers/Write.
Severity: The severity level of the event. Available values are Informational, Warning, Error, Critical.
Event initiated by: The user who performed the operation.
Open search: Open text search box that searches for that string across all fields in all events.
View change history
When reviewing the Activity Log, it can help to see what changes happened during that event time. You can view
this information with Change history. Select an event from the Activity Log you want to look deeper into. Select
the Change history (Preview) tab to view any associated changes with that event.
If there are any associated changes with the event, you'll see a list of changes that you can select. This opens up the
Change history (Preview) page. On this page you see the changes to the resource. As you can see from the
following example, we are able to see not only that the VM changed sizes, but what the previous VM size was
before the change and what it was changed to.
To learn more about Change history, see Get resource changes.

Click Logs at the top of the Activity Log page to open the Activity Log Analytics monitoring solution for the
subscription. This will allow you to view analytics for the Activity Log and to run log queries with the
AzureActivity table. If your Activity Log isn't connected to a Log Analytics workspace, you will be prompted to
perform this configuration.
PowerShell
Use the Get-AzLog cmdlet to retrieve the Activity Log from PowerShell. Following are some common examples.
NOTE
Get-AzLog only provides 15 days of history. Use the -MaxEvents parameter to query the last N events beyond 15 days.
To access events older than 15 days, use the REST API or SDK. If you do not include StartTime, then the default value is
EndTime minus one hour. If you do not include EndTime, then the default value is current time. All times are in UTC.
Get log entries created after a particular date time:
Get-AzLog -StartTime 2016-03-01T10:30
Get log entries between a date time range:
Get-AzLog -StartTime 2015-01-01T10:30 -EndTime 2015-01-01T11:30
Get log entries from a specific resource group:
Get-AzLog -ResourceGroup 'myrg1'
Get log entries from a specific resource provider between a date time range:
Get-AzLog -ResourceProvider 'Microsoft.Web' -StartTime 2015-01-01T10:30 -EndTime 2015-01-01T11:30
Get log entries with a specific caller:
Get-AzLog -Caller 'myname@company.com'
Get the last 1000 events:
Get-AzLog -MaxEvents 1000
CLI
Use az monitor activity-log to retrieve the Activity Log from CLI. Following are some common examples.
View all available options.
az monitor activity-log list -h
az monitor activity-log list --resource-group <group name>
Get log entries with a specific caller:
az monitor activity-log list --caller myname@company.com
Get logs by caller on a resource type, within a date range:

az monitor activity-log list --resource-provider Microsoft.Web \
--caller myname@company.com \
--start-time 2016-03-08T00:00:00Z \
--end-time 2016-03-16T00:00:00Z
REST API
Use the Azure Monitor REST API to retrieve the Activity Log from a REST client. Following are some common
examples.
Get Activity Logs with filter:
GET https://management.azure.com/subscriptions/089bd33f-d4ec-47fe-8ba5-
0753aa5c5b33/providers/microsoft.insights/eventtypes/management/values?api-version=2015-04-
01&$filter=eventTimestamp ge '2018-01-21T20:00:00Z' and eventTimestamp le '2018-01-23T20:00:00Z' and
resourceGroupName eq 'MSSupportGroup'
Get Activity Logs with filter and select:
01&$filter=eventTimestamp ge '2015-01-21T20:00:00Z' and eventTimestamp le '2015-01-23T20:00:00Z' and
resourceGroupName eq
'MSSupportGroup'&$select=eventName,id,resourceGroupName,resourceProviderName,operationName,status,eventTimesta
mp,correlationId,submissionTimestamp,level
Get Activity Logs with select:
01&$select=eventName,id,resourceGroupName,resourceProviderName,operationName,status,eventTimestamp,correlation
Id,submissionTimestamp,level
Get Activity Logs without filter or select:
0753aa5c5b33/providers/microsoft.insights/eventtypes/management/values?api-version=2015-04-01
Next Steps
Read an overview of the Activity Log
Archive the Activity Log to storage or stream it to Event Hubs
Stream the Azure Activity Log to Event Hubs
Archive the Azure Activity Log to storage
Collect and analyze Azure activity logs in Log
Analytics workspace in Azure Monitor
The Azure Activity Log provides insight into subscription-level events that have occurred in your Azure
subscription. This article describes how to collect the Activity Log into a Log Analytics workspace and how to use
the Activity Log Analytics monitoring solution, which provides log queries and views for analyzing this data.
Connecting the Activity Log to a Log Analytics workspace provides the following benefits:
Consolidate the Activity Log from multiple Azure subscriptions into one location for analysis.
Store Activity Log entries for longer than 90 days.
Correlate Activity Log data with other monitoring data collected by Azure Monitor.
Use log queries to perform complex analysis and gain deep insights on Activity Log entries.
Connect to Log Analytics workspace

An Activity Log can be connected to only one workspace, but a single workspace can be connected to the
Activity Log for multiple subscriptions in the same Azure tenant. For collection across multiple tenants, see
Collect Azure Activity Logs into a Log Analytics workspace across subscriptions in different Azure Active
Directory tenants.
IMPORTANT
You may receive an error with the following procedure if the Microsoft.OperationalInsights and
Microsoft.OperationsManagement resource providers aren't registered for your subscription. See Azure resource providers
and types to register these providers.
Use the following procedure to connect the Activity Log to your Log Analytics workspace:
1. From the Log Analytics workspaces menu in the Azure portal, select the workspace to collect the
Activity Log.
2. In the Workspace Data Sources section of the workspace's menu, select Azure Activity log.
3. Click the subscription you want to connect.
4. Click Connect to connect the Activity log in the subscription to the selected workspace. If the subscription
is already connected to another workspace, click Disconnect first to disconnect it.
Analyze in Log Analytics workspace

When you connect an Activity Log to a Log Analytics workspace, entries will be written to the workspace into a
table called AzureActivity that you can retrieve with a log query. The structure of this table varies depending on
the category of log entry. See Azure Activity Log event schema for a description of each category.
Activity Logs Analytics monitoring solution

The Azure Log Analytics monitoring solution includes multiple log queries and views for analyzing the Activity
Log records in your Log Analytics workspace.
Install the solution
Use the procedure in Install a monitoring solution to install the Activity Log Analytics solution. There is no
additional configuration required.
Use the solution
Monitoring solutions are accessed from the Monitor menu in the Azure portal. Select More in the Insights
section to open the Overview page with the solution tiles. The Azure Activity Logs tile displays a count of the
number of AzureActivity records in your workspace.
Click the Azure Activity Logs tile to open the Azure Activity Logs view. The view includes the visualization
parts in the following table. Each part lists up to 10 items matching that parts's criteria for the specified time
range. You can run a log query that returns all matching records by clicking See all at the bottom of the part.
VISUALIZATION PART DESCRIPTION
Azure Activity Log Entries Shows a bar chart of the top Azure Activity Log entry record
totals for the date range that you have selected and shows a
list of the top 10 activity callers. Click the bar chart to run a
log search for AzureActivity . Click a caller item to run a
log search returning all Activity Log entries for that item.
Activity Logs by Status Shows a doughnut chart for Azure Activity Log status for the
selected date range and a list of the top ten status records.
Click the chart to run a log query for
AzureActivity | summarize AggregatedValue = count()
by ActivityStatus
. Click a status item to run a log search returning all Activity
Log entries for that status record.
Activity Logs by Resource Shows the total number of resources with Activity Logs and
lists the top ten resources with record counts for each
resource. Click the total area to run a log search for
by Resource
, which shows all Azure resources available to the solution.
Click a resource to run a log query returning all activity
records for that resource.
Activity Logs by Resource Provider Shows the total number of resource providers that produce
Activity Logs and lists the top ten. Click the total area to run
a log query for
by ResourceProvider
, which shows all Azure resource providers. Click a resource
provider to run a log query returning all activity records for
the provider.
Next steps
Learn more about the Activity Log.
Use log queries to view detailed information from your Activity Log.
Collect Azure Activity logs into Azure Monitor across
Azure Active Directory tenants
This article steps through a method to collect Azure Activity Logs into a Log Analytics workspace in Azure Monitor
using the Azure Log Analytics Data Collector connector for Logic Apps. Use the process in this article when you
need to send logs to a workspace in a different Azure Active Directory tenant. For example, if you are a managed
service provider, you may want to collect activity logs from a customer's subscription and store them in a Log
Analytics workspace in your own subscription.
If the Log Analytics workspace is in the same Azure subscription, or in a different subscription but in the same
Azure Active Directory, use the steps in the Collect and analyze Azure activity logs in Log Analytics workspace in
Azure Monitor to collect Azure Activity logs.
Overview
The strategy used in this scenario is to have Azure Activity Log send events to an Event Hub where a Logic App
sends them to your Log Analytics workspace.
Advantages of this approach include:

Low latency since the Azure Activity Log is streamed into the Event Hub. The Logic App is then triggered and
posts the data to the workspace.
Minimal code is required, and there is no server infrastructure to deploy.
This article steps you through how to:
1. Create an Event Hub.
2. Export activity logs to an Event Hub using Azure Activity Log export profile.
3. Create a Logic App to read from the Event Hub and send events to Log Analytics workspace.
Requirements
Following are the requirements for the Azure resources used in this scenario.
The Event Hub namespace does not have to be in the same subscription as the subscription emitting logs. The
user who configures the setting must have appropriate access permissions to both subscriptions. If you have
multiple subscriptions in the same Azure Active directory, you can send the activity logs for all subscriptions to
a single event hub.
The Logic App can be in a different subscription from the event hub and does not need to be in the same Azure
Active Directory. The Logic App reads from the Event Hub using the Event Hub's shared access key.
The Log Analytics workspace can be in a different subscription and Azure Active Directory from the Logic App,
but for simplicity we recommend that they are in the same subscription. The Logic App sends to the workspace
using the Log Analytics workspace ID and key.
Step 1 - Create an Event Hub
1. In the Azure portal, select Create a resource > Internet of Things > Event Hubs.
2. Under Create namespace, either enter a new namespace or selecting an existing one. The system
immediately checks to see if the name is available.
3. Choose the pricing tier (Basic or Standard), an Azure subscription, resource group, and location for the new
resource. Click Create to create the namespace. You may have to wait a few minutes for the system to fully
provision the resources.
4. Click the namespace you just created from the list.
5. Select Shared access policies, and then click RootManageSharedAccessKey.
6. Click the copy button to copy the RootManageSharedAccessKey connection string to the clipboard.
7. In a temporary location, such as Notepad, keep a copy the Event Hub name and either the primary or
secondary Event Hub connection string. The Logic App requires these values. For the Event Hub connection
string, you can use the RootManageSharedAccessKey connection string or create a separate one. The
connection string you use must start with Endpoint=sb:// and be for a policy that has the Manage access
policy.
Step 2 - Export Activity Logs to Event Hub

To enable streaming of the Activity Log, you pick an Event Hub Namespace and a shared access policy for that
namespace. An Event Hub is created in that namespace when the first new Activity Log event occurs.
You can use an event hub namespace that is not in the same subscription as the subscription emitting logs,
however the subscriptions must be in the same Azure Active Directory. The user who configures the setting must
have the appropriate RBAC to access both subscriptions.
1. In the Azure portal, select Monitor > Activity Log.
2. Click the Export button at the top of the page.
3. Select the Subscription to export from, and then click Select all in the Regions drop-down to select
events for resources in all regions. Click the Export to an event hub check box.
4. Click Service bus namespace, and then select the Subscription with the event hub, the event hub
namespace, and an event hub policy name.
5. Click OK and then Save to save these settings. The settings are immediately be applied to your
subscription.
Step 3 - Create Logic App
Once the activity logs are writing to the event hub, you create a Logic App to collect the logs from the event hub
and write them to the Log Analytics workspace.
The Logic App includes the following:
An Event Hub connector trigger to read from the Event Hub.
A Parse JSON action to extract the JSON events.
A Compose action to convert the JSON to an object.
A Log Analytics send data connector to post the data to the Log Analytics workspace.
Logic App Requirements

Before creating your Logic App, make sure you have the following information from previous steps:
Event Hub name
Event Hub connection string (either the primary or secondary) for the Event Hub namespace.
Log Analytics workspace ID
Log Analytics shared key
To get the event Hub name and connection string, follow the steps in Check Event Hubs namespace permissions
and find the connection string.
Create a new blank Logic App
1. In the Azure portal, choose Create a resource > Enterprise Integration > Logic App.
2. Enter the settings in the table below.
SETTING DESCRIPTION
Name Unique name for the logic app.
Subscription Select the Azure subscription that will contain the logic
app.
Resource Group Select an existing Azure resource group or create a new

one for the logic app.
Location Select the datacenter region for deploying your logic app.
SETTING DESCRIPTION
Log Analytics Select if you want to log the status of each run of your
logic app in a Log Analytics workspace.
3. Select Create. When Deployment Succeeded notification displays, click on Go to resource to open your
Logic App.
4. Under Templates, choose Blank Logic App.
The Logic Apps Designer now shows you available connectors and their triggers, which you use for starting your
logic app workflow.
Add Event Hub trigger
1. In the search box for the Logic App Designer, type event hubs for your filter. Select the trigger Event Hubs -
When events are available in Event Hub.
2. When you're prompted for credentials, connect to your Event Hubs namespace. Enter a name for your
connection and then the connection string that you copied. Select Create.
3. After you create the connection, edit the settings for the trigger. Start by selecting insights-operational-
logs from the Event Hub name drop-down.
4. Expand Show advanced options and change Content type to application/json
Add Parse JSON action

The output from the Event Hub contains a JSON payload with an array of records. The Parse JSON action is used
to extract just the array of records for sending to Log Analytics workspace.
1. Click New step > Add an action
2. In the search box, type parse json for your filter. Select the action Data Operations - Parse JSON.
3. Click in the Content field and then select Body.
4. Copy and paste the following schema into the Schema field. This schema matches the output from the
Event Hub action.
{
"properties": {
"body": {
"properties": {
"ContentData": {
"type": "string"
},
"Properties": {
"properties": {
"ProfileName": {
"type": "string"
},
"x-opt-enqueued-time": {
"type": "string"
},
"x-opt-offset": {
"type": "string"
},
"x-opt-sequence-number": {
"type": "number"
}
},
"type": "object"
},
"SystemProperties": {
"properties": {
"EnqueuedTimeUtc": {
"type": "string"
},
"Offset": {
"type": "string"
},
"PartitionKey": {},
"SequenceNumber": {
"type": "number"
}
},
"type": "object"
}
},
"type": "object"
},
"headers": {
"properties": {
"Cache-Control": {
"type": "string"
},
"Content-Length": {
"type": "string"
},
"Content-Type": {
"type": "string"
},
"Date": {
"type": "string"
},
"Expires": {
"type": "string"
},
"Location": {
"type": "string"
},
"Pragma": {
"type": "string"
},
"Retry-After": {
"type": "string"
},
"Timing-Allow-Origin": {
"type": "string"
},
"Transfer-Encoding": {
"type": "string"
},
"Vary": {
"type": "string"
},
"X-AspNet-Version": {
"type": "string"
},
"X-Powered-By": {
"type": "string"
},
"x-ms-request-id": {
"type": "string"
}
},
"type": "object"
}
},
"type": "object"
}
TIP
You can get a sample payload by clicking Run and looking at the Raw Output from the Event Hub. You can then use this
output with Use sample payload to generate schema in the Parse JSON activity to generate the schema.
Add Compose action

The Compose action takes the JSON output and creates an object that can be used by the Log Analytics action.
2. Type compose for your filter and then select the action Data Operations - Compose.
3. Click the Inputs field and select Body under the Parse JSON activity.
Add Log Analytics Send Data action
The Azure Log Analytics Data Collector action takes the object from the Compose action and sends it to a Log
2. Type log analytics for your filter and then select the action Azure Log Analytics Data Collector - Send
Data.
3. Enter a name for your connection and paste in the Workspace ID and Workspace Key for your Log
Analytics workspace. Click Create.
4. After you create the connection, edit the settings in the table below.
SETTING VALUE DESCRIPTION
JSON Request body Output from the Compose action Retrieves the records from the body
of the Compose action.
Custom Log Name AzureActivity Name of the custom log table to

create in Log Analytics workspace to
hold the imported data.
Time-generated-field time Don't select the JSON field for time -

just type the word time. If you select
the JSON field the designer puts the
Send Data action into a For Each
loop, which is not what you want.
5. Click Save to save the changes you've made to your Logic App.
Step 4 - Test and troubleshoot the Logic App

With the workflow complete, you can test in the designer to verify that it's working without error.
In the Logic App Designer, click Run to test the Logic App. Each step in the Logic App shows a status icon, with a
white check mark in a green circle indicating success.
To see detailed information on each step, click on the step name to expand it. Click on Show raw inputs and
Show raw outputs to see more information on the data received and sent at each step.
Step 5 - View Azure Activity Log in Log Analytics

The final step is to check the Log Analytics workspace to make sure that data is being collected as expected.
1. In the Azure portal, click All services found in the upper left-hand corner. In the list of resources, type Log
Analytics. As you begin typing, the list filters based on your input. Select Log Analytics.
2. In your list of Log Analytics workspaces, select your workspace.
3. Click the Log Search tile and on the Log Search pane, in the query field type AzureActivity_CL and then hit
enter or click the search button to the right of the query field. If you didn't name your custom log AzureActivity,
type the name you chose and append _CL .
NOTE
The first time a new custom log is sent to the Log Analytics workspace it may take up to an hour for the custom log to be
searchable.
NOTE
The activity logs are written to a custom table and do not appear in the Activity Log solution.
Next steps
In this article, you’ve created a logic app to read Azure Activity Logs from an Event Hub and send them to the Log
Analytics workspace for analysis. To learn more about visualizing data in a workspace, including creating
dashboards, review the tutorial for Visualize data.
Visualize Log Search data tutorial
Export Azure Activity log to storage or Azure Event
Hubs
The Azure Activity Log provides insight into subscription-level events that have occurred in your Azure
subscription. In addition to viewing the Activity log in the Azure portal or copying it to a Log Analytics
workspace where it can be analyzed with other data collected by Azure Monitor, you can create a log profile to
archive the Activity log to an Azure storage account or stream it to an Event Hub.
Archive Activity Log

Archiving the Activity Log to a storage account is useful if you would like to retain your log data longer than 90
days (with full control over the retention policy) for audit, static analysis, or backup. If you only need to retain
your events for 90 days or less you do not need to set up archival to a storage account, since Activity Log events
are retained in the Azure platform for 90 days.
Stream Activity Log to Event Hub

Azure Event Hubs is a data streaming platform and event ingestion service that can receive and process millions
of events per second. Data sent to an event hub can be transformed and stored by using any real-time analytics
provider or batching/storage adapters. Two ways you might use the streaming capability for the Activity Log
are:
Stream to third-party logging and telemetry systems: Over time, Azure Event Hubs streaming will
become the mechanism to pipe your Activity Log into third-party SIEMs and log analytics solutions.
Build a custom telemetry and logging platform: If you already have a custom-built telemetry platform
or are thinking about building one, the highly scalable publish-subscribe nature of Event Hubs enables you to
flexibly ingest the activity log.
Prerequisites
Storage account
If you're archiving your Activity Log, you need to create a storage account if you don't already have one. You
should not use an existing storage account that has other, non-monitoring data stored in it so that you can better
control access to monitoring data. If you are also archiving Diagnostic Logs and metrics to a storage account
though, you may choose to use that same storage account to keep all monitoring data in a central location.
The storage account does not have to be in the same subscription as the subscription emitting logs as long as
the user who configures the setting has appropriate RBAC access to both subscriptions.
NOTE
You cannot currently archive data to a storage account that is behind a secured virtual network.
Event Hubs
If you're sending your Activity Log to an event hub, then you need to create an event hub if you don't already
have one. If you previously streamed Activity Log events to this Event Hubs namespace, then that event hub will
be reused.
The shared access policy defines the permissions that the streaming mechanism has. Streaming to Event Hubs
requires Manage, Send, and Listen permissions. You can create or modify shared access policies for the Event
Hubs namespace in the Azure portal under the Configure tab for your Event Hubs namespace.
To update the Activity Log log profile to include streaming, you must have the ListKey permission on that Event
Hubs authorization rule. The Event Hubs namespace does not have to be in the same subscription as the
subscription that's emitting logs, as long as the user who configures the setting has appropriate RBAC access to
both subscriptions and both subscriptions are in the same AAD tenant.
Stream the Activity Log to an Event Hub by creating a Log Profile.
Create a log profile

You define how your Azure Activity log is exported using a log profile. Each Azure subscription can only have
one log profile. These settings can be configured via the Export option in the Activity Log blade in the portal.
They can also be configured programmatically using the Azure Monitor REST API, PowerShell cmdlets, or CLI.
The log profile defines the following.
Where the Activity Log should be sent. Currently, the available options are Storage Account or Event Hubs.
Which event categories should be sent. The meaning of category in Log Profiles and Activity Log events is
different. In the Log Profile, Category represents the operation type (Write, Delete, Action). In an Activity Log
event, the category"* property represents the source or type of event (for example, Administration,
ServiceHealth, and Alert).
Which regions (locations) should be exported. You should include all locations since many events in the
Activity Log are global events.
How long the Activity Log 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 365.
If retention policies are set, but storing logs in a storage account is disabled, then 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 beginning of the day
today the logs from the day before yesterday would be deleted. The delete process begins at midnight UTC, but
note that it can take up to 24 hours for the logs to be deleted from your storage account.
IMPORTANT
You may receive an error when creating a log profile if the Microsoft.Insights resource provider isn't registered. See Azure
resource providers and types to register this provider.
Create log profile using the Azure portal

Create or edit a log profile with the Export to Event Hub option in the Azure portal.
1. From the Monitor menu in the Azure portal, select Export to Event Hub.
2. In the blade that appears, specify the following:
Regions with the events to export. You should select all regions to ensure that you don't miss key
events since the Activity Log is a global (non-regional) log and so most events do not have a
region associated with them.
If you want to write to storage account:
The Storage Account to which you would like to save events.
The number of days you want to retain these events in storage. A setting of 0 days retains the
logs forever.
If you want to write to event hub:
The Service Bus Namespace in which you would like an Event Hub to be created for streaming
these events.
3. Click Save to save these settings. The settings are immediately be applied to your subscription.
Configure log profile using PowerShell
NOTE
Azure PowerShell.
If a log profile already exists, you first need to remove the existing log profile and then create a new one.
1. Use Get-AzLogProfile to identify if a log profile exists. If a log profile does exist, note the name property.
2. Use Remove-AzLogProfile to remove the log profile using the value from the name property.
# For example, if the log profile name is 'default'

Remove-AzLogProfile -Name "default"
3. Use Add-AzLogProfile to create a new log profile:
Add-AzLogProfile -Name my_log_profile -StorageAccountId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -
serviceBusRuleId /subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessKe
y -Location global,westus,eastus -RetentionInDays 90 -Category Write,Delete,Action
PROPERTY REQUIRED DESCRIPTION
Name Yes Name of your log profile.
StorageAccountId No Resource ID of the Storage Account

where the Activity Log should be
saved.
serviceBusRuleId No Service Bus Rule ID for the Service

Bus namespace you would like to
have event hubs created in. This is a
string with the format:
{service bus resource
ID}/authorizationrules/{key
name}
.
Location Yes Comma-separated list of regions for

which you would like to collect
Activity Log events.
RetentionInDays Yes Number of days for which events

should be retained in the storage
account, between 1 and 365. A
value of zero stores the logs
indefinitely.
Category No Comma-separated list of event

categories that should be collected.
Possible values are Write, Delete,
and Action.
Example script
Following is a sample PowerShell script to create a log profile that writes the Activity Log to both a storage
account and event hub.
# Settings needed for the new log profile
$logProfileName = "default"
$locations = (Get-AzLocation).Location
$locations += "global"
$subscriptionId = "<your Azure subscription Id>"
$resourceGroupName = "<resource group name your event hub belongs to>"
$eventHubNamespace = "<event hub namespace>"
# Build the service bus rule Id from the settings above

$serviceBusRuleId =
"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.EventHub/namespaces/$e
ventHubNamespace/authorizationrules/RootManageSharedAccessKey"
# Build the storage account Id from the settings above

$storageAccountId =
"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccount
s/$storageAccountName"
Add-AzLogProfile -Name $logProfileName -Location $locations -ServiceBusRuleId $serviceBusRuleId
Configure log profile using Azure CLI

If a log profile already exists, you first need to remove the existing log profile and then create a new log profile.
1. Use az monitor log-profiles list to identify if a log profile exists.
2. Use az monitor log-profiles delete --name "<log profile name> to remove the log profile using the value
from the name property.
3. Use az monitor log-profiles create to create a new log profile:
az monitor log-profiles create --name "default" --location null --locations "global" "eastus"
"westus" --categories "Delete" "Write" "Action" --enabled false --days 0 --service-bus-rule-id
"/subscriptions/<YOUR SUBSCRIPTION ID>/resourceGroups/<RESOURCE GROUP
NAME>/providers/Microsoft.EventHub/namespaces/<EVENT HUB NAME
SPACE>/authorizationrules/RootManageSharedAccessKey"
name Yes Name of your log profile.
storage-account-id Yes Resource ID of the Storage Account

to which Activity Logs should be
saved.
locations Yes Space-separated list of regions for

which you would like to collect
Activity Log events. You can view a
list of all regions for your
subscription using
az account list-locations --
query [].name
.
days Yes Number of days for which events

should be retained, between 1 and
365. A value of zero will store the
logs indefinitely (forever). If zero,
then the enabled parameter should
be set to true.
enabled Yes True or False. Used to enable or

disable the retention policy. If True,
then the days parameter must be a
value greater than 0.
categories Yes Space-separated list of event

categories that should be collected.
Possible values are Write, Delete,
and Action.
Activity log schema

Whether sent to Azure storage or Event Hub, the Activity log data will be written to JSON with the following
format.
The format of Activity log data written to a storage account changed to JSON Lines on Nov. 1st, 2018. See
Prepare for format change to Azure Monitor diagnostic logs archived to a storage account for details on this
format change.
{
"records": [
{
"time": "2015-01-21T22:14:26.9792776Z",
"resourceId":
"/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841"
,
"operationName": "microsoft.support/supporttickets/write",
"category": "Write",
"resultSignature": "Succeeded.Created",
"durationMs": 2826,
"correlationId": "c776f9f4-36e5-4e0e-809b-c9b3c3fb62a8",
"identity": {
"authorization": {
"scope":
"/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841"
,
"action": "microsoft.support/supporttickets/write",
"evidence": {
"role": "Subscription Admin"
}
},
"claims": {
"aud": "https://management.core.windows.net/",
"iss": "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
"iat": "1421876371",
"nbf": "1421876371",
"exp": "1421880271",
"ver": "1.0",
"http://schemas.microsoft.com/identity/claims/tenantid": "1e8d8218-c5e7-4578-9acc-
9abbd5d23315 ",
"http://schemas.microsoft.com/claims/authnmethodsreferences": "pwd",
"http://schemas.microsoft.com/identity/claims/objectidentifier": "2468adf0-8211-44e3-
95xq-85137af64708",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "admin@contoso.com",
"puid": "20030000801A118C",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":
"9vckmEGF7zDKk1YzIY8k0t1_EAPaXoeHyPRn6f413zM",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "John",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Smith",
"name": "John Smith",
"groups": "cacfe77c-e058-4712-83qw-f9b08849fd60,7f71d11d-4c41-4b23-99d2-
d32ce7aa621c,31522864-0578-4ea0-9gdc-e66cc564d18c",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": " admin@contoso.com",
"appid": "c44b4083-3bq0-49c1-b47d-974e53cbdf3c",
"appidacr": "2",
"http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
"http://schemas.microsoft.com/claims/authnclassreference": "1"
}
},
"properties": {
"statusCode": "Created",
"serviceRequestId": "50d5cddb-8ca0-47ad-9b80-6cde2207f97c"
}
}
]
}
The elements in this JSON are described in the following table.

time Timestamp when the event was generated by the Azure

service processing the request corresponding the event.
resourceId Resource ID of the impacted resource.
category Category of the action, eg. Write, Read, Action.
resultType The type of the result, eg. Success, Failure, Start
resultSignature Depends on the resource type.
durationMs Duration of the operation in milliseconds
callerIpAddress IP address of the user who has performed the operation,

UPN claim, or SPN claim based on availability.
correlationId Usually a GUID in the string format. Events that share a

correlationId belong to the same uber action.
identity JSON blob describing the authorization and claims.
authorization Blob of RBAC properties of the event. Usually includes the

“action”, “role” and “scope” properties.
level Level of the event. One of the following values: Critical,

Error, Warning, Informational, and Verbose
location Region in which the location occurred (or global).
properties Set of <Key, Value> pairs (i.e. Dictionary) describing the

details of the event.
NOTE
The properties and usage of these properties can vary depending on the resource.
Next steps
Learn more about the Activity Log
Collect Activity Log into Azure Monitor Logs
Azure Activity Log event schema
The Azure Activity Log is a log that provides insight into any subscription-level events that have occurred in
Azure. This article describes the event schema per category of data. The schema of the data differs depending on if
you are reading the data in the portal, PowerShell, CLI, or directly via the REST API versus streaming the data to
storage or Event Hubs using a Log Profile. The examples below show the schema as made available via the portal,
PowerShell, CLI, and REST API. A mapping of those properties to the Azure diagnostic logs schema is provided at
the end of the article.
Administrative
This category contains the record of all create, update, delete, and action operations performed through Resource
Manager. Examples of the types of events you would see in this category include "create virtual machine" and
"delete network security group" Every action taken by a user or application using Resource Manager is modeled
as an operation on a particular resource type. If the operation type is Write, Delete, or Action, the records of both
the start and success or fail of that operation are recorded in the Administrative category. The Administrative
category also includes any changes to role-based access control in a subscription.
Sample event
{
"authorization": {
"action": "Microsoft.Network/networkSecurityGroups/write",
"scope": "/subscriptions/<subscription
ID>/resourcegroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNSG"
},
"caller": "rob@contoso.com",
"channels": "Operation",
"claims": {
"aud": "https://management.core.windows.net/",
"iss": "https://sts.windows.net/1114444b-7467-4144-a616-e3a5d63e147b/",
"iat": "1234567890",
"nbf": "1234567890",
"exp": "1234567890",
"_claim_names": "{\"groups\":\"src1\"}",
"_claim_sources": "{\"src1\":{\"endpoint\":\"https://graph.windows.net/1114444b-7467-4144-a616-
e3a5d63e147b/users/f409edeb-4d29-44b5-9763-ee9348ad91bb/getMemberObjects\"}}",
"http://schemas.microsoft.com/claims/authnclassreference": "1",
"aio": "A3GgTJdwK4vy7Fa7l6DgJC2mI0GX44tML385OpU1Q+z+jaPnFMwB",
"http://schemas.microsoft.com/claims/authnmethodsreferences": "rsa,mfa",
"appid": "355249ed-15d9-460d-8481-84026b065942",
"appidacr": "2",
"http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier": "10845a4d-ffa4-4b61-a3b4-
e57b9b31cdb5",
"e_exp": "262800",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Robertson",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "Rob",
"ipaddr": "111.111.1.111",
"name": "Rob Robertson",
"http://schemas.microsoft.com/identity/claims/objectidentifier": "f409edeb-4d29-44b5-9763-
ee9348ad91bb",
"onprem_sid": "S-1-5-21-4837261184-168309720-1886587427-18514304",
"puid": "18247BBD84827C6D",
"http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "b-24Jf94A3FH2sHWVIFqO3-
RSJEiv24Jnif3gj7s",
"http://schemas.microsoft.com/identity/claims/tenantid": "1114444b-7467-4144-a616-e3a5d63e147b",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "rob@contoso.com",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "rob@contoso.com",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "rob@contoso.com",
"uti": "IdP3SUJGtkGlt7dDQVRPAA",
"ver": "1.0"
},
"correlationId": "b5768deb-836b-41cc-803e-3f4de2f9e40b",
"eventDataId": "d0d36f97-b29c-4cd9-9d3d-ea2b92af3e9d",
"eventName": {
"value": "EndRequest",
"localizedValue": "End request"
},
"category": {
"value": "Administrative",
"localizedValue": "Administrative"
},
"eventTimestamp": "2018-01-29T20:42:31.3810679Z",
"id": "/subscriptions/<subscription
ID>/resourcegroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNSG/events/d0d36f97-
b29c-4cd9-9d3d-ea2b92af3e9d/ticks/636528553513810679",
"level": "Informational",
"operationId": "04e575f8-48d0-4c43-a8b3-78c4eb01d287",
"operationName": {
"value": "Microsoft.Network/networkSecurityGroups/write",
"localizedValue": "Microsoft.Network/networkSecurityGroups/write"
},
"resourceGroupName": "myResourceGroup",
"resourceProviderName": {
"value": "Microsoft.Network",
"localizedValue": "Microsoft.Network"
},
"resourceType": {
"value": "Microsoft.Network/networkSecurityGroups",
"localizedValue": "Microsoft.Network/networkSecurityGroups"
},
"resourceId": "/subscriptions/<subscription
ID>/resourcegroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNSG",
"status": {
"value": "Succeeded",
"localizedValue": "Succeeded"
},
"subStatus": {
"value": "",
"localizedValue": ""
},
"submissionTimestamp": "2018-01-29T20:42:50.0724829Z",
"subscriptionId": "<subscription ID>",
"properties": {
"statusCode": "Created",
"serviceRequestId": "a4c11dbd-697e-47c5-9663-12362307157d",
"responseBody": "",
"requestbody": ""
},
"relatedEvents": []
}
Property descriptions
authorization Blob of RBAC properties of the event. Usually includes the

“action”, “role” and “scope” properties.
caller Email address of the user who has performed the operation,
UPN claim, or SPN claim based on availability.
channels One of the following values: “Admin”, “Operation”
claims The JWT token used by Active Directory to authenticate the

user or application to perform this operation in Resource
Manager.

description Static text description of an event.
eventDataId Unique identifier of an event.
eventName Friendly name of the Administrative event.
category Always "Administrative"
httpRequest Blob describing the Http Request. Usually includes the

“clientRequestId”, “clientIpAddress” and “method” (HTTP
method. For example, PUT).
level Level of the event. One of the following values: “Critical”,

“Error”, “Warning”, and “Informational”
resourceGroupName Name of the resource group for the impacted resource.
resourceProviderName Name of the resource provider for the impacted resource
resourceType The type of resource that was affected by an Administrative

event.
operationId A GUID shared among the events that correspond to a single

operation.
properties Set of <Key, Value> pairs (that is, a Dictionary) describing

the details of the event.
status String describing the status of the operation. Some common

values are: Started, In Progress, Succeeded, Failed, Active,
Resolved.
subStatus Usually the HTTP status code of the corresponding REST call,
but can also include other strings describing a substatus, such
as these common values: OK (HTTP Status Code: 200),
Created (HTTP Status Code: 201), Accepted (HTTP Status
Code: 202), No Content (HTTP Status Code: 204), Bad
Request (HTTP Status Code: 400), Not Found (HTTP Status
Code: 404), Conflict (HTTP Status Code: 409), Internal Server
Error (HTTP Status Code: 500), Service Unavailable (HTTP
Status Code: 503), Gateway Timeout (HTTP Status Code: 504).
eventTimestamp Timestamp when the event was generated by the Azure

submissionTimestamp Timestamp when the event became available for querying.
subscriptionId Azure Subscription ID.
Service health
This category contains the record of any service health incidents that have occurred in Azure. An example of the
type of event you would see in this category is "SQL Azure in East US is experiencing downtime." Service health
events come in five varieties: Action Required, Assisted Recovery, Incident, Maintenance, Information, or Security,
and only appear if you have a resource in the subscription that would be impacted by the event.
Sample event
{
"channels": "Admin",
"correlationId": "c550176b-8f52-4380-bdc5-36c1b59d3a44",
"description": "Active: Network Infrastructure - UK South",
"eventDataId": "c5bc4514-6642-2be3-453e-c6a67841b073",
"eventName": {
"value": null
},
"category": {
"value": "ServiceHealth",
"localizedValue": "Service Health"
},
"id": "/subscriptions/<subscription ID>/events/c5bc4514-6642-2be3-453e-
c6a67841b073/ticks/636361902148022297",
"level": "Warning",
"operationName": {
"value": "Microsoft.ServiceHealth/incident/action",
"localizedValue": "Microsoft.ServiceHealth/incident/action"
},
"value": null
},
"resourceType": {
"value": null,
},
"resourceId": "/subscriptions/<subscription ID>",
"status": {
"value": "Active",
"localizedValue": "Active"
},
"subStatus": {
"value": null
},
"properties": {
"title": "Network Infrastructure - UK South",
"service": "Service Fabric",
"region": "UK South",
"communication": "Starting at approximately 21:41 UTC on 20 Jul 2017, a subset of customers in UK South
may experience degraded performance, connectivity drops or timeouts when accessing their Azure resources
hosted in this region. Engineers are investigating underlying Network Infrastructure issues in this region.
Impacted services may include, but are not limited to App Services, Automation, Service Bus, Log Analytics,
Key Vault, SQL Database, Service Fabric, Event Hubs, Stream Analytics, Azure Data Movement, API Management,
and Azure Search. Multiple engineering teams are engaged in multiple workflows to mitigate the impact. The
next update will be provided in 60 minutes, or as events warrant.",
"incidentType": "Incident",
"trackingId": "NA0F-BJG",
"impactStartTime": "2017-07-20T21:41:00.0000000Z",
"impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"UK South\"}],\"ServiceName\":\"Service
Fabric\"}]",
"defaultLanguageTitle": "Network Infrastructure - UK South",
"defaultLanguageContent": "Starting at approximately 21:41 UTC on 20 Jul 2017, a subset of customers in UK
South may experience degraded performance, connectivity drops or timeouts when accessing their Azure resources
hosted in this region. Engineers are investigating underlying Network Infrastructure issues in this region.
Impacted services may include, but are not limited to App Services, Automation, Service Bus, Log Analytics,
Key Vault, SQL Database, Service Fabric, Event Hubs, Stream Analytics, Azure Data Movement, API Management,
and Azure Search. Multiple engineering teams are engaged in multiple workflows to mitigate the impact. The
next update will be provided in 60 minutes, or as events warrant.",
"stage": "Active",
"communicationId": "636361902146035247",
"version": "0.1.1"
}
}
Refer to the service health notifications article for documentation about the values in the properties.
Resource health
This category contains the record of any resource health events that have occurred to your Azure resources. An
example of the type of event you would see in this category is "Virtual Machine health status changed to
unavailable." Resource health events can represent one of four health statuses: Available, Unavailable, Degraded,
and Unknown. Additionally, resource health events can be categorized as being Platform Initiated or User
Initiated.
Sample event
{
"channels": "Admin, Operation",
"correlationId": "28f1bfae-56d3-7urb-bff4-194d261248e9",
"description": "",
"eventDataId": "a80024e1-883d-37ur-8b01-7591a1befccb",
"eventName": {
"value": "",
},
"category": {
"value": "ResourceHealth",
"localizedValue": "Resource Health"
},
"id": "/subscriptions/<subscription ID>/resourceGroups/<resource
group>/providers/Microsoft.Compute/virtualMachines/<resource name>/events/a80024e1-883d-42a5-8b01-
7591a1befccb/ticks/636716720236500000",
"level": "Critical",
"operationId": "",
"operationName": {
"value": "Microsoft.Resourcehealth/healthevent/Activated/action",
"localizedValue": "Health Event Activated"
},
"resourceGroupName": "<resource group>",
"value": "Microsoft.Resourcehealth/healthevent/action",
"localizedValue": "Microsoft.Resourcehealth/healthevent/action"
},
"resourceType": {
"value": "Microsoft.Compute/virtualMachines",
"localizedValue": "Microsoft.Compute/virtualMachines"
},
"resourceId": "/subscriptions/<subscription ID>/resourceGroups/<resource
group>/providers/Microsoft.Compute/virtualMachines/<resource name>",
"status": {
"value": "Active",
},
"subStatus": {
"value": "",
},
"properties": {
"stage": "Active",
"title": "Virtual Machine health status changed to unavailable",
"details": "Virtual machine has experienced an unexpected event",
"healthStatus": "Unavailable",
"healthEventType": "Downtime",
"healthEventCause": "PlatformInitiated",
"healthEventCategory": "Unplanned"
},
"relatedEvents": []
}
channels Always “Admin, Operation”
correlationId A GUID in the string format.

description Static text description of the alert event.
eventDataId Unique identifier of the alert event.
category Always "ResourceHealth"


“Error”, “Warning”, “Informational”, and “Verbose”

operation.
resourceGroupName Name of the resource group that contains the resource.
resourceProviderName Always "Microsoft.Resourcehealth/healthevent/action".
resourceType The type of resource that was affected by a Resource Health

event.
resourceId Name of the resource ID for the impacted resource.
status String describing the status of the health event. Values can be:
Active, Resolved, InProgress, Updated.
subStatus Usually null for alerts.

properties.title A user-friendly string that describes the health status of the

resource.
properties.details A user-friendly string that describes further details about the

event.
properties.currentHealthStatus The current health status of the resource. One of the

following values: "Available", "Unavailable", "Degraded", and
"Unknown".
properties.previousHealthStatus The previous health status of the resource. One of the

following values: "Available", "Unavailable", "Degraded", and
"Unknown".
properties.type A description of the type of resource health event.
properties.cause A description of the cause of the resource health event. Either

"UserInitiated" and "PlatformInitiated".
Alert
This category contains the record of all activations of Azure alerts. An example of the type of event you would see
in this category is "CPU % on myVM has been over 80 for the past 5 minutes." A variety of Azure systems have an
alerting concept -- you can define a rule of some sort and receive a notification when conditions match that rule.
Each time a supported Azure alert type 'activates,' or the conditions are met to generate a notification, a record of
the activation is also pushed to this category of the Activity Log.
Sample event
{
"caller": "Microsoft.Insights/alertRules",
"claims": {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/alertRules"
},
"correlationId": "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/microsoft.insights/alertrules/myalert/incidents/L3N1YnNjcmlwdGlvb
nMvZGY2MDJjOWMtN2FhMC00MDdkLWE2ZmItZWIyMGM4YmQxMTkyL3Jlc291cmNlR3JvdXBzL0NzbUV2ZW50RE9HRk9PRC1XZXN0VVMvcHJvdml
kZXJzL21pY3Jvc29mdC5pbnNpZ2h0cy9hbGVydHJ1bGVzL215YWxlcnQwNjM2MzYyMjU4NTM1MjIxOTIw",
"description": "'Disk read LessThan 100000 ([Count]) in the last 5 minutes' has been resolved for
CloudService: myResourceGroup/Production/Event.BackgroundJobsWorker.razzle (myResourceGroup)",
"eventDataId": "149d4baf-53dc-4cf4-9e29-17de37405cd9",
"eventName": {
"value": "Alert",
"localizedValue": "Alert"
},
"category": {
"value": "Alert",
"localizedValue": "Alert"
},
ID>/resourceGroups/myResourceGroup/providers/Microsoft.ClassicCompute/domainNames/myResourceGroup/slots/Produc
tion/roles/Event.BackgroundJobsWorker.razzle/events/149d4baf-53dc-4cf4-9e29-
17de37405cd9/ticks/636362258535221920",
"value": "Microsoft.ClassicCompute",
"localizedValue": "Microsoft.ClassicCompute"
},
tion/roles/Event.BackgroundJobsWorker.razzle",
"resourceType": {
"value": "Microsoft.ClassicCompute/domainNames/slots/roles",
"localizedValue": "Microsoft.ClassicCompute/domainNames/slots/roles"
},
"operationId": "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/microsoft.insights/alertrules/myalert/incidents/L3N1YnNjcmlwdGlvb
nMvZGY2MDJjOWMtN2FhMC00MDdkLWE2ZmItZWIyMGM4YmQxMTkyL3Jlc291cmNlR3JvdXBzL0NzbUV2ZW50RE9HRk9PRC1XZXN0VVMvcHJvdml
kZXJzL21pY3Jvc29mdC5pbnNpZ2h0cy9hbGVydHJ1bGVzL215YWxlcnQwNjM2MzYyMjU4NTM1MjIxOTIw",
"operationName": {
"value": "Microsoft.Insights/AlertRules/Resolved/Action",
"localizedValue": "Microsoft.Insights/AlertRules/Resolved/Action"
},
"properties": {
"properties": {
"RuleUri": "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/microsoft.insights/alertrules/myalert",
"RuleName": "myalert",
"RuleDescription": "",
"Threshold": "100000",
"WindowSizeInMinutes": "5",
"Aggregation": "Average",
"Operator": "LessThan",
"MetricName": "Disk read",
"MetricUnit": "Count"
},
"status": {
"value": "Resolved",
"localizedValue": "Resolved"
},
"subStatus": {
"value": null
},
"subscriptionId": "<subscription ID>"
}
caller Always Microsoft.Insights/alertRules
claims JSON blob with the SPN (service principal name), or resource
type, of the alert engine.
description Static text description of the alert event.
eventDataId Unique identifier of the alert event.
category Always "Alert"

resourceGroupName Name of the resource group for the impacted resource if it is

a metric alert. For other alert types, it is the name of the
resource group that contains the alert itself.
resourceProviderName Name of the resource provider for the impacted resource if it

is a metric alert. For other alert types, it is the name of the
resource provider for the alert itself.
resourceId Name of the resource ID for the impacted resource if it is a

metric alert. For other alert types, it is the resource ID of the
alert resource itself.

operation.


Resolved.
subStatus Usually null for alerts.

Properties field per alert type

The properties field will contain different values depending on the source of the alert event. Two common alert
event providers are Activity Log alerts and metric alerts.
Properties for Activity Log alerts
properties.subscriptionId The subscription ID from the activity log event which caused
this activity log alert rule to be activated.
properties.eventDataId The event data ID from the activity log event which caused
properties.resourceGroup The resource group from the activity log event which caused
properties.resourceId The resource ID from the activity log event which caused this
activity log alert rule to be activated.
properties.eventTimestamp The event timestamp of the activity log event which caused
properties.operationName The operation name from the activity log event which caused
properties.status The status from the activity log event which caused this
activity log alert rule to be activated.
Properties for metric alerts

properties.RuleUri Resource ID of the metric alert rule itself.
properties.RuleName The name of the metric alert rule.
properties.RuleDescription The description of the metric alert rule (as defined in the alert
rule).
properties.Threshold The threshold value used in the evaluation of the metric alert
rule.
properties.WindowSizeInMinutes The window size used in the evaluation of the metric alert
rule.
properties.Aggregation The aggregation type defined in the metric alert rule.
properties.Operator The conditional operator used in the evaluation of the metric

alert rule.
properties.MetricName The metric name of the metric used in the evaluation of the
metric alert rule.
properties.MetricUnit The metric unit for the metric used in the evaluation of the
metric alert rule.
Autoscale
This category contains the record of any events related to the operation of the autoscale engine based on any
autoscale settings you have defined in your subscription. An example of the type of event you would see in this
category is "Autoscale scale up action failed." Using autoscale, you can automatically scale out or scale in the
number of instances in a supported resource type based on time of day and/or load (metric) data using an
autoscale setting. When the conditions are met to scale up or down, the start and succeeded or failed events will
be recorded in this category.
Sample event
{
"caller": "Microsoft.Insights/autoscaleSettings",
"claims": {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/autoscaleSettings"
},
"correlationId": "fc6a7ff5-ff68-4bb7-81b4-3629212d03d0",
"description": "The autoscale engine attempting to scale resource '/subscriptions/<subscription
tion/roles/myResource' from 3 instances count to 2 instances count.",
"eventDataId": "a5b92075-1de9-42f1-b52e-6f3e4945a7c7",
"eventName": {
"value": "AutoscaleAction",
"localizedValue": "AutoscaleAction"
},
"category": {
"value": "Autoscale",
"localizedValue": "Autoscale"
},
ID>/resourceGroups/myResourceGroup/providers/microsoft.insights/autoscalesettings/myResourceGroup-Production-
myResource-myResourceGroup/events/a5b92075-1de9-42f1-b52e-6f3e4945a7c7/ticks/636361956518681572",
"value": "microsoft.insights",
"localizedValue": "microsoft.insights"
},
ID>/resourceGroups/myResourceGroup/providers/microsoft.insights/autoscalesettings/myResourceGroup-Production-
myResource-myResourceGroup",
"resourceType": {
"value": "microsoft.insights/autoscalesettings",
"localizedValue": "microsoft.insights/autoscalesettings"
},
"operationId": "fc6a7ff5-ff68-4bb7-81b4-3629212d03d0",
"operationName": {
"value": "Microsoft.Insights/AutoscaleSettings/Scaledown/Action",
"localizedValue": "Microsoft.Insights/AutoscaleSettings/Scaledown/Action"
},
"properties": {
"Description": "The autoscale engine attempting to scale resource '/subscriptions/<subscription
tion/roles/myResource' from 3 instances count to 2 instances count.",
"ResourceName": "/subscriptions/<subscription
tion/roles/myResource",
"OldInstancesCount": "3",
"NewInstancesCount": "2",
"LastScaleActionTime": "Fri, 21 Jul 2017 01:00:51 GMT"
},
"status": {
},
"subStatus": {
"value": null
},
"subscriptionId": "<subscription ID>"
}
caller Always Microsoft.Insights/autoscaleSettings
claims JSON blob with the SPN (service principal name), or resource
type, of the autoscale engine.
description Static text description of the autoscale event.
eventDataId Unique identifier of the autoscale event.

resourceGroupName Name of the resource group for the autoscale setting.
resourceProviderName Name of the resource provider for the autoscale setting.
resourceId Resource ID of the autoscale setting.

operation.

properties.Description Detailed description of what the autoscale engine was doing.
properties.ResourceName Resource ID of the impacted resource (the resource on which

the scale action was being performed)
properties.OldInstancesCount The number of instances before the autoscale action took

effect.
properties.NewInstancesCount The number of instances after the autoscale action took effect.
properties.LastScaleActionTime The timestamp of when the autoscale action occurred.

Resolved.
subStatus Usually null for autoscale.


Security
This category contains the record any alerts generated by Azure Security Center. An example of the type of event
you would see in this category is "Suspicious double extension file executed."
Sample event
{
"correlationId": "965d6c6a-a790-4a7e-8e9a-41771b3fbc38",
"description": "Suspicious double extension file executed. Machine logs indicate an execution of a process
with a suspicious double extension.\r\nThis extension may trick users into thinking files are safe to be
opened and might indicate the presence of malware on the system.",
"eventDataId": "965d6c6a-a790-4a7e-8e9a-41771b3fbc38",
"eventName": {
"value": "Suspicious double extension file executed",
"localizedValue": "Suspicious double extension file executed"
},
"category": {
"value": "Security",
"localizedValue": "Security"
},
"id": "/subscriptions/<subscription ID>/providers/Microsoft.Security/locations/centralus/alerts/965d6c6a-
a790-4a7e-8e9a-41771b3fbc38/events/965d6c6a-a790-4a7e-8e9a-41771b3fbc38/ticks/636439033386179339",
"operationId": "965d6c6a-a790-4a7e-8e9a-41771b3fbc38",
"operationName": {
"value": "Microsoft.Security/locations/alerts/activate/action",
"localizedValue": "Microsoft.Security/locations/alerts/activate/action"
},
"value": "Microsoft.Security",
"localizedValue": "Microsoft.Security"
},
"resourceType": {
"value": "Microsoft.Security/locations/alerts",
"localizedValue": "Microsoft.Security/locations/alerts"
},
ID>/providers/Microsoft.Security/locations/centralus/alerts/2518939942613820660_a48f8653-3fc6-4166-9f19-
914f030a13d3",
"status": {
"value": "Active",
},
"subStatus": {
"value": null
},
"properties": {
"accountLogonId": "0x2r4",
"commandLine": "c:\\mydirectory\\doubleetension.pdf.exe",
"domainName": "hpc",
"parentProcess": "unknown",
"parentProcess id": "0",
"processId": "6988",
"processName": "c:\\mydirectory\\doubleetension.pdf.exe",
"userName": "myUser",
"UserSID": "S-3-2-12",
"ActionTaken": "Detected",
"Severity": "High"
},
"relatedEvents": []
}
channels Always “Operation”
description Static text description of the security event.
eventDataId Unique identifier of the security event.
eventName Friendly name of the security event.
category Always "Security"
id Unique resource identifier of the security event.

“Error”, “Warning”, or “Informational”
resourceGroupName Name of the resource group for the resource.
resourceProviderName Name of the resource provider for Azure Security Center.

Always "Microsoft.Security".
resourceType The type of resource that generated the security event, such
as "Microsoft.Security/locations/alerts"
resourceId Resource ID of the security alert.

operation.

the details of the event. These properties will vary depending
on the type of security alert. See this page for a description of
the types of alerts that come from Security Center.
properties.Severity The severity level. Possible values are "High," "Medium," or

"Low."

Resolved.
subStatus Usually null for security events.


Recommendation
This category contains the record of any new recommendations that are generated for your services. An example
of a recommendation would be "Use availability sets for improved fault tolerance." There are four types of
Recommendation events that can be generated: High Availability, Performance, Security, and Cost Optimization.
Sample event
{
"correlationId": "92481dfd-c5bf-4752-b0d6-0ecddaa64776",
"description": "The action was successful.",
"eventDataId": "06cb0e44-111b-47c7-a4f2-aa3ee320c9c5",
"eventName": {
"value": "",
},
"category": {
"value": "Recommendation",
"localizedValue": "Recommendation"
},
"id": "/SUBSCRIPTIONS/<Subscription
ID>/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/MYVM/events/06cb0e44-111b-47c7-
a4f2-aa3ee320c9c5/ticks/636640038429769190",
"operationId": "",
"operationName": {
"value": "Microsoft.Advisor/generateRecommendations/action",
"localizedValue": "Microsoft.Advisor/generateRecommendations/action"
},
"resourceGroupName": "MYRESOURCEGROUP",
"value": "MICROSOFT.COMPUTE",
"localizedValue": "MICROSOFT.COMPUTE"
},
"resourceType": {
"value": "MICROSOFT.COMPUTE/virtualmachines",
"localizedValue": "MICROSOFT.COMPUTE/virtualmachines"
},
"resourceId": "/SUBSCRIPTIONS/<Subscription
ID>/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/MYVM",
"status": {
"value": "Active",
},
"subStatus": {
"value": "",
},
"subscriptionId": "<Subscription ID>",
"properties": {
"recommendationSchemaVersion": "1.0",
"recommendationCategory": "Security",
"recommendationImpact": "High",
"recommendationRisk": "None"
},
"relatedEvents": []
}
channels Always “Operation”
description Static text description of the recommendation event
eventDataId Unique identifier of the recommendation event.
category Always "Recommendation"
id Unique resource identifier of the recommendation event.

“Error”, “Warning”, or “Informational”
operationName Name of the operation. Always

"Microsoft.Advisor/generateRecommendations/action"
resourceGroupName Name of the resource group for the resource.
resourceProviderName Name of the resource provider for the resource that this
recommendation applies to, such as "MICROSOFT.COMPUTE"
resourceType Name of the resource type for the resource that this
recommendation applies to, such as
"MICROSOFT.COMPUTE/virtualmachines"
resourceId Resource ID of the resource that the recommendation applies

to
status Always "Active"

the details of the recommendation.
properties.recommendationSchemaVersion Schema version of the recommendation properties published

in the Activity Log entry
properties.recommendationCategory Category of the recommendation. Possible values are "High

Availability", "Performance", "Security", and "Cost"
properties.recommendationImpact Impact of the recommendation. Possible values are "High",

"Medium", "Low"
properties.recommendationRisk Risk of the recommendation. Possible values are "Error",

"Warning", "None"
Policy
This category contains records of all effect action operations performed by Azure Policy. Examples of the types of
events you would see in this category include Audit and Deny. Every action taken by Policy is modeled as an
operation on a resource.
Sample Policy event
{
"authorization": {
"action": "Microsoft.Resources/checkPolicyCompliance/read",
"scope": "/subscriptions/<subscriptionID>"
},
"caller": "33a68b9d-63ce-484c-a97e-94aef4c89648",
"claims": {
"aud": "https://management.azure.com/",
"iss": "https://sts.windows.net/1114444b-7467-4144-a616-e3a5d63e147b/",
"iat": "1234567890",
"nbf": "1234567890",
"exp": "1234567890",
"aio": "A3GgTJdwK4vy7Fa7l6DgJC2mI0GX44tML385OpU1Q+z+jaPnFMwB",
"appid": "1d78a85d-813d-46f0-b496-dd72f50a3ec0",
"appidacr": "2",
"http://schemas.microsoft.com/identity/claims/identityprovider": "https://sts.windows.net/1114444b-
7467-4144-a616-e3a5d63e147b/",
"http://schemas.microsoft.com/identity/claims/objectidentifier": "f409edeb-4d29-44b5-9763-
ee9348ad91bb",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "b-24Jf94A3FH2sHWVIFqO3-
RSJEiv24Jnif3gj7s",
"http://schemas.microsoft.com/identity/claims/tenantid": "1114444b-7467-4144-a616-e3a5d63e147b",
"uti": "IdP3SUJGtkGlt7dDQVRPAA",
"ver": "1.0"
},
"correlationId": "b5768deb-836b-41cc-803e-3f4de2f9e40b",
"description": "",
"eventDataId": "d0d36f97-b29c-4cd9-9d3d-ea2b92af3e9d",
"eventName": {
"value": "EndRequest",
"localizedValue": "End request"
},
"category": {
"value": "Policy",
"localizedValue": "Policy"
},
"id":
"/subscriptions/<subscriptionID>/resourceGroups/myResourceGroup/providers/Microsoft.Sql/servers/contososqlpoli
cy/events/13bbf75f-36d5-4e66-b693-725267ff21ce/ticks/636831551961227642",
"level": "Warning",
"operationId": "04e575f8-48d0-4c43-a8b3-78c4eb01d287",
"operationName": {
"value": "Microsoft.Authorization/policies/audit/action",
"localizedValue": "Microsoft.Authorization/policies/audit/action"
},
"value": "Microsoft.Sql",
"localizedValue": "Microsoft SQL"
},
"resourceType": {
"value": "Microsoft.Resources/checkPolicyCompliance",
"localizedValue": "Microsoft.Resources/checkPolicyCompliance"
},
"resourceId":
"/subscriptions/<subscriptionID>/resourceGroups/myResourceGroup/providers/Microsoft.Sql/servers/contososqlpoli
cy",
"status": {
},
"subStatus": {
"value": "",
},
"subscriptionId": "<subscriptionID>",
"properties": {
"isComplianceCheck": "True",
"resourceLocation": "westus2",
"ancestors": "72f988bf-86f1-41af-91ab-2d7cd011db47",
"policies": "[{\"policyDefinitionId\":\"/subscriptions/<subscriptionID>/providers/Microsoft.
Authorization/policyDefinitions/5775cdd5-d3d3-47bf-bc55-bb8b61746506/\",\"policyDefiniti
onName\":\"5775cdd5-d3d3-47bf-bc55-bb8b61746506\",\"policyDefinitionEffect\":\"Deny\",\"
policyAssignmentId\":\"/subscriptions/<subscriptionID>/providers/Microsoft.Authorization
/policyAssignments/991a69402a6c484cb0f9b673/\",\"policyAssignmentName\":\"991a69402a6c48
4cb0f9b673\",\"policyAssignmentScope\":\"/subscriptions/<subscriptionID>\",\"policyAssig
nmentParameters\":{}}]"
},
"relatedEvents": []
}
Policy event property descriptions

authorization Array of RBAC properties of the event. For new resources, this
is the action and scope of the request that triggered
evaluation. For existing resources, the action is
"Microsoft.Resources/checkPolicyCompliance/read".
caller For new resources, the identity that initiated a deployment.

For existing resources, the GUID of the Microsoft Azure Policy
Insights RP.
channels Policy events use only the "Operation" channel.
claims The JWT token used by Active Directory to authenticate the

user or application to perform this operation in Resource
Manager.

description This field is blank for Policy events.
eventDataId Unique identifier of an event.
eventName Either "BeginRequest" or "EndRequest". "BeginRequest" is

used for delayed auditIfNotExists and deployIfNotExists
evaluations and when a deployIfNotExists effect starts a
template deployment. All other operations return
"EndRequest".
category Declares the activity log event as belonging to "Policy".

id Unique identifier of the event on the specific resource.
level Level of the event. Audit uses "Warning" and Deny uses
"Error". An auditIfNotExists or deployIfNotExists error can
generate "Warning" or "Error" depending on severity. All other
Policy events use "Informational".

operation.
operationName Name of the operation and directly correlates to the Policy

effect.
resourceGroupName Name of the resource group for the evaluated resource.
resourceProviderName Name of the resource provider for the evaluated resource.
resourceType For new resources, it is the type being evaluated. For existing
resources, returns
"Microsoft.Resources/checkPolicyCompliance".
resourceId Resource ID of the evaluated resource.
status String describing the status of the Policy evaluation result.

Most Policy evaluations return "Succeeded", but a Deny effect
returns "Failed". Errors in auditIfNotExists or deployIfNotExists
also return "Failed".
subStatus Field is blank for Policy events.
properties.isComplianceCheck Returns "False" when a new resource is deployed or an

existing resource's Resource Manager properties are updated.
All other evaluation triggers result in "True".
properties.resourceLocation The Azure region of the resource being evaluated.
properties.ancestors A comma-separated list of parent management groups

ordered from direct parent to farthest grandparent.
properties.policies Includes details about the policy definition, assignment, effect,

and parameters that this Policy evaluation is a result of.
relatedEvents This field is blank for Policy events.
Mapping to diagnostic logs schema

When streaming the Azure Activity Log to a storage account or Event Hubs namespace, the data follows the Azure
diagnostic logs schema. Here is the mapping of properties from the schema above to the diagnostic logs schema:
ACTIVITY LOG REST API SCHEMA
DIAGNOSTIC LOGS SCHEMA PROPERTY PROPERTY NOTES
time eventTimestamp
resourceId resourceId subscriptionId, resourceType,

resourceGroupName are all inferred
from the resourceId.
operationName operationName.value
category Part of operation name Breakout of the operation type -

"Write"/"Delete"/"Action"
resultType status.value
resultSignature substatus.value
resultDescription description
durationMs N/A Always 0
callerIpAddress httpRequest.clientIpAddress
correlationId correlationId
identity claims and authorization properties
Level Level
location N/A Location of where the event was

processed. This is not the location of
the resource, but rather where the
event was processed. This property will
be removed in a future update.
Properties properties.eventProperties
properties.eventCategory category If properties.eventCategory is not

present, category is "Administrative"
properties.eventName eventName
properties.operationId operationId
properties.eventProperties properties
Next steps
Learn more about the Activity Log
Export the Activity Log to Azure Storage or Event Hubs
Create diagnostic setting to collect platform logs
and metrics in Azure
Platform logs in Azure provide detailed diagnostic and auditing information for Azure resources and the Azure
platform they depend on. This article provides details on creating and configuring diagnostic settings to collect
platform logs to different destinations.
Each Azure resource requires its own diagnostic setting. The diagnostic setting defines the following for that
resource:
Categories of logs and metric data sent to the destinations defined in the setting. The available categories
will vary for different resource types.
One or more destinations to send the logs. Current destinations include Log Analytics workspace, Event
Hubs, and Azure Storage.
Retention policy for data stored in Azure Storage.
A single diagnostic setting can define one of each of the destinations. If you want to send data to more than one
of a particular destination type (for example, two different Log Analytics workspaces), then create multiple
settings. Each resource can have up to 5 diagnostic settings.
NOTE
The Activity log can be forwarded to the same destinations as the other platform logs, but is not configured with
diagnostic settings. See Overview of Platform logs in Azure for details.
NOTE
Platform metrics are collected automatically to Azure Monitor Metrics. Diagnostic settings can be used to collect metrics
for certain Azure services into Azure Monitor Logs for analysis with other monitoring data using log queries.
Destinations
Platform logs can be sent to the destinations in the following table. The configuration for each destination is
performed using the same process for creating diagnostic settings described in this article. Follow each link in
the following table for details on sending data to that destination.
DESTINATION DESCRIPTION
Log Analytics workspace Collecting logs into a Log Analytics workspace allows you to
analyze them with other monitoring data collected by Azure
Monitor using powerful log queries and also to leverage
other Azure Monitor features such as alerts and
visualizations.
Event hubs Sending logs to Event Hubs allows you to stream data to
external systems such as third-party SIEMs and other log
analytics solutions.
DESTINATION DESCRIPTION
Azure storage account Archiving logs to an Azure storage account is useful for
audit, static analysis, or backup.
Create diagnostic settings in Azure portal

You can configure diagnostic settings in the Azure portal either from the Azure Monitor menu or from the
menu for the resource.
1. From the Azure Monitor menu in the Azure portal, click Diagnostic settings under Settings and then
click on the resource.
Or from the resource menu in the Azure portal, click Diagnostic settings under Monitor.
2. 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. Either click
Add diagnostic setting to add a new setting or Edit setting to edit an existing one. Each setting can
have no more than one of each of the destination types.
3. Give your setting a name if it doesn't already have one.

4. Check the box for each destination to send the logs. Click Configure to specify their settings as
described in the following table.
SETTING DESCRIPTION
Log Analytics workspace Name of workspace.
Storage account Name of storage account.
Event hub namespace The namespace where the event hub is created (if this is
your first time streaming logs) or streamed to (if there
are already resources that are streaming that log
category to this namespace).
Event hub name Optionally specify an event hub name to send all data in
the setting. If you don't specify a name, an event hub is
created for each log category. If you are sending
multiple categories, you may want to specify a name to
limit the number of event hubs created. See Azure Event
Hubs quotas and limits for details.
Event hub policy name Defines the permissions that the streaming mechanism
has.
5. Check the box for each of the categories of data to send to the specified destinations. If you selected the
option to Archive to a storage account, then you will also need to specify the retention period.
NOTE
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.
4. Click Save.
After a few moments, the new setting appears in your list of settings for this resource, and logs are streamed to
the specified destinations as new event data is generated. Note that there may be up to fifteen minutes between
when an event is emitted and when it appears in a Log Analytics workspace.
Create diagnostic settings using PowerShell

Use the Set-AzDiagnosticSetting cmdlet to create a diagnostic setting with Azure PowerShell. See the
documentation for this cmdlet for descriptions of its parameters.
Following is an example PowerShell cmdlet to create a diagnostic setting using all three destinations.
Set-AzDiagnosticSetting -Name KeyVault-Diagnostics -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-

xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault -Category
AuditEvent -MetricCategory AllMetrics -Enabled $true -StorageAccountId /subscriptions/xxxxxxxx-xxxx-xxxx-
xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount -
RetentionEnabled $true -RetentionInDays 7 -WorkspaceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcegroups/oi-default-east-
us/providers/microsoft.operationalinsights/workspaces/myworkspace -EventHubAuthorizationRuleId
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub/authorizatio
nrules/RootManageSharedAccessKey
Create diagnostic settings using Azure CLI

Use the az monitor diagnostic-settings create command to create a diagnostic setting with Azure CLI. See the
documentation for this command for descriptions of its parameters.
Following is an example CLI command to create a diagnostic setting using all three destinations.
az monitor diagnostic-settings create \

--name KeyVault-Diagnostics \
--resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault \
--logs '[{"category": "AuditEvent","enabled": true,"retentionPolicy": {"days": 7,"enabled": true}}]' \
--metrics '[{"category": "AllMetrics","enabled": true,"retentionPolicy": {"days": 7,"enabled": true}}]' \
--storage-account /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount \
--workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/oi-default-east-
us/providers/microsoft.operationalinsights/workspaces/myworkspace \
--event-hub-rule /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub/authorizatio
nrules/RootManageSharedAccessKey
Configure diagnostic settings using REST API

See Diagnostic Settings to create or update diagnostic settings using the Azure Monitor REST API.
Configure diagnostic settings using Resource Manager template
See Automatically enable Diagnostic Settings at resource creation using a Resource Manager template to
create or update diagnostic settings with a Resource Manager template.
Next steps
Read more about Azure platform Logs
Create diagnostic setting in Azure using a Resource
Manager template
Platform logs in Azure provide detailed diagnostic and auditing information for Azure resources and the Azure
platform they depend on. This article provides details on using an Azure Resource Manager template to configure
diagnostic settings to collect platform logs to different destinations. This enables you to automatically start
collecting platform logs when a resource is created.
Resource Manager template

There are two sections of the Resource Manager template that you need to edit to create diagnostic settings. These
sections are described in the following sections.
Parameters
Depending on the destinations for the diagnostic setting, add parameters to the parameters blob for the storage
account name, event hub authorization rule ID, and Log Analytics workspace ID.
"settingName": {
"type": "string",
"metadata": {
"description": "Name for the diagnostic setting resource. Eg. 'archiveToStorage' or 'forSecurityTeam'."
}
},
"storageAccountName": {
"type": "string",
"metadata": {
"description": "Name of the Storage Account in which platform logs should be saved."
}
},
"eventHubAuthorizationRuleId": {
"type": "string",
"metadata": {
"description": "Resource ID of the event hub authorization rule for the Event Hubs namespace in which the
event hub should be created or streamed to."
}
},
"eventHubName": {
"type": "string",
"metadata": {
"description": "Optional. Name of the event hub within the namespace to which logs are streamed. Without
this, an event hub is created for each log category."
}
},
"workspaceId":{
"type": "string",
"metadata": {
"description": "Azure Resource ID of the Log Analytics workspace for the Log Analytics workspace to which
logs will be sent."
}
}
Resources
In the resources array of the resource for which you want to create the diagnostic setting, add a resource of type
[resource namespace]/providers/diagnosticSettings . The properties section follows the format described in
Diagnostic Settings - Create Or Update. Add the metrics property to collect resource metrics to the same
destinations if the resource supports metrics.
"resources": [
{
"type": "providers/diagnosticSettings",
"name": "[concat('Microsoft.Insights/', parameters('settingName'))]",
"dependsOn": [
"[/*resource Id for which resource logs will be enabled>*/]"
],
"properties": {
"name": "[parameters('settingName')]",
"storageAccountId": "[resourceId('Microsoft.Storage/storageAccounts',
parameters('storageAccountName'))]",
"eventHubAuthorizationRuleId": "[parameters('eventHubAuthorizationRuleId')]",
"eventHubName": "[parameters('eventHubName')]",
"workspaceId": "[parameters('workspaceId')]",
"logs": [
{
"category": "/* log category name */",
"enabled": true,
"retentionPolicy": {
"days": 0,
"enabled": false
}
}
],
"metrics": [
{
"category": "AllMetrics",
"enabled": true,
"enabled": false,
"days": 0
}
}
]
}
}
]
Example
Following is a complete example that creates a Logic App and creates a diagnostic setting that enables streaming
of resource logs to an event hub and storage in a storage account.
{
"parameters": {
"logicAppName": {
"type": "string",
"metadata": {
"description": "Name of the Logic App that will be created."
}
},
"testUri": {
"type": "string",
"defaultValue": "https://azure.microsoft.com/status/feed/"
},
"settingName": {
"type": "string",
"metadata": {
"description": "Name of the setting. Name for the diagnostic setting resource. Eg. 'archiveToStorage'
"description": "Name of the setting. Name for the diagnostic setting resource. Eg. 'archiveToStorage'
or 'forSecurityTeam'."
}
},
"storageAccountName": {
"type": "string",
"metadata": {
"description": "Name of the Storage Account in which resource logs should be saved."
}
},
"eventHubAuthorizationRuleId": {
"type": "string",
"metadata": {
"description": "Resource ID of the event hub authorization rule for the Event Hubs namespace in which
the event hub should be created or streamed to."
}
},
"eventHubName": {
"type": "string",
"metadata": {
"description": "Optional. Name of the event hub within the namespace to which logs are streamed.
Without this, an event hub is created for each log category."
}
},
"workspaceId": {
"type": "string",
"metadata": {
"description": "Log Analytics workspace ID for the Log Analytics workspace to which logs will be
sent."
}
}
},
"variables": {},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"name": "[parameters('logicAppName')]",
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/schemas/2016-06-01/Microsoft.Logic.json",
"parameters": {
"testURI": {
"type": "string",
"defaultValue": "[parameters('testUri')]"
}
},
"triggers": {
"recurrence": {
"type": "recurrence",
"recurrence": {
"frequency": "Hour",
"interval": 1
}
}
},
"actions": {
"http": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('testUri')"
},
"runAfter": {}
}
},
"outputs": {}
},
"parameters": {}
},
"resources": [
{
"type": "providers/diagnosticSettings",
"name": "[concat('Microsoft.Insights/', parameters('settingName'))]",
"dependsOn": [
"[resourceId('Microsoft.Logic/workflows', parameters('logicAppName'))]"
],
"properties": {
"name": "[parameters('settingName')]",
"storageAccountId": "[resourceId('Microsoft.Storage/storageAccounts',
parameters('storageAccountName'))]",
"eventHubAuthorizationRuleId": "[parameters('eventHubAuthorizationRuleId')]",
"eventHubName": "[parameters('eventHubName')]",
"workspaceId": "[parameters('workspaceId')]",
"logs": [
{
"enabled": true,
"days": 0,
"enabled": false
}
}
],
"metrics": [
{
"timeGrain": "PT1M",
"enabled": true,
"enabled": false,
"days": 0
}
}
]
}
}
],
"dependsOn": []
}
]
}
Next steps
Read more about platform logs in Azure.
Learn about diagnostic settings.
Prepare for format change to Azure Monitor platform
logs archived to a storage account
WARNING
If you are sending Azure resource logs or metrics to a storage account using diagnostic settings or activity logs to a storage
account using log profiles, the format of the data in the storage account changed to JSON Lines on Nov. 1, 2018. The
instructions below describe the impact and how to update your tooling to handle the new format.
What is changing
Azure Monitor offers a capability that enables you to send resource logs and activity logs into an Azure storage
account, Event Hubs namespace, or into a Log Analytics workspace in Azure Monitor. In order to address a system
performance issue, on November 1, 2018 at 12:00 midnight UTC the format of log data send to blob storage
will change. If you have tooling that is reading data out of blob storage, you need to update your tooling to
understand the new data format.
On Thursday, November 1, 2018 at 12:00 midnight UTC, the blob format changed to be JSON Lines. This
means each record will be delimited by a newline, with no outer records array and no commas between JSON
records.
The blob format changed for all diagnostic settings across all subscriptions at once. The first PT1H.json file
emitted for November 1 used this new format. The blob and container names remain the same.
Setting a diagnostic setting between prior to November 1 continued to emit data in the current format until
November 1.
This change occurred at once across all public cloud regions. The change will not occur in Microsoft Azure
Operated by 21Vianet, Azure Germany, or Azure Government clouds yet.
This change impacts the following data types:
Azure resource logs (see list of resources here)
Azure resource metrics being exported by diagnostic settings
Azure Activity log data being exported by log profiles
This change does not impact:
Network flow logs
Azure service logs not made available through Azure Monitor yet (for example, Azure App Service
diagnostic logs, storage analytics logs)
Routing of Azure diagnostic logs and activity logs to other destinations (Event Hubs, Log Analytics)
How to see if you are impacted
You are only impacted by this change if you:
1. Are sending log data to an Azure storage account using a diagnostic setting, and
2. Have tooling that depends on the JSON structure of these logs in storage.
To identify if you have diagnostic settings that are sending data to an Azure storage account, you can navigate to
the Monitor section of the portal, click on Diagnostic Settings, and identify any resources that have Diagnostic
Status set to Enabled:
If Diagnostic Status is set to enabled, you have an active diagnostic setting on that resource. Click on the resource
to see if any diagnostic settings are sending data to a storage account:
If you do have resources sending data to a storage account using these resource diagnostic settings, the format of
the data in that storage account will be impacted by this change. Unless you have custom tooling that operates off
of these storage accounts, the format change will not impact you.
Details of the format change
The current format of the PT1H.json file in Azure blob storage uses a JSON array of records. Here is a sample of a
KeyVault log file now:
{
"records": [
{
"time": "2016-01-05T01:32:01.2691226Z",
"durationMs": "78",
"identity": {
"claim": {
}
},
"properties": {
version=2015-06-01",
}
},
{
"time": "2016-01-05T01:33:56.5264523Z",
"durationMs": "83",
"identity": {
"claim": {
}
},
"properties": {
version=2015-06-01",
}
}
]
}
The new format uses JSON lines, where each event is a line and the newline character indicates a new event. Here
is what the above sample will look like in the PT1H.json file after the change:
"VaultGet","operationVersion": "2015-06-01","category": "AuditEvent","resultType":
"Success","resultSignature": "OK","resultDescription": "","durationMs": "78","callerIpAddress":
"104.40.82.76","correlationId": "","identity": {"claim":
{"http://schemas.microsoft.com/identity/claims/objectidentifier": "d9da5048-2737-4770-bd64-
XXXXXXXXXXXX","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":
"VaultGet","operationVersion": "2015-06-01","category": "AuditEvent","resultType":
"Success","resultSignature": "OK","resultDescription": "","durationMs": "83","callerIpAddress":
"104.40.82.76","correlationId": "","identity": {"claim":
{"http://schemas.microsoft.com/identity/claims/objectidentifier": "d9da5048-2737-4770-bd64-
XXXXXXXXXXXX","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":
This new format enables Azure Monitor to push log files using append blobs, which are more efficient for
continuously appending new event data.
How to update
You only need to make updates if you have custom tooling that ingests these log files for further processing. If you
are making use of an external log analytics or SIEM tool, we recommend using event hubs to ingest this data
instead. Event hubs integration is easier in terms of processing logs from many services and bookmarking location
in a particular log.
Custom tools should be updated to handle both the current format and the JSON Lines format described above.
This will ensure that when data starts to appear in the new format, your tools do not break.
Next steps
Learn about archiving resource diagnostic logs to a storage account
Learn about archiving activity log data to a storage account
Stream Azure monitoring data to an event hub
Azure Monitor provides a complete full stack monitoring solution for applications and services in Azure, in other
clouds, and on-premises. In addition to using Azure Monitor for analyzing that data and leveraging it for different
monitoring scenarios, you may need to send it to other monitoring tools in your environment. The most effective
method to stream monitoring data to external tools in most cases is using Azure Event Hubs. This article provides
a brief description for how you can stream monitoring data from different sources to an event hub and links to
detailed guidance.
Create an Event Hubs namespace

Before you configure streaming for any data source, you need to create an Event Hubs namespace and event hub.
This namespace and event hub is the destination for all of your monitoring data. An Event Hubs namespace is a
logical grouping of event hubs that share the same access policy, much like a storage account has individual blobs
within that storage account. Consider the following details about the event hubs namespace and event hubs that
you use for streaming monitoring data:
The number of throughput units allows you to increase throughput scale for your event hubs. Only one
throughput unit is typically necessary. If you need to scale up as your log usage increases, you can manually
increase the number of throughput units for the namespace or enable auto inflation.
The number of partitions allows you to parallelize consumption across many consumers. A single partition can
support up to 20MBps or approximately 20,000 messages per second. Depending on the tool consuming the
data, it may or may not support consuming from multiple partitions. Four partitions is reasonable to start if
you're unsure about if you're not sure about the number of partitions to set.
You set message retention on your event hub to at least 7 days. If your consuming tool goes down for more
than a day, this ensures that the tool can pick up where it left off for events up to 7 days old.
You should use the default consumer group for your event hub. There is no need to create other consumer
groups or use a separate consumer group unless you plan to have two different tools consume the same data
from the same event hub.
For the Azure Activity log, you pick an Event Hubs namespace, and Azure Monitor creates an event hub within
that namespace called insights-logs-operational-logs. For other log types, you can either choose an existing
event hub or have Azure Monitor create an event hub per log category.
Outbound port 5671 and 5672 must typically be opened on the computer or VNET consuming data from the
event hub.
Monitoring data available

Sources of monitoring data for Azure Monitor describes the different tiers of data for Azure applications and the
kinds of monitoring data available for each. The following table lists each of these tiers and a description of how
that data can be streamed to an event hub. Follow the links provided for further detail.
TIER DATA METHOD
Azure tenant Azure Active Directory audit logs Configure a tenant diagnostic setting
on your AAD tenant. See Tutorial:
Stream Azure Active Directory logs to
an Azure event hub for details.
TIER DATA METHOD
Azure subscription Azure Activity Log Create a log profile to export Activity
Log events to Event Hubs. See Export
Azure Activity log to storage or Azure
Event Hubs for details.
Azure resources Platform metrics Both types of data are sent to an event
Diagnostic logs hub using a resource diagnostic setting.
See Stream Azure Diagnostic logs to an
event hub for details.
Operating system (guest) Azure virtual machines Install the Azure Diagnostics Extension
on Windows and Linux virtual machines
in Azure. See Streaming Azure
Diagnostics data in the hot path by
using Event Hubs for details on
Windows VMs and Use Linux
Diagnostic Extension to monitor metrics
and logs for details on Linux VMs.
Application code Application Insights Application Insights doesn't provide a

direct method to stream data to event
hubs. You can set up continuous export
of the Application Insights data to a
storage account and then use a Logic
App to send the data to an event hub
as described in Manual streaming with
Logic App.
Manual streaming with Logic App

For data that you can't directly stream to an event hub, you can write to Azure storage and then use a time-
triggered Logic App that pulls data from blob storage and pushes it as a message to the event hub.
Tools with Azure Monitor integration

Routing your monitoring data to an event hub with Azure Monitor enables you to easily integrate with external
SIEM and monitoring tools. Examples of tools with Azure Monitor integration include the following:
TOOL DESCRIPTION
IBM QRadar The Microsoft Azure DSM and Microsoft Azure Event Hub
Protocol are available for download from the IBM support
website. You can learn more about the integration with Azure
at QRadar DSM configuration.
Splunk The Azure Monitor Add-On for Splunk is an open source

project available in Splunkbase. The documentation is
available at Azure Monitor Addon For Splunk.
If you cannot install an add-on in your Splunk instance, if for

example you're using a proxy or running on Splunk Cloud,
you can forward these events to the Splunk HTTP Event
Collector using Azure Function For Splunk, which is triggered
by new messages in the event hub.
TOOL DESCRIPTION
SumoLogic Instructions for setting up SumoLogic to consume data from

an event hub are available at Collect Logs for the Azure Audit
App from Event Hub.
ArcSight The ArcSight Azure Event Hub smart connector is available as

part of the ArcSight smart connector collection.
Syslog server If you want to stream Azure Monitor data directly to a syslog
server, you can use a solution based on an Azure function.
Next Steps
Archive the Activity log to a storage account
Read the overview of the Azure Activity log
Set up an alert based on an Activity log event
Azure Key Vault Analytics solution in Azure Monitor
NOTE
PowerShell.
You can use the Azure Key Vault solution in Azure Monitor to review Azure Key Vault AuditEvent logs.
To use the solution, you need to enable logging of Azure Key Vault diagnostics and direct the diagnostics to a Log
Analytics workspace. It is not necessary to write the logs to Azure Blob storage.
NOTE
In January 2017, the supported way of sending logs from Key Vault to Log Analytics changed. If the Key Vault solution you
are using shows (deprecated) in the title, refer to migrating from the old Key Vault solution for steps you need to follow.

Use the following instructions to install and configure the Azure Key Vault solution:
1. Use the process described in Add Azure Monitor solutions from the Solutions Gallery to add the Azure Key
Vault solution to your Log Analytics workspace.
2. Enable diagnostics logging for the Key Vault resources to monitor, using either the portal or PowerShell
Enable Key Vault diagnostics in the portal
1. In the Azure portal, navigate to the Key Vault resource to monitor
2. Select Diagnostics settings to open the following page
3. Click Turn on diagnostics to open the following page

4. Give a name to the diagnostic setting.
5. Click the checkbox for Send to Log Analytics
6. Select an existing Log Analytics workspace, or create a workspace
7. To enable AuditEvent logs, click the checkbox under Log
8. Click Save to enable the logging of diagnostics to Log Analytics workspace.
Enable Key Vault diagnostics using PowerShell
The following PowerShell script provides an example of how to use Set-AzDiagnosticSetting to enable diagnostic
logging for Key Vault:
$workspaceId = "/subscriptions/d2e37fee-1234-40b2-5678-0b2199de3b50/resourcegroups/oi-default-east-
us/providers/microsoft.operationalinsights/workspaces/rollingbaskets"
$kv = Get-AzKeyVault -VaultName 'ContosoKeyVault'
Set-AzDiagnosticSetting -ResourceId $kv.ResourceId -WorkspaceId $workspaceId -Enabled $true
Review Azure Key Vault data collection details

Azure Key Vault solution collects diagnostics logs directly from the Key Vault. It is not necessary to write the logs to
Azure Blob storage and no agent is required for data collection.
The following table shows data collection methods and other details about how data is collected for Azure Key
Vault.
OPERATIONS
SYSTEMS MANAGER
CENTER AGENT DATA
OPERATIONS OPERATIONS SENT VIA
MANAGER MANAGER MANAGEMENT COLLECTION
PLATFORM DIRECT AGENT AGENT AZURE REQUIRED? GROUP FREQUENCY
Azure • on arrival
Use Azure Key Vault

After you install the solution, view the Key Vault data by clicking the Key Vault Analytics tile from the Azure
Monitor Overview page. Open this page from the Azure Monitor menu by clicking More under the Insights
section.
After you click the Key Vault Analytics tile, you can view summaries of your logs and then drill in to details for
the following categories:
Volume of all key vault operations over time
Failed operation volumes over time
Average operational latency by operation
Quality of service for operations with the number of operations that take more than 1000 ms and a list of
operations that take more than 1000 ms
To view details for any operation
1. On the Overview page, click the Key Vault Analytics tile.
2. On the Azure Key Vault dashboard, review the summary information in one of the blades, and then click
one to view detailed information about it in the log search page.
On any of the log search pages, you can view results by time, detailed results, and your log search history.
You can also filter by facets to narrow the results.

The Azure Key Vault solution analyzes records that have a type of KeyVaults that are collected from AuditEvent
logs in Azure Diagnostics. Properties for these records are in the following table:
Type AzureDiagnostics
SourceSystem Azure
CallerIpAddress IP address of the client who made the request
Category AuditEvent
CorrelationId An optional GUID that the client can pass to correlate client-
side logs with service-side (Key Vault) logs.
DurationMs Time it took to service the REST API request, in milliseconds.

This time does not include network latency, so the time that
you measure on the client side might not match this time.
httpStatusCode_d HTTP status code returned by the request (for example, 200)
id_s Unique ID of the request

identity_claim_appid_g GUID for the application ID
OperationName Name of the operation, as documented in Azure Key Vault

Logging
OperationVersion REST API version requested by the client (for example 2015-
06-01)
requestUri_s Uri of the request
Resource Name of the key vault
ResourceGroup Resource group of the key vault
ResourceId Azure Resource Manager Resource ID. For Key Vault logs, this
is the Key Vault resource ID.
ResourceProvider MICROSOFT.KEYVAULT
ResourceType VAULTS
ResultSignature HTTP status (for example, OK)
ResultType Result of REST API request (for example, Success)
SubscriptionId Azure subscription ID of the subscription containing the Key

Vault
Migrating from the old Key Vault solution

In January 2017, the supported way of sending logs from Key Vault to Log Analytics changed. These changes
provide the following advantages:
Logs are written directly to a Log Analytics workspace without the need to use a storage account
Less latency from the time when logs are generated to them being available in Log Analytics
Fewer configuration steps
A common format for all types of Azure diagnostics
To use the updated solution:
1. Configure diagnostics to be sent directly to a Log Analytics workspace from Key Vault
2. Enable the Azure Key Vault solution by using the process described in Add Azure Monitor solutions from the
Solutions Gallery
3. Update any saved queries, dashboards, or alerts to use the new data type
Type is change from: KeyVaults to AzureDiagnostics. You can use the ResourceType to filter to Key Vault
Logs.
Instead of: KeyVaults , use AzureDiagnostics | where ResourceType'=="VAULTS"
Fields: (Field names are case-sensitive)
For any field that has a suffix of _s, _d, or _g in the name, change the first character to lower case
For any field that has a suffix of _o in name, the data is split into individual fields based on the nested
field names. For example, the UPN of the caller is stored in a field
identity_claim_http_schemas_xmlsoap_org_ws_2005_05_identity_claims_upn_s
Field CallerIpAddress changed to CallerIPAddress
Field RemoteIPCountry is no longer present
4. Remove the Key Vault Analytics (Deprecated ) solution. If you are using PowerShell, use
Set-AzureOperationalInsightsIntelligencePack -ResourceGroupName <resource group that the workspace is in> -
WorkspaceName <name of the log analytics workspace> -IntelligencePackName "KeyVault" -Enabled $false
Data collected before the change is not visible in the new solution. You can continue to query for this data using
the old Type and field names.
Troubleshooting
Troubleshoot Azure Diagnostics
If you receive the following error message, the Microsoft.insights resource provider is not registered:
Failed to update diagnostics for 'resource'. {"code":"Forbidden","message":"Please register the subscription
'subscription id' with Microsoft.Insights."}
To register the resource provider, perform the following steps in the Azure portal:
1. In the navigation pane on the left, click Subscriptions
2. Select the subscription identified in the error message
3. Click Resource Providers
4. Find the Microsoft.insights provider
5. Click the Register link
Once the Microsoft.insights resource provider is registered, retry configuring diagnostics.

In PowerShell, if you receive the following error message, you need to update your version of PowerShell:
Set-AzDiagnosticSetting : A parameter cannot be found that matches parameter name 'WorkspaceId'.
Update your version of Azure PowerShell, follow the instructions in the Install Azure PowerShell article.
Next steps
Use Log queries in Azure Monitor to view detailed Azure Key Vault data.
Performance Monitoring with Azure Monitor logs
This article covers the steps to add the Log Analytics agent as a virtual machine scale set extension to your cluster,
and connect it to your existing Azure Log Analytics workspace. This enables collecting diagnostics data about
containers, applications, and performance monitoring. By adding it as an extension to the virtual machine scale set
resource, Azure Resource Manager ensures that it gets installed on every node, even when scaling the cluster.
NOTE
This article assumes that you have an Azure Log Analytics workspace already set up. If you do not, head over to Set up Azure
Monitor logs
NOTE
Add the agent extension via Azure CLI

The best way to add the Log Analytics agent to your cluster is via the virtual machine scale set APIs available with
the Azure CLI. If you do not have Azure CLI set up yet, head over to Azure portal and open up a Cloud Shell
instance, or Install the Azure CLI.
1. Once your Cloud Shell is requested, make sure you are working in the same subscription as your resource.
Check this with az account show and make sure the "name" value matches that of your cluster's
subscription.
2. In the Portal, navigate to the resource group where your Log Analytics workspace is located. Click into the
log analytics resource (the type of the resource will be Log Analytics workspace). Once you are at the
resource overview page, click on Advanced Settings under the Settings section on the left menu.
3. Click on Windows Servers if you are standing up a Windows cluster, and Linux Servers if you are creating
a Linux cluster. This page will show you your workspace ID and workspace key (listed as Primary Key in the
portal). You will need both for the next step.
4. Run the command to install the Log Analytics agent onto your cluster, using the vmss extension set API in
your Cloud Shell:
For a Windows cluster:
az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring -

-resource-group <nameOfResourceGroup> --vmss-name <nameOfNodeType> --settings "{'workspaceId':'<Log
AnalyticsworkspaceId>'}" --protected-settings "{'workspaceKey':'<Log AnalyticsworkspaceKey>'}"
For a Linux cluster:

az vmss extension set --name OmsAgentForLinux --publisher Microsoft.EnterpriseCloud.Monitoring --
resource-group <nameOfResourceGroup> --vmss-name <nameOfNodeType> --settings "{'workspaceId':'<Log
AnalyticsworkspaceId>'}" --protected-settings "{'workspaceKey':'<Log AnalyticsworkspaceKey>'}"
Here's an example of the Log Analytics agent being added to a Windows cluster.
5. This should take less than 15 min to successfully add the agent to your nodes. You can verify that the agents
have been added by using the az vmss extension list API:
az vmss extension list --resource-group <nameOfResourceGroup> --vmss-name <nameOfNodeType>
Add the agent via the Resource Manager template

Sample Resource Manager templates that deploy an Azure Log Analytics workspace and add an agent to each of
your nodes is available for Windows or Linux.
You can download and modify this template to deploy a cluster that best suits your needs.
View Performance Counters

Now that you have added the Log Analytics agent, head on over to the Log Analytics portal to choose which
performance counters you'd like to collect.
1. In the Azure portal, go to the resource group in which you created the Service Fabric Analytics solution.
Select ServiceFabric<nameOfLog AnalyticsWorkspace>.
2. Click Log Analytics.
3. Click Advanced Settings.
4. Click Data, then click Windows or Linux Performance Counters. There is a list of default counters you
can choose to enable and you can set the interval for collection too. You can also add additional performance
counters to collect. The proper format is referenced in this article.
5. Click Save, then click OK.
6. Close the Advanced Settings blade.
7. Under the General heading, click Workspace summary.
8. You will see tiles in the form of a graph for each of the solutions enabled, including one for Service Fabric.
Click the Service Fabric graph to continue to the Service Fabric Analytics solution.
9. You will see a few tiles with graphs on operational channel and reliable services events. The graphical
representation of the data flowing in for the counters you have selected will appear under Node Metrics.
10. Click on a Container Metric graph to see additional details. You can also query on performance counter data
similarly to cluster events and filter on the nodes, perf counter name, and values using the Kusto query
language.
Next steps
Collect relevant performance counters. To configure the Log Analytics agent to collect specific performance
counters, review configuring data sources.
Configure Azure Monitor logs to set up automated alerting to aid in detecting and diagnostics
As an alternative you can collect performance counters through Azure Diagnostics extension and send them to
Monitor resource groups with Azure Monitor
(preview)
Modern applications are often complex and highly distributed with many discrete parts working together to
deliver a service. Recognizing this complexity, Azure Monitor provides monitoring insights for resource groups.
This makes it easy to triage and diagnose any problems your individual resources encounter, while offering context
as to the health and performance of the resource group—and your application—as a whole.
Access insights for resource groups

1. Select Resource groups from the left-side navigation bar.
2. Pick one of your resource groups that you want to explore. (If you have a large number of resource groups
filtering by subscription can sometimes be helpful.)
3. To access insights for a resource group, click Insights in the left-side menu of any resource group.
Resources with active alerts and health issues

The overview page shows how many alerts have been fired and are still active, along with the current Azure
Resource Health of each resource. Together, this information can help you quickly spot any resources that are
experiencing issues. Alerts help you detect issues in your code and how you've configured your infrastructure.
Azure Resource Health surfaces issue with the Azure platform itself, that aren't specific to your individual
applications.
Azure Resource Health
To display Azure Resource Health, check the Show Azure Resource Health box above the table. This column is
hidden by default to help the page load quickly.
By default, the resources are grouped by app layer and resource type. App layer is a simple categorization of
resource types, that only exists within the context of the resource group insights overview page. There are resource
types related to application code, compute infrastructure, networking, storage + databases. Management tools get
their own app layers, and every other resource is categorized as belonging to the Other app layer. This grouping
can help you see at-a-glance what subsystems of your application are healthy and unhealthy.
Diagnose issues in your resource group

The resource group insights page provides several other tools scoped to help you diagnose issues
Alerts View, create, and manage your alerts.
Metrics Visualize and explore your metric based data.
Activity logs Subscription level events that have occurred in Azure.
Application map Navigate your distributed application's topology to identify

performance bottlenecks or failure hotspots.
Failures and performance

What if you've noticed your application is running slowly, or users have reported errors? It's time consuming to
search through all of your resources to isolate problems.
The Performance and Failures tabs simplify this process by bringing together performance and failure diagnostic
views for many common resource types.
Most resource types will open a gallery of Azure Monitor Workbook templates. Each workbook you create can be
customized, saved, shared with your team, and reused in the future to diagnose similar issues.
Investigate failures
To test out the Failures tab select Failures under Investigate in the left-hand menu.
The left-side menu bar changes after your selection is made, offering you new options.
When App Service is chosen, you are presented with a gallery of Azure Monitor Workbook templates.
Choosing the template for Failure Insights will open the workbook.
You can select any of the rows. The selection is then displayed in a graphical details view.
Workbooks abstract away the difficult work of creating custom reports and visualizations into an easily
consumable format. While some users may only want to adjust the prebuilt parameters, workbooks are completely
customizable.
To get a sense of how this workbook functions internally, select Edit in the top bar.
A number of Edit boxes appear near the various elements of the workbook. Select the Edit box below the table of
operations.
This reveals the underlying log query that is driving the table visualization.
You can modify the query directly. Or you can use it as a reference and borrow from it when designing your own
custom parameterized workbook.
Investigate performance
Performance offers its own gallery of workbooks. For App Service the prebuilt Application Performance workbook
offers the following view:
In this case, if you select edit you will see that this set of visualizations is powered by Azure Monitor Metrics.
Troubleshooting
Enabling access to alerts
To see alerts in Azure Monitor for Resource Groups, someone with an Owner or Contributor role for this
subscription needs to open Azure Monitor for Resource Groups for any resource group in the subscription. This
will enable anyone with read access to see alerts in Azure Monitor for Resource Groups for all of the resource
groups in the subscription. If you have an Owner or Contributor role, refresh this page in a few minutes.
Azure Monitor for Resource Groups relies on the Azure Monitor Alerts Management system to retrieve alert
status. Alerts Management isn't configured for every resource group and subscription by default, and it can only
be enabled by someone with an Owner or Contributor role. It can be enabled either by:
Opening Azure Monitor for Resource Groups for any resource group in the subscription.
Or by going to the subscription, clicking Resource Providers, then clicking Register for Alerts.Management.
Next steps
Azure Monitor Workbooks
Azure Resource Health
Azure Monitor Alerts
Monitoring your storage service with Azure Monitor
for Storage (preview)
Azure Monitor for Storage (preview ) provides comprehensive monitoring of your Azure Storage accounts by
delivering a unified view of your Azure Storage services performance, capacity, and availability. You can observe
storage capacity, and performance in two ways, view directly from a storage account or view from Azure Monitor
to see across groups of storage accounts.
This article will help you understand the experience Azure Monitor for Storage (preview ) delivers to derive
actionable knowledge on the health and performance of Storage accounts at scale, with a capability to focus on
hotspots and diagnose latency, throttling, and availability issues.
Introduction to Azure Monitor for Storage (preview)

Before diving into the experience, you should understand how it presents and visualizes information. Whether you
select the Storage feature directly from a storage account or from Azure Monitor, Azure Monitor for Storage
presents a consistent experience.
Combined it delivers:
At scale perspective showing a snapshot view of their availability based on the health of the storage
service or the API operation, utilization showing total number of requests that the storage service receives,
and latency showing the average time the storage service or API operation type is taking to process
requests. You can also view capacity by blob, file, table, and queue.
Drill down analysis of a particular storage account to help diagnose issues or perform detailed analysis by
category - availability, performance, failures, and capacity. Selecting any one of those options provides an in-
depth view of metrics.
Customizable where you can change which metrics you want to see, modify or set thresholds that align
with your limits, and save as your own workbook. Charts in the workbook can be pinned to Azure
dashboard.
This feature does not require you to enable or configure anything, the storage metrics from your storage accounts
are collected by default. If you are unfamiliar with metrics available on Azure Storage, view the description and
definition in Azure Storage metrics by reviewing Azure storage metrics.
NOTE
There is no charge to access this feature and you will only be charged for the Azure Monitor essential features you configure
or enable, as described on the Azure Monitor pricing details page.
NOTE
Azure Monitor for Storage does not support general-purpose v1 accounts.
View from Azure Monitor

From Azure Monitor, you can view transaction, latency, and capacity details from multiple storage accounts in your
subscription, and help identify performance, capacity problems, and failures.
To view the utilization and availability of your storage accounts across all of your subscriptions, perform the
following steps.
2. Select Monitor from the left-hand pane in the Azure portal, and under the Insights section, select Storage
Accounts (preview).
Overview workbook
On the Overview workbook for the selected subscription, the table displays interactive storage metrics and service
availability state for up to 10 storage accounts grouped within the subscription. You can filter the results based on
the options you select from the following drop-down lists:
Subscriptions - only subscriptions that have storage accounts are listed.
Storage Accounts - by default, 10 storage accounts are pre-selected. If you select all or multiple storage
accounts in the scope selector, up to 200 storage accounts will be returned. For example, if you had a total of
573 storage accounts across three subscriptions that you've selected, only 200 accounts would be displayed.
Time Range - by default, displays the last 4 hours of information based on the corresponding selections
made.
The counter tile under the drop-down lists rolls-up the total number of storage accounts in the subscription and
reflects how many of the total are selected. There is conditional color-coding or heatmaps for columns in the
workbook that report transaction metrics or errors. The deepest color has the highest value and a lighter color is
based on the lowest values. For the error-based columns, the value is in red and for the metric-based columns, the
value is in blue.
Select a value in the columns Availability, E2E Latency, Server Latency, and transaction error type/Errors
directs you to a report tailored to the specific type of storage metrics that match the column selected for that
storage account. For more information about the workbooks for each category, see the Detailed storage
workbooks section below.
NOTE
For details on which errors can be shown in the report, see Response Type schema and look for response types such as
ServerOtherError, ClientOtherError, ClientThrottlingError. Depending on the storage accounts selected, if there are more
than three types of errors reported, all other errors are represented under the category of Other.
The default Availability threshold is:

Warning - 99%
Critical - 90%
To set an availability threshold based on the results of your observation or requirements, review modify the
availability threshold.
Capacity workbook
Select Capacity at the top of the page and the Capacity workbook opens. It shows you the amount of total
storage used in the account and capacity used by each data service in the account to help identify over and under
utilized storage.
There is conditional color-coding or heatmaps for columns in the workbook that report capacity metrics with a blue
value. The deepest color has the highest value and a lighter color is based on the lowest values.
When you select a value under any one of the columns in the workbook, you drill down to the Capacity workbook
for the storage account. Further details about the drill-down report are described in the Detailed storage
workbooks section below.
View from a storage account

To access Azure Monitor for VMs directly from a storage account:
1. In the Azure portal, select Storage accounts.
2. From the list, choose a storage account. In the Monitoring section, choose Insights (preview ).
On the Overview workbook for the storage account, it shows several storage performance metrics that help you
quickly assess:
Health of the Storage service to immediately see if an issue outside of your control is affecting the Storage
service in the region it is deployed to, which is stated under the Summary column.
Interactive performance charts showing the most essential details related to storage capacity, availability,
transactions, and latency.
Metric and status tiles highlighting service availability, total count of transactions to the storage service, E2E
latency, and server latency.
Selecting any one of buttons for Failures, Performance, Availability, and Capacity opens the respective
workbook.
Detailed storage workbooks
Whether you selected a value in the columns Availability, E2E Latency, Server Latency, and transaction error
type/Errors from the multiple storage account Overview workbook, or selecting any one of buttons for Failures,
Performance, Availability, and Capacity from the Overview workbook from a specific storage account, each
deliver a set of interactive storage-related information tailored to that category.
Availability opens the Availability workbook. It shows the current health state of Azure Storage service, a
table showing the available health state of each object categorized by data service defined in the storage
account with a trend line representing the time range selected, and an availability trend chart for each data
service in the account.
E2E Latency and Server Latency opens the Performance workbook. It includes a rollup status tile
showing E2E latency and server latency, a performance chart of E2E versus server latency, and a table
breaking down latency of successful calls by API categorized by data service defined in the storage account.
Selecting any of the error categories listed in the grid open the Failure workbook. The report shows metric
tiles of all other client-side errors except described ones and successful requests, client-throttling errors, a
performance chart for the transaction Response Type dimension metric specific to ClientOtherError
attribute, and two tables - Transactions by API name and Transactions by Response type.
Capacity opens the Capacity workbook. It shows the total amount of storage used for each storage data
object in the account in the tiles and the chart, and how many data objects are stored in the account.
Pin and export
You can pin any one of the metric sections to an Azure Dashboard by selecting the pushpin icon at the top right of
the section.
The multi-subscription and storage account Overview or Capacity workbooks support exporting the results in
Excel format by selecting the down arrow icon to the right of the pushpin icon.
Customize Azure Monitor for Storage (preview)
This section highlights common scenarios for editing the workbook to customize in support of your data analytics
needs:
Scope the workbook to always select a particular subscription or storage account(s)
Change metrics in the grid
Change the availability threshold
Change the color rendering
The customizations are saved to a custom workbook to prevent overwriting the default configuration in our
published workbook. Workbooks are saved within a resource group, either in the My Reports section that's private
to you or in the Shared Reports section that's accessible to everyone with access to the resource group. After you
save the custom workbook, you need to go to the workbook gallery to launch it.
Specifying a subscription or storage account

You can configure the multi-subscription and storage account Overview or Capacity workbooks to scope to a
particular subscription(s) or storage account(s) on every run, perform the following steps.
1. Select Monitor from the portal and then select Storage Accounts (preview) from the left-hand pane.
2. On the Overview workbook, from the command bar select Edit.
3. Select from the Subscriptions drop-down list one or more subscriptions you want it to default to.
Remember, the workbook supports selecting up to a total of 10 subscriptions.
4. Select from the Storage Accounts drop-down list one or more accounts you want it to default to.
Remember, the workbook supports selecting up to a total of 200 storage accounts.
5. Select Save as from the command bar to save a copy of the workbook with your customizations, and then
click Done editing to return to reading mode.
Modify metrics and colors in the workbook
The prebuilt workbooks contain metric data and you have the ability to modify or remove any one of the
visualizations and customize to your team's specific needs.
In our example, we are working with the multi-subscription and storage account capacity workbook, to
demonstrate how to:
Remove a metric
Change color rendering
You can perform the same changes against any one of the prebuilt Failures, Performance, Availability, and
Capacity workbooks.
1. Select Monitor from the portal and then select Storage Accounts (preview) from the left-hand pane.
2. Select Capacity to switch to the capacity workbook and from the command bar, select Edit from the
command bar.
3. Next to the metrics section, select Edit.
4. We are going to remove the Account used capacity timeline column, so select Column Settings in the
metrics grid.
5. In the Edit column settings pane, select under the Columns section
microsoft.storage/storageaccounts-Capacity-UsedCapacity Timeline$|Account used capacity
Timeline$, and under the drop-down list Column renderer select Hidden.
6. Select Save and close to commit your change.
Now let's change the color theme for the capacity metrics in the report to use green instead of blue.
1. Select Column Settings in the metrics grid.
2. In the Edit column settings pane, select under the Columns section
microsoft.storage/storageaccounts-Capacity-
UsedCapacity$|microsoft.storage/storageaccounts/blobservices-Capacity-
BlobCapacity$|microsoft.storage/storageaccounts/fileservices-Capacity-
FileCapacity$|microsoft.storage/storageaccounts/queueservices-Capacity-
QueueCapacity$|microsoft.storage/storageaccounts/tableservices-Capacity-TableCapacity$.
Under the drop-down list Color palette, select Green.
3. Select Save and close to commit your change.
Modify the availability threshold
In this example, we are working with the storage account capacity workbook and demonstrating how to modify the
availability threshold. By default, the tile and grid reporting percent availability are configured with a minimum
threshold of 90 and maximum threshold of 99. We are going to change the minimum threshold value of the
Availability % in the Availability by API name grid to 85%, which means the health state changes to critical if
the threshold is less than 85 percent.
1. Select Storage accounts from the portal and then select a storage account from the list.
2. Select Insights (preview) from the left-hand pane.
3. In the workbook, select Availability to switch to the availability workbook, and then select Edit from the
command bar.
4. Scroll down to the bottom of the page and on the left-hand side next to the Availability by API grid, select
Edit.
5. Select Column settings and then in the Edit column settings pane, under the Columns section select
Availability (%) (Thresholds + Formatted).
6. Change the value for the Critical health state from 90 to 85 and then click Save and Close.
Troubleshooting
This section will help you with the diagnosis and troubleshooting of some of the common issues you may
encounter when using Azure Monitor for Storage (preview ). Use the list below to locate the information relevant to
your specific issue.
Resolving performance, capacity, or availability issues
To help troubleshoot any storage-related issues you identify with Azure Monitor for Storage (preview ), see the
Azure Storage troubleshooting guidance.
Next steps
Configure metric alerts and service health notifications to set up automated alerting to aid in detecting
issues.
Learn the scenarios workbooks are designed to support, how to author new and customize existing reports,
and more by reviewing Create interactive reports with Azure Monitor workbooks.
For an in-depth guide on using Storage Analytics and other tools to identify, diagnose, and troubleshoot
Azure Storage-related issues, see Monitor, diagnose, and troubleshoot Microsoft Azure Storage.
Monitor Azure SQL Database using Azure SQL
Analytics (Preview)
Azure SQL Analytics is an advanced cloud monitoring solution for monitoring performance of Azure SQL
databases, elastic pools, and Managed Instances at scale and across multiple subscriptions through a single pane
of glass. It collects and visualizes important Azure SQL Database performance metrics with built-in intelligence for
performance troubleshooting.
By using metrics that you collect with the solution, you can create custom monitoring rules and alerts. The solution
helps you to identify issues at each layer of your application stack. It uses Azure Diagnostic metrics along with
Azure Monitor views to present data about all your Azure SQL databases, elastic pools, and databases in Managed
Instances in a single Log Analytics workspace. Azure Monitor helps you to collect, correlate, and visualize
structured and unstructured data.
For a hands-on overview on using Azure SQL Analytics solution and for typical usage scenarios, see the
embedded video:
Connected sources
Azure SQL Analytics is a cloud only monitoring solution supporting streaming of diagnostics telemetry for Azure
SQL databases: single, pooled, and Managed Instance databases. As the solution does not use agents to connect to
Azure Monitor, the solution does not support monitoring of SQL Server hosted on-premises or in VMs, see the
compatibility table below.
Azure Diagnostics Yes Azure metric and log data are sent to
Azure Monitor Logs directly by Azure.
Azure storage account No Azure Monitor doesn't read the data

from a storage account.
Windows agents No Direct Windows agents aren't used by

the solution.
Linux agents No Direct Linux agents aren't used by the

solution.
System Center Operations Manager No A direct connection from the

management group Operations Manager agent to Azure
Monitor is not used by the solution.
Configuration
Use the process described in Add Azure Monitor solutions from the Solutions Gallery to add the Azure SQL
Analytics (Preview ) solution to your Log Analytics workspace.
Configure Azure SQL Databases, elastic pools and Managed Instances to stream diagnostics telemetry
Once you have created Azure SQL Analytics solution in your workspace, you need to configure each resources
that you want to monitor to stream its diagnostics telemetry to the solution. Follow detailed instructions on this
page:
Enable Azure Diagnostics for your Azure SQL database to stream diagnostics telemetry to Azure SQL
Analytics.
The above page also provides instructions on enabling support for monitoring multiple Azure subscriptions from a
single Azure SQL Analytics workspace as a single pane of glass.
Using the solution

When you add the solution to your workspace, the Azure SQL Analytics tile is added to your workspace, and it
appears in Overview. Select View Summary link to load the tile content.
Once loaded, the tile shows the number of Azure SQL databases, elastic pools, Managed Instances, and databases
in Managed instances that the solution is receiving diagnostics telemetry from.
The solution provides two separate views -- one for monitoring Azure SQL Databases and elastic pools, and the
other view for monitoring Managed Instance, and databases in Managed Instances.
To view Azure SQL Analytics monitoring dashboard for Azure SQL Databases and elastic pools, click on the upper
part of the tile. To view Azure SQL Analytics monitoring dashboard for Managed Instance, and databases in
Managed Instance, click on the lower part of the tile.
Viewing Azure SQL Analytics data
The dashboard includes the overview of all databases that are monitored through different perspectives. For
different perspectives to work, you must enable proper metrics or logs on your SQL resources to be streamed to
Log Analytics workspace.
Note that if some metrics or logs are not streamed into Azure Monitor, the tiles in the solution are not populated
with monitoring information.
Azure SQL Database and elastic pool view
Once the Azure SQL Analytics tile for the database is selected, the monitoring dashboard is shown.
Selecting any of the tiles, opens a drill-down report into the specific perspective. Once the perspective is selected,
the drill-down report is opened.
Each perspective in this view provides summaries on subscription, server, elastic pool, and database level. In
addition, each perspective shows a perspective specific to the report on the right. Selecting subscription, server,
pool, or database from the list continues the drill-down.
Managed Instance and databases in Managed Instance view
Once the Azure SQL Analytics tile for the databases is selected, the monitoring dashboard is shown.
Selecting any of the tiles, opens a drill-down report into the specific perspective. Once the perspective is selected,
the drill-down report is opened.
Selecting Managed Instance view, shows details on the Managed Instance utilization, databases it contains, and
telemetry on the queries executed across the instance.
Perspectives
The below table outlines perspectives supported for two versions of the dashboard, one for Azure SQL database
and elastic pools, and the other one for Managed Instance.
SQL DATABASE AND ELASTIC

PERSPECTIVE DESCRIPTION POOLS SUPPORT MANAGED INSTANCE SUPPORT
Resource by type Perspective that counts all Yes Yes

the resources monitored.
Insights Provides hierarchical drill- Yes Yes

down into Intelligent
Insights into performance.
SQL DATABASE AND ELASTIC
PERSPECTIVE DESCRIPTION POOLS SUPPORT MANAGED INSTANCE SUPPORT
Errors Provides hierarchical drill- Yes Yes

down into SQL errors that
happened on the databases.
Timeouts Provides hierarchical drill- Yes No

down into SQL timeouts
that happened on the
databases.
Blockings Provides hierarchical drill- Yes No

down into SQL blockings
that happened on the
databases.
Database waits Provides hierarchical drill- Yes Yes

down into SQL wait statistics
on the database level.
Includes summaries of total
waiting time and the waiting
time per wait type.
Query duration Provides hierarchical drill- Yes Yes

down into the query
execution statistics such as
query duration, CPU usage,
Data IO usage, Log IO
usage.
Query waits Provides hierarchical drill- Yes Yes

down into the query wait
statistics by wait category.
Intelligent Insights report

Azure SQL Database Intelligent Insights lets you know what is happening with performance of all Azure SQL
databases. All Intelligent Insights collected can be visualized and accessed through the Insights perspective.
Elastic pool and Database reports

Both elastic pools and SQL Databases have their own specific reports that show all the data that is collected for the
resource in the specified time.
Query reports
Through the Query duration and query waits perspectives, you can correlate the performance of any query
through the query report. This report compares the query performance across different databases and makes it
easy to pinpoint databases that perform the selected query well versus ones that are slow.
Permissions
To use Azure SQL Analytics, users need to be granted a minimum permission of the Reader role in Azure. This
role, however, does not allow users to see the query text, or perform any Automatic tuning actions. More
permissive roles in Azure that allow using the solution to the fullest extent are Owner, Contributor, SQL DB
Contributor, or SQL Server Contributor. You also might want to consider creating a custom role in the portal with
specific permissions required only to use Azure SQL Analytics, and with no access to managing other resources.
Creating a custom role in portal
NOTE
PowerShell.
Recognizing that some organizations enforce strict permission controls in Azure, find the following PowerShell
script enabling creation of a custom role “SQL Analytics Monitoring Operator” in Azure portal with the minimum
read and write permissions required to use Azure SQL Analytics to its fullest extent.
Replace the “{SubscriptionId}" in the below script with your Azure subscription ID, and execute the script logged in
as an Owner or Contributor role in Azure.
Connect-AzAccount
Select-AzSubscription {SubscriptionId}
$role = Get-AzRoleDefinition -Name Reader
$role.Name = "SQL Analytics Monitoring Operator"
$role.Description = "Lets you monitor database performance with Azure SQL Analytics as a reader. Does not
allow change of resources."
$role.IsCustom = $true
$role.Actions.Add("Microsoft.SQL/servers/databases/read");
$role.Actions.Add("Microsoft.SQL/servers/databases/topQueries/queryText/*");
$role.Actions.Add("Microsoft.Sql/servers/databases/advisors/read");
$role.Actions.Add("Microsoft.Sql/servers/databases/advisors/write");
$role.Actions.Add("Microsoft.Sql/servers/databases/advisors/recommendedActions/read");
$role.Actions.Add("Microsoft.Sql/servers/databases/advisors/recommendedActions/write");
$role.Actions.Add("Microsoft.Sql/servers/databases/automaticTuning/read");
$role.Actions.Add("Microsoft.Sql/servers/databases/automaticTuning/write");
$role.Actions.Add("Microsoft.Sql/servers/advisors/read");
$role.Actions.Add("Microsoft.Sql/servers/advisors/write");
$role.Actions.Add("Microsoft.Sql/servers/advisors/recommendedActions/read");
$role.Actions.Add("Microsoft.Sql/servers/advisors/recommendedActions/write");
$role.Actions.Add("Microsoft.Resources/deployments/write");
$role.AssignableScopes = "/subscriptions/{SubscriptionId}"
New-AzRoleDefinition $role
Once the new role is created, assign this role to each user that you need to grant custom permissions to use Azure
SQL Analytics.
Analyze data and create alerts

Data analysis in Azure SQL Analytics is based on Log Analytics language for your custom querying and reporting.
Find description of the available data collected from database resource for custom querying in metrics and logs
available.
Automated alerting in the solution is based on writing a Log Analytics query that triggers an alert upon a
condition met. Find below several examples on Log Analytics queries upon which alerting can be set up in the
solution.
Creating alerts for Azure SQL Database
You can easily create alerts with the data coming from Azure SQL Database resources. Here are some useful log
queries that you can use with a log alert:
High CPU on Azure SQL Database
AzureMetrics
| where ResourceProvider=="MICROSOFT.SQL"
| where ResourceId contains "/DATABASES/"
| where MetricName=="cpu_percent"
| summarize AggregatedValue = max(Maximum) by bin(TimeGenerated, 5m)
| render timechart
NOTE
Pre-requirement of setting up this alert is that monitored databases stream Basic metrics to the solution.
Replace the MetricName value cpu_percent with dtu_consumption_percent to obtain high DTU results instead.
High CPU on Azure SQL Database elastic pools
AzureMetrics
| where ResourceProvider=="MICROSOFT.SQL"
| where ResourceId contains "/ELASTICPOOLS/"
| where MetricName=="cpu_percent"
| summarize AggregatedValue = max(Maximum) by bin(TimeGenerated, 5m)
| render timechart
NOTE
Replace the MetricName value cpu_percent with dtu_consumption_percent to obtain high DTU results instead.
Azure SQL Database storage in average above 95% in the last 1 hr
let time_range = 1h;

let storage_threshold = 95;
AzureMetrics
| where ResourceId contains "/DATABASES/"
| where MetricName == "storage_percent"
| summarize max_storage = max(Average) by ResourceId, bin(TimeGenerated, time_range)
| where max_storage > storage_threshold
| distinct ResourceId
NOTE
This query requires an alert rule to be set up to fire off an alert when there exist results (> 0 results) from the query,
denoting that the condition exists on some databases. The output is a list of database resources that are above the
storage_threshold within the time_range defined.
The output is a list of database resources that are above the storage_threshold within the time_range defined.
Alert on Intelligent insights
let alert_run_interval = 1h;

let insights_string = "hitting its CPU limits";
AzureDiagnostics
| where Category == "SQLInsights" and status_s == "Active"
| where TimeGenerated > ago(alert_run_interval)
| where rootCauseAnalysis_s contains insights_string
| distinct ResourceId
NOTE
Pre-requirement of setting up this alert is that monitored databases stream SQLInsights diagnostics log to the solution.
This query requires an alert rule to be set up to run with the same frequency as alert_run_interval in order to avoid
duplicate results. The rule should be set up to fire off the alert when there exist results (> 0 results) from the query.
Customize the alert_run_interval to specify the time range to check if the condition has occurred on databases configured
to stream SQLInsights log to the solution.
Customize the insights_string to capture the output of the Insights root cause analysis text. This is the same text
displayed in the UI of the solution that you can use from the existing insights. Alternatively, you can use the query below
to see the text of all Insights generated on your subscription. Use the output of the query to harvest the distinct strings
for setting up alerts on Insights.
AzureDiagnostics
| where Category == "SQLInsights" and status_s == "Active"
| distinct rootCauseAnalysis_s
Creating alerts for Managed Instance

Managed Instance storage is above 90%
let storage_percentage_threshold = 90;

AzureDiagnostics
| where Category =="ResourceUsageStats"
| summarize (TimeGenerated, calculated_storage_percentage) = arg_max(TimeGenerated,
todouble(storage_space_used_mb_s) *100 / todouble (reserved_storage_mb_s))
by ResourceId
| where calculated_storage_percentage > storage_percentage_threshold
NOTE
Pre-requirement of setting up this alert is that monitored Managed Instance has the streaming of ResourceUsageStats
log enabled to the solution.
denoting that the condition exists on the Managed Instance. The output is storage percentage consumption on the
Managed Instance.
Managed Instance CPU average consumption is above 95% in the last 1 hr
let cpu_percentage_threshold = 95;

let time_threshold = ago(1h);
AzureDiagnostics
| where Category == "ResourceUsageStats" and TimeGenerated > time_threshold
| summarize avg_cpu = max(todouble(avg_cpu_percent_s)) by ResourceId
| where avg_cpu > cpu_percentage_threshold
NOTE
Pre-requirement of setting up this alert is that monitored Managed Instance has the streaming of ResourceUsageStats
log enabled to the solution.
denoting that the condition exists on the Managed Instance. The output is average CPU utilization percentage
consumption in defined period on the Managed Instance.
Pricing
While the solution is free to use, consumption of diagnostics telemetry above the free units of data ingestion
allocated each month applies, see Log Analytics pricing. The free units of data ingestion provided enable free
monitoring of several databases each month. Note that more active databases with heavier workloads ingest more
data versus idle databases. You can easily monitor your data ingestion consumption in the solution by selecting
OMS Workspace on the navigation menu of Azure SQL Analytics, and then selecting Usage and Estimated Costs.
Next steps
Use log queries in Azure Monitor to view detailed Azure SQL data.
Create your own dashboards showing Azure SQL data.
Create alerts when specific Azure SQL events occur.
Optimize your SQL environment with the SQL Server
Health Check solution in Azure Monitor
You can use the SQL Health Check solution to assess the risk and health of your server environments on a regular
interval. This article will help you install the solution so that you can take corrective actions for potential problems.
This solution provides a prioritized list of recommendations specific to your deployed server infrastructure. The
recommendations are categorized across six focus areas which help you quickly understand the risk and take
corrective action.
The recommendations made are based on the knowledge and experience gained by Microsoft engineers from
thousands of customer visits. Each recommendation provides guidance about why an issue might matter to you
and how to implement the suggested changes.
You can choose focus areas that are most important to your organization and track your progress toward running
a risk free and healthy environment.
After you've added the solution and an assessment is completed, summary information for focus areas is shown
on the SQL Health Check dashboard for the infrastructure in your environment. The following sections describe
how to use the information on the SQL Health Check dashboard, where you can view and then take
recommended actions for your SQL Server infrastructure.
Prerequisites
The SQL Health Check solution requires a supported version of .NET Framework 4 installed on each
computer that has the Microsoft Monitoring Agent (MMA) installed. The MMA agent is used by System
Center 2016 - Operations Manager and Operations Manager 2012 R2, and Azure Monitor.
The solution supports SQL Server version 2012, 2014, and 2016.
A Log Analytics workspace to add the SQL Health Check solution from the Azure marketplace in the Azure
portal. In order to install the solution, you must be an administrator or contributor in the Azure subscription.
NOTE
After you've added the solution, the AdvisorAssessment.exe file is added to servers with agents. Configuration data is
read and then sent to Azure Monitor in the cloud for processing. Logic is applied to the received data and the cloud
service records the data.
To perform the health check against your SQL Server servers, they require an agent and connectivity to Azure
Monitor using one of the following supported methods:
1. Install the Microsoft Monitoring Agent (MMA) if the server is not already monitored by System Center 2016 -
Operations Manager or Operations Manager 2012 R2.
2. If it is monitored with System Center 2016 - Operations Manager or Operations Manager 2012 R2 and the
management group is not integrated with Azure Monitor, the server can be multi-homed with Log Analytics to
collect data and forward to the service and still be monitored by Operations Manager.
3. Otherwise, if your Operations Manager management group is integrated with the service, you need to add the
domain controllers for data collection by the service following the steps under add agent-managed computers
after you enable the solution in your workspace.
The agent on your SQL Server which reports to an Operations Manager management group, collects data,
forwards to its assigned management server, and then is sent directly from a management server to Azure
Monitor. The data is not written to the Operations Manager databases.
If the SQL Server is monitored by Operations Manager, you need to configure an Operations Manager Run As
account. See Operations Manager run-as accounts for Azure Monitor below for more information.
SQL Health Check data collection details

SQL Health Check collects data from the following sources using the agent that you have enabled:
Windows Management Instrumentation (WMI)
Registry
SQL Server dynamic management view results
Data is collected on the SQL Server and forwarded to Log Analytics every seven days.
Operations Manager run-as accounts for Log Analytics

Log Analytics uses the Operations Manager agent and management group to collect and send data to the Log
Analytics service. Log Analytics builds upon management packs for workloads to provide value-add services. Each
workload requires workload-specific privileges to run management packs in a different security context, such as a
domain user account. You need to provide credential information by configuring an Operations Manager Run As
account.
Use the following information to set the Operations Manager Run As account for SQL Health Check.
Set the Run As account for SQL Health Check
If you are already using the SQL Server management pack, you should use that Run As configuration.
To configure the SQL Run As account in the Operations console
NOTE
By default workflows in the management pack runs in the security context of the Local System account. If you are using the
Microsoft Monitoring Agent connected directly to the service rather than reporting directly to an Operations Manager
management group, skip steps 1-5 below and run either the T-SQL or PowerShell sample, specifying NT
AUTHORITY\SYSTEM as the user name.
1. In Operations Manager, open the Operations console, and then click Administration.
2. Under Run As Configuration, click Profiles, and open SQL Assessment Run As Profile.
3. On the Run As Accounts page, click Add.
4. Select a Windows Run As account that contains the credentials needed for SQL Server, or click New to
create one.
NOTE
The Run As account type must be Windows. The Run As account must also be part of Local Administrators group on
all Windows Servers hosting SQL Server Instances.
5. Click Save.
6. Modify and then execute the following T-SQL sample on each SQL Server instance to grant minimum
permissions required for the Run As Account to perform the health check. However, you don’t need to do
this if a Run As Account is already part of the sysadmin server role on SQL Server instances.
---
-- Replace <UserName> with the actual user name being used as Run As Account.
USE master
-- Create login for the user, comment this line if login is already created.
CREATE LOGIN [<UserName>] FROM WINDOWS
-- Grant permissions to user.

GRANT VIEW SERVER STATE TO [<UserName>]
GRANT VIEW ANY DEFINITION TO [<UserName>]
GRANT VIEW ANY DATABASE TO [<UserName>]
-- Add database user for all the databases on SQL Server Instance, this is required for connecting to
individual databases.
-- NOTE: This command must be run anytime new databases are added to SQL Server instances.
EXEC sp_msforeachdb N'USE [?]; CREATE USER [<UserName>] FOR LOGIN [<UserName>];'
To configure the SQL Run As account using Windows PowerShell

Open a PowerShell window and run the following script after you’ve updated it with your information:
import-module OperationsManager
New-SCOMManagementGroupConnection "<your management group name>"
$profile = Get-SCOMRunAsProfile -DisplayName "SQL Assessment Run As Profile"

$account = Get-SCOMrunAsAccount | Where-Object {$_.Name -eq "<your run as account name>"}
Set-SCOMRunAsProfile -Action "Add" -Profile $Profile -Account $Account
Understanding how recommendations are prioritized

Every recommendation made is given a weighting value that identifies the relative importance of the
recommendation. Only the ten most important recommendations are shown.
How weights are calculated
Weightings are aggregate values based on three key factors:
The probability that an issue identified will cause problems. A higher probability equates to a larger overall
score for the recommendation.
The impact of the issue on your organization if it does cause a problem. A higher impact equates to a larger
overall score for the recommendation.
The effort required to implement the recommendation. A higher effort equates to a smaller overall score for the
recommendation.
The weighting for each recommendation is expressed as a percentage of the total score available for each focus
area. For example, if a recommendation in the Security and Compliance focus area has a score of 5%,
implementing that recommendation will increase your overall Security and Compliance score by 5%.
Focus areas
Security and Compliance - This focus area shows recommendations for potential security threats and breaches,
corporate policies, and technical, legal and regulatory compliance requirements.
Availability and Business Continuity - This focus area shows recommendations for service availability,
resiliency of your infrastructure, and business protection.
Performance and Scalability - This focus area shows recommendations to help your organization's IT
infrastructure grow, ensure that your IT environment meets current performance requirements, and is able to
respond to changing infrastructure needs.
Upgrade, Migration and Deployment - This focus area shows recommendations to help you upgrade, migrate,
and deploy SQL Server to your existing infrastructure.
Operations and Monitoring - This focus area shows recommendations to help streamline your IT operations,
implement preventative maintenance, and maximize performance.
Change and Configuration Management - This focus area shows recommendations to help protect day-to-day
operations, ensure that changes don't negatively affect your infrastructure, establish change control procedures,
and to track and audit system configurations.
Should you aim to score 100% in every focus area?
Not necessarily. The recommendations are based on the knowledge and experiences gained by Microsoft
engineers across thousands of customer visits. However, no two server infrastructures are the same, and specific
recommendations may be more or less relevant to you. For example, some security recommendations might be
less relevant if your virtual machines are not exposed to the Internet. Some availability recommendations may be
less relevant for services that provide low priority ad hoc data collection and reporting. Issues that are important to
a mature business may be less important to a start-up. You may want to identify which focus areas are your
priorities and then look at how your scores change over time.
Every recommendation includes guidance about why it is important. You should use this guidance to evaluate
whether implementing the recommendation is appropriate for you, given the nature of your IT services and the
business needs of your organization.
Use Health Check focus area recommendations

Before you can use an assessment solution in Azure Monitor, you must have the solution installed. After it is
installed, you can view the summary of recommendations by using the SQL Health Check tile on the Overview
page for Azure Monitor in the Azure portal.
View the summarized compliance assessments for your infrastructure and then drill-into recommendations.
To view recommendations for a focus area and take corrective action
2. In the Azure portal, click More services found on the lower left-hand corner. In the list of resources, type
Monitor. As you begin typing, the list filters based on your input. Select Monitor.
3. In the Insights section of the menu, select More.
4. On the Overview page, click the SQL Health Check tile.
5. On the Health Check page, review the summary information in one of the focus area blades and then click one
to view recommendations for that focus area.
6. On any of the focus area pages, you can view the prioritized recommendations made for your environment.
Click a recommendation under Affected Objects to view details about why the recommendation is made.
7. You can take corrective actions suggested in Suggested Actions. When the item has been addressed, later
assessments will record that recommended actions were taken and your compliance score will increase.
Corrected items appear as Passed Objects.
Ignore recommendations
If you have recommendations that you want to ignore, you can create a text file that Azure Monitor will use to
prevent recommendations from appearing in your assessment results.
To identify recommendations that you will ignore
1. In the Azure Monitor menu, click Logs.
2. Use the following query to list recommendations that have failed for computers in your environment.
SQLAssessmentRecommendation | where RecommendationResult == "Failed" | sort by Computer asc | project

Computer, RecommendationId, Recommendation
Here's a screenshot showing the log query:
3. Choose recommendations that you want to ignore. You’ll use the values for RecommendationId in the next
procedure.
To create and use an IgnoreRecommendations.txt text file
1. Create a file named IgnoreRecommendations.txt.
2. Paste or type each RecommendationId for each recommendation that you want Azure Monitor to ignore on a
separate line and then save and close the file.
3. Put the file in the following folder on each computer where you want Azure Monitor to ignore
recommendations.
On computers with the Microsoft Monitoring Agent (connected directly or through Operations
Manager) - SystemDrive:\Program Files\Microsoft Monitoring Agent\Agent
On the Operations Manager management server - SystemDrive:\Program Files\Microsoft System
Center 2012 R2\Operations Manager\Server
On the Operations Manager 2016 management server - SystemDrive:\Program Files\Microsoft System
Center 2016\Operations Manager\Server
To verify that recommendations are ignored
1. After the next scheduled assessment runs, by default every 7 days, the specified recommendations are
marked Ignored and will not appear on the assessment dashboard.
2. You can use the following Log Search queries to list all the ignored recommendations.
SQLAssessmentRecommendation | where RecommendationResult == "Ignored" | sort by Computer asc | project

3. If you decide later that you want to see ignored recommendations, remove any IgnoreRecommendations.txt
files, or you can remove RecommendationIDs from them.
SQL Health Check solution FAQ

How often does a health check run?
The check runs every seven days.
Is there a way to configure how often the check runs?
Not at this time.
If another server is discovered after I’ve added the SQL Health Check solution, will it be checked?
Yes, once it is discovered it is checked from then on, every seven days.
If a server is decommissioned, when will it be removed from the health check?
If a server does not submit data for 3 weeks, it is removed.
What is the name of the process that does the data collection?
AdvisorAssessment.exe
How long does it take for data to be collected?
The actual data collection on the server takes about 1 hour. It may take longer on servers that have a large
number of SQL instances or databases.
What type of data is collected?
The following types of data are collected:
WMI
Registry
SQL dynamic management views (DMV ).
Is there a way to configure when data is collected?
Not at this time.
Why do I have to configure a Run As Account?
For SQL Server, a small number of SQL queries are run. In order for them to run, a Run As Account with VIEW
SERVER STATE permissions to SQL must be used. In addition, in order to query WMI, local administrator
credentials are required.
Why display only the top 10 recommendations?
Instead of giving you an exhaustive overwhelming list of tasks, we recommend that you focus on addressing
the prioritized recommendations first. After you address them, additional recommendations will become
available. If you prefer to see the detailed list, you can view all recommendations using the Log Analytics log
search.
Is there a way to ignore a recommendation?
Yes, see Ignore recommendations section above.
Next steps
Log queries to learn how to analyze detailed SQL Health Check data and recommendations.
Azure networking monitoring solutions in Azure
Monitor
NOTE
PowerShell.
Azure Monitor offers the following solutions for monitoring your networks:
Network Performance Monitor (NPM ) to
Monitor the health of your network
Azure Application Gateway analytics to review
Azure Application Gateway logs
Azure Application Gateway metrics
Solutions to monitor and audit network activity on your cloud network
Traffic Analytics
Azure Network Security Group Analytics
Network Performance Monitor (NPM)

The Network Performance Monitor management solution is a network monitoring solution, that monitors the
health, availability and reachability of networks. It is used to monitor connectivity between:
Public cloud and on-premises
Data centers and user locations (branch offices)
Subnets hosting various tiers of a multi-tiered application.
For more information, see Network Performance Monitor.
Azure Application Gateway and Network Security Group analytics

To use the solutions:
1. Add the management solution to Azure Monitor, and
2. Enable diagnostics to direct the diagnostics to a Log Analytics workspace in Azure Monitor. It is not necessary
to write the logs to Azure Blob storage.
You can enable diagnostics and the corresponding solution for either one or both of Application Gateway and
Networking Security Groups.
If you do not enable diagnostic logging for a particular resource type, but install the solution, the dashboard blades
for that resource are blank and display an error message.
NOTE
In January 2017, the supported way of sending logs from Application Gateways and Network Security Groups to a Log
Analytics workspace changed. If you see the Azure Networking Analytics (deprecated) solution, refer to migrating from
the old Networking Analytics solution for steps you need to follow.
Review Azure networking data collection details

The Azure Application Gateway analytics and the Network Security Group analytics management solutions collect
diagnostics logs directly from Azure Application Gateways and Network Security Groups. It is not necessary to
write the logs to Azure Blob storage and no agent is required for data collection.
The following table shows data collection methods and other details about how data is collected for Azure
Application Gateway analytics and the Network Security Group analytics.
OPERATIONS
SYSTEMS MANAGER
CENTER AGENT DATA
MANAGER MANAGER MANAGEMENT COLLECTION
PLATFORM DIRECT AGENT AGENT AZURE REQUIRED? GROUP FREQUENCY
Azure • when logged
Azure Application Gateway analytics solution in Azure Monitor
The following logs are supported for Application Gateways:

ApplicationGatewayAccessLog
ApplicationGatewayPerformanceLog
ApplicationGatewayFirewallLog
The following metrics are supported for Application Gateways:again
5 minute throughput
Use the following instructions to install and configure the Azure Application Gateway analytics solution:
1. Enable the Azure Application Gateway analytics solution from Azure marketplace or by using the process
described in Add Azure Monitor solutions from the Solutions Gallery.
2. Enable diagnostics logging for the Application Gateways you want to monitor.
Enable Azure Application Gateway diagnostics in the portal
1. In the Azure portal, navigate to the Application Gateway resource to monitor.
2. Select Diagnostics logs to open the following page.
3. Click Turn on diagnostics to open the following page.
4. To turn on diagnostics, click On under Status.

5. Click the checkbox for Send to Log Analytics.
6. Select an existing Log Analytics workspace, or create a workspace.
7. Click the checkbox under Log for each of the log types to collect.
8. Click Save to enable the logging of diagnostics to Azure Monitor.
Enable Azure network diagnostics using PowerShell
The following PowerShell script provides an example of how to enable diagnostic logging for application
gateways.
$gateway = Get-AzApplicationGateway -Name 'ContosoGateway'
Set-AzDiagnosticSetting -ResourceId $gateway.ResourceId -WorkspaceId $workspaceId -Enabled $true
Use Azure Application Gateway analytics
After you click the Azure Application Gateway analytics tile on the Overview, you can view summaries of your
logs and then drill in to details for the following categories:
Application Gateway Access logs
Client and server errors for Application Gateway access logs
Requests per hour for each Application Gateway
Failed requests per hour for each Application Gateway
Errors by user agent for Application Gateways
Application Gateway performance
Host health for Application Gateway
Maximum and 95th percentile for Application Gateway failed requests
On the Azure Application Gateway analytics dashboard, review the summary information in one of the blades,
and then click one to view detailed information on the log search page.
On any of the log search pages, you can view results by time, detailed results, and your log search history. You can
also filter by facets to narrow the results.
Azure Network Security Group analytics solution in Azure Monitor
NOTE
The Network Security Group analytics solution is moving to community support since its functionality has been replaced by
Traffic Analytics.
The solution is now available in Azure Quickstart Templates and will soon no longer be available in the Azure Marketplace.
For existing customers who already added the solution to their workspace, it will continue to function with no changes.
Microsoft will continue to support sending NSG diagnostic logs to your workspace using Diagnostics Settings.
The following logs are supported for network security groups:

NetworkSecurityGroupEvent
NetworkSecurityGroupRuleCounter
Use the following instructions to install and configure the Azure Networking Analytics solution:
1. Enable the Azure Network Security Group analytics solution from Azure marketplace or by using the process
described in Add Azure Monitor solutions from the Solutions Gallery.
2. Enable diagnostics logging for the Network Security Group resources you want to monitor.
Enable Azure network security group diagnostics in the portal
1. In the Azure portal, navigate to the Network Security Group resource to monitor
2. Select Diagnostics logs to open the following page
3. Click Turn on diagnostics to open the following page
4. To turn on diagnostics, click On under Status

5. Click the checkbox for Send to Log Analytics
6. Select an existing Log Analytics workspace, or create a workspace
7. Click the checkbox under Log for each of the log types to collect
8. Click Save to enable the logging of diagnostics to Log Analytics
Enable Azure network diagnostics using PowerShell
The following PowerShell script provides an example of how to enable diagnostic logging for network security
groups
$nsg = Get-AzNetworkSecurityGroup -Name 'ContosoNSG'
Set-AzDiagnosticSetting -ResourceId $nsg.ResourceId -WorkspaceId $workspaceId -Enabled $true
Use Azure Network Security Group analytics

After you click the Azure Network Security Group analytics tile on the Overview, you can view summaries of
your logs and then drill in to details for the following categories:
Network security group blocked flows
Network security group rules with blocked flows
MAC addresses with blocked flows
Network security group allowed flows
Network security group rules with allowed flows
MAC addresses with allowed flows
On the Azure Network Security Group analytics dashboard, review the summary information in one of the
blades, and then click one to view detailed information on the log search page.
On any of the log search pages, you can view results by time, detailed results, and your log search history. You can
also filter by facets to narrow the results.
Migrating from the old Networking Analytics solution

In January 2017, the supported way of sending logs from Azure Application Gateways and Azure Network
Security Groups to a Log Analytics workspace changed. These changes provide the following advantages:
Logs are written directly to Azure Monitor without the need to use a storage account
Less latency from the time when logs are generated to them being available in Azure Monitor
Fewer configuration steps
A common format for all types of Azure diagnostics
To use the updated solutions:
1. Configure diagnostics to be sent directly to Azure Monitor from Azure Application Gateways
2. Configure diagnostics to be sent directly to Azure Monitor from Azure Network Security Groups
3. Enable the Azure Application Gateway Analytics and the Azure Network Security Group Analytics solution by
using the process described in Add Azure Monitor solutions from the Solutions Gallery
4. Update any saved queries, dashboards, or alerts to use the new data type
Type is to AzureDiagnostics. You can use the ResourceType to filter to Azure networking logs.
INSTEAD OF: USE:

INSTEAD OF: USE:
NetworkApplicationgateways | where AzureDiagnostics | where

OperationName=="ApplicationGatewayAccess" ResourceType=="APPLICATIONGATEWAYS" and
OperationName=="ApplicationGatewayAccess"
NetworkApplicationgateways | where AzureDiagnostics | where

OperationName=="ApplicationGatewayPerformance" ResourceType=="APPLICATIONGATEWAYS" and
OperationName=="ApplicationGatewayPerformance"
NetworkSecuritygroups AzureDiagnostics | where

ResourceType=="NETWORKSECURITYGROUPS"
For any field that has a suffix of _s, _d, or _g in the name, change the first character to lower case
For any field that has a suffix of _o in name, the data is split into individual fields based on the nested
field names.
5. Remove the Azure Networking Analytics (Deprecated ) solution.
If you are using PowerShell, use
Set-AzureOperationalInsightsIntelligencePack -ResourceGroupName <resource group that the workspace is
in> -WorkspaceName <name of the log analytics workspace> -IntelligencePackName "AzureNetwork" -
Enabled $false
Data collected before the change is not visible in the new solution. You can continue to query for this data using
the old Type and field names.
Troubleshooting
Troubleshoot Azure Diagnostics
If you receive the following error message, the Microsoft.insights resource provider is not registered:
Failed to update diagnostics for 'resource'. {"code":"Forbidden","message":"Please register the subscription
'subscription id' with Microsoft.Insights."}
To register the resource provider, perform the following steps in the Azure portal:
1. In the navigation pane on the left, click Subscriptions
2. Select the subscription identified in the error message
3. Click Resource Providers
4. Find the Microsoft.insights provider
5. Click the Register link
Once the Microsoft.insights resource provider is registered, retry configuring diagnostics.
In PowerShell, if you receive the following error message, you need to update your version of PowerShell:
Set-AzDiagnosticSetting : A parameter cannot be found that matches parameter name 'WorkspaceId'.
Update your version of Azure PowerShell, follow the instructions in the Install Azure PowerShell article.
Next steps
Use Log queries in Azure Monitor to view detailed Azure diagnostics data.
Gather insights about your DNS infrastructure with
the DNS Analytics Preview solution
This article describes how to set up and use the Azure DNS Analytics solution in Azure Monitor to gather insights
into DNS infrastructure on security, performance, and operations.
DNS Analytics helps you to:
Identify clients that try to resolve malicious domain names.
Identify stale resource records.
Identify frequently queried domain names and talkative DNS clients.
View request load on DNS servers.
View dynamic DNS registration failures.
The solution collects, analyzes, and correlates Windows DNS analytic and audit logs and other related data from
your DNS servers.
Connected sources
The following table describes the connected sources that are supported by this solution:
Windows agents Yes The solution collects DNS information

from Windows agents.
Linux agents No The solution does not collect DNS

information from direct Linux agents.
System Center Operations Manager Yes The solution collects DNS information
management group from agents in a connected Operations
Manager management group. A direct
connection from the Operations
Manager agent to Azure Monitor is not
required. Data is forwarded from the
management group to the Log
Azure storage account No Azure storage isn't used by the solution.
Data collection details

The solution collects DNS inventory and DNS event-related data from the DNS servers where a Log Analytics
agent is installed. This data is then uploaded to Azure Monitor and displayed in the solution dashboard. Inventory-
related data, such as the number of DNS servers, zones, and resource records, is collected by running the DNS
PowerShell cmdlets. The data is updated once every two days. The event-related data is collected near real time
from the analytic and audit logs provided by enhanced DNS logging and diagnostics in Windows Server 2012 R2.
Configuration
Use the following information to configure the solution:
You must have a Windows or Operations Manager agent on each DNS server that you want to monitor.
You can add the DNS Analytics solution to your Log Analytics workspace from the Azure Marketplace. You can
also use the process described in Add Azure Monitor solutions from the Solutions Gallery.
The solution starts collecting data without the need of further configuration. However, you can use the following
configuration to customize data collection.
Configure the solution
On the solution dashboard, click Configuration to open the DNS Analytics Configuration page. There are two
types of configuration changes that you can make:
Whitelisted Domain Names. The solution does not process all the lookup queries. It maintains a whitelist
of domain name suffixes. The lookup queries that resolve to the domain names that match domain name
suffixes in this whitelist are not processed by the solution. Not processing whitelisted domain names helps
to optimize the data sent to Azure Monitor. The default whitelist includes popular public domain names,
such as www.google.com and www.facebook.com. You can view the complete default list by scrolling.
You can modify the list to add any domain name suffix that you want to view lookup insights for. You can
also remove any domain name suffix that you don't want to view lookup insights for.
Talkative Client Threshold. DNS clients that exceed the threshold for the number of lookup requests are
highlighted in the DNS Clients blade. The default threshold is 1,000. You can edit the threshold.
Management packs
If you are using the Microsoft Monitoring Agent to connect to your Log Analytics workspace, the following
management pack is installed:
Microsoft DNS Data Collector Intelligence Pack (Microsoft.IntelligencePacks.Dns)
If your Operations Manager management group is connected to your Log Analytics workspace, the following
management packs are installed in Operations Manager when you add this solution. There is no required
configuration or maintenance of these management packs:
Microsoft DNS Data Collector Intelligence Pack (Microsoft.IntelligencePacks.Dns)
Microsoft System Center Advisor DNS Analytics Configuration (Microsoft.IntelligencePack.Dns.Configuration)
Analytics.
Use the DNS Analytics solution

Data collected by this monitoring solution is available in the Azure Monitor Overview page in the Azure portal.
Open this page from the Azure Monitor menu by clicking More under the Insights section. Each solution is
represented by a tile. Click on a tile for more detailed data collected by that solution.
The DNS tile includes the number of DNS servers where the data is being collected. It also includes the number of
requests made by clients to resolve malicious domains in the past 24 hours. When you click the tile, the solution
dashboard opens.
Solution dashboard
The solution dashboard shows summarized information for the various features of the solution. It also includes
links to the detailed view for forensic analysis and diagnosis. By default, the data is shown for the last seven days.
You can change the date and time range by using the date-time selection control, as shown in the following
image:
The solution dashboard shows the following blades:

DNS Security. Reports the DNS clients that are trying to communicate with malicious domains. By using
Microsoft threat intelligence feeds, DNS Analytics can detect client IPs that are trying to access malicious domains.
In many cases, malware-infected devices "dial out" to the "command and control" center of the malicious domain
by resolving the malware domain name.
When you click a client IP in the list, Log Search opens and shows the lookup details of the respective query. In the
following example, DNS Analytics detected that the communication was done with an IRCbot:
The information helps you to identify the:
Client IP that initiated the communication.
Domain name that resolves to the malicious IP.
IP addresses that the domain name resolves to.
Malicious IP address.
Severity of the issue.
Reason for blacklisting the malicious IP.
Detection time.
Domains Queried. Provides the most frequent domain names being queried by the DNS clients in your
environment. You can view the list of all the domain names queried. You can also drill down into the lookup request
details of a specific domain name in Log Search.
DNS Clients. Reports the clients breaching the threshold for number of queries in the chosen time period. You can
view the list of all the DNS clients and the details of the queries made by them in Log Search.
Dynamic DNS Registrations. Reports name registration failures. All registration failures for address resource
records (Type A and AAAA) are highlighted along with the client IPs that made the registration requests. You can
then use this information to find the root cause of the registration failure by following these steps:
1. Find the zone that is authoritative for the name that the client is trying to update.
2. Use the solution to check the inventory information of that zone.
3. Verify that the dynamic update for the zone is enabled.
4. Check whether the zone is configured for secure dynamic update or not.
Name registration requests. The upper tile shows a trendline of successful and failed DNS dynamic update
requests. The lower tile lists the top 10 clients that are sending failed DNS update requests to the DNS servers,
sorted by the number of failures.
Sample DDI Analytics Queries. Contains a list of the most common search queries that fetch raw analytics data
directly.
You can use these queries as a starting point for creating your own queries for customized reporting. The queries
link to the DNS Analytics Log Search page where results are displayed:
List of DNS Servers. Shows a list of all DNS servers with their associated FQDN, domain name, forest
name, and server IPs.
List of DNS Zones. Shows a list of all DNS zones with the associated zone name, dynamic update status,
name servers, and DNSSEC signing status.
Unused Resource Records. Shows a list of all the unused/stale resource records. This list contains the
resource record name, resource record type, the associated DNS server, record generation time, and zone
name. You can use this list to identify the DNS resource records that are no longer in use. Based on this
information, you can then remove those entries from the DNS servers.
DNS Servers Query Load. Shows information so that you can get a perspective of the DNS load on your
DNS servers. This information can help you plan the capacity for the servers. You can go to the Metrics tab
to change the view to a graphical visualization. This view helps you understand how the DNS load is
distributed across your DNS servers. It shows DNS query rate trends for each server.
DNS Zones Query Load. Shows the DNS zone-query-per-second statistics of all the zones on the DNS
servers being managed by the solution. Click the Metrics tab to change the view from detailed records to a
graphical visualization of the results.
Configuration Events. Shows all the DNS configuration change events and associated messages. You can
then filter these events based on time of the event, event ID, DNS server, or task category. The data can help
you audit changes made to specific DNS servers at specific times.
DNS Analytical Log. Shows all the analytic events on all the DNS servers managed by the solution. You
can then filter these events based on time of the event, event ID, DNS server, client IP that made the lookup
query, and query type task category. DNS server analytic events enable activity tracking on the DNS server.
An analytic event is logged each time the server sends or receives DNS information.
Search by using DNS Analytics Log Search
On the Log Search page, you can create a query. You can filter your search results by using facet controls. You can
also create advanced queries to transform, filter, and report on your results. Start by using the following queries:
1. In the search query box, type DnsEvents to view all the DNS events generated by the DNS servers
managed by the solution. The results list the log data for all events related to lookup queries, dynamic
registrations, and configuration changes.
a. To view the log data for lookup queries, select LookUpQuery as the Subtype filter from the facet control
on the left. A table that lists all the lookup query events for the selected time period is displayed.
b. To view the log data for dynamic registrations, select DynamicRegistration as the Subtype filter from
the facet control on the left. A table that lists all the dynamic registration events for the selected time period
is displayed.
c. To view the log data for configuration changes, select ConfigurationChange as the Subtype filter from
the facet control on the left. A table that lists all the configuration change events for the selected time period
is displayed.
2. In the search query box, type DnsInventory to view all the DNS inventory-related data for the DNS
servers managed by the solution. The results list the log data for DNS servers, DNS zones, and resource
records.
Troubleshooting
Common troubleshooting steps:
1. Missing DNS Lookups Data - To troubleshoot this issue, try resetting the config or just loading the
configuration page once in portal. For resetting, just change a setting to another value, then change it back to to
the original value, and save the config.
Feedback
To provide feedback, visit the Log Analytics UserVoice page to post ideas for DNS Analytics features to work on.
Next steps
Query logs to view detailed DNS log records.
Network Performance Monitor solution in Azure
Network Performance Monitor is a cloud-based hybrid network monitoring solution that helps you monitor
network performance between various points in your network infrastructure. It also helps you monitor network
connectivity to service and application endpoints and monitor the performance of Azure ExpressRoute.
Network Performance Monitor detects network issues like traffic blackholing, routing errors, and issues that
conventional network monitoring methods aren't able to detect. The solution generates alerts and notifies you
when a threshold is breached for a network link. It also ensures timely detection of network performance issues
and localizes the source of the problem to a particular network segment or device.
Network Performance Monitor offers three broad capabilities:
Performance Monitor: You can monitor network connectivity across cloud deployments and on-premises
locations, multiple data centers, and branch offices and mission-critical multitier applications or
microservices. With Performance Monitor, you can detect network issues before users complain.
Service Connectivity Monitor: You can monitor the connectivity from your users to the services you care
about, determine what infrastructure is in the path, and identify where network bottlenecks occur. You can
know about outages before your users, and see the exact location of the issues along your network path.
This capability helps you perform tests based on HTTP, HTTPS, TCP, and ICMP to monitor in near real
time or historically the availability and response time of your service. You also can monitor the contribution
of the network in packet loss and latency. With a network topology map, you can isolate network
slowdowns. You can identify problem spots that occur along the network path from the node to the service,
with latency data on each hop. With built-in tests, you can monitor network connectivity to Office 365 and
Dynamics CRM without any preconfiguration. With this capability, you can monitor network connectivity to
any TCP -capable endpoint, such as websites, SaaS applications, PaaS applications, and SQL databases.
ExpressRoute Monitor: Monitor end-to-end connectivity and performance between your branch offices and
Azure, over Azure ExpressRoute.
More information on the various capabilities supported by Network Performance Monitor is available online.
Supported Regions
NPM can monitor connectivity between networks and applications in any part of the world, from a workspace
that is hosted in one of the following regions:
West Europe
West Central US
East US
East Japan
South East Asia
South East Australia
South UK
Central India
US Government Virginia
The list of supported regions for ExpressRoute Monitor is available in the documentation.
Set up and configure

Install and configure agents
Use the basic processes to install agents at Connect Windows computers to Azure Monitor and Connect
Operations Manager to Azure Monitor.
Where to install the agents
Performance Monitor: Install Log Analytics agents on at least one node connected to each subnetwork
from which you want to monitor network connectivity to other subnetworks.
To monitor a network link, install agents on both endpoints of that link. If you're unsure about the topology
of your network, install the agents on servers with critical workloads between which you want to monitor
the network performance. For example, if you want to monitor the network connection between a web
server and a server running SQL, install an agent on both servers. Agents monitor network connectivity
(links) between hosts, not the hosts themselves.
Service Connectivity Monitor: Install an Log Analytics agent on each node from which you want to
monitor the network connectivity to the service endpoint. An example is if you want to monitor network
connectivity to Office 365 from your office sites labeled O1, O2, and O3. Install the Log Analytics agent on
at least one node each in O1, O2, and O3.
ExpressRoute Monitor: Install at least one Log Analytics agent in your Azure virtual network. Also install
at least one agent in your on-premises subnetwork, which is connected through ExpressRoute private
peering.
Configure Log Analytics agents for monitoring
Network Performance Monitor uses synthetic transactions to monitor network performance between source and
destination agents. You can choose between TCP and ICMP as the protocol for monitoring in Performance
Monitor and Service Connectivity Monitor capabilities. Only TCP is available as the monitoring protocol for
ExpressRoute Monitor. Make sure that the firewall allows communication between the Log Analytics agents used
for monitoring on the protocol you choose.
TCP protocol: If you choose TCP as the protocol for monitoring, open the firewall port on the agents used
for Network Performance Monitor and ExpressRoute Monitor to make sure that the agents can connect to
each other. To open the port, run the EnableRules.ps1 PowerShell script without any parameters in a
PowerShell window with administrative privileges.
The script creates registry keys required by the solution. It also creates Windows Firewall rules to allow
agents to create TCP connections with each other. The registry keys created by the script specify whether to
log the debug logs and the path for the logs file. The script also defines the agent TCP port used for
communication. The values for these keys are automatically set by the script. Don't manually change these
keys. The port opened by default is 8084. You can use a custom port by providing the parameter
portNumber to the script. Use the same port on all the computers where the script is run.
NOTE
The script configures only Windows Firewall locally. If you have a network firewall, make sure that it allows traffic
destined for the TCP port used by Network Performance Monitor.
NOTE
You don't need to run the EnableRules.ps1 PowerShell script for Service Connectivity Monitor.
ICMP protocol: If you choose ICMP as the protocol for monitoring, enable the following firewall rules to
reliably utilize ICMP:
netsh advfirewall firewall add rule name="NPMDICMPV4Echo" protocol="icmpv4:8,any" dir=in action=allow

netsh advfirewall firewall add rule name="NPMDICMPV4DestinationUnreachable" protocol="icmpv4:3,any"
dir=in action=allow
netsh advfirewall firewall add rule name="NPMDICMPV6DestinationUnreachable" protocol="icmpv6:1,any"
dir=in action=allow
netsh advfirewall firewall add rule name="NPMDICMPV4TimeExceeded" protocol="icmpv4:11,any" dir=in
action=allow
netsh advfirewall firewall add rule name="NPMDICMPV6TimeExceeded" protocol="icmpv6:3,any" dir=in
action=allow
Configure the solution

1. Add the Network Performance Monitor solution to your workspace from the Azure marketplace. You also
can use the process described in Add Azure Monitor solutions from the Solutions Gallery.
2. Open your Log Analytics workspace, and select the Overview tile.
3. Select the Network Performance Monitor tile with the message Solution requires additional
configuration.
4. On the Setup page, you see the option to install Log Analytics agents and configure the agents for
monitoring in the Common Settings view. As previously explained, if you installed and configured Log
Analytics agents, select the Setup view to configure the capability you want to use.
Performance Monitor: Choose the protocol to use for synthetic transactions in the Default Performance
Monitor rule, and select Save & Continue. This protocol selection only holds for the system-generated
default rule. You need to choose the protocol each time you create a Performance Monitor rule explicitly.
You can always move to the Default rule settings on the Performance Monitor tab (it appears after you
complete your day-0 configuration) and change the protocol later. If you don't want the Performance
Monitor capability, you can disable the default rule from the Default rule settings on the Performance
Monitor tab.
Service Connectivity Monitor: The capability provides built-in preconfigured tests to monitor network
connectivity to Office 365 and Dynamics 365 from your agents. Choose the Office 365 and Dynamics 365
services that you want to monitor by selecting the check boxes beside them. To choose the agents from
which you want to monitor, select Add Agents. If you don't want to use this capability or want to set it up
later, don't choose anything and select Save & Continue.
ExpressRoute Monitor: Select Discover Now to discover all the ExpressRoute private peerings that are
connected to the virtual networks in the Azure subscription linked with this Log Analytics workspace.
After the discovery is finished, the discovered circuits and peerings are listed in a table.
The monitoring for these circuits and peerings is initially in a disabled state. Select each resource that you want to
monitor, and configure monitoring for them from the details view on the right. Select Save to save the
configuration. To learn more, see the "Configure ExpressRoute monitoring" article.
After the setup is finished, it takes 30 minutes to an hour for the data to populate. While the solution aggregates
data from your network, you see the message Solution requires additional configuration on the Network
Performance Monitor Overview tile. After the data is collected and indexed, the Overview tile changes and
informs you of your network health in a summary. You then can edit the monitoring of the nodes on which Log
Analytics agents are installed, as well as the subnets discovered from your environment.
Edit monitoring settings for subnets and nodes
All subnets with at least one agent installed are listed on the Subnetworks tab on the configuration page.
To enable or disable monitoring of particular subnetworks:
1. Select or clear the check box next to the subnetwork ID. Then make sure that Use for Monitoring is selected
or cleared, as appropriate. You can select or clear multiple subnets. When disabled, subnetworks aren't
monitored, and the agents are updated to stop pinging other agents.
2. Choose the nodes that you want to monitor in a particular subnetwork. Select the subnetwork from the list,
and move the required nodes between the lists that contain unmonitored and monitored nodes. You can add a
custom description to the subnetwork.
3. Select Save to save the configuration.
Choose nodes to monitor
All the nodes that have an agent installed on them are listed on the Nodes tab.
1. Select or clear the nodes that you want to monitor or stop monitoring.
2. Select Use for Monitoring, or clear it, as appropriate.
3. Select Save.
Configure the capabilities you want:
Performance Monitor
ExpressRoute Monitor
Data collection details

To collect loss and latency information, Network Performance Monitor uses TCP SYN -SYNACK-ACK handshake
packets when you choose TCP as the protocol. Network Performance Monitor uses ICMP ECHO ICMP ECHO
REPLY when you choose ICMP as the protocol. Trace route is also used to get topology information.
The following table shows data collection methods and other details about how data is collected for Network
Performance Monitor.
OPERATIONS
SYSTEM MANAGER
CENTER AGENT DATA
MANAGER AZURE MANAGER MANAGEMENT COLLECTION
PLATFORM DIRECT AGENT AGENT STORAGE REQUIRED? GROUP FREQUENCY
Windows • • TCP
handshakes/I
CMP ECHO
messages
every 5
seconds, data
sent every 3
minutes
The solution uses synthetic transactions to assess the health of the network. Log Analytics agents installed at
various points in the network exchange TCP packets or ICMP Echo with one another. Whether the agents use TCP
packets or ICMP Echo depends on the protocol you selected for monitoring. In the process, agents learn the
round-trip time and packet loss, if any. Periodically, each agent also performs a trace route to other agents to find
all the various routes in the network that must be tested. Using this data, the agents can deduce the network
latency and packet loss figures. The tests are repeated every five seconds. Data is aggregated for about three
minutes by the agents before it's uploaded to the Log Analytics workspace in Azure Monitor.
NOTE
Although agents communicate with each other frequently, they don't generate significant network traffic while conducting
the tests. Agents rely only on TCP SYN-SYNACK-ACK handshake packets to determine the loss and latency. No data packets
are exchanged. During this process, agents communicate with each other only when needed. The agent communication
topology is optimized to reduce network traffic.
Use the solution

Network Performance Monitor Overview tile
After you enable the Network Performance Monitor solution, the solution tile on the Overview page provides a
quick overview of the network health.
Network Performance Monitor dashboard
Top Network Health Events: This page provides a list of the most recent health events and alerts in the
system and the time since the events have been active. A health event or alert is generated whenever the
value of the chosen metric (loss, latency, response time, or bandwidth utilization) for the monitoring rule
exceeds the threshold.
ExpressRoute Monitor: This page provides health summaries for the various ExpressRoute peering
connections the solution monitors. The Topology tile shows the number of network paths through the
ExpressRoute circuits that are monitored in your network. Select this tile to go to the Topology view.
Service Connectivity Monitor: This page provides health summaries for the different tests you created.
The Topology tile shows the number of endpoints that are monitored. Select this tile to go to the
Topology view.
Performance Monitor: This page provides health summaries for the Network links and Subnetwork
links that the solution monitors. The Topology tile shows the number of network paths that are monitored
in your network. Select this tile to go to the Topology view.
Common Queries: This page contains a set of search queries that fetch raw network monitoring data
directly. You can use these queries as a starting point to create your own queries for customized reporting.
Drill down for depth

You can select various links on the solution dashboard to drill down deeper into any area of interest. For example,
when you see an alert or an unhealthy network link appear on the dashboard, select it to investigate further. A
page lists all the subnetwork links for the particular network link. You can see the loss, latency, and health status of
each subnetwork link. You can quickly find out which subnetwork link causes problems. Select View node links
to see all the node links for the unhealthy subnet link. Then, you can see individual node-to-node links and find
the unhealthy node links.
Select View topology to view the hop-by-hop topology of the routes between the source and destination nodes.
The unhealthy routes appear in red. You can view the latency contributed by each hop so that you can quickly
identify the problem to a particular portion of the network.
Network State Recorder control
Each view displays a snapshot of your network health at a particular point in time. By default, the most recent
state is shown. The bar at the top of the page shows the point in time for which the state is displayed. To view a
snapshot of your network health at a previous time, select Actions. You also can enable or disable auto-refresh
for any page while you view the latest state.
Trend charts
At each level that you drill down, you can see the trend of the applicable metric. It can be loss, latency, response
time, or bandwidth utilization. To change the time interval for the trend, use the time control at the top of the
chart.
Trend charts show you a historical perspective of the performance of a performance metric. Some network issues
are transient in nature and are hard to catch by looking at only the current state of the network. Issues can surface
quickly and disappear before anyone notices, only to reappear at a later point in time. Such transient issues also
can be difficult for application administrators. The issues often show up as unexplained increases in application
response time, even when all application components appear to run smoothly.
You can easily detect these kinds of issues by looking at a trend chart. The issue appears as a sudden spike in
network latency or packet loss. To investigate the issue, use the Network State Recorder control to view the
network snapshot and topology for that point in time when the issue occurred.
Topology map
Network Performance Monitor shows you the hop-by-hop topology of routes between the source and destination
endpoint on an interactive topology map. To view the topology map, select the Topology tile on the solution
dashboard. You also can select the View topology link on the drill-down pages.
The topology map displays how many routes are between the source and destination and what paths the data
packets take. The latency contributed by each network hop is also visible. All the paths for which the total path
latency is above the threshold (set in the corresponding monitoring rule) are shown in red.
When you select a node or hover over it on the topology map, you see the node properties, such as FQDN and IP
address. Select a hop to see its IP address. You can identify the troublesome network hop by noticing the latency it
contributes. To filter particular routes, use the filters in the collapsible action pane. To simplify the network
topologies, hide the intermediate hops by using the slider in the action pane. You can zoom in or zoom out of the
topology map by using your mouse wheel.
The topology shown in the map is layer 3 topology and doesn't contain layer 2 devices and connections.
Log queries in Azure Monitor

All data that is exposed graphically through the Network Performance Monitor dashboard and drill-down pages is
also available natively in log queries. You can perform interactive analysis of data in the repository and correlate
data from different sources. You also can create custom alerts and views and export the data to Excel, Power BI, or
a shareable link. The Common Queries area in the dashboard has some useful queries that you can use as the
starting point to create your own queries and reports.
Alerts
Network Performance Monitor uses the alerting capabilities of Azure Monitor.
This means that all notifications are managed using action groups.
If you are an NPM user creating an alert via Log Analytics:
1. You will see a link that will redirect you to Azure portal. Click it to access the portal.
2. Click the Network Performance Monitor solution tile.
3. Navigate to Configure.
4. Select the test you want to create an alert on and follow the below mentioned steps.
If you are an NPM user creating an alert via Azure portal:
1. You can choose to enter your email directly or you can choose to create alerts via action groups.
2. If you choose to enter your email directly, an action group with the name NPM Email ActionGroup is
created and the email id is added to that action group.
3. If you choose to use action groups, you will have to select an previously created action group. You can learn
how to create an action group here.
4. Once the alert is successfully created, you can use Manage Alerts link to manage your alerts.
Each time you create an alert, NPM creates a query based log alert rule in Azure Monitor. This query is triggered
every 5 mins by default. Azure monitor does not charge for the first 250 log alert rules created, and any alert rules
above the 250 log alert rules limit will be billed as per Alerts pricing in Azure Monitor pricing page. Notifications
are charged separately as per Notifications pricing in Azure Monitor pricing page.
Pricing
Information on pricing is available online.
Provide feedback
UserVoice: You can post your ideas for Network Performance Monitor features that you want us to work
on. Visit the UserVoice page.
Join our cohort: We're always interested in having new customers join our cohort. As part of it, you get
early access to new features and an opportunity to help us improve Network Performance Monitor. If
you're interested in joining, fill out this quick survey.
Next steps
Learn more about Performance Monitor, Service Connectivity Monitor, and ExpressRoute Monitor.
Network Performance Monitor solution: Performance
monitoring
The Performance Monitor capability in Network Performance Monitor helps you monitor network connectivity
across various points in your network. You can monitor cloud deployments and on-premises locations, multiple
data centers and branch offices, and mission-critical multitier applications or microservices. With Performance
Monitor, you can detect network issues before your users complain. Key advantages are that you can:
Monitor loss and latency across various subnets and set alerts.
Monitor all paths (including redundant paths) on the network.
Troubleshoot transient and point-in-time network issues, which are difficult to replicate.
Determine the specific segment on the network, which is responsible for degraded performance.
Monitor the health of the network, without the need for SNMP.
Configuration
To open the configuration for Network Performance Monitor, open the Network Performance Monitor solution,
and select Configure.
Create new networks

A network in Network Performance Monitor is a logical container for subnets. It helps you organize the monitoring
of your network infrastructure according to your needs. You can create a network with a friendly name and add
subnets to it according to your business logic. For example, you can create a network named London and add all
the subnets in your London data center. Or you can create a network named ContosoFrontEnd and add to this
network all the subnets named Contoso that serve the front end of your app. The solution automatically creates a
default network, which contains all the subnets discovered in your environment.
Whenever you create a network, you add a subnet to it. Then that subnet is removed from the default network. If
you delete a network, all its subnets are automatically returned to the default network. The default network acts as
a container for all the subnets that aren't contained in any user-defined network. You can't edit or delete the default
network. It always remains in the system. You can create as many custom networks as you need. In most cases, the
subnets in your organization are arranged in more than one network. Create one or more networks to group your
subnets for your business logic.
To create a new network:
1. Select the Networks tab.
2. SelectAdd network, and then enter the network name and description.
3. Select one or more subnets, and then select Add.
Create monitoring rules
Performance Monitor generates health events when the threshold of the performance of network connections
between two subnetworks or between two networks is breached. The system can learn these thresholds
automatically. You also can provide custom thresholds. The system automatically creates a default rule, which
generates a health event whenever loss or latency between any pair of network or subnetwork links breaches the
system-learned threshold. This process helps the solution monitor your network infrastructure until you haven't
created any monitoring rules explicitly. If the default rule is enabled, all the nodes send synthetic transactions to all
the other nodes that you enabled for monitoring. The default rule is useful with small networks. An example is a
scenario where you have a small number of servers running a microservice and you want to make sure that all the
servers have connectivity to each other.
NOTE
We recommend that you disable the default rule and create custom monitoring rules, especially with large networks where
you use a large number of nodes for monitoring. Custom monitoring rules can reduce the traffic generated by the solution
and help you organize the monitoring of your network.
Create monitoring rules according to your business logic. An example is if you want to monitor the performance of
the network connectivity of two office sites to headquarters. Group all the subnets in office site1 in network O1.
Then group all the subnets in office site2 in network O2. Finally, group all the subnets in the headquarters in
network H. Create two monitoring rules--one between O1 and H and the other between O2 and H.
To create custom monitoring rules:
1. Select Add Rule on the Monitor tab, and enter the rule name and description.
2. Select the pair of network or subnetwork links to monitor from the lists.
3. Select the network that contains the subnetworks you want from the network drop-down list. Then select the
subnetworks from the corresponding subnetwork drop-down list. If you want to monitor all the subnetworks in
a network link, select All subnetworks. Similarly, select the other subnetworks you want. To exclude
monitoring for particular subnetwork links from the selections you made, select Add Exception.
4. Choose between ICMP and TCP protocolsto execute synthetic transactions.
5. If you don't want to create health events for the items you selected, clear Enable Health Monitoring on the
links covered by this rule.
6. Choose monitoring conditions. To set custom thresholds for health-event generation, enter threshold values.
Whenever the value of the condition exceeds its selected threshold for the selected network or subnetwork pair,
a health event is generated.
After you save a monitoring rule, you can integrate that rule with Alert Management by selecting Create Alert. An
alert rule is automatically created with the search query. Other required parameters are automatically filled in.
Using an alert rule, you can receive e-mail-based alerts, in addition to the existing alerts within Network
Performance Monitor. Alerts also can trigger remedial actions with runbooks, or they can integrate with existing
service management solutions by using webhooks. Select Manage Alert to edit the alert settings.
You can now create more Performance Monitor rules or move to the solution dashboard to use the capability.
Choose the protocol
Network Performance Monitor uses synthetic transactions to calculate network performance metrics like packet
loss and link latency. To understand this concept better, consider a Network Performance Monitor agent connected
to one end of a network link. This Network Performance Monitor agent sends probe packets to a second Network
Performance Monitor agent connected to another end of the network. The second agent replies with response
packets. This process repeats a few times. By measuring the number of replies and the time taken to receive each
reply, the first Network Performance Monitor agent assesses link latency and packet drops.
The format, size, and sequence of these packets is determined by the protocol that you choose when you create
monitoring rules. Based on the protocol of the packets, the intermediate network devices, such as routers and
switches, might process these packets differently. Consequently, your protocol choice affects the accuracy of the
results. Your protocol choice also determines whether you must take any manual steps after you deploy the
Network Performance Monitor solution.
Network Performance Monitor offers you the choice between ICMP and TCP protocols for executing synthetic
transactions. If you choose ICMP when you create a synthetic transaction rule, the Network Performance Monitor
agents use ICMP ECHO messages to calculate the network latency and packet loss. ICMP ECHO uses the same
message that's sent by the conventional ping utility. When you use TCP as the protocol, Network Performance
Monitor agents send TCP SYN packets over the network. This step is followed by a TCP handshake completion,
and the connection is removed by using RST packets.
Consider the following information before you choose a protocol:
Discovery of multiple network routes. TCP is more accurate when discovering multiple routes, and it
needs fewer agents in each subnet. For example, one or two agents that use TCP can discover all redundant
paths between subnets. You need several agents that use ICMP to achieve similar results. Using ICMP, if
you havea number of routes between two subnets, you need more than 5Nagents in either a source or
destination subnet.
Accuracy of results. Routers and switches tend to assign lower priority to ICMP ECHO packets compared
to TCP packets. In certain situations, when network devices are heavily loaded, the data obtained by TCP
more closely reflects the loss and latency experienced by applications. This occurs because most of the
application traffic flows over TCP. In such cases, ICMP provides less-accurate results compared to TCP.
Firewall configuration. TCP protocol requires that TCP packets are sent to a destination port. The default
port used by Network Performance Monitor agents is 8084. You can change the port when you configure
agents. Make sure that your network firewalls or network security group (NSG ) rules (in Azure) allow traffic
on the port. You also need to make sure that the local firewall on the computers where agents are installed is
configured to allow traffic on this port. You can use PowerShell scripts to configure firewall rules on your
computers running Windows, but you need to configure your network firewall manually. In contrast, ICMP
doesn't operate by using a port. In most enterprise scenarios, ICMP traffic is permitted through the firewalls
to allow you to use network diagnostics tools like the ping utility. If you can ping one machine from another,
you can use the ICMP protocol without having to configure firewalls manually.
NOTE
Some firewalls might block ICMP, which might lead to retransmission that results in a large number of events in your security
information and event management system. Make sure the protocol that you choose isn't blocked by a network firewall or
NSG. Otherwise, Network Performance Monitor can't monitor the network segment. We recommend that you use TCP for
monitoring. Use ICMP in scenarios where you can't use TCP, such as when:
You use Windows client-based nodes, because TCP raw sockets aren't allowed in Windows clients.
Your network firewall or NSG blocks TCP.
You don't know how to switch the protocol.
If you chose to use ICMP during deployment, you can switch to TCP at any time by editing the default monitoring
rule.
1. Go to Network Performance>Monitor>Configure>Monitor. Then selectDefault rule.
2. Scroll to the Protocol section, and select the protocol that you want to use.
3. Select Save to apply the setting.
Even if the default rule uses a specific protocol, you can create new rules with a different protocol. You can even
create a mix of rules where some rules use ICMP and others use TCP.
Walkthrough
Now look at a simple investigation into the root cause for a health event.
On the solution dashboard, a health event shows that a network link is unhealthy. To investigate the issue, select
the Network links being monitored tile.
The drill-down page shows that the DMZ2-DMZ1 network link is unhealthy. Select View subnet links for this
network link.
The drill-down page shows all the subnetwork links in the DMZ2-DMZ1 network link. For both subnetwork links,
the latency crossed the threshold, which makes the network link unhealthy. You also can see the latency trends of
both subnetwork links. Use the time selection control in the graph to focus on the required time range. You can see
the time of day when latency reached its peak. Search the logs later for this time period to investigate the issue.
Select View node links to drill down further.
Similar to the previous page, the drill-down page for the particular subnetwork link lists its constituent node links.
You can perform similar actions here as you did in the previous step. Select View topology to view the topology
between the two nodes.
All the paths between the two selected nodes are plotted in the topology map. You can visualize the hop-by-hop
topology of routes between two nodes on the topology map. It gives you a clear picture of how many routes exist
between the two nodes and what paths the data packets take. Network performance bottlenecks are shown in red.
To locate a faulty network connection or a faulty network device, look at the red elements on the topology map.
You can review the loss, latency, and the number of hops in each path in the Action pane. Use the scrollbar to view
the details of the unhealthy paths. Use the filters to select the paths with the unhealthy hop so that the topology for
only the selected paths is plotted. To zoom in or out of the topology map, use your mouse wheel.
In the following image, the root cause of the problem areas to the specific section of the network appear in the red
paths and hops. Select a node in the topology map to reveal the properties of the node, which includes the FQDN
and IP address. Selecting a hop shows the IP address of the hop.
Next steps
Search logs to view detailed network performance data records.
You can use the Service Connectivity Monitor capability in Network Performance Monitor to monitor network
connectivity to any endpoint that has an open TCP port. Such endpoints include websites, SaaS applications, PaaS
applications, and SQL databases.
You can perform the following functions with Service Connectivity Monitor:
Monitor the network connectivity to your applications and network services from multiple branch offices or
locations. Applications and network services include Office 365, Dynamics CRM, internal line-of-business
applications, and SQL databases.
Use built-in tests to monitor network connectivity to Office 365 and Dynamics 365 endpoints.
Determine the response time, network latency, and packet loss experienced when connecting to the endpoint.
Determine whether poor application performance is because of the network or because of some issue on the
application provider's end.
Identify hot spots on the network that might be causing poor application performance by viewing the latency
contributed by each hop on a topology map.
Configuration
To open the configuration for Network Performance Monitor, open the Network Performance Monitor solution
Configure Log Analytics agents for monitoring

Enable the following firewall rules on the nodes used for monitoring so that the solution can discover the topology
from your nodes to the service endpoint:
netsh advfirewall firewall add rule name="NPMDICMPV4DestinationUnreachable" protocol="icmpv4:3,any" dir=in
action=allow
netsh advfirewall firewall add rule name="NPMDICMPV6DestinationUnreachable" protocol="icmpv6:1,any" dir=in
action=allow
netsh advfirewall firewall add rule name="NPMDICMPV4TimeExceeded" protocol="icmpv4:11,any" dir=in action=allow
netsh advfirewall firewall add rule name="NPMDICMPV6TimeExceeded" protocol="icmpv6:3,any" dir=in action=allow
Create Service Connectivity Monitor tests

Start creating your tests to monitor network connectivity to the service endpoints.
1. Select the Service Connectivity Monitor tab.
2. Select Add Test, and enter the test name and description. You can create maximum 450 tests per
workspace.
3. Select the type of test:
Select Web to monitor connectivity to a service that responds to HTTP/S requests, such as
outlook.office365.com or bing.com.
Select Network to monitor connectivity to a service that responds to TCP requests but doesn't respond
to HTTP/S requests, such as a SQL server, FTP server, or SSH port.
For example: To create a web test to a blob storage account, select Web and enter target as
yourstorageaccount.blob.core.windows.net. Similarly you can create tests for other table storage, queue
storage and Azure Files using this link.
4. If you don't want to perform network measurements, such as network latency, packet loss, and topology
discovery, clear the Perform network measurements check box. Keep it selected to get maximum benefit
from the capability.
5. In Target, enter the URL/FQDN/IP address to which you want to monitor network connectivity.
6. In Port number, enter the port number of the target service.
7. In Test Frequency, enter a value for how frequently you want the test to run.
8. Select the nodes from which you want to monitor the network connectivity to service. Ensure that the
number of agents added per test is less than 150. Any agent can test maximum 150 endpoints/agents.
NOTE
For Windows server-based nodes, the capability uses TCP-based requests to perform the network measurements. For
Windows client-based nodes, the capability uses ICMP-based requests to perform the network measurements. In
some cases, the target application blocks incoming ICMP-based requests when the nodes are Windows client-based.
The solution is unable to perform network measurements. We recommend that you use Windows server-based
nodes in such cases.
9. If you don't want to create health events for the items you select, clear Enable Health Monitoring in the
targets covered by this test.
10. Choose monitoring conditions. You can set custom thresholds for health-event generation by entering
threshold values. Whenever the value of the condition goes above its selected threshold for the selected
network or subnetwork pair, a health event is generated.
Walkthrough
Go to the Network Performance Monitor dashboard view. To get a summary of the health of the different tests you
created, look at the Service Connectivity Monitor page.
Select the tile to view the details of the tests on the Tests page. In the table on the left, you can view the point-in-
time health and value of the service response time, network latency, and packet loss for all the tests. Use the
Network State Recorder control to view the network snapshot at another time in the past. Select the test in the
table that you want to investigate. In the charts in the pane on the right, you can view the historical trend of the
loss, latency, and response time values. Select the Test Details link to view the performance from each node.
In the Test Nodes view, you can observe the network connectivity from each node. Select the node that has
performance degradation. This is the node where the application is observed to be running slow.
Determine whether poor application performance is because of the network or an issue on the application
provider's end by observing the correlation between the response time of the application and the network latency.
Application issue: A spike in the response time but consistency in the network latency suggests that the
network is working fine and the problem might be due to an issue on the application end.
Network issue: A spike in response time accompanied with a corresponding spike in network latency
suggests that the increase in response time might be due to an increase in network latency.
After you determine that the problem is because of the network, select the Topology view link to identify the
troublesome hop on the topology map. An example is shown in the following image. Out of the 105-ms total
latency between the node and the application endpoint, 96 ms is because of the hop marked in red. After you
identify the troublesome hop, you can take corrective action.
Diagnostics
If you observe an abnormality, follow these steps:
If the service response time, network loss, and latency are shown as NA, one or more of the following
reasons might be the cause:
The application is down.
The node used for checking network connectivity to the service is down.
The target entered in the test configuration is incorrect.
The node doesn't have any network connectivity.
If a valid service response time is shown but network loss as well as latency are shown as NA, one or more
of the following reasons might be the cause:
If the node used for checking network connectivity to the service is a Windows client machine, either the
target service is blocking ICMP requests or a network firewall is blocking ICMP requests that originate
from the node.
The Perform network measurements check box is blank in the test configuration.
If the service response time is NA but network loss as well as latency are valid, the target service might not
be a web application. Edit the test configuration, and choose the test type as Network instead of Web.
If the application is running slow, determine whether poor application performance is because of the
network or an issue on the application provider's end.
GCC Office URLs for US Government customers

For US Government Virginia region, only DOD URLs are built-in NPM. Customers using GCC URLs need to
create custom tests and add each URL individually.
FIELD GCC
Office 365 Portal and shared portal.apps.mil
Office 365 auth and identity * login.microsoftonline.us

* api.login.microsoftonline.com
* clientconfig.microsoftonline-p.net
* login.microsoftonline.com
* login.microsoftonline-p.com
* login.windows.net
* loginex.microsoftonline.com
* login-us.microsoftonline.com
* nexus.microsoftonline-p.com
* mscrl.microsoft.com
* secure.aadcdn.microsoftonline-p.com
Office Online * adminwebservice.gov.us.microsoftonline.com

* adminwebservice-s1-bn1a.microsoftonline.com
* adminwebservice-s1-dm2a.microsoftonline.com
* becws.gov.us.microsoftonline.com
* provisioningapi.gov.us.microsoftonline.com
* officehome.msocdn.us
* prod.msocdn.us
* portal.office365.us
* webshell.suite.office365.us
* www .office365.us
* activation.sls.microsoft.com
* crl.microsoft.com
* go.microsoft.com
* insertmedia.bing.office.net
* ocsa.officeapps.live.com
* ocsredir.officeapps.live.com
* ocws.officeapps.live.com
* office15client.microsoft.com
* officecdn.microsoft.com
* officecdn.microsoft.com.edgesuite.net
* officepreviewredir.microsoft.com
* officeredir.microsoft.com
* ols.officeapps.live.com
* r.office.microsoft.com
* cdn.odc.officeapps.live.com
* odc.officeapps.live.com
* officeclient.microsoft.com
Exchange Online * outlook.office365.us

* attachments.office365-net.us
* autodiscover-s.office365.us
* manage.office365.us
* scc.office365.us
FIELD GCC
MS Teams gov.teams.microsoft.us
Next steps
You can use the Azure ExpressRoute Monitor capability in Network Performance Monitor to monitor end-to-end
connectivity and performance between your branch offices and Azure, over Azure ExpressRoute. Key advantages
are:
Autodetection of ExpressRoute circuits associated with your subscription.
Tracking of bandwidth utilization, loss and latency at the circuit, peering, and Azure Virtual Network level for
ExpressRoute.
Discovery of network topology of your ExpressRoute circuits.
Configuration
To open the configuration for Network Performance Monitor, open the Network Performance Monitor solution
Configure network security group rules
For the servers in Azure that are used for monitoring via Network Performance Monitor, configure network
security group (NSG ) rules to allow TCP traffic on the port used by Network Performance Monitor for synthetic
transactions. The default port is 8084. This configuration allows the Log Analytics agent installed on Azure VMs to
communicate with an on-premises monitoring agent.
For more information about NSGs, seeNetwork security groups.
NOTE
Before you continue with this step, install the on-premises server agent and the Azure server agent, and run the
EnableRules.ps1 PowerShell script.
Discover ExpressRoute peering connections

1. Select the ExpressRoute Peerings view.
2. Select Discover Now to discover all the ExpressRoute private peerings that are connected to the virtual
networks in the Azure subscription linked with this Azure Log Analytics workspace.
NOTE
The solution currently discovers only ExpressRoute private peerings.
NOTE
Only private peerings connected to the virtual networks associated with the subscription linked with this Log
Analytics workspace are discovered. If ExpressRoute is connected to virtual networks outside of the subscription
linked to this workspace, create a Log Analytics workspace in those subscriptions. Then use Network Performance
Monitor to monitor those peerings.
After the discovery is complete, the discovered private peering connections are listed in a table. The
monitoring for these peerings is initially in a disabled state.
Enable monitoring of the ExpressRoute peering connections
1. Select the private peering connection you want to monitor.
2. In the pane on the right, select the Monitor this Peering check box.
3. If you intend to create health events for this connection, select Enable Health Monitoring for this
peering.
4. Choose monitoring conditions. You can set custom thresholds for health event generation by entering
threshold values. Whenever the value of the condition goes above its selected threshold for the peering
connection, a health event is generated.
5. Select Add Agents to choose the monitoring agents you intend to use for monitoring this peering
connection. Make sure that you add agents on both ends of the connection. You need at least one agent in
the virtual network connected to this peering. You also need at least one on-premises agent connected to
this peering.
After you enable the rules and select values and agents, wait 30 to 60 minutes for the values to populate and the
ExpressRoute Monitoring tiles to appear. When you see the monitoring tiles, your ExpressRoute circuits and
connection resources are now monitored by Network Performance Monitor.
NOTE
This capability works reliably on workspaces that have upgraded to the new query language.
Walkthrough
The Network Performance Monitor dashboard shows an overview of the health of ExpressRoute circuits and
peering connections.
Circuits list
To see a list of all monitored ExpressRoute circuits, select theExpressRoute circuitstile. You can select a circuit and
view its health state, trend charts for packet loss, bandwidth utilization, and latency. The charts are interactive. You
can select a custom time window for plotting the charts. Drag the mouse over an area on the chart to zoom in and
see fine-grained data points.
Trends of loss, latency, and throughput

The bandwidth utilization, latency, and loss charts are interactive. You can zoom in to any section of these charts by
using mouse controls. You also can see the bandwidth, latency, and loss data for other intervals. In the upper left
under the Actions button, selectDate/Time.
Peerings list
To bring up a list of all connections to virtual networks over private peering, select the Private Peerings tile on the
dashboard. Here, you can select a virtual network connection and view its health state, trend charts for packet loss,
bandwidth utilization, and latency.
Circuit topology
To view circuit topology, select the Topology tile. This action takes you to the topology view of the selected circuit
or peering. The topology diagram provides the latency for each segment on the network, and each layer 3 hop is
represented by a node of the diagram. Selecting a hop reveals more details about the hop. To increase the level of
visibility to include on-premises hops, move the slider bar under FILTERS. Moving the slider bar to the left or right
increases or decreases the number of hops in the topology graph. The latency across each segment is visible, which
allows for faster isolation of high-latency segments on your network.
Detailed topology view of a circuit

This view shows virtual network connections.
Diagnostics
Network Performance Monitor helps you diagnose several circuit connectivity issues. Some of the issues that you
can see are listed below.
You can see the notification codes and set alerts on them via LogAnalytics. On the NPM Diagnostics page, you
can see descriptions for every diagnostics message triggered.
NOTIFICATION CODE (LOGS) DESCRIPTION
5501 Unable to traverse through secondary connection of

ExpressRoute circuit
5502 Unable to traverse through primary connection of

ExpressRoute circuit
5503 No circuit is found for subscription linked to the workspace
5508 Not able to determine whether traffic is passing through any

circuit(s) for path
5510 The traffic is not passing through the intended circuit
5511 The traffic is not passing through the intended virtual network
Circuit is down. Network Performance Monitor notifies you as soon as the connectivity between your on-
premises resources and Azure virtual networks is lost. This notification helps you take proactive action before you
receive user escalations and reduce downtime.
Traffic not flowing through intended circuit. Network Performance Monitor notifies you whenever traffic isn't
flowing through the intended ExpressRoute circuit. This issue can happen if the circuit is down and traffic is flowing
through the backup route. It also can happen if there's a routing issue. This information helps you proactively
manage any configuration issues in your routing policies and make sure that the most optimal and secure route is
used.
Traffic not flowing through primary circuit. Network Performance Monitor notifies you when traffic is flowing
through the secondary ExpressRoute circuit. Even though you won't experience any connectivity issues in this case,
proactively troubleshooting the issues with the primary circuit makes you better prepared.
Degradation due to peak utilization. You can correlate the bandwidth utilization trend with the latency trend to
identify whether the Azure workload degradation is due to a peak in bandwidth utilization or not. Then you can
take action accordingly.
Next steps
Pricing changes for Azure Network Performance
Monitor
We have listened to your feedback and recently introduced a new pricing experience for various monitoring
services across Azure. This article captures the pricing changes related to Azure Network Performance Monitor
(NPM ) in an easy-to-read question and answer format.
Network Performance Monitor consists of three components:
Performance Monitor
Service Endpoint Monitor
The following sections explain the pricing changes for the NPM components.
Performance Monitor
How was usage of Performance Monitor billed in the old model?
The billing for NPM was based on the usage and consumption of two components:
Nodes: All synthetic transactions originate and terminate at the nodes. Nodes are also referred to as agents or
Microsoft Management Agents.
Data: The results of the various network tests are stored in the Log Analytics workspace.
Under the old model, the bill was computed based on the number of nodes and the volume of data generated.
How is usage of Performance Monitor charged under the new model?
The Performance Monitor feature in NPM is now billed based on a combination of:
Subnet links monitored
Data volume
What is a subnet link?
Performance Monitor monitors connectivity between two or more locations on the network. The connection
between a group of nodes or agents on one subnet, and a group of nodes on another subnet, is called a subnet link.
I have two subnets (A and B ), and I have several agents on each subnet. Performance Monitor monitors
connectivity from all agents on subnet A to all agents on subnet B. Will I be charged based on the
number of inter-subnet connections?
No. For billing purposes, all connections from subnet A to subnet B are grouped together into one subnet link.
You're billed for a single connection. Performance Monitor continues to monitor connectivity between various
agents on each subnet.
What are the costs for monitoring a subnet link?
For the cost of monitoring a single subnet link for the entire month, see the Ping Mesh section.
What are the charges for data that Performance Monitor generates?
The charge for ingestion (data upload to Log Analytics workspace in Azure Monitor, processing, and indexing) is
available on the pricing page for Log Analytics, in the Data Ingestion section. The charge for data retention (that is,
data retained at customer's option, beyond the first month) is also available on the pricing page, in the Data
Retention section.
What are the charges for usage of ExpressRoute Monitor?
Charges for ExpressRoute Monitor are billed based on the volume of data generated during monitoring. For more
information, see "What are the charges for data that Performance Monitor generates?"
I use ExpressRoute Monitor to monitor multiple ExpressRoute circuits. Am I charged based on the
number of circuits being monitored?
You are not charged based on either the number of circuits or the type of peering (for example, private peering,
Microsoft peering). You are charged based on the volume of data, as explained previously.
What is the volume of data generated when ExpressRoute monitors a single circuit?
The volume of data generated per month, when ExpressRoute monitors a private peering connection, is as follows:
PERCENTILE DATA/MONTH (MB)
50th 192
60th 256
70th 360
80th 498
90th 870
95th 1560
According to this table, customers at the 50th percentile pay for 192 MB of data. At USD $2.30/GB for the first
month, the cost incurred for monitoring a circuit is USD $0.43 (= 192 * 2.30 / 1024).
What are some reasons for variations in the volume of data?
The volume of monitoring data generated depends on several factors, such as:
Number of agents. The accuracy of fault isolation increases with an increase in the number of agents.
Number of hops on the network.
Number of paths between the source and the destination.
Customers at the higher percentiles (in the preceding table) usually monitor their circuits from several vantage
points on their on-premises network. Multiple agents are also placed deeper in the network, farther from the
service provider edge router. The agents are often placed at several user sites, branches, and racks in datacenters.
Service Endpoint Monitor

What are the charges for usage of Service Endpoint Monitor?
Charges for usage of Service Endpoint Monitor are computed based on:
Number of connections
Volume of data
What is a connection?
A connection is a test of reachability to one endpoint (URL or network service) from a single agent for the entire
month. For example, monitoring a connection to bing.com from three agents constitutes three connections.
What are the costs for Service Endpoint Monitor?
Refer to the Connection Monitoring section for the cost of monitoring an endpoint for the entire month. The
charge for data is available on the pricing page for Log Analytics, in the Data Ingestion section.
References
Log Analytics Pricing FAQ: The FAQ section has information on free tier, per node pricing and other pricing details.
Network Performance Monitor solution FAQ
This article captures the frequently asked questions (FAQs) about Network Performance Monitor (NPM ) in Azure
Network Performance Monitor is a cloud-based hybrid network monitoring solution that helps you monitor
network performance between various points in your network infrastructure. It also helps you monitor network
connectivity to service and application endpoints and monitor the performance of Azure ExpressRoute.
Network Performance Monitor detects network issues like traffic blackholing, routing errors, and issues that
conventional network monitoring methods aren't able to detect. The solution generates alerts and notifies you
when a threshold is breached for a network link. It also ensures timely detection of network performance issues
and localizes the source of the problem to a particular network segment or device.
More information on the various capabilities supported by Network Performance Monitor is available online.
Set up and configure agents

What are the platform requirements for the nodes to be used for monitoring by NPM?
Listed below are the platform requirements for NPM's various capabilities:
NPM's Performance Monitor and Service Connectivity Monitor capabilities support both Windows server and
Windows desktops/client operating systems. Windows server OS versions supported are 2008 SP1 or later.
Windows desktops/client versions supported are Windows 10, Windows 8.1, Windows 8 and Windows 7.
NPM's ExpressRoute Monitor capability supports only Windows server (2008 SP1 or later) operating system.
Can I use Linux machines as monitoring nodes in NPM?
The capability to monitor networks using Linux-based nodes is currently in preview. Reach out to your Account
Manager to know more. Linux agents provide monitoring capability only for NPM's Performance Monitor
capability, and are not available for the Service Connectivity Monitor and ExpressRoute Monitor capabilities
What are the size requirements of the nodes to be used for monitoring by NPM?
For running the NPM solution on node VMs to monitor networks, the nodes should have at least 500-MB memory
and one core. You do'nt need to use separate nodes for running NPM. The solution can run on nodes that have
other workloads running on it. The solution has the capability to stop the monitoring process if it uses more than
5% CPU.
To use NPM, should I connect my nodes as Direct agent or through System Center Operations Manager?
Both the Performance Monitor and the Service Connectivity Monitor capabilities support nodes connected as
Direct Agents and connected through Operations Manager.
For ExpressRoute Monitor capability, the Azure nodes should be connected as Direct Agents only. Azure nodes,
which are connected through Operations Manager are not supported. For on-premises nodes, the nodes
connected as Direct Agents and through Operations Manager are supported for monitoring an ExpressRoute
circuit.
Which protocol among TCP and ICMP should be chosen for monitoring?
If you're monitoring your network using Windows server-based nodes, we recommend you use TCP as the
monitoring protocol since it provides better accuracy.
ICMP is recommended for Windows desktops/client operating system-based nodes. This platform does'nt allow
TCP data to be sent over raw sockets, which NPM uses to discover network topology.
You can get more details on the relative advantages of each protocol here.
How can I configure a node to support monitoring using TCP protocol?
For the node to support monitoring using TCP protocol:
Ensure that the node platform is Windows Server (2008 SP1 or later).
Run EnableRules.ps1 Powershell script on the node. See instructions for more details.
How can I change the TCP port being used by NPM for monitoring?
You can change the TCP port used by NPM for monitoring, by running the EnableRules.ps1 script. You need enter
the port number you intend to use as a parameter. For example, to enable TCP on port 8060, run
EnableRules.ps1 8060 . Ensure that you use the same TCP port on all the nodes being used for monitoring.
The script configures only Windows Firewall locally. If you have network firewall or Network Security Group
(NSG ) rules, make sure that they allow the traffic destined for the TCP port used by NPM.
How many agents should I use?
You should use at least one agent for each subnet that you want to monitor.
What is the maximum number of agents I can use or I see error ".... you've reached your Configuration limit"?
NPM limits the number of IPs to 5000 IPs per workspace. If a node has both IPv4 and IPv6 addresses, this will
count as 2 IPs for that node. Hence, this limit of 5000 IPs would decide the upper limit on the number of agents.
You can delete the inactive agents from Nodes tab in NPM >> Configure. NPM also maintains history of all the
IPs that were ever assigned to the VM hosting the agent and each is counted as separate IP contributing to that
upper limit of 5000 IPs. To free up IPs for your workspace, you can use the Nodes page to delete the IPs that are
not in use.
Monitoring
How are loss and latency calculated
Source agents send either TCP SYN requests (if TCP is chosen as the protocol for monitoring) or ICMP ECHO
requests (if ICMP is chosen as the protocol for monitoring) to destination IP at regular intervals to ensure that all
the paths between the source-destination IP combination are covered. The percentage of packets received and
packet round-trip time is measured to calculate the loss and latency of each path. This data is aggregated over the
polling interval and over all the paths to get the aggregated values of loss and latency for the IP combination for
the particular polling interval.
With what frequency does the source agent send packets to the destination for monitoring?
For Performance Monitor and ExpressRoute Monitor capabilities, the source sends packets every 5 seconds and
records the network measurements. This data is aggregated over a 3-minute polling interval to calculate the
average and peak values of loss and latency. For Service Connectivity Monitor capability, the frequency of sending
the packets for network measurement is determined by the frequency entered by the user for the specific test while
configuring the test.
How many packets are sent for monitoring?
The number of packets sent by the source agent to destination in a polling is adaptive and is decided by our
proprietary algorithm, which can be different for different network topologies. More the number of network paths
between the source-destination IP combination, more is the number of packets that are sent. The system ensures
that all paths between the source-destination IP combination are covered.
How does NPM discover network topology between source and destination?
NPM uses a proprietary algorithm based on Traceroute to discover all the paths and hops between source and
destination.
Does NPM provide routing and switching level info
Though NPM can detect all the possible routes between the source agent and the destination, it does not provide
visibility into which route was taken by the packets sent by your specific workloads. The solution can help you
identify the paths and underlying network hops, which are adding more latency than you expected.
Why are some of the paths unhealthy?
Different network paths can exist between the source and destination IPs and each path can have a different value
of loss and latency. NPM marks those paths as unhealthy (denoted with red color) for which the values of loss
and/or latency is greater than the respective threshold set in the monitoring configuration.
What does a hop in red color signify in the network topology map?
If a hop is red, it signifies that it is part of at-least one unhealthy path. NPM only marks the paths as unhealthy, it
does not segregate the health status of each path. To identify the troublesome hops, you can view the hop-by-hop
latency and segregate the ones adding more than expected latency.
How does fault localization in Performance Monitor work?
NPM uses a probabilistic mechanism to assign fault-probabilities to each network path, network segment, and the
constituent network hops based on the number of unhealthy paths they are a part of. As the network segments and
hops become part of more number of unhealthy paths, the fault-probability associated with them increases. This
algorithm works best when you have many nodes with NPM agent connected to each other as this increases the
data points for calculating the fault-probabilities.
How can I create alerts in NPM?
Refer to alerts section in the documentation for step-by-step instructions.
Can NPM monitor routers and servers as individual devices?
NPM only identifies the IP and host name of underlying network hops (switches, routers, servers, etc.) between the
source and destination IPs. It also identifies the latency between these identified hops. It does not individually
monitor these underlying hops.
Can NPM be used to monitor network connectivity between Azure and AWS?
Yes. Refer to the article Monitor Azure, AWS, and on-premises networks using NPM for details.
Is the ExpressRoute bandwidth usage incoming or outgoing?
Bandwidth usage is the total of incoming and outgoing bandwidth. It is expressed in Bits/sec.
Can we get incoming and outgoing bandwidth information for the ExpressRoute?
Incoming and outgoing values for both Primary and Secondary bandwidth can be captured.
For peering level information, use the below mentioned query in Log Search
NetworkMonitoring
| where SubType == "ExpressRoutePeeringUtilization"
| project
CircuitName,PeeringName,PrimaryBytesInPerSecond,PrimaryBytesOutPerSecond,SecondaryBytesInPerSecond,SecondaryByt
esOutPerSecond
For circuit level information, use the below mentioned query

NetworkMonitoring
| where SubType == "ExpressRouteCircuitUtilization"
| project CircuitName,PrimaryBytesInPerSecond,
PrimaryBytesOutPerSecond,SecondaryBytesInPerSecond,SecondaryBytesOutPerSecond
Which regions are supported for NPM's Performance Monitor?

NPM can monitor connectivity between networks in any part of the world, from a workspace that is hosted in one
of the supported regions
Which regions are supported for NPM's Service Connectivity Monitor?
NPM can monitor connectivity to services in any part of the world, from a workspace that is hosted in one of the
supported regions
Which regions are supported for NPM's ExpressRoute Monitor?
NPM can monitor your ExpressRoute circuits located in any Azure region. To onboard to NPM, you will require a
Log Analytics workspace that must be hosted in one of the supported regions
Troubleshoot
Why are some of the hops marked as unidentified in the network topology view?
NPM uses a modified version of traceroute to discover the topology from the source agent to the destination. An
unidentified hop represents that the network hop did not respond to the source agent's traceroute request. If three
consecutive network hops do not respond to the agent's traceroute, the solution marks the unresponsive hops as
unidentified and does not try to discover more hops.
A hop may not respond to a traceroute in one or more of the below scenarios:
The routers have been configured to not reveal their identity.
The network devices are not allowing ICMP_TTL_EXCEEDED traffic.
A firewall is blocking the ICMP_TTL_EXCEEDED response from the network device.
I get alerts for unhealthy tests but I do not see the high values in NPM's loss and latency graph. How do I check
what is unhealthy ?
NPM raises an alert if end to end latency between source and destination crosses the threshhold for any path
between them. Some networks have more than one paths connecting the same source and destination. NPM raises
an alert is any path is unhealthy. The loss and latency seen in the graphs is the average value for all the paths,
hence it may not show the exact value of a single path. To understand where the threshold has been breached, look
for the "SubType" column in the alert. If the issue is caused by a path the SubType value will be NetworkPath ( for
Performance Monitor tests), EndpointPath (for Service Connectivity Monitor tests) and ExpressRoutePath (for
ExpressRotue Monitor tests).
Sample Query to find is path is unhealthy:
NetworkMonitoring
| where ( SubType == "ExpressRoutePath")
| where (LossHealthState == "Unhealthy" or LatencyHealthState == "Unhealthy" or UtilizationHealthState ==
"Unhealthy") and CircuitResourceID =="<your ER circuit ID>" and ConnectionResourceId == "<your ER connection
resource id>"
| project SubType, LossHealthState, LatencyHealthState, MedianLatency
Why does my test show unhealthy but the topology does not
NPM monitors end-to-end loss, latency, and topology at different intervals. Loss and latency are measured once
every 5 seconds and aggregated every three minutes (for Performance Monitor and Express Route Monitor) while
topology is calculated using traceroute once every 10 minutes. For example, between 3:44 and 4:04, topology may
be updated three times (3:44, 3:54, 4:04) , but loss and latency are updated about seven times (3:44, 3:47, 3:50, 3:53,
3:56, 3:59, 4:02). The topology generated at 3:54 will be rendered for the loss and latency that gets calculated at
3:56, 3:59 and 4:02. Suppose you get an alert that your ER circuit was unhealthy at 3:59. You log on to NPM and
try to set the topology time to 3:59. NPM will render the topology generated at 3:54. To understand the last known
topology of your network, compare the fields TimeProcessed (time at which loss and latency was calculated) and
TracerouteCompletedTime(time at which topology was calculated).
What is the difference between the fields E2EMedianLatency and AvgHopLatencyList in the
NetworkMonitoring table
E2EMedianLatency is the latency updated every three minutes after aggregating the results of tcp ping tests,
whereas AvgHopLatencyList is updated every 10 mins based on traceroute. To understand the exact time at which
E2EMedianLatency was calculated, use the field TimeProcessed. To understand the exact time at which traceroute
completed and updated AvgHopLatencyList, use the field TracerouteCompletedTime
Why does hop-by-hop latency numbers differ from HopLatencyValues
HopLatencyValues are source to endpoint. For Example: Hops - A,B,C. AvgHopLatency - 10,15,20. This means
source to A latency = 10, source to B latency = 15 and source to C latency is 20. UI will calculate A-B hop latency as
5 in the topology
The solution shows 100% loss but there is connectivity between the source and destination
This can happen if either the host firewall or the intermediate firewall (network firewall or Azure NSG ) is blocking
the communication between the source agent and the destination over the port being used for monitoring by NPM
(by default the port is 8084, unless the customer has changed this).
To verify that the host firewall is not blocking the communication on the required port, view the health status of
the source and destination nodes from the following view: Network Performance Monitor -> Configuration ->
Nodes. If they are unhealthy, view the instructions and take corrective action. If the nodes are healthy, move to
the step b. below.
To verify that an intermediate network firewall or Azure NSG is not blocking the communication on the
required port, use the third-party PsPing utility using the below instructions:
psping utility is available for download here
Run following command from the source node.
psping -n 15 <destination node IPAddress>:portNumber By default NPM uses 8084 port. In case
you have explicitly changed this by using the EnableRules.ps1 script, enter the custom port
number you are using). This is a ping from Azure machine to on-premises
Check if the pings are successful. If not, then it indicates that an intermediate network firewall or Azure NSG is
blocking the traffic on this port.
Now, run the command from destination node to source node IP.
There is loss from node A to B, but not from node B to A. Why?
As the network paths between A to B can be different from the network paths between B to A, different values for
loss and latency can be observed.
Why are all my ExpressRoute circuits and peering connections not being discovered?
NPM now discovers ExpressRoute circuits and peering connections in all subscriptions to which the user has
access. Choose all the subscriptions where your Express Route resources are linked and enable monitoring for each
discovered resource. NPM looks for connection objects when discovering a private peering, so please check if a
VNET is associated with your peering.
The ER Monitor capability has a diagnostic message "Traffic is not passing through ANY circuit". What does that
mean?
There can be a scenario where there is a healthy connection between the on-premises and Azure nodes but the
traffic is not going over the ExpressRoute circuit configured to be monitored by NPM.
This can happen if:
The ER circuit is down.
The route filters are configured in such a manner that they give priority to other routes (such as a VPN
connection or another ExpressRoute circuit) over the intended ExpressRoute circuit.
The on-premises and Azure nodes chosen for monitoring the ExpressRoute circuit in the monitoring
configuration, do not have connectivity to each other over the intended ExpressRoute circuit. Ensure that you
have chosen correct nodes that have connectivity to each other over the ExpressRoute circuit you intend to
monitor.
While configuring monitoring of my ExpressRoute circuit, the Azure nodes are not being detected.
This can happen if the Azure nodes are connected through Operations Manager. The ExpressRoute Monitor
capability supports only those Azure nodes that are connected as Direct Agents.
I cannot Discover by ExpressRoute circuits in the OMS portal
Though NPM can be used both from the Azure portal as well as the OMS portal, the circuit discovery in the
ExpressRoute Monitor capability works only through the Azure portal. Once the circuits are discovered through the
Azure portal, you can then use the capability in either of the two portals.
In the Service Connectivity Monitor capability, the service response time, network loss, as well as latency are
shown as NA
This can happen if one or more is true:
The service is down.
The node used for checking network connectivity to the service is down.
The target entered in the test configuration is incorrect.
The node doesn't have any network connectivity.
In the Service Connectivity Monitor capability, a valid service response time is shown but network loss as well as
latency are shown as NA
This can happen if one or more is true:
If the node used for checking network connectivity to the service is a Windows client machine, either the target
service is blocking ICMP requests or a network firewall is blocking ICMP requests that originate from the node.
The Perform network measurements check box is blank in the test configuration.
In the Service Connectivity Monitor capability, the service response time is NA but network loss as well as
latency are valid
This can happen if the target service is not a web application but the test is configured as a Web test. Edit the test
configuration, and choose the test type as Network instead of Web.
Miscellaneous
Is there a performance impact on the node being used for monitoring?
NPM process is configured to stop if it utilizes more than 5% of the host CPU resources. This is to ensure that you
can keep using the nodes for their usual workloads without impacting performance.
Does NPM edit firewall rules for monitoring?
NPM only creates a local Windows Firewall rule on the nodes on which the EnableRules.ps1 Powershell script is
run to allow the agents to create TCP connections with each other on the specified port. The solution does not
modify any network firewall or Network Security Group (NSG ) rules.
How can I check the health of the nodes being used for monitoring?
You can view the health status of the nodes being used for monitoring from the following view: Network
Performance Monitor -> Configuration -> Nodes. If a node is unhealthy, you can view the error details and take
the suggested action.
Can NPM report latency numbers in microseconds?
NPM rounds the latency numbers in the UI and in milliseconds. The same data is stored at a higher granularity
(sometimes up to four decimal places).
Next steps
Learn more about Network Performance Monitor by referring to Network Performance Monitor solution in
Azure.
Optimize your Active Directory environment with the
Active Directory Health Check solution in Azure
Monitor
NOTE
You can use the Active Directory Health Check solution to assess the risk and health of your server environments
on a regular interval. This article helps you install and use the solution so that you can take corrective actions for
potential problems.
recommendations are categorized across four focus areas, which help you quickly understand the risk and take
action.
The recommendations are based on the knowledge and experience gained by Microsoft engineers from thousands
of customer visits. Each recommendation provides guidance about why an issue might matter to you and how to
implement the suggested changes.
After you've added the solution and a check is completed, summary information for focus areas is shown on the
AD Health Check dashboard for the infrastructure in your environment. The following sections describe how to
use the information on the AD Health Check dashboard, where you can view and then take recommended
actions for your Active Directory server infrastructure.
Prerequisites
The Active Directory Health Check solution requires a supported version of .NET Framework 4.5.2 or above
installed on each computer that has the Log Analytics agent for Windows (also referred to as the Microsoft
Monitoring Agent (MMA)) installed. The agent is used by System Center 2016 - Operations Manager,
Operations Manager 2012 R2, and Azure Monitor.
The solution supports domain controllers running Windows Server 2008 and 2008 R2, Windows Server
2012 and 2012 R2, and Windows Server 2016.
A Log Analytics workspace to add the Active Directory Health Check solution from the Azure marketplace
in the Azure portal. There is no additional configuration required.
NOTE
After you've added the solution, the AdvisorAssessment.exe file is added to servers with agents. Configuration data is
read and then sent to Azure Monitor in the cloud for processing. Logic is applied to the received data and the cloud
service records the data.
To perform the health check against your domain controllers that are members of the domain to be evaluated, each
domain controller in that domain requires an agent and connectivity to Azure Monitor using one of the following
supported methods:
1. Install the Log Analytics agent for Windows if the domain controller is not already monitored by System Center
2016 - Operations Manager or Operations Manager 2012 R2.
2. If it is monitored with System Center 2016 - Operations Manager or Operations Manager 2012 R2 and the
management group is not integrated with Azure Monitor, the domain controller can be multi-homed with
Azure Monitor to collect data and forward to the service and still be monitored by Operations Manager.
3. Otherwise, if your Operations Manager management group is integrated with the service, you need to add the
domain controllers for data collection by the service following the steps under add agent-managed computers
after you enable the solution in your workspace.
The agent on your domain controller which reports to an Operations Manager management group, collects data,
forwards to its assigned management server, and then is sent directly from a management server to Azure
Monitor. The data is not written to the Operations Manager databases.
Active Directory Health Check data collection details

Active Directory Health Check collects data from the following sources using the agent that you have enabled:
Registry
LDAP
.NET Framework
Event log
Active Directory Service interfaces (ADSI)
Windows PowerShell
File data
DCDIAG tool API
File Replication Service (NTFRS ) API
Custom C# code
Data is collected on the domain controller and forwarded to Azure Monitor every seven days.

recommendation. Only the 10 most important recommendations are shown.
The probability that an issue identified causes problems. A higher probability equates to a larger overall score
for the recommendation.
recommendation.
area. For example, if a recommendation in the Security and Compliance focus area has a score of 5%,
implementing that recommendation increases your overall Security and Compliance score by 5%.
Focus areas
Security and Compliance - This focus area shows recommendations for potential security threats and breaches,
corporate policies, and technical, legal and regulatory compliance requirements.
Upgrade, Migration and Deployment - This focus area shows recommendations to help you upgrade, migrate,
and deploy Active Directory to your existing infrastructure.
Every recommendation includes guidance about why it is important. You should use this guidance to evaluate
whether implementing the recommendation is appropriate for you, given the nature of your IT services and the
business needs of your organization.
Use health check focus area recommendations

After it is installed, you can view the summary of recommendations by using the Health Check tile on the solution
page in the Azure portal.
1. On the Overview page, click the Active Directory Health Check tile.
2. On the Health Check page, review the summary information in one of the focus area blades and then click
one to view recommendations for that focus area.
assessments records that recommended actions were taken and your compliance score will increase.
If you have recommendations that you want to ignore, you can create a text file that Azure Monitor will use to
prevent recommendations from appearing in your assessment results.
To identify recommendations that you will ignore
Use log analytics to create queries and analyze log data in Azure Monitor by clicking Logs in the Azure Monitor
menu in the Azure portal.
Use the following query to list recommendations that have failed for computers in your environment.
ADAssessmentRecommendation | where RecommendationResult == "Failed" | sort by Computer asc | project Computer,
RecommendationId, Recommendation
Here's a screenshot showing the log query:<
Choose recommendations that you want to ignore. You’ll use the values for RecommendationId in the next
procedure.
2. Paste or type each RecommendationId for each recommendation that you want Azure Monitor to ignore on
a separate line and then save and close the file.
3. Put the file in the following folder on each computer where you want Azure Monitor to ignore
recommendations.
On computers with the Microsoft Monitoring Agent (connected directly or through Operations
Manager) - SystemDrive:\Program Files\Microsoft Monitoring Agent\Agent
On the Operations Manager 2012 R2 management server - SystemDrive:\Program Files\Microsoft
System Center 2012 R2\Operations Manager\Server
On the Operations Manager 2016 management server - SystemDrive:\Program Files\Microsoft System
Center 2016\Operations Manager\Server
After the next scheduled health check runs, by default every seven days, the specified recommendations are
marked Ignored and will not appear on the dashboard.
1. You can use the following log queries to list all the ignored recommendations.
ADAssessmentRecommendation | where RecommendationResult == "Ignored" | sort by Computer asc | project

AD Health Check solutions FAQ
How often does a health check run?
The check runs every seven days.
Is there a way to configure how often the health check runs?
Not at this time.
If another server for is discovered after I’ve added a health check solution, will it be checked
Yes, once it is discovered it is checked from then on, every seven days.
If a server is decommissioned, when will it be removed from the health check?
If a server does not submit data for 3 weeks, it is removed.
What is the name of the process that does the data collection?
AdvisorAssessment.exe
How long does it take for data to be collected?
The actual data collection on the server takes about 1 hour. It may take longer on servers that have a large
number of Active Directory servers.
Is there a way to configure when data is collected?
Not at this time.
Why display only the top 10 recommendations?
Instead of giving you an exhaustive overwhelming list of tasks, we recommend that you focus on addressing
the prioritized recommendations first. After you address them, additional recommendations will become
available. If you prefer to see the detailed list, you can view all recommendations using a log query.
Is there a way to ignore a recommendation?
Yes, see Ignore recommendations section above.
Next steps
Use Azure Monitor log queries to learn how to analyze detailed AD Health Check data and recommendations.
Monitor Active Directory replication status with Azure
Monitor
Active Directory is a key component of an enterprise IT environment. To ensure high availability and high
performance, each domain controller has its own copy of the Active Directory database. Domain controllers
replicate with each other in order to propagate changes across the enterprise. Failures in this replication process
can cause a variety of problems across the enterprise.
The AD Replication Status solution pack regularly monitors your Active Directory environment for any replication
failures.
NOTE
Previous versions of this article referred to Log Analytics as its own service. Its functionality hasn't changed, but it's been
renamed to the log feature of Azure Monitor. With this rename, this article describes its data being stored in a Log Analytics
workspace in Azure Monitor. For more information, see Azure Monitor branding changes.

Install agents on domain controllers
You must install agents on domain controllers that are members of the domain to be evaluated. Or, you must
install agents on member servers and configure the agents to send AD replication data to Azure Monitor. To
understand how to connect Windows computers to Azure Monitor, see Connect Windows computers to Azure
Monitor. If your domain controller is already part of an existing System Center Operations Manager environment
that you want to connect to Azure Monitor, see Connect Operations Manager to Azure Monitor.
Enable non-domain controller
If you don't want to connect any of your domain controllers directly to Azure Monitor, you can use any other
computer in your domain connected to Azure Monitor to collect data for the AD Replication Status solution pack
and have it send the data.
1. Verify that the computer is a member of the domain that you wish to monitor using the AD Replication
Status solution.
2. Connect the Windows computer to Azure Monitor or connect it using your existing Operations Manager
environment to Azure Monitor, if it is not already connected.
3. On that computer, set the following registry key:
Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Mana
gement Groups<ManagementGroupName>\Solutions\ADReplication
Value: IsTarget
Value Data: true
NOTE
These changes do not take effect until you restart the Microsoft Monitoring Agent service (HealthService.exe).
Install solution
Follow the process described in Install a monitoring solution to add the Active Directory Replication Status
solution to your Log Analytics workspace. There is no further configuration required.
AD Replication Status data collection details

The following table shows data collection methods and other details about how data is collected for AD Replication
Status.
SCOM AGENT
DATA SENT VIA
AZURE SCOM MANAGEMENT COLLECTION
PLATFORM DIRECT AGENT SCOM AGENT STORAGE REQUIRED? GROUP FREQUENCY
Windows • • • every five

days
Understanding replication errors

The AD Replication Status tile displays how many replication errors you currently have. Critical Replication
Errors are errors that are at or above 75% of the tombstone lifetime for your Active Directory forest.
When you click the tile, you can view more information about the errors.
Destination Server Status and Source Server Status
These columns show the status of destination servers and source servers that are experiencing replication errors.
The number after each domain controller name indicates the number of replication errors on that domain
controller.
The errors for both destination servers and source servers are shown because some problems are easier to
troubleshoot from the source server perspective and others from the destination server perspective.
In this example, you can see that many destination servers have roughly the same number of errors, but there's
one source server (ADDC35) that has many more errors than all the others. It's likely that there is some problem
on ADDC35 that is causing it to fail to send data to its replication partners. Fixing the problems on ADDC35 might
resolve many of the errors that appear in the destination server area.
Replication Error Types
This area gives you information about the types of errors detected throughout your enterprise. Each error has a
unique numerical code and a message that can help you determine the root cause of the error.
The donut at the top gives you an idea of which errors appear more and less frequently in your environment.
It shows you when multiple domain controllers experience the same replication error. In this case, you may be able
to discover or identify a solution on one domain controller, then repeat it on other domain controllers affected by
the same error.
Tombstone Lifetime
The tombstone lifetime determines how long a deleted object, referred to as a tombstone, is retained in the Active
Directory database. When a deleted object passes the tombstone lifetime, a garbage collection process
automatically removes it from the Active Directory database.
The default tombstone lifetime is 180 days for most recent versions of Windows, but it was 60 days on older
versions, and it can be changed explicitly by an Active Directory administrator.
It's important to know if you're having replication errors that are approaching or are past the tombstone lifetime. If
two domain controllers experience a replication error that persists past the tombstone lifetime, replication is
disabled between those two domain controllers, even if the underlying replication error is fixed.
The Tombstone Lifetime area helps you identify places where disabled replication is in danger of happening. Each
error in the Over 100% TSL category represents a partition that has not replicated between its source and
destination server for at least the tombstone lifetime for the forest.
In this situation, simply fixing the replication error will not be enough. At a minimum, you need to manually
investigate to identify and clean up lingering objects before you can restart replication. You may even need to
decommission a domain controller.
In addition to identifying any replication errors that have persisted past the tombstone lifetime, you also want to
pay attention to any errors falling into the 50-75% TSL or 75-100% TSL categories.
These are errors that are clearly lingering, not transient, so they likely need your intervention to resolve. The good
news is that they have not yet reached the tombstone lifetime. If you fix these problems promptly and before they
reach the tombstone lifetime, replication can restart with minimal manual intervention.
As noted earlier, the dashboard tile for the AD Replication Status solution shows the number of critical replication
errors in your environment, which is defined as errors that are over 75% of tombstone lifetime (including errors
that are over 100% of TSL ). Strive to keep this number at 0.
NOTE
All the tombstone lifetime percentage calculations are based on the actual tombstone lifetime for your Active Directory
forest, so you can trust that those percentages are accurate, even if you have a custom tombstone lifetime value set.
AD Replication status details

When you click any item in one of the lists, you see additional details about it using a log query. The results are
filtered to show only the errors related to that item. For example, if you click on the first domain controller listed
under Destination Server Status (ADDC02), you see query results filtered to show errors with that domain
controller listed as the destination server:
From here, you can filter further, modify the log query, and so on. For more information about using the log
queries in Azure Monitor, see Analyze log data in Azure Monitor.
The HelpLink field shows the URL of a TechNet page with additional details about that specific error. You can copy
and paste this link into your browser window to see information about troubleshooting and fixing the error.
You can also click Export to export the results to Excel. Exporting the data can help you visualize replication error
data in any way you'd like.
AD Replication Status FAQ
Q: How often is AD replication status data updated? A: The information is updated every five days.
Q: Is there a way to configure how often this data is updated? A: Not at this time.
Q: Do I need to add all of my domain controllers to my Log Analytics workspace in order to see
replication status? A: No, only a single domain controller must be added. If you have multiple domain controllers
in your Log Analytics workspace, data from all of them is sent to Azure Monitor.
Q: I don't want to add any domain controllers to my Log Analytics workspace. Can I still use the AD
Replication Status solution?
A: Yes. You can set the value of a registry key to enable it. See Enable non-domain controller.
Q: What is the name of the process that does the data collection? A: AdvisorAssessment.exe
Q: How long does it take for data to be collected? A: Data collection time depends on the size of the Active
Directory environment, but usually takes less than 15 minutes.
Q: What type of data is collected? A: Replication information is collected via LDAP.
Q: Is there a way to configure when data is collected? A: Not at this time.
Q: What permissions do I need to collect data? A: Normal user permissions to Active Directory are sufficient.
Troubleshoot data collection problems

In order to collect data, the AD Replication Status solution pack requires at least one domain controller to be
connected to your Log Analytics workspace. Until you connect a domain controller, a message appears indicating
that data is still being collected.
If you need assistance connecting one of your domain controllers, you can view documentation at Connect
Windows computers to Azure Monitor. Alternatively, if your domain controller is already connected to an existing
System Center Operations Manager environment, you can view documentation at Connect System Center
Operations Manager to Azure Monitor.
If you don't want to connect any of your domain controllers directly to Azure Monitor or to System Center
Operations Manager, see Enable non-domain controller.
Next steps
Use Log queries in Azure Monitor to view detailed Active Directory Replication status data.
Office 365 management solution in Azure (Preview)
NOTE
The recommended method to install and configure the Office 365 solution is enabling the Office 365 connector in Azure
Sentinel instead of using the steps in this article. This is an updated version of the Office 365 solution with an improved
configuration experience. To connect Azure AD logs, you can use either the Azure Sentinel Azure AD connector or configure
Azure AD diagnostic settings, which provides richer log data than the Office 365 management logs.
When you onboard Azure Sentinel, specify the Log Analytics workspace that you want the Office 365 solution installed in.
Once you enable the connector, the solution will be available in the workspace and used exactly the same as any other
monitoring solutions you have installed.
Users of the Azure government cloud must install the Office 365 using the steps in this article since Azure Sentinel is not yet
available in the government cloud.
The Office 365 management solution allows you to monitor your Office 365 environment in Azure Monitor.
Monitor user activities on your Office 365 accounts to analyze usage patterns as well as identify behavioral
trends. For example, you can extract specific usage scenarios, such as files that are shared outside your
organization or the most popular SharePoint sites.
Monitor administrator activities to track configuration changes or high privilege operations.
Detect and investigate unwanted user behavior, which can be customized for your organizational needs.
Demonstrate audit and compliance. For example, you can monitor file access operations on confidential files,
which can help you with the audit and compliance process.
Perform operational troubleshooting by using log queries on top of Office 365 activity data of your
organization.
NOTE
PowerShell.
Prerequisites
The following is required prior to this solution being installed and configured.
Organizational Office 365 subscription.
Credentials for a user account that is a Global Administrator.
To receive audit data, you must configure auditing in your Office 365 subscription. Note that mailbox auditing is
configured separately. You can still install the solution and collect other data if auditing is not configured.
Management packs
This solution does not install any management packs in connected management groups.
Install and configure

Start by adding the Office 365 solution to your subscription. Once it's added, you must perform the configuration
steps in this section to give it access to your Office 365 subscription.
Required information
Before you start this procedure, gather the following information.
From your Log Analytics workspace:
Workspace name: The workspace where the Office 365 data will be collected.
Resource group name: The resource group that contains the workspace.
Azure subscription ID: The subscription that contains the workspace.
From your Office 365 subscription:
Username: Email address of an administrative account.
Tenant ID: Unique ID for Office 365 subscription.
Client ID: 16-character string that represents Office 365 client.
Client Secret: Encrypted string necessary for authentication.
Create an Office 365 application in Azure Active Directory
The first step is to create an application in Azure Active Directory that the management solution will use to access
your Office 365 solution.
1. Log in to the Azure portal at https://portal.azure.com.
2. Select Azure Active Directory and then App registrations.
3. Click New registration.
4. Enter an application Name. Select Accounts in any organizational directory (Any Azure AD directory
- Multitenant) for the Supported account types.
5. Click Register and validate the application information.
Configure application for Office 365

1. Select Authentication and verify that Accounts in any organizational directory (Any Azure AD
directory - Multitenant) is selected under Supported account types.
2. Select API permissions and then Add a permission.

3. Click Office 365 Management APIs.
4. Under What type of permissions does your application require? select the following options for both
Application permissions and Delegated permissions:
Read service health information for your organization
Read activity data for your organization
Read activity reports for your organization
5. Click Add permissions.
6. Click Grant admin consent and then click Yes when asked for verification.
Add a secret for the application
1. Select Certificates & secrets and then New client secret.
2. Type in a Description and Duration for the new key.

3. Click Add and then copy the Value that's generated.
Add admin consent

To enable the administrative account for the first time, you must provide administrative consent for the application.
You can do this with a PowerShell script.
1. Save the following script as office365_consent.ps1.
param (
[Parameter(Mandatory=$True)][string]$WorkspaceName,
[Parameter(Mandatory=$True)][string]$ResourceGroupName,
[Parameter(Mandatory=$True)][string]$SubscriptionId
)
$option = [System.StringSplitOptions]::RemoveEmptyEntries
IF ($Subscription -eq $null)

{Login-AzAccount -ErrorAction Stop}
$Subscription = (Select-AzSubscription -SubscriptionId $($SubscriptionId) -ErrorAction Stop)
$Subscription
$Workspace = (Set-AzOperationalInsightsWorkspace -Name $($WorkspaceName) -ResourceGroupName
$($ResourceGroupName) -ErrorAction Stop)
$WorkspaceLocation= $Workspace.Location
$WorkspaceLocation
Function AdminConsent{
$domain='login.microsoftonline.com'
switch ($WorkspaceLocation.Replace(" ","").ToLower()) {
"eastus" {$OfficeAppClientId="d7eb65b0-8167-4b5d-b371-719a2e5e30cc"; break}
"westeurope" {$OfficeAppClientId="c9005da2-023d-40f1-a17a-2b7d91af4ede"; break}
"southeastasia" {$OfficeAppClientId="09c5b521-648d-4e29-81ff-7f3a71b27270"; break}
"australiasoutheast" {$OfficeAppClientId="f553e464-612b-480f-adb9-14fd8b6cbff8"; break}
"westcentralus" {$OfficeAppClientId="98a2a546-84b4-49c0-88b8-11b011dc8c4e"; break}
"japaneast" {$OfficeAppClientId="b07d97d3-731b-4247-93d1-755b5dae91cb"; break}
"uksouth" {$OfficeAppClientId="f232cf9b-e7a9-4ebb-a143-be00850cd22a"; break}
"centralindia" {$OfficeAppClientId="ffbd6cf4-cba8-4bea-8b08-4fb5ee2a60bd"; break}
"canadacentral" {$OfficeAppClientId="c2d686db-f759-43c9-ade5-9d7aeec19455"; break}
"eastus2" {$OfficeAppClientId="7eb65b0-8167-4b5d-b371-719a2e5e30cc"; break}
"westus2" {$OfficeAppClientId="98a2a546-84b4-49c0-88b8-11b011dc8c4e"; break} #Need to check
"usgovvirginia" {$OfficeAppClientId="c8b41a87-f8c5-4d10-98a4-f8c11c3933fe";
$domain='login.microsoftonline.us'; break}
default {$OfficeAppClientId="55b65fb5-b825-43b5-8972-c8b6875867c1";
$domain='login.windows-ppe.net'; break} #Int
}
$domain
Start-Process -FilePath "https://$($domain)/common/adminconsent?
client_id=$($OfficeAppClientId)&state=12345"
}
AdminConsent -ErrorAction Stop
2. Run the script with the following command. You will be prompted twice for credentials. Provide the
credentials for your Log Analytics workspace first and then the global admin credentials for your Office 365
tenant.
.\office365_consent.ps1 -WorkspaceName <Workspace name> -ResourceGroupName <Resource group name> -

SubscriptionId <Subscription ID>
Example:
.\office365_consent.ps1 -WorkspaceName MyWorkspace -ResourceGroupName MyResourceGroup -SubscriptionId

'60b79d74-f4e4-4867-b631- yyyyyyyyyyyy'
3. You will be presented with a window similar to the one below. Click Accept.
Subscribe to Log Analytics workspace

The last step is to subscribe the application to your Log Analytics workspace. You also do this with a PowerShell
script.
1. Save the following script as office365_subscription.ps1.
param (
[Parameter(Mandatory=$True)][string]$SubscriptionId,
[Parameter(Mandatory=$True)][string]$OfficeUsername,
[Parameter(Mandatory=$True)][string]$OfficeTennantId,
[Parameter(Mandatory=$True)][string]$OfficeClientId,
[Parameter(Mandatory=$True)][string]$OfficeClientSecret
)
$line='#------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------'
$line
$line
$Subscription
$Workspace
$OfficeClientSecret =[uri]::EscapeDataString($OfficeClientSecret)
# Client ID for Azure PowerShell

$clientId = "1950a258-227b-4e31-a9cf-717495945fc2"
# Set redirect URI for Azure PowerShell
$redirectUri = "urn:ietf:wg:oauth:2.0:oob"
$adTenant = $Subscription[0].Tenant.Id
$authority = "https://login.windows.net/$adTenant";
$ARMResource ="https://management.azure.com/";
$xms_client_tenant_Id ='55b65fb5-b825-43b5-8972-c8b6875867c1'
switch ($WorkspaceLocation) {
"USGov Virginia" {
$domain='login.microsoftonline.us';
$authority = "https://login.microsoftonline.us/$adTenant";
$ARMResource ="https://management.usgovcloudapi.net/"; break} # US Gov
Virginia
default {
$domain='login.microsoftonline.com';
$ARMResource ="https://management.azure.com/";break}
}
Function RESTAPI-Auth {
$global:SubscriptionID = $Subscription.SubscriptionId
# Set Resource URI to Azure Service Management API
$resourceAppIdURIARM=$ARMResource;
# Authenticate and Acquire Token
# Create Authentication Context tied to Azure AD Tenant
$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -
ArgumentList $authority
# Acquire token
$global:authResultARM = $authContext.AcquireToken($resourceAppIdURIARM, $clientId, $redirectUri, "Auto")
$authHeader = $global:authResultARM.CreateAuthorizationHeader()
$authHeader
}
Function Failure {
$line
$formatstring = "{0} : {1}`n{2}`n" +
" + CategoryInfo : {3}`n" +
" + FullyQualifiedErrorId : {4}`n"
$fields = $_.InvocationInfo.MyCommand.Name,
$_.ErrorDetails.Message,
$_.InvocationInfo.PositionMessage,
$_.CategoryInfo.ToString(),
$_.FullyQualifiedErrorId
$formatstring -f $fields
$_.Exception.Response
$line
break
}
Function Connection-API
{
$ResourceName = "https://manage.office.com"
$SubscriptionId = $Subscription[0].Subscription.Id
$line
$connectionAPIUrl = $ARMResource + 'subscriptions/' + $SubscriptionId + '/resourceGroups/' +
$ResourceGroupName + '/providers/Microsoft.OperationalInsights/workspaces/' + $WorkspaceName +
'/connections/office365connection_' + $SubscriptionId + $OfficeTennantId + '?api-version=2017-04-26-
preview'
$connectionAPIUrl
$line
$xms_client_tenant_Id ='1da8f770-27f4-4351-8cb3-43ee54f14759'
$BodyString = "{
'properties': {
'AuthProvider':'Office365',
'clientId': '" + $OfficeClientId + "',
'clientSecret': '" + $OfficeClientSecret + "',
'Username': '" + $OfficeUsername + "',
'Url': 'https://$($domain)/" + $OfficeTennantId + "/oauth2/token',
},
'etag': '*',
'kind': 'Connection',
'solution': 'Connection',
}"
$params = @{
ContentType = 'application/json'
Headers = @{
'Authorization'="$($authHeader)"
'x-ms-client-tenant-id'=$xms_client_tenant_Id #Prod-'1da8f770-27f4-4351-8cb3-43ee54f14759'
'Content-Type' = 'application/json'
}
Body = $BodyString
Method = 'Put'
URI = $connectionAPIUrl
}
$response = Invoke-WebRequest @params
$response
$line
Function Office-Subscribe-Call{
try{
#-------------------------------------------------------------------------------------------------------
---------------------------------------
$OfficeAPIUrl = $ARMResource + 'subscriptions/' + $SubscriptionId + '/resourceGroups/' +
'/datasources/office365datasources_' + $SubscriptionId + $OfficeTennantId + '?api-version=2015-11-01-
preview'
$OfficeBodyString = "{
'properties': {
'AuthProvider':'Office365',
'office365TenantID': '" + $OfficeTennantId + "',
'connectionID': 'office365connection_" + $SubscriptionId +
$OfficeTennantId + "',
'office365AdminUsername': '" + $OfficeUsername + "',
'contentTypes':'Audit.Exchange,Audit.AzureActiveDirectory,Audit.SharePoint'
},
'etag': '*',
'kind': 'Office365',
'solution': 'Office365',
}"
$Officeparams = @{
Headers = @{
'x-ms-client-tenant-id'=$xms_client_tenant_Id
}
Body = $OfficeBodyString
Method = 'Put'
URI = $OfficeAPIUrl
}
$officeresponse = Invoke-WebRequest @Officeparams

$officeresponse
}
catch{ Failure }
}
#GetDetails
RESTAPI-Auth -ErrorAction Stop
Connection-API -ErrorAction Stop
Office-Subscribe-Call -ErrorAction Stop
2. Run the script with the following command:
.\office365_subscription.ps1 -WorkspaceName <Log Analytics workspace name> -ResourceGroupName <Resource

Group name> -SubscriptionId <Subscription ID> -OfficeUsername <OfficeUsername> -OfficeTennantID <Tenant
ID> -OfficeClientId <Client ID> -OfficeClientSecret <Client secret>
Example:
.\office365_subscription.ps1 -WorkspaceName MyWorkspace -ResourceGroupName MyResourceGroup -

SubscriptionId '60b79d74-f4e4-4867-b631-yyyyyyyyyyyy' -OfficeUsername 'admin@contoso.com' -
OfficeTennantID 'ce4464f8-a172-4dcf-b675-xxxxxxxxxxxx' -OfficeClientId 'f8f14c50-5438-4c51-8956-
zzzzzzzzzzzz' -OfficeClientSecret 'y5Lrwthu6n5QgLOWlqhvKqtVUZXX0exrA2KRHmtHgQb='
Troubleshooting
You may see the following error if your application is already subscribed to this workspace or if this tenant is
subscribed to another workspace.
Invoke-WebRequest : {"Message":"An error has occurred."}

At C:\Users\v-tanmah\Desktop\ps scripts\office365_subscription.ps1:161 char:19
+ $officeresponse = Invoke-WebRequest @Officeparams
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-
WebRequest], WebException
+ FullyQualifiedErrorId :
WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
You may see the following error if invalid parameter values are provided.
Select-AzSubscription : Please provide a valid tenant or a valid subscription.

At line:12 char:18
+ ... cription = (Select-AzSubscription -SubscriptionId $($Subscriptio ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Set-AzContext], ArgumentException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.SetAzContextCommand
Uninstall
You can remove the Office 365 management solution using the process in Remove a management solution. This
will not stop data being collected from Office 365 into Azure Monitor though. Follow the procedure below to
unsubscribe from Office 365 and stop collecting data.
1. Save the following script as office365_unsubscribe.ps1.
param (
[Parameter(Mandatory=$True)][string]$SubscriptionId,
[Parameter(Mandatory=$True)][string]$OfficeTennantId
)
$line='#------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------'
$line
$Subscription
$Workspace
# Client ID for Azure PowerShell

$clientId = "1950a258-227b-4e31-a9cf-717495945fc2"
# Set redirect URI for Azure PowerShell
$redirectUri = "urn:ietf:wg:oauth:2.0:oob"
$adTenant = $Subscription[0].Tenant.Id
$ARMResource ="https://management.azure.com/";
$xms_client_tenant_Id ='55b65fb5-b825-43b5-8972-c8b6875867c1'
switch ($WorkspaceLocation) {
"USGov Virginia" {
$domain='login.microsoftonline.us';
$authority = "https://login.microsoftonline.us/$adTenant";
$ARMResource ="https://management.usgovcloudapi.net/"; break} # US Gov
Virginia
default {
$domain='login.microsoftonline.com';
$ARMResource ="https://management.azure.com/";break}
}
Function RESTAPI-Auth {
$global:SubscriptionID = $Subscription.SubscriptionId
# Set Resource URI to Azure Service Management API
$resourceAppIdURIARM=$ARMResource;
# Authenticate and Acquire Token
# Create Authentication Context tied to Azure AD Tenant
$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -
ArgumentList $authority
# Acquire token
$global:authResultARM = $authContext.AcquireToken($resourceAppIdURIARM, $clientId, $redirectUri, "Auto")
$authHeader
}
Function Office-UnSubscribe-Call{
#-------------------------------------------------------------------------------------------------------
---------------------------------------
$ResourceName = "https://manage.office.com"
$OfficeAPIUrl = $ARMResource + 'subscriptions/' + $SubscriptionId + '/resourceGroups/' +
'/datasources/office365datasources_' + $SubscriptionId + $OfficeTennantId + '?api-version=2015-11-01-
preview'
$Officeparams = @{
Headers = @{
'x-ms-client-tenant-id'=$xms_client_tenant_Id
}
Method = 'Delete'
URI = $OfficeAPIUrl
}
$officeresponse = Invoke-WebRequest @Officeparams

$officeresponse
#GetDetails
RESTAPI-Auth -ErrorAction Stop
Office-UnSubscribe-Call -ErrorAction Stop
2. Run the script with the following command:
.\office365_unsubscribe.ps1 -WorkspaceName <Log Analytics workspace name> -ResourceGroupName <Resource

Group name> -SubscriptionId <Subscription ID> -OfficeTennantID <Tenant ID>
Example:
.\office365_unsubscribe.ps1 -WorkspaceName MyWorkspace -ResourceGroupName MyResourceGroup -

SubscriptionId '60b79d74-f4e4-4867-b631-yyyyyyyyyyyy' -OfficeTennantID 'ce4464f8-a172-4dcf-b675-
xxxxxxxxxxxx'
Data collection
Supported agents
The Office 365 solution doesn't retrieve data from any of the Log Analytics agents. It retrieves data directly from
Office 365.
Collection frequency
It may take a few hours for data to initially be collected. Once it starts collecting, Office 365 sends a webhook
notification with detailed data to Azure Monitor each time a record is created. This record is available in Azure
Monitor within a few minutes after being received.
Using the solution

When you add the Office 365 solution to your Log Analytics workspace, the Office 365 tile will be added to your
dashboard. This tile displays a count and graphical representation of the number of computers in your
environment and their update compliance.
Click on the Office 365 tile to open the Office 365 dashboard.
The dashboard includes the columns in the following table. Each column lists the top ten alerts by count matching
that column's criteria for the specified scope and time range. You can run a log search that provides the entire list
by clicking See all at the bottom of the column or by clicking the column header.
COLUMN DESCRIPTION
Operations Provides information about the active users from your all
monitored Office 365 subscriptions. You will also be able to
see the number of activities that happen over time.
Exchange Shows the breakdown of Exchange Server activities such as

Add-Mailbox Permission, or Set-Mailbox.
SharePoint Shows the top activities that users perform on SharePoint

documents. When you drill down from this tile, the search
page shows the details of these activities, such as the target
document and the location of this activity. For example, for a
File Accessed event, you will be able to see the document
that’s being accessed, its associated account name, and IP
address.
Azure Active Directory Includes top user activities, such as Reset User Password and
Login Attempts. When you drill down, you will be able to see
the details of these activities like the Result Status. This is
mostly helpful if you want to monitor suspicious activities on
your Azure Active Directory.
All records created in the Log Analytics workspace in Azure Monitor by the Office 365 solution have a Type of
OfficeActivity. The OfficeWorkload property determines which Office 365 service the record refers to -
Exchange, AzureActiveDirectory, SharePoint, or OneDrive. The RecordType property specifies the type of
operation. The properties will vary for each operation type and are shown in the tables below.
Common properties
The following properties are common to all Office 365 records.
Type OfficeActivity
ClientIP The IP address of the device that was used when the activity
was logged. The IP address is displayed in either an IPv4 or
IPv6 address format.
OfficeWorkload Office 365 service that the record refers to.
AzureActiveDirectory
Exchange
SharePoint
Operation The name of the user or admin activity.
OrganizationId The GUID for your organization's Office 365 tenant. This value
will always be the same for your organization, regardless of
the Office 365 service in which it occurs.
RecordType Type of operation performed.
ResultStatus Indicates whether the action (specified in the Operation

property) was successful or not. Possible values are Succeeded,
PartiallySucceeded, or Failed. For Exchange admin activity, the
value is either True or False.
UserId The UPN (User Principal Name) of the user who performed the
action that resulted in the record being logged; for example,
my_name@my_domain_name. Note that records for activity
performed by system accounts (such as SHAREPOINT\system
or NTAUTHORITY\SYSTEM) are also included.
UserKey An alternative ID for the user identified in the UserId property.

For example, this property is populated with the passport
unique ID (PUID) for events performed by users in SharePoint,
OneDrive for Business, and Exchange. This property may also
specify the same value as the UserID property for events
occurring in other services and events performed by system
accounts
UserType The type of user that performed the operation.
Admin
Application
DcAdmin
Regular
Reserved
ServicePrincipal
System
Azure Active Directory base

The following properties are common to all Azure Active Directory records.
OfficeWorkload AzureActiveDirectory
RecordType AzureActiveDirectory
AzureActiveDirectory_EventType The type of Azure AD event.
ExtendedProperties The extended properties of the Azure AD event.
Azure Active Directory Account logon

These records are created when an Active Directory user attempts to log on.
RecordType AzureActiveDirectoryAccountLogon
Application The application that triggers the account login event, such as
Office 15.
Client Details about the client device, device OS, and device browser
that was used for the of the account login event.
LoginStatus This property is from OrgIdLogon.LoginStatus directly. The

mapping of various interesting logon failures could be done
by alerting algorithms.
UserDomain The Tenant Identity Information (TII).
Azure Active Directory

These records are created when change or additions are made to Azure Active Directory objects.
RecordType AzureActiveDirectory
AADTarget The user that the action (identified by the Operation property)
was performed on.
Actor The user or service principal that performed the action.
ActorContextId The GUID of the organization that the actor belongs to.
ActorIpAddress The actor's IP address in IPV4 or IPV6 address format.
InterSystemsId The GUID that track the actions across components within the
Office 365 service.
IntraSystemId The GUID that's generated by Azure Active Directory to track

the action.
SupportTicketId The customer support ticket ID for the action in "act-on-

behalf-of" situations.
TargetContextId The GUID of the organization that the targeted user belongs
to.
Data Center Security

These records are created from Data Center Security audit data.
EffectiveOrganization The name of the tenant that the elevation/cmdlet was

targeted at.
ElevationApprovedTime The timestamp for when the elevation was approved.
ElevationApprover The name of a Microsoft manager.
ElevationDuration The duration for which the elevation was active.
ElevationRequestId A unique identifier for the elevation request.
ElevationRole The role the elevation was requested for.
ElevationTime The start time of the elevation.
Start_Time The start time of the cmdlet execution.
Exchange Admin
These records are created when changes are made to Exchange configuration.
OfficeWorkload Exchange
RecordType ExchangeAdmin
ExternalAccess Specifies whether the cmdlet was run by a user in your

organization, by Microsoft datacenter personnel or a
datacenter service account, or by a delegated administrator.
The value False indicates that the cmdlet was run by someone
in your organization. The value True indicates that the cmdlet
was run by datacenter personnel, a datacenter service
account, or a delegated administrator.
ModifiedObjectResolvedName This is the user friendly name of the object that was modified
by the cmdlet. This is logged only if the cmdlet modifies the
object.
OrganizationName The name of the tenant.
OriginatingServer The name of the server from which the cmdlet was executed.
Parameters The name and value for all parameters that were used with
the cmdlet that is identified in the Operations property.
Exchange Mailbox
These records are created when changes or additions are made to Exchange mailboxes.
RecordType ExchangeItem
ClientInfoString Information about the email client that was used to perform
the operation, such as a browser version, Outlook version, and
mobile device information.
Client_IPAddress The IP address of the device that was used when the
operation was logged. The IP address is displayed in either an
IPv4 or IPv6 address format.
ClientMachineName The machine name that hosts the Outlook client.
ClientProcessName The email client that was used to access the mailbox.
ClientVersion The version of the email client .
InternalLogonType Reserved for internal use.
Logon_Type Indicates the type of user who accessed the mailbox and
performed the operation that was logged.
LogonUserDisplayName The user-friendly name of the user who performed the

operation.
LogonUserSid The SID of the user who performed the operation.

MailboxGuid The Exchange GUID of the mailbox that was accessed.
MailboxOwnerMasterAccountSid Mailbox owner account's master account SID.
MailboxOwnerSid The SID of the mailbox owner.
MailboxOwnerUPN The email address of the person who owns the mailbox that
was accessed.
Exchange Mailbox Audit

These records are created when a mailbox audit entry is created.
RecordType ExchangeItem
Item Represents the item upon which the operation was performed
SendAsUserMailboxGuid The Exchange GUID of the mailbox that was accessed to send
email as.
SendAsUserSmtp SMTP address of the user who is being impersonated.
SendonBehalfOfUserMailboxGuid The Exchange GUID of the mailbox that was accessed to send
mail on behalf of.
SendOnBehalfOfUserSmtp SMTP address of the user on whose behalf the email is sent.
Exchange Mailbox Audit Group

These records are created when changes or additions are made to Exchange groups.
OfficeWorkload ExchangeItemGroup
AffectedItems Information about each item in the group.
CrossMailboxOperations Indicates if the operation involved more than one mailbox.
DestMailboxId Set only if the CrossMailboxOperations parameter is True.

Specifies the target mailbox GUID.
DestMailboxOwnerMasterAccountSid Set only if the CrossMailboxOperations parameter is True.

Specifies the SID for the master account SID of the target
mailbox owner.
DestMailboxOwnerSid Set only if the CrossMailboxOperations parameter is True.

Specifies the SID of the target mailbox.
DestMailboxOwnerUPN Set only if the CrossMailboxOperations parameter is True.

Specifies the UPN of the owner of the target mailbox.
DestFolder The destination folder, for operations such as Move.
Folder The folder where a group of items is located.
Folders Information about the source folders involved in an operation;

for example, if folders are selected and then deleted.
SharePoint Base
These properties are common to all SharePoint records.
OfficeWorkload SharePoint
EventSource Identifies that an event occurred in SharePoint. Possible values

are SharePoint or ObjectModel.
ItemType The type of object that was accessed or modified. See the
ItemType table for details on the types of objects.
MachineDomainInfo Information about device sync operations. This information is

reported only if it's present in the request.
MachineId Information about device sync operations. This information is

reported only if it's present in the request.
Site_ The GUID of the site where the file or folder accessed by the
user is located.
Source_Name The entity that triggered the audited operation. Possible

values are SharePoint or ObjectModel.
UserAgent Information about the user's client or browser. This

information is provided by the client or browser.
SharePoint Schema
These records are created when configuration changes are made to SharePoint.
CustomEvent Optional string for custom events.
Event_Data Optional payload for custom events.
ModifiedProperties The property is included for admin events, such as adding a

user as a member of a site or a site collection admin group.
The property includes the name of the property that was
modified (for example, the Site Admin group), the new value of
the modified property (such the user who was added as a site
admin), and the previous value of the modified object.
SharePoint File Operations

These records are created in response to file operations in SharePoint.
OfficeWorkload SharePointFileOperation
DestinationFileExtension The file extension of a file that is copied or moved. This

property is displayed only for FileCopied and FileMoved
events.
DestinationFileName The name of the file that is copied or moved. This property is
displayed only for FileCopied and FileMoved events.
DestinationRelativeUrl The URL of the destination folder where a file is copied or

moved. The combination of the values for SiteURL,
DestinationRelativeURL, and DestinationFileName parameters
is the same as the value for the ObjectID property, which is
the full path name for the file that was copied. This property is
displayed only for FileCopied and FileMoved events.
SharingType The type of sharing permissions that were assigned to the

user that the resource was shared with. This user is identified
by the UserSharedWith parameter.
Site_Url The URL of the site where the file or folder accessed by the
user is located.
SourceFileExtension The file extension of the file that was accessed by the user. This
property is blank if the object that was accessed is a folder.
SourceFileName The name of the file or folder accessed by the user.
SourceRelativeUrl The URL of the folder that contains the file accessed by the
user. The combination of the values for the SiteURL,
SourceRelativeURL, and SourceFileName parameters is the
same as the value for the ObjectID property, which is the full
path name for the file accessed by the user.
UserSharedWith The user that a resource was shared with.

Sample log searches
The following table provides sample log searches for update records collected by this solution.
QUERY DESCRIPTION
Count of all the operations on your Office 365 subscription OfficeActivity | summarize count() by Operation
Usage of SharePoint sites OfficeActivity | where OfficeWorkload =~ "sharepoint" |

summarize count() by SiteUrl | sort by Count asc
File access operations by user type search in (OfficeActivity) OfficeWorkload =~

"azureactivedirectory" and "MyTest"
Search with a specific keyword Type=OfficeActivity OfficeWorkload=azureactivedirectory

"MyTest"
Monitor external actions on Exchange OfficeActivity | where OfficeWorkload =~ "exchange" and

ExternalAccess == true
Next steps
Use log queries in Azure Monitor to view detailed update data.
Create your own dashboards to display your favorite Office 365 search queries.
Create alerts to be proactively notified of important Office 365 activities.
Monitor Surface Hubs with Azure Monitor to track
their health
This article describes how you can use the Surface Hub solution in Azure Monitor to monitor Microsoft Surface
Hub devices. The solution helps you track the health of your Surface Hubs as well as understand how they are
being used.
Each Surface Hub has the Microsoft Monitoring Agent installed. Its through the agent that you can send data from
your Surface Hub to a Log Analytics workspace in Azure Monitor. Log files are read from your Surface Hubs and
are then are sent to Azure Monitor. Issues like servers being offline, the calendar not syncing, or if the device
account is unable to log into Skype are shown in the Surface Hub dashboard in Azure Monitor. By using the data
in the dashboard, you can identify devices that are not running, or that are having other problems, and potentially
apply fixes for the detected issues.

Use the following information to install and configure the solution. In order to manage your Surface Hubs in Azure
Monitor, you'll need the following:
A Log Analytics subscription level that will support the number of devices you want to monitor. Log Analytics
pricing varies depending on how many devices are enrolled, and how much data it processes. You'll want to
take this into consideration when planning your Surface Hub rollout.
Next, you will either add an existing Log Analytics workspace or create a new one. Detailed instructions for using
either method is at Create a Log Analytics workspace in the Azure portal. Once the Log Analytics workspace is
configured, there are two ways to enroll your Surface Hub devices:
Automatically through Intune
Manually through Settings on your Surface Hub device.
Set up monitoring
You can monitor the health and activity of your Surface Hub using Azure Monitor. You can enroll the Surface Hub
by using Intune, or locally by using Settings on the Surface Hub.
Connect Surface Hubs to Azure Monitor through Intune

You'll need the workspace ID and workspace key for the Log Analytics workspace that will manage your Surface
Hubs. You can get those from the workspace settings in the Azure portal.
Intune is a Microsoft product that allows you to centrally manage the Log Analytics workspace configuration
settings that are applied to one or more of your devices. Follow these steps to configure your devices through
Intune:
1. Sign in to Intune.
2. Navigate to Settings > Connected Sources.
3. Create or edit a policy based on the Surface Hub template.
4. Navigate to the Azure Operational Insights section of the policy, and add the Log Analytics Workspace ID
and Workspace Key to the policy.
5. Save the policy.
6. Associate the policy with the appropriate group of devices.
Intune then syncs the Log Analytics settings with the devices in the target group, enrolling them in your Log
Connect Surface Hubs to Azure Monitor using the Settings app

You'll need the workspace ID and workspace key for the Log Analytics workspace that will manage your Surface
Hubs. You can get those from the settings for the Log Analytics workspace in the Azure portal.
If you don't use Intune to manage your environment, you can enroll devices manually through Settings on each
Surface Hub:
1. From your Surface Hub, open Settings.
2. Enter the device admin credentials when prompted.
3. Click This device, and the under Monitoring, click Configure Log Analytics Settings.
4. Select Enable monitoring.
5. In the Log Analytics settings dialog, type the Log Analytics Workspace ID and type the Workspace Key.
6. Click OK to complete the configuration.
A confirmation appears telling you whether or not the configuration was successfully applied to the device. If it
was, a message appears stating that the agent successfully connected to Azure Monitor. The device then starts
sending data to Azure Monitor where you can view and act on it.
Monitor Surface Hubs

Monitoring your Surface Hubs using Azure Monitor is much like monitoring any other enrolled devices.
When you click on the Surface Hub tile, your device's health is displayed.
You can create alerts based on existing or custom log searches. Using the data Azure Monitor collects from your
Surface Hubs, you can search for issues and alert on the conditions that you define for your devices.
Next steps
Use Log queries in Azure Monitor to view detailed Surface Hub data.
Create alerts to notify you when issues occur with your Surface Hubs.
Monitoring solutions in Azure Monitor
Monitoring solutions leverage services in Azure to provide additional insight into the operation of a
particular application or service. This article provides a brief overview of monitoring solutions in Azure
and details on using and installing them.
NOTE
Monitoring solutions were previously referred to as management solutions.
Monitoring solutions typically collect log data and provide queries and views to analyze collected data.
They may also leverage other services such as Azure Automation to perform actions related to the
application or service.
You can add monitoring solutions to Azure Monitor for any applications and services that you use. They
are typically available at no cost but collect data that could invoke usage charges. In addition to solutions
provided by Microsoft, partners and customers can create management solutions to be used in their own
environment or made available to customers through the community.
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still
stored in a Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are
updating the terminology to better reflect the role of logs in Azure Monitor. See Azure Monitor terminology
changes for details.
Use monitoring solutions

Open the Overview page in Azure Monitor to display a tile for each solution installed in the workspace.
2. Open All services and locate Monitor.
3. Under the Insights menu, select More.
4. Use the dropdown boxes at the top of the screen to change the workspace or the time range used for
the tiles.
5. Click on the tile for a solution to open its view which includes more detailed analysis its collected data.
Monitoring solutions can contain multiple types of Azure resources, and you can view any resources
included with a solution just like any other resource. For example, any log queries included in the
solution are listed under Solution Queries in Query explorer You can use those queries when
performing ad hoc analysis with log queries.
List installed monitoring solutions

Use the following procedure to list the monitoring solutions installed in your subscription.
2. Open All services and locate Solutions.
3. Solutions installed in all your workspaces are listed. The name of the solution is followed by the name
of the workspace it's installed in.
4. Use the dropdown boxes at the top of the screen to filter by subscription or resource group.
Click on the name of a solution to open its summary page. This page displays any views included in the
solution and provides different options for the solution itself and its workspace. View the summary page
for a solution by using one of the procedures above to list solutions and then click on the name of the
solution.
Install a monitoring solution
Monitoring solutions from Microsoft and partners are available from the Azure Marketplace. You can
search available solutions and install them using the following procedure. When you install a solution,
you must select a Log Analytics workspace where the solution will be installed and where its data will be
collected.
1. From the list of solutions for your subscription, click Add.
2. Browse or search for a solution. You can also browse solutions from this search link.
3. Locate the monitoring solution you want and read through its description.
4. Click Create to start the installation process.
5. When the installation process starts, you're prompted to specify the Log Analytics workspace and
provide any required configuration for the solution.
Install a solution from the community

Members of the community can submit management solutions to Azure Quickstart Templates. You can
install these solutions directly or download them templates for later installation.
1. Follow the process described in Log Analytics workspace and Automation account to link a
workspace and account.
2. Go to Azure Quickstart Templates.
3. Search for a solution that you're interested in.
4. Select the solution from the results to view its details.
5. Click the Deploy to Azure button.
6. You're prompted to provide information such as the resource group and location in addition to values
for any parameters in the solution.
7. Click Purchase to install the solution.
Log Analytics workspace and Automation account

All monitoring solutions require a Log Analytics workspace to store data collected by the solution and to
host its log searches and views. Some solutions also require an Automation account to contain runbooks
and related resources. The workspace and account must meet the following requirements.
Each installation of a solution can only use one Log Analytics workspace and one Automation
account. You can install the solution separately into multiple workspaces.
If a solution requires an Automation account, then the Log Analytics workspace and Automation
account must be linked to one another. A Log Analytics workspace may only be linked to one
Automation account, and an Automation account may only be linked to one Log Analytics workspace.
To be linked, the Log Analytics workspace and Automation account must be in the same resource
group and region. The exception is a workspace in East US region and Automation account in East US
2.
Create a link between a Log Analytics workspace and Automation account
How you specify the Log Analytics workspace and Automation account depends on the installation
method for your solution.
When you install a solution through the Azure Marketplace, you are prompted for a workspace and
Automation account. The link between them is created if they aren't already linked.
For solutions outside of the Azure Marketplace, you must link the Log Analytics workspace and
Automation account before installing the solution. You can do this by selecting any solution in the
Azure Marketplace and selecting the Log Analytics workspace and Automation account. You don't
have to actually install the solution because the link is created as soon as the Log Analytics workspace
and Automation account are selected. Once the link is created, then you can use that Log Analytics
workspace and Automation account for any solution.
Verify the link between a Log Analytics workspace and Automation account
You can verify the link between a Log Analytics workspace and an Automation account using the
following procedure.
1. Select the Automation account in the Azure portal.
2. Scroll to the Related Resources section of the menu.
3. If the Workspace setting is enabled, then this account is linked to a Log Analytics workspace. You can
click on Workspace to view the details of the workspace.
Remove a monitoring solution

To remove an installed solution, locate it in the list of installed solutions. Click on the name of the solution
to open its summary page and then click on Delete.
Next steps
Get a list of monitoring solutions from Microsoft.
Learn how to create queries to analyze data collected by monitoring solutions.
Targeting monitoring solutions in Azure Monitor
(Preview)
When you add a monitoring solution to your subscription, it's automatically deployed by default to all Windows
and Linux agents connected to your Log Analytics workspace. You may want to manage your costs and limit the
amount of data collected for a solution by limiting it to a particular set of agents. This article describes how to use
Solution Targeting which is a feature that allows you to apply a scope to your solutions.
NOTE
How to target a solution

There are three steps to targeting a solution as described in the following sections.
1. Create a computer group
You specify the computers that you want to include in a scope by creating a computer group in Azure Monitor. The
computer group can be based on a log query or imported from other sources such as Active Directory or WSUS
groups. As described below, only computers that are directly connected to Azure Monitor will be included in the
scope.
Once you have the computer group created in your workspace, then you'll include it in a scope configuration that
can be applied to one or more solutions.
2. Create a scope configuration
A Scope Configuration includes one or more computer groups and can be applied to one or more solutions.
Create a scope configuration using the following process.
1. In the Azure portal, navigate to Log Analytics workspaces and select your workspace.
2. In the properties for the workspace under Workspace Data Sources select Scope Configurations.
3. Click Add to create a new scope configuration.
4. Type a Name for the scope configuration.
5. Click Select Computer Groups.
6. Select the computer group that you created and optionally any other groups to add to the configuration. Click
Select.
7. Click OK to create the scope configuration.
3. Apply the scope configuration to a solution.
Once you have a scope configuration, then you can apply it to one or more solutions. Note that while a single
scope configuration can be used with multiple solutions, each solution can only use one scope configuration.
Apply a scope configuration using the following process.
1. In the Azure portal, navigate to Log Analytics workspaces and select your workspace.
2. In the properties for the workspace select Solutions.
3. Click on the solution you want to scope.
4. In the properties for the solution under Workspace Data Sources select Solution Targeting. If the option is
not available then this solution cannot be targeted.
5. Click Add scope configuration. If you already have a configuration applied to this solution then this option
will be unavailable. You must remove the existing configuration before adding another one.
6. Click on the scope configuration that you created.
7. Watch the Status of the configuration to ensure that it shows Succeeded. If the status indicates an error, then
click the ellipse to the right of the configuration and select Edit scope configuration to make changes.
Solutions and agents that can't be targeted

Following are the criteria for agents and solutions that can't be used with solution targeting.
Solution targeting only applies to solutions that deploy to agents.
Solution targeting only applies to solutions provided by Microsoft. It does not apply to solutions created by
yourself or partners.
You can only filter out agents that connect directly to Azure Monitor. Solutions will automatically deploy to any
agents that are part of a connected Operations Manager management group whether or not they're included in
a scope configuration.
Exceptions
Solution targeting cannot be used with the following solutions even though they fit the stated criteria.
Agent Health Assessment
Next steps
Learn more about monitoring solutions including the solutions that are available to install in your environment
at Add Azure Log Analytics monitoring solutions to your workspace.
Learn more about creating computer groups at Computer groups in Azure Monitor log queries.
Custom metrics in Azure Monitor
As you deploy resources and applications in Azure, you'll want to start collecting telemetry to gain insights into
their performance and health. Azure makes some metrics available to you out of the box. These metrics are called
standard or platform. However, they're limited in nature. You might want to collect some custom performance
indicators or business-specific metrics to provide deeper insights. These custom metrics can be collected via
your application telemetry, an agent that runs on your Azure resources, or even an outside-in monitoring system
and submitted directly to Azure Monitor. After they're published to Azure Monitor, you can browse, query, and
alert on custom metrics for your Azure resources and applications side by side with the standard metrics emitted
by Azure.
Send custom metrics

Custom metrics can be sent to Azure Monitor via several methods:
Instrument your application by using the Azure Application Insights SDK and send custom telemetry to
Azure Monitor.
Install the Windows Azure Diagnostics (WAD ) extension on your Azure VM, virtual machine scale set, classic
VM, or classic Cloud Services and send performance counters to Azure Monitor.
Install the InfluxData Telegraf agent on your Azure Linux VM and send metrics by using the Azure Monitor
output plug-in.
Send custom metrics directly to the Azure Monitor REST API,
https://<azureregion>.monitoring.azure.com/<AzureResourceID>/metrics .
When you send custom metrics to Azure Monitor, each data point, or value, reported must include the following
information.
Authentication
To submit custom metrics to Azure Monitor, the entity that submits the metric needs a valid Azure Active
Directory (Azure AD ) token in the Bearer header of the request. There are a few supported ways to acquire a
valid bearer token:
1. Managed identities for Azure resources. Gives an identity to an Azure resource itself, such as a VM. Managed
Service Identity (MSI) is designed to give resources permissions to carry out certain operations. An example
is allowing a resource to emit metrics about itself. A resource, or its MSI, can be granted Monitoring Metrics
Publisher permissions on another resource. With this permission, the MSI can emit metrics for other
resources as well.
2. Azure AD Service Principal. In this scenario, an Azure AD application, or service, can be assigned permissions
to emit metrics about an Azure resource. To authenticate the request, Azure Monitor validates the application
token by using Azure AD public keys. The existing Monitoring Metrics Publisher role already has this
permission. It's available in the Azure portal. The service principal, depending on what resources it emits
custom metrics for, can be given the Monitoring Metrics Publisher role at the scope required. Examples are
a subscription, resource group, or specific resource.
NOTE
When you request an Azure AD token to emit custom metrics, ensure that the audience or resource the token is requested
for is https://monitoring.azure.com/. Be sure to include the trailing '/'.
Subject
This property captures which Azure resource ID the custom metric is reported for. This information will be
encoded in the URL of the API call being made. Each API can only submit metric values for a single Azure
resource.
NOTE
You can't emit custom metrics against the resource ID of a resource group or subscription.
Region
This property captures what Azure region the resource you're emitting metrics for is deployed in. Metrics must
be emitted to the same Azure Monitor regional endpoint as the region the resource is deployed in. For example,
custom metrics for a VM deployed in West US must be sent to the WestUS regional Azure Monitor endpoint.
The region information is also encoded in the URL of the API call.
NOTE
During the public preview, custom metrics are only available in a subset of Azure regions. A list of supported regions is
documented in a later section of this article.
Timestamp
Each data point sent to Azure Monitor must be marked with a timestamp. This timestamp captures the DateTime
at which the metric value is measured or collected. Azure Monitor accepts metric data with timestamps as far as
20 minutes in the past and 5 minutes in the future. The timestamp must be in ISO 8601 format.
Namespace
Namespaces are a way to categorize or group similar metrics together. By using namespaces, you can achieve
isolation between groups of metrics that might collect different insights or performance indicators. For example,
you might have a namespace called ContosoMemoryMetrics that tracks memory-use metrics which profile
your app. Another namespace called ContosoAppTransaction might track all metrics about user transactions in
your application.
Name
Name is the name of the metric that's being reported. Usually, the name is descriptive enough to help identify
what's measured. An example is a metric that measures the number of memory bytes used on a given VM. It
might have a metric name like Memory Bytes In Use.
Dimension keys
A dimension is a key or value pair that helps describe additional characteristics about the metric being collected.
By using the additional characteristics, you can collect more information about the metric, which allows for
deeper insights. For example, the Memory Bytes In Use metric might have a dimension key called Process that
captures how many bytes of memory each process on a VM consumes. By using this key, you can filter the
metric to see how much memory specific processes use or to identify the top five processes by memory usage.
Dimensions are optional, not all metrics may have dimensions. A custom metric can have up to 10 dimensions.
Dimension values
When reporting a metric data point, for each dimension key on the metric being reported, there's a
corresponding dimension value. For example, you might want to report the memory used by the ContosoApp on
your VM:
The metric name would be Memory Bytes in Use.
The dimension key would be Process.
The dimension value would be ContosoApp.exe.
When publishing a metric value, you can only specify a single dimension value per dimension key. If you collect
the same memory utilization for multiple processes on the VM, you can report multiple metric values for that
timestamp. Each metric value would specify a different dimension value for the Process dimension key.
Dimensions are optional, not all metrics may have dimensions. If a metric post defines dimension keys,
corresponding dimension values are mandatory.
Metric values
Azure Monitor stores all metrics at one-minute granularity intervals. We understand that during a given minute,
a metric might need to be sampled several times. An example is CPU utilization. Or it might need to be
measured for many discrete events. An example is sign-in transaction latencies. To limit the number of raw
values you have to emit and pay for in Azure Monitor, you can locally pre-aggregate and emit the values:
Min: The minimum observed value from all the samples and measurements during the minute.
Max: The maximum observed value from all the samples and measurements during the minute.
Sum: The summation of all the observed values from all the samples and measurements during the minute.
Count: The number of samples and measurements taken during the minute.
For example, if there were 4 sign-in transactions to your app during a given a minute, the resulting measured
latencies for each might be as follows:
TRANSACTION 1 TRANSACTION 2 TRANSACTION 3 TRANSACTION 4
7 ms 4 ms 13 ms 16 ms
Then the resulting metric publication to Azure Monitor would be as follows:

Min: 4
Max: 16
Sum: 40
Count: 4
If your application is unable to pre-aggregate locally and needs to emit each discrete sample or event
immediately upon collection, you can emit the raw measure values. For example, each time a sign-in transaction
occurs on your app, you publish a metric to Azure Monitor with only a single measurement. So for a sign-in
transaction that took 12 ms, the metric publication would be as follows:
Min: 12
Max: 12
Sum: 12
Count: 1
With this process, you can emit multiple values for the same metric plus dimension combination during a given
minute. Azure Monitor then takes all the raw values emitted for a given minute and aggregates them together.
Sample custom metric publication
In the following example, you create a custom metric called Memory Bytes in Use under the metric namespace
Memory Profile for a virtual machine. The metric has a single dimension called Process. For the given
timestamp, we emit metric values for two different processes:
{
"time": "2018-08-20T11:25:20-7:00",
"data": {
"baseData": {
"metric": "Memory Bytes in Use",

"namespace": "Memory Profile",
"dimNames": [
"Process" ],
"series": [
{
"dimValues": [
"ContosoApp.exe"
],
"min": 10,
"max": 89,
"sum": 190,
"count": 4
},
{
"dimValues": [
"SalesApp.exe"
],
"min": 10,
"max": 23,
"sum": 86,
"count": 4
}
]
}
}
}
NOTE
Application Insights, the diagnostics extension, and the InfluxData Telegraf agent are already configured to emit metric
values against the correct regional endpoint and carry all of the preceding properties in each emission.
Custom metric definitions

There's no need to predefine a custom metric in Azure Monitor before it's emitted. Each metric data point
published contains namespace, name, and dimension information. So the first time a custom metric is emitted to
Azure Monitor, a metric definition is automatically created. This metric definition is then discoverable on any
resource the metric is emitted against via the metric definitions.
NOTE
Azure Monitor doesn’t yet support defining Units for a custom metric.
Using custom metrics

After custom metrics are submitted to Azure Monitor, you can browse them via the Azure portal and query them
via the Azure Monitor REST APIs. You can also create alerts on them to notify you when certain conditions are
met.
Browse your custom metrics via the Azure portal
2. Select the Monitor pane.
3. Select Metrics.
4. Select a resource you've emitted custom metrics against.
5. Select the metrics namespace for your custom metric.
6. Select the custom metric.
Supported regions
During the public preview, the ability to publish custom metrics is available only in a subset of Azure regions.
This restriction means that metrics can be published only for resources in one of the supported regions. The
following table lists the set of supported Azure regions for custom metrics. It also lists the corresponding
endpoints that metrics for resources in those regions should be published to:
AZURE REGION REGIONAL ENDPOINT PREFIX
US and Canada
West Central US https://westcentralus.monitoring.azure.com/
West US 2 https://westus2.monitoring.azure.com/
North Central US https://northcentralus.monitoring.azure.com
South Central US https://southcentralus.monitoring.azure.com/
Central US https://centralus.monitoring.azure.com
Canada Central https://canadacentral.monitoring.azure.comc
East US https://eastus.monitoring.azure.com/
Europe
North Europe https://northeurope.monitoring.azure.com/
West Europe https://westeurope.monitoring.azure.com/
UK South https://uksouth.monitoring.azure.com
France Central https://francecentral.monitoring.azure.com
Africa
South Africa North https://southafricanorth.monitoring.azure.com
Asia
Central India https://centralindia.monitoring.azure.com
Australia East https://australiaeast.monitoring.azure.com
Japan East https://japaneast.monitoring.azure.com

AZURE REGION REGIONAL ENDPOINT PREFIX
Southeast Asia https://southeastasia.monitoring.azure.com
East Asia https://eastasia.monitoring.azure.com
Korea Central https://koreacentral.monitoring.azure.com
Quotas and limits

Azure Monitor imposes the following usage limits on custom metrics:
CATEGORY LIMIT
Active time series/subscriptions/region 50,000
Dimension keys per metric 10
String length for metric namespaces, metric names, 256 characters

dimension keys, and dimension values
An active time series is defined as any unique combination of metric, dimension key, or dimension value that has
had metric values published in the past 12 hours.
Next steps
Use custom metrics from different services:
Virtual Machines
Virtual machine scale set
Azure Virtual Machines (classic)
Linux Virtual Machine using the Telegraf agent
REST API
Classic Cloud Services
Send custom metrics for an Azure resource to the
Azure Monitor metric store by using a REST API
This article shows you how to send custom metrics for Azure resources to the Azure Monitor metrics store via a
REST API. After the metrics are in Azure Monitor, you can do all the things with them that you do with standard
metrics. Examples are charting, alerting, and routing them to other external tools.
NOTE
The REST API only permits sending custom metrics for Azure resources. To send metrics for resources in different
environments or on-premises, you can use Application Insights.
Create and authorize a service principal to emit metrics

Create a service principal in your Azure Active Directory tenant by using the instructions found at Create a service
principal.
Note the following while you go through this process:
You can enter any URL for the sign-in URL.
Create a new client secret for this app.
Give the app created as part of step 1, Monitoring Metrics Publisher, permissions to the resource you wish to emit
metrics against. If you plan to use the app to emit custom metrics against many resources, you can grant these
permissions at the resource group or subscription level.
Get an authorization token

Open a command prompt and run the following command:
curl -X POST https://login.microsoftonline.com/<yourtenantid>/oauth2/token -F "grant_type=client_credentials"

-F "client_id=<insert clientId from earlier step>" -F "client_secret=<insert client secret from earlier step>"
-F "resource=https://monitoring.azure.com/"
Save the access token from the response.

Emit the metric via the REST API
1. Paste the following JSON into a file, and save it ascustommetric.json on your local computer. Update the
time parameter in the JSON file:
{
"time": "2018-09-13T16:34:20",
"data": {
"baseData": {
"metric": "QueueDepth",
"namespace": "QueueProcessing",
"dimNames": [
"QueueName",
"MessageType"
],
"series": [
{
"dimValues": [
"ImagesToProcess",
"JPEG"
],
"min": 3,
"max": 20,
"sum": 28,
"count": 3
}
]
}
}
}
2. In your command prompt window, post the metric data:

azureRegion. Must match the deployment region of the resource you're emitting metrics for.
resourceID. Resource ID of the Azure resource you're tracking the metric against.
AccessToken. Paste the token that you acquired previously.
curl -X POST https://<azureRegion>.monitoring.azure.com/<resourceId>/metrics -H "Content-Type:

application/json" -H "Authorization: Bearer <AccessToken>" -d @custommetric.json
3. Change the timestamp and values in the JSON file.

4. Repeat the previous two steps a few times, so you have data for several minutes.
Troubleshooting
If you receive an error message with some part of the process, consider the following troubleshooting
information:
1. You can't issue metrics against a subscription or resource group as your Azure resource.
2. You can't put a metric into the store that's over 20 minutes old. The metric store is optimized for alerting and
real-time charting.
3. The number of dimension names should match the values and vice versa. Check the values.
4. You might be emitting metrics against a region that doesn’t support custom metrics. See supported regions.
View your metrics

2. In the left-hand menu, select Monitor.

5. In the resource drop-down menu, select the resource you emitted the metric against.
6. In the namespaces drop-down menu, select QueueProcessing.
7. In the metrics drop-down menu, select QueueDepth.
Next steps
Send log data to Azure Monitor with the HTTP
Data Collector API (public preview)
This article shows you how to use the HTTP Data Collector API to send log data to Azure Monitor from a REST
API client. It describes how to format data collected by your script or application, include it in a request, and
have that request authorized by Azure Monitor. Examples are provided for PowerShell, C#, and Python.
NOTE
NOTE
The Azure Monitor HTTP Data Collector API is in public preview.
Concepts
You can use the HTTP Data Collector API to send log data to a Log Analytics workspace in Azure Monitor from
any client that can call a REST API. This might be a runbook in Azure Automation that collects management
data from Azure or another cloud, or it might be an alternate management system that uses Azure Monitor to
consolidate and analyze log data.
All data in the Log Analytics workspace is stored as a record with a particular record type. You format your data
to send to the HTTP Data Collector API as multiple records in JSON. When you submit the data, an individual
record is created in the repository for each record in the request payload.
Create a request
To use the HTTP Data Collector API, you create a POST request that includes the data to send in JavaScript
Object Notation (JSON ). The next three tables list the attributes that are required for each request. We describe
each attribute in more detail later in the article.
Request URI
ATTRIBUTE PROPERTY
Method POST
URI https://<CustomerId>.ods.opinsights.azure.com/api/logs?
Content type application/json
Request URI parameters

CustomerID The unique identifier for the Log Analytics workspace.
Resource The API resource name: /api/logs.
API Version The version of the API to use with this request. Currently, it's
2016-04-01.
Request headers
HEADER DESCRIPTION
Authorization The authorization signature. Later in the article, you can read
about how to create an HMAC-SHA256 header.
Log-Type Specify the record type of the data that is being submitted.
Can only contain letters, numbers, and underscore (_), and
may not exceed 100 characters.
x-ms-date The date that the request was processed, in RFC 1123
format.
x-ms-AzureResourceId Resource ID of the Azure resource the data should be

associated with. This populates the _ResourceId property
and allows the data to be included in resource-context
queries. If this field isn't specified, the data will not be
included in resource-context queries.
time-generated-field The name of a field in the data that contains the timestamp
of the data item. If you specify a field then its contents are
used for TimeGenerated. If this field isn’t specified, the
default for TimeGenerated is the time that the message is
ingested. The contents of the message field should follow
the ISO 8601 format YYYY-MM-DDThh:mm:ssZ.
Authorization
Any request to the Azure Monitor HTTP Data Collector API must include an authorization header. To
authenticate a request, you must sign the request with either the primary or the secondary key for the
workspace that is making the request. Then, pass that signature as part of the request.
Here's the format for the authorization header:
Authorization: SharedKey <WorkspaceID>:<Signature>
WorkspaceID is the unique identifier for the Log Analytics workspace. Signature is a Hash-based Message
Authentication Code (HMAC ) that is constructed from the request and then computed by using the SHA256
algorithm. Then, you encode it by using Base64 encoding.
Use this format to encode the SharedKey signature string:
StringToSign = VERB + "\n" +

Content-Length + "\n" +
Content-Type + "\n" +
x-ms-date + "\n" +
"/api/logs";
Here's an example of a signature string:
POST\n1024\napplication/json\nx-ms-date:Mon, 04 Apr 2016 08:00:00 GMT\n/api/logs
When you have the signature string, encode it by using the HMAC -SHA256 algorithm on the UTF -8-encoded
string, and then encode the result as Base64. Use this format:
Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
The samples in the next sections have sample code to help you create an authorization header.
Request body
The body of the message must be in JSON. It must include one or more records with the property name and
value pairs in the following format. The property name can only contain letters, numbers, and underscore (_).
[
{
"property 1": "value1",
"property 4": "value4"
}
]
You can batch multiple records together in a single request by using the following format. All the records must
be the same record type.
[
{
},
{
}
]
Record type and properties

You define a custom record type when you submit data through the Azure Monitor HTTP Data Collector API.
Currently, you can't write data to existing record types that were created by other data types and solutions.
Azure Monitor reads the incoming data and then creates properties that match the data types of the values that
you enter.
Each request to the Data Collector API must include a Log-Type header with the name for the record type. The
suffix _CL is automatically appended to the name you enter to distinguish it from other log types as a custom
log. For example, if you enter the name MyNewRecordType, Azure Monitor creates a record with the type
MyNewRecordType_CL. This helps ensure that there are no conflicts between user-created type names and
those shipped in current or future Microsoft solutions.
To identify a property's data type, Azure Monitor adds a suffix to the property name. If a property contains a
null value, the property is not included in that record. This table lists the property data type and corresponding
suffix:
PROPERTY DATA TYPE SUFFIX
String _s
Boolean _b
Double _d
Date/time _t
GUID (stored as a string) _g
The data type that Azure Monitor uses for each property depends on whether the record type for the new
record already exists.
If the record type does not exist, Azure Monitor creates a new one using the JSON type inference to
determine the data type for each property for the new record.
If the record type does exist, Azure Monitor attempts to create a new record based on existing properties. If
the data type for a property in the new record doesn’t match and can’t be converted to the existing type, or if
the record includes a property that doesn’t exist, Azure Monitor creates a new property that has the relevant
suffix.
For example, this submission entry would create a record with three properties, number_d, boolean_b, and
string_s:
If you then submitted this next entry, with all values formatted as strings, the properties would not change.
These values can be converted to existing data types:
But, if you then made this next submission, Azure Monitor would create the new properties boolean_d and
string_d. These values can't be converted:
If you then submitted the following entry, before the record type was created, Azure Monitor would create a
record with three properties, number_s, boolean_s, and string_s. In this entry, each of the initial values is
formatted as a string:
Reserved properties
The following properties are reserved and should not be used in a custom record type. You will receive an error
if your payload includes any of these property names.
tenant
Data limits
There are some constraints around the data posted to the Azure Monitor Data collection API.
Maximum of 30 MB per post to Azure Monitor Data Collector API. This is a size limit for a single post. If the
data from a single post that exceeds 30 MB, you should split the data up to smaller sized chunks and send
them concurrently.
Maximum of 32 KB limit for field values. If the field value is greater than 32 KB, the data will be truncated.
Recommended maximum number of fields for a given type is 50. This is a practical limit from a usability and
search experience perspective.
A table in a Log Analytics workspace only supports up to 500 columns (referred to as a field in this article).
The maximum number of characters for the column name is 500.
Return codes
The HTTP status code 200 means that the request has been received for processing. This indicates that the
operation completed successfully.
This table lists the complete set of status codes that the service might return:
CODE STATUS ERROR CODE DESCRIPTION
200 OK The request was

successfully accepted.
400 Bad request InactiveCustomer The workspace has been

closed.
400 Bad request InvalidApiVersion The API version that you

specified was not
recognized by the service.
400 Bad request InvalidCustomerId The workspace ID specified

is invalid.
400 Bad request InvalidDataFormat Invalid JSON was

submitted. The response
body might contain more
information about how to
resolve the error.
400 Bad request InvalidLogType The log type specified

contained special characters
or numerics.
400 Bad request MissingApiVersion The API version wasn’t

specified.
400 Bad request MissingContentType The content type wasn’t

specified.
400 Bad request MissingLogType The required value log type

wasn’t specified.
400 Bad request UnsupportedContentType The content type was not

set to application/json.
403 Forbidden InvalidAuthorization The service failed to

authenticate the request.
Verify that the workspace
ID and connection key are
valid.
404 Not Found Either the URL provided is

incorrect, or the request is
too large.
CODE STATUS ERROR CODE DESCRIPTION
429 Too Many Requests The service is experiencing a

high volume of data from
your account. Please retry
the request later.
500 Internal Server Error UnspecifiedError The service encountered an

internal error. Please retry
the request.
503 Service Unavailable ServiceUnavailable The service currently is

unavailable to receive
requests. Please retry your
request.
Query data
To query data submitted by the Azure Monitor HTTP Data Collector API, search for records with Type that is
equal to the LogType value that you specified, appended with _CL. For example, if you used MyCustomLog,
then you'd return all records with MyCustomLog_CL .
Sample requests
In the next sections, you'll find samples of how to submit data to the Azure Monitor HTTP Data Collector API by
using different programming languages.
For each sample, do these steps to set the variables for the authorization header:
1. In the Azure portal, locate your Log Analytics workspace.
2. Select Advanced Settings and then Connected Sources.
3. To the right of Workspace ID, select the copy icon, and then paste the ID as the value of the Customer ID
variable.
4. To the right of Primary Key, select the copy icon, and then paste the ID as the value of the Shared Key
variable.
Alternatively, you can change the variables for the log type and JSON data.
PowerShell sample
# Replace with your Workspace ID

$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# Replace with your Primary Key

$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# Specify the name of the record type that you'll be creating

$LogType = "MyRecordType"
# You can use an optional field to specify the timestamp from the data. If the time field is not specified,
Azure Monitor assumes the time is the message ingestion time
$TimeStampField = "DateValue"
# Create two records with the same set of properties to create

$json = @"
[{ "StringValue": "MyString1",
"NumberValue": 42,
"BooleanValue": true,
"DateValue": "2019-09-12T20:00:00.625Z",
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{ "StringValue": "MyString2",
"NumberValue": 43,
"BooleanValue": false,
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@
# Create the function to create the authorization signature

Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
$xHeaders = "x-ms-date:" + $date
$stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" +
$resource
$bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
$keyBytes = [Convert]::FromBase64String($sharedKey)
$sha256 = New-Object System.Security.Cryptography.HMACSHA256

$sha256.Key = $keyBytes
$calculatedHash = $sha256.ComputeHash($bytesToHash)
$encodedHash = [Convert]::ToBase64String($calculatedHash)
$authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
return $authorization
}
# Create the function to create and post the request

Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
$method = "POST"
$contentType = "application/json"
$resource = "/api/logs"
$rfc1123date = [DateTime]::UtcNow.ToString("r")
$contentLength = $body.Length
$signature = Build-Signature `
-customerId $customerId `
-sharedKey $sharedKey `
-date $rfc1123date `
-contentLength $contentLength `
-method $method `
-contentType $contentType `
-resource $resource
$uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"
$headers = @{
"Authorization" = $signature;
"Log-Type" = $logType;
"x-ms-date" = $rfc1123date;
"time-generated-field" = $TimeStampField;
}
$response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -
Body $body -UseBasicParsing
return $response.StatusCode
# Submit the data to the API endpoint

Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body
([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType
C# sample
using System;
using System;
using System.Net;
using System.Net.Http.Headers;
using System.Security.Cryptography;
using System.Text;
namespace OIAPIExample
{
class ApiExample
{
// An example JSON object, with key/value pairs
static string json = @"[{""DemoField1"":""DemoValue1"",""DemoField2"":""DemoValue2""},
{""DemoField3"":""DemoValue3"",""DemoField4"":""DemoValue4""}]";
// Update customerId to your Log Analytics workspace ID

static string customerId = "xxxxxxxx-xxx-xxx-xxx-xxxxxxxxxxxx";
// For sharedKey, use either the primary or the secondary Connected Sources client authentication key
static string sharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
// LogName is name of the event type that is being submitted to Azure Monitor
static string LogName = "DemoExample";
// You can use an optional field to specify the timestamp from the data. If the time field is not
specified, Azure Monitor assumes the time is the message ingestion time
static string TimeStampField = "";
static void Main()

{
// Create a hash for the API signature
var datestring = DateTime.UtcNow.ToString("r");
var jsonBytes = Encoding.UTF8.GetBytes(json);
string stringToHash = "POST\n" + jsonBytes.Length + "\napplication/json\n" + "x-ms-date:" + datestring +
"\n/api/logs";
string hashedString = BuildSignature(stringToHash, sharedKey);
string signature = "SharedKey " + customerId + ":" + hashedString;
PostData(signature, datestring, json);

}
// Build the API signature

public static string BuildSignature(string message, string secret)
{
var encoding = new System.Text.ASCIIEncoding();
byte[] keyByte = Convert.FromBase64String(secret);
byte[] messageBytes = encoding.GetBytes(message);
using (var hmacsha256 = new HMACSHA256(keyByte))
{
byte[] hash = hmacsha256.ComputeHash(messageBytes);
return Convert.ToBase64String(hash);
}
}
// Send a request to the POST API endpoint

public static void PostData(string signature, string date, string json)
{
try
{
string url = "https://" + customerId + ".ods.opinsights.azure.com/api/logs?api-version=2016-04-01";
System.Net.Http.HttpClient client = new System.Net.Http.HttpClient();

client.DefaultRequestHeaders.Add("Accept", "application/json");
client.DefaultRequestHeaders.Add("Log-Type", LogName);
client.DefaultRequestHeaders.Add("Authorization", signature);
client.DefaultRequestHeaders.Add("x-ms-date", date);
client.DefaultRequestHeaders.Add("time-generated-field", TimeStampField);
System.Net.Http.HttpContent httpContent = new StringContent(json, Encoding.UTF8);

System.Net.Http.HttpContent httpContent = new StringContent(json, Encoding.UTF8);
httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
Task<System.Net.Http.HttpResponseMessage> response = client.PostAsync(new Uri(url), httpContent);
System.Net.Http.HttpContent responseContent = response.Result.Content;

string result = responseContent.ReadAsStringAsync().Result;
Console.WriteLine("Return Result: " + result);
}
catch (Exception excep)
{
Console.WriteLine("API Post Exception: " + excep.Message);
}
}
}
}
Python 2 sample
import json
import requests
import datetime
import hashlib
import hmac
import base64
# Update the customer ID to your Log Analytics workspace ID

customer_id = 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# For the shared key, use either the primary or the secondary Connected Sources client authentication key
shared_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# The log type is the name of the event that is being submitted
log_type = 'WebMonitorTest'
# An example JSON web monitor object

json_data = [{
"slot_ID": 12345,
"ID": "5cdad72f-c848-4df0-8aaa-ffe033e75d57",
"availability_Value": 100,
"performance_Value": 6.954,
"measurement_Name": "last_one_hour",
"duration": 3600,
"warning_Threshold": 0,
"critical_Threshold": 0,
"IsActive": "true"
},
{
"slot_ID": 67890,
"ID": "b6bee458-fb65-492e-996d-61c4d7fbb942",
"availability_Value": 100,
"performance_Value": 3.379,
"measurement_Name": "last_one_hour",
"duration": 3600,
"warning_Threshold": 0,
"critical_Threshold": 0,
"IsActive": "false"
}]
body = json.dumps(json_data)
#####################
######Functions######
#####################
# Build the API signature

def build_signature(customer_id, shared_key, date, content_length, method, content_type, resource):
x_headers = 'x-ms-date:' + date
string_to_hash = method + "\n" + str(content_length) + "\n" + content_type + "\n" + x_headers + "\n" +
string_to_hash = method + "\n" + str(content_length) + "\n" + content_type + "\n" + x_headers + "\n" +
resource
bytes_to_hash = bytes(string_to_hash).encode('utf-8')
decoded_key = base64.b64decode(shared_key)
encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash, digestmod=hashlib.sha256).digest())
authorization = "SharedKey {}:{}".format(customer_id,encoded_hash)
return authorization
# Build and send a request to the POST API

def post_data(customer_id, shared_key, body, log_type):
method = 'POST'
content_type = 'application/json'
resource = '/api/logs'
rfc1123date = datetime.datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
content_length = len(body)
signature = build_signature(customer_id, shared_key, rfc1123date, content_length, method, content_type,
resource)
uri = 'https://' + customer_id + '.ods.opinsights.azure.com' + resource + '?api-version=2016-04-01'
headers = {
'content-type': content_type,
'Authorization': signature,
'Log-Type': log_type,
'x-ms-date': rfc1123date
}
response = requests.post(uri,data=body, headers=headers)

if (response.status_code >= 200 and response.status_code <= 299):
print 'Accepted'
else:
print "Response code: {}".format(response.status_code)
post_data(customer_id, shared_key, body, log_type)
Alternatives and considerations

While the Data Collector API should cover most of your needs to collect free-form data into Azure Logs, there
are instances where an alternative might be required to overcome some of the limitations of the API. All your
options are as follows, major considerations included:
ALTERNATIVE DESCRIPTION BEST SUITED FOR
Custom events: Native SDK-based Application Insights, typically Data that is generated within
ingestion in Application Insights instrumented through an SDK within your application, but not picked
your application, offers the ability for up by SDK through one of the
you to send custom data through default data types (requests,
Custom Events. dependencies, exceptions, and
so on).
Data that is most often
correlated to other application
data in Application Insights
ALTERNATIVE DESCRIPTION BEST SUITED FOR
Data Collector API in Azure Monitor The Data Collector API in Azure Data that is not necessarily
Logs Monitor Logs is a completely open- generated within an application
ended way to ingest data. Any data instrumented within
formatted in a JSON object can be sent Application Insights.
here. Once sent, it will be processed, Examples include lookup and
and available in Logs to be correlated fact tables, reference data, pre-
with other data in Logs or against aggregated statistics, and so
other Application Insights data. on.
Intended for data that will be
It is fairly easy to upload the data as cross-referenced against other
files to an Azure Blob blob, from where Azure Monitor data
these files will be processed and (Application Insights, other
uploaded to Log Analytics. Please see Logs data types, Security
this article for a sample Center, Azure Monitor for
implementation of such a pipeline. Containers/VMs, and so on).
Azure Data Explorer Azure Data Explorer (ADX) is the data Data that will not be correlated
platform that powers Application to any other data under
Insights Analytics and Azure Monitor Application Insights or Logs.
Logs. Now Generally Available ("GA"), Data requiring advanced
using the data platform in its raw form ingestion or processing
provides you complete flexibility (but capabilities not today available
requiring the overhead of in Azure Monitor Logs.
management) over the cluster (RBAC,
retention rate, schema, and so on).
ADX provides many ingestion options
including CSV, TSV, and JSON files.
Next steps
Use the Log Search API to retrieve data from the Log Analytics workspace.
Learn more about how create a data pipeline with the Data Collector API using Logic Apps workflow to
Azure Monitor.
Create a data pipeline with the Data Collector API
The Azure Monitor Data Collector API allows you to import any custom log data into a Log Analytics workspace in
Azure Monitor. The only requirements are that the data be JSON -formatted and split into 30 MB or less segments.
This is a completely flexible mechanism that can be plugged into in many ways: from data being sent directly from
your application, to one-off adhoc uploads. This article will outline some starting points for a common scenario:
the need to upload data stored in files on a regular, automated basis. While the pipeline presented here will not be
the most performant or otherwise optimized, it is intended to serve as a starting point towards building a
production pipeline of your own.
NOTE
Example problem
For the remainder of this article, we will examine page view data in Application Insights. In our hypothetical
scenario, we want to correlate geographical information collected by default by the Application Insights SDK to
custom data containing the population of every country/region in the world, with the goal of identifying where we
should be spending the most marketing dollars.
We use a public data source such as the UN World Population Prospects for this purpose. The data will have the
following simple schema:
In our example, we assume that we will upload a new file with the latest year’s data as soon as it becomes
available.
General design
We are using a classic ETL -type logic to design our pipeline. The architecture will look as follows:
This article will not cover how to create data or upload it to an Azure Blob Storage account. Rather, we pick the
flow up as soon as a new file is uploaded to the blob. From here:
1. A process will detect that new data has been uploaded. Our example uses an Azure Logic App, which has
available a trigger to detect new data being uploaded to a blob.
2. A processor reads this new data and converts it to JSON, the format required by Azure Monitor In this
example, we use an Azure Function as a lightweight, cost-efficient way of executing our processing code.
The function is kicked off by the same Logic App that we used to detect a the new data.
3. Finally, once the JSON object is available, it is sent to Azure Monitor. The same Logic App sends the data to
Azure Monitor using the built in Log Analytics Data Collector activity.
While the detailed setup of the blob storage, Logic App, or Azure Function is not outlined in this article, detailed
instructions are available on the specific products’ pages.
To monitor this pipeline, we use Application Insights to monitor our Azure Function details here, and Azure
Monitor to monitor our Logic App details here.
Setting up the pipeline

To set the pipeline, first make sure you have your blob container created and configured. Likewise, make sure that
the Log Analytics workspace where you’d like to send the data to is created.
Ingesting JSON data

Ingesting JSON data is trivial with Logic Apps, and since no transformation needs to take place, we can encase the
entire pipeline in a single Logic App. Once both the blob container and the Log Analytics workspace have been
configured, create a new Logic App and configure it as follows:
Save your Logic App and proceed to test it.
Ingesting XML, CSV, or other formats of data

Logic Apps today does not have built-in capabilities to easily transform XML, CSV, or other types into JSON
format. Therefore, we need to use another means to complete this transformation. For this article, we use the
serverless compute capabilities of Azure Functions as a very lightweight and cost-friendly way of doing so.
In this example, we parse a CSV file, but any other file type can be similarly processed. Simply modify the
deserializing portion of the Azure Function to reflect the correct logic for your specific data type.
1. Create a new Azure Function, using the Function runtime v1 and consumption-based when prompted.
Select the HTTP trigger template targeted at C# as a starting point that configures your bindings as we
require.
2. From the View Files tab on the right pane, create a new file called project.json and paste the following
code from NuGet packages that we are using:
{
"frameworks": {
"net46":{
"dependencies": {
"CsvHelper": "7.1.1",
"Newtonsoft.Json": "11.0.2"
}
}
}
}
3. Switch to run.csx from the right pane, and replace the default code with the following.
NOTE
For your project, you have to replace the record model (the “PopulationRecord” class) with your own data schema.
using System.Net;
using Newtonsoft.Json;
using CsvHelper;
class PopulationRecord
{
public String Location { get; set; }
public int Time { get; set; }
public long Population { get; set; }
}
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)

{
string filePath = await req.Content.ReadAsStringAsync(); //get the CSV URI being passed from Logic
App
string response = "";
//get a stream from blob

WebClient wc = new WebClient();
Stream s = wc.OpenRead(filePath);
//read the stream

using (var sr = new StreamReader(s))
{
var csvReader = new CsvReader(sr);
var records = csvReader.GetRecords<PopulationRecord>(); //deserialize the CSV stream as an

IEnumerable
response = JsonConvert.SerializeObject(records); //serialize the IEnumerable back into JSON

}
return response == null

? req.CreateResponse(HttpStatusCode.BadRequest, "There was an issue getting data")
: req.CreateResponse(HttpStatusCode.OK, response);
}
4. Save your function.

5. Test the function to make sure the code is working correctly. Switch to the Test tab in the right pane,
configuring the test as follows. Place a link to a blob with sample data into the Request body textbox. After
clicking Run, you should see JSON output in the Output box:
Now we need to go back and modify the Logic App we started building earlier to include the data ingested and
converted to JSON format. Using View Designer, configure as follows and then save your Logic App:
Testing the pipeline
Now you can upload a new file to the blob configured earlier and have it monitored by your Logic App. Soon, you
should see a new instance of the Logic App kick off, call out to your Azure Function, and then successfully send the
data to Azure Monitor.
NOTE
It can take up to 30 minutes for the data to appear in Azure Monitor the first time you send a new data type.
Correlating with other data in Log Analytics and Application Insights

To complete our goal of correlating Application Insights page view data with the population data we ingested from
our custom data source, run the following query from either your Application Insights Analytics window or Log
Analytics workspace:
app("fabrikamprod").pageViews
| summarize numUsers = count() by client_CountryOrRegion
| join kind=leftouter (
workspace("customdatademo").Population_CL
) on $left.client_CountryOrRegion == $right.Location_s
| project client_CountryOrRegion, numUsers, Population_d
The output should show the two data sources now joined.
Suggested improvements for a production pipeline

This article presented a working prototype, the logic behind which can be applied towards a true production-
quality solution. For such a production-quality solution, the following improvements are recommended:
Add error handling and retry logic in your Logic App and Function.
Add logic to ensure that the 30MB/single Log Analytics Ingestion API call limit is not exceeded. Split the data
into smaller segments if needed.
Set up a clean-up policy on your blob storage. Once successfully sent to the Log Analytics workspace, unless
you’d like to keep the raw data available for archival purposes, there is no reason to continue storing it.
Verify monitoring is enabled across the full pipeline, adding trace points and alerts as appropriate.
Leverage source control to manage the code for your function and Logic App.
Ensure that a proper change management policy is followed, such that if the schema changes, the function and
Logic Apps are modified accordingly.
If you are uploading multiple different data types, segregate them into individual folders within your blob
container, and create logic to fan the logic out based on the data type.
Next steps
Learn more about the Data Collector API to write data to Log Analytics workspace from any REST API client.
Connect Operations Manager to Azure Monitor
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in
a Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the
To maintain your existing investment in System Center Operations Manager and use extended capabilities
with Azure Monitor, you can integrate Operations Manager with your Log Analytics workspace. This allows
you to leverage the opportunities of logs in Azure Monitor while continuing to use Operations Manager to:
Monitor the health of your IT services with Operations Manager
Maintain integration with your ITSM solutions supporting incident and problem management
Manage the lifecycle of agents deployed to on-premises and public cloud IaaS virtual machines that you
monitor with Operations Manager
Integrating with System Center Operations Manager adds value to your service operations strategy by using
the speed and efficiency of Azure Monitor in collecting, storing, and analyzing log data from Operations
Manager. Azure Monitor log queries help correlate and work towards identifying the faults of problems and
surfacing recurrences in support of your existing problem management process. The flexibility of the query
engine to examine performance, event and alert data, with rich dashboards and reporting capabilities to
expose this data in meaningful ways, demonstrates the strength Azure Monitor brings in complimenting
Operations Manager.
The agents reporting to the Operations Manager management group collect data from your servers based
on the Log Analytics data sources and solutions you have enabled in your workspace. Depending on the
solutions enabled, their data are either sent directly from an Operations Manager management server to the
service, or because of the volume of data collected on the agent-managed system, are sent directly from the
agent to a Log Analytics workspace. The management server forwards the data directly to the service; it is
never written to the operational or data warehouse database. When a management server loses connectivity
with Azure Monitor, it caches the data locally until communication is re-established. If the management
server is offline due to planned maintenance or unplanned outage, another management server in the
management group resumes connectivity with Azure Monitor.
The following diagram shows the connection between the management servers and agents in a System
Center Operations Manager management group and Azure Monitor, including the direction and ports.
If your IT security policies do not allow computers on your network to connect to the Internet, management
servers can be configured to connect to the Log Analytics gateway to receive configuration information and
send collected data depending on the solutions enabled. For more information and steps on how to
configure your Operations Manager management group to communicate through a Log Analytics gateway
to Azure Monitor, see Connect computers to Azure Monitor using the Log Analytics gateway.
Prerequisites
Before starting, review the following requirements.
Azure Monitor only supports System Center Operations Manager 2016 or later, Operations Manager
2012 SP1 UR6 or later, and Operations Manager 2012 R2 UR2 or later. Proxy support was added in
Operations Manager 2012 SP1 UR7 and Operations Manager 2012 R2 UR3.
Integrating System Center Operations Manager 2016 with US Government cloud requires an
updated Advisor management pack included with Update Rollup 2 or later. System Center Operations
Manager 2012 R2 requires an updated Advisor management pack included with Update Rollup 3 or
later.
All Operations Manager agents must meet minimum support requirements. Ensure that agents are at
the minimum update, otherwise Windows agent communication may fail and generate errors in the
Operations Manager event log.
A Log Analytics workspace. For further information, review Log Analytics workspace overview.
You authenticate to Azure with an account that is a member of the Log Analytics Contributor role.
Supported Regions - Only the following Azure regions are supported by System Center Operations
Manager to connect to a Log Analytics workspace:
West Central US
Australia South East
West Europe
East US
South East Asia
Japan East
UK South
Central India
Canada Central
West US 2
NOTE
Recent changes to Azure APIs will prevent customers from being able to successfully configure integration between
their management group and Azure Monitor for the first time. For customers who have already integrated their
management group with the service, you are not impacted unless you need to reconfigure your existing connection.
A new management pack has been released for the following versions of Operations Manager:
For System Center Operations Manager 2019, management pack is provided with the Operations Manager build.
Operations Manager 1801 management pack is also applicable for Operations Manager 1807.
For System Center Operations Manager 1801, download the management pack from here.
For System Center 2016 - Operations Manager, download the management pack from here.
For System Center Operations Manager 2012 R2, download the management pack from here.
Network
The information below list the proxy and firewall configuration information required for the Operations
Manager agent, management servers, and Operations console to communicate with Azure Monitor. Traffic
from each component is outbound from your network to Azure Monitor.
RESOURCE PORT NUMBER BYPASS HTTP INSPECTION
Agent
*.ods.opinsights.azure.com 443 Yes
*.oms.opinsights.azure.com 443 Yes
*.blob.core.windows.net 443 Yes
*.azure-automation.net 443 Yes
Management server
*.service.opinsights.azure.com 443
*.blob.core.windows.net 443 Yes
*.ods.opinsights.azure.com 443 Yes
*.azure-automation.net 443 Yes
Operations Manager console to

Azure Monitor
service.systemcenteradvisor.com 443
*.service.opinsights.azure.com 443
RESOURCE PORT NUMBER BYPASS HTTP INSPECTION
*.live.com 80 and 443
*.microsoft.com 80 and 443
*.microsoftonline.com 80 and 443
*.mms.microsoft.com 80 and 443
login.windows.net 80 and 443
portal.loganalytics.io 80 and 443
api.loganalytics.io 80 and 443
docs.loganalytics.io 80 and 443
TLS 1.2 protocol

To insure the security of data in transit to Azure Monitor, we strongly encourage you to configure the agent
and management group to use at least Transport Layer Security (TLS ) 1.2. Older versions of TLS/Secure
Sockets Layer (SSL ) have been found to be vulnerable and while they still currently work to allow backwards
compatibility, they are not recommended. For additional information, review Sending data securely using
TLS 1.2.
Connecting Operations Manager to Azure Monitor

Perform the following series of steps to configure your Operations Manager management group to connect
to one of your Log Analytics workspaces.
During initial registration of your Operations Manager management group with a Log Analytics workspace,
the option to specify the proxy configuration for the management group is not available in the Operations
console. The management group has to be successfully registered with the service before this option is
available. To work around this, you need to update the system proxy configuration using Netsh on the system
your running the Operations console from to configure integration, and all management servers in the
management group.
1. Open an elevated command-prompt. a. Go to Start and type cmd. b. Right-click Command prompt
and select Run as administrator**.
2. Enter the following command and press Enter:
netsh winhttp set proxy <proxy>:<port>
After completing the following steps to integrate with Azure Monitor, you can remove the configuration by
running netsh winhttp reset proxy and then use the Configure proxy server option in the Operations
console to specify the proxy or Log Analytics gateway server.
1. In the Operations Manager console, select the Administration workspace.
2. Expand the Operations Management Suite node and click Connection.
3. Click the Register to Operations Management Suite link.
4. On the Operations Management Suite Onboarding Wizard: Authentication page, enter the
email address or phone number and password of the administrator account that is associated with
your OMS subscription, and click Sign in.
NOTE
The Operations Management Suite name has been retired.
5. After you are successfully authenticated, on the Operations Management Suite Onboarding
Wizard: Select Workspace page, you are prompted to select your Azure tenant, subscription, and
Log Analytics workspace. If you have more than one workspace, select the workspace you want to
register with the Operations Manager management group from the drop-down list, and then click
Next.
NOTE
Operations Manager only supports one Log Analytics workspace at a time. The connection and the computers
that were registered to Azure Monitor with the previous workspace are removed from Azure Monitor.
6. On the Operations Management Suite Onboarding Wizard: Summary page, confirm your
settings and if they are correct, click Create.
7. On the Operations Management Suite Onboarding Wizard: Finish page, click Close.
Add agent-managed computers
After configuring integration with your Log Analytics workspace, it only establishes a connection with the
service, no data is collected from the agents reporting to your management group. This won’t happen until
after you configure which specific agent-managed computers collect log data for Azure Monitor. You can
either select the computer objects individually or you can select a group that contains Windows computer
objects. You cannot select a group that contains instances of another class, such as logical disks or SQL
databases.
1. Open the Operations Manager console and select the Administration workspace.
2. Expand the Operations Management Suite node and click Connection.
3. Click the Add a Computer/Group link under the Actions heading on the right-side of the pane.
4. In the Computer Search dialog box, you can search for computers or groups monitored by Operations
Manager. Select computers or groups including the Operations Manager Management Server to onboard
to Azure Monitor, click Add, and then click OK.
You can view computers and groups configured to collect data from the Managed Computers node under
Operations Management Suite in the Administration workspace of the Operations console. From here, you
can add or remove computers and groups as necessary.
Configure proxy settings in the Operations console
Perform the following steps if an internal proxy server is between the management group and Azure
Monitor. These settings are centrally managed from the management group and distributed to agent-
managed systems that are included in the scope to collect log data for Azure Monitor. This is beneficial for
when certain solutions bypass the management server and send data directly to the service.
2. Expand Operations Management Suite, and then click Connections.
3. In the OMS Connection view, click Configure Proxy Server.
4. On Operations Management Suite Wizard: Proxy Server page, select Use a proxy server to access
the Operations Management Suite, and then type the URL with the port number, for example,
http://corpproxy:80 and then click Finish.
If your proxy server requires authentication, perform the following steps to configure credentials and settings
that need to propagate to managed computers that reports to Azure Monitor in the management group.
2. Under RunAs Configuration, select Profiles.
3. Open the System Center Advisor Run As Profile Proxy profile.
4. In the Run As Profile Wizard, click Add to use a Run As account. You can create a Run As account or use
an existing account. This account needs to have sufficient permissions to pass through the proxy server.
5. To set the account to manage, choose A selected class, group, or object, click Select… and then click
Group… to open the Group Search box.
6. Search for and then select Microsoft System Center Advisor Monitoring Server Group. Click OK
after selecting the group to close the Group Search box.
7. Click OK to close the Add a Run As account box.
8. Click Save to complete the wizard and save your changes.
After the connection is created and you configure which agents will collect and report log data to Azure
Monitor, the following configuration is applied in the management group, not necessarily in order:
The Run As Account Microsoft.SystemCenter.Advisor.RunAsAccount.Certificate is created. It is
associated with the Run As profile Microsoft System Center Advisor Run As Profile Blob and is
targeting two classes - Collection Server and Operations Manager Management Group.
Two connectors are created. The first is named Microsoft.SystemCenter.Advisor.DataConnector and
is automatically configured with a subscription that forwards all alerts generated from instances of all
classes in the management group to Azure Monitor. The second connector is Advisor Connector, which
is responsible for communicating with Azure Monitor and sharing data.
Agents and groups that you have selected to collect data in the management group is added to the
Microsoft System Center Advisor Monitoring Server Group.
Management pack updates

After configuration is completed, the Operations Manager management group establishes a connection with
Azure Monitor. The management server synchronizes with the web service and receive updated
configuration information in the form of management packs for the solutions you have enabled that
integrate with Operations Manager. Operations Manager checks for updates of these management packs
and automatically download and imports them when they’re available. There are two rules in particular
which control this behavior:
Microsoft.SystemCenter.Advisor.MPUpdate - Updates the base Azure Monitor management packs.
Runs every 12 hours by default.
Microsoft.SystemCenter.Advisor.Core.GetIntelligencePacksRule - Updates solution management
packs enabled in your workspace. Runs every five (5) minutes by default.
You can override these two rules to either prevent automatic download by disabling them, or modify the
frequency for how often the management server synchronizes with Azure Monitor to determine if a new
management pack is available and should be downloaded. Follow the steps How to Override a Rule or
Monitor to modify the Frequency parameter with a value in seconds to change the synchronization
schedule, or modify the Enabled parameter to disable the rules. Target the overrides to all objects of class
Operations Manager Management Group.
To continue following your existing change control process for controlling management pack releases in your
production management group, you can disable the rules and enable them during specific times when
updates are allowed. If you have a development or QA management group in your environment and it has
connectivity to the Internet, you can configure that management group with a Log Analytics workspace to
support this scenario. This allows you to review and evaluate the iterative releases of the Azure Monitor
management packs before releasing them into your production management group.
Switch an Operations Manager group to a new Log Analytics

Workspace
2. In the Azure portal, click More services found on the lower left-hand corner. In the list of resources,
type Log Analytics. As you begin typing, the list filters based on your input. Select Log Analytics
and then create a workspace.
3. Open the Operations Manager console with an account that is a member of the Operations Manager
Administrators role and select the Administration workspace.
4. Expand Log Analytics, and select Connections.
5. Select the Re-configure Operation Management Suite link on the middle-side of the pane.
6. Follow the Log Analytics Onboarding Wizard and enter the email address or phone number and
password of the administrator account that is associated with your new Log Analytics workspace.
NOTE
The Operations Management Suite Onboarding Wizard: Select Workspace page presents the existing
workspace that is in use.
Validate Operations Manager Integration with Azure Monitor

There are a few different ways you can verify that Azure Monitor to Operations Manager integration is
successful.
To confirm integration from the Azure portal
1. In the Azure portal, click More services found on the lower left-hand corner. In the list of resources,
type Log Analytics. As you begin typing, the list filters based on your input.
2. In your list of Log Analytics workspaces, select the applicable workspace.
3. Select Advanced settings, select Connected Sources, and then select System Center.
4. In the table under the System Center Operations Manager section, you should see the name of the
management group listed with the number of agents and status when data was last received.
To confirm integration from the Operations console
2. Select Management Packs and in the Look for: text box type Advisor or Intelligence.
3. Depending on the solutions you have enabled, you see a corresponding management pack listed in
the search results. For example, if you have enabled the Alert Management solution, the management
pack Microsoft System Center Advisor Alert Management is in the list.
4. From the Monitoring view, navigate to the Operations Management Suite\Health State view.
Select a Management server under the Management Server State pane, and in the Detail View
pane confirm the value for property Authentication service URI matches the Log Analytics
Workspace ID.
Remove Integration with Azure Monitor

When you no longer require integration between your Operations Manager management group and the Log
Analytics workspace, there are several steps required to properly remove the connection and configuration in
the management group. The following procedure has you update your Log Analytics workspace by deleting
the reference of your management group, delete the Azure Monitor connectors, and then delete
management packs supporting integration with the service.
Management packs for the solutions you have enabled that integrate with Operations Manager and the
management packs required to support integration with Azure Monitor cannot be easily deleted from the
management group. This is because some of the Azure Monitor management packs have dependencies on
other related management packs. To delete management packs having a dependency on other management
packs, download the script remove a management pack with dependencies from TechNet Script Center.
1. Open the Operations Manager Command Shell with an account that is a member of the Operations
Manager Administrators role.
WARNING
Verify you do not have any custom management packs with the word Advisor or IntelligencePack in the name
before proceeding, otherwise the following steps delete them from the management group.
2. From the command shell prompt, type

Get-SCOMManagementPack -name "*Advisor*" | Remove-SCOMManagementPack -ErrorAction SilentlyContinue
3. Next type,
Get-SCOMManagementPack -name “*IntelligencePack*” | Remove-SCOMManagementPack -ErrorAction
SilentlyContinue
4. To remove any management packs remaining which have a dependency on other System Center
Advisor management packs, use the script RecursiveRemove.ps1 you downloaded from the TechNet
Script Center earlier.
NOTE
The step to remove the Advisor management packs with PowerShell will not automatically delete the Microsoft
System Center Advisor or Microsoft System Center Advisor Internal management packs. Do not attempt to
delete them.
5. Open the Operations Manager Operations console with an account that is a member of the
Operations Manager Administrators role.
6. Under Administration, select the Management Packs node and in the Look for: box, type Advisor
and verify the following management packs are still imported in your management group:
Microsoft System Center Advisor
Microsoft System Center Advisor Internal
7. In the Azure portal, click the Settings tile.
8. Select Connected Sources.
9. In the table under the System Center Operations Manager section, you should see the name of the
management group you want to remove from the workspace. Under the column Last Data, click
Remove.
NOTE
The Remove link will not be available until after 14 days if there is no activity detected from the connected
management group.
10. A window will appear asking you to confirm that you want to proceed with the removal. Click Yes to
proceed.
To delete the two connectors - Microsoft.SystemCenter.Advisor.DataConnector and Advisor Connector, save
the PowerShell script below to your computer and execute using the following examples:
.\OM2012_DeleteConnectors.ps1 “Advisor Connector” <ManagementServerName>

.\OM2012_DeleteConnectors.ps1 “Microsoft.SystemCenter.Advisor.DataConnector” <ManagementServerName>
NOTE
The computer you run this script from, if not a management server, should have the Operations Manager command
shell installed depending on the version of your management group.
param(
[String] $connectorName,
[String] $msName="localhost"
)
$mg = new-object Microsoft.EnterpriseManagement.ManagementGroup $msName
$admin = $mg.GetConnectorFrameworkAdministration()
##########################################################################################
# Configures a connector with the specified name.
##########################################################################################
function New-Connector([String] $name)
{
$connectorForTest = $null;
foreach($connector in $admin.GetMonitoringConnectors())
{
if($connectorName.Name -eq ${name})
{
$connectorForTest = Get-SCOMConnector -id $connector.id
}
}
if ($connectorForTest -eq $null)
{
$testConnector = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.ConnectorInfo
$testConnector.Name = $name
$testConnector.Description = "${name} Description"
$testConnector.DiscoveryDataIsManaged = $false
$connectorForTest = $admin.Setup($testConnector)
$connectorForTest.Initialize();
}
return $connectorForTest
}
##########################################################################################
# Removes a connector with the specified name.
##########################################################################################
function Remove-Connector([String] $name)
{
$testConnector = $null
foreach($connector in $admin.GetMonitoringConnectors())
{
if($connector.Name -eq ${name})
{
$testConnector = Get-SCOMConnector -id $connector.id
}
}
if ($testConnector -ne $null)
{
if($testConnector.Initialized)
{
foreach($alert in $testConnector.GetMonitoringAlerts())
{
$alert.ConnectorId = $null;
$alert.Update("Delete Connector");
}
$testConnector.Uninitialize()
}
$connectorIdForTest = $admin.Cleanup($testConnector)
}
}
##########################################################################################
# Delete a connector's Subscription
##########################################################################################
function Delete-Subscription([String] $name)
function Delete-Subscription([String] $name)
{
foreach($testconnector in $admin.GetMonitoringConnectors())
{
if($testconnector.Name -eq $name)
{
$connector = Get-SCOMConnector -id $testconnector.id
}
}
$subs = $admin.GetConnectorSubscriptions()
foreach($sub in $subs)
{
if($sub.MonitoringConnectorId -eq $connector.id)
{
$admin.DeleteConnectorSubscription($admin.GetConnectorSubscription($sub.Id))
}
}
}
#New-Connector $connectorName
write-host "Delete-Subscription"
Delete-Subscription $connectorName
write-host "Remove-Connector"
Remove-Connector $connectorName
In the future if you plan on reconnecting your management group to a Log Analytics workspace, you need to
re-import the Microsoft.SystemCenter.Advisor.Resources.\<Language>\.mpb management pack file. Depending
on the version of System Center Operations Manager deployed in your environment, you can find this file in
the following location:
On the source media under the \ManagementPacks folder for System Center 2016 - Operations Manager
and higher.
From the most recent update rollup applied to your management group. For Operations Manager 2012,
the source folder is
%ProgramFiles%\Microsoft System Center 2012\Operations Manager\Server\Management Packs for Update
Rollups
and for 2012 R2, it is located in
System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups .
Next steps
To add functionality and gather data, see Add Azure Monitor solutions from the Solutions Gallery.
Optimize your environment with the System Center
Operations Manager Health Check (Preview) solution
You can use the System Center Operations Manager Health Check solution to assess the risk and health of your
System Center Operations Manager management group on a regular interval. This article helps you install,
configure, and use the solution so that you can take corrective actions for potential problems.
recommendations are categorized across four focus areas, which help you quickly understand the risk and take
corrective action.
The recommendations made are based on the knowledge and experience gained by Microsoft engineers from
thousands of customer visits. Each recommendation provides guidance about why an issue might matter to you
and how to implement the suggested changes.
After you've added the solution and an assessment is performed, summary information for focus areas is shown
on the System Center Operations Manager Health Check dashboard for your infrastructure. The following
sections describe how to use the information on the System Center Operations Manager Health Check
dashboard, where you can view and then take recommended actions for your Operations Manager environment.
The solution works with Microsoft System Center 2012 Operations Manager Service Pack 1, Microsoft System
Center 2012 R2 Operations Manager, Microsoft System Center 2016 Operations Manager, Microsoft System
Center 2016 Operations Manager and Microsoft System Center Operations Manager 1807
Before you can use the Health Check solution in Log Analytics, you must have the solution installed. Install
the solution from Azure marketplace.
After adding the solution to the workspace, the System Center Operations Manager Health Check tile
on the dashboard displays an additional configuration required message. Click on the tile and follow the
configuration steps mentioned in the page
NOTE
Configuration of System Center Operations Manager can be done using a script by following the steps mentioned in the
configuration page of the solution in Log Analytics.
To configure the assessment through Operations Manager Operations console, perform the steps below in the
following order:
1. Set the Run As account for System Center Operations Manager Health Check
2. Configure the System Center Operations Manager Health Check rule
System Center Operations Manager Health Check data collection

details
The System Center Operations Manager Health Check solution collects data from the following sources:
Registry
Event log
File data
Directly from Operations Manager using PowerShell and SQL queries, from a management server that you
have specified.
Data is collected on the management server and forwarded to Log Analytics every seven days.
Operations Manager run-as accounts for Log Analytics

Log Analytics builds on management packs for workloads to provide value-add services. Each workload requires
workload-specific privileges to run management packs in a different security context, such as a domain user
account. Configure an Operations Manager Run As account with privileged credentials. For additional information,
see How to create a Run As account in the Operations Manager documentation.
Use the following information to set the Operations Manager Run As account for System Center Operations
Manager Health Check.
Set the Run As account
The Run As account must meet following requirements before proceeding:
A domain user account that is a member of the local Administrators group on all servers supporting any
Operations Manager role - Management server, SQL Server hosting the operational, data warehouse and ACS
database, Reporting, Web console, and Gateway server.
Operation Manager Administrator Role for the management group being assessed
If the account does not have SQL sysadmin rights, then execute the script to grant granular permissions to the
account on each SQL Server instance hosting one or all of the Operations Manager databases.
1. In the Operations Manager Console, select the Administration navigation button.
2. Under Run As Configuration, click Accounts.
3. In the Create Run As Account Wizard, on the Introduction page click Next.
4. On the General Properties page, select Windows in the Run As Account type: list.
5. Type a display name in the Display Name text box and optionally type a description in the Description box,
and then click Next.
6. On the Distribution Security page, select More secure.
7. Click Create.
Now that the Run As account is created, it needs to target management servers in the management group and
associated with a pre-defined Run As profile so workflows will run using the credentials.
1. Under Run As Configuration, Accounts, in the results pane, double-click the account you created earlier.
2. On the Distribution tab, click Add for the Selected computers box and add the management server to
distribute the account to. Click OK twice to save your changes.
3. Under Run As Configuration, click Profiles.
4. Search for the SCOM Assessment Profile.
5. The profile name should be: Microsoft System Center Operations Manager Health Check Run As Profile.
6. Right-click and update its properties and add the recently created Run As Account you created earlier.
SQL script to grant granular permissions to the Run As account
Execute the following SQL script to grant required permissions to the Run As account on the SQL Server instance
used by Operations Manager hosting the operational, data warehouse, and ACS database.
-- Replace <UserName> with the actual user name being used as Run As Account.
USE master
-- Create login for the user, comment this line if login is already created.
CREATE LOGIN [UserName] FROM WINDOWS
--GRANT permissions to user.

GRANT VIEW SERVER STATE TO [UserName]
GRANT VIEW ANY DEFINITION TO [UserName]
GRANT VIEW ANY DATABASE TO [UserName]
-- Add database user for all the databases on SQL Server Instance, this is required for connecting to
individual databases.
-- NOTE: This command must be run anytime new databases are added to SQL Server instances.
EXEC sp_msforeachdb N'USE [?]; CREATE USER [UserName] FOR LOGIN [UserName];'
Use msdb
GRANT SELECT To [UserName]
Go
--Give SELECT permission on all Operations Manager related Databases
--Replace the Operations Manager database name with the one in your environment
Use [OperationsManager];
GO
--Replace the Operations Manager DatawareHouse database name with the one in your environment
Use [OperationsManagerDW];
GO
--Replace the Operations Manager Audit Collection database name with the one in your environment
Use [OperationsManagerAC];
GO
--Give db_owner on [OperationsManager] DB

--Replace the Operations Manager database name with the one in your environment
USE [OperationsManager]
GO
ALTER ROLE [db_owner] ADD MEMBER [UserName]
Configure the health check rule

The System Center Operations Manager Health Check solution’s management pack includes a rule named
Microsoft System Center Operations Manager Run Health Check Rule. This rule is responsible for running the
health check. To enable the rule and configure the frequency, use the procedures below.
By default, the Microsoft System Center Operations Manager Run Health Check Rule is disabled. To run the health
check, you must enable the rule on a management server. Use the following steps.
Enable the rule for a specific management server
1. In the Authoring workspace of the Operations Manager Operations console, search for the rule Microsoft
System Center Operations Manager Run Health Check Rule in the Rules pane.
2. In the search results, select the one that includes the text Type: Management Server.
3. Right-click the rule and then click Overrides > For a specific object of class: Management Server.
4. In the available management servers list, select the management server where the rule should run. This
should be the same management server you configured earlier to associate the Run As account with.
5. Ensure that you change override value to True for the Enabled parameter value.
While still in this window, configure the run frequency using the next procedure.
Configure the run frequency
The assessment is configured to run every 10,080 minutes (or seven days) by default. You can override the value to
a minimum value of 1440 minutes (or one day). The value represents the minimum time gap required between
successive assessment runs. To override the interval, use the steps below.
1. In the Authoring workspace of the Operations Manager console, search for the rule Microsoft System
Center Operations Manager Run Health Check Rule in the Rules section.
2. In the search results, select the one that includes the text Type: Management Server.
3. Right-click the rule and then click Override the Rule > For all objects of class: Management Server.
4. Change the Interval parameter value to your desired interval value. In the example below, the value is set
to 1440 minutes (one day).
If the value is set to less than 1440 minutes, then the rule runs on a one day interval. In this example, the
rule ignores the interval value and runs at a frequency of one day.

recommendation. Only the 10 most important recommendations are shown.
The probability that an issue identified will cause problems. A higher probability equates to a larger overall
score for the recommendation.
recommendation.
area. For example, if a recommendation in the Availability and Business Continuity focus area has a score of 5%,
implementing that recommendation increases your overall Availability and Business Continuity score by 5%.
Focus areas
Upgrade, Migration, and Deployment - This focus area shows recommendations to help you upgrade, migrate,
and deploy SQL Server to your existing infrastructure.
Operations and Monitoring - This focus area shows recommendations to help streamline your IT operations,
implement preventative maintenance, and maximize performance.
Every recommendation includes guidance about why it is important. Use this guidance to evaluate whether
implementing the recommendation is appropriate for you, given the nature of your IT services and the business
needs of your organization.
Use health check focus area recommendations

Before you can use a health check solution in Log Analytics, you must have the solution installed. To read more
about installing solutions, see Install a management solution. After it is installed, you can view the summary of
recommendations by using the System Center Operations Manager Health Check tile on the Overview page for
your workspace in the Azure portal.
1. Log in to the Azure portal at https://portal.azure.com.
2. In the Azure portal, click More services found on the lower left-hand corner. In the list of resources, type Log
3. In the Log Analytics subscriptions pane, select a workspace and then click the Workspace summary menu
item.
4. On the Overview page, click the System Center Operations Manager Health Check tile.
5. On the System Center Operations Manager Health Check page, review the summary information in one of
the focus area blades and then click one to view recommendations for that focus area.
assessments will record that recommended actions were taken and your compliance score will increase.
If you have recommendations that you want to ignore, you can create a text file that Log Analytics uses to prevent
recommendations from appearing in your assessment results.
To identify recommendations that you want to ignore
1. In the Azure portal on the Log Analytics workspace page for your selected workspace, click the Log Search
menu item.
2. Use the following query to list recommendations that have failed for computers in your environment.
Type=SCOMAssessmentRecommendationRecommendationResult=Failed | select Computer, RecommendationId,

Recommendation | sort Computer
NOTE
If your workspace has been upgraded to the new Log Analytics query language, then the above query would change
to the following.
SCOMAssessmentRecommendationRecommendation | where RecommendationResult == "Failed" | sort by
Computer asc | project Computer, RecommendationId, Recommendation
Here's a screenshot showing the Log Search query:
3. Choose recommendations that you want to ignore. You'll use the values for RecommendationId in the next
procedure.
2. Paste or type each RecommendationId for each recommendation that you want Log Analytics to ignore on a
separate line and then save and close the file.
3. Put the file in the following folder on each computer where you want Log Analytics to ignore
recommendations.
4. On the Operations Manager management server - SystemDrive:\Program Files\Microsoft System Center 2012
R2\Operations Manager\Server.
1. After the next scheduled assessment runs, by default every seven days, the specified recommendations are
marked Ignored and will not appear on the health check dashboard.
2. You can use the following Log Search queries to list all the ignored recommendations.
Type=SCOMAssessmentRecommendationRecommendationResult=Ignored | select Computer, RecommendationId,
Recommendation | sort Computer
NOTE
If your workspace has been upgraded to the new Log Analytics query language, then the above query would change
to the following.
SCOMAssessmentRecommendationRecommendation | where RecommendationResult == "Ignore" | sort by
Computer asc | project Computer, RecommendationId, Recommendation
System Center Operations Manager Health Check solution FAQ

I added the Health Check solution to my Log Analytics workspace. But I don’t see the recommendations. Why not?
After adding the solution, use the following steps view the recommendations on the Log Analytics dashboard.
Set the Run As account for System Center Operations Manager Health Check
Configure the System Center Operations Manager Health Check rule
Is there a way to configure how often the check runs? Yes. See Configure the run frequency.
If another server is discovered after I’ve added the System Center Operations Manager Health Check solution, will
it be checked? Yes, after discovery it is checked from then on, by default every seven days.
What is the name of the process that does the data collection? AdvisorAssessment.exe
Where does the AdvisorAssessment.exe process run? AdvisorAssessment.exe runs under the HealthService process
of the management server where the health check rule is enabled. Using that process, discovery of your entire
environment is achieved through remote data collection.
How long does it take for data collection? Data collection on the server takes about one hour. It may take longer in
environments that have many Operations Manager instances or databases.
What if I set the interval of the assessment to less than 1440 minutes? The assessment is pre-configured to run at a
maximum of once per day. If you override the interval value to a value less than 1440 minutes, then the
assessment uses 1440 minutes as the interval value.
How to know if there are prerequisite failures? If the health check ran and you don't see results, then it is likely that
some of the prerequisites for the check failed. You can execute queries: Operation Solution=SCOMAssessment and
SCOMAssessmentRecommendation FocusArea=Prerequisites in Log Search to see the failed prerequisites.
There is a Failed to connect to the SQL Instance (….). message in prerequisite failures. What is the issue?
AdvisorAssessment.exe, the process that collects data, runs under the HealthService process on the management
server. As part of the health check, the process attempts to connect to the SQL Server where the Operations
Manager database is present. This error can occur when firewall rules block the connection to the SQL Server
instance.
What type of data is collected? The following types of data are collected: - WMI data - Registry data - EventLog
data - Operations Manager data through Windows PowerShell, SQL Queries and File information collector.
Why do I have to configure a Run As Account? With Operations Manager, various SQL queries are run. In order
for them to run, you must use a Run As Account with necessary permissions. In addition, local administrator
credentials are required to query WMI.
Why display only the top 10 recommendations? Instead of giving you an exhaustive, overwhelming list of tasks,
we recommend that you focus on addressing the prioritized recommendations first. After you address them,
additional recommendations will become available. If you prefer to see the detailed list, you can view all
recommendations using Log Search.
Is there a way to ignore a recommendation? Yes, see the Ignore recommendations.
Next steps
Search logs to learn how to analyze detailed System Center Operations Manager Health Check data and
recommendations.
Connect Configuration Manager to Azure Monitor
You can connect your System Center Configuration Manager environment to Azure Monitor to sync device
collection data and reference these collections in Azure Monitor and Azure Automation.
Prerequisites
Azure Monitor supports System Center Configuration Manager current branch, version 1606 and higher.
NOTE
The feature to connect Configuration Manager with a Log Analytics workspace is optional and not enabled by default. You
must enable this feature before using it. For more information, see Enable optional features from updates.
Configuration overview
The following steps summarize the steps to configure Configuration Manager integration with Azure Monitor.
1. In Azure Active Directory, register Configuration Manager as a Web Application and/or Web API app, and
ensure that you have the client ID and client secret key from the registration from Azure Active Directory.
See Use portal to create Active Directory application and service principal that can access resources for
detailed information about how to accomplish this step.
2. In Azure Active Directory, grant Configuration Manager (the registered web app) with permission to access
Azure Monitor.
3. In Configuration Manager, add a connection using the Azure Services wizard.
4. Download and install the Log Analytics agent for Windows on the computer running the Configuration
Manager service connection point site system role. The agent sends Configuration Manager data to the
Log Analytics workspace in Azure Monitor.
5. In Azure Monitor, import collections from Configuration Manager as computer groups.
6. In Azure Monitor, view data from Configuration Manager as computer groups.
Grant Configuration Manager with permissions to Log Analytics

In the following procedure, you grant the Contributor role in your Log Analytics workspace to the AD application
and service principal you created earlier for Configuration Manager. If you do not already have a workspace, see
Create a workspace in Azure Monitor before proceeding. This allows Configuration Manager to authenticate and
connect to your Log Analytics workspace.
NOTE
You must specify permissions in the Log Analytics workspace for Configuration Manager. Otherwise, you receive an error
message when you use the configuration wizard in Configuration Manager.
2. In your list of Log Analytics workspaces, select the workspace to modify.
3. From the left pane, select Access control (IAM ).
4. In the Access control (IAM ) page, click Add role assignment and the Add role assignment pane
appears.
5. In the Add role assignment pane, under the Role drop-down list select the Contributor role.
6. Under the Assign access to drop-down list, select the Configuration Manager application created in AD
earlier, and then click OK.
Download and install the agent

Review the article Connect Windows computers to Azure Monitor in Azure to understand the methods available
for installing the Log Analytics agent for Windows on the computer hosting the Configuration Manager service
connection point site system role.
Connect Configuration Manager to Log Analytics workspace

NOTE
In order to add a Log Analytics connection, your Configuration Manager environment must have a service connection point
configured for online mode.
NOTE
You must connect the top-tier site in your hierarchy to Azure Monitor. If you connect a standalone primary site to Azure
Monitor and then add a central administration site to your environment, you have to delete and recreate the connection
within the new hierarchy.
1. In the Administration workspace of Configuration Manager, select Clouds Services and then select
Azure Services.
2. Right-click Azure Services and then select Configure Azure Services. The Configure Azure Services
page appears.
3. On the General screen, confirm that you have done the following actions and that you have details for
each item, then select Next.
4. On the Azure Services page of the Azure Services Wizard:
a. Specify a Name for the object in Configuration Manager.
b. Specify an optional Description to help you identify the service.
c. Select the Azure service OMS Connector.
NOTE
OMS is now referred to as Log Analytics which is a feature of Azure Monitor.
5. Select Next to continue to the Azure app properties page of the Azure Services Wizard.
6. On the App page of the Azure Services Wizard, first select the Azure environment from the list and then
click Import.
7. On the Import Apps page, specify the following information:
a. Specify the Azure AD Tenant Name for the app.
b. Specify for Azure AD Tenant ID the Azure AD tenant. You can find this information on the Azure
Active Directory Properties page.
c. Specify for Application Name the application name.
d. Specify for Client ID, the Application ID of the created Azure AD app created earlier.
e. Specify for Secret key, the Client secret key of the created Azure AD app.
f. Specify for Secret Key Expiry, the expiration date of your key.
g. Specify for App ID URI, the App ID URI of the created Azure AD app created earlier.
h. Select Verify and to the right the results should show Successfully verified!.
8. On the Configuration page, review the information to verify the Azure subscriptions, Azure resource
group, and Operations Management Suite workspace fields are pre-populated indicating the Azure
AD application has sufficient permissions in the resource group. If the fields are empty, it indicates your
application does not have the rights required. Select the device collections to collect and forward to the
workspace and then select Add.
9. Review the options on the Confirm the settings page, and select Next to begin creating and configuring
the connection.
10. When configuration is finished, the Completion page appears. Select Close.
After you have linked Configuration Manager to Azure Monitor, you can add or remove collections, and view the
properties of the connection.
Update Log Analytics workspace connection properties

If a password or client secret key expires or is lost, you'll need to manually update the Log Analytics connection
properties.
1. In the Administration workspace of Configuration Manager, select Cloud Services and then select OMS
Connector to open the OMS Connection Properties page.
2. On this page, click the Azure Active Directory tab to view your Tenant, Client ID, Client secret key
expiration. Verify your Client secret key if it has expired.
Import collections
After you've added a Log Analytics connection to Configuration Manager and installed the agent on the computer
running the Configuration Manager service connection point site system role, the next step is to import
collections from Configuration Manager in Azure Monitor as computer groups.
After you have completed initial configuration to import device collections from your hierarchy, the collection
information is retrieved every 3 hours to keep the membership current. You can choose to disable this at any time.
Analytics. As you begin typing, the list filters based on your input. Select Log Analytics workspaces.
2. In your list of Log Analytics workspaces, select the workspace Configuration Manager is registered with.
4. Select Computer Groups and then select SCCM.
5. Select Import Configuration Manager collection memberships and then click Save.
View data from Configuration Manager
After you've added a Log Analytics connection to Configuration Manager and installed the agent on the computer
running the Configuration Manager service connection point site system role, data from the agent is sent to the
Log Analytics workspace in Azure Monitor. In Azure Monitor, your Configuration Manager collections appear as
computer groups. You can view the groups from the Configuration Manager page under Settings\Computer
Groups.
After the collections are imported, you can see how many computers with collection memberships have been
detected. You can also see the number of collections that have been imported.
When you click either one, log query editor opens displaying either all of the imported groups or all computers
that belong to each group. Using Log Search, you can perform further in-depth analysis the collection
membership data.
Next steps
Use Log Search to view detailed information about your Configuration Manager data.
Stream Azure resource logs to Azure Event Hubs
describes streaming resource logs to event hubs to send data to external systems such as third-party SIEMs and
other log analytics solutions.
What you can do with resource logs sent to an event hub

Stream resource logs in Azure to event hubs to provide the following functionality:
Stream logs to 3rd party logging and telemetry systems – Stream all of your resource logs to a single
event hub to pipe log data to a third-party SIEM or log analytics tool.
Build a custom telemetry and logging platform – The highly scalable publish-subscribe nature of
event hubs allows you to flexibly ingest resource logs into a custom teletry platform. See Designing and
Sizing a Global Scale Telemetry Platform on Azure Event Hubs for details.
View service health by streaming data to Power BI – Use Event Hubs, Stream Analytics, and Power BI
to transform your diagnostics data into near real-time insights on your Azure services. See Stream
Analytics and Power BI: A real-time analytics dashboard for streaming data for details on this solution.
The following SQL code is a sample Stream Analytics query that you can use to parse all the log data in to
a Power BI table:
SELECT
records.ArrayValue.[Properties you want to track]
INTO
[OutputSourceName – the Power BI source]
FROM
[InputSourceName] AS e
CROSS APPLY GetArrayElements(e.records) AS records
Prerequisites
You need to create an event hub if you don't already have one. If you previously streamed resource logs to this
Event Hubs namespace, then that event hub will be reused.
The shared access policy for the namespace defines the permissions that the streaming mechanism has.
Streaming to Event Hubs requires Manage, Send, and Listen permissions. You can create or modify shared
access policies in the Azure portal under the Configure tab for your Event Hubs namespace.
To update the diagnostic setting to include streaming, you must have the ListKey permission on that Event Hubs
authorization rule. The Event Hubs namespace does not have to be in the same subscription as the subscription
that's emitting logs, as long as the user who configures the setting has appropriate RBAC access to both
subscriptions and both subscriptions are in the same AAD tenant.

Resource logs are not collected by default. Send them to an event hub and other destinations by creating a
diagnostic setting for an Azure resource. See Create diagnostic setting to collect logs and metrics in Azure for
details.
Stream data from compute resources
The process in this article is for non-compute resources as described in Overview of Azure resource logs. Stream
resource logs from Azure compute resources using the Windows Azure Diagnostics agent. See Streaming Azure
Diagnostics data in the hot path by using Event Hubs for details.
Consuming log data from event hubs

When you consume resource logs from event hubs, it will be is JSON format with the elements in the following
table.
records An array of all log events in this payload.
time Time at which the event occurred.
category Log category for this event.
resourceId Resource ID of the resource that generated this event.
level Optional. Indicates the log event level.
properties Properties of the event. These will vary for each Azure service
as described in .
Following is sample output data from Event Hubs:

{
"records": [
{
"time": "2016-07-15T18:00:22.6235064Z",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"runId": "08587330013509921957",
},
"correlation": {
"actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
}
}
},
{
"time": "2016-07-15T18:01:15.7532989Z",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"runId": "08587330012106702630",
},
"correlation": {
"actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
}
}
}
]
}
Next steps
Stream Azure Active Directory logs with Azure Monitor.
Read more about Azure resource logs.
Get started with Event Hubs.
Getting started with Azure Metrics Explorer
Where do I start
Azure Monitor metrics explorer is a component of the Microsoft Azure portal that allows plotting charts,
visually correlating trends, and investigating spikes and dips in metrics' values. Use the metrics explorer to
investigate the health and utilization of your resources. Start in the following order:
1. Pick a resource and a metric and you see a basic chart. Then select a time range that is relevant for your
investigation.
2. Try applying dimension filters and splitting. The filters and splitting allow you to analyze which segments
of the metric contribute to the overall metric value and identify possible outliers.
3. Use advanced settings to customize the chart before pinning to dashboards. Configure alerts to receive
notifications when the metric value exceeds or drops below a threshold.
Create your first metric chart

To create a metric chart, from your resource, resource group, subscription, or Azure Monitor view, open the
Metrics tab and follow these steps:
1. Using the resource picker, select the resource for which you want to see metrics. (The resource is pre-
selected if you opened Metrics in the context of a specific resource).
2. For some resources, you must pick a namespace. The namespace is just a way to organize metrics so that
you can easily find them. For example, storage accounts have separate namespaces for storing Files,
Tables, Blobs, and Queues metrics. Many resource types only have one namespace.
3. Select a metric from a list of available metrics.
4. Optionally, you can change the metric aggregation. For example, you might want your chart to show
minimum, maximum, or average values of the metric.
NOTE
Use the Add metric button and repeat these steps if you want to see multiple metrics plotted in the same chart. For
multiple charts in one view, select the Add chart button on top.
Select a time range

By default, the chart shows the most recent 24 hours of metrics data. Use the time picker panel to change the
time range, zoom in, or zoom out on your chart.
NOTE
Use the time brush to investigate an interesting area of the chart (spike or a dip). Put the mouse pointer at the
beginning of the area, click and hold the left mouse button, drag to the other side of area and then release the button.
The chart will zoom in on that time range.
Apply dimension filters and splitting

Filtering and splitting are powerful diagnostic tools for the metrics that have dimensions. These features show
how various metric segments ("dimension values") impact the overall value of the metric, and allow you to
identify possible outliers.
Filtering lets you choose which dimension values are included in the chart. For example, you might want
to show successful requests when charting the server response time metric. You would need to apply the
filter on the success of request dimension.
Splitting controls whether the chart displays separate lines for each value of a dimension, or aggregates
the values into a single line. For example, you can see one line for an average response time across all
server instances, or see separate lines for each server. You would need to apply splitting on the server
instance dimension to see separate lines.
See examples of the charts that have filtering and splitting applied. The article shows the steps were used to
configure the charts.
Advanced chart settings

You can customize chart style, title, and modify advanced chart settings. When done with customization, pin it to
a dashboard to save your work. You can also configure metrics alerts. Follow product documentation to learn
about these and other advanced features of Azure Monitor metrics explorer.
Next steps
Learn about advanced features of Metrics Explorer
Troubleshooting Metrics Explorer
See a list of available metrics for Azure services
See examples of configured charts
Advanced features of Azure Metrics Explorer
NOTE
This article assumes that you are familiar with basic features of Metrics Explorer. If you are a new user and want to learn
how to create your first metric chart, see Getting started with Azure Metrics Explorer.
Metrics in Azure
Metrics in Azure Monitor are the series of measured values and counts that are collected and stored over time.
There are standard (or “platform”) metrics, and custom metrics. The standard metrics are provided to you by the
Azure platform itself. Standard metrics reflect the health and usage statistics of your Azure resources. Whereas
custom metrics are sent to Azure by your applications using the Application Insights API for custom events and
metrics, Windows Azure Diagnostics (WAD ) extension, or by Azure Monitor REST API.
Create views with multiple metrics and charts

You can create charts that plot multiple metrics lines or show multiple metric charts at once. This functionality
allows you to:
correlate related metrics on the same graph to see how one value is related to another
display metrics with different units of measure in close proximity
visually aggregate and compare metrics from multiple resources
For example, if you have 5 storage accounts and you want to know how much total space is consumed between
them, you can create a (stacked) area chart which shows the individual and sum of all the values at particular
points in time.
Multiple metrics on the same chart
First, create a new chart. Click Add Metric and repeat the steps to add another metric on the same chart.
NOTE
You typically don’t want to have metrics with different units of measure (i.e. “milliseconds” and “kilobytes”) or with
significantly different scale on one chart. Instead, consider using multiple charts. Click on the Add Chart button to create
multiple charts in metrics explorer.
Multiple charts
Click the Add chart and create another chart with a different metric.
Order or delete multiple charts
To order or delete multiple charts, click on the ellipses ( ... ) symbol to open the chart menu and choose the
appropriate menu item of Move up, Move down, or Delete.
Apply filters to charts

You can apply filters to the charts that show metrics with dimensions. For example, if the metric “Transaction
count” has a dimension, “Response type”, which indicates whether the response from transactions succeeded or
failed then filtering on this dimension would plot a chart line for only successful (or only failed) transactions.
To add a filter
1. Select Add filter above the chart
2. Select which dimension (property) you want to filter
3. Select which dimension values you want to include when plotting the chart (this example shows filtering
out the successful storage transactions):
4. After selecting the filter values, click away from the Filter Selector to close it. Now the chart shows how
many storage transactions have failed:
5. You can repeat steps 1-4 to apply multiple filters to the same charts.
Apply splitting to a chart

You can split a metric by dimension to visualize how different segments of the metric compare against each
other, and identify the outlying segments of a dimension.
Apply splitting
1. Click on Apply splitting above the chart.
NOTE
Splitting cannot be used with charts that have multiple metrics. Also, you can have multiple filters but only one
splitting dimension applied to any single chart.
2. Choose a dimension on which you want to segment your chart:
Now the chart now shows multiple lines, one for each segment of dimension:
3. Click away from the Grouping Selector to close it.
NOTE
Use both Filtering and Splitting on the same dimension to hide the segments that are irrelevant for your scenario
and make charts easier to read.
Lock boundaries of chart y-axis

Locking the range of the y-axis becomes important when the chart shows smaller fluctuations of larger values.
For example, when the volume of successful requests drops down from 99.99% to 99.5%, it may represent a
significant reduction in the quality of service. However, noticing a small numeric value fluctuation would be
difficult or even impossible from the default chart settings. In this case you could lock the lowest boundary of
the chart to 99%, which would make this small drop more apparent.
Another example is a fluctuation in the available memory, where the value will technically never reach 0. Fixing
the range to a higher value may make the drops in available memory easier to spot.
To control the y-axis range, use the “…” chart menu, and select Edit chart to access advanced chart settings.
Modify the values in the Y -Axis Range section, or use Auto button to revert to defaults.
WARNING
Locking the boundaries of y-axis for the charts that track various counts or sums over a period of time (and thus use
count, sum, minimum, or maximum aggregations) usually requires specifying a fixed time granularity rather than relying
on the automatic defaults. This is necessary is because the values on charts change when the time granularity is
automatically modified by the user resizing browser window or going from one screen resolution to another. The resulting
change in time granularity effects the look of the chart, invalidating current selection of y-axis range.
Pin charts to dashboards

After configuring the charts, you may want to add it to the dashboards so that you can view it again, possibly in
context of other monitoring telemetry, or share with your team.
To pin a configured chart to a dashboard:
After configuring your chart, click on the Chart Actions menu in the right top corner of the chart, and click Pin
to dashboard.
Create alert rules
You can use the criteria you have set to visualize your metrics as the basis of a metric based alert rule. The new
alerting rule will include your target resource, metric, splitting, and filter dimensions from your chart. You will
be able to modify these settings later on the alert rule creation pane.
To create a new alert rule, click New Alert rule
You will be taken to the alert rule creation pane with the underlying metric dimensions from your chart pre-
populated to make it easier to generate custom alert rules.
Check out this article to learn more about setting up metric alerts.
Troubleshooting
I don't see any data on my chart.
Filters apply to all the charts on the pane. Make sure that, while you're focusing on one chart, you didn't
set a filter that excludes all the data on another.
If you want to set different filters on different charts, create them in different blades, save them as
separate favorites. If you want, you can pin them to the dashboard so that you can see them alongside
each other.
If you segment a chart by a property that is not defined on the metric, then there will be nothing on the
chart. Try clearing the segmentation (splitting), or choose a different property.
Next steps
Read Creating custom KPI dashboards to learn about the best practices for creating actionable dashboards with
metrics.
Metric chart samples
The Azure platform offers over a thousand metrics, many of which have dimensions. By using dimension filters,
applying splitting, controlling chart type, and adjusting chart settings you can create powerful diagnostic views
and dashboards that provide insight into the health of your infrastructure and applications. This article shows
some examples of the charts that you can build using Metrics Explorer and explains the necessary steps to
configure each of these charts.
Want to share your great charts examples with the world? Contribute to this page on GitHub and share your own
chart examples here!
Website CPU utilization by server instances

This chart shows if CPU for an App Service was within the acceptable range and breaks it down by instance to
determine whether the load was properly distributed. You can see from the chart that the app was running on a
single server instance before 6 AM, and then scaled up by adding another instance.
How to configure this chart?

Select your App Service resource and find the CPU Percentage metric. Then click on Apply splitting and select
the Instance dimension.
Application availability by region

View your application's availability by region to identify which geographic locations are having problems. This
chart shows the Application Insights availability metric. You can see that the monitored application has no
problem with availability from the East US datacenter, but it is experiencing a partial availability problem from
West US, and East Asia.
You first need to turn on Application Insights availability monitoring for your website. After that, pick your
Application Insights resource and select the Availability metric. Apply splitting on the Run location dimension.
Volume of storage account transactions by API name

Your storage account resource is experiencing an excess volume of transactions. You can use the transactions
metric to identify which API is responsible for the excess load. Notice that the following chart is configured with
the same dimension (API name) in filtering and splitting to narrow down the view to only the API calls of the
interest:

In the metric picker, select your storage account and the Transactions metric. Switch chart type to Bar chart. Click
Apply splitting and select dimension API name. Then click on the Add filter and pick the API name dimension
once again. In the filter dialog, select the APIs that you want to plot on the chart.
Next steps
Learn about Azure Monitor Workbooks
Learn more about Metric Explorer
Troubleshooting metrics charts
Use this article if you run into issues with creating, customizing, or interpreting charts in Azure metrics explorer. If
you are new to metrics, learn about getting started with metrics explorer and advanced features of metrics
explorer. You can also see examples of the configured metric charts.
Can't find your resource to select it

You clicked on the Select a resource button, but don't see your resource in the resource picker dialog.
Solution: Metrics explorer requires you to select subscriptions and resource groups before listing available
resources. If you don't see your resource:
1. Ensure that you've selected correct subscription in the Subscription dropdown. If your subscription isn't
listed, click on the Directory + Subscription settings and add a subscription with your resource.
2. Ensure that you've selected the correct resource group.
WARNING
For best performance, when you first open metrics explorer, the Resource group dropdown has no pre-selected
resource groups. You must pick at least one group before you can see any resources.
Chart shows no data

Sometimes the charts might show no data after selecting correct resources and metrics. This behavior can be
caused by several of the following reasons:
Microsoft.Insights resource provider isn't registered for your subscription
Exploring metrics requires Microsoft.Insights resource provider registered in your subscription. In many cases, it is
registered automatically (that is, after you configure an alert rule, customize diagnostic settings for any resource, or
configure an autoscale rule). If the Microsoft.Insights resource provider is not registered, you must manually
register it by following steps described in Azure resource providers and types.
Solution: Open Subscriptions, Resource providers tab, and verify that Microsoft.Insights is registered for your
subscription.
You don't have sufficient access rights to your resource
In Azure, access to metrics is controlled by role-based access control (RBAC ). You must be a member of
monitoring reader, monitoring contributor, or contributor to explore metrics for any resource.
Solution: Ensure that you have sufficient permissions for the resource from which you are exploring metrics.
Your resource didn't emit metrics during the selected time range
Some resources don’t constantly emit their metrics. For example, Azure will not collect metrics for stopped virtual
machines. Other resources might emit their metrics only when some condition occurs. For example, a metric
showing processing time of a transaction requires at least one transaction. If there were no transactions in the
selected time range, the chart will naturally be empty. Additionally, while most of the metrics in Azure are collected
every minute, there are some that are collected less frequently. See the metric documentation to get more details
about the metric that you are trying to explore.
Solution: Change the time of the chart to a wider range. You may start from “Last 30 days” using a larger time
granularity (or relying on the “Automatic time granularity” option).
You picked a time range greater than 30 days
Most metrics in Azure are stored for 93 days. However, you can only query for no more than 30 days worth of
data on any single chart. This limitation doesn't apply to log-based metrics.
Solution: If you see a blank chart or your chart only displays part of metric data, verify that the difference
between start- and end- dates in the time picker doesn't exceed the 30-day interval.
All metric values were outside of the locked y-axis range
By locking the boundaries of chart y-axis, you can unintentionally make the chart display area not show the chart
line. For example, if the y-axis is locked to a range between 0% and 50%, and the metric has a constant value of
100%, the line is always rendered outside of the visible area, making the chart appear blank.
Solution: Verify that the y-axis boundaries of the chart aren’t locked outside of the range of the metric values. If
the y-axis boundaries are locked, you may want to temporarily reset them to ensure that the metric values don’t
fall outside of the chart range. Locking the y-axis range isn’t recommended with automatic granularity for the
charts with sum, min, and max aggregation because their values will change with granularity by resizing browser
window or going from one screen resolution to another. Switching granularity may leave the display area of your
chart empty.
You are looking at a Guest OS metric but didn’t enable Azure Diagnostic Extension
Collection of Guest OS metrics requires configuring the Azure Diagnostics Extension or enabling it using the
Diagnostic Settings panel for your resource.
Solution: If Azure Diagnostics Extension is enabled but you are still unable to see your metrics, follow steps
outlined in Azure Diagnostics Extension troubleshooting guide. See also the troubleshooting steps for Cannot pick
Guest OS namespace and metrics
“Error retrieving data” message on dashboard

This problem may happen when your dashboard was created with a metric that was later deprecated and removed
from Azure. To verify that it is the case, open the Metrics tab of your resource, and check the available metrics in
the metric picker. If the metric is not shown, the metric has been removed from Azure. Usually, when a metric is
deprecated, there is a better new metric that provides with a similar perspective on the resource health.
Solution: Update the failing tile by picking an alternative metric for your chart on dashboard. You can review a list
of available metrics for Azure services.
Chart shows dashed line

Azure metrics charts use dashed line style to indicate that there is a missing value (also known as “null value”)
between two known time grain data points. For example, if in the time selector you picked “1 minute” time
granularity but the metric was reported at 07:26, 07:27, 07:29, and 07:30 (note a minute gap between second and
third data points), then a dashed line will connect 07:27 and 07:29 and a solid line will connect all other data points.
The dashed line drops down to zero when the metric uses count and sum aggregation. For the avg, min or max
aggregations, the dashed line connects two nearest known data points. Also, when the data is missing on the
rightmost or leftmost side of the chart, the dashed line expands to the direction of the missing data point.
Solution: This behavior is by design. It is useful for identifying missing data points. The line chart is a superior
choice for visualizing trends of high-density metrics but may be difficult to interpret for the metrics with sparse
values, especially when corelating values with time grain is important. The dashed line makes reading of these
charts easier but if your chart is still unclear, consider viewing your metrics with a different chart type. For example,
a scattered plot chart for the same metric clearly shows each time grain by only visualizing a dot when there is a
value and skipping the data point altogether when the value is missing:
NOTE
If you still prefer a line chart for your metric, moving mouse over the chart may help to assess the time granularity by
highlighting the data point at the location of the mouse pointer.
Chart shows unexpected drop in values

In many cases, the perceived drop in the metric values is a misunderstanding of the data shown on the chart. You
can be misled by a drop in sums or counts when the chart shows the most-recent minutes because the last metric
data points haven’t been received or processed by Azure yet. Depending on the service, the latency of processing
metrics can be within a couple minutes range. For charts showing a recent time range with a 1- or 5- minute
granularity, a drop of the value over the last few minutes becomes more noticeable:
Solution: This behavior is by design. We believe that showing data as soon as we receive it is beneficial even when
the data is partial or incomplete. Doing so allows you to make important conclusion sooner and start investigation
right away. For example, for a metric that shows the number of failures, seeing a partial value X tells you that there
were at least X failures on a given minute. You can start investigating the problem right away, rather than wait to
see the exact count of failures that happened on this minute, which might not be as important. The chart will
update once we receive the entire set of data, but at that time it may also show new incomplete data points from
more recent minutes.
Cannot pick Guest OS namespace and metrics

Virtual machines and virtual machine scale sets have two categories of metrics: Virtual Machine Host metrics
that are collected by the Azure hosting environment, and Guest OS metrics that are collected by the monitoring
agent running on your virtual machines. You install the monitoring agent by enabling Azure Diagnostic Extension.
By default, Guest OS metrics are stored in Azure Storage account, which you pick from the Diagnostic settings
tab of your resource. If Guest OS metrics aren't collected or metrics explorer cannot access them, you will only see
the Virtual Machine Host metric namespace:
Solution: If you don't see Guest OS namespace and metrics in metrics explorer:
1. Confirm that Azure Diagnostic Extension is enabled and configured to collect metrics.
WARNING
You cannot use Log Analytics agent (also referred to as the Microsoft Monitoring Agent, or "MMA") to send Guest
OS into a storage account.
2. Verify that storage account isn't protected by the firewall.

3. Use the Azure storage explorer to validate that metrics are flowing into the storage account. If metrics aren't
collected, follow the Azure Diagnostics Extension troubleshooting guide.
Next steps
Learn about getting started with Metric Explorer
Learn about advanced features of Metric Explorer
See a list of available metrics for Azure services
See examples of configured charts
Overview of log queries in Azure Monitor
Log queries help you to fully leverage the value of the data collected in Azure Monitor
Logs. A powerful query language allows you to join data from multiple tables, aggregate
large sets of data, and perform complex operations with minimal code. Virtually any
question can be answered and analysis performed as long as the supporting data has been
collected, and you understand how to construct the right query.
Some features in Azure Monitor such as insights and solutions process log data without
exposing you to the underlying queries. To fully leverage other features of Azure Monitor,
you should understand how queries are constructed and how you can use them to
interactively analyze data in Azure Monitor Logs.
Use this article as a starting point to learning about log queries in Azure Monitor. It
answers common questions and provides links to other documentation that provides
further details and lessons.
How can I learn how to write queries?

If you want to jump right into things, you can start with the following tutorials:
Get started with Log Analytics in Azure Monitor.
Get started with log queries in Azure Monitor.
Once you have the basics down, walk through multiple lessons using either your own data
or data from our demo environment starting with:
Work with strings in Azure Monitor log queries
What language do log queries use?

Azure Monitor Logs is based on Azure Data Explorer, and log queries are written using the
same Kusto query language (KQL ). This is a rich language designed to be easy to read and
author, and you should be able to start using it with minimal guidance.
See Azure Data Explorer KQL documentation for complete documentation on KQL and
reference on different functions available.
See Get started with log queries in Azure Monitor for a quick walkthrough of the language
using data from Azure Monitor Logs. See Azure Monitor log query language differences
for minor differences in the version of KQL used by Azure Monitor.
What data is available to log queries?

All data collected in Azure Monitor Logs is available to retrieve and analyze in log queries.
Different data sources will write their data to different tables, but you can include multiple
tables in a single query to analyze data across multiple sources. When you build a query,
you start by determining which tables have the data that you're looking for, so you should
have at least a basic understanding of how data in Azure Monitor Logs is structured.
See Sources of Azure Monitor Logs, for a list of different data sources that populate Azure
Monitor Logs.
See Structure of Azure Monitor Logs for an explanation of how the data is structured.
What does a log query look like?

A query could be as simple as a single table name for retrieving all records from that table:
Syslog
Or it could filter for particular records, summarize them, and visualize the results in a chart:
SecurityEvent
| summarize count() by Computer, bin(TimeGenerated, 1h)
| render timechart
For more complex analysis, you might retrieve data from multiple tables using a join to
analyze the results together.
app("ContosoRetailWeb").requests
| summarize count() by bin(timestamp,1hr)
| join kind= inner (Perf
| summarize avg(CounterValue)
by bin(TimeGenerated,1hr))
on $left.timestamp == $right.TimeGenerated
Even if you aren't familiar with KQL, you should be able to at least figure out the basic logic
being used by these queries. They start with the name of a table and then add multiple
commands to filter and process that data. A query can use any number of commands, and
you can write more complex queries as you become familiar with the different KQL
commands available.
See Get started with log queries in Azure Monitor for a tutorial on log queries that
introduces the language and common functions, .
What is Log Analytics?

Log Analytics is the primary tool in the Azure portal for writing log queries and
interactively analyzing their results. Even if a log query is used elsewhere in Azure Monitor,
you'll typically write and test the query first using Log Analytics.
You can start Log Analytics from several places in the Azure portal. The scope of the data
available to Log Analytics is determined by how you start it. See Query Scope for more
details.
Select Logs from the Azure Monitor menu or Log Analytics workspaces menu.
Select Analytics from the Overview page of an Application Insights application.
Select Logs from the menu of an Azure resource.
See Get started with Log Analytics in Azure Monitor for a tutorial walkthrough of Log
Analytics that introduces several of its features.
Where else are log queries used?

In addition to interactively working with log queries and their results in Log Analytics, areas
in Azure Monitor where you will use queries include the following:
Alert rules. Alert rules proactively identify issues from data in your workspace. Each
alert rule is based on a log search that is automatically run at regular intervals. The
results are inspected to determine if an alert should be created.
Dashboards. You can pin the results of any query into an Azure dashboard which allow
you to visualize log and metric data together and optionally share with other Azure
users.
Views. You can create visualizations of data to be included in user dashboards with
View Designer. Log queries provide the data used by tiles and visualization parts in each
view.
Export. When you import log data from Azure Monitor into Excel or Power BI, you
create a log query to define the data to export.
PowerShell. You can run a PowerShell script from a command line or an Azure
Automation runbook that uses Get-AzOperationalInsightsSearchResults to retrieve log
data from Azure Monitor. This cmdlet requires a query to determine the data to retrieve.
Azure Monitor Logs API. The Azure Monitor Logs API allows any REST API client to
retrieve log data from the workspace. The API request includes a query that is run
against Azure Monitor to determine the data to retrieve.
Next steps
Walk through a tutorial on using Log Analytics in the Azure portal.
Walk through a tutorial on writing queries.
Simple Logs experience in Azure Monitor (Preview)
Azure Monitor provides a rich experience for creating log queries using the KQL language. You may not require the
full power of KQL though and prefer a simplified experience for basic query requirements. The Simple Logs
experience allows you to create basic queries without directly interacting with KQL. You can also use Simple Logs
as a learning tool for KQL as you require more sophisticated queries.
NOTE
Simple Logs is currently implemented as a test for only Cosmos DB and Key Vaults. Please share your experience with
Microsoft through User Voice to help us determine whether we will expand and release this feature.
Scope
The Simple Logs experience retrieves data from the AzureDiagnostics, AzureMetrics, and AzureActivity table for
the selected resource.
Using Simple Logs

Navigate to any Cosmos DB or Key Vault in your Azure subscription with diagnostic settings configured to collect
logs in a Log Analytics workspace. Click Logs in the Monitoring menu to open the Simple Logs experience.
Select a Field and an Operator and specify a Value for comparison. Click + and specify And/Or to add additional
criteria.
Click Run to view the query results.
View and edit KQL

Select Query editor to open the KQL generated by the Simple Logs query in the full Log Analytics experience.
You can directly edit the KQL and use other features in Log Analytics such as filters to further refine your results.
Next steps
Complete a tutorial on using Log Analytics in the Azure portal.
Complete a tutorial on writing log queries.
Get started with Log Analytics in Azure Monitor
NOTE
You can work through this exercise in your own environment if you are collecting data from at least one virtual
machine. If not then use our Demo environment, which includes plenty of sample data.
In this tutorial you will learn how to use Log Analytics in the Azure portal to write Azure Monitor log
queries. It will teach you how to:
Use Log Analytics to write a simple query
Understand the schema of your data
Filter, sort, and group results
Apply a time range
Create charts
Save and load queries
Export and share queries
For a tutorial on writing log queries, see Get started with log queries in Azure Monitor.
For more details on log queries, see Overview of log queries in Azure Monitor.
Meet Log Analytics

Log Analytics is a web tool used to write and execute Azure Monitor log queries. Open it by selecting Logs
in the Azure Monitor menu. It starts with a new blank query.
Firewall requirements
To use Log Analytics, your browser requires access to the following addresses. If your browser is accessing
the Azure portal through a firewall, you must enable access to these addresses.
URI IP PORTS
portal.loganalytics.io Dynamic 80,443
api.loganalytics.io Dynamic 80,443
docs.loganalytics.io Dynamic 80,443
Basic queries
Queries can be used to search terms, identify trends, analyze patterns, and provide many other insights
based on your data. Start with a basic query:
Event | search "error"
This query searches the Event table for records that contain the term error in any property.
Queries can start with either a table name or a search command. The above example starts with the table
name Event, which retrieves all records from the Event table. The pipe (|) character separates commands, so
the output of the first one serves as the input of the following command. You can add any number of
commands to a single query.
Another way to write that same query would be:
In this example, search is scoped to the Event table, and all records in that table are searched for the term
error.
Running a query
Run a query by clicking the Run button or pressing Shift+Enter. Consider the following details which
determine the code that will be run and the data that's returned:
Line breaks: A single break makes your query easier to read. Multiple line breaks split it into separate
queries.
Cursor: Place your cursor somewhere inside the query to execute it. The current query is considered to
be the code up until a blank line is found.
Time range - A time range of last 24 hours is set by default. To use a different range, use the time-picker
or add an explicit time range filter to your query.
Understand the schema

The schema is a collection of tables visually grouped under a logical category. Several of the categories are
from monitoring solutions. The LogManagement category contains common data such as Windows and
Syslog events, performance data, and agent heartbeats.
In each table, data is organized in columns with different data types as indicated by icons next to the
column name. For example, the Event table shown in the screenshot contains columns such as Computer
which is text, EventCategory which is a number, and TimeGenerated which is date/time.
Filter the results

Start by getting everything in the Event table.
Event
Log Analytics automatically scopes results by:

Time range: By default, queries are limited to the last 24 hours.
Number of results: Results are limited to maximum of 10,000 records.
This query is very general, and it returns too many results to be useful. You can filter the results either
through the table elements, or by explicitly adding a filter to the query. Filtering results through the table
elements applies to the existing result set, while a filter to the query itself will return a new filtered result set
and could therefore produce more accurate results.
Add a filter to the query
There is an arrow to the left of each record. Click this arrow to open the details for a specific record.
Hover above a column name for the "+" and "-" icons to display. To add a filter that will return only records
with the same value, click the "+" sign. Click "-" to exclude records with this value and then click Run to run
the query again.
Filter through the table elements
Now let's focus on events with a severity of Error. This is specified in a column named EventLevelName.
You'll need to scroll to the right to see this column.
Click the Filter icon next to the column title, and in the pop-up window select values that Starts with the text
error:
Sort and group results

The results are now narrowed down to include only error events from SQL Server, created in the last 24
hours. However, the results are not sorted in any way. To sort the results by a specific column, such as
timestamp for example, click the column title. One click sorts in ascending order while a second click will
sort in descending.
Another way to organize results is by groups. To group results by a specific column, simply drag the
column header above the other columns. To create subgroups, drag other columns the upper bar as well.
Select columns to display

The results table often includes a lot of columns. You might find that some of the returned columns are not
displayed by default, or you may want to remove some the columns that are displayed. To select the
columns to show, click the Columns button:
Select a time range

By default, Log Analytics applies the last 24 hours time range. To use a different range, select another value
through the time picker and click Run. In addition to the preset values, you can use the Custom time range
option to select an absolute range for your query.
When selecting a custom time range, the selected values are in UTC, which could be different than your
local time zone.
If the query explicitly contains a filter for TimeGenerated, the time picker title will show Set in query.
Manual selection will be disabled to prevent a conflict.
Charts
In addition to returning results in a table, query results can be presented in visual formats. Use the
following query as an example:
Event
| summarize count() by Source
By default, results are displayed in a table. Click Chart to see the results in a graphic view:
The results are shown in a stacked bar chart. Click Stacked Column and select Pie to show another view of
the results:
Different properties of the view, such as x and y axes, or grouping and splitting preferences, can be changed
manually from the control bar.
You can also set the preferred view in the query itself, using the render operator.
Smart diagnostics
On a timechart, if there is a sudden spike or step in your data, you may see a highlighted point on the line.
This indicates that Smart Diagnostics has identified a combination of properties that filter out the sudden
change. Click the point to get more detail on the filter, and to see the filtered version. This may help you
identify what caused the change:
Pin to dashboard
To pin a diagram or table to one of your shared Azure dashboards, click the pin icon. Note that this icon has
moved to the top of the Log Analytics window, different from the screenshot below.
Certain simplifications are applied to a chart when you pin it to a dashboard:
Table columns and rows: In order to pin a table to the dashboard, it must have four or fewer columns.
Only the top seven rows are displayed.
Time restriction: Queries are automatically limited to the past 14 days.
Bin count restriction: If you display a chart that has a lot of discrete bins, less populated bins are
automatically grouped into a single others bin.
Save queries
Once you've created a useful query, you might want to save it or share with others. The Save icon is on the
top bar.
You can save either the entire query page, or a single query as a function. Functions are queries that can
also be referenced by other queries. In order to save a query as a function, you must provide a function
alias, which is the name used to call this query when referenced by other queries.
NOTE
The following characters are supported - a–z, A–Z, 0-9, -, _, ., <space>, (, ), | in the Name field when
saving or editing the saved query.
Log Analytics queries are always saved to a selected workspace, and shared with other users of that
workspace.
Load queries
The Query Explorer icon is at the top-right area. This lists all saved queries by category. It also enables you
to mark specific queries as Favorites to quickly find them in the future. Double-click a saved query to add it
to the current window.
Export and share as link

Log Analytics supports several exporting methods:
Excel: Save the results as a CSV file.
Power BI: Export the results to Power BI. See Import Azure Monitor log data into Power BI for details.
Share a link: The query itself can be shared as a link which can then be sent and executed by other users
that have access to the same workspace.
Next steps
Learn more about writing Azure Monitor log queries.
Get started with log queries in Azure Monitor
NOTE
You should complete Get started with Azure Monitor Log Analytics before completing this tutorial.
NOTE
You can work through this exercise in your own environment if you are collecting data from at least one virtual
machine. If not then use our Demo environment, which includes plenty of sample data.
In this tutorial you will learn to write log queries in Azure Monitor. It will teach you how to:
Understand query structure
Sort query results
Filter query results
Select which fields to include in the results
Define and use custom fields
Aggregate and group results
For a tutorial on using Log Analytics in the Azure portal, see Get started with Azure Monitor Log Analytics.
For more details on log queries in Azure Monitor, see Overview of log queries in Azure Monitor.
Writing a new query

Queries can start with either a table name or the search command. You should start with a table name, since it
defines a clear scope for the query and improves both query performance and relevance of the results.
NOTE
The Kusto query language used by Azure Monitor is case-sensitive. Language keywords are typically written in lower-
case. When using names of tables or columns in a query, make sure to use the correct case, as shown on the schema
pane.
Table -based queries

Azure Monitor organizes log data in tables, each composed of multiple columns. All tables and columns are
shown on the schema pane in Log Analytics in the Analytics portal. Identify a table that you're interested in
and then take a look at a bit of data:
SecurityEvent
| take 10
The query shown above returns 10 results from the SecurityEvent table, in no specific order. This is a very
common way to take a glance at a table and understand its structure and content. Let's examine how it's built:
The query starts with the table name SecurityEvent - this part defines the scope of the query.
The pipe (|) character separates commands, so the output of the first one in the input of the following
command. You can add any number of piped elements.
Following the pipe is the take command, which returns a specific number of arbitrary records from the
table.
We could actually run the query even without adding | take 10 - that would still be valid, but it could return
up to 10,000 results.
Search queries
Search queries are less structured, and generally more suited for finding records that include a specific value
in any of their columns:
search in (SecurityEvent) "Cryptographic"

| take 10
This query searches the SecurityEvent table for records that contain the phrase "Cryptographic". Of those
records, 10 records will be returned and displayed. If we omit the in (SecurityEvent) part and just run
search "Cryptographic" , the search will go over all tables, which would take longer and be less efficient.
WARNING
Search queries are typically slower than table-based queries because they have to process more data.
Sort and top

While take is useful to get a few records, the results are selected and displayed in no particular order. To get
an ordered view, you could sort by the preferred column:
SecurityEvent
That could return too many results though and might also take some time. The above query sorts the entire
SecurityEvent table by the TimeGenerated column. The Analytics portal then limits the display to show only
10,000 records. This approach is of course not optimal.
The best way to get only the latest 10 records is to use top, which sorts the entire table on the server side and
then returns the top records:
SecurityEvent
Descending is the default sorting order, so we typically omit the desc argument.The output will look like this:
Where: filtering on a condition
Filters, as indicated by their name, filter the data by a specific condition. This is the most common way to limit
query results to relevant information.
To add a filter to a query, use the where operator followed by one or more conditions. For example, the
following query returns only SecurityEvent records where Level equals 8:
SecurityEvent
| where Level == 8
When writing filter conditions, you can use the following expressions:
EXPRESSION DESCRIPTION EXAMPLE
== Check equality Level == 8

(case-sensitive)
=~ Check equality EventSourceName =~ "microsoft-

(case-insensitive) windows-security-auditing"
!=, <> Check inequality Level != 4

(both expressions are identical)
and, or Required between conditions Level == 16 or CommandLine !=

""
To filter by multiple conditions, you can either use and:
SecurityEvent
| where Level == 8 and EventID == 4672
or pipe multiple where elements one after the other:
SecurityEvent
| where Level == 8
NOTE
Values can have different types, so you might need to cast them to perform comparison on the correct type. For
example, SecurityEvent Level column is of type String, so you must cast it to a numerical type such as int or long, before
you can use numerical operators on it: SecurityEvent | where toint(Level) >= 10

Time picker
The time picker is next to the Run button and indicates we’re querying only records from the last 24 hours.
This is the default time range applied to all queries. To get only records from the last hour, select Last hour and
run the query again.
Time filter in query

You can also define your own time range by adding a time filter to the query. It’s best to place the time filter
immediately after the table name:
SecurityEvent
| where toint(Level) >= 10
In the above time filter ago(30m) means "30 minutes ago" so this query only returns records from the last 30
minutes. Other units of time include days (2d), minutes (25m), and seconds (10s).
Project and Extend: select and compute columns

Use project to select specific columns to include in the results:
SecurityEvent
| project TimeGenerated, Computer, Activity
The preceding example generates this output:

You can also use project to rename columns and define new ones. The following example uses project to do
the following:
Select only the Computer and TimeGenerated original columns.
Rename the Activity column to EventDetails.
Create a new column named EventCode. The substring() function is used to get only the first four
characters from the Activity field.
SecurityEvent
| project Computer, TimeGenerated, EventDetails=Activity, EventCode=substring(Activity, 0, 4)
extend keeps all original columns in the result set and defines additional ones. The following query uses
extend to add the EventCode column. Note that this column may not display at the end of the table results in
which case you would need to expand the details of a record to view it.
SecurityEvent
| extend EventCode=substring(Activity, 0, 4)
Summarize: aggregate groups of rows

Use summarize to identify groups of records, according to one or more columns, and apply aggregations to
them. The most common use of summarize is count, which returns the number of results in each group.
The following query reviews all Perf records from the last hour, groups them by ObjectName, and counts the
records in each group:
Perf
| summarize count() by ObjectName
Sometimes it makes sense to define groups by multiple dimensions. Each unique combination of these values
defines a separate group:
Perf
| summarize count() by ObjectName, CounterName
Another common use is to perform mathematical or statistical calculations on each group. For example, the
following calculates the average CounterValue for each computer:
Perf
| summarize avg(CounterValue) by Computer
Unfortunately, the results of this query are meaningless since we mixed together different performance
counters. To make this more meaningful, we should calculate the average separately for each combination of
CounterName and Computer:
Perf
| summarize avg(CounterValue) by Computer, CounterName
Summarize by a time column

Grouping results can also be based on a time column, or another continuous value. Simply summarizing
by TimeGenerated though would create groups for every single millisecond over the time range, since these
are unique values.
To create groups based on continuous values, it is best to break the range into manageable units using bin.
The following query analyzes Perf records that measure free memory ( Available MBytes) on a specific
computer. It calculates the average value of each 1 hour period over the last 7 days:
Perf
| where Computer == "ContosoAzADDS2"
| where CounterName == "Available MBytes"
| summarize avg(CounterValue) by bin(TimeGenerated, 1h)
To make the output clearer, you select to display it as a time-chart, showing the available memory over time:
Next steps
Learn about writing search queries
Structure of Azure Monitor Logs
The ability to quickly gain insights into your data using a log query is a powerful feature of Azure Monitor. To
create efficient and useful queries, you should understand some basic concepts such as where the data you want is
located and how it's structured. This article provides the basic concepts you need to get started.
Overview
Data in Azure Monitor Logs is stored in either a Log Analytics workspace or an Application Insights application.
Both are powered by Azure Data Explorer meaning that they leverage its powerful data engine and query
language.
Data in both workspaces and applications is organized into tables, each of which stores different kinds of data and
has its own unique set of properties. Most data sources will write to their own tables in a Log Analytics workspace,
while Application Insights will write to a predefined set of tables in an Application Insights application. Log queries
are very flexible allowing you to easily combine data from multiple tables and even use a cross-resource query to
combine data from tables in multiple workspaces or to write queries that combine workspace and application data.
The following image shows examples of data sources that write to different tables that are used in sample queries.

All data collected by Azure Monitor Logs except for Application Insights is stored in a Log Analytics workspace.
You can create one or more workspaces depending on your particular requirements. Data Sources such as Activity
Logs and Diagnostic logs from Azure resources, agents on virtual machines, and data from insights and
monitoring solutions will write data to one or more workspaces that you configure as part of their onboarding.
Other services such as Azure Security Center and Azure Sentinel also use a Log Analytics workspace to store their
data so it can be analyzed using log queries along with monitoring data from other sources.
Different kinds of data are stored in different tables in the workspace, and each table has a unique set of
properties. A standard set of tables are added to a workspace when it's created, and new tables are added for
different data sources, solutions, and services as they're onboarded. You can also create custom tables using the
Data Collector API.
You can browse the tables in a workspace and their schema in the Schema tab in Log Analytics for the workspace.
Use the following query to list the tables in the workspace and the number of records collected into each over the
previous day.
union withsource = table *

| summarize count() by table
| sort by table asc
See documentation for each data source for details of the tables they create. Examples include articles for agent
data sources, diagnostic logs, and monitoring solutions.
Workspace permissions
See Designing an Azure Monitor Logs deployment to understand the access control strategy and
recommendations to provide access to data in a workspace. In addition to granting access to the workspace itself,
you can limit access to individual tables using Table Level RBAC.
Application Insights application

When you create an application in Application Insights, a corresponding application is automatically created in
Azure Monitor Logs. No configuration is required to collect data, and the application will automatically write
monitoring data such as page views, requests, and exceptions.
Unlike a Log Analytics workspace, an Application Insights application has a fixed set of tables. You can't configure
other data sources to write to the application so no additional tables can be created.
TABLE DESCRIPTION
availabilityResults Summary data from availability tests.
browserTimings Data about client performance, such as the time taken to

process the incoming data.
customEvents Custom events created by your application.
customMetrics Custom metrics created by your application.

TABLE DESCRIPTION
dependencies Calls from the application to external components.
exceptions Exceptions thrown by the application runtime.
pageViews Data about each website view with browser information.
performanceCounters Performance measurements from the compute resources

supporting the application.
requests Details of each application request.
traces Results from distributed tracing.
You can view the schema for each table in the Schema tab in Log Analytics for the application.
Standard properties
While each table in Azure Monitor Logs has its own schema, there are standard properties shared by all tables.
See Standard properties in Azure Monitor Logs for details of each.
LOG ANALYTICS WORKSPACE APPLICATION INSIGHTS APPLICATION DESCRIPTION
TimeGenerated timestamp Date and time the record was created.
Type itemType Name of the table the record was

retrieved from.
_ResourceId Unique identifier for the resource the

record is associated with.
_IsBillable Specifies whether ingested data is

billable.
LOG ANALYTICS WORKSPACE APPLICATION INSIGHTS APPLICATION DESCRIPTION
_BilledSize Specifies the size in bytes of data that

will be billed.
Next steps
Learn about using Log Analytics to create and edit log searches.
Check out a tutorial on writing queries using the new query language.
Log query scope and time range in Azure Monitor
Log Analytics
When you run a log query in Log Analytics in the Azure portal, the set of data evaluated by the query depends on
the scope and the time range that you select. This article describes the scope and time range and how you can set
each depending on your requirements. It also describes the behavior of different types of scopes.
Query scope
The query scope defines the records that are evaluated by the query. This will usually include all records in a single
Log Analytics workspace or Application Insights application. Log Analytics also allows you to set a scope for a
particular monitored Azure resource. This allows a resource owner to focus only on their data, even if that resource
writes to multiple workspaces.
The scope is always displayed at the top left of the Log Analytics window. An icon indicates whether the scope is a
Log Analytics workspace or an Application Insights application. No icon indicates another Azure resource.
The scope is determined by the method you use to start Log Analytics, and in some cases you can change the
scope by clicking on it. The following table lists the different types of scope used and different details for each.
QUERY SCOPE RECORDS IN SCOPE HOW TO SELECT CHANGING SCOPE
Log Analytics workspace All records in the Log Select Logs from the Azure Can change scope to any
Analytics workspace. Monitor menu or the Log other resource type.
Analytics workspaces
menu.
Application Insights All records in the Application Select Analytics from Can only change scope to
application Insights application. Overview page of another Application Insights
Application Insights. application.
Resource group Records created by all Select Logs from the Cannot change scope.
resources in the resource resource group menu.
group. May include data
from multiple Log Analytics
workspaces.
Subscription Records created by all Select Logs from the Cannot change scope.
resources in the subscription menu.
subscription. May include
data from multiple Log
Analytics workspaces.
QUERY SCOPE RECORDS IN SCOPE HOW TO SELECT CHANGING SCOPE
Other Azure resources Records created by the Select Logs from the Can only change scope to
resource. May include data resource menu. same resource type.
from multiple Log Analytics OR
workspaces. Select Logs from the Azure
Monitor menu and then
select a new scope.
Limitations when scoped to a resource

When the query scope is a Log Analytics workspace or an Application Insights application, all options in the portal
and all query commands are available. When scoped to a resource though, the following options in the portal not
available because they're associated with a single workspace or application:
Save
Query explorer
New alert rule
You can't use the following commands in a query when scoped to a resource since the query scope will already
include any workspaces with data for that resource or set of resources:
app
workspace
Query limits
You may have business requirements for an Azure resource to write data to multiple Log Analytics workspaces.
The workspace doesn't need to be in the same region as the resource, and a single workspace might gather data
from resources in a variety of regions.
Setting the scope to a resource or set of resources is a particularly powerful feature of Log Analytics since it allows
you to automatically consolidate distributed data in a single query. It can significantly affect performance though if
data needs to be retrieved from workspaces across multiple Azure regions.
Log Analytics helps protect against excessive overhead from queries that span workspaces in multiple regions by
issuing a warning or error when a certain number of regions are being used. Your query will receive a warning if
the scope includes workspaces in 5 or more regions. it will still run, but it may take excessive time to complete.
Your query will be blocked from running if the scope includes workspaces in 20 or more regions. In this case you
will be prompted to reduce the number of workspace regions and attempt to run the query again. The dropdown
will display all of the regions in the scope of the query, and you should reduce the number of regions before
attempting to run the query again.
Time range
The time range specifies the set of records that are evaluated for the query based on when the record was created.
This is defined by a standard property on every record in the workspace or application as specified in the following
table.
LOCATION PROPERTY
Log Analytics workspace TimeGenerated
Application Insights application timestamp
Set the time range by selecting it from the time picker at the top of the Log Analytics window. You can select a
predefined period or select Custom to specify a specific time range.
If you set a filter in the query that uses the standard time property as shown in the table above, the time picker
changes to Set in query, and the time picker is disabled. In this case, it's most efficient to put the filter at the top of
the query so that any subsequent processing only needs to work with the filtered records.
If you use the workspace or app command to retrieve data from another workspace or application, the time picker
may behave differently. If the scope is a Log Analytics workspace and you use app, or if the scope is an Application
Insights application and you use workspace, then Log Analytics may not understand that the property used in the
filter should determine the time filter.
In the following example, the scope is set to a Log Analytics workspace. The query uses workspace to retrieve data
from another Log Analytics workspace. The time picker changes to Set in query because it sees a filter that uses
the expected TimeGenerated property.
If the query uses app to retrieve data from an Application Insights application though, Log Analytics doesn't
recognize the timestamp property in the filter, and the time picker remains unchanged. In this case, both filters are
applied. In the example, only records created in the last 24 hours are included in the query even though it specifies
7 days in the where clause.
Next steps
Walk through a tutorial on using Log Analytics in the Azure portal.
Walk through a tutorial on writing queries.
Standard properties in Azure Monitor Logs
Data in Azure Monitor Logs is stored as a set of records in either a Log Analytics workspace or Application
Insights application, each with a particular data type that has a unique set of properties. Many data types will have
standard properties that are common across multiple types. This article describes these properties and provides
examples of how you can use them in queries.
NOTE
Some of the standard propertis will not show in the schema view or intellisense in Log Analytics, and they won't show in
query results unless you explicitly specify the property in the output.
TimeGenerated and timestamp

The TimeGenerated (Log Analytics workspace) and timestamp (Application Insights application) properties
contain the date and time that the record was created by the data source. See Log data ingestion time in Azure
Monitor for more details.
TimeGenerated and timestamp provide a common property to use for filtering or summarizing by time. When
you select a time range for a view or dashboard in the Azure portal, it uses TimeGenerated or timestamp to filter
the results.
Examples
The following query returns the number of error events created for each day in the previous week.
Event
| where TimeGenerated between(startofweek(ago(7days))..endofweek(ago(7days)))
| summarize count() by bin(TimeGenerated, 1day)
| sort by TimeGenerated asc
The following query returns the number of exceptions created for each day in the previous week.
exceptions
| where timestamp between(startofweek(ago(7days))..endofweek(ago(7days)))
| summarize count() by bin(TimeGenerated, 1day)
| sort by timestamp asc
_TimeReceived
The _TimeReceived property contains the date and time that the record was received by the Azure Monitor
ingestion point in the Azure cloud. This can be useful for identifying latency issues between the data source and
the cloud. An example would be a networking issue causing a delay with data being sent from an agent. See Log
data ingestion time in Azure Monitor for more details.
The following query gives the average latency by hour for event records from an agent. This includes the time
from the agent to the cloud and and the total time for the record to be available for log queries.
Event
| project TimeGenerated, TimeReceived = _TimeReceived, IngestionTime = ingestion_time()
| extend AgentLatency = toreal(datetime_diff('Millisecond',TimeReceived,TimeGenerated)) / 1000
| extend TotalLatency = toreal(datetime_diff('Millisecond',IngestionTime,TimeGenerated)) / 1000
| summarize avg(AgentLatency), avg(TotalLatency) by bin(TimeGenerated,1hr)
Type and itemType

The Type (Log Analytics workspace) and itemType (Application Insights application) properties hold the name of
the table that the record was retrieved from which can also be thought of as the record type. This property is
useful in queries that combine records from multiple table, such as those that use the search operator, to
distinguish between records of different types. $table can be used in place of Type in some places.
Examples
The following query returns the count of records by type collected over the past hour.
search *
| summarize count() by Type
_ItemId
The _ItemId property holds a unique identifier for the record.
_ResourceId
The _ResourceId property holds a unique identifier for the resource that the record is associated with. This gives
you a standard property to use to scope your query to only records from a particular resource, or to join related
data across multiple tables.
For Azure resources, the value of _ResourceId is the Azure resource ID URL. The property is currently limited to
Azure resources, but it will be extended to resources outside of Azure such as on-premises computers.
NOTE
Some data types already have fields that contain Azure resource ID or at least parts of it like subscription ID. While these
fields are kept for backward compatibility, it is recommended to use the _ResourceId to perform cross correlation since it will
be more consistent.
Examples
The following query joins performance and event data for each computer. It shows all events with an ID of 101
and processor utilization over 50%.
Perf
| where CounterName == "% User Time" and CounterValue > 50 and _ResourceId != ""
| join kind=inner (
Event
) on _ResourceId
The following query joins AzureActivity records with SecurityEvent records. It shows all activity operations with
users that were logged in to these machines.
AzureActivity
| where
OperationName in ("Restart Virtual Machine", "Create or Update Virtual Machine", "Delete Virtual Machine")
and ActivityStatus == "Succeeded"
| join kind= leftouter (
SecurityEvent
| summarize LoggedOnAccounts = makeset(Account) by _ResourceId
) on _ResourceId
The following query parses _ResourceId and aggregates billed data volumes per Azure subscription.
| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/"
resourceGroup "/providers/" provider "/" resourceType "/" resourceName
| summarize Bytes=sum(_BilledSize) by subscriptionId | sort by Bytes nulls last
Use these union withsource = tt * queries sparingly as scans across data types are expensive to execute.
_IsBillable
The _IsBillable property specifies whether ingested data is billable. Data with _IsBillable equal to false are
collected for free and not billed to your Azure account.
Examples
To get a list of computers sending billed data types, use the following query:
NOTE
Use queries with union withsource = tt * sparingly as scans across data types are expensive to execute.
| summarize TotalVolumeBytes=sum(_BilledSize) by computerName
This can be extended to return the count of computers per hour that are sending billed data types:
| summarize dcount(computerName) by bin(TimeGenerated, 1h) | sort by TimeGenerated asc
_BilledSize
The _BilledSize property specifies the size in bytes of data that will be billed to your Azure account if _IsBillable
is true.
Examples
To see the size of billable events ingested per computer, use the _BilledSize property which provides the size in
bytes:
| summarize Bytes=sum(_BilledSize) by Computer | sort by Bytes nulls last
To see the size of billable events ingested per subscription, use the following query:
union withsource=table *
| parse _ResourceId with "/subscriptions/" SubscriptionId "/" *
| summarize Bytes=sum(_BilledSize) by SubscriptionId | sort by Bytes nulls last
To see the size of billable events ingested per resource group, use the following query:
union withsource=table *
| parse _ResourceId with "/subscriptions/" SubscriptionId "/resourcegroups/" ResourceGroupName "/" *
| summarize Bytes=sum(_BilledSize) by SubscriptionId, ResourceGroupName | sort by Bytes nulls last
To see the count of events ingested per computer, use the following query:
| summarize count() by Computer | sort by count_ nulls last
To see the count of billable events ingested per computer, use the following query:
| summarize count() by Computer | sort by count_ nulls last
To see the count of billable data types from a specific computer, use the following query:
| where Computer == "computer name"
| summarize count() by tt | sort by count_ nulls last
Next steps
Read more about how Azure Monitor log data is stored.
Get a lesson on writing log queries.
Get a lesson on joining tables in log queries.
Azure Monitor log queries
Azure Monitor logs are built on Azure Data Explorer, and Azure Monitor log queries use a version of the same
Kusto query language. The Kusto query language documentation has all of the details for the language and
should be your primary resource for writing Azure Monitor log queries. This page provides links to other
resources for learning how to write queries and on differences with the Azure Monitor implementation of the
language.
NOTE
Getting started
Get started with Azure Monitor Log Analytics is a lesson for writing queries and working with results in the
Azure portal.
Get started with Azure Monitor log queries is a lesson for writing queries using Azure Monitor log data.
Concepts
Analyze log data in Azure Monitor gives a brief overview of log queries and describes how Azure Monitor log
data is structured.
Viewing and analyzing log data in Azure Monitor explains the portals where you create and run log queries.
Reference
Query language reference is the complete language reference for the Kusto query language.
Azure Monitor log query language differences describes differences between versions of the Kusto query
language.
Standard properties in Azure Monitor log records describes properties that are standard to all Azure Monitor
log data.
Perform cross-resource log queries in Azure Monitor describes how to write log queries that use data from
multiple Log Analytics workspaces and Application Insights applications.
Examples
Azure Monitor log query examples provides example queries using Azure Monitor log data.
Lessons
Working with strings in Azure Monitor log queries describes how to work with string data.
Working with date time values in Azure Monitor log queries describes how to work with date and time data.
Aggregations in Azure Monitor log queries and Advanced aggregations in Azure Monitor log queries describe
how to aggregate and summarize data.
Joins in Azure Monitor log queries describes how to join data from multiple tables.
Working with JSON and data Structures in Azure Monitor log queries describes how to parse json data.
Writing advanced log queries in Azure Monitor describes strategies for creating complex queries and reusing
code.
Creating charts and diagrams from Azure Monitor log queries describes how to visualize data from a log
query.
Cheatsheets
SQL to Azure Monitor log query assists users who are already familiar with SQL.
Splunk to Azure Monitor log query assists users who are already familiar with Splunk.
Next steps
Access the complete reference documentation for the Kusto query language.
Azure Monitor log query language differences
While logs in Azure Monitor is built on Azure Data Explorer and uses the same Kusto query language, the version
of the language does have some differences. This article identifies elements that are different between the version
of the language used for Data Explorer and the version used for Azure Monitor log queries.
NOTE
KQL elements not supported in Azure Monitor

The following sections describe elements of the Kusto query language that aren't supported by Azure Monitor.
Statements not supported in Azure Monitor
Alias
Query parameters
Functions not supported in Azure Monitor
cluster()
cursor_after()
cursor_before_or_at()
cursor_current(), current_cursor()
database()
current_principal()
extent_id()
extent_tags()
Operators not supported in Azure Monitor
Cross-Cluster Join
externaldata operator
Plugins not supported in Azure Monitor
Python plugin
sql_request plugin
Additional operators in Azure Monitor

The following operators support specific Azure Monitor features and are not available outside of Azure Monitor.
app()
workspace()
Next steps
Get references to different resources for writing Azure Monitor log queries.
Access the complete reference documentation for Kusto query language.
Useful operators in Azure Monitor log queries
The table below provides some common functions to use for different scenarios in Azure Monitor log queries.
Useful operators
CATEGORY RELEVANT ANALYTICS FUNCTION
Selection and Column aliases project , project-away , extend
Temporary tables and constants let scalar_alias_name = …;

let table_alias_name = … … … ;
Comparison and String Operators startswith , !startswith , has , !has

contains , !contains , containscs
hasprefix , !hasprefix , hassuffix , !hassuffix , in ,
!in
matches regex
== , =~ , != , !~
Common string functions strcat() , replace() , tolower() , toupper() ,

substring() , strlen()
Common math functions sqrt() , abs()

exp() , exp2() , exp10() , log() , log2() , log10() ,
pow()
gamma() , gammaln()
Parsing text extract() , extractjson() , parse , split()
Limiting output take , limit , top , sample
Date functions now() , ago()

datetime() , datepart() , timespan
startofday() , startofweek() , startofmonth() ,
startofyear()
endofday() , endofweek() , endofmonth() , endofyear()
dayofweek() , dayofmonth() , dayofyear()
getmonth() , getyear() , weekofyear() , monthofyear()
Grouping and aggregation summarize by

max() , min() , count() , dcount() , avg() , sum()
stddev() , countif() , dcountif() , argmax() ,
argmin()
percentiles() , percentile_array()
Joins and Unions join kind=leftouter , inner , rightouter , fullouter ,

leftanti
union
CATEGORY RELEVANT ANALYTICS FUNCTION
Sort, order sort , order
Dynamic object (JSON and array) parsejson()

makeset() , makelist()
split() , arraylength()
zip() , pack()
Logical operators and , or , iff(condition, value_t, value_f)

binary_and() , binary_or() , binary_not() ,
binary_xor()
Machine learning evaluate autocluster , basket , diffpatterns ,

extractcolumns
Next steps
Go through a lesson on the writing log queries in Azure Monitor.
Using functions in Azure Monitor log queries
To use a log query with another query you can save it as a function. This allows you to simplify complex queries by
breaking them into parts and allows you to reuse common code with multiple queries.
Create a function
Create a function with Log Analytics in the Azure portal by clicking Save and then providing the information in the
following table.
SETTING DESCRIPTION
Name Display name for the query in Query explorer.
Save as Function
Function Alias Short name to use the function in other queries. May not
contain spaces and must be unique.
Category A category to organize saved queries and functions in Query

explorer.
NOTE
A function in Azure Monitor cannot contain another function.
Use a function
Use a function by including its alias in another query. It can be used like any other table.
Example
The following sample query returns all missing security updates reported in the last day. Save this query as a
function with the alias security_updates_last_day.
Update
| where Classification == "Security Updates"
| where UpdateState == "Needed"
Create another query and reference the security_updates_last_day function to search for SQL -related needed
security updates.
security_updates_last_day | where Title contains "SQL"
Next steps
See other lessons for writing Azure Monitor log queries:
String operations
Joins
Charts
Transition from Log Analytics log search to Azure
Monitor logs
The log search in Log Analytics was recently replaced with a new experience for analyzing Azure Monitor logs. The
Log search page is currently still accessible through the Logs (classic) menu item in the Log Analytics
workspaces page in the Azure portal but will be removed February 15th, 2019. This article describes differences
between the two experiences to help you transition from log search.
Filter results of a query

In Log Search, a list of filters are displayed as search results are delivered. Select a filter and click Apply to run the
query with the selected filter.
In Azure Monitor logs, select Filter (preview ) to display filters. Click on the filter icon to display addition filters.
Select a filter and click Apply & Run to run the query with the selected filter.
Extract custom fields
In Log Search, you extract custom fields from the List view, where a field’s menu includes the action Extract fields
from Table.
In Azure Monitor logs, you extract custom fields from the table view. Expand a record by clicking the arrow to its
left then click the ellipsis to access the Extract fields action.
Functions and computer groups
To save a search in Log Search, select Saved searches and Add to provide a name, category, and query text.
Create a computer group by adding a function alias.
To save the current query in Azure Monitor logs, select Save. Change Save as to Function and provide a Function
Alias to create a function. Select Save this query as a computer group to use the function alias for a computer
group.
Saved queries
In Log Search, your saved queries are available through the action bar item Saved searches. In Azure Monitor
logs, access saved queries from Query Explorer.
Drill down on summarized rows

In Log Search, you can click on a row in a summarized query to launch another query that lists detailed records in
that row.
In Azure Monitor logs, you must modify the query to return these records. Expand one of the rows in the results
and click the + next to the value to add it to the query. Then comment out the summarize command and run the
query again.
Take action
In Log Search, you can start a runbook from a search result by selecting Take action.
In Azure Monitor logs, create an alert from the log query. Configure an action group with one or more actions that
will run in response to the alert.
Next steps
Learn more about the new Azure Monitor logs experience.
Work with strings in Azure Monitor log queries
NOTE
You should complete Get started with Azure Monitor Log Analytics and Getting started with Azure Monitor log queries
before completing this tutorial.
NOTE
You can work through this exercise in your own Log Analytics environment, or you can use our Demo environment, which
includes plenty of sample data.
This article describes how to edit, compare, search in and perform a variety of other operations on strings.
Each character in a string has an index number, according to its location. The first character is at index 0, the next
character is 1, and so on. Different string functions use index numbers as shown in the following sections. Many
of the following examples use the print command for to demonstrate string manipulation without using a specific
data source.
Strings and escaping them

String values are wrapped with either with single or double quote characters. Backslash (\) is used to escape
characters to the character following it, such as \t for tab, \n for newline, and " the quote character itself.
print "this is a 'string' literal in double \" quotes"
print 'this is a "string" literal in single \' quotes'
To prevent "\" from acting as an escape character, add "@" as a prefix to the string:
print @"C:\backslash\not\escaped\with @ prefix"
String comparisons
OPERATOR DESCRIPTION CASE-SENSITIVE EXAMPLE (YIELDS TRUE )
== Equals Yes "aBc" == "aBc"
!= Not equals Yes "abc" != "ABC"
=~ Equals No "abc" =~ "ABC"
!~ Not equals No "aBc" !~ "xyz"

has Right-hand-side is a whole No "North America" has

term in left-hand-side "america"
!has Right-hand-side isn't a full No "North America" !has

term in left-hand-side "amer"
has_cs Right-hand-side is a whole Yes "North America" has_cs

term in left-hand-side "America"
!has_cs Right-hand-side isn't a full Yes "North America" !has_cs

term in left-hand-side "amer"
hasprefix Right-hand-side is a term No "North America"

prefix in left-hand-side hasprefix "ame"
!hasprefix Right-hand-side isn't a term No "North America"

prefix in left-hand-side !hasprefix "mer"
hasprefix_cs Right-hand-side is a term Yes "North America"

prefix in left-hand-side hasprefix_cs "Ame"
!hasprefix_cs Right-hand-side isn't a term Yes "North America"

prefix in left-hand-side !hasprefix_cs "CA"
hassuffix Right-hand-side is a term No "North America"

suffix in left-hand-side hassuffix "ica"
!hassuffix Right-hand-side isn't a term No "North America"

suffix in left-hand-side !hassuffix "americ"
hassuffix_cs Right-hand-side is a term Yes "North America"

suffix in left-hand-side hassuffix_cs "ica"
!hassuffix_cs Right-hand-side isn't a term Yes "North America"

suffix in left-hand-side !hassuffix_cs "icA"
contains Right-hand-side occurs as a No "FabriKam" contains

subsequence of left-hand- "BRik"
side
!contains Right-hand-side doesn't No "Fabrikam" !contains

occur in left-hand-side "xyz"
contains_cs Right-hand-side occurs as a Yes "FabriKam" contains_cs

subsequence of left-hand- "Kam"
side
!contains_cs Right-hand-side doesn't Yes "Fabrikam" !contains_cs

occur in left-hand-side "Kam"
startswith Right-hand-side is an initial No "Fabrikam" startswith

subsequence of left-hand- "fab"
side
!startswith Right-hand-side isn't an No "Fabrikam" !startswith

initial subsequence of left- "kam"
hand-side
startswith_cs Right-hand-side is an initial Yes "Fabrikam"

subsequence of left-hand- startswith_cs "Fab"
side
!startswith_cs Right-hand-side isn't an Yes "Fabrikam"

initial subsequence of left- !startswith_cs "fab"
hand-side
endswith Right-hand-side is a closing No "Fabrikam" endswith

side
!endswith Right-hand-side isn't a No "Fabrikam" !endswith

closing subsequence of left- "brik"
hand-side
endswith_cs Right-hand-side is a closing Yes "Fabrikam" endswith

side
!endswith_cs Right-hand-side isn't a Yes "Fabrikam" !endswith

closing subsequence of left- "brik"
hand-side
matches regex left-hand-side contains a Yes "Fabrikam" matches

match for Right-hand-side regex "b.*k"
in Equals to one of the Yes "abc" in ("123", "345",

elements "abc")
!in Not equals to any of the Yes "bca" !in ("123",

elements "345", "abc")
countof
Counts occurrences of a substring in a string. Can match plain strings or use regex. Plain string matches may
overlap while regex matches do not.
Syntax
countof(text, search [, kind])
Arguments:
text - The input string
search - Plain string or regular expression to match inside text.
kind - normal | regex (default: normal).
Returns
The number of times that the search string can be matched in the container. Plain string matches may overlap
while regex matches do not.
Examples
Plain string matches
print countof("The cat sat on the mat", "at"); //result: 3

print countof("aaa", "a"); //result: 3
print countof("aaaa", "aa"); //result: 3 (not 2!)
print countof("ababa", "ab", "normal"); //result: 2
print countof("ababa", "aba"); //result: 2
Regex matches
print countof("The cat sat on the mat", @"\b.at\b", "regex"); //result: 3

print countof("ababa", "aba", "regex"); //result: 1
print countof("abcabc", "a.c", "regex"); // result: 2
extract
Gets a match for a regular expression from a given string. Optionally also converts the extracted substring to the
specified type.
Syntax
extract(regex, captureGroup, text [, typeLiteral])
Arguments
regex - A regular expression.
captureGroup - A positive integer constant indicating the capture group to extract. 0 for the entire match, 1 for
the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parentheses.
text - A string to search.
typeLiteral - An optional type literal (for example, typeof(long)). If provided, the extracted substring is
converted to this type.
Returns
The substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If
there's no match, or the type conversion fails, return null.
Examples
The following example extracts the last octet of ComputerIP from a heartbeat record:
Heartbeat
| where ComputerIP != ""
| take 1
| project ComputerIP, last_octet=extract("([0-9]*$)", 1, ComputerIP)
The following example extracts the last octet, casts it to a real type (number) and calculates the next IP value
Heartbeat
| where ComputerIP != ""
| take 1
| extend last_octet=extract("([0-9]*$)", 1, ComputerIP, typeof(real))
| extend next_ip=(last_octet+1)%255
| project ComputerIP, last_octet, next_ip
In the example below, the string Trace is searched for a definition of "Duration". The match is cast to real and
multiplied by a time constant (1 s) which casts Duration to type timespan.
let Trace="A=12, B=34, Duration=567, ...";

print Duration = extract("Duration=([0-9.]+)", 1, Trace, typeof(real)); //result: 567
print Duration_seconds = extract("Duration=([0-9.]+)", 1, Trace, typeof(real)) * time(1s); //result:
00:09:27
isempty, isnotempty, notempty

isempty returns true if the argument is an empty string or null (see also isnull).
isnotempty returns true if the argument isn't an empty string or a null (see also isnotnull). alias: notempty.
Syntax
isempty(value)
isnotempty(value)
Examples
print isempty(""); // result: true
print isempty("0"); // result: false
print isempty(0); // result: false
print isempty(5); // result: false
Heartbeat | where isnotempty(ComputerIP) | take 1 // return 1 Heartbeat record in which ComputerIP isn't
empty
parseurl
Splits a URL into its parts (protocol, host, port, etc.), and returns a dictionary object containing the parts as
strings.
Syntax
parseurl(urlstring)
Examples
print parseurl("http://user:pass@contoso.com/icecream/buy.aspx?a=1&b=2#tag")
The outcome will be:

{
"Scheme" : "http",
"Host" : "contoso.com",
"Port" : "80",
"Path" : "/icecream/buy.aspx",
"Username" : "user",
"Password" : "pass",
"Query Parameters" : {"a":"1","b":"2"},
"Fragment" : "tag"
}
replace
Replaces all regex matches with another string.
Syntax
replace(regex, rewrite, input_text)
Arguments
regex - The regular expression to match by. It can contain capture groups in '('parentheses')'.
rewrite - The replacement regex for any match made by matching regex. Use \0 to refer to the whole match,
\1 for the first capture group, \2, and so on for subsequent capture groups.
input_text - The input string to search in.
Returns
The text after replacing all matches of regex with evaluations of rewrite. Matches don't overlap.
Examples
SecurityEvent
| take 1
| project Activity
| extend replaced = replace(@"(\d+) -", @"Activity ID \1: ", Activity)
Can have the following results:
ACTIVITY REPLACED
4663 - An attempt was made to access an object Activity ID 4663: An attempt was made to access an object.
split
Splits a given string according to a specified delimiter, and returns an array of the resulting substrings.
Syntax
split(source, delimiter [, requestedIndex])
Arguments:
source - The string to be split according to the specified delimiter.
delimiter - The delimiter that will be used in order to split the source string.
requestedIndex - An optional zero-based index. If provided, the returned string array will hold only that item
(if exists).
Examples
print split("aaa_bbb_ccc", "_"); // result: ["aaa","bbb","ccc"]

print split("aa_bb", "_"); // result: ["aa","bb"]
print split("aaa_bbb_ccc", "_", 1); // result: ["bbb"]
print split("", "_"); // result: [""]
print split("a__b", "_"); // result: ["a","","b"]
print split("aabbcc", "bb"); // result: ["aa","cc"]
strcat
Concatenates string arguments (supports 1-16 arguments).
Syntax
strcat("string1", "string2", "string3")
Examples
print strcat("hello", " ", "world") // result: "hello world"
strlen
Returns the length of a string.
Syntax
strlen("text_to_evaluate")
Examples
print strlen("hello") // result: 5
substring
Extracts a substring from a given source string, starting at the specified index. Optionally, the length of the
requested substring can be specified.
Syntax
substring(source, startingIndex [, length])
Arguments:
source - The source string that the substring will be taken from.
startingIndex - The zero-based starting character position of the requested substring.
length - An optional parameter that can be used to specify the requested length of the returned substring.
Examples
print substring("abcdefg", 1, 2); // result: "bc"
print substring("123456", 1); // result: "23456"
print substring("123456", 2, 2); // result: "34"
print substring("ABCD", 0, 2); // result: "AB"
tolower, toupper
Converts a given string to all lower or upper case.
Syntax
tolower("value")
toupper("value")
Examples
print tolower("HELLO"); // result: "hello"

print toupper("hello"); // result: "HELLO"
Next steps
Continue with the advanced tutorials:
Charts and diagrams
Working with JSON and data structures
Joins - cross analysis
Working with date time values in Azure Monitor log
queries
NOTE
You should complete Get started with the Analytics portal and Getting started with queries before completing this lesson.
NOTE
This article describes how to work with date and time data in Azure Monitor log queries.
Date time basics

The Kusto query language has two main data types associated with dates and times: datetime and timespan. All
dates are expressed in UTC. While multiple datetime formats are supported, the ISO8601 format is preferred.
Timespans are expressed as a decimal followed by a time unit:
SHORTHAND TIME UNIT
d day
h hour
m minute
s second
ms millisecond
microsecond microsecond
tick nanosecond
Datetimes can be created by casting a string using the todatetime operator. For example, to review the VM
heartbeats sent in a specific timeframe, use the between operator to specify a time range.
Heartbeat
| where TimeGenerated between(datetime("2018-06-30 22:46:42") .. datetime("2018-07-01 00:57:27"))
Another common scenario is comparing a datetime to the present. For example, to see all heartbeats over the last
two minutes, you can use the now operator together with a timespan that represents two minutes:
Heartbeat
| where TimeGenerated > now() - 2m
A shortcut is also available for this function:
Heartbeat
| where TimeGenerated > now(-2m)
The shortest and most readable method though is using the ago operator:
Heartbeat
Suppose that instead of knowing the start and end time, you know the start time and the duration. You can
rewrite the query as follows:
let startDatetime = todatetime("2018-06-30 20:12:42.9");

let duration = totimespan(25m);
Heartbeat
| where TimeGenerated between(startDatetime .. (startDatetime+duration) )
| extend timeFromStart = TimeGenerated - startDatetime
Converting time units

You may want to express a datetime or timespan in a time unit other than the default. For example, if you're
reviewing error events from the last 30 minutes and need a calculated column showing how long ago the event
happened:
Event
| extend timeAgo = now() - TimeGenerated
The timeAgo column holds values such as: "00:09:31.5118992", meaning they're formatted as hh:mm:ss.fffffff. If
you want to format these values to the numver of minutes since the start time, divide that value by "1 minute":
Event
| extend timeAgo = now() - TimeGenerated
| extend timeAgoMinutes = timeAgo/1m
Aggregations and bucketing by time intervals

Another common scenario is the need to obtain statistics over a certain time period in a particular time grain. For
this scenario, a bin operator can be used as part of a summarize clause.
Use the following query to get the number of events that occurred every 5 minutes during the last half hour:
Event
| summarize events_count=count() by bin(TimeGenerated, 5m)
This query produces the following table:
TIMEGENERATED(UTC) EVENTS_COUNT
2018-08-01T09:30:00.000 54
2018-08-01T09:35:00.000 41
2018-08-01T09:40:00.000 42
2018-08-01T09:45:00.000 41
2018-08-01T09:50:00.000 41
2018-08-01T09:55:00.000 16
Another way to create buckets of results is to use functions, such as startofday :
Event
| summarize events_count=count() by startofday(TimeGenerated)
This query produces the following results:
TIMESTAMP COUNT_
2018-07-28T00:00:00.000 7,136
2018-07-29T00:00:00.000 12,315
2018-07-30T00:00:00.000 16,847
2018-07-31T00:00:00.000 12,616
2018-08-01T00:00:00.000 5,416
Time zones
Since all datetime values are expressed in UTC, it's often useful to convert these values into the local timezone.
For example, use this calculation to convert UTC to PST times:
Event
| extend localTimestamp = TimeGenerated - 8h
Related functions
CATEGORY FUNCTION
Convert data types todatetime totimespan
Round value to bin size bin

CATEGORY FUNCTION
Get a specific date or time ago now
Get part of value datetime_part getmonth monthofyear getyear dayofmonth

dayofweek dayofyear weekofyear
Get a relative date value endofday endofweek endofmonth endofyear startofday

startofweek startofmonth startofyear
Next steps
See other lessons for using the Kusto query language with Azure Monitor log data:
String operations
Joins
Charts
Aggregations in Azure Monitor log queries
NOTE
You should complete Get started with the Analytics portal and Getting started with queries before completing this lesson.
NOTE
This article describes aggregation functions in Azure Monitor log queries that offer useful ways to analyze your
data. These functions all work with the summarize operator that produces a table with aggregated results of the
input table.
Counts
count
Count the number of rows in the result set after any filters are applied. The following example returns the total
number of rows in the Perf table from the last 30 minutes. The result is returned in a column named count_
unless you assign it a specific name:
Perf
| summarize count()
Perf
| summarize num_of_records=count()
A timechart visualization can be useful to see a trend over time:
Perf
| summarize count() by bin(TimeGenerated, 5m)
| render timechart
The output from this example shows the perf record count trendline in 5 minutes' intervals:
dcount, dcountif
Use dcount and dcountif to count distinct values in a specific column. The following query evaluates how
many distinct computers sent heartbeats in the last hour:
Heartbeat
| summarize dcount(Computer)
To count only the Linux computers that sent heartbeats, use dcountif :
Heartbeat
| summarize dcountif(Computer, OSType=="Linux")
Evaluating subgroups
To perform a count or other aggregations on subgroups in your data, use the by keyword. For example, to
count the number of distinct Linux computers that sent heartbeats in each country/region:
Heartbeat
| summarize distinct_computers=dcountif(Computer, OSType=="Linux") by RemoteIPCountry
REMOTEIPCOUNTRY DISTINCT_COMPUTERS
United States 19
Canada 3
Ireland 0
United Kingdom 0
Netherlands 2
To analyze even smaller subgroups of your data, add additional column names to the by section. For example,
you might want to count the distinct computers from each country/region per OSType:
Heartbeat
| summarize distinct_computers=dcountif(Computer, OSType=="Linux") by RemoteIPCountry, OSType
Percentiles and Variance
When evaluating numerical values, a common practice is to average them using summarize avg(expression) .
Averages are affected by extreme values that characterize only a few cases. To address that issue, you can use
less sensitive functions such as median or variance .
Percentile
To find the median value, use the percentile function with a value to specify the percentile:
Perf
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| summarize percentiles(CounterValue, 50) by Computer
You can also specify different percentiles to get an aggregated result for each:
Perf
| summarize percentiles(CounterValue, 25, 50, 75, 90) by Computer
This might show that some computer CPUs have similar median values, but while some are steady around the
median, other computers have reported much lower and higher CPU values meaning they experienced spikes.
Variance
To directly evaluate the variance of a value, use the standard deviation and variance methods:
Perf
| summarize stdev(CounterValue), variance(CounterValue) by Computer
A good way to analyze the stability of the CPU usage is to combine stdev with the median calculation:
Perf
| summarize stdev(CounterValue), percentiles(CounterValue, 50) by Computer
String operations
Joins
Charts
Advanced aggregations in Azure Monitor log
queries
NOTE
You should complete Aggregations in Azure Monitor queries before completing this lesson.
NOTE
This article describes some of the more advanced aggregation options available to Azure Monitor queries.
Generating lists and sets

You can use makelist to pivot data by the order of values in a particular column. For example, you may want to
explore the most common order events take place on your machines. You can essentially pivot the data by the
order of EventIDs on each machine.
Event
| order by TimeGenerated desc
| summarize makelist(EventID) by Computer
COMPUTER LIST_EVENTID
computer1 [704,701,1501,1500,1085,704,704,701]
computer2 [326,105,302,301,300,102]
... ...
makelist generates a list in the order that data was passed into it. To sort events from oldest to newest, use asc
in the order statement instead of desc .
It is also useful to create a list of just distinct values. This is called a Set and can be generated with makeset :
Event
| order by TimeGenerated desc
| summarize makeset(EventID) by Computer
computer1 [704,701,1501,1500,1085]
computer2 [326,105,302,301,300,102]
... ...
Like makelist , makeset also works with ordered data and will generate the arrays based on the order of the
rows that are passed into it.
Expanding lists
The inverse operation of makelist or makeset is mvexpand , which expands a list of values to separate rows. It
can expand across any number of dynamic columns, both JSON and array. For example, you could check the
Heartbeat table for solutions sending data from computers that sent a heartbeat in the last hour:
Heartbeat
| project Computer, Solutions
COMPUTER SOLUTIONS
computer1 "security", "updates", "changeTracking"
computer2 "security", "updates"
computer3 "antiMalware", "changeTracking"
... ...
Use mvexpand to show each value in a separate row instead of a comma-separated list:
Heartbeat
| project Computer, split(Solutions, ",")
| mvexpand Solutions
COMPUTER SOLUTIONS
computer1 "security"
computer1 "updates"
computer1 "changeTracking"
computer2 "security"
computer2 "updates"
computer3 "antiMalware"
computer3 "changeTracking"
COMPUTER SOLUTIONS
... ...
You could then use makelist again to group items together, and this time see the list of computers per solution:
Heartbeat
| project Computer, split(Solutions, ",")
| mvexpand Solutions
| summarize makelist(Computer) by tostring(Solutions)
SOLUTIONS LIST_COMPUTER
"security" ["computer1", "computer2"]
"updates" ["computer1", "computer2"]
"changeTracking" ["computer1", "computer3"]
"antiMalware" ["computer3"]
... ...
Handling missing bins

A useful application of mvexpand is the need to fill default values in for missing bins. For example, suppose you're
looking for the uptime of a particular machine by exploring its heartbeat. You also want to see the source of the
heartbeat which is in the category column. Normally, we would use a simple summarize statement as follows:
Heartbeat
| summarize count() by Category, bin(TimeGenerated, 1h)
CATEGORY TIMEGENERATED COUNT_
Direct Agent 2017-06-06T17:00:00Z 15
Direct Agent 2017-06-06T18:00:00Z 60
Direct Agent 2017-06-06T20:00:00Z 55
Direct Agent 2017-06-06T21:00:00Z 57
Direct Agent 2017-06-06T22:00:00Z 60
... ... ...
In these results though the bucket associated with "2017-06-06T19:00:00Z" is missing because there isn't any
heartbeat data for that hour. Use the make-series function to assign a default value to empty buckets. This will
generate a row for each category with two extra array columns, one for values, and one for matching time
buckets:
Heartbeat
| make-series count() default=0 on TimeGenerated in range(ago(1d), now(), 1h) by Category
CATEGORY COUNT_ TIMEGENERATED
Direct Agent [15,60,0,55,60,57,60,...] ["2017-06-

06T17:00:00.0000000Z","2017-06-
06T18:00:00.0000000Z","2017-06-
06T19:00:00.0000000Z","2017-06-
06T20:00:00.0000000Z","2017-06-
06T21:00:00.0000000Z",...]
... ... ...
The third element of the count_ array is a 0 as expected, and there is a matching timestamp of "2017-06-
06T19:00:00.0000000Z" in the TimeGenerated array. This array format is difficult to read though. Use mvexpand
to expand the arrays and produce the same format output as generated by summarize :
Heartbeat
| make-series count() default=0 on TimeGenerated in range(ago(1d), now(), 1h) by Category
| mvexpand TimeGenerated, count_
| project Category, TimeGenerated, count_
CATEGORY TIMEGENERATED COUNT_
Direct Agent 2017-06-06T17:00:00Z 15
Direct Agent 2017-06-06T18:00:00Z 60
Direct Agent 2017-06-06T19:00:00Z 0
Direct Agent 2017-06-06T20:00:00Z 55
Direct Agent 2017-06-06T21:00:00Z 57
Direct Agent 2017-06-06T22:00:00Z 60
... ... ...
Narrowing results to a set of elements: let , makeset , toscalar , in

A common scenario is to select the names of some specific entities based on a set of criteria and then filter a
different data set down to that set of entities. For example you might find computers that are known to have
missing updates and identify IPs that these computers called out to:
let ComputersNeedingUpdate = toscalar(

Update
| summarize makeset(Computer)
| project set_Computer
);
WindowsFirewall
| where Computer in (ComputersNeedingUpdate)
Next steps
String operations
Joins
Charts
Joins in Azure Monitor log queries
NOTE
You should complete Get started with Azure Monitor Log Analytics and Azure Monitor log queries before completing this
lesson.
NOTE
Joins allow you to analyze data from multiple tables, in the same query. They merge the rows of two data sets by
matching values of specified columns.
SecurityEvent
| where EventID == 4624 // sign-in events
| project Computer, Account, TargetLogonId, LogonTime=TimeGenerated
| join kind= inner (
SecurityEvent
| where EventID == 4634 // sign-out events
| project TargetLogonId, LogoffTime=TimeGenerated
) on TargetLogonId
| extend Duration = LogoffTime-LogonTime
| project-away TargetLogonId1
| top 10 by Duration desc
In this example, the first dataset filters for all sign-in events. This is joined with a second dataset that filters for all
sign-out events. The projected columns are Computer, Account, TargetLogonId, and TimeGenerated. The
datasets are correlated by a shared column, TargetLogonId. The output is a single record per correlation, which
has both the sign-in and sign-out time.
If both datasets have columns with the same names, the columns of the right-side dataset would be given an
index number, so in this example the results would show TargetLogonId with values from the left-side table and
TargetLogonId1 with values from the right-side table. In this case, the second TargetLogonId1 column was
removed by using the project-away operator.
NOTE
To improve performance, keep only the relevant columns of the joined data-sets, using the project operator.
Use the following syntax to join two datasets and the joined key has a different name between the two tables:
Table1
| join ( Table2 )
on $left.key1 == $right.key2
Lookup Tables
A common use of joins is using static mapping of values using datatable that can help in transforming the
results into more presentable way. For example, to enrich the security event data with the event name for each
event ID.
let DimTable = datatable(EventID:int, eventName:string)

[
4625, "Account activity",
4688, "Process action",
4658, "The handle to an object was closed",
4656, "A handle to an object was requested",
4690, "An attempt was made to duplicate a handle to an object",
4663, "An attempt was made to access an object",
5061, "Cryptographic operation",
5058, "Key file operation"
];
SecurityEvent
| join kind = inner
DimTable on EventID
| summarize count() by eventName
Join kinds
Specify the type of join with the kind argument. Each type performs a different match between the records of the
given tables as described in the following table.
JOIN TYPE DESCRIPTION
innerunique This is the default join mode. First the values of the matched
column on the left table are found, and duplicate values are
removed. Then the set of unique values is matched against
the right table.
inner Only matching records in both tables are included in the

results.
leftouter All records in the left table and matching records in the right
table are included in the results. Unmatched output
properties contain nulls.
leftanti Records from the left side that do not have matches from the
right are included in the results. The results table has only
columns from the left table.
JOIN TYPE DESCRIPTION
leftsemi Records from the left side that have matches from the right
are included in the results. The results table has only columns
from the left table.
Best practices
Consider the following points for optimal performance:
Use a time filter on each table to reduce the records that must be evaluated for the join.
Use where and project to reduce the numbers of rows and columns in the input tables before the join.
If one table is always smaller than the other, use it as the left side of the join.
Next steps
See other lessons for using Azure Monitor log queries:
String operations
Charts
Working with JSON and data Structures in Azure
Monitor log queries
NOTE
You should complete Get started with Azure Monitor Log Analytics and Getting started with Azure Monitor log queries
before completing this lesson.
NOTE
Nested objects are objects that contain other objects in an array or a map of key-value pairs. These objects are
represented as JSON strings. This article describes how JSON is used to retrieve data and analyze nested
objects.
Working with JSON strings

Use extractjson to access a specific JSON element in a known path. This function requires a path expression
that uses the following conventions.
$ to refer to the root folder
Use the bracket or dot notation to refer to indexes and elements as illustrated in the following examples.
Use brackets for indexes and dots to separate elements:
let hosts_report='{"hosts": [{"location":"North_DC", "status":"running", "rate":5},{"location":"South_DC",

"status":"stopped", "rate":3}]}';
print hosts_report
| extend status = extractjson("$.hosts[0].status", hosts_report)
This is the same result using only the brackets notation:
let hosts_report='{"hosts": [{"location":"North_DC", "status":"running", "rate":5},{"location":"South_DC",

"status":"stopped", "rate":3}]}';
print hosts_report
| extend status = extractjson("$['hosts'][0]['status']", hosts_report)
If there is only one element, you can use only the dot notation:
let hosts_report='{"location":"North_DC", "status":"running", "rate":5}';

print hosts_report
| extend status = hosts_report.status
Working with objects

parsejson
To access multiple elements in your json structure, it's easier to access it as a dynamic object. Use parsejson to
cast text data to a dynamic object. Once converted to a dynamic type, additional functions can be used to analyze
the data.
let hosts_object = parsejson('{"hosts": [{"location":"North_DC", "status":"running", "rate":5},

{"location":"South_DC", "status":"stopped", "rate":3}]}');
print hosts_object
| extend status0=hosts_object.hosts[0].status, rate1=hosts_object.hosts[1].rate
arraylength
Use arraylength to count the number of elements in an array:

print hosts_object
| extend hosts_num=arraylength(hosts_object.hosts)
mvexpand
Use mvexpand to break the properties of an object into separate rows.

print hosts_object
| mvexpand hosts_object.hosts[0]
buildschema
Use buildschema to get the schema that admits all values of an object:

print hosts_object
| summarize buildschema(hosts_object)
The output is a schema in JSON format:

{
"hosts":
{
"indexer":
{
"location": "string",
"rate": "int",
"status": "string"
}
}
}
This output describes the names of the object fields and their matching data types.
Nested objects may have different schemas such as in the following example:

{"status":"stopped", "rate":"3", "range":100}]}');
print hosts_object
| summarize buildschema(hosts_object)
Next steps
See other lessons for using log queries in Azure Monitor:
String operations
Joins
Charts
Writing advanced queries in Azure Monitor
NOTE
You should complete Get started with Azure Monitor Log Analytics and Getting started with queries before completing this
lesson.
NOTE
Reusing code with let

Use let to assign results to a variable, and refer to it later in the query:
// get all events that have level 2 (indicates warning level)

let warning_events=
Event
| where EventLevel == 2;
// count the number of warning events per computer
warning_events
| summarize count() by Computer
You can also assign constant values to variables. This supports a method to set up parameters for the fields that
you need to change every time you execute the query. Modify those parameters as needed. For example, to
calculate the free disk space and free memory (in percentiles), in a given time window:
let startDate = datetime(2018-08-01T12:55:02);

let endDate = datetime(2018-08-02T13:21:35);
let FreeDiskSpace =
Perf
| where TimeGenerated between (startDate .. endDate)
| where ObjectName=="Logical Disk" and CounterName=="Free Megabytes"
| summarize percentiles(CounterValue, 50, 75, 90, 99);
let FreeMemory =
Perf
| where TimeGenerated between (startDate .. endDate)
| where ObjectName=="Memory" and CounterName=="Available MBytes Memory"
| summarize percentiles(CounterValue, 50, 75, 90, 99);
union FreeDiskSpace, FreeMemory
This makes it easy to change the start of end time the next time you run the query.
Local functions and parameters
Use let statements to create functions that can be used in the same query. For example, define a function that
takes a datetime field (in the UTC format) and converts it to a standard US format.
let utc_to_us_date_format = (t:datetime)
{
strcat(getmonth(t), "/", dayofmonth(t),"/", getyear(t), " ",
bin((t-1h)%12h+1h,1s), iff(t%24h<12h, "AM", "PM"))
};
Event
| extend USTimeGenerated = utc_to_us_date_format(TimeGenerated)
| project TimeGenerated, USTimeGenerated, Source, Computer, EventLevel, EventData
Print
print will return a table with a single column and a single row, showing the result of a calculation. This is often
used in cases where you need a simple calculation. For example, to find the current time in PST and add a column
with EST:
print nowPst = now()-8h

| extend nowEst = nowPst+3h
Datatable
datatable allows you to define a set of data. You provide a schema and a set of values and then pipe the table
into any other query elements. For example to create a table of RAM usage and calculate their average value per
hour:
datatable (TimeGenerated: datetime, usage_percent: double)

[
"2018-06-02T15:15:46.3418323Z", 15.5,
"2018-06-02T15:45:43.1561235Z", 20.2,
"2018-06-02T16:16:49.2354895Z", 17.3,
"2018-06-02T16:46:44.9813459Z", 45.7,
"2018-06-02T17:15:41.7895423Z", 10.9,
"2018-06-02T17:44:23.9813459Z", 24.7,
"2018-06-02T18:14:59.7283023Z", 22.3,
"2018-06-02T18:45:12.1895483Z", 25.4
]
| summarize avg(usage_percent) by bin(TimeGenerated, 1h)
Datatable constructs are also very useful when creating a lookup table. For example, to map table data such as
event IDs from the SecurityEvent table, to event types listed elsewhere, create a lookup table with the event types
using datatable and join this datatable with SecurityEvent data:
let eventCodes = datatable (EventID: int, EventType:string)
[
4672, "Access",
4799, "Access management",
5059, "Key operation",
4648, "A logon was attempted using explicit credentials",
4662, "Other",
4904, "Security event management",
4905, "Security event management",
];
SecurityEvent
| join kind=leftouter (
eventCodes
) on EventID
| project TimeGenerated, Account, AccountType, Computer, EventType
Next steps
String operations
Joins
Charts
Creating charts and diagrams from Azure Monitor
log queries
NOTE
You should complete Advanced aggregations in Azure Monitor log queries before completing this lesson.
NOTE
This article describes various visualizations in Azure Monitor to display your log data in different ways.
Charting the results

Start by reviewing how many computers there are per operating system, during the past hour:
Heartbeat
| summarize count(Computer) by OSType
By default, results display as a table:
To get a better view, select Chart, and choose the Pie option to visualize the results:
Timecharts
Show the average, 50th and 95th percentiles of processor time in bins of 1 hour. The query generates multiple
series and you can then select which series to show in the time chart:
Perf
| where CounterName == "% Processor Time"
| summarize avg(CounterValue), percentiles(CounterValue, 50, 95) by bin(TimeGenerated, 1h)
Select the Line chart display option:
Reference line
A reference line can help you easily identifying if the metric exceeded a specific threshold. To add a line to a
chart, extend the dataset with a constant column:
Perf
| summarize avg(CounterValue), percentiles(CounterValue, 50, 95) by bin(TimeGenerated, 1h)
| extend Threshold = 20
Multiple dimensions
Multiple expressions in the by clause of summarize create multiple rows in the results, one for each
combination of values.
SecurityEvent
| summarize count() by tostring(EventID), AccountType, bin(TimeGenerated, 1h)
When you view the results as a chart, it uses the first column from the by clause. The following example shows
a stacked column chart using the EventID. Dimensions must be of string type, so in this example the EventID is
being cast to string.
You can switch between by selecting the dropdown with the column name.
Next steps
String operations
Joins
Search queries in Azure Monitor logs
Azure Monitor log queries can start with either a table name or a search command. This tutorial covers search-
based queries. There are advantages to each method.
Table-based queries start by scoping the query and therefore tend to be more efficient than search queries. Search
queries are less structured which makes them the better choice when searching for a specific value across columns
or tables. search can scan all columns in a given table, or in all tables, for the specified value. The amount of data
being processed could be enormous, which is why these queries could take longer to complete and might return
very large result sets.
Search a term
The search command is typically used to search a specific term. In the following example, all columns in all tables
are scanned for the term "error":
search "error"
| take 100
While they're easy to use, unscoped queries like the one showed above are not efficient and are likely to return
many irrelevant results. A better practice would be to search in the relevant table, or even a specific column.
Table scoping
To search a term in a specific table, add in (table-name) just after the search operator:

| take 100
or in multiple tables:
search in (Event, SecurityEvent) "error"

| take 100
Table and column scoping

By default, search will evaluate all columns in the data set. To search only a specific column, use this syntax:
search in (Event) Source:"error"

| take 100
TIP
If you use == instead of : , the results would include records in which the Source column has the exact value "error", and
in this exact case. Using ':' will include records where Source has values such as "error code 404" or "Error".
Case-sensitivity
By default, term search is case-insensitive, so searching "dns" could yield results such as "DNS", "dns", or "Dns". To
make the search case-sensitive, use the kind option:
search kind=case_sensitive in (Event) "DNS"

| take 100
Use wild cards

The search command supports wild cards, at the beginning, end or middle of a term.
To search terms that start with "win":
search in (Event) "win*"

| take 100
To search terms that end with ".com":
search in (Event) "*.com"

| take 100
To search terms that contain "www":
search in (Event) "*www*"

| take 100
To search terms that starts with "corp" and ends in ".com", such as "corp.mydomain.com""
search in (Event) "corp*.com"

| take 100
You can also get everything in a table by using just a wild card: search in (Event) * , but that would be the same
as writing just Event .
TIP
While you can use search * to get every column from every table, it's recommended that you always scope your queries
to specific tables. Unscoped queries may take a while to complete and might return too many results.
Add and / or to search queries

Use and to search for records that contain multiple terms:
search in (Event) "error" and "register"

| take 100
Use or to get records that contain at least one of the terms:
search in (Event) "error" or "register"

| take 100
If you have multiple search conditions, you can combine them into the same query using parentheses:
search in (Event) "error" and ("register" or "marshal*")
| take 100
The results of this example would be records that contain the term "error" and also contain either "register" or
something that starts with "marshal".
Pipe search queries

Just like any other command, search can be piped so search results can be filtered, sorted, and aggregated. For
example, to get the number of Event records that contain "win":
search in (Event) "win"

| count
Next steps
See further tutorials on the Kusto query language site.
SQL to Azure Monitor log query cheat sheet
The table below helps users who are familiar with SQL to learn the Kusto query language to write log queries in
Azure Monitor. Have a look at the T-SQL command for solving common scenarios and the equivalent in an Azure
Monitor log query.
SQL to Azure Monitor

DESCRIPTION SQL QUERY AZURE MONITOR LOG QUERY
Select all data from a table SELECT * FROM dependencies dependencies
Select specific columns from a table SELECT name, resultCode FROM dependencies
dependencies | project name, resultCode
Select 100 records from a table SELECT TOP 100 * FROM dependencies
dependencies | take 100
Null evaluation SELECT * FROM dependencies WHERE dependencies

resultCode IS NOT NULL | where isnotnull(resultCode)
String comparison: equality SELECT * FROM dependencies WHERE dependencies

name = "abcde" | where name == "abcde"
String comparison: substring SELECT * FROM dependencies WHERE dependencies

name like "%bcd%" | where name contains "bcd"
String comparison: wildcard SELECT * FROM dependencies WHERE dependencies

name like "abc%" | where name startswith "abc"
Date comparison: last 1 day SELECT * FROM dependencies WHERE dependencies

timestamp > getdate()-1 | where timestamp > ago(1d)
Date comparison: date range SELECT * FROM dependencies WHERE dependencies

timestamp BETWEEN '2016-10-01' | where timestamp between
AND '2016-11-01' (datetime(2016-10-01) ..
datetime(2016-10-01))
Boolean comparison SELECT * FROM dependencies WHERE dependencies

!(success) | where success == "False"
Sort SELECT name, timestamp FROM dependencies

dependencies ORDER BY timestamp | order by timestamp asc
asc
Distinct SELECT DISTINCT name, type FROM dependencies

dependencies | summarize by name, type
Grouping, Aggregation SELECT name, AVG(duration) FROM dependencies

dependencies GROUP BY name | summarize avg(duration) by name
DESCRIPTION SQL QUERY AZURE MONITOR LOG QUERY
Column aliases, Extend SELECT operation_Name as Name, dependencies

AVG(duration) as AvgD FROM | summarize AvgD=avg(duration) by
dependencies GROUP BY name operation_Name
| project Name=operation_Name,
AvgD
Top n records by measure SELECT TOP 100 name, COUNT(*) as dependencies

Count FROM dependencies GROUP BY | summarize Count=count() by name
name ORDER BY Count asc | top 100 by Count asc
Union SELECT * FROM dependencies UNION union dependencies, exceptions

SELECT * FROM exceptions
Union: with conditions SELECT * FROM dependencies WHERE dependencies

value > 4 UNION SELECT * FROM | where value > 4
exceptions WHERE value < 5 | union (exceptions
| where value < 5)
Join SELECT * FROM dependencies JOIN dependencies

exceptions ON | join (exceptions) on
dependencies.operation_Id = operation_Id == operation_Id
exceptions.operation_Id
Next steps
Go through the lessons on writing log queries in Azure Monitor.
Splunk to Azure Monitor log query
This article is intended to assist users who are familiar with Splunk to learn the Kusto query language to write log
queries in Azure Monitor. Direct comparisons are made between the two to understand key differences and also
similarities where you can leverage your existing knowledge.
Structure and concepts

The following table compares concepts and data structures between Splunk and Azure Monitor logs.
CONCEPT SPLUNK AZURE MONITOR COMMENT
Deployment unit cluster cluster Azure Monitor allows

arbitrary cross cluster queries.
Splunk does not.
Data caches buckets Caching and retention policies Controls the period and
caching level for the data. This
setting directly impacts the
performance of queries and
cost of the deployment.
Logical partition of data index database Allows logical separation of

the data. Both
implementations allow unions
and joining across these
partitions.
Structured event metadata N/A table Splunk does not have the
concept exposed to the
search language of event
metadata. Azure Monitor logs
has the concept of a table,
which has columns. Each
event instance is mapped to a
row.
Data record event row Terminology change only.
Data record attribute field column In Azure Monitor, this is

predefined as part of the
table structure. In Splunk,
each event has its own set of
fields.
Types datatype datatype Azure Monitor datatypes are

more explicit as they are set
on the columns. Both have
the ability to work
dynamically with data types
and roughly equivalent set of
datatypes including JSON
support.
CONCEPT SPLUNK AZURE MONITOR COMMENT
Query and search search query Concepts are essentially the

same between both Azure
Monitor and Splunk.
Event ingestion time System Time ingestion_time() In Splunk, each event gets a
system timestamp of the time
that the event was indexed. In
Azure Monitor, you can
define a policy called
ingestion_time that exposes a
system column that can be
referenced through the
ingestion_time() function.
Functions
The following table specifies functions in Azure Monitor that are equivalent to Splunk functions.
SPLUNK AZURE MONITOR COMMENT
strcat strcat() (1)
split split() (1)
if iff() (1)
tonumber todouble() (1)

tolong()
toint()
upper toupper() (1)

lower tolower()
replace replace() (1)

Also note that while replace() takes
three parameters in both products, the
parameters are different.
substr substring() (1)

Also note that Splunk uses one-based
indices. Azure Monitor notes zero-based
indices.
tolower tolower() (1)
toupper toupper() (1)
match matches regex (2)
regex matches regex In Splunk, regex is an operator. In

Azure Monitor, it's a relational operator.
searchmatch == In Splunk, searchmatch allows

searching for the exact string.
SPLUNK AZURE MONITOR COMMENT
random rand() Splunk's function returns a number from

rand(n) zero to 231 -1. Azure Monitor' returns a
number between 0.0 and 1.0, or if a
parameter provided, between 0 and n-1.
now now() (1)
relative_time totimespan() (1)

In Azure Monitor, Splunk's equivalent of
relative_time(datetimeVal, offsetVal) is
datetimeVal + totimespan(offsetVal).
For example,
search | eval
n=relative_time(now(), "-1d@d")
becomes
... | extend myTime = now() -
totimespan("1d")
.
(1) In Splunk, the function is invoked with the eval operator. In Azure Monitor, it is used as part of extend or
project .
(2) In Splunk, the function is invoked with the eval operator. In Azure Monitor, it can be used with the where
operator.
Operators
The following sections give examples of using different operators between Splunk and Azure Monitor.
NOTE
For the purpose of the following example, the Splunk field rule maps to a table in Azure Monitor, and Splunk's default timestamp
maps to the Logs Analytics ingestion_time() column.
Search
In Splunk, you can omit the search keyword and specify an unquoted string. In Azure Monitor you must start each
query with find , an unquoted string is a column name, and the lookup value must be a quoted string.
Splunk search search Session.Id="c8894ffd-e684-

43c9-9125-42adc25cd3fc" earliest=-
24h
Azure Monitor find find Session.Id=="c8894ffd-e684-

43c9-9125-42adc25cd3fc" and
ingestion_time()> ago(24h)
Filter
Azure Monitor log queries start from a tabular result set where the filter. In Splunk, filtering is the default operation on
the current index. You can also use where operator in Splunk, but it is not recommended.
Splunk search Event.Rule="330009.2"

Session.Id="c8894ffd-e684-43c9-
9125-42adc25cd3fc" _indextime>-24h
Azure Monitor where Office_Hub_OHubBGTaskError
| where Session_Id == "c8894ffd-
e684-43c9-9125-42adc25cd3fc" and
ingestion_time() > ago(24h)
Getting n events/rows for inspection

Azure Monitor log queries also support take as an alias to limit . In Splunk, if the results are ordered, head will
return the first n results. In Azure Monitor, limit is not ordered but returns the first n rows that are found.
Splunk head Event.Rule=330009.2

| head 100
Azure Monitor limit Office_Hub_OHubBGTaskError

| limit 100
Getting the first n events/rows ordered by a field/column

For bottom results, in Splunk you use tail . In Azure Monitor you can specify the ordering direction with asc .
Splunk head Event.Rule="330009.2"

| sort Event.Sequence
| head 20
Azure Monitor top Office_Hub_OHubBGTaskError

| top 20 by Event_Sequence
Extending the result set with new fields/columns

Splunk also has an eval function, which is not to be comparable with the eval operator. Both the eval operator in
Splunk and the extend operator in Azure Monitor only support scalar functions and arithmetic operators.
Splunk eval Event.Rule=330009.2

| eval state= if(Data.Exception =
"0", "success", "error")
Azure Monitor extend Office_Hub_OHubBGTaskError

| extend state =
iif(Data_Exception == 0,"success"
,"error")
Rename
Azure Monitor uses the same operator to rename and to create a new field. Splunk has two separate operators, eval
and rename .
Splunk rename Event.Rule=330009.2

| rename Date.Exception as
execption
Azure Monitor extend Office_Hub_OHubBGTaskError
| extend exception =
Date_Exception
Format results/Projection
Splunk does not seem to have an operator similar to project-away . You can use the UI to filter away fields.
Splunk table Event.Rule=330009.2

| table rule, state
Azure Monitor project Office_Hub_OHubBGTaskError

project-away | project exception, state
Aggregation
See the Aggregations in Azure Monitor log queries for the different aggregation functions.
Splunk stats search (Rule=120502.*)

| stats count by OSEnv, Audience
Azure Monitor summarize Office_Hub_OHubBGTaskError

| summarize count() by
App_Platform, Release_Audience
Join
Join in Splunk has significant limitations. The subquery has a limit of 10000 results (set in the deployment
configuration file), and there a limited number of join flavors.
Splunk join Event.Rule=120103* | stats by

Client.Id, Data.Alias | join
Client.Id max=0 [search earliest=-
24h Event.Rule="150310.0"
Data.Hresult=-2147221040]
Azure Monitor join cluster("OAriaPPT").database("Office

PowerPoint").Office_PowerPoint_PPT_Exceptions
| where Data_Hresult== -2147221040
| join kind = inner
(Office_System_SystemHealthMetadata
| summarize by Client_Id, Data_Alias)on
Client_Id
Sort
In Splunk, to sort in ascending order you must use the reverse operator. Azure Monitor also supports defining where
to put nulls, at the beginning or at the end.
Splunk sort Event.Rule=120103

| sort Data.Hresult
| reverse
Azure Monitor order by Office_Hub_OHubBGTaskError
| order by Data_Hresult, desc
Multivalue expand
This is a similar operator in both Splunk and Azure Monitor.
Splunk mvexpand mvexpand foo
Azure Monitor mvexpand mvexpand foo
Results facets, interesting fields

In Log Analytics in the Azure portal, only the first column is exposed. All columns are available through the API.
Splunk fields Event.Rule=330009.2

| fields App.Version, App.Platform
Azure Monitor facets Office_Excel_BI_PivotTableCreate

| facet by App_Branch, App_Version
De-duplicate
You can use summarize arg_min() instead to reverse the order of which record gets chosen.
Splunk dedup Event.Rule=330009.2

| dedup device_id sortby -
batterylife
Azure Monitor summarize arg_max() Office_Excel_BI_PivotTableCreate

| summarize arg_max(batterylife,
*) by device_id
Next steps
Go through a lesson on the writing log queries in Azure Monitor.
Perform cross-resource log queries in Azure Monitor
Previously with Azure Monitor, you could only analyze data from within the current workspace, and it limited
your ability to query across multiple workspaces defined in your subscription. Additionally, you could only
search telemetry items collected from your web-based application with Application Insights directly in
Application Insights or from Visual Studio. This also made it a challenge to natively analyze operational and
application data together.
Now you can query not only across multiple Log Analytics workspaces, but also data from a specific Application
Insights app in the same resource group, another resource group, or another subscription. This provides you
with a system-wide view of your data. You can only perform these types of queries in Log Analytics.
Cross-resource query limits

The number of Application Insights resources and Log Analytics workspaces that you can include in a single
query is limited to 100.
Cross-resource query is not supported in View Designer. You can Author a query in Log Analytics and pin it
to Azure dashboard to visualize a log query.
Cross-resource query in log alerts is supported in the new scheduledQueryRules API. By default, Azure
Monitor uses the legacy Log Analytics Alert API for creating new log alert rules from Azure portal, unless
you switch from legacy Log Alerts API. After the switch, the new API becomes the default for new alert rules
in Azure portal and it lets you create cross-resource query log alerts rules. You can create cross-resource
query log alert rules without making the switch by using the Azure Resource Manager template for
scheduledQueryRules API – but this alert rule is manageable though scheduledQueryRules API and not
from Azure portal.
Querying across Log Analytics workspaces and from Application

Insights
To reference another workspace in your query, use the workspace identifier, and for an app from Application
Insights, use the app identifier.
Identifying workspace resources
The following examples demonstrate queries across Log Analytics workspaces to return summarized counts of
logs from the Update table on a workspace named contosoretail-it.
Identifying a workspace can be accomplished one of several ways:
Resource name - is a human-readable name of the workspace, sometimes referred to as component
name.
workspace("contosoretail-it").Update | count
Qualified name - is the “full name” of the workspace, composed of the subscription name, resource group,
and component name in this format: subscriptionName/resourceGroup/componentName.
workspace('contoso/contosoretail/contosoretail-it').Update | count
NOTE
Because Azure subscription names are not unique, this identifier might be ambiguous.
Workspace ID - A workspace ID is the unique, immutable, identifier assigned to each workspace

represented as a globally unique identifier (GUID ).
workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update | count
Azure Resource ID – the Azure-defined unique identity of the workspace. You use the Resource ID when
the resource name is ambiguous. For workspaces, the format is:
/subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/wo
rkspaces/componentName.
For example:
workspace("/subscriptions/e427519-5645-8x4e-1v67-
3b84b59a1985/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contoso
retail-it").Update | count
Identifying an application
The following examples return a summarized count of requests made against an app named fabrikamapp in
Identifying an application in Application Insights can be accomplished with the app (Identifier ) expression. The
Identifier argument specifies the app using one of the following:
Resource name - is a human readable name of the app, sometimes referred to as the component name.
app("fabrikamapp")
NOTE
Identifying an application by name assumes uniqueness across all accessible subscriptions. If you have multiple
applications with the specified name, the query fails because of the ambiguity. In this case, you must use one of
the other identifiers.
Qualified name - is the “full name” of the app, composed of the subscription name, resource group, and
component name in this format: subscriptionName/resourceGroup/componentName.
app("AI-Prototype/Fabrikam/fabrikamapp").requests | count
NOTE
Because Azure subscription names are not unique, this identifier might be ambiguous.
ID - the app GUID of the application.

app("b459b4f6-912x-46d5-9cb1-b43069212ab4").requests | count
Azure Resource ID - the Azure-defined unique identity of the app. You use the Resource ID when the
resource name is ambiguous. The format is:
/subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/co
mponents/componentName.
For example:
app("/subscriptions/b459b4f6-912x-46d5-9cb1-
b43069212ab4/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests |
count
Performing a query across multiple resources

You can query multiple resources from any of your resource instances, these can be workspaces and apps
combined.
Example for query across two workspaces:
union Update, workspace("contosoretail-it").Update, workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update

| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Using cross-resource query for multiple resources

When using cross-resource queries to correlate data from multiple Log Analytics workspaces and Application
Insights resources, the query can become complex and difficult to maintain. You should leverage functions in
Azure Monitor log queries to separate the query logic from the scoping of the query resources, which simplifies
the query structure. The following example demonstrates how you can monitor multiple Application Insights
resources and visualize the count of failed requests by application name.
Create a query like the following that references the scope of Application Insights resources. The
withsource= SourceApp command adds a column that designates the application name that sent the log. Save the
query as function with the alias applicationsScoping.
// crossResource function that scopes my Application Insights resources

union withsource= SourceApp
app('Contoso-app1').requests,
app('Contoso-app5').requests
You can now use this function in a cross-resource query like the following. The function alias
applicationsScoping returns the union of the requests table from all the defined applications. The query then
filters for failed requests and visualizes the trends by application. The parse operator is optional in this example.
It extracts the application name from SourceApp property.
applicationsScoping
| parse SourceApp with * '(' applicationName ')' *
| summarize count() by applicationName, bin(timestamp, 1h)
| render timechart
NOTE
This method can’t be used with log alerts because the access validation of the alert rule resources, including workspaces
and applications, is performed at alert creation time. Adding new resources to the function after the alert creation isn’t
supported. If you prefer to use function for resource scoping in log alerts, you need to edit the alert rule in the portal or
with a Resource Manager template to update the scoped resources. Alternatively, you can include the list of resources in
the log alert query.
Next steps
Review Analyze log data in Azure Monitor for an overview of log queries and how Azure Monitor log data is
structured.
Review Azure Monitor log queries to view all of the resources for Azure Monitor log queries.
app() expression in Azure Monitor query
The app expression is used in an Azure Monitor query to retrieve data from a specific Application Insights app in
the same resource group, another resource group, or another subscription. This is useful to include application
data in an Azure Monitor log query and to query data across multiple applications in an Application Insights
query.
Syntax
app( Identifier )
Arguments
Identifier: Identifies the app using one of the formats in the table below.
IDENTIFIER DESCRIPTION EXAMPLE
Resource Name Human readable name of the app (AKA app("fabrikamapp")

"component name")
Qualified Name Full name of the app in the form: app('AI-

"subscriptionName/resourceGroup/com Prototype/Fabrikam/fabrikamapp')
ponentName"
ID GUID of the app app("988ba129-363e-4415-8fe7-

8cbab5447518")
Azure Resource ID Identifier for the Azure resource app("/subscriptions/7293b69-db12-

44fc-9a66-
9c2005c3051d/resourcegroups/Fabrika
m/providers/microsoft.insights/compon
ents/fabrikamapp")
Notes
You must have read access to the application.
Identifying an application by its name assumes that it is unique across all accessible subscriptions. If you have
multiple applications with the specified name, the query will fail because of the ambiguity. In this case you must
use one of the other identifiers.
Use the related expression workspace to query across Log Analytics workspaces.
The app() expression is currently not supported in the search query when using the Azure portal to create a
custom log search alert rule, unless an Application Insights application is used as the resource for the alert rule.
Examples
app("fabrikamapp").requests | count
app("AI-Prototype/Fabrikam/fabrikamapp").requests | count
app("b438b4f6-912a-46d5-9cb1-b44069212ab4").requests | count
app("/subscriptions/7293b69-db12-44fc-9a66-
9c2005c3051d/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count
union
(workspace("myworkspace").Heartbeat | where Computer contains "Con"),
(app("myapplication").requests | where cloud_RoleInstance contains "Con")
| count
union
(workspace("myworkspace").Heartbeat), (app("myapplication").requests)
| where TimeGenerated between(todatetime("2018-02-08 15:00:00") .. todatetime("2018-12-08 15:05:00"))
Next steps
See the workspace expression to refer to a Log Analytics workspace.
Read about how Azure Monitor data is stored.
Access full documentation for the Kusto query language.
workspace() expression in Azure Monitor log query
The workspace expression is used in an Azure Monitor query to retrieve data from a specific workspace in the
same resource group, another resource group, or another subscription. This is useful to include log data in an
Application Insights query and to query data across multiple workspaces in a log query.
Syntax
workspace( Identifier )
Arguments
Identifier: Identifies the workspace using one of the formats in the table below.
Resource Name Human readable name of the workspace("contosoretail")

workspace (AKA "component name")
Qualified Name Full name of the workspace in the form: workspace('Contoso/ContosoResource/

"subscriptionName/resourceGroup/com ContosoWorkspace')
ponentName"
ID GUID of the workspace workspace("b438b3f6-912a-46d5-

9db1-b42069242ab4")
Azure Resource ID Identifier for the Azure resource workspace("/subscriptions/e4227-645-

44e-9c67-
3b84b5982/resourcegroups/ContosoA
zureHQ/providers/Microsoft.Operation
alInsights/workspaces/contosoretail")
Notes
You must have read access to the workspace.
A related expression is app that allows you to query across Application Insights applications.
Examples
workspace("contosoretail").Update | count
workspace("b438b4f6-912a-46d5-9cb1-b44069212ab4").Update | count
workspace("/subscriptions/e427267-5645-4c4e-9c67-
3b84b59a6982/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contosoretail")
.Event | count
union
(workspace("myworkspace").Heartbeat | where Computer contains "Con"),
(app("myapplication").requests | where cloud_RoleInstance contains "Con")
| count
union
(workspace("myworkspace").Heartbeat), (app("myapplication").requests)
| where TimeGenerated between(todatetime("2018-02-08 15:00:00") .. todatetime("2018-12-08 15:05:00"))
Next steps
See the app expression to refer to an Application Insights app.
Read about how Azure Monitor data is stored.
resource() expression in Azure Monitor log query
The resource expression is used in a Azure Monitor query scoped to a resource to retrieve data from other
resources.
Syntax
resource( Identifier )
Arguments
Identifier: Resource ID of a resource.
Resource Includes data for the resource. resource("/subscriptions/xxxxxxx-xxxx-

xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresour
cegroup/providers/microsoft.compute/vi
rtualmachines/myvm")
Resource Group or Subscription Includes data for the resource and all resource("/subscriptions/xxxxxxx-xxxx-
resources that it contains. xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresour
cegroup)
Notes
You must have read access to the resource.
Examples
union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresourcegroup/providers/microsoft.compute/virtualmachines/myvm").Heartbeat) |
summarize count() by _ResourceId, TenantId
union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresourcegroup).Heartbeat) | summarize count() by _ResourceId, TenantId
Next steps
See Log query scope and time range in Azure Monitor Log Analytics for details on a query scope.
Unify multiple Azure Monitor Application Insights
resources
This article describes how to query and view all your Application Insights log data in one place, even when they are
in different Azure subscriptions, as a replacement for the deprecation of the Application Insights Connector. The
number of Application Insights resources that you can include in a single query is limited to 100.
Recommended approach to query multiple Application Insights

resources
Listing multiple Application Insights resources in a query can be cumbersome and difficult to maintain. Instead,
you can leverage function to separate the query logic from the applications scoping.
This example demonstrates how you can monitor multiple Application Insights resources and visualize the count
of failed requests by application name. Before you begin, run this query in the workspace that is connected to
Application Insights resources to get the list of connected applications:
ApplicationInsights
| summarize by ApplicationName
Create a function using union operator with the list of applications, then save the query in your workspace as
function with the alias applicationsScoping.
You can modify the listed applications at any time in the portal by navigating to Query explorer in your workspace
and selecting the function for editing and then saving, or using the SavedSearch PowerShell cmdlet.
NOTE
This method can’t be used with log alerts because the access validation of the alert rule resources, including workspaces and
applications, is performed at alert creation time. Adding new resources to the function after the alert creation isn’t
supported. If you prefer to use function for resource scoping in log alerts, you need to edit the alert rule in the portal or with
a Resource Manager template to update the scoped resources. Alternatively, you can include the list of resources in the log
alert query.
The withsource= SourceApp command adds a column to the results that designates the application that sent the
log. The parse operator is optional in this example and uses to extracts the application name from SourceApp
property.
union withsource=SourceApp
app('Contoso-app5').requests
| parse SourceApp with * "('" applicationName "')" *
You are now ready to use applicationsScoping function in the cross-resource query:
applicationsScoping
| parse SourceApp with * '(' applicationName ')' *
| summarize count() by applicationName, bin(timestamp, 1h)
| render timechart
The query uses Application Insights schema, although the query is executed in the workspace since the
applicationsScoping function returns the Application Insights data structure. The function alias returns the union of
the requests from all the defined applications. The query then filters for failed requests and visualizes the trends by
application.
Query across Application Insights resources and workspace data

When you stop the Connector and need to perform queries over a time range that was trimmed by Application
Insights data retention (90 days), you need to perform cross-resource queries on the workspace and Application
Insights resources for an intermediate period. This is until your applications data accumulates per the new
Application Insights data retention mentioned above. The query requires some manipulations since the schemas in
Application Insights and the workspace are different. See the table later in this section highlighting the schema
differences.
NOTE
Cross-resource query in log alerts is supported in the new scheduledQueryRules API. By default, Azure Monitor uses the
legacy Log Analytics Alert API for creating new log alert rules from Azure portal, unless you switch from legacy Log Alerts
API. After the switch, the new API becomes the default for new alert rules in Azure portal and it lets you create cross-
resource query log alerts rules. You can create cross-resource query log alert rules without making the switch by using the
ARM template for scheduledQueryRules API – but this alert rule is manageable though scheduledQueryRules API and not
from Azure portal.
For example, if the connector stopped working on 2018-11-01, when you query logs across Application Insights
resources and applications data in the workspace, your query would be constructed like the following example:
applicationsScoping //this brings data from Application Insights resources
| where timestamp between (datetime("2018-11-01") .. now())
| where duration > 1000
| union (
ApplicationInsights //this is Application Insights data in Log Analytics workspace
| where TimeGenerated < (datetime("2018-12-01")
| where RequestSuccess == 'False'
| where RequestDuration > 1000
| extend duration = RequestDuration //align to Application Insights schema
| extend timestamp = TimeGenerated //align to Application Insights schema
| extend name = RequestName //align to Application Insights schema
| extend resultCode = ResponseCode //align to Application Insights schema
| project-away RequestDuration , RequestName , ResponseCode , TimeGenerated
)
| project timestamp , duration , name , resultCode
Application Insights and Log Analytics workspace schema differences

The following table shows the schema differences between Log Analytics and Application Insights.
LOG ANALYTICS WORKSPACE PROPERTIES APPLICATION INSIGHTS RESOURCE PROPERTIES
AnonUserId user_id
ApplicationId appId
ApplicationName appName
ApplicationTypeVersion application_Version
AvailabilityCount itemCount
AvailabilityDuration duration
AvailabilityMessage message
AvailabilityRunLocation location
AvailabilityTestId id
AvailabilityTestName name
AvailabilityTimestamp timestamp
Browser client_browser
City client_city
ClientIP client_IP
Computer cloud_RoleInstance
Country client_CountryOrRegion
CustomEventCount itemCount
CustomEventDimensions customDimensions
CustomEventName name
DeviceModel client_Model
DeviceType client_Type
ExceptionCount itemCount
ExceptionHandledAt handledAt
ExceptionMessage message
ExceptionType type
OperationID operation_id
OperationName operation_Name
OS client_OS
PageViewCount itemCount
PageViewDuration duration
PageViewName name
ParentOperationID operation_Id
RequestCount itemCount
RequestDuration duration
RequestID id
RequestName name
RequestSuccess success
ResponseCode resultCode
Role cloud_RoleName
RoleInstance cloud_RoleInstance
SessionId session_Id
SourceSystem operation_SyntheticSource
TelemetryTYpe type
URL url
UserAccountId user_AccountId
Next steps
Use Log Search to view detailed information for your Application Insights apps.
Azure Monitor log query examples
This article includes various examples of queries using the Kusto query language to retrieve different types of log
data from Azure Monitor. Different methods are used to consolidate and analyze data, so you can use these
samples to identify different strategies that you might use for your own requirements.
See the Kusto language reference for details on the different keywords used in these samples. Go through a lesson
on creating queries if you're new to Azure Monitor.
Events
Search application-level events described as "Cryptographic"
This example searches the Events table for records in which EventLog is Application and RenderedDescription
contains cryptographic. Includes records from the last 24 hours.
Event
| where EventLog == "Application"
| where RenderedDescription contains "cryptographic"
Search events related to unmarshaling

Search tables Event and SecurityEvents for records that mention unmarshaling.
search in (Event, SecurityEvent) "unmarshaling"
Heartbeat
Chart a week-over-week view of the number of computers sending data
The following example charts the number of distinct computers that sent heartbeats, each week.
Heartbeat
| where TimeGenerated >= startofweek(ago(21d))
| summarize dcount(Computer) by endofweek(TimeGenerated) | render barchart kind=default
Find stale computers

The following example finds computers that were active in the last day but did not send heartbeats in the last hour.
Heartbeat
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where isnotempty(Computer)
| where LastHeartbeat < ago(1h)
Get the latest heartbeat record per computer IP

This example returns the last heartbeat record for each computer IP.
Heartbeat
| summarize arg_max(TimeGenerated, *) by ComputerIP
Match protected status records with heartbeat records

This example finds related protection status records and heartbeat records, matched on both Computer and time.
Note the time field is rounded to the nearest minute. We used runtime bin calculation to do that:
round_time=bin(TimeGenerated, 1m) .
let protection_data = ProtectionStatus

| project Computer, DetectionId, round_time=bin(TimeGenerated, 1m);
let heartbeat_data = Heartbeat
| project Computer, Category, round_time=bin(TimeGenerated, 1m);
protection_data | join (heartbeat_data) on Computer, round_time
Server availability rate

Calculate server availability rate based on heartbeat records. Availability is defined as "at least 1 heartbeat per
hour". So, if a server was available 98 of 100 hours, the availability rate is 98%.
let start_time=startofday(datetime("2018-03-01"));
let end_time=now();
Heartbeat
| where TimeGenerated > start_time and TimeGenerated < end_time
| summarize heartbeat_per_hour=count() by bin_at(TimeGenerated, 1h, start_time), Computer
| extend available_per_hour=iff(heartbeat_per_hour>0, true, false)
| summarize total_available_hours=countif(available_per_hour==true) by Computer
| extend total_number_of_buckets=round((end_time-start_time)/1h)+1
| extend availability_rate=total_available_hours*100/total_number_of_buckets
Multiple data types

Chart the record-count per table
The following example collects all records of all tables from the last five hours and counts how many records were
in each table. The results are shown in a timechart.
union withsource=sourceTable *
| summarize count() by bin(TimeGenerated,10m), sourceTable
| render timechart
Count all logs collected over the last hour by type

The following example searches everything reported in the last hour and counts the records of each table by Type.
The results are displayed in a bar chart.
search *
| summarize CountOfRecords = count() by Type
| render barchart
AzureDiagnostics
Count Azure diagnostics records per category
This example counts all Azure diagnostics records for each unique category.
AzureDiagnostics
| summarize count() by Category
Get a random record for each unique category

This example gets a single random Azure diagnostics record for each unique category.
AzureDiagnostics
| summarize any(*) by Category
Get the latest record per category

This example gets the latest Azure diagnostics record in each unique category.
AzureDiagnostics
| summarize arg_max(TimeGenerated, *) by Category
Network monitoring
Computers with unhealthy latency
This example creates a list of distinct computers with unhealthy latency.
NetworkMonitoring
| where LatencyHealthState <> "Healthy"
| where Computer != ""
| distinct Computer
Performance
Join computer perf records to correlate memory and CPU
This example correlates a particular computer's perf records and creates two time charts, the average CPU and
maximum memory.
let StartTime = now()-5d;

let EndTime = now()-4d;
Perf
| where TimeGenerated > StartTime and TimeGenerated < EndTime
and TimeGenerated < EndTime
| project TimeGenerated, Computer, cpu=CounterValue
| join kind= inner (
Perf
| where CounterName == "% Used Memory"
| where TimeGenerated > StartTime and TimeGenerated < EndTime
| project TimeGenerated , Computer, mem=CounterValue
) on TimeGenerated, Computer
| summarize avgCpu=avg(cpu), maxMem=max(mem) by TimeGenerated bin=30m
| render timechart
Perf CPU Utilization graph per computer

This example calculates and charts the CPU utilization of computers that start with Contoso.
Perf
| where Computer startswith "Contoso"
| where CounterName == @"% Processor Time"
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 15m)
| render timechart
Protection status
Computers with non-reporting protection status duration
This example lists computers that had a protection status of Not Reporting and the duration they were in this
status.
ProtectionStatus
| where ProtectionStatus == "Not Reporting"
| summarize count(), startNotReporting = min(TimeGenerated), endNotReporting = max(TimeGenerated) by Computer,
ProtectionStatusDetails
| join ProtectionStatus on Computer
| summarize lastReporting = max(TimeGenerated), startNotReporting = any(startNotReporting), endNotReporting =
any(endNotReporting) by Computer
| extend durationNotReporting = endNotReporting - startNotReporting
Match protected status records with heartbeat records

This example finds related protection status records and heartbeat records matched on both Computer and time.
The time field is rounded to the nearest minute using bin.
let protection_data = ProtectionStatus

| project Computer, DetectionId, round_time=bin(TimeGenerated, 1m);
let heartbeat_data = Heartbeat
| project Computer, Category, round_time=bin(TimeGenerated, 1m);
protection_data | join (heartbeat_data) on Computer, round_time
Security records
Count security events by activity ID
This example relies on the fixed structure of the Activity column: <ID>-<Name>. It parses the Activity value into
two new columns, and counts the occurrence of each activityID.
SecurityEvent
| project Activity
| parse Activity with activityID " - " activityDesc
| summarize count() by activityID
Count security events related to permissions

This example shows the number of securityEvent records, in which the Activity column contains the whole term
Permissions. The query applies to records created over the last 30 minutes.
SecurityEvent
| summarize EventCount = countif(Activity has "Permissions")
Find accounts that failed to log in from computers with a security detection
This example finds and counts accounts that failed to log in from computers on which we identify a security
detection.
let detections = toscalar(SecurityDetection

| summarize makeset(Computer));
SecurityEvent
| where Computer in (detections) and EventID == 4624
| summarize count() by Account
Is my security data available?

Starting data exploration often starts with data availability check. This example shows the number of
SecurityEvent records in the last 30 minutes.
SecurityEvent
| count
Parse activity name and ID

The two examples below rely on the fixed structure of the Activity column: <ID>-<Name>. The first example uses
the parse operator to assign values to two new columns: activityID and activityDesc.
SecurityEvent
| take 100
| project Activity
| parse Activity with activityID " - " activityDesc
This example uses the split operator to create an array of separate values
SecurityEvent
| take 100
| project Activity
| extend activityArr=split(Activity, " - ")
| project Activity , activityArr, activityId=activityArr[0]
Explicit credentials processes

The following example shows a pie chart of processes that used explicit credentials in the last week
SecurityEvent
// filter by id 4648 ("A logon was attempted using explicit credentials")
| summarize count() by Process
| render piechart
Top running processes

The following example shows a time line of activity for the five most common processes, over the last three days.
// Find all processes that started in the last three days. ID 4688: A new process has been created.
let RunProcesses =
SecurityEvent
| where EventID == "4688";
// Find the 5 processes that were run the most
let Top5Processes =
RunProcesses
| summarize count() by Process
| top 5 by count_;
// Create a time chart of these 5 processes - hour by hour
RunProcesses
| where Process in (Top5Processes)
| summarize count() by bin (TimeGenerated, 1h), Process
| render timechart
Find repeating failed login attempts by the same account from different IPs
The following example finds failed login attempts by the same account from more than five different IPs in the last
six hours.
SecurityEvent
| where AccountType == "User" and EventID == 4625 and TimeGenerated > ago(6h)
| summarize IPCount = dcount(IpAddress), makeset(IpAddress) by Account
| where IPCount > 5
| sort by IPCount desc
Find user accounts that failed to log in

The following example identifies user accounts that failed to log in more than five times in the last day, and when
they last attempted to log in.
let timeframe = 1d;

SecurityEvent
| where AccountType == 'User' and EventID == 4625 // 4625 - failed log in
| summarize failed_login_attempts=count(), latest_failed_login=arg_max(TimeGenerated, Account) by Account
| where failed_login_attempts > 5
| project-away Account1
Using join, and let statements we can check if the same suspicious accounts were later able to log in successfully.
let timeframe = 1d;
let suspicious_users =
SecurityEvent
| where TimeGenerated > ago(timeframe)
| where AccountType == 'User' and EventID == 4625 // 4625 - failed login
| summarize failed_login_attempts=count(), latest_failed_login=arg_max(TimeGenerated, Account) by Account
| where failed_login_attempts > 5
| project-away Account1;
let suspicious_users_that_later_logged_in =
suspicious_users
| join kind=innerunique (
SecurityEvent
| where TimeGenerated > ago(timeframe)
| where AccountType == 'User' and EventID == 4624 // 4624 - successful login,
| summarize latest_successful_login=arg_max(TimeGenerated, Account) by Account
) on Account
| extend was_login_after_failures = iif(latest_successful_login>latest_failed_login, 1, 0)
| where was_login_after_failures == 1
;
suspicious_users_that_later_logged_in
Usage
Calculate the average size of perf usage reports per computer
This example calculates the average size of perf usage reports per computer, over the last 3 hours. The results are
shown in a bar chart.
Usage
| where DataType == "Perf"
| where QuantityUnit == "MBytes"
| summarize avg(Quantity) by Computer
| sort by avg_Quantity desc nulls last
| render barchart
Timechart latency percentiles 50 and 95

This example calculates and charts the 50th and 95th percentiles of reported avgLatency by hour over the last 24
hours.
Usage
| summarize percentiles(AvgLatencyInSeconds, 50, 95) by bin(TimeGenerated, 1h)
| render timechart
Usage of specific computers today

This example retrieves Usage data from the last day for computer names that contains the string ContosoFile. The
results are sorted by TimeGenerated.
Usage
| where Computer contains "ContosoFile"
| sort by TimeGenerated desc nulls last
Updates
Computers Still Missing Updates
This example shows a list of computers that were missing one or more critical updates a few days ago and are still
missing updates.
let ComputersMissingUpdates3DaysAgo = Update

| where TimeGenerated between (ago(30d)..ago(1h))
| where Classification !has "Critical" and UpdateState =~ "Needed"
| summarize makeset(Computer);
Update
| where Classification has "Critical" and UpdateState =~ "Needed"
| where Computer in (ComputersMissingUpdates3DaysAgo)
| summarize UniqueUpdatesCount = dcount(Product) by Computer, OSType
Next steps
Refer to the Kusto language reference for details on the language.
Walk through a lesson on writing log queries in Azure Monitor.
Log Analytics smart analytics examples
This article includes examples that use smart analytics functions in Log Analytics to perform analysis of user
activity. You can either use these examples to analyze your own applications monitored by Application Insights or
use the concepts in these queries for similar analysis on other data.
See the Kusto language reference for details on the different keywords used in these samples. Go through a lesson
on creating queries if you're new to Log Analytics.
Cohorts analytics
Cohort analysis tracks the activity of specific groups of users, known as cohorts. It attempts to measure how
appealing a service is by measuring the rate of returning users. The users are grouped by the time they first used
the service. When analyzing cohorts, we expect to find a decrease in activity over the first tracked periods. Each
cohort is titled by the week its members were observed for the first time.
The following example analyzes the number of activities users perform over the course of 5 weeks, following their
first use of the service.
let startDate = startofweek(bin(datetime(2017-01-20T00:00:00Z), 1d));
let week = range Cohort from startDate to datetime(2017-03-01T00:00:00Z) step 7d;
// For each user we find the first and last timestamp of activity
let FirstAndLastUserActivity = (end:datetime)
{
customEvents
| where customDimensions["sourceapp"]=="ai-loganalyticsui-prod"
// Check 30 days back to see first time activity
| where timestamp > startDate - 30d
| where timestamp < end
| summarize min=min(timestamp), max=max(timestamp) by user_AuthenticatedId
};
let DistinctUsers = (cohortPeriod:datetime, evaluatePeriod:datetime) {
toscalar (
FirstAndLastUserActivity(evaluatePeriod)
// Find members of the cohort: only users that were observed in this period for the first time
| where min >= cohortPeriod and min < cohortPeriod + 7d
// Pick only the members that were active during the evaluated period or after
| where max > evaluatePeriod - 7d
| summarize dcount(user_AuthenticatedId))
};
week
| where Cohort == startDate
// Finally, calculate the desired metric for each cohort. In this sample we calculate distinct users but you
can change
// this to any other metric that would measure the engagement of the cohort members.
| extend
r0 = DistinctUsers(startDate, startDate+7d),
r4 = DistinctUsers(startDate, startDate+35d)
| union (week | where Cohort == startDate + 7d
| extend
r0 = DistinctUsers(startDate+7d, startDate+14d),
r3 = DistinctUsers(startDate+7d, startDate+35d) )
| extend
| extend
| extend
r0 = DistinctUsers (startDate+28d, startDate+35d) )
// Calculate the retention percentage for each cohort by weeks
| project Cohort, r0, r1, r2, r3, r4,
p0 = r0/r0*100,
p1 = todouble(r1)/todouble (r0)*100,
p2 = todouble(r2)/todouble(r0)*100,
p3 = todouble(r3)/todouble(r0)*100,
p4 = todouble(r4)/todouble(r0)*100
| sort by Cohort asc
This example results in the following output.

Rolling monthly active users and user stickiness
The following examples uses time-series analysis with the series_fir function which allows you to perform sliding
window computations. The sample application being monitored is an online store that tracks users' activity through
custom events. The query tracks two types of user activities, AddToCart and Checkout, and defines active users as
those who performed a check-out at least once in a given day.
let endtime = endofday(datetime(2017-03-01T00:00:00Z));
let window = 60d;
let starttime = endtime-window;
let interval = 1d;
let user_bins_to_analyze = 28;
// Create an array of filters coefficients for series_fir(). A list of '1' in our case will produce a simple
sum.
let moving_sum_filter = toscalar(range x from 1 to user_bins_to_analyze step 1 | extend v=1 | summarize
makelist(v));
// Level of engagement. Users will be counted as engaged if they performed at least this number of activities.
let min_activity = 1;
customEvents
| where timestamp > starttime
| where customDimensions["sourceapp"] == "ai-loganalyticsui-prod"
// We want to analyze users who actually checked-out in our web site
| where (name == "Checkout") and user_AuthenticatedId <> ""
// Create a series of activities per user
| make-series UserClicks=count() default=0 on timestamp
in range(starttime, endtime-1s, interval) by user_AuthenticatedId
// Create a new column containing a sliding sum.
// Passing 'false' as the last parameter to series_fir() prevents normalization of the calculation by the size
of the window.
// For each time bin in the *RollingUserClicks* column, the value is the aggregation of the user activities in
the
// 28 days that preceded the bin. For example, if a user was active once on 2016-12-31 and then inactive
throughout
// January, then the value will be 1 between 2016-12-31 -> 2017-01-28 and then 0s.
| extend RollingUserClicks=series_fir(UserClicks, moving_sum_filter, false)
// Use the zip() operator to pack the timestamp with the user activities per time bin
| project User_AuthenticatedId=user_AuthenticatedId , RollingUserClicksByDay=zip(timestamp, RollingUserClicks)
// Transpose the table and create a separate row for each combination of user and time bin (1 day)
| mvexpand RollingUserClicksByDay
| extend Timestamp=todatetime(RollingUserClicksByDay[0])
// Mark the users that qualify according to min_activity
| extend RollingActiveUsersByDay=iff(toint(RollingUserClicksByDay[1]) >= min_activity, 1, 0)
// And finally, count the number of users per time bin.
| summarize sum(RollingActiveUsersByDay) by Timestamp
// First 28 days contain partial data, so we filter them out.
| where Timestamp > starttime + 28d
// render as timechart
| render timechart

THe following example turns the above query into a reusable function and uses it to calculate rolling user
stickiness. Active users in this query are defined as only those users that performed check-out at least once in a
given day.
let rollingDcount = (sliding_window_size: int, event_name:string)

{
let endtime = endofday(datetime(2017-03-01T00:00:00Z));
let window = 90d;
let starttime = endtime-window;
let interval = 1d;
let moving_sum_filter = toscalar(range x from 1 to sliding_window_size step 1 | extend v=1| summarize
makelist(v));
let min_activity = 1;
customEvents
| where timestamp > starttime
| where customDimensions["sourceapp"]=="ai-loganalyticsui-prod"
| where (name == event_name)
| where user_AuthenticatedId <> ""
| make-series UserClicks=count() default=0 on timestamp
in range(starttime, endtime-1s, interval) by user_AuthenticatedId
| extend RollingUserClicks=fir(UserClicks, moving_sum_filter, false)
| project User_AuthenticatedId=user_AuthenticatedId , RollingUserClicksByDay=zip(timestamp,
RollingUserClicks)
| mvexpand RollingUserClicksByDay
| extend Timestamp=todatetime(RollingUserClicksByDay[0])
| extend RollingActiveUsersByDay=iff(toint(RollingUserClicksByDay[1]) >= min_activity, 1, 0)
| summarize sum(RollingActiveUsersByDay) by Timestamp
| where Timestamp > starttime + 28d
};
// Use the moving_sum_filter with bin size of 28 to count MAU.
rollingDcount(28, "Checkout")
| join
(
// Use the moving_sum_filter with bin size of 1 to count DAU.
rollingDcount(1, "Checkout")
)
on Timestamp
| project sum_RollingActiveUsersByDay1 *1.0 / sum_RollingActiveUsersByDay, Timestamp
| render timechart

Regression analysis
This example demonstrates how to create an automated detector for service disruptions based exclusively on an
application's trace logs. The detector seeks abnormal sudden increases in the relative amount of error and warning
traces in the application.
Two techniques are used to evaluate the service status based on trace logs data:
Use make-series to convert semi-structured textual trace logs into a metric that represents the ratio between
positive and negative trace lines.
Use series_fit_2lines and series_fit_line to perform advanced step-jump detection using time-series analysis with
a 2-line linear regression.
let startDate = startofday(datetime("2017-02-01"));

let endDate = startofday(datetime("2017-02-07"));
let minRsquare = 0.8; // Tune the sensitivity of the detection sensor. Values close to 1 indicate very low
sensitivity.
// Count all Good (Verbose + Info) and Bad (Error + Fatal + Warning) traces, per day
traces
| where timestamp > startDate and timestamp < endDate
| summarize
Verbose = countif(severityLevel == 0),
Info = countif(severityLevel == 1),
Warning = countif(severityLevel == 2),
Error = countif(severityLevel == 3),
Fatal = countif(severityLevel == 4) by bin(timestamp, 1d)
| extend Bad = (Error + Fatal + Warning), Good = (Verbose + Info)
// Determine the ratio of bad traces, from the total
| extend Ratio = (todouble(Bad) / todouble(Good + Bad))*10000
| project timestamp , Ratio
// Create a time series
| make-series RatioSeries=any(Ratio) default=0 on timestamp in range(startDate , endDate -1d, 1d) by
'TraceSeverity'
// Apply a 2-line regression to the time series
| extend (RSquare2, SplitIdx, Variance2,RVariance2,LineFit2)=series_fit_2lines(RatioSeries)
// Find out if our 2-line is trending up or down
| extend (Slope,Interception,RSquare,Variance,RVariance,LineFit)=series_fit_line(LineFit2)
// Check whether the line fit reaches the threshold, and if the spike represents an increase (rather than a
decrease)
| project PatternMatch = iff(RSquare2 > minRsquare and Slope>0, "Spike detected", "No Match")
Next steps
Refer to the Data Explorer language reference for details on the language.
Walk through a lesson on writing queries in Log Analytics.
Writing efficient log queries in Azure Monitor
This article provides recommendations for writing efficient log queries in Azure Monitor. Using these strategies,
you can ensure that your queries will run quickly and with minimal overheard.
Scope your query

Having your query process more data than you actually need may lead to a long-running query and often result in
too much data in your results to effectively analyze. In extreme cases the query may even time out and fail.
Specify your data source
The first step in writing an efficient query is limiting its scope to its required data sources. Specifying a table is
always preferred over running an wide text search, such as search * . To query a specific table, start your query
with the table name as in the following:
requests | ...
You can use search to search for a value across multiple columns in specific tables using a query like the following:
search in (exceptions) "The server was not found"
search in (exceptions, customEvents) "timeout"
Use union to query several tables like the following:
union requests, traces | ...

You should also limit your query to the time range of data that you require. By default, your query will include data
collected in the last 24 hours. You can change that option in the Time range selector or add it explicitly to your
query. It's best to add the time filter immediately after the table name so that the rest of your query only processes
data within that range:
requests | where timestamp > ago(1h)
requests | where timestamp between (ago(1h) .. ago(30m))
Get only the latest records

To return only the latest records, use the top operator as in the following query which returns the latest 10 records
logged in the traces table:
traces | top 10 by timestamp
Filter records
To review only logs that match a given condition, use the where operator as in the following query that returns only
records in which the severityLevel value is higher than 0:
traces | where severityLevel > 0
String comparisons
When evaluating strings, you should usually use has instead of contains when looking for full tokens. has is
more efficient since it doesn't have to look-up for substrings.
Returned columns
Use project to narrow the set of columns being processed to only those you need:
traces
| project timestamp, severityLevel, client_City
| ...
While you can use extend to calculate values and create your own columns, it will typically be more efficient to filter
on a table column.
For example, the first query below that filters on operation_Name would be more efficient than the second which
creates a new subscription column and filters on it:
customEvents
| where split(operation_Name, "/")[2] == "acb"
customEvents
| extend subscription = split(operation_Name, "/")[2]
| where subscription == "acb"
Using joins
When using the join operator, choose the table with fewer rows to be on the left side of the query.
Next steps
To learn more about query best practices, see Query best practices.
Parse text data in Azure Monitor logs
Some log data collected by Azure Monitor will include multiple pieces of information in a single property. Parsing
this data into multiple properties make it easier to use in queries. A common example is a custom log that collects
an entire log entry with multiple values into a single property. By creating separate properties for the different
values, you can search and aggregate on each.
This article describes different options for parsing log data in Azure Monitor when the data is ingested and when
it's retrieved in a query, comparing the relative advantages for each.
Parsing methods
You can parse data either at ingestion time when the data is collected or at query time when analyzing the data
with a query. Each strategy has unique advantages as described below.
Parse data at collection time
When you parse data at collection time, you configure Custom Fields that create new properties in the table.
Queries don't have to include any parsing logic and simply use these properties as any other field in the table.
Advantages to this method include the following:
Easier to query the collected data since you don't need to include parse commands in the query.
Better query performance since the query doesn't need to perform parsing.
Disadvantages to this method include the following:
Must be defined in advance. Can't include data that's already been collected.
If you change the parsing logic, it will only apply to new data.
Fewer parsing options than available in queries.
Increases latency time for collecting data.
Errors can be difficult to handle.
Parse data at query time
When you parse data at query time, you include logic in your query to parse data into multiple fields. The actual
table itself isn't modified.
Advantages to this method include the following:
Applies to any data, including data that's already been collected.
Changes in logic can be applied immediately to all data.
Flexible parsing options including predefined logic for particular data structures.
Disadvantages to this method include the following:
Requires more complex queries. This can be mitigated by using functions to simulate a table.
Must replicate parsing logic in multiple queries. Can share some logic through functions.
Can create overhead when running complex logic against very large record sets (billions of records).
Parse data as it's collected

See Create custom fields in Azure Monitor for details on parsing data as it's collected. This creates custom
properties in the table that can be used by queries just like any other property.
Parse data in query using patterns

When the data you want to parse can be identified by a pattern repeated across records, you can use different
operators in the Kusto query language to extract the specific piece of data into one or more new properties.
Simple text patterns
Use the parse operator in your query to create one or more custom properties that can be extracted from a string
expression. You specify the pattern to be identified and the names of the properties to create. This is particularly
useful for data with key-value strings with a form similar to key=value.
Consider a custom log with data in the following format.
Time=2018-03-10 01:34:36 Event Code=207 Status=Success Message=Client 05a26a97-272a-4bc9-8f64-269d154b0e39

connected
Time=2018-03-10 01:33:33 Event Code=208 Status=Warning Message=Client ec53d95c-1c88-41ae-8174-92104212de5d
disconnected
Time=2018-03-10 01:35:44 Event Code=209 Status=Success Message=Transaction 10d65890-b003-48f8-9cfc-
9c74b51189c8 succeeded
Time=2018-03-10 01:38:22 Event Code=302 Status=Error Message=Application could not connect to database
Time=2018-03-10 01:31:34 Event Code=303 Status=Error Message=Application lost connection to database
The following query would parse this data into individual properties. The line with project is added to only return
the calculated properties and not RawData, which is the single property holding the entire entry from the custom
log.
MyCustomLog_CL
| parse RawData with * "Time=" EventTime " Event Code=" Code " Status=" Status " Message=" Message
| project EventTime, Code, Status, Message
Following is another example that breaks out the user name of a UPN in the AzureActivity table.
AzureActivity
| parse Caller with UPNUserPart "@" *
| where UPNUserPart != "" //Remove non UPN callers (apps, SPNs, etc)
| distinct UPNUserPart, Caller
Regular expressions
If your data can be identified with a regular expression, you can use functions that use regular expressions to
extract individual values. The following example uses extract to break out the UPN field from AzureActivity
records and then return distinct users.
AzureActivity
| extend UPNUserPart = extract("([a-z.]*)@", 1, Caller)
| distinct UPNUserPart, Caller
To enable efficient parsing at large scale, Azure Monitor uses re2 version of Regular Expressions, which is similar
but not identical to some of the other regular expression variants. Refer to the re2 expression syntax for details.
Parse delimited data in a query

Delimited data separates fields with a common character such as a comma in a CSV file. Use the split function to
parse delimited data using a delimiter that you specify. You can use this with extend operator to return all fields in
the data or to specify individual fields to be included in the output.
NOTE
Since split returns a dynamic object, the results may need to be explicitly cast to data types such as string to be used in
operators and filters.
Consider a custom log with data in the following CSV format.
2018-03-10 01:34:36, 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected

2018-03-10 01:33:33, 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2018-03-10 01:35:44, 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2018-03-10 01:38:22, 302,Error,Application could not connect to database
2018-03-10 01:31:34, 303,Error,Application lost connection to database
The following query would parse this data and summarize by two of the calculated properties. The first line splits
the RawData property into a string array. Each of the next lines gives a name to individual properties and adds
them to the output using functions to convert them to the appropriate data type.
MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend EventTime = todatetime(CSVFields[0])
| extend Code = toint(CSVFields[1])
| extend Status = tostring(CSVFields[2])
| extend Message = tostring(CSVFields[3])
| where getyear(EventTime) == 2018
| summarize count() by Status,Code
Parse predefined structures in a query

If your data is formatted in a known structure, you may be able to use one of the functions in the Kusto query
language for parsing predefined structures:
JSON
XML
IPv4
URL
URL query
File path
User agent
Version string
The following example query parses the Properties field of the AzureActivity table, which is structured in JSON. It
saves the results to a dynamic property called parsedProp, which includes the individual named value in the
JSON. These values are used to filter and summarize the query results.
AzureActivity
| extend parsedProp = parse_json(Properties)
| where parsedProp.isComplianceCheck == "True"
| summarize count() by ResourceGroup, tostring(parsedProp.tags.businessowner)
These parsing functions can be processor intensive, so they should be used only when your query uses multiple
properties from the formatted data. Otherwise, simple pattern matching processing will be faster.
The following example shows the breakdown of domain controller TGT Preauth type. The type exists only in the
EventData field, which is an XML string, but no other data from this field is needed. In this case, parse is used to
pick out the required piece of data.
SecurityEvent
| parse EventData with * 'PreAuthType">' PreAuthType '</Data>' *
| summarize count() by PreAuthType
Use function to simulate a table

You may have multiple queries that perform the same parsing of a particular table. In this case, create a function
that returns the parsed data instead of replicating the parsing logic in each query. You can then use the function
alias in place of the original table in other queries.
Consider the comma-delimited custom log example above. In order to use the parsed data in multiple queries,
create a function using the following query and save it with the alias MyCustomCSVLog.
MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend DateTime = tostring(CSVFields[0])
| extend Code = toint(CSVFields[1])
| extend Status = tostring(CSVFields[2])
| extend Message = tostring(CSVFields[3])
You can now use the alias MyCustomCSVLog in place of the actual table name in queries like the following.
MyCustomCSVLog
| summarize count() by Status,Code
Next steps
Automate Azure Monitor log processes with the
connector for Microsoft Flow
Microsoft Flow allows you to create automated workflows using hundreds of actions for a variety of services.
Output from one action can be used as input to another allowing you to create integration between different
services. The Azure Log Analytics connector for Microsoft Flow allow you to build workflows that include data
retrieved by log queries from a Log Analytics workspace in Azure Monitor.
NOTE
For example, you can use Microsoft Flow to use Azure Monitor log data in an email notification from Office 365,
create a bug in Azure DevOps, or post a Slack message. You can trigger a workflow by a simple schedule or from
some action in a connected service such as when a mail or a tweet is received.
The tutorial in this article shows you how to create a flow that automatically sends the results of an Azure Monitor
log query by email, just one example of how you can use the Log Analytics connector in Microsoft Flow.
Step 1: Create a flow

1. Sign in to Microsoft Flow, and select My Flows.
2. Click + Create from blank.
Step 2: Create a trigger for your flow

1. Click Search hundreds of connectors and triggers.
2. Type Schedule in the search box.
3. Select Schedule, and then select Schedule - Recurrence.
4. In the Frequency box select Day and in the Interval box, enter 1.
Step 3: Add a Log Analytics action

1. Click + New step, and then click Add an action.
2. Search for Log Analytics.
3. Click Azure Log Analytics – Run query and visualize results.
Step 4: Configure the Log Analytics action

1. Specify the details for your workspace including the Subscription ID, Resource Group, and Workspace
Name.
2. Add the following log query to the Query window. This is only a sample query, and you can replace with
any other that returns data.
Event
| where TimeGenerated > ago(1day)
| summarize count() by Computer
| sort by Computer
3. Select HTML Table for the Chart Type.

Step 5: Configure the flow to send email
1. Click New step, and then click + Add an action.
2. Search for Office 365 Outlook.
3. Click Office 365 Outlook – Send an email.
4. Specify the email address of a recipient in the To window and a subject for the email in Subject.
5. Click anywhere in the Body box. A Dynamic content window opens with values from previous actions.
6. Select Body. This is the results of the query in the Log Analytics action.
7. Click Show advanced options.
8. In the Is HTML box, select Yes.
Step 6: Save and test your flow

1. In the Flow name box, add a name for your flow, and then click Create flow.
2. The flow is now created and will run after a day which is the schedule you specified.
3. To immediately test the flow, click Run Now and then Run flow.
4. When the flow completes, check the mail of the recipient that you specified. You should have received a mail
with a body similar to the following:
Next steps
Learn more about log queries in Azure Monitor.
Automate Azure Application Insights processes with
the connector for Microsoft Flow
Do you find yourself repeatedly running the same queries on your telemetry data to check that your service is
functioning properly? Are you looking to automate these queries for finding trends and anomalies and then build
your own workflows around them? The Azure Application Insights connector for Microsoft Flow is the right tool
for these purposes.
With this integration, you can now automate numerous processes without writing a single line of code. After you
create a flow by using an Application Insights action, the flow automatically runs your Application Insights
Analytics query.
You can add additional actions as well. Microsoft Flow makes hundreds of actions available. For example, you can
use Microsoft Flow to automatically send an email notification or create a bug in Azure DevOps. You can also use
one of the many templates that are available for the connector for Microsoft Flow. These templates speed up the
process of creating a flow.
Create a flow for Application Insights

In this tutorial, you will learn how to create a flow that uses the Analytics autocluster algorithm to group attributes
in the data for a web application. The flow automatically sends the results by email, just one example of how you
can use Microsoft Flow and Application Insights Analytics together.
Step 1: Create a flow
1. Sign in to Microsoft Flow, and then select My Flows.
2. Click New then Scheduled—from blank.
Step 2: Create a trigger for your flow

1. In the popup Build a scheduled flow, fill out the name of your flow and how often you want your flow to
run.
2. Click Create.
Step 3: Add an Application Insights action
1. Search for Application Insights.
2. Click Azure Application Insights - Visualize Analytics query.
3. Select New step.
Step 4: Connect to an Application Insights resource
To complete this step, you need an application ID and an API key for your resource. You can retrieve them from the
Azure portal, as shown in the following diagram:
Provide a name for your connection, along with the application ID and API key.
If the connection box does not show up right away and instead goes straight to entering the query, click the ellipses
at the top right of the box. Then select my connections or use an existing one.
Click Create.
Step 5: Specify the Analytics query and chart type
This example query selects the failed requests within the last day and correlates them with exceptions that
occurred as part of the operation. Analytics correlates them based on the operation_Id identifier. The query then
segments the results by using the autocluster algorithm.
When you create your own queries, verify that they are working properly in Analytics before you add it to your
flow.
Add the following Analytics query, and select the HTML table chart type. Then select New step.
requests
| where success == "False"
| project name, operation_Id
| join ( exceptions
| project problemId, outerMessage, operation_Id
) on operation_Id
| evaluate autocluster()
Step 6: Configure the flow to send email

1. Search for Office 365 Outlook.
2. Click Office 365 Outlook - Send an email.
3. In the Send an email window:
a. Type the email address of the recipient.
b. Type a subject for the email.
c. Click anywhere in the Body box and then, on the dynamic content menu that opens at the right, select
Body.
e. Select Show advanced options
4. On the dynamic content menu:
a. Select Attachment Name.
b. Select Attachment Content.
c. In the Is HTML box, select Yes.
Step 7: Save and test your flow
Click Save.
You can wait for the trigger to run this action, or can click on Test in the top.
After selecting Test:
1. Select I'll perform the trigger action.
2. Select Run Flow.
When the flow runs, the recipients you have specified in the email list receive an email message like the one below.
Next steps
Automate Application Insights processes by using
Logic Apps
Do you find yourself repeatedly running the same queries on your telemetry data to check whether your service is
functioning properly? Are you looking to automate these queries for finding trends and anomalies and then build
your own workflows around them? The Azure Application Insights connector for Logic Apps is the right tool for
this purpose.
With this integration, you can automate numerous processes without writing a single line of code. You can create a
logic app with the Application Insights connector to quickly automate any Application Insights process.
You can add additional actions as well. The Logic Apps feature of Azure App Service makes hundreds of actions
available. For example, by using a logic app, you can automatically send an email notification or create a bug in
Azure DevOps. You can also use one of the many available templates to help speed up the process of creating your
logic app.
Create a logic app for Application Insights

In this tutorial, you learn how to create a logic app that uses the Analytics autocluster algorithm to group attributes
in the data for a web application. The flow automatically sends the results by email, just one example of how you
can use Application Insights Analytics and Logic Apps together.
Step 1: Create a logic app
2. Click Create a resource, select Web + Mobile, and then select Logic App.
Step 2: Create a trigger for your logic app

1. In the Logic App Designer window, under Start with a common trigger, select Recurrence.
2. In the Interval box, type 1 and then,Frequency box, select Day.
Step 3: Add an Application Insights action

1. Click New step.
2. In the Choose an action search box, type Azure Application Insights.
3. Under Actions, click Azure Application Insights - Visualize Analytics query.
Step 4: Connect to an Application Insights resource
To complete this step, you need an application ID and an API key for your resource. You can retrieve them from the
Azure portal, as shown in the following diagram:
Provide a name for your connection, the application ID, and the API key.
Step 5: Specify the Analytics query and chart type

In the following example, the query selects the failed requests within the last day and correlates them with
exceptions that occurred as part of the operation. Analytics correlates the failed requests, based on the
operation_Id identifier. The query then segments the results by using the autocluster algorithm.
When you create your own queries, verify that they are working properly in Analytics before you add it to your
flow.
1. In the Query box, add the following Analytics query:
requests
| where success == "False"
| project name, operation_Id
| join ( exceptions
| project problemId, outerMessage, operation_Id
) on operation_Id
| evaluate autocluster()
2. In the Chart Type box, select Html Table.
Step 6: Configure the logic app to send email

1. Click New step.
2. In the search box, type Office 365 Outlook.
3. Click Office 365 Outlook - Send an email.
4. In the Send an email window, do the following:
a. Type the email address of the recipient.
b. Type a subject for the email.
c. Click anywhere in the Body box and then, on the dynamic content menu that opens at the right, select
Body.
d. Click the Add new parameter drop down and select Attachments and Is HTML.
5. On the dynamic content menu, do the following:
a. Select Attachment Name.
b. Select Attachment Content.
c. In the Is HTML box, select Yes.
Step 7: Save and test your logic app
Click Save to save your changes.
You can wait for the trigger to run the logic app, or you can run the logic app immediately by selecting Run.
When your logic app runs, the recipients you specified in the email list will receive an email that looks like the
following:
Next steps
Learn more about Logic Apps.
Azure Monitoring REST API walkthrough
NOTE
PowerShell.
This article shows you how to perform authentication so your code can use the Microsoft Azure Monitor REST
API Reference.
The Azure Monitor API makes it possible to programmatically retrieve the available default metric definitions,
granularity, and metric values. The data can be saved in a separate data store such as Azure SQL Database, Azure
Cosmos DB, or Azure Data Lake. From there additional analysis can be performed as needed.
Besides working with various metric data points, the Monitor API also makes it possible to list alert rules, view
activity logs, and much more. For a full list of available operations, see the Microsoft Azure Monitor REST API
Reference.
Authenticating Azure Monitor requests

The first step is to authenticate the request.
All the tasks executed against the Azure Monitor API use the Azure Resource Manager authentication model.
Therefore, all requests must be authenticated with Azure Active Directory (Azure AD ). One approach to
authenticate the client application is to create an Azure AD service principal and retrieve the authentication (JWT)
token. The following sample script demonstrates creating an Azure AD service principal via PowerShell. For a
more detailed walk-through, refer to the documentation on using Azure PowerShell to create a service principal to
access resources. It is also possible to create a service principal via the Azure portal .
$subscriptionId = "{azure-subscription-id}"
$resourceGroupName = "{resource-group-name}"
# Authenticate to a specific Azure subscription.

Connect-AzAccount -SubscriptionId $subscriptionId
# Password for the service principal

$pwd = "{service-principal-password}"
$secureStringPassword = ConvertTo-SecureString -String $pwd -AsPlainText -Force
# Create a new Azure AD application

$azureAdApplication = New-AzADApplication `
-DisplayName "My Azure Monitor" `
-HomePage "https://localhost/azure-monitor" `
-IdentifierUris "https://localhost/azure-monitor" `
-Password $secureStringPassword
# Create a new service principal associated with the designated application

New-AzADServicePrincipal -ApplicationId $azureAdApplication.ApplicationId
# Assign Reader role to the newly created service principal

New-AzRoleAssignment -RoleDefinitionName Reader `
-ServicePrincipalName $azureAdApplication.ApplicationId.Guid
To query the Azure Monitor API, the client application should use the previously created service principal to
authenticate. The following example PowerShell script shows one approach, using the Active Directory
Authentication Library (ADAL ) to obtain the JWT authentication token. The JWT token is passed as part of an
HTTP Authorization parameter in requests to the Azure Monitor REST API.
$azureAdApplication = Get-AzADApplication -IdentifierUri "https://localhost/azure-monitor"
$subscription = Get-AzSubscription -SubscriptionId $subscriptionId
$clientId = $azureAdApplication.ApplicationId.Guid
$tenantId = $subscription.TenantId
$authUrl = "https://login.microsoftonline.com/${tenantId}"
$AuthContext = [Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext]$authUrl
$cred = New-Object -TypeName Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential -ArgumentList
($clientId, $pwd)
$result = $AuthContext.AcquireTokenAsync("https://management.core.windows.net/",
$cred).GetAwaiter().GetResult()
# Build an array of HTTP header values

$authHeader = @{
'Content-Type'='application/json'
'Accept'='application/json'
'Authorization'=$result.CreateAuthorizationHeader()
}
After authenticating, queries can then be executed against the Azure Monitor REST API. There are two helpful
queries:
1. List the metric definitions for a resource
2. Retrieve the metric values
NOTE
For additional information on authenticating with the Azure REST API, please refer to the Azure REST API Reference.
Retrieve Metric Definitions (Multi-Dimensional API)
Use the Azure Monitor Metric definitions REST API to access the list of metrics that are available for a service.
Method: GET
Request URI:
https://management.azure.com/subscriptions/{subscriptionId }/resourceGroups/{resourceGroupName}/providers/
{resourceProviderNamespace}/{resourceType}/{resourceName}/providers/microsoft.insights/metricDefinitions?
api-version={apiVersion}
For example, to retrieve the metric definitions for an Azure Storage account, the request would appear as follows:
$request = "https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/microsoft.insights/metricDefi
nitions?api-version=2018-01-01"
Invoke-RestMethod -Uri $request `

-Headers $authHeader `
-Method Get `
-OutFile ".\contosostorage-metricdef-results.json" `
-Verbose
NOTE
To retrieve metric definitions using the multi-dimensional Azure Monitor metrics REST API, use "2018-01-01" as the API
version.
The resulting JSON response body would be similar to the following example: (Note that the second metric has
dimensions)
{
"value": [
{
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/microsoft.insights/metricdefi
nitions/UsedCapacity",
"resourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage",
"namespace": "Microsoft.Storage/storageAccounts",
"category": "Capacity",
"name": {
"value": "UsedCapacity",
"localizedValue": "Used capacity"
},
"isDimensionRequired": false,
"unit": "Bytes",
"primaryAggregationType": "Average",
"supportedAggregationTypes": [
"Total",
"Average",
"Minimum",
"Maximum"
],
"metricAvailabilities": [
{
"timeGrain": "PT1H",
"retention": "P93D"
},
{
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"timeGrain": "P1D",
"retention": "P93D"
}
]
},
{
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/microsoft.insights/metricdefi
nitions/Transactions",
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage",
"category": "Transaction",
"name": {
"value": "Transactions",
"localizedValue": "Transactions"
},
"isDimensionRequired": false,
"unit": "Count",
"primaryAggregationType": "Total",
"supportedAggregationTypes": [
"Total"
],
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"retention": "P93D"
},
{
"timeGrain": "P1D",
"retention": "P93D"
}
],
"dimensions": [
{
"value": "ResponseType",
"localizedValue": "Response type"
"localizedValue": "Response type"
},
{
"value": "GeoType",
"localizedValue": "Geo type"
},
{
"value": "ApiName",
"localizedValue": "API name"
}
]
},
...
]
}
Retrieve Dimension Values (Multi-Dimensional API)

Once the available metric definitions are known, there may be some metrics that have dimensions. Before
querying for the metric you may want to discover what the range of values a dimension has. Based on these
dimension values you can then choose to filter or segment the metrics based on dimension values while querying
for metrics. Use the Azure Monitor Metrics REST API to achieve this.
Use the metric’s name ‘value’ (not the ‘localizedValue’) for any filtering requests . If no filters are specified, the
default metric is returned. The usage of this API only allows one dimension to have a wildcard filter.
NOTE
To retrieve dimension values using the Azure Monitor REST API, use "2018-01-01" as the API version.
Method: GET
Request URI: https://management.azure.com/subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/{resource-provider-namespace}/{resource-type}/{resource-
name}/providers/microsoft.insights/metrics?
metricnames={metric}&timespan={starttime/endtime}&$filter={filter }&resultType=metadata&api-
version={apiVersion}
For example, to retrieve the list of dimension values that were emitted for the 'API Name dimension' for the
'Transactions' metric, where the GeoType dimension = 'Primary' during the specified time range, the request
would be as follows:
$filter = "APIName eq '*' and GeoType eq 'Primary'"

walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/microsoft.insights/metrics?
metricnames=Transactions&timespan=2018-03-01T00:00:00Z/2018-03-
02T00:00:00Z&resultType=metadata&`$filter=${filter}&api-version=2018-01-01"
-Method Get `
-OutFile ".\contosostorage-dimension-values.json" `
-Verbose
The resulting JSON response body would be similar to the following example:
{
"timespan": "2018-03-01T00:00:00Z/2018-03-02T00:00:00Z",
"value": [
{
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/Microsoft.Insights/metrics/Tr
ansactions",
"type": "Microsoft.Insights/metrics",
"name": {
},
"unit": "Count",
"timeseries": [
{
"metadatavalues": [
{
"name": {
"value": "apiname",
"localizedValue": "apiname"
},
"value": "DeleteBlob"
}
]
},
{
"metadatavalues": [
{
"name": {
"value": "apiname",
},
"value": "SetBlobProperties"
}
]
},
...
]
}
],
"resourceregion": "eastus"
}
Retrieve Metric Values (Multi-Dimensional API)

Once the available metric definitions and possible dimension values are known, it is then possible to retrieve the
related metric values. Use the Azure Monitor Metrics REST API to achieve this.
Use the metric’s name ‘value’ (not the ‘localizedValue’) for any filtering requests. If no dimension filters are
specified, the rolled up aggregated metric is returned. If a metric query returns multiple timeseries, then you can
use the 'Top' and 'OrderBy' query parameters to return an limited ordered list of timeseries.
NOTE
To retrieve multi-dimensional metric values using the Azure Monitor REST API, use "2018-01-01" as the API version.
Method: GET
Request URI: https://management.azure.com/subscriptions/*{subscription-id}*/resourceGroups/*{resource-
group-name}*/providers/*{resource-provider-namespace}*/*{resource-type}*/*{resource-
name}*/providers/microsoft.insights/metrics?metricnames=*{metric}*&timespan=*
{starttime/endtime}*&$filter=*{filter}*&interval=*{timeGrain}*&aggregation=*{aggreation}*&api-version=*
{apiVersion}*
For example, to retrieve the top 3 APIs, in descending value, by the number of 'Transactions' during a 5 min range,
where the GeotType was 'Primary', the request would be as follows:
$filter = "APIName eq '*' and GeoType eq 'Primary'"

walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/microsoft.insights/metrics?
metricnames=Transactions&timespan=2018-03-01T02:00:00Z/2018-03-
01T02:05:00Z&`$filter=${filter}&interval=PT1M&aggregation=Total&top=3&orderby=Total desc&api-version=2018-01-
01"
-Method Get `
-OutFile ".\contosostorage-metric-values.json" `
-Verbose
{
"cost": 0,
"timespan": "2018-03-01T02:00:00Z/2018-03-01T02:05:00Z",
"interval": "PT1M",
"value": [
{
walkthrough/providers/Microsoft.Storage/storageAccounts/ContosoStorage/providers/Microsoft.Insights/metrics/Tr
ansactions",
"name": {
},
"unit": "Count",
"timeseries": [
{
"metadatavalues": [
{
"name": {
"value": "apiname",
},
"value": "GetBlobProperties"
}
],
"data": [
{
"timeStamp": "2017-09-19T02:00:00Z",
"total": 2
},
{
"timeStamp": "2017-09-19T02:01:00Z",
"total": 1
},
{
"timeStamp": "2017-09-19T02:02:00Z",
"total": 3
},
{
"timeStamp": "2017-09-19T02:03:00Z",
"total": 7
},
{
"timeStamp": "2017-09-19T02:04:00Z",
"total": 2
}
]
},
...
]
}
],
"resourceregion": "eastus"
}
Retrieve metric definitions

Use the Azure Monitor Metric definitions REST API to access the list of metrics that are available for a service.
Method: GET
Request URI:
https://management.azure.com/subscriptions/{subscriptionId }/resourceGroups/{resourceGroupName}/providers/
{resourceProviderNamespace}/{resourceType}/{resourceName}/providers/microsoft.insights/metricDefinitions?
api-version={apiVersion}
For example, to retrieve the metric definitions for an Azure Logic App, the request would appear as follows:
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metricDefinitions?
api-version=2016-03-01"

-Method Get `
-OutFile ".\contosotweets-metricdef-results.json" `
-Verbose
NOTE
To retrieve metric definitions using the Azure Monitor REST API, use "2016-03-01" as the API version.
{
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metricdefinitions",
"value": [
{
"name": {
"value": "RunsStarted",
"localizedValue": "Runs Started"
},
"category": "AllMetrics",
"startTime": "0001-01-01T00:00:00Z",
"endTime": "0001-01-01T00:00:00Z",
"unit": "Count",
"primaryAggregationType": "Total",
"resourceUri": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets",
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets",
{
"retention": "P30D",
"location": null,
"blobLocation": null
},
{
"retention": "P30D",
"location": null,
"blobLocation": null
}
],
"properties": null,
"dimensions": null,
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metricdefinitions/R
unsStarted",
"supportedAggregationTypes": [ "None", "Average", "Minimum", "Maximum", "Total", "Count" ]
}
]
}
For more information, see the List the metric definitions for a resource in Azure Monitor REST API
documentation.
Retrieve metric values

Once the available metric definitions are known, it is then possible to retrieve the related metric values. Use the
metric’s name ‘value’ (not the ‘localizedValue’) for any filtering requests (for example, retrieve the ‘CpuTime’ and
‘Requests’ metric data points). If no filters are specified, the default metric is returned.
NOTE
To retrieve metric values using the Azure Monitor REST API, use "2016-09-01" as the API version.
Method: GET
Request URI: https://management.azure.com/subscriptions/*{subscription-id}*/resourceGroups/*{resource-
group-name}*/providers/*{resource-provider-namespace}*/*{resource-type}*/*{resource-
name}*/providers/microsoft.insights/metrics?$filter=*{filter}*&api-version=*{apiVersion}*
For example, to retrieve the RunsSucceeded metric data points for the given time range and for a time grain of 1
hour, the request would be as follows:
$filter = "(name.value eq 'RunsSucceeded') and aggregationType eq 'Total' and startTime eq 2017-08-18T19:00:00

and endTime eq 2017-08-18T23:00:00 and timeGrain eq duration'PT1H'"
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metrics?
`$filter=${filter}&api-version=2016-09-01"
-Method Get `
-OutFile ".\contosotweets-metrics-results.json" `
-Verbose
{
"value": [
{
"data": [
{
"timeStamp": "2017-08-18T19:00:00Z",
"total": 0.0
},
{
"timeStamp": "2017-08-18T20:00:00Z",
"total": 159.0
},
{
"timeStamp": "2017-08-18T21:00:00Z",
"total": 174.0
},
{
"timeStamp": "2017-08-18T22:00:00Z",
"total": 97.0
}
],
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/Microsoft.Insights/metrics/RunsSucceed
ed",
"name": {
"value": "RunsSucceeded",
"localizedValue": "Runs Succeeded"
},
"unit": "Count"
}
]
}
To retrieve multiple data or aggregation points, add the metric definition names and aggregation types to the filter,
as seen in the following example:
$filter = "(name.value eq 'ActionsCompleted' or name.value eq 'RunsSucceeded') and (aggregationType eq 'Total'
or aggregationType eq 'Average') and startTime eq 2017-08-18T21:00:00 and endTime eq 2017-08-18T21:30:00 and
timeGrain eq duration'PT1M'"
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metrics?
`$filter=${filter}&api-version=2016-09-01"
-Method Get `
-OutFile ".\contosotweets-metrics-multiple-results.json" `
-Verbose
{
"value": [
{
"data": [
{
"timeStamp": "2017-08-18T21:03:00Z",
"total": 5.0,
"average": 1.0
},
{
"timeStamp": "2017-08-18T21:04:00Z",
"total": 7.0,
"average": 1.0
}
],
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/Microsoft.Insights/metrics/ActionsComp
leted",
"name": {
"value": "ActionsCompleted",
"localizedValue": "Actions Completed "
},
"unit": "Count"
},
{
"data": [
{
"timeStamp": "2017-08-18T21:03:00Z",
"total": 5.0,
"average": 1.0
},
{
"timeStamp": "2017-08-18T21:04:00Z",
"total": 7.0,
"average": 1.0
}
],
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/Microsoft.Insights/metrics/RunsSucceed
ed",
"name": {
"value": "RunsSucceeded",
"localizedValue": "Runs Succeeded"
},
"unit": "Count"
}
]
}
Use ARMClient
An additional approach is to use ARMClient on your Windows machine. ARMClient handles the Azure AD
authentication (and resulting JWT token) automatically. The following steps outline the use of ARMClient for
retrieving metric data:
1. Install Chocolatey and ARMClient.
2. In a terminal window, type armclient.exe login. Doing so prompts you to log in to Azure.
3. Type armclient GET [your_resource_id ]/providers/microsoft.insights/metricdefinitions?api-version=2016 -03 -
01
4. Type armclient GET [your_resource_id ]/providers/microsoft.insights/metrics?api-version=2016 -09 -01
For example, in order to retrieve the metric definitions for a specific Logic App, issue the following command:
armclient GET /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets/providers/microsoft.insights/metricDefinitions?
Retrieve the resource ID

Using the REST API can really help to understand the available metric definitions, granularity, and related values.
That information is helpful when using the Azure Management Library.
For the preceding code, the resource ID to use is the full path to the desired Azure resource. For example, to query
against an Azure Web App, the resource ID would be:
/subscriptions/{subscription-id }/resourceGroups/{resource-group -name}/providers/Microsoft.Web/sites/{site-
name}/
The following list contains a few examples of resource ID formats for various Azure resources:
IoT Hub - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.Devices/IotHubs/{iot-hub -name}
Elastic SQL Pool - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.Sql/servers/{pool-db }/elasticpools/{sql-pool-name}
SQL Database (v12) - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}
Service Bus - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.ServiceBus/{namespace}/{servicebus-name}
Virtual machine scale sets - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.Compute/virtualMachineScaleSets/{vm -name}
VMs - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.Compute/virtualMachines/{vm -name}
Event Hubs - /subscriptions/{subscription-id }/resourceGroups/{resource-group -
name}/providers/Microsoft.EventHub/namespaces/{eventhub -namespace}
There are alternative approaches to retrieving the resource ID, including using Azure Resource Explorer, viewing
the desired resource in the Azure portal, and via PowerShell or the Azure CLI.
Azure Resource Explorer
To find the resource ID for a desired resource, one helpful approach is to use the Azure Resource Explorer tool.
Navigate to the desired resource and then look at the ID shown, as in the following screenshot:
Azure portal
The resource ID can also be obtained from the Azure portal. To do so, navigate to the desired resource and then
select Properties. The Resource ID is displayed in the Properties section, as seen in the following screenshot:
Azure PowerShell
The resource ID can be retrieved using Azure PowerShell cmdlets as well. For example, to obtain the resource ID
for an Azure Logic App, execute the Get-AzureLogicApp cmdlet, as in the following example:
Get-AzLogicApp -ResourceGroupName azmon-rest-api-walkthrough -Name contosotweets
The result should be similar to the following example:

Id : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/azmon-rest-api-
walkthrough/providers/Microsoft.Logic/workflows/ContosoTweets
Name : ContosoTweets
Type : Microsoft.Logic/workflows
Location : centralus
ChangedTime : 8/21/2017 6:58:57 PM
CreatedTime : 8/18/2017 7:54:21 PM
AccessEndpoint : https://prod-08.centralus.logic.azure.com:443/workflows/f3a91b352fcc47e6bff989b85446c5db
State : Enabled
Definition : {$schema, contentVersion, parameters, triggers...}
Parameters : {[$connections, Microsoft.Azure.Management.Logic.Models.WorkflowParameter]}
SkuName :
AppServicePlan :
PlanType :
PlanId :
Version : 08586982649483762729
Azure CLI
To retrieve the resource ID for an Azure Storage account using the Azure CLI, execute the
az storage account show command, as shown in the following example:
az storage account show -g azmon-rest-api-walkthrough -n contosotweets2017
The result should be similar to the following example:
{
"accessTier": null,
"creationTime": "2017-08-18T19:58:41.840552+00:00",
"customDomain": null,
"enableHttpsTrafficOnly": false,
"encryption": null,
walkthrough/providers/Microsoft.Storage/storageAccounts/contosotweets2017",
"identity": null,
"kind": "Storage",
"lastGeoFailoverTime": null,
"location": "centralus",
"name": "contosotweets2017",
"networkAcls": null,
"primaryEndpoints": {
"blob": "https://contosotweets2017.blob.core.windows.net/",
"file": "https://contosotweets2017.file.core.windows.net/",
"queue": "https://contosotweets2017.queue.core.windows.net/",
"table": "https://contosotweets2017.table.core.windows.net/"
},
"primaryLocation": "centralus",
"provisioningState": "Succeeded",
"resourceGroup": "azmon-rest-api-walkthrough",
"secondaryEndpoints": null,
"secondaryLocation": "eastus2",
"sku": {
"name": "Standard_GRS",
"tier": "Standard"
},
"statusOfPrimary": "available",
"statusOfSecondary": "available",
"tags": {},
"type": "Microsoft.Storage/storageAccounts"
}
NOTE
Azure Logic Apps are not yet available via the Azure CLI, thus an Azure Storage account is shown in the preceding example.
Retrieve activity log data

In addition to metric definitions and related values, it is also possible to use the Azure Monitor REST API to
retrieve additional interesting insights related to Azure resources. As an example, it is possible to query activity log
data. The following sample demonstrates using the Azure Monitor REST API to query activity log data within a
specific date range for an Azure subscription:
$apiVersion = "2015-04-01"
$filter = "eventTimestamp ge '2017-08-18' and eventTimestamp le '2017-08-19'and eventChannels eq 'Admin,
Operation'"
xxxxxxxxxxxx/providers/microsoft.insights/eventtypes/management/values?api-
version=${apiVersion}&`$filter=${filter}"
-Method Get `
-Verbose
Next steps
Review the Overview of Monitoring.
View the Supported metrics with Azure Monitor.
Review the Microsoft Azure Monitor REST API Reference.
Review the Azure Management Library.
Create custom views by using View Designer in
Azure Monitor
By using View Designer in Azure Monitor, you can create a variety of custom views in the Azure portal that can
help you visualize data in your Log Analytics workspace. This article presents an overview of View Designer and
procedures for creating and editing custom views.
NOTE
For more information about View Designer, see:

Tile reference: Provides a reference guide to the settings for each of the available tiles in your custom views.
Visualization part reference: Provides a reference guide to the settings for the visualization parts that are
available in your custom views.
Concepts
Views are displayed in the Azure Monitor Overview page in the Azure portal. Open this page from the Azure
Monitor menu by clicking More under the Insights section. The tiles in each custom view are displayed
alphabetically, and the tiles for the monitoring solutions are installed the same workspace.
The views that you create with View Designer contain the elements that are described in the following table:
PART DESCRIPTION
PART DESCRIPTION
Tiles Are displayed on your Azure Monitor Overview page. Each

tile displays a visual summary of the custom view it
represents. Each tile type provides a different visualization of
your records. You select a tile to display a custom view.
Custom view Displayed when you select a tile. Each view contains one or
more visualization parts.
Visualization parts Present a visualization of data in the Log Analytics workspace

based on one or more log queries. Most parts include a
header, which provides a high-level visualization, and a list,
which displays the top results. Each part type provides a
different visualization of the records in the Log Analytics
workspace. You select elements in the part to perform a log
query that provides detailed records.
Required permissions
You require at least contributor level permissions in the Log Analytics workspace to create or modify views. If you
don't have this permission, then the View Designer option won't be displayed in the menu.
Work with an existing view

Views that were created with View Designer display the following options:
The options are described in the following table:
OPTION DESCRIPTION
Refresh Refreshes the view with the latest data.
Logs Opens the Log Analytics to analyze data with log queries.
Edit Opens the view in View Designer to edit its contents and
configuration.
Clone Creates a new view and opens it in View Designer. The name
of the new view is the same as the original name, but with
Copy appended to it.
Date range Set the date and time range filter for the data that's included
in the view. This date range is applied before any date ranges
set in queries in the view.
+ Define a custom filter that's defined for the view.
Create a new view

You can create a new view in View Designer by selecting View Designer in the menu of your Log Analytics
workspace.
Work with View Designer

You use View Designer to create new views or edit existing ones.
View Designer has three panes:
Design: Contains the custom view that you're creating or editing.
Controls: Contains the tiles and parts that you add to the Design pane.
Properties: Displays the properties of the tiles or selected parts.
Configure the view tile

A custom view can have only a single tile. To view the current tile or select an alternate one, select the Tile tab in
the Control pane. The Properties pane displays the properties of the current tile.
You can configure the tile properties according to the information in the Tile reference and then click Apply to
save the changes.
Configure the visualization parts
A view can include any number of visualization parts. To add parts to a view, select the View tab, and then select a
visualization part. The Properties pane displays the properties of the selected part.
You can configure the view properties according to the information in the Visualization part reference and then
click Apply to save the changes.
Views have only one row of visualization parts. You can rearrange the existing parts by dragging them to a new
location.
You can remove a visualization part from the view by selecting the X at the top right of the part.
Menu options
The options for working with views in edit mode are described in the following table.
OPTION DESCRIPTION
Save Saves your changes and closes the view.
Cancel Discards your changes and closes the view.
Delete View Deletes the view.
Export Exports the view to an Azure Resource Manager template

that you can import into another workspace. The name of the
file is the name of the view, and it has an omsview extension.
Import Imports the omsview file that you exported from another
workspace. This action overwrites the configuration of the
existing view.
Clone Creates a new view and opens it in View Designer. The name
of the new view is the same as the original name, but with
Copy appended to it.
Next steps
Add Tiles to your custom view.
Add Visualization parts to your custom view.
Reference guide to View Designer tiles in Azure
Monitor
help you visualize data in your Log Analytics workspace. This article is a reference guide to the settings for the
tiles that are available in your custom views.
View Designer: Provides an overview of View Designer and procedures for creating and editing custom views.
Visualization part reference: Provides a reference guide to the settings for the visualization parts that are
available in your custom views.
The available View Designer tiles are described in the following table:
TILE DESCRIPTION
Number The count of records from a query.
Two numbers The counts of records from two different queries.
Donut A chart that's based on a query, with a summary value in the

center.
Line chart and callout A line chart that's based on a query, and a callout with a
summary value.
Line chart A line chart that's based on a query.
Two timelines A column chart with two series, each based on a separate
query.
The next sections describe the tile types and their properties in detail.
NOTE
Tiles in views are based on log queries in your Log Analytics workspace. They do not currently support cross resource
queries to retrieve data from Application Insights.
Number tile
The Number tile displays both the count of records from a log query and a label.
SETTING DESCRIPTION
Name The text that's displayed at the top of the tile.
Description The text that's displayed under the tile name.
Tile
Legend The text that's displayed under the value.
Query The query that's run. The count of the records that are
returned by the query is displayed.
Advanced > Data-flow verification
Enabled Select this link if data-flow verification should be enabled for

the tile. This approach provides an alternate message if data is
unavailable. You ordinarily use the approach to provide a
message during the temporary period when the view is
installed and the data becomes available.
Query The query that's run to determine whether data is available

for the view. If the query returns no results, a message is
displayed in place of the value of the main query.
Message The message that's displayed if the data-flow verification

query returns no data. If you provide no message, a
Performing Assessment status message is displayed.
Two Numbers tile

This tile displays the count of records from two different log queries and a label for each.
SETTING DESCRIPTION
First Tile
Second Tile
SETTING DESCRIPTION



Donut tile
The Donut tile displays a single number that summarizes a value column in a log query. The donut graphically
displays results of the top three records.
SETTING DESCRIPTION
Donut
Query The query that's run for the donut. The first property is a text
value, and the second property is a numeric value. This query
ordinarily uses the measure keyword to summarize results.
Donut > Center
Text The text that's displayed under the value inside the donut.
SETTING DESCRIPTION
Operation The operation that's performed on the value property to

summarize it as a single value.
Sum: Add the values of all records with the property
value.
Percentage: Percentage of the summed values from
records with the property value compared to the
summed values of all records.
Result values used in center operation Optionally, select the plus sign (+) to add one or more values.
The results of the query are limited to records with the
property values you specify. If no values are added, all records
are included in the query.
Donut > Additional options
Colors The color that's displayed for each of the three top properties.
To specify alternate colors for specific property values, use
Advanced Color Mapping.
Advanced Color Mapping Displays a color that represents specific property values. If the
value you specify is in the top three, the alternate color is
displayed instead of the standard color. If the property is not
in the top three, the color is not displayed.



Line chart tile

This tile is a line chart that displays multiple series from a log query over time.
SETTING DESCRIPTION
Line chart
Query The query that's run for the line chart. The first property is a
text value, and the second property is a numeric value. This
query ordinarily uses the measure keyword to summarize
results. If the query uses the interval keyword, the x-axis uses
this time interval. If the query doesn't use the interval
keyword, the x-axis uses hourly intervals.
Line chart > Y-axis
Use Logarithmic Scale Select this link to use a logarithmic scale for the y-axis.
Units Specify the units for the values returned by the query. This
information is used to display labels on the chart indicating
the value types and optionally for converting the values. The
Unit Type specifies the category of the unit and defines the
Current Unit Type values that are available. If you select a
value in Convert to then the numeric values are converted
from the Current Unit type to the Convert to type.
Custom label The text that's displayed for the y-axis next to the label for the
Unit type. If no label is specified, only the Unit type is
displayed.



Line chart and callout tile

This tile has both a line chart that displays multiple series from a log query over time and a callout with a
summarized value.
SETTING DESCRIPTION
Line chart
Query The query that's run for the line chart. The first property is a
text value, and the second property is a numeric value. This
query ordinarily uses the measure keyword to summarize
results. If the query uses the interval keyword, the x-axis uses
this time interval. If the query doesn't use the interval
keyword, the x-axis uses hourly intervals.
Line chart > Callout
Callout title The text that's displayed above the callout value.
Series name The series property value to be used as the callout value. If no
series is provided, all records from the query are used.

summarize it as a single value for the callout.
Average: The average of the values from all records.
Count: The count of all records that are returned by
the query.
Last sample: The value of the last interval that's
included in the chart.
Max: The maximum value of the intervals that are
Min: The minimum value of the intervals that are
Sum: The sum of the values from all records.
Line chart > Y-axis
Units Specify the units for the values to be returned by the query.
This information is used to display chart labels that indicate
the value types and, optionally, to convert the values. The
Unit type specifies the category of the unit and defines the
available Current Unit type values. If you select a value in
Convert to, the numeric values are converted from the
Current Unit type to the Convert to type.
SETTING DESCRIPTION
Custom label The text that's displayed for the y-axis next to the label for the
Unit type. If no label is specified, only the Unit type is
displayed.



Two timelines tile

The Two timelines tile displays the results of two log queries over time as column charts. A callout is displayed
for each series.
SETTING DESCRIPTION
First Chart
Legend The text that's displayed under the callout for the first series.
Color The color that's used for the columns in the first series.
Chart query The query that's run for the first series. The count of the
records over each time interval is represented by the chart
columns.
SETTING DESCRIPTION

the query.
Second chart
Legend The text that's displayed under the callout for the second
series.
Color The color that's used for the columns in the second series.
Chart Query The query that's run for the second series. The count of the
records over each time interval is represented by the chart
columns.

the query.



Next steps
Learn about log queries to support the queries in tiles.
Add visualization parts to your custom view.
Reference guide to View Designer visualization parts
in Azure Monitor
help you visualize data in your Log Analytics workspace. This article is a reference guide to the settings for the
visualization parts that are available in your custom views.
View Designer: Provides an overview of View Designer and procedures for creating and editing custom views.
Tile reference: Provides a reference to the settings for each available tile in your custom views.
The available View Designer tile types are described in the following table:
VIEW TYPE DESCRIPTION
List of queries Displays a list of log queries. You can select each query to
display its results.
Number and list The header displays a single number that shows a count of
records from a log query. The list displays the top ten results
from a query, with a graph that indicates the relative value of
a numeric column or its change over time.
Two numbers and list The header displays two numbers that show counts of
records from separate log queries. The list displays the top
ten results from a query, with a graph that indicates the
relative value of a numeric column or its change over time.
Donut and list The header displays a single number that summarizes a value
column in a log query. The donut graphically displays results
of the top three records.
Two timelines and list The header displays the results of two log queries over time
as column charts, with a callout that displays a single number
that summarizes a value column in a log query. The list
displays the top ten results from a query, with a graph that
indicates the relative value of a numeric column or its change
over time.
Information The header displays static text and an optional link. The list
displays one or more items with a static title and text.
Line chart, callout, and list The header displays a line chart, with multiple series from a
log query over time and a callout with a summarized value.
The list displays the top ten results from a query, with a
graph that indicates the relative value of a numeric column or
its change over time.
VIEW TYPE DESCRIPTION
Line chart and list The header displays a line chart, with multiple series from a
log query over time. The list displays the top ten results from
a query, with a graph that indicates the relative value of a
numeric column or its change over time.
Stack of line charts part Displays three separate line charts, with multiple series from a
log query over time.
The next sections describe the tile types and their properties in detail.
NOTE
Parts in views are based on log queries in your Log Analytics workspace. They do not currently support cross resource
queries to retrieve data from Application Insights.
List of queries part

The list of queries part displays a list of log queries. You can select each query to display its results. The view
includes a single query by default, and you can select + Query to add additional queries.
SETTING DESCRIPTION
General
Title The text that's displayed at the top of the view.
New Group Select this link to create a new group in the view, starting at
the current view.
Pre-selected filters A comma-delimited list of properties to include in the left

filter pane when you select a query.
Render mode The initial view that's displayed when the query is selected.
You can select any available views after they open the query.
SETTING DESCRIPTION
Queries
Search query The query to run.
Friendly name The descriptive name that's displayed.
Number and list part

The header displays a single number that shows a count of records from a log query. The list displays the top ten
results from a query, with a graph that indicates the relative value of a numeric column or its change over time.
SETTING DESCRIPTION
General
Group title The text that's displayed at the top of the view.
the current view.
Icon The image file that's displayed next to the result in the header.
Use Icon Select this link to display the icon.
Title
Legend The text that's displayed at the top of the header.
Query The query to run for the header. The count of the records
that are returned by the query is displayed.
Click-through navigation Action taken when you click on the header. For more
information, see Common Settings.
SETTING DESCRIPTION
List
Query The query to run for the list. The first two properties for the
first ten records in the results are displayed. The first property
is a text value, and the second property is a numeric value.
Bars are automatically created that are based on the relative
value of the numeric column.
Use the Sort command in the query to sort the records in

the list. To run the query and return all records, you can
select See all.
Hide graph Select this link to disable the graph at the right of the
numeric column.
Enable sparklines Select this link to display a sparkline instead of a horizontal

bar. For more information, see Common Settings.
Color The color of the bars or sparklines.
Name and value separator The single-character delimiter to use to parse the text
property into multiple values. For more information, see
Common Settings.
Click-through navigation Action taken when you click on an item in the list. For more
List > Column titles
Name The text that's displayed at the top of the first column.
Value The text that's displayed at the top of the second column.
List > Thresholds
Enable Thresholds Select this link to enable thresholds. For more information,
see Common Settings.
Two numbers and list part

The header has two numbers that display a count of records from separate log queries. The list displays the top
ten results from a query, with a graph that indicates the relative value of a numeric column or its change over
time.
SETTING DESCRIPTION
General
Group title The text that's displayed at the top of the view.
the current view.
Title Navigation
Title
Legend The text that's displayed at the top of the header.
Query The query to run for the header. The count of the records
that are returned by the query is displayed.
List
Query The query to run for the list. The first two properties for the
first ten records in the results are displayed. The first property
is a text value, and the second property is a numeric value.
Bars are automatically created based on the relative value of
the numeric column.
Use the Sort command in the query to sort the records in

the list. To run the query and return all records, you can
select See all.
SETTING DESCRIPTION
numeric column.

Operation The operation to perform for the sparkline. For more

Common Settings.
List > Thresholds
Donut and list part

The header displays a single number that summarizes a value column in a log query. The donut graphically
displays results of the top three records.
SETTING DESCRIPTION
General
Group title The text that's displayed at the top of the tile.
the current view.
Header
Title The text that's displayed at the top of the header.
Subtitle The text that's displayed under the title at the top of the
header.
Donut
Query The query to run for the donut. The first property is a text
value, and the second property is a numeric value.
Donut > Center
Text The text that's displayed under the value inside the donut.
Operation The operation to perform on the value property to

summarize it as a single value.
Sum: Adds the values of all records.
Percentage: The ratio of the records returned by the
values in Result values used in center operation to
the total records in the query.
Result values used in center operation Optionally, select the plus sign (+) to add one or more values.
The results of the query are limited to records with the
property values you specify. If no values are added, all records
are included in the query.
Additional options > Colors
Color 1 Select the color for each of the values that are displayed in
Color 2 the donut.
Color 3
Additional options > Advanced color mapping
Field value Type the name of a field to display it as a different color if it is

included in the donut.
SETTING DESCRIPTION
Color Select the color for the unique field.
List
Query The query to run for the list. The count of the records that
are returned by the query is displayed.
numeric column.


Common Settings.
List > Thresholds
Two timelines and list part

The header displays the results of two log queries over time as column charts, with a callout that displays a single
number that summarizes a value column in a log query. The list displays the top ten results from a query, with a
graph that indicates the relative value of a numeric column or its change over time.
SETTING DESCRIPTION
General
the current view.
Title Navigation
First chart
Second chart
Legend The text that's displayed under the callout for the first series.
Color The color to use for the columns in the series.
Query The query to run for the first series. The count of records over
each time interval is represented by the chart columns.
SETTING DESCRIPTION

Last sample: The value from the last interval that's
First sample: The value from the first interval that's
the query.
List
numeric column.


List > Thresholds
Information part
The header displays static text and an optional link. The list displays one or more items with a static title and text.
SETTING DESCRIPTION
General
the current view.
Color The background color for the header.
Header
Image The image file that's displayed in the header.
Label The text that's displayed in the header.
Header > Link
Label The link text.
Url The Url for the link.
Information items
Title The text that's displayed for the title of each item.
Content The text that's displayed for each item.
Line chart, callout, and list part

The header displays a line chart with multiple series from a log query over time and a callout with a summarized
value. The list displays the top ten results from a query, with a graph that indicates the relative value of a numeric
column or its change over time.
SETTING DESCRIPTION
General
the current view.
Header
header.
Line chart
Query The query to run for the line chart. The first property is a text
ordinarily uses the measure keyword to summarize results. If
the query uses the interval keyword, the x-axis of the chart
uses this time interval. If the query does not include the
interval keyword, the x-axis uses hourly intervals.
Line chart > Callout
Callout title The text that's displayed above the callout value.
SETTING DESCRIPTION
Series Name Property value for the series to use for the callout value. If no
series is provided, all records from the query are used.

the query.
Last sample: The value from the last interval that's
Max: The maximum value from the intervals that are
Min: The minimum value from the intervals that are
Line chart > Y-axis
Custom label The text that's displayed for the y-axis next to the label for
the Unit type. If no label is specified, only the Unit type is
displayed.
List
numeric column.


Common Settings.
SETTING DESCRIPTION
List > Thresholds
Line chart and list part

The header displays a line chart with multiple series from a log query over time. The list displays the top ten
results from a query, with a graph that indicates the relative value of a numeric column or its change over time.
SETTING DESCRIPTION
General
the current view.
Header

SETTING DESCRIPTION
header.
Line chart
Line chart > Y-axis
displayed.
List
numeric column.


Common Settings.
SETTING DESCRIPTION
List > Thresholds
Stack of line charts part

The stack of line chart displays three separate line charts, with multiple series from a log query over time, as
shown here:
SETTING DESCRIPTION
General
the current view.
Chart 1 > Header

Chart 2
Chart 3
Title The text that's displayed at the top of the chart.

SETTING DESCRIPTION
chart.
Chart 1 Line chart

Chart 2
Chart 3
Chart > Y-axis
displayed.
Common settings
The following sections describe settings that are common to several visualization parts.
Name and value separator
The name and value separator is the single-character delimiter to use to parse the text property from a list query
into multiple values. If you specify a delimiter, you can provide names for each field, separated by the same
delimiter in the Name box.
For example, consider a property called Location that included values such as Redmond -Building 41 and
Bellevue-Building 12. You can specify a dash (-) for the name and value separator and City-Building for the name.
This approach parses each value into two properties called City and Building.
Click-Through Navigation
Click-through navigation defines what action will be taken when you click on a header or list item in a view. This
will either open a query in the Log Analytics or launch another view.
The following table describes the settings for click-through navigation.
SETTING DESCRIPTION
Log Search (Auto) Log query to run when you select a header item. This is the
same log query that the item is based on.
Log Search Log query to run when you select an item in a list. Type the
query into the Navigation query box. Use {selected item} to
include the syntax for the item that the user selected. For
example, if the query has a column named Computer and the
navigation query is {selected item}, a query such as
Computer="MyComputer" is run when you select a computer.
If the navigation query is Type=Event {selected item}, the
query Type=Event Computer="MyComputer" is run.
View View to open when you select a header item or an item in a

list. Select the name of a view in your workspace in the View
Name box.
Sparklines
A sparkline is a small line chart that illustrates the value of a list entry over time. For visualization parts with a list,
you can select whether to display a horizontal bar, which indicates the relative value of a numeric column, or a
sparkline, which indicates its value over time.
The following table describes the settings for sparklines:
SETTING DESCRIPTION
Enable Sparklines Select this link to display a sparkline instead of a horizontal

bar.
Operation If sparklines are enabled, this is the operation to perform on

each property in the list to calculate the values for the
sparkline.
Last sample: The last value for the series over the time
interval.
Max: The maximum value for the series over the time
interval.
Min: The minimum value for the series over the time
interval.
Sum: The sum of the values for the series over the
time interval.
Summary: Uses the same measure command as the
query in the header.
Thresholds
By using thresholds, you can display a colored icon next to each item in a list. Thresholds give you a quick visual
indicator of items that exceed a particular value or fall within a particular range. For example, you can display a
green icon for items with an acceptable value, yellow if the value is within a range that indicates a warning, and
red if it exceeds an error value.
When you enable thresholds for a part, you must specify one or more thresholds. If the value of an item is greater
than a threshold value and lower than the next threshold value, the color for that value is used. If the item is
greater than the highest threshold value, another color is used.
Each threshold set has one threshold with a value of Default. This is the color that's set if no other values are
exceeded. You can add or remove thresholds by selecting the Add (+) or Delete (x) button.
The following table describes the settings for thresholds:
SETTING DESCRIPTION
Enable Thresholds Select this link to display a color icon at the left of each value.
The icon indicates the value's health relative to specified
thresholds.
Name The name of the threshold value.
Threshold The value for the threshold. The health color for each list item
is set to the color of the highest threshold value that's
exceeded by the item's value. If no threshold values are
exceeded, a default color is used.
Color The color that indicates the threshold value.
Next steps
Learn about log queries to support the queries in visualization parts.
Filters in Azure Monitor views
A filter in an Azure Monitor view allows users to filter the data in the view by the value of a particular property
without modifying the view itself. For example, you could allow users of your view to filter the view for data only
from a particular computer or set of computers. You can create multiple filters on a single view to allow users to
filter by multiple properties. This article describes how to use a filter and add one to a custom view.
Using a filter
Click the date time range at the top of a view to open the drop down where you can change the date time range for
the view.
Click the + to add a filter using custom filters that are defined for the view. Either select a value for the filter from
the dropdown or type in a value. Continue to add filters by clicking the +.
If you remove all of the values for a filter, then that filter will no longer be applied.
Creating a filter
Create a filter from the Filters tab when editing a view. The filter is global for the view and applies to all parts in
the view.
The following table describes the settings for a filter.

SETTING DESCRIPTION
Field Name Name of the field used for filtering. This field must match the
summarize field in Query for Values.
Query for Values Query to run to populate filter dropdown for the user. This
query must use either summarize or distinct to provide
unique values for a particular field, and it must match the
Field Name. You can use sort to sort the values that are
displayed to the user.
Tag Name for the field that's used in queries supporting the filter
and is also displayed to the user.
Examples
The following table includes a few examples of common filters.
FIELD NAME QUERY FOR VALUES TAG
Computer Heartbeat | distinct Computer | sort by Computers

Computer asc
EventLevelName Event | distinct EventLevelName Severity
SeverityLevel Syslog | distinct SeverityLevel Severity
SvcChangeType ConfigurationChange | distinct ChangeType

svcChangeType
Modify view queries

For a filter to have any effect, you must modify any queries in the view to filter on the selected values. If you don't
modify any queries in the view, then any values the user selects will have no effect.
The syntax for using a filter value in a query is:
where ${filter name}
For example, if your view has a query that returns events and uses a filter called Computers, you could use the
following query.
Event | where ${Computers} | summarize count() by EventLevelName
If you added another filter called Severity, you could use the following query to use both filters.
Event | where ${Computers} | where ${Severity} | summarize count() by EventLevelName
Next steps
Learn more about the Visualization Parts you can add to your custom view.
Import Azure Monitor log data into Power BI
Power BI is a cloud based business analytics service from Microsoft that provides rich visualizations and reports
for analysis of different sets of data. You can import the results of an Azure Monitor log query into a Power BI
dataset so you can take advantage of its features such as combining data from different sources and sharing
reports on the web and mobile devices.
NOTE
Overview
To import data from a Log Analytics workspace in Azure Monitor into Power BI, you create a dataset in Power BI
based on a log query in Azure Monitor. The query is run each time the dataset is refreshed. You can then build
Power BI reports that use data from the dataset. To create the dataset in Power BI, you export your query from
Log Analytics to Power Query (M ) language. You then use this to create a query in Power BI Desktop and then
publish it to Power BI as a dataset. The details for this process are described below.
Export query
Start by creating a log query that returns the data that you want to populate the Power BI dataset. You then
export that query to Power Query (M ) language which can be used by Power BI Desktop.
1. Create the log query in Log Analytics to extract the data for your dataset.
2. Select Export > Power BI Query (M ). This exports the query to a text file called PowerBIQuery.txt.
3. Open the text file and copy its contents.
Import query into Power BI Desktop

Power BI Desktop is a desktop application that allows you to create datasets and reports that can be published to
Power BI. You can also use it to create a query using the Power Query language exported from Azure Monitor.
1. Install Power BI Desktop if you don't already have it and then open the application.
2. Select Get Data > Blank Query to open a new query. Then select Advanced Editor and paste the
contents of the exported file into the query. Click Done.
3. The query runs, and its results are displayed. You may be prompted for credentials to connect to Azure.
4. Type in a descriptive name for the query. The default is Query1. Click Close and Apply to add the
dataset to the report.
Publish to Power BI
When you publish to Power BI, a dataset and a report will be created. If you create a report in Power BI Desktop,
then this will be published with your data. If not, then a blank report will be created. You can modify the report in
Power BI or create a new one based on the dataset.
1. Create a report based on your data. Use Power BI Desktop documentation if you're not familiar with it.
2. When you're ready to send it to Power BI, click Publish.
3. When prompted, select a destination in your Power BI account. Unless you have a specific destination in
mind, use My workspace.
4. When the publishing completes, click Open in Power BI to open Power BI with your new dataset.
Configure scheduled refresh
The dataset created in Power BI will have the same data that you previously saw in Power BI Desktop. You need
to refresh the dataset periodically to run the query again and populate it with the latest data from Azure Monitor.
1. Click on the workspace where you uploaded your report and select the Datasets menu.
2. Select the context menu next to your new dataset and select Settings.
3. Under Data source credentials you should have a message that the credentials are invalid. This is
because you haven't provided credentials yet for the dataset to use when it refreshes its data.
4. Click Edit credentials and specify credentials with access to the Log Analytics workspace in Azure
Monitor. If you require two-factor authentication, select OAuth2 for the Authentication method to be
prompted to login with your credentials.
5. Under Scheduled refresh turn on the option to Keep your data up to date. You can optionally change
the Refresh frequency and one or more specific times to run the refresh.
Next steps
Learn about log searches to build queries that can be exported to Power BI.
Learn more about Power BI to build visualizations based on Azure Monitor log exports.
Feed Power BI from Application Insights
Power BI is a suite of business tools that helps you analyze data and share insights. Rich dashboards are
available on every device. You can combine data from many sources, including Analytics queries from Azure
There are three methods of exporting Application Insights data to Power BI:
Export Analytics queries. This is the preferred method. Write any query you want and export it to Power
BI. You can place this query on a dashboard, along with any other data.
Continuous export and Azure Stream Analytics. This method is useful if you want to store your data for
long periods of time. If you don't have an extended data retention requirement, use the export analytics
query method. Continuous export and Stream Analytics involves more work to set up and additional storage
overhead.
Power BI adapter. The set of charts is predefined, but you can add your own queries from any other
sources.
NOTE
The Power BI adapter is now deprecated. The predefined charts for this solution are populated by static uneditable
queries. You do not have the ability to edit these queries and depending on certain properties of your data it is possible
for the connection to Power BI to be successful, but no data is populated. This is due to exclusion criteria that are set
within the hardcoded query. While this solution may still work for some customers, due to the lack of flexibility of the
adapter the recommended solution is to use the export Analytics query functionality.
Export Analytics queries

This route allows you to write any Analytics query you like, or export from Usage Funnels, and then export that
to a Power BI dashboard. (You can add to the dashboard created by the adapter.)
One time: install Power BI Desktop
To import your Application Insights query, you use the desktop version of Power BI. Then you can publish it to
the web or to your Power BI cloud workspace.
Install Power BI Desktop.
Export an Analytics query
1. Open Analytics and write your query.
2. Test and refine the query until you're happy with the results. Make sure that the query runs correctly in
Analytics before you export it.
3. On the Export menu, choose Power BI (M ). Save the text file.
4. In Power BI Desktop, select Get Data > Blank Query. Then, in the query editor, under View, select
Advanced Editor.
Paste the exported M Language script into the Advanced Editor.
5. To allow Power BI to access Azure, you might have to provide credentials. Use Organizational account
to sign in with your Microsoft account.
If you need to verify the credentials, use the Data Source Settings menu command in the query editor.
Be sure to specify the credentials you use for Azure, which might be different from your credentials for
Power BI.
6. Choose a visualization for your query, and select the fields for x-axis, y-axis, and segmenting dimension.
7. Publish your report to your Power BI cloud workspace. From there, you can embed a synchronized
version into other web pages.
8. Refresh the report manually at intervals, or set up a scheduled refresh on the options page.
Export a Funnel
1. Make your Funnel.
2. Select Power BI.
3. In Power BI Desktop, select Get Data > Blank Query. Then, in the query editor, under View, select
Advanced Editor.
Paste the exported M Language script into the Advanced Editor.
4. Select items from the query, and choose a Funnel visualization.

5. Change the title to make it meaningful, and publish your report to your Power BI cloud workspace.
Troubleshooting
You might encounter errors pertaining to credentials or the size of the dataset. Here is some information about
what to do about these errors.
Unauthorized (401 or 403)
This can happen if your refresh token has not been updated. Try these steps to ensure you still have access:
1. Sign into the Azure portal, and make sure you can access the resource.
2. Try to refresh the credentials for the dashboard.
If you do have access and refreshing the credentials does not work, please open a support ticket.
Bad Gateway (502)
This is usually caused by an Analytics query that returns too much data. Try using a smaller time range for the
query.
If reducing the dataset coming from the Analytics query doesn't meet your requirements, consider using the
API to pull a larger dataset. Here's how to convert the M -Query export to use the API.
1. Create an API key.
2. Update the Power BI M script that you exported from Analytics by replacing the Azure Resource Manager
URL with the Application Insights API.
Replace https://management.azure.com/subscriptions/...
with, https://api.applicationinsights.io/beta/apps/...
3. Finally, update the credentials to basic, and use your API key.
Existing script
Source = Json.Document(Web.Contents("https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcegroups//providers/microsoft.insights/components//api/query?api-version=2014-12-01-
preview",[Query=[#"csl"="requests",#"x-ms-app"="AAPBI"],Timeout=#duration(0,0,4,0)]))
Updated script
Source = Json.Document(Web.Contents("https://api.applicationinsights.io/beta/apps/<APPLICATION_ID>/query?
api-version=2014-12-01-preview",[Query=[#"csl"="requests",#"x-ms-app"="AAPBI"],Timeout=#duration(0,0,4,0)]))
About sampling
Depending on the amount of data sent by your application, you might want to use the adaptive sampling
feature, which sends only a percentage of your telemetry. The same is true if you have manually set sampling
either in the SDK or on ingestion. Learn more about sampling.
Power BI adapter (deprecated)

This method creates a complete dashboard of telemetry for you. The initial dataset is predefined, but you can
add more data to it.
Get the adapter
1. Sign in to Power BI.
2. Open Get Data , Services.
3. Select Get it now under Application Insights.

4. Provide the details of your Application Insights resource, and then Sign-in.
This information can be found in the Application Insights Overview pane:
5. Open the newly created Application Insights Power BI App.

6. Wait a minute or two for the data to be imported.
You can edit the dashboard, combining the Application Insights charts with those of other sources, and with
Analytics queries. You can get more charts in the visualization gallery, and each chart has parameters you can
set.
After the initial import, the dashboard and the reports continue to update daily. You can control the refresh
schedule on the dataset.
Next steps
Power BI - Learn
Analytics tutorial
Create interactive reports with Azure Monitor
workbooks
Workbooks combine text,Analytics queries, Azure Metrics, and parameters into rich interactive reports.
Workbooks are editable by any other team members who have access to the same Azure resources.
Workbooks are helpful for scenarios like:
Exploring the usage of your app when you don't know the metrics of interest in advance: numbers of users,
retention rates, conversion rates, etc. Unlike other usage analytics tools, workbooks let you combine
multiple kinds of visualizations and analyses, making them great for this kind of free-form exploration.
Explaining to your team how a newly released feature is performing, by showing user counts for key
interactions and other metrics.
Sharing the results of an A/B experiment in your app with other members of your team. You can explain the
goals for the experiment with text, then show each usage metric and Analytics query used to evaluate the
experiment, along with clear call-outs for whether each metric was above- or below -target.
Reporting the impact of an outage on the usage of your app, combining data, text explanation, and a
discussion of next steps to prevent outages in the future.
Starting with a template or saved workbook

A workbook is made up of sections consisting of independently editable charts, tables, text, and input controls.
To better understand workbooks, it is best to open one up.
Select Workbooks from the left-hand menu from inside the Application Insights experience for your app.
This launches a workbook gallery with a number of prebuilt workbooks to help you get started.
We'll start with the Default Template, which is located under the heading Quick start.
Editing, rearranging, cloning, and deleting workbook sections
Workbooks have two modes: editing mode, and reading mode. When the default workbook is first
launched, it opens in editing mode. This shows all the content of the workbook, including any steps and
parameters that are otherwise hidden. Reading mode presents a simplified report style view. This allows you
to abstract away the complexity that went into creating a report while still having the underlying mechanics
only a few clicks away when needed for modification.
1. When you're done editing a section, click Done Editing in the bottom left corner of the section.
2. To create a duplicate of a section, click the Clone this section icon. Creating duplicate sections is a great
to way to iterate on a query without losing previous iterations.
3. To move up a section in a workbook, click the Move up or Move down icon.
4. To remove a section permanently, click the Remove icon.
Adding text and Markdown sections
Adding headings, explanations, and commentary to your workbooks helps turn a set of tables and charts into a
narrative. Text sections in workbooks support the Markdown syntax for text formatting, like headings, bold,
italics, and bulleted lists.
To add a text section to your workbook, use the Add text button at the bottom of the workbook, or at the
Adding query sections
To add query section to your workbook, use the Add query button at the bottom of the workbook, or at the
Query sections are highly flexible and can be used to answer questions like:
How many exceptions did your site throw during the same time period as a decline in usage?
What was the distribution of page load times for users viewing some page?
How many users viewed some set of pages on your site, but not some other set of pages? This can be
useful to understand if you have clusters of users who use different subsets of your site's functionality (use
the join operator with the kind=leftanti modifier in the Kusto query language ).
You also aren't only limited to querying from the context of the application you launched the workbook from.
You can query across multiple Application Insights monitored apps as well as Log Analytics workspaces as
long as you have access permission to those resources.
To query from additional external Application Insights resources use the app identifier.
union app('app01').requests, app('app02').requests, requests

| summarize count() by bin(timestamp, 1h)
This query is combining requests from three different applications. An app named app01, an app named
app02, and the requests from the local Application Insights resource.
To pull in data from an external Log Analytics workspace use the workspace identifier.
To learn more about cross-resource queries refer to the official guidance.
Advanced analytic query settings
Each section has its own advanced settings, which are accessible via the settings icon located to the right of
the Add parameters button.
Custom width Set this to make an item an arbitrary size, so you can fit
many items on a single line allowing you to better organize
your charts and tables into rich interactive reports.
Conditionally visible Use this to hide steps based on a parameter when in

reading mode.
Export a parameter This allows a selected row in the grid or chart to cause later
steps to change values or become visible.
Show query when not editing This displays the query above the chart or table even when
in reading mode.
Show open in analytics button when not editing This adds the blue Analytics icon to the right-hand corner of
the chart to allow one-click access.
Most of these settings are fairly intuitive, but to understand Export a parameter it is better to examine a
workbook that makes use of this functionality.
One of the prebuilt workbooks provides information on Active Users.
The first section of the workbook is based on Analytic query data:
The second section is also based on analytic query data, but selecting a row in the first table will interactively
update the contents of the chart:
This is possible through use of the When an item is selected, export a parameter advanced settings that
are enabled in the table's Analytics query.
The second analytics query then utilizes the exported values when a row is selected. If no row is selected, it
defaults to the row representing the overall values.
let start = startofday(ago({TimeRange} + {Metric}));

union customEvents, pageViews
| where timestamp >= start
| where name in ({Activities}) or '*' in ({Activities}) or ('%' in ({Activities}) and itemType ==
'pageView') or ('#' in ({Activities}) and itemType == 'customEvent')
{OtherFilters}
| where '{Filter}' == '' or '{Filter}' == ' Overall' or {AnalyzeBy} == replace(' ', '', '{Filter}')
| evaluate activity_engagement(user_Id, timestamp, start, now(), 1d, {Metric})
| where timestamp >= startofday(ago({TimeRange}))
| project timestamp, ["Active User"] = dcount_activities_outer
| render timechart
Adding metrics sections

Metrics sections give you full access to incorporate Azure Monitor metrics data into your interactive reports.
Many of the prebuilt workbooks will contain both analytic query data and metric data allowing you to take full
advantage of the best of both features all in one place. You also have the ability to pull in metric data from
resources in any of the subscriptions you have access to.
Here is an example of Virtual machine data being pulled into a workbook to provide a grid visualization of
CPU performance:
Adding parameter sections
Workbook parameters allow you to change values in the workbook without having to manually edit the query
or text sections. This removes the requirement of needing to understand the underlying analytics query
language and greatly expands the potential audience of workbook-based reporting.
The values of parameters are replaced in query, text or other parameter sections by putting the name of the
parameter in braces, like {parameterName} . Parameter names are limited to similar rules as JavaScript
identifiers, basically alphabetic characters or underscores, followed by alphanumeric characters or underscores.
For example, a1 is allowed, but 1a is not allowed.
Parameters are linear, starting from the top of a workbook and flowing down to later steps. Parameters
declared later in a workbook can override those that were declared further up. This also lets parameters that
use queries to access the values from parameters defined further up. Within a parameter's step itself,
parameters are also linear, left to right, where parameters to the right can depend on a parameter declared
earlier in that same step.
There are four different types of parameters which are currently supported:
Text the user will edit a text box, and you can optionally supply a
query to fill in the default value.
Drop down The user will choose from a set of values.
Time range picker The user will choose from a predefined set of time range
values, or pick from a custom time range.
Resource picker The user will choose from the resources selected for the
workbook.
Using a text parameter
The value a user types in the textbox is replaced directly in the query, with no escaping or quoting. If the value
you need is a string, the query should have quotes around the parameter (like '{parameter}').
This allows the value in a text box to be used anywhere. It can be a table name, column name, function name,
operator, etc.
The text parameter type has a setting Get default value from analytics query, which allows the workbook
author to use a query to populate the default value for that textbox.
When using the default value from an analytics query, only the first value of the first row (row 0, column 0) is
used as the default value. Therefore it is recommended to limit your query to return just one row and one
column. Any other data returned by the query is ignored.
Whatever value the query returns will be replaced directly with no escaping or quoting. If the query returns no
rows, the result of the parameter is either an empty string (if the parameter is not required) or undefined (if the
parameter is required).
Using a dropdown
The dropdown parameter type lets you create a dropdown control, allowing the selection of one or many
values.
The dropdown is populated by an analytics query. If the query returns one column, the values in that column
are both the value and the label in the dropdown control. If the query returns two columns, the first column is
the value, and the second column is the label shown in the dropdown. If the query returns three columns, the
3rd column is used to indicate the default selection in that dropdown. This column can be any type, but the
simplest is to use bool or numeric types, where 0 is false, and 1 is true.
If the column is a string type, null/empty string is considered false, and any other value is considered true. For
single selection dropdowns, the first value with a true value is used as the default selection. For multiple
selection dropdowns, all values with a true value are used as the default selected set. The items in the
dropdown are shown in whatever order the query returned rows.
Let's look at the parameters present in the Active Users report. Click the edit symbol next to TimeRange.
This will launch the Edit Parameter menu item:

The query uses a feature of the analytics query language called a datatable that lets you generate an arbitrary
table, full of content, out of thin air! For example, the following analytics query:
datatable( column1:string, column2:string )

[
"row 1 column 1", "row 1 column 2",
"row 2 column 1", "row 2 column 2"
]
Generates the result:
A more applicable example is using a dropdown to pick from a set of countries/regions by name:
customEvents
| where timestamp >= ago(14d)
| summarize count() by client_CountryOrRegion
| top 100 by count_
| project client_CountryOrRegion
| order by client_CountryOrRegion asc
The query will display results as follows:
Dropdowns are incredibly powerful tools for customizing and creating interactive reports.
Time range parameters
While you can make your own custom time range parameter via the dropdown parameter type, you can also
use the out-of-box time range parameter type if you don't need the same degree of flexibility.
Time range parameter types have 15 default ranges that go from five minutes to the last 90 days. There is also
an option to allow custom time range selection, which allows the operator of the report to choose explicit start
and stop values for the time range.
Resource picker
The resource picker parameter type gives you the ability to scope your report to certain types of resources. An
example of prebuilt workbook that leverages the resource picker type is the Failure Insights workbook.
Saving and sharing workbooks with your team

Workbooks are saved within an Application Insights resource, either in the My Reports section that's private
to you or in the Shared Reports section that's accessible to everyone with access to the Application Insights
resource. To view all the workbooks in the resource, click the Open button in the action bar.
To share a workbook that's currently in My Reports:
2. Click the "..." button beside the workbook you want to share
3. Click Move to Shared Reports.
To share a workbook with a link or via email, click Share in the action bar. Keep in mind that recipients of the
link need access to this resource in the Azure portal to view the workbook. To make edits, recipients need at
least Contributor permissions for the resource.
To pin a link to a workbook to an Azure Dashboard:
2. Click the "..." button beside the workbook you want to pin
3. Click Pin to dashboard.
Contributing workbook templates

Have you created an awesome workbook template and want to share it with the community? To learn more,
visit our GitHub repo.
Next steps
If you already send custom events or page views, explore the Usage tools to learn how users use your
service.
Funnels
Retention
User Flows
Add user context
2 minutes to read
Monitor your Azure services in Grafana
You can now monitor Azure services and applications from Grafana using the Azure Monitor data source plugin.
The plugin gathers application performance data collected by Azure Monitor, including various logs and metrics.
You can then display this data on your Grafana dashboard.
Use the following steps to set up a Grafana server and build dashboards for metrics and logs from Azure
Monitor.
Set up a Grafana server

Set up Grafana locally
To set up a local Grafana server, download and install Grafana in your local environment. To use the plugin's Azure
Monitor integration, install Grafana version 5.3 or higher.
Set up Grafana on Azure through the Azure Marketplace
1. Go to Azure Marketplace and pick Grafana by Grafana Labs.
2. Fill in the names and details. Create a new resource group. Keep track of the values you choose for the VM
username, VM password, and Grafana server admin password.
3. Choose VM size and a storage account.
4. Configure the network configuration settings.
5. View the summary and select Create after accepting the terms of use.
6. After the deployment completes, select Go to Resource Group. You see a list of newly created resources.
If you select the network security group (grafana -nsg in this case), you can see that port 3000 is used to
access Grafana server.
7. Get the public IP address of your Grafana server - go back to the list of resources and select Public IP
address.
Sign in to Grafana
1. Using the IP address of your server, open the Login page at http://<IP address>:3000 or the
<DNSName>:3000 in your browser. While 3000 is the default port, note you might have selected a
different port during setup. You should see a login page for the Grafana server you built.
2. Sign in with the user name admin and the Grafana server admin password you created earlier. If you're
using a local setup, the default password would be admin, and you'd be requested to change it on your first
login.
Configure data source plugin

Once successfully logged in, you should see that the Azure Monitor data source plugin is already included.
1. Select Add data source to add and configure the Azure Monitor data source.
2. Pick a name for the data source and select Azure Monitor as the type from the dropdown.
3. Create a service principal - Grafana uses an Azure Active Directory service principal to connect to Azure
Monitor APIs and collect data. You must create, or use an existing service principal, to manage access to
your Azure resources.
See these instructions to create a service principal. Copy and save your tenant ID (Directory ID ), client
ID (Application ID ) and client secret (Application key value).
See Assign application to role to assign the Reader role to the Azure Active Directory application on the
subscription, resource group or resource you want to monitor. The Log Analytics API requires the Log
Analytics Reader role, which includes the Reader role's permissions and adds to it.
4. Provide the connection details to the APIs you'd like to use. You can connect to all or to some of them.
If you connect to both metrics and logs in Azure Monitor, you can reuse the same credentials by
selecting Same details as Azure Monitor API.
When configuring the plugin, you can indicate which Azure Cloud you would like the plugin to
monitor (Public, Azure US Government, Azure Germany, or Azure China).
If you use Application Insights, you can also include your Application Insights API and application
ID to collect Application Insights based metrics. For more information, see Getting your API key and
Application ID.
NOTE
Some data source fields are named differently than their correlated Azure settings:
Tenant ID is the Azure Directory ID
Client ID is the Azure Active Directory Application ID
Client Secret is the Azure Active Directory Application key value
5. If you use Application Insights, you can also include your Application Insights API and application ID to
collect Application Insights based metrics. For more information, see Getting your API key and Application
ID.
6. Select Save, and Grafana will test the credentials for each API. You should see a message similar to the
following one.
Build a Grafana dashboard
1. Go to the Grafana Home page, and select New Dashboard.
2. In the new dashboard, select the Graph. You can try other charting options but this article uses Graph as
an example.
3. A blank graph shows up on your dashboard. Click on the panel title and select Edit to enter the details of
the data you want to plot in this graph chart.
4. Select the Azure Monitor data source you've configured.
Collecting Azure Monitor metrics - select Azure Monitor in the service dropdown. A list of
selectors shows up, where you can select the resources and metric to monitor in this chart. To collect
metrics from a VM, use the namespace Microsoft.Compute/VirtualMachines. Once you have
selected VMs and metrics, you can start viewing their data in the dashboard.
Collecting Azure Monitor log data - select Azure Log Analytics in the service dropdown. Select the
workspace you'd like to query and set the query text. You can copy here any log query you already
have or create a new one. As you type in your query, IntelliSense will show up and suggest
autocomplete options. Select the visualization type, Time series Table, and run the query.
NOTE
The default query provided with the plugin uses two macros: "$__timeFilter() and $__interval. These macros
allow Grafana to dynamically calculate the time range and time grain, when you zoom in on part of a chart.
You can remove these macros and use a standard time filter, such as TimeGenerated > ago (1h), but that
means the graph would not support the zoom in feature.
5. Following is a simple dashboard with two charts. The one on left shows the CPU percentage of two VMs.
The chart on the right shows the transactions in an Azure Storage account broken down by the Transaction
API type.
Optional: Monitor your custom metrics in the same Grafana server
You can also install Telegraf and InfluxDB to collect and plot both custom and agent-based metrics same Grafana
instance. There are many data source plugins that you can use to bring these metrics together in a dashboard.
You can also reuse this set up to include metrics from your Prometheus server. Use the Prometheus data source
plugin in Grafana's plugin gallery.
Here are good reference articles on how to use Telegraf, InfluxDB, Prometheus, and Docker
How To Monitor System Metrics with the TICK Stack on Ubuntu 16.04
A monitoring solution for Docker hosts, containers, and containerized services
Here is an image of a full Grafana dashboard that has metrics from Azure Monitor and Application Insights.
Advanced Grafana features

Variables
Some query values can be selected through UI dropdowns, and updated in the query. Consider the following
query as an example:
Usage
| where $__timeFilter(TimeGenerated)
| summarize total_KBytes=sum(Quantity)*1024 by bin(TimeGenerated, $__interval)
| sort by TimeGenerated
You can configure a variable that will list all available Solution values, and then update your query to use it. To
create a new variable, click the dashboard's Settings button in the top right area, select Variables, and then New.
On the variable page, define the data source and query to run in order to get the list of values.
Once created, adjust the query to use the selected value(s) and your charts will respond accordingly:
Usage
| where $__timeFilter(TimeGenerated) and Solution in ($Solutions)
| summarize total_KBytes=sum(Quantity)*1024 by bin(TimeGenerated, $__interval)
| sort by TimeGenerated
Create dashboard playlists

One of the many useful features of Grafana is the dashboard playlist. You can create multiple dashboards and add
them to a playlist configuring an interval for each dashboard to show. Select Play to see the dashboards cycle
through. You may want to display them on a large wall monitor to provide a status board for your group.
Clean up resources
If you've setup a Grafana environment on Azure, you are charged when VMs are running whether you are using
them or not. To avoid incurring additional charges, clean up the resource group created in this article.
1. From the left-hand menu in the Azure portal, click Resource groups and then click Grafana.
2. On your resource group page, click Delete, type Grafana in the text box, and then click Delete.
Next steps
Overview of Azure Monitor Metrics
Monitor the availability of any website
After you've deployed your web app/website, you can set up recurring tests to monitor availability
and responsiveness. Azure Application Insights sends web requests to your application at regular
intervals from points around the world. It can alert you if your application isn't responding, or if it
responds too slowly.
You can set up availability tests for any HTTP or HTTPS endpoint that is accessible from the public
internet. You don't have to make any changes to the website you're testing. In fact, it doesn't even
have to be a site you own. You can test the availability of a REST API that your service depends on.
Types of availability tests:
There are three types of availability tests:
URL ping test: a simple test that you can create in the Azure portal.
Multi-step web test: A recording of a sequence of web requests, which can be played back to
test more complex scenarios. Multi-step web tests are created in Visual Studio Enterprise and
uploaded to the portal for execution.
Custom Track Availability Tests: If you decide to create a custom application to run availability
tests, the TrackAvailability() method can be used to send the results to Application Insights.
You can create up to 100 availability tests per Application Insights resource.

In order to create an availability test, you first need to create an Application Insights resource. If
you have already created a resource, proceed to the next section to create a URL Ping test.
From the Azure portal, select Create a resource > Developer Tools > Application Insights and
create an Application Insights resource.
Create a URL ping test

The name "URL ping test" is a bit of a misnomer. To be clear, this test is not making any use of
ICMP (Internet Control Message Protocol) to check your site's availability. Instead it uses more
advanced HTTP request functionality to validate whether an endpoint is responding. It also
measures the performance associated with that response, and adds the ability to set custom
success criteria coupled with more advanced features like parsing dependent requests, and
allowing for retries.
To create your first availability request, open the Availability pane and select Create Test.
Create a test
SETTING EXPLANATION
URL The URL can be any web page you want to test, but
it must be visible from the public internet. The URL
can include a query string. So, for example, you can
exercise your database a little. If the URL resolves to
a redirect, we follow it up to 10 redirects.
Parse dependent requests Test requests images, scripts, style files, and other
files that are part of the web page under test. The
recorded response time includes the time taken to
get these files. The test fails if any of these resources
cannot be successfully downloaded within the
timeout for the whole test. If the option is not
checked, the test only requests the file at the URL
you specified. Enabling this option results in a stricter
check. The test could fail for cases, which may not be
noticeable when manually browsing the site.
Enable retries when the test fails, it is retried after a short interval.
A failure is reported only if three successive attempts
fail. Subsequent tests are then performed at the
usual test frequency. Retry is temporarily suspended
until the next success. This rule is applied
independently at each test location. We
recommend this option. On average, about 80% of
failures disappear on retry.
Test frequency Sets how often the test is run from each test location.
With a default frequency of five minutes and five test
locations, your site is tested on average every
minute.
Test locations Are the places from where our servers send web
requests to your URL. Our minimum number of
recommended test locations is five in order to
insure that you can distinguish problems in your
website from network issues. You can select up to 16
locations.
If your URL is not visible from the public internet, you can choose to selectively open up
your firewall to allow only the test transactions through. To learn more about the firewall
exceptions for our availability test agents, consult the IP address guide.
NOTE
We strongly recommend testing from multiple locations with a minimum of five locations. This is to
prevent false alarms that may result from transient issues with a specific location. In addition we have
found that the optimal configuration is to have the number of test locations be equal to the alert
location threshold + 2.
Success criteria
SETTING EXPLANATION
Test timeout Decrease this value to be alerted about slow

responses. The test is counted as a failure if the
responses from your site have not been received
within this period. If you selected Parse dependent
requests, then all the images, style files, scripts, and
other dependent resources must have been received
within this period.
HTTP response The returned status code that is counted as a

success. 200 is the code that indicates that a normal
web page has been returned.
Content match A string, like "Welcome!" We test that an exact case-

sensitive match occurs in every response. It must be
a plain string, without wildcards. Don't forget that if
your page content changes you might have to
update it. Only English characters are supported
with content match
Alerts
SETTING EXPLANATION
Near-realtime (Preview) We recommend using Near-realtime alerts.

Configuring this type of alert is done after your
availability test is created.
Classic We no longer recommended using classic alerts for

new availability tests.
Alert location threshold We recommend a minimum of 3/5 locations. The

optimal relationship between alert location threshold
and the number of test locations is alert location
threshold = number of test locations - 2, with a
minimum of five test locations.
See your availability test results

Availability test results can be visualized with both line and scatter plot views.
After a few minutes, click Refresh to see your test results.
The scatterplot view shows samples of the test results that have diagnostic test-step detail in them.
The test engine stores diagnostic detail for tests that have failures. For successful tests, diagnostic
details are stored for a subset of the executions. Hover over any of the green/red dots to see the
test, test name, and location.
Select a particular test, location, or reduce the time period to see more results around the time
period of interest. Use Search Explorer to see results from all executions, or use Analytics queries
to run custom reports on this data.
Inspect and edit tests

To edit, temporarily disable, or delete a test click the ellipses next to a test name. It may take up to
20 minutes for configuration changes to propagate to all test agents after a change is made.
You might want to disable availability tests or the alert rules associated with them while you are
performing maintenance on your service.
If you see failures

Click a red dot.
From an availability test result, you can see the transaction details across all components. Here you
can:
Inspect the response received from your server.
Diagnose failure with correlated server-side telemetry collected while processing the failed
availability test.
Log an issue or work item in Git or Azure Boards to track the problem. The bug will contain a
link to this event.
Open the web test result in Visual Studio.
Learn more about the end to end transaction diagnostics experience here.
Click on the exception row to see the details of the server-side exception that caused the synthetic
availability test to fail. You can also get the debug snapshot for richer code level diagnostics.
In addition to the raw results, you can also view two key Availability metrics in Metrics Explorer:
1. Availability: Percentage of the tests that were successful, across all test executions.
2. Test Duration: Average test duration across all test executions.
Automation
Use PowerShell scripts to set up an availability test automatically.
Set up a webhook that is called when an alert is raised.
Troubleshooting
Next steps
Availability Alerts
Set Alerts in Application Insights
Azure Application Insights can alert you to changes in performance or usage metrics in your web app.
Application Insights monitors your live app on a wide variety of platforms to help you diagnose performance
issues and understand usage patterns.
There are multiple types of alerts:
Metric alerts tell you when a metric crosses a threshold value for some period - such as response times,
exception counts, CPU usage, or page views.
Log Alerts is used to describe alerts where the alert signal is based on a custom Kusto query.
Web tests tell you when your site is unavailable on the internet, or responding slowly. Learn more.
Proactive diagnostics are configured automatically to notify you about unusual performance patterns.
Set a Metric alert

Open the Alert rules tab, and then use the add button.
Set the resource before the other properties. Choose the "(components)" resource if you want to set
alerts on performance or usage metrics.
The name that you give to the alert must be unique within the resource group (not just your application).
Be careful to note the units in which you're asked to enter the threshold value.
If you check the box "Email owners...", alerts are sent by email to everyone who has access to this resource
group. To expand this set of people, add them to the resource group or subscription (not the resource).
If you specify "Additional emails", alerts are sent to those individuals or groups (whether or not you
checked the "email owners..." box).
Set a webhook address if you have set up a web app that responds to alerts. It is called both when the alert
is Activated and when it is Resolved. (But note that at present, query parameters are not passed through as
webhook properties.)
You can Disable or Enable the alert: see the buttons at the top.
I don't see the Add Alert button.
Are you using an organizational account? You can set alerts if you have owner or contributor access to this
application resource. Take a look at the Access Control tab. Learn about access control.
NOTE
In the alerts blade, you see that there's already an alert set up: Proactive Diagnostics. The automatic alert monitors one
particular metric, request failure rate. Unless you decide to disable the proactive alert, you don't need to set your own
alert on request failure rate.
See your alerts

You get an email when an alert changes state between inactive and active.
The current state of each alert is shown in the Alert rules tab.
There's a summary of recent activity in the alerts drop-down:
The history of state changes is in the Activity Log:

How alerts work
An alert has three states: "Never activated", "Activated", and "Resolved." Activated means the condition
you specified was true, when it was last evaluated.
A notification is generated when an alert changes state. (If the alert condition was already true when
you created the alert, you might not get a notification until the condition goes false.)
Each notification generates an email if you checked the emails box, or provided email addresses. You
can also look at the Notifications drop-down list.
An alert is evaluated each time a metric arrives, but not otherwise.
The evaluation aggregates the metric over the preceding period, and then compares it to the threshold
to determine the new state.
The period that you choose specifies the interval over which metrics are aggregated. It doesn't affect
how often the alert is evaluated: that depends on the frequency of arrival of metrics.
If no data arrives for a particular metric for some time, the gap has different effects on alert evaluation
and on the charts in metric explorer. In metric explorer, if no data is seen for longer than the chart's
sampling interval, the chart shows a value of 0. But an alert based on the same metric is not be
reevaluated, and the alert's state remains unchanged.
When data eventually arrives, the chart jumps back to a non-zero value. The alert evaluates based on
the data available for the period you specified. If the new data point is the only one available in the
period, the aggregate is based just on that data point.
An alert can flicker frequently between alert and healthy states, even if you set a long period. This can
happen if the metric value hovers around the threshold. There is no hysteresis in the threshold: the
transition to alert happens at the same value as the transition to healthy.
What are good alerts to set?

It depends on your application. To start with, it's best not to set too many metrics. Spend some time looking at
your metric charts while your app is running, to get a feel for how it behaves normally. This practice helps you
find ways to improve its performance. Then set up alerts to tell you when the metrics go outside the normal
zone.
Popular alerts include:
Browser metrics, especially Browser page load times, are good for web applications. If your page has
many scripts, you should look for browser exceptions. In order to get these metrics and alerts, you have
to set up web page monitoring.
Server response time for the server side of web applications. As well as setting up alerts, keep an eye on
this metric to see if it varies disproportionately with high request rates: variation might indicate that your
app is running out of resources.
Server exceptions - to see them, you have to do some additional setup.
Don't forget that proactive failure rate diagnostics automatically monitor the rate at which your app responds
to requests with failure codes.
How to set an exception alert using custom log search

In this section, we will go through how to set a query based exception alert. For this example, let's say we want
an alert when the failed rate is greater than 10% in the last 24 hours.
1. Go to your Application Insight resource in the Azure portal.
2. On the left, under configure click on Alert.
3. At the top of the alert tab select New alert rule.

4. Your resource should be auto selected. To set a condition, click Add condition.
5. In the configure signal logic tab select Custom log search

6. In the custom log search tab, enter your query in the "Search query" box. For this example, we will use
the below Kusto query.
let percentthreshold = 10;

let period = 24h;
requests
| where timestamp >ago(period)
| summarize requestsCount = sum(itemCount)
| project requestsCount, exceptionsCount = toscalar(exceptions | where timestamp >ago(period) |
summarize sum(itemCount))
| extend exceptionsRate = toreal(exceptionsCount)/toreal(requestsCount) * 100
| where exceptionsRate > percentthreshold
NOTE
You can also apply these steps to other types of query-based alerts. You can learn more about the Kusto query
language from this Kusto getting started doc or this SQL to Kusto cheat sheet
7. Under "Alert logic", choose whether it's based on number of results or metric measurement. Then pick
the condition (greater than, equal to, less than) and a threshold. While you are changing these values,
you may notice the condition preview sentence changes. In this example we are using "equal to".
8. Under "Evaluated based on", set the period and frequency. The period here must match the value that
we put for period in the query above. Then click done.
9. We now see the condition we created with the estimated monthly cost. Below under "Action Groups"
you can create a new group or select an existing one. If you want, you can customize the actions.
10. Finally add your alert details (alert rule name, description, severity). When you are done, click Create
alert rule at the bottom.
How to unsubscribe from classic alert e-mail notifications
This section applies to classic availability alerts, classic Application Insights metric alerts, and to classic
failure anomalies alerts.
You are receiving e-mail notifications for these classic alerts if any of the following applies:
Your e-mail address is listed in the Notification e-mail recipients field in the alert rule settings.
The option to send e-mail notifications to users holding certain roles for the subscription is activated,
and you hold a respective role for that particular Azure subscription.
To better control your security and privacy we generally recommend that you explicitly specify the notification
recipients for your classic alerts in the Notification email recipients field. The option to notify all users
holding certain roles is provided for backward compatibility.
To unsubscribe from e-mail notifications generated by a certain alert rule, remove your e-mail address from
the Notification email recipients field.
If your email address is not listed explicitly, we recommend that you disable the option to notify all members of
certain roles automatically, and instead list all user e-mails who need to receive notifications for that alert rule
in the Notification e-mail recipients field.
Who receives the (classic) alert notifications?

This section only applies to classic alerts and will help you optimize your alert notifications to ensure that only
your desired recipients receive notifications. To understand more about the difference between classic alerts
and the new alerts experience, refer to the alerts overview article. To control alert notification in the new alerts
experience, use action groups.
We recommend the use of specific recipients for classic alert notifications.
For alerts on any Application Insights metrics (including availability metrics), the bulk/group check-
box option, if enabled, sends to users with owner, contributor, or reader roles in the subscription. In
effect, all users with access to the subscription the Application Insights resource are in scope and will
receive notifications.
NOTE
If you currently use the bulk/group check-box option, and disable it, you will not be able to revert the change.
Use the new alert experience/near-realtime alerts if you need to notify users based on their roles. With action
groups, you can configure email notifications to users with any of the contributor/owner/reader roles (not
combined together as a single option).
Automation
Use PowerShell to automate setting up alerts
Use webhooks to automate responding to alerts
See also
Automate setting up alerts
Proactive diagnostics
Create, view, and manage metric alerts using Azure
Monitor
Metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold.
Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, Application Insights
standard and custom metrics. In this article, we will describe how to create, view and manage metric alert rules
through Azure portal and Azure CLI. You can also create metric alert rules using Azure Resource Manager
templates which is described in a separate article.
You can learn more about how metric alerts work from metric alerts overview.
Create with Azure portal

The following procedure describes how to create a metric alert rule in Azure portal:
1. In Azure portal, click on Monitor. The Monitor blade consolidates all your monitoring settings and data
in one view.
2. Click Alerts then click + New alert rule.
TIP
Most resource blades also have Alerts in their resource menu under Monitoring, you could create alerts from
there as well.
3. Click Select target, in the context pane that loads, select a target resource that you want to alert on.
Use Subscription and Resource type drop-downs to find the resource you want to monitor. You can
also use the search bar to find your resource.
4. If the selected resource has metrics you can create alerts on, Available signals on the bottom right will
include metrics. You can view the full list of resource types supported for metric alerts in this article.
5. Once you have selected a target resource, click on Add condition.
6. You will see a list of signals supported for the resource, select the metric you want to create an alert on.
7. Optionally, refine the metric by adjusting Period and Aggregation. If the metric has dimensions, you
will see Dimensions table presented. Select one or more values per dimension. The metric alert will
run evaluate the condition for all combinations of values selected. Learn more about how alerting on
multi-dimensional metrics works. You can also Select * for any of the dimensions. Select * will
dynamically scale the selection to all current and future values for a dimension.
8. You will see a chart for the metric for the last 6 hours. Define the alert parameters; Condition Type,
Frequency, Operator and Threshold or Sensitivity, this will determine the logic which the metric
alert rule will evaluate. Learn more about Dynamic Thresholds condition type and sensitivity options.
9. If you are using a static threshold, the metric chart can help determine what might be a reasonable
threshold. If you are using a Dynamic Thresholds, the metric chart will display the calculated thresholds
based on recent data.
10. Click Done
11. Optionally, add another criteria if you want to monitor a complex alert rule. Currently users can have
alert rules with Dynamic Thresholds criteria as a single criterion.
12. Fill in Alert details like Alert Rule Name, Description and Severity
13. Add an action group to the alert either by selecting an existing action group or creating a new action
group.
14. Click Done to save the metric alert rule.
NOTE
Metric alert rules created through portal are created in the same resource group as the target resource.
View and manage with Azure portal

You can view and manage metric alert rules using the Manage Rules blade under Alerts. The procedure below
shows you how to view your metric alert rules and edit one of them.
1. In Azure portal, navigate to Monitor
2. Click on Alerts and Manage rules
3. In the Manage rules blade, you can view all your alert rules across subscriptions. You can further filter
the rules using Resource group, Resource type and Resource. If you want to see only metric alerts,
select Signal type as Metrics.
TIP
In the Manage rules blade, you can select multiple alert rules and enable/disable them. This might be useful
when certain target resources need to be put under maintenance
4. Click on the name of the metric alert rule you want to edit
5. In the Edit Rule, click on the Alert criteria you want to edit. You can change the metric, threshold
condition and other fields as required
NOTE
You can't edit the Target resource and Alert Rule Name after the metric alert is created.
6. Click Done to save your edits.
With Azure CLI

The previous sections described how to create, view and manage metric alert rules using Azure portal. This
section will describe how to do the same using cross-platform Azure CLI. Quickest way to start using Azure
CLI is through Azure Cloud Shell. For this article, we will use Cloud shell.
1. Go to Azure portal, click on Cloud shell.
2. At the prompt, you can use commands with --help option to learn more about the command and how
to use it. For example, the following command shows you the list of commands available for creating,
viewing and managing metric alerts
az monitor metrics alert --help
3. You can create a simple metric alert rule that monitors if average Percentage CPU on a VM is greater
than 90
az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes

{VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description
{descriptionofthealert}
4. You can view all the metric alerts in a resource group using the following command
az monitor metrics alert list -g {ResourceGroup}
5. You can see the details of a particular metric alert rule using the name or the resource ID of the rule.
az monitor metrics alert show -g {ResourceGroup} -n {AlertRuleName}
az monitor metrics alert show --ids {RuleResourceId}
6. You can disable a metric alert rule using the following command.
az monitor metrics alert update -g {ResourceGroup} -n {AlertRuleName} --enabled false
7. You can delete a metric alert rule using the following command.
az monitor metrics alert delete -g {ResourceGroup} -n {AlertRuleName}
Next steps
Create metric alerts using Azure Resource Manager Templates.
Understand how metric alerts work.
Understand how metric alerts with Dynamic Thresholds condition work.
Understand the web hook schema for metric alerts
Metric Alerts with Dynamic Thresholds in Azure
Monitor
Metric Alert with Dynamic Thresholds detection leverages advanced machine learning (ML ) to learn metrics'
historical behavior, identify patterns and anomalies that indicate possible service issues. It provides support of
both a simple UI and operations at scale by allowing users to configure alert rules through the Azure Resource
Manager API, in a fully automated manner.
Once an alert rule is created, it will fire only when the monitored metric doesn’t behave as expected, based on its
tailored thresholds.
We would love to hear your feedback, keep it coming at azurealertsfeedback@microsoft.com.
Why and when is using dynamic condition type recommended?

1. Scalable Alerting – Dynamic Thresholds alerts rules can create tailored thresholds for hundreds of metric
series at a time. Yet providing the same ease of defining an alert rule on a single metric. Using either the UI
or the Azure Resource Manager API results in fewer alert rules to manage. The scalable approach is
especially useful when dealing with metric dimensions or when applying to multiple resources, like all
subscription resources. Which translates to a significant time saving on management and creation of alerts
rules. Learn more about how to configure Metric Alerts with Dynamic Thresholds using templates.
2. Smart Metric Pattern Recognition – Using our unique ML technology, we’re able to automatically detect
metric patterns and adapt to metric changes over time, which may often include seasonality (Hourly / Daily
/ Weekly). Adapting to the metrics’ behavior over time and alerting based on deviations from its pattern
relieves the burden of knowing the “right” threshold for each metric. The ML algorithm used in Dynamic
Thresholds is designed to prevent noisy (low precision) or wide (low recall) thresholds that don’t have an
expected pattern.
3. Intuitive Configuration – Dynamic Thresholds allow setting up metric alerts using high-level concepts,
alleviating the need to have extensive domain knowledge about the metric.
How to configure alerts rules with Dynamic Thresholds?

Alerts with Dynamic Thresholds can be configured through Metric Alerts in Azure Monitor. Learn more about
how to configure Metric Alerts.
How are the thresholds calculated?

Dynamic Thresholds continuously learns the data of the metric series and tries to model it using a set of
algorithms and methods. It detects patterns in the data such as seasonality (Hourly / Daily / Weekly), and is able to
handle noisy metrics (such as machine CPU or memory) as well as metrics with low dispersion (such as
availability and error rate).
The thresholds are selected in such a way that a deviation from these thresholds indicates an anomaly in the
metric behavior.
NOTE
Seasonal pattern detection is set to a hour, day, or week interval. This means other patterns like bihourly pattern or
semiweekly might not be detected.
What does 'Sensitivity' setting in Dynamic Thresholds mean?

Alert threshold sensitivity is a high-level concept that controls the amount of deviation from metric behavior
required to trigger an alert. This option doesn't require domain knowledge about the metric like static threshold.
The options available are:
High – The thresholds will be tight and close to the metric series pattern. An alert rule will be triggered on the
smallest deviation, resulting in more alerts.
Medium – Less tight and more balanced thresholds, fewer alerts than with high sensitivity (default).
Low – The thresholds will be loose with more distance from metric series pattern. An alert rule will only trigger
on large deviations, resulting in fewer alerts.
What are the 'Operator' setting options in Dynamic Thresholds?

Dynamic Thresholds alerts rule can create tailored thresholds based on metric behavior for both upper and lower
bounds using the same alert rule. You can choose the alert to be triggered on one of the following three
conditions:
Greater than the upper threshold or lower than the lower threshold (default)
Greater than the upper threshold
Lower than the lower threshold.
What do the advanced settings in Dynamic Thresholds mean?

Failing Periods - Dynamic Thresholds also allows you to configure “Number violations to trigger the alert”, a
minimum number of deviations required within a certain time window for the system to raise an alert (the default
time window is four deviations in 20 minutes). The user can configure failing periods and choose what to be
alerted on by changing the failing periods and time window. This ability reduces alert noise generated by transient
spikes. For example:
To trigger an alert when the issue is continuous for 20 minutes, 4 consecutive times in a given period grouping of
5 minutes, use the following settings:
To trigger an alert when there was a violation from a Dynamic Thresholds in 20 minutes out of the last 30 minutes
with period of 5 minutes, use the following settings:
Ignore data before - Users may also optionally define a start date from which the system should begin
calculating the thresholds from. A typical use case may occur when a resource was a running in a testing mode
and is now promoted to serve a production workload, and therefore the behavior of any metric during the testing
phase should be disregarded.
How do you find out why a Dynamic Thresholds alert was triggered?
You can explore triggered alert instances in the alerts view either by clicking on the link in the email or text
message, or browser to see the alerts view in the Azure portal. Learn more about the alerts view.
The alert view displays:
All the metric details at the moment the Dynamic Thresholds alert fired.
A chart of the period in which the alert was triggered that includes the Dynamic Thresholds used at that point
in time.
Ability to provide feedback on Dynamic Thresholds alert and the alerts view experience, which could improve
future detections.
Will slow behavior change in the metric trigger an alert?

Probably not. Dynamic Thresholds are good for detecting significant deviations rather than slowly evolving issues.
How much data is used to preview and then calculate thresholds?

The thresholds appearing in the chart, before an alert rule is created on the metric, are calculated based on
enough historical data to calculate hour or daily seasonal patterns (10 days). Once an alert rule is created, the
Dynamic Thresholds will use all needed historical data that is available and will continuously learn and adapt
based on new data to make the thresholds more accurate. This means that after this calculation, the chart will also
display weekly patterns.
How much data is needed to trigger an alert?

If you have a new resource or missing metric data, Dynamic Thresholds won't trigger alerts before three days of
data are available to ensure accurate thresholds.
Dynamic Thresholds best practices

Dynamic Thresholds can be applied to any platform or custom metric in Azure Monitor and it was also tuned for
the common application and infrastructure metrics. The following items are best practices on how to configure
alerts on some of these metrics using Dynamic Thresholds.
Dynamic Thresholds on virtual machine CPU percentage metrics
1. In Azure portal, click on Monitor. The Monitor view consolidates all your monitoring settings and data in
one view.
TIP
Most resource blades also have Alerts in their resource menu under Monitoring, you could create alerts from there
as well.
3. Click Select target, in the context pane that loads, select a target resource that you want to alert on. Use
Subscription and 'Virtual Machines' Resource type drop-downs to find the resource you want to
monitor. You can also use the search bar to find your resource.
5. Select the 'CPU Percentage'.
6. Optionally, refine the metric by adjusting Period and Aggregation. It is discouraged to use 'Maximum'
aggregation type for this metric type as it is less representative of behavior. For 'Maximum' aggregation
type static threshold maybe more appropriate.
7. You will see a chart for the metric for the last 6 hours. Define the alert parameters:
a. Condition Type - Choose 'Dynamic' option.
b. Sensitivity - Choose Medium/Low sensitivity to reduce alert noise.
c. Operator - Choose 'Greater Than' unless behavior represents the application usage.
d. Frequency - Consider lowering based on business impact of the alert.
e. Failing Periods (Advanced Option) - The look back window should be at least 15 minutes. For example,
if the period is set to five minutes, then failing periods should be at least three or more.
8. The metric chart will display the calculated thresholds based on recent data.
9. Click Done.
10. Fill in Alert details like Alert Rule Name, Description, and Severity.
11. Add an action group to the alert either by selecting an existing action group or creating a new action group.
NOTE
Dynamic Thresholds on Application Insights HTTP request execution time

1. In Azure portal, click on Monitor. The Monitor view consolidates all your monitoring settings and data in
one view.
TIP
Most resource blades also have Alerts in their resource menu under Monitoring, you could create alerts from there
as well.
3. Click Select target, in the context pane that loads, select a target resource that you want to alert on. Use
Subscription and 'Application Insights' Resource type drop-downs to find the resource you want to
monitor. You can also use the search bar to find your resource.
5. Select the 'HTTP request execution time'.
6. Optionally, refine the metric by adjusting Period and Aggregation. It is discouraged to use 'Maximum'
aggregation type for this metric type as it is less representative of behavior. For 'Maximum' aggregation
type static threshold maybe more appropriate.
7. You will see a chart for the metric for the last 6 hours. Define the alert parameters:
a. Condition Type - Choose 'Dynamic' option.
b. Operator - Choose 'Greater Than' to reduce alerts fired on improvement in duration.
c. Frequency - Consider lowering based on business impact of the alert.
8. The metric chart will display the calculated thresholds based on recent data.
9. Click Done.
10. Fill in Alert details like Alert Rule Name, Description, and Severity.
11. Add an action group to the alert either by selecting an existing action group or creating a new action group.
NOTE
Create Metric Alerts for Logs in Azure Monitor
Overview
NOTE
PowerShell.
Azure Monitor supports metric alert type which has benefits over the classic alerts. Metrics are available for large
list of Azure services. This article explains usage of a subset (that is) for resource -
Microsoft.OperationalInsights/workspaces .
You can use metric alerts on popular Log Analytics logs extracted as metrics as part of Metrics from Logs
including resources in Azure or on-premise. The supported Log Analytics solutions are listed below:
Performance counters for Windows & Linux machines
Heartbeat records for Agent Health
Update management records
Event data logs
There are many benefits for using Metric Alerts for Logs over query based Log Alerts in Azure; some of them
are listed below:
Metric Alerts offer near-real time monitoring capability and Metric Alerts for Logs forks data from log source
to ensure the same.
Metric Alerts are stateful - only notifying once when alert is fired and once when alert is resolved; as opposed
to Log alerts, which are stateless and keep firing at every interval if the alert condition is met.
Metric Alerts for Log provide multiple dimensions, allowing filtering to specific values like Computers, OS
Type, etc. simpler; without the need for penning query in analytics.
NOTE
Specific metric and/or dimension will only be shown if data for it exists in chosen period. These metrics are available for
customers with Azure Log Analytics workspaces.
Metrics and dimensions supported for logs

Metric alerts support alerting for metrics that use dimensions. You can use dimensions to filter your metric to the
right level. The full list of metrics supported for Logs from Log Analytics workspaces is listed; across supported
solutions.
NOTE
To view supported metrics for being extracted from Log Analytics workspace via Azure Monitor - Metrics; a metric alert for
log must be created for the said metric. The dimensions chosen in Metric Alert for logs - will only appear for exploration via
Azure Monitor - Metrics.
Creating metric alert for Log Analytics

Metric data from popular logs is piped before it is processed in Log Analytics, into Azure Monitor - Metrics. This
allows users to leverage the capabilities of the Metric platform as well as metric alert - including having alerts with
frequency as low as 1 minute. Listed below are the means of crafting a metric alert for logs.
Prerequisites for Metric Alert for Logs

Before Metric for Logs gathered on Log Analytics data works, the following must be set up and available:
1. Active Log Analytics Workspace: A valid and active Log Analytics workspace must be present. For more
information, see Create a Log Analytics Workspace in Azure portal.
2. Agent is configured for Log Analytics Workspace: Agent needs to be configured for Azure VMs (and/or)
On-Premise VMs to send data into the Log Analytics Workspace used in earlier step. For more information,
see Log Analytics - Agent Overview.
3. Supported Log Analytics Solutions is installed: Log Analytics solution should be configured and sending
data into Log Analytics workspace - supported solutions are Performance counters for Windows & Linux,
Heartbeat records for Agent Health, Update management, and Event data.
4. Log Analytics solutions configured to send logs: Log Analytics solution should have the required logs/data
corresponding to metrics supported for Log Analytics workspaces enabled. For example, for % Available
Memory counter of it must be configured in Performance counters solution first.
Configuring Metric Alert for Logs

Metric alerts can be created and managed using the Azure portal, Resource Manager Templates, REST API,
PowerShell, and Azure CLI. Since Metric Alerts for Logs, is a variant of metric alerts - once the prerequisites are
done, metric alert for logs can be created for specified Log Analytics workspace. All characteristics and
functionalities of metric alerts will be applicable to metric alerts for logs, as well; including payload schema,
applicable quota limits, and billed price.
For step-by-step details and samples - see creating and managing metric alerts. Specifically, for Metric Alerts for
Logs - follow the instructions for managing metric alerts and ensure the following:
Target for metric alert is a valid Log Analytics workspace
Signal chosen for metric alert for selected Log Analytics workspace is of type Metric
Filter for specific conditions or resource using dimension filters; metrics for logs are multi-dimensional
When configuring Signal Logic, a single alert can be created to span multiple values of dimension (like
Computer)
If not using Azure portal for creating metric alert for selected Log Analytics workspace; then user must
manually first create an explicit rule for converting log data into a metric using Azure Monitor - Scheduled
Query Rules.
NOTE
When creating metric alert for Log Analytics workspace via Azure portal - corresponding rule for converting log data into
metric via Azure Monitor - Scheduled Query Rules is automatically created in background, without the need of any user
intervention or action. For metric alert for logs creation using means other than Azure portal, see Resource Template for
Metric Alerts for Logs section on sample means of creating a ScheduledQueryRule based log to metric conversion rule
before metric alert creation - else there will be no data for the metric alert on logs created.
Resource Template for Metric Alerts for Logs

As stated earlier, the process for creation of metric alerts from logs is two pronged:
1. Create a rule for extracting metrics from supported logs using scheduledQueryRule API
2. Create a metric alert for metric extracted from log (in step1) and Log Analytics workspace as a target resource
Metric Alerts for Logs with static threshold
To achieve the same, one can use the sample Azure Resource Manager Template below - where creation of a static
threshold metric alert depends on successful creation of the rule for extracting metrics from logs via
scheduledQueryRule.
{
"parameters": {
"convertRuleName": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the rule to convert log to metric"
}
},
"convertRuleDescription": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Description for log converted to metric"
}
},
"convertRuleRegion": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the region used by workspace"
}
},
"convertRuleStatus": {
"type": "string",
"defaultValue": "true",
"metadata": {
"description": "Specifies whether the log conversion rule is enabled"
}
},
"convertRuleMetric": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric once extraction done from logs."
}
},
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
"metadata": {
"description": "Name of the alert"
}
},
"alertDescription": {
"type": "string",
"defaultValue": "This is a metric alert",
"metadata": {
"description": "Description of alert"
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
"description": "Severity of alert {0,1,2,3,4}"
}
},
"isEnabled": {
"type": "bool",
"defaultValue": true,
"metadata": {
"description": "Specifies whether the alert is enabled"
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Full Resource ID of the resource emitting the metric that will be used for the
comparison. For example /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName/providers/Microsoft.compute/virtualMachines/VM_xyz"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric used in the comparison to activate the alert."
}
},
"operator": {
"type": "string",
"defaultValue": "GreaterThan",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"GreaterThanOrEqual",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
"description": "Operator comparing the current value with the threshold value."
}
},
"threshold": {
"type": "string",
"defaultValue": "0",
"metadata": {
"description": "The threshold value at which the alert is activated."
}
},
"timeAggregation": {
"type": "string",
"defaultValue": "Average",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total"
],
"metadata": {
"description": "How the data that is collected should be combined over time."
}
},
"windowSize": {
"type": "string",
"defaultValue": "PT5M",
"metadata": {
"description": "Period of time used to monitor alert activity based on the threshold. Must be
between five minutes and one day. ISO 8601 duration format."
}
},
"evaluationFrequency": {
"type": "string",
"metadata": {
"description": "how often the metric alert is evaluated represented in ISO 8601 duration
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "The ID of the action group that is triggered when the alert is activated or
deactivated"
}
}
},
"variables": {
"convertRuleTag": "hidden-link:/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName",
"convertRuleSourceWorkspace": {
"SourceId": "/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"resources": [
{
"name": "[parameters('convertRuleName')]",
"type": "Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[parameters('convertRuleRegion')]",
"tags": {
"[variables('convertRuleTag')]": "Resource"
},
"properties": {
"description": "[parameters('convertRuleDescription')]",
"enabled": "[parameters('convertRuleStatus')]",
"source": {
"dataSourceId": "[variables('convertRuleSourceWorkspace').SourceId]"
},
"action": {
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resource
s.ScheduledQueryRules.LogToMetricAction",
"criteria": [{
"metricName": "[parameters('convertRuleMetric')]",
"dimensions": []
}
]
}
}
},
{
"name": "[parameters('alertName')]",
"type": "Microsoft.Insights/metricAlerts",
"apiVersion": "2018-03-01",
"tags": {},
"dependsOn":["
[resourceId('Microsoft.Insights/scheduledQueryRules',parameters('convertRuleName'))]"],
"properties": {
"description": "[parameters('alertDescription')]",
"severity": "[parameters('alertSeverity')]",
"enabled": "[parameters('isEnabled')]",
"scopes": ["[parameters('resourceId')]"],
"evaluationFrequency":"[parameters('evaluationFrequency')]",
"windowSize": "[parameters('windowSize')]",
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria",
"allOf": [
{
"name" : "1st criterion",
"metricName": "[parameters('metricName')]",
"dimensions":[],
"operator": "[parameters('operator')]",
"threshold" : "[parameters('threshold')]",
"timeAggregation": "[parameters('timeAggregation')]"
}
]
},
"actions": [
{
"actionGroupId": "[parameters('actionGroupId')]"
}
]
}
}
]
}
Say the above JSON is saved as metricfromLogsAlertStatic.json - then it can be coupled with a parameter JSON
file for Resource Template based creation. A sample parameter JSON file is listed below:
{
"parameters": {
"value": "TestLogtoMetricRule"
},
"value": "Test rule to extract metrics from logs via template"
},
"value": "West Central US"
},
"value": "true"
},
"value": "Average_% Idle Time"
},
"alertName": {
"value": "TestMetricAlertonLog"
},
"value": "New multi-dimensional metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/1234-56789-1234-
567a/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
},
"metricName":{
},
"operator": {
"value": "GreaterThan"
},
"threshold":{
"value": "1"
},
"timeAggregation":{
"value": "Average"
},
"actionGroupId": {
567a/resourceGroups/myRG/providers/microsoft.insights/actionGroups/actionGroupName"
}
}
}
Assuming the above parameter file is saved as metricfromLogsAlertStatic.parameters.json; then one can create
metric alert for logs using Resource Template for creation in Azure portal.
Alternatively, one can use the Azure Powershell command below as well:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile metricfromLogsAlertStatic.json

TemplateParameterFile metricfromLogsAlertStatic.parameters.json
Or use deploy Resource Template using Azure CLI:

az group deployment create --resource-group myRG --template-file metricfromLogsAlertStatic.json --parameters
@metricfromLogsAlertStatic.parameters.json
Metric Alerts for Logs with Dynamic Thresholds

To achieve the same, one can use the sample Azure Resource Manager Template below - where creation of a
Dynamic Thresholds metric alert depends on successful creation of the rule for extracting metrics from logs via
scheduledQueryRule.
{
"parameters": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the rule to convert log to metric"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Description for log converted to metric"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the region used by workspace"
}
},
"type": "string",
"defaultValue": "true",
"metadata": {
"description": "Specifies whether the log conversion rule is enabled"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric once extraction done from logs."
}
},
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"defaultValue": "GreaterOrLessThan",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"alertSensitivity": {
"type": "string",
"defaultValue": "Medium",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
"description": "Tunes how 'noisy' the Dynamic Thresholds alerts will be: 'High' will result in
more alerts while 'Low' will result in fewer alerts."
}
},
"numberOfEvaluationPeriods": {
"type": "string",
"metadata": {
"description": "The number of periods to check in the alert evaluation."
}
},
"minFailingPeriodsToAlert": {
"type": "string",
"metadata": {
"metadata": {
"description": "The number of unhealthy periods to alert on (must be lower or equal to
numberOfEvaluationPeriods)."
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"convertRuleTag": "hidden-link:/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName",
"convertRuleSourceWorkspace": {
"SourceId": "/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"resources": [
{
"name": "[parameters('convertRuleName')]",
"type": "Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[parameters('convertRuleRegion')]",
"tags": {
"[variables('convertRuleTag')]": "Resource"
},
"properties": {
"description": "[parameters('convertRuleDescription')]",
"enabled": "[parameters('convertRuleStatus')]",
"source": {
"dataSourceId": "[variables('convertRuleSourceWorkspace').SourceId]"
},
"action": {
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resource
"criteria": [{
"metricName": "[parameters('convertRuleMetric')]",
"dimensions": []
}
]
}
}
},
{
"apiVersion": "2018-03-01",
"tags": {},
"dependsOn":["
[resourceId('Microsoft.Insights/scheduledQueryRules',parameters('convertRuleName'))]"],
"properties": {
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.MultipleResourceMultipleMetricCriteria",
"allOf": [
{
"criterionType": "DynamicThresholdCriterion",
"dimensions":[],
"alertSensitivity": "[parameters('alertSensitivity')]",
"failingPeriods": {
"numberOfEvaluationPeriods": "[parameters('numberOfEvaluationPeriods')]",
"minFailingPeriodsToAlert": "[parameters('minFailingPeriodsToAlert')]"
},
}
]
},
"actions": [
{
}
]
}
}
]
}
Say the above JSON is saved as metricfromLogsAlertDynamic.json - then it can be coupled with a parameter
JSON file for Resource Template based creation. A sample parameter JSON file is listed below:
{
"parameters": {
"value": "TestLogtoMetricRule"
},
"value": "Test rule to extract metrics from logs via template"
},
"value": "West Central US"
},
"value": "true"
},
},
"alertName": {
"value": "TestMetricAlertonLog"
},
"value": "New multi-dimensional metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
567a/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
},
"metricName":{
},
"operator": {
"value": "GreaterOrLessThan"
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"timeAggregation":{
"value": "Average"
},
"actionGroupId": {
567a/resourceGroups/myRG/providers/microsoft.insights/actionGroups/actionGroupName"
}
}
}
Assuming the above parameter file is saved as metricfromLogsAlertDynamic.parameters.json; then one can create
metric alert for logs using Resource Template for creation in Azure portal.
Alternatively, one can use the Azure Powershell command below as well:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile metricfromLogsAlertDynamic.json
TemplateParameterFile metricfromLogsAlertDynamic.parameters.json
Or use deploy Resource Template using Azure CLI:
az group deployment create --resource-group myRG --template-file metricfromLogsAlertDynamic.json --parameters

@metricfromLogsAlertDynamic.parameters.json
Next steps
Learn more about the metric alerts.
Learn about log alerts in Azure.
Learn about alerts in Azure.
Create a metric alert with a Resource Manager
template
NOTE
PowerShell.
This article shows how you can use an Azure Resource Manager template to configure newer metric alerts in
Azure Monitor. Resource Manager templates enable you to programmatically set up alerts in a consistent and
reproducible way across your environments. Newer metric alerts are currently available on this set of resource
types.
IMPORTANT
Resource template for creating metric alerts for resource type: Azure Log Analytics Workspace (i.e.)
Microsoft.OperationalInsights/workspaces , requires additional steps. For details, see the article on Metric Alert for Logs
- Resource Template.
The basic steps are as follows:

1. Use one of the templates below as a JSON file that describes how to create the alert.
2. Edit and use the corresponding parameters file as a JSON to customize the alert
3. Deploy the template using any deployment method.
Template for a simple static threshold metric alert

To create an alert using a Resource Manager template, you create a resource of type
Microsoft.Insights/metricAlerts and fill in all related properties. Below is a sample template that creates a metric
alert rule.
Save the json below as simplestaticmetricalert.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
between one minute and one day. ISO 8601 duration format."
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
An explanation of the schema and properties for an alert rule is available here.
You can set the values for the parameters either on the command line or through a parameter file. A sample
parameter file is provided below.
Save the json below as simplestaticmetricalert.parameters.json and modify it as required.
{
"parameters": {
"alertName": {
"value": "New Metric Alert"
},
"value": "New metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resourceGroup-
name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
"value": "Percentage CPU"
},
"operator": {
},
"threshold": {
"value": "80"
},
"value": "Average"
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.Insights/actionGroups/replace-with-action-group"
}
}
}
You can create the metric alert using the template and parameters file using PowerShell or Azure CLI.
Using Azure PowerShell
Connect-AzAccount
New-AzResourceGroupDeployment -Name AlertDeployment -ResourceGroupName ResourceGroupofTargetResource `

-TemplateFile simplestaticmetricalert.json -TemplateParameterFile simplestaticmetricalert.parameters.json
Using Azure CLI
az login
az group deployment create \

--name AlertDeployment \
--resource-group ResourceGroupofTargetResource \
--template-file simplestaticmetricalert.json \
--parameters @simplestaticmetricalert.parameters.json
NOTE
While the metric alert could be created in a different resource group to the target resource, we recommend using the same
resource group as your target resource.
Template for a simple Dynamic Thresholds metric alert

Microsoft.Insights/metricAlerts and fill in all related properties. Below is a sample template that creates a metric
alert rule.
Save the json below as simpledynamicmetricalert.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
between five minutes and one hour. ISO 8601 duration format."
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
Save the json below as simpledynamicmetricalert.parameters.json and modify it as required.
{
"parameters": {
"alertName": {
"value": "New Metric Alert with Dynamic Thresholds"
},
"value": "New metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.Insights/actionGroups/replace-with-action-group"
}
}
}
You can create the metric alert using the template and parameters file using PowerShell or Azure CLI.
Connect-AzAccount

-TemplateFile simpledynamicmetricalert.json -TemplateParameterFile simpledynamicmetricalert.parameters.json
Using Azure CLI

az login

--template-file simpledynamicmetricalert.json \
--parameters @simpledynamicmetricalert.parameters.json
NOTE
Template for a more advanced static threshold metric alert

Newer metric alerts support alerting on multi-dimensional metrics as well as supporting multiple criteria. You can
use the following template to create a more advanced metric alert on dimensional metrics and specify multiple
criteria.
Save the json below as advancedstaticmetricalert.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
"metadata": {
"description": "Resource ID of the resource emitting the metric that will be used for the
comparison."
}
},
"criterion1":{
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an operator.
The alert rule fires when ALL criteria are met"
}
},
"criterion2": {
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an operator.
The alert rule fires when ALL criteria are met"
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"criterion1": "[array(parameters('criterion1'))]",
"criterion2": "[array(parameters('criterion2'))]",
"criteria": "[concat(variables('criterion1'),variables('criterion2'))]"
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": "[variables('criteria')]"
},
"actions": [
{
}
]
}
}
]
}
You can use the above template along with the parameter file provided below.
Save and modify the json below as advancedstaticmetricalert.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert (Replace with your alert name)"
},
"value": "New multi-dimensional metric alert created via template (Replace with your alert
description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resourcegroup-
name/providers/Microsoft.Storage/storageAccounts/replace-with-storage-account"
},
"criterion1": {
"value": {
"name": "1st criterion",
"metricName": "Transactions",
"dimensions": [
{
"name":"ResponseType",
"operator": "Include",
"values": ["Success"]
},
{
"name":"ApiName",
"values": ["GetBlob"]
}
],
"operator": "GreaterThan",
"threshold": "5",
"timeAggregation": "Total"
}
},
"criterion2": {
"value":{
"name": "2nd criterion",
"metricName": "SuccessE2ELatency",
"dimensions": [
{
"name":"ApiName",
}
],
"threshold": "250",
"timeAggregation": "Average"
}
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-
name/providers/Microsoft.Insights/actionGroups/replace-with-actiongroup-name"
}
}
}
You can create the metric alert using the template and parameters file using PowerShell or Azure CLI from your
current working directory
Connect-AzAccount

-TemplateFile advancedstaticmetricalert.json -TemplateParameterFile
advancedstaticmetricalert.parameters.json
Using Azure CLI
az login

--template-file advancedstaticmetricalert.json \
--parameters @advancedstaticmetricalert.parameters.json
NOTE
Template for a more advanced Dynamic Thresholds metric alert

You can use the following template to create a more advanced Dynamic Thresholds metric alert on dimensional
metrics. Multiple criteria are not currently supported.
Dynamic Thresholds alerts rule can create tailored thresholds for hundreds of metric series (even different types)
at a time, which results in fewer alert rules to manage.
Save the json below as advanceddynamicmetricalert.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion":{
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an operator."
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"criteria": "[array(parameters('criterion'))]"
},
"resources": [
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": "[variables('criteria')]"
},
"actions": [
{
}
]
}
}
]
}
You can use the above template along with the parameter file provided below.
Save and modify the json below as advanceddynamicmetricalert.parameters.json for the purpose of this
walkthrough.
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert with Dynamic Thresholds (Replace with your alert
name)"
},
"value": "New multi-dimensional metric alert with Dynamic Thresholds created via template (Replace
with your alert description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resourcegroup-
name/providers/Microsoft.Storage/storageAccounts/replace-with-storage-account"
},
"criterion1": {
"value": {
"name": "1st criterion",
"dimensions": [
{
"name":"ResponseType",
"values": ["Success"]
},
{
"name":"ApiName",
}
],
"operator": "GreaterOrLessThan",
"alertSensitivity": "Medium",
"failingPeriods": {
"numberOfEvaluationPeriods": "4",
"minFailingPeriodsToAlert": "3"
},
"timeAggregation": "Total"
}
}
"actionGroupId": {
name/providers/Microsoft.Insights/actionGroups/replace-with-actiongroup-name"
}
}
}
current working directory
Connect-AzAccount

-TemplateFile advanceddynamicmetricalert.json -TemplateParameterFile
advanceddynamicmetricalert.parameters.json
Using Azure CLI
az login

--template-file advanceddynamicmetricalert.json \
--parameters @advanceddynamicmetricalert.parameters.json
NOTE
Template for metric alert that monitors multiple resources

The previous sections described sample Azure Resource Manager templates to create metric alerts that monitor a
single resource. Azure Monitor now supports monitoring multiple resources with a single metric alert rule. This
feature is currently only supported in Azure public cloud and only for virtual Machines and Databox Edge Devices.
Dynamic Thresholds alerts rule can also help create tailored thresholds for hundreds of metric series (even
different types) at a time, which results in fewer alert rules to manage.
This section will describe Azure Resource Manager templates for three scenarios to monitor multiple resources
with a single rule.
Monitoring all virtual machines (in one Azure region) in one or more resource groups.
Monitoring all virtual machines (in one Azure region) in a subscription
Monitoring a list of virtual machines (in one Azure region) in a subscription.
Static threshold alert on all virtual machines in one or more resource groups
This template will create a static threshold metric alert rule that monitors Percentage CPU for all virtual machines
(in one Azure region) in one or more resource groups.
Save the json below as all-vms-in-resource-group-static.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"targetResourceGroup":{
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored are
in. For example - /subscriptions/00000000-0000-0000-0000-0000-00000000/resourceGroups/ResourceGroupName"
}
},
"targetResourceRegion":{
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"GermanyWestCentral",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaSoutheast",
"AustraliaCentral",
"AustraliaCentral2",
"ChinaEast",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
"description": "Azure region in which target resources to be monitored are in (without
spaces). For example: EastUS"
}
},
"targetResourceType": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Resource type of target resources to be monitored. Currently only supported
resource type is Microsoft.Compute/virtualMachines"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceGroup')]",
"targetResourceType": "[parameters('targetResourceType')]",
"targetResourceRegion": "[parameters('targetResourceRegion')]",
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
You can use the above template with the parameter file below. Save and modify the json below as all-vms-in-
resource-group-static.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-
name1",
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-name2"
]
},
"value": "SouthCentralUS"
},
"targetResourceType":{
"value": "Microsoft.Compute/virtualMachines"
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
name/providers/Microsoft.Insights/actionGroups/replace-with-action-group-name"
}
}
}
You can create the static metric alert using the template and parameters file using PowerShell or Azure CLI from
your current working directory.
Connect-AzAccount
New-AzResourceGroupDeployment -Name MultiResourceAlertDeployment -ResourceGroupName

ResourceGroupWhereRuleShouldbeSaved `
-TemplateFile all-vms-in-resource-group-static.json -TemplateParameterFile all-vms-in-resource-group-
static.parameters.json
Using Azure CLI
az login

--name MultiResourceAlertDeployment \
--resource-group ResourceGroupWhereRuleShouldbeSaved \
--template-file all-vms-in-resource-group-static.json \
--parameters @all-vms-in-resource-group-static.parameters.json
Dynamic Thresholds alert on all virtual machines in one or more resource groups
This template will create a Dynamic Thresholds metric alert rule that monitors Percentage CPU for all virtual
machines (in one Azure region) in one or more resource groups.
Save the json below as all-vms-in-resource-group-dynamic.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored are
in. For example - /subscriptions/00000000-0000-0000-0000-0000-00000000/resourceGroups/ResourceGroupName"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceGroup')]",
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
resource-group-dynamic.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1",
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
current working directory.
Connect-AzAccount

-TemplateFile all-vms-in-resource-group-dynamic.json -TemplateParameterFile all-vms-in-resource-group-
dynamic.parameters.json
Using Azure CLI
az login

--template-file all-vms-in-resource-group-dynamic.json \
--parameters @all-vms-in-resource-group-dynamic.parameters.json
Static threshold alert on all virtual machines in a subscription

This template will create a static threshold metric alert rule that monitors Percentage CPU for all virtual machines
(in one Azure region) in a subscription.
Save the json below as all-vms-in-subscription-static.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
},
"targetSubscription":{
"type": "string",
"minLength": 1,
"metadata": {
"description": "Azure Resource Manager path up to subscription ID. For example -
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": ["[parameters('targetSubscription')]"],
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
subscription-static.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource sub level metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": "/subscriptions/replace-with-subscription-id"
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile all-vms-in-subscription-static.json -TemplateParameterFile all-vms-in-subscription-
static.parameters.json
Using Azure CLI

az login

--template-file all-vms-in-subscription-static.json \
--parameters @all-vms-in-subscription.parameters-static.json
Dynamic Thresholds alert on all virtual machines in a subscription

This template will create a Dynamic Thresholds metric alert rule that monitors Percentage CPU for all virtual
machines (in one Azure region) in a subscription.
Save the json below as all-vms-in-subscription-dynamic.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Azure Resource Manager path up to subscription ID. For example -
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": ["[parameters('targetSubscription')]"],
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
subscription-dynamic.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert with Dynamic Thresholds via Azure Resource Manager
template"
},
"value": "New Multi-resource sub level metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": "/subscriptions/replace-with-subscription-id"
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile all-vms-in-subscription-dynamic.json -TemplateParameterFile all-vms-in-subscription-
dynamic.parameters.json
Using Azure CLI
az login

--template-file all-vms-in-subscription-dynamic.json \
--parameters @all-vms-in-subscription-dynamic.parameter-dynamics.json
Static threshold alert on a list of virtual machines

This template will create a static threshold metric alert rule that monitors Percentage CPU for a list of virtual
Save the json below as list-of-vms-static.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"targetResourceId":{
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-0000-
0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H""
],
"metadata": {
format"
}
},
"actionGroupId": {
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceId')]",
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
You can use the above template with the parameter file below. Save and modify the json below as list-of-vms-
static.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert by list via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1/Microsoft.Compute/virtualMachines/replace-with-vm-name1",
name2/Microsoft.Compute/virtualMachines/replace-with-vm-name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile list-of-vms-static.json -TemplateParameterFile list-of-vms-static.parameters.json
Using Azure CLI

az login

--template-file list-of-vms-static.json \
--parameters @list-of-vms-static.parameters.json
Dynamic Thresholds alert on a list of virtual machines

This template will create a Dynamic Thresholds metric alert rule that monitors Percentage CPU for a list of virtual
Save the json below as list-of-vms-dynamic.json for the purpose of this walk-through.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-0000-
0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceId')]",
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
You can use the above template with the parameter file below. Save and modify the json below as list-of-vms-
dynamic.parameters.json for the purpose of this walkthrough.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds by list via Azure Resource Manager
template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1/Microsoft.Compute/virtualMachines/replace-with-vm-name1",
name2/Microsoft.Compute/virtualMachines/replace-with-vm-name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile list-of-vms-dynamic.json -TemplateParameterFile list-of-vms-dynamic.parameters.json
Using Azure CLI
az login

--template-file list-of-vms-dynamic.json \
--parameters @list-of-vms-dynamic.parameters.json
Template for a Availability test along with availability test alert

Application Insights availability tests help you monitor the availability of your web site/application from various
locations around the globe. Availability test alerts notify you when availability tests fail from a certain number of
locations. Availability test alerts of the same resource type as metric alerts (Microsoft.Insights/metricAlerts). The
following sample Azure Resource Manager Template can be used to set up a simple availability test and associated
alert.
Save the json below as availabilityalert.json for the purpose of this walkthrough.
{
"parameters": {
"appName": {
"type": "string"
},
"pingURL": {
"type": "string"
},
"pingText": {
"type": "string",
"defaultValue": ""
},
"actionGroupId": {
"type": "string"
}
},
"variables": {
"pingTestName": "[concat('PingTest-', toLower(parameters('appName')))]",
"pingAlertRuleName": "[concat('PingAlert-', toLower(parameters('appName')), '-',
subscription().subscriptionId)]"
},
"resources": [
{
"name": "[variables('pingTestName')]",
"type": "Microsoft.Insights/webtests",
"apiVersion": "2014-04-01",
"location": "West Central US",
"tags": {
"[concat('hidden-link:', resourceId('Microsoft.Insights/components', parameters('appName')))]":
"Resource"
},
"properties": {
"properties": {
"Name": "[variables('pingTestName')]",
"Description": "Basic ping test",
"Enabled": true,
"Frequency": 300,
"Timeout": 120,
"Kind": "ping",
"RetryEnabled": true,
"Locations": [
{
"Id": "us-va-ash-azr"
},
{
"Id": "emea-nl-ams-azr"
},
{
"Id": "apac-jp-kaw-edge"
}
],
"Configuration": {
"WebTest": "[concat('<WebTest Name=\"', variables('pingTestName'), '\" Enabled=\"True\"
CssProjectStructure=\"\" CssIteration=\"\" Timeout=\"120\" WorkItemIds=\"\"
xmlns=\"http://microsoft.com/schemas/VisualStudio/TeamTest/2010\" Description=\"\"
CredentialUserName=\"\" CredentialPassword=\"\" PreAuthenticate=\"True\" Proxy=\"default\"
StopOnError=\"False\" RecordedResultFile=\"\" ResultsLocale=\"\"> <Items> <Request Method=\"GET\"
Version=\"1.1\" Url=\"', parameters('pingURL'), '\" ThinkTime=\"0\" Timeout=\"300\"
ParseDependentRequests=\"True\" FollowRedirects=\"True\" RecordResult=\"True\" Cache=\"False\"
ResponseTimeGoal=\"0\" Encoding=\"utf-8\" ExpectedHttpStatusCode=\"200\" ExpectedResponseUrl=\"\"
ReportingName=\"\" IgnoreHttpStatusCode=\"False\" /> </Items> <ValidationRules> <ValidationRule
Classname=\"Microsoft.VisualStudio.TestTools.WebTesting.Rules.ValidationRuleFindText,
Microsoft.VisualStudio.QualityTools.WebTestFramework, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a\" DisplayName=\"Find Text\" Description=\"Verifies the existence of
the specified text in the response.\" Level=\"High\" ExecutionOrder=\"BeforeDependents\">
<RuleParameters> <RuleParameter Name=\"FindText\" Value=\"', parameters('pingText'), '\" />
<RuleParameter Name=\"IgnoreCase\" Value=\"False\" /> <RuleParameter Name=\"UseRegularExpression\"
Value=\"False\" /> <RuleParameter Name=\"PassIfTextFound\" Value=\"True\" /> </RuleParameters>
</ValidationRule> </ValidationRules> </WebTest>')]"
},
"SyntheticMonitorId": "[variables('pingTestName')]"
}
},
{
"name": "[variables('pingAlertRuleName')]",
"apiVersion": "2018-03-01",
"dependsOn": [
"[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]"
],
"tags": {
"Resource",
"[concat('hidden-link:', resourceId('Microsoft.Insights/webtests', variables('pingTestName')))]":
"Resource"
},
"properties": {
"description": "Alert for web test",
"severity": 1,
"enabled": true,
"scopes": [
"[resourceId('Microsoft.Insights/webtests',variables('pingTestName'))]",
"[resourceId('Microsoft.Insights/components',parameters('appName'))]"
],
"evaluationFrequency": "PT1M",
"windowSize": "PT5M",
"templateType": 0,
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.WebtestLocationAvailabilityCriteria",
"webTestId": "[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]",
"componentId": "[resourceId('Microsoft.Insights/components', parameters('appName'))]",
"componentId": "[resourceId('Microsoft.Insights/components', parameters('appName'))]",
"failedLocationCount": 2
},
"actions": [
{
}
]
}
}
]
}
Save the json below as availabilityalert.parameters.json and modify it as required.
{
"parameters": {
"appName": {
"value": "Replace with your Application Insights component name"
},
"pingURL": {
"value": "https://www.yoursite.com"
},
"actionGroupId": {
name/providers/microsoft.insights/actiongroups/replace-with-action-group-name"
}
}
}
You can create the availability test and associated alert using the template and parameters file using PowerShell or
Azure CLI.
Connect-AzAccount
New-AzResourceGroupDeployment -Name AvailabilityAlertDeployment -ResourceGroupName

ResourceGroupofApplicationInsightsComponent `
-TemplateFile availabilityalert.json -TemplateParameterFile availabilityalert.parameters.json
Using Azure CLI
az login

--name AvailabilityAlertDeployment \
--resource-group ResourceGroupofApplicationInsightsComponent \
--template-file availabilityalert.json \
--parameters @availabilityalert.parameters.json
Next steps
Read more about alerts in Azure
Learn how to create an action group with Resource Manager templates
For the JSON syntax and properties, see Microsoft.Insights/metricAlerts template reference.
Create, view, and manage log alerts using Azure
Monitor
Overview
This article shows you how to set up log alerts using the alerts interface inside Azure portal. Definition of an
alert rule is in three parts:
Target: Specific Azure resource, which is to be monitored
Criteria: Specific condition or logic that when seen in Signal, should trigger action
Action: Specific call sent to a receiver of a notification - email, SMS, webhook etc.
The term Log Alerts to describe alerts where signal is log query in a Log Analytics workspace or Application
Insights. Learn more about functionality, terminology, and types from Log alerts - Overview.
NOTE
Popular log data from a Log Analytics workspace is now also available on the metric platform in Azure Monitor. For
details view, Metric Alert for Logs
Managing log alerts from the Azure portal

Detailed next is step-by-step guide to using log alerts using the Azure portal interface.
Create a log alert rule with the Azure portal
1. In the portal, select Monitor and under the MONITOR section - choose Alerts.
2. Select the New Alert Rule button to create a new alert in Azure.
3. The Create Alert section is shown with the three parts consisting of: Define alert condition, Define alert
details, and Define action group.
4. Define the alert condition by using the Select Resource link and specifying the target by selecting a
resource. Filter by choosing the Subscription, Resource Type, and required Resource.
NOTE
For creating a log alert - verify the log signal is available for the selected resource before you proceed.
5. Log Alerts: Ensure Resource Type is an analytics source like Log Analytics or Application Insights and
signal type as Log, then once appropriate resource is chosen, click Done. Next use the Add criteria
button to view list of signal options available for the resource and from the signal list Custom log
search option for chosen log monitor service like Log Analytics or Application Insights.
NOTE
Alerts lists can import analytics query as signal type - Log (Saved Query), as seen in above illustration. So users
can perfect your query in Analytics and then save them for future use in alerts - more details on using saving
query available at using log query in Azure Monitor or shared query in application insights analytics.
6. Log Alerts: Once selected, query for alerting can be stated in Search Query field; if the query syntax is
incorrect the field displays error in RED. If the query syntax is correct - For reference historic data of the
stated query is shown as a graph with option to tweak the time window from last six hours to last week.
NOTE
Historical data visualization can only be shown if the query results have time details. If your query results in
summarized data or specific column values - same is shown as a singular plot. For Metric Measurement type of
Log Alerts using Application Insights or switched to new API, you can specify which specific variable to group the
data by using the Aggregate on option; as illustrated in below:
7. Log Alerts: With the visualization in place, Alert Logic can be selected from shown options of Condition,
Aggregation and finally Threshold. Finally specify in the logic, the time to assess for the specified
condition, using Period option. Along with how often Alert should run by selecting Frequency. Log
Alerts can be based on:
Number of Records: An alert is created if the count of records returned by the query is either greater
than or less than the value provided.
Metric Measurement: An alert is created if each aggregate value in the results exceeds the threshold
value provided and it is grouped by chosen value. The number of breaches for an alert is the number
of times the threshold is exceeded in the chosen time period. You can specify Total breaches for any
combination of breaches across the results set or Consecutive breaches to require that the breaches
must occur in consecutive samples.
8. As the second step, define a name for your alert in the Alert rule name field along with a Description
detailing specifics for the alert and Severity value from the options provided. These details are reused
in all alert emails, notifications, or push done by Azure Monitor. Additionally, user can choose to
immediately activate the alert rule on creation by appropriately toggling Enable rule upon creation
option.
For Log Alerts only, some additional functionality is available in Alert details:
Suppress Alerts: When you turn on suppression for the alert rule, actions for the rule are
disabled for a defined length of time after creating a new alert. The rule is still running and
creates alert records provided the criteria is met. Allowing you time to correct the problem
without running duplicate actions.
TIP
Specify an suppress alert value greater than frequency of alert to ensure notifications are stopped
without overlap
9. As the third and final step, specify if any Action Group needs to be triggered for the alert rule when
alert condition is met. You can choose any existing Action Group with alert or create a new Action
Group. According to selected Action Group, when alert is trigger Azure will: send email(s), send SMS (s),
call Webhook(s), remediate using Azure Runbooks, push to your ITSM tool, etc. Learn more about
Action Groups.
NOTE
Refer to the Azure subscription service limits for limits on Runbook payloads triggered for log alerts via Azure
action groups
For Log Alerts some additional functionality is available to override the default Actions:
Email Notification: Overrides e-mail subject in the email, sent via Action Group; if one or more
email actions exist in the said Action Group. You cannot modify the body of the mail and this field
is not for email address.
Include custom Json payload: Overrides the webhook JSON used by Action Groups; if one or
more webhook actions exist in the said Action Group. User can specify format of JSON to be
used for all webhooks configured in associated Action Group; for more information on webhook
formats, see webhook action for Log Alerts. View Webhook option is provided to check format
using sample JSON data.
10. If all fields are valid and with green tick the create alert rule button can be clicked and an alert is
created in Azure Monitor - Alerts. All alerts can be viewed from the alerts Dashboard.
Within a few minutes, the alert is active and triggers as previously described.
Users can also finalized their analytics query in log analytics and then push it to create an alert via 'Set Alert'
button - then following instructions from Step 6 onwards in the above tutorial.
View & manage log alerts in Azure portal

1. In the portal, select Monitor and under the MONITOR section - choose Alerts.
2. The Alerts Dashboard is displayed - wherein all Azure Alerts (including log alerts) are displayed in a
singular board; including every instance of when your log alert rule has fired. To learn more, see Alert
Management.
NOTE
Log alert rules comprise of custom query-based logic provided by users and hence without a resolved state. Due
to which every time the conditions specified in the log alert rule are met, it is fired.
3. Select the Manage rules button on the top bar, to navigate to the rule management section - where all
alert rules created are listed; including alerts that have been disabled.
Managing log alerts using Azure Resource Template

Log alerts in Azure Monitor are associated with resource type Microsoft.Insights/scheduledQueryRules/ . For
more information on this resource type, see Azure Monitor - Scheduled Query Rules API reference. Log alerts
for Application Insights or Log Analytics, can be created using Scheduled Query Rules API.
NOTE
Log alerts for Log Analytics can also be managed using legacy Log Analytics Alert API and legacy templates of Log
Analytics saved searches and alerts as well. For more information on using the new ScheduledQueryRules API detailed
here by default, see Switch to new API for Log Analytics Alerts.
Sample Log alert creation using Azure Resource Template

The following is the structure for Scheduled Query Rules creation based resource template using standard log
search query of number of results type log alert, with sample data set as variables.
{
"parameters": {
},
"variables": {
"alertLocation": "southcentralus",
"alertName": "samplelogalert",
"alertDescription": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"requests",
"SourceId": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/components/sampleAIapplication",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4"
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/actiongroups/sampleAG",
"Subject": "Customized Email Header",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"type":"Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescription')]",
"enabled": "[variables('alertStatus')]",
"source": {
"query": "[variables('alertSource').Query]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resou
rces.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"aznsAction":{
"actionGroup":"[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]"
}
}
}
} ]
}
The sample json above can be saved as (say) sampleScheduledQueryRule.json for the purpose of this walk
through and can be deployed using Azure Resource Manager in Azure portal.
Log alert with cross-resource query using Azure Resource Template
The following is the structure for Scheduled Query Rules creation based resource template using cross-
resource log search query of metric measurement type log alert, with sample data set as variables.
{
"parameters": {
},
"variables": {
"alertLocation": "Region Name for your Application Insights App or Log Analytics Workspace",
"alertName": "sample log alert",
"alertDescr": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"union workspace(\"servicews\").Update, app('serviceapp').requests | summarize
AggregatedValue = count() by bin(TimeGenerated,1h), Classification",
"Resource1": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews",
"Resource2": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/components/serviceapp",
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4",
"SuppressTimeinMin": 20
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"metricMeasurement": {
"thresholdOperator": "Equal",
"threshold": "1",
"metricTriggerType": "Consecutive",
"metricColumn": "Classification"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"type":"Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescr')]",
"enabled": "[variables('alertStatus')]",
"source": {
"query": "[variables('alertSource').Query]",
"authorizedResources": "[concat(array(variables('alertSource').Resource1),
array(variables('alertSource').Resource2))]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resou
rces.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"throttlingInMin": "[variables('alertActions').SuppressTimeinMin]",
"aznsAction":{
"actionGroup": "[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]",
"metricTrigger":{
"thresholdOperator": "[variables('metricMeasurement').thresholdOperator]",
"threshold": "[variables('metricMeasurement').threshold]",
"metricColumn": "[variables('metricMeasurement').metricColumn]",
"metricTriggerType": "[variables('metricMeasurement').metricTriggerType]"
}
}
}
}
}
} ]
}
IMPORTANT
When using cross-resource query in log alert, the usage of authorizedResources is mandatory and user must have
access to the list of resources stated
The sample json above can be saved as (say) sampleScheduledQueryRule.json for the purpose of this walk
through and can be deployed using Azure Resource Manager in Azure portal.
Managing log alerts using PowerShell

NOTE
Azure PowerShell.
Azure Monitor - Scheduled Query Rules API is a REST API and fully compatible with Azure Resource Manager
REST API. And PowerShell cmdlets listed below are available to leverage the Scheduled Query Rules API.
1. New -AzScheduledQueryRule : Powershell cmdlet to create a new log alert rule.
2. Set-AzScheduledQueryRule : Powershell cmdlet to update an existing log alert rule.
3. New -AzScheduledQueryRuleSource : Powershell cmdlet to create or update object specifying source
parameters for a log alert. Used as input by New -AzScheduledQueryRule and Set-AzScheduledQueryRule
cmdlet.
4. New -AzScheduledQueryRuleSchedule: Powershell cmdlet to create or update object specifying schedule
cmdlet.
5. New -AzScheduledQueryRuleAlertingAction : Powershell cmdlet to create or update object specifying action
cmdlet.
6. New -AzScheduledQueryRuleAznsActionGroup : Powershell cmdlet to create or update object specifying
action groups parameters for a log alert. Used as input by New -AzScheduledQueryRuleAlertingAction
cmdlet.
7. New -AzScheduledQueryRuleTriggerCondition : Powershell cmdlet to create or update object specifying
trigger condition parameters for log alert. Used as input by New -AzScheduledQueryRuleAlertingAction
cmdlet.
8. New -AzScheduledQueryRuleLogMetricTrigger : Powershell cmdlet to create or update object specifying
metric trigger condition parameters for metric measurement type log alert. Used as input by New -
AzScheduledQueryRuleTriggerCondition cmdlet.
9. Get-AzScheduledQueryRule : Powershell cmdlet to list existing log alert rules or a specific log alert rule
10. Update-AzScheduledQueryRule : Powershell cmdlet to enable or disable log alert rule
11. Remove-AzScheduledQueryRule: Powershell cmdlet to delete an existing log alert rule
NOTE
ScheduledQueryRules PowerShell cmdlets can only manage rules created cmdlet itself or using Azure Monitor -
Scheduled Query Rules API. Log alert rules created using legacy Log Analytics Alert API and legacy templates of Log
Analytics saved searches and alerts can be managed using ScheduledQueryRules PowerShell cmdlets only after user
switches API preference for Log Analytics Alerts.
Illustrated next are the steps for creation of a sample log alert rule using the scheduledQueryRules PowerShell
cmdlets.
$source = New-AzScheduledQueryRuleSource -Query 'Heartbeat | summarize AggregatedValue = count() by

bin(TimeGenerated, 5m), _ResourceId' -DataSourceId "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servicews"
$schedule = New-AzScheduledQueryRuleSchedule -FrequencyInMinutes 15 -TimeWindowInMinutes 30
$metricTrigger = New-AzScheduledQueryRuleLogMetricTrigger -ThresholdOperator "GreaterThan" -Threshold 2 -

MetricTriggerType "Consecutive" -MetricColumn "_ResourceId"
$triggerCondition = New-AzScheduledQueryRuleTriggerCondition -ThresholdOperator "LessThan" -Threshold 5 -

MetricTrigger $metricTrigger
$aznsActionGroup = New-AzScheduledQueryRuleAznsActionGroup -ActionGroup "/subscriptions/a123d7efg-123c-

1234-5678-a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG" -
EmailSubject "Custom email subject" -CustomWebhookPayload "{ \"alert\":\"#alertrulename\",
\"IncludeSearchResults\":true }"
$alertingAction = New-AzScheduledQueryRuleAlertingAction -AznsAction $aznsActionGroup -Severity "3" -

Trigger $triggerCondition
New-AzScheduledQueryRule -ResourceGroupName "contosoRG" -Location "Region Name for your Application

Insights App or Log Analytics Workspace" -Action $alertingAction -Enabled $true -Description "Alert
description" -Schedule $schedule -Source $source -Name "Alert Name"
Managing log alerts using CLI or API

Azure Monitor - Scheduled Query Rules API is a REST API and fully compatible with Azure Resource Manager
REST API. Hence it can be used via Powershell using Resource Manager commands for Azure CLI.
NOTE
Log alerts for Log Analytics can also be managed using legacy Log Analytics Alert API and legacy templates of Log
Analytics saved searches and alerts as well. For more information on using the new ScheduledQueryRules API detailed
here by default, see Switch to new API for Log Analytics Alerts.
Log alerts currently do not have dedicated CLI commands currently; but as illustrated below can be used via
Azure Resource Manager CLI command for sample Resource Template shown earlier
(sampleScheduledQueryRule.json) in the Resource Template section:
az group deployment create --resource-group contosoRG --template-file sampleScheduledQueryRule.json
On successful operation, 201 will be returned to state new alert rule creation or 200 will be returned if an
existing alert rule was modified.
Next steps
Learn about Log Alerts in Azure Alerts
Understand Webhook actions for log alerts
Learn more about Application Insights
Learn more about log queries.
Log alert queries in Azure Monitor
Alert rules based on Azure Monitor logs run at regular intervals, so you should ensure that they are written to
minimize overhead and latency. This article provides recommendations on writing efficient queries for log alerts
and a process for converting existing queries.
Types of log queries

Log queries in Azure Monitor start with either a table or a search or union operator.
For example the following query is scoped to the SecurityEvent table and searches for specific event ID. This is the
only table that the query must process.
SecurityEvent | where EventID == 4624
Queries that start with search or union allow you to search across multiple columns in a table or even multiple
tables. The following examples show multiple methods for searching the term Memory:
search "Memory"
search * | where == "Memory"
search ObjectName: "Memory"
search ObjectName == "Memory"
union * | where ObjectName == "Memory"
Although search and union are useful during data exploration, searching terms over the entire data model, they
are less efficient than using a table since they must scan across multiple tables. Since queries in alert rules are run
at regular intervals, this can result in excessive overhead adding latency to the alert. Because of this overhead,
queries for log alert rules in Azure should always start with a table to define a clear scope, which improves both
query performance and the relevance of the results.
Unsupported queries
Starting January 11,2019, creating or modifyinglog alert rules that use search , or union operators will not be
supported the inAzure portal. Using these operators in an alert rule will return an error message. Existing alert
rules and alert rules created and edited with the Log Analytics API are not affected by this change. You should still
consider changing any alert rules that use these types of queries though to improve their efficiency.
Log alert rules using cross-resource queries are not affected by this change since cross-resource queriesuse
union , which limits the query scope to specific resources. This is not equivalent of union * which cannot be used.
The following example would be valid in a log alert rule:
union
workspace('Contoso-workspace1').Perf
NOTE
Cross-resource query in log alerts is supported in the new scheduledQueryRules API. By default, Azure Monitor uses the
legacy Log Analytics Alert API for creating new log alert rules from Azure portal, unless you switch from legacy Log Alerts
API. After the switch, the new API becomes the default for new alert rules in Azure portal and it lets you create cross-
resource query log alerts rules. You can create cross-resource query log alert rules without making the switch by using the
ARM template for scheduledQueryRules API – but this alert rule is manageable though scheduledQueryRules API and not
from Azure portal.
Examples
The following examples include log queries that use search and union and provide steps you can use to modify
these queries for use with alert rules.
Example 1
You want to create a log alert rule using the following query which retrieves performance information using
search :
search * | where Type == 'Perf' and CounterName == '% Free Space'

| where CounterValue < 30
| summarize count()
To modify this query, start by using the following query to identify the table that the properties belong to:
search * | where CounterName == '% Free Space'

| summarize by $table
The result of this query would show that the CounterName property came from the Perf table.
You can use this result to create the following query which you would use for the alert rule:
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
| summarize count()
Example 2
You want to create a log alert rule using the following query which retrieves performance information using
search :
search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"

| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)
| count
To modify this query, start by using the following query to identify the table that the properties belong to:
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"

The result of this query would show that the ObjectName and CounterName property came from the Perf table.
You can use this result to create the following query which you would use for the alert rule:
Perf
| where ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage=avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)
| count
Example 3
You want to create a log alert rule using the following query which uses both search and union to retrieve
performance information:
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| where Computer !in ((union * | where CounterName == "% Processor Utility" | summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer| count
To modify this query, start by using the following query to identify the table that the properties in the first part of
the query belong to:
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
The result of this query would show that all these properties came from the Perf table.
Now use union with withsource command to identify which source table has contributed each row.
union withsource=table * | where CounterName == "% Processor Utility"

| summarize by table
The result of this query would show that these properties also came from the Perf table.
You can use these results to create the following query which you would use for the alert rule:
Perf
| where ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total"
| where Computer !in (
(Perf
| where CounterName == "% Processor Utility"
| summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer
| count
Example 4
You want to create a log alert rule using the following query which joins the results of two search queries:
search Type == 'SecurityEvent' and EventID == '4625'

| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
search in (Heartbeat) OSType == 'Windows'
| summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
| project Hour , Computer
)
on Hour
| count
To modify the query, start by using the following query to identify the table that contains the properties in the left
side of the join:
search Type == 'SecurityEvent' and EventID == '4625'
The result indicates that the properties in the left side of the join belong to SecurityEvent table.
Now use the following query to identify the table that contains the properties in the right side of the join:
search in (Heartbeat) OSType == 'Windows'

The result indicates that the properties in the right side of the join belong to Heartbeat table.
You can use these results to create the following query which you would use for the alert rule:
SecurityEvent
| where EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
Heartbeat
| where OSType == 'Windows'
| summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
| project Hour , Computer
)
on Hour
| count
Next steps
Learn about log alerts in Azure Monitor.
Learn about log queries.
Webhook actions for log alert rules
When a log alert is created in Azure, you have the option of configuring it by using action groups to perform one
or more actions. This article describes the different webhook actions that are available and shows how to
configure a custom JSON -based webhook.
NOTE
You also can use the common alert schema for your webhook integrations. The common alert schema provides the
advantage of having a single extensible and unified alert payload across all the alert services in Azure Monitor. Learn about
the common alert schema definitions.
Webhook actions
With webhook actions, you can invoke an external process through a single HTTP POST request. The service
that's called should support webhooks and determine how to use any payload it receives.
Webhook actions require the properties in the following table.
Webhook URL The URL of the webhook.
Custom JSON payload The custom payload to send with the webhook when this
option is chosen during alert creation. For more information,
see Manage log alerts.
NOTE
The View Webhook button alongside the Include custom JSON payload for webhook option for the log alert displays
the sample webhook payload for the customization that was provided. It doesn't contain actual data but is representative of
the JSON schema that's used for log alerts.
Webhooks include a URL and a payload formatted in JSON that the data sent to the external service. By default,
the payload includes the values in the following table. You can choose to replace this payload with a custom one of
your own. In that case, use the variables in the table for each of the parameters to include their values in your
custom payload.
PARAMETER VARIABLE DESCRIPTION
AlertRuleName #alertrulename Name of the alert rule.
Severity #severity Severity set for the fired log alert.
AlertThresholdOperator #thresholdoperator Threshold operator for the alert rule,

which uses greater than or less than.
AlertThresholdValue #thresholdvalue Threshold value for the alert rule.

PARAMETER VARIABLE DESCRIPTION
LinkToSearchResults #linktosearchresults Link to the Analytics portal that returns

the records from the query that created
the alert.
ResultCount #searchresultcount Number of records in the search results.
Search Interval End time #searchintervalendtimeutc End time for the query in UTC, with the
format mm/dd/yyyy HH:mm:ss AM/PM.
Search Interval #searchinterval Time window for the alert rule, with the
format HH:mm:ss.
Search Interval StartTime #searchintervalstarttimeutc Start time for the query in UTC, with
the format mm/dd/yyyy HH:mm:ss
AM/PM.
SearchQuery #searchquery Log search query used by the alert rule.
SearchResults "IncludeSearchResults": true Records returned by the query as a

JSON table, limited to the first 1,000
records, if "IncludeSearchResults": true
is added in a custom JSON webhook
definition as a top-level property.
Alert Type #alerttype The type of log alert rule configured as

Metric measurement or Number of
results.
WorkspaceID #workspaceid ID of your Log Analytics workspace.
Application ID #applicationid ID of your Application Insights app.
Subscription ID #subscriptionid ID of your Azure subscription used.
NOTE
LinkToSearchResults passes parameters like SearchQuery, Search Interval StartTime, and Search Interval End time in the
URL to the Azure portal for viewing in the Analytics section. The Azure portal has a URI size limit of approximately 2,000
characters. The portal will not open links provided in alerts if the parameter values exceed the limit. You can manually input
details to view results in the Analytics portal. Or, you can use the Application Insights Analytics REST API or the Log
Analytics REST API to retrieve results programmatically.
For example, you might specify the following custom payload that includes a single parameter called text. The
service that this webhook calls expects this parameter.
{
"text":"#alertrulename fired with #searchresultcount over threshold of #thresholdvalue."
}
This example payload resolves to something like the following when it's sent to the webhook:
{
"text":"My Alert Rule fired with 18 records over threshold of 10 ."
}
Because all variables in a custom webhook must be specified within a JSON enclosure, like "#searchinterval," the
resultant webhook also has variable data inside enclosures, like "00:05:00."
To include search results in a custom payload, ensure that IncludeSearchResults is set as a top-level property in
the JSON payload.
Sample payloads
This section shows sample payloads for webhooks for log alerts. The sample payloads include examples when the
payload is standard and when it's custom.
Standard webhook for log alerts
Both of these examples have a dummy payload with only two columns and two rows.
Log alert for Log Analytics
The following sample payload is for a standard webhook action without a custom JSON option that's used for
alerts based on Log Analytics:
{
"SubscriptionId":"12345a-1234b-123c-123d-12345678e",
"AlertRuleName":"AcmeRule",
"SearchQuery":"Perf | where ObjectName == \"Processor\" and CounterName == \"% Processor Time\" |
summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer",
"SearchIntervalStartTimeUtc": "2018-03-26T08:10:40Z",
"SearchIntervalEndtimeUtc": "2018-03-26T09:10:40Z",
"AlertThresholdOperator": "Greater Than",
"AlertThresholdValue": 0,
"ResultCount": 2,
"SearchIntervalInSeconds": 3600,
"LinkToSearchResults": "https://portal.azure.com/#Analyticsblade/search/index?
_timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",
"Description": "log alert rule",
"Severity": "Warning",
"SearchResult":
{
"tables":[
{"name":"PrimaryResult","columns":
[
{"name":"$table","type":"string"},
{"name":"Id","type":"string"},
{"name":"TimeGenerated","type":"datetime"}
],
"rows":
[
["Fabrikam","33446677a","2018-02-02T15:03:12.18Z"],
["Contoso","33445566b","2018-02-02T15:16:53.932Z"]
]
}
]
},
"WorkspaceId":"12345a-1234b-123c-123d-12345678e",
"AlertType": "Metric measurement"
}
NOTE
The "Severity" field value might change if you've switched your API preference for log alerts on Log Analytics.
Log alert for Application Insights

The following sample payload is for a standard webhook without a custom JSON option when it's used for log
alerts based on Application Insights:
{
"schemaId":"Microsoft.Insights/LogAlert","data":
{
"SubscriptionId":"12345a-1234b-123c-123d-12345678e",
"AlertRuleName":"AcmeRule",
"SearchQuery":"requests | where resultCode == \"500\"",
"SearchIntervalStartTimeUtc": "2018-03-26T08:10:40Z",
"SearchIntervalEndtimeUtc": "2018-03-26T09:10:40Z",
"AlertThresholdOperator": "Greater Than",
"AlertThresholdValue": 0,
"ResultCount": 2,
"SearchIntervalInSeconds": 3600,
"LinkToSearchResults": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-123c-123d-
12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-
26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",
"Description": null,
"Severity": "3",
"SearchResult":
{
"tables":[
[
],
"rows":
[
["Fabrikam","33446677a","2018-02-02T15:03:12.18Z"],
["Contoso","33445566b","2018-02-02T15:16:53.932Z"]
]
}
]
},
"ApplicationId": "123123f0-01d3-12ab-123f-abc1ab01c0a1",
"AlertType": "Number of results"
}
}
Log alert with custom JSON payload

For example, to create a custom payload that includes just the alert name and the search results, you can use the
following:
{
"alertname":"#alertrulename",
"IncludeSearchResults":true
}
The following sample payload is for a custom webhook action for any log alert:
{
"alertname":"AcmeRule","IncludeSearchResults":true,
"SearchResults":
{
"tables":[
[
],
"rows":
[
["Fabrikam","33446677a","2018-02-02T15:03:12.18Z"],
["Contoso","33445566b","2018-02-02T15:16:53.932Z"]
]
}
]
}
}
Next steps
Learn about log alerts in Azure alerts .
Understand how to manage log alerts in Azure.
Create and manage action groups in Azure.
Troubleshoot log alerts in Azure Monitor
This article shows you how to resolve common issues that might happen when you're setting up log alerts in Azure
Monitor. It also provides solutions to common problems with functionality or configuration of log alerts.
The term log alerts describe rules that fire based on a log query in an Azure Log Analytics workspace or in Azure
Application Insights. Learn more about functionality, terminology, and types in Log alerts in Azure Monitor.
NOTE
This article doesn't consider cases where the Azure portal shows an alert rule triggered and a notification is not performed by
an associated action group. For such cases, see the details in Create and manage action groups in the Azure portal.
Log alert didn't fire

Here are some common reasons why the state for a configured log alert rule in Azure Monitor doesn't show as
fired when expected.
Data ingestion time for logs
A log alert periodically runs your query based on Log Analytics or Application Insights. Because Azure Monitor
processes many terabytes of data from thousands of customers from varied sources across the world, the service is
susceptible to varying time delays. For more information, see Data ingestion time in Azure Monitor logs.
To mitigate delays, the system waits and retries the alert query multiple times if it finds the needed data is not yet
ingested. The system has an exponentially increasing wait time set. The log alert is triggered only after the data is
available, so the delay might be due to slow ingestion of log data.
Incorrect time period configured
As described in the article on terminology for log alerts, the time period stated in the configuration specifies the
time range for the query. The query returns only records that were created within this range.
The time period restricts the data fetched for a log query to prevent abuse, and it circumvents any time command
(like ago) used in a log query. For example, If the time period is set to 60 minutes, and the query is run at 1:15 PM,
only records created between 12:15 PM and 1:15 PM are used for the log query. If the log query uses a time
command like ago (1d), the query still only uses data between 12:15 PM and 1:15 PM because the time period is
set to that interval.
Check that the time period in the configuration matches your query. For the example shown earlier, if the log query
uses ago (1d) with the green marker, the time period should be set to 24 hours or 1,440 minutes (indicated in red).
This setting ensures that the query runs as intended.
Suppress Alerts option is set
As described in step 8 of the article on creating a log alert rule in the Azure portal , log alerts provide a Suppress
Alerts option to suppress triggering and notification actions for a configured amount of time. As a result, you
might think that an alert didn't fire. In fact, it did fire but was suppressed.
Metric measurement alert rule is incorrect
Metric measurement log alerts are a subtype of log alerts that have special capabilities and a restricted alert query
syntax. A rule for a metric measurement log alert requires the query output to be a metric time series. That is, the
output is a table with distinct, equally sized time periods along with corresponding aggregated values.
You can choose to have additional variables in the table alongside AggregatedValue. These variables can be used
to sort the table.
For example, suppose a rule for a metric measurement log alert was configured as:
Query of search *| summarize AggregatedValue = count() by $table, bin(timestamp, 1h)
Time period of 6 hours
Threshold of 50
Alert logic of three consecutive breaches
Aggregate Upon chosen as $table
Because the command includes summarize ... by and provides two variables (timestamp and $table), the system
chooses $table for Aggregate Upon. The system sorts the result table by the $table field, as shown in the
following screenshot. Then it looks at the multiple AggregatedValue instances for each table type (like
availabilityResults) to see if there were three or more consecutive breaches.
Because Aggregate Upon is defined on $table, the data is sorted on a $table column (indicated in red). Then we
group and look for types of the Aggregate Upon field.
For example, for $table, values for availabilityResults will be considered as one plot/entity (indicated in orange).
In this value plot/entity, the alert service checks for three consecutive breaches (indicated in green). The breaches
trigger an alert for the table value availabilityResults.
Similarly, if three consecutive breaches happen for any other value of $table, another alert notification is triggered
for the same thing. The alert service automatically sorts the values in one plot/entity (indicated in orange) by time.
Now suppose that the rule for the metric measurement log alert was modified and the query was
search *| summarize AggregatedValue = count() by bin(timestamp, 1h) . The rest of the configuration remained the
same as before, including the alert logic for three consecutive breaches. The Aggregate Upon option in this case
is timestamp by default. Only one value is provided in the query for summarize ... by (that is, timestamp). Like
the earlier example, the output at end of execution would be as illustrated as follows.
Because Aggregate Upon is defined on timestamp, the data is sorted on the timestamp column (indicated in
red). Then we group by timestamp. For example, values for 2018-10-17T06:00:00Z will be considered as one
plot/entity (indicated in orange). In this value plot/entity, the alert service will find no consecutive breaches
(because each timestamp value has only one entry). So the alert is never triggered. In such a case, the user must
either:
Add a dummy variable or an existing variable (like $table) to correctly sort by using the Aggregate Upon
field.
Reconfigure the alert rule to use alert logic based on total breach instead.
Log alert fired unnecessarily

A configured log alert rule in Azure Monitor might be triggered unexpectedly when you view it in Azure Alerts. The
following sections describe some common reasons.
Alert triggered by partial data
Log Analytics and Application Insights are subject to ingestion delays and processing. When you run a log alert
query, you might find that no data is available or only some data is available. For more information, see Log data
ingestion time in Azure Monitor.
Depending on how you configured the alert rule, misfiring might happen if there's no data or partial data in logs at
the time of alert execution. In such cases, we advise you to change the alert query or configuration.
For example, if you configure the log alert rule to be triggered when the number of results from an analytics query
is less than 5, the alert is triggered when there's no data (zero record) or partial results (one record). But after the
data ingestion delay, the same query with full data might provide a result of 10 records.
Alert query output is misunderstood
You provide the logic for log alerts in an analytics query. The analytics query can use various big data and
mathematical functions. The alert service runs your query at intervals specified with data for a specified time
period. The alert service makes subtle changes to the query based on the alert type. You can view this change in
the Query to be executed section on the Configure signal logic screen:
The Query to be executed box is what the log alert service runs. If you want to understand what the alert query
output might be before you create the alert, you can run the stated query and the timespan via the Analytics portal
or the Analytics API.
Log alert was disabled

The following sections list some reasons why Azure Monitor might disable the log alert rule.
Resource where the alert was created no longer exists
Log alert rules created in Azure Monitor target a specific resource like an Azure Log Analytics workspace, an Azure
Application Insights app, and an Azure resource. The log alert service will then run an analytics query provided in
the rule for the specified target. But after rule creation, users often go on to delete from Azure--or move inside
Azure--the target of the log alert rule. Because the target of the alert rule is no longer valid, execution of the rule
fails.
In such cases, Azure Monitor disables the log alert and ensures that you're not billed unnecessarily when the rule
can't run continually for sizable period (like a week). You can find out the exact time when Azure Monitor disabled
the log alert via Azure Activity Log. In Azure Activity Log, an event is added when Azure Monitor disables the log
alert rule.
The following sample event in Azure Activity Log is for an alert rule that has been disabled because of a continual
failure.
{
"caller": "Microsoft.Insights/ScheduledQueryRules",
"claims": {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
},
"correlationId": "abcdefg-4d12-1234-4256-21233554aff",
"description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing
consistently with the same exception for the past week",
"eventDataId": "f123e07-bf45-1234-4565-123a123455b",
"eventName": {
"value": "",
},
"category": {
"value": "Administrative",
"localizedValue": "Administrative"
},
"id":
"/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULE
S/TEST-BAD-ALERTS",
"operationId": "",
"operationName": {
"value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
},
"resourceGroupName": "<Resource Group>",
"value": "MICROSOFT.INSIGHTS",
"localizedValue": "Microsoft Insights"
},
"resourceType": {
"value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
"localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
},
"resourceId":
S/TEST-BAD-ALERTS",
"status": {
},
"subStatus": {
"value": "",
},
"subscriptionId": "<SubscriptionId>",
"properties": {
"resourceId":
S/TEST-BAD-ALERTS",
"subscriptionId": "<SubscriptionId>",
"resourceGroup": "<ResourceGroup>",
"eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
"eventTimeStamp": "03/22/2019 04:18:22",
"issueStartTime": "03/22/2019 04:18:22",
"operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"status": "Succeeded",
"reason": "Alert has been failing consistently with the same exception for the past week"
},
"relatedEvents": []
}
Query used in a log alert is not valid
Each log alert rule created in Azure Monitor as part of its configuration must specify an analytics query that the
alert service will run periodically. The analytics query might have correct syntax at the time of rule creation or
update. But sometimes, over a period of time, the query provided in the log alert rule can develop syntax issues
and cause the rule execution to fail. Some common reasons why an analytics query provided in a log alert rule can
develop errors are:
The query is written to run across multiple resources. And one or more of the specified resources no longer
exist.
Metric measurement type log alert configured has an alert query doesn't comply with the syntax norms
There has been no data flow to the analytics platform. The query execution gives an error because there's no
data for the provided query.
Changes in query language include a revised format for commands and functions. So the query provided
earlier in an alert rule is no longer valid.
Azure Advisor warns you about this behavior. A recommendation is added for the specific log alert rule on Azure
Advisor, under the category of High Availability with medium impact and a description of "Repair your log alert
rule to ensure monitoring." If an alert query in the log alert rule isn't rectified after Azure Advisor has provided a
recommendation for seven days, Azure Monitor will disable the log alert and ensure that you're not billed
unnecessarily when the rule can't run continually for a sizable period (like a week).
You can find the exact time when Azure Monitor disabled the log alert rule by looking for an event in Azure Activity
Log.
Next steps
Create, view, and manage activity log alerts by using
Azure Monitor
Overview
Activity log alerts are the alerts that get activated when a new activity log event occurs that matches the conditions
specified in the alert.
These alerts are for Azure resources and can be created by using an Azure Resource Manager template. They also
can be created, updated, or deleted in the Azure portal. Typically, you create activity log alerts to receive
notifications when specific changes occur to resources in your Azure subscription. Alerts are often scoped to
particular resource groups or resources. For example, you might want to be notified when any virtual machine in
the sample resource group myProductionResourceGroup is deleted. Or, you might want to get notified if any
new roles are assigned to a user in your subscription.
IMPORTANT
Alerts on service health notification can't be created via the interface for activity log alert creation. To learn more about how
to create and use service health notifications, see Receive activity log alerts on service health notifications .
When you create alert rules, ensure the following:

The subscription in the scope isn't different from the subscription where the alert is created.
The criteria must be the level, status, caller, resource group, resource ID, or resource type event category on
which the alert is configured.
There's no "anyOf" condition or nested conditions in the alert configuration JSON. Basically, only one "allOf"
condition is allowed with no further "allOf" or "anyOf" conditions.
When the category is "administrative," you must specify at least one of the preceding criteria in your alert. You
may not create an alert that activates every time an event is created in the activity logs.
Azure portal
You can use the Azure portal to create and modify activity log alert rules. The experience is integrated with an
Azure activity log to ensure seamless alert creation for specific events of interest.
Create with the Azure portal
Use the following procedure.
1. In the Azure portal, select Monitor > Alerts.
2. Select New alert rule in the upper-left corner of the Alerts window.
The Create rule window appears.

3. Under Define alert condition, provide the following information, and select Done:
Alert target: To view and select the target for the new alert, use Filter by subscription / Filter by
resource type. Select the resource or resource group from the list displayed.
NOTE
You can select only Azure Resource Manager tracked resource, resource group, or an entire subscription for
an activity log signal.
Alert target sample view

Under Target criteria, select Add criteria. All available signals for the target are displayed, which
includes those from various categories of Activity Log. The category name is appended to the
Monitor Service name.
Select the signal from the list displayed of various operations possible for the type Activity Log.
You can select the log history timeline and the corresponding alert logic for this target signal:
Add criteria screen
History time: Events available for the selected operation can be plotted over the last 6, 12, or
24 hours or over the last week.
Alert logic:
Event level: The severity level of the event: Verbose, Informational, Warning, Error, or
Critical.
Status: The status of the event: Started, Failed, or Succeeded.
Event initiated by: Also known as the caller. The email address or Azure Active Directory
identifier of the user who performed the operation.
This sample signal graph has the alert logic applied:
4. Under Define alert details, provide the following details:

Alert rule name: The name for the new alert rule.
Description: The description for the new alert rule.
Save alert to resource group: Select the resource group where you want to save this new rule.
5. Under Action group, from the drop-down menu, specify the action group that you want to assign to this
new alert rule. Or, create a new action group and assign it to the new rule. To create a new group, select +
New group.
6. To enable the rules after you create them, select Yes for the Enable rule upon creation option.
7. Select Create alert rule.
The new alert rule for the activity log is created, and a confirmation message appears in the upper-right
corner of the window.
You can enable, disable, edit, or delete a rule. Learn more about how to manage activity log rules.
A simple analogy for understanding conditions on which alert rules can be created in an activity log is to explore
or filter events via the activity log in the Azure portal. In the Azure Monitor - Activity log screen, you can filter
or find the necessary event and then create an alert by using the Add activity log alert button. Then follow steps
4 through 7 as previously shown.
View and manage in the Azure portal

1. In the Azure portal, select Monitor > Alerts. Select Manage alert rules in the upper-left corner of the
window.
The list of available rules appears.

2. Search for the activity log rule to modify.
You can use the available filters, Subscription, Resource group, Resource, Signal type, or Status, to find the
activity rule that you want to edit.
NOTE
You can edit only Description, Target criteria, and Action groups.
3. Select the rule, and double-click to edit the rule options. Make the required changes, and then select Save.
4. You can enable, disable, or delete a rule. Select the appropriate option at the top of the window after you
select the rule as described in step 2.

To create an activity log alert by using an Azure Resource Manager template, you create a resource of the type
microsoft.insights/activityLogAlerts . Then you fill in all related properties. Here's a template that creates an
activity log alert:
{
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Activity log alert."
}
},
"activityLogAlertEnabled": {
"type": "bool",
"metadata": {
"description": "Indicates whether or not the alert is enabled."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"location": "Global",
"properties": {
"enabled": "[parameters('activityLogAlertEnabled')]",
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "Administrative"
},
{
"field": "operationName",
"equals": "Microsoft.Resources/deployments/write"
},
{
"field": "resourceType",
"equals": "Microsoft.Resources/deployments"
}
]
},
"actions": {
"actionGroups":
[
{
"actionGroupId": "[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}
The previous sample JSON can be saved as, for example, sampleActivityLogAlert.json for the purpose of this
walk-through and can be deployed by using Azure Resource Manager in the Azure portal.
NOTE
It might take up to 5 minutes for the new activity log alert rule to become active.
REST API
The Azure Monitor Activity Log Alerts API is a REST API. It's fully compatible with the Azure Resource Manager
REST API. It can be used via PowerShell by using the Resource Manager cmdlet or the Azure CLI.
PowerShell
NOTE
PowerShell.
Deploy the Resource Manager template with PowerShell

To use PowerShell to deploy the sample Resource Manager template shown in the previous Azure Resource
Manager template section, use the following command:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile sampleActivityLogAlert.json -

TemplateParameterFile sampleActivityLogAlert.parameters.json
where the sampleActivityLogAlert.parameters.json contains the values provided for the parameters needed for
alert rule creation.
Use activity log PowerShell cmdlets
Activity log alerts have dedicated PowerShell cmdlets available:
Set-AzActivityLogAlert: Creates a new activity log alert or updates an existing activity log alert.
Get-AzActivityLogAlert: Gets one or more activity log alert resources.
Enable-AzActivityLogAlert: Enables an existing activity log alert and sets its tags.
Disable-AzActivityLogAlert: Disables an existing activity log alert and sets its tags.
Remove-AzActivityLogAlert: Removes an activity log alert.
Azure CLI
Dedicated Azure CLI commands under the set az monitor activity-log alert are available for managing activity log
alert rules.
To create a new activity log alert rule, use the following commands in this order:
1. az monitor activity-log alert create: Create a new activity log alert rule resource.
2. az monitor activity-log alert scope: Add scope for the created activity log alert rule.
3. az monitor activity-log alert action-group: Add an action group to the activity log alert rule.
To retrieve one activity log alert rule resource, use the Azure CLI command az monitor activity-log alert show. To
view all activity log alert rule resources in a resource group, use az monitor activity-log alert list. Activity log alert
rule resources can be removed by using the Azure CLI command az monitor activity-log alert delete.
Next steps
Learn about webhook schema for activity logs.
Read an overview of activity logs.
Learn more about action groups.
Learn about service health notifications.
2 minutes to read
2 minutes to read
2 minutes to read
Action rules (preview)
Action rules help you define or suppress actions at any Azure Resource Manager scope (Azure subscription,
resource group, or target resource). They have various filters that help you narrow down the specific subset of alert
instances that you want to act on.
Why and when should you use action rules?

Suppression of alerts
There are many scenarios where it's useful to suppress the notifications that alerts generate. These scenarios range
from suppression during a planned maintenance window to suppression during nonbusiness hours. For example,
the team responsible for ContosoVM wants to suppress alert notifications for the upcoming weekend, because
ContosoVM is undergoing planned maintenance.
Although the team can disable each alert rule that's configured on ContosoVM manually (and enable it again
after maintenance), it's not a simple process. Action rules help you define alert suppression at scale with the ability
to flexibly configure the period of suppression. In the previous example, the team can define one action rule on
ContosoVM that suppresses all alert notifications for the weekend.
Actions at scale
Although alert rules help you define the action group that triggers when the alert is generated, customers often
have a common action group across their scope of operations. For example, a team responsible for the resource
group ContosoRG will probably define the same action group for all alert rules defined within ContosoRG.
Action rules help you simplify this process. By defining actions at scale, an action group can be triggered for any
alert that's generated on the configured scope. In the previous example, the team can define one action rule on
ContosoRG that will trigger the same action group for all alerts generated within it.
NOTE
Action rules currently don't apply to Azure Service Health alerts.
Configuring an action rule

You can access the feature by selecting Manage actions from the Alerts landing page in Azure Monitor. Then,
select Action rules (preview). You can access the rules by selecting Action rules (preview) from the dashboard
of the landing page for alerts.
Select + New Action Rule.
Alternatively, you can create an action rule while you're configuring an alert rule.
You should now see the flow page for creating action rules. Configure the following elements:
Scope
First choose the scope (Azure subscription, resource group, or target resource). You can also multiple-select a
combination of scopes within a single subscription.
Filter criteria
You can additionally define filters to narrow them down to a specific subset of the alerts.
The available filters are:
Severity: The option to select one or more alert severities. Severity = Sev1 means that the action rule is
applicable for all alerts set to Sev1.
Monitor Service: A filter based on the originating monitoring service. This filter is also multiple-select. For
example, Monitor Service = “Application Insights” means that the action rule is applicable for all
Application Insights-based alerts.
Resource Type: A filter based on a specific resource type. This filter is also multiple-select. For example,
Resource Type = “Virtual Machines” means that the action rule is applicable for all virtual machines.
Alert Rule ID: An option to filter for specific alert rules by using the Resource Manager ID of the alert rule.
Monitor Condition: A filter for alert instances with either Fired or Resolved as the monitor condition.
Description: A regex (regular expression) match that defines a string match against the description, defined as
part of the alert rule. For example, Description contains 'prod' will match all alerts that contain the string
"prod" in their descriptions.
Alert Context (payload): A regex match that defines a string match against the alert context fields of an alert's
payload. For example, Alert context (payload) contains 'Computer-01' will match all alerts whose payloads
contain the string "Computer-01."
These filters are applied in conjunction with one another. For example, if you set Resource type' = Virtual
Machines and Severity' = Sev0, then you've filtered for all Sev0 alerts on only your VMs.
Suppression or action group configuration
Next, configure the action rule for either alert suppression or action group support. You can't choose both. The
configuration acts on all alert instances that match the previously defined scope and filters.
Suppression
If you select suppression, configure the duration for the suppression of actions and notifications. Choose one of
the following options:
From now (Always): Suppresses all notifications indefinitely.
At a scheduled time: Suppresses notifications within a bounded duration.
With a recurrence: Suppresses notifications on a recurring daily, weekly, or monthly schedule.
Action group
If you select Action group in the toggle, either add an existing action group or create a new one.
NOTE
You can associate only one action group with an action rule.
Action rule details

Last, configure the following details for the action rule:
Name
Resource group in which it's saved
Description
Example scenarios
Scenario 1: Suppression of alerts based on severity
Contoso wants to suppress notifications for all Sev4 alerts on all VMs within the subscription ContosoSub every
weekend.
Solution: Create an action rule with:
Scope = ContosoSub
Filters
Severity = Sev4
Resource Type = Virtual Machines
Suppression with recurrence set to weekly, and Saturday and Sunday checked
Scenario 2: Suppression of alerts based on alert context (payload)
Contoso wants to suppress notifications for all log alerts generated for Computer-01 in ContosoSub indefinitely
as it's going through maintenance.
Scope = ContosoSub
Filters
Monitor Service = Log Analytics
Alert Context (payload) contains Computer-01
Suppression set to From now (Always)
Scenario 3: Action group defined at a resource group
Contoso has defined a metric alert at a subscription level. But it wants to define the actions that trigger specifically
for alerts generated from the resource group ContosoRG.
Scope = ContosoRG
No filters
Action group set to ContosoActionGroup
NOTE
Action groups defined within action rules and alert rules operate independently, with no deduplication. In the scenario
described earlier, if an action group is defined for the alert rule, it triggers in conjunction with the action group defined in the
action rule.
Managing your action rules

You can view and manage your action rules from the list view:
From here, you can enable, disable, or delete action rules at scale by selecting the check box next to them. When
you select an action rule, its configuration page opens. The page helps you update the action rule's definition and
enable or disable it.
Best practices
Log alerts that you create with the number of results option generate a single alert instance by using the whole
search result (which might span across multiple computers). In this scenario, if an action rule uses the Alert
Context (payload) filter, it acts on the alert instance as long as there's a match. In Scenario 2, described
previously, if the search results for the generated log alert contain both Computer-01 and Computer-02, the
entire notification is suppressed. There's no notification generated for Computer-02 at all.
To best use log alerts with action rules, create log alerts with the metric measurement option. Separate alert
instances are generated by this option, based on its defined group field. Then, in Scenario 2, separate alert
instances are generated for Computer-01 and Computer-02. Due to the action rule described in the scenario,
only the notification for Computer-01 is suppressed. The notification for Computer-02 continues to fire as
normal.
FAQ
While I'm configuring an action rule, I'd like to see all the possible overlapping action rules, so that I avoid
duplicate notifications. Is it possible to do that?
After you define a scope as you configure an action rule, you can see a list of action rules that overlap on the same
scope (if any). This overlap can be one of the following options:
An exact match: For example, the action rule you're defining and the overlapping action rule are on the same
subscription.
A subset: For example, the action rule you're defining is on a subscription, and the overlapping action rule is on
a resource group within the subscription.
A superset: For example, the action rule you're defining is on a resource group, and the overlapping action rule
is on the subscription that contains the resource group.
An intersection: For example, the action rule you're defining is on VM1 and VM2, and the overlapping action
rule is on VM2 and VM3.
While I'm configuring an alert rule, is it possible to know if there are already action rules defined that might act
on the alert rule I'm defining?
After you define the target resource for your alert rule, you can see the list of action rules that act on the same
scope (if any) by selecting View configured actions under the Actions section. This list is populated based on
the following scenarios for the scope:
An exact match: For example, the alert rule you're defining and the action rule are on the same subscription.
A subset: For example, the alert rule you're defining is on a subscription, and the action rule is on a resource
group within the subscription.
A superset: For example, the alert rule you're defining is on a resource group, and the action rule is on the
subscription that contains the resource group.
An intersection: For example, the alert rule you're defining is on VM1 and VM2, and the action rule is on VM2
and VM3.
Can I see the alerts that have been suppressed by an action rule?
In the alerts list page, you can choose an additional column called Suppression Status. If the notification for an
alert instance was suppressed, it would show that status in the list.
If there's an action rule with an action group and another with suppression active on the same scope, what
happens?
Suppression always takes precedence on the same scope.
What happens if I have a resource that's monitored in two separate action rules? Do I get one or two
notifications? For example, VM2 in the following scenario:
"action rule AR1 defined for VM1 and VM2 with action group AG1
action rule AR2 defined for VM2 and VM3 with action group AG1"
For every alert on VM1 and VM3, action group AG1 would be triggered once. For every alert on VM2, action
group AG1 would be triggered twice, because action rules don't deduplicate actions.
What happens if I have a resource monitored in two separate action rules and one calls for action while another
for suppression? For example, VM2 in the following scenario:
"action rule AR1 defined for VM1 and VM2 with action group AG1
action rule AR2 defined for VM2 and VM3 with suppression"
For every alert on VM1, action group AG1 would be triggered once. Actions and notifications for every alert on
VM2 and VM3 will be suppressed.
What happens if I have an alert rule and an action rule defined for the same resource calling different action
groups? For example, VM1 in the following scenario:
"alert rule rule1 on VM1 with action group AG2
action rule AR1 defined for VM1 with action group AG1"
For every alert on VM1, action group AG1 would be triggered once. Whenever alert rule "rule1" is triggered, it will
also trigger AG2 additionally. Action groups defined within action rules and alert rules operate independently, with
no deduplication.
Next steps
Learn more about alerts in Azure
Create and manage action groups in the Azure
portal
An action group is a collection of notification preferences defined by the owner of an Azure subscription.
Azure Monitor and Service Health alerts use action groups to notify users that an alert has been triggered.
Various alerts may use the same action group or different action groups depending on the user's
requirements. You may configure up to 2,000 action groups in a subscription.
You configure an action to notify a person by email or SMS, they receive a confirmation indicating they
have been added to the action group.
This article shows you how to create and manage action groups in the Azure portal.
Each action is made up of the following properties:
Name: A unique identifier within the action group.
Action type: The action performed. Examples include sending a voice call, SMS, email; or triggering
various types of automated actions. See types later in this article.
Details: The corresponding details that vary by action type.
For information on how to use Azure Resource Manager templates to configure action groups, see Action
group Resource Manager templates.
Create an action group by using the Azure portal

1. In the Azure portal, select Monitor. The Monitor pane consolidates all your monitoring settings
and data in one view.
2. Select Alerts then select Manage actions.
3. Select Add action group, and fill in the fields.
4. Enter a name in the Action group name box, and enter a name in the Short name box. The short
name is used in place of a full action group name when notifications are sent using this group.
5. The Subscription box autofills with your current subscription. This subscription is the one in which
the action group is saved.
6. Select the Resource group in which the action group is saved.
7. Define a list of actions. Provide the following for each action:
a. Name: Enter a unique identifier for this action.
b. Action Type: Select Email/SMS/Push/Voice, Logic App, Webhook, ITSM, or Automation
Runbook.
c. Details: Based on the action type, enter a phone number, email address, webhook URI, Azure
app, ITSM connection, or Automation runbook. For ITSM Action, additionally specify Work
Item and other fields your ITSM tool requires.
d. Common alert schema: You can choose to enable the common alert schema, which
provides the advantage of having a single extensible and unified alert payload across all the
alert services in Azure Monitor.
8. Select OK to create the action group.
Manage your action groups

After you create an action group, it's visible in the Action groups section of the Monitor pane. Select the
action group you want to manage to:
Add, edit, or remove actions.
Delete the action group.
Action specific information

NOTE
See Subscription Service Limits for Monitoring for numeric limits on each of the items below.
Automation Runbook
Refer to the Azure subscription service limits for limits on Runbook payloads.
You may have a limited number of Runbook actions in an Action Group.
Azure app Push Notifications
You may have a limited number of Azure app actions in an Action Group.
Email
Emails will be sent from the following email addresses. Ensure that your email filtering is configured
appropriately
azure-noreply@microsoft.com
azureemail-noreply@microsoft.com
alerts-noreply@mail.windowsazure.com
You may have a limited number of email actions in an Action Group. See the rate limiting information
article.
Email Azure Resource Manager Role
Send email to the members of the subscription's role.
You may have a limited number of email actions in an Action Group. See the rate limiting information
article.
Function
The function keys for Function Apps configured as actions are read through the Functions API, which
currently requires v2 function apps to configure the app setting “AzureWebJobsSecretStorageType” to
“files”. For more information, see Changes to Key Management in Functions V2.
You may have a limited number of Function actions in an Action Group.
ITSM
ITSM Action requires an ITSM Connection. Learn how to create an ITSM Connection.
You may have a limited number of ITSM actions in an Action Group.
Logic App
You may have a limited number of Logic App actions in an Action Group.
Secure Webhook
The Secure Webhook functionality is currently in Preview.
The Action Groups Webhook action enables you to take advantage of Azure Active Directory to secure the
connection between your action group and your protected web API (webhook endpoint). The overall
workflow for taking advantage of this functionality is described below. For an overview of Azure AD
Applications and service principals, see Microsoft identity platform (v2.0) overview.
1. Create an Azure AD Application for your protected web API. See
https://docs.microsoft.com/azure/active-directory/develop/scenario-protected-web-api-overview.
Configure your protected API to be called by a daemon app.
2. Enable Action Groups to use your Azure AD Application.
NOTE
You must be a member of the Azure AD Application Administrator role to execute this script.
Modify the PowerShell script's Connect-AzureAD call to use your Azure AD Tenant ID.
Modify the PowerShell script's variable $myAzureADApplicationObjectId to use the Object ID of
your Azure AD Application
Run the modified script.
3. Configure the Action Group Secure Webhook action.
Copy the value $myApp.ObjectId from the script and enter it in the Application Object ID field in
the Webhook action definition.
Secure Webhook PowerShell Script

Connect-AzureAD -TenantId "<provide your Azure AD tenant ID here>"
# This is your Azure AD Application's ObjectId.

$myAzureADApplicationObjectId = "<the Object Id of your Azure AD Application>"
# This is the Action Groups Azure AD AppId

$actionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a"
# This is the name of the new role we will add to your Azure AD Application
$actionGroupRoleName = "ActionGroupsSecureWebhook"
# Create an application role of given name and description

Function CreateAppRole([string] $Name, [string] $Description)
{
$appRole = New-Object Microsoft.Open.AzureAD.Model.AppRole
$appRole.AllowedMemberTypes = New-Object System.Collections.Generic.List[string]
$appRole.AllowedMemberTypes.Add("Application");
$appRole.DisplayName = $Name
$appRole.Id = New-Guid
$appRole.IsEnabled = $true
$appRole.Description = $Description
$appRole.Value = $Name;
return $appRole
}
# Get my Azure AD Application, it's roles and service principal

$myApp = Get-AzureADApplication -ObjectId $myAzureADApplicationObjectId
$myAppRoles = $myApp.AppRoles
$actionGroupsSP = Get-AzureADServicePrincipal -Filter ("appId eq '" + $actionGroupsAppId + "'")
Write-Host "App Roles before addition of new role.."

Write-Host $myAppRoles
# Create the role if it doesn't exist

if ($myAppRoles -match "ActionGroupsSecureWebhook")
{
Write-Host "The Action Groups role is already defined.`n"
}
else
{
$myServicePrincipal = Get-AzureADServicePrincipal -Filter ("appId eq '" + $myApp.AppId + "'")
# Add our new role to the Azure AD Application

$newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Groups
to join"
$myAppRoles.Add($newRole)
Set-AzureADApplication -ObjectId $myApp.ObjectId -AppRoles $myAppRoles
}
# Create the service principal if it doesn't exist

if ($actionGroupsSP -match "AzNS AAD Webhook")
{
Write-Host "The Service principal is already defined.`n"
}
else
{
# Create a service principal for the Action Groups Azure AD Application and add it to the role
$actionGroupsSP = New-AzureADServicePrincipal -AppId $actionGroupsAppId
}
New-AzureADServiceAppRoleAssignment -Id $myApp.AppRoles[0].Id -ResourceId $myServicePrincipal.ObjectId

-ObjectId $actionGroupsSP.ObjectId -PrincipalId $actionGroupsSP.ObjectId
Write-Host "My Azure AD Application ($myApp.ObjectId): " + $myApp.ObjectId

Write-Host "My Azure AD Application's Roles"
Write-Host $myApp.AppRoles
SMS
See the rate limiting information and SMS alert behavior for additional important information.
You may have a limited number of SMS actions in an Action Group.
Voice
See the rate limiting information article.
You may have a limited number of Voice actions in an Action Group.
Webhook
Webhooks are retried using the following rules. The webhook call is retried a maximum of 2 times when
the following HTTP status codes are returned: 408, 429, 503, 504 or the HTTP endpoint does not respond.
The first retry happens after 10 seconds. The second retry happens after 100 seconds. After two failures, no
action group will call the endpoint for 30 minutes.
Source IP address ranges
13.72.19.232
13.106.57.181
13.106.54.3
13.106.54.19
13.106.38.142
13.106.38.148
13.106.57.196
13.106.57.197
52.244.68.117
52.244.65.137
52.183.31.0
52.184.145.166
51.4.138.199
51.5.148.86
51.5.149.19
To receive updates about changes to these IP addresses, we recommend you configure a Service Health
alert, which monitors for Informational notifications about the Action Groups service.
You may have a limited number of Webhook actions in an Action Group.
Next steps
Learn more about SMS alert behavior.
Gain an understanding of the activity log alert webhook schema.
Learn more about ITSM Connector
Learn more about rate limiting on alerts.
Get an overview of activity log alerts, and learn how to receive alerts.
Learn how to configure alerts whenever a service health notification is posted.
Common alert schema
This article describes what the common alert schema is, the benefits of using it and how to enable it.
What is the common alert schema?

The common alert schema standardizes the consumption experience for alert notifications in Azure today.
Historically, the three alert types in Azure today (metric, log, and activity log) have had their own email templates,
webhook schemas, etc. With the common alert schema, you can now receive alert notifications with a consistent
schema.
Any alert instance describes the resource that was affected and the cause of the alert, and these instances are
described in the common schema in the following sections:
Essentials: A set of standardized fields, common across all alert types, which describe what resource the
alert is on along with additional common alert metadata (for example, severity or description).
Alert Context: A set of fields which describe the cause of the alert, with fields that vary based on the alert
type. For example, a metric alert would have fields like the metric name and metric value in the alert context,
whereas an activity log alert would have information about the event that generated the alert.
The typical integration scenarios we hear from customers involve the routing of the alert instance to the concerned
team based on some pivot (for example, resource group), after which the responsible team starts working on it.
With the common alert schema, you can have standardized routing logic across alert types by leveraging the
essential fields, leaving the context fields as is for the concerned teams to investigate further.
This means that you can potentially have fewer integrations, making the process of managing and maintaining
them a much simpler task. Additionally, future alert payload enrichments (for example, customization, diagnostic
enrichment, etc.) will only surface up in the common schema.
What enhancements does the common alert schema bring?

The common alert schema will primarily manifest itself in your alert notifications. The enhancements that you will
see are listed below:
ACTION ENHANCEMENTS
SMS A consistent SMS template for all alert types.
Email A consistent and detailed email template, allowing you to

easily diagnose issues at a glance. Embedded deep-links to the
alert instance on the portal and the affected resource ensure
that you can quickly jump into the remediation process.
Webhook/Logic App/Azure Function/Automation Runbook A consistent JSON structure for all alert types, which allows
you to easily build integrations across the different alert types.
The new schema will also enable a richer alert consumption experience across both the Azure portal and the Azure
mobile app in the immediate future.
Learn more about the schema definitions for Webhooks/Logic Apps/Azure Functions/Automation Runbooks.
NOTE
The following actions do not support the common alert schema: ITSM Connector.
How do I enable the common alert schema?

You can opt in or opt out to the common alert schema through Action Groups, on both the portal and through the
REST API. The toggle to switch to the new schema exists at an action level. For example, you have to separately opt
in for an email action and a webhook action.
NOTE
1. The following alert types support the common schema by default (no opt in required):
Smart detection alerts
2. The following alert types currently do not support the common schema:
Alerts generated by Azure Monitor for VMs
Alerts generated by Azure Cost Management
Through the Azure portal
1. Open any existing or a new action in an action group.

2. Select ‘Yes’ for the toggle to enable the common alert schema as shown.
Through the Action Groups REST API
You can also use the Action Groups API to opt in to the common alert schema. While making the create or update
REST API call, you can set the flag "useCommonAlertSchema" to 'true' (to opt in) or 'false' (to opt out) for any of
the following actions - email/webhook/logic app/Azure Function/automation runbook.
For example, the following request body made to the create or update REST API will do the following:
Enable the common alert schema for the email action "John Doe's email"
Disable the common alert schema for the email action "Jane Smith's email"
Enable the common alert schema for the webhook action "Sample webhook"
{
"properties": {
"groupShortName": "sample",
"enabled": true,
"emailReceivers": [
{
"name": "John Doe's email",
"emailAddress": "johndoe@email.com",
"useCommonAlertSchema": true
},
{
"name": "Jane Smith's email",
"emailAddress": "janesmith@email.com",
"useCommonAlertSchema": false
}
],
"smsReceivers": [
{
"name": "John Doe's mobile",
"countryCode": "1",
"phoneNumber": "1234567890"
},
{
"name": "Jane Smith's mobile",
"countryCode": "1",
}
],
"webhookReceivers": [
{
"name": "Sample webhook",
"serviceUri": "http://www.example.com/webhook",
"useCommonAlertSchema": true
}
]
},
"tags": {}
}
Next steps
Common alert schema definitions for Webhooks/Logic Apps/Azure Functions/Automation Runbooks.
Learn how to create a logic app that leverages the common alert schema to handle all your alerts.
Common alert schema definitions
This article describes the common alert schema definitions for Azure Monitor, including those for webhooks, Azure
Logic Apps, Azure Functions, and Azure Automation runbooks.
Any alert instance describes the resource that was affected and the cause of the alert. These instances are described
in the common schema in the following sections:
Essentials: A set of standardized fields, common across all alert types, which describe what resource the alert is
on, along with additional common alert metadata (for example, severity or description).
Alert context: A set of fields that describes the cause of the alert, with fields that vary based on the alert type.
For example, a metric alert includes fields like the metric name and metric value in the alert context, whereas an
activity log alert has information about the event that generated the alert.
Sample alert payload
{
"schemaId": "azureMonitorCommonAlertSchema",
"data": {
"essentials": {
"alertId": "/subscriptions/<subscription ID>/providers/Microsoft.AlertsManagement/alerts/b9569717-bc32-
442f-add5-83a997729330",
"alertRule": "WCUS-R2-Gen2",
"severity": "Sev3",
"signalType": "Metric",
"monitorCondition": "Resolved",
"monitoringService": "Platform",
"alertTargetIDs": [
"/subscriptions/<subscription
ID>/resourcegroups/pipelinealertrg/providers/microsoft.compute/virtualmachines/wcus-r2-gen2"
],
"originAlertId": "3f2d4487-b0fc-4125-8bd5-
7ad17384221e_PipeLineAlertRG_microsoft.insights_metricAlerts_WCUS-R2-Gen2_-117781227",
"firedDateTime": "2019-03-22T13:58:24.3713213Z",
"resolvedDateTime": "2019-03-22T14:03:16.2246313Z",
"description": "",
"essentialsVersion": "1.0",
"alertContextVersion": "1.0"
},
"alertContext": {
"properties": null,
"conditionType": "SingleResourceMultipleMetricCriteria",
"condition": {
"allOf": [
{
"metricName": "Percentage CPU",
"metricNamespace": "Microsoft.Compute/virtualMachines",
"threshold": "25",
"timeAggregation": "Average",
"dimensions": [
{
"name": "ResourceId",
"value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"
}
],
"metricValue": 7.727
}
]
}
}
}
}
Essentials
FIELD DESCRIPTION
alertId The GUID uniquely identifying the alert instance.
alertRule The name of the alert rule that generated the alert instance.
Severity The severity of the alert. Possible values: Sev0, Sev1, Sev2,
Sev3, or Sev4.
signalType Identifies the signal on which the alert rule was defined.
Possible values: Metric, Log, or Activity Log.
FIELD DESCRIPTION
monitorCondition When an alert fires, the alert's monitor condition is set to

Fired. When the underlying condition that caused the alert to
fire clears, the monitor condition is set to Resolved.
monitoringService The monitoring service or solution that generated the alert.

The fields for the alert context are dictated by the monitoring
service.
alertTargetIds The list of the Azure Resource Manager IDs that are affected
targets of an alert. For a log alert defined on a Log Analytics
workspace or Application Insights instance, it's the respective
workspace or application.
originAlertId The ID of the alert instance, as generated by the monitoring

service generating it.
firedDateTime The date and time when the alert instance was fired in
Coordinated Universal Time (UTC).
resolvedDateTime The date and time when the monitor condition for the alert
instance is set to Resolved in UTC. Currently only applicable
for metric alerts.
description The description, as defined in the alert rule.
essentialsVersion The version number for the essentials section.
alertContextVersion The version number for the alertContext section.
Sample values
{
"essentials": {
"alertId": "/subscriptions/<subscription ID>/providers/Microsoft.AlertsManagement/alerts/b9569717-bc32-
442f-add5-83a997729330",
"alertRule": "Contoso IT Metric Alert",
"severity": "Sev3",
"signalType": "Metric",
"monitorCondition": "Fired",
"monitoringService": "Platform",
"alertTargetIDs": [
"/subscriptions/<subscription ID>/resourceGroups/aimon-rg/providers/Microsoft.Insights/components/ai-
orion-int-fe"
],
"originAlertId": "74ff8faa0c79db6084969cf7c72b0710e51aec70b4f332c719ab5307227a984f",
"firedDateTime": "2019-03-26T05:25:50.4994863Z",
"description": "Test Metric alert",
"essentialsVersion": "1.0",
"alertContextVersion": "1.0"
}
}
Alert context
Metric alerts
monitoringService = Platform
Sample values
{
"alertContext": {
"properties": null,
"condition": {
"allOf": [
{
"metricNamespace": "Microsoft.Compute/virtualMachines",
"threshold": "25",
"dimensions": [
{
"value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"
}
],
"metricValue": 31.1105
}
],
"windowStartTime": "2019-03-22T13:40:03.064Z",
"windowEndTime": "2019-03-22T13:45:03.064Z"
}
}
}
Log alerts
NOTE
For log alerts that have a custom JSON payload defined, enabling the common schema reverts the payload schema to the
one described as follows. Alerts with the common schema enabled have an upper size limit of 256 KB per alert. Search results
aren't embedded in the log alerts payload if they cause the alert size to cross this threshold. You can determine this by
checking the flag IncludedSearchResults . When the search results aren't included, you should use the search query in
conjunction with the Log Analytics API.
monitoringService = Log Analytics
Sample values
{
"alertContext": {
"SearchQuery": "search * \n| where Type == \"Heartbeat\" \n| where Category == \"Direct Agent\" \n| where
TimeGenerated > ago(30m) ",
"SearchIntervalStartTimeUtc": "3/22/2019 1:36:31 PM",
"SearchIntervalEndtimeUtc": "3/22/2019 1:51:31 PM",
"ResultCount": 15,
"LinkToSearchResults": "https://portal.azure.com#@72f988bf-86f1-41af-91ab-
2d7cd011db47/blade/Microsoft_OperationsManagementSuite_Workspace/AnalyticsBlade/initiator/AnalyticsShareLinkToQ
uery/isQueryEditorVisible/true/scope/%7B%22resources%22%3A%5B%7B%22resourceId%22%3A%22%2Fsubscriptions%
<subscription
ID>%2FresourceGroups%2Fpipelinealertrg%2Fproviders%2FMicrosoft.OperationalInsights%2Fworkspaces%2FINC-
OmsAlertRunner%22%7D%5D%7D/query/search%20%2A%20%0A%7C%20where%20Type%20%3D%3D%20%22Heartbeat%22%20%0A%7C%20whe
re%20Category%20%3D%3D%20%22Direct%20Agent%22%20%0A%7C%20where%20TimeGenerated%20%3E%20%28datetime%282019-03-
22T13%3A51%3A31.0000000%29%20-%2030m%29%20%20/isQuerybase64Compressed/false/timespanInIsoFormat/2019-03-
22T13%3a36%3a31.0000000Z%2f2019-03-22T13%3a51%3a31.0000000Z",
"SeverityDescription": "Warning",
"WorkspaceId": "2a1f50a7-ef97-420c-9d14-938e77c2a929",
"SearchIntervalDurationMin": "15",
"AffectedConfigurationItems": [
"INC-Gen2Alert"
],
"SearchIntervalInMinutes": "15",
"Threshold": 10000,
"Operator": "Less Than",
"SearchResult": {
"tables": [
{
"name": "PrimaryResult",
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Id",
"type": "string"
},
{
"name": "TimeGenerated",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
],
"dataSources": [
{
"resourceId": "/subscriptions/a5ea27e2-7482-49ba-90b3-60e7496dd873/resourcegroups/nrt-tip-
kc/providers/microsoft.operationalinsights/workspaces/nrt-tip-kc",
"tables": [
"Heartbeat"
]
}
]
},
"IncludedSearchResults": "True",
}
}
monitoringService = Application Insights
Sample values
{
"alertContext": {
"SearchQuery": "search *",
"SearchIntervalStartTimeUtc": "3/22/2019 1:36:33 PM",
"SearchIntervalEndtimeUtc": "3/22/2019 1:51:33 PM",
"ResultCount": 0,
"LinkToSearchResults": "https://portal.azure.com#@72f988bf-86f1-41af-91ab-
2d7cd011db47/blade/Microsoft_OperationsManagementSuite_Workspace/AnalyticsBlade/initiator/AnalyticsShareLinkToQ
uery/isQueryEditorVisible/true/scope/%7B%22resources%22%3A%5B%7B%22resourceId%22%3A%22%2Fsubscriptions%
<subscription ID>%2FresourceGroups%2FPipeLineAlertRG%2Fproviders%2Fmicrosoft.insights%2Fcomponents%2FWEU-
AIRunner%22%7D%5D%7D/query/search%20%2A/isQuerybase64Compressed/false/timespanInIsoFormat/2019-03-
22T13%3a36%3a33.0000000Z%2f2019-03-22T13%3a51%3a33.0000000Z",
"SearchIntervalDurationMin": "15",
"SearchIntervalInMinutes": "15",
"Threshold": 10000,
"Operator": "Less Than",
"ApplicationId": "8e20151d-75b2-4d66-b965-153fb69d65a6",
"SearchResult": {
"tables": [
{
"name": "PrimaryResult",
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Id",
"type": "string"
},
{
"name": "TimeGenerated",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
],
"dataSources": [
{
"resourceId": "/subscriptions/a5ea27e2-7482-49ba-90b3-60e7496dd873/resourcegroups/nrt-tip-
kc/providers/microsoft.operationalinsights/workspaces/nrt-tip-kc",
"tables": [
"Heartbeat"
]
}
]
},
"IncludedSearchResults": "True",
}
}
Activity log alerts

monitoringService = Activity Log - Administrative
Sample values
{
"alertContext": {
"authorization": {
"action": "Microsoft.Compute/virtualMachines/restart/action",
"scope": "/subscriptions/<subscription
ID>/resourceGroups/PipeLineAlertRG/providers/Microsoft.Compute/virtualMachines/WCUS-R2-ActLog"
},
"claims": "{\"aud\":\"https://management.core.windows.net/\",\"iss\":\"https://sts.windows.net/72f988bf-
86f1-41af-91ab-
2d7cd011db47/\",\"iat\":\"1553260826\",\"nbf\":\"1553260826\",\"exp\":\"1553264726\",\"aio\":\"42JgYNjdt+rr+3j/
dx68v018XhuFAwA=\",\"appid\":\"e9a02282-074f-45cf-93b0-
50568e0e7e50\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://s
ts.windows.net/72f988bf-86f1-41af-91ab-
2d7cd011db47/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"9778283b-b94c-4ac6-8a41-
d5b493d03aa3\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"9778283b-b94c-4ac6-
8a41-d5b493d03aa3\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"72f988bf-86f1-41af-91ab-
2d7cd011db47\",\"uti\":\"v5wYC9t9ekuA2rkZSVZbAA\",\"ver\":\"1.0\"}",
"caller": "9778283b-b94c-4ac6-8a41-d5b493d03aa3",
"correlationId": "8ee9c32a-92a1-4a8f-989c-b0ba09292a91",
"eventSource": "Administrative",
"eventTimestamp": "2019-03-22T13:56:31.2917159+00:00",
"eventDataId": "161fda7e-1cb4-4bc5-9c90-857c55a8f57b",
"operationName": "Microsoft.Compute/virtualMachines/restart/action",
"operationId": "310db69b-690f-436b-b740-6103ab6b0cba",
"subStatus": "",
"submissionTimestamp": "2019-03-22T13:56:54.067593+00:00"
}
}
monitoringService = Activity Log - Policy
Sample values
{
"alertContext": {
"authorization": {
"action": "Microsoft.Resources/checkPolicyCompliance/read",
"scope": "/subscriptions/<GUID>"
},
"claims": "
{\"aud\":\"https://management.azure.com/\",\"iss\":\"https://sts.windows.net/<GUID>/\",\"iat\":\"1566711059\",\
"nbf\":\"1566711059\",\"exp\":\"1566740159\",\"aio\":\"42FgYOhynHNw0scy3T/bL71+xLyqEwA=\",\"appid\":\"
<GUID>\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://sts.win
dows.net/<GUID>/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"
<GUID>\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"
<GUID>\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"
<GUID>\",\"uti\":\"Miy1GzoAG0Scu_l3m1aIAA\",\"ver\":\"1.0\"}",
"caller": "<GUID>",
"correlationId": "<GUID>",
"eventSource": "Policy",
"eventDataId": "<GUID>",
"level": "Warning",
"operationName": "Microsoft.Authorization/policies/audit/action",
"operationId": "<GUID>",
"properties": {
"isComplianceCheck": "True",
"resourceLocation": "eastus2",
"ancestors": "<GUID>",
"policies": "
[{\"policyDefinitionId\":\"/providers/Microsoft.Authorization/policyDefinitions/<GUID>/\",\"policySetDefinition
Id\":\"/providers/Microsoft.Authorization/policySetDefinitions/<GUID>/\",\"policyDefinitionReferenceId\":\"vuln
erabilityAssessmentMonitoring\",\"policySetDefinitionName\":\"<GUID>\",\"policyDefinitionName\":\"
<GUID>\",\"policyDefinitionEffect\":\"AuditIfNotExists\",\"policyAssignmentId\":\"/subscriptions/<GUID>/provide
rs/Microsoft.Authorization/policyAssignments/SecurityCenterBuiltIn/\",\"policyAssignmentName\":\"SecurityCenter
BuiltIn\",\"policyAssignmentScope\":\"/subscriptions/<GUID>\",\"policyAssignmentSku\":
{\"name\":\"A1\",\"tier\":\"Standard\"},\"policyAssignmentParameters\":{}}]"
},
"subStatus": "",
}
}
monitoringService = Activity Log - Autoscale
Sample values
{
"alertContext": {
"claims": "
{\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn\":\"Microsoft.Insights/autoscaleSettings\"}",
"caller": "Microsoft.Insights/autoscaleSettings",
"eventSource": "Autoscale",
"operationName": "Microsoft.Insights/AutoscaleSettings/Scaleup/Action",
"properties": {
"description": "The autoscale engine attempting to scale resource
'/subscriptions/d<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS'
from 9 instances count to 10 instances count.",
"resourceName":
"/subscriptions/<GUID>/resourceGroups/voiceassistancedemo/providers/Microsoft.Compute/virtualMachineScaleSets/a
lexademo",
"oldInstancesCount": "9",
"newInstancesCount": "10",
"activeAutoscaleProfile": "{\r\n \"Name\": \"Auto created scale condition\",\r\n \"Capacity\": {\r\n
\"Minimum\": \"1\",\r\n \"Maximum\": \"10\",\r\n \"Default\": \"1\"\r\n },\r\n \"Rules\": [\r\n
{\r\n \"MetricTrigger\": {\r\n \"Name\": \"Percentage CPU\",\r\n \"Namespace\":
\"microsoft.compute/virtualmachinescalesets\",\r\n \"Resource\":
\"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\r
\n \"ResourceLocation\": \"eastus\",\r\n \"TimeGrain\": \"PT1M\",\r\n \"Statistic\":
\"Average\",\r\n \"TimeWindow\": \"PT5M\",\r\n \"TimeAggregation\": \"Average\",\r\n
\"Operator\": \"GreaterThan\",\r\n \"Threshold\": 0.0,\r\n \"Source\":
\"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\r
\n \"MetricType\": \"MDM\",\r\n \"Dimensions\": [],\r\n \"DividePerInstance\": false\r\n
},\r\n \"ScaleAction\": {\r\n \"Direction\": \"Increase\",\r\n \"Type\":
\"ChangeCount\",\r\n \"Value\": \"1\",\r\n \"Cooldown\": \"PT1M\"\r\n }\r\n }\r\n
]\r\n}",
"lastScaleActionTime": "Wed, 21 Aug 2019 16:17:47 GMT"
},
}
}
monitoringService = Activity Log - Security
Sample values
{
"alertContext": {
"eventSource": "Security",
"eventTimestamp": "2019-08-26T08:34:14+00:00",
"operationName": "Microsoft.Security/locations/alerts/activate/action",
"properties": {
"threatStatus": "Quarantined",
"category": "Virus",
"threatID": "2147519003",
"filePath": "C:\\AlertGeneration\\test.eicar",
"protectionType": "Windows Defender",
"actionTaken": "Blocked",
"resourceType": "Virtual Machine",
"severity": "Low",
"compromisedEntity": "testVM",
"remediationSteps": "[\"No user action is necessary\"]",
"attackedResourceType": "Virtual Machine"
},
"status": "Active",
}
}
monitoringService = ServiceHealth
Sample values
{
"alertContext": {
"authorization": null,
"channels": 1,
"claims": null,
"caller": null,
"correlationId": "f3cf2430-1ee3-4158-8e35-7a1d615acfc7",
"eventSource": 2,
"httpRequest": null,
"level": 3,
"operationName": "Microsoft.ServiceHealth/maintenance/action",
"properties": {
"title": "Azure SQL DW Scheduled Maintenance Pending",
"service": "SQL Data Warehouse",
"region": "East US",
"communication": "<MESSAGE>",
"incidentType": "Maintenance",
"trackingId": "<GUID>",
"impactStartTime": "2019-06-26T04:00:00Z",
"impactMitigationTime": "2019-06-26T12:00:00Z",
"impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"East US\"}],\"ServiceName\":\"SQL Data
Warehouse\"}]",
"impactedServicesTableRows": "<tr>\r\n<td align='center' style='padding: 5px 10px; border-right:1px solid
black; border-bottom:1px solid black'>SQL Data Warehouse</td>\r\n<td align='center' style='padding: 5px 10px;
border-bottom:1px solid black'>East US<br></td>\r\n</tr>\r\n",
"defaultLanguageTitle": "Azure SQL DW Scheduled Maintenance Pending",
"defaultLanguageContent": "<MESSAGE>",
"stage": "Planned",
"communicationId": "<GUID>",
"maintenanceId": "<GUID>",
"isHIR": "false",
"version": "0.1.1"
},
"status": "Active",
"subStatus": null,
"submissionTimestamp": "2019-06-24T11:31:31.7147357+00:00",
"ResourceType": null
}
}
monitoringService = Resource Health
Sample values
{
"alertContext": {
"eventSource": "ResourceHealth",
"operationName": "Microsoft.Resourcehealth/healthevent/Activated/action",
"properties": {
"title": "This virtual machine is stopping and deallocating as requested by an authorized user or
process",
"details": null,
"currentHealthStatus": "Unavailable",
"previousHealthStatus": "Available",
"type": "Downtime",
"cause": "UserInitiated"
},
"status": "Active",
}
}
Next steps
Learn more about the common alert schema.
Learn how to create a logic app that uses the common alert schema to handle all your alerts.
How to integrate the common alert schema with
Logic Apps
This article shows you how to create a logic app that leverages the common alert schema to handle all your alerts.
Overview
The common alert schema provides a standardized and extensible JSON schema across all your different alert
types. The common alert schema is most useful when leveraged programmatically – through webhooks, runbooks,
and logic apps. In this article, we demonstrate how a single logic app can be authored to handle all your alerts. The
same principles can be applied to other programmatic methods. The logic app described in this article creates well-
defined variables for the 'essential' fields, and also describes how you can handle alert type specific logic.
Prerequisites
This article assumes that the reader is familiar with
Setting up alert rules ( metric, log, activity log)
Setting up action groups
Enabling the common alert schema from within action groups
Create a logic app leveraging the common alert schema

1. Follow the steps outlined to create your logic app.
2. Select the trigger: When a HTTP request is received.
3. Select Edit to change the HTTP request trigger.

4. Copy and paste the following schema:
{
"type": "object",
"properties": {
"schemaId": {
"type": "string"
},
"data": {
"type": "object",
"properties": {
"essentials": {
"type": "object",
"properties": {
"alertId": {
"type": "string"
},
"alertRule": {
"type": "string"
},
"severity": {
"type": "string"
},
"signalType": {
"type": "string"
},
"monitorCondition": {
"type": "string"
},
"monitoringService": {
"type": "string"
},
"alertTargetIDs": {
"type": "array",
"items": {
"type": "string"
}
},
"originAlertId": {
"type": "string"
},
"firedDateTime": {
"type": "string"
},
"resolvedDateTime": {
"type": "string"
},
"description": {
"type": "string"
},
"essentialsVersion": {
"type": "string"
},
"alertContextVersion": {
"type": "string"
}
}
},
"alertContext": {
"type": "object",
"properties": {}
}
}
}
}
}
5. Select + New step and then choose Add an action.

6. At this stage, you can add a variety of connectors (Microsoft Teams, Slack, Salesforce, etc.) based on your
specific business requirements. You can use the 'essential fields' out-of-the-box.
Alternatively, you can author conditional logic based on the alert type using the 'Expression' option.
The 'monitoringService' field allows you to uniquely identify the alert type, based on which you can create
the conditional logic.
For example, the below snippet checks if the alert is a Application Insights based log alert, and if so prints
the search results. Else, it prints 'NA'.
if(equals(triggerBody()?['data']?['essentials']?['monitoringService'],'Application
Insights'),triggerBody()?['data']?['alertContext']?['SearchResults'],'NA')
Learn more about writing logic app expressions.
Next steps
Learn more about the common alert schema.
Webhooks for Azure activity log alerts
As part of the definition of an action group, you can configure webhook endpoints to receive activity log alert
notifications. With webhooks, you can route these notifications to other systems for post-processing or custom
actions. This article shows what the payload for the HTTP POST to a webhook looks like.
For more information on activity log alerts, see how to create Azure activity log alerts.
For information on action groups, see how to create action groups.
NOTE
You can also use the common alert schema, which provides the advantage of having a single extensible and unified alert
payload across all the alert services in Azure Monitor, for your webhook integrations. Learn about the common alert
schema definitions.
Authenticate the webhook

The webhook can optionally use token-based authorization for authentication. The webhook URI is saved with a
token ID, for example, https://mysamplealert/webcallback?tokenid=sometokenid&someparameter=somevalue .
Payload schema
The JSON payload contained in the POST operation differs based on the payload's
data.context.activityLog.eventSource field.
Common
{
"schemaId": "Microsoft.Insights/activityLogs",
"data": {
"status": "Activated",
"context": {
"activityLog": {
"correlationId": "6ac88262-43be-4adf-a11c-bd2179852898",
"eventDataId": "8195a56a-85de-4663-943e-1a2bf401ad94",
"operationName": "Microsoft.Insights/actionGroups/write",
"operationId": "6ac88262-43be-4adf-a11c-bd2179852898",
"status": "Started",
"subStatus": "",
"subscriptionId": "52c65f65-0518-4d37-9719-7dbbfc68c57a",
...
}
},
"properties": {}
}
}
Administrative
{
"data": {
"context": {
"activityLog": {
"authorization": {
"action": "Microsoft.Insights/actionGroups/write",
"scope": "/subscriptions/52c65f65-0518-4d37-9719-7dbbfc68c57b/resourceGroups/CONTOSO-
TEST/providers/Microsoft.Insights/actionGroups/IncidentActions"
},
"claims": "{...}",
"caller": "me@contoso.com",
"description": "",
"httpRequest": "{...}",
"resourceId": "/subscriptions/52c65f65-0518-4d37-9719-7dbbfc68c57b/resourceGroups/CONTOSO-
TEST/providers/Microsoft.Insights/actionGroups/IncidentActions",
"resourceGroupName": "CONTOSO-TEST",
"resourceProviderName": "Microsoft.Insights",
"resourceType": "Microsoft.Insights/actionGroups"
}
},
"properties": {}
}
}
Security
{
"schemaId":"Microsoft.Insights/activityLogs",
"data":{"status":"Activated",
"context":{
"activityLog":{
"channels":"Operation",
"correlationId":"2518408115673929999",
"description":"Failed SSH brute force attack. Failed brute force attacks were detected from the following
attackers: [\"IP Address: 01.02.03.04\"]. Attackers were trying to access the host with the following user
names: [\"root\"].",
"eventSource":"Security",
"eventTimestamp":"2017-06-25T19:00:32.607+00:00",
"eventDataId":"Sec-07f2-4d74-aaf0-03d2f53d5a33",
"level":"Informational",
"operationName":"Microsoft.Security/locations/alerts/activate/action",
"operationId":"Sec-07f2-4d74-aaf0-03d2f53d5a33",
"properties":{
"attackers":"[\"IP Address: 01.02.03.04\"]",
"numberOfFailedAuthenticationAttemptsToHost":"456",
"accountsUsedOnFailedSignInToHostAttempts":"[\"root\"]",
"wasSSHSessionInitiated":"No","endTimeUTC":"06/25/2017 19:59:39",
"actionTaken":"Detected",
"resourceType":"Virtual Machine",
"severity":"Medium",
"compromisedEntity":"LinuxVM1",
"remediationSteps":"[In case this is an Azure virtual machine, add the source IP to NSG block list for 24
hours (see https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/)]",
"attackedResourceType":"Virtual Machine"
},
"resourceId":"/subscriptions/12345-5645-123a-9867-
123b45a6789/resourceGroups/contoso/providers/Microsoft.Security/locations/centralus/alerts/Sec-07f2-4d74-aaf0-
03d2f53d5a33",
"resourceGroupName":"contoso",
"resourceProviderName":"Microsoft.Security",
"status":"Active",
"subscriptionId":"12345-5645-123a-9867-123b45a6789",
"submissionTimestamp":"2017-06-25T20:23:04.9743772+00:00",
"resourceType":"MICROSOFT.SECURITY/LOCATIONS/ALERTS"
}
},
"properties":{}
}
}
Recommendation
{
"schemaId":"Microsoft.Insights/activityLogs",
"data":{
"status":"Activated",
"context":{
"activityLog":{
"channels":"Operation",
"claims":"{\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress\":\"Microsoft.Advisor\"}",
"caller":"Microsoft.Advisor",
"correlationId":"123b4c54-11bb-3d65-89f1-0678da7891bd",
"description":"A new recommendation is available.",
"eventSource":"Recommendation",
"eventTimestamp":"2017-06-29T13:52:33.2742943+00:00",
"httpRequest":"{\"clientIpAddress\":\"0.0.0.0\"}",
"eventDataId":"1bf234ef-e45f-4567-8bba-fb9b0ee1dbcb",
"level":"Informational",
"operationName":"Microsoft.Advisor/recommendations/available/action",
"properties":{
"recommendationSchemaVersion":"1.0",
"recommendationCategory":"HighAvailability",
"recommendationImpact":"Medium",
"recommendationName":"Enable Soft Delete to protect your blob data",
"recommendationResourceLink":"https://portal.azure.com/#blade/Microsoft_Azure_Expert/RecommendationListBlade/r
ecommendationTypeId/12dbf883-5e4b-4f56-7da8-123b45c4b6e6",
"recommendationType":"12dbf883-5e4b-4f56-7da8-123b45c4b6e6"
},
"resourceId":"/subscriptions/12345-5645-123a-9867-
123b45a6789/resourceGroups/contoso/providers/microsoft.storage/storageaccounts/contosoStore",
"resourceGroupName":"CONTOSO",
"resourceProviderName":"MICROSOFT.STORAGE",
"status":"Active",
"subStatus":"",
"subscriptionId":"12345-5645-123a-9867-123b45a6789",
"submissionTimestamp":"2017-06-29T13:52:33.2742943+00:00",
"resourceType":"MICROSOFT.STORAGE/STORAGEACCOUNTS"
}
},
"properties":{}
}
}
ServiceHealth
{
"data": {
"context": {
"activityLog": {
"correlationId": "bbac944f-ddc0-4b4c-aa85-cc7dc5d5c1a6",
"description": "Active: Virtual Machines - Australia East",
"eventSource": "ServiceHealth",
"eventDataId": "6fa98c0f-334a-b066-1934-1a4b3d929856",
"operationName": "Microsoft.ServiceHealth/incident/action",
"operationId": "bbac944f-ddc0-4b4c-aa85-cc7dc5d5c1a6",
"properties": {
"title": "Virtual Machines - Australia East",
"service": "Virtual Machines",
"region": "Australia East",
"communication": "Starting at 02:48 UTC on 18 Oct 2017 you have been identified as a customer
using Virtual Machines in Australia East who may receive errors starting Dv2 Promo and DSv2 Promo Virtual
Machines which are in a stopped "deallocated" or suspended state. Customers can still provision Dv1
and Dv2 series Virtual Machines or try deploying Virtual Machines in other regions, as a possible workaround.
Engineers have identified a possible fix for the underlying cause, and are exploring implementation options.
The next update will be provided as events warrant.",
"trackingId": "0NIH-U2O",
"impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"Australia
East\"}],\"ServiceName\":\"Virtual Machines\"}]",
"defaultLanguageTitle": "Virtual Machines - Australia East",
"defaultLanguageContent": "Starting at 02:48 UTC on 18 Oct 2017 you have been identified as a
customer using Virtual Machines in Australia East who may receive errors starting Dv2 Promo and DSv2 Promo
Virtual Machines which are in a stopped "deallocated" or suspended state. Customers can still
provision Dv1 and Dv2 series Virtual Machines or try deploying Virtual Machines in other regions, as a
possible workaround. Engineers have identified a possible fix for the underlying cause, and are exploring
implementation options. The next update will be provided as events warrant.",
"stage": "Active",
"version": "0.1.1"
},
"status": "Active",
"subscriptionId": "45529734-0ed9-4895-a0df-44b59a5a07f9",
}
},
"properties": {}
}
}
For specific schema details on service health notification activity log alerts, see Service health notifications.
Additionally, learn how to configure service health webhook notifications with your existing problem
management solutions.
ResourceHealth
{
"data": {
"context": {
"activityLog": {
"correlationId": "a1be61fd-37ur-ba05-b827-cb874708babf",
"eventSource": "ResourceHealth",
"eventDataId": "2b37e2d0-7bda-4de7-ur8c6-1447d02265b2",
"operationName": "Microsoft.Resourcehealth/healthevent/Activated/action",
"operationId": "2b37e2d0-7bda-489f-81c6-1447d02265b2",
"properties": {
"title": "Virtual Machine health status changed to unavailable",
"details": "Virtual machine has experienced an unexpected event",
"currentHealthStatus": "Unavailable",
"previousHealthStatus": "Available",
"type": "Downtime",
"cause": "PlatformInitiated"
},
"resourceId": "/subscriptions/<subscription Id>/resourceGroups/<resource
group>/providers/Microsoft.Compute/virtualMachines/<resource name>",
"resourceGroupName": "<resource group>",
"resourceProviderName": "Microsoft.Resourcehealth/healthevent/action",
"status": "Active",
"subscriptionId": "<subscription Id>",
"resourceType": "Microsoft.Compute/virtualMachines"
}
}
}
}
status Used for metric alerts. Always set to "activated" for activity
log alerts.
context Context of the event.
resourceProviderName The resource provider of the impacted resource.
conditionType Always "Event."
name Name of the alert rule.
id Resource ID of the alert.
description Alert description set when the alert is created.
subscriptionId Azure subscription ID.
timestamp Time at which the event was generated by the Azure service
that processed the request.

resourceGroupName Name of the resource group for the impacted resource.
properties Set of <Key, Value> pairs (that is,

Dictionary<String, String> ) that includes details about
the event.
event Element that contains metadata about the event.
authorization The Role-Based Access Control properties of the event. These

properties usually include the action, the role, and the scope.
category Category of the event. Supported values include

Administrative, Alert, Security, ServiceHealth, and
Recommendation.
caller Email address of the user who performed the operation, UPN
claim, or SPN claim based on availability. Can be null for
certain system calls.
correlationId Usually a GUID in string format. Events with correlationId

belong to the same larger action and usually share a
correlationId.
eventDescription Static text description of the event.
eventDataId Unique identifier for the event.
eventSource Name of the Azure service or infrastructure that generated

the event.
httpRequest The request usually includes the clientRequestId,

clientIpAddress, and HTTP method (for example, PUT).
level One of the following values: Critical, Error, Warning and

Informational.
operationId Usually a GUID shared among the events corresponding to

single operation.
properties Properties of the event.
status String. Status of the operation. Common values include

Started, In Progress, Succeeded, Failed, Active, and Resolved.
subStatus Usually includes the HTTP status code of the corresponding

REST call. It might also include other strings that describe a
substatus. Common substatus values include OK (HTTP
Status Code: 200), Created (HTTP Status Code: 201),
Accepted (HTTP Status Code: 202), No Content (HTTP Status
Code: 204), Bad Request (HTTP Status Code: 400), Not Found
(HTTP Status Code: 404), Conflict (HTTP Status Code: 409),
Internal Server Error (HTTP Status Code: 500), Service
Unavailable (HTTP Status Code: 503), and Gateway Timeout
(HTTP Status Code: 504).
For specific schema details on all other activity log alerts, see Overview of the Azure activity log.
Next steps
Learn more about the activity log.
Execute Azure automation scripts (Runbooks) on Azure alerts.
Use a logic app to send an SMS via Twilio from an Azure alert. This example is for metric alerts, but it can be
modified to work with an activity log alert.
Use a logic app to send a Slack message from an Azure alert. This example is for metric alerts, but it can be
modified to work with an activity log alert.
Use a logic app to send a message to an Azure queue from an Azure alert. This example is for metric alerts, but
it can be modified to work with an activity log alert.
SMS Alert Behavior in Action Groups
Overview
Action groups enable you to configure a list of actions. These groups are used when defining alerts; ensuring that
a particular action group is notified when the alert is triggered. One of the actions supported is SMS; SMS
notifications support bi-directional communication. A user may respond to an SMS to:
Unsubscribe from alerts: A user may unsubscribe from all SMS alerts for all action groups, or a single action
group.
Resubscribe to alerts: A user may resubscribe to all SMS alerts for all action groups, or a single action group.
Request help: A user may ask for more information on the SMS. They are redirected to this article.
This article covers the behavior of the SMS alerts and the response actions the user can take based on the locale
of the user:
Receiving an SMS Alert

An SMS receiver configured as part of an action group receives an SMS when an alert is triggered. The SMS
contains the following information:
Shortname of the action group this alert was sent to
Title of the alert
REPLY DESCRIPTION
DISABLE <Action Group Short name> Disables further SMS from the Action Group
ENABLE <Action Group Short name> Re-enables SMS from the Action Group
STOP Disables further SMS from all Action Groups
START Re-enables SMS from ALL Action Groups
HELP A response is sent to the user with a link to this article.
NOTE
If a user has unsubscribed from SMS alerts, but is then added to a new action group; they WILL receive SMS alerts for that
new action group, but remain unsubscribed from all previous action groups.
Next Steps
Get an overview of activity log alerts and learn how to get alerted
Learn more about SMS rate limiting
Learn more about action groups
Rate limiting for Voice, SMS, emails, Azure App push
notifications and webhook posts
Rate limiting is a suspension of notifications that occurs when too many are sent to a particular phone number,
email address or device. Rate limiting ensures that alerts are manageable and actionable.
The rate limit thresholds are:
SMS: No more than 1 SMS every 5 minutes.
Voice: No more than 1 Voice call every 5 minutes.
Email: No more than 100 emails in an hour.
Other actions are not rate limited.
Rate limit rules

A particular phone number or email is rate limited when it receives more messages than the threshold allows.
A phone number or email can be part of action groups across many subscriptions. Rate limiting applies
across all subscriptions. It applies as soon as the threshold is reached, even if messages are sent from multiple
subscriptions.
When an email address is rate limited, an additional notification is sent to communicate the rate limiting. The
email states when the rate limiting expires.
Next steps
Learn more about SMS alert behavior.
Get an overview of activity log alerts, and learn how to receive alerts.
Learn how to configure alerts whenever a service health notification is posted.
Create an action group with a Resource Manager
template
This article shows you how to use an Azure Resource Manager template to configure action groups. By using
templates, you can automatically set up action groups that can be reused in certain types of alerts. These action
groups ensure that all the correct parties are notified when an alert is triggered.
The basic steps are:
1. Create a template as a JSON file that describes how to create the action group.
2. Deploy the template by using any deployment method.
First, we describe how to create a Resource Manager template for an action group where the action definitions are
hard-coded in the template. Second, we describe how to create a template that takes the webhook configuration
information as input parameters when the template is deployed.
Resource Manager templates for an action group

To create an action group using a Resource Manager template, you create a resource of the type
Microsoft.Insights/actionGroups . Then you fill in all related properties. Here are two sample templates that create
an action group.
{
"parameters": {
"actionGroupName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"actionGroupShortName": {
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/actionGroups",
"apiVersion": "2018-03-01",
"name": "[parameters('actionGroupName')]",
"properties": {
"groupShortName": "[parameters('actionGroupShortName')]",
"enabled": true,
"smsReceivers": [
{
"name": "contosoSMS",
"countryCode": "1",
},
{
"name": "contosoSMS2",
"name": "contosoSMS2",
"countryCode": "1",
}
],
"emailReceivers": [
{
"name": "contosoEmail",
"emailAddress": "devops@contoso.com"
},
{
"name": "contosoEmail2",
"emailAddress": "devops2@contoso.com"
}
],
{
"name": "contosoHook",
"serviceUri": "http://requestb.in/1bq62iu1"
},
{
"name": "contosoHook2",
"serviceUri": "http://requestb.in/1bq62iu2"
}
]
}
}
],
"outputs":{
"actionGroupId":{
"type":"string",
"value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
}
}
}
{
"parameters": {
"actionGroupName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"actionGroupShortName": {
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
},
"webhookReceiverName": {
"type": "string",
"metadata": {
"description": "Webhook receiver service Name."
}
},
"webhookServiceUri": {
"type": "string",
"metadata": {
"description": "Webhook receiver service URI."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/actionGroups",
"apiVersion": "2018-03-01",
"name": "[parameters('actionGroupName')]",
"properties": {
"groupShortName": "[parameters('actionGroupShortName')]",
"enabled": true,
"smsReceivers": [
],
"emailReceivers": [
],
{
"name": "[parameters('webhookReceiverName')]",
"serviceUri": "[parameters('webhookServiceUri')]"
}
]
}
}
],
"outputs":{
"actionGroupResourceId":{
"type":"string",
"value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
}
}
}
Next steps
Learn more about alerts.
Learn how to add alerts by using a Resource Manager template.
How to trigger complex actions with Azure Monitor
alerts
This article shows you how to set up and trigger a logic app to create a conversation in Microsoft Teams when an
alert fires.
Overview
When an Azure Monitor alert triggers, it calls an action group. Action groups allow you to trigger one or more
actions to notify others about an alert and also remediate it.
The general process is:
Create the logic app for the respective alert type.
Import a sample payload for the respective alert type into the logic app.
Define the logic app behavior.
Copy the HTTP endpoint of the logic app into an Azure action group.
The process is similar if you want the logic app to perform a different action.
Create an activity log alert: Administrative

1. In the Azure portal, select Create a resource in the upper-left corner.
2. Search for and select Logic App, then select Create.
3. Give your logic app a Name, choose a Resource group, and so on.
4. Select Create to create the logic app. A pop-up message indicates that the logic app is created. Select
Launch Resource to open the Logic Apps Designer.
5. Select the trigger: When a HTTP request is received.
6. Select Edit to change the HTTP request trigger.

7. Select Use sample payload to generate schema.
8. Copy and paste the following sample payload into the dialog box:
{
"data": {
"context": {
"activityLog": {
"authorization": {
"action": "microsoft.insights/activityLogAlerts/write",
"scope": "/subscriptions/…"
},
"claims": "…",
"caller": "logicappdemo@contoso.com",
"correlationId": "91ad2bac-1afa-4932-a2ce-2f8efd6765a3",
"description": "",
"eventDataId": "ec74c4a2-d7ae-48c3-a4d0-2684a1611ca0",
"operationName": "microsoft.insights/activityLogAlerts/write",
"operationId": "61f59fc8-1442-4c74-9f5f-937392a9723c",
"resourceId": "/subscriptions/…",
"resourceGroupName": "LOGICAPP-DEMO",
"resourceProviderName": "microsoft.insights",
"subStatus": "",
"subscriptionId": "…",
"resourceType": "microsoft.insights/activityLogAlerts"
}
},
"properties": {}
}
}
9. The Logic App Designer displays a pop-up window to remind you that the request sent to the logic app
must set the Content-Type header to application/json. Close the pop-up window. The Azure Monitor
alert sets the header.
10. Select + New step and then choose Add an action.
11. Search for and select the Microsoft Teams connector. Choose the Microsoft Teams – Post message action.
12. Configure the Microsoft Teams action. The Logic Apps Designer asks you to authenticate to your Office
365 account. Choose the Team ID and Channel ID to send the message to.
13. Configure the message by using a combination of static text and references to the <fields> in the dynamic
content. Copy and paste the following text into the Message field:
Activity Log Alert: <eventSource>

operationName: <operationName>
status: <status>
resourceId: <resourceId>
Then search for and replace the <fields> with dynamic content tags of the same name.
NOTE
There are two dynamic fields that are named status. Add both of these fields to the message. Use the field that's in
the activityLog property bag and delete the other field. Hover your cursor over the status field to see the fully
qualified field reference, as shown in the following screenshot:
14. At the top of the Logic Apps Designer, select Save to save your logic app.
15. Open your existing action group and add an action to reference the logic app. If you don’t have an existing
action group, see Create and manage action groups in the Azure portal to create one. Don’t forget to save
your changes.
The next time an alert calls your action group, your logic app is called.
Create a service health alert

Azure Service Health entries are part of the activity log. The process for creating the alert is similar to creating an
activity log alert, but with a few changes:
Steps 1 through 7 are the same.
For step 8, use the following sample payload for the HTTP request trigger:
{
"data": {
"context": {
"activityLog": {
"correlationId": "e416ed3c-8874-4ec8-bc6b-54e3c92a24d4",
"description": "…",
"eventSource": "ServiceHealth",
"eventDataId": "9ce152f5-d435-ee31-2dce-104228486a6d",
"operationName": "Microsoft.ServiceHealth/incident/action",
"operationId": "e416ed3c-8874-4ec8-bc6b-54e3c92a24d4",
"properties": {
"title": "…",
"service": "…",
"region": "Global",
"communication": "…",
"trackingId": "…",
"impactMitigationTime": "2018-03-22T21:41:00.0000000Z",
"impactedServices": "[{"ImpactedRegions"}]",
"defaultLanguageTitle": "…",
"defaultLanguageContent": "…",
"stage": "Active",
"version": "0.1.1"
},
"status": "Active",
}
},
"properties": {}
}
}
Steps 9 and 10 are the same.

For steps 11 through 14, use the following process:
1. Select + New step and then choose Add a condition. Set the following conditions so the logic app
executes only when the input data matches the values below. When entering the version value into
the text box, put quotes around it ("0.1.1") to make sure that it's evaluated as a string and not a
numeric type. The system does not show the quotes if you return to the page, but the underlying code
still maintains the string type.
schemaId == Microsoft.Insights/activityLogs
eventSource == ServiceHealth
version == "0.1.1"
2. In the if true condition, follow the instructions in steps 11 through 13 in Create an activity log alert to
add the Microsoft Teams action.
3. Define the message by using a combination of HTML and dynamic content. Copy and paste the
following content into the Message field. Replace the [incidentType] , [trackingID] , [title] , and
[communication] fields with dynamic content tags of the same name:
<p>
<b>Alert Type:</b> <strong>[incidentType]</strong>
<strong>Tracking ID:</strong> [trackingId]
<strong>Title:</strong> [title]</p>
<p>
<a
href="https://ms.portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade/serviceIss
ues">For details, log in to the Azure Service Health dashboard.</a>
</p>
<p>[communication]</p>
4. For the If false condition, provide a useful message:
<p><strong>Service Health Alert</strong></p>

<p><b>Unrecognized alert schema</b></p>
<p><a
href="https://ms.portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade/serviceIss
ues">For details, log in to the Azure Service Health dashboard.\</a></p>
Step 15 is the same. Follow the instructions to save your logic app and update your action group.
Create a metric alert

The process for creating a metric alert is similar to creating an activity log alert, but with a few changes:
Steps 1 through 7 are the same.
For step 8, use the following sample payload for the HTTP request trigger:
{
"schemaId": "AzureMonitorMetricAlert",
"data": {
"version": "2.0",
"context": {
"timestamp": "2018-04-09T19:00:07.7461615Z",
"id": "…",
"name": "TEST-VM CPU Utilization",
"description": "",
"condition": {
"allOf": [
{
"dimensions": [
{
"value": "d92fc5cb-06cf-4309-8c9a-538eea6a17a6"
}
],
"threshold": "5",
"timeAggregation": "PT15M",
"metricValue": 1.0
}
]
},
"resourceGroupName": "TEST",
"resourceName": "test-vm",
"resourceType": "Microsoft.Compute/virtualMachines",
"resourceId": "…",
"portalLink": "…"
},
"properties": {}
}
}
Steps 9 and 10 are the same.

For steps 11 through 14, use the following process:
1. Select + New step and then choose Add a condition. Set the following conditions so the logic app
executes only when the input data matches these values below. When entering the version value into
the text box, put quotes around it ("2.0") to makes sure that it's evaluated as a string and not a
numeric type. The system does not show the quotes if you return to the page, but the underlying code
still maintains the string type.
schemaId == AzureMonitorMetricAlert
version == "2.0"
2. In the if true condition, add a For each loop and the Microsoft Teams action. Define the message by
using a combination of HTML and dynamic content.
3. In the If false condition, define a Microsoft Teams action to communicate that the metric alert
doesn’t match the expectations of the logic app. Include the JSON payload. Notice how to reference
the triggerBody dynamic content in the json() expression.
Step 15 is the same. Follow the instructions to save your logic app and update your action group.
Calling other applications besides Microsoft Teams

Logic Apps has a number of different connectors that allow you to trigger actions in a wide range of applications
and databases. Slack, SQL Server, Oracle, Salesforce, are just some examples. For more information about
connectors, see Logic App connectors.
Next steps
Get an overview of Azure activity log alerts and learn how to receive alerts.
Learn how to configure alerts when an Azure Service Health notification is posted.
Alert Management solution in Azure Log Analytics
NOTE
Azure Monitor now supports enhanced capabilities for managing your alerts at scale, including those generated by
monitoring tools like System Center Operations Manager, Zabbix, or Nagios.
The Alert Management solution helps you analyze all of the alerts in your Log Analytics repository. These alerts
may have come from a variety of sources including those sources created by Log Analytics or imported from
Nagios or Zabbix. The solution also imports alerts from any connected System Center Operations Manager
management groups.
Prerequisites
The solution works with any records in the Log Analytics repository with a type of Alert, so you must perform
whatever configuration is required to collect these records.
For Log Analytics alerts, create alert rules to create alert records directly in the repository.
For Nagios and Zabbix alerts, configure those servers to send alerts to Log Analytics.
For System Center Operations Manager alerts, connect your Operations Manager management group to your
Log Analytics workspace. Any alerts created in System Center Operations Manager are imported into Log
Analytics.
Configuration
Add the Alert Management solution to your Log Analytics workspace using the process described in Add
solutions. There is no further configuration required.
Management packs
If your System Center Operations Manager management group is connected to your Log Analytics workspace,
then the following management packs are installed in System Center Operations Manager when you add this
solution. There is no configuration or maintenance of the management packs required.
Microsoft System Center Advisor Alert Management (Microsoft.IntelligencePacks.AlertManagement)
Analytics.
Data collection
Agents
Windows agents No Direct Windows agents do not generate

alerts. Log Analytics alerts can be
created from events and performance
data collected from Windows agents.
Linux agents No Direct Linux agents do not generate

alerts. Log Analytics alerts can be
created from events and performance
data collected from Linux agents.
Nagios and Zabbix alerts are collected
from those servers that require the
Linux agent.
System Center Operations Manager Yes Alerts that are generated on

management group Operations Manager agents are
delivered to the management group
and then forwarded to Log Analytics.
A direct connection from Operations

Manager agents to Log Analytics is not
required. Alert data is forwarded from
the management group to the Log
Analytics repository.
Collection frequency
Alert records are available to the solution as soon as they are stored in the repository.
Alert data is sent from the Operations Manager management group to Log Analytics every three minutes.
Using the solution

When you add the Alert Management solution to your Log Analytics workspace, the Alert Management tile is
added to your dashboard. This tile displays a count and graphical representation of the number of currently active
alerts that were generated within the last 24 hours. You cannot change this time range.
Click on the Alert Management tile to open the Alert Management dashboard. The dashboard includes the
columns in the following table. Each column lists the top 10 alerts by count matching that column's criteria for the
specified scope and time range. You can run a log search that provides the entire list by clicking See all at the
bottom of the column or by clicking the column header.
COLUMN DESCRIPTION
Critical Alerts All alerts with a severity of Critical grouped by alert name.
Click on an alert name to run a log search returning all
records for that alert.
COLUMN DESCRIPTION
Warning Alerts All alerts with a severity of Warning grouped by alert name.
Click on an alert name to run a log search returning all
records for that alert.
Active System Center Operations Manager Alerts All alerts collected from Operations Manager with any state
other than Closed grouped by source that generated the
alert.
All Active Alerts All alerts with any severity grouped by alert name. Only
includes Operations Manager alerts with any state other than
Closed.
If you scroll to the right, the dashboard lists several common queries that you can click on to perform a log search
for alert data.
Log Analytics records

The Alert Management solution analyzes any record with a type of Alert. Alerts created by Log Analytics or
collected from Nagios or Zabbix are not directly collected by the solution.
The solution does import alerts from System Center Operations Manager and creates a corresponding record for
each with a type of Alert and a SourceSystem of OpsManager. These records have the properties in the
following table:
Type Alert
AlertContext Details of the data item that caused the alert to be generated
in XML format.
AlertDescription Detailed description of the alert.
AlertId GUID of the alert.
AlertName Name of the alert.

AlertPriority Priority level of the alert.
AlertSeverity Severity level of the alert.
AlertState Latest resolution state of the alert.
LastModifiedBy Name of the user who last modified the alert.
ManagementGroupName Name of the management group where the alert was

generated.
RepeatCount Number of times the same alert was generated for the same
monitored object since being resolved.
ResolvedBy Name of the user who resolved the alert. Empty if the alert
has not yet been resolved.
SourceDisplayName Display name of the monitoring object that generated the

alert.
SourceFullName Full name of the monitoring object that generated the alert.
TicketId Ticket ID for the alert if the System Center Operations

Manager environment is integrated with a process for
assigning tickets for alerts. Empty of no ticket ID is assigned.
TimeGenerated Date and time that the alert was created.
TimeLastModified Date and time that the alert was last changed.
TimeRaised Date and time that the alert was generated.
TimeResolved Date and time that the alert was resolved. Empty if the alert
has not yet been resolved.
Sample log searches

The following table provides sample log searches for alert records collected by this solution:
QUERY DESCRIPTION
Alert | where SourceSystem == "OpsManager" and Critical alerts raised during the past 24 hours
AlertSeverity == "error" and TimeRaised > ago(24h)
Alert | where AlertSeverity == "warning" and TimeRaised > Warning alerts raised during the past 24 hours
ago(24h)
Alert | where SourceSystem == "OpsManager" and AlertState Sources with active alerts raised during the past 24 hours
!= "Closed" and TimeRaised > ago(24h) | summarize Count =
count() by SourceDisplayName
QUERY DESCRIPTION
Alert | where SourceSystem == "OpsManager" and Critical alerts raised during the past 24 hours that are still
AlertSeverity == "error" and TimeRaised > ago(24h) and active
AlertState != "Closed"
Alert | where SourceSystem == "OpsManager" and Alerts raised during the past 24 hours that are now closed
TimeRaised > ago(24h) and AlertState == "Closed"
Alert | where SourceSystem == "OpsManager" and Alerts raised during the past 1 day grouped by their severity
TimeRaised > ago(1d) | summarize Count = count() by
AlertSeverity
Alert | where SourceSystem == "OpsManager" and Alerts raised during the past 1 day sorted by their repeat
TimeRaised > ago(1d) | sort by RepeatCount desc count value
Next steps
Learn about Alerts in Log Analytics for details on generating alerts from Log Analytics.
Smart groups
A common challenge faced when dealing with alerts is sifting through the noise to find out what actually matters -
smart groups are intended to be the solution to that problem.
Smart groups are automatically created by using machine learning algorithms to combine related alerts that
represent a single issue. When an alert is created, the algorithm adds it to a new smart group or an existing smart
group based on information such as historical patterns, similar properties, and similar structure. For example, if %
CPU on several virtual machines in a subscription simultaneously spikes leading to many individual alerts, and if
such alerts have occurred together anytime in the past, these alerts will likely be grouped into a single Smart
Group, suggesting a potential common root cause. This means that for someone troubleshooting alerts, smart
groups not only allows them to reduce noise by managing related alerts as a single aggregated unit, it also guides
them towards possible common root causes for their alerts.
Currently, the algorithm only considers alerts from the same monitor service within a subscription. Smart groups
can reduce up to 99% of alert noise through this consolidation. You can view the reason that alerts were included
in a group in the smart group details page.
You can view the details of smart groups and set the state similarly to how you can with alerts. Each alert is a
member of one and only one smart group.
Smart group state

Smart group state is a similar concept to the alert state, which allows you to manage the resolution process at the
level of a smart group. Similar to the alert state, when a smart group is created, it has the New state, which can be
changed to either Acknowledged or Closed.
The following smart group states are supported.
STATE DESCRIPTION
New The issue has just been detected and has not yet been
reviewed.
Acknowledged An administrator has reviewed the smart group and started

working on it.
Closed The issue has been resolved. After a smart group has been
closed, you can reopen it by changing it to another state.
Learn how to change the state of your smart group.
NOTE
Changing the state of a smart group does not change the state of the individual member alerts.
Smart group details page

The Smart group detail page is displayed when you select a smart group. It provides details about the smart
group, including the reasoning that was used to create the group, and enables you to change its state.
The smart group detail page includes the following sections.
SECTION DESCRIPTION
Alerts Lists the individual alerts that are included in the smart group.
Select an alert to open its alert detail page.
History Lists each action taken by the smart group and any changes
that are made to it. This is currently limited to state changes
and alert membership changes.
Smart group taxonomy

The name of a smart group is the name of its first alert. You can't create or rename a smart group.
Next steps
Manage smart groups
Change your alert and smart group state
Manage alert instances with unified alerts
With the unified alerts experience in Azure Monitor, you can see all your different types of alerts across Azure. This
spans multiple subscriptions, in a single pane. This article shows how you can view your alert instances, and how
to find specific alert instances for troubleshooting.
NOTE
You can only access alerts generated in the last 30 days.
Go to the alerts page

You can go to the alerts page in any of the following ways:
In the Azure portal, select Monitor > Alerts.
Use the context of a specific resource. Open a resource, go to the Monitoring section, and choose Alerts.
The landing page is pre-filtered for alerts on that specific resource.
Use the context of a specific resource group. Open a resource group, go to the Monitoring section, and
choose Alerts. The landing page is pre-filtered for alerts on that specific resource group.
Find alert instances
The Alerts Summary page gives you an overview of all your alert instances across Azure. You can modify the
summary view by selecting multiple subscriptions (up to a maximum of 5), or by filtering across resource
groups, specific resources, or time ranges. Select Total Alerts, or any of the severity bands, to go to the list view
for your alerts.
On the All Alerts page, all the alert instances across Azure are listed. If you’re coming to the portal from an alert
notification, you can use the filters available to narrow in on that specific alert instance.
NOTE
If you came to the page by selecting any of the severity bands, the list is pre-filtered for that severity.
Apart from the filters available on the previous page, you can also filter on the basis of monitor service (for
example, platform for metrics), monitor condition (fired or resolved), severity, alert state
(new/acknowledged/closed), or the smart group ID.
NOTE
If you came to the page by selecting any of the severity bands, the list is pre-filtered for that severity.
Selecting any alert instance opens the Alert Details page, allowing you to see more details about that specific
alert instance.
Manage smart groups
Smart groups use machine learning algorithms to group together alerts on the basis of co-occurrence or similarity,
so that the user can now manage smart groups instead of having to manage each alert individually. This article will
walk you through how to access and use smart groups in Azure Monitor.
1. To see the Smart Groups created for your alert instances you can either
a. Click on Smart Groups from the Alerts Summary page
b. Click on Alerts by Smart Groups from the All Alerts page
2. This takes you to the list view for all Smart Groups created over your alert instances. Instead of sifting through
multiple alerts, you can now deal with the smart groups instead.
3. Clicking on any Smart Group opens up the details page, where you can see the grouping reason, along with the
member alerts. This aggregation allows you to deal with a singular smart group, instead of sifting through
multiple alerts.
Manage alert and smart group states
Alerts in Azure Monitor now have an alert state and a monitor condition and, similarly, Smart Groups have a
smart group state. Changes to the state are now captured in history associated with the respective alert or smart
group. This article walks you through the process of changing the state, for both an alert and a smart group.
Change the state of an alert

1. You can change the state of an alert in the following different ways:
In the All Alerts page, click the checkbox next to the alerts you wish to change the state of, and click
change state.
In the Alert Details page for a particular alert instance, you can click change state
In the Alert Details page for a specific alert instance, in the Smart Group pane you can click the
checkbox next to the alerts you wish
In the Smart Group Details page, in the list of member alerts you can click the checkbox next to the
alerts you wish to change the state of and click Change Stateto change the state of and click Change
State.
2. On clicking Change State, a popup opens up allowing you to select the state (New/Acknowledged/Closed) and
enter a comment if necessary.
3. Once this is done, the state change is recorded in the history of the respective alert. This can be viewed by
opening the respective Details page, and checking the history section.
Change the state of a smart group
1. You can change the state of a smart group in the following different ways:
a. In the Smart Group list page, you can click the checkbox next to the smart groups you wish to change
the state of and click Change State
b. In the Smart Group Details page, you can click change state
2. On clicking Change State, a popup opens up allowing you to select the state (New/Acknowledged/Closed)
and enter a comment if necessary.
NOTE
Changing the state of a smart group does not change the state of the individual member alerts.
3. Once this is done, the state change is recorded in the history of the respective smart group. This can be
viewed by opening the respective Details page, and checking the history section.
Manage alerts from System Center Operations
Manager, Zabbix and Nagios in Azure Monitor
You can now view your alerts from Nagios, Zabbix, and System Center Operations Manager in Azure Monitor.
These alerts come from integrations with Nagios/Zabbix servers or System Center Operations Manager into Log
Analytics.
Prerequisites
Any records in the Log Analytics repository with a type of Alert will get imported into Azure Monitor, so you must
perform the configuration that is required to collect these records.
1. For Nagios and Zabbix alerts, configure those servers to send alerts to Log Analytics.
2. For System Center Operations Manager alerts, connect your Operations Manager management group to
your Log Analytics workspace. Following this, deploy the Alert Management solution from the Azure solutions
marketplace. Once done, any alerts created in System Center Operations Manager are imported into Log
Analytics.
View your alert instances

Once you have configured the import into Log Analytics, you can start viewing alert instances from these
monitoring services in Azure Monitor. Once they are present in Azure Monitor, you can manage your alert
instances, manage smart groups created on these alerts and change the state of your alerts and smart groups.
NOTE
1. This solution only allows you to view System Center Operations Manager/Zabbix/Nagios fired alert instances in Azure
Monitor. Alert rule configuration can only be viewed/edited in respective monitoring tools.
2. All fired alert instances will be available both in Azure Monitor and Azure Log Analytics. Currently, there is no way to
choose between the two or ingest only specific fired alerts.
3. All alerts from System Center Operations Manager, Zabbix and Nagios have the signal type "Unknown" since the
underlying telemetry type is not available.
4. Nagios alerts are not stateful – for example, the monitor condition of an alert will not go from "Fired" to "Resolved".
Instead, both the “Fired” and “Resolved” are displayed as separate alert instances.
What are classic alerts in Microsoft Azure?
NOTE
This article describes how to create older classic metric alerts. Azure Monitor now supports newer near-real time metric
alerts and a new alerts experience. Classic alerts are scheduled to be retired.
Alerts allow you to configure conditions over data and become notified when the conditions match the latest
monitoring data.
Old and New alerting capabilities

In the past Azure Monitor, Application Insights, Log Analytics, and Service Health had separate alerting
capabilities. Overtime, Azure improved and combined both the user interface and different methods of alerting.
The consolidation is still in process.
You can view classic alerts only in the classic alerts user screen in the Azure Portal. You get this screen from the
View classic alerts button on the alerts screen.
The new alerts user experience has the following benefits over the classic alerts experience:
Better notification system - All newer alerts use action groups, which are named groups of notifications
and actions that can be reused in multiple alerts. Classic metric alerts and older Log Analytics alerts do not
use action groups.
A unified authoring experience - All alert creation for metrics, logs and activity log across Azure Monitor,
Log Analytics, and Application Insights is in one place.
View fired Log Analytics alerts in Azure portal - You can now also see fired Log Analytics alerts in your
subscription. Previously these were in a separate portal.
Separation of fired alerts and alert rules - Alert rules (the definition of condition that triggers an alert), and
Fired Alerts (an instance of the alert rule firing) are differentiated, so the operational and configuration views
are separated.
Better workflow - The new alerts authoring experience guides the user along the process of configuring an
alert rule, which makes it simpler to discover the right things to get alerted on.
Smart Alerts consolidation and setting alert state - Newer alerts include auto grouping functionality
showing similar alerts together to reduce overload in the user interface.
The newer metric alerts have the following benefits over the classic metric alerts:
Improved latency: Newer metric alerts can run as frequently as every one minute. Older metric alerts
always run at a frequency of 5 minutes. Newer alerts have increasing smaller delay from issue occurrence to
notification or action (3 to 5 minutes). Older alerts are 5 to 15 minutes depending on the type. Log alerts
typically have 10 to 15-minute delay due to the time it takes to ingest the logs, but newer processing methods
are reducing that time.
Support for multi-dimensional metrics: You can alert on dimensional metrics allowing you to monitor an
interesting segment of the metric.
More control over metric conditions: You can define richer alert rules. The newer alerts support
monitoring the maximum, minimum, average, and total values of metrics.
Combined monitoring of multiple metrics: You can monitor multiple metrics (currently, up to two metrics)
with a single rule. An alert is triggered if both metrics breach their respective thresholds for the specified time-
period.
Better notification system: All newer alerts use action groups, which are named groups of notifications and
actions that can be reused in multiple alerts. Classic metric alerts and older Log Analytics alerts do not use
action groups.
Metrics from Logs (public preview ): Log data going into Log Analytics can now be extracted and converted
into Azure Monitor metrics and then alerted on just like other metrics. See Alerts (classic) for the terminology
specific to classic alerts.
Classic alerts on Azure Monitor data

There are two types of classic alerts available - metric alerts and activity log alerts.
Classic metric alerts - This alert triggers when the value of a specified metric crosses a threshold that you
assign. The alert generates a notification when that threshold is crossed and the alert condition is met. At
that point, the alert is considered "Activated". It generates another notification when it is "Resolved" - that
is, when the threshold is crossed again and the condition is no longer met.
Classic activity log alerts - A streaming log alert that triggers on an Activity Log event entry that
matches your filter criteria. These alerts have only one state, "Activated". The alert engine simply applies
the filter criteria to any new event. It does not search to find older entries. These alerts can notify you when
a new Service Health incident occurs or when a user or application performs an operation in your
subscription, for example, "Delete virtual machine."
For Diagnostic Log data available through Azure Monitor, route the data into Log Analytics (formerly OMS ) and
use a Log Analytics query alert. Log Analytics now uses the new alerting method
The following diagram summarizes sources of data in Azure Monitor and, conceptually, how you can alert off of
that data.
Taxonomy of alerts (classic)
Azure uses the following terms to describe classic alerts and their functions:
Alert - a definition of criteria (one or more rules or conditions) that becomes activated when met.
Active - the state when the criteria defined by a classic alert is met.
Resolved - the state when the criteria defined by a classic alert is no longer met after previously having been
met.
Notification - the action taken based off of a classic alert becoming active.
Action - a specific call sent to a receiver of a notification (for example, emailing an address or posting to a
webhook URL ). Notifications can usually trigger multiple actions.
How do I receive a notification from an Azure Monitor classic alert?

Historically, Azure alerts from different services used their own built-in notification methods.
Azure Monitor created a reusable notification grouping called action groups. Action groups specify a set of
receivers for a notification. Any time an alert is activated that references the Action Group, all receivers receive
that notification. Action groups allow you to reuse a grouping of receivers (for example, your on-call engineer list)
across many alert objects. Action groups support notification by posting to a webhook URL in addition to email
addresses, SMS numbers, and a number of other actions. For more information, see action groups.
Older classic Activity Log alerts use action groups.
However, the older metric alerts do not use action groups. Instead, you can configure the following actions:
Send email notifications to the service administrator, to coadministrators, or to additional email addresses that
you specify.
Call a webhook, which enables you to launch additional automation actions.
Webhooks enables automation and remediation, for example, using:
Azure Automation Runbook
Azure Function
Azure Logic App
a third-party service
Next steps
Get information about alert rules and configuring them by using:
Learn more about Metrics
Configure classic Metric Alerts via Azure portal
Configure classic Metric Alerts PowerShell
Configure classic Metric Alerts Command-line interface (CLI)
Configure classic Metric Alerts Azure Monitor REST API
Learn more about Activity Log
Configure Activity Log Alerts via Azure portal
Configure Activity Log Alerts via Resource Manager
Review the activity log alert webhook schema
Learn more about Action groups
Configure newer Alerts
Prepare your logic apps and runbooks for migration
of classic alert rules
As previously announced, classic alerts in Azure Monitor are being retired in September 2019 (was originally July
2019). A migration tool is available in the Azure portal to customers who use classic alert rules and who want to
trigger migration themselves.
NOTE
Due to delay in roll-out of migration tool, the retirement date for classic alerts migration has been extended to August 31st,
2019 from the originally announced date of June 30th, 2019.
If you choose to voluntarily migrate your classic alert rules to new alert rules, be aware that there are some
differences between the two systems. This article explains those differences and how you can prepare for the
change.
API changes
The APIs that create and manage classic alert rules ( microsoft.insights/alertrules ) are different from the APIs
that create and manage new metric alerts ( microsoft.insights/metricalerts ). If you programmatically create and
manage classic alert rules today, update your deployment scripts to work with the new APIs.
The following table is a reference to the programmatic interfaces for both classic and new alerts:
CLASSIC ALERTS NEW METRIC ALERTS
REST API microsoft.insights/alertrules microsoft.insights/metricalerts
Azure CLI az monitor alert az monitor metrics alert
PowerShell Reference Reference
Azure Resource Manager template For classic alerts For new metric alerts
Notification payload changes

The notification payload format is slightly different between classic alert rules and new metric alerts. If you have
any webhook, logic app, or runbook actions that are triggered by classic alert rules, you must update those
notification endpoints to accept the payload format of new metric alerts.
Use the following table to map the webhook payload fields from the classic format to the new format:
Was the alert activated or resolved? status data.status
Contextual information about the alert context data.context

Time stamp at which the alert was context.timestamp data.context.timestamp

activated or resolved
Alert rule ID context.id data.context.id
Alert rule name context.name data.context.name
Description of the alert rule context.description data.context.description
Alert rule condition context.condition data.context.condition
Metric name context.condition.metricName data.context.condition.allOf[0].metr

icName
Time aggregation (how the metric is context.condition.timeAggregation context.condition.timeAggregation

aggregated over the evaluation
window)
Evaluation period context.condition.windowSize data.context.condition.windowSize
Operator (how the aggregated metric context.condition.operator data.context.condition.operator

value is compared against the
threshold)
Threshold context.condition.threshold data.context.condition.allOf[0].thres

hold
Metric value context.condition.metricValue data.context.condition.allOf[0].metr

icValue
Subscription ID context.subscriptionId data.context.subscriptionId
Resource group of the affected resource context.resourceGroup data.context.resourceGroup
Name of the affected resource context.resourceName data.context.resourceName
Type of the affected resource context.resourceType data.context.resourceType
Resource ID of the affected resource context.resourceId data.context.resourceId
Direct link to the portal resource context.portalLink data.context.portalLink

summary page
Custom payload fields to be passed to properties data.properties

the webhook or logic app
The payloads are similar, as you can see. The following section offers:
Details about modifying logic apps to work with the new format.
A runbook example that parses the notification payload for new alerts.
Modify a logic app to receive a metric alert notification

If you're using logic apps with classic alerts, you must modify your logic-app code to parse the new metric alerts
payload. Follow these steps:
1. Create a new logic app.
2. Use the template "Azure Monitor - Metrics Alert Handler". This template has an HTTP request trigger with
the appropriate schema defined.
3. Add an action to host your processing logic.
Use an automation runbook that receives a metric alert notification

The following example provides PowerShell code to use in your runbook. This code can parse the payloads for
both classic metric alert rules and new metric alert rules.
## Example PowerShell code to use in a runbook to handle parsing of both classic and new metric alerts.
[OutputType("PSAzureOperationResponse")]
param
(
[Parameter (Mandatory=$false)]
[object] $WebhookData
)
$ErrorActionPreference = "stop"
if ($WebhookData)
{
# Get the data object from WebhookData.
$WebhookBody = (ConvertFrom-Json -InputObject $WebhookData.RequestBody)
# Determine whether the alert triggering the runbook is a classic metric alert or a new metric alert
(depends on the payload schema).
$schemaId = $WebhookBody.schemaId
Write-Verbose "schemaId: $schemaId" -Verbose
if ($schemaId -eq "AzureMonitorMetricAlert") {
# This is the new metric alert schema.

$AlertContext = [object] ($WebhookBody.data).context
$status = ($WebhookBody.data).status
# Parse fields related to alert rule condition.

$metricName = $AlertContext.condition.allOf[0].metricName
$metricValue = $AlertContext.condition.allOf[0].metricValue
$threshold = $AlertContext.condition.allOf[0].threshold
$timeAggregation = $AlertContext.condition.allOf[0].timeAggregation
}
elseif ($schemaId -eq $null) {
# This is the classic metric alert schema.
$AlertContext = [object] $WebhookBody.context
$status = $WebhookBody.status
# Parse fields related to alert rule condition.

$metricName = $AlertContext.condition.metricName
$metricValue = $AlertContext.condition.metricValue
$threshold = $AlertContext.condition.threshold
$timeAggregation = $AlertContext.condition.timeAggregation
}
else {
# The schema is neither a classic metric alert nor a new metric alert.
Write-Error "The alert data schema - $schemaId - is not supported."
}
# Parse fields related to resource affected.

$ResourceName = $AlertContext.resourceName
$ResourceType = $AlertContext.resourceType
$ResourceGroupName = $AlertContext.resourceGroupName
$ResourceId = $AlertContext.resourceId
$SubId = $AlertContext.subscriptionId
## Your logic to handle the alert here.

}
else {
# Error
Write-Error "This runbook is meant to be started from an Azure alert webhook only."
}
For a full example of a runbook that stops a virtual machine when an alert is triggered, see the Azure Automation
documentation.
Partner integration via webhooks
Most of our partners that integrate with classic alerts already support newer metric alerts through their
integrations. Known integrations that already work with new metric alerts are:
PagerDuty
OpsGenie
Signl4
If you're using a partner integration that's not listed here, confirm with the integration provider that the integration
works with new metric alerts.
Next steps
How to use the migration tool
Understand how the migration tool works
As previously announced, classic alerts in Azure Monitor are being retired by August 31, 2019 (was originally June
30, 2019). A migration tool is available in the Azure portal to customers who use classic alert rules and who want
to trigger migration themselves.
This article explains how the voluntary migration tool works. It also describes remedies for some common
problems.
NOTE
Classic alert rules that will not be migrated

IMPORTANT
Activity log alerts (including Service health alerts) and Log alerts are not impacted by the migration. The migration only
applies to classic alert rules described here.
Although the tool can migrate almost all classic alert rules, there are some exceptions. The following alert rules
won't be migrated by using the tool (or during the automatic migration starting September 2019):
Classic alert rules on virtual-machine guest metrics (both Windows and Linux). See the guidance for recreating
such alert rules in new metric alerts later in this article.
Classic alert rules on classic storage metrics. See the guidance for monitoring your classic storage accounts.
Classic alert rules on some storage account metrics. See details later in this article.
Classic alert rules on some Cosmos DB metrics. See details later in this article.
Classic alert rules on all classic virtual machines and cloud services metrics
(Microsoft.ClassicCompute/virtualMachines and Microsoft.ClassicCompute/domainNames/slots/roles). See
details later in this article.
If your subscription has any such classic rules, you must migrate them manually. Because we can't provide an
automatic migration, any existing, classic metric alerts of these types will continue to work until June 2020. This
extension gives you time to move over to new alerts. You can also continue to create new classic alerts on the
above listed exceptions till June 2020. However for everything else, no new classic alerts can be created after
August 2019.
NOTE
Besides the above listed exceptions, if your classic alert rules are invalid i.e. they are on deprecated metrics or resources that
have been deleted, they will not be migrated during voluntary migration. Any such invalid classic alert rules will be deleted
when automatic migration happens.
Guest metrics on virtual machines

Before you can create new metric alerts on guest metrics, the guest metrics must be sent to the Azure Monitor
custom metrics store. Follow these instructions to enable the Azure Monitor sink in diagnostic settings:
Enabling guest metrics for Windows VMs
Enabling guest metrics for Linux VMs
After these steps are done, you can create new metric alerts on guest metrics. And after you have created new
metric alerts, you can delete classic alerts.
Storage account metrics
All classic alerts on storage accounts can be migrated except alerts on these metrics:
PercentAuthorizationError
PercentClientOtherError
PercentNetworkError
PercentServerOtherError
PercentSuccess
PercentThrottlingError
PercentTimeoutError
AnonymousThrottlingError
SASThrottlingError
ThrottlingError
Classic alert rules on Percent metrics must be migrated based on the mapping between old and new storage
metrics. Thresholds will need to be modified appropriately because the new metric available is an absolute one.
Classic alert rules on AnonymousThrottlingError, SASThrottlingError and ThrottlingError must be split into two
new alerts because there is no combined metric that provides the same functionality. Thresholds will need to be
adapted appropriately.
Cosmos DB metrics
All classic alerts on Cosmos DB metrics can be migrated except alerts on these metrics:
Average Requests per Second
Consistency Level
Http 2xx
Http 3xx
Http 400
Http 401
Internal Server Error
Max RUPM Consumed Per Minute
Max RUs Per Second
Mongo Count Failed Requests
Mongo Delete Failed Requests
Mongo Insert Failed Requests
Mongo Other Failed Requests
Mongo Other Request Charge
Mongo Other Request Rate
Mongo Query Failed Requests
Mongo Update Failed Requests
Observed Read Latency
Observed Write Latency
Service Availability
Storage Capacity
Throttled Requests
Total Requests
Average Requests per Second, Consistency Level, Max RUPM Consumed Per Minute, Max RUs Per Second,
Observed Read Latency, Observed Write Latency, Storage Capacity are not currently available in the new system.
Alerts on request metrics like Http 2xx, Http 3xx, Http 400, Http 401, Internal Server Error, Service Availability,
Throttled Requests and Total Requests are not migrated because the way requests are counted is different between
classic metrics and new metrics. Alerts on these will need to be manually recreated with thresholds adjusted.
Alerts on Mongo Failed Requests metrics must be split into multiple alerts because there is no combined metric
that provides the same functionality. Thresholds will need to be adapted appropriately.
Classic compute metrics
Any alerts on classic compute metrics will not be migrated using the migration tool as classic compute resources
are not yet supported with new alerts. Support for new alerts on these resource types will be added in future.
Once that is available, customers must recreate new equivalent alert rules based on their classic alert rules before
June 2020.
Classic alert rules on deprecated metrics
These are classic alert rules on metrics which were previously supported but were eventually deprecated. A small
percentage of customer might have invalid classic alert rules on such metrics. Since these alert rules are invalid,
they won't be migrated.
RESOURCE TYPE DEPRECATED METRIC(S)
Microsoft.DBforMySQL/servers compute_consumption_percent, compute_limit
Microsoft.DBforPostgreSQL/servers compute_consumption_percent, compute_limit
Microsoft.Network/publicIPAddresses defaultddostriggerrate
Microsoft.SQL/servers/databases service_level_objective, storage_limit, storage_used, throttling,

dtu_consumption_percent, storage_used
Microsoft.Web/hostingEnvironments/multirolepools averagememoryworkingset
Microsoft.Web/hostingEnvironments/workerpools bytesreceived, httpqueuelength
How equivalent new alert rules and action groups are created
The migration tool converts your classic alert rules to equivalent new alert rules and action groups. For most
classic alert rules, equivalent new alert rules are on the same metric with the same properties such as windowSize
and aggregationType . However, there are some classic alert rules are on metrics that have a different, equivalent
metric in the new system. The following principles apply to the migration of classic alerts unless specified in the
section below:
Frequency: Defines how often a classic or new alert rule checks for the condition. The frequency in classic
alert rules was not configurable by the user and was always 5 mins for all resource types except Application
Insights components for which it was 1 min. So frequency of equivalent rules is also set to 5 min and 1 min
respectively.
Aggregation Type: Defines how the metric is aggregated over the window of interest. The aggregationType is
also the same between classic alerts and new alerts for most metrics. In some cases, since the metric is different
between classic alerts and new alerts, equivalent aggregationType or the primary Aggregation Type defined for
the metric is used.
Units: Property of the metric on which alert is created. Some equivalent metrics have different units. The
threshold is adjusted appropriately as needed. For example, if the original metric has seconds as units but
equivalent new metric has milliSeconds as units, the original threshold is multiplied by 1000 to ensure same
behavior.
Window Size: Defines the window over which metric data is aggregated to compare against the threshold. For
standard windowSize values like 5mins, 15mins, 30mins, 1hour, 3hours, 6 hours, 12 hours, 1 day, there is no
change made for equivalent new alert rule. For other values, the closest windowSize is chosen to be used. For
most customers, there is no impact with this change. For a small percentage of customers, there might be a
need to tweak the threshold to get exact same behavior.
In the following sections, we detail the metrics that have a different, equivalent metric in the new system. Any
metric that remains the same for classic and new alert rules is not listed. You can find a list of metrics supported in
the new system here.
Microsoft.StorageAccounts/services
For Storage account services like blob, table, file and queue, the following metrics are mapped to equivalent
metrics as shown below:
METRIC IN CLASSIC ALERTS EQUIVALENT METRIC IN NEW ALERTS COMMENTS
AnonymousAuthorizationError Transactions metric with dimensions

"ResponseType"="AuthorizationError"
and "Authentication" = "Anonymous"
AnonymousClientOtherError Transactions metric with dimensions

"ResponseType"="ClientOtherError" and
"Authentication" = "Anonymous"
AnonymousClientTimeOutError Transactions metric with dimensions

"ResponseType"="ClientTimeOutError"
AnonymousNetworkError Transactions metric with dimensions

"ResponseType"="NetworkError" and
AnonymousServerOtherError Transactions metric with dimensions

"ResponseType"="ServerOtherError"
AnonymousServerTimeOutError Transactions metric with dimensions

"ResponseType"="ServerTimeOutError"
AnonymousSuccess Transactions metric with dimensions

"ResponseType"="Success" and
AuthorizationError Transactions metric with dimensions

AverageE2ELatency SuccessE2ELatency
AverageServerLatency SuccessServerLatency
Capacity BlobCapacity Use aggregationType 'average'

instead of 'last'. Metric only applies to
Blob services
ClientOtherError Transactions metric with dimensions

"ResponseType"="ClientOtherError"
ClientTimeoutError Transactions metric with dimensions

ContainerCount ContainerCount Use aggregationType 'average'

Blob services
NetworkError Transactions metric with dimensions

"ResponseType"="NetworkError"
ObjectCount BlobCount Use aggregationType 'average'

Blob services
SASAuthorizationError Transactions metric with dimensions

and "Authentication" = "SAS"
SASClientOtherError Transactions metric with dimensions

"ResponseType"="ClientOtherError" and
"Authentication" = "SAS"
SASClientTimeOutError Transactions metric with dimensions

SASNetworkError Transactions metric with dimensions

"ResponseType"="NetworkError" and
SASServerOtherError Transactions metric with dimensions

SASServerTimeOutError Transactions metric with dimensions

SASSuccess Transactions metric with dimensions

"ResponseType"="Success" and
ServerOtherError Transactions metric with dimensions

ServerTimeOutError Transactions metric with dimensions

Success Transactions metric with dimensions

"ResponseType"="Success"
TotalBillableRequests Transactions
TotalEgress Egress
TotalIngress Ingress
TotalRequests Transactions
Microsoft.insights/components
For Application Insights, equivalent metrics are as shown below:
availability.availabilityMetric.value availabilityResults/availabilityPercentage
availability.durationMetric.value availabilityResults/duration Multiply original threshold by 1000 as

units for classic metric are in seconds
and for new one are in milliSeconds.
basicExceptionBrowser.count exceptions/browser Use aggregationType 'count' instead

of 'sum'.
basicExceptionServer.count exceptions/server Use aggregationType 'count' instead

of 'sum'.
clientPerformance.clientProcess.value browserTimings/processingDuration Multiply original threshold by 1000 as

clientPerformance.networkConnection.v browserTimings/networkDuration Multiply original threshold by 1000 as

alue units for classic metric are in seconds
clientPerformance.receiveRequest.value browserTimings/receiveDuration Multiply original threshold by 1000 as

clientPerformance.sendRequest.value browserTimings/sendDuration Multiply original threshold by 1000 as

clientPerformance.total.value browserTimings/totalDuration Multiply original threshold by 1000 as

performanceCounter.available_bytes.val performanceCounters/memoryAvailable
ue Bytes
performanceCounter.io_data_bytes_per performanceCounters/processIOBytesP
_sec.value erSecond
performanceCounter.number_of_exceps performanceCounters/exceptionsPerSec
_thrown_per_sec.value ond
performanceCounter.percentage_proces performanceCounters/processCpuPerce
sor_time_normalized.value ntage
performanceCounter.percentage_proces performanceCounters/processCpuPerce Threshold will need to be appropriately

sor_time.value ntage modified as original metric was across
all cores and new metric is normalized
to one core. Migration tool doesn't
change thresholds.
performanceCounter.percentage_proces performanceCounters/processorCpuPer
sor_total.value centage
performanceCounter.process_private_b performanceCounters/processPrivateBy
ytes.value tes
performanceCounter.request_execution performanceCounters/requestExecution
_time.value Time
performanceCounter.requests_in_applic performanceCounters/requestsInQueue
ation_queue.value
performanceCounter.requests_per_sec.v performanceCounters/requestsPerSeco
alue nd
request.duration requests/duration Multiply original threshold by 1000 as

request.rate requests/rate
requestFailed.count requests/failed Use aggregationType 'count' instead

of 'sum'.
view.count pageViews/count Use aggregationType 'count' instead

of 'sum'.
Microsoft.DocumentDB/databaseAccounts
For Cosmos DB, equivalent metrics are as shown below:
AvailableStorage AvailableStorage
Data Size DataUsage
Document Count DocumentCount

Index Size IndexUsage
Mongo Count Request Charge MongoRequestCharge with dimension

"CommandName" = "count"
Mongo Count Request Rate MongoRequestsCount with dimension

"CommandName" = "count"
Mongo Delete Request Charge MongoRequestCharge with dimension

"CommandName" = "delete"
Mongo Delete Request Rate MongoRequestsCount with dimension

"CommandName" = "delete"
Mongo Insert Request Charge MongoRequestCharge with dimension

"CommandName" = "insert"
Mongo Insert Request Rate MongoRequestsCount with dimension

"CommandName" = "insert"
Mongo Query Request Charge MongoRequestCharge with dimension

"CommandName" = "find"
Mongo Query Request Rate MongoRequestsCount with dimension

"CommandName" = "find"
Mongo Update Request Charge MongoRequestCharge with dimension

"CommandName" = "update"
Service Unavailable ServiceAvailability
TotalRequestUnits TotalRequestUnits
How equivalent action groups are created

Classic alert rules had email, webhook, logic app and runbook actions tied to the alert rule itself. New alert rules
use action groups which can be reused across multiple alert rules. The migration tool creates single action group
for same actions irrespective of how many alert rules are using the action. Action groups created by the migration
tool use the naming format 'Migrated_AG*'.
NOTE
Classic alerts sent localized emails based on the locale of classic administrator when used to notify classic administrator roles.
New alert emails are sent via Action Groups and are only in English.
Rollout phases
The migration tool is rolling out in phases to customers that use classic alert rules. Subscription owners will
receive an email when the subscription is ready to be migrated by using the tool.
NOTE
Because the tool is being rolled out in phases, you might see that some of your subscriptions are not yet ready to be
migrated during the early phases.
Most of the subscriptions are currently marked as ready for migration. Only subscriptions that have classic alerts
on following resource types are still not ready for migration.
Microsoft.classicCompute/domainNames/slots/roles
Microsoft.insights/components
Who can trigger the migration?

Any user who has the built-in role of Monitoring Contributor at the subscription level can trigger the migration.
Users who have a custom role with the following permissions can also trigger the migration:
*/read
Microsoft.Insights/actiongroups/*
Microsoft.Insights/AlertRules/*
Microsoft.Insights/metricAlerts/*
Microsoft.AlertsManagement/smartDetectorAlertRules/*
NOTE
In addition to having above permissions, your subscription should additionally be registered with
Microsoft.AlertsManagement resource provider. This is required to successfully migrate Failure Anomaly alerts on Application
Insights.
Common problems and remedies

After you trigger the migration, you'll receive email at the addresses you provided to notify you that migration is
complete or if any action is needed from you. This section describes some common problems and how to deal
with them.
Validation failed
Due to some recent changes to classic alert rules in your subscription, the subscription cannot be migrated. This
problem is temporary. You can restart the migration after the migration status moves back Ready for migration
in a few days.
Scope lock preventing us from migrating your rules
As part of the migration, new metric alerts and new action groups will be created, and then classic alert rules will
be deleted. However, a scope lock can prevent us from creating or deleting resources. Depending on the scope
lock, some or all rules could not be migrated. You can resolve this problem by removing the scope lock for the
subscription, resource group, or resource, which is listed in the migration tool, and triggering the migration again.
Scope lock can't be disabled and must be removed for the duration of the migration process. Learn more about
managing scope locks.
Policy with 'Deny' effect preventing us from migrating your rules
As part of the migration, new metric alerts and new action groups will be created, and then classic alert rules will
be deleted. However, a policy can prevent us from creating resources. Depending on the policy, some or all rules
could not be migrated. The policies that are blocking the process are listed in the migration tool. Resolve this
problem by either:
Excluding the subscriptions, or resource groups for the duration of the migration process from the policy
assignment. Learn more about managing policies exclusion scope.
Removing or changing effect to 'audit' or 'append' (which, for example, can solve issues relating to missing
tags). Learn more about managing policies effect.
Next steps
Prepare for the migration
Use the voluntary migration tool to migrate your
classic alert rules
2019). A migration tool is available in the Azure portal to customers who use classic alert rules and who want to
trigger migration themselves. This article explains how to use the migration tool to voluntarily migrate your
classic alert rules before the automatic migration starts in September 2019.
NOTE
Benefits of new alerts

Classic alerts are being replaced by new, unified alerting in Azure Monitor. The new alerts platform has the
following benefits:
You can alert on a variety of multidimensional metrics for many more Azure services.
The new metric alerts support multi-resource alert rules that greatly reduce the overhead of managing many
rules.
The unified notification mechanism, which supports:
Action groups, a modular notification mechanism that works with all new alert types (metric, log, and
activity log).
New notification mechanisms like SMS, voice, and ITSM Connector.
The unified alert experience brings all the alerts on different signals (metric, log, and activity log) into one
place.
Before you migrate

The migration process converts classic alert rules to new, equivalent alert rules, and creates action groups. In
preparation, be aware of the following points:
Both the notification payload format and the APIs to create and manage new alert rules are different from
those of the classic alert rules because they support more features. Learn how to prepare for the migration.
Some classic alert rules cannot be migrated by using the tool. Learn which rules cannot be migrated and
what to do with them.
NOTE
The migration process won't impact the evaluation of your classic alert rules. They'll continue to run and send alerts
until they're migrated and the new alert rules take effect.

To trigger the migration of your classic alert rules in the Azure portal, follow these steps:
1. In Azure portal, select Monitor.
2. Select Alerts, and then select Manage alert rules or View classic alerts.
3. Select Migrate to new rules to go to the migration landing page. This page shows a list of all your
subscriptions and their migration status:
All subscriptions that can be migrated by using the tool are marked as Ready to migrate.
NOTE
The migration tool is rolling out in phases to all the subscriptions that use classic alert rules. In the early phases of
the rollout, you might see some subscriptions marked as not ready for migration.
4. Select one or more subscriptions, and then select Preview migration.

The resulting page shows the details of classic alert rules that will be migrated for one subscription at a
time. You can also select Download the migration details for this subscription to get the details in a
CSV format.
5. Specify one or more email addresses to be notified of migration status. You'll receive email when the
migration is complete or if any action is needed from you.
6. Select Start Migration. Read the information shown in the confirmation dialog box and confirm that
you're ready to start the migration process.
IMPORTANT
After you initiate migration for a subscription, you won't be able to edit or create classic alert rules for that
subscription. This restriction ensures that no changes to your classic alert rules are lost during migration to the new
rules. Although you won't be able to change your classic alert rules, they'll still continue to run and to provide alerts
until they've been migrated. After the migration is complete for your subscription, you can't use classic alert rules
anymore.
7. When migration is complete, or if action is required from you, you'll receive an email at the addresses that
you provided earlier. You can also periodically check the status at the migration landing page in the portal.
Why is my subscription listed as not ready for migration?
The migration tool is rolling out to customers in phases. In the early phases, most or all of your subscriptions
might be marked as Not ready for migration.
When a subscription becomes ready for migration, the subscription owner will receive an email message stating
that the tool is available. Keep an eye out for this message.
Who can trigger the migration?
Users who have the Monitoring Contributor role assigned to them at the subscription level are able to trigger the
migration. Learn more about Role-Based Access Control for the migration process.
How long will the migration take?
Migration is completed for most subscriptions in under an hour. You can keep track of the migration progress on
the migration landing page. During the migration, be assured that your alerts are still running either in the classic
alerts system or in the new one.
What can I do if I run into a problem during migration?
See the troubleshooting guide for help with problems you might face during migration. If any action is needed
from you to complete the migration, you'll be notified at the email addresses you provided when you set up the
tool.
Next steps
Understand the automatic migration process for your
classic alert rules
2019). As part of the retirement process, a migration tool is available in the Azure portal for customers to trigger
migration themselves. If you haven't used the migration tool by August 31, 2019, Azure Monitor will start the
process of automatic migration of your classic alerts starting September 1, 2019. This article walks you through
the the automatic migration process and help you resolve any issues you might run into.
NOTE
This article only applies to Azure public cloud. Retirement process for Azure Monitor classic alerts in Azure Government cloud
and Azure China 21Vianet will be announced at future date.
What will happen during the automatic migration process?

Starting September 1, 2019, customers won't be able to create any new classic alert rules except on certain
metrics.
For the exceptions, customer can continue to create new classic alert rules and use their classic alerts
until June 2020.
Starting September 1, 2019, migration of classic alerts will be triggered in batches for any customers that
have classic alerts.
As with the voluntary migration tool, certain classic alert rules that aren't migratable will be left as they are.
These classic alert rules will continue to be supported until June 2020. However, any invalid classic alert
rules will be deleted as they're non-functional. Any classic alert rules that are monitoring deleted target
resources or on metrics that are no longer supported are considered invalid.
Once migration for your subscription starts, unless there are any issues, migration should be complete
within an hour. Customers can monitor the status of migration on the migration blade in Azure Monitor.
Subscription owners will receive an email on successful completion of migration.
If there are any issues during the migration, subscription owners will also receive an email informing them
of the same. Customers can use the migration blade to see full details of the issue.
In case an action is needed from customer like temporarily disabling a resource lock or changing a policy
assignment, customers will need to resolve any issues by October 31, 2019. If the issues are not resolved by
then, successful migration of your classic alerts can't be guaranteed.
NOTE
If you don't want to wait for the automatic migration process to start, you can still trigger the migration voluntarily
using the migration tool.
Important things to note

The migration process converts classic alert rules to new, equivalent alert rules, and creates action groups. In
preparation, be aware of the following points:
The notification payload formats for new alert rules are different from those of the classic alert rules
because they support more features. If you have logic apps, runbooks or webhooks that are triggered by
classic alert rule they might stop functioning as expected once migration is complete because of differences
in notification payloads. Learn how to prepare for the migration.
Some classic alert rules can't be migrated by using the tool. Learn which rules can't be migrated and what to
do with them.
NOTE
The migration process won't impact the evaluation of your classic alert rules. They'll continue to run and send alerts
until they're migrated and the new alert rules take effect.
What if the automatic migration fails?

When the automatic migration process fails, subscription owners will receive an email notifying them of the issue.
You can use the migration blade in Azure Monitor to see the full details of the issue.
See the troubleshooting guide for help with problems you might face during migration.
NOTE
In case an action is needed from customer like temporarily disabling a resource lock or changing a policy assignment,
customers will need to resolve any issues by October 31, 2019. If the issues are not resolved by then, successful migration of
your classic alerts cannot be guaranteed.
Next steps
Create, view, and manage classic metric alerts using
Azure Monitor
Classic metric alerts in Azure Monitor provide a way to get notified when one of your metrics cross a threshold.
Classic metric alerts is an older functionality that allows for alerting only on non-dimensional metrics. There is an
existing newer functionality called Metric alerts which has improved functionality over classic metric alerts. You
can learn more about the new metric alerts functionality in metric alerts overview. In this article, we will describe
how to create, view and manage classic metric alert rules through Azure portal, Azure CLI and Powershell.
With Azure portal

1. In the portal, locate the resource that you want to monitor, and then select it.
2. In the MONITORING section, select Alerts (Classic). The text and icon might vary slightly for different
resources. If you don't find Alerts (Classic) here, you might find it in Alerts or Alert Rules.
3. Select the Add metric alert (classic) command, and then fill in the fields.
4. Name your alert rule. Then choose a Description, which also appears in notification emails.
5. Select the Metric that you want to monitor. Then choose a Condition and Threshold value for the metric.
Also choose the Period of time that the metric rule must be satisfied before the alert triggers. For example,
if you use the period "Over the last 5 minutes" and your alert looks for a CPU above 80%, the alert triggers
when the CPU has been consistently above 80% for 5 minutes. After the first trigger occurs, it triggers
again when the CPU stays below 80% for 5 minutes. The CPU metric measurement happens every minute.
6. Select Email owners... if you want administrators and co-administrators to receive email notifications
when the alert fires.
7. If you want to send notifications to additional email addresses when the alert fires, add them in the
Additional Administrator email(s) field. Separate multiple emails with semicolons, in the following
format: email@contoso.com;email2@contoso.com
8. Put in a valid URI in the Webhook field if you want it to be called when the alert fires.
9. If you use Azure Automation, you can select a runbook to be run when the alert fires.
10. Select OK to create the alert.
Within a few minutes, the alert is active and triggers as previously described.
After you create an alert, you can select it and do one of the following tasks:
View a graph that shows the metric threshold and the actual values from the previous day.
Edit or delete it.
Disable or Enable it if you want to temporarily stop or resume receiving notifications for that alert.
With Azure CLI

The previous sections described how to create, view and manage metric alert rules using Azure portal. This
section will describe how to do the same using cross-platform Azure CLI. Quickest way to start using Azure CLI is
through Azure Cloud Shell.
Get all classic metric alert rules in a resource group
az monitor alert list --resource-group <group name>
See details of a particular classic metric alert rule
az monitor alert show --resource-group <group name> --name <alert name>
Create a classic metric alert rule
az monitor alert create --name <alert name> --resource-group <group name> \

--action email <email1 email2 ...> \
--action webhook <URI> \
--target <target object ID> \
--condition "<METRIC> {>,>=,<,<=} <THRESHOLD> {avg,min,max,total,last} ##h##m##s"
Delete a classic metric alert rule
az monitor alert delete --name <alert name> --resource-group <group name>
With PowerShell
NOTE
PowerShell.
This sections shows how to use PowerShell commands create, view and manage classic metric alerts.The
examples in the article illustrate how you can use Azure Monitor cmdlets for classic metric alerts.
1. If you haven't already, set up PowerShell to run on your computer. For more information, seeHow to
Install and Configure PowerShell. You can also review the entire list of Azure Monitor PowerShell cmdlets
at Azure Monitor (Insights) Cmdlets.
2. First, log in to your Azure subscription.
Connect-AzAccount
3. You'll see a sign in screen. Once you sign in your Account, TenantID, and default Subscription ID are
displayed. All the Azure cmdlets work in the context of your default subscription. To view the list of
subscriptions you have access to, use the following command:
Get-AzSubscription
4. To change your working context to a different subscription, use the following command:
Set-AzContext -SubscriptionId <subscriptionid>
5. You can retrieve all classic metric alert rules on a resource group:
Get-AzAlertRule -ResourceGroup montest
6. You can view details of a classic metric alert rule
Get-AzAlertRule -Name simpletestCPU -ResourceGroup montest -DetailedOutput
7. You can retrieve all alert rules set for a target resource. For example, all alert rules set on a VM.
Get-AzAlertRule -ResourceGroup montest -TargetResourceId

/subscriptions/s1/resourceGroups/montest/providers/Microsoft.Compute/virtualMachines/testconfig
8. Classic alert rules can no longer be created via PowerShell. To create an alert rule you need to use the new
'Add-AzMetricAlertRule' command.
Next steps
Create a classic metric alert with a Resource Manager template.
Have a classic metric alert notify a non-Azure system using a webhook.
Create a classic metric alert with a Resource Manager
template
This article shows how you can use an Azure Resource Manager template to configure Azure metric alerts. This
enables you to automatically set up alerts on your resources when they are created to ensure that all resources are
monitored correctly.
NOTE
This article describes creating classic metric alerts using Resource Manager templates. If you are looking for creating newer
metric alerts using templates, this article provides the details.
The basic steps are as follows:

1. Create a template as a JSON file that describes how to create the alert.
2. Deploy the template using any deployment method.
Below we describe how to create a Resource Manager template first for an alert alone, then for an alert during the
creation of another resource.
Resource Manager template for a classic metric alert

Microsoft.Insights/alertRules and fill in all related properties. Below is a template that creates an alert rule.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
"description": "Name of alert"
}
},
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
"description": "Specifies whether alerts are enabled"
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
comparison."
}
},
"metricName": {
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"aggregation": {
"type": "string",
"allowedValues": [
"Average",
"Last",
"Maximum",
"Minimum",
"Total"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"metadata": {
}
},
"sendToServiceOwners": {
"type": "bool",
"metadata": {
"description": "Specifies whether alerts are sent to service owners"
}
},
"customEmailAddresses": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Comma-delimited email addresses where the alerts are also sent"
}
},
"webhookUrl": {
"type": "string",
"defaultValue": "",
"metadata": {
"metadata": {
"description": "URL of a webhook that will receive an HTTP POST when the alert activates."
}
}
},
"variables": {
"customEmails": "[split(parameters('customEmailAddresses'), ',')]"
},
"resources": [
{
"type": "Microsoft.Insights/alertRules",
"apiVersion": "2016-03-01",
"properties": {
"isEnabled": "[parameters('isEnabled')]",
"condition": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
"dataSource": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
"resourceUri": "[parameters('resourceId')]",
"metricName": "[parameters('metricName')]"
},
"threshold": "[parameters('threshold')]",
"timeAggregation": "[parameters('aggregation')]"
},
"actions": [
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
"sendToServiceOwners": "[parameters('sendToServiceOwners')]",
"customEmails": "[variables('customEmails')]"
},
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleWebhookAction",
"serviceUri": "[parameters('webhookUrl')]",
"properties": {}
}
]
}
}
]
}
Resource Manager template for a resource with a classic metric alert

An alert on a Resource Manager template is most often useful when creating an alert while creating a resource.
For example, you may want to ensure that a “CPU % > 80” rule is set up every time you deploy a Virtual Machine.
To do this, you add the alert rule as a resource in the resource array for your VM template and add a dependency
using the dependsOn property to the VM resource ID. Here’s a full example that creates a Windows VM and adds
an alert that notifies subscription admins when the CPU utilization goes above 80%.
{
"parameters": {
"newStorageAccountName": {
"type": "string",
"metadata": {
"Description": "The name of the storage account where the VM disk is stored."
}
},
"adminUsername": {
"type": "string",
"metadata": {
"Description": "The name of the administrator account on the VM."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"Description": "The administrator account password on the VM."
}
},
"dnsNameForPublicIP": {
"type": "string",
"metadata": {
"Description": "The name of the public IP address used to access the VM."
}
}
},
"variables": {
"location": "Central US",
"imagePublisher": "MicrosoftWindowsServer",
"imageOffer": "WindowsServer",
"windowsOSVersion": "2012-R2-Datacenter",
"OSDiskName": "osdisk1",
"nicName": "nc1",
"addressPrefix": "10.0.0.0/16",
"subnetName": "sn1",
"subnetPrefix": "10.0.0.0/24",
"storageAccountType": "Standard_LRS",
"publicIPAddressName": "ip1",
"publicIPAddressType": "Dynamic",
"vmStorageAccountContainerName": "vhds",
"vmName": "vm1",
"vmSize": "Standard_A0",
"virtualNetworkName": "vn1",
"vnetID": "[resourceId('Microsoft.Network/virtualNetworks',variables('virtualNetworkName'))]",
"subnetRef": "[concat(variables('vnetID'),'/subnets/',variables('subnetName'))]",
"vmID":"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]",
"alertName": "highCPUOnVM",
"alertDescription":"CPU is over 80%",
"alertIsEnabled": true,
"resourceId": "",
"threshold": "80",
"aggregation": "Average",
"customEmails": "",
"sendToServiceOwners": true,
"webhookUrl": "http://testwebhook.test"
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[parameters('newStorageAccountName')]",
"apiVersion": "2015-06-15",
"location": "[variables('location')]",
"properties": {
"accountType": "[variables('storageAccountType')]"
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('publicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "[variables('publicIPAddressType')]",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsNameForPublicIP')]"
}
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]"
}
}
]
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/networkInterfaces",
"name": "[variables('nicName')]",
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "
[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"dependsOn": [
"[concat('Microsoft.Storage/storageAccounts/', parameters('newStorageAccountName'))]",
"[concat('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[variables('vmSize')]"
},
"osProfile": {
"osProfile": {
"computername": "[variables('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"publisher": "[variables('imagePublisher')]",
"offer": "[variables('imageOffer')]",
"sku": "[variables('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "
[concat('http://',parameters('newStorageAccountName'),'.blob.core.windows.net/',variables('vmStorageAccountCon
tainerName'),'/',variables('OSDiskName'),'.vhd')]"
},
"caching": "ReadWrite",
"createOption": "FromImage"
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
}
}
},
{
"type": "Microsoft.Insights/alertRules",
"name": "[variables('alertName')]",
"dependsOn": [
"[variables('vmID')]"
],
"apiVersion": "2016-03-01",
"properties": {
"name": "[variables('alertName')]",
"description": "variables('alertDescription')",
"isEnabled": "[variables('alertIsEnabled')]",
"condition": {
"dataSource": {
"resourceUri": "[variables('vmID')]",
"metricName": "[variables('metricName')]"
},
"operator": "[variables('operator')]",
"threshold": "[variables('threshold')]",
"windowSize": "[variables('windowSize')]",
"timeAggregation": "[variables('aggregation')]"
},
"actions": [
{
"sendToServiceOwners": "[variables('sendToServiceOwners')]",
"customEmails": "[variables('customEmails')]"
},
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleWebhookAction",
"serviceUri": "[variables('webhookUrl')]",
"properties": {}
}
]
}
}
}
]
}
Next Steps
Read more about Alerts
Add Diagnostic Settings to your Resource Manager template
For the JSON syntax and properties, see Microsoft.Insights/alertrules template reference.
Have a classic metric alert notify a non-Azure
system using a webhook
You can use webhooks to route an Azure alert notification to other systems for post-processing or custom
actions. You can use a webhook on an alert to route it to services that send SMS messages, to log bugs, to notify
a team via chat or messaging services, or for various other actions.
This article describes how to set a webhook on an Azure metric alert. It also shows you what the payload for the
HTTP POST to a webhook looks like. For information about the setup and schema for an Azure activity log alert
(alert on events), see Call a webhook on an Azure activity log alert.
Azure alerts use HTTP POST to send the alert contents in JSON format to a webhook URI that you provide
when you create the alert. The schema is defined later in this article. The URI must be a valid HTTP or HTTPS
endpoint. Azure posts one entry per request when an alert is activated.
Configure webhooks via the Azure portal

To add or update the webhook URI, in the Azure portal, go to Create/Update Alerts.
You can also configure an alert to post to a webhook URI by using Azure PowerShell cmdlets, a cross-platform
CLI, or Azure Monitor REST APIs.
Authenticate the webhook

The webhook can authenticate by using token-based authorization. The webhook URI is saved with a token ID.
For example: https://mysamplealert/webcallback?tokenid=sometokenid&someparameter=somevalue
Payload schema
The POST operation contains the following JSON payload and schema for all metric-based alerts:
{
"context": {
"timestamp": "2015-08-14T22:26:41.9975398Z",
"id": "/subscriptions/s1/resourceGroups/useast/providers/microsoft.insights/alertrules/ruleName1",
"name": "ruleName1",
"description": "some description",
"conditionType": "Metric",
"condition": {
"metricName": "Requests",
"metricUnit": "Count",
"metricValue": "10",
"threshold": "10",
"windowSize": "15",
"operator": "GreaterThanOrEqual"
},
"subscriptionId": "s1",
"resourceGroupName": "useast",
"resourceName": "mysite1",
"resourceType": "microsoft.foo/sites",
"resourceId": "/subscriptions/s1/resourceGroups/useast/providers/microsoft.foo/sites/mysite1",
"resourceRegion": "centralus",
"portalLink":
"https://portal.azure.com/#resource/subscriptions/s1/resourceGroups/useast/providers/microsoft.foo/sites/mysi
te1"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
FIELD MANDATORY FIXED SET OF VALUES NOTES
status Y Activated, Resolved The status for the alert

based on the conditions you
set.
context Y The alert context.
timestamp Y The time at which the alert

was triggered.
id Y Every alert rule has a unique

ID.
name Y The alert name.
description Y A description of the alert.

conditionType Y Metric, Event Two types of alerts are

supported: metric and
event. Metric alerts are
based on a metric condition.
Event alerts are based on an
event in the activity log. Use
this value to check whether
the alert is based on a
metric or on an event.
condition Y The specific fields to check

based on the
conditionType value.
metricName For metric alerts The name of the metric that

defines what the rule
monitors.
metricUnit For metric alerts Bytes, BytesPerSecond, The unit allowed in the
Count, CountPerSecond, metric. See allowed values.
Percent, Seconds
metricValue For metric alerts The actual value of the

metric that caused the alert.
threshold For metric alerts The threshold value at

which the alert is activated.
windowSize For metric alerts The period of time that's

used to monitor alert
activity based on the
threshold. The value must
be between 5 minutes and
1 day. The value must be in
ISO 8601 duration format.
timeAggregation For metric alerts Average, Last, Maximum, How the data that's
Minimum, None, Total collected should be
combined over time. The
default value is Average. See
allowed values.
operator For metric alerts The operator that's used to

compare the current metric
data to the set threshold.
subscriptionId Y The Azure subscription ID.
resourceGroupName Y The name of the resource

group for the affected
resource.
resourceName Y The resource name of the

affected resource.
resourceType Y The resource type of the

affected resource.
resourceId Y The resource ID of the

affected resource.
resourceRegion Y The region or location of the

affected resource.
portalLink Y A direct link to the portal

resource summary page.
properties N Optional A set of key/value pairs that

has details about the event.
For example,
Dictionary<String,
String>
. The properties field is
optional. In a custom UI or
logic app-based workflow,
users can enter key/value
pairs that can be passed via
the payload. An alternate
way to pass custom
properties back to the
webhook is via the webhook
URI itself (as query
parameters).
NOTE
You can set the properties field only by using Azure Monitor REST APIs.
Next steps
Learn more about Azure alerts and webhooks in the video Integrate Azure alerts with PagerDuty.
Learn how to execute Azure Automation scripts (runbooks) on Azure alerts.
Learn how to use a logic app to send an SMS message via Twilio from an Azure alert.
Learn how to use a logic app to send a Slack message from an Azure alert.
Learn how to use a logic app to send a message to an Azure queue from an Azure alert.
Create and manage alert rules in Log Analytics with
REST API
The Log Analytics Alert REST API allows you to create and manage alerts in Log Analytics. This article
provides details of the API and several examples for performing different operations.
IMPORTANT
As announced earlier, log analytics workspace(s) created after June 1, 2019 - will be able to manage alert rules using
only Azure scheduledQueryRules REST API, Azure Resource Mananger Template and PowerShell cmdlet. Customers can
easily switch their preferred means of alert rule management for older workspaces to leverage Azure Monitor
scheduledQueryRules as default and gain many new benefits like the ability to use native PowerShell cmdlets, increased
lookback time period in rules, creation of rules in separate resource group or subscription and much more.
The Log Analytics Search REST API is RESTful and can be accessed via the Azure Resource Manager REST
API. In this document, you will find examples where the API is accessed from a PowerShell command line
using ARMClient, an open-source command-line tool that simplifies invoking the Azure Resource Manager
API. The use of ARMClient and PowerShell is one of many options to access the Log Analytics Search API.
With these tools, you can utilize the RESTful Azure Resource Manager API to make calls to Log Analytics
workspaces and perform search commands within them. The API will output search results to you in JSON
format, allowing you to use the search results in many different ways programmatically.
Prerequisites
Currently, alerts can only be created with a saved search in Log Analytics. You can refer to the Log Search
REST API for more information.
Schedules
A saved search can have one or more schedules. The schedule defines how often the search is run and the time
interval over which the criteria is identified. Schedules have the properties in the following table.
Interval How often the search is run. Measured in minutes.
QueryTimeSpan The time interval over which the criteria is evaluated. Must
be equal to or greater than Interval. Measured in minutes.
Version The API version being used. Currently, this should always be
set to 1.
For example, consider an event query with an Interval of 15 minutes and a Timespan of 30 minutes. In this
case, the query would be run every 15 minutes, and an alert would be triggered if the criteria continued to
resolve to true over a 30-minute span.
Retrieving schedules
Use the Get method to retrieve all schedules for a saved search.
armclient get /subscriptions/{Subscription
ID}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{Workspace
Name}/savedSearches/{Search ID}/schedules?api-version=2015-03-20
Use the Get method with a schedule ID to retrieve a particular schedule for a saved search.

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}?api-version=2015-03-20
Following is a sample response for a schedule.
{
"value": [{
"id": "subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/sampleRG/providers/Microsoft.OperationalInsights/workspaces/MyWorkspace/savedSe
arches/0f0f4853-17f8-4ed1-9a03-8e888b0d16ec/schedules/a17b53ef-bd70-4ca4-9ead-83b00f2024a8",
"etag": "W/\"datetime'2016-02-25T20%3A54%3A49.8074679Z'\"",
"properties": {
"Interval": 15,
"QueryTimeSpan": 15,
"Enabled": true,
}
}]
}
Creating a schedule
Use the Put method with a unique schedule ID to create a new schedule. Two schedules cannot have the same
ID even if they are associated with different saved searches. When you create a schedule in the Log Analytics
console, a GUID is created for the schedule ID.
NOTE
The name for all saved searches, schedules, and actions created with the Log Analytics API must be in lowercase.
$scheduleJson = "{'properties': { 'Interval': 15, 'QueryTimeSpan':15, 'Enabled':'true' } }"

armclient put /subscriptions/{Subscription
Name}/savedSearches/{Search ID}/schedules/mynewschedule?api-version=2015-03-20 $scheduleJson
Editing a schedule
Use the Put method with an existing schedule ID for the same saved search to modify that schedule; in example
below the schedule is disabled. The body of the request must include the etag of the schedule.
$scheduleJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A49.8074679Z'\""','properties': { 'Interval':

15, 'QueryTimeSpan':15, 'Enabled':'false' } }"
Name}/savedSearches/{Search ID}/schedules/mynewschedule?api-version=2015-03-20 $scheduleJson
Deleting schedules
Use the Delete method with a schedule ID to delete a schedule.
armclient delete /subscriptions/{Subscription
Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}?api-version=2015-03-20
Actions
A schedule can have multiple actions. An action may define one or more processes to perform such as sending
a mail or starting a runbook, or it may define a threshold that determines when the results of a search match
some criteria. Some actions will define both so that the processes are performed when the threshold is met.
All actions have the properties in the following table. Different types of alerts have different additional
properties, which are described below.
Type Type of the action. Currently the possible values are Alert
and Webhook.
Name Display name for the alert.
Version The API version being used. Currently, this should always be
set to 1.
Retrieving actions
Use the Get method to retrieve all actions for a schedule.

Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions?api-version=2015-03-20
Use the Get method with the action ID to retrieve a particular action for a schedule.

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}/actions/{Action ID}?api-version=2015-03-20
Creating or editing actions

Use the Put method with an action ID that is unique to the schedule to create a new action. When you create an
action in the Log Analytics console, a GUID is for the action ID.
NOTE
The name for all saved searches, schedules, and actions created with the Log Analytics API must be in lowercase.
Use the Put method with an existing action ID for the same saved search to modify that schedule. The body of
the request must include the etag of the schedule.
The request format for creating a new action varies by action type so these examples are provided in the
sections below.
Deleting actions
Use the Delete method with the action ID to delete an action.
armclient delete /subscriptions/{Subscription
Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}/Actions/{Action ID}?api-version=2015-03-20
Alert Actions
A Schedule should have one and only one Alert action. Alert actions have one or more of the sections in the
following table. Each is described in further detail below.
SECTION DESCRIPTION USAGE
Threshold Criteria for when the action is run. Required for every alert, before or
after they are extended to Azure.
Severity Label used to classify alert when Required for every alert, before or
triggered. after they are extended to Azure.
Suppress Option to stop notifications from alert. Optional for every alert, before or
after they are extended to Azure.
Action Groups IDs of Azure ActionGroup where Required once alerts are extended to
actions required are specified, like - E- Azure
Mails, SMSs, Voice Calls, Webhooks,
Automation Runbooks, ITSM
Connectors, etc.
Customize Actions Modify the standard output for select Optional for every alert, can be used
actions from ActionGroup after alerts are extended to Azure.
Thresholds
An Alert action should have one and only one threshold. When the results of a saved search match the
threshold in an action associated with that search, then any other processes in that action are run. An action can
also contain only a threshold so that it can be used with actions of other types that don’t contain thresholds.
Thresholds have the properties in the following table.
Operator Operator for the threshold comparison.

gt = Greater Than
lt = Less Than
Value Value for the threshold.
For example, consider an event query with an Interval of 15 minutes, a Timespan of 30 minutes, and a
Threshold of greater than 10. In this case, the query would be run every 15 minutes, and an alert would be
triggered if it returned 10 events that were created over a 30-minute span.
Following is a sample response for an action with only a threshold.
"properties": {
"Type": "Alert",
"Name": "My threshold action",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Version": 1
}
Use the Put method with a unique action ID to create a new threshold action for a schedule.
$thresholdJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1', 'Type':'Alert', 'Threshold': {

'Operator': 'gt', 'Value': 10 } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/mythreshold?api-version=2015-03-20
$thresholdJson
Use the Put method with an existing action ID to modify a threshold action for a schedule. The body of the
request must include the etag of the action.
$thresholdJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': { 'Name': 'My

Threshold', 'Version':'1', 'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 10 } }"
$thresholdJson
Severity
Log Analytics allows you to classify your alerts into categories, to allow easier management and triage. The
Alert severity defined is: informational, warning, and critical. These are mapped to the normalized severity scale
of Azure Alerts as:
LOG ANALYTICS SEVERITY LEVEL AZURE ALERTS SEVERITY LEVEL
critical Sev 0
warning Sev 1
informational Sev 2
Following is a sample response for an action with only a threshold and severity.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Severity": "critical",
"Version": 1 }
Use the Put method with a unique action ID to create a new action for a schedule with severity.
$thresholdWithSevJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1','Severity': 'critical',
'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 10 } }"
$thresholdWithSevJson
Use the Put method with an existing action ID to modify a severity action for a schedule. The body of the
$thresholdWithSevJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': {

'Name': 'My Threshold', 'Version':'1','Severity': 'critical', 'Type':'Alert', 'Threshold': { 'Operator':
'gt', 'Value': 10 } }"
$thresholdWithSevJson
Suppress
Log Analytics based query alerts will fire every time threshold is met or exceeded. Based on the logic implied in
the query, this may result in alert getting fired for a series of intervals and hence notifications also being sent
constantly. To prevent such scenario, a user can set Suppress option instructing Log Analytics to wait for a
stipulated amount of time before notification is fired the second time for the alert rule. So if suppress is set for
30 minutes; then alert will fire the first time and send notifications configured. But then wait for 30 minutes,
before notification for the alert rule is again used. In the interim period, alert rule will continue to run - only
notification is suppressed by Log Analytics for specified time, regardless of how many times the alert rule fired
in this period.
Suppress property of Log Analytics alert rule is specified using the Throttling value and the suppression period
using DurationInMinutes value.
Following is a sample response for an action with only a threshold, severity, and suppress property
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Throttling": {
"DurationInMinutes": 30
},
"Version": 1 }
Use the Put method with a unique action ID to create a new action for a schedule with severity.
$AlertSuppressJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1','Severity': 'critical',

'Type':'Alert', 'Throttling': { 'DurationInMinutes': 30 },'Threshold': { 'Operator': 'gt', 'Value': 10 } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/myalert?api-version=2015-03-20
$AlertSuppressJson
Use the Put method with an existing action ID to modify a severity action for a schedule. The body of the
$AlertSuppressJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': { 'Name':
'My Threshold', 'Version':'1','Severity': 'critical', 'Type':'Alert', 'Throttling': { 'DurationInMinutes':
30 },'Threshold': { 'Operator': 'gt', 'Value': 10 } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/myalert?api-version=2015-03-20
$AlertSuppressJson
Action Groups
All alerts in Azure, use Action Group as the default mechanism for handling actions. With Action Group, you
can specify your actions once and then associate the action group to multiple alerts - across Azure. Without the
need, to repeatedly declare the same actions over and over again. Action Groups support multiple actions -
including email, SMS, Voice Call, ITSM Connection, Automation Runbook, Webhook URI and more.
For users who have extended their alerts into Azure - a schedule should now have Action Group details passed
along with threshold, to be able to create an alert. E -mail details, Webhook URLs, Runbook Automation details,
and other Actions, need to be defined in side an Action Group first before creating an alert; one can create
Action Group from Azure Monitor in Portal or use Action Group API.
To add association of action group to an alert, specify the unique Azure Resource Manager ID of the action
group in the alert definition. A sample illustration is provided below:
"properties": {
"Type": "Alert",
"Name": "test-alert",
"Description": "I need to put a description here",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"AzNsNotification": {
"GroupIds": [
"/subscriptions/1234a45-123d-4321-12aa-123b12a5678/resourcegroups/my-resource-
group/providers/microsoft.insights/actiongroups/test-actiongroup"
]
},
"Version": 1
},
Use the Put method with a unique action ID to associate already existing Action Group for a schedule. The
following is a sample illustration of usage.
$AzNsJson = "{'properties': { 'Name': 'test-alert', 'Version':'1', 'Type':'Alert', 'Threshold': {

'Operator': 'gt', 'Value': 12 },'Severity': 'critical', 'AzNsNotification': {'GroupIds':
['subscriptions/1234a45-123d-4321-12aa-123b12a5678/resourcegroups/my-resource-
group/providers/microsoft.insights/actiongroups/test-actiongroup']} }"
armclient put /subscriptions/{Subscription ID}/resourceGroups/{Resource Group
Name}/Microsoft.OperationalInsights/workspaces/{Workspace Name}/savedSearches/{Search
ID}/schedules/{Schedule ID}/actions/myAzNsaction?api-version=2015-03-20 $AzNsJson
Use the Put method with an existing action ID to modify an Action Group associated for a schedule. The body
of the request must include the etag of the action.
$AzNsJson = "{'etag': 'datetime'2017-12-13T10%3A52%3A21.1697364Z'\"', properties': { 'Name': 'test-alert',
'Version':'1', 'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 12 },'Severity': 'critical',
'AzNsNotification': {'GroupIds': ['subscriptions/1234a45-123d-4321-12aa-123b12a5678/resourcegroups/my-
resource-group/providers/microsoft.insights/actiongroups/test-actiongroup']} }"
Customize Actions
By default actions, follow standard template and format for notifications. But user can customize some actions,
even if they are controlled by Action Groups. Currently, customization is possible for Email Subject and
Webhook Payload.
C u st o m i z e E- M a i l Su b j e c t fo r A c t i o n G r o u p
By default, the email subject for alerts is: Alert Notification <AlertName> for <WorkspaceName> . But this can be
customized, so that you can specific words or tags - to allow you to easily employ filter rules in your Inbox. The
customize email header details need to send along with ActionGroup details, as in sample below.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"GroupIds": [
],
"CustomEmailSubject": "Azure Alert fired"
},
"Version": 1
},
Use the Put method with a unique action ID to associate already existing Action Group with customization for a
schedule. The following is a sample illustration of usage.

group/providers/microsoft.insights/actiongroups/test-actiongroup'], 'CustomEmailSubject': 'Azure Alert
fired'} }"
resource-group/providers/microsoft.insights/actiongroups/test-actiongroup']}, 'CustomEmailSubject': 'Azure
Alert fired' }"
C u st o m i z e W e b h o o k P a y l o a d fo r A c t i o n G r o u p
By default, the webhook sent via Action Group for log analytics has a fixed structure. But one can customize the
JSON payload by using specific variables supported, to meet requirements of the webhook endpoint. For more
information, see Webhook action for log alert rules.
The customize webhook details need to send along with ActionGroup details and will be applied to all
Webhook URI specified inside the action group; as in sample below.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"GroupIds": [
],
"CustomWebhookPayload": "{\"field1\":\"value1\",\"field2\":\"value2\"}",
"CustomEmailSubject": "Azure Alert fired"
},
"Version": 1
},
Use the Put method with a unique action ID to associate already existing Action Group with customization for a
schedule. The following is a sample illustration of usage.

group/providers/microsoft.insights/actiongroups/test-actiongroup'], 'CustomEmailSubject': 'Azure Alert
fired','CustomWebhookPayload': '{\"field1\":\"value1\",\"field2\":\"value2\"}'} }"
resource-group/providers/microsoft.insights/actiongroups/test-actiongroup']}, 'CustomEmailSubject': 'Azure
Alert fired','CustomWebhookPayload': '{\"field1\":\"value1\",\"field2\":\"value2\"}' }"
Next steps
Use the REST API to perform log searches in Log Analytics.
Learn about log alerts in Azure monitor
How to create, edit or manage log alert rules in Azure monitor
Connect Azure to ITSM tools using IT Service
Management Connector
The IT Service Management Connector (ITSMC ) allows you to connect Azure and a supported IT Service
Management (ITSM ) product/service.
Azure services like Log Analytics and Azure Monitor provide tools to detect, analyze and troubleshoot issues with
your Azure and non-Azure resources. However, the work items related to an issue typically reside in an ITSM
product/service. The ITSM connector provides a bi-directional connection between Azure and ITSM tools to help
you resolve issues faster.
ITSMC supports connections with the following ITSM tools:
ServiceNow
System Center Service Manager
Provance
Cherwell
With ITSMC, you can:
Create work items in ITSM tool, based on your Azure alerts (metric alerts, Activity Log alerts and Log Analytics
alerts).
Optionally, you can sync your incident and change request data from your ITSM tool to an Azure Log Analytics
workspace.
Read more about the legal terms and privacy policy.
You can start using the ITSM Connector using the following steps:
1. Add the ITSM Connector Solution
2. Create an ITSM connection
3. Use the connection
Adding the IT Service Management Connector Solution

Before you can create a connection, you need to add the ITSM Connector Solution.
1. In Azure portal, click + New icon.
2. Search for IT Service Management Connector in the Marketplace and click Create.
3. In the OMS Workspace section, select the Azure Log Analytics workspace where you want to install the
solution.
NOTE
As part of the ongoing transition from Microsoft Operations Management Suite (OMS) to Azure Monitor, OMS
Workspaces are now referred to as Log Analytics workspaces.
The ITSM Connector can only be installed in Log Analytics workspaces in the following regions: East US, West
Europe, Southeast Asia, Southeast Australia, West Central US, East Japan, South UK, Central India, Central
Canada.
4. In the OMS Workspace Settings section, select the ResourceGroup where you want to create the solution
resource.
NOTE
As part of the ongoing transition from Microsoft Operations Management Suite (OMS) to Azure Monitor, OMS
Workspaces are now referred to as Log Analytics workspaces.
5. Click Create.
When the solution resource is deployed, a notification appears at the top right of the window.
Creating an ITSM connection

Once you have installed the solution, you can create a connection.
For creating a connection, you will need to prep your ITSM tool to allow the connection from the ITSM Connector
solution.
Depending on the ITSM product you are connecting to, use the following steps :
System Center Service Manager (SCSM )
ServiceNow
Provance
Cherwell
Once you have prepped your ITSM tools, follow the steps below to create a connection:
1. Go to All Resources, look for ServiceDesk(YourWorkspaceName).
2. Under WORKSPACE DATA SOURCES in the left pane, click ITSM Connections.
This page displays the list of connections.

3. Click Add Connection.
4. Specify the connection settings as described in Configuring the ITSMC connection with your ITSM
products/services article.
NOTE
By default, ITSMC refreshes the connection's configuration data once in every 24 hours. To refresh your connection's
data instantly for any edits or template updates that you make, click the Sync button on your connection's blade.
Using the solution
By using the ITSM Connector solution, you can create work items from Azure alerts, Log Analytics alerts and Log
Analytics log records.
Create ITSM work items from Azure alerts

Once you have your ITSM connection created, you can create work item(s) in your ITSM tool based on Azure
alerts, by using the ITSM Action in Action Groups.
Action Groups provide a modular and reusable way of triggering actions for your Azure Alerts. You can use Action
Groups with metric alerts, Activity Log alerts and Azure Log Analytics alerts in Azure portal.
Use the following procedure:
1. In Azure portal, click Monitor.
2. In the left pane, click Action groups. The Add action group window appears.
3. Provide Name and ShortName for your action group. Select the Resource Group and Subscription
where you want to create your action group.
4. In the Actions list, select ITSM from the drop-down menu for Action Type. Provide a Name for the action
and click Edit details.
5. Select the Subscription where your Log Analytics workspace is located. Select the Connection name
(your ITSM Connector name) followed by your Workspace name. For example,
"MyITSMMConnector(MyWorkspace)."
6. Select Work Item type from the drop-down menu. Choose to use an existing template or fill the fields
required by your ITSM product.
7. Click OK.
When creating/editing an Azure alert rule, use an Action group, which has an ITSM Action. When the alert
triggers, work item is created/updated in the ITSM tool.
NOTE
For information on pricing of ITSM Action, see the pricing page for Action Groups.
Visualize and analyze the incident and change request data

Based on your configuration when setting up a connection, ITSM connector can sync up to 120 days of Incident
and Change request data. The log record schema for this data is provided in the next section.
The incident and change request data can be visualized using the ITSM Connector dashboard in the solution.
The dashboard also provides information on connector status which can be used as a starting point to analyze any
issues with the connections.
You can also visualize the incidents synced against the impacted computers, within the Service Map solution.
Service Map automatically discovers the application components on Windows and Linux systems and maps the
communication between services. It allows you to view your servers as you think of them – as interconnected
systems that deliver critical services. Service Map shows connections between servers, processes, and ports across
any TCP -connected architecture with no configuration required other than installation of an agent. Learn more.
If you are using the Service Map solution, you can view the service desk items created in the ITSM solutions as
shown in the following example:
More information: Service Map
Additional information
Data synced from ITSM product
Incidents and change requests are synced from your ITSM product to your Log Analytics workspace based on the
connection's configuration.
The following information shows examples of data gathered by ITSMC:
NOTE
Depending on the work item type imported into Log Analytics, ServiceDesk_CL contains the following fields:
Work item: Incidents

ServiceDeskWorkItemType_s="Incident"
Fields
ServiceDeskConnectionName
Service Desk ID
State
Urgency
Impact
Priority
Escalation
Created By
Resolved By
Closed By
Source
Assigned To
Category
Title
Description
Created Date
Closed Date
Resolved Date
Last Modified Date
Computer
Work item: Change Requests
ServiceDeskWorkItemType_s="ChangeRequest"
Fields
ServiceDeskConnectionName
Service Desk ID
Created By
Closed By
Source
Assigned To
Title
Type
Category
State
Escalation
Conflict Status
Urgency
Priority
Risk
Impact
Assigned To
Created Date
Closed Date
Last Modified Date
Requested Date
Planned Start Date
Planned End Date
Work Start Date
Work End Date
Description
Computer
Output data for a ServiceNow incident

LOG ANALYTICS FIELD SERVICENOW FIELD
ServiceDeskId_s Number
IncidentState_s State
Urgency_s Urgency
Impact_s Impact
Priority_s Priority
CreatedBy_s Opened by
ResolvedBy_s Resolved by
ClosedBy_s Closed by
Source_s Contact type
AssignedTo_s Assigned to
Category_s Category
Title_s Short description
Description_s Notes
CreatedDate_t Opened
LOG ANALYTICS FIELD SERVICENOW FIELD
ClosedDate_t closed
ResolvedDate_t Resolved
Computer Configuration item
Output data for a ServiceNow change request

LOG ANALYTICS SERVICENOW FIELD
ServiceDeskId_s Number
CreatedBy_s Requested by
ClosedBy_s Closed by
AssignedTo_s Assigned to
Title_s Short description
Type_s Type
Category_s Category
CRState_s State
Urgency_s Urgency
Priority_s Priority
Risk_s Risk
Impact_s Impact
RequestedDate_t Requested by date
ClosedDate_t Closed date
PlannedStartDate_t Planned start date
PlannedEndDate_t Planned end date
WorkStartDate_t Actual start date
WorkEndDate_t Actual end date
Description_s Description
Computer Configuration Item

Troubleshoot ITSM connections
1. If connection fails from connected source's UI with an Error in saving connection message, take the
following steps:
For ServiceNow, Cherwell and Provance connections,
ensure you correctly entered the username, password, client ID, and client secret for each of the
connections.
check if you have sufficient privileges in the corresponding ITSM product to make the connection.
For Service Manager connections,
ensure that the Web app is successfully deployed and hybrid connection is created. To verify the
connection is successfully established with the on premises Service Manager machine, visit the Web app
URL as detailed in the documentation for making the hybrid connection.
2. If data from ServiceNow is not getting synced to Log Analytics, ensure that the ServiceNow instance is not
sleeping. ServiceNow Dev Instances sometimes go to sleep when idle for a long period. Else, report the
issue.
3. If Log Analytics alerts fire but work items are not created in ITSM product or configuration items are not
created/linked to work items or for any other generic information, look in the following places:
ITSMC: The solution shows a summary of connections/work items/computers etc. Click the tile showing
Connector Status, which takes you to Log Search with the relevant query. Look at the log records with
LogType_S as ERROR for more information.
Log Search page: view the errors/related information directly using the query * ServiceDeskLog_CL
* .
Troubleshoot Service Manager Web App deployment

1. In case of any issues with web app deployment, ensure you have sufficient permissions in the subscription
mentioned to create/deploy resources.
2. If you get an "Object reference not set to instance of an object" error when you run the script, ensure that
you entered valid values under User Configuration section.
3. If you fail to create service bus relay namespace, ensure that the required resource provider is registered in the
subscription. If not registered, manually create service bus relay namespace from the Azure portal. You can
also create it while creating the hybrid connection from the Azure portal.
Contact us
For any queries or feedback on the IT Service Management Connector, contact us at
omsitsmfeedback@microsoft.com.
Next steps
Add ITSM products/services to IT Service Management Connector.
Connect ITSM products/services with IT Service
Management Connector
This article provides information about how to configure the connection between your ITSM product/service and
the IT Service Management Connector (ITSMC ) in Log Analytics to centrally manage your work items. For more
information about ITSMC, see Overview.
The following ITSM products/services are supported. Select the product to view detailed information about how
to connect the product to ITSMC.
System Center Service Manager
ServiceNow
Provance
Cherwell
NOTE
ITSM Connector can only connect to cloud-based ServiceNow instances. On-premises ServiceNow instances are currently not
supported.
Connect System Center Service Manager to IT Service Management

Connector in Azure
The following sections provide details about how to connect your System Center Service Manager product to
ITSMC in Azure.
Prerequisites
Ensure the following prerequisites are met:
ITSMC installed. More information: Adding the IT Service Management Connector Solution.
The Service Manager Web application (Web app) is deployed and configured. Information on Web app is here.
Hybrid connection created and configured. More information: Configure the hybrid Connection.
Supported versions of Service Manager: 2012 R2 or 2016.
User role: Advanced operator.
Connection procedure
Use the following procedure to connect your System Center Service Manager instance to ITSMC:
1. In Azure portal, go to All Resources and look for ServiceDesk(YourWorkspaceName)
2. Under WORKSPACE DATA SOURCES click ITSM Connections.
3. At the top of the right pane, click Add.
4. Provide the information as described in the following table, and click OK to create the connection.
NOTE
All these parameters are mandatory.
FIELD DESCRIPTION
Connection Name Type a name for the System Center Service Manager instance
that you want to connect with ITSMC. You use this name later
when you configure work items in this instance/ view detailed
log analytics.
Partner type Select System Center Service Manager.
Server URL Type the URL of the Service Manager Web app. More
information about Service Manager Web app is here.
Client ID Type the client ID that you generated (using the automatic
script) for authenticating the Web app. More information
about the automated script is here.
Client Secret Type the client secret, generated for this ID.
Sync Data Select the Service Manager work items that you want to sync
through ITSMC. These work items are imported into Log
Analytics. Options: Incidents, Change Requests.
Data Sync Scope Type the number of past days that you want the data from.
Maximum limit: 120 days.
FIELD DESCRIPTION
Create new configuration item in ITSM solution Select this option if you want to create the configuration items
in the ITSM product. When selected, Log Analytics creates the
affected CIs as configuration items (in case of non-existing
CIs) in the supported ITSM system. Default: disabled.
When successfully connected, and synced:

Selected work items from Service Manager are imported into Azure Log Analytics. You can view the
summary of these work items on the IT Service Management Connector tile.
You can create incidents from Log Analytics alerts or from log records, or from Azure alerts in this Service
Manager instance.
Learn more: Create ITSM work items from Azure alerts.
Create and deploy Service Manager web app service
To connect the on-premises Service Manager with ITSMC in Azure, Microsoft has created a Service Manager Web
app on the GitHub.
To set up the ITSM Web app for your Service Manager, do the following:
Deploy the Web app – Deploy the Web app, set the properties, and authenticate with Azure AD. You can
deploy the web app by using the automated script that Microsoft has provided you.
Configure the hybrid connection - Configure this connection, manually.
Deploy the web app
Use the automated script to deploy the Web app, set the properties, and authenticate with Azure AD.
Run the script by providing the following required details:
Azure subscription details
Resource group name
Location
Service Manager server details (server name, domain, user name, and password)
Site name prefix for your Web app
ServiceBus Namespace.
The script creates the Web app using the name that you specified (along with few additional strings to make it
unique). It generates the Web app URL, client ID and client secret.
Save the values, you use them when you create a connection with ITSMC.
Check the Web app installation
1. Go to Azure portal > Resources.
2. Select the Web app, click Settings > Application Settings.
3. Confirm the information about the Service Manager instance that you provided at the time of deploying the
app through the script.
Configure the hybrid connection
Use the following procedure to configure the hybrid connection that connects the Service Manager instance with
ITSMC in Azure.
1. Find the Service Manager Web app, under Azure Resources.
2. Click Settings > Networking.
3. Under Hybrid Connections, click Configure your hybrid connection endpoints.
4. In the Hybrid Connections blade, click Add hybrid connection.
5. In the Add Hybrid Connections blade, click Create new hybrid Connection.
6. Type the following values:
EndPoint Name: Specify a name for the new Hybrid connection.
EndPoint Host: FQDN of the Service Manager management server.
EndPoint Port: Type 5724
Servicebus namespace: Use an existing servicebus namespace or create a new one.
Location: select the location.
Name: Specify a name to the servicebus if you are creating it.
7. Click OK to close the Create hybrid connection blade and start creating the hybrid connection.
Once the Hybrid connection is created, it is displayed under the blade.
8. After the hybrid connection is created, select the connection and click Add selected hybrid connection.
Configure the listener setup
Use the following procedure to configure the listener setup for the hybrid connection.
1. In the Hybrid Connections blade, click Download the Connection Manager and install it on the
machine where System Center Service Manager instance is running.
Once the installation is complete, Hybrid Connection Manager UI option is available under Start menu.
2. Click Hybrid Connection Manager UI , you will be prompted for your Azure credentials.
3. Login with your Azure credentials and select your subscription where the Hybrid connection was created.
4. Click Save.
Your hybrid connection is successfully connected.
NOTE
After the hybrid connection is created, verify and test the connection by visiting the deployed Service Manager Web app.
Ensure the connection is successful before you try to connect to ITSMC in Azure.
The following sample image shows the details of a successful connection:

Connect ServiceNow to IT Service Management Connector in Azure
The following sections provide details about how to connect your ServiceNow product to ITSMC in Azure.
Prerequisites
ServiceNow supported versions: Madrid, London, Kingston, Jakarta, Istanbul, Helsinki, Geneva.
ServiceNow Admins must do the following in their ServiceNow instance:
Generate client ID and client secret for the ServiceNow product. For information on how to generate client
ID and secret, see the following information as required:
Set up OAuth for Madrid
Set up OAuth for London
Set up OAuth for Kingston
Set up OAuth for Jakarta
Set up OAuth for Istanbul
Set up OAuth for Helsinki
Set up OAuth for Geneva
Install the User App for Microsoft Log Analytics integration (ServiceNow app). Learn more.
Create integration user role for the user app installed. Information on how to create the integration user
role is here.
Connection procedure
Use the following procedure to create a ServiceNow connection:

NOTE
FIELD DESCRIPTION
Connection Name Type a name for the ServiceNow instance that you want to
connect with ITSMC. You use this name later in Log Analytics
when you configure work items in this ITSM/ view detailed log
analytics.
Partner type Select ServiceNow.
Username Type the integration user name that you created in the
ServiceNow app to support the connection to ITSMC. More
information: Create ServiceNow app user role.
FIELD DESCRIPTION
Password Type the password associated with this user name. Note: User
name and password are used for generating authentication
tokens only, and are not stored anywhere within the ITSMC
service.
Server URL Type the URL of the ServiceNow instance that you want to
connect to ITSMC.
Client ID Type the client ID that you want to use for OAuth2
Authentication, which you generated earlier. More information
on generating client ID and secret: OAuth Setup.
Client Secret Type the client secret, generated for this ID.
Data Sync Scope Select the ServiceNow work items that you want to sync to
Azure Log Analytics, through the ITSMC. The selected values
are imported into log analytics. Options: Incidents and
Change Requests.
Sync Data Type the number of past days that you want the data from.
in the ITSM product. When selected, ITSMC creates the
Selected work items from ServiceNow instance are imported into Azure Log Analytics. You can view the
You can create incidents from Log Analytics alerts or from log records, or from Azure alerts in this
ServiceNow instance.
Create integration user role in ServiceNow app
User the following procedure:
1. Visit the ServiceNow store and install the User App for ServiceNow and Microsoft OMS Integration
into your ServiceNow Instance.
NOTE
As part of the ongoing transition from Microsoft Operations Management Suite (OMS) to Azure Monitor, OMS is
now referred to as Log Analytics.
2. After installation, visit the left navigation bar of the ServiceNow instance, search, and select Microsoft OMS
integrator.
3. Click Installation Checklist.
The status is displayed as Not complete if the user role is yet to be created.
4. In the text boxes, next to Create integration user, enter the user name for the user that can connect to
ITSMC in Azure.
5. Enter the password for this user, and click OK.
NOTE
You use these credentials to make the ServiceNow connection in Azure.
The newly created user is displayed with the default roles assigned.
Default roles:
personalize_choices
import_transformer
x_mioms_microsoft.user
itil
template_editor
view_changer
Once the user is successfully created, the status of Check Installation Checklist moves to Completed, listing the
details of the user role created for the app.
NOTE
ITSM Connector can send incidents to ServiceNow without any other modules installed on your ServiceNow instance. If you
are using EventManagement module in your ServiceNow instance and wish to create Events or Alerts in ServiceNow using
the connector, add the following roles to the integration user:
evt_mgmt_integration
evt_mgmt_operator
Connect Provance to IT Service Management Connector in Azure

The following sections provide details about how to connect your Provance product to ITSMC in Azure.
Prerequisites
Provance App should be registered with Azure AD - and client ID is made available. For detailed
information, see how to configure active directory authentication.
User role: Administrator.
Connection Procedure
Use the following procedure to create a Provance connection:

NOTE
FIELD DESCRIPTION
Connection Name Type a name for the Provance instance that you want to
connect with ITSMC. You use this name later when you
configure work items in this ITSM/ view detailed log analytics.
Partner type Select Provance.
Username Type the user name that can connect to ITSMC.
Password Type the password associated with this user name. Note:
User name and password are used for generating
authentication tokens only, and are not stored anywhere
within the ITSMC service._
Server URL Type the URL of your Provance instance that you want to
connect to ITSMC.
FIELD DESCRIPTION
Client ID Type the client ID for authenticating this connection, which

you generated in your Provance instance. More information
on client ID, see how to configure active directory
authentication.
Data Sync Scope Select the Provance work items that you want to sync to
Azure Log Analytics, through ITSMC. These work items are
imported into log analytics. Options: Incidents, Change
Requests.

Selected work items from this Provance instance are imported into Azure Log Analytics. You can view the
You can create incidents from Log Analytics alerts or from log records, or from Azure alerts in this
Provance instance.
Connect Cherwell to IT Service Management Connector in Azure

The following sections provide details about how to connect your Cherwell product to ITSMC in Azure.
Prerequisites
Client ID generated. More information: Generate client ID for Cherwell.
User role: Administrator.
Connection Procedure
Use the following procedure to create a Provance connection:

NOTE
FIELD DESCRIPTION
FIELD DESCRIPTION
Connection Name Type a name for the Cherwell instance that you want to
connect to ITSMC. You use this name later when you
configure work items in this ITSM/ view detailed log analytics.
Partner type Select Cherwell.
Username Type the Cherwell user name that can connect to ITSMC.
Password Type the password associated with this user name. Note:
User name and password are used for generating
authentication tokens only, and are not stored anywhere
within the ITSMC service.
Server URL Type the URL of your Cherwell instance that you want to
connect to ITSMC.
Client ID Type the client ID for authenticating this connection, which

you generated in your Cherwell instance.
Data Sync Scope Select the Cherwell work items that you want to sync through
ITSMC. These work items are imported into log analytics.
Options: Incidents, Change Requests.
Selected work items from this Cherwell instance are imported into Azure Log Analytics. You can view the
You can create incidents from Log Analytics alerts or from log records, or from Azure alerts in this Cherwell
instance.
Generate client ID for Cherwell
To generate the client ID/key for Cherwell, use the following procedure:
1. Log in to your Cherwell instance as admin.
2. Click Security > Edit REST API client settings.
3. Select Create new client > client secret.
Next steps
Create ITSM work items from Azure alerts
Create Service Manager Web app using the
automated script
Use the following script to create the Web app for your Service Manager instance. More information about
Service Manager connection is here: Service Manager Web app
Run the script by providing the following required details:
Azure subscription details
Resource group name
Location
Service Manager server details (server name, domain, username, and password)
Site name prefix for your Web app
ServiceBus Namespace.
The script will create the Web app using the name that you specified (along with few additional strings to make it
unique). It generates the Web app URL, client ID, and client secret.
Save these values, you will need these values when you create a connection with IT Service Management
Connector.
NOTE
PowerShell.
Prerequisites
Windows Management Framework 5.0 or above. Windows 10 has 5.1 by default. You can download the
framework from here:
Use the following script:
####################################
# User Configuration Section Begins
####################################
# Subscription name in Azure account. Check in Azure Portal.

$azureSubscriptionName = ""
# Resource group name for resource deployment. Could be an existing resource group or a new one to be created.
$resourceGroupName = ""
# Location for existing resource group or new resource group deployment

################################### List of available regions
#################################################
# centralus,eastasia,southeastasia,eastus,eastus2,westus,westus2,northcentralus,southcentralus,westcentralus,
#
northeurope,westeurope,japaneast,japanwest,brazilsouth,australiasoutheast,australiaeast,westindia,southindia,
# centralindia,canadacentral,canadaeast,uksouth,ukwest.
##############################################################################################################
##############################################################################################################
#
$location = ""
# Service Manager Authentication Settings

$serverName = ""
$domain = ""
$username = ""
$password = ""
# Azure site Name Prefix. Default is "smoc". It can be configured to any desired value.
$siteNamePrefix = ""
# Service Bus namespace. Please provide an already existing service bus namespace.
# If it doesn't exist, a new one will be created with name $siteName + "sbn" which can also be later reused
for any other hybrid connections.
$serviceName = ""
##################################
# User Configuration Section Ends
##################################
################
# Installations
################
# Allowing the execution of the script for current user.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser -Force
Write-Host "Checking for required modules..."

if(!(Get-PackageProvider -Name NuGet))
{
Write-Host "Installing NuGet Package Provider..."
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Scope CurrentUser -Force -WarningAction
SilentlyContinue
}
$module = Get-Module -ListAvailable -Name Az
if(!$module -or ($module[0].Version.Major -lt 1))

{
Write-Host "Installing Az Module..."
try
{
# In case of Win 10 Anniversary update
Install-Module Az -MinimumVersion 1.0 -Scope CurrentUser -Force -WarningAction SilentlyContinue -
AllowClobber
}
catch
{
Install-Module Az -MinimumVersion 1.0 -Scope CurrentUser -Force -WarningAction SilentlyContinue
}
Write-Host "Requirement check complete!!"
#############
# Parameters
#############
$errorActionPreference = "Stop"
$templateUri = "https://raw.githubusercontent.com/Azure/SMOMSConnector/master/azuredeploy.json"
if(!$siteNamePrefix)
{
$siteNamePrefix = "smoc"
}
Connect-AzAccount
$context = Set-AzContext -SubscriptionName $azureSubscriptionName -WarningAction SilentlyContinue
$resourceProvider = Get-AzResourceProvider -ProviderNamespace Microsoft.Web
if(!$resourceProvider -or $resourceProvider[0].RegistrationState -ne "Registered")

{
try
{
Write-Host "Registering Microsoft.Web Resource Provider"
Register-AzResourceProvider -ProviderNamespace Microsoft.Web
}
catch
{
Write-Host "Failed to Register Microsoft.Web Resource Provider. Please register it in Azure Portal."
exit
}
}
do
{
$rand = Get-Random -Maximum 32000
$siteName = $siteNamePrefix + $rand
$resource = Get-AzResource -Name $siteName -ResourceType Microsoft.Web/sites
}while($resource)
$azureSite = "https://"+$siteName+".azurewebsites.net"
##############
# MAIN Begins
##############
# Web App Deployment

####################
$tenant = $context.Tenant.Id
if(!$tenant)
{
#For backward compatibility with older versions
$tenant = $context.Tenant.TenantId
}
try
{
Get-AzResourceGroup -Name $resourceGroupName
}
catch
{
New-AzResourceGroup -Location $location -Name $resourceGroupName
}
Write-Output "Web App Deployment in progress...."
New-AzResourceGroupDeployment -TemplateUri $templateUri -siteName $siteName -ResourceGroupName

$resourceGroupName
Write-Output "Web App Deployed successfully!!"
# AAD Authentication
####################
Add-Type -AssemblyName System.Web
$secret = [System.Web.Security.Membership]::GeneratePassword(30,2).ToString()
$clientSecret = $secret | ConvertTo-SecureString -AsPlainText -Force
try
{
Write-Host "Creating AzureAD application..."
$adApp = New-AzADApplication -DisplayName $siteName -HomePage $azureSite -IdentifierUris $azureSite -

Password $clientSecret
Write-Host "AzureAD application created successfully!!"

}
catch
{
# Delete the deployed web app if Azure AD application fails
Remove-AzResource -ResourceGroupName $resourceGroupName -ResourceName $siteName -ResourceType
Microsoft.Web/sites -Force
Write-Host "Failure occurred in Azure AD application....Try again!!"
exit
$clientId = $adApp.ApplicationId
$servicePrincipal = New-AzADServicePrincipal -ApplicationId $clientId
# Web App Configuration

#######################
try
{
Write-Host "Configuring deployed Web-App..."

$webApp = Get-AzWebAppSlot -ResourceGroupName $resourceGroupName -Name $siteName -Slot production -
WarningAction SilentlyContinue
$appSettingList = $webApp.SiteConfig.AppSettings
$appSettings = @{}
ForEach ($item in $appSettingList) {
$appSettings[$item.Name] = $item.Value
}
$appSettings['ida:Tenant'] = $tenant
$appSettings['ida:Audience'] = $azureSite
$appSettings['ida:ServerName'] = $serverName
$appSettings['ida:Domain'] = $domain
$appSettings['ida:Username'] = $userName
$appSettings['ida:WhitelistedClientId'] = $clientId
$connStrings = @{}
$kvp = @{"Type"="Custom"; "Value"=$password}
$connStrings['ida:Password'] = $kvp
Set-AzWebAppSlot -ResourceGroupName $resourceGroupName -Name $siteName -AppSettings $appSettings -

ConnectionStrings $connStrings -Slot production -WarningAction SilentlyContinue
}
catch
{
Write-Host "Web App configuration failed. Please ensure all values are provided in Service Manager
Authentication Settings in User Configuration Section"
# Delete the AzureRm AD Application if configuration fails

Remove-AzADApplication -ObjectId $adApp.ObjectId -Force
# Delete the deployed web app if configuration fails

Remove-AzResource -ResourceGroupName $resourceGroupName -ResourceName $siteName -ResourceType
exit
}
# Relay Namespace
###################
if(!$serviceName)
{
$serviceName = $siteName + "sbn"
}
$resourceProvider = Get-AzResourceProvider -ProviderNamespace Microsoft.Relay
if(!$resourceProvider -or $resourceProvider[0].RegistrationState -ne "Registered")

{
try
{
Write-Host "Registering Microsoft.Relay Resource Provider"
Register-AzResourceProvider -ProviderNamespace Microsoft.Relay
}
catch
{
Write-Host "Failed to Register Microsoft.Relay Resource Provider. Please register it in Azure Portal."
}
}
$resource = Get-AzResource -Name $serviceName -ResourceType Microsoft.Relay/namespaces
if(!$resource)
{
$serviceName = $siteName + "sbn"
$properties = @{
"sku" = @{
"name"= "Standard"
"tier"= "Standard"
"capacity"= 1
}
}
try
{
Write-Host "Creating Service Bus namespace..."
New-AzResource -ResourceName $serviceName -Location $location -PropertyObject $properties -
ResourceGroupName $resourceGroupName -ResourceType Microsoft.Relay/namespaces -ApiVersion 2016-07-01 -Force
}
catch
{
$err = $TRUE
Write-Host "Creation of Service Bus Namespace failed...Please create it manually from Azure Portal.`n"
}
Write-Host "Note: Please Configure Hybrid connection in the Networking section of the web application in Azure
Portal to link to the on-premises system.`n"
Write-Host "App Details"
Write-Host "============"
Write-Host "App Name:" $siteName
Write-Host "Client Id:" $clientId
Write-Host "Client Secret:" $secret
Write-Host "URI:" $azureSite
if(!$err)
{
Write-Host "ServiceBus Namespace:" $serviceName
}```
## Next steps
[Configure the Hybrid connection](../../azure-monitor/platform/itsmc-connections.md#configure-the-hybrid-
connection).
connection).
Overview of autoscale in Microsoft Azure Virtual
Machines, Cloud Services, and Web Apps
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, App Service - Web Apps, and
API Management services.
NOTE
Azure has two autoscale methods. An older version of autoscale applies to Virtual Machines (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.
What is autoscale?
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.
The following explanation applies to the pieces of the previous diagram.
Resource Metrics
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.
Custom 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.
Time
Schedule-based rules are based on UTC. You must set your time zone properly when setting up your rules.
Rules
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.
Actions and automation

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 Settings
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.
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
Horizontal vs vertical scaling

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.
For more information, see Vertically scale Azure virtual machine with Azure Automation.
Methods of access
You can set up autoscale via
Azure portal
PowerShell
Cross-platform Command Line Interface (CLI)
Azure Monitor REST API
Supported services for autoscale

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
API Management service Automatically scale an Azure API Management instance
Next steps
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
Get started with Autoscale in Azure
This article describes how to set up your Autoscale settings for your resource in the Microsoft Azure portal.
Discover the Autoscale settings in your subscription

You can discover all the resources for which Autoscale is applicable in Azure Monitor. Use the following steps for a
step-by-step walkthrough:
1. Open the Azure portal.
2. Click the Azure Monitor icon in the left pane.
3. Click Autoscale to view all the resources for which Autoscale is applicable, along with their current Autoscale
status.
You can use the filter pane at the top to scope down the list to select resources in a specific resource group, specific
resource types, or a specific resource.
For each resource, you will find the current instance count and the Autoscale status. The Autoscale status can be:
Not configured: You have not enabled Autoscale yet for this resource.
Enabled: You have enabled Autoscale for this resource.
Disabled: You have disabled Autoscale for this resource.
Create your first Autoscale setting

Let's now go through a simple step-by-step walkthrough to create your first Autoscale setting.
1. Open the Autoscale blade in Azure Monitor and select a resource that you want to scale. (The following
steps use an App Service plan associated with a web app. You can create your first ASP.NET web app in
Azure in 5 minutes.)
2. Note that the current instance count is 1. Click Enable autoscale.
3. Provide a name for the scale setting, and then click Add a rule. Notice the scale rule options that open as a
context pane on the right side. By default, this sets the option to scale your instance count by 1 if the CPU
percentage of the resource exceeds 70 percent. Leave it at its default values and click Add.
4. You've now created your first scale rule. Note that the UX recommends best practices and states that "It is
recommended to have at least one scale in rule." To do so:
a. Click Add a rule.
b. Set Operator to Less than.
c. Set Threshold to 20.
d. Set Operation to Decrease count by.
You should now have a scale setting that scales out/scales in based on CPU usage.
5. Click Save.
Congratulations! You've now successfully created your first scale setting to autoscale your web app based on CPU
usage.
NOTE
The same steps are applicable to get started with a virtual machine scale set or cloud service role.
Other considerations
Scale based on a schedule
In addition to scale based on CPU, you can set your scale differently for specific days of the week.
1. Click Add a scale condition.
2. Setting the scale mode and the rules is the same as the default condition.
3. Select Repeat specific days for the schedule.
4. Select the days and the start/end time for when the scale condition should be applied.
Scale differently on specific dates

In addition to scale based on CPU, you can set your scale differently for specific dates.
1. Click Add a scale condition.
2. Setting the scale mode and the rules is the same as the default condition.
3. Select Specify start/end dates for the schedule.
4. Select the start/end dates and the start/end time for when the scale condition should be applied.
View the scale history of your resource
Whenever your resource is scaled up or down, an event is logged in the activity log. You can view the scale history
of your resource for the past 24 hours by switching to the Run history tab.
If you want to view the complete scale history (for up to 90 days), select Click here to see more details. The
activity log opens, with Autoscale pre-selected for your resource and category.
View the scale definition of your resource
Autoscale is an Azure Resource Manager resource. You can view the scale definition in JSON by switching to the
JSON tab.
You can make changes in JSON directly, if required. These changes will be reflected after you save them.
Disable Autoscale and manually scale your instances
There might be times when you want to disable your current scale setting and manually scale your resource.
Click the Disable autoscale button at the top.
NOTE
This option disables your configuration. However, you can get back to it after you enable Autoscale again.
You can now set the number of instances that you want to scale to manually.
You can always return to Autoscale by clicking Enable autoscale and then Save.
Next steps
Create an Activity Log Alert to monitor all Autoscale engine operations on your subscription
Create an Activity Log Alert to monitor all failed Autoscale scale-in/scale-out operations on your subscription
Understand Autoscale settings
Autoscale settings help ensure that you have the right amount of resources running to handle the fluctuating load
of your application. You can configure Autoscale settings to be triggered based on metrics that indicate load or
performance, or triggered at a scheduled date and time. This article takes a detailed look at the anatomy of an
Autoscale setting. The article begins with the schema and properties of a setting, and then walks through the
different profile types that can be configured. Finally, the article discusses how the Autoscale feature in Azure
evaluates which profile to execute at any given time.
Autoscale setting schema

To illustrate the Autoscale setting schema, the following Autoscale setting is used. It is important to note that this
Autoscale setting has:
One profile.
Two metric rules in this profile: one for scale out, and one for scale in.
The scale-out rule is triggered when the virtual machine scale set's average percentage CPU metric is
greater than 85 percent for the past 10 minutes.
The scale-in rule is triggered when the virtual machine scale set's average is less than 60 percent for the
past minute.
NOTE
A setting can have multiple profiles. To learn more, see the profiles section. A profile can also have multiple scale-out rules
and scale-in rules defined. To see how they are evaluated, see the evaluation section.
{
"id": "/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/autoscalesettings/setting1",
"name": "setting1",
"type": "Microsoft.Insights/autoscaleSettings",
"location": "East US",
"properties": {
"enabled": true,
"targetResourceUri":
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/vmss1",
"profiles": [
{
"name": "mainProfile",
"capacity": {
"minimum": "1",
"maximum": "4",
"default": "1"
},
"rules": [
{
"metricTrigger": {
"metricResourceUri":
"statistic": "Average",
"timeWindow": "PT10M",
"threshold": 85
},
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"operator": "LessThan",
"threshold": 60
},
"scaleAction": {
"direction": "Decrease",
"value": "1",
"cooldown": "PT5M"
}
}
]
}
]
}
}
SECTION ELEMENT NAME DESCRIPTION

Setting ID The Autoscale setting's resource ID.

Autoscale settings are an Azure
Resource Manager resource.
Setting name The Autoscale setting name.
Setting location The location of the Autoscale setting.

This location can be different from the
location of the resource being scaled.
properties targetResourceUri The resource ID of the resource being

scaled. You can only have one Autoscale
setting per resource.
properties profiles An Autoscale setting is composed of

one or more profiles. Each time the
Autoscale engine runs, it executes one
profile.
profile name The name of the profile. You can choose

any name that helps you identify the
profile.
profile Capacity.maximum The maximum capacity allowed. It

ensures that Autoscale, when executing
this profile, does not scale your resource
above this number.
profile Capacity.minimum The minimum capacity allowed. It

ensures that Autoscale, when executing
this profile, does not scale your resource
below this number.
profile Capacity.default If there is a problem reading the

resource metric (in this case, the CPU of
“vmss1”), and the current capacity is
below the default, Autoscale scales out
to the default. This is to ensure the
availability of the resource. If the current
capacity is already higher than the
default capacity, Autoscale does not
scale in.
profile rules Autoscale automatically scales between

the maximum and minimum capacities,
by using the rules in the profile. You can
have multiple rules in a profile. Typically
there are two rules: one to determine
when to scale out, and the other to
determine when to scale in.
rule metricTrigger Defines the metric condition of the rule.
metricTrigger metricName The name of the metric.

metricTrigger metricResourceUri The resource ID of the resource that

emits the metric. In most cases, it is the
same as the resource being scaled. In
some cases, it can be different. For
example, you can scale a virtual
machine scale set based on the number
of messages in a storage queue.
metricTrigger timeGrain The metric sampling duration. For

example, TimeGrain = “PT1M” means
that the metrics should be aggregated
every 1 minute, by using the
aggregation method specified in the
statistic element.
metricTrigger statistic The aggregation method within the

timeGrain period. For example, statistic
= “Average” and timeGrain =
“PT1M” means that the metrics should
be aggregated every 1 minute, by
taking the average. This property
dictates how the metric is sampled.
metricTrigger timeWindow The amount of time to look back for

metrics. For example, timeWindow =
“PT10M” means that every time
Autoscale runs, it queries metrics for the
past 10 minutes. The time window
allows your metrics to be normalized,
and avoids reacting to transient spikes.
metricTrigger timeAggregation The aggregation method used to

aggregate the sampled metrics. For
example, TimeAggregation =
“Average” should aggregate the
sampled metrics by taking the average.
In the preceding case, take the ten 1-
minute samples, and average them.
rule scaleAction The action to take when the

metricTrigger of the rule is triggered.
scaleAction direction "Increase" to scale out, or "Decrease" to

scale in.
scaleAction value How much to increase or decrease the

capacity of the resource.
scaleAction cooldown The amount of time to wait after a scale

operation before scaling again. For
example, if cooldown = “PT10M”,
Autoscale does not attempt to scale
again for another 10 minutes. The
cooldown is to allow the metrics to
stabilize after the addition or removal of
instances.
Autoscale profiles
There are three types of Autoscale profiles:
Regular profile: The most common profile. If you don’t need to scale your resource based on the day of the
week, or on a particular day, you can use a regular profile. This profile can then be configured with metric
rules that dictate when to scale out and when to scale in. You should only have one regular profile defined.
The example profile used earlier in this article is an example of a regular profile. Note that it is also possible
to set a profile to scale to a static instance count for your resource.
Fixed date profile: This profile is for special cases. For example, let’s say you have an important event
coming up on December 26, 2017 (PST). You want the minimum and maximum capacities of your resource
to be different on that day, but still scale on the same metrics. In this case, you should add a fixed date profile
to your setting’s list of profiles. The profile is configured to run only on the event’s day. For any other day,
Autoscale uses the regular profile.
"profiles": [{
"name": " regularProfile",
"capacity": {
...
},
"rules": [{
...
},
{
...
}]
},
{
"name": "eventProfile",
"capacity": {
...
},
"rules": [{
...
}, {
...
}],
"fixedDate": {
"timeZone": "Pacific Standard Time",
"start": "2017-12-26T00:00:00",
"end": "2017-12-26T23:59:00"
}}
]
Recurrence profile: This type of profile enables you to ensure that this profile is always used on a
particular day of the week. Recurrence profiles only have a start time. They run until the next recurrence
profile or fixed date profile is set to start. An Autoscale setting with only one recurrence profile runs that
profile, even if there is a regular profile defined in the same setting. The following two examples illustrate
how this profile is used:
Example 1: Weekdays vs. weekends
Let’s say that on weekends, you want your maximum capacity to be 4. On weekdays, because you expect
more load, you want your maximum capacity to be 10. In this case, your setting would contain two
recurrence profiles, one to run on weekends and the other on weekdays. The setting looks like this:
"profiles": [
{
"name": "weekdayProfile",
"capacity": {
...
},
"rules": [{
...
}],
"recurrence": {
"frequency": "Week",
"schedule": {
"days": [
"Monday"
],
"hours": [
0
],
"minutes": [
0
]
}
}}
},
{
"name": "weekendProfile",
"capacity": {
...
},
"rules": [{
...
}]
"recurrence": {
"schedule": {
"days": [
"Saturday"
],
"hours": [
0
],
"minutes": [
0
]
}
}
}]
The preceding setting shows that each recurrence profile has a schedule. This schedule determines when the
profile starts running. The profile stops when it’s time to run another profile.
For example, in the preceding setting, “weekdayProfile” is set to start on Monday at 12:00 AM. That means
this profile starts running on Monday at 12:00 AM. It continues until Saturday at 12:00 AM, when
“weekendProfile” is scheduled to start running.
Example 2: Business hours
Let's say you want to have one metric threshold during business hours (9:00 AM to 5:00 PM ), and a
different one for all other times. The setting would look like this:
"profiles": [
{
"name": "businessHoursProfile",
"capacity": {
...
},
"rules": [{
...
}],
"recurrence": {
"schedule": {
"days": [
"Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
],
"hours": [
9
],
"minutes": [
0
]
}
}
},
{
"name": "nonBusinessHoursProfile",
"capacity": {
...
},
"rules": [{
...
}]
"recurrence": {
"schedule": {
"days": [
"Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
],
"hours": [
17
],
"minutes": [
0
]
}
}
}]
The preceding setting shows that “businessHoursProfile” begins running on Monday at 9:00 AM, and
continues to 5:00 PM. That’s when “nonBusinessHoursProfile” starts running. The
“nonBusinessHoursProfile” runs until 9:00 AM Tuesday, and then the “businessHoursProfile” takes over
again. This repeats until Friday at 5:00 PM. At that point, “nonBusinessHoursProfile” runs all the way to
Monday at 9:00 AM.
NOTE
The Autoscale user interface in the Azure portal enforces end times for recurrence profiles, and begins running the Autoscale
setting's default profile in between recurrence profiles.
Autoscale evaluation
Given that Autoscale settings can have multiple profiles, and each profile can have multiple metric rules, it is
important to understand how an Autoscale setting is evaluated. Each time the Autoscale job runs, it begins by
choosing the profile that is applicable. Then Autoscale evaluates the minimum and maximum values, and any
metric rules in the profile, and decides if a scale action is necessary.
Which profile will Autoscale pick?
Autoscale uses the following sequence to pick the profile:
1. It first looks for any fixed date profile that is configured to run now. If there is, Autoscale runs it. If there are
multiple fixed date profiles that are supposed to run, Autoscale selects the first one.
2. If there are no fixed date profiles, Autoscale looks at recurrence profiles. If a recurrence profile is found, it runs it.
3. If there are no fixed date or recurrence profiles, Autoscale runs the regular profile.
How does Autoscale evaluate multiple rules?
After Autoscale determines which profile to run, it evaluates all the scale-out rules in the profile (these are rules
with direction = “Increase”).
If one or more scale-out rules are triggered, Autoscale calculates the new capacity determined by the scaleAction
of each of those rules. Then it scales out to the maximum of those capacities, to ensure service availability.
For example, let's say there is a virtual machine scale set with a current capacity of 10. There are two scale-out
rules: one that increases capacity by 10 percent, and one that increases capacity by 3 counts. The first rule would
result in a new capacity of 11, and the second rule would result in a capacity of 13. To ensure service availability,
Autoscale chooses the action that results in the maximum capacity, so the second rule is chosen.
If no scale-out rules are triggered, Autoscale evaluates all the scale-in rules (rules with direction = “Decrease”).
Autoscale only takes a scale-in action if all of the scale-in rules are triggered.
Autoscale calculates the new capacity determined by the scaleAction of each of those rules. Then it chooses the
scale action that results in the maximum of those capacities to ensure service availability.
For example, let's say there is a virtual machine scale set with a current capacity of 10. There are two scale-in rules:
one that decreases capacity by 50 percent, and one that decreases capacity by 3 counts. The first rule would result
in a new capacity of 5, and the second rule would result in a capacity of 7. To ensure service availability, Autoscale
chooses the action that results in the maximum capacity, so the second rule is chosen.
Next steps
Learn more about Autoscale by referring to the following:
Overview of autoscale
Azure Monitor autoscale common metrics
Best practices for Azure Monitor autoscale
Use autoscale actions to send email and webhook alert notifications
Autoscale REST API
Best practices for Autoscale
Autoscale concepts
A resource can have only one autoscale setting
An autoscale setting can have one or more profiles and each profile can have one or more autoscale rules.
An autoscale setting scales instances horizontally, which is out by increasing the instances and in by decreasing
the number of instances. An autoscale setting has a maximum, minimum, and default value of instances.
An autoscale job always reads the associated metric to scale by, checking if it has crossed the configured
threshold for scale-out or scale-in. You can view a list of metrics that autoscale can scale by at Azure Monitor
autoscaling common metrics.
All thresholds are calculated at an instance level. For example, "scale out by one instance when average CPU >
80% when instance count is 2", means scale-out when the average CPU across all instances is greater than
80%.
All autoscale failures are logged to the Activity Log. You can then configure an activity log alert so that you can
be notified via email, SMS, or webhooks whenever there is an autoscale failure.
Similarly, all successful scale actions are posted to the Activity Log. You can then configure an activity log alert
so that you can be notified via email, SMS, or webhooks whenever there is a successful autoscale action. You
can also configure email or webhook notifications to get notified for successful scale actions via the
notifications tab on the autoscale setting.
Autoscale best practices

Use the following best practices as you use autoscale.
Ensure the maximum and minimum values are different and have an adequate margin between them
If you have a setting that has minimum=2, maximum=2 and the current instance count is 2, no scale action can
occur. Keep an adequate margin between the maximum and minimum instance counts, which are inclusive.
Autoscale always scales between these limits.
Manual scaling is reset by autoscale min and max
If you manually update the instance count to a value above or below the maximum, the autoscale engine
automatically scales back to the minimum (if below ) or the maximum (if above). For example, you set the range
between 3 and 6. If you have one running instance, the autoscale engine scales to three instances on its next run.
Likewise, if you manually set the scale to eight instances, on the next run autoscale will scale it back to six instances
on its next run. Manual scaling is temporary unless you reset the autoscale rules as well.
Always use a scale -out and scale -in rule combination that performs an increase and decrease
If you use only one part of the combination, autoscale will only take action in a single direction (scale out, or in)
until it reaches the maximum, or minimum instance counts of defined in the profile. This is not optimal, ideally you
want your resource to scale up at times of high usage to ensure availability. Similarly, at times of low usage you
want your resource to scale down, so you can realize cost savings.
Choose the appropriate statistic for your diagnostics metric
For diagnostics metrics, you can choose among Average, Minimum, Maximum and Total as a metric to scale by.
The most common statistic is Average.
Choose the thresholds carefully for all metric types
We recommend carefully choosing different thresholds for scale-out and scale-in based on practical situations.
We do not recommend autoscale settings like the examples below with the same or very similar threshold values
for out and in conditions:
Increase instances by 1 count when Thread Count <= 600
Decrease instances by 1 count when Thread Count >= 600
Let's look at an example of what can lead to a behavior that may seem confusing. Consider the following
sequence.
1. Assume there are two instances to begin with and then the average number of threads per instance grows to
625.
2. Autoscale scales out adding a third instance.
3. Next, assume that the average thread count across instance falls to 575.
4. Before scaling down, autoscale tries to estimate what the final state will be if it scaled in. For example, 575 x 3
(current instance count) = 1,725 / 2 (final number of instances when scaled down) = 862.5 threads. This means
autoscale would have to immediately scale-out again even after it scaled in, if the average thread count remains
the same or even falls only a small amount. However, if it scaled up again, the whole process would repeat,
leading to an infinite loop.
5. To avoid this situation (termed "flapping"), autoscale does not scale down at all. Instead, it skips and reevaluates
the condition again the next time the service's job executes. This can confuse many people because autoscale
wouldn't appear to work when the average thread count was 575.
Estimation during a scale-in is intended to avoid "flapping" situations, where scale-in and scale-out actions
continually go back and forth. Keep this behavior in mind when you choose the same thresholds for scale-out and
in.
We recommend choosing an adequate margin between the scale-out and in thresholds. As an example, consider
the following better rule combination.
Increase instances by 1 count when CPU% >= 80
Decrease instances by 1 count when CPU% <= 60
In this case
1. Assume there are 2 instances to start with.
2. If the average CPU% across instances goes to 80, autoscale scales out adding a third instance.
3. Now assume that over time the CPU% falls to 60.
4. Autoscale's scale-in rule estimates the final state if it were to scale-in. For example, 60 x 3 (current instance
count) = 180 / 2 (final number of instances when scaled down) = 90. So autoscale does not scale-in because it
would have to scale-out again immediately. Instead, it skips scaling down.
5. The next time autoscale checks, the CPU continues to fall to 50. It estimates again - 50 x 3 instance = 150 / 2
instances = 75, which is below the scale-out threshold of 80, so it scales in successfully to 2 instances.
Considerations for scaling threshold values for special metrics
For special metrics such as Storage or Service Bus Queue length metric, the threshold is the average number of
messages available per current number of instances. Carefully choose the threshold value for this metric.
Let's illustrate it with an example to ensure you understand the behavior better.
Increase instances by 1 count when Storage Queue message count >= 50
Decrease instances by 1 count when Storage Queue message count <= 10
Consider the following sequence:
1. There are two storage queue instances.
2. Messages keep coming and when you review the storage queue, the total count reads 50. You might assume
that autoscale should start a scale-out action. However, note that it is still 50/2 = 25 messages per instance. So,
scale-out does not occur. For the first scale-out to happen, the total message count in the storage queue should
be 100.
3. Next, assume that the total message count reaches 100.
4. A 3rd storage queue instance is added due to a scale-out action. The next scale-out action will not happen until
the total message count in the queue reaches 150 because 150/3 = 50.
5. Now the number of messages in the queue gets smaller. With three instances, the first scale-in action happens
when the total messages in all queues add up to 30 because 30/3 = 10 messages per instance, which is the
scale-in threshold.
Considerations for scaling when multiple profiles are configured in an autoscale setting
In an autoscale setting, you can choose a default profile, which is always applied without any dependency on
schedule or time, or you can choose a recurring profile or a profile for a fixed period with a date and time range.
When autoscale service processes them, it always checks in the following order:
1. Fixed Date profile
2. Recurring profile
3. Default ("Always") profile
If a profile condition is met, autoscale does not check the next profile condition below it. Autoscale only processes
one profile at a time. This means if you want to also include a processing condition from a lower-tier profile, you
must include those rules as well in the current profile.
Let's review this using an example:
The image below shows an autoscale setting with a default profile of minimum instances = 2 and maximum
instances = 10. In this example, rules are configured to scale-out when the message count in the queue is greater
than 10 and scale-in when the message count in the queue is less than three. So now the resource can scale
between two and ten instances.
In addition, there is a recurring profile set for Monday. It is set for minimum instances = 3 and maximum instances
= 10. This means on Monday, the first-time autoscale checks for this condition, if the instance count is two, it scales
to the new minimum of three. As long as autoscale continues to find this profile condition matched (Monday), it
only processes the CPU -based scale-out/in rules configured for this profile. At this time, it does not check for the
queue length. However, if you also want the queue length condition to be checked, you should include those rules
from the default profile as well in your Monday profile.
Similarly, when autoscale switches back to the default profile, it first checks if the minimum and maximum
conditions are met. If the number of instances at the time is 12, it scales in to 10, the maximum allowed for the
default profile.
Considerations for scaling when multiple rules are configured in a profile
There are cases where you may have to set multiple rules in a profile. The following set of autoscale rules are used
by services use when multiple rules are set.
On scale out, autoscale runs if any rule is met. On scale-in, autoscale require all rules to be met.
To illustrate, assume that you have the following four autoscale rules:
If CPU < 30 %, scale-in by 1
If Memory < 50%, scale-in by 1
If CPU > 75%, scale-out by 1
If Memory > 75%, scale-out by 1
Then the follow occurs:
If CPU is 76% and Memory is 50%, we scale-out.
If CPU is 50% and Memory is 76% we scale-out.
On the other hand, if CPU is 25% and memory is 51% autoscale does not scale-in. In order to scale-in, CPU must
be 29% and Memory 49%.
Always select a safe default instance count
The default instance count is important autoscale scales your service to that count when metrics are not available.
Therefore, select a default instance count that's safe for your workloads.
Configure autoscale notifications
Autoscale will post to the Activity Log if any of the following conditions occur:
Autoscale issues a scale operation
Autoscale service successfully completes a scale action
Autoscale service fails to take a scale action.
Metrics are not available for autoscale service to make a scale decision.
Metrics are available (recovery) again to make a scale decision.
You can also use an Activity Log alert to monitor the health of the autoscale engine. Here are examples to create
an Activity Log Alert to monitor all autoscale engine operations on your subscription or to create an Activity Log
Alert to monitor all failed autoscale scale in/scale out operations on your subscription.
In addition to using activity log alerts, you can also configure email or webhook notifications to get notified for
successful scale actions via the notifications tab on the autoscale setting.
Next Steps
Create an Activity Log Alert to monitor all autoscale engine operations on your subscription.
Create an Activity Log Alert to monitor all failed autoscale scale in/scale out operations on your subscription
Azure Monitor autoscaling common metrics
NOTE
PowerShell.
Azure Monitor autoscaling allows you to scale the number of running instances up or down, based on telemetry
data (metrics). This document describes common metrics that you might want to use. In the Azure portal, you can
choose the metric of the resource to scale by. However, you can also choose any metric from a different resource
to scale by.
API Management services. Other Azure services use different scaling methods.
Compute metrics for Resource Manager-based VMs

By default, Resource Manager-based Virtual Machines and Virtual Machine Scale Sets emit basic (host-level)
metrics. In addition, when you configure diagnostics data collection for an Azure VM and VMSS, the Azure
diagnostic extension also emits guest-OS performance counters (commonly known as "guest-OS metrics"). You
use all these metrics in autoscale rules.
You can use the Get MetricDefinitions API/PoSH/CLI to view the metrics available for your VMSS resource.
If you're using VM scale sets and you don't see a particular metric listed, then it is likely disabled in your
diagnostics extension.
If a particular metric is not being sampled or transferred at the frequency you want, you can update the
diagnostics configuration.
If either preceding case is true, then review Use PowerShell to enable Azure Diagnostics in a virtual machine
running Windows about PowerShell to configure and update your Azure VM Diagnostics extension to enable the
metric. That article also includes a sample diagnostics configuration file.
Host metrics for Resource Manager-based Windows and Linux VMs
The following host-level metrics are emitted by default for Azure VM and VMSS in both Windows and Linux
instances. These metrics describe your Azure VM, but are collected from the Azure VM host rather than via agent
installed on the guest VM. You may use these metrics in autoscaling rules.
Host metrics for Resource Manager-based Windows and Linux VMs
Host metrics for Resource Manager-based Windows and Linux VM Scale Sets
Guest OS metrics Resource Manager-based Windows VMs
When you create a VM in Azure, diagnostics is enabled by using the Diagnostics extension. The diagnostics
extension emits a set of metrics taken from inside of the VM. This means you can autoscale off of metrics that are
not emitted by default.
You can generate a list of the metrics by using the following command in PowerShell.
Get-AzMetricDefinition -ResourceId <resource_id> | Format-Table -Property Name,Unit
You can create an alert for the following metrics:
METRIC NAME UNIT
\Processor(_Total)% Processor Time Percent
\Processor(_Total)% Privileged Time Percent
\Processor(_Total)% User Time Percent
\Processor Information(_Total)\Processor Frequency Count
\System\Processes Count
\Process(_Total)\Thread Count Count
\Process(_Total)\Handle Count Count
\Memory% Committed Bytes In Use Percent
\Memory\Available Bytes Bytes
\Memory\Committed Bytes Bytes
\Memory\Commit Limit Bytes
\Memory\Pool Paged Bytes Bytes
\Memory\Pool Nonpaged Bytes Bytes
\PhysicalDisk(_Total)% Disk Time Percent
\PhysicalDisk(_Total)% Disk Read Time Percent
\PhysicalDisk(_Total)% Disk Write Time Percent
\PhysicalDisk(_Total)\Disk Transfers/sec CountPerSecond
\PhysicalDisk(_Total)\Disk Reads/sec CountPerSecond
\PhysicalDisk(_Total)\Disk Writes/sec CountPerSecond
\PhysicalDisk(_Total)\Disk Bytes/sec BytesPerSecond
\PhysicalDisk(_Total)\Disk Read Bytes/sec BytesPerSecond
\PhysicalDisk(_Total)\Disk Write Bytes/sec BytesPerSecond
\PhysicalDisk(_Total)\Avg. Disk Queue Length Count

METRIC NAME UNIT
\PhysicalDisk(_Total)\Avg. Disk Read Queue Length Count
\PhysicalDisk(_Total)\Avg. Disk Write Queue Length Count
\LogicalDisk(_Total)% Free Space Percent
\LogicalDisk(_Total)\Free Megabytes Count
Guest OS metrics Linux VMs

When you create a VM in Azure, diagnostics is enabled by default by using Diagnostics extension.
You can generate a list of the metrics by using the following command in PowerShell.
You can create an alert for the following metrics:
METRIC NAME UNIT
\Memory\AvailableMemory Bytes
\Memory\PercentAvailableMemory Percent
\Memory\UsedMemory Bytes
\Memory\PercentUsedMemory Percent
\Memory\PercentUsedByCache Percent
\Memory\PagesPerSec CountPerSecond
\Memory\PagesReadPerSec CountPerSecond
\Memory\PagesWrittenPerSec CountPerSecond
\Memory\AvailableSwap Bytes
\Memory\PercentAvailableSwap Percent
\Memory\UsedSwap Bytes
\Memory\PercentUsedSwap Percent
\Processor\PercentIdleTime Percent
\Processor\PercentUserTime Percent
\Processor\PercentNiceTime Percent
\Processor\PercentPrivilegedTime Percent
METRIC NAME UNIT
\Processor\PercentInterruptTime Percent
\Processor\PercentDPCTime Percent
\Processor\PercentProcessorTime Percent
\Processor\PercentIOWaitTime Percent
\PhysicalDisk\BytesPerSecond BytesPerSecond
\PhysicalDisk\ReadBytesPerSecond BytesPerSecond
\PhysicalDisk\WriteBytesPerSecond BytesPerSecond
\PhysicalDisk\TransfersPerSecond CountPerSecond
\PhysicalDisk\ReadsPerSecond CountPerSecond
\PhysicalDisk\WritesPerSecond CountPerSecond
\PhysicalDisk\AverageReadTime Seconds
\PhysicalDisk\AverageWriteTime Seconds
\PhysicalDisk\AverageTransferTime Seconds
\PhysicalDisk\AverageDiskQueueLength Count
\NetworkInterface\BytesTransmitted Bytes
\NetworkInterface\BytesReceived Bytes
\NetworkInterface\PacketsTransmitted Count
\NetworkInterface\PacketsReceived Count
\NetworkInterface\BytesTotal Bytes
\NetworkInterface\TotalRxErrors Count
\NetworkInterface\TotalTxErrors Count
\NetworkInterface\TotalCollisions Count
Commonly used Web (Server Farm) metrics

You can also perform autoscale based on common web server metrics such as the Http queue length. It's metric
name is HttpQueueLength. The following section lists available server farm (Web Apps) metrics.
Web Apps metrics
You can generate a list of the Web Apps metrics by using the following command in PowerShell.
You can alert on or scale by these metrics.
METRIC NAME UNIT
CpuPercentage Percent
MemoryPercentage Percent
DiskQueueLength Count
HttpQueueLength Count
BytesReceived Bytes
BytesSent Bytes
Commonly used Storage metrics

You can scale by Storage queue length, which is the number of messages in the storage queue. Storage queue
length is a special metric and the threshold is the number of messages per instance. For example, if there are two
instances and if the threshold is set to 100, scaling occurs when the total number of messages in the queue is 200.
That can be 100 messages per instance, 120 and 80, or any other combination that adds up to 200 or more.
Configure this setting in the Azure portal in the Settings blade. For VM scale sets, you can update the Autoscale
setting in the Resource Manager template to use metricName as ApproximateMessageCount and pass the ID of
the storage queue as metricResourceUri.
For example, with a Classic Storage Account the autoscale setting metricTrigger would include:
"metricName": "ApproximateMessageCount",
"metricNamespace": "",
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.ClassicStorage/storageAccoun
ts/STORAGE_ACCOUNT_NAME/services/queue/queues/QUEUE_NAME"
For a (non-classic) storage account, the metricTrigger would include:
"metricName": "ApproximateMessageCount",
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.Storage/storageAccounts/STOR
AGE_ACCOUNT_NAME/services/queue/queues/QUEUE_NAME"
Commonly used Service Bus metrics

You can scale by Service Bus queue length, which is the number of messages in the Service Bus queue. Service
Bus queue length is a special metric and the threshold is the number of messages per instance. For example, if
there are two instances and if the threshold is set to 100, scaling occurs when the total number of messages in the
queue is 200. That can be 100 messages per instance, 120 and 80, or any other combination that adds up to 200
or more.
For VM scale sets, you can update the Autoscale setting in the Resource Manager template to use metricName as
ApproximateMessageCount and pass the ID of the storage queue as metricResourceUri.
"metricName": "MessageCount",
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.ServiceBus/namespaces/SB_NAM
ESPACE/queues/QUEUE_NAME"
NOTE
For Service Bus, the resource group concept does not exist but Azure Resource Manager creates a default resource group
per region. The resource group is usually in the 'Default-ServiceBus-[region]' format. For example, 'Default-ServiceBus-
EastUS', 'Default-ServiceBus-WestUS', 'Default-ServiceBus-AustraliaEast' etc.
Overview of common autoscale patterns
This article describes some of the common patterns to scale your resource in Azure.
Lets get started

This article assumes that you are familiar with auto scale. You can get started here to scale your resource. The
following are some of the common scale patterns.
Scale based on CPU

You have a web app (/VMSS/cloud service role) and
You want to scale out/scale in based on CPU.
Additionally, you want to ensure there is a minimum number of instances.
Also, you want to ensure that you set a maximum limit to the number of instances you can scale to.
Scale differently on weekdays vs weekends

You want 3 instances by default (on weekdays)
You don't expect traffic on weekends and hence you want to scale down to 1 instance on weekends.
Scale differently during holidays
You want to scale up/down based on CPU usage by default
However, during holiday season (or specific days that are important for your business) you want to override the
defaults and have more capacity at your disposal.
Scale based on custom metric

You have a web front end and an API tier that communicates with the backend.
You want to scale the API tier based on custom events in the front end (example: You want to scale your
checkout process based on the number of items in the shopping cart)
Get started with auto scale by custom metric in Azure
This article describes how to scale your resource by a custom metric in Azure portal.
Lets get started

This article assumes that you have a web app with application insights configured. If you don't have one already,
you can set up Application Insights for your ASP.NET website
Open Azure portal
Click on Azure Monitor icon in the left navigation pane.
Click on Autoscale setting to view all the resources for which auto scale is applicable, along with its current
autoscale status
Open 'Autoscale' blade in Azure Monitor and select a resource you want to scale
Note: The steps below use an app service plan associated with a web app that has app insights
configured.
In the scale setting blade for the resource, notice that the current instance count is 1. Click on 'Enable autoscale'.
Provide a name for the scale setting, and the click on "Add a rule". Notice the scale rule options that opens as a
context pane in the right hand side. By default, it sets the option to scale your instance count by 1 if the CPU
percentage of the resource exceeds 70%. Change the metric source at the top to "Application Insights", select
the app insights resource in the 'Resource' dropdown and then select the custom metric based on which you
want to scale.
Similar to the step above, add a scale rule that will scale in and decrease the scale count by 1 if the custom
metric is below a threshold.
Set the you instance limits. For example, if you want to scale between 2-5 instances depending on the custom
metric fluctuations, set 'minimum' to '2', 'maximum' to '5' and 'default' to '2'
Note: In case there is a problem reading the resource metrics and the current capacity is below the
default capacity, then to ensure the availability of the resource, Autoscale will scale out to the default
value. If the current capacity is already higher than default capacity, Autoscale will not scale in.
Click on 'Save'
Congratulations. You now successfully created your scale setting to auto scale your web app based on a custom
metric.
Note: The same steps are applicable to get started with a VMSS or cloud service role.
2 minutes to read
Advanced autoscale configuration using Resource
Manager templates for VM Scale Sets
You can scale-in and scale-out in Virtual Machine Scale Sets based on performance metric thresholds, by a
recurring schedule, or by a particular date. You can also configure email and webhook notifications for scale
actions. This walkthrough shows an example of configuring all these objects using a Resource Manager template
on a VM Scale Set.
NOTE
While this walkthrough explains the steps for VM Scale Sets, the same information applies to autoscaling Cloud Services, App
Service - Web Apps, and API Management services For a simple scale in/out setting on a VM Scale Set based on a simple
performance metric such as CPU, refer to the Linux and Windows documents
Walkthrough
In this walkthrough, we use Azure Resource Explorer to configure and update the autoscale setting for a scale set.
Azure Resource Explorer is an easy way to manage Azure resources via Resource Manager templates. If you are
new to Azure Resource Explorer tool, read this introduction.
1. Deploy a new scale set with a basic autoscale setting. This article uses the one from the Azure QuickStart
Gallery, which has a Windows scale set with a basic autoscale template. Linux scale sets work the same way.
2. After the scale set is created, navigate to the scale set resource from Azure Resource Explorer. You see the
following under Microsoft.Insights node.
The template execution has created a default autoscale setting with the name 'autoscalewad'. On the
right-hand side, you can view the full definition of this autoscale setting. In this case, the default autoscale
setting comes with a CPU% based scale-out and scale-in rule.
3. You can now add more profiles and rules based on the schedule or specific requirements. We create an
autoscale setting with three profiles. To understand profiles and rules in autoscale, review Autoscale Best
Practices.
PROFILES & RULES DESCRIPTION
Profile Performance/metric based
Rule Service Bus Queue Message Count > x
Rule Service Bus Queue Message Count < y
Rule CPU% > n
Rule CPU% < p
Profile Weekday morning hours (no rules)
Profile Product Launch day (no rules)
4. Here is a hypothetical scaling scenario that we use for this walk-through.

Load based - I'd like to scale out or in based on the load on my application hosted on my scale set.*
Message Queue size - I use a Service Bus Queue for the incoming messages to my application. I
use the queue's message count and CPU% and configure a default profile to trigger a scale action if
either of message count or CPU hits the threshold.*
Time of week and day - I want a weekly recurring 'time of the day' based profile called 'Weekday
Morning Hours'. Based on historical data, I know it is better to have certain number of VM instances
to handle my application's load during this time.*
Special Dates - I added a 'Product Launch Day' profile. I plan ahead for specific dates so my
application is ready to handle the load due marketing announcements and when we put a new
product in the application.*
The last two profiles can also have other performance metric based rules within them. In this case, I
decided not to have one and instead to rely on the default performance metric based rules. Rules are
optional for the recurring and date-based profiles.
Autoscale engine's prioritization of the profiles and rules is also captured in the autoscaling best
practices article. For a list of common metrics for autoscale, refer Common metrics for Autoscale
5. Make sure you are on the Read/Write mode in Resource Explorer
6. Click Edit. Replace the 'profiles' element in autoscale setting with the following configuration:
{
"name": "Perf_Based_Scale",
"capacity": {
"minimum": "2",
"maximum": "12",
"default": "2"
},
"rules": [
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue",
"threshold": 10
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue",
"threshold": 3
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/<this_vmss_na
me>",
"threshold": 85
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/<this_vmss_na
me>",
"threshold": 60
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
}
]
},
{
"name": "Weekday_Morning_Hours_Scale",
"capacity": {
"minimum": "4",
"maximum": "12",
"default": "4"
},
"rules": [],
"recurrence": {
"schedule": {
"days": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"hours": [
6
],
"minutes": [
0
]
}
}
}
},
{
"name": "Product_Launch_Day",
"capacity": {
"minimum": "6",
"maximum": "20",
"default": "6"
},
"rules": [],
"fixedDate": {
"start": "2016-06-20T00:06:00Z",
"end": "2016-06-21T23:59:00Z"
}
}
For supported fields and their values, see Autoscale REST API documentation. Now your autoscale setting
contains the three profiles explained previously.
7. Finally, look at the Autoscale notification section. Autoscale notifications allow you to do three things
when a scale-out or in action is successfully triggered.
Notify the admin and co-admins of your subscription
Email a set of users
Trigger a webhook call. When fired, this webhook sends metadata about the autoscaling condition and
the scale set resource. To learn more about the payload of autoscale webhook, see Configure Webhook
& Email Notifications for Autoscale.
Add the following to the Autoscale setting replacing your notification element whose value is null
"notifications": [
{
"operation": "Scale",
"email": {
"sendToSubscriptionAdministrator": true,
"sendToSubscriptionCoAdministrators": false,
"customEmails": [
"user1@mycompany.com",
"user2@mycompany.com"
]
},
"webhooks": [
{
"serviceUri": "https://foo.webhook.example.com?token=abcd1234",
"properties": {
"optional_key1": "optional_value1",
"optional_key2": "optional_value2"
}
}
]
}
]
Hit Put button in Resource Explorer to update the autoscale setting.

You have updated an autoscale setting on a VM Scale set to include multiple scale profiles and scale notifications.
Next Steps
Use these links to learn more about autoscaling.
TroubleShoot Autoscale with Virtual Machine Scale Sets
Common Metrics for Autoscale
Best Practices for Azure Autoscale
Manage Autoscale using PowerShell
Manage Autoscale using CLI
Configure Webhook & Email Notifications for Autoscale
Microsoft.Insights/autoscalesettings template reference
Use autoscale actions to send email and webhook
alert notifications in Azure Monitor
This article shows you how set up triggers so that you can call specific web URLs or send emails based on
autoscale actions in Azure.
Webhooks
Webhooks allow you to route the Azure alert notifications to other systems for post-processing or custom
notifications. For example, routing the alert to services that can handle an incoming web request to send SMS, log
bugs, notify a team using chat or messaging services, etc. The webhook URI must be a valid HTTP or HTTPS
endpoint.
Email
Email can be sent to any valid email address. Administrators and co-administrators of the subscription where the
rule is running will also be notified.
Cloud Services and Web Apps

You can opt-in from the Azure portal for Cloud Services and Server Farms (Web Apps).
Choose the scale by metric.
Virtual Machine scale sets

For newer Virtual Machines created with Resource Manager (Virtual Machine scale sets), you can configure this
using REST API, Resource Manager templates, PowerShell, and CLI. A portal interface is not yet available. When
using the REST API or Resource Manager template, include the notifications element with the following options.
"notifications": [
{
"operation": "Scale",
"email": {
"sendToSubscriptionAdministrator": false,
"sendToSubscriptionCoAdministrators": false,
"customEmails": [
"user1@mycompany.com",
"user2@mycompany.com"
]
},
"webhooks": [
{
"serviceUri": "https://foo.webhook.example.com?token=abcd1234",
"properties": {
"optional_key1": "optional_value1",
"optional_key2": "optional_value2"
}
}
]
}
]
FIELD MANDATORY? DESCRIPTION
operation yes value must be "Scale"
sendToSubscriptionAdministrator yes value must be "true" or "false"
sendToSubscriptionCoAdministrators yes value must be "true" or "false"
customEmails yes value can be null [] or string array of

emails
webhooks yes value can be null or valid Uri
serviceUri yes a valid https Uri
properties yes value must be empty {} or can contain

key-value pairs
Authentication in webhooks
The webhook can authenticate using token-based authentication, where you save the webhook URI with a token
ID as a query parameter. For example, https://mysamplealert/webcallback?
tokenid=sometokenid&someparameter=somevalue
Autoscale notification webhook payload schema

When the autoscale notification is generated, the following metadata is included in the webhook payload:
{
"version": "1.0",
"operation": "Scale In",
"context": {
"timestamp": "2016-03-11T07:31:04.5834118Z",
"id":
"/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/autoscalesettings/myautoscaleSetting",
"name": "myautoscaleSetting",
"details": "Autoscale successfully started scale operation for resource 'MyCSRole' from
capacity '3' to capacity '2'",
"subscriptionId": "s1",
"resourceGroupName": "rg1",
"resourceName": "MyCSRole",
"resourceType": "microsoft.classiccompute/domainnames/slots/roles",
"resourceId":
"/subscriptions/s1/resourceGroups/rg1/providers/microsoft.classicCompute/domainNames/myCloudService/slots/Prod
uction/roles/MyCSRole",
"portalLink":
"https://portal.azure.com/#resource/subscriptions/s1/resourceGroups/rg1/providers/microsoft.classicCompute/dom
ainNames/myCloudService",
"oldCapacity": "3",
"newCapacity": "2"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
status yes The status that indicates that an

autoscale action was generated
operation yes For an increase of instances, it will be

"Scale Out" and for a decrease in
instances, it will be "Scale In"
context yes The autoscale action context
timestamp yes Time stamp when the autoscale action

was triggered
id Yes Resource Manager ID of the autoscale

setting
name Yes The name of the autoscale setting
details Yes Explanation of the action that the

autoscale service took and the change
in the instance count
subscriptionId Yes Subscription ID of the target resource

that is being scaled
resourceGroupName Yes Resource Group name of the target

resource that is being scaled
resourceName Yes Name of the target resource that is

being scaled
resourceType Yes The three supported values:

"microsoft.classiccompute/domainname
s/slots/roles" - Cloud Service roles,
"microsoft.compute/virtualmachinescale
sets" - Virtual Machine Scale Sets, and
"Microsoft.Web/serverfarms" - Web
App
resourceId Yes Resource Manager ID of the target

resource that is being scaled
portalLink Yes Azure portal link to the summary page

of the target resource
oldCapacity Yes The current (old) instance count when

Autoscale took a scale action
newCapacity Yes The new instance count that Autoscale

scaled the resource to
properties No Optional. Set of <Key, Value> pairs (for

example, Dictionary <String, String>).
The properties field is optional. In a
custom user interface or Logic app
based workflow, you can enter keys and
values that can be passed using the
payload. An alternate way to pass
custom properties back to the outgoing
webhook call is to use the webhook URI
itself (as query parameters)
Azure Monitor PowerShell quick start samples
This article shows you sample PowerShell commands to help you access Azure Monitor features.
NOTE
Azure Monitor is the new name for what was called "Azure Insights" until Sept 25th, 2016. However, the namespaces and
thus the following commands still contain the word "insights."
NOTE
PowerShell.
Set up PowerShell
If you haven't already, set up PowerShell to run on your computer. For more information, seeHow to Install and
Configure PowerShell.
Examples in this article

The examples in the article illustrate how you can use Azure Monitor cmdlets. You can also review the entire list of
Azure Monitor PowerShell cmdlets at Azure Monitor (Insights) Cmdlets.
Sign in and use subscriptions

First, log in to your Azure subscription.
Connect-AzAccount
You'll see a sign in screen. Once you sign in your Account, TenantID, and default Subscription ID are displayed. All
the Azure cmdlets work in the context of your default subscription. To view the list of subscriptions you have
access to, use the following command:
Get-AzSubscription
To see your working context (which subscription your commands are run against), use the following command:
Get-AzContext
To change your working context to a different subscription, use the following command:
Set-AzContext -SubscriptionId <subscriptionid>

Retrieve Activity log for a subscription
Use the Get-AzLog cmdlet. The following are some common examples. The Activity Log holds the last 90 days of
operations. Using dates before this time results in an error message.
See what the current date/time are to verify what times to use in the commands below:
Get-Date
Get log entries from this time/date to present:
Get-AzLog -StartTime 2019-03-01T10:30
Get log entries between a time/date range:
Get-AzLog -StartTime 2019-01-01T10:30 -EndTime 2015-01-01T11:30
Get-AzLog -ResourceGroup 'myrg1'
Get log entries from a specific resource provider between a time/date range:
Get-AzLog -ResourceProvider 'Microsoft.Web' -StartTime 2015-01-01T10:30 -EndTime 2015-01-01T11:30
Get all log entries with a specific caller:
Get-AzLog -Caller 'myname@company.com'
The following command retrieves the last 1000 events from the activity log:
Get-AzLog -MaxRecord 10
Get-AzLog supports many other parameters. See the Get-AzLog reference for more information.
NOTE
Get-AzLog only provides 15 days of history. Using the -MaxRecords parameter allows you to query the last N events,
beyond 15 days. To access events older than 15 days, use the REST API or SDK (C# sample using the SDK). If you do not
include StartTime, then the default value is EndTime minus one hour. If you do not include EndTime, then the default value
is current time. All times are in UTC.
Retrieve alerts history

To view all alert events, you can query the Azure Resource Manager logs using the following examples.
Get-AzLog -Caller "Microsoft.Insights/alertRules" -DetailedOutput -StartTime 2015-03-01
To view the history for a specific alert rule, you can use the Get-AzAlertHistory cmdlet, passing in the resource ID
of the alert rule.
Get-AzAlertHistory -ResourceId
/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/alertrules/myalert -StartTime 2016-03-1 -
Status Activated
The Get-AzAlertHistory cmdlet supports various parameters. More information, see Get-AlertHistory.
Retrieve information on alert rules

All of the following commands act on a Resource Group named "montest".
View all the properties of the alert rule:
Get-AzAlertRule -Name simpletestCPU -ResourceGroup montest -DetailedOutput
Retrieve all alerts on a resource group:
Get-AzAlertRule -ResourceGroup montest
Retrieve all alert rules set for a target resource. For example, all alert rules set on a VM.
Get-AzAlertRule -ResourceGroup montest -TargetResourceId

/subscriptions/s1/resourceGroups/montest/providers/Microsoft.Compute/virtualMachines/testconfig
Get-AzAlertRule supports other parameters. See Get-AlertRule for more information.
Create metric alerts

You can use the Add-AlertRule cmdlet to create, update, or disable an alert rule.
You can create email and webhook properties using New-AzAlertRuleEmail and New-AzAlertRuleWebhook ,
respectively. In the Alert rule cmdlet, assign these properties as actions to the Actions property of the Alert Rule.
The following table describes the parameters and values used to create an alert using a metric.
PARAMETER VALUE
Name simpletestdiskwrite
Location of this alert rule East US
ResourceGroup montest
TargetResourceId /subscriptions/s1/resourceGroups/montest/providers/Microso
ft.Compute/virtualMachines/testconfig
MetricName of the alert that is created \PhysicalDisk(_Total)\Disk Writes/sec. See the

Get-MetricDefinitions cmdlet about how to retrieve the
exact metric names
operator GreaterThan
PARAMETER VALUE
Threshold value (count/sec in for this metric) 1
WindowSize (hh:mm:ss format) 00:05:00
aggregator (statistic of the metric, which uses Average count, Average

in this case)
custom emails (string array) 'foo@example.com','bar@example.com'
send email to owners, contributors and readers -SendToServiceOwners
Create an Email action
$actionEmail = New-AzAlertRuleEmail -CustomEmail myname@company.com
Create a Webhook action
$actionWebhook = New-AzAlertRuleWebhook -ServiceUri https://example.com?token=mytoken
Create the alert rule on the CPU% metric on a classic VM
Add-AzMetricAlertRule -Name vmcpu_gt_1 -Location "East US" -ResourceGroup myrg1 -TargetResourceId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.ClassicCompute/virtualMachines/my_vm1 -MetricName
"Percentage CPU" -Operator GreaterThan -Threshold 1 -WindowSize 00:05:00 -TimeAggregationOperator Average -
Action $actionEmail, $actionWebhook -Description "alert on CPU > 1%"
Retrieve the alert rule
Get-AzAlertRule -Name vmcpu_gt_1 -ResourceGroup myrg1 -DetailedOutput
The Add alert cmdlet also updates the rule if an alert rule already exists for the given properties. To disable an alert
rule, include the parameter -DisableRule.
Get a list of available metrics for alerts

You can use the Get-AzMetricDefinition cmdlet to view the list of all metrics for a specific resource.
Get-AzMetricDefinition -ResourceId <resource_id>
The following example generates a table with the metric Name and the Unit for it.
A full list of available options for Get-AzMetricDefinition is available at Get-MetricDefinitions.
Create and manage Activity Log alerts

You can use the Set-AzActivityLogAlert cmdlet to set an Activity Log alert. An Activity Log alert requires that you
first define your conditions as a dictionary of conditions, then create an alert that uses those conditions.
$condition1 = New-AzActivityLogAlertCondition -Field 'category' -Equal 'Administrative'
$condition2 = New-AzActivityLogAlertCondition -Field 'operationName' -Equal
'Microsoft.Compute/virtualMachines/write'
$additionalWebhookProperties = New-Object
"System.Collections.Generic.Dictionary``2[System.String,System.String]"
$additionalWebhookProperties.Add('customProperty', 'someValue')
$actionGrp1 = New-AzActionGroup -ActionGroupId '/subscriptions/<subid>/providers/Microsoft.Insights/actiongr1'
-WebhookProperty $additionalWebhookProperties
Set-AzActivityLogAlert -Location 'Global' -Name 'alert on VM create' -ResourceGroupName 'myResourceGroup' -
Scope '/subscriptions/<subid>' -Action $actionGrp1 -Condition $condition1, $condition2
The additional webhook properties are optional. You can get back the contents of an Activity Log Alert using
Get-AzActivityLogAlert .
Create and manage AutoScale settings

A resource (a Web app, VM, Cloud Service, or Virtual Machine Scale Set) can have only one autoscale setting
configured for it. However, each autoscale setting can have multiple profiles. For example, one for a performance-
based scale profile and a second one for a schedule-based profile. Each profile can have multiple rules configured
on it. For more information about Autoscale, see How to Autoscale an Application.
Here are the steps to use:
1. Create rule(s).
2. Create profile(s) mapping the rules that you created previously to the profiles.
3. Optional: Create notifications for autoscale by configuring webhook and email properties.
4. Create an autoscale setting with a name on the target resource by mapping the profiles and notifications that
you created in the previous steps.
The following examples show you how you can create an Autoscale setting for a Virtual Machine Scale Set for a
Windows operating system based by using the CPU utilization metric.
First, create a rule to scale out, with an instance count increase.
$rule1 = New-AzAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -Operator
GreaterThan -MetricStatistic Average -Threshold 60 -TimeGrain 00:01:00 -TimeWindow 00:10:00 -
ScaleActionCooldown 00:10:00 -ScaleActionDirection Increase -ScaleActionValue 1
Next, create a rule to scale in, with an instance count decrease.
$rule2 = New-AzAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -Operator
GreaterThan -MetricStatistic Average -Threshold 30 -TimeGrain 00:01:00 -TimeWindow 00:10:00 -
ScaleActionCooldown 00:10:00 -ScaleActionDirection Decrease -ScaleActionValue 1
Then, create a profile for the rules.
$profile1 = New-AzAutoscaleProfile -DefaultCapacity 2 -MaximumCapacity 10 -MinimumCapacity 2 -Rules

$rule1,$rule2 -Name "My_Profile"
Create a webhook property.

$webhook_scale = New-AzAutoscaleWebhook -ServiceUri "https://example.com?mytoken=mytokenvalue"
Create the notification property for the autoscale setting, including email and the webhook that you created
previously.
$notification1= New-AzAutoscaleNotification -CustomEmails ashwink@microsoft.com -

SendEmailToSubscriptionAdministrators SendEmailToSubscriptionCoAdministrators -Webhooks $webhook_scale
Finally, create the autoscale setting to add the profile that you created previously.
Add-AzAutoscaleSetting -Location "East US" -Name "MyScaleVMSSSetting" -ResourceGroup big2 -TargetResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -
AutoscaleProfiles $profile1 -Notifications $notification1
For more information about managing Autoscale settings, see Get-AutoscaleSetting.
Autoscale history
The following example shows you how you can view recent autoscale and alert events. Use the activity log search
to view the autoscale history.
Get-AzLog -Caller "Microsoft.Insights/autoscaleSettings" -DetailedOutput -StartTime 2015-03-01
You can use the Get-AzAutoScaleHistory cmdlet to retrieve AutoScale history.
Get-AzAutoScaleHistory -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/microsoft.insights/autoscalesettings/myScaleSetting -
StartTime 2016-03-15 -DetailedOutput
For more information, see Get-AutoscaleHistory.

View details for an autoscale setting
You can use the Get-Autoscalesetting cmdlet to retrieve more information about the autoscale setting.
The following example shows details about all autoscale settings in the resource group 'myrg1'.
Get-AzAutoscalesetting -ResourceGroup myrg1 -DetailedOutput
The following example shows details about all autoscale settings in the resource group 'myrg1' and specifically the
autoscale setting named 'MyScaleVMSSSetting'.
Get-AzAutoscalesetting -ResourceGroup myrg1 -Name MyScaleVMSSSetting -DetailedOutput
Remove an autoscale setting

You can use the Remove-Autoscalesetting cmdlet to delete an autoscale setting.
Remove-AzAutoscalesetting -ResourceGroup myrg1 -Name MyScaleVMSSSetting
Manage log profiles for activity log

You can create a log profile and export data from your activity log to a storage account and you can configure data
retention for it. Optionally, you can also stream the data to your Event Hub. This feature is currently in Preview and
you can only create one log profile per subscription. You can use the following cmdlets with your current
subscription to create and manage log profiles. You can also choose a particular subscription. Although
PowerShell defaults to the current subscription, you can always change that using Set-AzContext . You can
configure activity log to route data to any storage account or Event Hub within that subscription. Data is written as
blob files in JSON format.
Get a log profile
To fetch your existing log profiles, use the Get-AzLogProfile cmdlet.
Add a log profile without data retention
Add-AzLogProfile -Name my_log_profile_s1 -StorageAccountId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -Location
global,westus,eastus,northeurope,westeurope,eastasia,southeastasia,japaneast,japanwest,northcentralus,southcen
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia
Remove a log profile
Remove-AzLogProfile -name my_log_profile_s1
Add a log profile with data retention

You can specify the -RetentionInDays property with the number of days, as a positive integer, where the data is
retained.

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -Location
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia -
RetentionInDays 90
Add log profile with retention and EventHub

In addition to routing your data to storage account, you can also stream it to an Event Hub. In this preview release
the storage account configuration is mandatory but Event Hub configuration is optional.

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -
serviceBusRuleId /subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessKey -
Location
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia -
RetentionInDays 90
Configure diagnostics logs

Many Azure services provide additional logs and telemetry that can do one or more of the following:
be configured to save data in your Azure Storage account
sent to Event Hubs
sent to a Log Analytics workspace.
The operation can only be performed at a resource level. The storage account or event hub should be present in
the same region as the target resource where the diagnostics setting is configured.
Get diagnostic setting
Get-AzDiagnosticSetting -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Logic/workflows/andy0315logicapp
Disable diagnostic setting
Set-AzDiagnosticSetting -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Logic/workflows/andy0315logicapp -StorageAccountId
/subscriptions/s1/resourceGroups/Default-Storage-
WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $false
Enable diagnostic setting without retention
WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $true
Enable diagnostic setting with retention
WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $true -RetentionEnabled $true -
RetentionInDays 90
Enable diagnostic setting with retention for a specific log category
Set-AzDiagnosticSetting -ResourceId /subscriptions/s1/resourceGroups/insights-

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -StorageAccountId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/sakteststorage -Categories
NetworkSecurityGroupEvent -Enable $true -RetentionEnabled $true -RetentionInDays 90
Enable diagnostic setting for Event Hubs

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -serviceBusRuleId
/subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessKey -Enable
$true
Enable diagnostic setting for Log Analytics

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -WorkspaceId
/subscriptions/s1/resourceGroups/insights-
integration/providers/providers/microsoft.operationalinsights/workspaces/myWorkspace -Enabled $true
Note that the WorkspaceId property takes the resource ID of the workspace. You can obtain the resource ID of
your Log Analytics workspace using the following command:
(Get-AzOperationalInsightsWorkspace).ResourceId
These commands can be combined to send data to multiple destinations.

Manage Log Analytics workspace in Azure Monitor using
PowerShell
You can use the Log Analytics PowerShell cmdlets to perform various functions on a Log Analytics workspace in Azure Monitor from a
command line or as part of a script. Examples of the tasks you can perform with PowerShell include:
Create a workspace
Add or remove a solution
Import and export saved searches
Create a computer group
Enable collection of IIS logs from computers with the Windows agent installed
Collect performance counters from Linux and Windows computers
Collect events from syslog on Linux computers
Collect events from Windows event logs
Collect custom event logs
Add the log analytics agent to an Azure virtual machine
Configure log analytics to index data collected using Azure diagnostics
This article provides two code samples that illustrate some of the functions that you can perform from PowerShell. You can refer to the
Log Analytics PowerShell cmdlet reference for other functions.
NOTE
Log Analytics was previously called Operational Insights, which is why it is the name used in the cmdlets.
NOTE
This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will continue to receive bug
fixes until at least December 2020. To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az
module. For Az module installation instructions, see Install Azure PowerShell.
Prerequisites
These examples work with version 1.0.0 or later of the Az.OperationalInsights module.
Create and configure a Log Analytics Workspace

The following script sample illustrates how to:
1. Create a workspace
2. List the available solutions
3. Add solutions to the workspace
4. Import saved searches
5. Export saved searches
7. Enable collection of IIS logs from computers with the Windows agent installed
8. Collect Logical Disk perf counters from Linux computers (% Used Inodes; Free Megabytes; % Used Space; Disk Transfers/sec; Disk
Reads/sec; Disk Writes/sec)
9. Collect syslog events from Linux computers
10. Collect Error and Warning events from the Application Event Log from Windows computers
11. Collect Memory Available Mbytes performance counter from Windows computers
12. Collect a custom log
$ResourceGroup = "oms-example"
$WorkspaceName = "log-analytics-" + (Get-Random -Maximum 99999) # workspace names need to be unique - Get-Random helps with this for
$WorkspaceName = "log-analytics-" + (Get-Random -Maximum 99999) # workspace names need to be unique - Get-Random helps with this for
the example code
$Location = "westeurope"
# List of solutions to enable

$Solutions = "Security", "Updates", "SQLAssessment"
# Saved Searches to import

$ExportedSearches = @"
[
{
"Category": "My Saved Searches",
"DisplayName": "WAD Events (All)",
"Query": "Type=Event SourceSystem:AzureStorage ",
"Version": 1
},
{
"Category": "My Saved Searches",
"DisplayName": "Current Disk Queue Length",
"Query": "Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and InstanceName == "C:"",
"Version": 1
}
]
"@ | ConvertFrom-Json
# Custom Log to collect

$CustomLog = @"
{
"customLogName": "sampleCustomLog1",
"description": "Example custom log datasource",
"inputs": [
{
"location": {
"fileSystemLocations": {
"windowsFileTypeLogPaths": [ "e:\\iis5\\*.log" ],
"linuxFileTypeLogPaths": [ "/var/logs" ]
}
},
"recordDelimiter": {
"regexDelimiter": {
"pattern": "\\n",
"matchIndex": 0,
"matchIndexSpecified": true,
"numberedGroup": null
}
}
}
],
"extractions": [
{
"extractionName": "TimeGenerated",
"extractionType": "DateTime",
"extractionProperties": {
"dateTimeExtraction": {
"regex": null,
"joinStringRegex": null
}
}
}
]
}
"@
# Create the resource group if needed

try {
Get-AzResourceGroup -Name $ResourceGroup -ErrorAction Stop
} catch {
New-AzResourceGroup -Name $ResourceGroup -Location $Location
}
# Create the workspace

New-AzOperationalInsightsWorkspace -Location $Location -Name $WorkspaceName -Sku Standard -ResourceGroupName $ResourceGroup
# List all solutions and their installation status

Get-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Add solutions
foreach ($solution in $Solutions) {
Set-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -IntelligencePackName
$solution -Enabled $true
}
# List enabled solutions

# List enabled solutions
(Get-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName).Where({($_.enabled -eq
$true)})
# Import Saved Searches

foreach ($search in $ExportedSearches) {
$id = $search.Category + "|" + $search.DisplayName
New-AzOperationalInsightsSavedSearch -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -SavedSearchId $id -
DisplayName $search.DisplayName -Category $search.Category -Query $search.Query -Version $search.Version
}
# Export Saved Searches

(Get-AzOperationalInsightsSavedSearch -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName).Value.Properties | ConvertTo-
Json
# Create Computer Group based on a query

New-AzOperationalInsightsComputerGroup -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -SavedSearchId "My Web
Servers" -DisplayName "Web Servers" -Category "My Saved Searches" -Query "Computer=""web*"" | distinct Computer" -Version 1
# Enable IIS Log Collection using agent

Enable-AzOperationalInsightsIISLogCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Linux Perf
New-AzOperationalInsightsLinuxPerformanceObjectDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName
"Logical Disk" -InstanceName "*" -CounterNames @("% Used Inodes", "Free Megabytes", "% Used Space", "Disk Transfers/sec", "Disk
Reads/sec", "Disk Reads/sec", "Disk Writes/sec") -IntervalSeconds 20 -Name "Example Linux Disk Performance Counters"
Enable-AzOperationalInsightsLinuxPerformanceCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Linux Syslog
New-AzOperationalInsightsLinuxSyslogDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -Facility "kern" -
CollectEmergency -CollectAlert -CollectCritical -CollectError -CollectWarning -Name "Example kernel syslog collection"
Enable-AzOperationalInsightsLinuxSyslogCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Windows Event
New-AzOperationalInsightsWindowsEventDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -EventLogName
"Application" -CollectErrors -CollectWarnings -Name "Example Application Event Log"
# Windows Perf
New-AzOperationalInsightsWindowsPerformanceCounterDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -
ObjectName "Memory" -InstanceName "*" -CounterName "Available MBytes" -IntervalSeconds 20 -Name "Example Windows Performance Counter"
# Custom Logs
New-AzOperationalInsightsCustomLogDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -CustomLogRawJson

"$CustomLog" -Name "Example Custom Log Collection"
In the above example regexDelimiter was defined as "\n" for newline. The log delimiter may also be a timestamp. These are the supported
formats:
JSON REGEX FORMAT USES TWO \

FOR EVERY \ IN A STANDARD REGEX
SO IF TESTING IN A REGEX APP
FORMAT REDUCE \ TO \
YYYY-MM-DD HH:MM:SS ((\\d{2})|(\\d{4}))-([0-

1]\\d)-(([0-3]\\d)|
(\\d))\\s((\\d)|([0-1]\\d)|
(2[0-4])):[0-5][0-9]:[0-5][0-
9]
M/D/YYYY HH:MM:SS AM/PM (([0-1]\\d)|[0-9])/(([0-

3]\\d)|(\\d))/((\\d{2})|
(\\d{4}))\\s((\\d)|([0-
1]\\d)|(2[0-4])):[0-5][0-9]:
[0-5][0-9]\\s(AM|PM|am|pm)
dd/MMM/yyyy HH:MM:SS (([0-2][1-9]|[3][0-

1])\\/(Jan|Feb|Mar|May|Apr|Jul|Jun|Aug|Oct|Sep|Nov|Dec|jan|feb|mar|may|apr|jul|jun|aug|oct|sep|nov|dec)\\/((19|20)
[0-9][0-9]))\\s((\\d)|([0-1]\\d)|(2[0-4])):[0-5][0-9]:[0-5][0-9])
JSON REGEX FORMAT USES TWO \
FOR EVERY \ IN A STANDARD REGEX
SO IF TESTING IN A REGEX APP
FORMAT REDUCE \ TO \
MMM dd yyyy HH:MM:SS (((?:Jan(?:uary)?

|Feb(?:ruary)?|Mar(?:ch)?
|Apr(?:il)?|May|Jun(?:e)?
|Jul(?:y)?|Aug(?:ust)?
|Sep(?:tember)?
|Sept|Oct(?:ober)?
|Nov(?:ember)?
|Dec(?:ember)?)).*?((?:(?:[0-
2]?\\d{1})|(?:[3][01]{1})))
(?![\\d]).*?((?:(?:[1]
{1}\\d{1}\\d{1}\\d{1})|(?:[2]
{1}\\d{3})))(?![\\d]).*?((?:
(?:[0-1][0-9])|(?:[2][0-3])|
(?:[0-9])):(?:[0-5][0-9])(?::
[0-5][0-9])?(?:\\s?
(?:am|AM|pm|PM))?))
yyMMdd HH:mm:ss ([0-9]{2}([0][1-9]|[1][0-2])

([0-2][0-9]|[3][0-1])\\s\\s?
([0-1]?[0-9]|[2][0-3]):[0-5]
[0-9]:[0-5][0-9])
ddMMyy HH:mm:ss (([0-2][0-9]|[3][0-1])([0][1-

9]|[1][0-2])[0-9]{2}\\s\\s?
([0-1]?[0-9]|[2][0-3]):[0-5]
[0-9]:[0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s\\s?

([0]?[1-9]|[1-2][0-9]|[3][0-1])\\s([0-1]?[0-9]|[2][0-
3]):([0-5][0-9]):([0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s\\s([0]?

two spaces after MMM [1-9]|[1-2][0-9]|[3][0-1])\\s([0][0-9]|[1][0-2]):([0-5][0-
9]):([0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s([0]?

[1-9]|[1-2][0-9]|[3][0-1])\\s([0][0-9]|[1][0-2]):([0-5]
[0-9]):([0-5][0-9])
dd/MMM/yyyy:HH:mm:ss +zzzz (([0-2][1-9]|[3][0-

where + is + or a - 1])\\/(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\/((19|20)
[0-9][0-9]):([0][0-9]|[1][0-2]):([0-5][0-9]):([0-5][0-
where zzzz time offset 9])\\s[\\+|\\-][0-9]{4})
yyyy-MM-ddTHH:mm:ss ((\\d{2})|(\\d{4}))-([0-
The T is a literal letter T 1]\\d)-(([0-3]\\d)|
(\\d))T((\\d)|([0-1]\\d)|
(2[0-4])):[0-5][0-9]:[0-5][0-
9]
Configuring Log Analytics to send Azure diagnostics

For agentless monitoring of Azure resources, the resources need to have Azure diagnostics enabled and configured to write to a Log
Analytics workspace. This approach sends data directly to the workspace and does not require data to be written to a storage account.
Supported resources include:
RESOURCE TYPE LOGS METRICS
Application Gateways Yes Yes
Automation accounts Yes
Batch accounts Yes Yes
Data Lake analytics Yes
Data Lake store Yes
Elastic SQL Pool Yes
Event Hub namespace Yes

RESOURCE TYPE LOGS METRICS
IoT Hubs Yes
Key Vault Yes
Load Balancers Yes
Logic Apps Yes Yes
Network Security Groups Yes
Azure Cache for Redis Yes
Search services Yes Yes
Service Bus namespace Yes
SQL (v12) Yes
Web Sites Yes
Web Server farms Yes
For the details of the available metrics, refer to supported metrics with Azure Monitor.
For the details of the available logs, refer to supported services and schema for diagnostic logs.
$workspaceId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/resourcegroups/oi-default-east-
$resourceId = "/SUBSCRIPTIONS/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxx/RESOURCEGROUPS/DEMO/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/DEMO"
Set-AzDiagnosticSetting -ResourceId $resourceId -WorkspaceId $workspaceId -Enabled $true
You can also use the preceding cmdlet to collect logs from resources that are in different subscriptions. The cmdlet is able to work across
subscriptions since you're providing the ID of both the resource creating logs and the workspace the logs are sent to.
Configuring Log Analytics workspace to collect Azure diagnostics from storage

To collect log data from within a running instance of a classic cloud service or a service fabric cluster, you need to first write the data to
Azure storage. A Log Analytics workspace is then configured to collect the logs from the storage account. Supported resources include:
Classic cloud services (web and worker roles)
Service fabric clusters
The following example shows how to:
1. List the existing storage accounts and locations that the workspace will index data from
2. Create a configuration to read from a storage account
3. Update the newly created configuration to index data from additional locations
4. Delete the newly created configuration
# validTables = "WADWindowsEventLogsTable", "LinuxsyslogVer2v0", "WADServiceFabric*EventTable", "WADETWEventTable"
$workspace = (Get-AzOperationalInsightsWorkspace).Where({$_.Name -eq "your workspace name"})
# Update these two lines with the storage account resource ID and the storage account key for the storage account you want the
workspace to index
$storageId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxx/resourceGroups/demo/providers/Microsoft.Storage/storageAccounts/wadv2storage"
$key = "abcd=="
# List existing insights

Get-AzOperationalInsightsStorageInsight -ResourceGroupName $workspace.ResourceGroupName -WorkspaceName $workspace.Name
# Create a new insight

New-AzOperationalInsightsStorageInsight -ResourceGroupName $workspace.ResourceGroupName -WorkspaceName $workspace.Name -Name
"newinsight" -StorageAccountResourceId $storageId -StorageAccountKey $key -Tables @("WADWindowsEventLogsTable") -Containers @("wad-
iis-logfiles")
# Update existing insight

Set-AzOperationalInsightsStorageInsight -ResourceGroupName $workspace.ResourceGroupName -WorkspaceName $workspace.Name -Name
"newinsight" -Tables @("WADWindowsEventLogsTable", "WADETWEventTable") -Containers @("wad-iis-logfiles")
# Remove the insight

Remove-AzOperationalInsightsStorageInsight -ResourceGroupName $workspace.ResourceGroupName -WorkspaceName $workspace.Name -Name
"newinsight"
You can also use the preceding script to collect logs from storage accounts in different subscriptions. The script is able to work across
subscriptions since you are providing the storage account resource ID and a corresponding access key. When you change the access key,
you need to update the storage insight to have the new key.
Next steps
Review Log Analytics PowerShell cmdlets for additional information on using PowerShell for configuration of Log Analytics.
Create Application Insights resources using
PowerShell
NOTE
Azure PowerShell.
This article shows you how to automate the creation and update of Application Insights resources automatically
by using Azure Resource Management. You might, for example, do so as part of a build process. Along with the
basic Application Insights resource, you can create availability web tests, set up alerts, set the pricing scheme, and
create other Azure resources.
The key to creating these resources is JSON templates for Azure Resource Manager. In a nutshell, the procedure
is: download the JSON definitions of existing resources; parameterize certain values such as names; and then run
the template whenever you want to create a new resource. You can package several resources together, to create
them all in one go - for example, an app monitor with availability tests, alerts, and storage for continuous export.
There are some subtleties to some of the parameterizations, which we'll explain here.
One-time setup
If you haven't used PowerShell with your Azure subscription before:
Install the Azure Powershell module on the machine where you want to run the scripts:
1. Install Microsoft Web Platform Installer (v5 or higher).
2. Use it to install Microsoft Azure Powershell.
Create an Azure Resource Manager template

Create a new .json file - let's call it template1.json in this example. Copy this content into it:
{
"parameters": {
"appName": {
"type": "string",
"metadata": {
"description": "Enter the application name."
}
},
"appType": {
"type": "string",
"defaultValue": "web",
"allowedValues": [
"web",
"java",
"other"
],
"metadata": {
"metadata": {
"description": "Enter the application type."
}
},
"appLocation": {
"type": "string",
"defaultValue": "East US",
"allowedValues": [
"South Central US",
"West Europe",
"East US",
"North Europe"
],
"metadata": {
"description": "Enter the application location."
}
},
"priceCode": {
"type": "int",
"defaultValue": 1,
"allowedValues": [
1,
2
],
"metadata": {
"description": "1 = Per GB (Basic), 2 = Per Node (Enterprise)"
}
},
"dailyQuota": {
"type": "int",
"defaultValue": 100,
"minValue": 1,
"metadata": {
"description": "Enter daily quota in GB."
}
},
"dailyQuotaResetTime": {
"type": "int",
"defaultValue": 24,
"metadata": {
"description": "Enter daily quota reset hour in UTC (0 to 23). Values outside the range
will get a random reset hour."
}
},
"warningThreshold": {
"type": "int",
"defaultValue": 90,
"minValue": 1,
"maxValue": 100,
"metadata": {
"description": "Enter the % value of daily quota after which warning mail to be sent. "
}
}
},
"variables": {
"priceArray": [
"Basic",
"Application Insights Enterprise"
],
"pricePlan": "[take(variables('priceArray'),parameters('priceCode'))]",
"billingplan": "[concat(parameters('appName'),'/', variables('pricePlan')[0])]"
},
"resources": [
{
"kind": "[parameters('appType')]",
"name": "[parameters('appName')]",
"apiVersion": "2014-04-01",
"location": "[parameters('appLocation')]",
"tags": {},
"properties": {
"ApplicationId": "[parameters('appName')]"
},
"dependsOn": []
},
{
"name": "[variables('billingplan')]",
"type": "microsoft.insights/components/CurrentBillingFeatures",
"apiVersion": "2015-05-01",
"dependsOn": [
"[resourceId('microsoft.insights/components', parameters('appName'))]"
],
"properties": {
"CurrentBillingFeatures": "[variables('pricePlan')]",
"DataVolumeCap": {
"Cap": "[parameters('dailyQuota')]",
"WarningThreshold": "[parameters('warningThreshold')]",
"ResetTime": "[parameters('dailyQuotaResetTime')]"
}
}
}
]
}
Create Application Insights resources

1. In PowerShell, sign in to Azure:
Connect-AzAccount
2. Run a command like this:
New-AzResourceGroupDeployment -ResourceGroupName Fabrikam `

-TemplateFile .\template1.json `
-appName myNewApp
-ResourceGroupNameis the group where you want to create the new resources.
-TemplateFile must occur before the custom parameters.
-appName The name of the resource to create.
You can add other parameters - you'll find their descriptions in the parameters section of the template.
To get the instrumentation key

After creating an application resource, you'll want the instrumentation key:
$resource = Find-AzResource -ResourceNameEquals "<YOUR APP NAME>" -ResourceType

"Microsoft.Insights/components"
$details = Get-AzResource -ResourceId $resource.ResourceId
$ikey = $details.Properties.InstrumentationKey
Set the price plan

You can set the price plan.
To create an app resource with the Enterprise price plan, using the template above:
New-AzResourceGroupDeployment -ResourceGroupName Fabrikam `

-TemplateFile .\template1.json `
-priceCode 2 `
-appName myNewApp
PRICECODE PLAN
1 Basic
2 Enterprise
If you only want to use the default Basic price plan, you can omit the CurrentBillingFeatures resource from
the template.
If you want to change the price plan after the component resource has been created, you can use a template
that omits the "microsoft.insights/components" resource. Also, omit the dependsOn node from the billing
resource.
To verify the updated price plan, look at the Usage and estimated costs page blade in the browser. Refresh
the browser view to make sure you see the latest state.
Add a metric alert

To set up a metric alert at the same time as your app resource, merge code like this into the template file:
{
parameters: { ... // existing parameters ...
"responseTime": {
"type": "int",
"defaultValue": 3,
"minValue": 1,
"metadata": {
"description": "Enter response time threshold in seconds."
}
},
variables: { ... // existing variables ...
// Alert names must be unique within resource group.
"responseAlertName": "[concat('ResponseTime-', toLower(parameters('appName')))]"
},
resources: { ... // existing resources ...
{
//
// Metric alert on response time
//
"name": "[variables('responseAlertName')]",
"type": "Microsoft.Insights/alertrules",
"apiVersion": "2014-04-01",
// Ensure this resource is created after the app resource:
"dependsOn": [
"[resourceId('Microsoft.Insights/components', parameters('appName'))]"
],
"tags": {
"Resource"
},
"properties": {
"name": "[variables('responseAlertName')]",
"description": "response time alert",
"isEnabled": true,
"condition": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.ThresholdRuleCondition,
Microsoft.WindowsAzure.Management.Mon.Client",
"dataSource": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleMetricDataSource,
"resourceUri": "[resourceId('microsoft.insights/components', parameters('appName'))]",
"metricName": "request.duration"
},
"threshold": "[parameters('responseTime')]", //seconds
"windowSize": "PT15M" // Take action if changed state for 15 minutes
},
"actions": [
{
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleEmailAction,
"customEmails": []
}
]
}
}
}
When you invoke the template, you can optionally add this parameter:
`-responseTime 2`
You can of course parameterize other fields.

To find out the type names and configuration details of other alert rules, create a rule manually and then inspect
it in Azure Resource Manager.
Add an availability test

This example is for a ping test (to test a single page).
There are two parts in an availability test: the test itself, and the alert that notifies you of failures.
Merge the following code into the template file that creates the app.
{
parameters: { ... // existing parameters here ...
"pingURL": { "type": "string" },
"pingText": { "type": "string" , defaultValue: ""}
},
variables: { ... // existing variables here ...
"pingTestName":"[concat('PingTest-', toLower(parameters('appName')))]",
"pingAlertRuleName": "[concat('PingAlert-', toLower(parameters('appName')), '-',
subscription().subscriptionId)]"
},
resources: { ... // existing resources here ...
{ //
// Availability test: part 1 configures the test
//
"name": "[variables('pingTestName')]",
"type": "Microsoft.Insights/webtests",
"apiVersion": "2014-04-01",
// Ensure this is created after the app resource:
"dependsOn": [
"[resourceId('Microsoft.Insights/components', parameters('appName'))]"
],
"tags": {
"Resource"
},
"properties": {
"Name": "[variables('pingTestName')]",
"Description": "Basic ping test",
"Enabled": true,
"Frequency": 900, // 15 minutes
"Timeout": 120, // 2 minutes
"Kind": "ping", // single URL test
"RetryEnabled": true,
"Locations": [
{
"Id": "us-va-ash-azr"
},
{
"Id": "emea-nl-ams-azr"
},
{
"Id": "apac-jp-kaw-edge"
}
],
"Configuration": {
"WebTest": "[concat('<WebTest Name=\"', variables('pingTestName'), '\" Enabled=\"True\"
CssProjectStructure=\"\" CssIteration=\"\" Timeout=\"120\" WorkItemIds=\"\"
xmlns=\"http://microsoft.com/schemas/VisualStudio/TeamTest/2010\" Description=\"\"
StopOnError=\"False\" RecordedResultFile=\"\" ResultsLocale=\"\"> <Items> <Request Method=\"GET\"
Version=\"1.1\" Url=\"', parameters('Url'), '\" ThinkTime=\"0\" Timeout=\"300\"
ParseDependentRequests=\"True\" FollowRedirects=\"True\" RecordResult=\"True\" Cache=\"False\"
ResponseTimeGoal=\"0\" Encoding=\"utf-8\" ExpectedHttpStatusCode=\"200\" ExpectedResponseUrl=\"\"
ReportingName=\"\" IgnoreHttpStatusCode=\"False\" /> </Items> <ValidationRules> <ValidationRule
Classname=\"Microsoft.VisualStudio.TestTools.WebTesting.Rules.ValidationRuleFindText,
Microsoft.VisualStudio.QualityTools.WebTestFramework, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a\" DisplayName=\"Find Text\" Description=\"Verifies the existence of
the specified text in the response.\" Level=\"High\" ExecutionOrder=\"BeforeDependents\">
<RuleParameters> <RuleParameter Name=\"FindText\" Value=\"', parameters('pingText'), '\" />
<RuleParameter Name=\"IgnoreCase\" Value=\"False\" /> <RuleParameter Name=\"UseRegularExpression\"
Value=\"False\" /> <RuleParameter Name=\"PassIfTextFound\" Value=\"True\" /> </RuleParameters>
</ValidationRule> </ValidationRules> </WebTest>')]"
},
"SyntheticMonitorId": "[variables('pingTestName')]"
}
},
{
//
// Availability test: part 2, the alert rule
//
"type": "Microsoft.Insights/alertrules",
"apiVersion": "2014-04-01",
"dependsOn": [
"[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]"
],
"tags": {
"Resource",
"[concat('hidden-link:', resourceId('Microsoft.Insights/webtests', variables('pingTestName')))]":
"Resource"
},
"properties": {
"description": "alert for web test",
"isEnabled": true,
"condition": {
"$type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.LocationThresholdRuleCondition,
"odata.type": "Microsoft.Azure.Management.Insights.Models.LocationThresholdRuleCondition",
"dataSource": {
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleMetricDataSource,
"resourceUri": "[resourceId('microsoft.insights/webtests', variables('pingTestName'))]",
"metricName": "GSMT_AvRaW"
},
"windowSize": "PT15M", // Take action if changed state for 15 minutes
"failedLocationCount": 2
},
"actions": [
{
"$type": "Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.RuleEmailAction,
"customEmails": []
}
]
}
}
}
To discover the codes for other test locations, or to automate the creation of more complex web tests, create an
example manually and then parameterize the code from Azure Resource Manager.
Add more resources

To automate the creation of any other resource of any kind, create an example manually, and then copy and
parameterize its code from Azure Resource Manager.
1. Open Azure Resource Manager. Navigate down through
subscriptions/resourceGroups/<your resource group>/providers/Microsoft.Insights/components , to your
application resource.
Components are the basic Application Insights resources for displaying applications. There are separate
resources for the associated alert rules and availability web tests.
2. Copy the JSON of the component into the appropriate place in template1.json .
3. Delete these properties:
id
InstrumentationKey
CreationDate
TenantId
4. Open the webtests and alertrules sections and copy the JSON for individual items into your template.
(Don't copy from the webtests or alertrules nodes: go into the items under them.)
Each web test has an associated alert rule, so you have to copy both of them.
You can also include alerts on metrics. Metric names.
5. Insert this line in each resource:
"apiVersion": "2015-05-01",
Parameterize the template
Now you have to replace the specific names with parameters. To parameterize a template, you write expressions
using a set of helper functions.
You can't parameterize just part of a string, so use concat() to build strings.
Here are examples of the substitutions you'll want to make. There are several occurrences of each substitution.
You might need others in your template. These examples use the parameters and variables we defined at the top
of the template.
FIND REPLACE WITH
"hidden- "[concat('hidden-link:',
link:/subscriptions/.../../components/MyAppName"
resourceId('microsoft.insights/components',
parameters('appName')))]"
"/subscriptions/.../../alertrules/myAlertName- "[resourceId('Microsoft.Insights/alertrules',
myAppName-subsId", variables('alertRuleName'))]",
"/subscriptions/.../../webtests/myTestName- "[resourceId('Microsoft.Insights/webtests',
myAppName", parameters('webTestName'))]",
"myWebTest-myAppName" "[variables(testName)]"'
"myTestName-myAppName-subsId" "[variables('alertRuleName')]"
"myAppName" "[parameters('appName')]"
"myappname" (lower case) "[toLower(parameters('appName'))]"
"<WebTest Name=\"myWebTest\" ... [concat('<WebTest Name=\"',

Url=\"http://fabrikam.com/home\" ...>" parameters('webTestName'),
'\" ... Url=\"', parameters('Url'),
'\"...>')]"
Delete Guid and Id.
Set dependencies between the resources

Azure should set up the resources in strict order. To make sure one setup completes before the next begins, add
dependency lines:
In the availability test resource:
"dependsOn": ["[resourceId('Microsoft.Insights/components', parameters('appName'))]"],
In the alert resource for an availability test:

"dependsOn": ["[resourceId('Microsoft.Insights/webtests', variables('testName'))]"],
Next steps
Other automation articles:
Create an Application Insights resource - quick method without using a template.
Set up Alerts
Create web tests
Send Azure Diagnostics to Application Insights
Deploy to Azure from GitHub
Create release annotations
PowerShell script to create an Application Insights
resource
NOTE
PowerShell.
When you want to monitor a new application - or a new version of an application - with Azure Application
Insights, you set up a new resource in Microsoft Azure. This resource is where the telemetry data from your app is
analyzed and displayed.
You can automate the creation of a new resource by using PowerShell.
For example, if you are developing a mobile device app, it's likely that, at any time, there will be several published
versions of your app in use by your customers. You don't want to get the telemetry results from different versions
mixed up. So you get your build process to create a new resource for each build.
NOTE
If you want to create a set of resources all at the same time, consider creating the resources using an Azure template.
Script to create an Application Insights resource

See the relevant cmdlet specs:
New -AzResource
New -AzRoleAssignment
PowerShell Script
###########################################
# Set Values
###########################################
# If running manually, uncomment before the first

# execution to login to the Azure Portal:
# Connect-AzAccount / Connect-AzAccount
# Set the name of the Application Insights Resource
$appInsightsName = "TestApp"
# Set the application name used for the value of the Tag "AppInsightsApp"
$applicationTagName = "MyApp"
# Set the name of the Resource Group to use.

# Default is the application name.
$resourceGroupName = "MyAppResourceGroup"
###################################################
# Create the Resource and Output the name and iKey
###################################################
# Select the azure subscription

Select-AzureSubscription -SubscriptionName "MySubscription"
# Create the App Insights Resource
$resource = New-AzResource `
-ResourceName $appInsightsName `
-ResourceGroupName $resourceGroupName `
-Tag @{ applicationType = "web"; applicationName = $applicationTagName} `
-ResourceType "Microsoft.Insights/components" `
-Location "East US" ` # or North Europe, West Europe, South Central US
-PropertyObject @{"Application_Type"="web"} `
-Force
# Give owner access to the team
New-AzRoleAssignment `
-SignInName "myteam@fabrikam.com" `
-RoleDefinitionName Owner `
-Scope $resource.ResourceId
# Display iKey
Write-Host "App Insights Name = " $resource.Name
Write-Host "IKey = " $resource.Properties.InstrumentationKey
What to do with the iKey

Each resource is identified by its instrumentation key (iKey). The iKey is an output of the resource creation script.
Your build script should provide the iKey to the Application Insights SDK embedded in your app.
There are two ways to make the iKey available to the SDK:
In ApplicationInsights.config:
<instrumentationkey> ikey </instrumentationkey>
Or in initialization code:
Microsoft.ApplicationInsights.Extensibility. TelemetryConfiguration.Active.InstrumentationKey = " iKey
";
See also
Create Application Insights and web test resources from templates
Set up monitoring of Azure diagnostics with PowerShell
Set alerts by using PowerShell
Use PowerShell to set alerts in Application Insights
NOTE
PowerShell.
You can automate the configuration of alerts in Application Insights.

In addition, you can set webhooks to automate your response to an alert.
NOTE
If you want to create resources and alerts at the same time, consider using an Azure Resource Manager template.
One-time setup
If you haven't used PowerShell with your Azure subscription before:
Install the Azure Powershell module on the machine where you want to run the scripts.
Install Microsoft Web Platform Installer (v5 or higher).
Use it to install Microsoft Azure Powershell
Connect to Azure
Start Azure PowerShell and connect to your subscription:
Add-AzAccount
Get alerts
Get-AzAlertRule -ResourceGroup "Fabrikam" [-Name "My rule"] [-DetailedOutput]
Add alert
Add-AzMetricAlertRule -Name "{ALERT NAME}" -Description "{TEXT}" `
-ResourceGroup "{GROUP NAME}" `
-ResourceId "/subscriptions/{SUBSCRIPTION ID}/resourcegroups/{GROUP
NAME}/providers/microsoft.insights/components/{APP RESOURCE NAME}" `
-MetricName "{METRIC NAME}" `
-Operator GreaterThan `
-Threshold {NUMBER} `
-WindowSize {HH:MM:SS} `
[-SendEmailToServiceOwners] `
[-CustomEmails "EMAIL1@X.COM","EMAIL2@Y.COM" ] `
-Location "East US" // must be East US at present
-RuleType Metric
Example 1
Email me if the server's response to HTTP requests, averaged over 5 minutes, is slower than 1 second. My
Application Insights resource is called IceCreamWebApp, and it is in resource group Fabrikam. I am the owner of
the Azure subscription.
The GUID is the subscription ID (not the instrumentation key of the application).
Add-AzMetricAlertRule -Name "slow responses" `

-Description "email me if the server responds slowly" `
-ResourceGroup "Fabrikam" `
-ResourceId "/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/Fabrikam/providers/microsoft.insights/components/IceCreamWebApp" `
-MetricName "request.duration" `
-Operator GreaterThan `
-Threshold 1 `
-WindowSize 00:05:00 `
-SendEmailToServiceOwners `
-Location "East US" -RuleType Metric
Example 2
I have an application in which I use TrackMetric() to report a metric named "salesPerHour." Send an email to my
colleagues if "salesPerHour" drops below 100, averaged over 24 hours.
Add-AzMetricAlertRule -Name "poor sales" `

-Description "slow sales alert" `
-ResourceGroup "Fabrikam" `
-ResourceId "/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/Fabrikam/providers/microsoft.insights/components/IceCreamWebApp" `
-MetricName "salesPerHour" `
-Operator LessThan `
-Threshold 100 `
-WindowSize 24:00:00 `
-CustomEmails "satish@fabrikam.com","lei@fabrikam.com" `
-Location "East US" -RuleType Metric
The same rule can be used for the metric reported by using the measurement parameter of another tracking call
such as TrackEvent or trackPageView.
Metric names
METRIC NAME SCREEN NAME DESCRIPTION
basicExceptionBrowser.count Browser exceptions Count of uncaught exceptions thrown

in the browser.
basicExceptionServer.count Server exceptions Count of unhandled exceptions thrown

by the app
clientPerformance.clientProcess.value Client processing time Time between receiving the last byte of
a document until the DOM is loaded.
Async requests may still be processing.
Page load network connect time

clientPerformance.networkConnection.value Time the browser takes to connect to
the network. Can be 0 if cached.
clientPerformance.receiveRequest.valueReceiving response time Time between browser sending request

to starting to receive response.
clientPerformance.sendRequest.value Send request time Time taken by browser to send request.
clientPerformance.total.value Browser page load time Time from user request until DOM,
stylesheets, scripts and images are
loaded.
Available memory
performanceCounter.available_bytes.value Physical memory immediately available
for a process or for system use.
Process IO
performanceCounter.io_data_bytes_per_sec.value Rate Total bytes per second read and written
to files, network and devices.
exception rate
performanceCounter.number_of_exceps_thrown_per_sec.value Exceptions thrown per second.
Process CPU
performanceCounter.percentage_processor_time.value The percentage of elapsed time of all
process threads used by the processor
to execution instructions for the
applications process.
Processor time
performanceCounter.percentage_processor_total.value The percentage of time that the
processor spends in non-Idle threads.
Process private bytes

performanceCounter.process_private_bytes.value Memory exclusively assigned to the
monitored application's processes.
ASP.NET request execution time

performanceCounter.request_execution_time.value Execution time of the most recent
request.
ASP.NET requests in execution queue

performanceCounter.requests_in_application_queue.value Length of the application request
queue.
ASP.NET request rate

performanceCounter.requests_per_sec.value Rate of all requests to the application
per second from ASP.NET.
Dependency failures
remoteDependencyFailed.durationMetric.count Count of failed calls made by the server
application to external resources.
METRIC NAME SCREEN NAME DESCRIPTION
request.duration Server response time Time between receiving an HTTP

request and finishing sending the
response.
request.rate Request rate Rate of all requests to the application

per second.
requestFailed.count Failed requests Count of HTTP requests that resulted in

a response code >= 400
view.count Page views Count of client user requests for a web

page. Synthetic traffic is filtered out.
{your custom metric name} {Your metric name} Your metric value reported by
TrackMetric or in the measurements
parameter of a tracking call.
The metrics are sent by different telemetry modules:
METRIC GROUP COLLECTOR MODULE
basicExceptionBrowser, Browser JavaScript

clientPerformance,
view
performanceCounter Performance
remoteDependencyFailed Dependency
request, Server request

requestFailed
Webhooks
You can automate your response to an alert. Azure will call a web address of your choice when an alert is raised.
See also
Script to configure Application Insights
Create Application Insights and web test resources from templates
Automate coupling Microsoft Azure Diagnostics to Application Insights
Automate your response to an alert
Using PowerShell to set up Application Insights for
Microsoft Azure can be configured to send Azure Diagnostics to Azure Application Insights. The diagnostics relate
to Azure Cloud Services and Azure VMs. They complement the telemetry that you send from within the app using
the Application Insights SDK. As part of automating the process of creating new resources in Azure, you can
configure diagnostics using PowerShell.
Azure template
If the web app is in Azure and you create your resources using an Azure Resource Manager template, you can
configure Application Insights by adding this to the resources node:
{
resources: [
/* Create Application Insights resource */
{
"apiVersion": "2015-05-01",
"name": "nameOfAIAppResource",
"location": "centralus",
"kind": "web",
"properties": { "ApplicationId": "nameOfAIAppResource" },
"dependsOn": [
"[concat('Microsoft.Web/sites/', myWebAppName)]"
]
}
]
}
nameOfAIAppResource - a name for the Application Insights resource

myWebAppName - the ID of the web app
Enable diagnostics extension as part of deploying a Cloud Service

The New-AzureDeployment cmdlet has a parameter ExtensionConfiguration , which takes an array of diagnostics
configurations. These can be created using the New-AzureServiceDiagnosticsExtensionConfig cmdlet. For example:
$service_package = "CloudService.cspkg"
$service_config = "ServiceConfiguration.Cloud.cscfg"
$diagnostics_storagename = "myservicediagnostics"
$webrole_diagconfigpath = "MyService.WebRole.PubConfig.xml"
$workerrole_diagconfigpath = "MyService.WorkerRole.PubConfig.xml"
$primary_storagekey = (Get-AzStorageKey `
-StorageAccountName "$diagnostics_storagename").Primary
$storage_context = New-AzStorageContext `
-StorageAccountName $diagnostics_storagename `
-StorageAccountKey $primary_storagekey
$webrole_diagconfig = `
New-AzureServiceDiagnosticsExtensionConfig `
-Role "WebRole" -Storage_context $storageContext `
-DiagnosticsConfigurationPath $webrole_diagconfigpath
$workerrole_diagconfig = `
New-AzureServiceDiagnosticsExtensionConfig `
-Role "WorkerRole" `
-StorageContext $storage_context `
-DiagnosticsConfigurationPath $workerrole_diagconfigpath
New-AzureDeployment `
-ServiceName $service_name `
-Slot Production `
-Package $service_package `
-Configuration $service_config `
-ExtensionConfiguration @($webrole_diagconfig,$workerrole_diagconfig)
Enable diagnostics extension on an existing Cloud Service

On an existing service, use Set-AzureServiceDiagnosticsExtension .
$service_name = "MyService"
$diagnostics_storagename = "myservicediagnostics"
$webrole_diagconfigpath = "MyService.WebRole.PubConfig.xml"
$workerrole_diagconfigpath = "MyService.WorkerRole.PubConfig.xml"
$primary_storagekey = (Get-AzStorageKey `
-StorageAccountName "$diagnostics_storagename").Primary
$storage_context = New-AzStorageContext `
-StorageAccountName $diagnostics_storagename `
-StorageAccountKey $primary_storagekey
Set-AzureServiceDiagnosticsExtension `
-DiagnosticsConfigurationPath $webrole_diagconfigpath `
-Slot Production `
-Role "WebRole"
Set-AzureServiceDiagnosticsExtension `
-DiagnosticsConfigurationPath $workerrole_diagconfigpath `
-Slot Production `
-Role "WorkerRole"
Get current diagnostics extension configuration

Get-AzureServiceDiagnosticsExtension -ServiceName "MyService"
Remove diagnostics extension

Remove-AzureServiceDiagnosticsExtension -ServiceName "MyService"
If you enabled the diagnostics extension using either Set-AzureServiceDiagnosticsExtension or

New-AzureServiceDiagnosticsExtensionConfig without the Role parameter, then you can remove the extension using
Remove-AzureServiceDiagnosticsExtension without the Role parameter. If the Role parameter was used when
enabling the extension then it must also be used when removing the extension.
To remove the diagnostics extension from each individual role:
Remove-AzureServiceDiagnosticsExtension -ServiceName "MyService" -Role "WebRole"
See also
Monitor Azure Cloud Services apps with Application Insights
Send Azure Diagnostics to Application Insights
Automate configuring alerts
Azure Monitor CLI quick start samples
This article shows you sample command-line interface (CLI) commands to help you access Azure Monitor
features. Azure Monitor allows you to AutoScale Cloud Services, Virtual Machines, and Web Apps and to send
alert notifications or call web URLs based on values of configured telemetry data.
Prerequisites
If you haven't already installed the Azure CLI, follow the instructions for Install the Azure CLI. You can also use
Azure Cloud Shell to run the CLI as an interactive experience in your browser. See a full reference of all available
commands in the Azure Monitor CLI reference.
Log in to Azure
The first step is to login to your Azure account.
az login
After running this command, you have to sign in via the instructions on the screen. All commands work in the
context of your default subscription.
To list the details of your current subscription, use the following command.
az account show
To change working context to a different subscription, use the following command.
az account set -s <Subscription ID or name>
To view a list of all supported Azure Monitor commands, perform the following.
az monitor -h
View activity log for a subscription

To view a list of activity log events, perform the following.
az monitor activity-log list
Try the following to view all available options.
az monitor activity-log list -h
Here is an example to list logs by a resourceGroup

az monitor activity-log list --resource-group <group name>
Example to list logs by caller
az monitor activity-log list --caller myname@company.com
Example to list logs by caller on a resource type, within a date range
az monitor activity-log list --resource-provider Microsoft.Web \

--caller myname@company.com \
--start-time 2016-03-08T00:00:00Z \
--end-time 2016-03-16T00:00:00Z
Work with alerts

NOTE
Only alerts (classic) is supported in CLI at this time.
Get alert (classic) rules in a resource group
az monitor activity-log alert list --resource-group <group name>

az monitor activity-log alert show --resource-group <group name> --name <alert name>
Create a metric alert (classic) rule
az monitor alert create --name <alert name> --resource-group <group name> \

--action email <email1 email2 ...> \
--action webhook <URI> \
--target <target object ID> \
--condition "<METRIC> {>,>=,<,<=} <THRESHOLD> {avg,min,max,total,last} ##h##m##s"
Delete an alert (classic) rule
az monitor alert delete --name <alert name> --resource-group <group name>
Log profiles
Use the information in this section to work with log profiles.
Get a log profile
az monitor log-profiles list

az monitor log-profiles show --name <profile name>
Add a log profile with retention

az monitor log-profiles create --name <profile name> --location <location of profile> \
--locations <locations to monitor activity in: location1 location2 ...> \
--categories <categoryName1 categoryName2 ...> \
--days <# days to retain> \
--enabled true \
--storage-account-id <storage account ID to store the logs in>
Add a log profile with retention and EventHub
az monitor log-profiles create --name <profile name> --location <location of profile> \

--locations <locations to monitor activity in: location1 location2 ...> \
--categories <categoryName1 categoryName2 ...> \
--days <# days to retain> \
--enabled true
--storage-account-id <storage account ID to store the logs in>
--service-bus-rule-id <service bus rule ID to stream to>
Remove a log profile
az monitor log-profiles delete --name <profile name>
Diagnostics
Use the information in this section to work with diagnostic settings.
Get a diagnostic setting
az monitor diagnostic-settings list --resource <target resource ID>
Create a diagnostic log setting
az monitor diagnostic-settings create --name <diagnostic name> \

--storage-account <storage account ID> \
--resource <target resource object ID> \
--logs '[
{
"category": <category name>,
"enabled": true,
"days": <# days to retain>,
"enabled": true
}
}]'
Delete a diagnostic setting
az monitor diagnostic-settings delete --name <diagnostic name> \

--resource <target resource ID>
Autoscale
Use the information in this section to work with autoscale settings. You need to modify these examples.
Get autoscale settings for a resource group
az monitor autoscale list --resource-group <group name>
Get autoscale settings by name in a resource group
az monitor autoscale show --name <settings name> --resource-group <group name>
Set autoscale settings
az monitor autoscale create --name <settings name> --resource-group <group name> \

--count <# instances> \
--resource <target resource ID>
Manage Log Analytics workspace using Azure
Resource Manager templates
NOTE
PowerShell.
You can use Azure Resource Manager templates to create and configure Log Analytics workspaces in Azure
Monitor. Examples of the tasks you can perform with templates include:
Create a workspace including setting pricing tier
Add a solution
Create saved searches
Create a computer group
Enable collection of IIS logs from computers with the Windows agent installed
Collect performance counters from Linux and Windows computers
Collect events from syslog on Linux computers
Collect events from Windows event logs
Collect custom logs from Windows computer
Add the log analytics agent to an Azure virtual machine
Configure log analytics to index data collected using Azure diagnostics
This article provides template samples that illustrate some of the configuration that you can perform with
templates.
API versions
The following table lists the API version for the resources used in this example.
RESOURCE RESOURCE TYPE API VERSION
Workspace workspaces 2017-03-15-preview
Search savedSearches 2015-03-20
Data source datasources 2015-11-01-preview
Solution solutions 2015-11-01-preview
Create a Log Analytics workspace

The following example creates a workspace using a template from your local machine. The JSON template is
configured to only require the name and location of the new workspace (using the default values for the other
workspace parameters such as pricing tier and retention).
{
"parameters": {
"workspaceName": {
"type": "String",
"metadata": {
}
},
"location": {
"type": "String",
"allowedValues": [
"australiacentral",
"australiaeast",
"australiasoutheast",
"brazilsouth",
"canadacentral",
"centralindia",
"centralus",
"eastasia",
"eastus",
"eastus2",
"francecentral",
"japaneast",
"koreacentral",
"northcentralus",
"northeurope",
"southafricanorth",
"southcentralus",
"southeastasia",
"uksouth",
"ukwest",
"westcentralus",
"westeurope",
"westus",
"westus2"
],
"metadata": {
}
}
},
"resources": [
{
"properties": {
"features": {
"searchVersion": 1
}
}
}
]
}

4. You are ready to deploy this template. You use either PowerShell or the command line to create the
workspace, specifying the workspace name and location as part of the command.
For PowerShell use the following commands from the folder containing the template:
New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateFile

deploylaworkspacetemplate.json -workspaceName <workspace-name> -location <location>
For command line, use the following commands from the folder containing the template:
azure config mode arm

azure group deployment create <my-resource-group> <my-deployment-name> --TemplateFile
deploylaworkspacetemplate.json --workspaceName <workspace-name> --location <location>
Configure a Log Analytics workspace

The following template sample illustrates how to:
1. Add solutions to the workspace
2. Create saved searches
4. Enable collection of IIS logs from computers with the Windows agent installed
5. Collect Logical Disk perf counters from Linux computers (% Used Inodes; Free Megabytes; % Used Space;
Disk Transfers/sec; Disk Reads/sec; Disk Writes/sec)
6. Collect syslog events from Linux computers
7. Collect Error and Warning events from the Application Event Log from Windows computers
8. Collect Memory Available Mbytes performance counter from Windows computers
9. Collect IIS logs and Windows Event logs written by Azure diagnostics to a storage account
10. Collect custom logs from Windows computer
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
"metadata": {
"description": "Workspace name"
}
},
"pricingTier": {
"type": "string",
"allowedValues": [
"PerGB2018",
"Free",
"Standalone",
"PerNode",
"Standard",
"Premium"
],
"metadata": {
"description": "Pricing tier: PerGB2018 or legacy tiers (Free, Standalone, PerNode, Standard or
Premium) which are not available to all customers."
}
},
"dataRetention": {
"type": "int",
"defaultValue": 30,
"minValue": 7,
"maxValue": 730,
"metadata": {
"description": "Number of days of retention. Workspaces in the legacy Free pricing tier can only have
7 days."
}
},
"immediatePurgeDataOn30Days": {
"type": "bool",
"defaultValue": "false",
"metadata": {
"description": "If set to true when changing retention to 30 days, older data will be immediately
deleted. Use this with extreme caution. This only applies when retention is being set to 30 days."
}
},
"location": {
"type": "string",
"allowedValues": [
"australiacentral",
"australiaeast",
"australiasoutheast",
"brazilsouth",
"canadacentral",
"centralindia",
"centralus",
"eastasia",
"eastus",
"eastus2",
"francecentral",
"japaneast",
"koreacentral",
"northcentralus",
"northeurope",
"southafricanorth",
"southcentralus",
"southeastasia",
"uksouth",
"ukwest",
"westcentralus",
"westeurope",
"westus",
"westus2"
],
"metadata": {
}
},
},
"applicationDiagnosticsStorageAccountName": {
"type": "string",
"metadata": {
"description": "Name of the storage account with Azure diagnostics output"
}
},
"applicationDiagnosticsStorageAccountResourceGroup": {
"type": "string",
"metadata": {
"description": "The resource group name containing the storage account with Azure diagnostics
output"
}
}
},
"customlogName": {
"type": "string",
"metadata": {
"description": "custom log name"
}
},
"variables": {
"Updates": {
"Name": "[Concat('Updates', '(', parameters('workspaceName'), ')')]",
"GalleryName": "Updates"
},
"AntiMalware": {
"Name": "[concat('AntiMalware', '(', parameters('workspaceName'), ')')]",
"GalleryName": "AntiMalware"
},
"SQLAssessment": {
"Name": "[Concat('SQLAssessment', '(', parameters('workspaceName'), ')')]",
"GalleryName": "SQLAssessment"
},
"diagnosticsStorageAccount": "
[resourceId(parameters('applicationDiagnosticsStorageAccountResourceGroup'),
'Microsoft.Storage/storageAccounts', parameters('applicationDiagnosticsStorageAccountName'))]"
},
"resources": [
{
"properties": {
"retentionInDays": "[parameters('dataRetention')]",
"features": {
"immediatePurgeDataOn30Days": "[parameters('immediatePurgeDataOn30Days')]"
},
"sku": {
"name": "[parameters('pricingTier')]"
}
},
"resources": [
{
"apiVersion": "2015-03-20",
"name": "VMSS Queries2",
"type": "savedSearches",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'))]"
],
"properties": {
"Category": "VMSS",
"ETag": "*",
"DisplayName": "VMSS Instance Count",
"Query": "Event | where Source == \"ServiceFabricNodeBootstrapAgent\" | summarize AggregatedValue
= count() by Computer",
"Version": 1
}
},
},
{
"type": "datasources",
"name": "sampleWindowsEvent1",
"dependsOn": [
],
"kind": "WindowsEvent",
"properties": {
"eventLogName": "Application",
"eventTypes": [
{
"eventType": "Error"
},
{
"eventType": "Warning"
}
]
}
},
{
"name": "sampleWindowsPerfCounter1",
"dependsOn": [
],
"kind": "WindowsPerformanceCounter",
"properties": {
"objectName": "Memory",
"instanceName": "*",
"intervalSeconds": 10,
"counterName": "Available MBytes"
}
},
{
"name": "sampleIISLog1",
"dependsOn": [
],
"kind": "IISLogs",
"properties": {
"state": "OnPremiseEnabled"
}
},
{
"name": "sampleSyslog1",
"dependsOn": [
],
"kind": "LinuxSyslog",
"properties": {
"syslogName": "kern",
"syslogSeverities": [
{
"severity": "emerg"
},
{
"severity": "alert"
},
{
"severity": "crit"
},
{
"severity": "err"
"severity": "err"
},
{
"severity": "warning"
}
]
}
},
{
"name": "sampleSyslogCollection1",
"dependsOn": [
],
"kind": "LinuxSyslogCollection",
"properties": {
"state": "Enabled"
}
},
{
"name": "sampleLinuxPerf1",
"dependsOn": [
],
"kind": "LinuxPerformanceObject",
"properties": {
"performanceCounters": [
{
"counterName": "% Used Inodes"
},
{
"counterName": "Free Megabytes"
},
{
"counterName": "% Used Space"
},
{
"counterName": "Disk Transfers/sec"
},
{
"counterName": "Disk Reads/sec"
},
{
"counterName": "Disk Writes/sec"
}
],
"objectName": "Logical Disk",
"instanceName": "*",
"intervalSeconds": 10
}
},
{
"type": "dataSources",
"name": "[concat(parameters('workspaceName'), parameters('customlogName'))]",
"dependsOn": [
],
"kind": "CustomLog",
"properties": {
"customLogName": "[parameters('customlogName')]",
"description": "this is a description",
"extractions": [
{
"extractionName": "TimeGenerated",
"extractionProperties": {
"regex": [
{
"matchIndex": 0,
"numberdGroup": null,
"pattern": "((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))\\s((\\d)|([0-1]\\d)|
(2[0-4])):[0-5][0-9]:[0-5][0-9]"
}
]
}
},
"extractionType": "DateTime"
}
],
"inputs": [
{
"location": {
"fileSystemLocations": {
"linuxFileTypeLogPaths": null,
"windowsFileTypeLogPaths": [
"[concat('c:\\Windows\\Logs\\',parameters('customlogName'))]"
]
}
},
"recordDelimiter": {
"regexDelimiter": {
"matchIndex": 0,
"numberdGroup": null,
"pattern": "(^.*((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))\\s((\\d)|([0-1]\\d)|
(2[0-4])):[0-5][0-9]:[0-5][0-9].*$)"
}
}
}
]
}
}
{
"name": "sampleLinuxPerfCollection1",
"dependsOn": [
],
"kind": "LinuxPerformanceCollection",
"properties": {
"state": "Enabled"
}
},
{
"apiVersion": "2015-03-20",
"name": "
[concat(parameters('applicationDiagnosticsStorageAccountName'),parameters('workspaceName'))]",
"type": "storageinsightconfigs",
"dependsOn": [
],
"properties": {
"containers": [
"wad-iis-logfiles"
],
"tables": [
"WADWindowsEventLogsTable"
],
"storageAccount": {
"id": "[variables('diagnosticsStorageAccount')]",
"key": "[listKeys(variables('diagnosticsStorageAccount'),'2015-06-15').key1]"
}
}
},
{
"name": "[variables('Updates').Name]",
"id": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/',
resourceGroup().name, '/providers/Microsoft.OperationsManagement/solutions/', variables('Updates').Name)]",
"dependsOn": [
],
"properties": {
parameters('workspaceName'))]"
},
"plan": {
"name": "[variables('Updates').Name]",
"product": "[Concat('OMSGallery/', variables('Updates').GalleryName)]",
"promotionCode": ""
}
},
{
"name": "[variables('AntiMalware').Name]",
resourceGroup().name, '/providers/Microsoft.OperationsManagement/solutions/',
variables('AntiMalware').Name)]",
"dependsOn": [
],
"properties": {
},
"plan": {
"name": "[variables('AntiMalware').Name]",
"product": "[Concat('OMSGallery/', variables('AntiMalware').GalleryName)]",
"promotionCode": ""
}
},
{
"name": "[variables('SQLAssessment').Name]",
resourceGroup().name, '/providers/Microsoft.OperationsManagement/solutions/',
variables('SQLAssessment').Name)]",
"dependsOn": [
],
"properties": {
},
"plan": {
"name": "[variables('SQLAssessment').Name]",
"product": "[Concat('OMSGallery/', variables('SQLAssessment').GalleryName)]",
"promotionCode": ""
}
}
]
}
],
"outputs": {
"workspaceName": {
"type": "string",
"value": "[parameters('workspaceName')]"
},
"provisioningState": {
"type": "string",
"value": "[reference(resourceId('Microsoft.OperationalInsights/workspaces',
parameters('workspaceName')), '2015-11-01-preview').provisioningState]"
},
"source": {
"type": "string",
parameters('workspaceName')), '2015-11-01-preview').source]"
},
"customerId": {
"type": "string",
parameters('workspaceName')), '2015-11-01-preview').customerId]"
},
"pricingTier": {
"type": "string",
parameters('workspaceName')), '2015-11-01-preview').sku.name]"
},
"retentionInDays": {
"type": "int",
parameters('workspaceName')), '2015-11-01-preview').retentionInDays]"
},
"immediatePurgeDataOn30Days": {
"type": "bool",
parameters('workspaceName')), '2015-11-01-preview').features.immediatePurgeDataOn30Days]"
},
"portalUrl": {
"type": "string",
parameters('workspaceName')), '2015-11-01-preview').portalUrl]"
}
}
}
Deploying the sample template

To deploy the sample template:
1. Save the attached sample in a file, for example azuredeploy.json
2. Edit the template to have the configuration you want
3. Use PowerShell or the command line to deploy the template
PowerShell
New-AzResourceGroupDeployment -Name <deployment-name> -ResourceGroupName <resource-group-name> -TemplateFile

azuredeploy.json
Command line
azure config mode arm

azure group deployment create <my-resource-group> <my-deployment-name> --TemplateFile azuredeploy.json
Example Resource Manager templates

The Azure quickstart template gallery includes several templates for Log Analytics, including:
Deploy a virtual machine running Windows with the Log Analytics VM extension
Deploy a virtual machine running Linux with the Log Analytics VM extension
Monitor Azure Site Recovery using an existing Log Analytics workspace
Monitor Azure Web Apps using an existing Log Analytics workspace
Add an existing storage account to Log Analytics
Next steps
Deploy Windows agent to Azure VMs using Resource Manager template.
Deploy Linux agent to Azure VMs using Resource Manager template.
Design and build a management solution in Azure
(Preview)
NOTE
This is preliminary documentation for creating management solutions in Azure which are currently in preview. Any schema
described below is subject to change.
Management solutions provide packaged management scenarios that customers can add to their Log Analytics
workspace. This article presents a basic process to design and build a management solution that is suitable for
most common requirements. If you are new to building management solutions then you can use this process as a
starting point and then leverage the concepts for more complex solutions as your requirements evolve.
What is a management solution?

Management solutions contain Azure resources that work together to achieve a particular management scenario.
They are implemented as Resource Management templates that contain details of how to install and configure
their contained resources when the solution is installed.
The basic strategy is to start your management solution by building the individual components in your Azure
environment. Once you have the functionality working properly, then you can start packaging them into a
management solution file.
Design your solution

The most common pattern for a management solution is shown in the following diagram. The different
components in this pattern are discussed in the below.
Data sources
The first step in designing a solution is determining the data that you require from the Log Analytics repository.
This data may be collected by a data source or another solution, or your solution may need to provide the
process to collect it.
There are a number of ways data sources that can be collected in the Log Analytics repository as described in
Data sources in Log Analytics. This includes events in the Windows Event Log or generated by Syslog in addition
to performance counters for both Windows and Linux clients. You can also gather data from Azure resources
collected by Azure Monitor.
If you require data that's not accessible through any of the available data sources, then you can use the HTTP
Data Collector API which allows you to write data to the Log Analytics repository from any client that can call a
REST API. The most common means of custom data collection in a management solution is to create a runbook
in Azure Automation that collects the required data from Azure or external resources and uses the Data Collector
API to write to the repository.
Log searches
Log searches are used to extract and analyze data in the Log Analytics repository. They are used by views and
alerts in addition to allowing the user to perform ad hoc analysis of data in the repository.
You should define any queries that you think will be helpful to the user even if they aren't used by any views or
alerts. These will be available to them as Saved Searches in the portal, and you can also include them in a List of
Queries visualization part in your custom view.
Alerts
Alerts in Log Analytics identify issues through log searches against the data in the repository. They either notify
the user or automatically run an action in response. You should identify different alert conditions for your
application and include corresponding alert rules in your solution file.
If the issue can potentially be corrected with an automated process, then you'll typically create a runbook in Azure
Automation to perform this remediation. Most Azure services can be managed with cmdlets which the runbook
would leverage to perform such functionality.
If your solution requires external functionality in response to an alert, then you can use a webhook response. This
allows you to call an external web service sending information from the alert.
Views
Views in Log Analytics are used to visualize data from the Log Analytics repository. Each solution will typically
contain a single view with a tile that is displayed on the user's main dashboard. The view can contain any number
of visualization parts to provide different visualizations of the collected data to the user.
You create custom views using the View Designer which you can later export for inclusion in your solution file.
Create solution file

Once you've configured and tested the components that will be part of your solution, you can create your
solution file. You will implement the solution components in a Resource Manager template that includes a
solution resource with relationships to the other resources in the file.
Test your solution

While you are developing your solution, you will need to install and test it in your workspace. You can do this
using any of the available methods to test and install Resource Manager templates.
Publish your solution

Once you have completed and tested your solution, you can make it available to customers through either the
following sources.
Azure Quickstart templates. Azure Quickstart templates is a set of Resource Manager templates
contributed by the community through GitHub. You can make your solution available by following
information in the contribution guide.
Azure Marketplace. The Azure Marketplace allows you to distribute and sell your solution to other
developers, ISVs, and IT professionals. You can learn how to publish your solution to Azure Marketplace at
How to publish and manage an offer in the Azure Marketplace.
Next steps
Learn how to create a solution file for your management solution.
Learn the details of Authoring Azure Resource Manager templates.
Search Azure Quickstart Templates for samples of different Resource Manager templates.
Creating a management solution file in Azure
(Preview)
NOTE
Management solutions in Azure are implemented as Resource Manager templates. The main task in learning how
to author management solutions is learning how to author a template. This article provides unique details of
templates used for solutions and how to configure typical solution resources.
Tools
You can use any text editor to work with solution files, but we recommend leveraging the features provided in
Visual Studio or Visual Studio Code as described in the following articles.
Creating and deploying Azure resource groups through Visual Studio
Working with Azure Resource Manager Templates in Visual Studio Code
Structure
The basic structure of a management solution file is the same as a Resource Manager Template, which is as
follows. Each of the sections below describes the top-level elements and their contents in a solution.
{
"contentVersion": "1.0",
"parameters": { },
"variables": { },
"resources": [ ],
"outputs": { }
}
Parameters
Parameters are values that you require from the user when they install the management solution. There are
standard parameters that all solutions will have, and you can add additional parameters as required for your
particular solution. How users will provide parameter values when they install your solution will depend on the
particular parameter and how the solution is being installed.
When a user installs your management solution through the Azure Marketplace or Azure QuickStart templates
they are prompted to select a Log Analytics workspace and Automation account. These are used to populate the
values of each of the standard parameters. The user is not prompted to directly provide values for the standard
parameters, but they are prompted to provide values for any additional parameters.
A sample parameter is shown below.
"startTime": {
"type": "string",
"metadata": {
"description": "Enter time for starting VMs by resource group.",
"control": "datetime",
"category": "Schedule"
}
The following table describes the attributes of a parameter.
ATTRIBUTE DESCRIPTION
type Data type for the parameter. The input control displayed for
the user depends on the data type.
bool - Drop down box

string - Text box
int - Text box
securestring - Password field
category Optional category for the parameter. Parameters in the same

category are grouped together.
control Additional functionality for string parameters.
datetime - Datetime control is displayed.

guid - Guid value is automatically generated, and the
parameter is not displayed.
description Optional description for the parameter. Displayed in an

information balloon next to the parameter.
Standard parameters
The following table lists the standard parameters for all management solutions. These values are populated for
the user instead of prompting for them when your solution is installed from the Azure Marketplace or Quickstart
templates. The user must provide values for them if the solution is installed with another method.
NOTE
The user interface in the Azure Marketplace and Quickstart templates is expecting the parameter names in the table. If you
use different parameter names then the user will be prompted for them, and they will not be automatically populated.
PARAMETER TYPE DESCRIPTION
accountName string Azure Automation account name.
pricingTier string Pricing tier of both Log Analytics

workspace and Azure Automation
account.
regionId string Region of the Azure Automation

account.
PARAMETER TYPE DESCRIPTION
solutionName string Name of the solution. If you are

deploying your solution through
Quickstart templates, then you should
define solutionName as a parameter so
you can define a string instead
requiring the user to specify one.
workspaceName string Log Analytics workspace name.
workspaceRegionId string Region of the Log Analytics workspace.
Following is the structure of the standard parameters that you can copy and paste into your solution file.
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
"description": "A valid Log Analytics workspace name"
}
},
"accountName": {
"type": "string",
"metadata": {
"description": "A valid Azure Automation account name"
}
},
"workspaceRegionId": {
"type": "string",
"metadata": {
"description": "Region of the Log Analytics workspace"
}
},
"regionId": {
"type": "string",
"metadata": {
"description": "Region of the Azure Automation account"
}
},
"pricingTier": {
"type": "string",
"metadata": {
"description": "Pricing tier of both Log Analytics workspace and Azure Automation account"
}
}
}
You refer to parameter values in other elements of the solution with the syntax parameters('parameter name').
For example, to access the workspace name, you would use parameters('workspaceName')
Variables
Variables are values that you will use in the rest of the management solution. These values are not exposed to the
user installing the solution. They are intended to provide the author with a single location where they can manage
values that may be used multiple times throughout the solution. You should put any values specific to your
solution in variables as opposed to hard coding them in the resources element. This makes the code more
readable and allows you to easily change these values in later versions.
Following is an example of a variables element with typical parameters used in solutions.
"variables": {
"SolutionVersion": "1.1",
"SolutionPublisher": "Contoso",
"SolutionName": "My Solution",
"LogAnalyticsApiVersion": "2015-11-01-preview",
"AutomationApiVersion": "2015-10-31"
},
You refer to variable values through the solution with the syntax variables('variable name'). For example, to
access the SolutionName variable, you would use variables('SolutionName').
You can also define complex variables that multiple sets of values. These are particularly useful in management
solutions where you are defining multiple properties for different types of resources. For example, you could
restructure the solution variables shown above to the following.
"variables": {
"Solution": {
"Version": "1.1",
"Publisher": "Contoso",
"Name": "My Solution"
},
"AutomationApiVersion": "2015-10-31"
},
In this case, you refer to variable values through the solution with the syntax variables('variable
name').property. For example, to access the Solution Name variable, you would use
variables('Solution').Name.
Resources
Resources define the different resources that your management solution will install and configure. This will be the
largest and most complex portion of the template. You can get the structure and complete description of resource
elements in Authoring Azure Resource Manager templates. Different resources that you will typically define are
detailed in other articles in this documentation.
Dependencies
The dependsOn element specifies a dependency on another resource. When the solution is installed, a resource
is not created until all of its dependencies have been created. For example, your solution might start a runbook
when it's installed using a job resource. The job resource would be dependent on the runbook resource to make
sure that the runbook is created before the job is created.
Log Analytics workspace and Automation account
Management solutions require a Log Analytics workspace to contain views and an Automation account to contain
runbooks and related resources. These must be available before the resources in the solution are created and
should not be defined in the solution itself. The user will specify a workspace and account when they deploy your
solution, but as the author you should consider the following points.
Solution resource
Each solution requires a resource entry in the resources element that defines the solution itself. This will have a
type of Microsoft.OperationsManagement/solutions and have the following structure. This includes standard
parameters and variables that are typically used to define properties of the solution.
{
"name": "[concat(variables('Solution').Name, '[' ,parameters('workspaceName'), ']')]",
"location": "[parameters('workspaceRegionId')]",
"tags": { },
"apiVersion": "[variables('LogAnalyticsApiVersion')]",
"dependsOn": [
<list-of-resources>
],
"properties": {
"workspaceResourceId": "[resourceId('Microsoft.OperationalInsights/workspaces',
parameters('workspaceName'))]",
"referencedResources": [
<list-of-referenced-resources>
],
"containedResources": [
<list-of-contained-resources>
]
},
"plan": {
"name": "[concat(variables('Solution').Name, '[' ,parameters('workspaceName'), ']')]",
"Version": "[variables('Solution').Version]",
"product": "[variables('ProductName')]",
"publisher": "[variables('Solution').Publisher]",
"promotionCode": ""
}
}
Dependencies
The solution resource must have a dependency on every other resource in the solution since they need to exist
before the solution can be created. You do this by adding an entry for each resource in the dependsOn element.
Properties
The solution resource has the properties in the following table. This includes the resources referenced and
contained by the solution which defines how the resource is managed after the solution is installed. Each resource
in the solution should be listed in either the referencedResources or the containedResources property.
workspaceResourceId ID of the Log Analytics workspace in the form <Resource

Group
ID>/providers/Microsoft.OperationalInsights/workspaces/<
Workspace Name>.
referencedResources List of resources in the solution that should not be removed

when the solution is removed.
containedResources List of resources in the solution that should be removed when

the solution is removed.
The example above is for a solution with a runbook, a schedule, and view. The schedule and runbook are
referenced in the properties element so they are not removed when the solution is removed. The view is
contained so it is removed when the solution is removed.
Plan
The plan entity of the solution resource has the properties in the following table.
name Name of the solution.
version Version of the solution as determined by the author.
product Unique string to identify the solution.
publisher Publisher of the solution.
Next steps
Add saved searches and alerts to your management solution.
Add views to your management solution.
Add runbooks and other Automation resources to your management solution.
Learn the details of Authoring Azure Resource Manager templates.
Search Azure Quickstart Templates for samples of different Resource Manager templates.
Adding Azure Automation resources to a
management solution (Preview)
NOTE
This is preliminary documentation for creating management solutions which are currently in preview. Any schema described
below is subject to change.
Management solutions will typically include runbooks in Azure Automation to automate processes such as
collecting and processing monitoring data. In addition to runbooks, Automation accounts includes assets such as
variables and schedules that support the runbooks used in the solution. This article describes how to include
runbooks and their related resources in a solution.
NOTE
The samples in this article use parameters and variables that are either required or common to management solutions and
described in Design and build a management solution in Azure
Prerequisites
This article assumes that you're already familiar with the following information.
How to create a management solution.
The structure of a solution file.
How to author Resource Manager templates
Automation account
All resources in Azure Automation are contained in an Automation account. As described in Log Analytics
workspace and Automation account the Automation account isn't included in the management solution but must
exist before the solution is installed. If it isn't available, then the solution install will fail.
The name of each Automation resource includes the name of its Automation account. This is done in the solution
with the accountName parameter as in the following example of a runbook resource.
"name": "[concat(parameters('accountName'), '/MyRunbook'))]"
Runbooks
You should include any runbooks used by the solution in the solution file so that they're created when the solution
is installed. You cannot contain the body of the runbook in the template though, so you should publish the
runbook to a public location where it can be accessed by any user installing your solution.
Azure Automation runbook resources have a type of Microsoft.Automation/automationAccounts/runbooks
and have the following structure. This includes common variables and parameters so that you can copy and paste
this code snippet into your solution file and change the parameter names.
{
"name": "[concat(parameters('accountName'), '/', variables('Runbook').Name)]",
"type": "Microsoft.Automation/automationAccounts/runbooks",
"apiVersion": "[variables('AutomationApiVersion')]",
"dependsOn": [
],
"location": "[parameters('regionId')]",
"tags": { },
"properties": {
"runbookType": "[variables('Runbook').Type]",
"logProgress": "true",
"logVerbose": "true",
"description": "[variables('Runbook').Description]",
"publishContentLink": {
"uri": "[variables('Runbook').Uri]",
"version": [variables('Runbook').Version]"
}
}
}
The properties for runbooks are described in the following table.
runbookType Specifies the types of the runbook.
Script - PowerShell script

PowerShell - PowerShell workflow
GraphPowerShell - Graphical PowerShell script runbook
GraphPowerShellWorkflow - Graphical PowerShell workflow
runbook
logProgress Specifies whether progress records should be generated for

the runbook.
logVerbose Specifies whether verbose records should be generated for the

runbook.
description Optional description for the runbook.
publishContentLink Specifies the content of the runbook.
uri - Uri to the content of the runbook. This will be a .ps1 file
for PowerShell and Script runbooks, and an exported graphical
runbook file for a Graph runbook.
version - Version of the runbook for your own tracking.
Automation jobs
When you start a runbook in Azure Automation, it creates an automation job. You can add an automation job
resource to your solution to automatically start a runbook when the management solution is installed. This
method is typically used to start runbooks that are used for initial configuration of the solution. To start a runbook
at regular intervals, create a schedule and a job schedule
Job resources have a type of Microsoft.Automation/automationAccounts/jobs and have the following
structure. This includes common variables and parameters so that you can copy and paste this code snippet into
your solution file and change the parameter names.
{
"name": "[concat(parameters('accountName'), '/', parameters('Runbook').JobGuid)]",
"type": "Microsoft.Automation/automationAccounts/jobs",
"dependsOn": [
"[concat('Microsoft.Automation/automationAccounts/', parameters('accountName'), '/runbooks/',
variables('Runbook').Name)]"
],
"tags": { },
"properties": {
"runbook": {
"name": "[variables('Runbook').Name]"
},
"parameters": {
"Parameter1": "[[variables('Runbook').Parameter1]",
"Parameter2": "[[variables('Runbook').Parameter2]"
}
}
}
The properties for automation jobs are described in the following table.
runbook Single name entity with the name of the runbook to start.
parameters Entity for each parameter value required by the runbook.
The job includes the runbook name and any parameter values to be sent to the runbook. The job should depend
on the runbook that it's starting since the runbook must be created before the job. If you have multiple runbooks
that should be started you can define their order by having a job depend on any other jobs that should be run first.
The name of a job resource must contain a GUID which is typically assigned by a parameter. You can read more
about GUID parameters in Creating a management solution file in Azure.
Certificates
Azure Automation certificates have a type of Microsoft.Automation/automationAccounts/certificates and
have the following structure. This includes common variables and parameters so that you can copy and paste this
code snippet into your solution file and change the parameter names.
{
"name": "[concat(parameters('accountName'), '/', variables('Certificate').Name)]",
"type": "Microsoft.Automation/automationAccounts/certificates",
"tags": { },
"dependsOn": [
],
"properties": {
"base64Value": "[variables('Certificate').Base64Value]",
"thumbprint": "[variables('Certificate').Thumbprint]"
}
}
The properties for Certificates resources are described in the following table.
base64Value Base 64 value for the certificate.
thumbprint Thumbprint for the certificate.
Credentials
Azure Automation credentials have a type of Microsoft.Automation/automationAccounts/credentials and
{
"name": "[concat(parameters('accountName'), '/', variables('Credential').Name)]",
"type": "Microsoft.Automation/automationAccounts/credentials",
"tags": { },
"dependsOn": [
],
"properties": {
"userName": "[parameters('credentialUsername')]",
"password": "[parameters('credentialPassword')]"
}
}
The properties for Credential resources are described in the following table.
userName User name for the credential.
password Password for the credential.
Schedules
Azure Automation schedules have a type of Microsoft.Automation/automationAccounts/schedules and
{
"name": "[concat(parameters('accountName'), '/', variables('Schedule').Name)]",
"type": "microsoft.automation/automationAccounts/schedules",
"tags": { },
"dependsOn": [
],
"properties": {
"description": "[variables('Schedule').Description]",
"startTime": "[parameters('scheduleStartTime')]",
"timeZone": "[parameters('scheduleTimeZone')]",
"isEnabled": "[variables('Schedule').IsEnabled]",
"interval": "[variables('Schedule').Interval]",
"frequency": "[variables('Schedule').Frequency]"
}
}
The properties for schedule resources are described in the following table.
description Optional description for the schedule.
startTime Specifies the start time of a schedule as a DateTime object. A

string can be provided if it can be converted to a valid
DateTime.
isEnabled Specifies whether the schedule is enabled.
interval The type of interval for the schedule.
day
hour
frequency Frequency that the schedule should fire in number of days or

hours.
Schedules must have a start time with a value greater than the current time. You cannot provide this value with a
variable since you would have no way of knowing when it's going to be installed.
Use one of the following two strategies when using schedule resources in a solution.
Use a parameter for the start time of the schedule. This will prompt the user to provide a value when they
install the solution. If you have multiple schedules, you could use a single parameter value for more than one of
them.
Create the schedules using a runbook that starts when the solution is installed. This removes the requirement
of the user to specify a time, but you can't contain the schedule in your solution so it will be removed when the
solution is removed.
Job schedules
Job schedule resources link a runbook with a schedule. They have a type of
Microsoft.Automation/automationAccounts/jobSchedules and have the following structure. This includes
common variables and parameters so that you can copy and paste this code snippet into your solution file and
change the parameter names.
{
"name": "[concat(parameters('accountName'), '/', variables('Schedule').LinkGuid)]",
"type": "microsoft.automation/automationAccounts/jobSchedules",
"dependsOn": [
"[resourceId('Microsoft.Automation/automationAccounts/runbooks/', parameters('accountName'),
variables('Runbook').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/schedules/', parameters('accountName'),
variables('Schedule').Name)]"
],
"tags": {
},
"properties": {
"schedule": {
"name": "[variables('Schedule').Name]"
},
"runbook": {
}
}
}
The properties for job schedules are described in the following table.
schedule name Single name entity with the name of the schedule.
runbook name Single name entity with the name of the runbook.
Variables
Azure Automation variables have a type of Microsoft.Automation/automationAccounts/variables and have
the following structure. This includes common variables and parameters so that you can copy and paste this code
snippet into your solution file and change the parameter names.
{
"name": "[concat(parameters('accountName'), '/', variables('Variable').Name)]",
"type": "microsoft.automation/automationAccounts/variables",
"tags": { },
"dependsOn": [
],
"properties": {
"description": "[variables('Variable').Description]",
"isEncrypted": "[variables('Variable').Encrypted]",
"type": "[variables('Variable').Type]",
"value": "[variables('Variable').Value]"
}
}
The properties for variable resources are described in the following table.
description Optional description for the variable.

isEncrypted Specifies whether the variable should be encrypted.
type This property currently has no effect. The data type of the
variable will be determined by the initial value.
value Value for the variable.
NOTE
The type property currently has no effect on the variable being created. The data type for the variable will be determined by
the value.
If you set the initial value for the variable, it must be configured as the correct data type. The following table
provides the different data types allowable and their syntax. Note that values in JSON are expected to always be
enclosed in quotes with any special characters within the quotes. For example, a string value would be specified by
quotes around the string (using the escape character (\)) while a numeric value would be specified with one set of
quotes.
DATA TYPE DESCRIPTION EXAMPLE RESOLVES TO
string Enclose value in double ""Hello world"" "Hello world"

quotes.
numeric Numeric value with single "64" 64

quotes.
boolean true or false in quotes. "true" true

Note that this value must be
lowercase.
datetime Serialized date value. "\/Date(1495656897378)\/" 2017-05-24 13:14:57

You can use the ConvertTo-
Json cmdlet in PowerShell to
generate this value for a
particular date.
Example: get-date
"5/24/2017 13:14:57" |
ConvertTo-Json
Modules
Your management solution does not need to define global modules used by your runbooks because they will
always be available in your Automation account. You do need to include a resource for any other module used by
your runbooks.
Integration modules have a type of Microsoft.Automation/automationAccounts/modules and have the
following structure. This includes common variables and parameters so that you can copy and paste this code
{
"name": "[concat(parameters('accountName'), '/', variables('Module').Name)]",
"type": "Microsoft.Automation/automationAccounts/modules",
"dependsOn": [
],
"properties": {
"contentLink": {
"uri": "[variables('Module').Uri]"
}
}
}
The properties for module resources are described in the following table.
contentLink Specifies the content of the module.
uri - Uri to the content of the module. This will be a .ps1 file
for PowerShell and Script runbooks, and an exported graphical
runbook file for a Graph runbook.
version - Version of the module for your own tracking.
The runbook should depend on the module resource to ensure that it's created before the runbook.
Updating modules
If you update a management solution that includes a runbook that uses a schedule, and the new version of your
solution has a new module used by that runbook, then the runbook may use the old version of the module. You
should include the following runbooks in your solution and create a job to run them before any other runbooks.
This will ensure that any modules are updated as required before the runbooks are loaded.
Update-ModulesinAutomationToLatestVersion will ensure that all of the modules used by runbooks in your
solution are the latest version.
ReRegisterAutomationSchedule-MS -Mgmt will reregister all of the schedule resources to ensure that the
runbooks linked to them with use the latest modules.
Sample
Following is a sample of a solution that include that includes the following resources:
Runbook. This is a sample runbook stored in a public GitHub repository.
Automation job that starts the runbook when the solution is installed.
Schedule and job schedule to start the runbook at regular intervals.
Certificate.
Credential.
Variable.
Module. This is the OMSIngestionAPI module for writing data to Log Analytics.
The sample uses standard solution parameters variables that would commonly be used in a solution as opposed
to hardcoding values in the resource definitions.
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
"Description": "Name of Log Analytics workspace."
}
},
"accountName": {
"type": "string",
"metadata": {
"Description": "Name of Automation account."
}
},
"workspaceregionId": {
"type": "string",
"metadata": {
"Description": "Region of Log Analytics workspace."
}
},
"regionId": {
"type": "string",
"metadata": {
"Description": "Region of Automation account."
}
},
"pricingTier": {
"type": "string",
"metadata": {
"Description": "Pricing tier of both Log Analytics workspace and Azure Automation account."
}
},
"certificateBase64Value": {
"type": "string",
"metadata": {
"Description": "Base 64 value for certificate."
}
},
"certificateThumbprint": {
"metadata": {
"Description": "Thumbprint for certificate."
}
},
"credentialUsername": {
"type": "string",
"metadata": {
"Description": "Username for credential."
}
},
"credentialPassword": {
"metadata": {
"Description": "Password for credential."
}
},
"scheduleStartTime": {
"type": "string",
"metadata": {
"Description": "Start time for schedule."
}
},
"scheduleTimeZone": {
"type": "string",
"metadata": {
"Description": "Time zone for schedule."
}
},
"scheduleLinkGuid": {
"type": "string",
"metadata": {
"description": "GUID for the schedule link to runbook.",
"control": "guid"
}
},
"runbookJobGuid": {
"type": "string",
"metadata": {
"description": "GUID for the runbook job.",
"control": "guid"
}
}
},
"variables": {
"SolutionName": "MySolution",
"ProductName": "SampleSolution",
"AutomationApiVersion": "2015-10-31",
"Runbook": {
"Name": "MyRunbook",
"Description": "Sample runbook",
"Type": "PowerShell",
"Uri": "https://raw.githubusercontent.com/user/myrepo/master/samples/MyRunbook.ps1",
"JobGuid": "[parameters('runbookJobGuid')]"
},
"Certificate": {
"Name": "MyCertificate",
"Base64Value": "[parameters('certificateBase64Value')]",
"Thumbprint": "[parameters('certificateThumbprint')]"
},
"Credential": {
"Name": "MyCredential",
"UserName": "[parameters('credentialUsername')]",
"Password": "[parameters('credentialPassword')]"
},
"Schedule": {
"Name": "MySchedule",
"Description": "Sample schedule",
"IsEnabled": "true",
"Interval": "1",
"Frequency": "hour",
"StartTime": "[parameters('scheduleStartTime')]",
"TimeZone": "[parameters('scheduleTimeZone')]",
"LinkGuid": "[parameters('scheduleLinkGuid')]"
},
"Variable": {
"Name": "MyVariable",
"Description": "Sample variable",
"Encrypted": 0,
"Type": "string",
"Value": "'This is my string value.'"
},
"Module": {
"Name": "OMSIngestionAPI",
"Uri": "https://devopsgallerystorage.blob.core.windows.net/packages/omsingestionapi.1.3.0.nupkg"
}
},
"resources": [
{
"name": "[concat(variables('SolutionName'), '[' ,parameters('workspacename'), ']')]",
"tags": { },
"tags": { },
"dependsOn": [
"[resourceId('Microsoft.Automation/automationAccounts/jobs/', parameters('accountName'),
variables('Runbook').JobGuid)]",
"[resourceId('Microsoft.Automation/automationAccounts/certificates/', parameters('accountName'),
variables('Certificate').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/credentials/', parameters('accountName'),
variables('Credential').Name)]",
variables('Schedule').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/jobSchedules/', parameters('accountName'),
variables('Schedule').LinkGuid)]",
"[resourceId('Microsoft.Automation/automationAccounts/variables/', parameters('accountName'),
variables('Variable').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/modules/', parameters('accountName'),
variables('Module').Name)]"
],
"properties": {
parameters('workspacename'))]",
"[resourceId('Microsoft.Automation/automationAccounts/modules/', parameters('accountName'),
variables('Module').Name)]"
],
"[resourceId('Microsoft.Automation/automationAccounts/jobs/', parameters('accountName'),
variables('Runbook').JobGuid)]",
"[resourceId('Microsoft.Automation/automationAccounts/certificates/', parameters('accountName'),
variables('Certificate').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/credentials/', parameters('accountName'),
variables('Credential').Name)]",
"[resourceId('Microsoft.Automation/automationAccounts/jobSchedules/', parameters('accountName'),
variables('Schedule').LinkGuid)]",
"[resourceId('Microsoft.Automation/automationAccounts/variables/', parameters('accountName'),
variables('Variable').Name)]"
]
},
"plan": {
"name": "[concat(variables('SolutionName'), '[' ,parameters('workspaceName'), ']')]",
"Version": "[variables('SolutionVersion')]",
"publisher": "[variables('SolutionPublisher')]",
"promotionCode": ""
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Runbook').Name)]",
"type": "Microsoft.Automation/automationAccounts/runbooks",
"dependsOn": [
],
"tags": { },
"properties": {
"runbookType": "[variables('Runbook').Type]",
"logProgress": "true",
"logVerbose": "true",
"description": "[variables('Runbook').Description]",
"publishContentLink": {
"uri": "[variables('Runbook').Uri]",
"version": "1.0.0.0"
}
}
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Runbook').JobGuid)]",
"type": "Microsoft.Automation/automationAccounts/jobs",
"dependsOn": [
"[concat('Microsoft.Automation/automationAccounts/', parameters('accountName'), '/runbooks/',
variables('Runbook').Name)]"
],
"tags": { },
"properties": {
"runbook": {
},
"parameters": {
"targetSubscriptionId": "[subscription().subscriptionId]",
"resourcegroup": "[resourceGroup().name]",
"automationaccount": "[parameters('accountName')]"
}
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Certificate').Name)]",
"type": "Microsoft.Automation/automationAccounts/certificates",
"tags": { },
"dependsOn": [
],
"properties": {
"Base64Value": "[variables('Certificate').Base64Value]",
"Thumbprint": "[variables('Certificate').Thumbprint]"
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Credential').Name)]",
"type": "Microsoft.Automation/automationAccounts/credentials",
"tags": { },
"dependsOn": [
],
"properties": {
"userName": "[variables('Credential').UserName]",
"password": "[variables('Credential').Password]"
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Schedule').Name)]",
"type": "microsoft.automation/automationAccounts/schedules",
"tags": { },
"dependsOn": [
],
"properties": {
"description": "[variables('Schedule').Description]",
"startTime": "[variables('Schedule').StartTime]",
"timeZone": "[variables('Schedule').TimeZone]",
"isEnabled": "[variables('Schedule').IsEnabled]",
"frequency": "[variables('Schedule').Frequency]"
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Schedule').LinkGuid)]",
"type": "microsoft.automation/automationAccounts/jobSchedules",
"dependsOn": [
variables('Schedule').Name)]"
],
"tags": {
},
"properties": {
"schedule": {
"name": "[variables('Schedule').Name]"
},
"runbook": {
}
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Variable').Name)]",
"type": "microsoft.automation/automationAccounts/variables",
"tags": { },
"dependsOn": [
],
"properties": {
"description": "[variables('Variable').Description]",
"isEncrypted": "[variables('Variable').Encrypted]",
"type": "[variables('Variable').Type]",
"value": "[variables('Variable').Value]"
}
},
{
"name": "[concat(parameters('accountName'), '/', variables('Module').Name)]",
"type": "Microsoft.Automation/automationAccounts/modules",
"dependsOn": [
],
"properties": {
"contentLink": {
"uri": "[variables('Module').Uri]"
}
}
}
],
"outputs": { }
}
Next steps
Add a view to your solution to visualize collected data.
Adding Log Analytics saved searches and alerts to
management solution (Preview)
IMPORTANT
As announced earlier, log analytics workspace(s) created after June 1, 2019 - will be able to manage alert rules using only
Azure scheduledQueryRules REST API, Azure Resource Manager Template and PowerShell cmdlet. Customers can easily
switch their preferred means of alert rule management for older workspaces to leverage Azure Monitor scheduledQueryRules
as default and gain many new benefits like the ability to use native PowerShell cmdlets, increased lookback time period in
rules, creation of rules in separate resource group or subscription and much more.
NOTE
Management solutions will typically include saved searches in Log Analytics to analyze data collected by the
solution. They may also define alerts to notify the user or automatically take action in response to a critical issue.
This article describes how to define Log Analytics saved searches and alerts in a Resource Management template
so they can be included in management solutions.
NOTE
Prerequisites
This article assumes that you're already familiar with how to create a management solution and the structure of a
Resource Manager template and solution file.
Log Analytics Workspace

All resources in Log Analytics are contained in a workspace. As described in Log Analytics workspace and
Automation account, the workspace isn't included in the management solution but must exist before the solution is
installed. If it isn't available, then the solution install fails.
The name of the workspace is in the name of each Log Analytics resource. This is done in the solution with the
workspace parameter as in the following example of a SavedSearch resource.
"name": "[concat(parameters('workspaceName'), '/', variables('SavedSearchId'))]"
Log Analytics API version

All Log Analytics resources defined in a Resource Manager template have a property apiVersion that defines the
version of the API the resource should use.
The following table lists the API version for the resource used in this example.
RESOURCE TYPE API VERSION QUERY
savedSearches 2017-03-15-preview Event | where EventLevelName ==

"Error"
Saved Searches
Include saved searches in a solution to allow users to query data collected by your solution. Saved searches appear
under Saved Searches in the Azure portal. A saved search is also required for each alert.
Log Analytics saved search resources have a type of Microsoft.OperationalInsights/workspaces/savedSearches and
{
"name": "[concat(parameters('workspaceName'), '/', variables('SavedSearch').Name)]",
"type": "Microsoft.OperationalInsights/workspaces/savedSearches",
"dependsOn": [
],
"tags": { },
"properties": {
"etag": "*",
"query": "[variables('SavedSearch').Query]",
"displayName": "[variables('SavedSearch').DisplayName]",
"category": "[variables('SavedSearch').Category]"
}
}
Each property of a saved search is described in the following table.
category The category for the saved search. Any saved searches in the
same solution will often share a single category so they are
grouped together in the console.
displayname Name to display for the saved search in the portal.
query Query to run.
NOTE
You may need to use escape characters in the query if it includes characters that could be interpreted as JSON. For example,
if your query was AzureActivity | OperationName:"Microsoft.Compute/virtualMachines/write", it should be written in
the solution file as AzureActivity | OperationName:/"Microsoft.Compute/virtualMachines/write".
Alerts
Azure Log alerts are created by Azure Alert rules that run specified log queries at regular intervals. If the results of
the query match specified criteria, an alert record is created and one or more actions are run using Action Groups.
For users that extend alerts to Azure, actions are now controlled in Azure action groups. When a workspace and its
alerts are extended to Azure, you can retrieve or add actions by using the Action Group - Azure Resource Manager
Template. Alert rules in legacy management solution are made up of the following three different resources.
Saved search. Defines the log search that is run. Multiple alert rules can share a single saved search.
Schedule. Defines how often the log search is run. Each alert rule has one and only one schedule.
Alert action. Each alert rule has one action group resource or action resource (legacy) with a type of Alert that
defines the details of the alert such as the criteria for when an alert record is created and the alert's severity.
Action group resource can have a list of configured actions to take when alert is fired - such as voice call, SMS,
email, webhook, ITSM tool, automation runbook, logic app, etc.
Saved search resources are described above. The other resources are described below.
Schedule resource
A saved search can have one or more schedules with each schedule representing a separate alert rule. The
schedule defines how often the search is run and the time interval over which the data is retrieved. Schedule
resources have a type of Microsoft.OperationalInsights/workspaces/savedSearches/schedules/ and have the
following structure. This includes common variables and parameters so that you can copy and paste this code
{
"name": "[concat(parameters('workspaceName'), '/', variables('SavedSearch').Name, '/',
"type": "Microsoft.OperationalInsights/workspaces/savedSearches/schedules/",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'), '/savedSearches/',
variables('SavedSearch').Name)]"
],
"properties": {
"etag": "*",
"queryTimeSpan": "[variables('Schedule').TimeSpan]",
"enabled": "[variables('Schedule').Enabled]"
}
}
The properties for schedule resources are described in the following table.
ELEMENT NAME REQUIRED DESCRIPTION
enabled Yes Specifies whether the alert is enabled

when it's created.
interval Yes How often the query runs in minutes.
queryTimeSpan Yes Length of time in minutes over which to

evaluate results.
The schedule resource should depend on the saved search so that it's created before the schedule.
NOTE
Schedule Name must be unique in a given workspace; two schedules cannot have the same ID even if they are associated
with different saved searches. Also name for all saved searches, schedules, and actions created with the Log Analytics API
must be in lowercase.
Actions
A schedule can have multiple actions. An action may define one or more processes to perform such as sending a
mail or starting a runbook, or it may define a threshold that determines when the results of a search match some
criteria. Some actions will define both so that the processes are performed when the threshold is met. Actions can
be defined using [action group] resource or action resource.
There are two types of action resource specified by the Type property. A schedule requires one Alert action, which
defines the details of the alert rule and what actions are taken when an alert is created. Action resources have a
type of Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions .
Alert actions have the following structure. This includes common variables and parameters so that you can copy
and paste this code snippet into your solution file and change the parameter names.
{
"name": "[concat(parameters('workspaceName'), '/', variables('SavedSearch').Name, '/',
variables('Schedule').Name, '/', variables('Alert').Name)]",
"type": "Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'), '/savedSearches/',
variables('SavedSearch').Name, '/schedules/', variables('Schedule').Name)]"
],
"properties": {
"etag": "*",
"type": "Alert",
"name": "[variables('Alert').Name]",
"description": "[variables('Alert').Description]",
"severity": "[variables('Alert').Severity]",
"threshold": {
"operator": "[variables('Alert').Threshold.Operator]",
"value": "[variables('Alert').Threshold.Value]",
"metricsTrigger": {
"triggerCondition": "[variables('Alert').Threshold.Trigger.Condition]",
"operator": "[variables('Alert').Trigger.Operator]",
"value": "[variables('Alert').Trigger.Value]"
},
},
"GroupIds": "[variables('MyAlert').AzNsNotification.GroupIds]",
"CustomEmailSubject": "[variables('MyAlert').AzNsNotification.CustomEmailSubject]",
"CustomWebhookPayload": "[variables('MyAlert').AzNsNotification.CustomWebhookPayload]"
}
}
}
The properties for Alert action resources are described in the following tables.
type Yes Type of the action. This is Alert for alert

actions.
name Yes Display name for the alert. This is the

name that's displayed in the console for
the alert rule.
description No Optional description of the alert.

severity Yes Severity of the alert record from the

following values:
critical
warning
informational
Threshold
This section is required. It defines the properties for the alert threshold.
Operator Yes Operator for the comparison from the

following values:
gt = greater than
lt = less than
Value Yes The value to compare the results.
Met r i c sT r i gger
This section is optional. Include it for a metric measurement alert.
TriggerCondition Yes Specifies whether the threshold is for

total number of breaches or
consecutive breaches from the following
values:
Total
Consecutive
Operator Yes Operator for the comparison from the

following values:
gt = greater than
lt = less than
Value Yes Number of the times the criteria must

be met to trigger the alert.
Throttling
This section is optional. Include this section if you want to suppress alerts from the same rule for some amount of
time after an alert is created.
DurationInMinutes Yes if Throttling element included Number of minutes to suppress alerts

after one from the same alert rule is
created.
Azure action group

All alerts in Azure, use Action Group as the default mechanism for handling actions. With Action Group, you can
specify your actions once and then associate the action group to multiple alerts - across Azure. Without the need,
to repeatedly declare the same actions over and over again. Action Groups support multiple actions - including
email, SMS, Voice Call, ITSM Connection, Automation Runbook, Webhook URI and more.
For user's who have extended their alerts into Azure - a schedule should now have Action Group details passed
along with threshold, to be able to create an alert. E -mail details, Webhook URLs, Runbook Automation details,
and other Actions, need to be defined in side an Action Group first before creating an alert; one can create Action
Group from Azure Monitor in Portal or use Action Group - Resource Template.
AzNsNotification Yes The resource ID of the Azure action

group to be associated with alert for
taking necessary actions when alert
criteria is met.
CustomEmailSubject No Custom subject line of the mail sent to

all addresses specified in associated
action group.
CustomWebhookPayload No Customized payload to be sent to all

webhook endpoints defined in
associated action group. The format
depends on what the webhook is
expecting and should be a valid
serialized JSON.
Sample
Following is a sample of a solution that includes the following resources:
Saved search
Schedule
Action group
The sample uses standard solution parameters variables that would commonly be used in a solution as opposed to
hardcoding values in the resource definitions.
{
"contentVersion": "1.0",
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
"Description": "Name of Log Analytics workspace"
}
},
"type": "string",
"metadata": {
"Description": "Region of Log Analytics workspace"
}
},
"actiongroup": {
"type": "string",
"metadata": {
"Description": "List of action groups for alert actions separated by semicolon"
}
}
},
"variables": {
"SolutionName": "MySolution",
"ProductName": "SampleSolution",
"LogAnalyticsApiVersion-Search": "2017-03-15-preview",
"LogAnalyticsApiVersion-Solution": "2015-11-01-preview",
"MySearch": {
"displayName": "Error records by hour",
"query": "MyRecord_CL | summarize AggregatedValue = avg(Rating_d) by Instance_s,
bin(TimeGenerated, 60m)",
"category": "Samples",
"name": "Samples-Count of data"
},
"MyAlert": {
"Name": "[toLower(concat('myalert-',uniqueString(resourceGroup().id, deployment().name)))]",
"DisplayName": "My alert rule",
"Description": "Sample alert. Fires when 3 error records found over hour interval.",
"ThresholdOperator": "gt",
"ThresholdValue": 3,
"Schedule": {
"Name": "[toLower(concat('myschedule-',uniqueString(resourceGroup().id,
deployment().name)))]",
"Interval": 15,
"TimeSpan": 60
},
"MetricsTrigger": {
"TriggerCondition": "Consecutive",
"Operator": "gt",
"Value": 3
},
"ThrottleMinutes": 60,
"GroupIds": [
"[parameters('actiongroup')]"
],
"CustomEmailSubject": "Sample alert"
}
}
},
"resources": [
{
"name": "[concat(variables('SolutionName'), '[' ,parameters('workspacename'), ']')]",
"tags": { },
"apiVersion": "[variables('LogAnalyticsApiVersion-Solution')]",
"dependsOn": [
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches',
parameters('workspacename'), variables('MySearch').Name)]",
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches/schedules',
parameters('workspacename'), variables('MySearch').Name, variables('MyAlert').Schedule.Name)]",
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions',
parameters('workspacename'), variables('MySearch').Name, variables('MyAlert').Schedule.Name,
variables('MyAlert').Name)]"
],
"properties": {
parameters('workspacename'))]",
],
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches',
parameters('workspacename'), variables('MySearch').Name)]",
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches/schedules',
parameters('workspacename'), variables('MySearch').Name, variables('MyAlert').Schedule.Name)]",
"[resourceId('Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions',
parameters('workspacename'), variables('MySearch').Name, variables('MyAlert').Schedule.Name,
variables('MyAlert').Name)]"
]
]
},
"plan": {
"name": "[concat(variables('SolutionName'), '[' ,parameters('workspaceName'), ']')]",
"promotionCode": ""
}
},
{
"name": "[concat(parameters('workspaceName'), '/', variables('MySearch').Name)]",
"type": "Microsoft.OperationalInsights/workspaces/savedSearches",
"apiVersion": "[variables('LogAnalyticsApiVersion-Search')]",
"dependsOn": [ ],
"tags": { },
"properties": {
"etag": "*",
"query": "[variables('MySearch').query]",
"displayName": "[variables('MySearch').displayName]",
"category": "[variables('MySearch').category]"
}
},
{
"name": "[concat(parameters('workspaceName'), '/', variables('MySearch').Name, '/',
variables('MyAlert').Schedule.Name)]",
"type": "Microsoft.OperationalInsights/workspaces/savedSearches/schedules/",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'),
'/savedSearches/', variables('MySearch').Name)]"
],
"properties": {
"etag": "*",
"interval": "[variables('MyAlert').Schedule.Interval]",
"queryTimeSpan": "[variables('MyAlert').Schedule.TimeSpan]",
"enabled": true
}
},
{
"name": "[concat(parameters('workspaceName'), '/', variables('MySearch').Name, '/',
variables('MyAlert').Schedule.Name, '/', variables('MyAlert').Name)]",
"type": "Microsoft.OperationalInsights/workspaces/savedSearches/schedules/actions",
"dependsOn": [
'/savedSearches/', variables('MySearch').Name, '/schedules/', variables('MyAlert').Schedule.Name)]"
],
"properties": {
"etag": "*",
"Type": "Alert",
"Name": "[variables('MyAlert').DisplayName]",
"Description": "[variables('MyAlert').Description]",
"Severity": "[variables('MyAlert').Severity]",
"Threshold": {
"Operator": "[variables('MyAlert').ThresholdOperator]",
"Value": "[variables('MyAlert').ThresholdValue]",
"MetricsTrigger": {
"TriggerCondition": "[variables('MyAlert').MetricsTrigger.TriggerCondition]",
"Operator": "[variables('MyAlert').MetricsTrigger.Operator]",
"Value": "[variables('MyAlert').MetricsTrigger.Value]"
}
},
"Throttling": {
"DurationInMinutes": "[variables('MyAlert').ThrottleMinutes]"
},
"GroupIds": "[variables('MyAlert').AzNsNotification.GroupIds]",
"CustomEmailSubject": "[variables('MyAlert').AzNsNotification.CustomEmailSubject]"
}
}
}
}
]
}
The following parameter file provides samples values for this solution.
{
"parameters": {
"workspacename": {
"value": "myWorkspace"
},
"accountName": {
"value": "myAccount"
},
"value": "East US"
},
"regionId": {
"value": "East US 2"
},
"pricingTier": {
"value": "Free"
},
"actiongroup": {
"value": "/subscriptions/3b540246-808d-4331-99aa-
917b808a9166/resourcegroups/myTestGroup/providers/microsoft.insights/actiongroups/sample"
}
}
}
Next steps
Add Automation runbooks and other resources to your management solution.
Views in management solutions (Preview)
NOTE
Management solutions will typically include one or more views to visualize data. This article describes how to
export a view created by the View Designer and include it in a management solution.
NOTE
Prerequisites
This article assumes that you're already familiar with how to create a management solution and the structure of a
solution file.
Overview
To include a view in a management solution, you create a resource for it in the solution file. The JSON that
describes the view's detailed configuration is typically complex though and not something that a typical solution
author would be able to create manually. The most common method is to create the view using the View
Designer, export it, and then add its detailed configuration to the solution.
The basic steps to add a view to a solution are as follows. Each step is described in further detail in the sections
below.
1. Export the view to a file.
2. Create the view resource in the solution.
3. Add the view details.
Export the view to a file

Follow the instructions at Log Analytics View Designer to export a view to a file. The exported file will be in JSON
format with the same elements as the solution file.
The resources element of the view file will have a resource with a type of
Microsoft.OperationalInsights/workspaces that represents the Log Analytics workspace. This element will
have a subelement with a type of views that represents the view and contains its detailed configuration. You will
copy the details of this element and then copy it into your solution.
Create the view resource in the solution

Add the following view resource to the resources element of your solution file. This uses variables that are
described below that you must also add. Note that the Dashboard and OverviewTile properties are
placeholders that you will overwrite with the corresponding properties from the exported view file.
{
"name": "[concat(parameters('workspaceName'), '/', variables('ViewName'))]",
"type": "Microsoft.OperationalInsights/workspaces/views",
"location": "[parameters('workspaceregionId')]",
"id": "[Concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name,
'/providers/Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'),'/views/',
variables('ViewName'))]",
"dependson": [
],
"properties": {
"Id": "[variables('ViewName')]",
"Name": "[variables('ViewName')]",
"DisplayName": "[variables('ViewName')]",
"Description": "",
"Author": "[variables('ViewAuthor')]",
"Source": "Local",
"Dashboard": ,
"OverviewTile":
}
}
Add the following variables to the variables element of the solution file and replace the values to those for your
solution.
"LogAnalyticsApiVersion": "<api-version>",
"ViewAuthor": "Your name."
"ViewDescription": "Optional description of the view."
"ViewName": "Provide a name for the view here."
Note that you could copy the entire view resource from your exported view file, but you would need to make the
following changes for it to work in your solution.
The type for the view resource needs to be changed from views to
Microsoft.OperationalInsights/workspaces.
The name property for the view resource needs to be changed to include the workspace name.
The dependency on the workspace needs to be removed since the workspace resource isn't defined in the
solution.
DisplayName property needs to be added to the view. The Id, Name, and DisplayName must all match.
Parameter names must be changed to match the required set of parameters.
Variables should be defined in the solution and used in the appropriate properties.
Log Analytics API version
All Log Analytics resources defined in a Resource Manager template have a property apiVersion that defines the
version of the API the resource should use. This version is different for views with queries that use the legacy and
the upgraded query language.
The following table specifies the Log Analytics API versions for views in legacy and upgraded workspaces:
WORKSPACE VERSION API VERSION QUERY
v1 (legacy) 2015-11-01-preview Legacy format.

Example: Type=Event EventLevelName
= Error
WORKSPACE VERSION API VERSION QUERY
v2 (upgraded) 2015-11-01-preview Legacy format. Converted to upgraded

format on install.
Example: Type=Event EventLevelName
= Error
Converted to: Event | where
EventLevelName == "Error"
v2 (upgraded) 2017-03-03-preview Upgrade format.

Example: Event | where EventLevelName
== "Error"
Add the view details

The view resource in the exported view file will contain two elements in the properties element named
Dashboard and OverviewTile which contain the detailed configuration of the view. Copy these two elements
and their contents into the properties element of the view resource in your solution file.
Example
For example, the following sample shows a simple solution file with a view. Ellipses (...) are shown for the
Dashboard and OverviewTile contents for space reasons.
{
"parameters": {
"workspaceName": {
"type": "string"
},
"accountName": {
"type": "string"
},
"workspaceRegionId": {
"type": "string"
},
"regionId": {
"type": "string"
},
"pricingTier": {
"type": "string"
}
},
"variables": {
"SolutionName": "Contoso Solution",
"ViewAuthor": "user@contoso.com",
"ViewDescription": "This is a sample view.",
"ViewName": "Contoso View"
},
"resources": [
{
"name": "[concat(variables('SolutionName'), '(' ,parameters('workspacename'), ')')]",
"tags": { },
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspacename'), '/views/',
variables('ViewName'))]"
variables('ViewName'))]"
],
"properties": {
"workspaceResourceId": "[concat(resourceGroup().id,
'/providers/Microsoft.OperationalInsights/workspaces/', parameters('workspacename'))]",
],
'/views/', variables('ViewName'))]"
]
},
"plan": {
"name": "[concat(variables('SolutionName'), '(' ,parameters('workspaceName'), ')')]",
"product": "ContosoSolution",
"promotionCode": ""
}
},
{
"name": "[concat(parameters('workspaceName'), '/', variables('ViewName'))]",
"type": "Microsoft.OperationalInsights/workspaces/views",
"location": "[parameters('workspaceregionId')]",
"id": "[Concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/',
resourceGroup().name, '/providers/Microsoft.OperationalInsights/workspaces/',
parameters('workspaceName'),'/views/', variables('ViewName'))]",
"dependson": [
],
"properties": {
"Id": "[variables('ViewName')]",
"Name": "[variables('ViewName')]",
"DisplayName": "[variables('ViewName')]",
"Description": "[variables('ViewDescription')]",
"Author": "[variables('ViewAuthor')]",
"Source": "Local",
"Dashboard": ...,
"OverviewTile": ...
}
}
]
}
Next steps
Learn complete details of creating management solutions.
Include Automation runbooks in your management solution.
Best practices for creating management solutions in
Azure (Preview)
NOTE
This article provides best practices for creating a management solution file in Azure. This information will be
updated as additional best practices are identified.
Data sources
Data sources can be configured with a Resource Manager template, but they should not be included in a
solution file. The reason is that configuring data sources is not currently idempotent meaning that your
solution could overwrite existing configuration in the user's workspace.
For example, your solution may require Warning and Error events from the Application event log. If you
specify this as a data source in your solution, you risk removing Information events if the user had this
configured in their workspace. If you included all events, then you may be collecting excessive Information
events in the user's workspace.
If your solution requires data from one of the standard data sources, then you should define this as a
prerequisite. State in documentation that the customer must configure the data source on their own.
Add a Data Flow Verification message to any views in your solution to instruct the user on data sources that
need to be configured for required data to be collected. This message is displayed on the tile of the view
when required data is not found.
Runbooks
Add an Automation schedule for each runbook in your solution that needs to run on a schedule.
Include the IngestionAPI module in your solution to be used by runbooks writing data to the Log Analytics
repository. Configure the solution to reference this resource so that it remains if the solution is removed. This
allows multiple solutions to share the module.
Use Automation variables to provide values to the solution that users may want to change later. Even if the
solution is configured to contain the variable, it's value can still be changed.
Views
All solutions should include a single view that is displayed in the user's portal. The view can contain multiple
visualization parts to illustrate different sets of data.
Add a Data Flow Verification message to any views in your solution to instruct the user on data sources that
need to be configured for required data to be collected.
Configure the solution to contain the view so that it's removed if the solution is removed.
Alerts
Define the recipients list as a parameter in the solution file so the user can define them when they install the
solution.
Configure the solution to reference alert rules so that user's can change their configuration. They may want to
make changes such as modifying the recipient list, changing the threshold of the alert, or disabling the alert rule.
Next steps
Walk through the basic process of designing and building a management solution.
Learn how to create a solution file.
Add saved searches and alerts to your management solution.
Add Automation runbooks and other resources to your management solution.
Azure Monitor service limits
This article lists limits in different areas of Azure Monitor.
Alerts
RESOURCE DEFAULT LIMIT MAXIMUM LIMIT
Metric alerts (classic) 100 active alert rules per subscription. Call support.
Metric alerts 1000 active alert rules per subscription Call support.
in Azure public, Azure China 21Vianet
and Azure Government clouds.
Activity log alerts 100 active alert rules per subscription. Same as default.
Log alerts 512 Call support.
Action groups 2,000 action groups per subscription. Call support.
Autoscale settings 100 per region per subscription. Same as default.
Action groups
Azure app push 10 Azure app actions per action group. Call support.
Email 1,000 email actions in an action group. Call support.

No more than 100 emails in an hour.
Also see the rate limiting information.
ITSM 10 ITSM actions in an action group. Call support.
Logic app 10 logic app actions in an action group. Call support.
Runbook 10 runbook actions in an action group. Call support.
SMS 10 SMS actions in an action group. Call support.

No more than 1 SMS message every 5
minutes.
Voice 10 voice actions in an action group. Call support.

No more than 1 voice call every 5
minutes.
Webhook 10 webhook actions in an action group. Call support.

Maximum number of webhook calls is
1500 per minute per subscription.
Other limits are available at action-
specific information.
Log queries and language

LIMIT DESCRIPTION
Query language Azure Monitor uses the same Kusto query language as Azure
Data Explorer. See Azure Monitor log query language
differences for KQL language elements not supported in Azure
Monitor.
Azure regions Log queries can experience excessive overhead when data
spans Log Analytics workspaces in multiple Azure regions. See
Query limits for details.
Cross resource queries Maximum number of Application Insights resources and Log
Analytics workspaces in a single query limited to 100.
Cross-resource query is not supported in View Designer.
Cross-resource query in log alerts is supported in the new
scheduledQueryRules API.
See Cross-resource query limits for details.

Data collection volume and retention
TIER LIMIT PER DAY DATA RETENTION COMMENT
Current Per GB pricing tier No limit 30 - 730 days Data retention beyond 31
(introduced April 2018) days is available for
additional charges. Learn
more about Azure Monitor
pricing.
Legacy Free tiers 500 MB 7 days When your workspace

(introduced April 2016) reaches the 500 MB per day
limit, data ingestion stops
and resumes at the start of
the next day. A day is based
on UTC. Note that data
collected by Azure Security
Center is not included in this
500 MB per day limit and
will continue to be collected
above this limit.
Legacy Standalone Per GB No limit 30 to 730 days Data retention beyond 31

tier days is available for
(introduced April 2016) additional charges. Learn
pricing.
TIER LIMIT PER DAY DATA RETENTION COMMENT
Legacy Per Node (OMS) No limit 30 to 730 days Data retention beyond 31
(introduced April 2016) days is available for
additional charges. Learn
pricing.
Legacy Standard tier No limit 30 days Retention can't be adjusted
Legacy Premium tier No limit 365 days Retention can't be adjusted
Number of workspaces per subscription.
PRICING TIER WORKSPACE LIMIT COMMENTS
Free tier 10 This limit can't be increased.
All other tiers No limit You're limited by the number of

resources within a resource group and
the number of resource groups per
subscription.
Azure portal
CATEGORY LIMITS COMMENTS
Maximum records returned by a log 10,000 Reduce results using query scope, time
query range, and filters in the query.
Data Collector API
Maximum size for a single post 30 MB Split larger volumes into multiple posts.
Maximum size for field values 32 KB Fields longer than 32 KB are truncated.
Search API
Maximum records returned in a single 500,000

query
Maximum size of data returned 64,000,000 bytes (~61 MiB)
Maximum query running time 10 minutes See Timeouts for details.
Maximum request rate 200 requests per 30 seconds per AAD See Rate limits for details.
user or client IP address
General workspace limits

Maximum columns in a table 500
Maximum characters for column name 500
Regions at capacity West Central US You cannot currently create a new

workspace in this region since it is at
temporary capacity limit. This limit is
planned to be addressed by end of
October, 2019.
Data export Not currently available Use Azure Function or Logic App to
aggregate and export data.
Data ingestion volume rate

month at a growing pace. The default ingestion volume rate limit for data sent from Azure resources using
diagnostic settings is approximately 6 GB/min per workspace. This is an approximate value since the actual size
can vary between data types depending on the log length and its compression ratio. This limit does not apply to
data that is sent from agents or Data Collector API.
If you send data at a higher rate to a single workspace, some data is dropped, and an event is sent to the Operation
table in your workspace every 6 hours while the threshold continues to be exceeded. If your ingestion volume
continues to exceed the rate limit or you are expecting to reach it sometime soon, you can request an increase to
your workspace by opening a support request.
To be notified on such an event in your workspace, create a log alert rule using the following query with alert logic
base on number of results grater than zero.
Operation
|where OperationCategory == "Ingestion"
|where Detail startswith "The rate of data crossed the threshold"
NOTE
Depending on how long you've been using Log Analytics, you might have access to legacy pricing tiers. Learn more about
Log Analytics legacy pricing tiers.
There are some limits on the number of metrics and events per application, that is, per instrumentation key. Limits
depend on the pricing plan that you choose.
Total data per day 100 GB You can reduce data by setting a cap. If
you need more data, you can increase
the limit in the portal, up to 1,000 GB.
For capacities greater than 1,000 GB,
send email to
Data retention 90 days This resource is for Search, Analytics,

Availability multi-step test detailed 90 days This resource provides detailed results
results retention of each step.
Maximum event size 64,000
Next Steps
Azure Monitor pricing
Monitoring usage and estimated costs in Azure Monitor
Manage usage and costs for Application Insights
Dependency auto-collection
Below is the currently supported list of dependency calls that are automatically detected as dependencies without
requiring any additional modification to your application's code. These dependencies are visualized in the
Application Insights Application map and Transaction diagnostics views. If your dependency isn't on the list below,
you can still track it manually with a track dependency call.
.NET
APP FRAMEWORKS VERSIONS
ASP.NET Webforms 4.5+
ASP.NET MVC 4+
ASP.NET WebAPI 4.5+
ASP.NET Core 1.1+
Communication libraries
HttpClient 4.5+, .NET Core 1.1+
SqlClient .NET Core 1.0+, NuGet 4.3.0
EventHubs Client SDK 1.1.0
ServiceBus Client SDK 3.0.0
Storage clients
ADO.NET 4.5+
Java
APP SERVERS VERSIONS
Tomcat 7, 8
JBoss EAP 6, 7
Jetty 9
App frameworks
Spring 3.0
APP SERVERS VERSIONS
Spring Boot 1.5.9+*
Java Servlet 3.1+
Communication libraries
Apache Http Client 4.3+†
Storage clients
SQL Server 1+†
PostgreSQL (Beta Support)
Oracle 1+†
MySql 1+†
Logging libraries
Logback 1+
Log4j 1.2+
Metrics libraries
JMX 1.0+
NOTE
*Except reactive programing support.
†Requires installation of JVM Agent.
Node.js
COMMUNICATION LIBRARIES VERSIONS
HTTP, HTTPS 0.10+
Storage clients
Redis 2.x
MongoDb; MongoDb Core 2.x - 3.x
MySQL 2.0.0 - 2.16.x
PostgreSql; 6.x - 7.x

pg-pool 1.x - 2.x
Logging libraries
console 0.10+
Bunyan 1.x
Winston 2.x - 3.x
JavaScript
XMLHttpRequest All
Next steps
Set up custom dependency tracking for .NET.
Set up custom dependency tracking for Java.
Write custom dependency telemetry
See data model for Application Insights types and data model.
Check out platforms supported by Application Insights.

A distributed logical operation typically consists of a set of smaller operations, which are requests processed by
one of the components. These operations are defined by request telemetry. Every request telemetry has its own
id that identifies it uniquely and globally. And all telemetry items (such as traces and exceptions) that are
associated with this request should set the operation_parentId to the value of the request id .
In a microservices environment, traces from components can go to different storage items. Every component
can have its own instrumentation key in Application Insights. To get telemetry for the logical operation, the
Application Insights UX queries data from every storage item. When the number of storage items is huge, you'll
need a hint about where to look next. The Application Insights data model defines two fields to solve this
problem: request.source and dependency.target . The first field identifies the component that initiated the
dependency request, and the second identifies which component returned the response of the dependency call.
Example
using an external API called Stock . The Stock Prices application has a page called Stock page that the client
web browser opens by using GET /Home/Stock . The application queries the Stock API by using an HTTP call

In the results, note that all telemetry items share the root operation_Id . When an Ajax call is made from the
page, a new unique ID ( qJSXU ) is assigned to the dependency telemetry and the ID of the pageView is used as
When the call GET /api/stock/value is made to an external service, you want to know the identity of that server
so you can set the dependency.target field appropriately. When the external service doesn't support monitoring,
target is set to the host name of the service (for example, stock-prices-api.com ). However, if the service
identifies itself by returning a predefined HTTP header, target contains the service identity that allows
Application Insights to build a distributed trace by querying telemetry from that service.
Correlation headers
Latest versions of Application Insights SDKs support Trace-Context protocol, but you may need to opt-into that
(it will keep backward compatibility with old correlation protocol supported by ApplicationInsights SDKs).
value pairs to propagate the collection of properties used by the immediate caller or callee. The Application
Insights SDK uses this header to set dependency.target and request.source fields.
NOTE
If for any reason you want to keep using legacy Request-Id protocol, you may disable Trace-Context with
following configuration
Under DependencyTrackingTelemetryModule , add the EnableW3CHeadersInjection element with value set to
true .
...
NOTE
If for any reason you want to keep using legacy Request-Id protocol, you may disable Trace-Context with
following configuration
Trace-Context.

{
// ....
}

<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryMo
dule>
</Add>

<Instrumentation>
</BuiltIn>
</Instrumentation>
NOTE
Backward compatibility mode is enabled by default, and the enableW3CBackCompat parameter is optional. Use it
only when you want to turn backward compatibility off.
Ideally, you would turn this off when all your services have been updated to newer versions of SDKs that support
the W3C protocol. We highly recommend that you move to these newer SDKs as soon as possible.
IMPORTANT


} });

n=a.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",a.get
ElementsByTagName("script")[0].parentNode.appendChild(n)});try{i.cookie=a.cookie}catch(e){}i.queue=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n(
"track"+r.pop());n("startTrackPage"),n("stopTrackPage");var
o="Track"+r[0];if(n("start"+o),n("stop"+o),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&
!0===e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+
(r="onerror"));var s=t[r];t[r]=function(e,n,a,t,o){var c=s&&s(e,n,a,t,o);return!0!==c&&i["_"+r]
(
{
}
);
</script>


However, those methods didn't enable automatic distributed tracing support. DiagnosticSource is a way to
support automatic cross-machine correlation. .NET libraries support 'DiagnosticSource' and allow automatic
cross-machine propagation of the correlation context via the transport, such as HTTP.

The Application Insights SDK for Java supports automatic correlation of telemetry beginning with version 2.0.0.
It automatically populates operation_id for all telemetry (such as traces, exceptions, and custom events) issued
NOTE
Only calls made via Apache HTTPClient are supported for the correlation feature. If you're using Spring RestTemplate or
Feign, both can be used with Apache HTTPClient under the hood.
Currently, automatic context propagation across messaging technologies (such Kafka, RabbitMQ, or Azure
Service Bus) isn't supported. However, it's possible to code such scenarios manually by using the
trackDependency and trackRequest APIs. In these APIs, a dependency telemetry represents a message being
enqueued by a producer, and the request represents a message being processed by a consumer. In this case,
both operation_id and operation_parentId should be propagated in the message's properties.
Role name
At times, you might want to customize the way component names are displayed in the Application Map. To do
so, you can manually set the cloud_RoleName by doing one of the following:
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebAppNameContextInitializer"
/>
Next steps
For advanced correlation scenarios in ASP.NET Core and ASP.NET consult the track custom operations
article.
Application Insights NuGet packages
Below is the current list of stable release NuGet Packages for Application Insights.
Common packages for ASP.NET

PACKAGE NAME STABLE VERSION DESCRIPTION DOWNLOAD
Microsoft.ApplicationInsights 2.8.0 Provides core functionality Download Package

for transmission of all
Telemetry Types and is a
dependent package for all
other Application Insights
packages
Microsoft.ApplicationInsights 2.4.0 Enables Interception of Download Package

.Agent.Intercept method calls
Microsoft.ApplicationInsights 2.8.0 Application Insights Download Package

.DependencyCollector Dependency Collector for
.NET applications. This is a
dependent package for
platform-specific packages
and provides automatic
collection of dependency
telemetry.

.PerfCounterCollector Performance Counters
Collector allows you to send
data collected by
Performance Counters to
Microsoft.ApplicationInsights 2.8.0 Application Insights for .NET Download Package

.Web web applications

.WindowsServer Windows Server NuGet
package provides automatic
collection of application
insights telemetry for .NET
applications. This package
can be used as a dependent
package for Application
Insights platform-specific
packages or as a standalone
package for .NET applications
that are not covered by
(like for .NET worker roles).
Microsoft.ApplicationInsights 2.8.0 Provides a telemetry channel Download Package

.WindowsServer.TelemetryCh to Application Insights
annel Windows Server SDK that
will preserve telemetry in
offline scenarios.
Common packages for ASP.NET Core

Microsoft.ApplicationInsights 2.5.0 Application Insights for Download Package

.AspNetCore ASP.NET Core web
applications.
Microsoft.ApplicationInsights 2.8.0 This package provides core Download Package

functionality for transmission
of all Application Insights
Telemetry Types and is a
dependent package for all
other Application Insights
packages

.DependencyCollector Dependency Collector for
.NET applications. This is a
dependent package for
and provides automatic
collection of dependency
telemetry.

.PerfCounterCollector Performance Counters
Collector allows you to send
data collected by
Performance Counters to

.WindowsServer Windows Server NuGet
package provides automatic
collection of application
insights telemetry for .NET
applications. This package
can be used as a dependent
package for Application
Insights platform-specific
packages or as a standalone
package for .NET applications
that are not covered by
(like for .NET worker roles).
Microsoft.ApplicationInsights 2.8.0 Provides a telemetry channel Download Package

.WindowsServer.TelemetryCh to Application Insights
annel Windows Server SDK that
will preserve telemetry in
offline scenarios.
Listeners/collectors/appenders
Microsoft.ApplicationInsights 2.7.2 Allows forwarding events Download Package

.DiagnosticSourceListener from DiagnosticSource to

.EventSourceListener EventSourceListener allows
sending data from
EventSource events to

.EtwCollector EtwCollector allows sending
data from Event Tracing for
Windows (ETW) to
Microsoft.ApplicationInsights 2.7.2 A custom TraceListener Download Package

.TraceListener allowing you to send trace
log messages to Application
Insights.
Microsoft.ApplicationInsights 2.7.2 A custom appender allowing Download Package

.Log4NetAppender you to send Log4Net log
messages to Application
Insights.
Microsoft.ApplicationInsights 2.7.2 a custom target allowing you Download Package

.NLogTarget to send NLog log messages
to Application Insights.
Microsoft.ApplicationInsights 1.3.1 Monitors exceptions in your Download Package

.SnapshotCollector application and automatically
collects snapshots for offline
analysis.
Service Fabric
Microsoft.ApplicationInsights 2.2.0 This package provides Download Package

.ServiceFabric automatic decoration of
telemetry with the service
fabric context the application
is running in. Do not use this
NuGet for Native Service
Fabric applications.
Microsoft.ApplicationInsights 2.2.0 Application Insights module Download Package

.ServiceFabric.Native for service fabric
applications. Use this NuGet
only for Native Service Fabric
applications. For applications
running in containers, use
.ServiceFabric package.
Status monitor
Microsoft.ApplicationInsights 2.2.1 Enables runtime data Download Package

.Agent_x64 collection for x64
applications
Microsoft.ApplicationInsights 2.2.1 Enables runtime data Download Package

.Agent_x86 collection for x86
applications.
These packages make up part of the core functionality of the runtime monitoring in Status Monitor. You don't need
to download these packages directly, just use the Status Monitor installer. If you want to understand more about
how these packages work under the hood this blog post from one of our developers is a good start.
Additional packages
Microsoft.ApplicationInsights 2.6.5 This extension enables the Download Package

.AzureWebSites Application Insights
monitoring on an Azure App
Service. SDK version 2.6.1.
Instructions: Add
'APPINSIGHTS_INSTRUMENT
ATIONKEY' application
settings with your ikey and
restart the webapp to take
an effect.
Microsoft.ApplicationInsights 2.6.7 This package contains files Download Package

.Injector required for codeless
Application Insights injection
Next steps
Monitor ASP.NET Core.
Profile ASP.NET Core Azure Linux web apps.
Debug ASP.NET snapshots.
Supported languages
C#|VB (.NET)
Java
JavaScript
Node.JS
Supported platforms and frameworks

Instrumentation for already-deployed applications (codeless, agent-based)
Azure VM and Azure virtual machine scale sets
Azure App Service
ASP.NET - for apps that are already live
Azure Cloud Services, including both web and worker roles
Azure Functions
Instrumentation through code (SDKs)
ASP.NET
ASP.NET Core
Android (App Center)
iOS (App Center)
Java EE
Node.JS
Universal Windows app (App Center)
Windows desktop applications, services, and worker roles
Logging frameworks
ILogger
Log4Net, NLog, or System.Diagnostics.Trace
Java, Log4J, or Logback
LogStash plugin
Azure Monitor
Export and data analysis

Power BI
Stream Analytics
Unsupported SDKs
We're aware that several other community-supported SDKs exist. However, Azure Monitor only provides
support when using the supported SDKs listed on this page. We’re constantly assessing opportunities to
expand our support for other languages, so follow our GitHub Announcements page to receive the latest SDK
news.
Application Insights overriding default endpoints
To send data from Application Insights to certain regions, you'll need to override the default endpoint addresses. Each SDK requires
slightly different modifications, all of which are described in this article. These changes require adjusting the sample code and replacing
the placeholder values for QuickPulse_Endpoint_Address , TelemetryChannel_Endpoint_Address , and Profile_Query_Endpoint_address with
the actual endpoint addresses for your specific region. The end of this article contains links to the endpoint addresses for regions where
this configuration is required.
SDK code changes

.NET with applicationinsights.config
NOTE
The applicationinsights.config file is automatically overwritten anytime a SDK upgrade is performed. After performing an SDK upgrade be sure to re-
enter the region specific endpoint values.
...
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule,
<QuickPulseServiceEndpoint>Custom_QuickPulse_Endpoint_Address</QuickPulseServiceEndpoint>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
<EndpointAddress>TelemetryChannel_Endpoint_Address</EndpointAddress>
</TelemetryChannel>
...
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationIdProvider,
Microsoft.ApplicationInsights">
<ProfileQueryEndpoint>Profile_Query_Endpoint_address</ProfileQueryEndpoint>
...
ASP.NET Core
Modify the appsettings.json file in your project as follows to adjust the main endpoint:
"InstrumentationKey": "instrumentationkey",
"TelemetryChannel": {
"EndpointAddress": "TelemetryChannel_Endpoint_Address"
}
}
The values for Live Metrics and the Profile Query Endpoint can only be set via code. To override the default values for all endpoint
values via code, make the following changes in the ConfigureServices method of the Startup.cs file:
using Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse; //Place at top of Startup.cs file
services.ConfigureTelemetryModule<QuickPulseTelemetryModule>((module, o) =>
module.QuickPulseServiceEndpoint="QuickPulse_Endpoint_Address");
services.AddSingleton<IApplicationIdProvider, ApplicationInsightsApplicationIdProvider>(_ => new

ApplicationInsightsApplicationIdProvider() { ProfileQueryEndpoint = "Profile_Query_Endpoint_address" });
services.AddSingleton<ITelemetryChannel>(_ => new ServerTelemetryChannel() { EndpointAddress =

"TelemetryChannel_Endpoint_Address" });
//Place in the ConfigureServices method. Place this before services.AddApplicationInsightsTelemetry("instrumentation key"); if

it's present
Azure Functions v2.x

Install the following packages in your function project:
Microsoft.ApplicationInsights version 2.10.0
Microsoft.ApplicationInsights.PerfCounterCollector version 2.10.0
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel version 2.10.0
Then, add (or modify) the startup code for your function application:
[assembly: WebJobsStartup(typeof(Example.Startup))]
namespace Example
{
class Startup : FunctionsStartup
{
public override void Configure(IWebJobsBuilder builder)
{
var quickPulseFactory = builder.Services.FirstOrDefault(sd => sd.ServiceType == typeof(ITelemetryModule) &&
sd.ImplementationType == typeof(QuickPulseTelemetryModule));
if (quickPulseFactory != null)
{
builder.Services.Remove(quickPulseFactory);
}
var appIdFactory = builder.Services.FirstOrDefault(sd => sd.ServiceType == typeof(IApplicationIdProvider));

if (appIdFactory != null)
{
builder.Services.Remove(appIdFactory);
}
var channelFactory = builder.Services.FirstOrDefault(sd => sd.ServiceType == typeof(ITelemetryChannel));

if (channelFactory != null)
{
builder.Services.Remove(channelFactory);
}
builder.Services.AddSingleton<ITelemetryModule, QuickPulseTelemetryModule>(_ =>

new QuickPulseTelemetryModule
{
QuickPulseServiceEndpoint = "QuickPulse_Endpoint_Address"
});
builder.Services.AddSingleton<IApplicationIdProvider, ApplicationInsightsApplicationIdProvider>(_ => new

ApplicationInsightsApplicationIdProvider() { ProfileQueryEndpoint = "Profile_Query_Endpoint_address" });
builder.Services.AddSingleton<ITelemetryChannel>(_ => new ServerTelemetryChannel() { EndpointAddress =

"TelemetryChannel_Endpoint_Address" });
}
}
}
Java
Modify the applicationinsights.xml file to change the default endpoint address.
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<InstrumentationKey>ffffeeee-dddd-cccc-bbbb-aaaa99998888</InstrumentationKey>
<TelemetryModules>
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
</TelemetryModules>
<Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitializer"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitializer"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
<Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"/>

<Channel type="com.microsoft.applicationinsights.channel.concrete.inprocess.InProcessTelemetryChannel">
<EndpointAddress>TelemetryChannel_Endpoint_Address</EndpointAddress>
</Channel>
Spring Boot
Modify the application.properties file and add:
azure.application-insights.channel.in-process.endpoint-address= TelemetryChannel_Endpoint_Address
Node.js

appInsights.setup('INSTRUMENTATION_KEY');
appInsights.defaultClient.config.endpointUrl = "TelemetryChannel_Endpoint_Address"; // ingestion
appInsights.defaultClient.config.profileQueryEndpoint = "Profile_Query_Endpoint_address"; // appid/profile lookup
appInsights.defaultClient.config.quickPulseHost = "QuickPulse_Endpoint_Address"; //live metrics
appInsights.Configuration.start();
The endpoints can also be configured through environment variables:
Instrumentation Key: "APPINSIGHTS_INSTRUMENTATIONKEY"

Profile Endpoint: "Profile_Query_Endpoint_address"
Live Metrics Endpoint: "QuickPulse_Endpoint_Address"
JavaScript
aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){t[e]=function(){var n=arguments;t.queue.push(function()
{t[e].apply(t,n)})}}var t={config:e};t.initialize=!0;var i=document,a=window;setTimeout(function(){var
n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.getElementsByTagName("script")
[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e){}t.queue=[],t.version=2;for(var r=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("track"+r.pop());n("startTrack
Page"),n("stopTrackPage");var
s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedUserContext"),n("flush"),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0===e.extensionConfig.Applica
tionInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var o=a[r];a[r]=function(e,n,i,a,s){var
c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]
{
endpointUrl: "TelemetryChannel_Endpoint_Address"
}
</script>
Regions that require endpoint modification

Currently the only regions that require endpoint modifications are Azure Government and Azure China.
REGION ENDPOINT NAME VALUE
Azure China Telemetry Channel https://dc.applicationinsights.azure.cn/v2/track
Azure China QuickPulse (Live Metrics) https://live.applicationinsights.azure.cn/QuickPulseServic
Azure China Profile Query https://dc.applicationinsights.azure.cn/api/profiles/{0}/a
Azure Government Telemetry Channel https://dc.applicationinsights.us/v2/track
Azure Government QuickPulse (Live Metrics) https://quickpulse.applicationinsights.us/QuickPulseServic
Azure Government Profile Query https://dc.applicationinsights.us/api/profiles/{0}/appId
If you currently use the Application Insights REST API which is normally accessed via àpi.applicationinsights.io' you will need to use an
endpoint that is local to your region:
REGION ENDPOINT NAME VALUE
Azure China REST API api.applicationinsights.azure.cn
Azure Government REST API api.applicationinsights.us
NOTE
Codeless agent/extension based monitoring for Azure App Services is currently not supported in these regions. As soon as this functionality
becomes available this article will be updated.
Next steps
To learn more about the custom modifications for Azure Government, consult the detailed guidance for Azure monitoring and
management.
To learn more about Azure China, consult the Azure China Playbook.
Application Insights telemetry data model
Azure Application Insights sends telemetry from your web application to the Azure portal, so that you can
analyze the performance and usage of your application. The telemetry model is standardized so that it is
possible to create platform and language-independent monitoring.
Data collected by Application Insights models this typical application execution pattern:
The following types of telemetry are used to monitor the execution of your app. The following three types are
typically automatically collected by the Application Insights SDK from the web application framework:
Request - Generated to log a request received by your app. For example, the Application Insights web
SDK automatically generates a Request telemetry item for each HTTP request that your web app
receives.
An Operation is the threads of execution that processes a request. You can also write code to monitor
other types of operation, such as a "wake up" in a web job or function that periodically processes data.
Each operation has an ID. This ID that can be used to group all telemetry generated while your app is
processing the request. Each operation either succeeds or fails, and has a duration of time.
Exception - Typically represents an exception that causes an operation to fail.
Dependency - Represents a call from your app to an external service or storage such as a REST API or
SQL. In ASP.NET, dependency calls to SQL are defined by System.Data . Calls to HTTP endpoints are
defined by System.Net .
Application Insights provides three additional data types for custom telemetry:
Trace - used either directly, or through an adapter to implement diagnostics logging using an
instrumentation framework that is familiar to you, such as Log4Net or System.Diagnostics .
Event - typically used to capture user interaction with your service, to analyze usage patterns.
Metric - used to report periodic scalar measurements.
Every telemetry item can define the context information like application version or user session id. Context is a
set of strongly typed fields that unblocks certain scenarios. When application version is properly initialized,
Application Insights can detect new patterns in application behavior correlated with redeployment. Session id
can be used to calculate the outage or an issue impact on users. Calculating distinct count of session id values
for certain failed dependency, error trace or critical exception gives a good understanding of an impact.
Application Insights telemetry model defines a way to correlate telemetry to the operation of which it’s a part.
For example, a request can make a SQL Database calls and recorded diagnostics info. You can set the
correlation context for those telemetry items that tie it back to the request telemetry.
Schema improvements
Application Insights data model is a simple and basic yet powerful way to model your application telemetry.
We strive to keep the model simple and slim to support essential scenarios and allow to extend the schema for
advanced use.
To report data model or schema problems and suggestions use GitHub ApplicationInsights-Home repository.
Next steps
Write custom telemetry
Use sampling to minimize amount of telemetry based on data model.
Request telemetry: Application Insights data model
A request telemetry item (in Application Insights) represents the logical sequence of execution triggered by an
external request to your application. Every request execution is identified by unique ID and url containing all
the execution parameters. You can group requests by logical name and define the source of this request. Code
execution can result in success or fail and has a certain duration . Both success and failure executions may be
grouped further by resultCode . Start time for the request telemetry defined on the envelope level.
Request telemetry supports the standard extensibility model using custom properties and measurements .
Name
Name of the request represents code path taken to process the request. Low cardinality value to allow better
grouping of requests. For HTTP requests it represents the HTTP method and URL path template like
GET /values/{id} without the actual id value.
Application Insights web SDK sends request name "as is" with regards to letter case. Grouping on UI is case-
sensitive so GET /Home/Index is counted separately from GET /home/INDEX even though often they result in the
same controller and action execution. The reason for that is that urls in general are case-sensitive. You may want
to see if all 404 happened for the urls typed in uppercase. You can read more on request name collection by
ASP.NET Web SDK in the blog post.
Max length: 1024 characters
ID
Identifier of a request call instance. Used for correlation between request and other telemetry items. ID should be
globally unique. For more information, see correlation page.
Url
Request URL with all query string parameters.
Source
Source of the request. Examples are the instrumentation key of the caller or the ip address of the caller. For more
information, see correlation page.
Duration
Request duration in format: DD.HH:MM:SS.MMMMMM . Must be positive and less than 1000 days. This field is required
as request telemetry represents the operation with the beginning and the end.
Response code
Result of a request execution. HTTP status code for HTTP requests. It may be HRESULT value or exception type for
other request types.
Success
Indication of successful or unsuccessful call. This field is required. When not set explicitly to false - a request is
considered to be successful. Set this value to false if operation was interrupted by exception or returned error
result code.
For the web applications, Application Insights define a request as successful when the response code is less than
400 or equal to 401 . However there are cases when this default mapping does not match the semantic of the
application. Response code 404 may indicate "no records", which can be part of regular flow. It also may indicate
a broken link. For the broken links, you can even implement more advanced logic. You can mark broken links as
failures only when those links are located on the same site by analyzing url referrer. Or mark them as failures
when accessed from the company's mobile application. Similarly 301 and 302 indicates failure when accessed
from the client that doesn't support redirect.
Partially accepted content 206 may indicate a failure of an overall request. For instance, Application Insights
endpoint receives a batch of telemetry items as a single request. It returns 206 when some items in the batch
were not processed successfully. Increasing rate of 206 indicates a problem that needs to be investigated. Similar
logic applies to 207 Multi-Status where the success may be the worst of separate response codes.
You can read more on request result code and status code in the blog post.
Custom properties
Name-value collection of custom properties. This collection is used to extend standard telemetry with the custom
dimensions. Examples are deployment slot that produced telemetry or telemetry-item specific property like order
number.
Max key length: 150 Max value length: 8192
Custom measurements
Collection of custom measurements. Use this collection to report named measurement associated with the
telemetry item. Typical use cases are:
the size of Dependency Telemetry payload
the number of queue items processed by Request Telemetry
time that customer took to complete the step in wizard step completion Event Telemetry.
You can query custom measurements in Application Analytics:
customEvents
| where customMeasurements != ""
| summarize avg(todouble(customMeasurements["Completion Time"]) * itemCount)
NOTE
Custom measurements are associated with the telemetry item they belong to. They are subject to sampling with the
telemetry item containing those measurements. To track a measurement that has a value independent from other telemetry
types, use Metric telemetry.
Max key length: 150
Next steps
Write custom request telemetry
Learn how to configure ASP.NET Core application with Application Insights.
Dependency telemetry: Application Insights data
model
Dependency Telemetry (in Application Insights) represents an interaction of the monitored component with a
remote component such as SQL or an HTTP endpoint.
Name
Name of the command initiated with this dependency call. Low cardinality value. Examples are stored procedure
name and URL path template.
ID
Identifier of a dependency call instance. Used for correlation with the request telemetry item corresponding to
this dependency call. For more information, see correlation page.
Data
Command initiated by this dependency call. Examples are SQL statement and HTTP URL with all query
parameters.
Type
Dependency type name. Low cardinality value for logical grouping of dependencies and interpretation of other
fields like commandName and resultCode. Examples are SQL, Azure table, and HTTP.
Target
Target site of a dependency call. Examples are server name, host address. For more information, see correlation
page.
Duration
Request duration in format: DD.HH:MM:SS.MMMMMM . Must be less than 1000 days.
Result code
Result code of a dependency call. Examples are SQL error code and HTTP status code.
Success
Indication of successful or unsuccessful call.
Custom properties
number.
Custom measurements
customEvents
NOTE
telemetry item containing those measurements. To track a measurement that has a value independent from other
telemetry types, use Metric telemetry.
Max key length: 150
Next steps
Set up dependency tracking for .NET.
Set up dependency tracking for Java.
Write custom dependency telemetry
Exception telemetry: Application Insights data model
In Application Insights, an instance of Exception represents a handled or unhandled exception that occurred during
execution of the monitored application.
Problem Id
Identifier of where the exception was thrown in code. Used for exceptions grouping. Typically a combination of
exception type and a function from the call stack.
Severity level
Trace severity level. Value can be Verbose , Information , Warning , Error , Critical .
Exception details
(To be extended)
Custom properties
number.
Custom measurements
customEvents
NOTE
Max key length: 150
Next steps
Learn how to diagnose exceptions in your web apps with Application Insights.
Trace telemetry: Application Insights data model
Trace telemetry (in Application Insights) represents printf style trace statements that are text-searched. Log4Net ,
NLog , and other text-based log file entries are translated into instances of this type. The trace does not have
measurements as an extensibility.
Message
Trace message.
Severity level
Trace severity level. Value can be Verbose , Information , Warning , Error , Critical .
Custom properties
number.
Next steps
Explore .NET trace logs in Application Insights.
Explore Java trace logs in Application Insights.
Write custom trace telemetry
Event telemetry: Application Insights data model
You can create event telemetry items (in Application Insights) to represent an event that occurred in your
application. Typically it is a user interaction such as button click or order checkout. It can also be an application life
cycle event like initialization or configuration update.
Semantically, events may or may not be correlated to requests. However, if used properly, event telemetry is more
important than requests or traces. Events represent business telemetry and should be a subject to separate, less
aggressive sampling.
Name
Event name. To allow proper grouping and useful metrics, restrict your application so that it generates a small
number of separate event names. For example, don't use a separate name for each generated instance of an event.
Custom properties
number.
Custom measurements
customEvents
NOTE
Max key length: 150
Next steps
Write custom event telemetry
Metric telemetry: Application Insights data model
There are two types of metric telemetry supported by Application Insights: single measurement and pre-
aggregated metric. Single measurement is just a name and value. Pre-aggregated metric specifies minimum and
maximum value of the metric in the aggregation interval and standard deviation of it.
Pre-aggregated metric telemetry assumes that aggregation period was one minute.
There are several well-known metric names supported by Application Insights. These metrics placed into
performanceCounters table.
Metric representing system and process counters:
.NET NAME PLATFORM AGNOSTIC NAME REST API NAME DESCRIPTION
\Processor(_Total)\% Work in progress... processorCpuPercentage total machine CPU

Processor Time
\Memory\Available Bytes Work in progress... memoryAvailableBytes Shows the amount of

physical memory, in bytes,
available to processes
running on the computer. It
is calculated by summing the
amount of space on the
zeroed, free, and standby
memory lists. Free memory
is ready for use; zeroed
memory consists of pages of
memory filled with zeros to
prevent later processes from
seeing data used by a
previous process; standby
memory is memory that has
been removed from a
process's working set (its
physical memory) en route
to disk but is still available to
be recalled. See Memory
Object
\Process(?? Work in progress... processCpuPercentage CPU of the process hosting

APP_WIN32_PROC??)\% the application
Processor Time
\Process(?? Work in progress... processPrivateBytes memory used by the

APP_WIN32_PROC??)\Private process hosting the
Bytes
application
\Process(?? Work in progress... processIOBytesPerSecond rate of I/O operations runs

APP_WIN32_PROC??)\IO by process hosting the
Data Bytes/sec
application
\ASP.NET Applications(?? Work in progress... requestsPerSecond rate of requests processed

APP_W3SVC_PROC??)\Requests/Sec by application
.NET NAME PLATFORM AGNOSTIC NAME REST API NAME DESCRIPTION
\.NET CLR Exceptions(?? Work in progress... exceptionsPerSecond rate of exceptions thrown by

APP_CLR_PROC??)\# of application
Exceps Thrown / sec
\ASP.NET Applications(?? Work in progress... requestExecutionTime average requests execution

APP_W3SVC_PROC??)\Request time
Execution Time
\ASP.NET Applications(?? Work in progress... requestsInQueue number of requests waiting

APP_W3SVC_PROC??)\Requests for the processing in a
In Application Queue
queue
Name
Name of the metric you'd like to see in Application Insights portal and UI.
Value
Single value for measurement. Sum of individual measurements for the aggregation.
Count
Metric weight of the aggregated metric. Should not be set for a measurement.
Min
Minimum value of the aggregated metric. Should not be set for a measurement.
Max
Maximum value of the aggregated metric. Should not be set for a measurement.
Standard deviation
Standard deviation of the aggregated metric. Should not be set for a measurement.
Custom properties
Metric with the custom property CustomPerfCounter set to true indicate that the metric represents the windows
performance counter. These metrics placed in performanceCounters table. Not in customMetrics. Also the name of
this metric is parsed to extract category, counter, and instance names.
number.
Next steps
Learn how to use Application Insights API for custom events and metrics.
Telemetry context: Application Insights data model
Every telemetry item may have a strongly typed context fields. Every field enables a specific monitoring scenario.
Use the custom properties collection to store custom or application-specific contextual information.
Application version
Information in the application context fields is always about the application that is sending the telemetry.
Application version is used to analyze trend changes in the application behavior and its correlation to the
deployments.
Max length: 1024
Client IP address
The IP address of the client device. IPv4 and IPv6 are supported. When telemetry is sent from a service, the
location context is about the user that initiated the operation in the service. Application Insights extract the geo-
location information from the client IP and then truncate it. So client IP by itself cannot be used as end-user
identifiable information.
Max length: 46
Device type
Originally this field was used to indicate the type of the device the end user of the application is using. Today used
primarily to distinguish JavaScript telemetry with the device type 'Browser' from server-side telemetry with the
device type 'PC'.
Max length: 64
Operation id
A unique identifier of the root operation. This identifier allows to group telemetry across multiple components.
See telemetry correlation for details. The operation id is created by either a request or a page view. All other
telemetry sets this field to the value for the containing request or page view.
Max length: 128
Parent operation ID
The unique identifier of the telemetry item's immediate parent. See telemetry correlation for details.
Max length: 128
Operation name
The name (group) of the operation. The operation name is created by either a request or a page view. All other
telemetry items set this field to the value for the containing request or page view. Operation name is used for
finding all the telemetry items for a group of operations (for example 'GET Home/Index'). This context property is
used to answer questions like "what are the typical exceptions thrown on this page."
Max length: 1024
Synthetic source of the operation

Name of synthetic source. Some telemetry from the application may represent synthetic traffic. It may be web
crawler indexing the web site, site availability tests, or traces from diagnostic libraries like Application Insights
SDK itself.
Max length: 1024
Session id
Session ID - the instance of the user's interaction with the app. Information in the session context fields is always
about the end user. When telemetry is sent from a service, the session context is about the user that initiated the
operation in the service.
Max length: 64
Anonymous user id
Anonymous user id. Represents the end user of the application. When telemetry is sent from a service, the user
context is about the user that initiated the operation in the service.
Sampling is one of the techniques to minimize the amount of collected telemetry. Sampling algorithm attempts to
either sample in or out all the correlated telemetry. Anonymous user id is used for sampling score generation. So
anonymous user id should be a random enough value.
Using anonymous user id to store user name is a misuse of the field. Use Authenticated user id.
Max length: 128
Authenticated user id
Authenticated user id. The opposite of anonymous user id, this field represents the user with a friendly name.
Since its PII information it is not collected by default by most SDK.
Max length: 1024
Account id
In multi-tenant applications this is the account ID or name, which the user is acting with. Examples may be
subscription ID for Azure portal or blog name blogging platform.
Max length: 1024
Cloud role
Name of the role the application is a part of. Maps directly to the role name in azure. Can also be used to
distinguish micro services, which are part of a single application.
Max length: 256
Cloud role instance

Name of the instance where the application is running. Computer name for on-premises, instance name for Azure.
Max length: 256
Internal: SDK version
SDK version. See https://github.com/Microsoft/ApplicationInsights-Home/blob/master/SDK-
AUTHORING.md#sdk-version-specification for information.
Max length: 64
Internal: Node name

This field represents the node name used for billing purposes. Use it to override the standard detection of nodes.
Max length: 256
Next steps
Check out standard context properties collection configuration.
Application Insights for Azure Functions supported
features
Azure Functions offers built-in integration with Application Insights, which is available through the ILogger
Interface. Below is the list of currently supported features. Review Azure Functions' guide for Getting started.
Supported features
AZURE FUNCTIONS V1 V2 (IGNITE 2018)
Application Insights .NET SDK 2.5.0 2.9.1
Automatic collection of
• Requests Yes Yes
• Exceptions Yes Yes
• Performance Counters Yes Yes
• Dependencies
— HTTP Yes
— ServiceBus Yes
— EventHub Yes
— SQL Yes
Supported features
• QuickPulse/LiveMetrics Yes Yes
— Secure Control Channel Yes
• Sampling Yes Yes
• Heartbeats Yes
Correlation
• ServiceBus Yes
• EventHub Yes
Configurable
•Fully configurable. Yes

See Azure Functions for instructions.
See Asp.NET Core for all options.
Performance Counters
Automatic collection of Performance Counters only work Windows machines.
Live Metrics & Secure Control Channel

The custom filters criteria you specify are sent back to the Live Metrics component in the Application Insights SDK.
The filters could potentially contain sensitive information such as customerIDs. You can make the channel secure
with a secret API key. See Secure the control channel for instructions.
Sampling
Azure Functions enables Sampling by default in their configuration. For more information, see Configure
Sampling.
If your project takes a dependency on the Application Insights SDK to do manual telemetry tracking, you may
experience strange behavior if your sampling configuration is different than the Functions' sampling configuration.
We recommend using the same configuration as Functions. With Functions v2, you can get the same
configuration using dependency injection in your constructor:
public class Function1

{
public Function1(TelemetryConfiguration configuration)

{
this.telemetryClient = new TelemetryClient(configuration);
}
[FunctionName("Function1")]
public async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req, ILogger
logger)
{
this.telemetryClient.TrackTrace("C# HTTP trigger function processed a request.");
}
}
Supported metrics with Azure Monitor
Azure Monitor provides several ways to interact with metrics, including charting them in the portal, accessing
them through the REST API, or querying them using PowerShell or CLI. Below is a complete list of all metrics
currently available with Azure Monitor's metric pipeline. Other metrics may be available in the portal or using
legacy APIs. This list below only includes metrics available using the consolidated Azure Monitor metric
pipeline. To query for and access these metrics please use the 2018-01-01 api-version
NOTE
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.
Microsoft.AnalysisServices/servers
METRIC DISPLAY AGGREGATION
METRIC NAME UNIT TYPE DESCRIPTION DIMENSIONS
qpu_metric QPU Count Average QPU. Range 0- ServerResourceT

100 for S1, 0- ype
200 for S2 and
0-400 for S4
memory_metric Memory Bytes Average Memory. Range ServerResourceT

0-25 GB for S1, ype
0-50 GB for S2
and 0-100 GB
for S4
TotalConnection Total Connection Count Average Total connection ServerResourceT

Requests Requests requests. These ype
are arrivals.
SuccessfullConne Successful CountPerSecond Average Rate of ServerResourceT

ctionsPerSec Connections Per successful ype
Sec connection
completions.
TotalConnection Total Connection Count Average Total failed ServerResourceT

Failures Failures connection ype
attempts.
CurrentUserSessi Current User Count Average Current number ServerResourceT

ons Sessions of user sessions ype
established.
QueryPoolBusyT Query Pool Busy Count Average Number of busy ServerResourceT

hreads Threads threads in the ype
query thread
pool.
CommandPoolJo Command Pool Count Average Number of jobs ServerResourceT

bQueueLength Job Queue in the queue of ype
Length the command
thread pool.
ProcessingPoolJo Processing Pool Count Average Number of non- ServerResourceT

bQueueLength Job Queue I/O jobs in the ype
Length queue of the
processing
thread pool.
CurrentConnecti Connection: Count Average Current number ServerResourceT

ons Current of client ype
connections connections
established.
CleanerCurrentP Memory: Cleaner Count Average Current price of ServerResourceT

rice Current Price memory, ype
$/byte/time,
normalized to
1000.
CleanerMemoryS Memory: Cleaner Bytes Average Amount of ServerResourceT

hrinkable Memory memory, in ype
shrinkable bytes, subject to
purging by the
background
cleaner.
CleanerMemory Memory: Cleaner Bytes Average Amount of ServerResourceT

Nonshrinkable Memory memory, in ype
nonshrinkable bytes, not
subject to
purging by the
background
cleaner.
MemoryUsage Memory: Bytes Average Memory usage ServerResourceT

Memory Usage of the server ype
process as used
in calculating
cleaner memory
price. Equal to
counter
Process\PrivateB
ytes plus the size
of memory-
mapped data,
ignoring any
memory which
was mapped or
allocated by the
xVelocity in-
memory
analytics engine
(VertiPaq) in
excess of the
xVelocity engine
Memory Limit.
MemoryLimitHar Memory: Bytes Average Hard memory ServerResourceT

d Memory Limit limit, from ype
Hard configuration file.
MemoryLimitHig Memory: Bytes Average High memory ServerResourceT

h Memory Limit limit, from ype
High configuration file.
MemoryLimitLo Memory: Bytes Average Low memory ServerResourceT

w Memory Limit limit, from ype
Low configuration file.
MemoryLimitVer Memory: Bytes Average In-memory limit, ServerResourceT

tiPaq Memory Limit from ype
VertiPaq configuration file.
Quota Memory: Quota Bytes Average Current memory ServerResourceT

quota, in bytes. ype
Memory quota is
also known as a
memory grant
or memory
reservation.
QuotaBlocked Memory: Quota Count Average Current number ServerResourceT

Blocked of quota ype
requests that are
blocked until
other memory
quotas are freed.
VertiPaqNonpag Memory: Bytes Average Bytes of memory ServerResourceT

ed VertiPaq locked in the ype
Nonpaged working set for
use by the in-
memory engine.
VertiPaqPaged Memory: Bytes Average Bytes of paged ServerResourceT

VertiPaq Paged memory in use ype
for in-memory
data.
RowsReadPerSec Processing: Rows CountPerSecond Average Rate of rows ServerResourceT

read per sec read from all ype
relational
databases.
RowsConvertedP Processing: Rows CountPerSecond Average Rate of rows ServerResourceT

erSec converted per converted ype
sec during
processing.
RowsWrittenPerS Processing: Rows CountPerSecond Average Rate of rows ServerResourceT

ec written per sec written during ype
processing.
CommandPoolB Threads: Count Average Number of busy ServerResourceT

usyThreads Command pool threads in the ype
busy threads command thread
pool.
CommandPoolId Threads: Count Average Number of idle ServerResourceT

leThreads Command pool threads in the ype
idle threads command thread
pool.
LongParsingBusy Threads: Long Count Average Number of busy ServerResourceT

Threads parsing busy threads in the ype
threads long parsing
thread pool.
LongParsingIdleT Threads: Long Count Average Number of idle ServerResourceT

hreads parsing idle threads in the ype
threads long parsing
thread pool.
LongParsingJob Threads: Long Count Average Number of jobs ServerResourceT

QueueLength parsing job in the queue of ype
queue length the long parsing
thread pool.
ProcessingPoolB Threads: Count Average Number of ServerResourceT

usyIOJobThreads Processing pool threads running ype
busy I/O job I/O jobs in the
threads processing
thread pool.
ProcessingPoolB Threads: Count Average Number of ServerResourceT

usyNonIOThread Processing pool threads running ype
s busy non-I/O non-I/O jobs in
threads the processing
thread pool.
ProcessingPoolI Threads: Count Average Number of I/O ServerResourceT

OJobQueueLeng Processing pool jobs in the ype
th I/O job queue queue of the
length processing
thread pool.
ProcessingPoolId Threads: Count Average Number of idle ServerResourceT

leIOJobThreads Processing pool threads for I/O ype
idle I/O job jobs in the
threads processing
thread pool.
ProcessingPoolId Threads: Count Average Number of idle ServerResourceT

leNonIOThreads Processing pool threads in the ype
idle non-I/O processing
threads thread pool
dedicated to
non-I/O jobs.
QueryPoolIdleTh Threads: Query Count Average Number of idle ServerResourceT

reads pool idle threads threads for I/O ype
jobs in the
processing
thread pool.
QueryPoolJobQu Threads: Query Count Average Number of jobs ServerResourceT

eueLength pool job queue in the queue of ype
length the query thread
pool.
ShortParsingBus Threads: Short Count Average Number of busy ServerResourceT

yThreads parsing busy threads in the ype
threads short parsing
thread pool.
ShortParsingIdle Threads: Short Count Average Number of idle ServerResourceT

Threads parsing idle threads in the ype
threads short parsing
thread pool.
ShortParsingJob Threads: Short Count Average Number of jobs ServerResourceT

QueueLength parsing job in the queue of ype
queue length the short
parsing thread
pool.
memory_thrashi Memory Percent Average Average ServerResourceT

ng_metric Thrashing memory ype
thrashing.
mashup_engine_ M Engine QPU Count Average QPU usage by ServerResourceT

qpu_metric mashup engine ype
processes
mashup_engine_ M Engine Bytes Average Memory usage ServerResourceT

memory_metric Memory by mashup ype
engine processes
Microsoft.ApiManagement/service
Requests Requests Count Total The total Location,

number of BackendRespons
gateway eCode,
requests in a LastErrorReason,
given period. It GatewayRespons
can be sliced by eCode
various
dimensions to
help you
diagnose issues.
TotalRequests Total Gateway Count Total The total Location,

Requests number of Hostname
gateway
requests in a
given period.
This metric has
been deprecated,
we recommend
using the new
Requests
metric.
SuccessfulReques Successful Count Total The total Location,

ts Gateway number of Hostname
Requests successful
gateway
requests in a
given period.
This metric has
been deprecated,
we recommend
using the new
Requests
metric.
UnauthorizedRe Unauthorized Count Total The total Location,

quests Gateway number of Hostname
Requests unauthorized
gateway
requests in a
given period.
This metric has
been deprecated,
we recommend
using the new
Requests
metric.
FailedRequests Failed Gateway Count Total The total Location,

Requests number of failed Hostname
gateway
requests in a
given period.
This metric has
been deprecated,
we recommend
using the new
Requests
metric.
OtherRequests Other Gateway Count Total The total Location,

Requests number of Hostname
gateway
requests in a
given period that
do not fall into
the successful,
unauthorized, or
failed categories.
This metric has
been deprecated,
we recommend
using the new
Requests
metric.
Duration Overall Duration Milliseconds Average The time Location,

of Gateway between when Hostname
Requests API
Management
receives a
request from a
client and when
it returns a
response to the
client.
Capacity Capacity Percent Average Indicator of load Location

on an API
Management
instance for
making informed
decisions
whether to scale
the instance to
accommodate
more load.
EventHubTotalEv Total EventHub Count Total The total Location

ents Events number of
events sent to
EventHub from
API
Management in
a given period.
EventHubSucces Successful Count Total The total Location

sfulEvents EventHub Events number of
successful
EventHub events
in a given period.
EventHubTotalFa Failed EventHub Count Total The total Location

iledEvents Events number of failed
EventHub events
in a given period.
EventHubRejecte Rejected Count Total The total Location

dEvents EventHub Events number of
rejected
EventHub events
(wrong
configuration or
unauthorized) in
a given period.
EventHubThrottl Throttled Count Total The total Location

edEvents EventHub Events number of
throttled
EventHub events
in a given period.
EventHubTimedo Timed Out Count Total The total Location

utEvents EventHub Events number of timed
out EventHub
events in a given
period.
EventHubDropp Dropped Count Total The total Location

edEvents EventHub Events number of
events skipped
because of
queue size limit
reached in a
given period.
EventHubTotalBy Size of EventHub Bytes Total The total size of Location

tesSent Events EventHub events
in bytes in a
given period.
Microsoft.Automation/automationAccounts
TotalJob Total Jobs Count Total The total Runbook, Status

number of jobs
TotalUpdateDepl Total Update Count Total Total software SoftwareUpdate

oymentRuns Deployment update ConfigurationNa
Runs deployment runs me, Status
TotalUpdateDepl Total Update Count Total Total software SoftwareUpdate

oymentMachine Deployment update ConfigurationNa
Runs Machine Runs deployment me, Status,
machine runs in TargetComputer,
a software SoftwareUpdate
update ConfigurationRu
deployment run nId
Microsoft.Batch/batchAccounts
CoreCount Dedicated Core Count Total Total number of No Dimensions

Count dedicated cores
in the batch
account
TotalNodeCount Dedicated Node Count Total Total number of No Dimensions

Count dedicated nodes
in the batch
account
LowPriorityCore LowPriority Core Count Total Total number of No Dimensions

Count Count low-priority
cores in the
batch account
TotalLowPriority Low-Priority Count Total Total number of No Dimensions

NodeCount Node Count low-priority
nodes in the
batch account
CreatingNodeCo Creating Node Count Total Number of No Dimensions

unt Count nodes being
created
StartingNodeCo Starting Node Count Total Number of No Dimensions

unt Count nodes starting
WaitingForStartT Waiting For Start Count Total Number of No Dimensions

askNodeCount Task Node Count nodes waiting
for the Start Task
to complete
StartTaskFailedN Start Task Failed Count Total Number of No Dimensions

odeCount Node Count nodes where the
Start Task has
failed
IdleNodeCount Idle Node Count Count Total Number of idle No Dimensions

nodes
OfflineNodeCou Offline Node Count Total Number of No Dimensions

nt Count offline nodes
RebootingNodeC Rebooting Node Count Total Number of No Dimensions

ount Count rebooting nodes
ReimagingNode Reimaging Node Count Total Number of No Dimensions

Count Count reimaging nodes
RunningNodeCo Running Node Count Total Number of No Dimensions

unt Count running nodes
LeavingPoolNod Leaving Pool Count Total Number of No Dimensions

eCount Node Count nodes leaving
the Pool
UnusableNodeC Unusable Node Count Total Number of No Dimensions

ount Count unusable nodes
PreemptedNode Preempted Node Count Total Number of No Dimensions

Count Count preempted
nodes
TaskStartEvent Task Start Events Count Total Total number of No Dimensions

tasks that have
started
TaskCompleteEv Task Complete Count Total Total number of No Dimensions

ent Events tasks that have
completed
TaskFailEvent Task Fail Events Count Total Total number of No Dimensions

tasks that have
completed in a
failed state
PoolCreateEvent Pool Create Count Total Total number of No Dimensions

Events pools that have
been created
PoolResizeStartE Pool Resize Start Count Total Total number of No Dimensions

vent Events pool resizes that
have started
PoolResizeCompl Pool Resize Count Total Total number of No Dimensions

eteEvent Complete Events pool resizes that
have completed
PoolDeleteStartE Pool Delete Start Count Total Total number of No Dimensions

vent Events pool deletes that
have started
PoolDeleteComp Pool Delete Count Total Total number of No Dimensions

leteEvent Complete Events pool deletes that
have completed
JobDeleteCompl Job Delete Count Total Total number of No Dimensions

eteEvent Complete Events jobs that have
been successfully
deleted.
JobDeleteStartEv Job Delete Start Count Total Total number of No Dimensions

ent Events jobs that have
been requested
to be deleted.
JobDisableCompl Job Disable Count Total Total number of No Dimensions

eteEvent Complete Events jobs that have
been successfully
disabled.
JobDisableStartE Job Disable Start Count Total Total number of No Dimensions

vent Events jobs that have
been requested
to be disabled.
JobStartEvent Job Start Events Count Total Total number of No Dimensions

jobs that have
been successfully
started.
JobTerminateCo Job Terminate Count Total Total number of No Dimensions

mpleteEvent Complete Events jobs that have
been successfully
terminated.
JobTerminateStar Job Terminate Count Total Total number of No Dimensions

tEvent Start Events jobs that have
been requested
to be
terminated.
Microsoft.Cache/redis
connectedclients Connected Count Maximum ShardId

Clients
totalcommandsp Total Operations Count Total ShardId

rocessed
cachehits Cache Hits Count Total ShardId
cachemisses Cache Misses Count Total ShardId
getcommands Gets Count Total ShardId
setcommands Sets Count Total ShardId
operationsPerSec Operations Per Count Maximum ShardId

ond Second
evictedkeys Evicted Keys Count Total ShardId
totalkeys Total Keys Count Maximum ShardId
expiredkeys Expired Keys Count Total ShardId
usedmemory Used Memory Bytes Maximum ShardId
usedmemoryper Used Memory Percent Maximum ShardId

centage Percentage
usedmemoryRss Used Memory Bytes Maximum ShardId

RSS
serverLoad Server Load Percent Maximum ShardId
cacheWrite Cache Write BytesPerSecond Maximum ShardId

cacheRead Cache Read BytesPerSecond Maximum ShardId
percentProcessor CPU Percent Maximum ShardId

Time
cacheLatency Cache Latency Count Average ShardId,

Microseconds SampleType
(Preview)
errors Errors Count Maximum ShardId,

ErrorType
connectedclients Connected Count Maximum No Dimensions

0 Clients (Shard 0)
totalcommandsp Total Operations Count Total No Dimensions

rocessed0 (Shard 0)
cachehits0 Cache Hits Count Total No Dimensions

(Shard 0)
cachemisses0 Cache Misses Count Total No Dimensions

(Shard 0)
getcommands0 Gets (Shard 0) Count Total No Dimensions
setcommands0 Sets (Shard 0) Count Total No Dimensions
operationsPerSec Operations Per Count Maximum No Dimensions

ond0 Second (Shard 0)
evictedkeys0 Evicted Keys Count Total No Dimensions

(Shard 0)
totalkeys0 Total Keys (Shard Count Maximum No Dimensions

0)
expiredkeys0 Expired Keys Count Total No Dimensions

(Shard 0)
usedmemory0 Used Memory Bytes Maximum No Dimensions

(Shard 0)
usedmemoryRss Used Memory Bytes Maximum No Dimensions

0 RSS (Shard 0)
serverLoad0 Server Load Percent Maximum No Dimensions

(Shard 0)
cacheWrite0 Cache Write BytesPerSecond Maximum No Dimensions

(Shard 0)
cacheRead0 Cache Read BytesPerSecond Maximum No Dimensions

(Shard 0)
percentProcessor CPU (Shard 0) Percent Maximum No Dimensions

Time0

1 Clients (Shard 1)

rocessed1 (Shard 1)

(Shard 1)

(Shard 1)


(Shard 1)

1)

(Shard 1)

(Shard 1)

1 RSS (Shard 1)

(Shard 1)

(Shard 1)

(Shard 1)

Time1

2 Clients (Shard 2)

rocessed2 (Shard 2)

(Shard 2)

(Shard 2)


(Shard 2)

2)

(Shard 2)

(Shard 2)

2 RSS (Shard 2)

(Shard 2)

(Shard 2)

(Shard 2)

Time2

3 Clients (Shard 3)

rocessed3 (Shard 3)

(Shard 3)

(Shard 3)


(Shard 3)

3)

(Shard 3)

(Shard 3)

3 RSS (Shard 3)

(Shard 3)

(Shard 3)

(Shard 3)

Time3

4 Clients (Shard 4)

rocessed4 (Shard 4)

(Shard 4)

(Shard 4)


(Shard 4)

4)

(Shard 4)

(Shard 4)

4 RSS (Shard 4)

(Shard 4)

(Shard 4)

(Shard 4)

Time4

5 Clients (Shard 5)

rocessed5 (Shard 5)

(Shard 5)

(Shard 5)


(Shard 5)

5)

(Shard 5)

(Shard 5)

5 RSS (Shard 5)

(Shard 5)

(Shard 5)

(Shard 5)

Time5

6 Clients (Shard 6)

rocessed6 (Shard 6)

(Shard 6)

(Shard 6)


(Shard 6)

6)

(Shard 6)

(Shard 6)

6 RSS (Shard 6)

(Shard 6)

(Shard 6)

(Shard 6)

Time6

7 Clients (Shard 7)

rocessed7 (Shard 7)

(Shard 7)

(Shard 7)


(Shard 7)

7)

(Shard 7)

(Shard 7)

7 RSS (Shard 7)

(Shard 7)

(Shard 7)

(Shard 7)

Time7

8 Clients (Shard 8)

rocessed8 (Shard 8)

(Shard 8)

(Shard 8)


(Shard 8)

8)

(Shard 8)

(Shard 8)

8 RSS (Shard 8)

(Shard 8)

(Shard 8)

(Shard 8)

Time8

9 Clients (Shard 9)

rocessed9 (Shard 9)

(Shard 9)

(Shard 9)


(Shard 9)

9)

(Shard 9)

(Shard 9)

9 RSS (Shard 9)

(Shard 9)

(Shard 9)

(Shard 9)

Time9
Microsoft.ClassicCompute/virtualMachines
Percentage CPU Percentage CPU Percent Average The percentage No Dimensions

of allocated
compute units
that are
currently in use
by the Virtual
Machine(s).
Network In Network In Bytes Total The number of No Dimensions

bytes received
on all network
interfaces by the
Virtual
Machine(s)
(Incoming
Traffic).
Network Out Network Out Bytes Total The number of No Dimensions

bytes out on all
network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic).
Disk Read Disk Read BytesPerSecond Average Average bytes No Dimensions

Bytes/Sec read from disk
during
monitoring
period.
Disk Write Disk Write BytesPerSecond Average Average bytes No Dimensions

Bytes/Sec written to disk
during
monitoring
period.
Disk Read Disk Read CountPerSecond Average Disk Read IOPS. No Dimensions
Operations/Sec Operations/Sec
Disk Write Disk Write CountPerSecond Average Disk Write IOPS. No Dimensions
Microsoft.ClassicCompute/domainNames/slots/roles
Percentage CPU Percentage CPU Percent Average The percentage RoleInstanceId

of allocated
compute units
that are
currently in use
by the Virtual
Machine(s).
Network In Network In Bytes Total The number of RoleInstanceId

bytes received
on all network
interfaces by the
Virtual
Machine(s)
(Incoming
Traffic).
Network Out Network Out Bytes Total The number of RoleInstanceId

bytes out on all
network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic).
Disk Read Disk Read BytesPerSecond Average Average bytes RoleInstanceId

Bytes/Sec read from disk
during
monitoring
period.
Disk Write Disk Write BytesPerSecond Average Average bytes RoleInstanceId

Bytes/Sec written to disk
during
monitoring
period.
Disk Read Disk Read CountPerSecond Average Disk Read IOPS. RoleInstanceId
Disk Write Disk Write CountPerSecond Average Disk Write IOPS. RoleInstanceId
Microsoft.CognitiveServices/accounts
TotalCalls Total Calls Count Total Total number of ApiName,

calls. OperationName,
Region
SuccessfulCalls Successful Calls Count Total Number of ApiName,

successful calls. OperationName,
Region
TotalErrors Total Errors Count Total Total number of ApiName,

calls with error OperationName,
response (HTTP Region
response code
4xx or 5xx).
BlockedCalls Blocked Calls Count Total Number of calls ApiName,

that exceeded OperationName,
rate or quota Region
limit.
ServerErrors Server Errors Count Total Number of calls ApiName,

with service OperationName,
internal error Region
(HTTP response
code 5xx).
ClientErrors Client Errors Count Total Number of calls ApiName,

with client side OperationName,
error (HTTP Region
response code
4xx).
DataIn Data In Bytes Total Size of incoming ApiName,

data in bytes. OperationName,
Region
DataOut Data Out Bytes Total Size of outgoing ApiName,

data in bytes. OperationName,
Region
Latency Latency MilliSeconds Average Latency in ApiName,

milliseconds. OperationName,
Region
CharactersTransl Characters Count Total Total number of ApiName,

ated Translated characters in OperationName,
incoming text Region
request.
CharactersTraine Characters Count Total Total number of ApiName,

d Trained characters OperationName,
trained. Region
SpeechSessionD Speech Session Seconds Total Total duration of ApiName,

uration Duration speech session in OperationName,
seconds. Region
TotalTransactions Total Count Total Total number of No Dimensions

Transactions transactions.
TotalTokenCalls Total Token Calls Count Total Total number of ApiName,

token calls. OperationName,
Region
Microsoft.Compute/virtualMachines
Percentage CPU Percentage CPU Percent Average The percentage No Dimensions

of allocated
compute units
that are
currently in use
by the Virtual
Machine(s)
Network In Network In Bytes Total The number of No Dimensions

Billable billable bytes
received on all
network
interfaces by the
Virtual
Machine(s)
(Incoming Traffic)

Billable billable bytes out
on all network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic)
Disk Read Bytes Disk Read Bytes Bytes Total Bytes read from No Dimensions
disk during
monitoring
period
Disk Write Bytes Disk Write Bytes Bytes Total Bytes written to No Dimensions
disk during
monitoring
period
Disk Read Disk Read CountPerSecond Average Disk Read IOPS No Dimensions
Disk Write Disk Write CountPerSecond Average Disk Write IOPS No Dimensions
CPU Credits CPU Credits Count Average Total number of No Dimensions

Remaining Remaining credits available
to burst

Consumed Consumed credits
consumed by
the Virtual
Machine
Per Disk Read Data Disk Read CountPerSecond Average Bytes/Sec read SlotId
Bytes/sec Bytes/Sec from a single
(Deprecated) disk during
monitoring
period
Per Disk Write Data Disk Write CountPerSecond Average Bytes/Sec written SlotId
Bytes/sec Bytes/Sec to a single disk
(Deprecated) during
monitoring
period
Per Disk Read Data Disk Read CountPerSecond Average Read IOPS from SlotId
Operations/Sec Operations/Sec a single disk
(Deprecated) during
monitoring
period
Per Disk Write Data Disk Write CountPerSecond Average Write IOPS from SlotId
(Deprecated) during
monitoring
period
Per Disk QD Data Disk QD Count Average Data Disk Queue SlotId
(Deprecated) Depth(or Queue
Length)
OS Per Disk OS Disk Read CountPerSecond Average Bytes/Sec read No Dimensions

Read Bytes/sec Bytes/Sec from a single
monitoring
period for OS
disk
OS Per Disk OS Disk Write CountPerSecond Average Bytes/Sec written No Dimensions

Write Bytes/sec Bytes/Sec to a single disk
(Deprecated) during
monitoring
period for OS
disk
OS Per Disk OS Disk Read CountPerSecond Average Read IOPS from No Dimensions
Read Operations/Sec a single disk
Operations/Sec (Deprecated) during
monitoring
period for OS
disk
OS Per Disk OS Disk Write CountPerSecond Average Write IOPS from No Dimensions
Write Operations/Sec a single disk
monitoring
period for OS
disk
OS Per Disk QD OS Disk QD Count Average OS Disk Queue No Dimensions

Length)
Data Disk Read Data Disk Read CountPerSecond Average Bytes/Sec read LUN
(Preview) disk during
monitoring
period
Data Disk Write Data Disk Write CountPerSecond Average Bytes/Sec written LUN
(Preview) during
monitoring
period
Data Disk Read Data Disk Read CountPerSecond Average Read IOPS from LUN
(Preview) during
monitoring
period
Data Disk Write Data Disk Write CountPerSecond Average Write IOPS from LUN
(Preview) during
monitoring
period
Data Disk Queue Data Disk Queue Count Average Data Disk Queue LUN
Depth Depth (Preview) Depth(or Queue
Length)
OS Disk Read OS Disk Read CountPerSecond Average Bytes/Sec read No Dimensions

monitoring
period for OS
disk
OS Disk Write OS Disk Write CountPerSecond Average Bytes/Sec written No Dimensions

(Preview) during
monitoring
period for OS
disk
OS Disk Read OS Disk Read CountPerSecond Average Read IOPS from No Dimensions
(Preview) during
monitoring
period for OS
disk
OS Disk Write OS Disk Write CountPerSecond Average Write IOPS from No Dimensions
(Preview) during
monitoring
period for OS
disk
OS Disk Queue OS Disk Queue Count Average OS Disk Queue No Dimensions

Length)
Inbound Flows Inbound Flows Count Average Inbound Flows No Dimensions

(Preview) are number of
current flows in
the inbound
direction (traffic
going into the
VM)
Outbound Flows Outbound Flows Count Average Outbound Flows No Dimensions

current flows in
the outbound
direction (traffic
going out of the
VM)
Inbound Flows Inbound Flows CountPerSecond Average The maximum No Dimensions

Maximum Maximum creation rate of
Creation Rate Creation Rate inbound flows
(Preview) (traffic going into
the VM)
Outbound Flows Outbound Flows CountPerSecond Average The maximum No Dimensions

Creation Rate Creation Rate outbound flows
(Preview) (traffic going out
of the VM)
Premium Data Premium Data Percent Average Premium Data LUN

Disk Cache Read Disk Cache Read Disk Cache Read
Hit Hit (Preview) Hit
Premium Data Premium Data Percent Average Premium Data LUN

Miss Miss (Preview) Miss
Premium OS Premium OS Percent Average Premium OS No Dimensions

Premium OS Premium OS Percent Average Premium OS No Dimensions

Network In Total Network In Total Bytes Total The number of No Dimensions

bytes received
on all network
interfaces by the
Virtual
Machine(s)
(Incoming Traffic)

Total Total bytes out on all
network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic)
Microsoft.Compute/virtualMachineScaleSets
Percentage CPU Percentage CPU Percent Average The percentage VMName

of allocated
compute units
that are
currently in use
by the Virtual
Machine(s)
Network In Network In Bytes Total The number of VMName

Billable billable bytes
received on all
network
interfaces by the
Virtual
Machine(s)
(Incoming Traffic)
Network Out Network Out Bytes Total The number of VMName

Billable billable bytes out
on all network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic)
Disk Read Bytes Disk Read Bytes Bytes Total Bytes read from VMName
disk during
monitoring
period
Disk Write Bytes Disk Write Bytes Bytes Total Bytes written to VMName
disk during
monitoring
period
Disk Read Disk Read CountPerSecond Average Disk Read IOPS VMName
Disk Write Disk Write CountPerSecond Average Disk Write IOPS VMName

Remaining Remaining credits available
to burst

Consumed Consumed credits
consumed by
the Virtual
Machine
Per Disk Read Data Disk Read CountPerSecond Average Bytes/Sec read SlotId
monitoring
period
Per Disk Write Data Disk Write CountPerSecond Average Bytes/Sec written SlotId
(Deprecated) during
monitoring
period
Per Disk Read Data Disk Read CountPerSecond Average Read IOPS from SlotId
(Deprecated) during
monitoring
period
Per Disk Write Data Disk Write CountPerSecond Average Write IOPS from SlotId
(Deprecated) during
monitoring
period
Per Disk QD Data Disk QD Count Average Data Disk Queue SlotId
Length)
OS Per Disk OS Disk Read CountPerSecond Average Bytes/Sec read No Dimensions

Read Bytes/sec Bytes/Sec from a single
monitoring
period for OS
disk
OS Per Disk OS Disk Write CountPerSecond Average Bytes/Sec written No Dimensions

Write Bytes/sec Bytes/Sec to a single disk
(Deprecated) during
monitoring
period for OS
disk
OS Per Disk OS Disk Read CountPerSecond Average Read IOPS from No Dimensions
Read Operations/Sec a single disk
monitoring
period for OS
disk
OS Per Disk OS Disk Write CountPerSecond Average Write IOPS from No Dimensions
Write Operations/Sec a single disk
monitoring
period for OS
disk
OS Per Disk QD OS Disk QD Count Average OS Disk Queue No Dimensions

Length)
Data Disk Read Data Disk Read CountPerSecond Average Bytes/Sec read LUN, VMName
monitoring
period
Data Disk Write Data Disk Write CountPerSecond Average Bytes/Sec written LUN, VMName
(Preview) during
monitoring
period
Data Disk Read Data Disk Read CountPerSecond Average Read IOPS from LUN, VMName
(Preview) during
monitoring
period
Data Disk Write Data Disk Write CountPerSecond Average Write IOPS from LUN, VMName
(Preview) during
monitoring
period
Data Disk Queue Data Disk Queue Count Average Data Disk Queue LUN, VMName
Length)
OS Disk Read OS Disk Read CountPerSecond Average Bytes/Sec read VMName

monitoring
period for OS
disk
OS Disk Write OS Disk Write CountPerSecond Average Bytes/Sec written VMName

(Preview) during
monitoring
period for OS
disk
OS Disk Read OS Disk Read CountPerSecond Average Read IOPS from VMName
(Preview) during
monitoring
period for OS
disk
OS Disk Write OS Disk Write CountPerSecond Average Write IOPS from VMName
(Preview) during
monitoring
period for OS
disk
OS Disk Queue OS Disk Queue Count Average OS Disk Queue VMName

Length)
Inbound Flows Inbound Flows Count Average Inbound Flows VMName

current flows in
the inbound
direction (traffic
going into the
VM)
Outbound Flows Outbound Flows Count Average Outbound Flows VMName

current flows in
the outbound
direction (traffic
going out of the
VM)
Inbound Flows Inbound Flows CountPerSecond Average The maximum VMName

Creation Rate Creation Rate inbound flows
(Preview) (traffic going into
the VM)
Outbound Flows Outbound Flows CountPerSecond Average The maximum VMName

Creation Rate Creation Rate outbound flows
(Preview) (traffic going out
of the VM)
Premium Data Premium Data Percent Average Premium Data LUN, VMName
Premium Data Premium Data Percent Average Premium Data LUN, VMName
Premium OS Premium OS Percent Average Premium OS VMName

Premium OS Premium OS Percent Average Premium OS VMName

Network In Total Network In Total Bytes Total The number of VMName

bytes received
on all network
interfaces by the
Virtual
Machine(s)
(Incoming Traffic)
Network Out Network Out Bytes Total The number of VMName

Total Total bytes out on all
network
interfaces by the
Virtual
Machine(s)
(Outgoing
Traffic)
Microsoft.ContainerInstance/containerGroups
CpuUsage CPU Usage Count Average CPU usage on all containerName

cores in
millicores.
MemoryUsage Memory Usage Bytes Average Total memory containerName

usage in byte.
NetworkBytesRe Network Bytes Bytes Average The network No Dimensions

ceivedPerSecond Received Per bytes received
Second per second.
NetworkBytesTra Network Bytes Bytes Average The network No Dimensions

nsmittedPerSeco Transmitted Per bytes
nd Second transmitted per
second.
Microsoft.ContainerRegistry/registries
TotalPullCount Total Pull Count Count Average Number of No Dimensions

image pulls in
total
SuccessfulPullCo Successful Pull Count Average Number of No Dimensions

unt Count successful image
pulls
TotalPushCount Total Push Count Count Average Number of No Dimensions

image pushes in
total
SuccessfulPushC Successful Push Count Average Number of No Dimensions

ount Count successful image
pushes
RunDuration Run Duration Milliseconds Total Run Duration in No Dimensions

milliseconds
Microsoft.ContainerService/managedClusters
kube_node_statu Total number of Count Total Total number of No Dimensions

s_allocatable_cpu available cpu available cpu
_cores cores in a cores in a
managed cluster managed cluster
kube_node_statu Total amount of Bytes Total Total amount of No Dimensions

s_allocatable_me available available
mory_bytes memory in a memory in a
managed cluster managed cluster
kube_pod_status Number of pods Count Total Number of pods namespace, pod

_ready in Ready state in Ready state
kube_node_statu Statuses for Count Total Statuses for condition, status,

s_condition various node various node status2, node
conditions conditions
kube_pod_status Number of pods Count Total Number of pods phase,

_phase by phase by phase namespace, pod
Microsoft.CustomerInsights/hubs
DCIApiCalls Customer Count Total No Dimensions

Insights API Calls
DCIMappingImp Mapping Import Count Total No Dimensions

ortOperationSuc Operation
cessfulLines Successful Lines

ortOperationFail Operation Failed
edLines Lines

ortOperationTot Operation Total
alLines Lines
DCIMappingImp Mapping Import Seconds Total No Dimensions

ortOperationRun Operation
timeInSeconds Runtime In
Seconds
DCIOutboundPr Outbound Count Total No Dimensions

ofileExportSuccee Profile Export
ded Succeeded
DCIOutboundPr Outbound Count Total No Dimensions

ofileExportFailed Profile Export
Failed
DCIOutboundPr Outbound Seconds Total No Dimensions

ofileExportDurati Profile Export
on Duration
DCIOutboundKp Outbound Kpi Count Total No Dimensions

iExportSucceede Export
d Succeeded
DCIOutboundKp Outbound Kpi Count Total No Dimensions

iExportFailed Export Failed
DCIOutboundKp Outbound Kpi Seconds Total No Dimensions

iExportDuration Export Duration

iExportStarted Export Started

iRecordCount Record Count
DCIOutboundPr Outbound Seconds Total No Dimensions

ofileExportCount Profile Export
Count
DCIOutboundIni Outbound Initial Seconds Total No Dimensions

tialProfileExportF Profile Export
ailed Failed

tialProfileExportS Profile Export
ucceeded Succeeded

tialKpiExportFaile Kpi Export Failed
d

tialKpiExportSucc Kpi Export
eeded Succeeded

tialProfileExportD Profile Export
urationInSecond Duration In
s Seconds
AdlaJobForStand Adla Job For Seconds Total No Dimensions

ardKpiFailed Standard Kpi
Failed In Seconds

ardKpiTimeOut Standard Kpi
TimeOut In
Seconds

ardKpiComplete Standard Kpi
d Completed In
Seconds
ImportASAValue Import ASA Count Total No Dimensions

sFailed Values Failed
Count
ImportASAValue Import ASA Count Total No Dimensions

sSucceeded Values
Succeeded
Count
DCIProfilesCount Profile Instance Count Last No Dimensions

Count
DCIInteractionsP Interactions per Count Last No Dimensions

erMonthCount Month Count
DCIKpisCount KPI Count Count Last No Dimensions
DCISegmentsCo Segment Count Count Last No Dimensions

unt
DCIPredictiveMa Predictive Match Count Last No Dimensions

tchPoliciesCount Count
DCIPredictionsC Prediction Count Count Last No Dimensions

ount
Microsoft.DataBoxEdge/dataBoxEdgeDevices
NICReadThrough Read BytesPerSecond Average The read InstanceName

put Throughput throughput of
(Network) the network
interface on the
device in the
reporting period
for all volumes in
the gateway.
NICWriteThroug Write BytesPerSecond Average The write InstanceName

hput Throughput throughput of
(Network) the network
interface on the
device in the
reporting period
for all volumes in
the gateway.
CloudReadThrou Cloud Download BytesPerSecond Average The download Share

ghputPerShare Throughput throughput to
(Share) Azure from a
share during the
reporting period.
CloudUploadThr Cloud Upload BytesPerSecond Average The upload Share

oughputPerShar Throughput throughput to
e (Share) Azure from a
share during the
reporting period.
BytesUploadedT Cloud Bytes Bytes Average The total Share

oCloudPerShare Uploaded (Share) number of bytes
that is uploaded
to Azure from a
share during the
reporting period.
TotalCapacity Total Capacity Bytes Average Total Capacity No Dimensions
AvailableCapacit Available Bytes Average The available No Dimensions

y Capacity capacity in bytes
during the
reporting period.
CloudUploadThr Cloud Upload BytesPerSecond Average The cloud upload No Dimensions

oughput Throughput throughput to
Azure during the
reporting period.
CloudReadThrou Cloud Download BytesPerSecond Average The cloud No Dimensions

ghput Throughput download
throughput to
Azure during the
reporting period.
BytesUploadedT Cloud Bytes Bytes Average The total No Dimensions

oCloud Uploaded number of bytes
(Device) that is uploaded
to Azure from a
device during
the reporting
period.
HyperVVirtualPr Edge Compute - Percent Average Percent CPU InstanceName

ocessorUtilizatio Percentage CPU Usage
n
HyperVMemory Edge Compute - Percent Average Amount of RAM InstanceName

Utilization Memory Usage in Use
Microsoft.DataFactory/datafactories
FailedRuns Failed Runs Count Total pipelineName,

activityName
SuccessfulRuns Successful Runs Count Total pipelineName,

activityName
Microsoft.DataFactory/factories
PipelineFailedRu Failed pipeline Count Total FailureType,

ns runs metrics Name
PipelineSucceede Succeeded Count Total FailureType,

dRuns pipeline runs Name
metrics
ActivityFailedRun Failed activity Count Total ActivityType,

s runs metrics PipelineName,
FailureType,
Name
ActivitySucceede Succeeded Count Total ActivityType,

dRuns activity runs PipelineName,
metrics FailureType,
Name
TriggerFailedRun Failed trigger Count Total Name,

s runs metrics FailureType
TriggerSucceede Succeeded Count Total Name,

dRuns trigger runs FailureType
metrics
IntegrationRunti Integration Percent Average IntegrationRunti

meCpuPercentag runtime CPU meName,
e utilization NodeName
IntegrationRunti Integration Bytes Average IntegrationRunti

meAvailableMem runtime available meName,
ory memory NodeName
MaxAllowedReso Maximum Count Maximum No Dimensions

urceCount allowed entities
count
MaxAllowedFact Maximum Count Maximum No Dimensions

orySizeInGbUnits allowed factory
size (GB unit)
ResourceCount Total entities Count Maximum No Dimensions

count
FactorySizeInGb Total factory size Count Maximum No Dimensions

Units (GB unit)
Microsoft.DataLakeAnalytics/accounts
JobEndedSuccess Successful Jobs Count Total Count of No Dimensions

successful jobs.
JobEndedFailure Failed Jobs Count Total Count of failed No Dimensions

jobs.
JobEndedCancell Canceled Jobs Count Total Count of No Dimensions

ed canceled jobs.
JobAUEndedSucc Successful AU Seconds Total Total AU time for No Dimensions

ess Time successful jobs.
JobAUEndedFail Failed AU Time Seconds Total Total AU time for No Dimensions

ure failed jobs.
JobAUEndedCan Canceled AU Seconds Total Total AU time for No Dimensions

celled Time canceled jobs.
Microsoft.DataLakeStore/accounts
TotalStorage Total Storage Bytes Maximum Total amount of No Dimensions

data stored in
the account.
DataWritten Data Written Bytes Total Total amount of No Dimensions

data written to
the account.
DataRead Data Read Bytes Total Total amount of No Dimensions

data read from
the account.
WriteRequests Write Requests Count Total Count of data No Dimensions

write requests to
the account.
ReadRequests Read Requests Count Total Count of data No Dimensions

read requests to
the account.
Microsoft.DBforMariaDB/servers
cpu_percent CPU percent Percent Average CPU percent No Dimensions
memory_percent Memory percent Percent Average Memory percent No Dimensions
io_consumption_ IO percent Percent Average IO percent No Dimensions

percent
storage_percent Storage percent Percent Average Storage percent No Dimensions
storage_used Storage used Bytes Average Storage used No Dimensions
storage_limit Storage limit Bytes Average Storage limit No Dimensions
serverlog_storag Server Log Percent Average Server Log No Dimensions

e_percent storage percent storage percent
serverlog_storag Server Log Bytes Average Server Log No Dimensions

e_usage storage used storage used

e_limit storage limit storage limit
active_connectio Active Count Average Active No Dimensions

ns Connections Connections
connections_faile Failed Count Total Failed No Dimensions

d Connections Connections
seconds_behind_ Replication lag in Count Average Replication lag in No Dimensions

master seconds seconds
backup_storage_ Backup Storage Bytes Average Backup Storage No Dimensions

used used used
network_bytes_e Network Out Bytes Total Network Out No Dimensions

gress across active
connections
network_bytes_i Network In Bytes Total Network In No Dimensions

ngress across active
connections
Microsoft.DBforMySQL/servers

percent





seconds_behind_ Replication lag in Count Average Replication lag in No Dimensions

master seconds seconds

used used used

gress across active
connections

connections
Microsoft.DBforPostgreSQL/servers

percent






used used used

gress across active
connections

connections
pg_replica_log_d Replica Lag Seconds Maximum Replica lag in No Dimensions

elay_in_seconds seconds
pg_replica_log_d Max Lag Across Bytes Maximum Lag in bytes of No Dimensions

elay_in_bytes Replicas the most lagging
replica
Microsoft.DBforPostgreSQL/serversv2
iops IOPS Count Average IO Operations No Dimensions

per second


gress across active
connections

connections
Microsoft.Devices/IotHubs
d2c.telemetry.ing Telemetry Count Total Number of No Dimensions

ress.allProtocol message send device-to-cloud
attempts telemetry
messages
attempted to be
sent to your IoT
hub
d2c.telemetry.ing Telemetry Count Total Number of No Dimensions

ress.success messages sent device-to-cloud
telemetry
messages sent
successfully to
your IoT hub
c2d.commands.e Commands Count Total Number of No Dimensions

gress.complete.s completed cloud-to-device
uccess commands
completed
successfully by
the device

gress.abandon.s abandoned cloud-to-device
uccess commands
abandoned by
the device

gress.reject.succe rejected cloud-to-device
ss commands
rejected by the
device
devices.totalDevi Total devices Count Total Number of No Dimensions

ces (deprecated) devices
registered to
your IoT hub
devices.connecte Connected Count Total Number of No Dimensions

dDevices.allProto devices devices
col (deprecated) connected to
your IoT hub
d2c.telemetry.eg Routing: Count Total The number of No Dimensions

ress.success telemetry times messages
messages were successfully
delivered delivered to all
endpoints using
IoT Hub routing.
If a message is
routed to
multiple
endpoints, this
value increases
by one for each
successful
delivery. If a
message is
delivered to the
same endpoint
multiple times,
this value
increases by one
for each
successful
delivery.

ress.dropped telemetry times messages
messages were dropped by
dropped IoT Hub routing
due to dead
endpoints. This
value does not
count messages
delivered to
fallback route as
dropped
messages are
not delivered
there.

ress.orphaned telemetry times messages
messages were orphaned
orphaned by IoT Hub
routing because
they didn't
match any
routing rules
(including the
fallback rule).

ress.invalid telemetry times IoT Hub
messages routing failed to
incompatible deliver messages
due to an
incompatibility
with the
endpoint. This
value does not
include retries.

ress.fallback messages times IoT Hub
delivered to routing delivered
fallback messages to the
endpoint
associated with
the fallback
route.
d2c.endpoints.eg Routing: Count Total The number of No Dimensions

ress.eventHubs messages times IoT Hub
delivered to routing
Event Hub successfully
delivered
messages to
Event Hub
endpoints.
d2c.endpoints.lat Routing: Milliseconds Average The average No Dimensions

ency.eventHubs message latency latency
for Event Hub (milliseconds)
between
message ingress
to IoT Hub and
message ingress
into an Event
Hub endpoint.

ress.serviceBusQ messages times IoT Hub
ueues delivered to routing
Service Bus successfully
Queue delivered
messages to
Service Bus
queue
endpoints.

ency.serviceBusQ message latency latency
ueues for Service Bus (milliseconds)
Queue between
message ingress
to IoT Hub and
telemetry
message ingress
into a Service
Bus queue
endpoint.

ress.serviceBusTo messages times IoT Hub
pics delivered to routing
Service Bus Topic successfully
delivered
messages to
Service Bus topic
endpoints.

ency.serviceBusT message latency latency
opics for Service Bus (milliseconds)
Topic between
message ingress
to IoT Hub and
telemetry
message ingress
into a Service
Bus topic
endpoint.

ress.builtIn.event messages times IoT Hub
s delivered to routing
messages/events successfully
delivered
messages to the
built-in endpoint
(messages/event
s). This metric
only starts
working when
routing is
enabled
(https://aka.ms/i
otrouting) for
the IoT hub.

ency.builtIn.even message latency latency
ts for (milliseconds)
messages/events between
message ingress
to IoT Hub and
telemetry
message ingress
into the built-in
endpoint
(messages/event
s). This metric
only starts
working when
routing is
enabled
(https://aka.ms/i
otrouting) for
the IoT hub.

ress.storage messages times IoT Hub
delivered to routing
storage successfully
delivered
messages to
storage
endpoints.

ency.storage message latency latency
for storage (milliseconds)
between
message ingress
to IoT Hub and
telemetry
message ingress
into a storage
endpoint.
d2c.endpoints.eg Routing: data Bytes Total The amount of No Dimensions

ress.storage.byte delivered to data (bytes) IoT
s storage Hub routing
delivered to
storage
endpoints.
d2c.endpoints.eg Routing: blobs Count Total The number of No Dimensions

ress.storage.blob delivered to times IoT Hub
s storage routing delivered
blobs to storage
endpoints.
EventGridDeliveri Event Grid Count Total The number of Result,

es deliveries IoT Hub events EventType
(preview) published to
Event Grid. Use
the Result
dimension for
the number of
successful and
failed requests.
EventType
dimension shows
the type of event
(https://aka.ms/i
oteventgrid).
EventGridLatenc The average EventType

y latency
(milliseconds)
from when the
Iot Hub event
was generated
to when the
event was
published to
Event Grid. This
number is an
average between
all event types.
Use the
EventType
dimension to see
latency of a
specific type of
event.
d2c.twin.read.suc Successful twin Count Total The count of all No Dimensions

cess reads from successful
devices device-initiated
twin reads.
d2c.twin.read.fail Failed twin reads Count Total The count of all No Dimensions
ure from devices failed device-
initiated twin
reads.
d2c.twin.read.siz Response size of Bytes Average The average, No Dimensions

e twin reads from min, and max of
devices all successful
device-initiated
twin reads.
d2c.twin.update. Successful twin Count Total The count of all No Dimensions

success updates from successful
devices device-initiated
twin updates.
d2c.twin.update.f Failed twin Count Total The count of all No Dimensions

ailure updates from failed device-
devices initiated twin
updates.
d2c.twin.update. Size of twin Bytes Average The average, No Dimensions

size updates from min, and max
devices size of all
successful
device-initiated
twin updates.
c2d.methods.suc Successful direct Count Total The count of all No Dimensions

cess method successful direct
invocations method calls.
c2d.methods.fail Failed direct Count Total The count of all No Dimensions

ure method failed direct
invocations method calls.
c2d.methods.req Request size of Bytes Average The average, No Dimensions

uestSize direct method min, and max of
invocations all successful
direct method
requests.
c2d.methods.res Response size of Bytes Average The average, No Dimensions

ponseSize direct method min, and max of
invocations all successful
direct method
responses.
c2d.twin.read.suc Successful twin Count Total The count of all No Dimensions

cess reads from back successful back-
end end-initiated
twin reads.
c2d.twin.read.fail Failed twin reads Count Total The count of all No Dimensions
ure from back end failed back-end-
initiated twin
reads.
c2d.twin.read.siz Response size of Bytes Average The average, No Dimensions

e twin reads from min, and max of
back end all successful
back-end-
initiated twin
reads.
c2d.twin.update. Successful twin Count Total The count of all No Dimensions

success updates from successful back-
back end end-initiated
twin updates.
c2d.twin.update.f Failed twin Count Total The count of all No Dimensions

ailure updates from failed back-end-
back end initiated twin
updates.
c2d.twin.update. Size of twin Bytes Average The average, No Dimensions

size updates from min, and max
back end size of all
successful back-
end-initiated
twin updates.
twinQueries.succ Successful twin Count Total The count of all No Dimensions

ess queries successful twin
queries.
twinQueries.failu Failed twin Count Total The count of all No Dimensions

re queries failed twin
queries.
twinQueries.resul Twin queries Bytes Average The average, No Dimensions

tSize result size min, and max of
the result size of
all successful
twin queries.
jobs.createTwinU Successful Count Total The count of all No Dimensions

pdateJob.success creations of twin successful
update jobs creation of twin
update jobs.
jobs.createTwinU Failed creations Count Total The count of all No Dimensions

pdateJob.failure of twin update failed creation of
jobs twin update jobs.
jobs.createDirect Successful Count Total The count of all No Dimensions

MethodJob.succ creations of successful
ess method creation of direct
invocation jobs method
invocation jobs.
jobs.createDirect Failed creations Count Total The count of all No Dimensions

MethodJob.failur of method failed creation of
e invocation jobs direct method
invocation jobs.
jobs.listJobs.succ Successful calls Count Total The count of all No Dimensions

ess to list jobs successful calls
to list jobs.
jobs.listJobs.failur Failed calls to list Count Total The count of all No Dimensions
e jobs failed calls to list
jobs.
jobs.cancelJob.su Successful job Count Total The count of all No Dimensions

ccess cancellations successful calls
to cancel a job.
jobs.cancelJob.fai Failed job Count Total The count of all No Dimensions

lure cancellations failed calls to
cancel a job.
jobs.queryJobs.s Successful job Count Total The count of all No Dimensions

uccess queries successful calls
to query jobs.
jobs.queryJobs.fa Failed job Count Total The count of all No Dimensions

ilure queries failed calls to
query jobs.
jobs.completed Completed jobs Count Total The count of all No Dimensions

completed jobs.
jobs.failed Failed jobs Count Total The count of all No Dimensions

failed jobs.
d2c.telemetry.ing Number of Count Total Number of No Dimensions

ress.sendThrottle throttling errors throttling errors
due to device
throughput
throttles
dailyMessageQu Total number of Count Average Number of total No Dimensions

otaUsed messages used messages used
today. This is a
cumulative value
that is reset to
zero at 00:00
UTC every day.
deviceDataUsage Total device data Bytes Total Bytes transferred No Dimensions

usage to and from any
devices
connected to
IotHub
totalDeviceCoun Total devices Count Average Number of No Dimensions

t (preview) devices
registered to
your IoT hub
connectedDevice Connected Count Average Number of No Dimensions

Count devices (preview) devices
connected to
your IoT hub
configurations Configuration Count Total Metrics for No Dimensions

Metrics Configuration
Operations
Microsoft.Devices/provisioningServices
RegistrationAtte Registration Count Total Number of ProvisioningServi

mpts attempts device ceName,
registrations IotHubName,
attempted Status
DeviceAssignme Devices assigned Count Total Number of ProvisioningServi

nts devices assigned ceName,
to an IoT hub IotHubName
AttestationAtte Attestation Count Total Number of ProvisioningServi

mpts attempts device ceName, Status,
attestations Protocol
attempted
Microsoft.DocumentDB/databaseAccounts
AvailableStorage Available Storage Bytes Total Total available CollectionName,

storage reported DatabaseName,
at 5 minutes Region
granularity
CassandraConne Cassandra Count Total Number of Region,

ctionClosures Connection Cassandra ClosureReason
Closures connections that
were closed,
reported at a 1
minute
granularity
CassandraReque Cassandra Count Total RUs consumed DatabaseName,

stCharges Request Charges for Cassandra CollectionName,
requests made Region,
OperationType,
ResourceType
CassandraReque Cassandra Count Count Number of DatabaseName,

sts Requests Cassandra CollectionName,
requests made Region,
OperationType,
ResourceType,
ErrorCode
DataUsage Data Usage Bytes Total Total data usage CollectionName,

reported at 5 DatabaseName,
minutes Region
granularity
DocumentCount Document Count Total Total document CollectionName,

Count count reported DatabaseName,
at 5 minutes Region
granularity
DocumentQuota Document Bytes Total Total storage CollectionName,

Quota quota reported DatabaseName,
at 5 minutes Region
granularity
IndexUsage Index Usage Bytes Total Total index usage CollectionName,

reported at 5 DatabaseName,
minutes Region
granularity
MetadataReques Metadata Count Count Count of DatabaseName,

ts Requests metadata CollectionName,
requests. Region,
Cosmos DB StatusCode,
maintains
system metadata
collection for
each account,
that allows you
to enumerate
collections,
databases, etc.,
and their
configurations,
free of charge.
MongoRequestC Mongo Request Count Total Mongo Request DatabaseName,

harge Charge Units Consumed CollectionName,
Region,
CommandName,
ErrorCode
MongoRequests Mongo Requests Count Count Number of DatabaseName,

Mongo Requests CollectionName,
Made Region,
CommandName,
ErrorCode
ProvisionedThro Provisioned Count Maximum Provisioned DatabaseName,

ughput Throughput Throughput CollectionName
ReplicationLaten P99 Replication MilliSeconds Average P99 Replication SourceRegion,

cy Latency Latency across TargetRegion
source and
target regions
for geo-enabled
account
ServiceAvailabilit Service Percent Average Account No Dimensions

y Availability requests
availability at
one hour, day or
month
granularity
TotalRequestUnit Total Request Count Total Request Units DatabaseName,

s Units consumed CollectionName,
Region,
StatusCode,
OperationType
TotalRequests Total Requests Count Count Number of DatabaseName,

requests made CollectionName,
Region,
StatusCode,
OperationType
Microsoft.EventGrid/topics
PublishSuccessC Published Events Count Total Total events No Dimensions

ount published to this
topic
PublishFailCount Publish Failed Count Total Total events ErrorType, Error

Events failed to publish
to this topic
UnmatchedEvent Unmatched Count Total Total events not No Dimensions

Count Events matching any of
the event
subscriptions for
this topic
PublishSuccessLa Publish Success Count Total Publish success No Dimensions

tencyInMs Latency latency in
milliseconds
Microsoft.EventGrid/eventSubscriptions
MatchedEventCo Matched Events Count Total Total events No Dimensions

unt matched to this
event
subscription
DeliveryAttempt Delivery Failed Count Total Total events Error, ErrorType

FailCount Events failed to deliver
to this event
subscription
DeliverySuccessC Delivered Events Count Total Total events No Dimensions

ount delivered to this
event
subscription
DestinationProce Destination Milliseconds Average Destination No Dimensions

ssingDurationIn Processing processing
Ms Duration duration in
milliseconds
DroppedEventCo Dropped Events Count Total Total dropped DropReason

unt events matching
to this event
subscription
DeadLetteredCo Dead Lettered Count Total Total dead DeadLetterReaso

unt Events lettered events n
matching to this
event
subscription
Microsoft.EventGrid/extensionTopics
PublishSuccessC Published Events Count Total Total events No Dimensions

ount published to this
topic
PublishFailCount Failed Events Count Total Total events ErrorType, Error

failed to publish
to this topic
UnmatchedEvent Unmatched Count Total Total events not No Dimensions

Count Events matching any of
the event
subscriptions for
this topic
PublishSuccessLa Publish Success Count Total Publish success No Dimensions

tencyInMs Latency latency in
milliseconds
Microsoft.EventHub/namespaces
SuccessfulReques Successful Count Total Successful EntityName,

ts Requests Requests for
Microsoft.EventH
ub.
ServerErrors Server Errors. Count Total Server Errors for EntityName,

Microsoft.EventH
ub.
UserErrors User Errors. Count Total User Errors for EntityName,

Microsoft.EventH
ub.
QuotaExceededE Quota Exceeded Count Total Quota Exceeded EntityName,

rrors Errors. Errors for
Microsoft.EventH
ub.
ThrottledRequest Throttled Count Total Throttled EntityName,

s Requests. Requests for
Microsoft.EventH
ub.
IncomingReques Incoming Count Total Incoming EntityName

Microsoft.EventH
ub.
IncomingMessag Incoming Count Total Incoming EntityName

es Messages Messages for
Microsoft.EventH
ub.
OutgoingMessa Outgoing Count Total Outgoing EntityName

ges Messages Messages for
Microsoft.EventH
ub.
IncomingBytes Incoming Bytes. Bytes Total Incoming Bytes EntityName

for
Microsoft.EventH
ub.
OutgoingBytes Outgoing Bytes. Bytes Total Outgoing Bytes EntityName

for
Microsoft.EventH
ub.
ActiveConnectio ActiveConnectio Count Average Total Active No Dimensions

ns ns Connections for
Microsoft.EventH
ub.
ConnectionsOpe Connections Count Average Connections EntityName

ned Opened. Opened for
Microsoft.EventH
ub.
ConnectionsClos Connections Count Average Connections EntityName

ed Closed. Closed for
Microsoft.EventH
ub.
CaptureBacklog Capture Backlog. Count Total Capture Backlog EntityName

for
Microsoft.EventH
ub.
CapturedMessag Captured Count Total Captured EntityName

es Messages. Messages for
Microsoft.EventH
ub.
CapturedBytes Captured Bytes. Bytes Total Captured Bytes EntityName

for
Microsoft.EventH
ub.
Size Size Bytes Average Size of an EntityName

EventHub in
Bytes.
INREQS Incoming Count Total Total incoming No Dimensions

Requests send requests
(Deprecated) for a namespace
(Deprecated)
SUCCREQ Successful Count Total Total successful No Dimensions

Requests requests for a
(Deprecated) namespace
(Deprecated)
FAILREQ Failed Requests Count Total Total failed No Dimensions

(Deprecated) requests for a
namespace
(Deprecated)
SVRBSY Server Busy Count Total Total server busy No Dimensions

Errors errors for a
(Deprecated)
INTERR Internal Server Count Total Total internal No Dimensions

Errors server errors for
(Deprecated) a namespace
(Deprecated)
MISCERR Other Errors Count Total Total failed No Dimensions

(Deprecated) requests for a
namespace
(Deprecated)
INMSGS Incoming Count Total Total incoming No Dimensions

Messages messages for a
(Deprecated) namespace. This
(Deprecated) metric is
deprecated.
Please use
Incoming
Messages metric
instead
(Deprecated)
EHINMSGS Incoming Count Total Total incoming No Dimensions

(Deprecated)
OUTMSGS Outgoing Count Total Total outgoing No Dimensions

(Deprecated) namespace. This
(Deprecated) metric is
deprecated.
Please use
Outgoing
Messages metric
instead
(Deprecated)
EHOUTMSGS Outgoing Count Total Total outgoing No Dimensions

(Deprecated)
EHINMBS Incoming bytes Bytes Total Event Hub No Dimensions

(Deprecated) incoming
(Deprecated) message
throughput for a
namespace. This
metric is
deprecated.
Please use
Incoming bytes
metric instead
(Deprecated)
EHINBYTES Incoming bytes Bytes Total Event Hub No Dimensions

(Deprecated) incoming
message
throughput for a
namespace
(Deprecated)
EHOUTMBS Outgoing bytes Bytes Total Event Hub No Dimensions

(Deprecated) outgoing
throughput for a
namespace. This
metric is
deprecated.
Please use
Outgoing bytes
metric instead
(Deprecated)
EHOUTBYTES Outgoing bytes Bytes Total Event Hub No Dimensions

(Deprecated) outgoing
message
throughput for a
namespace
(Deprecated)
EHABL Archive backlog Count Total Event Hub No Dimensions

messages archive
(Deprecated) messages in
backlog for a
namespace
(Deprecated)
EHAMSGS Archive Count Total Event Hub No Dimensions

messages archived
(Deprecated) messages in a
namespace
(Deprecated)
EHAMBS Archive message Bytes Total Event Hub No Dimensions

throughput archived
throughput in a
namespace
(Deprecated)
Microsoft.EventHub/clusters
SuccessfulReques Successful Count Total Successful No Dimensions

(Preview) Microsoft.EventH
ub. (Preview)
ServerErrors Server Errors. Count Total Server Errors for No Dimensions

ub. (Preview)
UserErrors User Errors. Count Total User Errors for No Dimensions

ub. (Preview)
QuotaExceededE Quota Exceeded Count Total Quota Exceeded No Dimensions

rrors Errors. (Preview) Errors for
Microsoft.EventH
ub. (Preview)
ThrottledRequest Throttled Count Total Throttled No Dimensions

ub. (Preview)
IncomingReques Incoming Count Total Incoming No Dimensions

ub. (Preview)
IncomingMessag Incoming Count Total Incoming No Dimensions

ub. (Preview)
OutgoingMessa Outgoing Count Total Outgoing No Dimensions

ub. (Preview)
IncomingBytes Incoming Bytes. Bytes Total Incoming Bytes No Dimensions

(Preview) for
Microsoft.EventH
ub. (Preview)
OutgoingBytes Outgoing Bytes. Bytes Total Outgoing Bytes No Dimensions

(Preview) for
Microsoft.EventH
ub. (Preview)
ActiveConnectio ActiveConnectio Count Average Total Active No Dimensions

ns ns (Preview) Connections for
Microsoft.EventH
ub. (Preview)
ConnectionsOpe Connections Count Average Connections No Dimensions

ned Opened. Opened for
ub. (Preview)
ConnectionsClos Connections Count Average Connections No Dimensions

ed Closed. (Preview) Closed for
Microsoft.EventH
ub. (Preview)
CaptureBacklog Capture Backlog. Count Total Capture Backlog No Dimensions

(Preview) for
Microsoft.EventH
ub. (Preview)
CapturedMessag Captured Count Total Captured No Dimensions

es Messages. Messages for
ub. (Preview)
CapturedBytes Captured Bytes. Bytes Total Captured Bytes No Dimensions

(Preview) for
Microsoft.EventH
ub. (Preview)
CPU CPU (Preview) Percent Maximum CPU utilization Role

for the Event
Hub Cluster as a
percentage
AvailableMemor Available Count Maximum Available Role

y Memory memory for the
(Preview) Event Hub
Cluster in bytes
Microsoft.HDInsight/clusters
GatewayRequest Gateway Count Total Number of ClusterDnsName,

s Requests gateway HttpStatus
requests
CategorizedGate Categorized Count Total Number of ClusterDnsName,

wayRequests Gateway gateway HttpStatus
Requests requests by
categories
(1xx/2xx/3xx/4xx/
5xx)
NumActiveWork Number of Count Maximum Number of ClusterDnsName,

ers Active Workers Active Workers MetricName
Microsoft.Insights/AutoscaleSettings
ObservedMetric Observed Metric Count Average The value MetricTriggerSou

Value Value computed by rce
autoscale when
executed
MetricThreshold Metric Threshold Count Average The configured MetricTriggerRul

autoscale e
threshold when
autoscale ran.
ObservedCapacit Observed Count Average The capacity No Dimensions

y Capacity reported to
autoscale when
it executed.
ScaleActionsInitia Scale Actions Count Total The direction of ScaleDirection

ted Initiated the scale
operation.
Microsoft.Insights/Components
(Public Preview )

availabilityResult Availability Percent Average Percentage of availabilityResult/

s/availabilityPerc successfully name,
entage completed availabilityResult/
availability tests location
availabilityResult Availability tests Count Count Count of availabilityResult/

s/count availability tests name,
availabilityResult/
location,
availabilityResult/
success
availabilityResult Availability test MilliSeconds Average Availability test availabilityResult/

s/duration duration duration name,
availabilityResult/
location,
availabilityResult/
success
browserTimings/ Page load MilliSeconds Average Time between No Dimensions

networkDuration network connect user request and
time network
connection.
Includes DNS
lookup and
transport
connection.
browserTimings/ Client processing MilliSeconds Average Time between No Dimensions

processingDurati time receiving the last
on byte of a
document until
the DOM is
loaded. Async
requests may
still be
processing.
browserTimings/ Receiving MilliSeconds Average Time between No Dimensions

receiveDuration response time the first and last
bytes, or until
disconnection.
browserTimings/ Send request MilliSeconds Average Time between No Dimensions

sendDuration time network
connection and
receiving the first
byte.
browserTimings/ Browser page MilliSeconds Average Time from user No Dimensions

totalDuration load time request until
DOM,
stylesheets,
scripts and
images are
loaded.
dependencies/co Dependency calls Count Count Count of calls dependency/type

unt made by the ,
application to dependency/perf
external ormanceBucket,
resources. dependency/succ
ess,
operation/synthe
tic,
cloud/roleInstanc
e,
cloud/roleName
dependencies/du Dependency MilliSeconds Average Duration of calls dependency/type

ration duration made by the ,
application to dependency/perf
external ormanceBucket,
resources. dependency/succ
ess,
operation/synthe
tic,
cloud/roleInstanc
e,
cloud/roleName
dependencies/fail Dependency call Count Count Count of failed dependency/type

ed failures dependency calls ,
made by the dependency/perf
application to ormanceBucket,
external operation/synthe
resources. tic,
cloud/roleInstanc
e,
cloud/roleName
pageViews/count Page views Count Count Count of page operation/synthe

views. tic
pageViews/durat Page view load MilliSeconds Average Page view load operation/synthe
ion time time tic
performanceCou HTTP request MilliSeconds Average Execution time of cloud/roleInstanc

nters/requestExe execution time the most recent e
cutionTime request.
performanceCou HTTP requests in Count Average Length of the cloud/roleInstanc

nters/requestsIn application application e
Queue queue request queue.
performanceCou HTTP request CountPerSecond Average Rate of all cloud/roleInstanc

nters/requestsPe rate requests to the e
rSecond application per
second from
ASP.NET.
performanceCou Exception rate CountPerSecond Average Count of cloud/roleInstanc

nters/exceptions handled and e
PerSecond unhandled
exceptions
reported to
windows,
including .NET
exceptions and
unmanaged
exceptions that
are converted
into .NET
exceptions.
performanceCou Process IO rate BytesPerSecond Average Total bytes per cloud/roleInstanc

nters/processIOB second read and e
ytesPerSecond written to files,
network and
devices.
performanceCou Process CPU Percent Average The percentage cloud/roleInstanc

nters/processCp of elapsed time e
uPercentage that all process
threads used the
processor to
execute
instructions. This
can vary
between 0 to
100. This metric
indicates the
performance of
w3wp process
alone.
performanceCou Processor time Percent Average The percentage cloud/roleInstanc

nters/processorC of time that the e
puPercentage processor
spends in non-
idle threads.
performanceCou Available Bytes Average Physical memory cloud/roleInstanc

nters/memoryAv memory immediately e
ailableBytes available for
allocation to a
process or for
system use.
performanceCou Process private Bytes Average Memory cloud/roleInstanc

nters/processPriv bytes exclusively e
ateBytes assigned to the
monitored
application's
processes.
requests/duratio Server response MilliSeconds Average Time between request/perform

n time receiving an anceBucket,
HTTP request request/resultCo
and finishing de,
sending the operation/synthe
response. tic,
cloud/roleInstanc
e,
request/success,
cloud/roleName
requests/count Server requests Count Count Count of HTTP request/perform

requests anceBucket,
completed. request/resultCo
de,
operation/synthe
tic,
cloud/roleInstanc
e,
request/success,
cloud/roleName
requests/failed Failed requests Count Count Count of HTTP request/perform

requests marked anceBucket,
as failed. In most request/resultCo
cases these are de,
requests with a operation/synthe
response code tic,
>= 400 and not cloud/roleInstanc
equal to 401. e,
cloud/roleName
requests/rate Server request CountPerSecond Average Rate of server request/perform

rate requests per anceBucket,
second request/resultCo
de,
operation/synthe
tic,
cloud/roleInstanc
e,
request/success,
cloud/roleName
exceptions/count Exceptions Count Count Combined count cloud/roleName,

of all uncaught cloud/roleInstanc
exceptions. e, client/type
exceptions/brow Browser Count Count Count of No Dimensions

ser exceptions uncaught
exceptions
thrown in the
browser.
exceptions/serve Server Count Count Count of cloud/roleName,

r exceptions uncaught cloud/roleInstanc
exceptions e
thrown in the
server
application.
traces/count Traces Count Count Trace document trace/severityLev

count el,
operation/synthe
tic,
cloud/roleName,
cloud/roleInstanc
e
Microsoft.KeyVault/vaults
ServiceApiHit Total Service Api Count Count Number of total ActivityType,

Hits service api hits ActivityName
ServiceApiLatenc Overall Service Milliseconds Average Overall latency ActivityType,

y Api Latency of service api ActivityName,
requests StatusCode
ServiceApiResult Total Service Api Count Count Number of total ActivityType,

Results service api ActivityName,
results StatusCode
Microsoft.Kusto/Clusters
CacheUtilization Cache Utilization Percent Average Utilization level None

in the cluster
scope
QueryDuration Query Duration Milliseconds Average Queries’ Query Status

duration in
seconds
IngestionUtilizati Ingestion Percent Average Ratio of used None

on Utilization ingestion slots in
the cluster
KeepAlive Keep Alive Count Average Sanity check None

indicates the
cluster responds
to queries
IngestionVolume Ingestion Count Total Overall volume Database

InMB Volume (In MB) of ingested data
to the cluster (in
MB)
IngestionLatency Ingestion Seconds Average Ingestion time None

InSeconds Latency (In from the source
seconds) (e.g. message is
in EventHub) to
the cluster in
seconds
EventProcessedF Events Processed Count Total Number of None

orEventHubs (for Event Hubs) events processed
by the cluster
when ingesting
from Event Hub
IngestionResult Ingestion Result Count Count Number of Status

ingestion
operations
CPU CPU Percent Average CPU utilization None

level
ContinuousExpor Number of Count Total Number of None

tNumOfRecordsE records exported records exported
xported in continuous for every storage
export artifact written
during the
export operation
ExportUtilization Export Utilization Percent Maximum Export utilization None
ContinuousExpor Continuous Count Maximum The number of None

tPendingCount Export Pending pending
Count continuous
export jobs
ready for
execution
ContinuousExpor Continuous Count Maximum The max time in None

tMaxLatenessMi Export Max minutes of all
nutes Lateness continuous
Minutes exports which
are pending and
ready for
execution
Microsoft.LocationBasedServices/accounts
Usage Usage Count Count Count of API ApiCategory,

calls ApiName
Microsoft.Logic/workflows
RunsStarted Runs Started Count Total Number of No Dimensions

workflow runs
started.
RunsCompleted Runs Completed Count Total Number of No Dimensions

workflow runs
completed.
RunsSucceeded Runs Succeeded Count Total Number of No Dimensions

workflow runs
succeeded.
RunsFailed Runs Failed Count Total Number of No Dimensions

workflow runs
failed.
RunsCancelled Runs Canceled Count Total Number of No Dimensions

workflow runs
canceled.
RunLatency Run Latency Seconds Average Latency of No Dimensions

completed
workflow runs.
RunSuccessLaten Run Success Seconds Average Latency of No Dimensions

cy Latency succeeded
workflow runs.
RunThrottledEve Run Throttled Count Total Number of No Dimensions

nts Events workflow action
or trigger
throttled events.
RunFailurePercen Run Failure Percent Total Percentage of No Dimensions

tage Percentage workflow runs
failed.
ActionsStarted Actions Started Count Total Number of No Dimensions

workflow actions
started.
ActionsComplete Actions Count Total Number of No Dimensions

d Completed workflow actions
completed.
ActionsSucceede Actions Count Total Number of No Dimensions

d Succeeded workflow actions
succeeded.
ActionsFailed Actions Failed Count Total Number of No Dimensions

workflow actions
failed.
ActionsSkipped Actions Skipped Count Total Number of No Dimensions

workflow actions
skipped.
ActionLatency Action Latency Seconds Average Latency of No Dimensions

completed
workflow actions.
ActionSuccessLat Action Success Seconds Average Latency of No Dimensions

ency Latency succeeded
workflow actions.
ActionThrottledE Action Throttled Count Total Number of No Dimensions

vents Events workflow action
throttled events..
TriggersStarted Triggers Started Count Total Number of No Dimensions

workflow
triggers started.
TriggersComplet Triggers Count Total Number of No Dimensions

ed Completed workflow
triggers
completed.
TriggersSucceede Triggers Count Total Number of No Dimensions

d Succeeded workflow
triggers
succeeded.
TriggersFailed Triggers Failed Count Total Number of No Dimensions

workflow
triggers failed.
TriggersSkipped Triggers Skipped Count Total Number of No Dimensions

workflow
triggers skipped.
TriggersFired Triggers Fired Count Total Number of No Dimensions

workflow
triggers fired.
TriggerLatency Trigger Latency Seconds Average Latency of No Dimensions

completed
workflow
triggers.
TriggerFireLatenc Trigger Fire Seconds Average Latency of fired No Dimensions

y Latency workflow
triggers.
TriggerSuccessLa Trigger Success Seconds Average Latency of No Dimensions

tency Latency succeeded
workflow
triggers.
TriggerThrottledE Trigger Throttled Count Total Number of No Dimensions

vents Events workflow trigger
throttled events.
BillableActionExe Billable Action Count Total Number of No Dimensions

cutions Executions workflow action
executions
getting billed.
BillableTriggerExe Billable Trigger Count Total Number of No Dimensions

cutions Executions workflow trigger
executions
getting billed.
TotalBillableExecu Total Billable Count Total Number of No Dimensions

tions Executions workflow
executions
getting billed.
BillingUsageNati Billing Usage for Count Total Number of No Dimensions

veOperation Native Operation native operation
Executions executions
getting billed.
BillingUsageStan Billing Usage for Count Total Number of No Dimensions

dardConnector Standard standard
Connector connector
getting billed.
BillingUsageStor Billing Usage for Count Total Number of No Dimensions

ageConsumption Storage storage
Consumption consumption
getting billed.
BillingUsageNati Billing Usage for Count Total Number of No Dimensions

veOperation Native Operation native operation
getting billed.
BillingUsageStan Billing Usage for Count Total Number of No Dimensions

dardConnector Standard standard
Connector connector
getting billed.
BillingUsageStor Billing Usage for Count Total Number of No Dimensions

ageConsumption Storage storage
Consumption consumption
getting billed.
Microsoft.Logic/integrationServiceEnvironments
RunsStarted Runs Started Count Total Number of No Dimensions

workflow runs
started.
RunsCompleted Runs Completed Count Total Number of No Dimensions

workflow runs
completed.
RunsSucceeded Runs Succeeded Count Total Number of No Dimensions

workflow runs
succeeded.
RunsFailed Runs Failed Count Total Number of No Dimensions

workflow runs
failed.
RunsCancelled Runs Canceled Count Total Number of No Dimensions

workflow runs
canceled.
RunLatency Run Latency Seconds Average Latency of No Dimensions

completed
workflow runs.
RunSuccessLaten Run Success Seconds Average Latency of No Dimensions

cy Latency succeeded
workflow runs.
RunThrottledEve Run Throttled Count Total Number of No Dimensions

nts Events workflow action
or trigger
throttled events.
RunStartThrottle Run Start Count Total Number of No Dimensions

dEvents Throttled Events workflow run
start throttled
events.
RunFailurePercen Run Failure Percent Total Percentage of No Dimensions

tage Percentage workflow runs
failed.
ActionsStarted Actions Started Count Total Number of No Dimensions

workflow actions
started.
ActionsComplete Actions Count Total Number of No Dimensions

d Completed workflow actions
completed.
ActionsSucceede Actions Count Total Number of No Dimensions

d Succeeded workflow actions
succeeded.
ActionsFailed Actions Failed Count Total Number of No Dimensions

workflow actions
failed.
ActionsSkipped Actions Skipped Count Total Number of No Dimensions

workflow actions
skipped.
ActionLatency Action Latency Seconds Average Latency of No Dimensions

completed
workflow actions.
ActionSuccessLat Action Success Seconds Average Latency of No Dimensions

ency Latency succeeded
workflow actions.
ActionThrottledE Action Throttled Count Total Number of No Dimensions

vents Events workflow action
throttled events..
TriggersStarted Triggers Started Count Total Number of No Dimensions

workflow
triggers started.
TriggersComplet Triggers Count Total Number of No Dimensions

ed Completed workflow
triggers
completed.
TriggersSucceede Triggers Count Total Number of No Dimensions

d Succeeded workflow
triggers
succeeded.
TriggersFailed Triggers Failed Count Total Number of No Dimensions

workflow
triggers failed.
TriggersSkipped Triggers Skipped Count Total Number of No Dimensions

workflow
triggers skipped.
TriggersFired Triggers Fired Count Total Number of No Dimensions

workflow
triggers fired.
TriggerLatency Trigger Latency Seconds Average Latency of No Dimensions

completed
workflow
triggers.
TriggerFireLatenc Trigger Fire Seconds Average Latency of fired No Dimensions

y Latency workflow
triggers.
TriggerSuccessLa Trigger Success Seconds Average Latency of No Dimensions

tency Latency succeeded
workflow
triggers.
TriggerThrottledE Trigger Throttled Count Total Number of No Dimensions

vents Events workflow trigger
throttled events.
IntegrationServic Workflow Percent Average Workflow No Dimensions

eEnvironmentW Processor Usage processor usage
orkflowProcessor for Integration for integration
Usage Service service
Environment environment.
IntegrationServic Workflow Percent Average Workflow No Dimensions

eEnvironmentW Memory Usage memory usage
orkflowMemory for Integration for integration
IntegrationServic Connector Percent Average Connector No Dimensions

eEnvironmentCo Processor Usage processor usage
nnectorProcesso for Integration for integration
rUsage Service service
IntegrationServic Connector Percent Average Connector No Dimensions

eEnvironmentCo Memory Usage memory usage
nnectorMemory for Integration for integration
Microsoft.MachineLearningServices/workspaces
Completed Runs Completed Runs Count Total Number of runs Scenario

completed
successfully for
this workspace
Started Runs Started Runs Count Total Number of runs Scenario

started for this
workspace
Failed Runs Failed Runs Count Total Number of runs Scenario

failed for this
workspace
Microsoft.Maps/accounts
Usage Usage Count Count Count of API ApiCategory,

calls ApiName,
ResultType,
ResponseCode
Availability Availability Percent Average Availability of the ApiCategory,

APIs ApiName
Microsoft.NetApp/netAppAccounts/capacityPools/Volumes
AverageOtherLat Average other ms/op Average Average other No Dimensions

ency latency latency (that is
not read or
write) in
milliseconds per
operation
AverageReadLat Average read ms/op Average Average read No Dimensions

ency latency latency in
milliseconds per
operation
AverageTotalLate Average total ms/op Average Average total No Dimensions

ncy latency latency in
milliseconds per
operation
AverageWriteLat Average write ms/op Average Average write No Dimensions

ency latency latency in
milliseconds per
operation
FilesystemOther Filesystem other ops Average Number of No Dimensions

Ops ops filesystem other
operations (that
is not read or
write)
FilesystemReadO Filesystem read ops Average Number of No Dimensions

ps ops filesystem read
operations
FilesystemTotalO Filesystem total ops Average Sum of all No Dimensions

ps ops filesystem
operations
FilesystemWrite Filesystem write ops Average Number of No Dimensions

Ops ops filesystem write
operations
IoBytesPerOther Io bytes per bytes/op Average Number of No Dimensions

Ops other ops In/out bytes per
other operations
(that is not read
or write)
IoBytesPerRead Io bytes per read bytes/op Average Number of No Dimensions

Ops ops In/out bytes per
read operation
IoBytesPerTotalO Io bytes per op bytes/op Average Sum of all In/out No Dimensions

ps across all bytes operation
operations
IoBytesPerWrite Io bytes per bytes/op Average Number of No Dimensions

Ops write ops In/out bytes per
write operation
OtherIops Other iops operations/secon Average Other In/out No Dimensions

d operation per
second
OtherThroughpu Other MBps Average Other No Dimensions

t throughput throughput (that
is not read or
write) in
megabytes per
second
ReadIops Read iops operations/secon Average Read In/out No Dimensions

d operations per
second
ReadThroughput Read throughput MBps Average Read throughput No Dimensions

in megabytes
per second
TotalIops Total iops operations/secon Average Sum of all In/out No Dimensions

d operations per
second
TotalThroughput Total throughput MBps Average Sum of all No Dimensions

throughput in
megabytes per
second
VolumeAllocated Volume allocated bytes Average Allocated size of No Dimensions

Size size the volume (Not
the actual used
bytes)
VolumeLogicalSiz Volume logical bytes Average Logical size of No Dimensions

e size the volume
(used bytes)
VolumeSnapshot Volume bytes Average Size of all No Dimensions

Size snapshot size snapshots in
volume
WriteIops Write iops operations/secon Average Write In/out No Dimensions

d operations per
second
WriteThroughpu Write MBps Average Write No Dimensions

t throughput throughput in
megabytes per
second
Microsoft.NetApp/netAppAccounts/capacityPools
VolumePoolAlloc Volume pool bytes Average Allocated size of No Dimensions

atedSize allocated size the pool (Not
the actual used
bytes)
VolumePoolAlloc Volume pool bytes Average Allocated used No Dimensions

atedUsed allocated used size of the pool
VolumePoolTotal Volume pool bytes Average Sum of the No Dimensions

LogicalSize total logical size logical size of all
the volumes
belonging to the
pool
VolumePoolTotal Volume pool bytes Average Sum of all No Dimensions

SnapshotSize total snapshot snapshots in
size pool
Microsoft.Network/networkInterfaces
BytesSentRate Bytes Sent Count Total Number of bytes No Dimensions

the Network
Interface sent
BytesReceivedRa Bytes Received Count Total Number of bytes No Dimensions

te the Network
Interface
received
PacketsSentRate Packets Sent Count Total Number of No Dimensions

packets the
Network
Interface sent
PacketsReceived Packets Received Count Total Number of No Dimensions

Rate packets the
Network
Interface
received
Microsoft.Network/loadBalancers
VipAvailability Data Path Count Average Average Load FrontendIPAddre

Availability Balancer data ss, FrontendPort
path availability
per time
duration
DipAvailability Health Probe Count Average Average Load ProtocolType,

Status Balancer health BackendPort,
probe status per FrontendIPAddre
time duration ss, FrontendPort,
BackendIPAddres
s
ByteCount Byte Count Count Total Total number of FrontendIPAddre

Bytes ss, FrontendPort,
transmitted Direction
within time
period
PacketCount Packet Count Count Total Total number of FrontendIPAddre

Packets ss, FrontendPort,
within time
period
SYNCount SYN Count Count Total Total number of FrontendIPAddre

SYN Packets ss, FrontendPort,
within time
period
SnatConnection SNAT Count Total Total number of FrontendIPAddre

Count Connection new SNAT ss,
Count connections BackendIPAddres
created within s,
time period ConnectionState
AllocatedSnatPor Allocated SNAT Count Total Total number of FrontendIPAddre

ts Ports (Preview) SNAT ports ss,
allocated within BackendIPAddres
time period s, ProtocolType
UsedSnatPorts Used SNAT Ports Count Total Total number of FrontendIPAddre

(Preview) SNAT ports used ss,
within time BackendIPAddres
period s, ProtocolType
Microsoft.Network/dnszones
QueryVolume Query Volume Count Total Number of No Dimensions

queries served
for a DNS zone
RecordSetCount Record Set Count Maximum Number of No Dimensions

Count Record Sets in a
DNS zone
RecordSetCapaci Record Set Percent Maximum Percent of No Dimensions

tyUtilization Capacity Record Set
Utilization capacity utilized
by a DNS zone
Microsoft.Network/publicIPAddresses
PacketsInDDoS Inbound packets CountPerSecond Maximum Inbound packets No Dimensions

DDoS DDoS
PacketsDropped Inbound packets CountPerSecond Maximum Inbound packets No Dimensions

DDoS dropped DDoS dropped DDoS
PacketsForwarde Inbound packets CountPerSecond Maximum Inbound packets No Dimensions

dDDoS forwarded DDoS forwarded DDoS
TCPPacketsInDD Inbound TCP CountPerSecond Maximum Inbound TCP No Dimensions

oS packets DDoS packets DDoS
TCPPacketsDrop Inbound TCP CountPerSecond Maximum Inbound TCP No Dimensions

pedDDoS packets dropped packets dropped
DDoS DDoS
TCPPacketsForw Inbound TCP CountPerSecond Maximum Inbound TCP No Dimensions

ardedDDoS packets packets
forwarded DDoS forwarded DDoS
UDPPacketsInD Inbound UDP CountPerSecond Maximum Inbound UDP No Dimensions

DoS packets DDoS packets DDoS
UDPPacketsDrop Inbound UDP CountPerSecond Maximum Inbound UDP No Dimensions

pedDDoS packets dropped packets dropped
DDoS DDoS
UDPPacketsForw Inbound UDP CountPerSecond Maximum Inbound UDP No Dimensions

ardedDDoS packets packets
forwarded DDoS forwarded DDoS
BytesInDDoS Inbound bytes BytesPerSecond Maximum Inbound bytes No Dimensions

DDoS DDoS
BytesDroppedD Inbound bytes BytesPerSecond Maximum Inbound bytes No Dimensions

DoS dropped DDoS dropped DDoS
BytesForwarded Inbound bytes BytesPerSecond Maximum Inbound bytes No Dimensions

DDoS forwarded DDoS forwarded DDoS
TCPBytesInDDoS Inbound TCP BytesPerSecond Maximum Inbound TCP No Dimensions

bytes DDoS bytes DDoS
TCPBytesDroppe Inbound TCP BytesPerSecond Maximum Inbound TCP No Dimensions

dDDoS bytes dropped bytes dropped
DDoS DDoS
TCPBytesForwar Inbound TCP BytesPerSecond Maximum Inbound TCP No Dimensions

dedDDoS bytes forwarded bytes forwarded
DDoS DDoS
UDPBytesInDDo Inbound UDP BytesPerSecond Maximum Inbound UDP No Dimensions

S bytes DDoS bytes DDoS
UDPBytesDropp Inbound UDP BytesPerSecond Maximum Inbound UDP No Dimensions

edDDoS bytes dropped bytes dropped
DDoS DDoS
UDPBytesForwar Inbound UDP BytesPerSecond Maximum Inbound UDP No Dimensions

dedDDoS bytes forwarded bytes forwarded
DDoS DDoS
IfUnderDDoSAtt Under DDoS Count Maximum Under DDoS No Dimensions

ack attack or not attack or not
DDoSTriggerTCP Inbound TCP CountPerSecond Maximum Inbound TCP No Dimensions

Packets packets to packets to
trigger DDoS trigger DDoS
mitigation mitigation
DDoSTriggerUDP Inbound UDP CountPerSecond Maximum Inbound UDP No Dimensions

DDoSTriggerSYN Inbound SYN CountPerSecond Maximum Inbound SYN No Dimensions

VipAvailability Data Path Count Average Average IP Port

Availability Address
availability per
time duration
ByteCount Byte Count Count Total Total number of Port, Direction

Bytes
transmitted
within time
period
PacketCount Packet Count Count Total Total number of Port, Direction

Packets
transmitted
within time
period
SynCount SYN Count Count Total Total number of Port, Direction

SYN Packets
transmitted
within time
period
Microsoft.Network/azurefirewalls
ApplicationRuleH Application rules Count Total Number of times Status, Reason,

it hit count Application rules Protocol
were hit
NetworkRuleHit Network rules hit Count Total Number of times Status, Reason,
count Network rules Protocol
were hit
Microsoft.Network/applicationGateways
Throughput Throughput BytesPerSecond Total Number of bytes No Dimensions

per second the
Application
Gateway has
served
UnhealthyHostC Unhealthy Host Count Average Number of BackendSettings

ount Count unhealthy Pool
backend hosts
HealthyHostCou Healthy Host Count Average Number of BackendSettings

nt Count healthy backend Pool
hosts
TotalRequests Total Requests Count Total Count of BackendSettings

successful Pool
requests that
Application
Gateway has
served
FailedRequests Failed Requests Count Total Count of failed BackendSettings

requests that Pool
Application
Gateway has
served
ResponseStatus Response Status Count Total Http response HttpStatusGroup

status returned
by Application
Gateway
CurrentConnecti Current Count Total Count of current No Dimensions

ons Connections connections
established with
Application
Gateway
CapacityUnits Current Capacity Count Average Capacity Units No Dimensions

Units consumed
Microsoft.Network/virtualNetworkGateways
AverageBandwid Gateway S2S BytesPerSecond Average Average site-to- No Dimensions

th Bandwidth site bandwidth
of a gateway in
bytes per second
P2SBandwidth Gateway P2S BytesPerSecond Average Average point- No Dimensions

Bandwidth to-site
bandwidth of a
gateway in bytes
per second
P2SConnectionC P2S Connection Count Maximum Point-to-site Protocol

ount Count connection
count of a
gateway
TunnelAverageB Tunnel BytesPerSecond Average Average ConnectionName

andwidth Bandwidth bandwidth of a , RemoteIP
tunnel in bytes
per second
TunnelEgressByt Tunnel Egress Bytes Total Outgoing bytes ConnectionName

es Bytes of a tunnel , RemoteIP
TunnelIngressByt Tunnel Ingress Bytes Total Incoming bytes ConnectionName

es Bytes of a tunnel , RemoteIP
TunnelEgressPac Tunnel Egress Count Total Outgoing packet ConnectionName

kets Packets count of a tunnel , RemoteIP
TunnelIngressPa Tunnel Ingress Count Total Incoming packet ConnectionName

ckets Packets count of a tunnel , RemoteIP
TunnelEgressPac Tunnel Egress TS Count Total Outgoing packet ConnectionName

ketDropTSMisma Mismatch Packet drop count from , RemoteIP
tch Drop traffic selector
mismatch of a
tunnel
TunnelIngressPa Tunnel Ingress Count Total Incoming packet ConnectionName

cketDropTSMism TS Mismatch drop count from , RemoteIP
atch Packet Drop traffic selector
mismatch of a
tunnel
Microsoft.Network/expressRouteCircuits
BitsInPerSecond BitsInPerSecond CountPerSecond Average Bits ingressing PeeringType

Azure per
second
BitsOutPerSecon BitsOutPerSecon CountPerSecond Average Bits egressing PeeringType

d d Azure per
second
Microsoft.Network/expressRouteCircuits/peerings
BitsInPerSecond BitsInPerSecond CountPerSecond Average Bits ingressing No Dimensions

Azure per
second
BitsOutPerSecon BitsOutPerSecon CountPerSecond Average Bits egressing No Dimensions

d d Azure per
second
Microsoft.Network/connections
BitsInPerSecond BitsInPerSecond CountPerSecond Average Bits ingressing No Dimensions

Azure per
second
BitsOutPerSecon BitsOutPerSecon CountPerSecond Average Bits egressing No Dimensions

d d Azure per
second
Microsoft.Network/trafficManagerProfiles
QpsByEndpoint Queries by Count Total Number of times EndpointName

Endpoint a Traffic Manager
Returned endpoint was
returned in the
given time frame
ProbeAgentCurr Endpoint Status Count Maximum 1 if an endpoint's EndpointName

entEndpointStat by Endpoint probe status is
eByProfileResour "Enabled", 0
ceId otherwise.
Microsoft.Network/networkWatchers/connectionMonitors
ProbesFailedPerc % Probes Failed Percent Average % of connectivity No Dimensions

ent monitoring
probes failed
AverageRoundtri Avg. Round-trip MilliSeconds Average Average network No Dimensions

pMs Time (ms) round-trip time
(ms) for
connectivity
monitoring
probes sent
between source
and destination
Microsoft.Network/frontdoors
RequestCount Request Count Count Total The number of HttpStatus,

client requests HttpStatusGroup
served by the , ClientRegion,
HTTP/S proxy ClientCountry
RequestSize Request Size Bytes Total The number of HttpStatus,

bytes sent as HttpStatusGroup
requests from , ClientRegion,
clients to the ClientCountry
HTTP/S proxy
ResponseSize Response Size Bytes Total The number of HttpStatus,

bytes sent as HttpStatusGroup
responses from , ClientRegion,
HTTP/S proxy to ClientCountry
clients
BackendRequest Backend Request Count Total The number of HttpStatus,

Count Count requests sent HttpStatusGroup
from the HTTP/S , Backend
proxy to
backends
BackendRequest Backend Request MilliSeconds Average The time Backend

Latency Latency calculated from
when the
request was sent
by the HTTP/S
proxy to the
backend until
the HTTP/S
proxy received
the last response
byte from the
backend
TotalLatency Total Latency MilliSeconds Average The time HttpStatus,

calculated from HttpStatusGroup
when the client , ClientRegion,
request was ClientCountry
received by the
HTTP/S proxy
until the client
acknowledged
the last response
byte from the
HTTP/S proxy
BackendHealthP Backend Health Percent Average The percentage Backend,

ercentage Percentage of successful BackendPool
health probes
from the HTTP/S
proxy to
backends
WebApplicationF Web Application Count Total The number of PolicyName,

irewallRequestCo Firewall Request client requests RuleName,
unt Count processed by the Action
Web Application
Firewall
Microsoft.NotificationHubs/Namespaces/NotificationHubs
registration.all Registration Count Total The count of all No Dimensions

Operations successful
registration
operations
(creations
updates queries
and deletions).
registration.creat Registration Count Total The count of all No Dimensions

e Create successful
Operations registration
creations.
registration.upda Registration Count Total The count of all No Dimensions

te Update successful
updates.
registration.get Registration Count Total The count of all No Dimensions

Read Operations successful
registration
queries.
registration.delet Registration Count Total The count of all No Dimensions

e Delete successful
deletions.
incoming Incoming Count Total The count of all No Dimensions

Messages successful send
API calls.
incoming.schedul Scheduled Push Count Total Scheduled Push No Dimensions

ed Notifications Notifications
Sent Canceled
incoming.schedul Scheduled Push Count Total Scheduled Push No Dimensions

ed.cancel Notifications Notifications
Canceled Canceled
scheduled.pendi Pending Count Total Pending No Dimensions

ng Scheduled Scheduled
Notifications Notifications
installation.all Installation Count Total Installation No Dimensions

Management Management
Operations Operations
installation.get Get Installation Count Total Get Installation No Dimensions

installation.upser Create or Count Total Create or No Dimensions

t Update Update
Installation Installation
installation.patch Patch Installation Count Total Patch Installation No Dimensions

installation.delet Delete Count Total Delete No Dimensions

e Installation Installation
outgoing.allpns.s Successful Count Total The count of all No Dimensions

uccess notifications successful
notifications.
outgoing.allpns.i Payload Errors Count Total The count of No Dimensions

nvalidpayload pushes that
failed because
the PNS
returned a bad
payload error.
outgoing.allpns.p External Count Total The count of No Dimensions

nserror Notification pushes that
System Errors failed because
there was a
problem
communicating
with the PNS
(excludes
authentication
problems).
outgoing.allpns.c Channel Errors Count Total The count of No Dimensions

hannelerror pushes that
failed because
the channel was
invalid not
associated with
the correct app
throttled or
expired.
outgoing.allpns.b Bad or Expired Count Total The count of No Dimensions

adorexpiredchan Channel Errors pushes that
nel failed because
the
channel/token/re
gistrationId in
the registration
was expired or
invalid.
outgoing.wns.su WNS Successful Count Total The count of all No Dimensions

ccess Notifications successful
notifications.
outgoing.wns.inv WNS Count Total The count of No Dimensions

alidcredentials Authorization pushes that
Errors (Invalid failed because
Credentials) the PNS did not
accept the
provided
credentials or
the credentials
are blocked.
(Windows Live
does not
recognize the
credentials).
outgoing.wns.ba WNS Bad Count Total The count of No Dimensions

dchannel Channel Error pushes that
failed because
the ChannelURI
in the
registration was
not recognized
(WNS status:
404 not found).
outgoing.wns.ex WNS Expired Count Total The count of No Dimensions

piredchannel Channel Error pushes that
failed because
the ChannelURI
is expired (WNS
status: 410
Gone).
outgoing.wns.thr WNS Throttled Count Total The count of No Dimensions

ottled Notifications pushes that
failed because
WNS is throttling
this app (WNS
status: 406 Not
Acceptable).
outgoing.wns.to WNS Count Total Windows Live is No Dimensions

kenproviderunre Authorization not reachable.
achable Errors
(Unreachable)
outgoing.wns.inv WNS Count Total The token No Dimensions

alidtoken Authorization provided to WNS
Errors (Invalid is not valid (WNS
Token) status: 401
Unauthorized).
outgoing.wns.wr WNS Count Total The token No Dimensions

ongtoken Authorization provided to WNS
Errors (Wrong is valid but for
Token) another
application (WNS
status: 403
Forbidden). This
can happen if
the ChannelURI
in the
registration is
associated with
another app.
Check that the
client app is
associated with
the same app
whose
credentials are in
the notification
hub.
outgoing.wns.inv WNS Invalid Count Total The format of No Dimensions

alidnotificationfo Notification the notification is
rmat Format invalid (WNS
status: 400).
Note that WNS
does not reject
all invalid
payloads.
outgoing.wns.inv WNS Invalid Count Total The notification No Dimensions

alidnotificationsiz Notification Size payload is too
e Error large (WNS
status: 413).
outgoing.wns.ch WNS Channel Count Total The notification No Dimensions

annelthrottled Throttled was dropped
because the
ChannelURI in
the registration
is throttled (WNS
response header:
X-WNS-
NotificationStatu
s:channelThrottle
d).
outgoing.wns.ch WNS Channel Count Total The notification No Dimensions

anneldisconnecte Disconnected was dropped
d because the
ChannelURI in
the registration
is throttled (WNS
response header:
X-WNS-
DeviceConnectio
nStatus:
disconnected).
outgoing.wns.dr WNS Dropped Count Total The notification No Dimensions

opped Notifications was dropped
because the
ChannelURI in
the registration
is throttled (X-
WNS-
NotificationStatu
s: dropped but
not X-WNS-
DeviceConnectio
nStatus:
disconnected).
outgoing.wns.pn WNS Errors Count Total Notification not No Dimensions

serror delivered
because of errors
communicating
with WNS.
outgoing.wns.au WNS Count Total Notification not No Dimensions

thenticationerror Authentication delivered
Errors because of errors
communicating
with Windows
Live invalid
credentials or
wrong token.
outgoing.apns.su APNS Successful Count Total The count of all No Dimensions

notifications.
outgoing.apns.in APNS Count Total The count of No Dimensions

validcredentials Authorization pushes that
Errors failed because
the PNS did not
accept the
provided
credentials or
the credentials
are blocked.
outgoing.apns.b APNS Bad Count Total The count of No Dimensions

adchannel Channel Error pushes that
failed because
the token is
invalid (APNS
binary protocol
status code: 8.
APNS HTTP
protocol status
code: 400 with
"BadDeviceToken
").
outgoing.apns.ex APNS Expired Count Total The count of No Dimensions

piredchannel Channel Error token that were
invalidated by
the APNS
feedback
channel.
outgoing.apns.in APNS Invalid Count Total The count of No Dimensions

validnotificationsi Notification Size pushes that
ze Error failed because
the payload was
too large (APNS
binary protocol
status code: 7).
outgoing.apns.p APNS Errors Count Total The count of No Dimensions

nserror pushes that
failed because of
errors
communicating
with APNS.
outgoing.gcm.su GCM Successful Count Total The count of all No Dimensions

notifications.
outgoing.gcm.in GCM Count Total The count of No Dimensions

validcredentials Authorization pushes that
Errors (Invalid failed because
Credentials) the PNS did not
accept the
provided
credentials or
the credentials
are blocked.
outgoing.gcm.ba GCM Bad Count Total The count of No Dimensions

dchannel Channel Error pushes that
failed because
the
registrationId in
the registration
was not
recognized
(GCM result:
Invalid
Registration).
outgoing.gcm.ex GCM Expired Count Total The count of No Dimensions

piredchannel Channel Error pushes that
failed because
the
registrationId in
the registration
was expired
(GCM result:
NotRegistered).
outgoing.gcm.th GCM Throttled Count Total The count of No Dimensions

rottled Notifications pushes that
failed because
GCM throttled
this app (GCM
status code:
501-599 or
result:Unavailabl
e).
outgoing.gcm.in GCM Invalid Count Total The count of No Dimensions

validnotificationf Notification pushes that
ormat Format failed because
the payload was
not formatted
correctly (GCM
result:
InvalidDataKey
or InvalidTtl).
outgoing.gcm.in GCM Invalid Count Total The count of No Dimensions

validnotificationsi Notification Size pushes that
ze Error failed because
the payload was
too large (GCM
result:
MessageTooBig).
outgoing.gcm.wr GCM Wrong Count Total The count of No Dimensions

ongchannel Channel Error pushes that
failed because
the
registrationId in
the registration
is not associated
to the current
app (GCM result:
InvalidPackageN
ame).
outgoing.gcm.pn GCM Errors Count Total The count of No Dimensions

serror pushes that
failed because of
errors
communicating
with GCM.
outgoing.gcm.au GCM Count Total The count of No Dimensions

thenticationerror Authentication pushes that
Errors failed because
the PNS did not
accept the
provided
credentials the
credentials are
blocked or the
SenderId is not
correctly
configured in the
app (GCM result:
MismatchedSend
erId).
outgoing.mpns.s MPNS Successful Count Total The count of all No Dimensions

uccess Notifications successful
notifications.
outgoing.mpns.i MPNS Invalid Count Total The count of No Dimensions

nvalidcredentials Credentials pushes that
failed because
the PNS did not
accept the
provided
credentials or
the credentials
are blocked.
outgoing.mpns.b MPNS Bad Count Total The count of No Dimensions

adchannel Channel Error pushes that
failed because
the ChannelURI
in the
registration was
not recognized
(MPNS status:
404 not found).
outgoing.mpns.t MPNS Throttled Count Total The count of No Dimensions

hrottled Notifications pushes that
failed because
MPNS is
throttling this
app (WNS
MPNS: 406 Not
Acceptable).
outgoing.mpns.i MPNS Invalid Count Total The count of No Dimensions

nvalidnotification Notification pushes that
format Format failed because
the payload of
the notification
was too large.
outgoing.mpns.c MPNS Channel Count Total The count of No Dimensions

hanneldisconnec Disconnected pushes that
ted failed because
the ChannelURI
in the
registration was
disconnected
(MPNS status:
412 not found).
outgoing.mpns.d MPNS Dropped Count Total The count of No Dimensions

ropped Notifications pushes that were
dropped by
MPNS (MPNS
response header:
X-
NotificationStatu
s: QueueFull or
Suppressed).
outgoing.mpns.p MPNS Errors Count Total The count of No Dimensions

nserror pushes that
failed because of
errors
communicating
with MPNS.
outgoing.mpns.a MPNS Count Total The count of No Dimensions

uthenticationerr Authentication pushes that
or Errors failed because
the PNS did not
accept the
provided
credentials or
the credentials
are blocked.
notificationhub.p All Outgoing Count Total All outgoing No Dimensions

ushes Notifications notifications of
the notification
hub
incoming.all.requ All Incoming Count Total Total incoming No Dimensions

ests Requests requests for a
notification hub
incoming.all.faile All Incoming Count Total Total incoming No Dimensions

drequests Failed Requests failed requests
for a notification
hub
Microsoft.OperationalInsights/workspaces
Average_% Free % Free Inodes Count Average Average_% Free Computer,

Inodes Inodes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Free % Free Space Count Average Average_% Free Computer,

Space Space ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Used % Used Inodes Count Average Average_% Used Computer,

Inodes Inodes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Used % Used Space Count Average Average_% Used Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Read Count Average Average_Disk Computer,

Read Bytes/sec Bytes/sec Read Bytes/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Reads/sec Count Average Average_Disk Computer,

Reads/sec Reads/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Count Average Average_Disk Computer,

Transfers/sec Transfers/sec Transfers/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Write Count Average Average_Disk Computer,

Write Bytes/sec Bytes/sec Write Bytes/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Writes/sec Count Average Average_Disk Computer,

Writes/sec Writes/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Free Free Megabytes Count Average Average_Free Computer,

Megabytes Megabytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Logical Logical Disk Count Average Average_Logical Computer,

Disk Bytes/sec Bytes/sec Disk Bytes/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% % Available Count Average Average_% Computer,

Available Memory Available ObjectName,
Memory Memory InstanceName,
CounterPath,
SourceSystem
Average_% % Available Swap Count Average Average_% Computer,

Available Swap Space Available Swap ObjectName,
Space Space InstanceName,
CounterPath,
SourceSystem
Average_% Used % Used Memory Count Average Average_% Used Computer,

Memory Memory ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Used % Used Swap Count Average Average_% Used Computer,

Swap Space Space Swap Space ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Availabl Available MBytes Count Average Average_Availabl Computer,

e MBytes Memory e MBytes ObjectName,
Memory Memory InstanceName,
CounterPath,
SourceSystem

e MBytes Swap Swap e MBytes Swap ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Page Page Reads/sec Count Average Average_Page Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Page Page Writes/sec Count Average Average_Page Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Pages/s Pages/sec Count Average Average_Pages/s Computer,

ec ec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Used Used MBytes Count Average Average_Used Computer,

MBytes Swap Swap Space MBytes Swap ObjectName,
Space Space InstanceName,
CounterPath,
SourceSystem
Average_Used Used Memory Count Average Average_Used Computer,

Memory MBytes MBytes Memory MBytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Total Total Bytes Count Average Average_Total Computer,

Bytes Transmitted Bytes ObjectName,
Transmitted Transmitted InstanceName,
CounterPath,
SourceSystem

Bytes Received Received Bytes Received ObjectName,
InstanceName,
CounterPath,
SourceSystem

Bytes Bytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Total Total Packets Count Average Average_Total Computer,

Packets Transmitted Packets ObjectName,
Transmitted Transmitted InstanceName,
CounterPath,
SourceSystem
Average_Total Total Packets Count Average Average_Total Computer,

Packets Received Received Packets Received ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Total Rx Total Rx Errors Count Average Average_Total Rx Computer,

Errors Errors ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Total Tx Total Tx Errors Count Average Average_Total Tx Computer,

Errors Errors ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Total Total Collisions Count Average Average_Total Computer,

Collisions Collisions ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Avg. Avg. Disk Count Average Average_Avg. Computer,

Disk sec/Read sec/Read Disk sec/Read ObjectName,
InstanceName,
CounterPath,
SourceSystem

Disk sec/Transfer sec/Transfer Disk sec/Transfer ObjectName,
InstanceName,
CounterPath,
SourceSystem

Disk sec/Write sec/Write Disk sec/Write ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Physical Physical Disk Count Average Average_Physical Computer,

Disk Bytes/sec Bytes/sec Disk Bytes/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Pct Pct Privileged Count Average Average_Pct Computer,

Privileged Time Time Privileged Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Pct Pct User Time Count Average Average_Pct Computer,

User Time User Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Used Used Memory Count Average Average_Used Computer,

Memory kBytes kBytes Memory kBytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Virtual Virtual Shared Count Average Average_Virtual Computer,

Shared Memory Memory Shared Memory ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% DPC % DPC Time Count Average Average_% DPC Computer,

Time Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Idle % Idle Time Count Average Average_% Idle Computer,

InstanceName,
CounterPath,
SourceSystem
Average_% % Interrupt Time Count Average Average_% Computer,

Interrupt Time Interrupt Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% IO % IO Wait Time Count Average Average_% IO Computer,

Wait Time Wait Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Nice % Nice Time Count Average Average_% Nice Computer,

InstanceName,
CounterPath,
SourceSystem
Average_% % Privileged Count Average Average_% Computer,

Privileged Time Time Privileged Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% % Processor Count Average Average_% Computer,

Processor Time Time Processor Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% User % User Time Count Average Average_% User Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Free Free Physical Count Average Average_Free Computer,

Physical Memory Memory Physical Memory ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Free Free Space in Count Average Average_Free Computer,

Space in Paging Paging Files Space in Paging ObjectName,
Files Files InstanceName,
CounterPath,
SourceSystem
Average_Free Free Virtual Count Average Average_Free Computer,

Virtual Memory Memory Virtual Memory ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Process Processes Count Average Average_Process Computer,

es es ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Size Size Stored In Count Average Average_Size Computer,

Stored In Paging Paging Files Stored In Paging ObjectName,
Files Files InstanceName,
CounterPath,
SourceSystem
Average_Uptime Uptime Count Average Average_Uptime Computer,

ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Users Users Count Average Average_Users Computer,

ObjectName,
InstanceName,
CounterPath,
SourceSystem

Disk sec/Read sec/Read Disk sec/Read ObjectName,
InstanceName,
CounterPath,
SourceSystem

Disk sec/Write sec/Write Disk sec/Write ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Current Current Disk Count Average Average_Current Computer,

Disk Queue Queue Length Disk Queue ObjectName,
Length Length InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Reads/sec Count Average Average_Disk Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Count Average Average_Disk Computer,

Transfers/sec Transfers/sec Transfers/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Disk Disk Writes/sec Count Average Average_Disk Computer,

InstanceName,
CounterPath,
SourceSystem
Average_Free Free Megabytes Count Average Average_Free Computer,

Megabytes Megabytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% Free % Free Space Count Average Average_% Free Computer,

InstanceName,
CounterPath,
SourceSystem

e MBytes e MBytes ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% % Committed Count Average Average_% Computer,

Committed Bytes In Use Committed ObjectName,
Bytes In Use Bytes In Use InstanceName,
CounterPath,
SourceSystem
Average_Bytes Bytes Count Average Average_Bytes Computer,

Received/sec Received/sec Received/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Bytes Bytes Sent/sec Count Average Average_Bytes Computer,

Sent/sec Sent/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Bytes Bytes Total/sec Count Average Average_Bytes Computer,

Total/sec Total/sec ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_% % Processor Count Average Average_% Computer,

Processor Time Time Processor Time ObjectName,
InstanceName,
CounterPath,
SourceSystem
Average_Process Processor Queue Count Average Average_Process Computer,

or Queue Length Length or Queue Length ObjectName,
InstanceName,
CounterPath,
SourceSystem
Heartbeat Heartbeat Count Total Heartbeat Computer,

OSType, Version,
SourceComputer
Id
Update Update Count Average Update Computer,

Product,
Classification,
UpdateState,
Optional,
Approved
Event Event Count Average Event Source,

EventLog,
Computer,
EventCategory,
EventLevel,
EventLevelName,
EventID
Microsoft.PowerBIDedicated/capacities
QueryDuration Query Duration Milliseconds Average DAX Query No Dimensions

duration in last
interval
QueryPoolJobQu Threads: Query Count Average Number of jobs No Dimensions

eueLength pool job queue in the queue of
length the query thread
pool.
qpu_high_utilizat QPU High Count Total QPU High No Dimensions

ion_metric Utilization Utilization In
Last Minute, 1
For High QPU
Utilization,
Otherwise 0
memory_metric Memory Bytes Average Memory. Range No Dimensions

0-3 GB for A1,
0-5 GB for A2,
0-10 GB for A3,
0-25 GB for A4,
0-50 GB for A5
and 0-100 GB
for A6
memory_thrashi Memory Percent Average Average No Dimensions

ng_metric Thrashing memory
thrashing.
Microsoft.Relay/namespaces
ListenerConnecti ListenerConnecti Count Total Successful EntityName

ons-Success ons-Success ListenerConnecti
ons for
Microsoft.Relay.
ListenerConnecti ListenerConnecti Count Total ClientError on EntityName

ons-ClientError ons-ClientError ListenerConnecti
ons for
Microsoft.Relay.
ListenerConnecti ListenerConnecti Count Total ServerError on EntityName

ons-ServerError ons-ServerError ListenerConnecti
ons for
Microsoft.Relay.
SenderConnectio SenderConnectio Count Total Successful EntityName

ns-Success ns-Success SenderConnectio
ns for
Microsoft.Relay.
SenderConnectio SenderConnectio Count Total ClientError on EntityName

ns-ClientError ns-ClientError SenderConnectio
ns for
Microsoft.Relay.
SenderConnectio SenderConnectio Count Total ServerError on EntityName

ns-ServerError ns-ServerError SenderConnectio
ns for
Microsoft.Relay.
ListenerConnecti ListenerConnecti Count Total Total EntityName

ons- ons- ListenerConnecti
TotalRequests TotalRequests ons for
Microsoft.Relay.
SenderConnectio SenderConnectio Count Total Total EntityName

ns-TotalRequests ns-TotalRequests SenderConnectio
ns requests for
Microsoft.Relay.
ActiveConnectio ActiveConnectio Count Total Total EntityName

ns ns ActiveConnectio
ns for
Microsoft.Relay.
ActiveListeners ActiveListeners Count Total Total EntityName

ActiveListeners
for
Microsoft.Relay.
BytesTransferred BytesTransferred Count Total Total EntityName

BytesTransferred
for
Microsoft.Relay.
ListenerDisconne ListenerDisconne Count Total Total EntityName

cts cts ListenerDisconne
cts for
Microsoft.Relay.
SenderDisconnec SenderDisconnec Count Total Total EntityName

ts ts SenderDisconnec
ts for
Microsoft.Relay.
Microsoft.Search/searchServices
SearchLatency Search Latency Seconds Average Average search No Dimensions

latency for the
search service
SearchQueriesPe Search queries CountPerSecond Average Search queries No Dimensions

rSecond per second per second for
the search
service
ThrottledSearch Throttled search Percent Average Percentage of No Dimensions

QueriesPercenta queries search queries
ge percentage that were
throttled for the
search service
Microsoft.ServiceBus/namespaces
SuccessfulReques Successful Count Total Total successful EntityName

ts Requests requests for a
(Preview) namespace
(Preview)
ServerErrors Server Errors. Count Total Server Errors for EntityName

(Preview) Microsoft.Service
Bus. (Preview)
UserErrors User Errors. Count Total User Errors for EntityName

Bus. (Preview)
ThrottledRequest Throttled Count Total Throttled EntityName

Bus. (Preview)
IncomingReques Incoming Count Total Incoming EntityName

Bus. (Preview)
IncomingMessag Incoming Count Total Incoming EntityName

Bus. (Preview)
OutgoingMessa Outgoing Count Total Outgoing EntityName

Bus. (Preview)
ActiveConnectio ActiveConnectio Count Total Total Active No Dimensions

ns ns (Preview) Connections for
Microsoft.Service
Bus. (Preview)
Size Size (Preview) Bytes Average Size of an EntityName

Queue/Topic in
Bytes. (Preview)
Messages Count of Count Average Count of EntityName

messages in a messages in a
Queue/Topic. Queue/Topic.
(Preview) (Preview)
ActiveMessages Count of active Count Average Count of active EntityName

(Preview) (Preview)
DeadletteredMes Count of dead- Count Average Count of dead- EntityName

sages lettered lettered
(Preview) (Preview)
ScheduledMessa Count of Count Average Count of EntityName

ges scheduled scheduled
(Preview) (Preview)
CPUXNS CPU usage per Percent Maximum Service bus No Dimensions

namespace premium
namespace CPU
usage metric
WSXNS Memory size Percent Maximum Service bus No Dimensions

usage per premium
namespace namespace
memory usage
metric
Microsoft.ServiceFabricMesh/applications
AllocatedCpu AllocatedCpu Count Average Cpu allocated to ApplicationName

this container in , ServiceName,
millicores CodePackageNa
me,
ServiceReplicaNa
me
AllocatedMemor AllocatedMemor Bytes Average Memory ApplicationName

y y allocated to this , ServiceName,
container in MB CodePackageNa
me,
ServiceReplicaNa
me
ActualCpu ActualCpu Count Average Actual CPU ApplicationName

usage in , ServiceName,
millicores CodePackageNa
me,
ServiceReplicaNa
me
ActualMemory ActualMemory Bytes Average Actual memory ApplicationName

usage in MB , ServiceName,
CodePackageNa
me,
ServiceReplicaNa
me
CpuUtilization CpuUtilization Percent Average Utilization of ApplicationName

CPU for this , ServiceName,
container as CodePackageNa
percentage of me,
AllocatedCpu ServiceReplicaNa
me
MemoryUtilizatio MemoryUtilizatio Percent Average Utilization of ApplicationName

n n CPU for this , ServiceName,
container as CodePackageNa
percentage of me,
AllocatedCpu ServiceReplicaNa
me
ApplicationStatu ApplicationStatu Count Average Status of Service ApplicationName

s s Fabric Mesh , Status
application
ServiceStatus ServiceStatus Count Average Health Status of ApplicationName

a service in , Status,
Service Fabric ServiceName
Mesh application
ServiceReplicaSta ServiceReplicaSta Count Average Health Status of ApplicationName

tus tus a service replica , Status,
in Service Fabric ServiceName,
Mesh application ServiceReplicaNa
me
ContainerStatus ContainerStatus Count Average Status of the ApplicationName

container in , ServiceName,
Service Fabric CodePackageNa
Mesh application me,
ServiceReplicaNa
me, Status
RestartCount RestartCount Count Average Restart count of ApplicationName

a container in , Status,
Service Fabric ServiceName,
Mesh application ServiceReplicaNa
me,
CodePackageNa
me
Microsoft.SignalRService/SignalR
ConnectionCoun Connection Count Maximum The amount of Endpoint

t Count user connection.
MessageCount Message Count Count Total The total No Dimensions

amount of
messages.
InboundTraffic Inbound Traffic Bytes Total The inbound No Dimensions

traffic of service
OutboundTraffic Outbound Traffic Bytes Total The outbound No Dimensions

traffic of service
UserErrors User Errors Percent Maximum The percentage No Dimensions

of user errors
SystemErrors System Errors Percent Maximum The percentage No Dimensions

of system errors
Microsoft.Sql/servers/databases
cpu_percent CPU percentage Percent Average CPU percentage No Dimensions
physical_data_re Data IO Percent Average Data IO No Dimensions

ad_percent percentage percentage
log_write_percen Log IO Percent Average Log IO No Dimensions

t percentage percentage. Not
applicable to
data
warehouses.
dtu_consumptio DTU percentage Percent Average DTU percentage. No Dimensions

n_percent Applies to DTU-
based databases.
storage Data space used Bytes Maximum Total database No Dimensions

size. Not
applicable to
data
warehouses.
connection_succ Successful Count Total Successful No Dimensions

essful Connections Connections
connection_failed Failed Count Total Failed No Dimensions

Connections Connections
blocked_by_firew Blocked by Count Total Blocked by No Dimensions

all Firewall Firewall
deadlock Deadlocks Count Total Deadlocks. Not No Dimensions

applicable to
data
warehouses.
storage_percent Data space used Percent Maximum Database size No Dimensions

percent percentage. Not
applicable to
data warehouses
or hyperscale
databases.
xtp_storage_perc In-Memory Percent Average In-Memory No Dimensions

ent OLTP storage OLTP storage
percent percent. Not
applicable to
data
warehouses.
workers_percent Workers Percent Average Workers No Dimensions

percentage percentage. Not
applicable to
data
warehouses.
sessions_percent Sessions Percent Average Sessions No Dimensions

percentage percentage. Not
applicable to
data
warehouses.
dtu_limit DTU Limit Count Average DTU Limit. No Dimensions

Applies to DTU-
based databases.
dtu_used DTU used Count Average DTU used. No Dimensions

Applies to DTU-
based databases.
cpu_limit CPU limit Count Average CPU limit. No Dimensions

Applies to
vCore-based
databases.
cpu_used CPU used Count Average CPU used. No Dimensions

Applies to
vCore-based
databases.
dwu_limit DWU limit Count Maximum DWU limit. No Dimensions

Applies only to
data
warehouses.
dwu_consumptio DWU percentage Percent Maximum DWU No Dimensions

n_percent percentage.
Applies only to
data
warehouses.
dwu_used DWU used Count Maximum DWU used. No Dimensions

Applies only to
data
warehouses.
dw_cpu_percent DW node level Percent Average DW node level DwLogicalNodeI

CPU percentage CPU percentage d
dw_physical_data DW node level Percent Average DW node level DwLogicalNodeI

_read_percent Data IO Data IO d
percentage percentage
cache_hit_percen Cache hit Percent Maximum Cache hit No Dimensions

t percentage percentage.
Applies only to
data
warehouses.
cache_used_perc Cache used Percent Maximum Cache used No Dimensions

ent percentage percentage.
Applies only to
data
warehouses.
local_tempdb_us Local tempdb Percent Average Local tempdb No Dimensions

age_percent percentage percentage.
Applies only to
data
warehouses.
app_cpu_billed App CPU billed Count Total App CPU billed. No Dimensions
Applies to
serverless
databases.
app_cpu_percent App CPU Percent Average App CPU No Dimensions

percentage percentage.
Applies to
serverless
databases.
app_memory_pe App memory Percent Average App memory No Dimensions

rcent used percentage used percentage.
Applies to
serverless
databases.
allocated_data_st Data space Bytes Average Data space No Dimensions

orage allocated allocated. Not
applicable to
data
warehouses.
Microsoft.Sql/servers/elasticPools
METRIC AGGREGATION
METRIC DISPLAY NAME UNIT TYPE DESCRIPTION DIMENSIONS
cpu_percent CPU Percent Average CPU No

percentage percentage Dimensions
physical_data Data IO Percent Average Data IO No

_read_percent percentage percentage Dimensions
log_write_per Log IO Percent Average Log IO No

cent percentage percentage Dimensions
dtu_consump DTU Percent Average DTU No

tion_percent percentage percentage. Dimensions
Applies to
DTU-based
elastic pools.
storage_perce Data space Percent Average Storage No

nt used percent percentage Dimensions
workers_perc Workers Percent Average Workers No

ent percentage percentage Dimensions
sessions_perc Sessions Percent Average Sessions No

ent percentage percentage Dimensions
eDTU_limit eDTU limit Count Average eDTU limit. No

Applies to Dimensions
DTU-based
elastic pools.
storage_limit Data max size Bytes Average Storage limit No

Dimensions
eDTU_used eDTU used Count Average eDTU used. No

DTU-based
elastic pools.
storage_used Data space Bytes Average Storage used No

used Dimensions
xtp_storage_p In-Memory Percent Average In-Memory No

ercent OLTP storage OLTP storage Dimensions
percent percent
METRIC AGGREGATION
METRIC DISPLAY NAME UNIT TYPE DESCRIPTION DIMENSIONS
cpu_limit CPU limit Count Average CPU limit. No

vCore-based
elastic pools.
cpu_used CPU used Count Average CPU used. No

vCore-based
elastic pools.
allocated_dat Data space Bytes Average Data space No

a_storage allocated allocated Dimensions
allocated_dat Data space Percent Maximum Data space No

a_storage_per allocated allocated Dimensions
cent percent percent
Microsoft.Sql/managedInstances
virtual_core_cou Virtual core Count Average Virtual core No Dimensions

nt count count
avg_cpu_percent Average CPU Percent Average Average CPU No Dimensions

percentage percentage
reserved_storage Storage space Count Average Storage space No Dimensions

_mb reserved reserved
storage_space_u Storage space Count Average Storage space No Dimensions

sed_mb used used
io_requests IO requests Count Average IO requests No Dimensions

count count
io_bytes_read IO bytes read Bytes Average IO bytes read No Dimensions
io_bytes_written IO bytes written Bytes Average IO bytes written No Dimensions
Microsoft.Storage/storageAccounts
UsedCapacity Used capacity Bytes Average Account used No Dimensions

capacity
Transactions Transactions Count Total The number of ResponseType,

requests made GeoType,
to a storage ApiName,
service or the Authentication
specified API
operation. This
number includes
successful and
failed requests,
as well as
requests which
produced errors.
Use
ResponseType
dimension for
the number of
different type of
response.
Ingress Ingress Bytes Total The amount of GeoType,

ingress data, in ApiName,
bytes. This Authentication
number includes
ingress from an
external client
into Azure
Storage as well
as ingress within
Azure.
Egress Egress Bytes Total The amount of GeoType,

egress data, in ApiName,
number includes
egress from an
external client
into Azure
Storage as well
as egress within
Azure. As a
result, this
number does
not reflect
billable egress.
SuccessServerLat Success Server Milliseconds Average The average GeoType,

ency Latency latency used by ApiName,
Azure Storage to Authentication
process a
successful
request, in
milliseconds. This
value does not
include the
network latency
specified in
AverageE2ELate
ncy.
SuccessE2ELaten Success E2E Milliseconds Average The average GeoType,

cy Latency end-to-end ApiName,
latency of Authentication
successful
requests made
to a storage
service or the
specified API
operation, in
milliseconds. This
value includes
the required
processing time
within Azure
Storage to read
the request,
send the
response, and
receive
acknowledgment
of the response.
Availability Availability Percent Average The percentage GeoType,

of availability for ApiName,
the storage Authentication
service or the
specified API
operation.
Availability is
calculated by
taking the
TotalBillableRequ
ests value and
dividing it by the
number of
applicable
requests,
including those
that produced
unexpected
errors. All
unexpected
errors result in
reduced
availability for
the storage
service or the
specified API
operation.
METR
IC
DISPL AGG
AY REGA DESC DIME
METR NAM TION RIPTI NSIO
IC E UNIT TYPE ON NS
Blob Blob Bytes Aver The Blob

Capa Capa age amo Type,
city city unt Tier
of
stora
ge
used
by
the
stora
ge
acco
unt’s
Blob
servi
ce in
bytes
.
Blob Blob Coun Total The Blob Blob Blob Coun Aver The BlobT
Coun Coun t num Type Coun Coun t age num ype,
t t ber t t ber Tier
of of
Blob Blob
in in
the the
stora stora
ge ge
acco acco
unt’s unt’s
Blob Blob
servi servic
ce. e.
Cont Blob Coun Aver The No

ainer Cont t age num Dime
Coun ainer ber nsion
t Coun of s
t cont
ainer
s in
the
stora
ge
acco
unt’s
Blob
servi
ce.
METR
IC
DISPL AGG
AY REGA DESC DIME
Index Index Bytes Aver The No

Capa Capa age amo Dime
city city unt nsion
of s
stora
ge
used
by
ADLS
Gen2
(Hier
archi
cal)
Index
in
bytes
.
METR
IC
DISPL AGG
AY REGA DESC DIME
Trans Trans Coun Total The Resp

actio actio t num onse
ns ns ber Type,
of GeoT
requ ype,
ests ApiN
mad ame,
e to Auth
a entic
stora ation
ge
servi
ce or
the
speci
fied
API
oper
ation
. This
num
ber
inclu
des
succe
ssful
and
failed
requ
ests,
as
well
as
requ
ests
whic
h
prod
uced
error
s.
Use
Resp
onse
Type
dime
nsion
for
the
num
ber
of
differ
ent
type
of
resp
onse.
METR
Ingre Ingre
IC Bytes Total The GeoT
ss ss
DISPL AGG amo ype,
AY REGA unt
DESC ApiN
DIME
METR NAM TION RIPTI
of NSIO
ame,
ingre Auth
ss entic
data, ation
in
bytes
. This
num
ber
inclu
des
ingre
ss
from
an
exter
nal
client
into
Azur
e
Stora
ge as
well
as
ingre
ss
withi
n
Azur
e.
METR
IC
DISPL AGG
AY REGA DESC DIME
Egres Egres Bytes Total The GeoT

s s amo ype,
unt ApiN
of ame,
egres Auth
s entic
data, ation
in
bytes
. This
num
ber
inclu
des
egres
s
from
an
exter
nal
client
into
Azur
e
Stora
ge as
well
as
egres
s
withi
n
Azur
e. As
a
resul
t,
this
num
ber
does
not
reflec
t
billab
le
egres
s.
METR
IC
DISPL AGG
AY REGA DESC DIME
Succ Succ Millis Aver The GeoT

essSe ess econ age avera ype,
rverL Serve ds ge ApiN
atenc r laten ame,
y Late cy Auth
ncy used entic
by ation
Azur
e
Stora
ge to
proc
ess a
succe
ssful
requ
est,
in
millis
econ
ds.
This
value
does
not
inclu
de
the
netw
ork
laten
cy
speci
fied
in
Aver
ageE
2ELa
tency
.
Succ Succ Millis Aver The GeoT

essE ess econ age avera ype,
2ELa E2E ds ge ApiN
tency Late end- ame,
ncy to- Auth
end entic
laten ation
cy of
succe
ssful
requ
ests
mad
e to
a
stora
ge
servi
METR
IC ce or
DISPL AGG the
AY REGA speci
DESC DIME
METR NAM TION RIPTI
fied NSIO
API
oper
ation
, in
millis
econ
ds.
This
value
inclu
des
the
requi
red
proc
essin
g
time
withi
n
Azur
e
Stora
ge to
read
the
requ
est,
send
the
resp
onse,
and
recei
ve
ackn
owle
dgm
ent
of
the
resp
onse.
Avail Avail Perce Aver The GeoT

abilit abilit nt age perce ype,
y y ntag ApiN
e of ame,
avail Auth
abilit entic
y for ation
the
stora
ge
servi
ce or
the
speci
fied
API
oper
METR
IC ation
DISPL AGG .
AY REGA Avail
DESC DIME
METR NAM TION RIPTI
abilit NSIO
y is
calcul
ated
by
takin
g the
Total
Billab
leReq
uests
value
and
dividi
ng it
by
the
num
ber
of
appli
cable
requ
ests,
inclu
ding
thos
e
that
prod
uced
unex
pecte
d
error
s. All
unex
pecte
d
error
s
resul
t in
redu
ced
avail
abilit
y for
the
stora
ge
servi
ce or
the
speci
fied
API
oper
ation
.
Microsoft.Storage/storageAccounts/fileServices
FileCapacity File Capacity Bytes Average The amount of No Dimensions

storage used by
the storage
account’s File
service in bytes.
FileCount File Count Count Average The number of No Dimensions

file in the
storage
account’s File
service.
FileShareCount File Share Count Count Average The number of No Dimensions

file shares in the
storage
account’s File
service.

specified API
operation. This
number includes
successful and
failed requests,
as well as
requests which
produced errors.
Use
ResponseType
dimension for
the number of
different type of
response.

number includes
ingress from an
external client
into Azure
Storage as well
as ingress within
Azure.

number includes
egress from an
external client
into Azure
Storage as well
as egress within
Azure. As a
result, this
number does
not reflect
billable egress.

process a
successful
request, in
milliseconds. This
value does not
include the
network latency
specified in
AverageE2ELate
ncy.

successful
requests made
to a storage
service or the
specified API
operation, in
milliseconds. This
value includes
the required
processing time
within Azure
Storage to read
the request,
send the
response, and
receive
acknowledgment
of the response.

service or the
specified API
operation.
Availability is
calculated by
taking the
TotalBillableRequ
ests value and
dividing it by the
number of
applicable
requests,
including those
that produced
unexpected
errors. All
unexpected
errors result in
reduced
availability for
the storage
service or the
specified API
operation.
Microsoft.Storage/storageAccounts/queueServices
QueueCapacity Queue Capacity Bytes Average The amount of No Dimensions

storage used by
the storage
account’s Queue
service in bytes.
QueueCount Queue Count Count Average The number of No Dimensions

queue in the
storage
account’s Queue
service.
QueueMessageC Queue Message Count Average The approximate No Dimensions

ount Count number of
queue messages
in the storage
account’s Queue
service.

specified API
operation. This
number includes
successful and
failed requests,
as well as
requests which
produced errors.
Use
ResponseType
dimension for
the number of
different type of
response.

number includes
ingress from an
external client
into Azure
Storage as well
as ingress within
Azure.

number includes
egress from an
external client
into Azure
Storage as well
as egress within
Azure. As a
result, this
number does
not reflect
billable egress.

process a
successful
request, in
milliseconds. This
value does not
include the
network latency
specified in
AverageE2ELate
ncy.

successful
requests made
to a storage
service or the
specified API
operation, in
milliseconds. This
value includes
the required
processing time
within Azure
Storage to read
the request,
send the
response, and
receive
acknowledgment
of the response.

service or the
specified API
operation.
Availability is
calculated by
taking the
TotalBillableRequ
ests value and
dividing it by the
number of
applicable
requests,
including those
that produced
unexpected
errors. All
unexpected
errors result in
reduced
availability for
the storage
service or the
specified API
operation.
Microsoft.Storage/storageAccounts/tableServices
TableCapacity Table Capacity Bytes Average The amount of No Dimensions

storage used by
the storage
account’s Table
service in bytes.
TableCount Table Count Count Average The number of No Dimensions

table in the
storage
account’s Table
service.
TableEntityCount Table Entity Count Average The number of No Dimensions

Count table entities in
the storage
account’s Table
service.

specified API
operation. This
number includes
successful and
failed requests,
as well as
requests which
produced errors.
Use
ResponseType
dimension for
the number of
different type of
response.

number includes
ingress from an
external client
into Azure
Storage as well
as ingress within
Azure.

number includes
egress from an
external client
into Azure
Storage as well
as egress within
Azure. As a
result, this
number does
not reflect
billable egress.

process a
successful
request, in
milliseconds. This
value does not
include the
network latency
specified in
AverageE2ELate
ncy.

successful
requests made
to a storage
service or the
specified API
operation, in
milliseconds. This
value includes
the required
processing time
within Azure
Storage to read
the request,
send the
response, and
receive
acknowledgment
of the response.

service or the
specified API
operation.
Availability is
calculated by
taking the
TotalBillableRequ
ests value and
dividing it by the
number of
applicable
requests,
including those
that produced
unexpected
errors. All
unexpected
errors result in
reduced
availability for
the storage
service or the
specified API
operation.
microsoft.storagesync/storageSyncServices
ServerSyncSessio Sync Session Count Average Metric that logs SyncGroupName,

nResult Result a value of 1 each ServerEndpointN
time the Server ame,
Endpoint SyncDirection
successfully
completes a Sync
Session with the
Cloud Endpoint
StorageSyncSync Files Synced Count Total Count of Files SyncGroupName,

SessionAppliedFil synced ServerEndpointN
esCount ame,
SyncDirection
StorageSyncSync Files not syncing Count Total Count of files SyncGroupName,

SessionPerItemEr failed to sync ServerEndpointN
rorsCount ame,
SyncDirection
StorageSyncBatc Bytes synced Bytes Total Total file size SyncGroupName,

hTransferredFileB transferred for ServerEndpointN
ytes Sync Sessions ame,
SyncDirection
StorageSyncServ Server Online Count Maximum Metric that logs ServerName

erHeartbeat Status a value of 1 each
time the
registered server
successfully
records a
heartbeat with
the Cloud
Endpoint
StorageSyncReca Cloud tiering Bytes Total Total size of data ServerName

llIOTotalSizeByte recall recalled by the
s server
Microsoft.StreamAnalytics/streamingjobs
ResourceUtilizati SU % Utilization Percent Maximum SU % Utilization LogicalName,

on PartitionId
InputEvents Input Events Count Total Input Events LogicalName,

PartitionId
InputEventBytes Input Event Bytes Total Input Event LogicalName,

Bytes Bytes PartitionId
LateInputEvents Late Input Count Total Late Input LogicalName,

Events Events PartitionId
OutputEvents Output Events Count Total Output Events LogicalName,

PartitionId
ConversionErrors Data Conversion Count Total Data Conversion LogicalName,

Errors Errors PartitionId
Errors Runtime Errors Count Total Runtime Errors LogicalName,

PartitionId
DroppedOrAdjus Out of order Count Total Out of order LogicalName,

tedEvents Events Events PartitionId
AMLCalloutRequ Function Count Total Function LogicalName,

ests Requests Requests PartitionId
AMLCalloutFaile Failed Function Count Total Failed Function LogicalName,

dRequests Requests Requests PartitionId
AMLCalloutInput Function Events Count Total Function Events LogicalName,

Events PartitionId
DeserializationErr Input Count Total Input LogicalName,

or Deserialization Deserialization PartitionId
Errors Errors
EarlyInputEvents Early Input Count Total Early Input LogicalName,

Events Events PartitionId
OutputWaterma Watermark Seconds Maximum Watermark LogicalName,

rkDelaySeconds Delay Delay PartitionId
InputEventsSour Backlogged Count Maximum Backlogged LogicalName,

cesBacklogged Input Events Input Events PartitionId
InputEventsSour Input Sources Count Total Input Sources LogicalName,

cesPerSecond Received Received PartitionId
Microsoft.TimeSeriesInsights/environments
IngressReceived Ingress Received Count Total Count of No Dimensions

Messages Messages messages read
from all Event
hub or IoT hub
event sources
IngressReceivedI Ingress Received Count Total Count of invalid No Dimensions

nvalidMessages Invalid Messages messages read
from all Event
hub or IoT hub
event sources
IngressReceivedB Ingress Received Bytes Total Count of bytes No Dimensions

ytes Bytes read from all
event sources
IngressStoredByt Ingress Stored Bytes Total Total size of No Dimensions

es Bytes events
successfully
processed and
available for
query
IngressStoredEve Ingress Stored Count Total Count of No Dimensions

nts Events flattened events
successfully
processed and
available for
query
IngressReceived Ingress Received Seconds Maximum Difference No Dimensions

MessagesTimeLa Messages Time between the
g Lag time that the
message is
enqueued in the
event source and
the time it is
processed in
Ingress
IngressReceived Ingress Received Count Average Difference No Dimensions

MessagesCountL Messages Count between the
ag Lag sequence
number of last
enqueued
message in the
event source
partition and
sequence
number of
message being
processed in
Ingress
WarmStorageMa Warm Storage Count Maximum Maximum No Dimensions

xProperties Max Properties number of
properties used
allowed by the
environment for
S1/S2 SKU and
maximum
number of
properties
allowed by
Warm Store for
PAYG SKU
WarmStorageUs Warm Storage Count Maximum Number of No Dimensions

edProperties Used Properties properties used
by the
environment for
S1/S2 SKU and
number of
properties used
by Warm Store
for PAYG SKU
Microsoft.TimeSeriesInsights/environments/eventsources
IngressReceived Ingress Received Count Total Count of No Dimensions

Messages Messages messages read
from the event
source
IngressReceivedI Ingress Received Count Total Count of invalid No Dimensions

nvalidMessages Invalid Messages messages read
from the event
source
IngressReceivedB Ingress Received Bytes Total Count of bytes No Dimensions

ytes Bytes read from the
event source
IngressStoredByt Ingress Stored Bytes Total Total size of No Dimensions

es Bytes events
successfully
processed and
available for
query
IngressStoredEve Ingress Stored Count Total Count of No Dimensions

nts Events flattened events
successfully
processed and
available for
query
IngressReceived Ingress Received Seconds Maximum Difference No Dimensions

MessagesTimeLa Messages Time between the
g Lag time that the
message is
enqueued in the
event source and
the time it is
processed in
Ingress
IngressReceived Ingress Received Count Average Difference No Dimensions

MessagesCountL Messages Count between the
ag Lag sequence
number of last
enqueued
message in the
event source
partition and
sequence
number of
message being
processed in
Ingress
WarmStorageMa Warm Storage Count Maximum Maximum No Dimensions

xProperties Max Properties number of
properties used
allowed by the
environment for
S1/S2 SKU and
maximum
number of
properties
allowed by
Warm Store for
PAYG SKU
WarmStorageUs Warm Storage Count Maximum Number of No Dimensions

edProperties Used Properties properties used
by the
environment for
S1/S2 SKU and
number of
properties used
by Warm Store
for PAYG SKU
Microsoft.VMwareCloudSimple/virtualMachines
DiskReadBytesPe Disk Read BytesPerSecond Average Average disk No Dimensions

rSecond Bytes/Sec throughput due
to read
operations over
the sample
period.
DiskWriteBytesP Disk Write BytesPerSecond Average Average disk No Dimensions

erSecond Bytes/Sec throughput due
to write
operations over
the sample
period.
Disk Read Bytes Disk Read Bytes Bytes Total Total disk No Dimensions
throughput due
to read
operations over
the sample
period.
Disk Write Bytes Disk Write Bytes Bytes Total Total disk No Dimensions
throughput due
to write
operations over
the sample
period.
DiskReadOperati Disk Read Count Total The number of No Dimensions

ons Operations IO read
operations in the
previous sample
period. Note that
these operations
may be variable
sized.
DiskWriteOperati Disk Write Count Total The number of No Dimensions

ons Operations IO write
operations in the
previous sample
period. Note that
these operations
may be variable
sized.
Disk Read Disk Read CountPerSecond Average The average No Dimensions

Operations/Sec Operations/Sec number of IO
read operations
in the previous
sample period.
Note that these
operations may
be variable sized.
Disk Write Disk Write CountPerSecond Average The average No Dimensions

Operations/Sec Operations/Sec number of IO
write operations
in the previous
sample period.
Note that these
operations may
be variable sized.
DiskReadLatency Disk Read Milliseconds Average Total read No Dimensions

Latency latency. The sum
of the device and
kernel read
latencies.
DiskWriteLatenc Disk Write Milliseconds Average Total write No Dimensions

y Latency latency. The sum
of the device and
kernel write
latencies.
NetworkInBytesP Network In BytesPerSecond Average Average network No Dimensions

erSecond Bytes/Sec throughput for
received traffic.
NetworkOutByte Network Out BytesPerSecond Average Average network No Dimensions

sPerSecond Bytes/Sec throughput for
transmitted
traffic.
Network In Network In Bytes Total Total network No Dimensions

throughput for
received traffic.
Network Out Network Out Bytes Total Total network No Dimensions

throughput for
transmitted
traffic.
MemoryUsed Memory Used Bytes Average The amount of No Dimensions

machine
memory that is
in use by the
VM.
MemoryGranted Memory Bytes Average The amount of No Dimensions

Granted memory that
was granted to
the VM by the
host. Memory is
not granted to
the host until it
is touched one
time and
granted memory
may be swapped
out or ballooned
away if the
VMkernel needs
the memory.
MemoryActive Memory Active Bytes Average The amount of No Dimensions

memory used by
the VM in the
past small
window of time.
This is the "true"
number of how
much memory
the VM currently
has need of.
Additional,
unused memory
may be swapped
out or ballooned
with no impact
to the guest's
performance.
Percentage CPU Percentage CPU Percent Average The CPU No Dimensions

utilization. This
value is reported
with 100%
representing all
processor cores
on the system.
As an example, a
2-way VM using
50% of a four-
core system is
completely using
two cores.
PercentageCpuR Percentage CPU Milliseconds Total Ready time is the No Dimensions

eady Ready time spend
waiting for
CPU(s) to
become available
in the past
update interval.
Microsoft.Web/serverfarms
CpuPercentage CPU Percentage Percent Average CPU Percentage Instance
MemoryPercenta Memory Percent Average Memory Instance

ge Percentage Percentage
DiskQueueLengt Disk Queue Count Average Disk Queue Instance

h Length Length
HttpQueueLengt Http Queue Count Average Http Queue Instance

h Length Length
BytesReceived Data In Bytes Total Data In Instance
BytesSent Data Out Bytes Total Data Out Instance
Microsoft.Web/sites (excluding functions)

CpuTime CPU Time Seconds Total CPU Time Instance
Requests Requests Count Total Requests Instance

Http101 Http 101 Count Total Http 101 Instance
Http2xx Http 2xx Count Total Http 2xx Instance
Http5xx Http Server Count Total Http Server Instance

Errors Errors
MemoryWorking Memory working Bytes Average Memory working Instance

Set set set
AverageMemory Average Bytes Average Average Instance

WorkingSet memory working memory working
set set
AverageRespons Average Seconds Average Average Instance

eTime Response Time Response Time
AppConnections Connections Count Average Connections Instance
Handles Handle Count Count Average Handle Count Instance
Threads Thread Count Count Average Thread Count Instance
PrivateBytes Private Bytes Bytes Average Private Bytes Instance
IoReadBytesPerS IO Read Bytes BytesPerSecond Total IO Read Bytes Instance

econd Per Second Per Second
IoWriteBytesPerS IO Write Bytes BytesPerSecond Total IO Write Bytes Instance

IoOtherBytesPer IO Other Bytes BytesPerSecond Total IO Other Bytes Instance

Second Per Second Per Second
IoReadOperation IO Read BytesPerSecond Total IO Read Instance

sPerSecond Operations Per Operations Per
Second Second
IoWriteOperatio IO Write BytesPerSecond Total IO Write Instance

nsPerSecond Operations Per Operations Per
Second Second
IoOtherOperatio IO Other BytesPerSecond Total IO Other Instance

Second Second
RequestsInApplic Requests In Count Average Requests In Instance

ationQueue Application Application
Queue Queue
CurrentAssembli Current Count Average Current Instance

es Assemblies Assemblies
TotalAppDomain Total App Count Average Total App Instance

s Domains Domains

sUnloaded Domains Domains
Unloaded Unloaded
Gen0Collections Gen 0 Garbage Count Total Gen 0 Garbage Instance

Collections Collections


Microsoft.Web/sites (functions)

Errors Errors

Set set set

set set
FunctionExecutio Function MB / Total Function Instance

nUnits Execution Units Milliseconds Execution Units
FunctionExecutio Function Count Total Function Instance

nCount Execution Count Execution Count




Second Second

Second Second

Second Second

Queue Queue


s Domains Domains

Unloaded Unloaded



Microsoft.Web/sites/slots
CpuTime CPU Time Seconds Total CPU Time Instance

Errors Errors

Set set set

set set


nUnits Execution Units Execution Units

nCount Execution Count Execution Count
AppConnections Connections Count Average Connections Instance
Handles Handle Count Count Average Handle Count Instance
Threads Thread Count Count Average Thread Count Instance





Second Second

Second Second

Second Second

Queue Queue


s Domains Domains

Unloaded Unloaded



Microsoft.Web/hostingEnvironments/multiRolePools


Errors Errors


DiskQueueLengt Disk Queue Count Average Disk Queue Instance

h Length Length
HttpQueueLengt Http Queue Count Average Http Queue Instance

h Length Length
ActiveRequests Active Requests Count Total Active Requests Instance
TotalFrontEnds Total Front Ends Count Average Total Front Ends No Dimensions
SmallAppService Small App Count Average Small App No Dimensions

PlanInstances Service Plan Service Plan
Workers Workers
MediumAppServi Medium App Count Average Medium App No Dimensions

cePlanInstances Service Plan Service Plan
Workers Workers
LargeAppService Large App Count Average Large App No Dimensions

PlanInstances Service Plan Service Plan
Workers Workers
Microsoft.Web/hostingEnvironments/workerPools
WorkersTotal Total Workers Count Average Total Workers No Dimensions
WorkersAvailable Available Count Average Available No Dimensions

Workers Workers
WorkersUsed Used Workers Count Average Used Workers No Dimensions

Next steps
Read about metrics in Azure Monitor
Create alerts on metrics
Export metrics to storage, Event Hub, or Log Analytics
Supported resources for metric alerts in Azure
Monitor
Azure Monitor now supports a new metric alert type which has significant benefits over the older classic metric
alerts. Metrics are available for large list of Azure services. The newer alerts support a (growing) subset of the
resource types. This article lists that subset.
You can also use newer metric alerts on popular log data stored in a Log Analytics workspace extracted as metrics.
For more information, view Metric Alerts for Logs.
Portal, PowerShell, CLI, REST support

Currently, you can create newer metric alerts only in the Azure portal, REST API, or Resource Manager Templates.
Support for configuring newer alerts using PowerShell and Azure CLI versions 2.0 and higher is coming soon.
Metrics and Dimensions Supported

Newer metric alerts support alerting for metrics that use dimensions. You can use dimensions to filter your metric
to the right level. All supported metrics along with applicable dimensions can be explored and visualized from
Azure Monitor - Metrics Explorer.
Here's the full list of Azure monitor metric sources supported by the newer alerts:
RESOURCE TYPE DIMENSIONS SUPPORTED METRICS AVAILABLE
Microsoft.ApiManagement/service Yes API Management
Microsoft.Automation/automationAcco Yes Automation Accounts

unts
Microsoft.Batch/batchAccounts N/A Batch Accounts
Microsoft.Cache/Redis N/A Azure Cache for Redis
Microsoft.CognitiveServices/accounts N/A Cognitive Services
Microsoft.Compute/virtualMachines N/A Virtual Machines
Microsoft.Compute/virtualMachineScale N/A Virtual machine scale sets

Sets
Microsoft.ContainerInstance/container Yes Container groups

Groups
Microsoft.ContainerService/managedCl Yes Managed Clusters

usters
Microsoft.DataFactory/datafactories Yes Data Factories V1

Microsoft.DataFactory/factories Yes Data Factories V2
Microsoft.DBforMySQL/servers N/A DB for MySQL
Microsoft.DBforPostgreSQL/servers N/A DB for PostgreSQL
Microsoft.Devices/IotHubs N/A IoT Hub Metrics
Microsoft.Devices/provisioningServices Yes DPS Metrics
Microsoft.EventHub/namespaces Yes Event Hubs
Microsoft.KeyVault/vaults No Vaults
Microsoft.Logic/workflows N/A Logic Apps
Microsoft.Network/applicationGateways N/A Application Gateways
Microsoft.Network/dnsZones N/A DNS Zones
Microsoft.Network/expressRouteCircuit N/A Express Route Circuits

s
Microsoft.Network/loadBalancers (only Yes Load Balancers

for Standard SKUs)
Microsoft.Network/publicipaddresses N/A Public IP Addresses
Microsoft.Network/trafficManagerProfil Yes Traffic Manager Profiles

es
Microsoft.OperationalInsights/workspac Yes Log Analytics workspaces

es
Microsoft.PowerBIDedicated/capacities N/A Capacities
Microsoft.Search/searchServices N/A Search services
Microsoft.ServiceBus/namespaces Yes Service Bus
Microsoft.Storage/storageAccounts Yes Storage Accounts
Microsoft.Storage/storageAccounts/ser Yes Blob Services, File Services, Queue

vices Services and Table Services
Microsoft.StreamAnalytics/streamingjob N/A Stream Analytics

s
Microsoft.Web/serverfarms Yes App Service Plans
Microsoft.Web/sites Yes App Services and Functions

Microsoft.Web/sites/slots Yes App Service slots
Payload schema
NOTE
You can also use the common alert schema, which provides the advantage of having a single extensible and unified alert
payload across all the alert services in Azure Monitor, for your webhook integrations. Learn about the common alert
schema definitions.
The POST operation contains the following JSON payload and schema for all near newer metric alerts when an
appropriately configured action group is used:
{
"schemaId": "AzureMonitorMetricAlert",
"data": {
"version": "2.0",
"context": {
"timestamp": "2018-02-28T10:44:10.1714014Z",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/Contoso/providers/microsoft.insights/metricAlerts/StorageCheck",
"name": "StorageCheck",
"description": "",
"severity":"3",
"condition": {
"allOf": [
{
"metricNamespace":"microsoft.storage/storageAccounts",
"dimensions": [
{
"name": "AccountResourceId",
"value": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/Contoso/providers/Microsoft.Storage/storageAccounts/diag500"
},
{
"name": "GeoType",
"value": "Primary"
}
],
"threshold": "0",
"timeAggregation": "PT5M",
"metricValue": 1
}
]
},
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "Contoso",
"resourceName": "diag500",
"resourceType": "Microsoft.Storage/storageAccounts",
"resourceId": "/subscriptions/1e3ff1c0-771a-4119-a03b-
be82a51e232d/resourceGroups/Contoso/providers/Microsoft.Storage/storageAccounts/diag500",
"portalLink": "https://portal.azure.com/#resource//subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/Contoso/providers/Microsoft.Storage/storageAccounts/diag500"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
}
Next steps
Learn more about the new Alerts experience.
Learn about alerts in Azure.
Supported services, schemas, and categories for Azure
Diagnostic Logs
Azure Monitor diagnostic logs are logs emitted by Azure services that describe the operation of those services or resources. All
diagnostic logs available through Azure Monitor share a common top-level schema, with flexibility for each service to emit unique
properties for their own events.
A combination of the resource type (available in the resourceId property) and the category uniquely identify a schema. This article
describes the top-level schema for diagnostic logs and links to the schemata for each service.
Top-level diagnostic logs schema

time Required The timestamp (UTC) of the event.
resourceId Required The resource ID of the resource that emitted the

event. For tenant services, this is of the form
/tenants/tenant-id/providers/provider-name.
tenantId Required for tenant logs The tenant ID of the Active Directory tenant
that this event is tied to. This property is only
used for tenant-level logs, it does not appear in
resource-level logs.
operationName Required The name of the operation represented by this

event. If the event represents an RBAC
operation, this is the RBAC operation name (eg.
/blobs/Read). Typically modeled in the form of a
Resource Manager operation, even if they are
not actual documented Resource Manager
operations (
Microsoft.
<providerName>/<resourceType>/<subtype>/<Write/Read/Delete
)
operationVersion Optional The api-version associated with the operation, if

the operationName was performed using an API
(eg.
http://myservice.windowsazure.net/object?
). If there is no API that corresponds to this
operation, the version represents the version of
that operation in case the properties associated
with the operation change in the future.
category Required The log category of the event. Category is the

granularity at which you can enable or disable
logs on a particular resource. The properties
that appear within the properties blob of an
event are the same within a particular log
category and resource type. Typical log
categories are “Audit” “Operational” “Execution”
and “Request.”
resultType Optional The status of the event. Typical values include

Started, In Progress, Succeeded, Failed, Active,
and Resolved.
resultSignature Optional The sub status of the event. If this operation

corresponds to a REST API call, this is the HTTP
status code of the corresponding REST call.
resultDescription Optional The static text description of this operation, eg.

“Get storage file.”
durationMs Optional The duration of the operation in milliseconds.
callerIpAddress Optional The caller IP address, if the operation

corresponds to an API call that would come
from an entity with a publicly-available IP
address.
correlationId Optional A GUID used to group together a set of related

events. Typically, if two events have the same
operationName but two different statuses (eg.
“Started” and “Succeeded”), they share the same
correlation ID. This may also represent other
relationships between events.
identity Optional A JSON blob that describes the identity of the

user or application that performed the
operation. Typically this will include the
authorization and claims / JWT token from
active directory.
Level Optional The severity level of the event. Must be one of

Informational, Warning, Error, or Critical.
location Optional The region of the resource emitting the event,

eg. “East US” or “France South”
properties Optional Any extended properties related to this

particular category of events. All custom/unique
properties must be put inside this “Part B” of
the schema.
Service-specific schemas for resource diagnostic logs

The schema for resource diagnostic logs varies depending on the resource and log category. This list shows all services that make
available diagnostic logs and links to the service and category-specific schema where available.
Azure Active Directory Overview, Audit log schema and Sign-ins schema
Analysis Services https://azure.microsoft.com/blog/azure-analysis-services-integration-with-

azure-diagnostic-logs/
API Management API Management Diagnostic Logs
Application Gateways Diagnostics Logging for Application Gateway
Azure Automation Log analytics for Azure Automation
Azure Batch Azure Batch diagnostic logging
Azure Database for MySQL Azure Database for MySQL diagnostic logs
Azure Database for PostgreSQL Azure Database for PostgreSQL diagnostic logs
Cognitive Services Diagnostic Logging for Azure Cognitive Services
Content Delivery Network Azure Diagnostic Logs for CDN
CosmosDB Azure Cosmos DB Logging

Data Factory Monitor Data Factories using Azure Monitor
Data Lake Analytics Accessing diagnostic logs for Azure Data Lake Analytics
Data Lake Store Accessing diagnostic logs for Azure Data Lake Store
Event Hubs Azure Event Hubs diagnostic logs
Express Route Schema not available.
Azure Firewall Schema not available.
IoT Hub IoT Hub Operations
Key Vault Azure Key Vault Logging
Kubernetes Service Azure Kubernetes Logging
Load Balancer Log analytics for Azure Load Balancer
Logic Apps Logic Apps B2B custom tracking schema
Network Security Groups Log analytics for network security groups (NSGs)
DDOS Protection Manage Azure DDoS Protection Standard
Power BI Dedicated Diagnostic logging for Power BI Embedded in Azure
Recovery Services Data Model for Azure Backup
Search Enabling and using Search Traffic Analytics
Service Bus Azure Service Bus diagnostic logs
SQL Database Azure SQL Database diagnostic logging
Stream Analytics Job diagnostic logs
Traffic Manager Traffic Manager Log schema
Virtual Networks Schema not available.
Virtual Network Gateways Schema not available.
Supported log categories per resource type

RESOURCE TYPE CATEGORY CATEGORY DISPLAY NAME
Microsoft.AnalysisServices/servers Engine Engine
Microsoft.AnalysisServices/servers Service Service
Microsoft.ApiManagement/service GatewayLogs Logs related to ApiManagement Gateway
Microsoft.Automation/automationAccounts JobLogs Job Logs
Microsoft.Automation/automationAccounts JobStreams Job Streams
Microsoft.Automation/automationAccounts DscNodeStatus Dsc Node Status

Microsoft.Batch/batchAccounts ServiceLog Service Logs
Microsoft.Cdn/profiles/endpoints CoreAnalytics Gets the metrics of the endpoint, e.g.,

bandwidth, egress, etc.
Microsoft.ClassicNetwork/networksecuritygroup Network Security Group Rule Flow Event Network Security Group Rule Flow Event
s
Microsoft.CognitiveServices/accounts Audit Audit Logs
Microsoft.CognitiveServices/accounts RequestResponse Request and Response Logs
Microsoft.ContainerService/managedClusters kube-apiserver Kubernetes API Server
Microsoft.ContainerService/managedClusters kube-controller-manager Kubernetes Controller Manager
Microsoft.ContainerService/managedClusters cluster-autoscaler Kubernetes Cluster Autoscaler
Microsoft.ContainerService/managedClusters kube-scheduler Kubernetes Scheduler
Microsoft.ContainerService/managedClusters guard Authentication Webhook
Microsoft.CustomerInsights/hubs AuditEvents AuditEvents
Microsoft.DataFactory/factories ActivityRuns Pipeline activity runs log
Microsoft.DataFactory/factories PipelineRuns Pipeline runs log
Microsoft.DataFactory/factories TriggerRuns Trigger runs log
Microsoft.DataLakeAnalytics/accounts Audit Audit Logs
Microsoft.DataLakeAnalytics/accounts Requests Request Logs
Microsoft.DataLakeStore/accounts Audit Audit Logs
Microsoft.DataLakeStore/accounts Requests Request Logs
Microsoft.DBforMySQL/servers MySqlSlowLogs MySQL Server Logs
Microsoft.DBforPostgreSQL/servers PostgreSQLLogs PostgreSQL Server Logs
Microsoft.Devices/IotHubs Connections Connections
Microsoft.Devices/IotHubs DeviceTelemetry Device Telemetry
Microsoft.Devices/IotHubs C2DCommands C2D Commands
Microsoft.Devices/IotHubs DeviceIdentityOperations Device Identity Operations
Microsoft.Devices/IotHubs FileUploadOperations File Upload Operations
Microsoft.Devices/IotHubs Routes Routes
Microsoft.Devices/IotHubs D2CTwinOperations D2CTwinOperations
Microsoft.Devices/IotHubs C2DTwinOperations C2D Twin Operations
Microsoft.Devices/IotHubs TwinQueries Twin Queries
Microsoft.Devices/IotHubs JobsOperations Jobs Operations

Microsoft.Devices/IotHubs DirectMethods Direct Methods
Microsoft.Devices/IotHubs E2EDiagnostics E2E Diagnostics (Preview)
Microsoft.Devices/IotHubs Configurations Configurations
Microsoft.Devices/provisioningServices DeviceOperations Device Operations
Microsoft.Devices/provisioningServices ServiceOperations Service Operations
Microsoft.DocumentDB/databaseAccounts DataPlaneRequests DataPlaneRequests
Microsoft.DocumentDB/databaseAccounts MongoRequests MongoRequests
Microsoft.DocumentDB/databaseAccounts QueryRuntimeStatistics QueryRuntimeStatistics
Microsoft.EventHub/namespaces ArchiveLogs Archive Logs
Microsoft.EventHub/namespaces OperationalLogs Operational Logs
Microsoft.EventHub/namespaces AutoScaleLogs Auto Scale Logs
Microsoft.Insights/AutoscaleSettings AutoscaleEvaluations Autoscale Evaluations
Microsoft.Insights/AutoscaleSettings AutoscaleScaleActions Autoscale Scale Actions
Microsoft.IoTSpaces/Graph Trace Trace
Microsoft.IoTSpaces/Graph Operational Operational
Microsoft.IoTSpaces/Graph Audit Audit
Microsoft.IoTSpaces/Graph UserDefinedFunction UserDefinedFunction
Microsoft.IoTSpaces/Graph Ingress Ingress
Microsoft.IoTSpaces/Graph Egress Egress
Microsoft.KeyVault/vaults AuditEvent Audit Logs
Microsoft.Logic/workflows WorkflowRuntime Workflow runtime diagnostic events
Microsoft.Logic/integrationAccounts IntegrationAccountTrackingEvents Integration Account track events
Microsoft.Network/networksecuritygroups NetworkSecurityGroupEvent Network Security Group Event
Microsoft.Network/networksecuritygroups NetworkSecurityGroupRuleCounter Network Security Group Rule Counter
Microsoft.Network/loadBalancers LoadBalancerAlertEvent Load Balancer Alert Events
Microsoft.Network/loadBalancers LoadBalancerProbeHealthStatus Load Balancer Probe Health Status
Microsoft.Network/publicIPAddresses DDoSProtectionNotifications DDoS protection notifications
Microsoft.Network/publicIPAddresses DDoSMitigationFlowLogs Flow logs of DDoS mitigation decisions
Microsoft.Network/publicIPAddresses DDoSMitigationReports Reports of DDoS mitigations
Microsoft.Network/virtualNetworks VMProtectionAlerts VM protection alerts
Microsoft.Network/applicationGateways ApplicationGatewayAccessLog Application Gateway Access Log

Microsoft.Network/applicationGateways ApplicationGatewayPerformanceLog Application Gateway Performance Log
Microsoft.Network/applicationGateways ApplicationGatewayFirewallLog Application Gateway Firewall Log
Microsoft.Network/securegateways AzureFirewallApplicationRule Azure Firewall Application Rule
Microsoft.Network/securegateways AzureFirewallNetworkRule Azure Firewall Network Rule
Microsoft.Network/azurefirewalls AzureFirewallApplicationRule Azure Firewall Application Rule
Microsoft.Network/azurefirewalls AzureFirewallNetworkRule Azure Firewall Network Rule
Microsoft.Network/virtualNetworkGateways GatewayDiagnosticLog Gateway Diagnostic Logs
Microsoft.Network/virtualNetworkGateways TunnelDiagnosticLog Tunnel Diagnostic Logs
Microsoft.Network/virtualNetworkGateways RouteDiagnosticLog Route Diagnostic Logs
Microsoft.Network/virtualNetworkGateways IKEDiagnosticLog IKE Diagnostic Logs
Microsoft.Network/virtualNetworkGateways P2SDiagnosticLog P2S Diagnostic Logs
Microsoft.Network/trafficManagerProfiles ProbeHealthStatusEvents Traffic Manager Probe Health Results Event
Microsoft.Network/expressRouteCircuits PeeringRouteLog Peering Route Table Logs
Microsoft.Network/frontdoors FrontdoorAccessLog Frontdoor Access Log
Microsoft.Network/frontdoors FrontdoorWebApplicationFirewallLog Frontdoor Web Application Firewall Log
Microsoft.PowerBIDedicated/capacities Engine Engine
Microsoft.RecoveryServices/Vaults AzureBackupReport Azure Backup Reporting Data
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryJobs Azure Site Recovery Jobs
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryEvents Azure Site Recovery Events
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryReplicatedItems Azure Site Recovery Replicated Items
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryReplicationStats Azure Site Recovery Replication Stats
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryRecoveryPoints Azure Site Recovery Recovery Points
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryReplicationDataUploadRate Azure Site Recovery Replication Data Upload

Rate
Microsoft.RecoveryServices/Vaults AzureSiteRecoveryProtectedDiskDataChurn Azure Site Recovery Protected Disk Data Churn
Microsoft.Search/searchServices OperationLogs Operation Logs
Microsoft.ServiceBus/namespaces OperationalLogs Operational Logs
Microsoft.Sql/servers/databases SQLInsights SQL Insights
Microsoft.Sql/servers/databases AutomaticTuning Automatic tuning
Microsoft.Sql/servers/databases QueryStoreRuntimeStatistics Query Store Runtime Statistics
Microsoft.Sql/servers/databases QueryStoreWaitStatistics Query Store Wait Statistics

Microsoft.Sql/servers/databases Errors Errors
Microsoft.Sql/servers/databases DatabaseWaitStatistics Database Wait Statistics
Microsoft.Sql/servers/databases Timeouts Timeouts
Microsoft.Sql/servers/databases Blocks Blocks
Microsoft.Sql/servers/databases Deadlocks Deadlocks
Microsoft.Sql/servers/databases Audit Audit Logs
Microsoft.Sql/servers/databases SQLSecurityAuditEvents SQL Security Audit Event
Microsoft.Sql/servers/databases DmsWorkers Dms Workers
Microsoft.Sql/servers/databases ExecRequests Exec Requests
Microsoft.Sql/servers/databases RequestSteps Request Steps
Microsoft.Sql/servers/databases SqlRequests Sql Requests
Microsoft.Sql/servers/databases Waits Waits
Microsoft.Sql/managedInstances ResourceUsageStats Resource Usage Statistics
Microsoft.Sql/managedInstances SQLSecurityAuditEvents SQL Security Audit Event
Microsoft.Sql/managedInstances/databases SQLInsights SQL Insights
Microsoft.Sql/managedInstances/databases QueryStoreRuntimeStatistics Query Store Runtime Statistics
Microsoft.Sql/managedInstances/databases QueryStoreWaitStatistics Query Store Wait Statistics
Microsoft.Sql/managedInstances/databases Errors Errors
Microsoft.StreamAnalytics/streamingjobs Execution Execution
Microsoft.StreamAnalytics/streamingjobs Authoring Authoring
microsoft.web/sites FunctionExecutionLogs Function Execution Logs
microsoft.web/sites/slots FunctionExecutionLogs Function Execution Logs
Next Steps
Learn more about diagnostic logs
Stream resource diagnostic logs to Event Hubs
Change resource diagnostic settings using the Azure Monitor REST API
Analyze logs from Azure storage with Log Analytics
Application Insights for Azure Functions supported
features
Azure Functions offers built-in integration with Application Insights, which is available through the ILogger
Interface. Below is the list of currently supported features. Review Azure Functions' guide for Getting started.
Supported features
Application Insights .NET SDK 2.5.0 2.9.1
Automatic collection of
• Requests Yes Yes
• Exceptions Yes Yes
• Performance Counters Yes Yes
• Dependencies
— HTTP Yes
— ServiceBus Yes
— EventHub Yes
— SQL Yes
Supported features
• QuickPulse/LiveMetrics Yes Yes
— Secure Control Channel Yes
• Sampling Yes Yes
• Heartbeats Yes
Correlation
• ServiceBus Yes
• EventHub Yes
Configurable
•Fully configurable. Yes

See Azure Functions for instructions.
See Asp.NET Core for all options.
Performance Counters
Automatic collection of Performance Counters only work Windows machines.
Live Metrics & Secure Control Channel

The custom filters criteria you specify are sent back to the Live Metrics component in the Application Insights SDK.
The filters could potentially contain sensitive information such as customerIDs. You can make the channel secure
with a secret API key. See Secure the control channel for instructions.
Sampling
Azure Functions enables Sampling by default in their configuration. For more information, see Configure
Sampling.
If your project takes a dependency on the Application Insights SDK to do manual telemetry tracking, you may
experience strange behavior if your sampling configuration is different than the Functions' sampling configuration.
We recommend using the same configuration as Functions. With Functions v2, you can get the same
configuration using dependency injection in your constructor:
public class Function1

{
public Function1(TelemetryConfiguration configuration)

{
this.telemetryClient = new TelemetryClient(configuration);
}
[FunctionName("Function1")]
public async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req, ILogger
logger)
{
this.telemetryClient.TrackTrace("C# HTTP trigger function processed a request.");
}
}
Azure Monitor retirement of classic deployment
model APIs for metrics and autoscale
Azure Monitor (formerly Azure Insights when first released) currently offers the capability to create and manage
autoscale settings for and consume metrics from classic VMs and classic Cloud Services. The original set of classic
deployment model-based APIs will be retired after June 30, 2019 in all Azure public and private clouds in all
regions.
The same operations have been supported through a set of Azure Resource Manager based APIs for over a year.
The Azure portal uses the new REST APIs for both autoscale and metrics. A new SDK, PowerShell, and CLI based
on these Resource Manager APIs are also available. Our partner services for monitoring consume the new
Resource Manager based REST APIs in Azure Monitor.
Who is not affected

If you are managing autoscale via the Azure portal, the new Azure Monitor SDK, PowerShell, CLI, or Resource
Manager templates, no action is necessary.
If you are consuming metrics via the Azure portal or via various monitoring partner services, no action is
necessary. Microsoft is working with monitoring partners to migrate to the new APIs.
Who is affected
This article applies to you if you are using the following components:
Classic Azure Insights SDK - If you're using the classic Azure Insights SDK, switch to using the new Azure
Monitor SDK for .NET or Java. Download the Azure Monitor SDK NuGet package.
Classic Autoscale - If you're calling the classic autoscale settings APIs from your custom-built tools or
using the classic Azure Insights SDK, you should switch to using the Resource Manager Azure Monitor
REST API.
Classic Metrics - If you're consuming metrics using the classic REST APIs or classic Azure Insights SDK
from custom-built tools, you should switch to using the Resource Manager Azure Monitor REST API.
If you're unsure whether your code or custom tools are calling the classic APIs, look at the following:
Review the URI referenced in your code or tool. The classic APIs use the URI
https://management.core.windows.net. You should be using the newer URI for the Resource Manager based
APIs begins with https://management.azure.com/.
Compare the assembly name on your machine. The older classic assembly is at
https://www.nuget.org/packages/Microsoft.WindowsAzure.Management.Monitoring/.
If you're using certificate authentication to access metrics or autoscale APIs, you are using a classic endpoint
and library. The newer Resource Manager APIs require Azure Active Directory authentication via a service
principal or user principal.
If you're using calls referenced in the documentation at any of the following links, you are using the older
classic APIs.
Windows.Azure.Management.Monitoring Class Library
Monitoring (classic) .NET
IMetricOperations Interface
Why you should switch

All the existing capabilities for autoscale and metrics will continue to work via the new APIs.
Migrating over to newer APIs come with Resource Manager based capabilities, such as support for consistent
Role-Based Access Control (RBAC ) across all your monitoring services. You also gain additional functionality for
metrics:
support for dimensions
consistent 1-minute metric granularity across all services
better querying
higher data retention (93 days of metrics vs. 30 days)
Overall, like all other services in Azure, the Resource Manager based Azure Monitor APIs come with better
performance, scalability, and reliability.
What happens if you do not migrate

Before retirement
There will not be any direct impact to your Azure services or their workloads.
After retirement
Any calls to the classic APIs listed previously will fail and return error messages similar the following ones:
For autoscale: This API has been deprecated. Use the Azure portal, Azure Monitor SDK, PowerShell, CLI, or
Resource Manager templates to manage Autoscale Settings.
For metrics: This API has been deprecated. Use the Azure portal, Azure Monitor SDK, PowerShell, CLI to query for
metrics.
Email notifications
A retirement notification was sent to email addresses for the following account roles:
Account and service administrators
Coadministrators
If you have any questions, contact us at MonitorClassicAPIhelp@microsoft.com.
References
Newer REST APIs for Azure Monitor
Newer Azure Monitor SDK
Unified alerting & monitoring in Azure Monitor
replaces classic alerting & monitoring
Azure Monitor has now become a unified full stack monitoring service, which now supports ‘One Metric’ and
‘One Alerts’ across resources; for more information, see our blog post on new Azure Monitor.The new Azure
monitoring and alerting platforms has been built to be faster, smarter, and extensible – keeping pace with the
growing expanse of cloud computing and in-line with Microsoft Intelligent Cloud philosophy.
With the new Azure monitoring and alerting platform in place, we will be retiring the "classic" monitoring and
alerting platform - hosted within view classic alerts section of Azure alerts, will be deprecated by August 2019
in Azure public clouds. Azure Government cloud and Azure China 21Vianet will not be affected.
NOTE
We encourage you to get started and recreate your alerts in the new platform. For customers who have a large
number of alerts, we are rolling out in phases, a voluntary migration tool to move existing classic alerts to the new
alerts system without disruption or added costs.
IMPORTANT
Classic Alert rules created on Activity Log will not be deprecated or migrated. All classic alert rules created on Activity Log
can be accessed and used as-is from the new Azure Monitor - Alerts. For more information, see Create, view, and manage
activity log alerts using Azure Monitor. Similarly, Alerts on Service Health can be accessed and used as-is from the new
Service Health section. For details, see alerts on service health notifications.
Unified Metrics and Alerts in Application Insights

Azure Monitor’s newer metric platform will now power monitoring coming from Application Insights. This move
means Application Insights will hook to Action Groups, allowing far more options than just the previous email and
webhook calls. Alerts can now trigger Voice Calls, Azure Functions, Logic Apps, SMS, and ITSM Tools like
ServiceNow and Automation Runbooks. With near real-time monitoring and alerting, the new platform enables
Application Insights users to leverage the same technology powering monitoring across other Azure resources
and underpinning monitoring of Microsoft products.
The new unified Monitoring and Alerting for Application Insights will encompass:
Application Insights Platform metrics – which provides popular prebuilt metrics from Application Insights
product. For more information, see this article on using Platform Metrics for Application Insights on new
Azure Monitor.
Application Insights Availability and Web test -which provides you the ability to assess the
responsiveness and availability of your web app or server. For more information, see this article on using
Availability Tests and Alerts for Application Insights on new Azure Monitor.
Application Insights Custom metrics – which lets you define and emit their own metrics for monitoring and
alerts. For more information, see this article on using Custom Metric for Application Insights on new Azure
Monitor.
Application Insights Failure Anomalies (part of Smart Detection) – which automatically notifies you in
near real time if your web app experiences an abnormal rise in the rate of failed HTTP requests or dependency
calls. For more information, see this article on using Smart Detection - Failure Anomalies.
Unified Metrics and Alerts for other Azure resources

Since March 2018, the next generation of alerting and multi-dimensional monitoring for Azure resources have
been in availability. Now the newer metric platform and alerting is faster with near-real time capabilities. More
importantly, the newer metric platform alerts provide more granularity, as the newer platform includes the option
of dimensions, which allow you to slice and filter to specific value combination, condition, or operation. Like all
alerts in the new Azure Monitor, the newer metric alerts are more extensible with the use of ActionGroups –
allowing notifications to expand beyond email or webhook to SMS, Voice, Azure Function, Automation Runbook
and more. For more information, see Create, view, and manage metric alerts using Azure Monitor. Newer metrics
for Azure resources are available as:
Azure Monitor Standard platform metrics – which provides popular pre-populated metrics from various
Azure services and products. For more information, see this article on Supported metrics on Azure Monitor
and Support metric alerts on Azure Monitor.
Azure Monitor Custom metrics – which provides metrics from user driven sources including the Azure
Diagnostics agent. For more information, see this article on Custom metrics in Azure Monitor. Using custom
metrics, you can also publish metrics collected by Windows Azure Diagnostics agent and InfluxData Telegraf
agent.
Retirement of Classic monitoring and alerting platform

As stated earlier, the classic monitoring and alerting platform currently usable from the Alerts (classic) section of
Azure portal will be retired in coming months given they have been replaced by the newer system. Older classic
monitoring and alerting will be retired on 31 August 2019; including the closure of related APIs, Azure portal
interface, and Services in it. Specifically, these features will be deprecated:
Older (classic) metrics and alerts for Azure resources as currently available via Alerts (classic) section of Azure
portal; accessible as microsoft.insights/alertrules resource
Older (classic) platform and custom metrics for Application Insights as well as alerting on them as currently
available via Alerts (classic) section of Azure portal and accessible as microsoft.insights/alertrules resource
Older (classic) Failure Anomalies alert currently available as Smart Detection inside Application Insights in the
Azure portal; with alerts configured shown in Alerts (classic) section of Azure portal
All classic monitoring and alerting systems including corresponding API, PowerShell, CLI, Azure portal page, and
Resource Template will remain usable until end of August 2019.
At the end of August 2019, in Azure Monitor:
Classic monitoring and alerts service will be retired and no longer available for creation of new alert rules.
Any alert rules that continue to exist in Alerts (classic) beyond August 2019 will continue to execute and fire
notifications, but not be available for modification.
Starting September 2019, alert rules in classic monitoring & alerting which can be migrated, will be
automatically moved by Microsoft to their equivalent in the new Azure monitor platform in phases spanning
few weeks. The process will be seamless without any downtime and customers will have no loss in monitoring
coverage.
Alert rules migrated to the new alerts platform will provide monitoring coverage as before but will fire
notification with new payloads. Any email address, webhook endpoint, or logic app link associated with classic
alert rule will be carried forward when migrated, but may not behave correctly as alert payload will be different
in the new platform.
Some classic alert rules that cannot be automatically migrated and require manual action from users will
continue to run until June 2020.
IMPORTANT
Microsoft Azure Monitor has rolled out in phases tool to voluntarily migrate their classic alert rules on to the new platform
soon. And run it by force for all classic alert rules that still exist and can be migrated, starting September 2019. Customers
will need to ensure automation consuming classic alert rule payload is adapted to handle the new payload from Unified
Metrics and Alerts in Application Insights or Unified Metrics and Alerts for other Azure resources, post-migration of the
classic alert rules. For more information, see prepare for classic alert rule migration
This article will be continually updated with links & details regarding the new Azure monitoring & alerting
functionality, as well as the availability of tools to assist users in adopting the new Azure Monitor platform.
Pricing for Migrated Alert Rules

We are rolling out a migration tool to help you migrate your Azure Monitor classic alerts to the new alerts
experience. The migrated alert rules and corresponding migrated action groups (email, webhook, or LogicApp)
will remain free of charge. The functionality you had with classic alerts including the ability to edit the threshold,
aggregation type, and the aggregation granularity will continue to be available for free with your migrated alert
rule. However, if you edit the migrated alert rule to use any of the new alert platform features, notifications or
action types, a corresponding charge will apply. For more information on the pricing for alert rules and
notifications, see Azure Monitor Pricing.
The following are examples of cases where you will incur a charge for your alert rule:
Any new (non-migrated) alert rule created beyond free units, on the new Azure Monitor platform
Any data ingested and retained beyond free units included by Azure Monitor
Any multi-test web tests executed by Application Insights
Any custom metrics stored beyond free units included in Azure Monitor
Any migrated alert rules that are edited to use newer metric alert features like frequency, multiple
resources/dimensions, Dynamic Thresholds, changing resource/signal, and so on.
Any migrated action groups that are edited to use newer notifications, or action types like SMS, Voice Call
and/or ITSM integration.
Next steps
Learn about the new unified Azure Monitor.
Learn more about the new Azure Alerts.
Switch API preference for Log Alerts
NOTE
Content stated applicable to users Azure public cloud only and not for Azure Government or Azure China cloud.
Until recently, you managed alert rules in the Microsoft Operations Management Suite portal. The new alerts
experience was integrated with various services in Microsoft Azure including Log Analytics and we asked to
extend your alert rules from OMS portal to Azure. But to ensure minimal disruption for customers, the process
did not alter the programmatic interface for its consumption - Log Analytics Alert API based on SavedSearch.
But now you announce for Log Analytics alerting users a true Azure programmatic alternative, Azure Monitor -
ScheduledQueryRules API, which is also reflective in your Azure billing - for log alerts. To learn more on how to
manage your log alerts using the API, see Managing log alerts using Azure Resource Template and Managing
log alerts using PowerShell.
Benefits of switching to new Azure API

There are several advantages of creating and managing alerts using scheduledQueryRules API over legacy Log
Analytics Alert API; we have listed some of the major ones below:
Ability to cross workspace log search in alert rules and span up external resources like Log Analytics
workspaces or even Application Insights apps
When multiple fields used to Group in query, using scheduledQueryRules API user can specify which field to
aggregate-on in Azure portal
Log alerts created using scheduledQueryRules API can have period defined up to 48 hours and fetch data for
longer period than before
Create alert rules in one shot as a single resource without the need to create three levels of resources as with
legacy Log Analytics Alert API
Single programmatic interface for all variants of query-based log alerts in Azure - new scheduledQueryRules
API can be used to manage rules for Log Analytics as well as Application Insights
Manage your log alerts using Powershell cmdlets
All new log alert functionality and future development will be available only via the new
scheduledQueryRules API
Process of switching from legacy Log Alerts API

Users are free to use either legacy Log Analytics Alert API or the new scheduledQueryRules API. Alert rules
created by either API, will be manageable by the same API only - as well as from Azure portal. By default, Azure
Monitor will continue to use legacy Log Analytics Alert API for creating any new alert rule from Azure portal for
existing workspaces of Log Analytics. As announced new Log workspace created on or after June 1, 2019 - will
automatically use new scheduledQueryRules API by default including in Azure portal.
The impacts of the switch of preference to scheduledQueryRules API are compiled below:
All interactions done for managing log alerts via programmatic interfaces must now be done using
scheduledQueryRules instead. For more information, see, sample use via Azure Resource Template and
sample use via PowerShell
Any new log alert rule created in Azure portal, will be created using scheduledQueryRules only and allow
users to use the additional functionality of new API via Azure portal as well
Severity for log alert rules will shift from: Critical, Warning & Informational, to Severity values of 0, 1 & 2.
Along with the option to create/update alert rules with severity 3 and 4 as well.
The process of moving alert rules from legacy Log Analytics Alert API does not involve changing your alert
definition, query, or configuration in any way. Your alert rules and monitoring are unaffected and the alerts will
not stop or be stalled, during or after the switch. The only change is a change in API preference and access to
your rules via a new API.
NOTE
Once a user opts to switch preference to the new scheduledQueryRules API, the you cannot opt back or revert to using of
the older legacy Log Analytics Alert API.
Any customer who wishes to switch voluntarily to the new scheduledQueryRules and block usage from the
legacy Log Analytics Alert API; can do so by performing a PUT call on the below API to switch all alert rules
associated with the specific Log Analytics workspace.
PUT
/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/wo
rkspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview
With request body containing the below JSON.
{
"scheduledQueryRulesEnabled" : true
}
The API can also be accessed from a PowerShell command line using ARMClient, an open-source command-line
tool that simplifies invoking the Azure Resource Manager API. As illustrated below, in sample PUT call using
ARMclient tool to switch all alert rules associated with the specific Log Analytics workspace.
$switchJSON = '{"scheduledQueryRulesEnabled": "true"}'

armclient PUT
rkspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview $switchJSON
If switch of all alert rules in the Log Analytics workspace to use new scheduledQueryRules is successful, the
following response will be provided.
{
"version": 2,
}
Users can also check the current status of your Log Analytics workspace and see if it has or has not been
switched to use scheduledQueryRules only. To check, users can perform a GET call on the below API.
GET
To execute the above in using PowerShell command line using ARMClient tool, see the sample below.
armclient GET
If the specified Log Analytics workspace has been switched to use scheduledQueryRules only; then the response
JSON will be as listed below.
{
"version": 2,
}
Else, if the specified Log Analytic workspace has not yet been switched to use scheduledQueryRules only; then
the response JSON will be as listed below.
{
"version": 2,
"scheduledQueryRulesEnabled" : false
}
Next steps
Learn about the Azure Monitor - Log Alerts.
Learn how to create log alerts in Azure Alerts.
Learn more about the Azure Alerts experience.
Exploring HockeyApp data in Application Insights
NOTE
HockeyApp is no longer available for new applications. Existing HockeyApp deployments will continue to work. Visual Studio
App Center is now the recommended service from Microsoft for monitoring new mobile apps. Learn how to set up your apps
with App Center and Application Insights.
HockeyApp is a service for monitoring live desktop and mobile apps. From HockeyApp, you can send custom and
trace telemetry to monitor usage and assist in diagnosis (in addition to getting crash data). This stream of
telemetry can be queried using the powerful Analytics feature of Azure Application Insights. In addition, you can
export the custom and trace telemetry. To enable these features, you set up a bridge that relays HockeyApp custom
data to Application Insights.
The HockeyApp Bridge app

The HockeyApp Bridge App is the core feature that enables you to access your HockeyApp custom and trace
telemetry in Application Insights through the Analytics and Continuous Export features. Custom and trace events
collected by HockeyApp after the creation of the HockeyApp Bridge App will be accessible from these features.
Let's see how to set up one of these Bridge Apps.
In HockeyApp, open Account Settings, API Tokens. Either create a new token or reuse an existing one. The
minimum rights required are "read only". Take a copy of the API token.
Open the Microsoft Azure portal and create an Application Insights resource. Set Application Type to "HockeyApp
bridge application":
You don't need to set a name - this will automatically be set from the HockeyApp name.
The HockeyApp bridge fields appear.
Enter the HockeyApp token you noted earlier. This action populates the "HockeyApp Application" dropdown menu
with all your HockeyApp applications. Select the one you want to use, and complete the remainder of the fields.
Open the new resource.
Note that the data takes a while to start flowing.
That's it! Custom and trace data collected in your HockeyApp-instrumented app from this point forward is now
also available to you in the Analytics and Continuous Export features of Application Insights.
Let's briefly review each of these features now available to you.
Analytics
Analytics is a powerful tool for ad hoc querying of your data, allowing you to diagnose and analyze your telemetry
and quickly discover root causes and patterns.
Learn more about Analytics
Continuous export
Continuous Export allows you to export your data into an Azure Blob Storage container. This is very useful if you
need to keep your data for longer than the retention period currently offered by Application Insights. You can keep
the data in blob storage, process it into a SQL Database, or your preferred data warehousing solution.
Learn more about Continuous Export
Next steps
Apply Analytics to your data
View analytic data for metrics across all your Azure
Web App resources
NOTE
The Azure Web App Analytics solution has moved to community support.
The solution is no longer available from the Azure Marketplace but can be installed from Azure Quickstart templates
where it's supported by the community.
Customers who have already installed the solution can continue to use it with changes.
Microsoft recommends that you use Application Insights to monitor your web applications.
Application Insights Connector management solution
(Deprecated)
NOTE
With the support of cross-resource queries, the Application Insights Connector management solution is no longer required.
It has been deprecated and removed from Azure Marketplace, along with the OMS portal that was officially deprecated on
January 15, 2019 for Azure commercial cloud. It will be retired on March 30, 2019 for Azure US Government cloud.
Existing connections will continue to work until June 30, 2019. With OMS portal deprecation, there is no way to configure
and remove existing connections from the portal. See Removing the connector with PowerShell below for a script on using
PowerShell to remove existing connections.
For guidance on querying Application Insights log data for multiple applications, see Unify multiple Azure Monitor
Application Insights resources. For more information on the OMS portal deprecation, see OMS portal moving to Azure.
The Applications Insights Connector solution helps you diagnose performance issues and understand what users
do with your app when it is monitored with Application Insights. Views of the same application telemetry that
developers see in Application Insights are available in Log Analytics. However, when you integrate your
Application Insights apps with Log Analytics, visibility of your applications is increased by having operation and
application data in one place. Having the same views helps you to collaborate with your app developers. The
common views can help reduce the time to detect and resolve both application and platform issues.
When you use the solution, you can:
View all your Application Insights apps in a one place, even when they are in different Azure subscriptions
Correlate infrastructure data with application data
Visualize application data with perspectives in log search
Pivot from Log Analytics data to your Application Insights app in the Azure portal
NOTE
PowerShell.
Connected sources
Unlike most other Log Analytics solutions, data isn't collected for the Application Insights Connector by agents. All
data used by the solution comes directly from Azure.
Windows agents No The solution does not collect

information from Windows agents.
Linux agents No The solution does not collect

information from Linux agents.
SCOM management group No The solution does not collect

information from agents in a connected
SCOM management group.
Azure storage account No The solution does not collection

information from Azure storage.
Prerequisites
To access Application Insights Connector information, you must have an Azure subscription
You must have at least one configured Application Insights resource.
You must be the owner or contributor of the Application Insights resource.
Configuration
1. Enable the Azure Web Apps Analytics solution from the Azure marketplace or by using the process described in
Add Log Analytics solutions from the Solutions Gallery.
2. Browse to the Azure portal. Select All services to open Application Insights. Then, search for Application
Insights.
3. Under Subscriptions, select a subscription that has Application Insights resources and then under Name,
select one or more applications.
4. Click Save.
In approximately 30 minutes, data becomes available and the Application Insights tile is updated with data, like the
following image:
Other points to keep in mind:

You can only link Application Insights apps to one Log Analytics workspace.
You can only link Basic or Enterprise Application Insights resources to Log Analytics. However, you can use the
Free tier of Log Analytics.
Management packs
This solution does not install any management packs in connected management groups.
Use the solution

The following sections describe how you can use the blades shown in the Application Insights dashboard to view
and interact with data from your apps.
View Application Insights Connector information
Click the Application Insights tile to open the Application Insights dashboard to see the following blades.
The dashboard includes the blades shown in the table. Each blade lists up to 10 items matching that blade's criteria
for the specified scope and time range. You can run a log search that returns all records when you click See all at
the bottom of the blade or when you click the blade header.
COLUMN DESCRIPTION
COLUMN DESCRIPTION
Applications - Number of applications Shows the number of applications in Application resources.

Also lists application names and for each, the count of
application records. Click the number to run a log search for
ApplicationInsights | summarize AggregatedValue =
sum(SampledCount) by ApplicationName
Click an application name to run a log search for the

application that shows application records per host, records by
telemetry type, and all data by type (based on the last day).
Data Volume – Hosts sending data Shows the number of computer hosts that are sending data.
Also lists computer hosts and record count for each host. Click
the number to run a log search for
ApplicationInsights | summarize AggregatedValue =
sum(SampledCount) by Host
Click on a computer name to run a log search for the host

that shows application records per host, records by telemetry
type, and all data by type (based on the last day).
Availability – Webtest results Shows a doughnut chart for web test results, indicating pass
or fail. Click the chart to run a log search for
ApplicationInsights | where TelemetryType ==
"Availability" | summarize AggregatedValue =
sum(SampledCount) by AvailabilityResult
Results show the number of passes and failures for all tests. It
shows all Web Apps with traffic for the last minute. Click an
application name to view a log search showing details of failed
web tests.
Server Requests – Requests per hour Shows a line chart of the server requests per hour for various
applications. Hover over a line in the chart to see the top 3
applications receiving requests for a point in time. Also shows
a list of the applications receiving requests and the number of
requests for the selected period.
Click the graph to run a log search for

"Request" | summarize AggregatedValue =
sum(SampledCount) by ApplicationName,
bin(TimeGenerated, 1h)
that shows a more detailed line chart of the server requests
per hour for various applications.
Click an application in the list to run a log search for

ApplicationInsights | where ApplicationName ==
"yourapplicationname" and TelemetryType == "Request"
and iff(isnotnull(toint(RequestSuccess)),
RequestSuccess == false, RequestSuccess == "false")
== true
that shows a list of requests, charts for requests over time and
request duration and a list of request response codes.
COLUMN DESCRIPTION
Failures – Failed requests per hour Shows a line chart of failed application requests per hour.
Hover over the chart to see the top 3 applications with failed
requests for a point in time. Also shows a list of applications
with the number of failed requests for each. Click the chart to
run a log search for
"Request" and iff(isnotnull(toint(RequestSuccess)),
== true | summarize AggregatedValue =
that shows a more detailed line chart of failed application
requests.
Click an item in the list to run a log search for

"yourapplicationname" and TelemetryType == "Request"
and iff(isnotnull(toint(RequestSuccess)),
== true
that shows failed requests, charts for failed requests over time
and request duration and a list of failed request response
codes.
Exceptions – Exceptions per hour Shows a line chart of exceptions per hour. Hover over the
chart to see the top 3 applications with exceptions for a point
in time. Also shows a list of applications with the number of
exceptions for each. Click the chart to run a log search for
"Exception" | summarize AggregatedValue =
that shows a more detailed link chart of exceptions.
Click an item in the list to run a log search for

"yourapplicationname" and TelemetryType ==
"Exception"
that shows a list of exceptions, charts for exceptions over time
and failed requests, and a list of exception types.
View the Application Insights perspective with log search

When you click any item in the dashboard, you see an Application Insights perspective shown in search. The
perspective provides an extended visualization, based on the telemetry type that selected. So, visualization content
changes for different telemetry types.
When you click anywhere in the Applications blade, you see the default Applications perspective.
The perspective shows an overview of the application that you selected.
The Availability blade shows a different perspective view where you can see web test results and related failed
requests.
When you click anywhere in the Server Requests or Failures blades, the perspective components change to give
you a visualization that related to requests.
When you click anywhere in the Exceptions blade, you see a visualization that's tailored to exceptions.
Regardless of whether you click something one the Application Insights Connector dashboard, within the
Search page itself, any query returning Application Insights data shows the Application Insights perspective. For
example, if you are viewing Application Insights data, a * query also shows the perspective tab like the following
image:
Perspective components are updated depending on the search query. This means that you can filter the results by
using any search field that gives you the ability to see the data from:
All your applications
A single selected application
A group of applications
Pivot to an app in the Azure portal
Application Insights Connector blades are designed to enable you to pivot to the selected Application Insights app
when you use the Azure portal. You can use the solution as a high-level monitoring platform that helps you
troubleshoot an app. When you see a potential problem in any of your connected applications, you can either drill
into it in Log Analytics search or you can pivot directly to the Application Insights app.
To pivot, click the ellipses (… ) that appears at the end of each line, and select Open in Application Insights.
NOTE
Open in Application Insights is not available in the Azure portal.
Sample -corrected data

Application Insights provides sampling correction to help reduce telemetry traffic. When you enable sampling on
your Application Insights app, you get a reduced number of entries stored both in Application Insights and in Log
Analytics. While data consistency is preserved in the Application Insights Connector page and perspectives,
you should manually correct sampled data for your custom queries.
Here is an example of sampling correction in a log search query:
ApplicationInsights | summarize AggregatedValue = sum(SampledCount) by TelemetryType
The Sampled Count field is present in all entries and shows the number of data points that the entry represents.
If you turn on sampling for your Application Insights app, Sampled Count is greater than 1. To count the actual
number of entries that your application generates, sum the Sampled Count fields.
Sampling affects only the total number of entries that your application generates. You don't need to correct
sampling for metric fields like RequestDuration or AvailabilityDuration because those fields show the average
for represented entries.
Input data
The solution receives the following telemetry types of data from your connected Application Insights apps:
Availability
Exceptions
Requests
Page views – For your workspace to receive page views, you must configure your apps to collect that
information. Fore more information, see PageViews.
Custom events – For your workspace to receive custom events, you must configure your apps to collect that
information. Fore more information, see TrackEvent.
Data is received by Log Analytics from Application Insights as it becomes available.
Output data
A record with a type of ApplicationInsights is created for each type of input data. ApplicationInsights records have
properties shown in the following sections:
Generic fields
Type ApplicationInsights
ClientIP
TimeGenerated Time of the record
ApplicationId Instrumentation key of the Application Insights app
ApplicationName Name of the Application Insights app
RoleInstance ID of server host
DeviceType Client device
ScreenResolution
Continent Continent where the request originated
Country Country/region where the request originated
Province Province, state, or locale where the request originated
City City or town where the request originated
isSynthetic Indicates whether the request was created by a user or by

automated method. True = automated method or false = user
generated
SamplingRate Percentage of telemetry generated by the SDK that is sent to

portal. Range 0.0-100.0.
SampledCount 100/(SamplingRate). For example, 4 => 25%
IsAuthenticated True or false

OperationID Items that have the same operation ID are shown as Related
Items in the portal. Usually the request ID
ParentOperationID ID of the parent operation
OperationName
SessionId GUID to uniquely identify the session where the request was
created
SourceSystem ApplicationInsights
Availability-specific fields
TelemetryType Availability
AvailabilityTestName Name of the web test
AvailabilityRunLocation Geographic source of http request
AvailabilityResult Indicates the success result of the web test
AvailabilityMessage The message attached to the web test
AvailabilityCount 100/(Sampling Rate). For example, 4 => 25%
DataSizeMetricValue 1.0 or 0.0
DataSizeMetricCount 100/(Sampling Rate). For example, 4 => 25%
AvailabilityDuration Time, in milliseconds, of the web test duration
AvailabilityDurationCount 100/(Sampling Rate). For example, 4 => 25%
AvailabilityValue
AvailabilityMetricCount
AvailabilityTestId Unique GUID for the web test
AvailabilityTimestamp Precise timestamp of the availability test
AvailabilityDurationMin For sampled records, this field shows the minimum web test
duration (milliseconds) for the represented data points
AvailabilityDurationMax For sampled records, this field shows the maximum web test
AvailabilityDurationStdDev For sampled records, this field shows the standard deviation
between all web test durations (milliseconds) for the
represented data points
AvailabilityMin
AvailabilityMax
AvailabilityStdDev
Exception-specific fields
TYPE APPLICATIONINSIGHTS
TelemetryType Exception
ExceptionType Type of the exception
ExceptionMethod The method that creates the exception
ExceptionAssembly Assembly includes the framework and version as well as the

public key token
ExceptionGroup Type of the exception
ExceptionHandledAt Indicates the level that handled the exception
ExceptionCount 100/(Sampling Rate). For example, 4 => 25%
ExceptionMessage Message of the exception
ExceptionStack Full stack of the exception
ExceptionHasStack True, if exception has a stack
Request-specific fields
Type ApplicationInsights
TelemetryType Request
ResponseCode HTTP response sent to client
RequestSuccess Indicates success or failure. True or false.
RequestID ID to uniquely identify the request
RequestName GET/POST + URL base

RequestDuration Time, in seconds, of the request duration
URL URL of the request not including host
Host Web server host
URLBase Full URL of the request
ApplicationProtocol Type of protocol used by the application
RequestCount 100/(Sampling Rate). For example, 4 => 25%
RequestDurationCount 100/(Sampling Rate). For example, 4 => 25%
RequestDurationMin For sampled records, this field shows the minimum request
duration (milliseconds) for the represented data points.
RequestDurationMax For sampled records, this field shows the maximum request
RequestDurationStdDev For sampled records, this field shows the standard deviation
between all request durations (milliseconds) for the
represented data points
Sample log searches

This solution does not have a set of sample log searches shown on the dashboard. However, sample log search
queries with descriptions are shown in the View Application Insights Connector information section.
Removing the connector with PowerShell

With OMS portal deprecation, there is no way to configure and remove existing connections from the portal. You
can remove existing connections with the following PowerShell script. You must be the owner or contributor of the
workspace and reader of Application Insights resource to perform this operation.
$Subscription_app = "App Subscription Name"

$ResourceGroup_app = "App ResourceGroup"
$Application = "Application Name"
$Subscription_workspace = "Workspace Subscription Name"
$ResourceGroup_workspace = "Workspace ResourceGroup"
$Workspace = "Workspace Name"
Connect-AzAccount
Set-AzContext -SubscriptionId $Subscription_app
$AIApp = Get-AzApplicationInsights -ResourceGroupName $ResourceGroup_app -Name $Application
Set-AzContext -SubscriptionId $Subscription_workspace
Remove-AzOperationalInsightsDataSource -WorkspaceName $Workspace -ResourceGroupName $ResourceGroup_workspace -
Name $AIApp.Id
You can retrieve a list of applications using the following PowerShell script that invokes a REST API call.
Connect-AzAccount
$Tenant = "TenantId"
$Subscription_workspace = "Workspace Subscription Name"
$ResourceGroup_workspace = "Workspace ResourceGroup"
$Workspace = "Workspace Name"
$AccessToken = "AAD Authentication Token"
Set-AzContext -SubscriptionId $Subscription_workspace

$LAWorkspace = Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroup_workspace -Name $Workspace
$Headers = @{
"Authorization" = "Bearer $($AccessToken)"
"x-ms-client-tenant-id" = $Tenant
}
$Connections = Invoke-RestMethod -Method "GET" -Uri

"https://management.azure.com$($LAWorkspace.ResourceId)/dataSources/?
%24filter=kind%20eq%20'ApplicationInsights'&api-version=2015-11-01-preview" -Headers $Headers
$ConnectionsJson = $Connections | ConvertTo-Json
This script requires a bearer authentication token for authentication against Azure Active Directory. One way to
retrieve this token is using an article in the REST API documentation site. Click Try It and log into your Azure
subscription. You can copy the bearer token from the Request Preview as shown in the following image.
You can also retrieve a list of applications use a log query:
ApplicationInsights | summarize by ApplicationName
Next steps
Use Log Search to view detailed information for your Application Insights apps.
Monitor Docker applications in Application Insights
(Deprecated)
NOTE
This solution has been deprecated. To learn more about our current investments in container monitoring we recommend
checking out Azure Monitor for containers.
Lifecycle events and performance counters from Docker containers can be charted on Application Insights. Install
the Application Insights image in a container in your host, and it will display performance counters for the host, as
well as for the other images.
With Docker, you distribute your apps in lightweight containers complete with all dependencies. They'll run on any
host machine that runs a Docker Engine.
When you run the Application Insights image on your Docker host, you get these benefits:
Lifecycle telemetry about all the containers running on the host - start, stop, and so on.
Performance counters for all the containers. CPU, memory, network usage, and more.
If you installed Application Insights SDK for Java in the apps running in the containers, all the telemetry of
those apps will have additional properties identifying the container and host machine. So for example, if you
have instances of an app running in more than one host, you can easily filter your app telemetry by host.
Set up your Application Insights resource

1. Sign into Microsoft Azure portal and open the Application Insights resource for your app; or create a new
one.
Which resource should I use? If the apps that you are running on your host were developed by someone
else, then you need to create a new Application Insights resource. This is where you view and analyze the
telemetry. (Select 'General' for the app type.)
But if you're the developer of the apps, then we hope you added Application Insights SDK to each of them.
If they're all really components of a single business application, then you might configure all of them to
send telemetry to one resource, and you'll use that same resource to display the Docker lifecycle and
performance data.
A third scenario is that you developed most of the apps, but you are using separate resources to display
their telemetry. In that case, you probably also want to create a separate resource for the Docker data.
2. Click the Essentials drop-down and copy the Instrumentation Key. You use this to tell the SDK where to
send its telemetry.
Keep that browser window handy, as you'll come back to it soon to look at your telemetry.
Run the Application Insights monitor on your host

Now that you've got somewhere to display the telemetry, you can set up the containerized app that will collect and
send it.
1. Connect to your Docker host.
2. Edit your instrumentation key into this command, and then run it:
docker run -v /var/run/docker.sock:/docker.sock -d microsoft/applicationinsights ikey=000000-1111-2222-

3333-444444444
Only one Application Insights image is required per Docker host. If your application is deployed on multiple
Docker hosts, then repeat the command on every host.
Update your app

If your application is instrumented with the Application Insights SDK for Java, add the following line into the
ApplicationInsights.xml file in your project, under the <TelemetryInitializers> element:
<Add type="com.microsoft.applicationinsights.extensibility.initializer.docker.DockerContextInitializer"/>
This adds Docker information such as container and host id to every telemetry item sent from your app.
View your telemetry

Go back to your Application Insights resource in the Azure portal.
Click through the Docker tile.
You'll shortly see data arriving from the Docker app, especially if you have other containers running on your
Docker engine.
Docker container events
To investigate individual events, click Search. Search and filter to find the events you want. Click any event to get
more detail.
Exceptions by container name
Docker context added to app telemetry

Request telemetry sent from the application instrumented with AI SDK, is enriched with Docker context
information.
Q&A
What does Application Insights give me that I can't get from Docker?
Detailed breakdown of performance counters by container and image.
Integrate container and app data in one dashboard.
Export telemetry for further analysis to a database, Power BI or other dashboard.
How do I get telemetry from the app itself?
Install the Application Insights SDK in the app. Learn how for: Java web apps, Windows web apps.
Video
Next steps
Application Insights for Java
Application Insights for Node.js
Application Insights for ASP.NET
OMS portal moving to Azure
NOTE
This article applies to both the Azure public cloud and government cloud except where noted otherwise.
The OMS portal for the Azure public cloud has been officially retired. The OMS portal for Azure US
Government cloud was officially retired on May 15, 2019. We are excited to move to the Azure portal and
expect the transition to be easy. But we understand changes are difficult and can be disruptive. The rest of this
article goes over the key scenarios and the roadmap for this transition.
The Azure portal is the hub for all Azure services and offers a rich management experience with capabilities such
as dashboards for pinning resources, intelligent search for finding resources, and tagging for resource
management. To consolidate and streamline the monitoring and management workflow, we started adding the
OMS portal capabilities into the Azure portal. All of the features of the OMS portal are now part of the Azure
portal. In fact, some of the new features such as Traffic Analytics are only available in the Azure portal. You will be
able to accomplish everything you were doing in the OMS portal with the Azure portal and more. If you haven’t
already done so, you should start using the Azure portal today!
What is changing?
The following changes are being announced with the deprecation of the OMS portal. Each of these changes is
described in more detail in the sections below.
You can create new workspaces only in the Azure portal.
The new alert management experience replaces the Alert Management solution.
User access management is now done in the Azure portal using Azure role-based access control.
The Application Insights Connector is no longer required since the same functionality is enabled through cross-
workspace queries.
The OMS Mobile App is being deprecated.
The NSG solution is being replaced with enhanced functionality available via Traffic Analytics solution.
New connections from System Center Operations Manager to Log Analytics require updated management
packs.
See Migrate your OMS Update Deployments to Azure for details on changes to Update Management.
What should I do now?

While most features will continue to work without performing any migration, you do need to perform the
following tasks:
You need to migrate your user permissions to the Azure portal.
See Migrate your OMS Update Deployments to Azure for details on transitioning the Update Management
solution.
Refer to Common questions for transition from OMS portal to Azure portal for Log Analytics users for
information about how to transition to the Azure portal.
User access and role migration
Azure portal access management is richer and more powerful than the access management in the OMS Portal.
See Designing your Azure Monitor Logs workspace for details of access management in Log Analytics.
NOTE
Previous versions of this article stated that the permissions would automatically be converted from the OMS portal to the
Azure portal. This automatic conversion is no longer planned, and you must perform the conversion yourself.
You may already have appropriate access in the Azure portal in which case you don't need to make any changes.
There are a couple of cases where you may not have appropriate access in which case your administrator must
assign you permissions.
You have ReadOnly User permissions in the OMS portal but no permissions in the Azure portal.
You have Contributor permissions in the OMS portal but only Reader access in the Azure portal.
In both of these cases, your administrator needs to manually assign you the appropriate role from the following
table. We recommend that you assign this role at the resource group or subscription level. More prescriptive
guidance will be provided shortly for both these cases.
OMS PORTAL PERMISSION AZURE ROLE
ReadOnly Log Analytics Reader
Contributor Log Analytics Contributor
Administrator Owner
New workspaces
You are no longer be able to create new workspaces using the OMS portal. Follow the guidance in Create a Log
Analytics workspace in the Azure portal to create a new workspace in the Azure portal.
Changes to alerts
Alert extension
Alerts have been extended into the Azure portal Existing alerts will continue to be listed in the OMS portal, but
you can only manage them in Azure portal. If you access alerts programmatically by using the Log Analytics Alert
REST API or Log Analytics Alert Resource Template, you'll need to use action groups instead of actions in your
API calls, Azure Resource Manager templates, and PowerShell commands.
Alert management solution
As a change from a previous announcement, the Alert management solution will continue to be available and fully
supported in the Azure portal. You can continue to install the solution from Azure Marketplace.
While the Alert management solution continues to be available, we encourage you to use Azure Monitor's unified
alerting interface to visualize and manage all alerts in Azure. This new experience natively aggregates alerts from
multiple sources within Azure including log alerts from Log Analytics. If you are using Azure Monitor’s unified
alerting interface, then the Alert management solution is only required to enable integration of alerts from System
Center Operation Manager to Azure. In Azure Monitor’s unified alerting interface, you can see distributions of
your alerts, take advantage of automated grouping of related alerts via smart groups, and view alerts across
multiple subscriptions while applying rich filters. Future advancements in alert management will primarily be
available from this new experience.
The data collected by the Alert management solution (records with a type of Alert) continues to be in Log Analytics
as long as the solution is installed for the workspace.
OMS Mobile App

The OMS mobile app will be sunsetted along with the OMS portal. Instead of the OMS mobile app, to access
information about your IT infrastructure, dashboards and saved queries, you can access the Azure portal directly
from your browser in your mobile device. To get alerts, you should configure Azure Action Groups to receive
notifications in the form of SMS or a voice call
Application Insights Connector and solution

Application Insights Connector provides a way to include Application Insights data into a Log Analytics workspace.
This data duplication was required to enable visibility across infrastructure and application data. With Application
Insights extended data retention support in March, 2019 and the ability to perform cross-resource queries in
addition to being able to view multiple Azure Monitor Application Insights resources, there is no need to duplicate
data from your Application Insights resources and send it to Log Analytics. Furthermore, the Connector sends a
subset of the applications properties to Log Analytics, while the cross-resource queries gives you enhanced
flexibility.
As such, Application Insights Connector was deprecated and removed from Azure Marketplace along with OMS
portal deprecation on March 30, 2019. Existing connections will continue to work until June 30, 2019. With OMS
portal deprecation, there is no way to configure and remove existing connections from the portal. This will be
supported using the REST API that will be made available in January, 2019 and a notification will be posted on
Azure updates.
Azure Network Security Group Analytics

The Azure Network Security Group Analytics solution will be replaced with the recently launched Traffic Analytics
which provides visibility into user and application activity on cloud networks. Traffic Analytics helps you audit your
organization's network activity, secure applications and data, optimize workload performance and stay compliant.
This solution analyzes NSG Flow logs and provides insights into the following.
Traffic flows across your networks between Azure and Internet, public cloud regions, VNETs, and subnets.
Applications and protocols on your network, without the need for sniffers or dedicated flow collection
appliances.
Top talkers, chatty applications, VM conversations in the cloud, traffic hotspots.
Sources and destinations of traffic across VNETs, inter-relationships between critical business services and
applications.
Security including malicious traffic, ports open to the Internet, applications or VMs attempting Internet access.
Capacity utilization, which helps you eliminate issues of over provisioning or underutilization.
You can continue to rely on Diagnostics Settings to send NSG logs to Log Analytics so your existing saved
searches, alerts, dashboards will continue to work. Customers who have already installed the solution can continue
to use it until further notice. Starting September 5, the Network Security Group Analytics solution will be removed
from the marketplace and made available through the community as a Azure QuickStart Template.

If you've connected your Operations Manager management group to Log Analytics, then it will continue to work
with no changes. For new connections though, you must follow the guidance in Microsoft System Center
Operations Manager Management Pack to configure Operations Management Suite.
Next steps
See Common questions for transition from OMS portal to Azure portal for Log Analytics users for guidance
on moving from the OMS portal to the Azure portal.
SDK Release Notes - Application Insights
Here are detailed release notes and update instructions for our SDKs:
ASP.NET Web Server SDK
.NET Core SDK
.NET Logging Adapters
ASP.NET Core
Java
JavaScript
Other platforms
Read also our blogs and Service Updates which summarize major improvements in the Application Insights
service as a whole.

Azure PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure PDF

Uploaded by

Copyright:

Available Formats

Contents

Azure Monitor Documentation

Monitoring data platform

What data does Azure Monitor collect?

Azure Monitor for containers

Responding to critical situations

Visualizing monitoring data

Integrate and export data

February 2019 - Log Analytics terminology

August 2018 - Consolidation of monitoring services into Azure Monitor

April 2018 - Retirement of Operations Management Suite brand

Enable Application Insights

Confirm app configuration

Start monitoring in the Azure portal

Sign in to the Azure portal

Enable Application Insights

SETTINGS VALUE DESCRIPTION

Resource Group myResourceGroup Name for the new resource group to

Location East US Choose a location near you, or near

Configure App Insights SDK

2. Click the Get Started button

Start monitoring in the Azure portal

Sign in to the Azure portal

Enable Application Insights

SETTINGS VALUE DESCRIPTION

Application Type Node.js Application Type of app you are monitoring

Location East US Choose a location near you, or near

Configure App Insights SDK

npm install applicationinsights --save

const appInsights = require('applicationinsights');

4. Restart your app.

Start monitoring in the Azure portal

Onboard to App Center

Track events in your app

Create an Application Insights resource

SETTINGS VALUE DESCRIPTION

Export to Application Insights

Start monitoring your app

Sign in to the Azure portal

Enable Application Insights

SETTINGS VALUE DESCRIPTION

Resource Group myResourceGroup Name for the new resource group to

Location East US Choose a location near you, or near

Create an HTML file

Configure App Insights SDK

3. Edit hello_world.html and add your instrumentation key.

// average pageView duration by name

Sign in to Azure portal

Enable the Log Analytics VM Extension

Collect event and performance data

2. Select Data, and then select Windows Event Logs.

View data collected

Sign in to the Azure portal

Obtain workspace ID and key

Install the agent for Linux

3. Restart the agent by running the following command:

sudo /opt/microsoft/omsagent/bin/service_control restart [<workspace id>]

Collect event and performance data

View data collected

Sign in to Azure portal

Get the workspace ID and key

Install the agent for Windows

3. Select Data, and then select Windows Event Logs.