-Under the */Controllers* folder, add a *PublicController.cs* file, and then add to it the following code snippet:

-Under the */Controllers* folder, add a *HelloController.cs* file, and then add to it the following code:

-Under the project root folder, create a *config.json* file, and then add to it the following JSON snippet:

-description: Tutorial to configure Azure Active Directory B2C with Azure Web application firewall to protect your applications from malicious attacks

-# Tutorial: Configure Azure Web Application Firewall with Azure Active Directory B2C

-In this sample tutorial, learn how to enable [Azure Web Application Firewall (WAF)](https://azure.microsoft.com/services/web-application-firewall/#overview) solution for Azure Active Directory (AD) B2C tenant with custom domain. Azure WAF provides centralized protection of your web applications from common exploits and vulnerabilities.

->[!NOTE]

->This feature is in public preview.

-To get started, you'll need:

-## Azure AD B2C setup

-To use custom domains in Azure AD B2C, it's required to use custom domain feature provided by AFD. Learn how to [enable Azure AD B2C custom domains](./custom-domain.md?pivots=b2c-user-flow).

-After custom domain for Azure AD B2C is successfully configured using AFD, [test the custom domain](./custom-domain.md?pivots=b2c-custom-policy#test-your-custom-domain) before proceeding further.

-## Onboard with Azure WAF

-To enable Azure WAF, configure a WAF policy and associate that policy to the AFD for protection.

-Create a basic WAF policy with managed Default Rule Set (DRS) in the [Azure portal](https://portal.azure.com).

-1. Go to the [Azure portal](https://portal.azure.com). Select **Create a resource** and then search for Azure WAF. Select **Azure Web Application Firewall (WAF)** > **Create**.

-2. Go to the **Create a WAF policy** page, select the **Basics** tab. Enter the following information, accept the defaults for the remaining settings.

-| Value | Description |

-|:--|:-|

-| Policy for | Global WAF (Front Door)|

-| Front Door SKU | Select between Basic, Standard, or Premium SKU |

-|Subscription | Select your Front Door subscription name |

-| Resource group | Select your Front Door resource group name |

-| Policy name | Enter a unique name for your WAF policy |

-| Policy state | Set as Enabled |

-| Policy mode | Set as Detection |

-3. Select **Review + create**

-4. Go to the **Association** tab of the Create a WAF policy page, select + **Associate a Front Door profile**, enter the following settings

-| Value | Description |

-|:-|:|

-| Front Door | Select your Front Door name associated with Azure AD B2C custom domain |

-| Domains | Select the Azure AD B2C custom domains you want to associate the WAF policy to|

-5. Select **Add**.

-6. Select **Review + create**, then select **Create**.

-### Change policy mode from detection to prevention

-When a WAF policy is created, by default the policy is in Detection mode. In Detection mode, WAF doesn't block any requests, instead, requests matching the WAF rules are logged in the WAF logs. For more information about WAF logging, see [Azure WAF monitoring and logging](../web-application-firewall/afds/waf-front-door-monitor.md).

-The sample query shows all the requests that were blocked by the WAF policy in the past 24 hours. The details include, rule name, request data, action taken by the policy, and the policy mode.

-

-

-It's recommended that you let the WAF capture requests in Detection mode. Review the WAF logs to determine if there are any rules in the policy that are causing false positive results. Then after [exclude the WAF rules based on the WAF logs](../web-application-firewall/afds/waf-front-door-exclusion.md#define-exclusion-based-on-web-application-firewall-logs).

-To see WAF in action, use Switch to prevention mode to change from Detection to Prevention mode. All requests that match the rules defined in the Default Rule Set (DRS) are blocked and logged in the WAF logs.

-

-In case you want to switch back to the detection mode, you can do so by using Switch to detection mode option.

-

-* The Azure AD Provisioning Service makes the /schemas request every time someone saves the provisioning configuration in the Azure portal or every time a user lands on the edit provisioning page in the Azure portal. Other attributes discovered are surfaced to customers in the attribute mappings under the target attribute list. Schema discovery only leads to more target attributes being added. Attributes aren't removed.

-* Users can be queried by `userName` or `emails[type eq "work"]` attributes.

-* Groups shall always be created with an empty members list.

-* Groups can be queried by the `displayName` attribute.

-The open source .NET Core [reference code example](https://aka.ms/SCIMReferenceCode) published by the Azure AD provisioning team is one such resource that can jump start your development. Once you have built your SCIM endpoint, you'll want to test it out. You can use the collection of [Postman tests](https://github.com/AzureAD/SCIMReferenceCode/wiki/Test-Your-SCIM-Endpoint) provided as part of the reference code or run through the sample requests / responses provided [above](#user-operations).

-The .NET Core SDK includes an HTTPS development certificate that can be used during development, the certificate is installed as part of the first-run experience. Depending on how you run the ASP.NET Core Web Application it will listen to a different port:

-If you're building an application that will be used by more than one tenant, you can make it available in the Azure AD application gallery. It's easy for organizations to discover the application and configure provisioning. Publishing your app in the Azure AD gallery and making provisioning available to others is easy. Check out the steps [here](../manage-apps/v2-howto-app-gallery-listing.md). Microsoft will work with you to integrate your application into our gallery, test your endpoint, and release onboarding [documentation](../saas-apps/tutorial-list.md) for customers to use.

-Use the checklist to onboard your application quickly and customers have a smooth deployment experience. The information will be gathered from you when onboarding to the gallery.

-**Long-lived OAuth bearer tokens:** If your application doesn't support the OAuth authorization code grant flow, instead generate a long lived OAuth bearer token that an administrator can use to set up the provisioning integration. The token should be perpetual, or else the provisioning job will be [quarantined](application-provisioning-quarantine-status.md) when the token expires.

-You can specify the lifetime of a access, ID, or SAML token issued by the Microsoft identity platform. You can set token lifetimes for all apps in your organization, for a multi-tenant (multi-organization) application, or for a specific service principal in your organization. However, we currently do not support configuring the token lifetimes for [managed identity service principals](../managed-identities-azure-resources/overview.md).

-In Azure AD, a policy object represents a set of rules that are enforced on individual applications or on all applications in an organization. Each policy type has a unique structure, with a set of properties that are applied to objects to which they are assigned.

-You can designate a policy as the default policy for your organization. The policy is applied to any application in the organization, as long as it is not overridden by a policy with a higher priority. You also can assign a policy to specific applications. The order of priority varies by policy type.

-Non-persistent session tokens have a Max Inactive Time of 24 hours whereas persistent session tokens have a Max Inactive Time of 90 days. Any time the SSO session token is used within its validity period, the validity period is extended another 24 hours or 90 days. If the SSO session token is not used within its Max Inactive Time period, it is considered expired and will no longer be accepted. Any changes to this default periods should be change using [Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md).

-* If a policy is explicitly assigned to the service principal, it is enforced.

-3. Under **Manage**, select **Branding**.

-1. Navigating to the **App Registrations** section and select your app.

-4. Save your changes.

-To programmatically update all your apps, you can use the Microsoft Graph API to update all your apps to include links to the terms of service and privacy statement documents.

-PATCH https://graph.microsoft.com/v1.0/applications/{application id}

-    "appId": "{your application id}",

-The example sleeps for 20 seconds to allow some time for the new service principal to propagate throughout Azure AD. If your script doesn't wait long enough, you'll see an error stating: "Principal {ID} does not exist in the directory {DIR-ID}." To resolve this error, wait a moment then run the **New-AzRoleAssignment** command again.

-Wildcard URIs like `https://*.contoso.com` may seem convenient, but should be avoided due to security implications. According to the OAuth 2.0 specification ([section 3.1.2 of RFC 6749](https://tools.ietf.org/html/rfc6749#section-3.1.2)), a redirection endpoint URI must be an absolute URI.

-Applications that integrate with Microsoft identity platform require directory objects (such as app registrations, service principals, groups, and users) to be created and managed in an Azure AD tenant. Any production tenant settings that affect your app's behavior should be replicated in the test tenant. Populate your test tenant with the needed conditional access, permission grant, claims mapping, token lifetime, and token issuance policies. Your application may also use Azure resources such as compute or storage, which need to be added to the test environment. Your test environment may require a lot of resources, depending on the app to be tested.

-| Resources | <ul><li>A maximum of 50,000 Azure AD resources can be created in a single tenant by users of the Free edition of Azure Active Directory by default. If you have at least one verified domain, the default Azure AD service quota for your organization is extended to 300,000 Azure AD resources. Azure AD service quota for organizations created by self-service sign-up remains 50,000 Azure AD resources even after you performed an internal admin takeover and the organization is converted to a managed tenant with at least one verified domain. This service limit is unrelated to the pricing tier limit of 500,000 resources on the Azure AD pricing page. To go beyond the default quota, you must contact Microsoft Support.</li><li>A non-admin user can create no more than 250 Azure AD resources. Both active resources and deleted resources that are available to restore count toward this quota. Only deleted Azure AD resources that were deleted fewer than 30 days ago are available to restore. Deleted Azure AD resources that are no longer available to restore count toward this quota at a value of one-quarter for 30 days. If you have developers who are likely to repeatedly exceed this quota in the course of their regular duties, you can create and assign a custom role with permission to create a limitless number of app registrations.</li></ul>|

- * [Connect Azure AD Identity Protection data to Microsoft Sentinel](../../sentinel/data-connectors-reference.md#azure-active-directory-identity-protection)

-If done via the Azure portal, the new version is created automatically. If done using Microsoft Graph, you will have to manually create a new version of the workflow. For more information, see [Edit the properties of a workflow using Microsoft Graph](#edit-the-properties-of-a-workflow-using-microsoft-graph).

-To edit the properties of a workflow using the Azure portal, you'll do the following steps:

-1. Here you'll see a list of all of your current workflows. Select the workflow that you want to edit.

-Organizations can choose to [connect Azure AD data to Microsoft Sentinel](../../sentinel/data-connectors-reference.md#azure-active-directory-identity-protection) as well for further processing.

-Information about integrating Identity Protection information with Microsoft Sentinel can be found in the article, [Connect data from Azure AD Identity Protection](../../sentinel/data-connectors-reference.md#azure-active-directory-identity-protection).

-MFA enables you to enhance the security posture of your tenant. While enabling MFA is a good practice, you should try to keep the number of MFA prompts your users have to go through at a minimum. One option you have to accomplish this goal is to **allow users to remember multi-factor authentication on devices they trust**.

-The remember multi-factor authentication feature sets a persistent cookie on the browser when a user selects the Don't ask again for X days option at sign-in. The user isn't prompted again for MFA from that browser until the cookie expires. If the user opens a different browser on the same device or clears the cookies, they're prompted again to verify.

-

-## Logic

-This recommendation shows up, if you have set the remember multi-factor authentication feature to less than 30 days.

-1. Review [configure Azure AD Multi-Factor Authentication settings](../authentication/howto-mfa-mfasettings.md).

-2. Set the remember multi-factor authentication feature to 90 days.

-

-As an admin responsible for managing applications, I want my applications to use Azure ADΓÇÖs security features and maximize their value.

-## Logic

-If a tenant has apps on AD FS, and any of these apps are deemed 100% migratable, this recommendation shows up.

-Multi-factor authentication (MFA) is a key component to improve the security posture of your Azure AD tenant. However, while keeping your tenant safe is important, you should also keep an eye on keeping the security related overhead as little as possible on your users.

-One possibility to accomplish this goal is to migrate users using SMS or voice call for MFA to use the Microsoft authenticator app.

-

-1. Go to **Azure AD** > **App registration** and locate the application that was surfaced as part of this recommendation.

- >`<YOUR-SUBDOMAIN>` is the subdomain your organization has chosen to access Ardoq. This is the same URL segment you use when you access the Ardoq app. For example, if your organization accesses Ardoq at `https://acme.ardoq.com` you'd fill in `acme. If you're in the US and access Ardoq at `https://piedpiper.us.ardoq.com` then you'd fill in `piedpiper.us`.

-AKS now supports an exclusive channel dedicated to controlling node-level OS security updates. This channel, referred to as the node OS auto-upgrade channel, works in tandem with the existing [Autoupgrade][auto-upgrade] channel which is used for Kubernetes version upgrades.

-| `SecurityPatch`|AKS will update the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only" on a regular basis. Where possible, patches will also be applied without disruption to existing nodes. Some patches, such as kernel patches, can't be applied to existing nodes without disruption. For such patches, the VHD will be updated and existing machines will be upgraded to that VHD following maintenance windows and surge settings. This option incurs the extra cost of hosting the VHDs in your node resource group.|N/A|

-> [!NOTE]

-> Azure CNI Overlay is currently **_unavailable_** in the **West US** region. All other public regions are supported.

-Pod to pod traffic with Azure CNI Overlay is not encapsulated and subnet [network security group][nsgs] rules are applied. If the subnet NSG contains deny rules that would impact the pod CIDR traffic, make sure the following rules are in place to ensure proper cluster functionality (in addition to all [AKS egress requirements][aks-egress]):

-[nsg]: /azure/virtual-network/network-security-groups-overview

-# Monitoring Azure Kubernetes Service (AKS) with Azure Monitor

-This scenario describes how to use Azure Monitor to monitor the health and performance of Azure Kubernetes Service (AKS). It includes collection of telemetry critical for monitoring, analysis and visualization of collected data to identify trends, and how to configure alerting to be proactively notified of critical issues.

-The [Cloud Monitoring Guide](/azure/cloud-adoption-framework/manage/monitor/) defines the [primary monitoring objectives](/azure/cloud-adoption-framework/strategy/monitoring-strategy#formulate-monitoring-requirements) you should focus on for your Azure resources. This scenario focuses on Health and Status monitoring using Azure Monitor.

-This scenario is intended for customers using Azure Monitor to monitor AKS. It does not include the following, although this content may be added in subsequent updates to the scenario.

-> For information on using the security services to monitor AKS, see [Microsoft Defender for Kubernetes - the benefits and features](../defender-for-cloud/defender-for-kubernetes-introduction.md) and [Connect Azure Kubernetes Service (AKS) diagnostics logs to Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-kubernetes-service-aks).

-## Container insights

-AKS generates [platform metrics and resource logs](monitor-aks-reference.md), like any other Azure resource, that you can use to monitor its basic health and performance. Enable [Container insights](../azure-monitor/containers/container-insights-overview.md) to expand on this monitoring. Container insights is a feature in Azure Monitor that monitors the health and performance of managed Kubernetes clusters hosted on AKS in addition to other cluster configurations. Container insights provides interactive views and workbooks that analyze collected data for a variety of monitoring scenarios.

-[Prometheus](https://aka.ms/azureprometheus-promio) and [Grafana](https://aka.ms/azureprometheus-promio-grafana) are CNCF backed widely popular open source tools for kubernetes monitoring. AKS exposes many metrics in Prometheus format which makes Prometheus a popular choice for monitoring. [Container insights](../azure-monitor/containers/container-insights-overview.md) has native integration with AKS, collecting critical metrics and logs, alerting on identified issues, and providing visualization with workbooks. It also collects certain Prometheus metrics, and many native Azure Monitor Insights are built-up on top of Prometheus metrics. Container insights complements and completes E2E monitoring of AKS including log collection which Prometheus as stand-alone tool doesnΓÇÖt provide. Many customers use Prometheus integration and Azure Monitor together for E2E monitoring.

-Learn more about using Container insights at [Container insights overview](../azure-monitor/containers/container-insights-overview.md). [Monitor layers of AKS with Container insights](#monitor-layers-of-aks-with-container-insights) below introduces various features of Container insights and the monitoring scenarios that they support.

-You require at least one Log Analytics workspace to support Container insights and to collect and analyze other telemetry about your AKS cluster. There is no cost for the workspace, but you do incur ingestion and retention costs when you collect data. See [Azure Monitor Logs pricing details](../azure-monitor/logs/cost-logs.md) for details.

-If you're just getting started with Azure Monitor, then start with a single workspace and consider creating additional workspaces as your requirements evolve. Many environments will use a single workspace for all the Azure resources they monitor. You can even share a workspace used by [Microsoft Defender for Cloud and Microsoft Sentinel](../azure-monitor/vm/monitor-virtual-machine-security.md), although many customers choose to segregate their availability and performance telemetry from security data.

-See [Designing your Azure Monitor Logs deployment](../azure-monitor/logs/workspace-design.md) for details on logic that you should consider for designing a workspace configuration.

-### Enable container insights

-When you enable Container insights for your AKS cluster, it deploys a containerized version of the [Log Analytics agent](../agents/../azure-monitor/agents/log-analytics-agent.md) that sends data to Azure Monitor. There are multiple methods to enable it depending whether you're working with a new or existing AKS cluster. See [Enable Container insights](../azure-monitor/containers/container-insights-onboard.md) for prerequisites and configuration options.

-Container insights allows you to send Prometheus metrics to [Azure Monitor managed service for Prometheus](../azure-monitor/essentials/prometheus-metrics-overview.md) or to your Log Analytics workspace without requiring a local Prometheus server. You can analyze this data using Azure Monitor features along with other data collected by Container insights. See [Collect Prometheus metrics with Container insights](../azure-monitor/containers/container-insights-prometheus.md) for details on this configuration.

-The logs for AKS control plane components are implemented in Azure as [resource logs](../azure-monitor/essentials/resource-logs.md). Container insights doesn't currently use these logs, so you do need to create your own log queries to view and analyze them. See [How to query logs from Container insights](../azure-monitor/containers/container-insights-log-query.md#resource-logs) for details on the structure of these logs and how to write queries for them.

-You need to create a diagnostic setting to collect resource logs. Create multiple diagnostic settings to send different sets of logs to different locations. See [Create diagnostic settings to send platform logs and metrics to different destinations](../azure-monitor/essentials/diagnostic-settings.md) to create diagnostic settings for your AKS cluster.

-There is a cost for sending resource logs to a workspace, so you should only collect those log categories that you intend to use. Send logs to an Azure storage account to reduce costs if you need to retain the information but don't require it to be readily available for analysis. See [Resource logs](monitor-aks-reference.md#resource-logs) for a description of the categories that are available for AKS and See [Azure Monitor Logs pricing details](../azure-monitor/logs/cost-logs.md) for details on the cost of ingesting and retaining log data. Start by collecting a minimal number of categories and then modify the diagnostic setting to collect additional categories as your needs increase and as you understand your associated costs.

-If you're unsure about which resource logs to initially enable, use the recommendations in the following table which are based on the most common customer requirements. Enable the other categories if you later find that you require this information.

-Access Azure Monitor features for all AKS clusters in your subscription from the **Monitoring** menu in the Azure portal or for a single AKS cluster from the **Monitor** section of the **Kubernetes services** menu. The screenshot below shows the cluster's **Monitor** menu.

-| Insights | Opens container insights for the current cluster. Select **Containers** from the **Monitor** menu to open container insights for all clusters. |

-## Monitor layers of AKS with Container insights

-Because of the wide variance in Kubernetes implementations, each customer will have unique requirements for AKS monitoring. The approach you take should be based on factors including scale, topology, organizational roles, and multi-cluster tenancy. This section presents a common strategy that is a bottoms-up approach starting from infrastructure up through applications. Each layer has distinct monitoring requirements. These layers are illustrated in the following diagram and discussed in more detail in the following sections.

-Cluster level includes the following components.

-Use existing views and reports in Container Insights to monitor cluster level components. The **Cluster** view gives you a quick view of the performance of the nodes in your cluster including their CPU and memory utilization. Use the **Nodes** view to view the health of each node in addition to the health and performance of the pods running on each. See [Monitor your Kubernetes cluster performance with Container insights](../azure-monitor/containers/container-insights-analyze.md) for details on using this view and analyzing node health and performance. Use the **Subnet IP Usage** view under workbooks to get a quick view of the IP allocation and assignment on each node for a selected time-range.

-Use **Node** workbooks in Container Insights to analyze disk capacity and IO in addition to GPU usage. See [Node Monitoring workbooks](../azure-monitor/containers/container-insights-reports.md#node-monitoring-workbooks) for a description of these workbooks.

-For troubleshooting scenarios, you may need to access the AKS nodes directly for maintenance or immediate log collection. For security purposes, the AKS nodes aren't exposed to the internet but you can `kubectl debug` to SSH to the AKS nodes. See [Connect with SSH to Azure Kubernetes Service (AKS) cluster nodes for maintenance or troubleshooting](ssh.md) for details on this process.

-Managed AKS level includes the following components.

-| API Server | Monitor the status of API server, identifying any increase in request load and bottlenecks if the service is down. |

-| Kubelet | Monitoring Kubelet helps in troubleshooting of pod management issues, pods not starting, nodes not ready or pods getting killed. |

-Azure Monitor and container insights don't yet provide full monitoring for the API server. You can use metrics explorer to view the **Inflight Requests** counter, but you should refer to metrics in Prometheus for a complete view of API Server performance. This includes such values as request latency and workqueue processing time. A Grafana dashboard that provides views of the critical metrics for the API server is available at [Grafana Labs](https://grafana.com/grafan)

-Use the **Kubelet** workbook to view the health and performance of each kubelet. See [Resource Monitoring workbooks](../azure-monitor/containers/container-insights-reports.md#resource-monitoring-workbooks) for details on this workbook. For troubleshooting scenarios, you can access kubelet logs using the process described at [Get kubelet logs from Azure Kubernetes Service (AKS) cluster nodes](kubelet-logs.md).

-Use [log queries with resource logs](../azure-monitor/containers/container-insights-log-query.md#resource-logs) to analyze control plane logs generated by AKS components.

-Kubernetes objects and workloads level include the following components.

-| Deployments | Monitor actual vs desired state of the deployment and the status and resource utilization of the pods running on them. |

-| Containers | Monitor the resource utilization, including CPU and memory, of the containers running on your AKS cluster. |

-Use existing views and reports in Container Insights to monitor containers and pods. Use the **Nodes** and **Controllers** views to view the health and performance of the pods running on them and drill down to the health and performance of their containers. View the health and performance for containers directly from the **Containers** view. See [Monitor your Kubernetes cluster performance with Container insights](../azure-monitor/containers/container-insights-analyze.md) for details on using this view and analyzing container health and performance.

-Use the **Deployment** workbook in Container insights to view metrics collected for deployments. See [Deployment & HPA metrics with Container insights](../azure-monitor/containers/container-insights-deployment-hpa-metrics.md) for details.

-> [!NOTE]

-> Deployments view in Container insights is currently in public preview.

-In troubleshooting scenarios, Container insights provides access to live AKS container logs (stdout/stderror), events, and pod metrics. See [How to view Kubernetes logs, events, and pod metrics in real-time](../azure-monitor/containers/container-insights-livedata-overview.md) for details on using this feature.

-### Level 4- Applications

-The application level includes the application workloads running in the AKS cluster.

-| Applications | Monitor microservice application deployments to identify application failures and latency issues. Includes such information as request rates, response times, and exceptions. |

-Application Insights provides complete monitoring of applications running on AKS and other environments. If you have a Java application, you can provide monitoring without instrumenting your code following [Zero instrumentation application monitoring for Kubernetes - Azure Monitor Application Insights](../azure-monitor/app/kubernetes-codeless.md). For complete monitoring though, you should configure code-based monitoring depending on your application.

-See [What is Application Insights?](../azure-monitor/app/app-insights-overview.md)

-### Level 5- External components

-Components external to AKS include the following.

-Monitor external components such as Service Mesh, Ingress, Egress with Prometheus and Grafana or other proprietary tools. Monitor databases and other Azure resources using other features of Azure Monitor.

-## Analyze metric data with metrics explorer

-Use metrics explorer when you want to perform custom analysis of metric data collected for your containers. Metrics explorer allows you plot charts, visually correlate trends, and investigate spikes and dips in metrics' values. Create a metrics alert to proactively notify you when a metric value crosses a threshold, and pin charts to dashboards for use by different members of your organization.

-See [Getting started with Azure Metrics Explorer](../azure-monitor/essentials/metrics-getting-started.md) for details on using this feature. For a list of the platform metrics collected for AKS, see [Monitoring AKS data reference metrics](monitor-aks-reference.md#metrics). When Container insights is enabled for a cluster, [addition metric values](../azure-monitor/containers/container-insights-update-metrics.md) are available.

-Use Log Analytics when you want to analyze resource logs or dig deeper into the data used to create the views in Container insights. Log Analytics allows you to perform custom analysis of your log data.

-See [How to query logs from Container insights](../azure-monitor/containers/container-insights-log-query.md) for details on using log queries to analyze data collected by Container insights. See [Using queries in Azure Monitor Log Analytics](../azure-monitor/logs/queries.md) for information on using these queries and [Log Analytics tutorial](../azure-monitor/logs/log-analytics-tutorial.md) for a complete tutorial on using Log Analytics to run queries and work with their results.

-For a list of the tables collected for AKS that you can analyze in metrics explorer, see [Monitoring AKS data reference logs](monitor-aks-reference.md#azure-monitor-logs-tables).

-In addition to Container insights data, you can use log queries to analyze resource logs from AKS. For a list of the log categories available, see [AKS data reference resource logs](monitor-aks-reference.md#resource-logs). You must create a diagnostic setting to collect each category as described in [Configure monitoring](#configure-monitoring) before that data will be collected.

-[Alerts in Azure Monitor](../azure-monitor/alerts/alerts-overview.md) proactively notify you of interesting data and patterns in your monitoring data. They allow you to identify and address issues in your system before your customers notice them. There are no preconfigured alert rules for AKS clusters, but you can create your own based on data collected by Container insights.

-> Most alert rules have a cost that's dependent on the type of rule, how many dimensions it includes, and how frequently it's run. Refer to **Alert rules** in [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/) before you create any alert rules.

-### Choosing the alert type

-The most common types of alert rules in Azure Monitor are [metric alerts](../azure-monitor/alerts/alerts-metric.md) and [log query alerts](../azure-monitor/alerts/alerts-log-query.md). The type of alert rule that you create for a particular scenario will depend on where the data is located that you're alerting on. You may have cases though where data for a particular alerting scenario is available in both Metrics and Logs, and you need to determine which rule type to use.

-It's typically the best strategy to use metric alerts instead of log alerts when possible since they're more responsive and stateful. You can create a metric alert on any values you can analyze in metrics explorer. If the logic for your alert rule requires data in Logs, or if it requires more complex logic, then you can use a log query alert rule.

-For example, if you want to alert when an application workload is consuming excessive CPU then you can create a metric alert using the CPU metric. If you need an alert when a particular message is found in a control plane log, then you'll require a log alert.

-Metric alert rules use the same metric values as metrics explorer. In fact, you can create an alert rule directly from metrics explorer with the data you're currently analyzing. You can use any of the values in [AKS data reference metrics](monitor-aks-reference.md#metrics) for metric alert rules.

-Container insights includes a feature in public preview that creates a recommended set of metric alert rules for your AKS cluster. This feature creates new metric values (also in preview) used by the alert rules that you can also use in metrics explorer. See [Recommended metric alerts (preview) from Container insights](../azure-monitor/containers/container-insights-metric-alerts.md) for details on this feature and on creating metric alerts for AKS.

-### Log alerts rules

-Use log alert rules to generate an alert from the results of a log query. This may be data collected by Container insights or from AKS resource logs. See [How to create log alerts from Container insights](../azure-monitor/containers/container-insights-log-alerts.md) for details on log alert rules for AKS and a set of sample queries designed for alert rules. You can also refer to [How to query logs from Container insights](../azure-monitor/containers/container-insights-log-query.md) for details on log queries that could be modified for alert rules.

-For those conditions where Azure Monitor either doesn't have the data required for an alerting condition, or where the alerting may not be responsive enough, you should configure alerts in Prometheus. One example is alerting for the API server. Azure Monitor doesn't collect critical information for the API server including whether it's available or experiencing a bottleneck. You can create a log query alert using the data from the kube-apiserver resource log category, but this can take up to several minutes before you receive an alert which may not be sufficient for your requirements.

-> When you upgrade an AKS cluster, extra resources are temporarily consumed. These resources include available IP addresses in a virtual network subnet or virtual machine vCPU quota.

-VM sizes with less than 2 CPUs may not be used with AKS.

-Each node in an AKS cluster contains a fixed amount of compute resources such as vCPU and memory. If an AKS node contains insufficient compute resources, pods might fail to run correctly. To ensure the required *kube-system* pods and your applications can be reliably scheduled, AKS requires nodes use VM sizes with at least 2 CPUs.

-AKS defines a generally available version as a version enabled in all SLO or SLA measurements and available in all regions. AKS supports three GA minor versions of Kubernetes:

-## AKS Kubernetes release calendar

-> [!NOTE]

-> AKS follows 12 months of support for a GA Kubernetes version. To read more about our support policy for Kubernetes versioning, please read our [FAQ](https://learn.microsoft.com/azure/aks/supported-kubernetes-versions?tabs=azure-cli#faq).

-For the past release history, see [Kubernetes](https://en.wikipedia.org/wiki/Kubernetes#History).

-| K8s version | Upstream release | AKS preview | AKS GA | End of life |

-|--|-|--||-|

-| 1.22 | Aug-04-21 | Sept 2021 | Dec 2021 | Dec 2022 |

-| 1.23 | Dec 2021 | Jan 2022 | Apr 2022 | Apr 2023 |

-| 1.24 | Apr-22-22 | May 2022 | Jul 2022 | Jul 2023

-| 1.25 | Aug 2022 | Oct 2022 | Dec 2022 | Dec 2023

-| 1.26 | Dec 2022 | Feb 2023 | Mar 2023 | Mar 2024

-| 1.27 | Apr 2023 | May 2023 | Jun 2023 | Jun 2024

-> [!NOTE]

-> To see real-time updates of region release status and version release notes, visit the [AKS release status webpage][aks-release]. To learn more about the release status webpage, see [AKS release tracker][aks-tracker].

-For a system node pool, AKS automatically assigns the label **kubernetes.azure.com/mode: system** to its nodes. This causes AKS to prefer scheduling system pods on node pools that contain this label. This label doesn't prevent you from scheduling application pods on system node pools. However, we recommend you isolate critical system pods from your application pods to prevent misconfigured or rogue application pods from accidentally killing system pods.

-You can add one or more system node pools to existing AKS clusters. It's recommended to schedule your application pods on user node pools, and dedicate system node pools to only critical system pods. This prevents rogue application pods from accidentally killing system pods. Enforce this behavior with the `CriticalAddonsOnly=true:NoSchedule` [taint][aks-taints] for your system node pools.

-You can check the details of your node pool with the following command.

-[Azure App Service](overview.md) provides a highly scalable, self-patching web hosting service. In addition, App Service has built-in support for [user authentication and authorization](overview-authentication-authorization.md). This tutorial shows how to secure your apps with App Service authentication and authorization. It uses a ASP.NET Core app with an Angular.js front end as an example. App Service authentication and authorization support all language runtimes, and you can learn how to apply it to your preferred language by following the tutorial.

-[Azure App Service](overview.md) provides a highly scalable, self-patching web hosting service using the Linux operating system. In addition, App Service has built-in support for [user authentication and authorization](overview-authentication-authorization.md). This tutorial shows how to secure your apps with App Service authentication and authorization. It uses an ASP.NET Core app with an Angular.js front end as an example. App Service authentication and authorization support all language runtimes, and you can learn how to apply it to your preferred language by following the tutorial.

-

-It also shows you how to secure a multi-tiered app, by accessing a secured back-end API on behalf of the authenticated user, both [from server code](#call-api-securely-from-server-code) and [from browser code](#call-api-securely-from-browser-code).

-

-These are only some of the possible authentication and authorization scenarios in App Service.

-Here's a more comprehensive list of things you learn in the tutorial:

-You can follow the steps in this tutorial on macOS, Linux, Windows.

-## Prerequisites

-To complete this tutorial:

-## Create local .NET Core app

-In this step, you set up the local .NET Core project. You use the same project to deploy a back-end API app and a front-end web app.

-### Clone and run the sample application

-1. Run the following commands to clone the sample repository and run it.

- ```bash

- git clone https://github.com/Azure-Samples/dotnet-core-api

- cd dotnet-core-api

- dotnet run

- ```

-

-1. Navigate to `http://localhost:5000` and try adding, editing, and removing todo items.

- 

-1. To stop ASP.NET Core, press `Ctrl+C` in the terminal.

-1. Make sure the default branch is `main`.

- ```bash

- git branch -m main

-

- > [!TIP]

- > The branch name change isn't required by App Service. However, since many repositories are changing their default branch to `main`, this tutorial also shows you how to deploy a repository from `main`. For more information, see [Change deployment branch](deploy-local-git.md#change-deployment-branch).

-## Deploy apps to Azure

-In this step, you deploy the project to two App Service apps. One is the front-end app and the other is the back-end app.

-### Configure a deployment user

-### Create Azure resources

-In the Cloud Shell, run the following commands to create two Windows web apps. Replace _\<front-end-app-name>_ and _\<back-end-app-name>_ with two globally unique app names (valid characters are `a-z`, `0-9`, and `-`). For more information on each command, see [Host a RESTful API with CORS in Azure App Service](app-service-web-tutorial-rest-api.md).

-```azurecli-interactive

-az group create --name myAuthResourceGroup --location "West Europe"

-az appservice plan create --name myAuthAppServicePlan --resource-group myAuthResourceGroup --sku FREE

-az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <front-end-app-name> --deployment-local-git --query deploymentLocalGitUrl

-az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <back-end-app-name> --deployment-local-git --query deploymentLocalGitUrl

-```

-In the Cloud Shell, run the following commands to create two web apps. Replace _\<front-end-app-name>_ and _\<back-end-app-name>_ with two globally unique app names (valid characters are `a-z`, `0-9`, and `-`). For more information on each command, see [Create a .NET Core app in Azure App Service](quickstart-dotnetcore.md).

-```azurecli-interactive

-az group create --name myAuthResourceGroup --location "West Europe"

-az appservice plan create --name myAuthAppServicePlan --resource-group myAuthResourceGroup --sku FREE --is-linux

-az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <front-end-app-name> --runtime "DOTNETCORE|3.1" --deployment-local-git --query deploymentLocalGitUrl

-az webapp create --resource-group myAuthResourceGroup --plan myAuthAppServicePlan --name <back-end-app-name> --runtime "DOTNETCORE|3.1" --deployment-local-git --query deploymentLocalGitUrl

-```

-> [!NOTE]

-> Save the URLs of the Git remotes for your front-end app and back-end app, which are shown in the output from `az webapp create`.

->

-### Push to Azure from Git

-1. Since you're deploying the `main` branch, you need to set the default deployment branch for your two App Service apps to `main` (see [Change deployment branch](deploy-local-git.md#change-deployment-branch)). In the Cloud Shell, set the `DEPLOYMENT_BRANCH` app setting with the [`az webapp config appsettings set`](/cli/azure/webapp/config/appsettings#az-webapp-config-appsettings-set) command.

- az webapp config appsettings set --name <front-end-app-name> --resource-group myAuthResourceGroup --settings DEPLOYMENT_BRANCH=main

- az webapp config appsettings set --name <back-end-app-name> --resource-group myAuthResourceGroup --settings DEPLOYMENT_BRANCH=main

-1. Back in the _local terminal window_, run the following Git commands to deploy to the back-end app. Replace _\<deploymentLocalGitUrl-of-back-end-app>_ with the URL of the Git remote that you saved from [Create Azure resources](#create-azure-resources). When prompted for credentials by Git Credential Manager, make sure that you enter [your deployment credentials](deploy-configure-credentials.md), not the credentials you use to sign in to the Azure portal.

- ```bash

- git remote add backend <deploymentLocalGitUrl-of-back-end-app>

- git push backend main

-1. In the local terminal window, run the following Git commands to deploy the same code to the front-end app. Replace _\<deploymentLocalGitUrl-of-front-end-app>_ with the URL of the Git remote that you saved from [Create Azure resources](#create-azure-resources).

- ```bash

- git remote add frontend <deploymentLocalGitUrl-of-front-end-app>

- git push frontend main

-### Browse to the apps

-Navigate to the following URLs in a browser and see the two apps working.

-```

-http://<back-end-app-name>.azurewebsites.net

-http://<front-end-app-name>.azurewebsites.net

-```

-> [!NOTE]

-> If your app restarts, you may have noticed that new data has been erased. This behavior by design because the sample ASP.NET Core app uses an in-memory database.

->

->

-## Call back-end API from front end

-In this step, you point the front-end app's server code to access the back-end API. Later, you enable authenticated access from the front end to the back end.

-### Modify front-end code

-1. In the local repository, open _Controllers/TodoController.cs_. At the beginning of the `TodoController` class, add the following lines and replace _\<back-end-app-name>_ with the name of your back-end app:

- ```cs

- private static readonly HttpClient _client = new HttpClient();

- private static readonly string _remoteUrl = "https://<back-end-app-name>.azurewebsites.net";

- ```

-1. Find the method that's decorated with `[HttpGet]` and replace the code inside the curly braces with:

- ```cs

- var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo");

- return JsonConvert.DeserializeObject<List<TodoItem>>(data);

- ```

- The first line makes a `GET /api/Todo` call to the back-end API app.

-1. Next, find the method that's decorated with `[HttpGet("{id}")]` and replace the code inside the curly braces with:

- ```cs

- var data = await _client.GetStringAsync($"{_remoteUrl}/api/Todo/{id}");

- return Content(data, "application/json");

- ```

- The first line makes a `GET /api/Todo/{id}` call to the back-end API app.

-1. Next, find the method that's decorated with `[HttpPost]` and replace the code inside the curly braces with:

- ```cs

- var response = await _client.PostAsJsonAsync($"{_remoteUrl}/api/Todo", todoItem);

- var data = await response.Content.ReadAsStringAsync();

- return Content(data, "application/json");

- ```

- The first line makes a `POST /api/Todo` call to the back-end API app.

-1. Next, find the method that's decorated with `[HttpPut("{id}")]` and replace the code inside the curly braces with:

- ```cs

- var res = await _client.PutAsJsonAsync($"{_remoteUrl}/api/Todo/{id}", todoItem);

- return new NoContentResult();

- ```

- The first line makes a `PUT /api/Todo/{id}` call to the back-end API app.

-1. Next, find the method that's decorated with `[HttpDelete("{id}")]` and replace the code inside the curly braces with:

- ```cs

- var res = await _client.DeleteAsync($"{_remoteUrl}/api/Todo/{id}");

- return new NoContentResult();

- ```

- The first line makes a `DELETE /api/Todo/{id}` call to the back-end API app.

-1. Save all your changes. In the local terminal window, deploy your changes to the front-end app with the following Git commands:

- ```bash

- git add .

- git commit -m "call back-end API"

- git push frontend main

- ```

-### Check your changes

-1. Navigate to `http://<front-end-app-name>.azurewebsites.net` and add a few items, such as `from front end 1` and `from front end 2`.

-1. Navigate to `http://<back-end-app-name>.azurewebsites.net` to see the items added from the front-end app. Also, add a few items, such as `from back end 1` and `from back end 2`, then refresh the front-end app to see if it reflects the changes.

- :::image type="content" source="./media/tutorial-auth-aad/remote-api-call-run.png" alt-text="Screenshot of an Azure App Service REST API Sample in a browser window, which shows a To do list app with items added from the front-end app.":::

-## Configure auth

-In this step, you enable authentication and authorization for the two apps. You also configure the front-end app to generate an access token that you can use to make authenticated calls to the back-end app.

-You use Azure Active Directory as the identity provider. For more information, see [Configure Azure Active Directory authentication for your App Services application](configure-authentication-provider-aad.md).

-### Enable authentication and authorization for back-end app

-1. In **Resource groups**, find and select your resource group. In **Overview**, select your back-end app's management page.

- :::image type="content" source="./media/tutorial-auth-aad/portal-navigate-back-end.png" alt-text="Screenshot of the Resource groups window, showing the Overview for an example resource group and a back-end app's management page selected.":::

-1. In your back-end app's left menu, select **Authentication**, and then click **Add identity provider**.

-1. Accept the default settings and click **Add**.

- :::image type="content" source="./media/tutorial-auth-aad/configure-auth-back-end.png" alt-text="Screenshot of the back-end app's left menu showing Authentication/Authorization selected and settings selected in the right menu.":::

-If you stop here, you have a self-contained app that's already secured by the App Service authentication and authorization. The remaining sections show you how to secure a multi-app solution by "flowing" the authenticated user from the front end to the back end.

-### Enable authentication and authorization for front-end app

-Follow the same steps for the front-end app, but skip the last step. You don't need the client ID for the front-end app. However, stay on the **Authentication** page for the front-end app because you'll use it in the next step.

-If you like, navigate to `http://<front-end-app-name>.azurewebsites.net`. It should now direct you to a secured sign-in page. After you sign in, *you still can't access the data from the back-end app*, because the back-end app now requires Azure Active Directory sign-in from the front-end app. You need to do three things:

-### Grant front-end app access to back end

-Now that you've enabled authentication and authorization to both of your apps, each of them is backed by an AD application. In this step, you give the front-end app permissions to access the back end on the user's behalf. (Technically, you give the front end's _AD application_ the permissions to access the back end's _AD application_ on the user's behalf.)

-1. In the **Authentication** page for the front-end app, select your front-end app name under **Identity provider**. This app registration was automatically generated for you. Select **API permissions** in the left menu.

-1. Select **Add a permission**, then select **My APIs** > **\<back-end-app-name>**.

-1. In the **Request API permissions** page for the back-end app, select **Delegated permissions** and **user_impersonation**, then select **Add permissions**.

-The front-end app now has the required permissions to access the back-end app as the signed-in user. In this step, you configure App Service authentication and authorization to give you a usable access token for accessing the back end. For this step, you need the back end's client ID, which you copied from [Enable authentication and authorization for back-end app](#enable-authentication-and-authorization-for-back-end-app).

-In the Cloud Shell, run the following commands on the front-end app to add the `scope` parameter to the authentication setting `identityProviders.azureActiveDirectory.login.loginParameters`. Replace *\<front-end-app-name>* and *\<back-end-client-id>*.

-The commands effectively adds a `loginParameters` property with additional custom scopes. Here's an explanation of the requested scopes:

-> - To view the `api://<back-end-client-id>/user_impersonation` scope in the Azure portal, go to the **Authentication** page for the back-end app, click the link under **Identity provider**, then click **Expose an API** in the left menu.

-> - Some scopes require admin or user consent. This requirement causes the consent request page to be displayed when a user signs into the front-end app in the browser. To avoid this consent page, add the front end's app registration as an authorized client application in the **Expose an API** page by clicking **Add a client application** and supplying the client ID of the front end's app registration.

-> [!NOTE]

-> For Linux apps, There's a temporary requirement to configure a versioning setting for the back-end app registration. In the Cloud Shell, configure it with the following commands. Be sure to replace *\<back-end-client-id>* with your back end's client ID.

->

-> ```azurecli-interactive

-> id=$(az ad app show --id <back-end-client-id> --query id --output tsv)

-> az rest --method PATCH --url https://graph.microsoft.com/v1.0/applications/$id --body "{'api':{'requestedAccessTokenVersion':2}}"

-> ```

-Your apps are now configured. The front end is now ready to access the back end with a proper access token.

-## Call API securely from server code

-In this step, you enable your previously modified server code to make authenticated calls to the back-end API.

-Your front-end app now has the required permission and also adds the back end's client ID to the login parameters. Therefore, it can obtain an access token for authentication with the back-end app. App Service supplies this token to your server code by injecting a `X-MS-TOKEN-AAD-ACCESS-TOKEN` header to each authenticated request (see [Retrieve tokens in app code](configure-authentication-oauth-tokens.md#retrieve-tokens-in-app-code)).

-> [!NOTE]

-> These headers are injected for all supported languages. You access them using the standard pattern for each respective language.

-1. In the local repository, open _Controllers/TodoController.cs_ again. Under the `TodoController(TodoContext context)` constructor, add the following code:

- ```cs

- public override void OnActionExecuting(ActionExecutingContext context)

- {

- base.OnActionExecuting(context);

-

- _client.DefaultRequestHeaders.Accept.Clear();

- _client.DefaultRequestHeaders.Authorization =

- new AuthenticationHeaderValue("Bearer", Request.Headers["X-MS-TOKEN-AAD-ACCESS-TOKEN"]);

- This code adds the standard HTTP header `Authorization: Bearer <access-token>` to all remote API calls. In the ASP.NET Core MVC request execution pipeline, `OnActionExecuting` executes just before the respective action does, so each of your outgoing API call now presents the access token.

-1. Save all your changes. In the local terminal window, deploy your changes to the front-end app with the following Git commands:

- ```bash

- git add .

- git commit -m "add authorization header for server code"

- git push frontend main

- ```

-1. Sign in to `https://<front-end-app-name>.azurewebsites.net` again. At the user data usage agreement page, click **Accept**.

- You should now be able to create, read, update, and delete data from the back-end app as before. The only difference now is that both apps are now secured by App Service authentication and authorization, including the service-to-service calls.

-Congratulations! Your server code is now accessing the back-end data on behalf of the authenticated user.

-## Call API securely from browser code

-In this step, you point the front-end Angular.js app to the back-end API. This way, you learn how to retrieve the access token and make API calls to the back-end app with it.

-While the server code has access to request headers, client code can access `GET /.auth/me` to get the same access tokens (see [Retrieve tokens in app code](configure-authentication-oauth-tokens.md#retrieve-tokens-in-app-code)).

-> [!TIP]

-> This section uses the standard HTTP methods to demonstrate the secure HTTP calls. However, you can use [Microsoft Authentication Library for JavaScript](https://github.com/AzureAD/microsoft-authentication-library-for-js) to help simplify the Angular.js application pattern.

->

-### Configure CORS

-In the Cloud Shell, enable CORS to your client's URL by using the [`az webapp cors add`](/cli/azure/webapp/cors#az-webapp-cors-add) command. Replace the _\<back-end-app-name>_ and _\<front-end-app-name>_ placeholders.

-```azurecli-interactive

-az webapp cors add --resource-group myAuthResourceGroup --name <back-end-app-name> --allowed-origins 'https://<front-end-app-name>.azurewebsites.net'

-```

-This step is not related to authentication and authorization. However, you need it so that your browser allows the cross-domain API calls from your Angular.js app. For more information, see [Add CORS functionality](app-service-web-tutorial-rest-api.md#add-cors-functionality).

-### Point Angular.js app to back-end API

-1. In the local repository, open _wwwroot/https://docsupdatetracker.net/index.html_.

-1. In Line 51, set the `apiEndpoint` variable to the HTTPS URL of your back-end app (`https://<back-end-app-name>.azurewebsites.net`). Replace _\<back-end-app-name>_ with your app name in App Service.

-1. In the local repository, open _wwwroot/app/scripts/todoListSvc.js_ and see that `apiEndpoint` is prepended to all the API calls. Your Angular.js app is now calling the back-end APIs.

-### Add access token to API calls

-1. In _wwwroot/app/scripts/todoListSvc.js_, above the list of API calls (above the line `getItems : function(){`), add the following function to the list:

- ```javascript

- setAuth: function (token) {

- $http.defaults.headers.common['Authorization'] = 'Bearer ' + token;

- },

- This function is called to set the default `Authorization` header with the access token. You call it in the next step.

-1. In the local repository, open _wwwroot/app/scripts/app.js_ and find the following code:

- ```javascript

- $routeProvider.when("/Home", {

- controller: "todoListCtrl",

- templateUrl: "/App/Views/TodoList.html",

- }).otherwise({ redirectTo: "/Home" });

- ```

-1. Replace the entire code block with the following code:

- ```javascript

- $routeProvider.when("/Home", {

- controller: "todoListCtrl",

- templateUrl: "/App/Views/TodoList.html",

- resolve: {

- token: ['$http', 'todoListSvc', function ($http, todoListSvc) {

- return $http.get('/.auth/me').then(function (response) {

- todoListSvc.setAuth(response.data[0].access_token);

- return response.data[0].access_token;

- });

- }]

- },

- }).otherwise({ redirectTo: "/Home" });

- ```

- The new change adds the `resolve` mapping that calls `/.auth/me` and sets the access token. It makes sure you have the access token before instantiating the `todoListCtrl` controller. That way all API calls by the controller includes the token.

-### Deploy updates and test

-1. Save all your changes. In the local terminal window, deploy your changes to the front-end app with the following Git commands:

- ```bash

- git add .

- git commit -m "add authorization header for Angular"

- git push frontend main

- ```

-1. Navigate to `https://<front-end-app-name>.azurewebsites.net` again. You should now be able to create, read, update, and delete data from the back-end app, directly in the Angular.js app.

-Congratulations! Your client code is now accessing the back-end data on behalf of the authenticated user.

-## When access tokens expire

-Your access token expires after some time. For information on how to refresh your access tokens without requiring users to reauthenticate with your app, see [Refresh identity provider tokens](configure-authentication-oauth-tokens.md#refresh-auth-tokens).

-## Clean up resources

-In the preceding steps, you created Azure resources in a resource group. If you don't expect to need these resources in the future, delete the resource group by running the following command in the Cloud Shell:

-```azurecli-interactive

-az group delete --name myAuthResourceGroup

-```

-This command may take a minute to run.

-Advance to the next tutorial to learn how to map a custom DNS name to your app.

-> [Secure with custom domain and certificate](tutorial-secure-domain-certificate.md)

-* A [**Form Recognizer**](https://portal.azure.com/#create/Microsoft.CognitiveServicesTextTranslation) or [**Cognitive Services**](https://portal.azure.com/#create/Microsoft.CognitiveServicesAllInOne) resource in the Azure portal. For detailed steps, _see_ [Create a Cognitive Services resource using the Azure portal](../../cognitive-services/cognitive-services-apis-create-account.md?tabs=multiservice%2cwindows).

-* **StackExchange.Redis:** Set `ssl=true` and `sslprotocols=tls12` in the connection string.

-az group delete --name $resourceGroup

- - Allows filtering rules and data transformations to reduce the overall data volume being uploaded, thus lowering ingestion and storage costs significantly

- - Supports data uploads multiple destinations (multiple Log Analytics workspaces, i.e. *multihoming* on Windows and Linux) including cross-region and cross-tenant data collection (using Azure LightHouse)

- - Centralized, agent configuration "in the cloud" for enterprise scale throughout the data collection lifecycle, from onboarding to deployment to updates and changes over time.

- - Any change(s) in configuration is rolled out to all agents automatically, without requiring a client side deployment

- - Enhanced security through Managed Identity and Azure Active Directory (Azure AD) tokens (for clients)

-Deploy Azure Monitor Agent on all new virtual machines, scale sets and on-premises servers to collect data for [supported services and features](#supported-services-and-features).

-| [Microsoft Sentinel](../../sentinel/overview.md) | <ul><li>Windows Security Events: [Generally available](../../sentinel/connect-windows-security-events.md?tabs=AMA)</li><li>Windows Forwarding Event (WEF): [Public preview](../../sentinel/data-connectors-reference.md#windows-forwarded-events-preview)</li><li>Windows DNS logs: [Public preview](../../sentinel/connect-dns-ama.md)</li><li>Linux Syslog CEF: [Public preview](../../sentinel/connect-cef-ama.md#set-up-the-common-event-format-cef-via-ama-connector)</li></ul> | Sentinel DNS extension, if youΓÇÖre collecting DNS logs. For all other data types, you just need the Azure Monitor Agent extension. | - |

-| [SQL Best Practices Assessment](/sql/sql-server/azure-arc/assess/) | Generally available | | [Configure best practices assessment using Azure Monitor Agent](/sql/sql-server/azure-arc/assess#enable-best-practices-assessment) |

-|Microsoft.Search/searchServices | No | No | [Search services](../essentials/metrics-supported.md#microsoftsearchsearchservices) |

-Using various authentication systems can be cumbersome and risky because it's difficult to manage credentials at scale. You can now choose to [opt out of local authentication](#disable-local-authentication) to ensure only telemetry exclusively authenticated by using [managed identities](../../active-directory/managed-identities-azure-resources/overview.md) and [Azure AD](../../active-directory/fundamentals/active-directory-whatis.md) is ingested in your resource. This feature is a step to enhance the security and reliability of the telemetry used to make critical operational ([alerting](../alerts/alerts-overview.md#what-are-azure-monitor-alerts)and [autoscale](../autoscale/autoscale-overview.md#overview-of-autoscale-in-microsoft-azure)) and business decisions.

- 1. We recommend using a managed identity:

- 1. We don't recommend using a service principal:

-Or add the following JVM args while running your application:`-Djava.net.useSystemProxies=true -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8888`

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-|sdkVersion|string|SdkVersion|string|

-* Micrometer, including Spring Boot Actuator metrics

-| &nbsp;&nbsp;&nbsp;Micrometer | | Yes | | | | | |

-description: Autoscale patterns in Azure for Web Apps, virtual machine scale sets, and Cloud Services

-# Best practices for Autoscale

-Azure Monitor autoscale applies only to [Virtual Machine Scale Sets](https://azure.microsoft.com/services/virtual-machine-scale-sets/), [Cloud Services](https://azure.microsoft.com/services/cloud-services/), [App Service - Web Apps](https://azure.microsoft.com/services/app-service/web/), and [API Management services](../../api-management/api-management-key-concepts.md).

-* 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 has a maximum, minimum, and default value of instances.

-* 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](../alerts/activity-log-alerts.md) so that you can be notified via email, SMS, or webhooks whenever there's 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's 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.

-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.

-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, as defined in the profile. This isn't 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.

-When you use a scale-in and scale-out rule, ideally use the same metric to control both. Otherwise, itΓÇÖs possible that the scale-in and scale-out conditions could be met at the same time resulting in some level of flapping. For example, the following rule combination isn't* recommended because there's no scale-in rule for memory usage:

-* If CPU > 90%, scale-out by 1

-* If Memory > 90%, scale-out by 1

-* If CPU < 45%, scale-in by 1

-In this example, you can have a situation in which the memory usage is over 90% but the CPU usage is under 45%. This can lead to flapping for as long as both conditions are met.

-For diagnostics metrics, you can choose among *Average*, *Minimum*, *Maximum* and *Total* as a metric to scale by. The most common statistic is *Average*.

-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

-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's still 50/2 = 25 messages per instance. So, scale-out doesn't 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 third storage queue instance is added due to a scale-out action. The next scale-out action won't 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.

-There are cases where you may have to set multiple rules in a profile. The following autoscale rules are used by the autoscale engine 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:

-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%.

-The default instance count is important because autoscale scales your service to that count when metrics aren't available. Therefore, select a default instance count that's safe for your workloads.

-Autoscale will post to the Activity Log if any of the following conditions occur:

-* Autoscale detects flapping and aborts the scale attempt. You'll see a log type of `Flapping` in this situation. If you see this, consider whether your thresholds are too narrow.

-* Autoscale detects flapping but is still able to successfully scale. You'll see a log type of `FlappingOccurred` in this situation. If you see this, the autoscale engine has attempted to scale (for example, from 4 instances to 2), but has determined that this would cause flapping. Instead, the autoscale engine has scaled to a different number of instances (for example, using 3 instances instead of 2), which no longer causes flapping, so it has scaled to this number of instances.

-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](https://github.com/Azure/azure-quickstart-templates/tree/master/demos/monitor-autoscale-alert) or to [create an Activity Log Alert to monitor all failed autoscale scale in/scale out operations on your subscription](https://github.com/Azure/azure-quickstart-templates/tree/master/demos/monitor-autoscale-failed-alert).

-## Send data securely using TLS 1.2

-To ensure the security of data in transit to Azure Monitor, 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](https://www.pcisecuritystandards.org/) has set a deadline of [June 30th, 2018](https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Migrating_from_SSL_and_Early_TLS_Resource_Guide.pdf) to disable older versions of TLS/SSL and upgrade to more secure protocols. Once Azure drops legacy support, if your agents can't communicate over at least TLS 1.2 you wouldn't be able to send data to Azure Monitor Logs.

-We recommend you do NOT explicit set your agent to only use TLS 1.2 unless absolutely necessary. Allowing the agent to automatically detect, negotiate, and take advantage of future security standards is preferable. Otherwise you may miss the added security of the newer standards and possibly experience problems if TLS 1.2 is ever deprecated in favor of those newer standards.

-## Next Steps

-description: Learn some of the common patterns to auto scale your resource in Azure.

-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.

-Azure autoscale supports many resource types. For more information about supported resources, see [autoscale supported resources](./autoscale-overview.md#supported-services-for-autoscale).

-This article assumes that you're familiar with auto scale. [Get started here to scale your resource](./autoscale-get-started.md).

-Scale your resource based on metrics produce by the resource itself or any other resource.

-* Scale your Virtual Machine Scale Set based on the CPU usage of the virtual machine.

-* Set a maximum limit on the number of instances.

-The image below shows a default scale condition for a Virtual Machine Scale Set

- * The **Scale rule** tab shows that the metric source is the scale set itself and the metric used is Percentage CPU.

- * The minimum number of instances running is set to 2.

- * The maximum number of instances is set to 10.

- * When the scale set starts, the default number of instances is 3.

-Scale a resource based on the metrics from a different resource.

-The image below shows a scale rule that is scaling a Virtual Machine Scale Set based on the number of allocated ports on a load balancer.

-You can scale your resources differently on different days of the week.

-For example, you have a Virtual Machine Scale Set and want to:

-+ The weekend profile starts at 00:01, Saturday morning and ends at 04:00 on Monday morning.

-+ The end times are left blank. The weekday profile will end when the weekend profile starts and vice-versa.

-+ The default profile is irrelevant as there's no time that isn't covered by the other profiles.

-> Creating a recurring profile with no end time is only supported via the portal and ARM templates. For more information on creating recurring profiles with ARM templates, see [Add a recurring profile using ARM templates](./autoscale-multiprofile.md?tabs=templates#add-a-recurring-profile-using-arm-templates).

-> If the end-time is not included in the CLI command, a default end-time of 23:59 will be implemented by creating a copy of the default profile with the naming convention `"name": {\"name\": \"Auto created default scale condition\", \"for\": \"<non-default profile name>\"}`

-

-You can set your scale rules and instance limits differently for specific events.

-For example:

-Scale by custom metrics generated by your application.

-For example, you have a web front end and an API tier that communicates with the backend, and you want to scale the API tier based on custom events in the front end.

-Next steps

-Learn more about autoscale by referring to the following articles:

-* [Flapping in Autoscale](./autoscale-custom-metric.md)

-description: Configure diagnostics in autoscale.

-# Customer intent: As a devops admin, I want to collect and analyze autoscale metrics and logs.

-# Diagnostic settings in Autoscale

-Autoscale has two log categories and a set of metrics that can be enabled via the **Diagnostics settings** tab on the autoscale setting page.

-The two categories are

-* [Autoscale Evaluations](https://learn.microsoft.com/azure/azure-monitor/reference/tables/autoscaleevaluationslog) containing log data relating to rule evaluation.

-* [Autoscale Scale Actions](https://learn.microsoft.com/azure/azure-monitor/reference/tables/autoscalescaleactionslog) log data relating to each scale event.

-Information about Autoscale Metrics can be found in the [Supported metrics](../essentials/metrics-supported.md#microsoftinsightsautoscalesettings) reference.

-Both the logs and metrics can be sent to various destinations including:

-For more information on diagnostics, see [Diagnostic settings in Azure Monitor](../essentials/diagnostic-settings.md?tabs=portal)

-View the history of your autoscale activity in the run history tab. The run history tab includes a chart of resource instance counts over time and the resource activity log entries for autoscale.

-## Resource log schemas

-The following are the general formats for autoscale resource logs with example data included. Not all examples below are properly formed JSON as they may include a list of valid for a given field.

-## Autoscale Evaluations Log

-Logged when autoscale first looks at an autoscale profile

-### Profile cooldown evaluation

-Logged when autoscale evaluates if it shouldn't scale because of a cool down period.

-Logged when autoscale first starts evaluating a particular scale rule.

-Logged when autoscale evaluated the metric being used to trigger a scale action.

-Logged when autoscale evaluates the number of instances already running in preparation for deciding if it should start more, shut down some, or do nothing.

-Logged when autoscale starts evaluation if a scale action should take place.

-Logged when autoscale updates the number of compute instances running, either up or down.

-## Autoscale Scale Actions Log

-Logged when autoscale initiates a scale action, either up or down.

-Logged at different intervals of an instance scale action.

-## Activity Logs

-The following events are logged to the Activity log with a `CategoryValue` of `Autoscale`.

-* Autoscale scale up initiated

-* Autoscale scale up completed

-* Autoscale scale down initiated

-* Autoscale scale down completed

-* Predictive Autoscale scale up initiated

-* Predictive Autoscale scale up completed

-* Metric Failure

-* Metric Recovery

-* Predictive Metric Failure

-An extract of each log event name, showing the relevant parts of the `Properties` element are shown below:

-### Autoscale action

-Logged when autoscale attempts to scale in or out.

-### Get Operation Status Result

-Logged following a scale event.

-Logged when autoscale can't determine the value of the metric used in the scale rule.

-Logged when autoscale can once again determine the value of the metric used in the scale rule after a `MetricFailure` event

-### Predictive Metric Failure

-Logged when autoscale can't calculate predicted scale events due to the metric being unavailable.

-### Flapping Occurred

-Logged when autoscale detects flapping could occur, and scales differently to avoid it.

-Logged when autoscale detects flapping could occur, and defers scaling in to avoid it.

-* [Troubleshooting Autoscale](./autoscale-troubleshoot.md)

-* [Autoscale Flapping](./autoscale-flapping.md)

-In the above example, on Monday after 6 AM, the recurring profile will be used. If the instance count is less than 3, autoscale scales to the new minimum of three. Autoscale continues to use this profile and scales based on CPU% until Monday at 6 PM. At all other times scaling will be done according to the default profile, based on the number of requests. After 6 PM on Monday, autoscale switches to the default profile. If for example, the number of instances at the time is 12, autoscale scales in to 10, which the maximum allowed for the default profile.

-description: "Autoscale in Microsoft Azure"

-# Overview of autoscale in Microsoft Azure

-This article describes Microsoft Azure autoscale and its benefits.

-Azure autoscale supports many resource types. For more information about supported resources, see [autoscale supported resources](#supported-services-for-autoscale).

-> [Availability sets](/archive/blogs/kaevans/autoscaling-azurevirtual-machines) are an older scaling feature for virtual machines with limited support. We recommend migrating to [virtual machine scale sets](../../virtual-machine-scale-sets/overview.md) for faster and more reliable autoscale support.

-## What is autoscale

-Autoscale is a service that allows you to automatically add and remove resources according to the load on your application.

-When your application experiences higher load, autoscale adds resources to handle the increased load. When load is low, autoscale reduces the number of resources, lowering your costs. You can scale your application based on metrics like CPU usage, queue length, and available memory, or based on a schedule. Metrics and schedules are set up in rules. The rules include a minimum level of resources that you need to run your application, and a maximum level of resources that won't be exceeded.

-For example, scale out your application by adding VMs when the average CPU usage per VM is above 70%. Scale it back in removing VMs when CPU usage drops to 40%.

-When the conditions in the rules are met, one or more autoscale actions are triggered, adding or removing VMs. In addition, you can perform other actions like sending email notifications, or webhooks to trigger processes in other systems.

-## Scaling out and scaling up

-Autoscale scales in and out, which is an increase, or decrease of the number of resource instances. Scaling in and out is also called horizontal scaling. For example, for a Virtual Machine Scale Set, scaling out means adding more virtual machines. Scaling in means removing virtual machines. Horizontal scaling is flexible in a cloud situation as it allows you to run a large number of VMs to handle load.

-In contrast, scaling up and down, or vertical scaling, keeps the number of resources constant, but gives those resources more capacity in terms of memory, CPU speed, disk space and network. Vertical scaling is limited by the availability of larger hardware, which eventually reaches an upper limit. Hardware size availability varies in Azure by region. Vertical scaling may also require a restart of the virtual machine during the scaling process.

-When the conditions in the rules are met, one or more autoscale actions are triggered, adding or removing VMs. In addition, you can perform other actions like sending email notifications, or webhooks to trigger processes in other systems.

-[Predictive autoscale](./autoscale-predictive.md) uses machine learning to help manage and scale Azure Virtual Machine Scale Sets with cyclical workload patterns. It forecasts the overall CPU load on your Virtual Machine Scale Set, based on historical CPU usage patterns. The scale set can then be scaled out in time to meet the predicted demand.

-* [Cross-platform Command Line Interface (CLI)](../cli-samples.md#autoscale)

-The following diagram shows the autoscale architecture.

- 

-Resources generate metrics that are used in autoscale rules to trigger scale events. Virtual Machine Scale Sets use telemetry data from Azure diagnostics agents to generate metrics. Telemetry for Web apps and Cloud services comes directly from the Azure Infrastructure. Some commonly used metrics include CPU usage, memory usage, thread counts, queue length, and disk usage. See [Autoscale Common Metrics](autoscale-common-metrics.md) for a list of available metrics.

-Use your own custom metrics that your application generates. Configure your application to send metrics to [Application Insights](../app/app-insights-overview.md) so you can use those metrics decide when to scale.

-Set up schedule-based rules to trigger scale events. Use schedule-based rules when you see time patterns in your load, and want to scale before an anticipated change in load occurs.

-Rules define the conditions needed to trigger a scale event, the direction of the scaling, and the amount to scale by. Combine multiple rules using different metrics, for example CPU usage and queue length. Define up to 10 rules per profile.

-* Metric-based

-Trigger based on a metric value, for example when CPU usage is above 50%.

-* Time-based

-Trigger based on a schedule, for example, every Saturday at 8am.

-Autoscale scales out if *any* of the rules are met, whereas autoscale scales in only if *all* the rules are met.

-In terms of logic operators, the OR operator is used when scaling out with multiple rules. The AND operator is used when scaling in with multiple rules.

-* Scale - Scale resources in or out.

-* Email - Send an email to the subscription admins, co-admins, and/or any other email address.

-* Webhooks - Call webhooks to trigger multiple complex actions inside or outside Azure. In Azure, you can:

- * Call an [Azure Function](../../azure-functions/functions-overview.md).

- * Trigger an [Azure Logic App](../../logic-apps/logic-apps-overview.md).

-Autoscale settings contain the autoscale configuration. The setting including scale conditions that define rules, limits, and schedules and notifications. Define one or more scale conditions in the settings, and one notification setup.

-Autoscale uses the following terminology and structure. The UI and JSON

-| Scale conditions | profiles | A collection of rules, instance limits and schedules, based on a metric or time. You can define one or more scale conditions or profiles. |

-| Rules | rules | A set of time or metric-based conditions that trigger a scale action. You can define one or more rules for both scale-in and scale-out actions. |

-| Instance limits | capacity | Each scale condition or profile defines th default, max, and min number of instances that can run under that profile. |

-| Schedule | recurrence | Indicates when autoscale should put this scale condition or profile into effect. You can have multiple scale conditions, which allow you to handle different and overlapping requirements. For example, you can have different scale conditions for different times of day, or days of the week. |

-| Notify | notification | Defines the notifications to send when an autoscale event occurs. Autoscale can notify one or more email addresses or make a call one or more webhooks. You can configure multiple webhooks in the JSON but only one in the UI. |

-

-For code examples, see

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with an Azure template](../../virtual-machine-scale-sets/tutorial-autoscale-template.md)

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with the Azure CLI](../../virtual-machine-scale-sets/tutorial-autoscale-cli.md)

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with an Azure template](../../virtual-machine-scale-sets/tutorial-autoscale-powershell.md)

-## Horizontal vs vertical scaling

-Autoscale scales horizontally, which is an increase, or decrease of the number of resource instances. For example, in a Virtual Machine Scale Set, scaling out means adding more virtual machines Scaling in means removing virtual machines. Horizontal scaling is flexible in a cloud situation as it allows you to run a large number of VMs to handle load.

-In contrast, vertical scaling, keeps the same number of resources constant, but gives them more capacity in terms of memory, CPU speed, disk space and network. Adding or removing capacity in vertical scaling is known as scaling or down. Vertical scaling is limited by the availability of larger hardware, which eventually reaches an upper limit. Hardware size availability varies in Azure by region. Vertical scaling may also require a restart of the virtual machine during the scaling process.

-The following services are supported by autoscale:

-| Service | Schema & Documentation |

-| Azure Virtual machines scale sets | [Overview of autoscale with Azure Virtual Machine Scale Sets](../../virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-overview.md) |

-| Web apps | [Scaling Web Apps](autoscale-get-started.md) |

-| Azure Data Explorer Clusters | [Manage Azure Data Explorer clusters scaling to accommodate changing demand](/azure/data-explorer/manage-cluster-horizontal-scaling) |

-| Azure Stream Analytics | [Autoscale streaming units (Preview)](../../stream-analytics/stream-analytics-autoscale.md) |

-| Azure SignalR Service (Premium tier) | [Automatically scale units of an Azure SignalR service](https://learn.microsoft.com/azure/azure-signalr/signalr-howto-scale-autoscale) |

-| Azure Machine Learning Workspace | [Autoscale an online endpoint](../../machine-learning/how-to-autoscale-endpoints.md) |

-| Media Services | [Autoscaling in Media Services](/azure/media-services/latest/release-notes#autoscaling) |

-| Service Bus | [Automatically update messaging units of an Azure Service Bus namespace](../../service-bus-messaging/automate-update-messaging-units.md) |

-| Logic Apps - Integration Service Environment(ISE) | [Add ISE capacity](../../logic-apps/ise-manage-integration-service-environment.md#add-ise-capacity) |

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with an Azure template](../../virtual-machine-scale-sets/tutorial-autoscale-template.md)

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with the Azure CLI](../../virtual-machine-scale-sets/tutorial-autoscale-cli.md)

-* [Tutorial: Automatically scale a Virtual Machine Scale Set with Azure PowerShell](../../virtual-machine-scale-sets/tutorial-autoscale-powershell.md)

-* [PowerShell Az.Monitor Reference](/powershell/module/az.monitor/#monitor)

-* [REST API reference. Autoscale Settings](/rest/api/monitor/autoscale-settings).

-description: Tracking down problems with Azure Monitor autoscaling used in Service Fabric, Virtual Machines, Web Apps, and cloud services.

-# Troubleshooting Azure Monitor autoscale

-

-Azure Monitor autoscale helps you to have the right amount of resources running to handle the load on your application. It enables you to add resources to handle increases in load and also save money by removing resources that are sitting idle. You can scale based on a schedule, fixed date-time, or resource metric you choose. For more information, see [Autoscale Overview](autoscale-overview.md).

-The autoscale service provides you metrics and logs to understand what scale actions have occurred and the evaluation of the conditions that led to those actions. You can find answers to questions such as:

-Autoscale provides you with [four metrics](../essentials/metrics-supported.md#microsoftinsightsautoscalesettings) to understand its operation.

-You can use the [Metrics Explorer](../essentials/metrics-getting-started.md) to chart the above metrics all in one place. The chart should show:

- - the actual metric

- - the metric as seen/computed by autoscale engine

- - the threshold for a scale action

- - the change in capacity

-## Example 1 - Analyzing a simple autoscale rule

-We have a simple autoscale setting for a virtual machine scale set that:

-LetΓÇÖs review the metrics from the autoscale service.

-

-

-

-***Figure 1a - Percentage CPU metric for virtual machine scale set and the Observed Metric Value metric for autoscale setting***

-

-***Figure 1b - Metric Threshold and Observed Capacity***

-In figure 1b, the **Metric Threshold** (light blue line) for the scale-out rule is 70. The **Observed Capacity** (dark blue line) shows the number of active instances, which is currently 3.

-> [!NOTE]

-> You will need to filter the **Metric Threshold** by the metric trigger rule dimension scale out (increase) rule to see the scale-out threshold and by the scale in rule (decrease).

-## Example 2 - Advanced autoscaling for a virtual machine scale set

-We have an autoscale setting that allows a virtual machine scale set resource to scale out based on its own metric **Outbound Flows**. Notice that the **divide metric by instance count** option for the metric threshold is checked.

-The scale action rule is:

-If the value of **Outbound Flow per instance** is greater than 10, then autoscale service should scale out by 1 instance.

-In this case, the autoscale engineΓÇÖs observed metric value is calculated as the actual metric value divided by the number of instances. If the observed metric value is less than the threshold, no scale-out action is initiated.

-

-

-

-***Figure 2 - Virtual machine scale set autoscale metrics charts example***

-In figure 2, you can see two metric charts.

-The chart on top shows the actual value of the **Outbound Flows** metric. The actual value is 6.

-The chart on the bottom shows a few values.

-If there are multiple scale action rules, you can use splitting or the **add filter** option in the Metrics explorer chart to look at metric by a specific source or rule. For more information on splitting a metric chart, see [Advanced features of metric charts - splitting](../essentials/metrics-charts.md#apply-splitting)

-## Example 3 - Understanding autoscale events

-In the autoscale setting screen, go to the **Run history** tab to see the most recent scale actions. The tab also shows the change in **Observed Capacity** over time. To find more details about all autoscale actions including operations such as update/delete autoscale settings, view the activity log and filter by autoscale operations.

-

-## Autoscale Resource Logs

-Same as any other Azure resource, the autoscale service provides [resource logs](../essentials/platform-logs-overview.md). There are two categories of logs.

-As with any Azure Monitor supported service, you can use [Diagnostic Settings](../essentials/diagnostic-settings.md) to route these logs:

-

-The previous picture shows the Azure portal autoscale diagnostic settings. There you can select the Diagnostic/Resource Logs tab and enable log collection and routing. You can also perform the same action using REST API, CLI, PowerShell, Resource Manager templates for Diagnostic Settings by choosing the resource type as *Microsoft.Insights/AutoscaleSettings*.

-## Troubleshooting using autoscale logs

-For best troubleshooting experience, we recommend routing your logs to Azure Monitor Logs (Log Analytics) through a workspace when you create the autoscale setting. This process is shown in the picture in the previous section. You can validate the evaluations and scale actions better using Log Analytics.

-Once you have configured your autoscale logs to be sent to the Log Analytics workspace, you can execute the following queries to check the logs.

-Use the following sections to these questions.

-## A scale action occurred that I didnΓÇÖt expect

-First execute the query for scale action to find the scale action you are interested in. If it is the latest scale action, use the following query:

-Select the CorrelationId field from the scale actions log. Use the CorrelationId to find the right Evaluation log. Executing the below query will display all the rules and conditions evaluated leading to that scale action.

-A scaled action occurred, but you have overlapping rules and profiles and need to track down which caused the action.

-Find the correlationId of the scale action (as explained in example 1) and then execute the query on evaluation logs to learn more about the profile.

-The whole profile evaluation can also be understood better using the following query

-## A scale action did not occur

-I expected a scale action and it did not occur. There may be no scale action events or logs.

-Review the autoscale metrics if you are using a metric-based scale rule. It's possible that the **Observed metric value** or **Observed Capacity** are not what you expected them to be and therefore the scale rule did not fire. You would still see evaluations, but not a scale-out rule. It's also possible that the cool-down time kept a scale action from occurring.

- Review the autoscale evaluation logs during the time period you expected the scale action to occur. Review all the evaluations it did and why it decided to not trigger a scale action.

-There may be a case where autoscale service took the scale action but the system decided not to scale or failed to complete the scale action. Use this query to find the failed scale actions.

-For more information, see [autoscale resource logs](autoscale-resource-log-schema.md)

-description: "A detailed breakdown of autoscale settings and how they work. Applies to Virtual Machines, Cloud Services, Web Apps"

-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 gives a detailed explanation of the autoscale settings.

-The following example shows an autoscale setting. This autoscale setting has the following attributes:

- - 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.

-> A setting can have multiple profiles. To learn more, see the [profiles](#autoscale-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](#autoscale-evaluation) section.

-The table below describes the elements in the above autoscale setting's JSON.

-| properties | profiles | Scale condition |An autoscale setting is composed of one or more profiles. Each time the autoscale engine runs, it executes one profile. |

-| profiles | capacity.maximum | Instance limits - Maximum |The maximum capacity allowed. It ensures that autoscale doesn't scale your resource above this number when executing the profile. |

-| profiles | capacity.minimum | Instance limits - Minimum |The minimum capacity allowed. It ensures that autoscale doesn't scale your resource below this number when executing the profile |

-| profiles | capacity.default | Instance limits - Default |If there's a problem reading the resource metric, and the current capacity is below the default, autoscale scales out to the default. This ensures the availability of the resource. If the current capacity is already higher than the default capacity, autoscale doesn't scale in. |

-| profiles | rules | Rules |Autoscale automatically scales between the maximum and minimum capacities, by using the rules in the profile. Define up to 10 individual rules in a profile. Typically rules are defined in pairs, one to determine when to scale out, and the other to determine when to scale in. |

-| 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 | Time grain (minutes) |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 | Time grain 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 | Duration |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 |Time aggregation |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. |

-| scaleAction | cooldown | Cool down (minutes)|The amount of time to wait after a scale operation before scaling again. For example, if **cooldown = ΓÇ£PT10MΓÇ¥**, autoscale doesn't attempt to scale again for another 10 minutes. The cooldown is to allow the metrics to stabilize after the addition or removal of instances. |

-```json

- ...

- "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"

- }

- ]

-```

- The partial schema example below shows a recurring profile, starting at 06:00 and ending at 19:00 on Saturdays and Sundays. The default profile has been modified to start at 19:00 on Saturdays and Sundays.

-

-``` JSON

- {

- "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

- "contentVersion": "1.0.0.0",

- "resources": [

- {

- "type": "Microsoft.Insights/ autoscaleSettings",

- "apiVersion": "2015-04-01",

- "name": "VMSS1-Autoscale-607",

- "location": "eastus",

- "properties": {

- "enabled": true,

- "targetResourceUri": "/subscriptions/ abc123456-987-f6e5-d43c-9a8d8e7f6541/ resourceGroups/rg-vmss1/providers/ Microsoft.Compute/ virtualMachineScaleSets/VMSS1",

- "profiles": [

- {

- "name": "Weekend profile",

- "capacity": {

- ...

- },

- "rules": [

- ...

- ],

- "recurrence": {

- "frequency": "Week",

- "schedule": {

- "timeZone": "E. Europe Standard Time",

- "days": [

- "Saturday",

- "Sunday"

- ],

- "hours": [

- 6

- ],

- "minutes": [

- 0

- ]

- }

- }

- },

- {

- "name": "{\"name\":\"Auto created default scale condition\",\"for\":\"Weekend profile\"}",

- "capacity": {

- ...

- },

- "recurrence": {

- "frequency": "Week",

- "schedule": {

- "timeZone": "E. Europe Standard Time",

- "days": [

- "Saturday",

- "Sunday"

- ],

- "hours": [

- 19

- ],

- "minutes": [

- 0

- ]

- "rules": [

- ...

- ]

- }

- ],

- "notifications": [],

- "targetResourceLocation": "eastus"

-

- }

- ]

- }

-

-```

-

-Autoscale settings can have multiple profiles. Each profile can have multiple rules. Each time the autoscale job runs, it begins by choosing the applicable profile for that time. Autoscale then evaluates the minimum and maximum values, any metric rules in the profile, and decides if a scale action is necessary. The autoscale job runs every 30 to 60 seconds, depending on the resource type.

-1. Fixed date profiles

-The first suitable profile found will be used.

-After autoscale determines which profile to run, it evaluates the scale-out rules in the profile, that is, where **direction = ΓÇ£IncreaseΓÇ¥**.

-If one or more scale-out rules are triggered, autoscale calculates the new capacity determined by the **scaleAction** specified for each of the rules. If more than one scale-out rule is triggered, autoscale scales to the highest specified capacity to ensure service availability.

-For example, assume that there are two rules: Rule 1 specifies a scale out by 3 instances, and rule 2 specifies a scale out by 5. If both rules are triggered, autoscale will scale out by 5 instances. Similarly, if one rule specifies scale out by 3 instances and another rule, scale out by 15%, the higher of the two instance counts will be used.

-If no scale-out rules are triggered, autoscale evaluates the scale-in rules, that is, rules with **direction = ΓÇ£DecreaseΓÇ¥**. Autoscale only scales in if all of the scale-in rules are triggered.

-Autoscale calculates the new capacity determined by the **scaleAction** of each of those rules. To ensure service availability, autoscale scales in by as little as possible to achieve the maximum capacity specified. For example, assume two scale-in rules, one that decreases capacity by 50 percent, and one that decreases capacity by 3 instances. If first rule results in 5 instances and the second rule results in 7, autoscale scales-in to 7 instances.

-Each time autoscale calculates the result of a scale-in action, it evaluates whether that action would trigger a scale-out action. The scenario where a scale action triggers the opposite scale action is known as flapping. Autoscale may defer a scale-in action to avoid flapping or may scale by a number less than what was specified in the rule. For more information on flapping, see [Flapping in Autoscale](./autoscale-custom-metric.md)

-Learn more about autoscale by referring to the following articles :

-* [Flapping in Autoscale](./autoscale-custom-metric.md)

-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 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 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 App Services

-You can opt-in from the Azure portal for Cloud Services and Server Farms (App Services).

-

-## 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 in your [autoscalesettings](/azure/templates/microsoft.insights/2015-04-01/autoscalesettings) with the following options.

-| 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 |

-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

-| Field | Mandatory? | Description |

-| 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/domainnames/slots/roles" - Cloud Service roles, "microsoft.compute/virtualmachinescalesets" - 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) |

-description: Create an autoscale setting for an app service plan using metric data and a schedule

-# 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

-> * Clean up your resources

-## Log in to the Azure portal

-Log in to the [Azure portal](https://portal.azure.com/).

-## 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:

- 

-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.

- 

-1. Click on the **Add a scale condition** link under the default profile.

-2. Edit the **Name** of this profile to be 'Monday to Friday profile'.

-3. Ensure the **Scale mode** is set to 'Scale based on a metric'.

-4. For **Instance limits** set the **Minimum** as '1', the **Maximum** as '2' and the **Default** as '1'. This setting ensures that this profile does not autoscale the service plan to have less than 1 instance, or more than 2 instances. If the profile does not have sufficient data to make a decision, it uses the default number of instances (in this case 1).

-5. For **Schedule**, select 'Repeat specific days'.

-6. Set the profile to repeat Monday through Friday, from 09:00 PST to 18:00 PST. This setting ensures that this profile is only active and applicable 9AM to 6PM, Monday through Friday. During all other times, the 'Default' profile is the profile the autoscale setting uses.

-1. In the 'Monday to Friday profile'.

-2. Click the **Add a rule** link.

-3. Set the **Metric source** to be 'other resource'. Set the **Resource type** as 'App Services' and the **Resource** as the Web App created earlier in this tutorial.

-4. Set the **Time aggregation** as 'Total', the **Metric name** as 'Requests', and the **Time grain statistic** as 'Sum'.

-5. Set the **Operator** as 'Greater than', the **Threshold** as '10' and the **Duration** as '5' minutes.

-6. Select the **Operation** as 'Increase count by', the **Instance count** as '1', and the **Cool down** as '5' minutes.

-7. Click the **Add** button.

-This rule ensures that if your Web App receives more than 10 requests within 5 minutes or less, one additional instance is added to your App Service Plan to manage load.

- 

-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.

- 

-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.

-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.

- 

-1. From the left-hand menu in the Azure portal, click **All resources** and then select the Web App created in this tutorial.

-2. On your resource page, click **Delete**, confirm delete by typing **yes** in the text box, and then click **Delete**.

-3. Then select the App Service Plan resource and click **Delete**.

-4. Confirm delete by typing **yes** in the text box, and then click **Delete**.

-In this tutorial, you

-> [!div class="checklist"]

-> * 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](../autoscale/autoscale-overview.md).

-Considering all these factors, is critical for a good DCR organization. All the above points impact on DCR management effort as well on resource consumption for configuration transfer and processing.

-Given the native granularity, which allows a given DCR to be associated with more than one target virtual machine and vice versa, it's important to keep the DCR as simple as possible using fewer data sources each. It's also important to keep the list of collected items in each data source, lean and oriented to the observability scope.

-To clarify what an *observability scope* could be, think about it as your preferred logical boundary for collecting data. For instance, a possible scope could be a set of virtual machine running software (that is "Sql Servers") needed for a specific application, or basic operating system counters or events set used by the IT Admins. It's also possible to create similar scopes dedicated to different environments ('Development', 'Test', 'Production') to specialize even more.

-In fact, it's not ideal, even not recommended, to create a single DCR containing all the data sources, collection items and destinations to implement the observability. In the following table, there are several recommendations that could help in better planning DCR creation and maintenance:

-| Data Collection | Define the observability scope | Defining the observability scope is key to an easier and successful DCR management and organization observability scope. It will help clarifying what the collection need is, and from which target virtual machine it should be performed. As previously explained, an observability scope could be a set of virtual machine running software that is common to a specific application, a set of common information for the IT department, etc. As an example, collecting the basic operating system performance counter, such as CPU utilization, available memory and free disk space, could be seen as scope for the Central IT Management. | Not having a clearly defined scope doesn't bring clarity and doesn't allow for a proper management. |

-> This solution has been replaced by the [Office 365](../../sentinel/data-connectors-reference.md#microsoft-office-365) General Availability solution in [Microsoft Sentinel](../../sentinel/overview.md) and the [Azure AD reporting and monitoring solution](../../active-directory/reports-monitoring/plan-monitoring-and-reporting.md). Together they provide an updated version of the previous Azure Monitor Office 365 solution with an improved configuration experience. You can continue to use the existing solution until October 31, 2020.

-description: How to Authenticate and access the Azure Monitor Log Analytics API.

-You can submit a query request to a workspace using the Azure Monitor Log Analytics endpoint `https://api.loganalytics.azure.com`. To access the endpoint, you must authenticate through Azure Active Directory (Azure AD).

-> The `api.loganalytics.io` endpoint is being replaced by `api.loganalytics.azure.com`. `api.loganalytics.io` will continue to be supported for the forseeable future.

-## Authenticating with a demo API key

-To quickly explore the API without Azure Active Directory authentication, use the demonstration workspace with sample data, which supports API key authentication.

-If either the Application ID or the API key is incorrect, the API service will return a [403](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error) (Forbidden) error.

-The API key `DEMO_KEY` can be passed in three different ways, depending on whether you prefer to use the URL, a header, or basic authentication.

-1. **Custom header**: provide the API key in the custom header `X-Api-Key`

-2. **Query parameter**: provide the API key in the URL parameter `api_key`

-3. **Basic authentication**: provide the API key as either username or password. If you provide both, the API key must be in the username.

-This example uses the Workspace ID and API key in the header:

-For example,

-## Set up Authentication

-To access the API, you need to register a client app with Azure Active Directory and request a token.

-1. [Register an app in Azure Active Directory](./register-app-for-token.md).

-1. On the app's overview page, select **API permissions**

-1. Select **Add a permission**

-1. In the **APIs my organization uses** tab search for *log analytics* and select **Log Analytics API** from the list.

-1. Select **Delegated permissions**

-1. Check the checkbox for **Data.Read**

-1. Select **Add permissions**

-Now that your app is registered and has permissions to use the API, grant your app access to your Log Analytics Workspace.

-1. From your Log analytics Workspace overview page, select **Access control (IAM)**.

- :::image type="content" source="../media/api-register-app/workspace-access-control.png" alt-text="A screenshot showing the access control page for a log analytics workspace.":::

-1. Select the **Reader** role then select **Members**

-

- :::image type="content" source="../media/api-register-app/add-role-assignment.png" alt-text="A screenshot showing the add role assignment page for a log analytics workspace.":::

-1. In the Members tab, select **Select members**

-1. Enter the name of your app in the **Select** field.

-1. Choose your app and select **Select**

-1. Select **Review and assign**

-

- :::image type="content" source="../media/api-register-app/select-members.png" alt-text="A screenshot showing the select members blade on the role assignment page for a log analytics workspace.":::

-1. After completing the Active Directory setup and workspace permissions, request an authorization token.

-> For this example we applied the **Reader** role. This role is one of many built-in roles and may include more permissions than you require. More granular roles and permissions can be created. For more information, see [Manage access to Log Analytics workspaces](../../logs/manage-access.md).

-## Request an Authorization Token

-Before beginning, make sure you have all the values required to make the request successfully. All requests require:

-The Log Analytics API supports Azure Active Directory authentication with three different [Azure AD OAuth2](/azure/active-directory/develop/active-directory-protocols-oauth-code) flows:

-### Client Credentials Flow

-In the client credentials flow, the token is used with the log analytics endpoint. A single request is made to receive a token, using the credentials provided for your app in the [Register an app for in Azure Active Directory](./register-app-for-token.md) step above.

-Use the `https://api.loganalytics.azure.com` endpoint.

-##### Client Credentials Token URL (POST request)

-Use the token in requests to the log analytics endpoint:

-Example Response:

-### Authorization Code Flow

-The main OAuth2 flow supported is through [authorization codes](/azure/active-directory/develop/active-directory-protocols-oauth-code). This method requires two HTTP requests to acquire a token with which to call the Azure Monitor Log Analytics API. There are two URLs, one endpoint per request. Their formats are:

-#### Authorization Code URL (GET request):

-When making a request to the Authorize URL, the client\_id is the Application ID from your Azure AD App, copied from the App's properties menu. The redirect\_uri is the home page/login URL from the same Azure AD App. When a request is successful, this endpoint redirects you to the sign-in page you provided at sign-up with the authorization code appended to the URL. See the following example:

-At this point you'll have obtained an authorization code, which you need now to request an access token.

-#### Authorization Code Token URL (POST request)

-All values are the same as before, with some additions. The authorization code is the same code you received in the previous request after a successful redirect. The code is combined with the key obtained from the Azure AD App. If you didn't save the key, you can delete it and create a new one from the keys tab of the Azure AD App menu. The response is a JSON string containing the token with the following schema. Types are indicated for the token values.

-The access token portion of this response is what you present to the Log Analytics API in the `Authorization: Bearer` header. You may also use the refresh token in the future to acquire a new access\_token and refresh\_token when yours have gone stale. For this request, the format and endpoint are:

-### Implicit Code Flow

-The Log Analytics API supports the OAuth2 [implicit flow](/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant). For this flow, only a single request is required but no refresh token can be acquired.

-#### Implicit Code Authorize URL

-A successful request will produce a redirect to your redirect URI with the token in the URL as follows.

-This access\_token can be used as the `Authorization: Bearer` header value when passed to the Log Analytics API to authorize requests.

-## More Information

-# Azure Monitor Log Analytics API Errors

-This section contains a non-exhaustive list of known common errors, their causes, and possible solutions. It also contains successful responses which often indicate an issue with the request (such as a missing header) or otherwise unexpected behavior.

-## Query Syntax Error

-Code: 400 Response:

-Details: The query string is malformed. Check for extra spaces, punctuation, or spelling errors.

-## No Authentication Provided

-Code: 401 Response:

-Details: Include a form of authentication with your request, such as the header "Authorization: Bearer \<token\>"

-## Invalid Authentication Token

-Code: 403 Response:

-Details: the token is malformed or otherwise invalid. This can occur if you manually copy-paste the token and add or cut characters to the payload. Verify that the token is exactly as received from Azure AD.

-## Invalid Token Audience

-Code: 403 Response:

-Details: this occurs if you try to use the client credentials OAuth2 flow to obtain a token for the API and then use that token via the ARM endpoint. Use one of the indicated URLs as the resource in your token request if you want to use the ARM endpoint. Alternatively, you can use the direct API endpoint with a different OAuth2 flow for authorization.

-## Client Credentials to Direct API

-Code: 403 Response:

-Details: This error can occur if you try to use client credentials via the direct API endpoint. If you are using the direct API endpoint, use a different OAuth2 flow for authorization. If you must use client credentials, use the ARM API endpoint.

-## Insufficient Permissions

-Code: 403 Response:

-Details: The token you have presented for authorization belongs to a user who does not have sufficient access to this privilege. Verify your workspace GUID and your token request are correct, and if necessary grant IAM privileges in your workspace to the Azure AD Application you created as Contributor.

-> When using Azure AD authentication, it may take up to 60 minutes for the Azure Application Insights REST API to recognize new

-> role-based access control (RBAC) permissions. While permissions are propagating, REST API calls may fail with error code 403.

-## Bad Authorization Code

-Code: 403 Response:

-Details: The authorization code submitted in the token request was either stale or previously used. Reauthorize via the Azure AD authorize endpoint to get a new code.

-## Path Not Found

-Code: 404 Response:

-Details: the requested query path does not exist. Verify the URL spelling of the endpoint you are hitting, and that you are using a supported HTTP verb.

-Code: 200 Response: empty body. Details: If you send a POST request that is missing either JSON body or the "Content-Type: application/json" header, we will return an empty 200 response.

-## No Data in Workspace

-Code: 204 Response: empty body. Details: If a workspace has no data in it, we return a 204 No Content.

-description: This article describes the REST API, created to make the data collected by Azure Log Analytics easily available.

-# Azure Monitor Log Analytics API Overview

-The Log Analytics **Query API** is a REST API that lets you query the full set of data collected by Azure Monitor logs using the same query language used throughout the service. Use this API to retrieve data, build new visualizations of your data, and extend the capabilities of Log Analytics.

-## Log Analytics API Authentication

-You must authenticate to access the Log Analytics API.

-After receiving a token, the process for calling the Log Analytics API is the same for all flows. Requests require the `Authorization: Bearer` header, populated with the token received from the OAuth2 flow.

-To quickly explore the API without using Azure AD authentication, we provide a demonstration workspace with sample data, which allows [authenticating with an API key](./access-api.md#authenticating-with-a-demo-api-key).

-> When using Azure AD authentication, it may take up to 60 minutes for the Azure Application Insights REST API to recognize new

-> role-based access control (RBAC) permissions. While permissions are propagating, REST API calls may fail with [error code 403](./errors.md#insufficient-permissions).

-## Log Analytics API Query Limits

-See [the **Query API** section of this page](../../service-limits.md) for information about query limits.

-## Trying the Log Analytics API

- - [cURL](https://curl.haxx.se/) from the command line, and then pipe the output into [jsonlint](https://github.com/zaach/jsonlint) to get readable JSON.

-The response is JSON string that contains an array of table objects.

-In the following example, we can see the result contains two columns, `Category` and `count_`. The first column, `Category`, represents the value of the `Category` column in the `AzureActivity` table, and the second column, `count_` is count of the number of events in the `AzureActivity` table for the given Category.

-If a fatal error occurs during query execution, an error status code is returned with a [OneAPI](https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#errorresponse--object) error object describing the error.

-If a non-fatal error occurs during query execution, the response status code is `200 OK` and contains the query results in the `tables` property as described above. The response will also contain an `error` property, which is OneAPI error object with code `PartialError`. Details of the error are included in the `details` property.

-## Next Steps

-Get detailed information about using the [API options](batch-queries.md).

-description: Query execution times can vary widely based on the complexity of the query, amount of data being analyzed, and the load on the system and workspace at the time of the query.

-You may want to customize the timeout for the query. The default timeout is 3 minutes, and the maximum timeout is 10 minutes.

-To set the timeout, use the `Prefer` header in the HTTP request, using the standard `wait` preference, see [here](https://tools.ietf.org/html/rfc7240#section-4.3) for details. The `Prefer` header puts an upper limit, in seconds, on how long the client will wait for the service to process the query.

-If a query takes longer than the specified timeout (or default timeout, if unspecified), it will fail with a status code of 504 Gateway Timeout.

-For example, the following request allows a maximum server timeout age of 30 seconds

->[!Note]

->Integration with private DNS zone present in different subscriptions is unsupported in this experience.

->Azure Backup may allocate new storage account for your vault for the backup data, and the extension or agent needs to access the respective endpoints. For more about how to add more DNS records after registration and backup, see [the guidance in Use Private Endpoints for Backup](private-endpoints.md#use-private-endpoints-for-backup).

-[Restore Azure blobs using Azure PowerShell](restore-blobs-storage-account-ps.md)

-Vaulted backup (preview) for blobs is currently available in the following regions: France Central, Canada Central, Canada East, US East, and US South.

-[Azure Disk Backup FAQ](./disk-backup-faq.yml)

-1. Create the same customer backup user (with the same password) and key (in *hdbuserstore*) on both VMs/nodes.

-Certificates are often required in various scenarios such as decrypting a secret, securing communication channels, or [accessing another service](credential-access-key-vault.md). Currently, Azure Batch offers two ways to manage certificates on Batch pools. You can add certificates to a Batch account or you can use the Azure Key Vault VM extension to manage certificates on Batch pools. Only the [certificate functionality on an Azure Batch account](/rest/api/batchservice/certificate) and the functionality it extends to Batch pools via `CertificateReference` to [Add Pool](/rest/api/batchservice/pool/add#certificatereference), [Patch Pool](/rest/api/batchservice/pool/patch#certificatereference), [Update Properties](/rest/api/batchservice/pool/update-properties#certificatereference) and the corresponding references on Get and List Pool APIs are being retired.

-After the certificates feature in Azure Batch is retired on February 29, 2024, a certificate in Batch won't work as expected. After that date, you'll no longer be able to add certificates to a Batch account or link these certificates to Batch pools. Pools that continue to use this feature after this date may not behave as expected such as updating certificate references or the ability to install existing certificate references.

-

-> The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT).

- > **205478c0-bd83-4e1b-a9d6-db63a3e1e1c8** is the service principal for **Microsoft.AzureFrontDoor-Cdn**.

- > In order for the certificate to be automatically rotated to the latest version when a newer version of the certificate is available in your Key Vault, please set the certificate/secret version to 'Latest'. If a specific version is selected, you have to re-select the new version manually for certificate rotation. It takes up to 72 hours for the new version of the certificate/secret to be deployed.

-||||

-When calling the **Image Analysis - Segment** API, you specify the image's URL by formatting the request body like this: `{"url":"https://docs.microsoft.com/azure/cognitive-services/computer-vision/images/windows-kitchen.jpg"}`.

-var imageSource = VisionSource.FromUrl(new Uri("https://docs.microsoft.com/azure/cognitive-services/computer-vision/images/windows-kitchen.jpg"));

-When analyzing a remote image, you specify the image's URL by formatting the request body like this: `{"url":"https://docs.microsoft.com/azure/cognitive-services/computer-vision/images/windows-kitchen.jpg"}`.

-> The ```ConversationTranslator``` doesn't support Azure AD authentication.

-> [Next steps button](../concepts/models.md)

-| **Create identity** | 30 | 500|

-| **Issue access token** | 30 | 500|

-| **Revoke access token** | 1 | 100|

-To start generating the events, we must configure Azure Event Grid for our Azure Communication Services resource. Leveraging Event Grid generates an additional charge for the usage. More information on Event Grid pricing can be found on the [pricing page](https://azure.microsoft.com/pricing/details/event-grid/).

-> [Managed identities in Azure Container Apps](managed-identity.md)

-> [Tutorial: Communication between microservices](communicate-between-microservices.md)

-[availability-zone-overview]: ../availability-zones/az-overview.md

-[cloud-shell-bash]: ../cloud-shell/overview.md

-

-[azure-cli-install]: /cli/azure/install-azure-cli

-[azure-cli-install]: /cli/azure/install-azure-cli

-[az-resource-delete]: /cli/azure/resource#az-resource-delete

-[quay]: https://quay.io

-> [Create a database in Azure Cosmos DB for NoSQL using Python](how-to-python-create-database.md)

-* Learn about [private DNS zones](../../dns/private-dns-overview.md)

-## Enable cost management for customer tenant subscriptions

-## View and enable all policies

-You can also view and change policies for Azure reservations, Azure Marketplace, view Azure charges, and tag management in a single location. The policy settings apply to all customers under the billing profile.

-To view or change policies:

-1. In the Azure portal, navigate to **Cost Management** (not Cost Management + Billing).

-1. In the left menu under **Settings**, select **Configuration**.

-1. The billing profile configuration is shown. Policies are shown as Enabled or Disabled. If you want to change a policy, select **Edit** under a policy.

- :::image type="content" source="./media/get-started-partners/configuration-policy-settings.png" alt-text="Screenshot showing the billing profile configuration page where you can view and edit policy settings." lightbox="./media/get-started-partners/configuration-policy-settings.png" :::

-1. If needed, change the policy settings, and then select **Save**.

-To view costs for a subscription, open **Cost Management + Billing** in the customer's Azure tenant. Select **Cost analysis** and then the required subscription to start reviewing costs. You can view consumption costs for each subscription individually in the customer tenant.

-To know the Savings made out of public list price:

-Get public or list price cost. Multiply the `PayGPrice` value with `Quantity` values to get public-list-price costs.

-Get Savings made out of savings plan against public list price. Subtract estimated public-list-price costs from `Cost`.

-To know the % savings made out of discounted price for customer:

-Get Savings made out of savings plan against discounts given to customer. Subtract estimated pay-as-you-go from `Cost`.

-Get % discount applied on each line item. Divide `Cost` with public-list-price and then divide by 100.

-* Learn how to reference trigger metadata in pipeline, see [Reference Trigger Metadata in Pipeline Runs](how-to-use-trigger-parameterization.md)

-| [Monitor and manage pipelines using Monitoring App](data-factory-monitor-manage-app.md) |This article describes how to monitor, manage, and debug pipelines using the Monitoring & Management App. |

-To learn about how to copy data to/from a data store, click the link for the data store in the table.

-

-

-For details about the stored procedure activity, see the [Stored Procedure activity](data-factory-stored-proc-activity.md) article.

-[Deploy virtual machines on your Azure Stack Edge Pro GPU device using templates](azure-stack-edge-gpu-deploy-virtual-machine-templates.md).

-[Deploy VMs on your Azure Stack Edge Pro GPU device](azure-stack-edge-gpu-deploy-virtual-machine-portal.md).

-[Azure Resource Manager cmdlets](/powershell/module/azurerm.resources/?view=azurermps-6.13.0&preserve-view=true)

-Azure DDoS Protection provides detailed attack insights and visualization with DDoS Attack Analytics. Customers protecting their virtual networks against DDoS attacks have detailed visibility into attack traffic and actions taken to mitigate the attack via attack mitigation reports & mitigation flow logs. Rich telemetry is exposed via Azure Monitor including detailed metrics during the duration of a DDoS attack. Alerting can be configured for any of the Azure Monitor metrics exposed by DDoS Protection. Logging can be further integrated with [Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection), Splunk (Azure Event Hubs), OMS Log Analytics, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.

-Azure DDoS Protection provides detailed attack insights and visualization with DDoS Attack Analytics. Customers protecting their virtual networks against DDoS attacks have detailed visibility into attack traffic and actions taken to mitigate the attack via attack mitigation reports & mitigation flow logs. Rich telemetry is exposed via Azure Monitor including detailed metrics during the duration of a DDoS attack. Alerting can be configured for any of the Azure Monitor metrics exposed by DDoS Protection. Logging can be further integrated with [Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection), Splunk (Azure Event Hubs), OMS Log Analytics, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.

-Get detailed reports in five-minute increments during an attack, and a complete summary after the attack ends. Stream mitigation flow logs to [Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection) or an offline security information and event management (SIEM) system for near real-time monitoring during an attack. See [View and configure DDoS diagnostic logging](diagnostic-logging.md) to learn more.

-Azure DDoS Protection provides detailed attack insights and visualization with DDoS Attack Analytics. Customers protecting their virtual networks against DDoS attacks have detailed visibility into attack traffic and actions taken to mitigate the attack via attack mitigation reports & mitigation flow logs. Rich telemetry is exposed via Azure Monitor including detailed metrics during the duration of a DDoS attack. Alerting can be configured for any of the Azure Monitor metrics exposed by DDoS Protection. Logging can be further integrated with [Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection), Splunk (Azure Event Hubs), OMS Log Analytics, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.

-You can connect logs to Microsoft Sentinel, view and analyze your data in workbooks, create custom alerts, and incorporate it into investigation processes. To connect to Microsoft Sentinel, see [Connect to Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection).

-Azure DDoS Protection provides detailed attack insights and visualization with DDoS Attack Analytics. Customers protecting their virtual networks against DDoS attacks have detailed visibility into attack traffic and actions taken to mitigate the attack via attack mitigation reports & mitigation flow logs. Rich telemetry is exposed via Azure Monitor including detailed metrics during the duration of a DDoS attack. Alerting can be configured for any of the Azure Monitor metrics exposed by DDoS Protection. Logging can be further integrated with [Microsoft Sentinel](../sentinel/data-connectors-reference.md#azure-ddos-protection), Splunk (Azure Event Hubs), OMS Log Analytics, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.

-> For a better, richer investigation experience, stream your Azure activity logs to Microsoft Sentinel as described in [Connect data from Azure Activity log](../sentinel/data-connectors-reference.md#azure-activity).

-The recommendation "Machines should be configured securely" is going to be upgraded on March 20th to improve its performance and stability, and to align its experience with the generic behavior of MDC recommendations.

-As part of this update, the recommendation's ID will be changed from "181ac480-f7c4-544b-9865-11b8ffe87f47" to "c476dc48-8110-4139-91af-c8d940896b98".

-No action is required on the customer side, and there is no expected downtime nor impact on the secure score.

-In the scenario where an activity from a suspicious IP address is detected, one of the following Defender for Azure Resource Manager plan alerts `Azure Resource Manager operation from suspicious IP address` or `Azure Resource Manager operation from suspicious proxy IP address` will be present.

-The following security recommendations will be deprecated as part of this change:

-

-While you can view device details from any of these locations, each location also offers extra device inventory support. The following table describes the device inventory visible supported for each location and the extra actions available from that location only:

-|**OT network sensor consoles** | Devices detected by that OT sensor | - View all detected devices across a network device map<br>- View related events on the **Event timeline** |

-|**Building** | Access panels, surveillance devices, HVAC systems, elevators , smart lighting systems |

-The *new* status is removed as soon as you edit any of the device details move the device on an OT sensor device map. In contrast, the *unauthorized* label remains until you manually edit the device details and mark it as *authorized*.

-| **Device Id** | The device's Azure-assigned ID number|

-> Currently, having both the Microsoft Defender for IoT and the [Microsoft Defender for Cloud](../../sentinel/data-connectors-reference.md#microsoft-defender-for-cloud) data connectors enabled on the same Microsoft Sentinel workspace simultaneously may result in duplicate alerts in Microsoft Sentinel. We recommend that you disconnect the Microsoft Defender for Cloud data connector before connecting to Microsoft Defender for IoT.

-Start by enabling the [Defender for IoT data connector](../../sentinel/data-connectors-reference.md#microsoft-defender-for-iot) to stream all your Defender for IoT events into Microsoft Sentinel.

-To verify that data is flowing through the data history pipeline, navigate to the [Azure portal](https://portal.azure.com) and open the Event Hubs namespace resource you created. You should see charts showing the flow of messages into and out of the namespace, indicating the flow of incoming messages from Azure Digital Twins and outgoing messages to Azure Data Explorer. The image below shows what these charts might look like after an hour of running the simulator (but you should start to see some data after only a few minutes).

-In this section, you'll view all three types of historized updates that were generated by the simulator and stored in Azure Data Explorer tables.

-# Mandatory fields.

-#

-# Mandatory fields.

-#

-After establishing a data pipeline to send time series data from Azure Digital Twins to Time Series Insights, you might want to think about how to translate asset models designed for Azure Digital Twins into asset models for Time Series Insights. For a tutorial on this next step in the integration process, see [Model synchronization between Azure Digital Twins and Time Series Insights Gen2](../time-series-insights/tutorials-model-sync.md).

-# Mandatory fields.

-#

-# Mandatory fields.

-#

-You can use this panel to [view your twins and relationships](#view-twins-and-relationships).

-### View twins and relationships

-# Mandatory fields.

-#

-> [Connect an end-to-end solution](tutorial-end-to-end.md)

-# Mandatory fields.

-#

-To learn more, see [an overview of Azure Database Migration Service](dms-overview.md).

-* [FAQ about using Azure Database Migration Service](./faq.yml)

-* Review the migration guidance in the Microsoft [Database Migration Guide](/data-migration/).

-* Review the migration guidance in the Microsoft [Database Migration Guide](/data-migration/).

-For information about additional migrating scenarios (source/target pairs), see the Microsoft [Database Migration Guide](/data-migration/).

-* View the tutorial [Migrate Azure Database for MySQL - Single Server to Flexible Server offline using DMS via the Azure portal](tutorial-mysql-azure-mysql-offline-portal.md).

-

-* For tutorial about using DMS via portal, see the article [Tutorial: Migrate MySQL to Azure Database for MySQL offline using DMS](./tutorial-mysql-azure-mysql-offline-portal.md)

-* To troubleshoot, review [Known issues](known-issues-azure-sql-migration-azure-data-studio.md).

-description: Learn to perform an online migration from SQL Server to an Azure SQL Managed Instance by using Azure Database Migration Service (classic)

-* To troubleshoot, review [Known issues](known-issues-azure-sql-migration-azure-data-studio.md).

-**DNS resolution in the hub VNet**: The virtual network link from the private zone to the Hub VNet enables resources inside the hub VNet to automatically resolve DNS records in **azure.contoso.com** using Azure-provided DNS ([168.63.129.16](../virtual-network/what-is-ip-address-168-63-129-16.md)). All other namespaces are also resolved using Azure-provided DNS. The hub VNet doesn't use ruleset rules to resolve DNS names because it is not linked to the ruleset. To use forwarding rules in the hub VNet, create and link another ruleset to the Hub VNet.

-**DNS resolution in the spoke VNet**: The virtual network link from the ruleset to the spoke VNet enables the spoke VNet to resolve **azure.contoso.com** using the configured forwarding rule. A link from the private zone to the spoke VNet is not required here. The spoke VNet sends queries for **azure.contoso.com**, and any other namespaces that have been configured in the ruleset, to the hub VNet. DNS queries that don't match a ruleset rule use Azure-provided DNS.

-**DNS resolution in the spoke VNet**: In this example, the spoke VNet sends all of its DNS traffic to the inbound endpoint in the Hub VNet. Since **azure.contoso.com** has a virtual network link to the Hub VNet, all resources in the Hub can resolve **azure.contoso.com**, including the inbound endpoint (10.10.0.4). The spoke VNet also resolves all DNS names using rules provisioned in a forwarding ruleset if one is present and linked to the hub VNet.

-> In the centralized DNS architecture scenario, both the hub and the spoke VNets can use the optional hub-linked ruleset when resolving DNS names. This is because all DNS traffic from the spoke VNet is being sent to the hub due to the VNet's custom DNS setting. The hub VNet doesn't require an outbound endpoint or ruleset here, but if one is provisioned and linked to the hub (as shown in Figure 2), both the hub and spoke VNets will use the forwarding rules. As mentioned previously, it is important that a forwarding rule for the private zone is not present in the ruleset because this configuration can cause a DNS resolution loop.

-1. Navigate to the [Azure Dev Tools for Teaching webpage](https://azure.microsoft.com/education/institutions/).

-Now that you have assigned a system-assigned identity to your system topic, custom topic, or domain, and added the identity to appropriate roles on destinations, see [Deliver events using the managed identity](managed-service-identity.md) on delivering events to destinations using the identity.

- $resourceGroupName = <resource group name>

- $topicName = <topic name>

-description: This article provides Azure Monitor metrics supported by the Azure Event Grid service.

-# Metrics supported by Azure Event Grid

-This article provides lists of Event Grid metrics that are categorized by namespaces.

-## System topics

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|AdvancedFilterEvaluationCount|Yes|Advanced Filter Evaluations|Count|Total|Total advanced filters evaluated across event subscriptions for this topic.|EventSubscriptionName|

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason, EventSubscriptionName|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType, EventSubscriptionName|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason, EventSubscriptionName|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-## Custom topics

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|AdvancedFilterEvaluationCount|Yes|Advanced Filter Evaluations|Count|Total|Total advanced filters evaluated across event subscriptions for this topic.|EventSubscriptionName|

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason, EventSubscriptionName|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType, EventSubscriptionName|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason, EventSubscriptionName|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-## Domains

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|AdvancedFilterEvaluationCount|Yes|Advanced Filter Evaluations|Count|Total|Total advanced filters evaluated across event subscriptions for this topic.|Topic, EventSubscriptionName, DomainEventSubscriptionName|

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|Topic, EventSubscriptionName, DomainEventSubscriptionName, DeadLetterReason|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Topic, EventSubscriptionName, DomainEventSubscriptionName, Error, ErrorType|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|Topic, EventSubscriptionName, DomainEventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|Topic, EventSubscriptionName, DomainEventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|Topic, EventSubscriptionName, DomainEventSubscriptionName, DropReason|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|Topic, EventSubscriptionName, DomainEventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|Topic, ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|Topic|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-## Event subscriptions

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|No Dimensions|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|No Dimensions|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|No Dimensions|

-## Extension topics

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-## Partner namespaces

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason, EventSubscriptionName|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType, EventSubscriptionName|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason, EventSubscriptionName|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-## Partner topics

-|Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|

-||||||||

-|AdvancedFilterEvaluationCount|Yes|Advanced Filter Evaluations|Count|Total|Total advanced filters evaluated across event subscriptions for this topic.|EventSubscriptionName|

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason, EventSubscriptionName|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType, EventSubscriptionName|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason, EventSubscriptionName|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-## Next steps

-See the following article: [Diagnostic logs](diagnostic-logs.md)

-> For a list of metrics supported Azure Event Grid, see [Metrics](metrics.md).

- > For a list of metrics supported Azure Event Grid, see [Metrics](metrics.md).

-[Deploy resource with Bicep and Azure CLI]: ../azure-resource-manager/bicep/deploy-cli.md

- If you see values higher than number of TUs * limits (1 MB per second for ingress or 1000 requests for ingress/second, 2 MB per second for egress), increase the number of TUs by using the **Scale** (on the left menu) page of an Event Hubs namespace to manually scale higher or to use the [Auto-inflate](event-hubs-auto-inflate.md) feature of Event Hubs. Note that auto-Inflate can only increase up to 20 TUS. To raise it to exactly 40 TUs, submit a [support request](../azure-portal/supportability/how-to-create-azure-support-request.md).

-* **Microsoft Sentinel**: You can connect Azure Firewall logs to Microsoft Sentinel, enabling you to view log data in workbooks, use it to create custom alerts, and incorporate it to improve your investigation. The Azure Firewall data connector in Microsoft Sentinel is currently in public preview. For more information, see [Connect data from Azure Firewall](../sentinel/data-connectors-reference.md#azure-firewall).

-Azure Firewall is a cloud-native and intelligent network firewall security service that provides the best of breed threat protection for your cloud workloads running in Azure. It's a fully stateful, firewall as a service with built-in high availability and unrestricted cloud scalability. It provides both east-west and north-south traffic inspection.

-When you create your TLS/SSL certificate, you must create a complete certificate chain with an allowed certificate authority (CA) that is part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT). If you use a non-allowed CA, your request will be rejected. The root CA must be part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT). If a certificate without complete chain is presented, the requests that involve that certificate aren't guaranteed to work as expected.

-The common name (CN) of the certificate must match the domain configured in Azure Front Door.

-Azure Front Door doesn't support certificates with elliptic curve (EC) cryptography algorithms.

-## DenyAction

-for new and updated resources. And when the policy definition effect is [Deny](./effects.md#deny) or [DenyAction](./effects.md#denyaction), Policy stops the creation or alteration of the request.

-|3.3|March 22,2023|Public Preview|-|-|-|

-|3.3|March 22,2023|Public Preview|-|-|-|

-| Apache Spark | 3.3 * | 3.1.2 |

-|3.3|March 22,2023|Public Preview|-|-|-|